导读
蜀海供应链是集销售、研发、洽购、生产、品保、仓储、运输、信息、金融为一体的餐饮供应链服务企业。2021 年初，蜀海信息技术核心大数据技术研发团队开始测试用 DolphinScheduler 作为数据中台和各业务产品我的项目的任务调度零碎工具。本文次要分享了蜀海供应链在海豚晚期旧版本实际过程中的摸索翻新和在跨大版本升级部署过程中的教训，心愿对大家有所启发和帮忙。
作者简介
杜全，蜀海供应链大数据工程师，参加蜀海大数据平台和数据中台建设。
业务背景介绍
咱们公司的次要业务如下图所示：
- 领导驾驶舱：提供给高层领导查看的数据准实时剖析，T+ 1 经营剖析、产品毛利类、市场价格等报表
- 财务：各类日报、月报、年度报表；对账、毛利报表、指标表等
- 客户销售：客户采销类实时报表、日报、月报各个维度的数据分析及查问销售明细数据
- 供应商类：洽购剖析、询价报表、供应商等级、供应商工作台、供应商对账剖析，洽购策略优化等
- 仓储：库存周转、库位、实时库存等各种维度数据指标及报表需要
- 物流运输类：准点率、温控、运输成本，调度等剖析
- 数据分析师：疾速响应各种数据分析需要，及高层领导各种长期数据需要，数据挖掘及各种实时交互式剖析
- 各业务经营 / 策略 / 负责人：次要查看各自业务经营的整体状况，查问数据中台的各该业务各种维度实时聚合数据
-
以及一些其余业务的数据报表及剖析需要。
集成降级教训
在数据中台建设过程中，好的大数据调度组件往往能达到事倍功半的作用，咱们团队也深知这一点，因而抉择了海豚调度作为蜀海供应链数据中台的调度零碎，并通过从 v1.3.6 的耦合集成部署革新到 v3.1.8 解耦集成部署的革新的阶段，在这个过程中也遇到了各种各样的问题并及时提供了解决方案，现就这些做一下分享，心愿能够帮忙到各位小伙伴。
海豚调度旧版本集成
之前团队集成的旧版本为 v1.3.6，曾经在生产环境稳固运行两年多了，这里次要简略介绍下过后集成到数据中台的细节及随着业务量剧增带来的痛点。
（1）API 服务、UI 革新对接集成到中台
- 前端 UI 革新
基于 dolphinscheduler-ui 我的项目二次开发（改变量大）适配中台款式，集成各海豚调度菜单（首页、项目管理、资源核心、数据源核心、监控核心、平安核心）到中台，对立走中台路由网关。
- 后端 API 接口服务革新
基于 dolphinscheduler-api 我的项目二次开发，交融中台用户体系革新。外围革新点如下：
① 革新点 1：LoginHandlerInterceptor 拦截器类 preHandle()办法重构
② 革新点 2：每个 Controller 管制层类中接口办法减少获取登录用户办法 getLoginUser() 办法
③ 革新点 3：返回数据及分页数据办法革新
（2）告警革新减少钉钉告警
v1.3.6 版本告警组组类型仅反对：邮件、短信两种。公司平时是通过钉钉接管告警信息，因而须要集成钉钉告警类型。外围革新点如下：
① 步骤 1：定义 DingAlertPlugin 钉钉告警插件类实现 AlertPlugin 接口，重写 getId()、getName() 及process()办法
② 步骤 2：定义 DingManager 钉钉发送治理类
③ 步骤 3：编写 DingUtils 钉钉发送音讯工具类
④ 步骤 4：向 AlertServer 注册钉钉告警插件
⑤ 步骤 5：打包部署并批改dolphinscheduler-daemon.sh
打包部署依据具体批改逻辑，这里批改了 dolphinscheduler-alert-1.3.6.jar 和dolphinscheduler-dao-1.3.6.jar 因而打包这两个包即可。另外，装置门路下减少 alertlib 文件夹并在 dolphinscheduler-daemon.sh 中减少 alter-server 加载逻辑。
（3）集成成绩展现
数据中台集成菜单与 v1.3.6 海豚调度保持一致，次要包含：首页、项目管理、资源核心、数据源核心、监控核心、平安核心，这些菜单都是集成到了咱们的数据中台中，前端走平台对立的路由网关。
（4）v1.3.6 旧版本业务痛点问题
- 工作流定义表
process_definition_json字段大 JSON 工作和工作流耦合度高，解析 json，十分消耗性能，且工作没法重用；否则会导致数据大量冗余，性能差，资源耗费重大 - 降级艰难，1.3.6 集成到数据中台零碎中，相当于二次开发了 API 服务，集成了中台用户体系走对立路由网关，前端 UI 组件每一次降级，海豚调度就会呈现各种前端款式问题（SUB_PROCESS 子工作流 进入不到该子节点下）、菜单显示不全、日志全屏看不全、我的项目主页高低滑动不了等等一系列 UI 交互问题
- 工作间自定义参数高低不能依赖传参
- 工作流实例工作穿插没有工作执行策略，默认是并行处理的，不保障单例模式，比方调度频率高时 前一个工作流实例还未执行完，后一个又开始，造成数据错乱、不精确
- 自带数据品质从 3.0.0 开始
- 反对多种告警插件类型和告警组及实例治理（不限于钉钉），从 3.0.0 开始
- 前端 UI 大调整、优化
鉴于第一版集成的 v1.3.6 以上的业务痛点，降级并重构集成形式变得尤为重要。
海豚调度新版本升级
v1.3.6 版本在数据分析师进行业务剖析流转过程中面临的痛点，联合海豚调度新版本更优的个性，降级到更新版本火烧眉毛，以下是对咱们在将海豚调度集成到数据中台以及降级过程的细节做一下介绍，心愿对遇到跨大版本升级的你有所帮忙。
（1）新版本（v3.1.1）集成到中台
- 海豚调度集成中台我的项目整体架构
次要分为：数据中台 - 前端、数据中台 - 后端、海豚调度 API 服务 <UI> 及集群。
- 海豚调度集成中台调用流程
次要流程：数据中台 - 前端申请关上海豚调度菜单 -> 调用数据中台后端获取海豚调度用户登录信息接口 -> 返回用户名明码 -> 登入海豚调度零碎 -> 数据中台 - 前端申请退出平台账号 -> 海豚调度接口登出接口 -> 退出零碎
- 数据模型及设计细节
海豚调度集成数据中台我的项目两头用户模型设计
模型设计的目标次要建设数据中台和海豚调度用户的关系，便于在数据中台用户登录后，点击海豚调度菜单时获取到对应的海豚调度用户登录信息胜利登录。
（2）v1.3.6 滚动迁徙并降级到 v3.1.8+
这里我以咱们生产环境降级版本 v1.3.6 为终点，通过 v2.0.0->2.0.9>3.0.0>3.1.0->3.18 这些版本迭代降级 < 当然能够跨度步调迈的再小一点，呈现的问题可能就更少了，因为毕竟官网提供的 update_schema.sh 脚本是实用于小版本的，对于大版本兼容性反对不欠缺。
在降级过程中次要在 v2.0.0 须要批改局部源码兼容降级，其余版本根本都是须要批改 schema 对应的 ddl 脚本兼容降级，次要降级流程总结如下：
- 下载指标降级安装包（须要滚动降级的源码包和二进制包下载）
下载新稳固版本（待降级版本）的所有二进制安装包，并将二进制包放到与以后 DolphinScheduler 旧服务不一样的门路中，降级步骤需在新版本的目录进行。
留神：如果存在跨大版本升级需要，尤其是跨 v2.0.0 版本，须要下载 2.0.0 源码包，批改详见（3）
- Dolphin Scheduler 元数据备份（获取生产旧版本 SQL 脚本）
从生产环境转储或用 dump 命令备份数据库脚本文件，一些非必要的日志表数据能够不要，但须要备份表构造。
- 批改降级版本的配置文件
这里按版本分为≤v2.0.9 和≥v3.0.0，在 v2.0.9 版本之前，目录构造大抵如下：
在 v3.0.0 版本之后，目录构造大抵如下：
个别批改遵循先配置降级 schema，再配置根底部署文件的准则。
对于≤v2.0.9 而言，配置降级 schema 须要批改 conf/datasource.properties 文件并将数据库驱动包放在 lib 目录下即可；而配置根底部署文件须要批改conf/common.properties、conf/config/install_config.conf、conf/env/dolphinscheduler_env.sh。
对于≥v3.0.0 而言，配置降级 schema 则须要批改 bin/env/dolphinscheduler_env.sh 并将数据库驱动包放在 tools/libs 目录下即可；而配置根底部署文件则须要批改 bin/env/install_env.sh、alert/master/worker/api-server/conf 下的common.properties、application.yaml。
- 更新数据库、执行数据库降级脚本
这里阐明一下，如果刚好是 v2.0.0 之前的旧版本，那就会遇到一个辣手问题：工作流定义表大 JSON 未拆分。首先须要通过官网提供的 update-schema.sh 拆分大 JSON 并且在执行过程中会呈现很多问题，除非你们公司的旧版本的工作流定义 ID 未通过删减始终放弃自增并且不间断，因为官网对于工作流定义中 tasks 的拆分逻辑是自增的，找不到就会报错，因而须要批改 v2.0.0 源码兼容。
- 装置部署、启用最新版本的服务
这里会遇到一个问题，当执行 bin/install.sh 后，应该在 3.1.x 版本后都会遇到，在 install.sh 的第四步 < 即：4.delete zk node> 中会呈现如下报错：
大略剖析了下，通过排查定位确定是缺 jar 包，我用的 Zookeeper 版本为 v3.8.0。而 worker-server/master-server/api-server 的 libs 下commons-cli-1.2.jar源包中也的确没有 DefaultParser 类，是因为 1.2 的版本过低。
解决办法：下载≥1.4 的 common-cli 包别离放到各服务对应的 libs 下，再次装置部署就没问题了，https://mvnrepository.com/artifact/commons-cli/commons-cli/1.4，成果如下：
这里会呈现一个显眼的 ERROR 信息：ERROR org.apache.zookeeper.util.ServiceUtils - Exiting JVM with code 0，尽管看着不难受，但请疏忽这个是 Zookeeper 失常执行完命令的退出码，0 示意程序失常终止，如果仍存在纳闷能够关上一个 Zookeeper 客户端 （bin/zkCli.sh）Ctrl+D 试一下退出。
- 初始化数据、验证新版本性能
初始化数据次要包含：租户、用户、告警组及实例、资源核心、数据源核心、环境治理等数据信息保护，这些须要依据公司具体业务场景自行保护，性能验证这里不再赘述。
（3）滚动降级过程中遇到的问题总结
- OutOfMemoryError：Java heap space (v1.3.6->v2.0.0)
呈现这种问题的起因是：在降级到 v2.0.0 过程中须要拆分工作流定义表 process_definition_json 字段，而咱们的工作流定义数为 6463 个（随着业务量还在增长中），拆分须要大量消耗内存，Java 堆空间有余，导致无奈调配更多的内存，这个须要依据服务器配置适当调大 -Xmx 参数，这里我调整到了 -Xmx4g，而后降级就没问题了。
- json split error && NullPointException：null (v1.3.6->v2.0.0)
这个问题说切实的，刚开始是一脸懵逼啊，差点让我放弃了跨大版本的降级之路，而后直觉通知我遇到问题不要慌，要淡定，于是果决下载 v2.0.0 源码，定位到了源代码地位，剖析后对其进行了批改并打印记录谬误日志，以便后续剖析，先让程序失常运行起来，这里我在调试过程中次要批改了以下几处：
源码批改第 1 处次要是躲避 processDefinitionMap 为空，导致的空指针异样，如下图所示：
源码批改第 2 处次要是躲避 task 对象节点获取 description 形容信息为空，导致的空指针异样，如下图所示：
源码批改第 3 处次要是躲避 task 对象节点获取 preTasks 前置工作为空，导致的空指针异样，如下图所示：
- Data too long for column ‘task_params’ (v1.3.6->v2.0.0)
这个问题须要批改官网提供的 DDL 脚本，具体须要批改 dolphinscheduler_ddl.sql 中t_ds_task_definition_log 的 task_params字段长度 text->longtext 以及 t_ds_task_instance 的task_params字段长度text->longtext，text 曾经满足不了工作参数的存储大小要求了，如下图所示：
- Duplicate column name ‘alter_type’ (v2.0.9->v3.0.0)
这个问题是因为在 v2.0.9 及之前某个版本曾经增加过，官网脚本未正文掉。
- class path resource cannot be opened because it does not exist（v2.0.0->v3.1.7 这个是前提调研尝试的）
这个问题集体总结是版本跨度太大导致的，也印证了降级脚本只能小碎步，不能大跨步降级，如果你也遇到跨大版本升级，能够参考我的滚动降级版本，少走弯路。
- Unknown column ‘other_params_json’ in ‘t_ds_worker_group’ (v3.0.0->v3.1.0)
批改官网提供的 DDL 脚本，须要调整 dolphinscheduler_ddl.sql，t_ds_worker_group 表减少 other_params_json 字段，t_ds_process_instance表减少 state_history 字段，如下图所示：
- Unknown column ‘description’ in ‘t_ds_worker_group’ (v3.1.0->v3.1.8)
批改官网提供的 DDL 脚本（在 v3.1.8 中 3.1.1_schema 下），须要调整 dolphinscheduler_ddl.sql，t_ds_worker_group 表减少 description 字段，如下图所示：
- 不向前兼容性的更新
这个兼容性次要波及 v3.0.0 和 v3.1.1 版本，对于 v3.0.0 一个是复制和导入工作流时去掉了 copy 前缀；应用分号; 作为 SQL 默认分隔符。对于 v3.1.1 就是扭转了 unix 执行 shell 的形式由 sh 改为 bash，这些影响根本能够疏忽。
（4）集成成绩展现
数据中台集成菜单是平台定义的，只有一个入口菜单，即：海豚调度，这里嵌入中台的截图的是 v3.1.1 的版本，v3.1.8 随后会疾速集成进去，除了状态和定时状态款式根本大差不差。
技术创新之数据表血统
基于海豚调度工作流定义，咱们也做了创新性的数据表血统实际，总体逻辑通过解析工作流定义，在数据流转过程中根本都是以 Insert...Select 这种语法，以输出表（Select 语句）、输出表（Insert 语句）作为流转过程构建数据血统 DAG 流图来赋能咱们的业务，相当于为数据中台插了一双眼，真正做到数据表流转过程的可视化，这些都是以海豚调度作为外围点开展的。
数据血统解析及全量查问
（1）数据血统解析
- 整体架构
- 解析流程及展现
- 解析 SQL 的外围代码
解析 SQL 表血统，咱们采纳的是阿里的 Druid，倡议版本（≥V1.2.6），Druid 解析 SQL 还是很弱小的，它的 TableStat 反对 Merge、Insert、Update、Select、Delete、Drop、Create、Alter、CreateIndex、DropIndex 这些类型并且能够依照语法组合，比方：InsertSelect，咱们的血统解析执行多个 insert...select 语句解析，多个用分号; 宰割
（2）数据血统查问
（3）全量血统查问
全量血统查问能够以输出、输出表的模式直观的展现海豚调度我的项目工作流定义，疾速查问定位到某个工作，给咱们数据分析师带来了极大的便当。
（4）血统异样解决
在数据血统解析过程中，难免会呈现 SQL 语句解析异样的状况，咱们也思考到了这一点，总体异样解决流程如下：
用户收益
- 撑持公司数据中台每日累计近 7000 的工作流定义工作个数，78 个我的项目根本涵盖数据中台的所有业务模块；
- 基于工作流和工作定义构建的表级上下游血统解析及查问，真正做到了表血缘关系的统一化检索和可视化治理，极大晋升了数据中台开发人员和数据分析师的日常检索表的效率；
- 提供了设置工作执行策略模式，在同一工作流实例下工作穿插执行时，保障了数据的准确性；解决了工作间自定义参数上下游依赖传参问题；
- 后续迭代降级能够做到疾速高效地响应数据中台生产需要。
总结与致谢
不得不说基于 Apache DolphinScheduler 提供的弱小集成扩大插件能力大幅晋升了企业数据加工、集成、开发的效率，真正做到了为企业业务数据分析高效流转赋能。
咱们第一版数据中台集成部署时应用的是 v1.3.6 版本。目前社区曾经公布了 v3.1.8，并且这次咱们也是滚动降级到了最新版本 v3.1.8，也是紧跟社区步调，官网社区 v3.2.0 也在预热中，迭代速度之快，也侧面反映了用户群体在日益倍增。如果你们公司正在为抉择大数据调度组件而苦恼，咱们真心强烈建议应用海豚调度。
退出社区、进 DS Group 群，DS 也会有每周的 FAQ 环节及时为你答疑解惑，贴心服务，你值得领有。
强烈值得举荐 Apache DolphinScheduler，调度选的好，上班回家早；调度选的对，中午安心睡！心愿大家都能从中受害，辞别 996。
最初，衷心祝愿 Apache DolphinScheduler 生态圈越来越好！
用户简介
蜀海（北京）供应链治理有限责任公司
所属行业：整体食材供应链
蜀海供应链成立于 2014 年 6 月，是集销售、研发、洽购、生产、品保、仓储、运输、信息、金融为一体的餐饮供应链服务企业，现为宽广餐饮连锁企业及批发客户提供整体食材供应链解决方案服务。
蜀海领有遍布全国的现代化冷链物流核心、食品工厂、蔬果加工核心、底料加工等基地。以平安通明的供应链体系为餐饮客户提供品质服务，解决餐饮行业难标准化的痛点。在净菜生产、菜品研发、餐饮规范工业化等我的项目畛域做继续一直的钻研降级下，蜀海取得了业内权威机构和广大客户的认可，已成为供应链畛域的标杆企业。
本文由 白鲸开源科技 提供公布反对！