乐趣区

关于大数据:数据平台调度升级改造-从Azkaban-平滑过度到-Apache-DolphinScheduler-的操作实践

jiezi

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 零碎，预警系统）等对接进来，提供根底的调度性能。

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

退出移动版