Fordeal的数据平台调度零碎之前是基于Azkaban进行二次开发的，然而在用户层面、技术层面都存在一些痛点问题难以被解决。比方在用户层面短少工作可视化编辑界面、补数等必要性能，导致用户上手难体验差。在技术层面，架构过期，继续迭代难度大。基于这些状况，通过竞品比照和调研后，Fordeal数据平台新版零碎决定基于Apache DolphinScheduler进行降级革新。那整个迁徙过程中开发人员是如何让应用方平滑过渡到新零碎，又做出了哪些致力呢？

5月 Apache Dolphinscheduler  线上 Meetup， 来自 Fordeal 的大数据开发工程师卢栋给大家分享了平台迁徙的实践经验

讲师介绍

卢栋Fordeal 大数据开发工程师。5年的数据开发相干教训，目前就任于Fordeal，次要关注的数据技术方向包含：湖仓一体、MPP数据库、数据可视化等。

本次演讲次要蕴含四个局部：

  • Fordeal数据平台调度零碎的需要剖析
  • 迁徙到Apache Dolphin Scheduler过程中如何适配
  • 适配实现后如何实现特新加强
  • 将来布局

01 需要剖析

01 Fordeal 利用背景

Fordeal 数据平台调度零碎最早是基于Azkaban进行二次开发的。反对机器分组，SHELL动静参数、依赖检测后勉强能够满足应用，但在日常应用中仍然存在以下三个问题，别离是在用户、技术和运维的层面。

首先在用户层面，不足可视化的编辑、补数等必要的性能。只有技术的同学能力应用该调度平台，而其余没有根底的同学如果应用就非常容易出错，并且Azkaban 的报错模式导致开发人员对其进行针对性地进行批改。

第二在技术层面，Fordeal 数据平台调度零碎的技术架构十分古老，前后端并不拆散，想要减少一个性能，二开的难度十分高。

第三在运维层面，也是最大的问题。零碎不定时会进去 flow 执行卡死的问题。要解决这个问题，须要登录到数据库，删除 execution flow外面的ID，再重启 Worker 和 API服务，过程非常繁琐。

02 Fordeal 所做的调研

因而，在2019年Apache DolphinScheduler开源时，咱们就及时地关注到，并开始理解是否能够进行迁徙。过后一起调研了三款软件，Apache Dolphin Scheduler、Azkaban和Airflow。咱们基于五大需要。

  1. 首选JVM系语言。因为JVM系语言在线程、开发文档等方面较为成熟。

    Airflow基于Python其实和咱们当初的体系并无二异，非技术同学无奈应用

  2. 分布式架构，反对HA。Azkaban的work并不是分布式web和master服务是耦合在一起，因而属于单节点。
  3. 工作流必须反对DSL和可视化编辑。这样能够保障技术同学能够用DSL进行书写，可视化则面向用户，用以扩充用户面。
  4. 前后端拆散，支流架构。前后端能够离开进行开发，剥离开来后耦合度也会升高。
  5. 社区活跃度。最初关注的的社区活跃度对于开发也非常重要，如果常常存在一些“陈年”老bug都须要本人进行批改，那会大大降低开发效率。

03 Fordeal 当初的架构

现在咱们的数据架构如上图。Apache Dolphin Scheduler承接了整个生命周期从HDFS、S3采集到K8S计算再到基于Spark、Flink的开发。两边的olphinScheduler和Zookeeper都是作为基础性的架构。咱们的调度信息如下：Master x2、Worker x6、API x1（承载接口等），目前日均工作流实例：3.5k，日均工作实例15k+。（下图为1.2.0版本架构图）

02 适配迁徙

01 外部零碎对接

Fordeal外部零碎须要上线对用户提供拜访，这时候必须对接几个外部服务，以升高用户上手老本和缩小运维工作。次要包含以下三个零碎。

  1. 单点登录零碎：

    基于JWT实现的SSO零碎，一次登录，认证所有。

  2. 工单零碎：

    DS对我的项目的受权接入工单，防止人肉运维。

    （接入所有受权动作，实现自动化）

  3. 告警平台：

    扩大DS告警模式，将告警信息全副发送到外部告警平台，用户可配置电话、企业微信等模式告警。

下方三张图就是对应别离是登录零碎、工单权限和企业微信的告警。

02 Azkaban 的兼容

Azkaban的Flow治理是基于自定义的DSL配置，每个Flow配置蕴含的Node数量多则800+少则1个，其更新的形式次要有三类。

1、用户本地保留，每次批改后zip压缩上传，用户自行保护Flow的信息。2、所有的flow配置和资源都托管git，在Azkaban我的项目设置中绑定git地址，git是由咱们自行开发的，git提交后在页面点击刷新按钮。3、所有的Flow托管到配置核心，对接Azkaban的上传接口去笼罩掉之前的调度信息。

上图为一部分数仓我的项目的flow配置文件。想要把Azkaban迁徙到Apache DolphinScheduler中，咱们一共列出了十点需要。

  1. DS上传接口反对Flow配置文件的解析并生成工作流。（反对嵌套flow）Flow的配置文件就相当于 Azkaban 的DAG文件，如果不配适咱们就要本人写代码解析配置文件，将Flow转成Json。
  2. DS资源核心反对文件夹（托管Azkaban我的项目下的所有资源）过后咱们的1.2.0版本过后没有文件夹性能，而咱们的数仓有许多文件夹，因而咱们必须要反对。
  3. DS提供client包，提供根底的数据结构类和工具类，不便调用API，生成工作流的配置。
  4. DS反对工作流并发管制（并行或跳过）
  5. DS工夫参数需反对配置时区（例如：dt=$[ZID_CTT yyyy-MM=dd=1]）。尽管咱们配置的时区大多在海内，但对于用户而言，他们更心愿看到北京时区。
  6. DS跑数和部署界面反对全局变量覆写。因为咱们的版本较低，一些相似补数的性能都没有，工作流用什么变量跑，心愿用户能够本人设置。
  7. DS DAG图反对task多选操作。
  8. DS task日志输入最终执行内容，不便用户查看调试。
  9. DS 反对运行中失败工作手动重试。通常一次跑数仓须要数个小时，其中有几个task可能因为代码问题报错，咱们心愿能够在不中断工作流的状况下，手动重试，把谬误的节点逐个批改完后重试。这样最终的状态是胜利的。
  10. 数仓我的项目需反对一键迁徙，放弃用户的工作习惯（jenkins 对接DS）。

在咱们与五六个组进行一直的沟通和革新后，这十点需要最终满足。

03 性能优化汇总

从 Azkaban 齐全迁徙到 Apache DolphinScheduler 实现大略用时一年，因为波及到API用户，波及到 git 用户，还有反对各种各样性能用户，每个项目组都会提出本人的需要，在帮助其余团队迁徙的整个过程中，依据用户应用反馈，共提交了140+个优化 commit，以下是 commit 分类词云。

03 个性加强

01 前端重构

对于为什么咱们要重构，咱们的痛点到底是什么？咱们列出了一下几点。首先，Azkaban的操作步骤过于繁琐。用户想要找一个工作流定义时，首先要关上我的项目，找到我的项目首页中的工作流列表，再找到定义，用户无奈一眼找到我想要的定义。第二，我无奈通过名字、分组等条件检索到工作流定义和实例。第三，无奈通过URL分享工作流定义和实例详情。第四，数据库表和API设计不合理，查询卡顿，常常会呈现长事务告警。第五，界面很多中央写死布局，如设置了宽度，导致增加列不能很好适配电脑和手机。第六，工作流定义和实例短少批量操作。但凡程序必定有谬误，如何批量重试，成为用户十分头疼的问题。

执行计划

  1. 基于 AntDesign 库开发新的一套前端界面。

  2. 弱化我的项目概念，不想让用户过多去关注我的项目这个概念，我的项目只作为工作流或实例的标签。

    目前电脑版只有四个入口，首页、工作流列表、执行列表和资源核心列表，手机版只有两个入口，别离是工作流列表和执行列表。

  3. 简化操作步骤，将工作流列表和执行列表放在第一入口。

  4. 优化查问条件和索引，减少批量操作接口等。

    减少联结索引。

  5. 齐全适配电脑和手机（除了编辑 dag ，其余性能都统一）

02 依赖调度

什么是依赖调度？即工作流实例或 Task 实例胜利后被动登程上游工作流或 Task 跑数（执行状态为依赖执行）。构想以下几个场景，上游工作流须要依据上游工作流的调度工夫去设置本人的定时工夫；上游跑数失败后，上游定时跑数是也会呈现谬误；上游补数，只能告诉所有上游业务方补数。数仓上下游定时距离调整难，计算集群资源利用率没有最大化（K8S）。因为用户并不是继续提交的。

构思图（按层触发工作流）

依赖调度规定

  1. 工作流反对工夫，依赖，两者组合调度（且与或）
  2. 工作流内的Task反对依赖调度（不受定时限度）。
  3. 依赖调度须要设置一个依赖周期，只有当所有的依赖在这个周期内满足才会触发。
  4. 依赖调度最小的设置单位是 Task ，反对依赖多个工作流或 Task （只反对且关系）。
  5. 工作流仅仅只是一个执行树中的组概念，就是说不会限度Task。

手机工作流依赖详情

03 工作拓展

拓展更多的 Task 类型，将罕用的性能形象并提供编辑界面，升高应用老本，咱们次要扩大了以下几个。

  1. 数据开放平台（DOP）：

    次要是提供数据导入导出性能（反对Hive、Hbase，Mysql、ES、Postgre、Redis、S3）

  2. 数据品质：基于Deequ开发的数据校验。

    对数据进行形象供用户应用。

  3. SQL-Prest数据源：SQL模块反对Presto数据源
  4. 血统数据采集：内置到所有Task中，Task裸露血统须要的所有数据

04 监控告警

架构为Java+Spring下的服务监控，平台是有一套通用的Grafana监控看板，监控数据存储在Prometheus，咱们的准则是服务外部不做监控，只须要把数据裸露进去即可，不反复造轮子，革新列表为：

  1. API、Master和Worker服务接入micrometer-registry-prometheus，采集通用数据并裸露Prometheus采集接口。
  2. 采集Master和Worker执行线程池状态数据，如Master和Worker正在运行的工作流实例、数据库等，用于后续的监控优化和告警（下右图）。
  3. Prometheus侧配置服务状态异样告警，比方一段时间内工作流实例运行数小于n（阻塞）、服务内存&CPU告警等等。

04 将来布局

01 跟进社区个性

目前Fordeal线上运行的版本是基于社区第一个**Apache版本（1.2.0）**进行二开的，通过监控咱们也发现了几个问题。

  1. 数据库压力大，网络IO费用高
  2. Zookeeper 充当了队列角色，时不时对导致磁盘IOPS飙升，存在隐患
  3. Command 生产和Task散发模型比较简单，导致机器负载不平均
  4. 这个调度模型中应用了十分多的轮询逻辑（Thread.sleep），调度生产、散发、检测等效率不高

社区倒退迅速，当下的架构也更加的正当易用，很多问题失去了解决，咱们近期比拟关注的问题是Master间接对Worker的散发工作，加重Zookeeper 的压力，**Task 类型插件化，易于后续扩大。**Master配置或自定义散发逻辑，机器简单更加正当。更完满的容错机制和运维工具（优雅高低线），当初Worker没有优雅高低线性能，当初更新Worker的做法是切掉流量，让线程池归零后再高低线，比拟平安。

02 欠缺数据同步

目前只提供了工作流实例的执行统计，粒度比拟粗，后续须要反对更细化的统计数据，如依照 Task 筛选进行统计分析，依照执行树进行统计分析，依照最耗时的执行路径分析等（对其进行优化）。

再次，减少更多的数据同步性能，如执行统计增加同步、环比阈值告警等性能，这些都是基于工作流的告警。

03 连贯其余零碎

当调度迭代稳固后，会逐渐充当根底组件应用，提供更加便当的接口和可嵌入的窗口（iframe），让更多的下层数据利用（如BI零碎，预警系统）等对接进来，提供根底的调度性能。

我的分享就到这里，谢谢大家认真浏览！