关于数据链路的任务调度

Home

关于数据链路的任务调度

做好数据调度,做好流程控制,就是做好数据

Directory

我是一名数据研发工程师,不同于前端后端工程师那样有明确的分工和完整的协作方法论,作为一名数据开发工作负责的部分涉及到数据链路的各个环节。 由于各个企业涉及的数据问题不同,数据开发的职责也存在很模糊的定位,好像跟数据擦边的都能叫数据开发,但是具体分工和职责又确实千差万别。 我不知道你是否经常熬夜处理问题,如果是的话,这是一篇讨论夜间任务调度的博客,希望你能从文中体会到感同身受之处。同时,本文也是我对自己、对这项工作的一个阶段性总结。

关于最开始

从我最开始的工作讲起来,其实也非常简单,那就是把线上的数据搬运到线下来。 用到的技术也非常简单,就是部署一个crontab任务。 这个crontab任务里需要调一个shell脚本,脚本负责数据的下载、压缩、传输、回滚。

完成整个数据搬运的工作流后,剩下的工作就是基于线下的数据开始分析。 那时候公司业务不过是刚刚起步,没有太过复杂的数据场景,于是就是python脚本写一堆查询去出最简单的PV、UV。

即便是如此简单的场景,依然遇到很多问题。 首先就是crontab时间差战争,线上任务凌晨1点开始执行,我们预期凌晨3点结束。 那就是想当然的把线下拉取数据的脚本启动时间设置到凌晨5点开始。 随着数据量不断上涨,线上任务直接执行到了凌晨6点。 第二天一早发现,线下任务启动失败。

还需要设计可容错的shell脚本,我花了很长时间一次次重构线上线下两段脚本,最终将脚本设计成模块化的,有点面向对象意思的脚本。 这样就可以在脚本执行出错的时候,手动的修改模块,注释掉已经执行成功的部分,缩短任务重试时间。

crontab + shell任务的执行状态是不可控不可预期不能精准处理失败的。即便是最优化的脚本,依然还是会遇到很多问题。比如cron进程被误杀,比如网络中断。

每天早晨醒来,第一件事就是看看任务是否执行成功。 为了失败任务尽快回滚,极端情况下,我在夜间各个时间段设置了闹铃,在代码各处设置了邮件报警。 即便是从线下SSH Callback到线上,也经常发生因为ssh长时间链接导致网络中断的问题。

让数据及时交付这件事,明明这么简单,我就杠上了。

关于探索期

随着企业业务发展,数据量增长是一个方面,另一个方面就是业务开始负责,你作为一个“数据工程师”要与不同的业务方不同的业务库打交道。 最开始的crontab开始显得难以应付,线性流程的数据调度,时间和空间维度都不再合适。于是开启了大数据之路。

什么是大数据,什么是大数据工程师,内心充满疑惑。技术栈拓展,似乎触碰到了数据最主流。 后来我才逐渐清醒,处理海量数据,不一定非要上Hadoop,大数据重要的是思想,处理数据的方法论。

当然,就算是大数据也得先解决数据任务调度问题,这个时候最著名的两个选择就是AzkabanOozie。 我们最后的选型是用Oozie,更多原因是我们的数据处理平台使用的是HDP。 也就是在这个时候,我终于清楚的知道这件事有个很官方的命名Workflow Scheduler。 而相应工具一般被称为Workflow Management Systems

疲于应付cron的不直观难控制,Oozie似乎成为了我的睡眠救星。 终于可以不再担心时间差了。

事实上,更复杂的处理场景才刚刚开始。 业务多了,就代表有多个Oozie任务需要部署。 但是从数仓建设角度将,这些任务又不可能完全独立分散。

痛点来了,Oozie不能清晰的表述出各个任务的依赖关系。 处理不好依赖关系,依然无法又好又快又安全的交付最终数据。

回到当下

终究是业务推动架构演化。复杂调度依赖的场景下,机缘巧合遇到Airflow,粗一看Apache Airflow的特性命中痛点。 你可能会搜到一堆Airflow特性,但是说白了选择使用这款工具的根本原因还不是馋人家Web UI吗?

人间首款开源的好用的可视化依赖关系图,用到就爽到。 依赖关系终于清晰了! 失败重试、小面积崩溃不影响主线,用的好就赚到。

Airflow从架构上也很好的解决了任务管理和自身鲁棒性:

explain_airflow_arch

最底层数据库负责存储各个任务元数据,以及任务状态。

数据持久层之上是统一的Scheduler调度模块,这部分可以做到多节点启动,防止因为单点故障导致Airflow停摆。 Scheduler会控制任务

Worker就是执行任务的具体进程。由Scheduler统一调度管理这些Worker的具体状态。其技术本质是Celery

我觉得理解好Airflow的整体架构,可以套用到其它分布式处理系统上去。

Web UI是Airflow的惊艳之处,底层系统的信息完美的反应到前端中,对DAG的图化展示可以让使用者清晰了解任务依赖关系,以及对每个task的状态反映和控制,都可以通过Web界面下操作完成。

在实际的生产环境使用上,我们大胆的使用了docker-compose做容器编排,将Airflow系统涉及的多个组件容器化管理。 这里对应有功能上的取舍,考虑到未来发展不可控,不能完全被一项技术绑死,全部调度任务均使用SSH Operator在容器内基于ssh远程调用。

不过调度系统使用依然没有完全银弹,在Airfow生产环境实践过程中,依然遇到重重困难。 印象深刻的几次生产环境事故,均也来自于Airflow使用不当导致。

首先跨DAG依赖,可能会发生乐观锁问题。比如A和B内的task相互依赖,就有可能发生一直相互等待。 其次是较为常发生的Airflow任务一直hangon,task没有报错也没有执行状态,或者干脆一直执行,这种情况最快的处理方式就是手动杀死具体任务ID。更本质原因是Worker在等待资源或者干脆是Scheduler方面的问题,需要调优增加并发度等。

回头来看,调度本质解决的是资源编排问题。 针对资源问题本身,需要具体下药,Spark任务就走Spark的调优策略,数据的问题就按数据库的处理方式反思解决。 调度系统本质是一个整体资源管理器。

最后

截止2020年5月前,我们每日调度任务已经有几百个task。这些task相互关联依赖,在数据层面也存在耦合。 依赖调度系统,才精准的实现了数据资源的管控。

至于我那该死的睡眠,终于可以把定时闹铃先取消了,但是夜间调度任务报错后,还是依赖Airflow的报警机制给我们运维人员打电话和发钉钉。 致命错误还是需要人为介入处理比较快捷。 但是打电话还是有问题,天大的巧合发生过:夜间家里断网,住的小区偶尔夜间就没有了手机信号,导致错过一个报警。

我是一个纯粹的数据研发工程师吗?还是不确定。 我有了完整的睡眠了吗?依然没有。

那到底有啥进步?技术升级? 不不不,我觉得唯一的进步就是应对错误更从容了。

最大的反思是什么? 一切的开始是数据搬运问题。到最后成了一个调度系统。 工作中需要培养由小见大的能力,具体说来就是要在调研阶段极度复杂化看待问题,最后再抽丝剥茧回归问题本身。 作为一个数据工程师,是和信息系统完全耦合的职业状态,不会有完全的生活边界。 认真工作没有错,将工作视为全部,就是对待生活不认真,对待生活不认真,对待问题又怎么能认真呢? 失眠算什么,职业生涯赌进去才是最大的错。

我走错了很多路,现在要咬牙扳回来。