数据工程领域当前遇到的挑战
现代系统正变得越来越复杂，从单线程到多线程，从单体到微服务，从单节点到分布式，从本地到云端... … 复杂度使得程序产生预期的结果需要越来越多的必要条件，而每种条件都有其自身的成功概率，即使每种条件的成功概率都很高，根据墨菲定律，或早或晚一定会遇到不可预知的结果。
在数据工程领域，这个问题尤其突出，目前大数据领域几乎都是分布式运行的任务、高可用的消息队列、多备份的存储、主从节点等等。在这样的情况下，如何构建稳定、健壮的任务或服务成为了一个挑战。而数据工程实践中每日调度的任务成为了与各个复杂数据组件交互的最主要形式，所以本文我们将以数据工程的任务调度为例，利用混沌工程帮助我们找出系统薄弱点或脆弱性，引出我们沉淀的基于日志驱动的任务调度实践。
什么是混沌工程？
混沌工程是在系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。(摘自：混沌工程原则)混沌工程通过以下四个步骤来找出系统中隐藏的“混沌”：
- 用系统在正常行为下的一些可测量的输出来定义“稳定状态”。
- 假设这个系统在控制组和实验组都会继续保持稳定状态。
- 在实验组中引入反映真实世界事件的变量，如服务器崩溃、硬盘故障、网络连接断开等。
- 通过控制组和实验组之间的状态差异来反驳稳定状态的假说。
混沌工程实验是通过向现有系统注入故障，从而发现系统的薄弱点，从而可以有针对性地提高整个系统的健壮性。
环境都是高可用的，应该很健壮啊
有些人可能会有疑问，“我们环境都是高可用的，应该很健壮啊”。这个问题还是要分开来看，健壮的系统能够忠实执行程序逻辑并得到最终结果。但是如果程序逻辑就是有问题的呢？或者，即使程序逻辑没有问题，由于程序本身的脆弱性，在系统从错误中恢复时可能没有处理一些必要的逻辑，导致最终结果出现问题。因此，系统级别的高可用性或健壮性与程序级别的健壮性是两回事，必须分开看待。二者缺一不可。在工程实践中，我们往往会过于关注基础设置是否具备高可用性，而忽略了程序逻辑的健壮性和错误恢复处理。
仅仅是幂等就足够了吗？
有些人认为他们的程序是幂等的，因此即使出错了可以重跑，所以不需要考虑其他。这里先讲一下幂等的定义：总能够用同样的参数重复执行，并得到相同的结果。
那我们可以按照混沌工程的四个步骤来模拟一个场景出来：
- 用系统在正常行为下的一些可测量的输出来定义“稳定状态”，这里尝试定义“稳定状态”为：
- ETL计算结果稳定且正确(幂等)
- 资源队列占用合理，提交的任务不需要等待太久就可以运行
- 过去的数据不会被重复计算
- 同一时刻不发生重复计算
- 假设这个系统在控制组和实验组都会继续保持稳定状态。
- 在实验组中引入反映真实世界事件的变量：手动调度任务时页面卡住了，习惯性多点了几次，刷新页面后发现调度起来了十几个任务。
- 通过控制组和实验组之间的状态差异来反驳稳定状态的假说：
- 资源队列被打满，新调度的任务都得排队（不符合稳定状态条件2）
- 重跑并覆盖过去已经运行过的数据（计算资源浪费，不符合稳定状态条件3）
- 计算同一天的数据几十次，而最终只留了最后那份（计算资源浪费，不符合稳定状态条件4）
通过上面的模拟实验我们可以知道，虽然ETL是满足幂等性（即稳定状态条件1）的，但是由于没有满足其他几个稳定状态，所以我们可以说它仍然是存在脆弱性的。
反脆弱的任务调度应该是什么样的？
对于一个每日运行的任务来说，理想情况下它应该每天都能成功完成，但实际情况下很可能会遇到失败的情况。不同的调度引擎往往对失败的情况有不同的处理方式。例如，有的调度引擎会忽略过去失败的任务并继续开启下一个调度周期。比如跳过了2022年2月2日的任务，继续运行2022年2月3日的任务。但当发现任务出现问题后，就需要手动补数据并重新运行2022年2月2日的任务，以便将数据完整地补齐。如果在这期间有报表使用了2022年2月2日的数据，那么这些报表的数据肯定是不准确的。
然而，完全依赖任务调度工具有一些缺点。首先，它完全依赖于调度工具的任务历史记录。如果没有配置失败通知机制，那么需要一个个去查看哪个任务挂掉了。其次，如果允许失败任务之后的任务继续运行，可能会导致对顺序有要求的场景出现问题。比如，假设2月3日的数据在MySQL中进行了upsert操作，而2月2日的数据在重新运行失败任务后又执行了一次，那么就会导致用旧的数据覆盖新的数据的问题等等。
虽然一些调度框架在适当的配置时可以解决上述问题，但无法保证所有调度框架都能解决这些问题，或者你的项目对调度框架没有自由选择的余地。因此，在实践中，我们需要在ETL任务和实际调度框架（如Airflow等）中引入“日志驱动”的这一层抽象隔离，以便为任务运行添加一层统一的逻辑处理。这样做可以使得ETL任务在不同的调度框架下表现一致，更加符合大家的预期，也不局限于某一个特定的调度框架。这样我们就得以摆脱特定框架的局限，而不是让每个人都要熟悉常见、不常见的调度框架。
数据工程的任务调度实践
前述问题的一个难点在于在处理重复提交的任务时如何隔离不同调度系统的具体实现。
我认为数据工程的任务调度应该以“日志驱动”作为解决方案。而日志驱动的重要部分“日志解耦”正是处理这个问题的利器：我们需要判断是不是有任务已经提交过了，对不对？同时要考虑到隔离不同调度系统，所以方案自然是需要一个单独的地方保存这些调度日志，以便在调度任务时检查是否需要调度（是否有相同任务在运行或者这个任务是否已经运行过等），从而解耦不同具体组件的日志。
注意这里的“日志”并不是任务运行的日志，而是调度任务的日志，记录的是那个任务在哪个时间调度，状态是什么等等。应用“日志驱动”所带来的的好处，远不止于此，因为留存了任务调度日志的记录，在这个基础上很多事情变得可能。其实“日志驱动”和“断点续传”这个概念很像，只不过没有应用在下载文件上，而是应用到了任务调度。日志驱动有几个核心要点：
- 自行记录任务运行历史，而不依赖与调度框架的功能。这样就做到了与不同调度框架解绑；
- 调度是有序的，上个周期任务失败了，不会跳过它运行下个周期的任务，每次调度还是会先执行之前失败的任务，直到它成功；
日志驱动也带来了几点好处：
- 可以解决重复调度的问题，当任务运行后发现有相同任务在运行或者已经运行过了，当前任务可以直接退出或者kill掉之前的任务
- 补数据操作更加容易实现且灵活而不容易出错
- 更加灵活的任务依赖配置（任务上下游不一定是同频率或者必须在一个dag里面）
- 更加灵活的调度起始设置，例如对于kafka offset和自增主键的支持
- 更加统一且容易的运维操作（不同的项目、不同的调度引擎，都可以基于日志驱动(的表)来进行运维操作）
- 可以记录更加详细的任务状态，比如读到多少条数据，写了多少条数据等等（特指结构化记录，而不是普通的执行日志），方便做统计查看
- 可以自行选择事务级别，或者说可以让用户选择是否要“脏读”数据
- 还有一些其他好处，篇幅有限就不在此展开了
回到现实场景，任务失败的情况大致可以分为两种：
- 重试就可以成功（网络闪崩，排队超时等）
- 代码、环境有问题需要人工介入的
对于重试就可以成功的情况，往往在下一次调度就可以自动补上之前失败的任务的数据；如果不想等到下一个周期，可以人工马上调度一次。
对于无法重试成功的情况，往往每次调度都会挂掉，但是只会尝试最开始的那天的任务，因为前置的任务没有成功，只是在每天重试 2022-02-02 的任务；无法重试成功的任务，仍然需要人工介入，修复（环境、逻辑、上游数据等问题）之后，自动（按顺序）补上之前挂掉的任务的数据；
总结
通过混沌工程的虚拟实验我们知道常规的任务调度并不足够健壮，而日志驱动的加入可以让ETL任务更加稳定。同时日志驱动也带来了诸多好处，不仅仅解决了混沌工程的稳定性问题，也更加丰富了数据工程实践。
