You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dolphinscheduler.apache.org by zh...@apache.org on 2023/08/30 02:24:15 UTC
[dolphinscheduler-website] branch master updated: Add three new blog (#911)
This is an automated email from the ASF dual-hosted git repository.
zhongjiajie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dolphinscheduler-website.git
The following commit(s) were added to refs/heads/master by this push:
new 7c95d576e4 Add three new blog (#911)
7c95d576e4 is described below
commit 7c95d576e441130a6162fa6c8b85fc76aa2619a2
Author: Niko-Zeng <97...@users.noreply.github.com>
AuthorDate: Wed Aug 30 10:24:10 2023 +0800
Add three new blog (#911)
---------
Co-authored-by: Jay Chung <zh...@gmail.com>
---
...cheduler_in_financial_technology_data_center.md | 201 ++++++++++++++
...th_Apache_DolphinScheduler_by_Hangzhou_Cisco.md | 128 +++++++++
...tion_from_Azkaban_to_Apache_DolphinScheduler.md | 293 +++++++++++++++++++++
config/blog/zh-cn/user.json | 23 +-
4 files changed, 644 insertions(+), 1 deletion(-)
diff --git a/blog/zh-cn/Application_transformation_based_on_DolphinScheduler_in_financial_technology_data_center.md b/blog/zh-cn/Application_transformation_based_on_DolphinScheduler_in_financial_technology_data_center.md
new file mode 100644
index 0000000000..8efce71ef9
--- /dev/null
+++ b/blog/zh-cn/Application_transformation_based_on_DolphinScheduler_in_financial_technology_data_center.md
@@ -0,0 +1,201 @@
+---
+title: 金融科技数据中台基于 DolphinScheduler 的应用改造
+keywords: Apache DolphinScheduler, 金融, 数据中台
+description: 来自成方金融科技的大数据工程师冯鸣夏为大家带来 DolphinScheduler 在金融科技领域的应用实践分享。
+---
+
+
+
+在Apache DolphinScheduler Meetup 上，来自 **成方金融科技的 大数据工程师 冯鸣夏** 为大家带来 DolphinScheduler 在金融科技领域的应用实践分享。以下为演讲整理：
+
+**-冯鸣夏 成方金融科技 大数据工程师-**
+
+
+
+
+聚焦于大数据领域的实时和离线数据处理和分析，目前主要负责数据中台的研发。
+
+**演讲概要：**
+
+- 使用背景
+
+- 基于 DolphinScheduler 的二次改造
+
+- DolphinScheduler 的插件扩充
+
+- 未来和展望
+
+
+# **1 使用背景**
+
+## **01** 数据中台建设
+
+目前，大数据技术在金融领域有着广泛的应用，大数据平台已经成为了金融基础设施。在大数据平台的建设中，数据中台又是最亮的那颗星，它是业务系统使用大数据的入口和接口，当纷杂的业务系统接入数据中台时，数据中台需要提供统一的管理和统一的入口，以保障服务的安全高靠高效和可靠。正如下图所示，数据中台处于各业务系统连接大数据平台的中间环节，各业务系统通过数据中台所提供的服务对大数据平台进行数据访问。
+
+
+
+
+数据中台的核心理念是实现 4 个四化，即业务数据化、数据资产化、资产服务化和服务业务化。从业务到数据，再回到业务形成的完整闭环，支持企业的数字化转型。
+
+
+
+
+ 数据中台逻辑架构图
+
+
+数据中台的逻辑架构如上图所示，从下往上分析，首先最底层是数据资源层，这是各个业务系统产生的原始数据；再往上一层是数据集成，数据集成的方式分为离线采集和实时采集，其中采用的技术包括 Flume、CDC 实时采集等。
+
+再往上一层是目前比较热的数据湖了，通过数据集成手段将数据入湖，存到 Hadoop 的分布式存储或者 MPP 架构的数据库中。
+
+再往上一层是数据引擎层，通过实时和离线计算引擎 Flink、Spark 等对数据湖中的数据进行处理分析，形成可供上层使用的服务数据。
+
+再上一层就是数据中台所需要提供的数据服务了，数据服务目前包括数据开发服务和数据共享服务，为上层的各业务系统提供数据的开发和共享能力。
+
+数据应用层是数据的具体应用，包括数据的异常检测、数据治理、AI 人工智能的决策以及BI分析等。
+
+
+在整个的数据中台的建设中，调度引擎在数据引擎层中是属于比较核心的位置，也是数据中台建设中比较重要的功能。
+
+## **02** 数据中台面对的问题和挑战
+
+数据中台会面临一些问题和挑战。首先，数据任务的执行和调度是数据中台提供数据开发服务的核心和关键。
+
+其次，数据中台对外提供统一的数据服务管理，服务开发，服务调用和服务监控。
+
+第三，保障金融数据的安全是金融科技的首要任务，数据中台需要保障数据服务的安全可靠。
+
+在以上这些问题的和挑战下，我们对一些开源的调度引擎进行了调研。
+
+
+
+
+目前我们在生产过程中同时使用了多种调度引擎，比如 oozie，XXL-job，DolphinScheduler 是我们 2022 年通过调研分析引进的调度引擎,它在整个数据中台的建设中起到了非常重要的作用。
+
+
+首先，DolphinScheduler 部分地解决了我们统一服务管理、服务开发、服务调用和服务管理的需求。其次，它在任务容错方面有自己独到设计，支持 HA、弹性扩展、故障容错，基本保障任务的安全运行。第三，它支持任务和节点的监控。第四，它支持多租户和权限的控制。最后，它的社区非常活跃，版本更迭快速，问题修复也是非常快速。通过分析 DolphinScheduler 的架构和源码分析，我们认为它的架构符合主流的大数据框架设计，和Hbase、Kafka 等优秀的国外产品有类似的架构模式和设计。
+
+# **2 基于DolphinScheduler 的二次改造**
+
+为了让 DolphinScheduler 更加符合我们应用场景的需要，我们基于 DolphinScheduler 进行了二次改造，共包括 6 个方面。
+
+1. **增加异步服务调用功能**
+2. **增加元数据库Oracle适配**
+3. **增加多环境配置能力**
+4. **增加日志和历史数据清理策略**
+5. **增加对Yarn日志的获取能力**
+6. **增加服务安全策略**
+
+## **01** 增加异步服务调用功能
+
+
+
+
+首先是增加了异步服务调用功能，上图是 DolphinScheduler 2.0.5版本的架构图，大部分都是原生 DolphinScheduler 的服务组件，其中标标红的 GateWay 是我们基于 DolphinScheduler 增加的一个网关服务，通过它实现了流量控制、黑白名单，同时也是用户访问服务开发的入口。通过优化流程的启动接口，返回流程的唯一编码，我们增加了服务映射的功能。
+
+
+
+
+在经典的 DolphinScheduler 的访问模式中，用户提交的工作流执行指令会进入到原数据库中的 command 表里面，master 组件拿到 zk 锁后从 元数据库中获取command，并进行 DAG 解析，生成实际的流程实例，并将分解的任务通过 RPC 交付 work节点执行，然后同步等待执行结果。在原生的 DolphinScheduler 请求中，用户提交了指令之后，缺少执行工作流的返回码，所以我们增加了返回的唯一标识，用户可以通过这个唯一的返回标识，进行后续的流程状态的查询，日志的下载和数据的下载。
+
+## **02** 增加元数据库 Oracle 适配
+
+我们的第二个改造是对 DolphinScheduler 与 Oracle 数据库进行了适配。目前原生 DolphinScheduler 的元数据库是 MySQL，而根据我们的生产需求需要将原数据库转换成Oracle数据库。为实现这一点，需要完成数据初始化模块和数据操作模块的适配。
+
+
+
+首先，对于数据的初始化模块，我们修改了 install_config.conf 配置文件，将其更改为Oracle 的配置。
+
+其次，需要增加Oracle的application.yml，我们在 dolphinscheduler-2.0.*/apache-dolphinscheduler-2.0.*-bin/conf/ 目录下增加Oracle的application.yml。
+
+最后，我们对数据操作模块进行转换，对 mapper 文件和的文件进行相应的修改，因为 Dolphinscheduler-dao 模块是数据库操作模块，其它模块会引用该模块实现数据库的操作。它使用 Mybatis 进行数据库连接，所以需要更改 mapper文件，所有的 mapper 文件在 resources 目录下。
+
+## **03** 多环境配置能力
+
+原生的 DolphinScheduler 版本安装无法根据环境进行配置，一般需要根据实际环境进行调整相关的参数。我们希望通过增强安装脚本对环境的选择配置，以减少人为在线修改的成本，实现自动化安装。相信小伙伴们也都遇到类似的困境，为了在开发环境、测试环境、联调环境、性能环境、准生产环境、生产环境上使用DolphinScheduler，需要进行大量环境相关配置参数的修改。
+
+
+我们通过修改 install.sh 文件，增加输入参数\[dev|test|product\]，选择合适install\_config\_${evn}.conf 进行安装，可以实现了环境的自动选择。
+
+
+另外，DolphinScheduler 的工作流跟环境是强绑定的，不同环境的工作流无法共用。下图是原生 DolphinScheduler 导出的一个工作流的JSON文件，标灰的部分表示这个流程所依赖的 resource 资源， id是一个数字，是由数据库自增所产生的。但是如果 a 环境产生的流程实例放到 b 环境中，可能就会存在ID主键冲突。换句话说，就是不同环境所产生的工作流是无法进行共用的。
+
+
+
+
+我们通过将资源的绝对路径所作为资源的唯一ID这种生成的方式来解决这个问题。
+
+## **04** 日志和历史数据清理策略
+
+DolphinScheduler 所产生的数据非常多，数据库中会产生实例表中的实例数据，这些数据会随着实例任务不停运行不断地增长。我们采用的策略就是通过定义 DolphinScheduler的定时任务，将这些表的数据按照约定的保存周期进行清理。
+
+
+其次，DolphinScheduler 的数据主要是日志数据和任务执行目录，其中包括worker、master、API 的服务日志数据以及 worker 执行的目录，这些数据并不会随着任务的执行的结束而自动删除，也需要通过定时任务删除。通过运行日志清理脚本，我们可以实现日志的自动删除。
+
+
+
+
+
+## **05** 增加对 Yarn 日志的获取能力
+
+原生的 DolphinScheduler 可以获取在worker 节点上执行的日志信息，但是对于 Yarn 上的任务还需要登录到 Yarn 的集群上，通过命令或者界面的方式获取。我们通过分析日志中的 YARNID 标签，获取 Yarn 任务 ID，通过 yarnclient 获取任务的日志。减少了手工查看日志的过程。
+
+
+
+<YARNID>1234567890<YARNID>
+
+## 06 服务安全策略
+
+- 增加 Monitor 组件监控
+
+
+
+
+上图是是 DolphinScheduler 中两大核心组件 master和 worker 与Zookeeper 的交互过程。MasterServer 服务启动时会向 Zookeeper 注册临时节点，通过监听 Zookeeper 临时节点变化来进行容错处理。WorkerServer 主要负责任务的执行。WorkerServer 服务启动时向 Zookeeper 注册临时节点，并维持心跳。目前Zookeeper起到非常重要的作用，主要进行服务的注册和心跳的检测。
+
+
+
+
+从上面这张表格可以看到 master和 worker连接 Zookeeper 时的一些相关参数，包括连接超时，session超时时间，最大连重试次数。
+
+
+由于网络抖动等因素，可能会造成 master 和 worker节点与 zk 失联的情况。失联之后，worker 和 master 因为在 zk 上注册的临时信息消失，会判定 zk 与 master 和 worker 失联，影响任务的执行。如果没有人工干预，就会导致任务迟迟得不到响应。我们增加了 monitor 组件进行服务状态的监控，通过定时任务 cron, 每 5 分钟运行一次 monitor 程序检测 worker 进程和 master 进程是否存活，如果宕机则重新调起。
+
+- 增加服务组件使用 zk 的 Kerberos 认证环节
+
+
+
+第二个安全策略是增加了服务组件使用 zk 的 Kerberos 认证环节。Kerberos 是一种网络认证协议，其设计目的是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。Master 服务组件，API 服务组件，worker 服务组件在启动时完成 Kerberos 认证之后再使用 zk 进行相关的服务注册和心跳连接，从而保证服务的安全。
+
+# **3 基于DolphinScheduler的插件扩展**
+
+此外，我们还基于 DolphinScheduler进行了插件扩展，我们扩展了 4 类算子，包括 **Richshell、SparkSQL、Dataexport 和 GBase** 算子。
+
+## **01** 增加新的任务类型Richshell
+
+首先是新增了任务类型 Richshell，增强了原生的 Shell功能，主要是通过模板引擎实现脚本参数动态替换，用户通过服务调用实现脚本参数的替换，让用户使用参数更加灵活，是对全局参数的补充。
+
+
+
+## **02** 增加新的任务类型SparkSQL
+
+第二个增加的算子是 SparkSQL，用户通过编写 SQL执行 Spark 任务，让任务调度在Yarn 上。DolphinScheduler 原生也支持以 JDBC 的方式执行 SparkSQL，但存在l资源争抢的情况，因为 JDBC 连接数是有限的。通过SparkSQL /Spark-beeline 等工具执行不能使用 Yarn cluster 模式。而采用该任务类型可以将 SparkSQL 程序以cluster 的模式运行在 Yarn 集群上，最大限度地利用集群资源，减少客户端的资源使用。
+
+## **03** 增加新的任务类型 Dataexport
+
+第三个增加的是 Dataexport，也就是数据导出算子，让用户可以通过选择不同的存储组件，导出存储在组件中的数据。组件包括 ES、Hive、Hbase 等。
+
+
+
+在大数据平台中的数据，被导出后后续可能被用于 BI 展示、统计分析、机器学习等数据准备，而这些场景大多需要进行数据导出，利用 Spark 数据处理能力实现不同数据源的导出功能。
+
+## **04** 增加新的任务类型GBase
+
+第四个增加的插件是 Gbase。GBase 8a MPP Cluster 是一款列式存储，Shared Nothing架构的分布式并行数据库集群，具备高性能、高可用、高扩展等特性，适用于OLAP场景（查询场景），可以为超大规模数据管理提供高性价比的通用计算平台，并广泛用于支撑各类数据仓库系统、BI 系统和决策支持系统。
+
+GBase 作为数据入湖的一个应用场景，我们新增了 GBase 算子，它支持 GBase 数据的导入、导出和执行。
+
+# **4 未来与展望**
+
+未来，我们将增加云原生的支持，对目前架构进行云原生改造，DolphinScheduler 已经迭代至 3 版本，我们会持续更新支持。第二，增加AI模型算子，AI 应用场景越来越多，我们需要对 更多的AI 场景进行抽象 ；第三，增加灰度发布功能，以实现无感知发布；第四，增加基于用户优先级的调度策略。
+
+我相信随着 DolphinScheduler、Kylin 等中国开源社区的蓬勃发展，国产软件一定会迎来更好的未来。最后和大家分享一句话：“没有比追梦更加激荡人心的力量，没有比梦想更加铿锵有力的步伐”，与大家共勉！
\ No newline at end of file
diff --git a/blog/zh-cn/K8s_Integration_with_Apache_DolphinScheduler_by_Hangzhou_Cisco.md b/blog/zh-cn/K8s_Integration_with_Apache_DolphinScheduler_by_Hangzhou_Cisco.md
new file mode 100644
index 0000000000..36cc235bb5
--- /dev/null
+++ b/blog/zh-cn/K8s_Integration_with_Apache_DolphinScheduler_by_Hangzhou_Cisco.md
@@ -0,0 +1,128 @@
+---
+title: 全面拥抱 K8s，ApacheDolphinScheduler 应用与支持 K8s 任务的探索
+keywords: Apache DolphinScheduler, K8s, 杭州思科
+description: 来自杭州思科的大数据工程师李千分享他们基于Apache DolphinScheduler对K8s的交互探索和开发成果。
+---
+
+
+
+
+
+
+
+K8s 打通了主流公私云之间的壁垒，成为唯一连通公私云的基础架构平台。K8s 是未来云端的趋势，全面拥抱 K8s 成为更多企业推动 IT 现代化的选择。
+
+杭州思科基于 Apache DolphinScheduler，也在进行支持 K8s 的相关探索，且部分功能已经成功上线运行。今天，来自杭州思科的大数据工程师 李千，将为我们分享他们的开发成果。
+
+
+
+
+
+**李千**
+
+杭州思科 大数据工程师，多年大数据解决方案经验，有 Spark，Flink，以及调度系统，ETL 等方面的项目经验。
+
+本次我的分享主要分为这几部分，Namespace 管理，持续运行的 K8s 任务，K8s 任务的工作流调度，以及未来的规划。
+
+# **01 Namespace 管理**
+
+## **资源管理**
+
+第一部分中，我首先介绍一下资源管理。我们引入资源管理目的，是为了利用 K8s 集群运行不属于 Apache DolphinScheduler 所属的调度概念上的任务，比如 Namespace，更类似于一个数据解决方案，如果 CPU 的 memory 有限，就可以限制队列中的资源，实现一定的资源隔离。
+
+以后我们可能会把一部分资源管理功能合并到 Apache DolphinScheduler 上。
+
+## **增删维护管理**
+
+我们可以加一些 Type，即标记的类型，比如某些 Namespace 只允许跑一些特定类型的 job。我们可以统计Namespace 下面的任务数量、pod 数量、请求资源量、请求等，查看队列的资源使用情况，界面默认只有管理员才可以操作。
+
+
+
+
+
+## **多 K8s 集群**
+
+K8s 支持多个集群，我们通过 Apache DolphinScheduler 客户端连接到多个 K8s 集群，batch、PROD 等可以搭建多套这K8s 集群，并通过 Namespace 支持多套 K8s 集群。
+
+我们可以编辑所开发的集群，修改所有的属性，如内存等。
+
+在新版中，用户权限的管理位于 user master 中，可以给某个用户授权，允许用户可以向某个 Namespace 上提交任务，并编辑资源。
+
+# **02 持续运行的 K8s 任务**
+
+第二部分是关于我们目前已经支持的任务类型。
+
+**启动不退出的普通镜像，如 ETL 等**
+
+比如 ETL 这种提交完之后必须要手动操作才会退出的任务。这种任务一旦提交，就会把数据 sink，这种任务理论上只要不做升级，它永远不会停。
+
+
+
+
+这种任务其实调度可能用不到，因为它只有启停这两种状态。所以，我们把它放在一个实时列表中，并做了一套监控。POD是实时运行的状态，主要是通过一个 Fabris operator 进行交互，可以进行动态进行扩展，以提高资源利用率。
+
+## **Flink 任务**
+
+我们对于 CPU 的管理可以精确到 0.01%，充分利用了 K8s 虚拟 CPU。
+
+
+
+
+
+
+
+
+
+
+
+另外，我们也常用 Flink 任务，这是一种基于 ETL 的扩展。Flink 任务界面中包含编辑、查看状态、上线、下线、删除、执行历史，以及一些监控的设计。我们用代理的模式来设计 Flink UI，并开发了权限管控，不允许外部的人随意修改。
+
+Flink 默认了基于 checkpoint 启动，也可以指定一个时间创建，或基于上一次 checkpoint 来提交和启动。
+
+Flink 任务支持多种模式镜像版本，因为 K8s 本身就是运行镜像的，可以直接指定一些镜像来选择使用包，或通过文件上传的方式提交任务。
+
+另外，Batch 类型的任务可能一次运行即结束，或是按照周期来调度，自动执行完后退出，这和 Flink 不太一样，所以对于这种类型的任务，我们还是基于 Apache DolphinScheduler 做。
+
+# \*\*03 \*\***K8s 任务的运行**
+
+## **K8s 任务的工作流调度**
+
+我们在最底层增加了一些 Flink 的 batch 和 Spark 的 batch 任务，添加了一些配置，如使用的资源，所运行的 namespace 等。镜像信息可以支持一些自定义参数启动，封装起来后就相当于插件的模式，Apache DolphinScheduler 完美地扩展了它的功能。
+
+
+
+
+
+## **Spark 任务**
+
+Spark 任务下可以查看 CPU 等信息，上传文件支持 Spark Jar 包，也可以单独上传配置文件。
+
+
+
+
+
+这种多线程的上层，可以大幅提高处理速度。
+
+# **04 其他和划化**
+
+## **Watch 状态**
+
+
+
+
+
+除了上述改动，我们还对任务运行状态进行了优化。
+
+当提交任务后，实际情况下运行过程中可能会出现失败，甚至任务的并行度也会基于某些策略发生改变。这时，我们就需要一种 watch 的方式来动态实时地来获取任务状态，并同步给 Apache DolphinScheduler 系统，以保证界面上看到的状态一定是最准确的。
+
+Batch 做不做 watch 都可以，因为这不是一个需要全量监听的独立任务而且 namespace 的资源使用率也是基于 watch 模式，这样就可以保证状态都是准确的。
+
+## **多环境**
+
+多环境是指，同一个任务可以推送到不同的 K8s 集群上，比如同一个Flink 任务。
+
+从代码上来说，watch 有两种方式，一种是单独放一些 pod，比如当使用了 K8s 模块时，定义多个 K8s 集群的信息，在每个集群上创建一些watch pod 来监听集群中的任务状态，并做一些代理的功能。另一种是跟随 API 或单独服务，启动一个监听服务监听所有K8s集群。但这样无法在外做一些K8s内外网络的代理。
+
+而针对 Batch 有多种方案，一种是可以基于 Apache DolphinScheduler 自带功能，通过同步的方式进行 watch，这和 Apache DolphinScheduler 比较兼容。关于这方面的工作我们未来可能很快会提交 PR。Spark 使用相同的模式，提供一些 pod 来进行交互，而内部代码我们使用的是 Fabric K8s 的 client。
+
+今后，我们将与 Apache DolphinScheduler 一起共建，陆续支持这里讨论的功能，并和大家分享更多关于我们的工作进展。谢谢大家！
\ No newline at end of file
diff --git a/blog/zh-cn/The_operation_practice_of_smooth_transition_from_Azkaban_to_Apache_DolphinScheduler.md b/blog/zh-cn/The_operation_practice_of_smooth_transition_from_Azkaban_to_Apache_DolphinScheduler.md
new file mode 100644
index 0000000000..6418f260f4
--- /dev/null
+++ b/blog/zh-cn/The_operation_practice_of_smooth_transition_from_Azkaban_to_Apache_DolphinScheduler.md
@@ -0,0 +1,293 @@
+---
+title: 数据平台调度升级改造 | 从Azkaban 平滑过度到Apache DolphinScheduler 的操作实践
+keywords: Apache DolphinScheduler, Azkaban,迁移,最佳实践,Fordeal,二次开发
+description: Fordeal数据平台新版系统决定基于Apache DolphinScheduler进行升级改造。那整个迁移过程中开发人员是如何让使用方平滑过渡到新系统，又做出了哪些努力呢？
+
+---
+
+
+
+
+Fordeal的数据平台调度系统之前是基于Azkaban进行二次开发的，但是在用户层面、技术层面都存在一些痛点问题难以被解决。比如在用户层面缺少任务可视化编辑界面、补数等必要功能，导致用户上手难体验差。在技术层面，架构过时，持续迭代难度大。基于这些情况，经过竞品对比和调研后，Fordeal数据平台新版系统决定基于Apache DolphinScheduler进行升级改造。那整个迁移过程中开发人员是如何让使用方平滑过渡到新系统，又做出了哪些努力呢？
+
+5月 Apache Dolphinscheduler 线上 Meetup， 来自 Fordeal 的大数据开发工程师卢栋给大家分享了平台迁移的实践经验
+
+**START**
+
+讲师介绍
+
+
+**卢栋**
+
+Fordeal 大数据开发工程师。5年的数据开发相关经验，目前就职于Fordeal，主要关注的数据技术方向包括：湖仓一体、MPP数据库、数据可视化等。
+
+
+
+**本次演讲主要包含四个部分：**
+
+- Fordeal数据平台调度系统的需求分析
+
+- 迁移到Apache Dolphin Scheduler过程中如何适配
+
+- 适配完成后如何完成特新增强
+
+- 未来规划
+
+
+
+
+## 一、需求分析
+
+### 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都需要自己进行修改，那会大大降低开发效率。
+
+
+### Fordeal 现在的架构
+
+
+
+
+
+如今我们的数据架构如上图。Apache Dolphin Scheduler承接了整个生命周期从HDFS、S3采集到K8S计算再到基于Spark、Flink的开发。两边的olphinScheduler和Zookeeper都是作为基础性的架构。我们的调度信息如下：Master x2、Worker x6、API x1（承载接口等），**目前日均工作流实例：3.5k，日均任务实例15k+**。（下图为1.2.0版本架构图）
+
+
+
+
+
+## 二、适配迁移
+
+### 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 分类词云。
+
+
+
+
+## 三、特性增强
+
+### 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告警等等。
+
+
+
+
+
+## 四、未来规划
+
+### 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系统，预警系统）等对接进来，提供基础的调度功能。
+
+我的分享就到这里，谢谢大家认真阅读！
+
+
+
diff --git a/config/blog/zh-cn/user.json b/config/blog/zh-cn/user.json
index 959e13d73e..9949a4962d 100644
--- a/config/blog/zh-cn/user.json
+++ b/config/blog/zh-cn/user.json
@@ -1,5 +1,26 @@
{
- "The_practice_of_Apache_Dolphinscheduler_in_fresh_food_industry": {
+ "Application_transformation_based_on_DolphinScheduler_in_financial_technology_data_center": {
+ "title": "金融科技数据中台基于 DolphinScheduler 的应用改造",
+ "author": "Niko Zeng",
+ "dateStr": "2023-8-24",
+ "desc": "来自成方金融科技的大数据工程师冯鸣夏为大家带来 DolphinScheduler 在金融科技领域的应用实践分享...",
+ "img": "https://fastly.jsdelivr.net/gh/filess/img16@main/2023/08/24/1692847150919-97fb9072-8e2b-4016-bb9f-d089a22d2b6e.png"
+ },
+ "The_operation_practice_of_smooth_transition_from_Azkaban_to_Apache_DolphinScheduler": {
+ "title": "数据平台调度升级改造 | 从Azkaban 平滑过度到Apache DolphinScheduler 的操作实践",
+ "author": "Niko Zeng",
+ "dateStr": "2023-8-16",
+ "desc": "Fordeal数据平台新版系统决定基于Apache DolphinScheduler进行升级改造。那整个迁移过程中开发人员是如何让使用方平滑过渡到新系统，又做出了哪些努力呢...",
+ "img": "https://fastly.jsdelivr.net/gh/filess/img2@main/2023/08/16/1692153345322-92a7cded-4702-4e86-85a2-1b7bae3ba59c.png"
+ },
+ "K8s_Integration_with_Apache_DolphinScheduler_by_Hangzhou_Cisco": {
+ "title": "全面拥抱 K8s，ApacheDolphinScheduler 应用与支持 K8s 任务的探索",
+ "author": "Niko Zeng",
+ "dateStr": "2023-8-8",
+ "desc": "来自杭州思科的大数据工程师李千分享他们基于Apache DolphinScheduler对K8s的交互探索和开发成果...",
+ "img": "https://fastly.jsdelivr.net/gh/filess/img16@main/2023/08/24/1692847150919-97fb9072-8e2b-4016-bb9f-d089a22d2b6e.png"
+ },
+ "The_practice_of_Apache_Dolphinscheduler_in_fresh_food_industry": {
"title": "突破单点瓶颈、挑战海量离线任务，Apache Dolphinscheduler在生鲜电商领域的落地实践",
"author": "Niko Zeng",
"dateStr": "2023-8-1",