Migrate from Airflow to StepFunction for a Supply Chain Company#

Keywords: AWS Step Function, StepFunction, SFN, Case Study

Overview#

帮助一个物流公司解决在人员紧缺的情况下, 大量任务积压, 以及 data visibility 下降的问题. 以及希望能够适应不断增长的数据量和业务需求.

Situation#

  • 有一个 supply chain 企业 (Infor, 有 10k+ 雇员), 它们的各种业务系统都跑在 AWS 上, 由许多大大小小的服务组成.

  • 其中 Data Team 一直在用 AWS Airflow 来管理它们的 ETL 任务以及报表任务. 这些任务的都不复杂, 但是需要做的任务数量很多.

  • 在 COVID 期间, 它们的 Data Team 人员因为搬去了其他地方离开了 从 10 人下降到了 3 人, 但是它们的业务却增长了不少.

  • 由于 Airflow 本身是一个服务器, 需要人来维护, 特别是在不断增长的业务面前, scale out 就成为了问题, 而 scale out 本身也需要人来维护.

  • 另外由于写这些工作流编排程序的人既需要懂数据和业务, 还需要会开发 Airflow 的程序. 这样的复合型人招聘不好找, 它们之前通常都是内部培养的.

  • 由于总任务量很大, 人员流失后他们的新任务就积压了很多, 一些旧的任务 crush 了也没有人手修复, 导致 data visibility 下降的很严重.

Task#

  • 客户找到了 AWS, 希望能找到一个解决方案, 希望在 6 个月内解决积压的任务, 恢复 data visibility.

  • 我是负责这个 Case 的 Solution Architect, 负责跟他们的 Business 和 Data Engineer Team 对接.

  • 根据我的观察, 解决积压的任务, 恢复 data visibility 只是结果, 不是 root cause. 而 root cause 则是:

    • 维护基础设施的人手不够

    • Airflow 不能根据业务量的增长 scale out

    • 不容易招聘到同时具有数据业务能力以及 Airflow 编程能力的人

  • 所以我重点解决这三个 root cause.

Action#

我将这个需求分拆成了 4 步:

  1. 了解这个项目的实际需求, 以及 Data Team 的上下游系统和人员关系.

  2. 制定详细的解决方案, 给客户做 demo, 并且得到客户的确认.

  3. 制定详细的实施计划, 规划时间线, 评估每个阶段需要的人, 以及计划要达到的目标.

  4. 对人员进行培训, 以及具体执行.

遇到的难点:

  1. 这个项目的需求都不复杂, 但是数量多, 而且对外部的影响较大. 我作为外人很难快速的把业务逻辑都弄清楚.

  2. 这个项目来自于客户独特的需求, 我无法说就简单的推荐一个产品就期待能解决所有问题. 我必须为客户的需求量身定做解决方案.

  3. 具体的实施也不容易, 因为这个项目的人员流失严重, 人手不够, 但是任务量又很大.

其中我的具体行动是这样的:

  1. 了解这个项目的实际需求, 以及 Data Team 的上下游系统和人员关系.

    • 了解谁是这个系统的 downstream data consumer, 谁需要这个 dashboard report, 如果没有这些数据和 report, 会造成什么影响, 这些影响有多大, 并且对他们排序.

    • 了解谁是这个系统的 upstream data producer, 他们能提供什么样的帮助.

    • 具体这个 Data Team 的人员关系, 以及各自的技能水平. 谁能拍板做决定, 谁是开发的主力, 我可以 leverage 谁来帮我做事情. 从而让我专注于设计解决方案, 而让 Data Team 上的人帮我理清业务逻辑 (解决难点 1)

  2. 制定详细的解决方案, 给客户做 demo, 并且得到客户的确认.

    • 根据需求, 初步方案有两种.

    • 一是用 AWS MWAA 让 AWS 完全托管管理 Airflow, 减轻了运维的压力, 并且让扩容变得简单.

    • 二是迁徙到 AWS Step Function (SFN), 完全避免了运维, 并且可以几乎无限扩容.

      • 虽然对于团队中已有的 Engineer 来说, 需要学习 Pickup, 但是由于 SFN 天生比较简单, 并且 Low code, 这使得让负责 ETL 和 Generate report 的 Data Engineer 就能帮忙负责工作流编排, 因为他们已经有了业务知识, 对编排的逻辑更了解, 避免了 knowledge transfer, 而无需像以前一样要专人来编排. 总体来说项目进度是加快了的 (解决了难点 3).

      • 而对于企业招聘来说, 新人无论如何都要 pickup 学习, 而 pickup SFN 的难度要比 Airflow 更低 (开发环境友好), 所以也更好招人.

    • 经过比较, 客户最终选择了迁徙到 SFN. (解决难点 2)

  3. 制定详细的实施计划, 规划时间线, 评估每个阶段需要的人, 以及计划要达到的目标.

    • 第一步是任务调研, 对任务进行排序. 我和客户都认为需要重点解决积压的任务, 而不是迁徙已有的任务. 这个阶段主要是和他们的 business team 以及以前做工作流编排的人对接

    • 第二步是对人员进行培训, 让它们学会 SFN. 我自己制定了培训资料, 以及用了一个积压任务中的实际问题作为例子教他们. 并且把这个教学过程录下来, 以及优化了培训材料, 以便于可以重复利用与培训新人.

    • 第三步是进行测试, 一是看看基于 SFN 的编排连续跑一个礼拜, 是否能满足业务需求. 二是评估开发速度, 计算人力资源的需求和开发进度.

    • 第四步是重复前面的三步, 招聘并 onboard 新人, 并且逐步完成迁徙, 解决积压的任务.

  4. 对人员进行培训, 以及具体执行.

    • 在执行的过程中. 其中的重点是培训材料以及参考手册. 因为这个资料会被已有的 Data Engineer 学习, 还好会用在对新招聘的人的培训上, 在整个迁徙的过程中也会不断地参考这个资料. 这是我的专业, 这个任务由我来负责, 并且根据客户的反馈不断地优化, 尽量用实际的生产 use case 来做培训材料.

Result#

  • 我希望不仅仅是解决积压的任务, 而是从架构设计上就保证以后这种任务积压不再出现, 以及在人员短缺的情况下有应对方案.

  • 在大约第二个月的时候我估算 6 个月不够. 根客户商量之后, 客户也选择了延长 3 个月, 然后彻底根治这个问题.

  • 最终经过 9 个月的开发, 结果如下:

    • 我们在只招聘了 2 个新的 junior engineer 的情况下, 以及在懂业务的 Data Engineer 的情况下, 将 70 个 DAG 中的 60 多个迁徙到了 SFN, 并且解决了全部积压的 20 多个任务.

    • 上线了新的 business metrics 以及新的 dashboard analysis.

    • 并且目前的架构设计能支持 10 倍于现有的数据量和工作流编排的数量.

    • 同时给 AWS 带来了每年 320K 美金的收入.

    • 同一时间, 我还服务了 2 个其他的客户, 这里我们不提了, 给 AWS 带来的收入达到了快 1M.