This is an automated email from the ASF dual-hosted git repository.

cancai pushed a commit to branch dev
in repository 
https://gitbox.apache.org/repos/asf/incubator-streampark-website.git


The following commit(s) were added to refs/heads/dev by this push:
     new 9c07dd4  [improve] update whitespace and punctuation are used properly 
(#350)
9c07dd4 is described below

commit 9c07dd4016bd594a20f5fb22cd3e6de4d2877712
Author: VampireAchao <[email protected]>
AuthorDate: Thu Apr 25 16:49:45 2024 +0800

    [improve] update whitespace and punctuation are used properly (#350)
---
 .../0-streampark-flink-on-k8s.md                       |  6 +++---
 .../1-flink-framework-streampark.md                    |  4 ++--
 .../10-streampark-flink-with-paimon-in-ziru.md         |  2 +-
 .../2-streampark-usercase-chinaunion.md                |  4 ++--
 .../3-streampark-usercase-bondex-paimon.md             |  8 ++++----
 .../4-streampark-usercase-shunwang.md                  |  2 +-
 .../5-streampark-usercase-dustess.md                   |  6 +++---
 .../6-streampark-usercase-joyme.md                     |  6 +++---
 .../7-streampark-usercase-haibo.md                     |  4 ++--
 .../8-streampark-usercase-ziru.md                      | 18 +++++++++---------
 .../9-streampark-usercase-changan.md                   | 12 ++++++------
 11 files changed, 36 insertions(+), 36 deletions(-)

diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/0-streampark-flink-on-k8s.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/0-streampark-flink-on-k8s.md
index f2dc7fc..a85684d 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/0-streampark-flink-on-k8s.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/0-streampark-flink-on-k8s.md
@@ -14,9 +14,9 @@ Native Kubernetes 具有以下优势:
 
 - 更短的 Failover 时间
 - 可以实现资源托管,不需要手动创建 TaskManager 的 Pod,可以自动完成销毁
-- 具有更加便捷的 HA,Flink 1.12版本之后在 Native Kubernetes 模式下,可以依赖于原生 Kubernetes 的 
Leader选举机制来完成 JobManager 的 HA
+- 具有更加便捷的 HA,Flink 1.12 版本之后在 Native Kubernetes 模式下,可以依赖于原生 Kubernetes 的 
Leader选举机制来完成 JobManager 的 HA
 
-Native Kubernetes 和 Standalone Kubernetes 主要区别在于 Flink 与 Kubernetes 
交互的方式不同以及由此产生的一系列优势。Standalone Kubernetes 需要用户自定义 JobManager  和 TaskManager 的 
Kubernetes 资源描述文件,提交作业时需要用 kubectl 结合资源描述文件启动 Flink 集群。而 Native Kubernetes 模式 
Flink Client 里面集成了一个 Kubernetes Client,它可以直接和 Kubernetes API Server 进行通讯,完成 
JobManager Deployment 以及 ConfigMap 的创建。JobManager Development 创建完成之后,它里面的 
Resource Manager 模块可以直接和 Kubernetes API Server 进行通讯,完成 TaskManager pod 
的创建和销毁工作以及 Taskmanager 的弹性伸缩。因此生产环境中推荐使用 Flink  [...]
+Native Kubernetes 和 Standalone Kubernetes 主要区别在于 Flink 与 Kubernetes 
交互的方式不同以及由此产生的一系列优势。Standalone Kubernetes 需要用户自定义 JobManager 和 TaskManager 的 
Kubernetes 资源描述文件,提交作业时需要用 kubectl 结合资源描述文件启动 Flink 集群。而 Native Kubernetes 模式 
Flink Client 里面集成了一个 Kubernetes Client,它可以直接和 Kubernetes API Server 进行通讯,完成 
JobManager Deployment 以及 ConfigMap 的创建。JobManager Development 创建完成之后,它里面的 
Resource Manager 模块可以直接和 Kubernetes API Server 进行通讯,完成 TaskManager pod 
的创建和销毁工作以及 Taskmanager 的弹性伸缩。因此生产环境中推荐使用 Flink o [...]
 
 ![](/blog/relx/nativekubernetes_architecture.png)
 
@@ -73,7 +73,7 @@ kubectl -n flink-cluster get svc
 
 ------
 
-对于企业级生产环境使用 Flink on Kubernetes 会有着更高的要求, 一般会选择自建平台或者购买相关商业产品, 不论哪种方案在产品能力上满足: 
**大批量任务开发部署、状态跟踪、运维监控、失败告警、任务统一管理、高可用性** 等这些是普遍的诉求。
+对于企业级生产环境使用 Flink on Kubernetes 会有着更高的要求,一般会选择自建平台或者购买相关商业产品,不论哪种方案在产品能力上满足: 
**大批量任务开发部署、状态跟踪、运维监控、失败告警、任务统一管理、高可用性** 等这些是普遍的诉求。
 
 针对以上问题我们调研了开源领域支持开发部署 Flink on Kubernetes 
任务的开源项目,调研的过程中也不乏遇到了其他优秀的开源项目,在综合对比了多个开源项目后得出结论: **StreamPark 
不论是完成度还是使用体验、稳定性等整体表现都非常出色,因此最终选择了 StreamPark 作为我们的一站式实时计算平台。**下面我们看看 
StreamPark 是如何支持 Flink on Kubernetes :
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/1-flink-framework-streampark.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/1-flink-framework-streampark.md
index 756d7ff..5e2f875 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/1-flink-framework-streampark.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/1-flink-framework-streampark.md
@@ -31,7 +31,7 @@ Hadoop 体系虽然在目前应用非常广泛,但架构繁琐、运维复杂
 
 在这里,实际上有一些问题我们一直没有彻底解决:
 
-用过 Native-Application 模式的朋友都知道,每提交一个任务,都需要打包新的镜像,提交到私有仓库,然后再调用 Flink Run 指令沟通 
K8s,去拉取镜像运行 Pod。任务提交之后,还需要去 K8s 查看 log, 但是:
+用过 Native-Application 模式的朋友都知道,每提交一个任务,都需要打包新的镜像,提交到私有仓库,然后再调用 Flink Run 指令沟通 
K8s,去拉取镜像运行 Pod。任务提交之后,还需要去 K8s 查看 log,但是:
 
 1. 任务运行监控怎么处理?
 2. 使用 Cluster 模式还是 NodePort 暴露端口访问 Web UI?
@@ -167,7 +167,7 @@ SQL 校验能力和 Zeppelin 基本一致:
 
 ![](/blog/belle/sqlverify.png)
 
-我们也可以指定资源,指定 Flink Run 中的动态参数 Dynamic Option,甚至参数可以整合 Pod  Template
+我们也可以指定资源,指定 Flink Run 中的动态参数 Dynamic Option,甚至参数可以整合 Pod Template
 
 ![](/blog/belle/pod.png)
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/10-streampark-flink-with-paimon-in-ziru.md
 
b/i18n/zh-CN/docusaurus-plugin-content-blog/10-streampark-flink-with-paimon-in-ziru.md
index 76b686d..cce070e 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-blog/10-streampark-flink-with-paimon-in-ziru.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-blog/10-streampark-flink-with-paimon-in-ziru.md
@@ -30,7 +30,7 @@ Paimon: https://github.com/apache/paimon
 
 自如的数据集成方案根据业务使用场景主要可分为两种:
 
-- **低新鲜度**:低新鲜度对数据的时效性要求是 **T+1day**  , 每日定时凌晨 00:00 采用 Hive jdbc handler 进行 
MySQL 数据的全量拉取至 Hive,其基本流程如下图所示:
+- **低新鲜度**:低新鲜度对数据的时效性要求是 **T+1day**,每日定时凌晨 00:00 采用 Hive jdbc handler 进行 
MySQL 数据的全量拉取至 Hive,其基本流程如下图所示:
 
   ![](/blog/ziru/low_freshness.png)
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/2-streampark-usercase-chinaunion.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/2-streampark-usercase-chinaunion.md
index 65bba59..5ecf903 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-blog/2-streampark-usercase-chinaunion.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-blog/2-streampark-usercase-chinaunion.md
@@ -31,7 +31,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 第一部分是采集解析,我们的数据源来自于业务的数据库,包含 OGG 和 DTS 格式的消息、日志消息、用户行为和用户位置数据,总共 50 
多种数据源,后续还会逐渐增加,所有数据源均使用 Flink 做实时解析;并增加了 Metrics 来监控数据源的延迟情况。
 
-第二部分是实时计算, 这个环节处理的数据量很大,数据量在万亿级别,支撑了 10000+的数据实时订阅,有 200 多个 Flink 
任务,我们将某一种同类型的业务封装成一种场景,同一个 Flink 作业可以支持相同场景的多个订阅,目前 Flink 作业数还在不停的增长,后续可能会增加到 
500 
多个;其中面临的一个很大挑战是每天万亿级的数据实时关联电子围栏、用户特征等信息,电子围栏有几万个,用户特征涉及数亿用户,最初我们将电子围栏信息和用户特征放到 
HBase, 但这样会导致 HBase 压力很大,经常遇到性能问题造成数据延迟,而且一旦产生数据积压,需要很长的时间去消化,得益于 Flink State 
的强大,我们将电子围栏信息和用户特征放到状态里,目前已经很好的支撑了大并发的场景,同时我们也增加了数据处理的性能监控;最后是实时产品和营销触达前
 端的一些应用。
+第二部分是实时计算,这个环节处理的数据量很大,数据量在万亿级别,支撑了 10000+的数据实时订阅,有 200 多个 Flink 
任务,我们将某一种同类型的业务封装成一种场景,同一个 Flink 作业可以支持相同场景的多个订阅,目前 Flink 作业数还在不停的增长,后续可能会增加到 
500 
多个;其中面临的一个很大挑战是每天万亿级的数据实时关联电子围栏、用户特征等信息,电子围栏有几万个,用户特征涉及数亿用户,最初我们将电子围栏信息和用户特征放到 
HBase,但这样会导致 HBase 压力很大,经常遇到性能问题造成数据延迟,而且一旦产生数据积压,需要很长的时间去消化,得益于 Flink State 
的强大,我们将电子围栏信息和用户特征放到状态里,目前已经很好的支撑了大并发的场景,同时我们也增加了数据处理的性能监控;最后是实时产品和营销触达前
 端的一些应用。
 
 ![](/blog/chinaunion/platform_evolution.png)
 
@@ -51,7 +51,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 运维背景也可以分为以下几部分:
 
 - 支撑需求多:50 多种数据源,10000+的数据服务订阅。
-- 实时作业多:现在有 200+Flink 生产作业,并且持续快速增长中, 未来可达 500+。
+- 实时作业多:现在有 200+Flink 生产作业,并且持续快速增长中,未来可达 500+。
 - 上线频率高:每天都有新增的或增强的 Flink 作业上线操作。
 - 开发人员多:50+研发人员参与开发 Flink 实时计算任务。
 - 使用用户多:30+内部和外部组织的用户使用。
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/3-streampark-usercase-bondex-paimon.md
 
b/i18n/zh-CN/docusaurus-plugin-content-blog/3-streampark-usercase-bondex-paimon.md
index da60201..11b0ab8 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-blog/3-streampark-usercase-bondex-paimon.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-blog/3-streampark-usercase-bondex-paimon.md
@@ -253,7 +253,7 @@ docker push 
registry-vpc.cn-zhangjiakou.aliyuncs.com/xxxxx/flink-table-store:v1.
 kubectl cluster-info
 ```
 
-Kubernetes RBAC 配置,创建 streampark 命名空间:
+Kubernetes RBAC 配置,创建 streampark 命名空间:
 
 ```shell
 kubectl create ns streampark
@@ -783,7 +783,7 @@ paimon-dws:
 
 ![](/blog/bondex/paimon-dws.png)
 
-特别提醒 sqlserver 数据库抽取时如果源表数据量过大全量抽取会锁表,建议在业务允许的情况下采用增量抽取。对于全量抽取 sqlserver 
可以采用中转的方式 sqlserver 全量数据导入到 mysql,从 mysql 再到 paimon-ods ,后面再通过 sqlserever 做增量抽取。
+特别提醒 sqlserver 数据库抽取时如果源表数据量过大全量抽取会锁表,建议在业务允许的情况下采用增量抽取。对于全量抽取 sqlserver 
可以采用中转的方式 sqlserver 全量数据导入到 mysql,从 mysql 再到 paimon-ods ,后面再通过 sqlserever 做增量抽取。
 
 ## 04 问题排查分析
 
@@ -797,7 +797,7 @@ sqlserver cdc 采集数据到 paimon 表,说明:
 
 **ads 表:**
 
-'merge-engine' = 'aggregation',  -- 使用 aggregation 聚合计算 sum
+'merge-engine' = 'aggregation',-- 使用 aggregation 聚合计算 sum
 
 'fields.sum_amount.aggregate-function' = 'sum'
 
@@ -929,7 +929,7 @@ https://github.com/apache/incubator-paimon/pull/1308
 
 在复杂的实时任务中,可以通过修改动态参数的方式,增加资源。
 
-## 05  未 来 规 划
+## 05 未 来 规 划
 
 - 自建的数据平台 bondata 正在集成 paimon 的元数据信息、数据指标体系、血缘、一键 pipline 
等功能,形成海程邦达的数据资产,并将在此基础上展开一站式数据治理
 - 后面将基于 trino Catalog接入Doris,实现真正的离线数据和实时数据的one service
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/4-streampark-usercase-shunwang.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/4-streampark-usercase-shunwang.md
index 7d86cdd..9831945 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-blog/4-streampark-usercase-shunwang.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-blog/4-streampark-usercase-shunwang.md
@@ -100,7 +100,7 @@ Streaming-Launcher 中,没有提供统一的作业管理界面。开发同学
 
 **开发脚手架**
 
-通过进一步的研究发现,StreamPark 不仅仅是一个平台,还包含 Flink 作业开发脚手架, 在 StreamPark 中,针对编写代码的 Flink 
作业,提供一种更好的解决方案,将程序配置标准化,提供了更为简单的编程模型,同时还提供了一些列 Connectors,降低了 DataStream 开发的门槛。
+通过进一步的研究发现,StreamPark 不仅仅是一个平台,还包含 Flink 作业开发脚手架,在 StreamPark 中,针对编写代码的 Flink 
作业,提供一种更好的解决方案,将程序配置标准化,提供了更为简单的编程模型,同时还提供了一些列 Connectors,降低了 DataStream 开发的门槛。
 
 
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/5-streampark-usercase-dustess.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/5-streampark-usercase-dustess.md
index d167497..73fb813 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/5-streampark-usercase-dustess.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/5-streampark-usercase-dustess.md
@@ -4,7 +4,7 @@ title: Apache StreamPark™ 在尘锋信息的最佳实践,化繁为简极致
 tags: [StreamPark, 生产实践, FlinkSQL]
 ---
 
-**摘要:**本文源自 StreamPark 在尘锋信息的生产实践, 作者是资深数据开发工程师Gump。主要内容为:
+**摘要:**本文源自 StreamPark 在尘锋信息的生产实践,作者是资深数据开发工程师Gump。主要内容为:
 
 1. 技术选型
 2. 落地实践
@@ -51,7 +51,7 @@ tags: [StreamPark, 生产实践, FlinkSQL]
 
 #### **2. 支持多种部署模式**
 
-StreamPark 支持 Flink **所有主流的提交模式**,如 standalone、yarn-session 、yarn 
application、yarn-perjob、kubernetes-session、kubernetes-application  而且StreamPark 
不是简单的拼接 Flink run 命令来进行的任务提交,而是引入了 Flink Client 源码包,直接调用 Flink Client API 
来进行的任务提交。这样的好处是代码模块化、易读、便于扩展,稳定,且能在后期根据 Flink 版本升级进行很快的适配。
+StreamPark 支持 Flink **所有主流的提交模式**,如 standalone、yarn-session 、yarn 
application、yarn-perjob、kubernetes-session、kubernetes-application 而且StreamPark 
不是简单的拼接 Flink run 命令来进行的任务提交,而是引入了 Flink Client 源码包,直接调用 Flink Client API 
来进行的任务提交。这样的好处是代码模块化、易读、便于扩展,稳定,且能在后期根据 Flink 版本升级进行很快的适配。
 
 ![](/blog/dustess/execution_mode.png)
 
@@ -71,7 +71,7 @@ Flink SQL 现在虽然足够强大,但使用 Java 和 Scala 等 JVM 语言开
 
 StreamPark 除了支持 Jar 上传,更提供了**在线更新构建**的功能,优雅解决了以上问题:
 
-1、新建 Project :填写 GitHub/Gitlab(支持企业私服)地址及用户名密码, StreamPark 就能 Pull 和 Build 项目。
+1、新建 Project :填写 GitHub/Gitlab(支持企业私服)地址及用户名密码,StreamPark 就能 Pull 和 Build 项目。
 
 2、创建 StreamPark Custom-Code 任务时引用 Project,指定主类,启动任务时可选自动 Pull、Build 和绑定生成的 
Jar,非常优雅!
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/6-streampark-usercase-joyme.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/6-streampark-usercase-joyme.md
index 8230d9e..a795e5c 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/6-streampark-usercase-joyme.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/6-streampark-usercase-joyme.md
@@ -4,7 +4,7 @@ title: Apache StreamPark™ 在 Joyme 的生产实践
 tags: [StreamPark, 生产实践, FlinkSQL]
 ---
 
-**摘要:** 本文带来 StreamPark 在 Joyme 中的生产实践, 作者是 Joyme 的大数据工程师秦基勇, 主要内容为:
+**摘要:** 本文带来 StreamPark 在 Joyme 中的生产实践,作者是 Joyme 的大数据工程师秦基勇,主要内容为:
 
 - 遇见StreamPark
 - Flink Sql 作业开发
@@ -76,7 +76,7 @@ SELECT  Data.uid  FROM source_table;
 
 ### **2. 添加依赖**
 
-关于依赖这块是 StreamPark 里特有的,在 StreamPark 中创新型的将一个完整的 Flink Sql 任务拆分成两部分组成: Sql 和 
依赖, Sql 很好理解不多啰嗦, 依赖是 Sql 里需要用到的一些 Connector 的 Jar, 如 Sql 里用到了 Kafka 和 MySQL 的 
Connector, 那就需要引入这两个 Connector 的依赖, 在 StreamPark 中添加依赖两种方式,一种是基于标准的 Maven pom 
坐标方式,另一种是从本地上传需要的 Jar 。这两种也可以混着用,按需添加,点击应用即可, 在提交作业的时候就会自动加载这些依赖。
+关于依赖这块是 StreamPark 里特有的,在 StreamPark 中创新型的将一个完整的 Flink Sql 任务拆分成两部分组成: Sql 和 
依赖,Sql 很好理解不多啰嗦,依赖是 Sql 里需要用到的一些 Connector 的 Jar,如 Sql 里用到了 Kafka 和 MySQL 的 
Connector,那就需要引入这两个 Connector 的依赖,在 StreamPark 中添加依赖两种方式,一种是基于标准的 Maven pom 
坐标方式,另一种是从本地上传需要的 Jar 。这两种也可以混着用,按需添加,点击应用即可, 在提交作业的时候就会自动加载这些依赖。
 
 ![](/blog/joyme/add_dependency.png)
 
@@ -114,7 +114,7 @@ Streaming 作业我们是使用 Flink java 进行开发,将之前 Spark scala
 
 ![](/blog/joyme/add_projectconfiguration.png)
 
-以及任务的并行度,监控的方式等,内存大小根据任务需要进行配置。Program Args 程序的参数则根据程序需要自行定义入口参数,比如:我们统一启动类是 
StartJobApp,那么启动作业就需要传入作业的 Full name 告诉启动类要去找哪个类来启动此次任务,也就是一个反射机制,作业配置完成以后同样也是 
Submit 提交,然后在 application 界面部署任务。
+以及任务的并行度,监控的方式等,内存大小根据任务需要进行配置。Program Args 程序的参数则根据程序需要自行定义入口参数,比如:我们统一启动类是 
StartJobApp,那么启动作业就需要传入作业的 Full name 告诉启动类要去找哪个类来启动此次任务,也就是一个反射机制,作业配置完成以后同样也是 
Submit 提交,然后在 application 界面部署任务。
 
 ![](/blog/joyme/application_interface.png)
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/7-streampark-usercase-haibo.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/7-streampark-usercase-haibo.md
index faebb98..a629f4e 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/7-streampark-usercase-haibo.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/7-streampark-usercase-haibo.md
@@ -74,7 +74,7 @@ StreamPark 在海博主要用于运行实时 Flink SQL任务: 读取 Kafka 上
 
 **3. 数据分析模型管理**
 
-针对无法使用 Flink SQL 需要开发 Flink 代码的任务,例如: 实时布控模型、离线数据分析模型,StreamPark 提供了 Custom 
code 的方式, 允许用户上传可执行的 Flink Jar 包并运行。
+针对无法使用 Flink SQL 需要开发 Flink 代码的任务,例如: 实时布控模型、离线数据分析模型,StreamPark 提供了 Custom 
code 的方式,允许用户上传可执行的 Flink Jar 包并运行。
 
 目前,我们已经将人员,车辆等 20 余类分析模型上传至 StreamPark,交由 StreamPark 管理运行。
 
@@ -96,6 +96,6 @@ Datahub 是 Linkedin 开发的一个元数据管理平台,提供了数据源
 
 Workbench 将使用全新的工作台式的 SQL 开发风格,选择数据源即可生成 SQL,进一步提升 Flink 任务开发效率。统一的 UDF 
资源中心将解决当前每个任务都要上传依赖包的问题。批量任务调度功能将解决当前 StreamPark 无法调度任务的遗憾。
 
-下图是 StreamPark 开发者设计的原型图,敬请期待。
+下图是 StreamPark 开发者设计的原型图,敬请期待。
 
 ![](/blog/haibo/data_source.png)
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/8-streampark-usercase-ziru.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/8-streampark-usercase-ziru.md
index 8ba6c83..2a343db 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/8-streampark-usercase-ziru.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/8-streampark-usercase-ziru.md
@@ -22,7 +22,7 @@ tags: [StreamPark, 生产实践]
 
 在拥有庞大用户群体情况下,自如为了给用户提供更加优质的产品体验,实现企业的数字化转型,从 2021 年开始大力发展实时计算,Flink 
在自如的实时计算中一直扮演着重要的角色。到目前为止,自如每日需要处理 TB 级别的数据,总共拥有 500+ 个实时作业,并支撑每日超过 1000 
万次的数据调用请求。
 
-## **实时计算遇到的挑战**  
+## **实时计算遇到的挑战**
 
 在自如,实时计算大概分为 2 个应用场景:
 
@@ -58,7 +58,7 @@ tags: [StreamPark, 生产实践]
 
 因此,急需提高开发、调试的效率
 
-## **寻求解决方案之路**  
+## **寻求解决方案之路**
 
 在平台构建的初期阶段,2022 
年初开始我们就全面调查了行业内的几乎所有相关项目,涵盖了商业付费版和开源版。经过调查和对比发现,这些项目都或多或少地存在一定的局限性,可用性和稳定性也无法有效地保障。
 
@@ -86,7 +86,7 @@ tags: [StreamPark, 生产实践]
 
 在 StreamPark 的基础上,我们进一步完善了相关的功能,其中包括对 LDAP 
的支持,以便我们未来可以完全开放实时能力,让公司的四个业务线所属的分析师能够使用该平台,预计届时人数将达到 170 
人左右。随着人数的增加,账号的管理变得越发重要,特别是在人员变动时,账号的注销和申请将成为一项频繁且耗时的操作。所以,接入 LDAP 
变得尤为重要。因此我们及时和社区沟通,并且发起讨论,最终我们贡献了该 Feature。现在在 StreamPark 开启 LDAP 
已经变得非常简单,只需要简单两步即可:
 
-#### step1:  填写对应的 LDAP 配置:
+#### step1: 填写对应的 LDAP 配置:
 
 编辑 application.yml 文件,设置 LDAP 基础信息,如下:
 
@@ -250,7 +250,7 @@ curl -X POST '/flink/app/start' \
 
 ![](/blog/ziru/http_scheduling.png)
 
-## **实践经验总结**  
+## **实践经验总结**
 
 在深度使用 StreamPark 实践过程中,我们总结了一些常见问题和实践过程中所探索出解决方案,我们把这些汇总成示例,仅供大家参考。
 
@@ -466,12 +466,12 @@ public Optional<String> 
getExistingHadoopConfigurationConfigMap() {
 
 @Override
 public Optional<String> getLocalHadoopConfigurationDirectory() {
-    // 2、如果没有 1 中指定的参数,查找提交 native 命令的本地环境是否有环境变量:HADOOP_CONF_DIR
+    // 2、如果没有 1 中指定的参数,查找提交 native 命令的本地环境是否有环境变量:HADOOP_CONF_DIR
     final String hadoopConfDirEnv = 
System.getenv(Constants.ENV_HADOOP_CONF_DIR);
     if (StringUtils.isNotBlank(hadoopConfDirEnv)) {
         return Optional.of(hadoopConfDirEnv);
     }
-    // 3、如果没有 2 中环境变量,再继续看否有环境变量:HADOOP_HOME
+    // 3、如果没有 2 中环境变量,再继续看否有环境变量:HADOOP_HOME
     final String hadoopHomeEnv = System.getenv(Constants.ENV_HADOOP_HOME);
     if (StringUtils.isNotBlank(hadoopHomeEnv)) {
         // Hadoop 2.2+
@@ -498,7 +498,7 @@ if (hadoopConfigurationFileItems.isEmpty()) {
             localHadoopConfigurationDirectory.get());
     return flinkPod;
 }
-// 如果 2 或者 3 存在,会在路径下查找 core-site.xml 和 hdfs-site.xml 文件
+// 如果 2 或者 3 存在,会在路径下查找 core-site.xml 和 hdfs-site.xml 文件
 private List<File> getHadoopConfigurationFileItems(String 
localHadoopConfigurationDirectory) {
     final List<String> expectedFileNames = new ArrayList<>();
     expectedFileNames.add("core-site.xml");
@@ -518,7 +518,7 @@ private List<File> getHadoopConfigurationFileItems(String 
localHadoopConfigurati
     }
 }
 
-//如果有 hadoop 的环境,将会把上述两个文件解析为 kv 对,然后构建成一个 ConfigMap,名字命名规则如下
+//如果有 hadoop 的环境,将会把上述两个文件解析为 kv 对,然后构建成一个 ConfigMap,名字命名规则如下
 public static String getHadoopConfConfigMapName(String clusterId) {
     return Constants.HADOOP_CONF_CONFIG_MAP_PREFIX + clusterId;
 }
@@ -539,7 +539,7 @@ netstat -tlnp | grep 10002
 
 ![](/blog/ziru/production_environment.png)
 
-## **未 来 期 待**  
+## **未 来 期 待**
 
 自如作为 StreamPark 早期的用户之一,我们一直和社区同学保持密切交流,参与 StreamPark 的稳定性打磨,我们将生产运维中遇到的 Bug 
和新的 Feature 提交给了社区。在未来,我们希望可以在 StreamPark 上管理 Apache Paimon 湖表的元数据信息和 Paimon 的 
Action 辅助作业的能力,基于 Flink 引擎通过对接湖表的 Catalog 和 Action 作业,来实现湖表作业的管理、优化于一体的能力。目前 
StreamPark 正在对接 Paimon 数据集成的能力,这一块在未来对于实时一键入湖会提供很大的帮助。
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-blog/9-streampark-usercase-changan.md 
b/i18n/zh-CN/docusaurus-plugin-content-blog/9-streampark-usercase-changan.md
index 1388998..33c0fe6 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-blog/9-streampark-usercase-changan.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/9-streampark-usercase-changan.md
@@ -18,9 +18,9 @@ tags: [StreamPark, 生产实践]
 
 近些年随着汽车销量的不断增加与智能化程度的不断提升,车辆每天将产生千亿级别的 CAN 数据,清洗处理后的数据也在 50 
亿级别,面对如此庞大且持续膨胀的数据规模,如何从海量数据中快速提取挖掘有价值的信息,为研发、生产、销售等部门提供数据支持,成为当前亟需解决的问题。
 
-## **1.实时计算面临的挑战**  
+## **1.实时计算面临的挑战**
 
-长安汽车数据的存储与分析处理主要由云上和云下两部分构成,云上指的是我们部署在腾讯云服务器上的大数据集群,CDH 搭建, 
用于存储热数据;云下是部署在本地机房的 CDP 集群,从云上拉取同步数据,进行存储和分析。**Flink 
在长安汽车实时计算中一直扮演着重要的角色,长安汽车开发了一套流应用平台,来满足开发人员对于 Flink 
作业管理和运维工作的基础需求**。但是在实际使用中,流应用平台存在以下四各方面问题:
+长安汽车数据的存储与分析处理主要由云上和云下两部分构成,云上指的是我们部署在腾讯云服务器上的大数据集群,CDH 搭建,用于存储热数据;云下是部署在本地机房的 
CDP 集群,从云上拉取同步数据,进行存储和分析。**Flink 在长安汽车实时计算中一直扮演着重要的角色,长安汽车开发了一套流应用平台,来满足开发人员对于 
Flink 作业管理和运维工作的基础需求**。但是在实际使用中,流应用平台存在以下四各方面问题:
 
 ①**功能单一**: 只提供部署功能,无用户权限管理、团队管理、角色管理、项目管理,无法满足项目、团队管理需求。
 
@@ -30,7 +30,7 @@ tags: [StreamPark, 生产实践]
 
 ④**可维护性较差**: 无日志查看、无版本管理、无配置中心等。
 
-## **2.为什么用 StreamPark**  
+## **2.为什么用 StreamPark**
 
 我们针对Flink 作业面临的困境,决定先从开源领域寻求解决方案,因此我们全面调研了Apache 
StreamPark、Dxxky、strxxing-xx-web等开源项目,**从核心能力、稳定性、易用性、可扩展性、可维护性、操作体验等多个维度进行了全方位的评估对比,并结合当前我们的流作业开发需求以及我司的大数据平台后续规划,发现
 Apache StreamPark 是最符合我们当前需求的产品。因此采用 StreamPark 作为我们的流计算平台**,StreamPark 有以下优势:
 
@@ -64,7 +64,7 @@ StreamPark 解决了流应用平台可扩展性差,不支持在线扩容 Flink
 
 ![](/blog/changan/job_management.png)
 
-## **3.StreamPark落地实践** 
+## **3.StreamPark落地实践**
 
 为了使 StreamPark 在日常生产实践中与我们的需求更加契合,我们对其进行了一定的适应性改造:
 
@@ -144,10 +144,10 @@ source 使其生效,重启 StreamPark 即可。
 
 StreamPark 自身具备作业使用后重启拉取的能力,当检测到作业失败后会重新拉起,但在实践中发现会出现同一个失败的作业在 
YARN上启动多个的情况,经过和社区沟通,已确定是个 Bug,最终在 2.1.3 中解决了该 Bug。
 
-## **4.带来的收益** 
+## **4.带来的收益**
 
 目前长安汽车已经在云上生产/预生产环境、云下生产/预生产环境中部署了 StreamPark,截至发稿前 StreamPark 共管理了 150+ 的 
Flink 作业,包括 JAR 和与 SQL 作业。涉及利用 Flink、FlinkCDC 等技术,从 MySQL 或 kafka 同步数据到 
MySQL、Doris、HBase、Hive 等数据库。后续所有环境总计 3000+ 的 Flink 作业也会分批迁至 StreamPark 来集中管理。
 
 **Apache StreamPark 带来的收益最明显的就是其提供了一站式服务,业务开发同学可以在 StreamPark 
上完成作业开发编译发布,无需再使用多个工具完成一个 FlinkSQL 作业开发,简化了整个开发流程**,StreamPark 给我们在 Flink 
作业开发部署上节省了很多时间,显著地提升了 Flink 应用开发效率。
 
-![](/blog/changan/job.png)
\ No newline at end of file
+![](/blog/changan/job.png)

Reply via email to