当数据工程遇到混沌工程

什么是混沌工程？

混沌工程是在系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。(混沌工程原则)

现代系统正变得越来越复杂，从单线程到多线程，从单体到微服务，从单节点到高可用，从本地到云端… …复杂度使得程序产生预期的结果需要越来越多的必要条件，而每种条件都有其自身的成功概率，即使每种条件的成功概率都很高，根据墨菲定律，或早或晚一定会遇到不可预知的结果。

混沌工程通过一下四个步骤来找出系统中隐藏的“混沌”：

首先，用系统在正常行为下的一些可测量的输出来定义“稳定状态”。
其次，假设这个在控制组和实验组都会继续保持稳定状态。
然后，在实验组中引入反映真实世界事件的变量，如服务器崩溃、硬盘故障、网络连接断开等。
最后，通过控制组和实验组之间的状态差异来反驳稳定状态的假说。

混沌工程实验是通过向现有系统注入故障，从而发现系统的薄弱点，从而可以有针对性的提高整个系统的健壮性。

环境都是高可用(HA)的，应该很健壮啊

有同学可能会有疑问，“我们环境都是高可用(HA)的，应该很健壮啊”。这个问题还是要分开来看，健壮的系统能够忠实的执行程序逻辑并得到最终结果。但是如果程序逻辑是错的呢？或者，程序逻辑没有错但是因为其自身的脆弱性，当系统从错误中恢复时没有处理一些必要的逻辑，导致最终的结果出现了问题。所以系统级别的高可用或者健壮性和程序级别的健壮性是两回事，一定要分开看待，且二者缺一不可。而在数据工程实践中我们往往聚焦于基础设置有没有做到高可用，而忽略了程序逻辑的健壮性。

仅仅是幂等就足够了吗？

有些同学觉得无所谓，我的程序是幂等的呀，报错了重跑不就完了。这里先讲一下幂等的定义：能够用同样的参数重复执行，并总能得到相同的结果。

那我们可以按照混沌工程的四个步骤来模拟一个场景出来：

用系统在正常行为下的一些可测量的输出来定义“稳定状态”，这里尝试定义“稳定状态”为：
1. ETL计算结果稳定且正确(幂等)
2. 资源队列占用合理，提交的任务不需要等待太久就可以运行
3. 过去的数据不会被重复计算
4. 同一时刻不发生重复计算
假设这个在控制组和实验组都会继续保持稳定状态。
在实验组中引入反映真实世界事件的变量：手动调度任务时页面卡住了，习惯性多点了几次，刷新页面后发现调度起来了十几个任务。
通过控制组和实验组之间的状态差异来反驳稳定状态的假说：
- 资源队列被打满，新调度的任务都得排队（不符合稳定状态条件2）
- 重跑并覆盖过去已经运行过的数据（计算资源浪费，不符合稳定状态条件3）
- 计算同一天的数据几十次，而最终只留了最后那份（计算资源浪费，不符合稳定状态条件4）

通过上面的模拟实验我们可以知道，虽然ETL是满足幂等性（即稳定状态条件1）的，但是由于没有满足其他记得稳定状态所以我们可以说它是存在脆弱性的。

常规的任务调度的其他问题

Log Driven

对于一个daily的任务，理想情况下是每天都会成功，但是实际上肯定会遇到失败的场景，不同的调度引擎往往对于失败的case有不同的处理逻辑。这里以忽略过去失败的任务，继续开启下一个调度周期为例，对比实例，跳过了2022-02-02的任务，继续运行 2022-02-03的任务。当发现任务出问题之后，需要手动补数据，手动重新运行2022-02-02的任务，把数据补上去。（这里如果有报表使用了2022-02-02的数据，那么报表的数据肯定是不准确的）

缺点：完全依赖于调度工具的任务历史记录，如果没有配置失败通知机制，需要一个个去看哪个任务挂掉了。如果允许失败任务之后的任务继续运行，可能会导致对顺序有要求的场景下出问题，比如 2月3日的数据在mysql做了upsert操作，2月2日的又做了一次（在修复失败之后），就会导致用旧的数据覆盖新的数据的问题。

这里也不否认有些调度框架在适当的配置时也能解决上述问题，但是没有人能保证所有的调度框架都能解决上面的问题或者你的项目对于调度框架有自由选择的空间。所以在实践中我们需要在ETL任务和实际调度框架（如airflow）中通过“日志驱动”做一层隔离，加入的这一层统一的逻辑处理可以使得ETL任务在不同的调度框架下行为一致，符合大家的预期，而不是让所有人都精通常见的调度框架。

那该怎么办？

针对这个问题，我认为“日志解耦”是必要的解决方案。观察上面的问题可以思考，重复提交的任务应该怎么组织呢？我们需要判断是不是有任务已经提交过了，对不对？同时要考虑到隔离不同调度系统，所以方案自然是需要一个单独的地方保存这些调度日志，以便在调度任务时检查是否需要调度（是否有相同任务在运行或者这个任务是否已经运行过等）。

注意这里的“日志”并不是任务运行的日志，而是调度任务的日志，记录的是那个任务在哪个时间调度，状态是什么等等。

“日志解耦”的结果是通过日志来驱动任务运行，所谓的“日志驱动”，其实和“断点续传”这个概念很像，只不过没有应用在下载文件上，而是应用到了任务调度。日志驱动有几个核心要点：

自行记录任务运行历史，而不依赖与调度框架的功能。这样就做到了与不同调度框架解绑；
调度是有序的，上个周期任务失败了，不会跳过它运行下个周期的任务，每次调度还是会先执行之前失败的任务，直到它成功；

日志驱动也带来了几点好处：

可以解决重复调度的问题，当任务运行后发现有相同任务在运行或者已经运行过了，当前任务可以直接退出或者kill掉之前的任务
补数据操作更加容易实现且灵活而不容易出错
更加灵活的任务依赖配置（任务上下游不一定是同频率或者必须在一个dag里面）
更加灵活的调度起始设置，例如对于kafka offset和自增主键的支持
更加统一且容易的运维操作（不同的项目、不同的调度引擎，都可以基于日志驱动(的表)来进行运维操作）
可以记录更加详细的任务状态，比如读到多少条数据，写了多少条数据等等（特指结构化记录，而不是普通的执行日志），方便做统计查看
可以自行选择事务级别，或者说可以让用户选择是否要“脏读”数据
还有其他的好处，篇幅有限就不在此展开了

Log Driven

回到现实场景，任务失败的情况大致可以分为两种：

重试就可以成功（网络闪崩，排队超时等）
代码、环境有问题需要人工介入的

对于重试就可以成功的情况，往往在下一次调度就可以自动补上之前失败的任务的数据；如果不想等到下一个周期，可以人工马上调度一次。

对于无法重试成功的情况，往往每次调度都会挂掉，但是只会尝试最开始的那天的任务，因为前置的任务没有成功，只是在每天重试 2022-02-02 的任务；无法重试成功的任务，仍然需要人工介入，修复（环境、逻辑、上游数据等问题）之后，自动（按顺序）补上之前挂掉的任务的数据；

总结

通过混沌工程的虚拟实验我们知道常规的任务调度并不够稳定，而日志驱动的加入可以让ETL任务更加稳定。同时日志驱动也带来了诸多好处，不仅仅解决了混沌工程的稳定性问题。

Original link：https://izhangzhihao.github.io//2022/05/30/当数据工程遇到混沌工程/

Zhihao's Blog