表白网站怎么做,电网商城,花瓣网 素材 图库,做美食软件视频网站有哪些目录
一、业务痛点
二、应用现状
三、技术改造
3.1 稳定性
3.1.1 滚动重启黑名单机制精准路由
3.2 易用性
依赖节点优化
补数任务优化
多 SQL 执行 原文大佬的这篇基于调度系统的数据治理案例有借鉴意义#xff0c;这里摘抄下来用作学习和知识沉淀。
一、业务痛点 蔚…目录
一、业务痛点
二、应用现状
三、技术改造
3.1 稳定性
3.1.1 滚动重启黑名单机制精准路由
3.2 易用性
依赖节点优化
补数任务优化
多 SQL 执行 原文大佬的这篇基于调度系统的数据治理案例有借鉴意义这里摘抄下来用作学习和知识沉淀。
一、业务痛点 蔚来汽车构建一个统一的数据中台之前我们面临这样一些业务痛点和困境
1数据缺乏治理数仓不规范、不完整 没有统一的数据仓库无全域的数据资产视图 存在数据孤岛
2工具散乱用户权限不统一学习成本高
用户需要在多个工具之间切换导致开发效率低底层运维成本高
3数据需求响应周期长找数难取数难
无沉淀的数据资产与中台能力重复处理原始数据业务数据需求从提出到获取结果的周期长 基于这些痛点和问题我们构建了一个公司层面的业务中台内部叫做 DataSight。 由上图可知最底下是一些基础组件往上一层这些基础组件主要是支撑了一些数据接入与开发的模块再向上是数据治理以及数据资产与应用层模块。其中 DolphinScheduler调度系统的在公司内部主要应用于交互的模块就是数据开发和数据运维两个模块。
二、应用现状 作业现状DolphinScheduler 版本2.0.7集群机器共有 9 台分别是两台 Master 机器是8c 和 32G六台 Worker 机器,16c 和 64G以及一台 Alert 机器8c 和 32G。目前DS线上运行大概一年多日均的调度工作流实例大概在 4w日均调度任务实例大概在 10w 左右主要的任务节点有Spark 节点、SparkSQL、prestoSQL、Python 和 Shell其中 Spark 节点占比约 70%。
三、技术改造 为了适应业务需求我们对DolphinScheduler 进行了一些技术改造核心目标是确保作业调度稳定性。
3.1 稳定性
3.1.1 滚动重启黑名单机制精准路由 这个改造是因为我们遇到的一些痛点首先大家知道DolphinScheduler 的 Worker 重启机制在重启时会把所有的任务给 kill 掉然后去Restart 这个任务把这个 kill 的任务分发到新的 Worker 机器上。这样会导致任务执行时间较长这不符合我们的预期。 同时我们也无法在特定的worker上进行验证任务的对比我们的解决方案就是滚动重启在重启某台机器之先下线这台机器也就是加上黑名单这样的话Master 机器就不会给这台下已经下线的机器去分发Worker任务。这台机器会在上面的任务全部处理完毕后自动上线也就是移出这个黑名单接下来所有的worker节点都按照此时方式重启达到平滑重启的目标。 这样做的好处在于不会阻塞每个任务的执行集群在重启的时候稳定性能得到大幅提升。 如图所示我们在这个任务后面加一个specific dispatch-worker02 的话那这个任务一定会被分配到Worker02这台机器上去。这样的好处在于假设我们想要去某一个功能点我们只需要把某一台Worker 机器下线重启需要测试的功能点按照这个方式就一定能够打到这台特定的机器上去实现最小范围的灰度有助于提高稳定性。 优化存储 在存储方面我们痛点也很明显就是process instance和task instance 这两张表数据量是比较大的由于我们每天的数据量比较大目前已经达到了千万级别造成 MySQL 的存储压力比较大。另外部分 SQL 执行时间长业务响应变慢而且 DDL 时会造成锁表导致业务不可用。 针对这些问题我们的解决方案包括去梳理所有的慢 SQL然后去添加合适的索引。与此同时还有降低查询频率特别是针对依赖节点。因为我们知道依赖节点每 5 秒钟查询一次数据库所以我们根据依赖节点所在的 tasks instance ID 去做一个“打散”偶数节点每 30 秒查询一次奇数节点每 30 秒查询一次把他们分开来降低对整个数据库的查询压力。 另外为了减轻表数据量大的问题我们也做了一个定期删除的策略以及定时同步历史数据的策略。 定时删除就是我们利用 DolphinScheduler 自身的调度能力建立两个工作流去删除这两张表保证 process instance 这张表保留两个月的数据task instance 这张表保留一个月的数据。同时在删表的时候我们要注意在非业务高峰期时去做这个动作每次删表的时候batch size 要控制好尽量不要影响线上的任务。 定时同步历史数据就是我们针对 process instance这个表依据schedule time 按年去分表针对task instance这张表按first submit time 按月去分表。 Spark任务优化 我们提交Spark任务的方式是通过Spark Submit 去提交的它的缺点在于提交 Spark 任务后常驻机器导致机器内存过大会有机器宕机的风险worker 的运行效率较低。我们优化了 Spark 任务提交和运行的逻辑就是通过 Spark Submit 提交的时候添加spark.yarn.submit.waitAppCompletionfalse 这个参数这样任务提交完以后这个进程就消失了。考虑到要保证Worker 机器任务的线程和Spark 和 Yarn 上的状态一致我们间隔一定时间查询 Spark任务状态如图所示 这里的while true循环首先去判断这个任务是否超时如果任务已经超时就会结束这个spark任务同时会kill掉集群上的那个真正在跑的任务。 如果任务没有超时我们会去获取任务的状态如果任务状态是终止状态就直接跳出这个循环否则会间隔一定的时间比如 30秒再继续这个while true 循环。这种方式让整个 Worker 机器所能承载的Spark任务大大增加。
3.2 易用性 依赖节点优化 我们的依赖节点之前的痛点在于它的使用规则不太符合用户的需求比如之前是单次查询不到上游即失败日志内容显示信息不全对用户不友好用户无法自定义依赖范围。 针对这些问题我们做的工作包括修改了查询逻辑为继续等待就是说当这个任务查询不到上游的时候我们会继续等待而不是直接失败。同时我们会也有个极端的保证就是这个依赖节点超过 24 小时以后就让它自动失败然后给用户发一个报警。 针对依赖节点我们也做了强制成功这样一个小技巧并支持用户自定义依赖范围。 另外我们还优化了依赖节点的日志输出当用户点击依赖节点的日志的时候可以比较清楚地看到依赖的上游所在的空间这个空间内任务所对应的维护人是什么以及工作流节点是什么和完成状态让用户可以点对点地找到上游的同学快速解决这个依赖节点卡住的问题。 补数任务优化 针对补数之前的痛点比如补数任务没有进度提示并行补数流程实例不严格按照时间顺序停止并行补数任务逻辑比较麻烦等问题我们的解决方案包括并行任务引入线程池也就是把任务按照时间顺序一个一个抛到新建的线程池里执行完毕以后退出这个线程池然后再放一个新的进来达到并行补数的状态。同时执行时间按递增的顺序。 当我们想停止这个补数任务的时候也比较简单直接把这个线程池 shutdown 就行。 多 SQL 执行 最后是关于多 SQL 执行方面的优化。我们之前面临的痛点包括 多 SQL 需要多节点执行浪费集群资源 自定义环境变量无法实现 无法跟踪 SparkSQL 的运行日志。 我们的解决方案包括拆分这条 SQL支持多条 SQL 同时执行。与此同时我们可以在 SparkSQL 任务执行之前拦截执行select engine_id() as engine_id语句。 如上图所示对于 SQL 1 和 SQL 2之前我们会在两个任务里面去放着但是现在可以在一个任务节点里面放下来它会执行两次。同时我们可以清晰地看到这个 SparkSQL 所在的 application ID 是什么用户能够清晰地根据这个 application ID 找这个业务所在的地址了解这个作业的进度。
参考文章
日均调度 10W 任务实例DolphinScheduler 在蔚来汽车一站式数据治理开发平台的应用改造
