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 363b61f188 Add and update some blog (#914)
363b61f188 is described below
commit 363b61f188022649d5eecd9fbceb18605aac3fc3
Author: Niko-Zeng <[email protected]>
AuthorDate: Thu Sep 7 10:14:53 2023 +0800
Add and update some blog (#914)
---
blog/img/2023-9-5/1.png | Bin 0 -> 95333 bytes
blog/img/2023-9-5/10.png | Bin 0 -> 150684 bytes
blog/img/2023-9-5/11.png | Bin 0 -> 57455 bytes
blog/img/2023-9-5/12.png | Bin 0 -> 83900 bytes
blog/img/2023-9-5/13.png | Bin 0 -> 220062 bytes
blog/img/2023-9-5/14.png | Bin 0 -> 42481 bytes
blog/img/2023-9-5/15.png | Bin 0 -> 59207 bytes
blog/img/2023-9-5/2.png | Bin 0 -> 142283 bytes
blog/img/2023-9-5/3.png | Bin 0 -> 189510 bytes
blog/img/2023-9-5/4.png | Bin 0 -> 296868 bytes
blog/img/2023-9-5/5.png | Bin 0 -> 282486 bytes
blog/img/2023-9-5/6.png | Bin 0 -> 100833 bytes
blog/img/2023-9-5/7.png | Bin 0 -> 54557 bytes
blog/img/2023-9-5/8.png | Bin 0 -> 81144 bytes
blog/img/2023-9-5/9.png | Bin 0 -> 116556 bytes
blog/img/2023-9-6/1.png | Bin 0 -> 198149 bytes
blog/img/2023-9-6/2.png | Bin 0 -> 128828 bytes
blog/img/2023-9-6/3.png | Bin 0 -> 174578 bytes
blog/img/2023-9-6/4.png | Bin 0 -> 149289 bytes
blog/img/2023-9-6/5.png | Bin 0 -> 82894 bytes
blog/img/2023-9-6/6.png | Bin 0 -> 60314 bytes
blog/img/2023-9-6/7.png | Bin 0 -> 55455 bytes
blog/img/2023-9-6/8.png | Bin 0 -> 64683 bytes
blog/img/2023-9-6/9.png | Bin 0 -> 68879 bytes
...cheduler_in_financial_technology_data_center.md | 69 +++----
...data_islands_and_strengthen_data_unification.md | 51 ++---
...Chuanzhi_Education_data_warehouse_scheduling.md | 219 +++++++++++++++++++++
...th_Apache_DolphinScheduler_by_Hangzhou_Cisco.md | 19 --
...pplication_of_Apache_DolphinScheduler_in_DDS.md | 213 ++++++++++++++++++++
...tion_from_Azkaban_to_Apache_DolphinScheduler.md | 215 ++++++++------------
config/blog/zh-cn/user.json | 16 +-
31 files changed, 586 insertions(+), 216 deletions(-)
diff --git a/blog/img/2023-9-5/1.png b/blog/img/2023-9-5/1.png
new file mode 100644
index 0000000000..b66836f6c9
Binary files /dev/null and b/blog/img/2023-9-5/1.png differ
diff --git a/blog/img/2023-9-5/10.png b/blog/img/2023-9-5/10.png
new file mode 100644
index 0000000000..3ba6cf8e3a
Binary files /dev/null and b/blog/img/2023-9-5/10.png differ
diff --git a/blog/img/2023-9-5/11.png b/blog/img/2023-9-5/11.png
new file mode 100644
index 0000000000..ad9c08adf0
Binary files /dev/null and b/blog/img/2023-9-5/11.png differ
diff --git a/blog/img/2023-9-5/12.png b/blog/img/2023-9-5/12.png
new file mode 100644
index 0000000000..c6307e1250
Binary files /dev/null and b/blog/img/2023-9-5/12.png differ
diff --git a/blog/img/2023-9-5/13.png b/blog/img/2023-9-5/13.png
new file mode 100644
index 0000000000..650ff499aa
Binary files /dev/null and b/blog/img/2023-9-5/13.png differ
diff --git a/blog/img/2023-9-5/14.png b/blog/img/2023-9-5/14.png
new file mode 100644
index 0000000000..94ed6ab841
Binary files /dev/null and b/blog/img/2023-9-5/14.png differ
diff --git a/blog/img/2023-9-5/15.png b/blog/img/2023-9-5/15.png
new file mode 100644
index 0000000000..fa6eec24d2
Binary files /dev/null and b/blog/img/2023-9-5/15.png differ
diff --git a/blog/img/2023-9-5/2.png b/blog/img/2023-9-5/2.png
new file mode 100644
index 0000000000..90f1e60c52
Binary files /dev/null and b/blog/img/2023-9-5/2.png differ
diff --git a/blog/img/2023-9-5/3.png b/blog/img/2023-9-5/3.png
new file mode 100644
index 0000000000..346dc0bd82
Binary files /dev/null and b/blog/img/2023-9-5/3.png differ
diff --git a/blog/img/2023-9-5/4.png b/blog/img/2023-9-5/4.png
new file mode 100644
index 0000000000..06f9f210dc
Binary files /dev/null and b/blog/img/2023-9-5/4.png differ
diff --git a/blog/img/2023-9-5/5.png b/blog/img/2023-9-5/5.png
new file mode 100644
index 0000000000..10d951d69d
Binary files /dev/null and b/blog/img/2023-9-5/5.png differ
diff --git a/blog/img/2023-9-5/6.png b/blog/img/2023-9-5/6.png
new file mode 100644
index 0000000000..72bd10f783
Binary files /dev/null and b/blog/img/2023-9-5/6.png differ
diff --git a/blog/img/2023-9-5/7.png b/blog/img/2023-9-5/7.png
new file mode 100644
index 0000000000..93e42dc33b
Binary files /dev/null and b/blog/img/2023-9-5/7.png differ
diff --git a/blog/img/2023-9-5/8.png b/blog/img/2023-9-5/8.png
new file mode 100644
index 0000000000..ceb3e3ce69
Binary files /dev/null and b/blog/img/2023-9-5/8.png differ
diff --git a/blog/img/2023-9-5/9.png b/blog/img/2023-9-5/9.png
new file mode 100644
index 0000000000..8a9897f0f9
Binary files /dev/null and b/blog/img/2023-9-5/9.png differ
diff --git a/blog/img/2023-9-6/1.png b/blog/img/2023-9-6/1.png
new file mode 100644
index 0000000000..13d79c9bbb
Binary files /dev/null and b/blog/img/2023-9-6/1.png differ
diff --git a/blog/img/2023-9-6/2.png b/blog/img/2023-9-6/2.png
new file mode 100644
index 0000000000..b93f16f38c
Binary files /dev/null and b/blog/img/2023-9-6/2.png differ
diff --git a/blog/img/2023-9-6/3.png b/blog/img/2023-9-6/3.png
new file mode 100644
index 0000000000..fa8d3feb29
Binary files /dev/null and b/blog/img/2023-9-6/3.png differ
diff --git a/blog/img/2023-9-6/4.png b/blog/img/2023-9-6/4.png
new file mode 100644
index 0000000000..aaed5a9823
Binary files /dev/null and b/blog/img/2023-9-6/4.png differ
diff --git a/blog/img/2023-9-6/5.png b/blog/img/2023-9-6/5.png
new file mode 100644
index 0000000000..ec161d80d3
Binary files /dev/null and b/blog/img/2023-9-6/5.png differ
diff --git a/blog/img/2023-9-6/6.png b/blog/img/2023-9-6/6.png
new file mode 100644
index 0000000000..d6aa7fb0c2
Binary files /dev/null and b/blog/img/2023-9-6/6.png differ
diff --git a/blog/img/2023-9-6/7.png b/blog/img/2023-9-6/7.png
new file mode 100644
index 0000000000..639c385cf2
Binary files /dev/null and b/blog/img/2023-9-6/7.png differ
diff --git a/blog/img/2023-9-6/8.png b/blog/img/2023-9-6/8.png
new file mode 100644
index 0000000000..12ce33a27d
Binary files /dev/null and b/blog/img/2023-9-6/8.png differ
diff --git a/blog/img/2023-9-6/9.png b/blog/img/2023-9-6/9.png
new file mode 100644
index 0000000000..9fe9ff89c4
Binary files /dev/null and b/blog/img/2023-9-6/9.png differ
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
index 8efce71ef9..c4b09e83dc 100644
---
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
@@ -4,27 +4,25 @@ keywords: Apache DolphinScheduler, 金融, 数据中台
description: 来自成方金融科技的大数据工程师冯鸣夏为大家带来 DolphinScheduler 在金融科技领域的应用实践分享。
---
-
+
在Apache DolphinScheduler Meetup 上，来自 **成方金融科技的 大数据工程师 冯鸣夏** 为大家带来
DolphinScheduler 在金融科技领域的应用实践分享。以下为演讲整理：
**-冯鸣夏 成方金融科技 大数据工程师-**
-
聚焦于大数据领域的实时和离线数据处理和分析，目前主要负责数据中台的研发。
**演讲概要：**
-- 使用背景
-
-- 基于 DolphinScheduler 的二次改造
-
-- DolphinScheduler 的插件扩充
-
-- 未来和展望
-
+- 使用背景
+
+- 基于 DolphinScheduler 的二次改造
+
+- DolphinScheduler 的插件扩充
+
+- 未来和展望
# **1 使用背景**
@@ -32,17 +30,14 @@ description: 来自成方金融科技的大数据工程师冯鸣夏为大家带
目前，大数据技术在金融领域有着广泛的应用，大数据平台已经成为了金融基础设施。在大数据平台的建设中，数据中台又是最亮的那颗星，它是业务系统使用大数据的入口和接口，当纷杂的业务系统接入数据中台时，数据中台需要提供统一的管理和统一的入口，以保障服务的安全高靠高效和可靠。正如下图所示，数据中台处于各业务系统连接大数据平台的中间环节，各业务系统通过数据中台所提供的服务对大数据平台进行数据访问。
-
数据中台的核心理念是实现 4 个四化，即业务数据化、数据资产化、资产服务化和服务业务化。从业务到数据，再回到业务形成的完整闭环，支持企业的数字化转型。
-
数据中台逻辑架构图
-
数据中台的逻辑架构如上图所示，从下往上分析，首先最底层是数据资源层，这是各个业务系统产生的原始数据；再往上一层是数据集成，数据集成的方式分为离线采集和实时采集，其中采用的技术包括
Flume、CDC 实时采集等。
再往上一层是目前比较热的数据湖了，通过数据集成手段将数据入湖，存到 Hadoop 的分布式存储或者 MPP 架构的数据库中。
@@ -53,7 +48,6 @@ description: 来自成方金融科技的大数据工程师冯鸣夏为大家带
数据应用层是数据的具体应用，包括数据的异常检测、数据治理、AI 人工智能的决策以及BI分析等。
-
在整个的数据中台的建设中，调度引擎在数据引擎层中是属于比较核心的位置，也是数据中台建设中比较重要的功能。
## **02** 数据中台面对的问题和挑战
@@ -66,33 +60,29 @@ description: 来自成方金融科技的大数据工程师冯鸣夏为大家带
在以上这些问题的和挑战下，我们对一些开源的调度引擎进行了调研。
-
目前我们在生产过程中同时使用了多种调度引擎，比如 oozie，XXL-job，DolphinScheduler 是我们 2022
年通过调研分析引进的调度引擎,它在整个数据中台的建设中起到了非常重要的作用。
-
首先，DolphinScheduler 部分地解决了我们统一服务管理、服务开发、服务调用和服务管理的需求。其次，它在任务容错方面有自己独到设计，支持
HA、弹性扩展、故障容错，基本保障任务的安全运行。第三，它支持任务和节点的监控。第四，它支持多租户和权限的控制。最后，它的社区非常活跃，版本更迭快速，问题修复也是非常快速。通过分析
DolphinScheduler 的架构和源码分析，我们认为它的架构符合主流的大数据框架设计，和Hbase、Kafka
等优秀的国外产品有类似的架构模式和设计。
# **2 基于DolphinScheduler 的二次改造**
为了让 DolphinScheduler 更加符合我们应用场景的需要，我们基于 DolphinScheduler 进行了二次改造，共包括 6 个方面。
-1. **增加异步服务调用功能**
-2. **增加元数据库Oracle适配**
-3. **增加多环境配置能力**
-4. **增加日志和历史数据清理策略**
-5. **增加对Yarn日志的获取能力**
-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
请求中，用户提交了指令之后，缺少执行工作流的返回码，所以我们增加了返回的唯一标识，用户可以通过这个唯一的返回标识，进行后续的流程状态的查询，日志的下载和数据的下载。
@@ -101,7 +91,7 @@ description: 来自成方金融科技的大数据工程师冯鸣夏为大家带
我们的第二个改造是对 DolphinScheduler 与 Oracle 数据库进行了适配。目前原生 DolphinScheduler 的元数据库是
MySQL，而根据我们的生产需求需要将原数据库转换成Oracle数据库。为实现这一点，需要完成数据初始化模块和数据操作模块的适配。
-
+
首先，对于数据的初始化模块，我们修改了 install_config.conf 配置文件，将其更改为Oracle 的配置。
@@ -113,57 +103,48 @@ description: 来自成方金融科技的大数据工程师冯鸣夏为大家带
原生的 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 组件监控
-
+- 增加 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 认证环节
-
第二个安全策略是增加了服务组件使用 zk 的 Kerberos 认证环节。Kerberos
是一种网络认证协议，其设计目的是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。Master 服务组件，API 服务组件，worker
服务组件在启动时完成 Kerberos 认证之后再使用 zk 进行相关的服务注册和心跳连接，从而保证服务的安全。
# **3 基于DolphinScheduler的插件扩展**
@@ -174,7 +155,7 @@ DolphinScheduler 所产生的数据非常多，数据库中会产生实例表中
首先是新增了任务类型 Richshell，增强了原生的
Shell功能，主要是通过模板引擎实现脚本参数动态替换，用户通过服务调用实现脚本参数的替换，让用户使用参数更加灵活，是对全局参数的补充。
-
+
## **02** 增加新的任务类型SparkSQL
@@ -184,7 +165,7 @@ DolphinScheduler 所产生的数据非常多，数据库中会产生实例表中
第三个增加的是 Dataexport，也就是数据导出算子，让用户可以通过选择不同的存储组件，导出存储在组件中的数据。组件包括 ES、Hive、Hbase 等。
-
+
在大数据平台中的数据，被导出后后续可能被用于 BI 展示、统计分析、机器学习等数据准备，而这些场景大多需要进行数据导出，利用 Spark
数据处理能力实现不同数据源的导出功能。
diff --git
a/blog/zh-cn/Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification.md
b/blog/zh-cn/Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification.md
index e1b60c9266..5de24295d3 100644
---
a/blog/zh-cn/Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification.md
+++
b/blog/zh-cn/Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification.md
@@ -7,21 +7,22 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
## 讲师简介
-
-
长城汽车-IDC-数据中台部-刘永飞 高级工程师
我是长城汽车 IDC-数据中台部的刘永飞，给大家分享一下我们自研的一个数据同步工具平台，以及在使用这个工具过程中遇到的问题。今天的分享主要有四个部分：
+
1. 我们自研的数据管道工具平台的定位和功能；
2. DolphinScheduler 在这个数据管道平台中的应用；
3. 总结了我们在使用 DolphinScheduler 时遇到的一些问题；
4. 对于数据管道平台的总结。
## 数据管道
+
本章节我将介绍一下我们自研的数据管道平台，包括技术架构、支持多种数据源、支持多种管道、主要界面、引擎设置、数据类型映射、人工告警和推广几个方面。
### 平台简介
+
数据管道是一个基于分布式技术构建的数据传输平台，支持多种数据源海量数据的实时、离线的方式传输。
数据管道可通过简单的页面配置即可完成数据传输，操作过程简单且高效，降低用户使用门槛；内设告警机制，传输任务出现异常可第一时间通过钉钉将信息发送具体责任人。
@@ -29,10 +30,10 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
我们从立项之初，其实是为了解决长城汽车在数据方面的一些问题，主要目标就是连接数据孤岛，加速数据的一元化。大家知道凡是涉及到数据，数据孤岛问题就是一个绕不开的问题，我们就希望能够通过数据管道连接好各个业务线、各个领域、各个系统，真正的打破数据孤岛。
另一个目标就是加速数据一元化了，数据一元化是长城汽车在数智化转型过程中一个关键目标，做数据一元化的第一步就是数据的快速汇集，我们也能够承担好这个快速汇集数据的角色。
+
### 技术架构
-给大家介绍一下我们的这个管道平台的技术架构。
-
+给大家介绍一下我们的这个管道平台的技术架构。
@@ -44,12 +45,9 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
最上面的 web 层，我们提供了项目级隔离，任务管理、资源管理、日志查看、告警等能力，更加友好的让用户使用我们平台。
### 支持多种数据源
-截止到当前的V2.1.4版本，数据管道平台可以支持 23 种数据源，基本上涵盖了主流的关系型数据库常见的大数据组件。
-
-
+截止到当前的V2.1.4版本，数据管道平台可以支持 23 种数据源，基本上涵盖了主流的关系型数据库常见的大数据组件。
-
### 支持多种管道
@@ -59,87 +57,92 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
以常见的关系型数据库 MySQL 做为数据源为例，一共可以支持 38 个管道。
-
### 操作简单、容易上手
-
-
这是数据管道的 UI
界面，我们自研的初衷就是要简单，通过简单的交互，用户录入源端数据源、目的端数据源，连通性测试通过后，就可以进行任务的创建了。通过简单的页面配置，用户很快就可以创建出一个能够支持大数据量同步的任务。
-
### 主要界面
这是数据源的管理用户界面，你可以根据你想要的类型进行对应的数据源连接参数创建，下面这张图以一个离线任务创建任务为例，来展示新建任务设置的界面。
-
+
### 引擎设置
+
数据管道平台可以根据任务使用的计算引擎（Spark/Flink）来设置任务运行过程中所需的资源参数。
数据管道平台可以根据任务使用的计算引擎（Spark/Flink）来设置任务运行过程中所需的资源参数。
-
+
### 数据类型映射
+
目标库设置时可以方便的进行源端字段和目标端字段的映射。我们收集了Spark/Flink的数据类型映射字典，用于进行源端数据类型到目标数据类型的转换。
-
+
### 任务告警
+
用户在创建任务的时候开启告警设置并选择通知用户后，如果任务执行失败，会在第一时间将告警信息发给通知用户的钉钉账户。
如果用户已经在数据管道平台处于登录状态，则点击”查看错误日志”可以直接跳转到任务实例的提交日志界面，查看日志详情。
-
### 方便、丰富的日志查看
+
在任务创建成功，设置任务”上线”后，点击”手动运行”便可以运行任务了。数据管道平台提供了丰富的日志管理功能，供用户查看任务执行信息。用户可以通过平台生成的日志链接很方便的查看任务向集群提交时的提交日志、任务在集群运行时的运行日志，如果是实时任务，还可以直接跳转到
Flink的web UI 进行任务信息的查看。
-
### 推广成果
+
目前该产品已经在我们内部的一些部门及子公司进行了使用，创建任务 300+ 个，每日近 2000 个任务实例运行 。
+
## DolphinScheduler 在数据管道平台中的应用
+
### 主要流程
+
我们的数据管道依赖了
DolphinScheduler（V3.0.0）的能力，用户在数据管道上创建任务、运行任务，会经海豚调度器进行调度，提交工作流后，最终任务将在集群中执行。
-
+
对大家可以看到，最左侧就是数据管道平台创建数据源，创建任务，数据管道根据不同的数据源获取模板，更新模板，绑定配置文件，最终在数据管道上点执行任务，就会依赖
DolphinScheduler 的能力去执行工作流，提交任务，并在 Yarn 集群中执行。同时在这个过程中，DolphinScheduler
会收集到提交任务的日志，我们利用这个能力，在我们的平台上可以查看任务的实时日志。
+
### 数据管道使用了哪些DolphinScheduler的API服务
数据管道前台使用了我们自定义的 UI 界面，后台的许多功能使用了DolphinScheduler 的 API
服务，包括项目相关的操作，任务状态相关、数据源相关等，具体如下图所示：
-
+
### 数据管道创建任务会生成工作流定义数据
+
用户在数据管道上创建任务之后会生成一个 Resource Name，还有一些配置文件。配置文件会上传到资源中心，上传成功之后会有一个Resource
ID，之后我们会组装数据格式，把它合成任务所需要的参数，然后再组装出来一个任务节点的定义，形成一个任务节点定义列表。任务节点关系就形成任务节点关系列表，任务节点位置就形成任务节点位置列表。任务的执行类型、全局参数等数据组装起来之后，到
DolphinScheduler 创建功能的定义接口，这样创建工作流的流程就做完了。
然后我再讲几个特色的功能给大家分享一下。
+
### 参数设置
-用户在数据管道创建任务的时候可以进行参数的设置。这里我们使用了 DolphinScheduler
内置的时间参数进行参数复制，在过滤条件里边使用定义好的参数进行数据过滤。
+用户在数据管道创建任务的时候可以进行参数的设置。这里我们使用了 DolphinScheduler
内置的时间参数进行参数复制，在过滤条件里边使用定义好的参数进行数据过滤。
-
离线任务比较常见的是补数，这一块，我们通过参数式的功能支持用户在界面上进行参数的自定义，如上图所示。
+
### 提交日志
从数据管道平台运行任务后，我们会调用DolphinScheduler 的运行工作流接口，我们DolphinScheduler
的提交任务日志详情接口拿到提交任务日志数据，用户可以刷新、下载日志。
-
+
### 扩充实例列表支持实时任务断点续传
数据管道平台在创建任务时支持创建多个子任务。每个子任务均可查看实例列表。这里我们调用了 DolphinScheduler
的实例列表接口来展示运行信息，并在该接口的基础上，添加了实例的运行状态、运行开始时间、运行结束时间、实例运行时长等。同时，我们提供了实时任务的停止、运行按钮，可支持实时任务的断点续传功能。
-
+
## 在使用DolphinScheduler时遇到的问题
@@ -149,7 +152,6 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
最初，我们在数据管道平台调用工作流实例列表接口获取实例的信息时，发现接口返回的 state字段值是
SUCCESS，但其实任务是执行失败的。于是就去仔细研究了一下这个 state
字段，发现其实这只是海豚调度器提交任务时获取到的一个状态，并不能真实反映任务的运行状态，于是我们在改接口的基础上又添加了实例的运行状态的逻辑封装。
-
### 问题2：DolphinScheduler 集群扩容，workgroup 分组遇到的问题
这个问题是这样，我们在扩容时新增的节点的也加入到了默认的 default 组，由于新扩容的节点和现在的 work 节点属于不同的 Hadoop
集群，这样的话，提交任务到 default 组，会存在这个组的节点不是属于同一个集群而报错。所以需要把这些新增的节点根据hadoop集群而进行分组。
@@ -161,6 +163,7 @@ description: 来自长城汽车的高级工程师工程师刘永飞分享他们
这个说起来也是因为我们的 DolphinScheduler 上面有两个 Hadoop 集群，配置一个
hdfs，提交到另一个集群的任务可能会存在找不到文件的情况。我们知道对于 standalone
环境，可以选择本地文件目录作为上传文件夹，我们想了两个方案，一个是 NFS 文件共享，另一个是 OSS，我们选择了后者，OSS
通过服务器挂载就像普通磁盘一样使用方便，还有就是 OSS 底层是多副本存储，数据存储上和NFS相比更安全。
## 总结
+
说完了我们所遇到的问题，最后总结一下我在使用 DolphinScheduler 过程中的一些心得体会吧！
首先，得益于 DolphinScheduler
强大的能力、丰富的文档、火热的社区等多方面综合因素，我们在技术选项的时候首选了DolphinScheduler。
diff --git
a/blog/zh-cn/How_does_Apache_DolphinScheduler_solve_the_pain_points_of_Chuanzhi_Education_data_warehouse_scheduling.md
b/blog/zh-cn/How_does_Apache_DolphinScheduler_solve_the_pain_points_of_Chuanzhi_Education_data_warehouse_scheduling.md
new file mode 100644
index 0000000000..741ce0641f
--- /dev/null
+++
b/blog/zh-cn/How_does_Apache_DolphinScheduler_solve_the_pain_points_of_Chuanzhi_Education_data_warehouse_scheduling.md
@@ -0,0 +1,219 @@
+---
+title: Apache DolphinScheduler 如何解决传智教育数仓调度痛点？
+keywords: Apache DolphinScheduler, 数仓调度, 传智教育
+description: 本文主要介绍了传智教育数仓架构的演变和Apache DolphinScheduler在传智的实践与思考
+---
+
+**精彩回顾**
+
+在 Apache DolphinScheduler&Hudi 联合 Meetup 上，传智教育的资深研究员 孔帅，为我们带来题为《Apache
DolphinScheduler在传智教育的实践》的分享。
+
+演讲主要分为 3 部分：
+
+1. 传智教育数仓架构的演变
+
+2. DolphinScheduler在传智的实践与思考
+
+3. 展望未来
+
+# **1、传智教育数仓架构的演变**
+
+首先我们来看一下传智教育数仓架构的演变。
+
+## 01 **传智教育数仓 1.0 架构**
+
+在传智教育数仓 1.0 的架构体系中，我们首先聊一下我们的主体业务流程。
+
+
+
+上图为传智教育的核心分析流程。首先客户会访问官方网站，客户在访问网站期间可以咨询在线客服，了解我们的课程。如果客户感觉这些课程有帮助，并产生学习意向，会给我们留下一些线索，比如电话、微信、QQ
号等。
+
+我们拿到这些之后，线下客服人员会根据这些线索和客户进行进一步沟通联系。如果这些线索联系不到，则把这些线索设置为无效线索；如果能够联系上，客服会和客户进行电话沟通或微信交流。
+
+当客户报名后，就会开始进行学习对应课程。
+
+在这一系列操作过程当中，所有的数据记录都会通过后台存储在服务器上，而我们的大数据系统会在每天凌晨用 T+1
的方式进行数据采集和分析计算。分析计算的主要有访问数据、咨询数据、意向数据、线索数据，还有一些报名数据、考勤数据等。将这些数据分析计算结果以后，我们会把这些结果同步到应用系统中，比如决策系统、报表系统等，并在应用系统当中的
BI 进行展示。
+
+基于这套业务流程，我们设计了教育数仓 1.0 架构。在 1.0
版本的架构中，我们使用的原始数据主要有内部的一些电咨系统、线下的面授系统，以及在线教育系统、客户管理系统等，主要使用的是这些系统里的一些结构化数据。
+
+对于这些结构化数据来说，Sqoop 能够很好地进行数据的采集，所以早期我们主要使用 Sqoop 进行 ETL，数据存储主要使用 HDFS，并基于
MapReduce 引擎的 Hive 来进行分析。
+
+我们在数仓中采取了一些分层，主要有 6 层，第一层是我们的 ODS
原始数据层，保留最原始的数据，不会做任何的变更，这一层也会保留我们最完整的数据。为了保证数据的安全性，我们 ODS 层采用的都是 外部表。
+
+接下来是 DWD 层，主要进行清洗转换操作，清洗主要是把无效垃圾过滤掉，转换则是进行枚举值、字段等转换，以及数据脱敏工作。
+
+经过 DWD 层的信息转换之后，我们能够提供一个比较干净的应用数据。再接下来就是我们的 DWM
层，这一层主要是用来生成我们中间可以复用的一些组件，主要的操作有两种，一种是生成明细宽表，用来为后续的查询提高性能，减少服务器的消耗；另一种是做一些轻度汇总的工作。基于这些天数据和小时数据，我们在后面的
DWS
层进行进一步的数据汇总，这是一个数据集市，会基于中间层的数据进行数据汇总，把时间维度计算出来，比如说年维度、月度、季度、周等，并把总累计值数据计算出来。
+
+数据集市会把最终的数据导出到 RPT 应用层，主要保存的是个性化业务数据。
+
+另外我们还有一个 DIM 维度层，主要是存放一些标准维度数据，最后将这些数据导出给应用系统。应用系统一般使用都MySQL 数据库，导出的数据通过
Spring boot 来对外提供数据接口，用 BI 展现。
+
+因为我们之前采用的是离线数仓，采用的也是 T+1 的计算方案。所以初期的数据能够满足我们计算需求。
+
+初期的任务脚本，我们选择的也是当时比较流行的 Shell 脚本，而且 1.0 版本时我们的调度任务并不是特别的多，所以当时 Oozie
的功能和性能都能够满足我们的调度需求。
+
+以下为离线数仓的若干核心主题设计思路：
+
+
+
+
+
+
+
+
+
+基本流程是将不同主题表格抽取到 ODS 层，形成明细宽表，既有宽表的相关指标和维度，将宽表合并成一张大的数据集市，在 DWM 层进行汇总和计算。
+
+## 02 **2.0 架构**
+
+随着非结构化数据和业务场景越来越多，原来 的 ETL 工具 Sqoop 已经无法满足我们的 ETL 需求了，于是我们对 1.0 架构进行了一些调整，主要包括：
+
+- 除 Sqoop 之外，增加 Flume 进行日志文件采集，使用 Python 自研了 ETL 工具；
+
+- 随着数据量逐步增加，Hive 已经不能满足计算性能的需求。通过对各种分析引擎的对比，选择了 Presto；
+
+- 任务脚本也在逐步地体系化，Shell 脚本的可维护性和拓展性不如 Python，所以 把脚本替换成了 Python。
+
+
+
+另外，系统分层也进行了一些变更，我们在 2.0 版本中去掉了维度层，把维度表都直接放在了 DWD 层中；原来的 DWS 层，数据集市层被替换为了 DM
层，也是数据集市层，作用是一样的。另外，我们新加了一个轻度汇总层和明细宽表层，也就是 DWB 层和 DWS 层。DWB 层的主要作用是把 DWD 里的表，在
DWB 层进行宽表化，将雪花模型转换为星型模型。生成了明细宽表以后，在后续计算中能够提升性能，降低服务器的损耗。DWS
层主要进行轻度汇总，比如按小时、按天先进行轻度的汇总，再在 DM 层中按照年、季度等进行计算。
+
+剩下的 RPT 和 Presto 是整个公司提供所有分层数据的一个入口。
+
+最后，我们还变更了调度工具。因为之前的调度工具 Oozie
配置比较复杂，而且功能相对比较少，可能还会出现服务阻塞的情况，对于升级兼容问题权限问题也都不是特别好。所以，我们把 Oozie
替换DolphinScheduler。
+
+## 03 **核心技术点**
+
+首先是 Sqoop。在数仓 1.0 版本中，我们的原始数据主要是结构化数据，Sqoop 正好就是一款专业的结构化数据传送的 ETL
工具，但随着数据和业务场景增多，ETL 场景也越来越复杂，Sqoop 已经满足不了我们的需求了。所以在 2.0 版本中，我们把 Sqoop
替换成了DolphinScheduler 体系。在 DolphinScheduler 和 Flume 基础之上，我们通过自研的 Python ETL
工具，就可以做到更加灵活地支持各种复杂的业务场景。
+
+Hive 成本低、稳定性好，生态兼容性好，但其缺点也很明显：慢。随着数据量大幅增加，Hive 已经不能满足我们的计算性能需求了。经过各种对比，我们决定在
2.0 版本中选择 Presto 作为新的引擎。
+
+之前我们还参考了 SparkSql、Impala、HAWQ 和 ClickHouse 等，结果如下：
+
+- SparkSql 虽然比 Hive 快，但和 Presto 比单表&多表的查询性能都不突出。
+
+- Impala 多表查询性能优异，但单表查询不如 Presto，不支持 OrcFile、不支持 update、delete 和 grouping sets
等语法，不支持 Date 数据类型。
+
+- HAWQ、Greenplum 比较中庸，用起来比较复杂，性能也不突出。
+
+- ClickHouse 的单表性能较好，但是多表性能不突出，兼容性也不如Presto。
+
+**Presto 的优势：**
+
+- Presto 和 Hive 都是 Facebook 公司开源的，两者兼容好，Trino 是从 Presto 分支出来的，两者非常相似。
+
+- Presto/Trino 单表&多表的查询性能优异，数据量支持 EB 级的数仓和数据湖。
+
+- Presto/Trino 兼容 Hive，还支持 mysql、oracle 等关系型数据库，kafka、redis、MongoDB 等非关系型数据库。
+
+- Presto/Trino 能够进行异构数据源的跨库读写操作。
+
+接下来就是 shell 脚本。1,0 版本汇总我们主要使用
Shell，因为当时任务较少，也并不是特别的复杂，但是随着脚本的体系化，我们需要脚本的可维护性和可扩展性，这些缺点就越来越突出，Shell是用来进行系统管理的脚本，功能有限，性能低开销大。Python
无论是性能方面，还是一致性、扩展性，都比需要脚本要好，现在已经成为了全球编程语言排行榜的第一名。
+
+所以在 2.0 的数仓架构体系中，我们把 shell 脚本变更为了 Python 脚本。
+
+最后就是调度工具，传智教育最初使用的调度软件是Oozie，由于Oozie功能的限制，在不断迭代的需求中，我们重新调研了各种调度工具，最终选择了国产开源的Apache
DolphinScheduler。
+
+
+
+
+
+上面两张图是我们使用 Apache DolphinScheduler
的一些功能，比如文件管理功能和数据源。文件管理功能非常方便，可以让我们很方便地引用文件，这些文件之间也可以互相引用。
+
+数据源创建之后也可以不断复用，对我们提升效率来说很有帮助。
+
+由于 Oozie 历史的原因，目前 Sqoop、HiveSQL、Presto 等任务在DolphinScheduler 中使用的主要还是 Shell
组件，但**受益于 DolphinScheduler 的可视化界面、资源管理、多租户管理、权限管理、告警组管理、多项目管理等功能，调度效率已有大幅提高。**
+
+
+
+这个就是我们这个数仓架构的技术演变，接下来介绍一下传智教育在技术演变的过程中调度工具使用的痛点，以及我们如何解决这些问题。
+
+# 2、DolphinScheduler 在传智教育**的实践**
+
+## 01 **调**度的痛点
+
+- **XML 配置复杂**
+
+传智教育以前采用的工作流调度软件是 Oozie。Oozie 是一个工作流引擎，它的一个特点是默认采用
HPDL语言（XML）定义流程，可视化支持依赖于第三方工具软件（比如HUE），自带的可视化界面功能较弱，安装也标胶复杂。
+
+Oozie 工作流的核心组成部分有两个：job.properites 和
workflow.xml。前者主要保存一些常用的参数变量，后者是核心文件，具体的工作流都是在 workflow 里面去定义的。
+
+
+
+ workflow.xml
+
+
+
+job.properties
+
+上图展示了一个非常简单的工作流，打印 Oozie，再返回一个错误信息进行输出。但就是这么简单的一个工作流，我们可以看到这个过程需要配置大量的 XML
标签，非常麻烦，工作效率非常低。随着我们的调度工作增加，业务场景复杂化，这个调度软件对我们的生产效率已经产生了非常大的影响。
+
+- **功能组件少**
+
+另外就是功能组建比较少，Oozie 对流行技术的反应有些迟钝，比如PySpark等当下流行的分析计算引擎。虽然官方已经宣称支持 PySpark
任务，但在实际应用中 Oozie 的 PySpark 任务却支持较差、问题不断。
+
+此外，多租户管理、告警组管理、多环境管理、Worker 分组管理、项目管理、资源管理等功能，Oozie 也都不具备。
+
+- **阻塞死锁**
+
+
+
+Oozie 在执行过程中，每个任务都会启动一个 oozie-launcher 加载器，oozie-launche 会占用很多内存；
+
+Oozie launcher
的生命周期是数据任务开始之前到结束，期间资源不会释放，如果此时数据任务得不到充足的资源就会一直等待，有充足资源时才会执行数据任务；
+
+如果同时提交了多个 Oozie 任务，或是 Oozie 有多个并行子任务，会导致内存不够，而 Oozie launcher
在得不到充足的资源时就会一直等待资源，导致资源和任务互相等待从而造成死锁现象。
+
+- **权限控制 & 升级兼容**
+
+**权限：**Oozie 基本没有权限控制，也没有多租户功能；
+
+**兼容：**Oozie 依赖于 Hadoop 集群版本，如果更新最新版，容易出现与现有集群不兼容的问题。
+
+# 3、**DolphinScheduler 解决痛点**
+
+以上是 1.0 版本中我们的调度所遇到的一些痛点。那么我们是如何解决这些痛点的呢？
+
+Apache DolphinScheduler 是一个分布式易扩展的可视化工作流任务调度平台。
+
+相对于 Oozie 的复杂 xml 配置流程，DolphinScheduler 所有的流、定时操作都是可视化的，通过拖拽任务来绘制 DAG，并可进行实时监控。
+
+同时 DolphinScheduler 支持一键部署，无需复杂的安装过程，提升工作效率。
+
+- **功能丰富**
+
+DolphinScheduler 的一个好处是功能比较丰富，和 Oozie 相比，相比， DolphinScheduler 紧跟流行技术。
+
+对 PySpark 等当下流程的分析计算引擎，DolphinScheduler 做到了快速升级进行兼容。并且新组件使用起来便捷高效，对于工作效率提升很大。
+
+同时，DolphinScheduler 还在不断升级完善各种功能，比如多租户管理、告警组管理、多环境管理、Worker
分组管理、项目管理、资源管理等功能，功能丰富，升级也快。
+
+- **高可靠性**
+
+
+
+另一个特点是高可靠性，与 Oozie 的阻塞死锁现象对比，DolphinScheduler
采用任务缓冲队列机制来避免过载；单个机器上可调度的任务数量可以灵活配置，当任务过多时会缓存在任务队列中，不会导致机器卡死，就像红绿灯一样。
+
+同时，DolphinScheduler 支持去中心化的多 Master 和多 Worker 服务对等架构，可以避免单 Master 压力过大。
+
+- **权限控制 & 升级兼容**
+
+权限：Oozie 基本没有权限控制；DolphinScheduler 可以通过对用户进行资源、项目、数据源的访问授权，不同用户间互不影响。
+
+兼容：Oozie 容易出现与现有集群不兼容的问题；DolphinScheduler 升级不会影响之前集群的设置，升级方式操作简单。
+
+
+
+
+
+以上为 DolphinScheduler 工作界面截图，帮助我们解决了很多调度痛点。
+
+# 4、**展望未来**
+
+最后是我们对未来的展望。
+
+我们目前虽然还未使用 Apache DolphinScheduler
的所有组件，但它已经帮助我们解决了以前大多数的痛点，大幅提高了工作效率，后续我们准备向更多的项目组推广使用。
+
+在目前的使用中，DolphinScheduler 对 PySpark 任务支持良好，但Presto 插件使用时还有些适配问题，我们也在做 Presto
功能的适配，后续计划将数据源类型优化为支持动态热插拔的功能，让任意类型的数据源都可以被随时使用。
+
+如上所述，由于 DolphinScheduler 社区活跃、版本更新速度较快，在使用过程中会遇到一些适配问题，同时我们也有很多新的
idea，我们会积极地参与到社区中，不断优化完善，助力 Apache DolphinScheduler 更上一层楼！
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
index 36cc235bb5..177741eb13 100644
---
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
@@ -5,18 +5,12 @@ description: 来自杭州思科的大数据工程师李千分享他们基于Apac
---
-
-
-
-
K8s 打通了主流公私云之间的壁垒，成为唯一连通公私云的基础架构平台。K8s 是未来云端的趋势，全面拥抱 K8s 成为更多企业推动 IT 现代化的选择。
杭州思科基于 Apache DolphinScheduler，也在进行支持 K8s 的相关探索，且部分功能已经成功上线运行。今天，来自杭州思科的大数据工程师
李千，将为我们分享他们的开发成果。
-
-
**李千**
@@ -37,8 +31,6 @@ K8s 打通了主流公私云之间的壁垒，成为唯一连通公私云的基
我们可以加一些 Type，即标记的类型，比如某些 Namespace 只允许跑一些特定类型的 job。我们可以统计Namespace 下面的任务数量、pod
数量、请求资源量、请求等，查看队列的资源使用情况，界面默认只有管理员才可以操作。
-
-
## **多 K8s 集群**
@@ -56,7 +48,6 @@ K8s 支持多个集群，我们通过 Apache DolphinScheduler 客户端连接到
比如 ETL 这种提交完之后必须要手动操作才会退出的任务。这种任务一旦提交，就会把数据 sink，这种任务理论上只要不做升级，它永远不会停。
-
这种任务其实调度可能用不到，因为它只有启停这两种状态。所以，我们把它放在一个实时列表中，并做了一套监控。POD是实时运行的状态，主要是通过一个 Fabris
operator 进行交互，可以进行动态进行扩展，以提高资源利用率。
@@ -66,13 +57,9 @@ K8s 支持多个集群，我们通过 Apache DolphinScheduler 客户端连接到
我们对于 CPU 的管理可以精确到 0.01%，充分利用了 K8s 虚拟 CPU。
-
-
-
-
另外，我们也常用 Flink 任务，这是一种基于 ETL 的扩展。Flink
任务界面中包含编辑、查看状态、上线、下线、删除、执行历史，以及一些监控的设计。我们用代理的模式来设计 Flink
UI，并开发了权限管控，不允许外部的人随意修改。
@@ -90,16 +77,12 @@ Flink 任务支持多种模式镜像版本，因为 K8s 本身就是运行镜像
我们在最底层增加了一些 Flink 的 batch 和 Spark 的 batch 任务，添加了一些配置，如使用的资源，所运行的 namespace
等。镜像信息可以支持一些自定义参数启动，封装起来后就相当于插件的模式，Apache DolphinScheduler 完美地扩展了它的功能。
-
-
## **Spark 任务**
Spark 任务下可以查看 CPU 等信息，上传文件支持 Spark Jar 包，也可以单独上传配置文件。
-
-
这种多线程的上层，可以大幅提高处理速度。
@@ -108,8 +91,6 @@ Spark 任务下可以查看 CPU 等信息，上传文件支持 Spark Jar 包，
## **Watch 状态**
-
-
除了上述改动，我们还对任务运行状态进行了优化。
diff --git
a/blog/zh-cn/Practical_development_and_application_of_Apache_DolphinScheduler_in_DDS.md
b/blog/zh-cn/Practical_development_and_application_of_Apache_DolphinScheduler_in_DDS.md
new file mode 100644
index 0000000000..d090a72018
--- /dev/null
+++
b/blog/zh-cn/Practical_development_and_application_of_Apache_DolphinScheduler_in_DDS.md
@@ -0,0 +1,213 @@
+---
+title: 小海豚“变身”全新智能调度引擎，深入浅出在DDS的实践开发应用
+keywords: Apache DolphinScheduler, 调度引擎, DDS
+description:
本文是基于DolphinScheduler的智能调度引擎在DDS的应用，这场演讲主要会跟大家介绍宇动源-DDS（自研的图形化数据开发工作室）、大数据架构、DDS产品和使用中遇到的问题，包括在迁移过程中的调研情况、遇到的困难、解决方案以及针对需求的优化
+---
+
+
+
+
+
+这次在 7月 Meetup
为大家带来的是基于DolphinScheduler的智能调度引擎在DDS的应用，这场演讲主要会跟大家介绍宇动源-DDS（自研的图形化数据开发工作室）、大数据架构、DDS产品和使用中遇到的问题，包括在迁移过程中的调研情况、遇到的困难、解决方案以及针对需求的优化，还有一些心得体会，希望你有所收获。
+
+
+
+**王子健**
+
+宇动源大数据平台开发工程师
+
+原搜狐畅游数据仓库开发工程师
+
+**本次演讲主要包含四个部分：**
+
+- 关于宇动源-DDS
+
+- 全新调度引擎的迁移-DS
+
+- 引擎功能优化
+
+- 总结与计划
+
+# **关于宇动源-DDS**
+
+
+
+😀宇动源DDS架构图
+
+## 01 **什么是BDP？**
+
+BDP是宇动源自研的大数据基础平台，类似的商业的应用主要有**fusioninsget** 和
**EMR**，都是在工业互联网领域比较领先的大数据平台，他们也都对现有开源大数据底层组件的封装和统一管理，使其更适用于工业领域的**实时数据、时序数据、生产监控数据**等，为DDS上层应用提供一个使用更方便、更容易使用的基础平台。
+
+**主要提供的功能**：统一计算调度及管理、计算节点管理、存储节点管理、数据统一访问接口、统一权限控制、全局智能运维
+
+有了BDP之后，我们不需要手动的安装/维护这些组件，包括我们DDS所有的组件也都是通过BDP进行安装和维护。
+
+## 02 **关于DDS**
+
+DDS实际上是对底层的调度引擎的优化，主要是使用的**workflow code 和Stream code** 的两种开发方式，利用拖拉拽快速完成大数据开发。
+
+除此之外还支持**Notebook 交互式**开发方式，当我们使用Shell SQL节点的时候可以在线编辑。
+
+最终在执行过程，其实和我们平时使用DolphinScheduler一样，在运行后，也会生成一个调度任务，并且可以在调度管理中查看/管理。
+
+## 03 **缺点与不足**
+
+**案例一：某能源集团火力发电远程告警系统**
+
+问题：基于上一代调度引擎在性能、权限控制等方面存在缺陷，导致出现告警延迟、无法精准控制权限等问题。
+
+**案例二：某石油加工集团云边端设备采集项目**
+
+问题：DDS与Hadoop架构紧密耦合，不仅前期需要额外部署Hadoop集群（即使客户不使用），后期Hadoop集群维护也增加了运维成本。
+
+**案例三：某军部数字化建设项目**
+
+问题：无法对整个集群的运行状态进行统计，比如1000个任务，在运行过程中，我们不知道哪些任务是正常运行的，哪些任务挂掉了；
+
+DDS中老调度引擎无法获取日志（日志的粒度依赖oozie
的日志）从而增加了**调试维护成本**，在开发过程中，命令行的方式也不是很友好，XML配置文件容易出错，开发效率低，无法更全面的统计与维护。
+
+综上所诉的这些缺点和问题，导致了我们需要迭代一个新的版本，**在DDS的后续版本准备对调度引擎进行替换**，来解决这些使用当中的痛点。
+
+# **全新调度引擎的迁移**
+
+## 01**调研阶段**
+
+接下来跟大家分享的就是在迁移过程当中，我们的一些调研工作、遇到的问题以及解决方案。
+
+我们调研了oozie，azkaban，Airflow，
还有DolphinScherduler，当然还有一些其他的调度，这个表格里就没整理，在整个调研的阶段，我们特别重视的指标主要是资源的监控和分布式和日志，还有权限等方面的控制。
+
+
+
+
+
+## **为什么选择DolphinScheduler ？**
+
+**资源方面**，DolphinsScheduler 可以有自己的数据中心，可以对master worker运行状态和指标实时监控；
+
+**分布式方面**，支持HA，是去中心化的，支持多Master多worker；
+
+**日志方面，**通过DolphinsScheduler我们能准确的定位到每一个task任务执行的日志。也可以监控在执行过程当中启动时间，停止时间，然后运行的机器所在的运行阶段；
+
+**容错机制**也很有特色；
+
+**支持多租户**。DolphinsScheduler的租户能和Hadoop的用户能实现映射关系，实现对资源的精确管理；
+
+
+
+
+
+## 02 **引擎接入方案(dds-adaptor)**
+
+### **接入方案-典型问题**
+
+在迁移的过程当中，**我们遇到了一个典型的问题**：DolphinScheduler中的描述文件（json）无法与DDS的工作流描述文件（xml）兼容。就是DDS中的工作流是用xml的格式来绘制描述的。而DolphinScheduler中是使用json格式来描述的，**这样就会导致于现有的前端生成的XML，无法兼容DolphinScheduler。**
+
+### **问题解决方案**
+
+我们在DDS和DolphinScheduler中间，加入了DDS-adaptor服务，它有一个自己的API，DDS前端绘制完工作流，会将XML格式的请求体，通过API接口的形式发送到parser-engine，parser-engine收到了带有XML参数的请求后，会将它解析成JSON格式
，当然这个JSON就是我们DS引擎能解析和兼容的。这样就解决了保留DDS前端框架不变的情况下，将原有的XML描述方式，适配到DolphinScheduler的json方式。
+
+**这样也就实现了我们在DDS前端创建task 任务，在DS的后端会生成DolphinScheduler task 规则的任务。**
+
+也就是说可能有个客户DDS使用了几年。上面配了几千个任务，用这个架构接入方案它就不需要重新的做任务的迁移，可以无缝的实现底层调度引擎的迁移。
+
+## 03 **实现简介**
+
+### **DDS_adaptor架构**
+
+DDS_adaptor项目里边包含两个子项目，一个**dsengine-core和external-model**，那么前面说的API是在controller层里，当我们接收到xml的请求，会通过engine-core去对它进行解析。
+
+### **具体的实现**
+
+
+
+
+
+**实现流程：**
+
+1.前端先发送XML文件到HTTP接口
+
+2.HTTP接到之后会创建一个解析工厂也就是SchedulerParserFactory
+
+3.解析工厂生成一个IParser接口
+
+4.然后实现Dds2DolphinModelParser，也就是模型解析实现类
+
+5.其中parser方法实际上是XML格式的字符串，里面调用的是核心方法、核心类
+
+6.DdsDolphinModelAdaptor，即模型适配器。在接收parser传进来的参数后会有两个方法，[分别是from和.to](http://xn--from-pg9fth21n4t8b.to)，from是将DDS的Graph转换成中间对象的Graph。.to是将中间对象的Graph转换成Dolphin的Graph。
+
+7.创建SystemConvertDepartmentFactory，它同时会创建DDS转换成Dolphin特有的转换方法，分别有3个：
+
+**方法一：**
+
+INodeConvertercreateNodeConverter（nodeType）：**创建节点转换器**
+
+**方法二：**
+
+AdaptorNodeTypeconvertNodeType2Adaptor(nodeType) ：**目标节点转为中间节点**
+
+**方法三：**
+
+StringconvertAaptor2NodeType(AdaptorNodeType)：**中间节点转为目标节点**
+
+在第一步中需要将DDS Graph 转为 Adaptor Graph ，这个实际上执行的时是AdaptorNodeType
convertNodeType2Adaptor(nodeType) 方法，将Graph做转换，
+
+但是每个Graph 中包含很多组件，因此每个组件都需要进行转换，需要调用到的方法是
+
+convertAdpator2Node(AdaptorNode , OutputNode)
+
+convertNode2Adaptor(AdaptorNodeBuilder,InputNode)，针对每个组件进行转换，实现了将DDS Graph 转为
Adaptor Graph。
+
+**第二步是中间对象转换成目标对象**，我们想要的是Dolphin的Graph，这个时候实际上就是将中间组件转换成目标组件，这样就实现了中间的Graph转换成目标Graph，中间的Graph就是Adaptor-Garph，目标组件就是Dolphin-Graph，这样就实现了前端以XML的方式发送，引擎解析出来是Dolphin支持的json格式
+
+# **引擎功能优化（更智能）**
+
+主要介绍扩展的两个功能，第一个是节点推荐机制，第二个是重跑控制策略。
+
+## **节点推荐机制**
+
+
+
+
+
+在DDS调度启动之前，可以进行一个调度策略的设置，分别有一个分配策略和推荐节点；
+
+在分配策略的时候，我们可以根据实际情况来选择，比如你是采集任务还是计算任务？是让它网络优先，还是IO优先，在这里你可以根据不同的情况自定义选择。
+
+## **时间架构**
+
+
+
+
+
+这里没有展示时间关系代码，主要依赖是基于DDS-monitor。在每一个子节点上部署
agent，那么agent它会采集系统的各种信息，比如说我们的系统版本，CPU，内存，磁盘等。
+
+agent会将这些信息上报给server端，sever端将这些指标全部存在时序数据库里，数据库主要有两个用途，一个是我们监控数据，我们可以监控每一个agent上面的信息，另一个就是分析计算，指标分析计算后，根据我们的策略规则，会将符合功能策略的节点推荐返回给server，从而实现了节点的推荐机制。
+
+## **分析指标**
+
+我们指标分析计算里面涉及到的一些指标，有系统版本、CPU、内存、磁盘、进程、端口、网络io等等
+
+
+
+
+
+那么配置规则里有IO相关的配置，有符合我们特定业务类型的配置。
+
+
+
+
+
+## **重跑控制策略**
+
+我们对调度的是否重跑可以进行控制。比如说当任务运行到一半的时候，节点重启，所有的任务都失败了，有一些任务可以直接进行重跑覆盖，但是有一些任务重跑会影响它的结果，所以对这些重跑的限制也是针对需求来进行优化的点。
+
+# **总结与计划**
+
+一方面，不管是基于DolphinScheduler引擎去开发自己的调度系统，还是直接使用DolphinScheduler进行二次开发，都是需要根据自己的开发环境来实际操作，**比如说公司的环境要求、规范、前后端技术栈、开发环境等等**，不要拿过来就开发，需要多方面的考虑。
+
+另一方面，我们在devops过程当中需要收集和整理产生的这些缺陷、缺点和一些用户的痛点, 我们需要在这个版本的迭代当中，有针对性的去处理这些问题。
+
+我们后续也有很多功能在实现当中，给大家列举一下，比如说后续的**Task组件节点之间结果集的传递、SQL
运行后传递给后续节点等**，然后还需要集成一些热门的时序数据库，比如说influxdb、open plant等。
+
+等实现之后希望还有机会和大家一起交流分享，谢谢大家。
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
index 6418f260f4..a226e743d5 100644
---
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
@@ -5,7 +5,6 @@ description: Fordeal数据平台新版系统决定基于Apache DolphinScheduler
---
-
Fordeal的数据平台调度系统之前是基于Azkaban进行二次开发的，但是在用户层面、技术层面都存在一些痛点问题难以被解决。比如在用户层面缺少任务可视化编辑界面、补数等必要功能，导致用户上手难体验差。在技术层面，架构过时，持续迭代难度大。基于这些情况，经过竞品对比和调研后，Fordeal数据平台新版系统决定基于Apache
DolphinScheduler进行升级改造。那整个迁移过程中开发人员是如何让使用方平滑过渡到新系统，又做出了哪些努力呢？
@@ -16,32 +15,25 @@ Fordeal的数据平台调度系统之前是基于Azkaban进行二次开发的，
讲师介绍
-
**卢栋**
Fordeal 大数据开发工程师。5年的数据开发相关经验，目前就职于Fordeal，主要关注的数据技术方向包括：湖仓一体、MPP数据库、数据可视化等。
-
-
**本次演讲主要包含四个部分：**
-- Fordeal数据平台调度系统的需求分析
-
-- 迁移到Apache Dolphin Scheduler过程中如何适配
-
-- 适配完成后如何完成特新增强
-
-- 未来规划
-
+- Fordeal数据平台调度系统的需求分析
+- 迁移到Apache Dolphin Scheduler过程中如何适配
+- 适配完成后如何完成特新增强
+
+- 未来规划
## 一、需求分析
### 01 Fordeal 应用背景
-
Fordeal
数据平台调度系统最早是基于Azkaban进行二次开发的。支持机器分组，SHELL动态参数、依赖检测后勉强可以满足使用，但在日常使用中依然存在以下三个问题，分别是在用户、技术和运维的层面。
@@ -51,38 +43,30 @@ Fordeal 数据平台调度系统最早是基于Azkaban进行二次开发的。
第三在**运维层面**，也是最大的问题。系统不定时会出来 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都需要自己进行修改，那会大大降低开发效率。
-
+1. **首选JVM系语言。**因为JVM系语言在线程、开发文档等方面较为成熟。
+
+ Airflow基于Python其实和我们现在的体系并无二异，非技术同学无法使用
-### Fordeal 现在的架构
+2. **分布式架构，支持HA。**Azkaban的work并不是分布式web和master服务是耦合在一起，因此属于单节点。
+3. **工作流必须支持DSL和可视化编辑。**这样可以保证技术同学可以用DSL进行书写，可视化则面向用户，用以扩大用户面。
-
+4. **前后端分离，主流架构。**前后端可以分开进行开发，剥离开来后耦合度也会降低。
+5. **社区活跃度。**最后关注的的社区活跃度对于开发也十分重要，如果经常存在一些“陈年”老bug都需要自己进行修改，那会大大降低开发效率。
-如今我们的数据架构如上图。Apache Dolphin
Scheduler承接了整个生命周期从HDFS、S3采集到K8S计算再到基于Spark、Flink的开发。两边的olphinScheduler和Zookeeper都是作为基础性的架构。我们的调度信息如下：Master
x2、Worker x6、API x1（承载接口等），**目前日均工作流实例：3.5k，日均任务实例15k+**。（下图为1.2.0版本架构图）
+### Fordeal 现在的架构
-
+
+如今我们的数据架构如上图。Apache Dolphin
Scheduler承接了整个生命周期从HDFS、S3采集到K8S计算再到基于Spark、Flink的开发。两边的olphinScheduler和Zookeeper都是作为基础性的架构。我们的调度信息如下：Master
x2、Worker x6、API x1（承载接口等），**目前日均工作流实例：3.5k，日均任务实例15k+**。（下图为1.2.0版本架构图）
+
## 二、适配迁移
@@ -91,26 +75,23 @@ Fordeal 数据平台调度系统最早是基于Azkaban进行二次开发的。
Fordeal内部系统需要上线对用户提供访问，这时候必须对接几个内部服务，以降低用户上手成本和减少运维工作。主要包括以下**三个系统**。
-1. **单点登录系统：**
-
- 基于JWT实现的SSO系统，一次登录，认证所有。
-
+1. **单点登录系统：**
+
+ 基于JWT实现的SSO系统，一次登录，认证所有。
+
2. ** 工单系统：**
-
+
DS对项目的授权接入工单，避免人肉运维。
-
+
（接入所有授权动作，实现自动化）
-
+
3. ** 告警平台：**
-
+
扩展DS告警模式，将告警信息全部发送到内部告警平台，用户可配置电话、企业微信等模式告警。
-
下方三张图就是对应分别是**登录系统、工单权限和企业微信的告警**。
-
-
### 02 Azkaban 的兼容
@@ -123,41 +104,36 @@ Azkaban的Flow管理是基于**自定义的DSL配置**，每个Flow配置包含
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）。
-
+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 分类词云。
-
## 三、特性增强
@@ -175,47 +151,41 @@ Azkaban的Flow管理是基于**自定义的DSL配置**，每个Flow配置包含
**执行方案**
-1. 基于 AntDesign 库开发新的一套前端界面。
-
-2. 弱化项目概念，不想让用户过多去关注项目这个概念，项目只作为工作流或实例的标签。
-
- 目前电脑版只有四个入口，首页、工作流列表、执行列表和资源中心列表，手机版只有两个入口，分别是工作流列表和执行列表。
-
-3. 简化操作步骤，将工作流列表和执行列表放在第一入口。
-
-4. 优化查询条件和索引，增加批量操作接口等。
-
- 增加联合索引。
-
-5. 完全适配电脑和手机（除了编辑 dag ，其他功能都一致）
-
+1. 基于 AntDesign 库开发新的一套前端界面。
+
+2. 弱化项目概念，不想让用户过多去关注项目这个概念，项目只作为工作流或实例的标签。
+
+ 目前电脑版只有四个入口，首页、工作流列表、执行列表和资源中心列表，手机版只有两个入口，分别是工作流列表和执行列表。
+
+3. 简化操作步骤，将工作流列表和执行列表放在第一入口。
+
+4. 优化查询条件和索引，增加批量操作接口等。
+
+ 增加联合索引。
+
+5. 完全适配电脑和手机（除了编辑 dag ，其他功能都一致）
### 02 依赖调度
**什么是依赖调度？**即工作流实例或 Task 实例成功后主动出发下游工作流或 Task
跑数（执行状态为依赖执行）。**设想以下几个场景**，下游工作流需要根据上游工作流的调度时间去设置自己的定时时间；上游跑数失败后，下游定时跑数是也会出现错误；上游补数，只能通知所有下游业务方补数。数仓上下游定时间隔调整难，计算集群资源利用率没有最大化（K8S）。因为用户并不是持续提交的。
-
-
构思图（按层触发工作流）
**依赖调度规则**
+1. 工作流支持时间，依赖，两者组合调度（且与或）
+
+2. 工作流内的Task支持依赖调度（不受定时限制）。
-1. 工作流支持时间，依赖，两者组合调度（且与或）
-
-2. 工作流内的Task支持依赖调度（不受定时限制）。
-
-3. 依赖调度需要设置一个依赖周期，只有当所有的依赖在这个周期内满足才会触发。
-
-4. 依赖调度最小的设置单位是 Task ，支持依赖多个工作流或 Task （只支持且关系）。
-
-5. 工作流仅仅只是一个执行树中的组概念，就是说不会限制Task。
-
+3. 依赖调度需要设置一个依赖周期，只有当所有的依赖在这个周期内满足才会触发。
+
+4. 依赖调度最小的设置单位是 Task ，支持依赖多个工作流或 Task （只支持且关系）。
+
+5. 工作流仅仅只是一个执行树中的组概念，就是说不会限制Task。
-
手机工作流依赖详情
@@ -223,35 +193,31 @@ Azkaban的Flow管理是基于**自定义的DSL配置**，每个Flow配置包含
拓展更多的 **Task 类型**，将常用的功能抽象并提供编辑界面，降低使用成本，我们主要扩展了以下几个。
-1. **数据开放平台（DOP）**：
-
- 主要是提供数据导入导出功能（支持Hive、Hbase，Mysql、ES、Postgre、Redis、S3）
-
-2. **数据质量：**基于Deequ开发的数据校验。
-
- 对数据进行抽象供用户使用。
-
-3. **SQL-Prest数据源：**SQL模块支持Presto数据源
-
-4. **血缘数据采集：**内置到所有Task中，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告警等等。
-
+1. API、Master和Worker服务接入micrometer-registry-prometheus，采集通用数据并暴露Prometheus采集接口。
+
+2. 采集Master和Worker执行线程池状态数据，如Master和Worker正在运行的工作流实例、数据库等，用于后续的监控优化和告警（下右图）。
+
+3. Prometheus侧配置服务状态异常告警，比如一段时间内工作流实例运行数小于n（阻塞）、服务内存&CPU告警等等。
-
## 四、未来规划
@@ -259,22 +225,19 @@ Azkaban的Flow管理是基于**自定义的DSL配置**，每个Flow配置包含
目前Fordeal线上运行的版本是基于社区第一个**Apache版本（1.2.0）**进行二开的，通过监控我们也发现了几个问题。
-1. 数据库压力大，网络IO费用高
-
-2. Zookeeper 充当了队列角色，时不时对导致磁盘IOPS飙升，存在隐患
-
-3. Command 消费和Task分发模型比较简单，导致机器负载不均匀
-
-4. 这个调度模型中使用了非常多的轮询逻辑（Thread.sleep），调度消费、分发、检测等效率不高
-
+1. 数据库压力大，网络IO费用高
+
+2. Zookeeper 充当了队列角色，时不时对导致磁盘IOPS飙升，存在隐患
+
+3. Command 消费和Task分发模型比较简单，导致机器负载不均匀
+
+4. 这个调度模型中使用了非常多的轮询逻辑（Thread.sleep），调度消费、分发、检测等效率不高
社区发展迅速，当下的架构也更加的合理易用，很多问题得到了解决，我们近期比较关注的问题是Master直接对Worker的分发任务，减轻Zookeeper
的压力，**Task
类型插件化，易于后续扩展。**Master配置或自定义分发逻辑，机器复杂更加合理。更完美的容错机制和运维工具（**优雅上下线**），现在Worker没有优雅上下线功能，现在更新Worker的做法是切掉流量，让线程池归零后再上下线，比较安全。
### 02 完善数据同步
-
-
目前只提供了工作流实例的执行统计，粒度比较粗，后续需要支持更细化的统计数据，如**按照 Task
筛选进行统计分析，按照执行树进行统计分析，按照最耗时的执行路径分析等**（对其进行优化）。
@@ -283,11 +246,7 @@ Azkaban的Flow管理是基于**自定义的DSL配置**，每个Flow配置包含
### 03 连接其他系统
-
当调度迭代稳定后，会逐步充当基础组件使用，提供更加便利的**接口和可嵌入的窗口**（iframe），让更多的上层数据应用（如BI系统，预警系统）等对接进来，提供基础的调度功能。
我的分享就到这里，谢谢大家认真阅读！
-
-
-
diff --git a/config/blog/zh-cn/user.json b/config/blog/zh-cn/user.json
index c3a72fa5f1..4d00f426c9 100644
--- a/config/blog/zh-cn/user.json
+++ b/config/blog/zh-cn/user.json
@@ -1,5 +1,19 @@
{
-
"Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification":
{
+"Practical_development_and_application_of_Apache_DolphinScheduler_in_DDS": {
+ "title": "小海豚“变身”全新智能调度引擎，深入浅出在DDS的实践开发应用？",
+ "author": "Niko Zeng",
+ "dateStr": "2023-9-6",
+ "desc":
"本文是基于DolphinScheduler的智能调度引擎在DDS的应用，这场演讲主要会跟大家介绍宇动源-DDS（自研的图形化数据开发工作室）、大数据架构、DDS产品和使用中遇到的问题，包括在迁移过程中的调研情况、遇到的困难、解决方案以及针对需求的优化...",
+ "img": "/img/2023-9-6/1.png"
+ },
+"How_does_Apache_DolphinScheduler_solve_the_pain_points_of_Chuanzhi_Education_data_warehouse_scheduling":
{
+ "title": "Apache DolphinScheduler 如何解决传智教育数仓调度痛点？",
+ "author": "Niko Zeng",
+ "dateStr": "2023-9-5",
+ "desc": "本文主要介绍了传智教育数仓架构的演变和Apache DolphinScheduler在传智的实践与思考 ...",
+ "img": "/img/2023-9-5/1.png"
+ },
+"Help_the_data_pipeline_platform_in_the_automotive_industry_to_connect_data_islands_and_strengthen_data_unification":
{
"title": "助力长城汽车数据管道平台连接 “数据孤岛”，加强数据一元化，Apache DolphinScheduler 的角色定位",
"author": "Niko Zeng",
"dateStr": "2023-8-31",
