StreamX 在尘锋信息的最佳实践，化繁为简极致体验

摘要：本文源自 StreamX 在尘锋信息的生产实践, 作者是资深数据开发工程师Gump。主要内容为：

1. 技术选型

2. 落地实践

3. 业务支撑 & 能力开放

4. 未来规划

5. 结束语

尘锋信息是基于企业微信生态的一站式私域运营管理解决方案供应商，致力于成为全行业首席私域运营与管理专家，帮助企业构建数字时代私域运营管理新模式，助力企业实现高质量发展。  

目前，尘锋已在全国拥有13个城市中心，覆盖华北、华中、华东、华南、西南五大区域，为超30个行业的10,000+家企业提供数字营销服务。

一. 技术选型

尘锋信息在2021年进入了快速发展时期，随着服务行业和企业客户的增加，实时需求越来越多，落地实时计算平台迫在眉睫。

由于公司处于高速发展期，需求紧迫且变化快，所以团队的技术选型遵循以下原则:

• 快：由于业务紧迫，我们需要快速落地规划的技术选型并运用生产

• 稳：满足快的基础上，所选择技术一定要稳定服务业务

• 新：在以上基础，所选择的技术也尽量的新    

• 全：所选择技术能够满足公司快速发展和变化的业务，能够符合团队长期发展目标，能够支持且快速支持二次开发

首先在计算引擎方面：我们选择 Flink，原因如下:

• 团队成员对 Flink 有深入了解，熟读源码

• Flink 支持批流一体，虽然目前公司的批处理架构还是基于 Hive、Spark 等。使用 Flink 进行流计算，便于后期建设批流一体和湖仓一体

• 目前国内 Flink 生态已经越来越成熟，Flink 也开始着手踏破边界向流式数仓发展

在平台层面，我们综合对比了 StreamX 、 Apache Zeppelin 和 flink-streaming-platform-web，也深入阅读了源码和并做了优缺点分析，关于后两个项目本文就不展开赘述，感兴趣的朋友可以去 GitHub 搜索，我们最终选择 StreamX，理由如下：

1.完成度高

1. 支持Flink 多版本

新建任务时可以自由选择Flink版本，Flink 二进制版本包会自动上传至 HDFS（如果使用 Yarn 提交），且一个版本的二进制包只会在 HDFS 保存一份。任务启动时会自动根据上下文加载 HDFS 中的 Flink 二进制包，非常优雅。能够满足多版本共存，及升级Flink 新版本试用测试的场景。

Flink Home 设置页  

2.支持多种部署模式

StreamX 支持 Flink 所有主流的提交模式，如 standalone、yarn-session 、yarn application、yarn-perjob、kubernetes-session、kubernetes-application   而且StreamX 不是简单的拼接 Flink run 命令来进行的任务提交，而是引入了 Flink Client 源码包，直接调用 Flink Client API 来进行的任务提交。这样的好处是代码模块化、易读、便于扩展，稳定，且能在后期根据 Flink 版本升级进行很快的适配。

多种部署模式  

Flink SQL 可以极大提升开发效率和提高 Flink 的普及。StreamX 对于 Flink SQL 的支持非常到位，优秀的 SQL 编辑器，依赖管理，任务多版本管理等等。StreamX 官网介绍后期会加入 Flink SQL 的元数据管理整合，大家拭目以待。

FlinkSQL IDE 

FlinkSQL 多版本管理,内容比对 

3.java任务在线构建

Flink SQL 现在虽然足够强大，但使用 Java 和 Scala 等 JVM 语言开发 Flink 任务会更加灵活、定制化更强、便于调优和提升资源利用率。与 SQL 相比 Jar 包提交任务最大的问题是Jar包的上传管理等，没有优秀的工具产品会严重降低开发效率和加大维护成本。  

StreamX 除了支持 Jar 上传，更提供了在线更新构建的功能，优雅解决了以上问题：    

1、新建 Project ：填写 GitHub/Gitlab（支持企业私服）地址及用户名密码, StreamX 就能 Pull 和 Build 项目。

2、创建 StreamX Custom-Code 任务时引用 Project，指定主类，启动任务时可选自动 Pull、Build 和绑定生成的 Jar，非常优雅！

同时 StreamX 社区最近也在完善整个任务编译、上线的流程，以后的 StreamX 会在此基础上更加完善和专业。

 项目列表  

4.完善的任务参数配置

对于使用 Flink 做数据开发而言，Flink run 提交的参数几乎是难以维护的。StreamX 也非常优雅的解决了此类问题，原因是上面提到的 StreamX 直接调用 Flink Client API，并且从 StreamX 产品前端打通了整个流程。

常用参数配置 

大家可以看到，StreamX 的任务参数设置涵盖了主流的所有参数，并且非常细心的对每个参数都做了介绍和最佳实践的最优推荐。这对于刚使用 Flink 的同学来说也是非常好的事情，避免踩坑！

5.优秀的配置文件设计

对于 Flink 任务的原生参数，上面的任务参数已经涵盖了很大一部分。StreamX 还提供了强大的Yaml 配置文件 模式和 编程模型。

扩展参数配置 

1、对于 Flink SQL 任务，直接使用任务的 Yaml 配置文件可以配置 StreamX 已经内置的参数，如常见的 CheckPoint、重试机制、State Backend、table planer 、mode 等等。

2、对于 Jar 任务，StreamX 提供了通用的编程模型，该模型封装了 Flink 原生 API ，结合 StreamX 提供的封装包可以非常优雅的获取配置文件中的自定义参数，这块文档详见：

编程模型：

编程模型 | StreamXhttp://www.streamxhub.com/docs/development/dev-model

内置配置文件参数：

项目配置 | StreamXClientOption,http://www.streamxhub.com/docs/development/config

除此之外：

StreamX 也支持Apache Flink 原生任务，参数配置可以由 Java 任务内部代码静态维护，可以覆盖非常多的场景，比如存量 Flink 任务无缝迁移等等

6.Checkpoint管理

关于 Flink 的 Checkpoint（Savepoint）机制，最大的困难是维护 ，StreamX 也非常优雅的解决此问题:

• StreamX 会自动维护任务 Checkpoint 的目录及版本至系统中方便检索

• 当用户需要更新重启应用时，可以选择是否保存 Savepoint

• 重新启动任务时可选择 Checkpoint/Savepoint 从指定版本的恢复

如下，开发同学能够非常直观方便的升级或处理异常任务，非常强大

Savepoint/Checkpoint 管理 

从 Savepoint 恢复启动 

7.完善的报警功能

对于流式计算此类7*24H常驻任务来说，监控报警是非常重要的 ，StreamX 对于此类问题也有完善的解决方案:

• 自带基于邮件的报警方式，0开发成本，配置即可使用

• 得益于 StreamX 源码优秀的模块化，可以在 Task Track 处进行代码增强，引入公司内部的 SDK 进行电话、群组等报警方式，开发成本也非常低

告警邮件 

  2. 源码优秀  

遵循技术选型原则，一个新的技术必须足够了解底层原理和架构思想后，才会考虑应用生产。在选择 StreamX 之前，对其架构和源码进入过深入研究和阅读。发现 StreamX 所选用的底层技术是国人非常熟悉的：MySQL、Spring Boot、Mybatis Plus、Vue 等，代码风格统一，实现优雅，注释完善，各模块独立抽象合理，使用了较多的设计模式，且代码质量很高，非常适合后期的排错及二次开发。

 部分源码解读笔记 

StreamX 于 2021年11月成功被开源中国评选为GVP - Gitee「最有价值开源项目」，足以见得其质量和潜力。

 3.  社区活跃  

目前社区非常活跃，从2021年11月底落地 StreamX (基于1.2.0-release），当时StreamX 刚刚才被大家认识，还有一些体验上的小 Bug（不影响核心功能）。当时为了快速上线，屏蔽掉了一些功能和修复了一些小 Bug，正当准备贡献给社区时发现早已修复，这也可以看出目前社区的迭代周期非常快。以后我们公司团队也会努力和社区保持一致，将新特性快速落地，提升数据开发效率和降低维护成本。

二. 落地实践

StreamX 的环境搭建非常简单，跟随官网的搭建教程可以在小时内完成搭建。目前已经支持了前后端分离打包部署的模式，可以满足更多公司的需求，而且已经有 Docker Build 相关的 PR，相信以后 StreamX 的编译部署会更加方便快捷。相关文档如下:

平台部署 | StreamXStreamX 总体组件栈架构如下， 由 streamx-core 和 streamx-console 两个大的部分组成 , streamx-console 是一个非常重要的模块, 定位是一个综合实时数据平台，流式数仓平台, 低代码 ( Low Code ), Flink & Spark 任务托管平台，可以较好的管理 Flink 任务，集成了项目编译、发布、参数配置、启动、savepoint，火焰图 ( flame graph )，Flink SQL，监控等诸多功能于一体，大大简化了 Flink 任务的日常操作和维护，融合了诸多最佳实践。其最终目标是打造成一个实时数仓，流批一体的一站式大数据解决方案http://www.streamxhub.com/docs/user-guide/deployment

为了快速落地和生产使用，我们选择了稳妥的 On Yarn 资源管理模式（虽然 StreamX 已经很完善的支持 K8S），且已经有较多公司通过 StreamX 落地了 K8S 部署方式，大家可以参考: 

Flink开发利器StreamX | StreamXhttp://www.streamxhub.com/blog/flink-development-framework-streamx

StreamX 整合 Hadoop 生态可以说是0成本的（前提是按照 Flink 官网将 Flink 与  Hadoop 生态整合，能够通过 Flink 脚本启动任务即可）

目前我们也正在进行 K8S 的测试及方案设计，在未来一段时间会整体迁移至 K8S

1. 落地 FlinkSQL 任务

目前我们公司基于 Flink SQL 的任务主要为业务比较简单的实时 ETL 和计算场景，数量在10个左右，上线至今都十分稳定。

线上 FlinkSQL 任务 

StreamX 非常贴心的准备了 Demo SQL 任务，可以直接在刚搭建的平台上运行，从这些细节可以看出社区对用户体验非常重视。前期我们的简单任务都是通过 Flink SQL 来编写及运行，StreamX 对于 Flink SQL 的支持得非常好，优秀的 SQL 编辑器，创新型的 POM 及 Jar 包依赖管理，可以满足非常多的 SQL 场景下的问题。

目前我们正在进行元数据层面、权限、UDF等相关的方案调研、设计等

2. 落地 Jar 任务

由于目前团队的数据开发同学大多有 Java 和 Scala 语言基础，为了更加灵活的开发、更加透明的调优 Flink 任务及覆盖更多场景，我们也快速的落地了基于 Jar 包的构建方式。我们落地分为了两个阶段

第一阶段：StreamX 提供了原生 Apache Flink 项目的支持，我们将存量的任务Git地址配置至 StreamX，底层使用 Maven 打包为 Jar 包，创建 StreamX 的 Apache Flink任务，无缝的进行了迁移。在这个过程中，StreamX 只是作为了任务提交和状态维护的一个平台工具，远远没有使用到上面提到的其他功能。

第二阶段：第一阶段将任务都迁移至 StreamX 上之后，任务已经在平台上运行，但是任务的配置，如 checkpoint，容错以及 Flink 任务内部的业务参数的调整都需要修改源码 push 及 build，效率十分低下且不透明。

于是，根据 StreamX 的 QuickStart 我们快速整合了StreamX 的编程模型，也就是StreamX Flink 任务（对于 Apache Flink）的封装。

如：

StreamingContext = ParameterTool + StreamExecutionEnvironment

• StreamingContext 为 StreamX 的封装对象 

• ParameterTool 为解析配置文件后的参数对象 

String value = ParameterTool.get("${user.custom.key}") 

• StreamExecutionEnvironment 为 Apache Flink 原生任务上下文

三. 业务支撑

目前尘锋基于 StreamX 的实时计算平台从去年11月底上线至今，已经上线 50+ Flink 任务，其中 10+为 Flink SQL 任务，40+ 为 Jar 任务。目前主要还是数据团队内部使用，近期会将实时计算平台开放全公司业务团队使用，任务量会大量增加。 

 线上 Jar类型 任务 

1. 实时数仓

实时数仓主要是用 Jar 任务，因为模式比较通用，使用 Jar 任务可以通用化的处理大量的数据表同步和计算，甚至做到配置化同步等，我们的实时数仓主要基 Apache Doris 来存储，使用 Flink 来进行清洗计算（目标是存算分离）

使用 StreamX 整合其他组件也是非常简单，同时我们也将 Apache Doris 和 Kafka 相关的配置也抽象到了配置文件中，大大提升了我们的开发效率和灵活度。

2. 能力开放

数据团队外的其他业务团队也有很多的流处理场景，于是我们将基于 StreamX 的实时计算平台二次开发后，将以下能力开放全公司业务团队

• 业务能力开放：实时数仓上游将所有业务表通过日志采集写入 Kafka，业务团队可基于 Kafka 进行业务相关开发，也可通过实时数仓（Apache Doris）进行 OLAP分析

• 计算能力开放：将大数据平台的服务器资源开放业务团队使用

• 解决方案开放：Flink 生态的成熟 Connector、Exactly Once 语义支持，可减少业务团队流处理相关的开发成本及维护成本

目前 StreamX 还不支持多业务组功能，多业务组功能会抽象后贡献社区。  

二开的团队管理模块 

二开的任务检索 

四. 未来规划

1. Flink on K8S

目前我司 Flink 任务都运行在 Yarn 上，满足当下需求，但 Flink on kubernetes 有以下优点:

• 统一运维。公司统一化运维，有专门的部门运维 K8S

• CPU 隔离。K8S Pod 之间 CPU 隔离，实时任务不相互影响，更加稳定

• 存储计算分离。Flink 计算资源和状态存储分离，计算资源能够和其他组件资源进行混部，提升机器使用率

• 弹性扩缩容。能够弹性扩缩容，更好的节省人力和物力成本

目前本人也在整理和落地相关的技术架构及方案，并已在实验环境使用 StreamX 完成了 Flink on kubernetes 的技术验证，生产落地这一目标由于有 StreamX 的平台支持，以及社区同学的热心帮心，相信在未来不久就能达成。

2.流批一体建设

个人认为批/流最大的区别在于算子 Task 的调度策略 和 数据在算子间的流转策略：

• 批处理上下游算子 Task 存在先后调度（上游Task结束释放资源），数据存在 Shuffle 策略（落地磁盘），缺点是时效性较低且计算无中间状态，但优点是吞吐量大，适合离线超大数据量计算。

• 流处理上下游算子 Task 同时拉起（同时占用资源），数据通过网络在节点间流式计算，缺点是吞吐量不足，优点是时效性高及计算有中间状态，适合实时及增量计算场景。

如上，个人认为选择批处理还是流处理，是数据开发针对不同数据量和不同业务场景的一种调优方式。但目前由于计算引擎和计算平台会将离线、实时区分，会造成开发及维护的撕裂，成本巨高不下。如果要实现批流一体，要实现以下几个方面：

• 存储的统一（元数据的统一）：支持批及流的写入/读取

• 计算引擎的统一 ：能够使用一套 API 或 SQL 开发离线和实时任务

• 数据平台的统一 ：能够支持实时任务常驻，也能支持离线调度策略

关于批流统一这一块，目前也正在调研、整理、感兴趣的小伙伴欢迎一块探讨项目学习。

五. 结束语

以上就是 StreamX 在尘锋信息生产实践的全部分享内容，感谢大家看到这里。