为什么选择 Native Kubernetes​

Native Kubernetes 具有以下优势：

• 更短的 Failover 时间
• 可以实现资源托管，不需要手动创建 TaskManager 的 Pod，可以自动完成销毁
• 具有更加便捷的 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 on Native Kubernetes 模式部署 Flink 任务。

当 Flink On Kubernetes 遇见 Apache StreamPark™​

Flink on Native Kubernetes 目前支持 Application 模式和 Session 模式，两者对比 Application 模式部署规避了 Session 模式的资源隔离问题、以及客户端资源消耗问题，因此**生产环境更推荐采用 Application Mode 部署 Flink 任务。**下面我们分别看看使用原始脚本的方式和使用 StreamPark 开发部署一个 Flink on Native Kubernetes 作业的流程。

使用脚本方式部署Kubernetes​

在没有一个支持 Flink on Kubernetes 任务开发部署的平台的情况下，需要使用脚本的方式进行任务的提交和停止，这也是 Flink 提供的默认的方式，具体步骤如下:

1. 在 Flink 客户端节点准备 kubectl 和 Docker 命令运行环境，创建部署 Flink 作业使用的 Kubernetes Namespace 和 Service Account 以及进行 RBAC
2. 编写 Dockerfile 文件，将 Flink 基础镜像和用户的作业 Jar 打包到一起

FROM flink:1.13.6-scala_2.11
RUN mkdir -p $FLINK_HOME/usrlib
COPY my-flink-job.jar $FLINK_HOME/usrlib/my-flink-job.jar

3. 使用 Flink 客户端脚本启动 Flink 任务

./bin/flink run-application \
    --target kubernetes-application \
    -Dkubernetes.namespace=flink-cluster \
    -Dkubernetes.jobmanager.service-account=default \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=relx_docker_url/streamx/relx_flink_1.13.6-scala_2.11:latest \
    -Dkubernetes.rest-service.exposed.type=NodePort \
    local:///opt/flink/usrlib/my-flink-job.jar

4. 使用 Kubectl 命令获取到 Flink 作业的 WebUI 访问地址和 JobId

kubectl -n flink-cluster get svc

5. 使用Flink命令停止作业

./bin/flink cancel
    --target kubernetes-application
    -Dkubernetes.cluster-id=my-first-application-cluster
    -Dkubernetes.namespace=flink-cluster <jobId>

以上就是使用 Flink 提供的最原始的脚本方式把一个 Flink 任务部署到 Kubernetes 上的过程，只做到了最基本的任务提交，如果要达到生产使用级别，还有一系列的问题需要解决，如：方式过于原始无法适配大批量任务、无法记录任务checkpoint 和实时状态跟踪、任务运维和监控困难、无告警机制、 无法集中化管理等等。

使用 Apache StreamPark™ 部署 Flink on Kubernetes​

对于企业级生产环境使用 Flink on Kubernetes 会有着更高的要求，一般会选择自建平台或者购买相关商业产品，不论哪种方案在产品能力上满足: 大批量任务开发部署、状态跟踪、运维监控、失败告警、任务统一管理、高可用性 等这些是普遍的诉求。

针对以上问题我们调研了开源领域支持开发部署 Flink on Kubernetes 任务的开源项目，调研的过程中也不乏遇到了其他优秀的开源项目，在综合对比了多个开源项目后得出结论: **StreamPark 不论是完成度还是使用体验、稳定性等整体表现都非常出色，因此最终选择了 StreamPark 作为我们的一站式实时计算平台。**下面我们看看 StreamPark 是如何支持 Flink on Kubernetes :

基础环境配置​

基础环境配置包括 Kubernetes 和 Docker 仓库信息以及 Flink 客户端的信息配置。对于 Kubernetes 基础环境最为简单的方式是直接拷贝 Kubernetes 节点的 .kube/config 到 StreamPark 节点用户目录，之后使用 kubectl 命令创建 Flink 专用的 Kubernetes Namespace 以及进行 RBAC 配置。

# 创建Flink作业使用的k8s namespace
kubectl create ns flink-cluster
# 对default用户进行RBAC资源绑定
kubectl create clusterrolebinding flink-role-binding-default --clusterrole=edit --serviceaccount=flink-cluster:default

Docker 账户信息直接在 Docker Setting 界面配置即可：

StreamPark 可适配多版本 Flink 作业开发，Flink 客户端直接在 StreamPark Setting 界面配置即可：

作业开发​

StreamPark 做好基础环境配置之后只需要三步即可开发部署一个 Flink 作业:

StreamPark 既支持 Upload Jar 也支持直接编写 Flink SQL 作业, Flink SQL 作业只需要输入SQL 和 依赖项即可, 该方式大大提升了开发体验, **并且规避了依赖冲突等问题，**对此部分本文不重点介绍。

这里需要选择部署模式为 kubernetes application, 并且需要在作业开发页面进行以下参数的配置：红框中参数为 Flink on Kubernetes 基础参数。

下面参数为 Flink 作业和资源相关的参数，Resolve Order 的选择与代码加载模式有关，对于 DataStream API 开发的 Upload Jar上传的作业选择使用 Child-first，Flink SQL 作业选择使用 Parent-first 加载。

最后就是下面这两个重量级参数了，对于 Native Kubernetes 而言，k8s-pod-template 一般只需要进行 pod-template 配置即可，Dynamic Option 是 pod-template 参数的补充，对于一些个性化配置可以在 Dynamic Option 中配置。更多 Dynamic Option 直接参考 Flink 官网即可。

作业上线​

作业开发完成之后是作业上线环节，在这一环节中 StreamPark 做了大量的工作，具体如下:

• 准备环境
• 作业中的依赖下载
• 构建作业(打JAR包)
• 构建镜像
• 推送镜像到远程仓库

对于用户来说: 只需要点击任务列表中的云状的上线按钮即可。

在镜像构建和推送的时候我们可以看到 StreamPark 做的一系列工作: 读取配置、构建镜像、推送镜像到远程仓库... 这里要给StreamPark 一个大大的赞！

作业提交​

最后只需要点击 Operation 里 start Application 按钮便可启动一个 Flink on Kubernetes 作业，作业启动成功之后点击作业名便可跳转到 Jobmanager WebUI 页面、整个过程非常简单丝滑。

整个过程仅需上述三步，即可完成在 StreamPark 上开发和部署一个Flink on Kubernetes 作业。而 StreamPark 对于 Flink on Kubernetes 的支持远远不止提交个任务这么简单。

作业管理​

在作业提交之后，StreamPark 能实时获取到任务的最新 checkpoint 地址、任务的运行状态、集群实时的资源消耗信息，针对运行的任务可以非常方便的一键启停, 在停止作业时支持记录 savepoint 的位置, 以及再次启动时从 savepoint 恢复状态等功能，从而保证了生产环境的数据一致性，真正具备 Flink on Kubernetes 的 一站式开发、部署、运维监控的能力。

接下来我们来看看这一块的能力 StreamPark 是如何进行支持的:

• 实时记录checkpoint

在作业提交之后，有时候需要更改作业逻辑但是要保证数据的一致性，那么就需要平台具有实时记录每一次 checkpoint 位置的能力, 以及停止时记录最后的 savepoint 位置的能力，StreamPark 在 Flink on Kubernetes 上很好的实现了该功能。默认会每隔5秒获取一次 checkpoint 信息记录到对应的表中，并且会按照 Flink 中保留 checkpoint 数量的策略，只保留 state.checkpoints.num-retained 个，超过的部分则删除。在任务停止时有勾选 savepoint 的选项，如勾选了savepoint 选项，在任务停止时会做 savepoint 操作，同样会记录 savepoint 具体位置到表中。

默认 savepoint 的根路径只需要在 Flink Home flink-conf.yaml 文件中配置即可自动识别，除了默认地址，在停止时也可以自定义指定 savepoint 的根路径。

• 实时跟踪运行状态

对于生产环境的挑战，很重要的一点就是监控是否到位，Flink on Kubernetes 更是如此。这点很重要, 也是最基本需要具备的能力，StreamPark 可实时监控 Flink on Kubernetes 作业的运行状态并在平台上展示给用户，在页面上可以很方便的根据各种运行状态来检索任务。

• 完善的告警机制

除此之外 StreamPark 还具备完善的报警功能: 支持邮件、钉钉、微信和短信 等。这也是当初公司调研之后选择 StreamPark 作为 Flink on Kubernetes 一站式平台的重要原因。

通过以上我们看到 StreamPark 在支持 Flink on Kubernetes 开发部署过程中具备的能力, 包括：作业的开发能力、部署能力、监控能力、运维能力、异常处理能力等，StreamPark 提供的是一套相对完整的解决方案。 且已经具备了一些 CICD/DevOps 的能力，整体的完成度还在持续提升。是在整个开源领域中对于 Flink on Kubernetes 一站式开发部署运维工作全链路都支持的产品，StreamPark 是值得被称赞的。

Apache StreamPark™ 在雾芯科技的落地实践​

StreamPark 在雾芯科技落地较晚，目前主要用于实时数据集成作业和实时指标计算作业的开发部署，有 Jar 任务也有 Flink SQL 任务，全部使用 Native Kubernetes 部署；数据源有CDC、Kafka 等，Sink 端有 Maxcompute、kafka、Hive 等，以下是公司开发环境StreamPark 平台截图：

遇到的问题​

任何新技术都有探索与踩坑的过程，失败的经验是宝贵的，这里介绍下 StreamPark 在雾芯科技落地过程中踩的一些坑和经验，这块的内容不仅仅关于 StreamPark 的部分, 相信会带给所有使用 Flink on Kubernetes 的小伙伴一些参考。

常见问题总结如下​

• kubernetes pod 拉取镜像失败

这个问题主要在于 Kubernetes pod-template 缺少 docker的 imagePullSecrets

• scala 版本不一致

由于 StreamPark 部署需要 Scala 环境，而且 Flink SQL 运行需要用到 StreamPark 提供的 Flink SQL Client，因此一定要保证 Flink 作业的 Scala 版本和 StreamPark 的 Scala 版本保持一致。

• 注意类冲突

进行 Flink SQL 作业开发的时候需要注意 Flink 镜像和 Flink connector 及 UDF 中有没有类冲突，最好的避免类冲突的办法是将 Flink 镜像和常用的 Flink connector 及用户 UDF 打成一个可用的基础镜像，之后其他 Flink SQL 作业直接复用即可。

• 没有 Hadoop 环境怎么存储 checkpoint?

HDFS 阿里云 OSS/AWS S3 都可以进行 checkpoint 和 savepoint 存储，Flink 基础镜像已经有了对于 OSS 和 S3 的支持，如果没有 HDFS 可以使用阿里云 OSS 或者 S3存储状态和 checkpoint 和 savepoint 数据，只需要在 Flink 动态参数中简单配置一下即可。

-Dstate.backend=rocksdb
-Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-oss-fs-hadoop-1.13.6.jar
-Dcontainerized.taskmanager.env.ENABLE_BUILT_IN_PLUGINS=flink-oss-fs-hadoop-1.13.6.jar
-Dfs.oss.endpoint=xxyy.aliyuncs.com
-Dfs.oss.accessKeyId=xxxxxxxxxx
-Dfs.oss.accessKeySecret=xxxxxxxxxx
-Dstate.checkpoints.dir=oss://realtime-xxx/streamx/dev/checkpoints/
-Dstate.savepoints.dir=oss://realtime-xxx/streamx/dev/savepoints/

• 改了代码重新发布后并未生效

该问题与 Kubernetes pod 镜像拉取策略有关，建议将 Pod 镜像拉取策略设置为 Always：

‍-Dkubernetes.container.image.pull-policy=Always

• 任务每次重启都会导致多出一个 Job 实例

在配置了基于 kubernetes 的HA的前提条件下，当需要停止 Flink 任务时，需要通过 StreamPark 的 cancel 来进行，不要直接通过 kubernetes 集群删除 Flink 任务的 Deployment。因为 Flink 的关闭有其自有的关闭流程，在删除 pod 同时 Configmap 中的相应配置文件也会被一并删除，而直接删除 pod 会导致 Configmap 的残留。当相同名称的任务重启时，会出现两个相同 Job 现象，因为在启动时，任务会加载之前残留的配置文件，尝试将已经关闭的任务恢复。

• kubernetes pod 域名访问怎么实现

域名配置只需要按照 Kubernetes 资源在 pod-template 中配置即，可针对以上问题给大家分享一个本人总结的一个 pod-template.yaml 模板：

apiVersion: v1
kind: Pod
metadata:
  name: pod-template
spec:
  serviceAccount: default
  containers:
  - name: flink-main-container
    image:
  imagePullSecrets:
  - name: regsecret
  hostAliases:
    - ip: "192.168.0.1"
      hostnames:
      - "node1"
    - ip: "192.168.0.2"
      hostnames:
      - "node2"
    - ip: "192.168.0.3"
      hostnames:
      - "node3"

最佳实践​

悦刻的大数据组件很多基于阿里云，比如 Maxcompute、阿里云 Redis，同时我们这边 Flink SQL 作业需要用到一些 UDF。最开始我们是采用使用 Flink Base image + maven dependency + upload udf jar 的方式，但是实践过程中遇到了一些比如版本冲突、类冲突的问题，同时如果是大批量作业的话这种方式开发效率比较低，最后我们采取将公司级别的常用的 Flink connector 和 udf 和 Flink base image 打包成公司级别的基础镜像，新 Flink SQL 作业使用该基础镜像之后直接写 Flink SQL 即可，大大提高了开发效率。

下面分享一个制作基础镜像的简单步骤：

1. 准备需要的 JAR

将常用 Flink Connector Jar 和用户 Udf Jar 放置在同一文件夹 lib 下，以下都是Flink 1.13.6 常用的一些 connector 包

bigdata-udxf-1.0.0-shaded.jar
flink-connector-jdbc_2.11-1.13.6.jar
flink-sql-connector-kafka_2.11-1.13.6.jar
flink-sql-connector-mysql-cdc-2.0.2.jar
hudi-flink-bundle_2.11-0.10.0.jar
ververica-connector-odps-1.13-vvr-4.0.7.jar
ververica-connector-redis-1.13-vvr-4.0.7.jar

2. 准备 Dockerfile

创建 Dockerfile 文件，并将 Dockerfile 文件跟上面文件夹放置在同一文件夹下

FROM flink:1.13.6-scala_2.11COPY lib $FLINK_HOME/lib/

3. 基础镜像制作并推送私有仓库

docker login --username=xxxdocker \
build -t udf_flink_1.13.6-scala_2.11:latest \
.docker tag udf_flink_1.13.6-scala_2.11:latest \
k8s-harbor.xxx.com/streamx/udf_flink_1.13.6-scala_2.11:latestdocker \
push k8s-harbor.xxx.com/streamx/udf_flink_1.13.6-scala_2.11:latest

未来期待​

• StreamPark 对于 Flink 作业 Metric 监控的支持

StreamPark 如果可以对接 Flink Metric 数据而且可以在 StreamPark 平台上展示每时每刻 Flink 的实时消费数据情况就太棒了

• StreamPark 对于Flink 作业日志持久化的支持

对于部署到 YARN 的 Flink 来说，如果 Flink 程序挂了，我们可以去 YARN 上看历史日志，但是对于 Kubernetes 来说，如果程序挂了，那么 Kubernetes 的 pod 就消失了，就没法查日志了。所以用户需要借助 Kubernetes 上的工具进行日志持久化，如果 StreamPark 支持 Kubernetes 日志持久化接口就更好了。

• 镜像过大的问题改进

StreamPark 目前对于 Flink on Kubernetes 作业的镜像支持是将基础镜像和用户代码打成一个 Fat 镜像推送到 Docker 仓库，这种方式存在的问题就是镜像过大的时候耗时比较久，希望未来基础镜像可以复用不需要每次都与业务代码打到一起，这样可以极大地提升开发效率和节约成本。

Hadoop 体系虽然在目前应用非常广泛，但架构繁琐、运维复杂度过高、版本升级困难，且由于部门原因，数据中台需求排期较长，我们急需探索敏捷性开发的数据平台模式。在目前云原生架构的普及和湖仓一体化的大背景下，我们已经确定了将 Doris 作为离线数据仓库，将 TiDB（目前已经应用于生产）作为实时数据平台，同时因为 Doris 具有 on MySQL 的 ODBC 能力，所以又可以对外部数据库资源进行整合，统一对外输出报表

Hadoop 体系虽然在目前应用非常广泛，但架构繁琐、运维复杂度过高、版本升级困难，且由于部门原因，数据中台需求排期较长，我们急需探索敏捷性开发的数据平台模式。在目前云原生架构的普及和湖仓一体化的大背景下，我们已经确定了将 Doris 作为离线数据仓库，将 TiDB（目前已经应用于生产）作为实时数据平台，同时因为 Doris 具有 on MySQL 的 ODBC 能力，所以又可以对外部数据库资源进行整合，统一对外输出报表

2. 遇到的问题

在数据引擎上，我们确定使用 Spark 和 Flink

• 使用 Spark on K8s client 客户端模式做离线数据处理
• 使用 Flink on K8s Native-Application/Session 模式做实时任务流管理

在这里，实际上有一些问题我们一直没有彻底解决：

用过 Native-Application 模式的朋友都知道，每提交一个任务，都需要打包新的镜像，提交到私有仓库，然后再调用 Flink Run 指令沟通 K8s，去拉取镜像运行 Pod。任务提交之后，还需要去 K8s 查看 log，但是：

1. 任务运行监控怎么处理？
2. 使用 Cluster 模式还是 NodePort 暴露端口访问 Web UI？
3. 提交任务能否简化打包镜像的流程?
4. 如何减少开发压力？

3. 解决问题的过程

以上的这些其实都是需要解决的问题，如果单纯地使用命令行去提交每个任务，是不现实的，任务量大了，会变得不可维护。如何解决这些问题变成一个不得不面对的问题。

简化镜像构建​

首先，针对 Flink 原生镜像需要二次 build 的问题：我们利用了 MinIO 作为外部存储，并使用 s3-fuse 通过 DaemonSet 的方式直接挂载在了每个宿主节点上，我们所需要提交的 jar 包都可以放到上面统一管理。这样的话，即使扩缩容 Flink 节点，也能实现 S3 挂载自动伸缩。

Flink 从 1.13 版本开始，就支持 Pod Template，我们可以在 Pod Template 中利用数据卷挂载的方式再将宿主机目录挂载到每个 pod 中，从而无需镜像打包而直接在 K8s 上运行 Flink 程序。如上图，我们将 S3 先通过 s3-fuse Pod 挂载在 Node 1、Node 2 的 /mnt/data-s3fs 目录下，然后再将 /mnt/data-s3fs 挂载到 Pod A 中。

但是，因为对象存储随机写入或追加文件需要重写整个对象，导致这种方式仅适合于频繁读。而这刚好满足我们现在的场景。

引入 Apache StreamPark™​

之前我们写 Flink SQL 基本上都是使用 Java 包装 SQL，打 jar 包，提交到 S3 平台上。通过命令行方式提交代码，但这种方式始终不友好，流程繁琐，开发和运维成本太大。我们希望能够进一步简化流程，将 Flink TableEnvironment 抽象出来，有平台负责初始化、打包运行 Flink 任务，实现 Flink 应用程序的构建、测试和部署自动化。

这是个开源兴起的时代，我们自然而然的将目光投向开源领域中：在一众开源项目中，经过对比各个项目综合评估发现 Zeppelin 和 StreamPark 这两个项目对 Flink 的支持较为完善，都宣称支持 Flink on K8s ，最终进入到我们的目标选择范围中，以下是两者在 K8s 相关支持的简单比较（目前如果有更新，麻烦批评指正）。

调研过程中，我们与两者的主开发人员都进行了多次沟通。经过我们反复研究之后，还是决定将 StreamPark 作为我们目前的 Flink 开发工具来使用。

经过开发同学长时间开发测试，StreamPark 目前已经具备：

• 完善的SQL 校验功能
• 实现了自动 build/push 镜像
• 使用自定义类加载器，通过 Child-first 加载方式 解决了 YARN 和 K8s 两种运行模式、支持了自由切换 Flink 多版本
• 与 Flink-Kubernetes 进行深度整合，提交任务后返回 WebUI，通过 remote rest api + remote K8s，追踪任务执行状态
• 同时支持了 Flink 1.12、1.13、1.14 等版本

以上基本解决了我们目前开发和运维中存在的大部分问题。

在目前最新发布的 1.2.0 版本中，StreamPark 较为完善地支持了 K8s-Native-Application 和 K8s-Session-Application 模式。

K8s Native Application 模式​

在 StreamPark 中，我们只需要配置相应的参数，并在 Maven POM 中填写相应的依赖，或者上传依赖 jar 包，点击 Apply，相应的依赖就会生成。这就意味着我们也可以将所有使用的 UDF 打成 jar 包，以及各种 connector.jar，直接在 SQL 中使用。如下图:

SQL 校验能力和 Zeppelin 基本一致:

我们也可以指定资源，指定 Flink Run 中的动态参数 Dynamic Option，甚至参数可以整合 Pod Template

程序保存后，点击运行时，也可以指定 savepoint。任务提交成功后，StreamPark 会根据 FlinkPod 网络 Exposed Type（loadBalancer/NodePort/ClusterIp），返回相应的 WebURL，从而自然的实现 WebUI 跳转。但是，目前因为线上私有 K8s 集群出于安全性考虑，尚未打通 Pod 与客户端节点网络（目前也没有这个规划）。所以么，我们只使用 NodePort。如果后续任务数过多，有使用 ClusterIP 的需求的话，我们可能会将 StreamPark 部署在 K8s，或者同 Ingress 做进一步整合。

注意：K8s master 如果使用 vip 做均衡代理的情况下，Flink 1.13 版本会返回 vip 的 ip 地址，在 1.14 版本中已经修复该问题。

下面是 K8s Application 模式下具体提交流程

K8s Native Session 模式​

StreamPark 还较好地支持了 K8s Native-Sesson 模式，这为我们后续做离线 FlinkSQL 开发或部分资源隔离做了较好的技术支持。

Native-Session 模式需要事先使用 Flink 命令创建一个运行在 K8s 中的 Flink 集群。如下：

./kubernetes-session.sh \
-Dkubernetes.cluster-id=flink-on-k8s-flinkSql-test \
-Dkubernetes.context=XXX \
-Dkubernetes.namespace=XXXX \
-Dkubernetes.service-account=XXXX \
-Dkubernetes.container.image=XXXX \
-Dkubernetes.container.image.pull-policy=Always \
-Dkubernetes.taskmanager.node-selector=XXXX \
-Dkubernetes.rest-service.exposed.type=Nodeport

如上图，使用该 ClusterId 作为 StreamPark 的任务参数 Kubernetes ClusterId。保存提交任务后，任务会很快处于 Running 状态：

我们顺着 application info 的 WebUI 点击跳转：

可以看到，其实 StreamPark 是将 jar 包通过 REST API 上传到 Flink 集群上，并调度执行任务的。

Custom Code 模式​

另我们惊喜的是，StreamPark 还支持代码编写 DataStream/FlinkSQL 任务。对于特殊需求，我们可以自己写 Java/Scala 实现。可以根据 StreamPark 推荐的脚手架方式编写任务，也可以编写一个标准普通的 Flink 任务，通过这种方式我们可以将代码管理交由 git 实现，平台可以用来自动化编译打包与部署。当然，如果能用 SQL 实现的功能，我们会尽量避免自定义 DataStream，减少不必要的运维麻烦。

4. 意见和规划

改进意见​

当然 StreamPark 还有很多需要改进的地方，就目前测试来看：

• 资源管理还有待加强：多文件系统jar包等资源管理功能尚未添加，任务版本功能有待加强。
• 前端 button 功能还不够丰富：比如任务添加后续可以增加复制等功能按钮。
• 任务提交日志也需要可视化展示：任务提交伴随着加载 class 文件，打 jar 包，build 镜像，提交镜像，提交任务等过程，每一个环节出错，都会导致任务的失败，但是失败日志往往不明确，或者因为某种原因导致异常未正常抛出，没有转换任务状态，用户会无从下手改进。

众所周知，一个新事物的出现一开始总会不是那么完美。尽管有些许问题和需要改进的 point，但是瑕不掩瑜，我们仍然选择 StreamPark 作为我们的 Flink DevOps，我们也将会和主开发人员一道共同完善 StreamPark，也欢迎更多的人来使用，为 StreamPark 带来更多进步。

未来规划​

• 我们会继续跟进 Doris，并将业务数据 + 日志数据统一入 Doris，通过 Flink 实现湖仓一体；
• 我们也会逐步将探索 StreamPark 同 DolphinScheduler 2.x 进行整合，完善DolphinScheduler 离线任务，逐步用 Flink 替换掉 Spark，实现真正的流批一体；
• 基于我们自身在 S3 上的探索积累，fat-jar 包 build 完成之后不再构建镜像，直接利用 Pod Tempelet 挂载 PVC 到 Flink Pod 中的目录，进一步优化代码提交流程；
• 将 StreamPark 持续应用到我们生产中，并汇同社区开发人员，共同努力，增强 StreamPark 在 Flink 流上的开发部署能力与运行监控能力，努力把 StreamPark 打造成一个功能完善的流数据 DevOps。

附：

StreamPark GitHub：https://github.com/apache/streampark
Doris GitHub：https://github.com/apache/doris

导读：本文主要介绍了自如 MySQL 数据迁移至 Hive 的架构升级演进，原有架构涉及到的组件众多，链路复杂，遇到很多挑战，在使用 StreamPark + Paimon 这套组合方案后有效地解决了数据集成中遇到的困境和挑战，分享了 StreamPark + Paimon 在实际应用中具体的实践方案，以及这套新秀组合方案带来的优势和收益。

StreamPark: https://github.com/apache/streampark

Paimon: https://github.com/apache/paimon

欢迎关注、Star、Fork，参与贡献

供稿单位｜北京自如信息科技有限公司

文章作者｜刘涛、梁研生、魏林子

文章整理｜杨林伟

内容校对｜潘月鹏

1.数据集成业务背景​

自如租房业务的数据集成场景主要来源于各业务线的 MySQL 表同步到 Hive 表的需求。这一需求包含了每天同步的 MySQL 业务表数量超过 4400 个，以及超过 8000 多个的 Hive ETL 加工任务，每天新产生数据量有 50T，而且这些数字还在不断增长。根据数据的新鲜度需求分为低新鲜度（T+1 day）和高新鲜度（T+10 minutes）两种，每天同步调度 4000 多个低新鲜度数据表，以及每天同步调度 400 多个高新鲜度数据表，用以确保数据的及时性和准确性。

自如的数据集成方案根据业务使用场景主要可分为两种：

• 低新鲜度：低新鲜度对数据的时效性要求是 T+1day，每日定时凌晨 00:00 采用 Hive jdbc handler 进行 MySQL 数据的全量拉取至 Hive，其基本流程如下图所示：

  

• 高新鲜度：此场景中要求数据实效性是 T+10minutes，我们复用了低新鲜度场景的快照拉取方法来实现全量数据的获取，并且初始化至 MySQL，同步利用 Canal 解析日志收集到 Kafka，然后使用 Flink 读取 kafka 中的数据并写入到 HDFS，最后用 Airflow 进行调度以合并增量数据至 Hive，其基本逻辑如下所示：

  

然而，当前架构存在着多方面的挑战和压力。首先是运维成本高昂，其次是计算压力、存储压力和网络压力都非常大。另外，虽然系统运行时间从 0:00 到 1:00 期间资源利用不充分，但其他时间段却面临着资源不足的情况。对此自如决定更新数据集成架构以提高系统的效率和稳定性。

2.遇到的挑战​

在上述的两种场景中，我们在数据集成过程中遇到了以下挑战：

• 网络带宽超负荷问题：由于拉取任务达到 4000+，过多的镜像全量数据拉取对数据库网络带宽产生了巨大压力。

• 资源利用率低效：上游数据从 MySQL 同步到 ODS 层表后，下游的加工表才能启动，导致在 0:00 到 1:00 之间，Hadoop 集群的 CPU 和内存资源并未得到充分利用。

• 维护成本高昂：当数据库表结构发生改变时，需要同步修改 Airflow 脚本。否则，会出现不完整的字段，引起线上数据异常问题。

• 问题排查困难：数据链路较长，当出现数据异常时，问题排查成本较高，问题可能出现在 Canal、Kafka、Flink、Airflow 调度中的任何一个环节，导致问题恢复时间长。

• Flink 作业难以统一管理：Flink 本身没有提供很好的部署和开发能力，在 Flink 任务数量增多后，管理和维护的时间成本也随之上升。

为了解决上述问题，我们经过一系列调研后，决定采用 “StreamPark+Paimon” 的策略，那么选择它们的原因是什么呢？我们可以先看看它们的特性。

Paimon 的核心特性​

在经过对 Apache Hudi / Iceberg / Paimon 几个数据湖框架的调研和综合评估之后，我们决定使用 Apache Paimon，Apache Paimon 是一项流式数据湖存储技术，可以为用户提供高吞吐低延时的数据摄入，流式订阅和实时查询能力，支持使用 Flink 和 Spark 构建实时 Lakehouse 架构，支持批/流数据处理操作，创新性地将 Lake 格式与 LSM 结构相结合，将实时流式更新引入 Lake 架构中，具有以下优点：

• 统一的批处理和流处理：Paimon 支持批量写入、批量读取和流式操作，提供了灵活的数据处理方式。

• 数据湖功能：作为数据湖存储系统，Paimon 具有低成本、高可靠性和可扩展的元数据等特性。

• 丰富的合并引擎：Paimon 提供了多种合并引擎，可以根据需求选择保留最新数据、进行局部更新或进行聚合操作。

• 自动生成变更日志：Paimon 支持多种 Changelog 生产者，能够自动生成正确完整的变更日志，简化流式任务分析。

• 丰富的表类型：Paimon 支持主键表和仅追加表，以及多种表类型，如内部表、外部表、分区表和临时表。

• 支持表结构变更同步：当数据源表结构发生变化时，Paimon 能自动识别并同步这些变化。

Paimon 可以结合 Apache Spark™ 来使用，我们场景是 Paimon 结合 Flink 的方式，这样一来 “如何管理 4000+个 Flink 数据同步作业” 将会是我们面临的新问题。在全面调研了相关项目，经过各项维度综合评估后，我们决定采用 StreamPark，那么为什么选择 StremaPark 呢？

StreamPark 的核心特性​

Apache StreamPark 是一个流处理开发管理框架，提供了一套快捷的API 用来开发 Flink/Spark 作业，此外还提供了一个一站式的流处理作业开发管理平台，从流处理作业开发到上线全生命周期都做了支持，StreamPark 主要包含下面这些核心特点：

• 流处理应用开发框架：基于 StreamPark，开发者可以轻松构建和管理流处理应用程序，更好地利用 Apache Flink® 去编写流处理应用程序。

• 完善的作为管理能力：StreamPark 提供一站式流任务开发管理平台，支持了 Flink / Spark 从应用开发到调试、部署、运维等全生命周期的能力支持，让 Flink / Spark 作业变得简单。

• 完成度高：StreamPark 支持了 Flink 多版本，可以做到一个平台灵活切换，同时支持 Flink 所的部署模式，有效解决了 Flink on YARN / K8s 部署过于繁琐的问题，通过自动化流程，简化了任务的构建、测试和部署流程，并提高了开发效率。

• 丰富的管理 API：StreamPark 提供了作业操作的 API，包括作业创建、拷贝、构建、部署、基于 checkpoint/savepoint 的停止和启动等功能，使外部系统调用 Apache Flink® 任务变得易于实现。

3. StreamPark + Paimon 实践​

接下来，我们将继续分享自如是如何基于 StreamPark + Paimon 进行架构优化改造的，我们先看架构升级前后的对比。

3.1 架构升级前​

数据集成模块在改造之前的系统交互流程如下：

Step1（用户发起接入申请）：首先用户在数据接入平台选择一个表，然后点击申请接入按钮：

Step2（发起OA系统审批流程）：OA 系统接收到接入申请，会发起工作流审批，如审批失败会驳回申请，审批通过才会继续下一步。

Step3（数据接入平台处理审批通过事件）：数据接入平台调用 Canal 接口部署 Canal 任务，将表中的 Binlog 数据传入 Kafka ：

Step4（Flink 任务部署）：人工使用 Flink Session Submit UI 部署 Flink 模板作业，负责解析 Kafka 中的 Binlog 变化数据，并将数据写入 HDFS，同时映射成 Hive 外部增量表：

Step5（Airflow调度初始化表）：创建 Hive 映射增量表和全量表并用 Airflow 调度完成首次初始化:

Step6（数据合并到 Hive 全量表）：配置调度通过 Hive Merge 方式将 Hive 外部增量表的数据合并到 Hive 全量表中

3.2 架构升级后​

改造后的系统交互流程图如下：

对比改造前和改造后的交互流程图，可以看出前两个步骤的流程（表接入申请与审批）是一样的，只是审批通过之后的事件监听处理方式的差异。

• 改造前：调用 Canal 接口去部署Canal 任务（旧的逻辑）；

• 改造后：调用 StreamPark 的 API 接口完成 Flink Paimon 的任务部署。

接下来看看使用 Paimon 来完成数据的集成的。

3.3 Paimon 实现一键入 Hive​

在 Apache Paimon 0.5 版本后，提供了 CDC 数据集成能力，通过官方提供的 paimon-action jar 可以很方便的将 MySQL、Kafka、Mongo 等中的数据实时摄入到 Paimon 中，我们正在使用的是 paimon-flink-action ，采用了 mysql-sync-database（整库同步），并通过“—including_tables” 参数选择要同步的表。这种同步模式有效地节省了大量资源开销，相比每个表启动一个 Flink 任务而言，避免了资源的大量浪费。

paimon-flink-action 提供了自动创建 Paimon 表的功能，并支持 Schema Evolution（例如，当 MySQL 表字段发生变化时，Paimon 表会相应变化，无需额外操作）。整个操作流程高效而顺畅，解决了原始架构因添加字段而产生的不必要运维成本，paimon-action 具体使用如下，更多请参考Paimon 官网文档。

<FLINK_HOME>/bin/flink run \
    /path/to/paimon-flink-action-0.8-SNAPSHOT.jar \
    mysql_sync_table
    --warehouse <warehouse-path> \
    --database <database-name> \
    --table <table-name> \
    [--partition_keys <partition_keys>] \
    [--primary_keys <primary-keys>] \
    [--type_mapping <option1,option2...>] \
    [--computed_column <'column-name=expr-name(args[, ...])'> [--computed_column ...]] \
    [--metadata_column <metadata-column>] \
    [--mysql_conf <mysql-cdc-source-conf> [--mysql_conf <mysql-cdc-source-conf> ...]] \
    [--catalog_conf <paimon-catalog-conf> [--catalog_conf <paimon-catalog-conf> ...]] \
    [--table_conf <paimon-table-sink-conf> [--table_conf <paimon-table-sink-conf> ...]]

引入 Paimon 后缩短了整个数据接入链路，消除了对 Canal、Kafka、Airflow 的依赖，使得 MySQL 直接以分钟级速度与 Hive 对接，整体环境清爽高效。此外，Paimon 完全兼容 Hive 端数据读取，转换成本极低，对原始架构脚本的使用也具备良好的兼容性，Paimon 还支持 Tag 功能，可以视为轻量级的快照，大幅降低了存储成本。

3.4 StreamPark + Paimon 落地实践​

StreamPark 在 2.1.2 版本中更好的支持了 JAR 类型的作业，使得 Paimon 类型的数据集成作业更简单了，下面的示例，演示了如何使用 StreamPark 快速开发 Paimon 数据迁移类型的作业：

//视频链接 (StreamPark 部署 Paimon 数据集成作业示例 )

诚然 StreamPark 在 2.1.2 版本之后已经特别针对 Paimon 数据集成类作业做了支持，但是这种手动创建作业，输入作业参数的方式还是不满足我们的实际需求，我们需要更灵活的作业创建，可以通过调用 API 的方式快速完成作业创建、启动... 经过我们的调研发现 StreamPark 已经完整的开放了作业的各项操作 API，如作业的复制、创建、部署、启动、停止等，这样一来，我们通过定时调度就可以非常方便和 StreamPark 组合，来快速完成作业的开发和运行，具体方式如下：

Step1：首先，会调用api copy 模版接口，并传入参数，相关截图如下：

这样该作业就快速创建完成，参数会通过 copy 接口传入，具体参数如下：

Step2：接着，调用api构建作业镜像：

Step3：继续调用api启动作业：

最后，任务启动成功后，可以在 StreamPark 平台看到任务的相关状态信息以及整体任务的资源概况：

并可以点击Application Name 调度Flink Web UI：

最后可以直接在 Hive 端查询 Paimon 表，获取所需的数据，其中 Paimon 表是经过 Flink 处理的、延时较低的数据同步目标表。Hue 中 Hive 查询 Paimon 表截图如下

通过以上步骤，业务方可以方便地发起接入申请，经过审批流程后，通过 StreamPark 创建部署 Flink 作业，数据通过 Flink 作业入 Paimon 表，使用户能够轻松地在 Hive 端进行查询操作，整个流程简化了用户操作，提高了数据接入的效率和可维护性。

4. 带来的收益​

自如通过使用 Paimon 和 StreamPark ，带来了如下优势和效益：

• 网络资源和数据库压力优化：通过直接从 Paimon 表获取数据快照，解决了凌晨从业务数据库拉取数据导致的网络资源紧张和数据库压力过大问题，同时降低了数据存储成本。

• 作业管理接口提升效率：使用 StreamPark 的作业管理接口轻松解决了手动部署 Flink 任务的问题，消除了人员依赖时间导致任务不及时部署的情况，提高了效率，同时减少了沟通成本，提升了 Flink 作业的管理效率。

• 降低开发、维护成本：解决了之前方案链路长导致的维护成本高和问题定位慢的问题，同时解决了字段变化导致的字段不一致问题，实现了数据接入的流批统一，降低了开发和维护的成本。

• 降低了数据集成调度资源和计算资源的使用成本：不再依赖外部调度系统进行增量数据的合并，减少了调度资源的使用。也不再依赖 Hive 资源进行合并操作，降低了合并增量数据对 Hive 计算资源的花销成本。

5. 结语与期望​

我们衷心地感谢 Apache StreamPark 社区在我们使用 StreamPark API 时提供的无私帮助。他们专业的服务精神和以用户为本的态度，使我们得以更加高效、流畅地运用这一强大框架。作为一套卓越的框架，StreamPark 不但拥有出色的功能，而且能支持一系列如任务复制、创建、部署、启动、停止以及状态监控的操作，并在简化 Flink 任务的管理与维护方面显著地发挥了其价值。

同时，对 Apache Paimon 社区在自如 MySQL 入 Paimon 测试阶段给予我们的耐心与专业指导表示感谢，这是我们能够顺利完成测试的重要支持。Paimon 作为一项富有潜力的项目，无论是在功能实现还是团队协作方面，都展现了非凡的素质。

最后，我们对 Apache StreamPark 和 Apache Paimon 的未来之路满怀期待和信心，坚信它们能在未来会成为 Apache 的优秀项目。它们卓越的功能和和睦的社区合作模式，都为其在开源社区的成熟之路打下了坚实的基础。我们期待 StreamPark 和 Paimon 社区能一如既往地保持专业态度和良好的团队协作精神，不断推进项目发展，成为近年来新晋 Apache 项目的典范，以便对更广大的开发者社区产生更大的影响。

导读：本文主要介绍天眼查在实时计算业务近千个 Flink 作业运维时面临作业开发和管理上的挑战，通过引入 Apache StreamPark 来解决这些挑战，介绍了在引入 StreamPark 落地过程中遇到的一些问题以及如何解决这些问题并成功落地，最后极大地降低运维成本，显著地提升人效。

Github: https://github.com/apache/streampark

欢迎关注、Star、Fork，参与贡献

供稿单位 | 北京天眼查

文章作者 | 李治霖

文章整理 | 杨林伟

内容校对 | 潘月鹏

天眼查是中国领先的商业查询平台。自 2014 年创立以来，天眼查持续保持高速增长，行业渗透率超过 77%，月活跃用户数高达 3500 万，累计用户数 6 亿+，“天眼一下”已成为商业领域的超级符号，是首批获得央行备案企业征信资质的公司之一。经过公司多年深耕，平台共收录全国 3.4 亿、全球 6.4 亿社会实体，1000 多种商查信息维度实时更新，成为企业客户和个人用户商业查询的首选品牌。

本文将介绍天眼查实时计算业务面临的挑战，如何通过 Apache StreamPark 平台来解决这些挑战，以及带来的显著效益和未来规划。

业务背景与挑战​

天眼查有着庞大的用户基础和多样的业务维度，我们通过 Apache Flink® 这一强大的实时计算引擎，为用户提供更优质的产品和服务体验，我们的实时计算业务主要涵盖以下几个场景：

• 实时数据 ETL 处理和数据传输。

• C 端维度数据统计，包括用户行为、PV/UV 分析。

• C 端业务数据与工商信息、风险信息、产权、股权、股东、案件等信息的实时关联分析。

随着天眼查业务的快速发展，实时作业目前已增至 800 +，未来很快会上千，面对这么大体量的作业、在开发和管理上都遇到了挑战，大致如下：

• 作业运维困难：作业覆盖多个 Flink 版本，多版本 Flink 作业的运行和升级因 API 变动而成本高昂，且作业提交和参数调优依赖于复杂脚本，极大增加了维护难度和成本。

• 作业开发低效：从本地 IDE 调试到测试环境部署，需经过编译、文件传输和命令执行等繁琐步骤，耗时且影响效率。

• 缺乏自动重试机制：实时业务的多表关联操作易受网络和 IO 波动影响，导致 Flink 程序故障，需手动或额外程序介入恢复，增加了开发和维护成本。

• 维护成本高昂：缺少集中化的日志、版本控制和配置管理工具，随着任务量上升，维护大量 JAR 包、提交脚本和 Flink 客户端配置变得日益复杂。

StreamPark 落地实践​

为了解决上述问题，我司决定引入 StreamPark。我们在 StreamPark 项目刚开源的时候就开始关注，当时项目名还是 StreamX，此后也在一直密切关注着项目的发展，见证了其从开源到加入 Apache 软件基金会孵化的过程，其社区活跃度、用户口碑、发版次数等各项表现都很不错，有大量企业的真实使用案例，这增强了我们对 StreamPark 信心，因此引入 StreamPark 是自然而然的事情，我们尤其关注以下可以解决我们痛点的能力：

• Git 式项目管理：为作业提供了便捷的版本控制和部署流程。

• 强大的作业运维能力：显著提升了作业的管理和维护效率。

• 精确的秒级告警系统：提供了实时监控和快速响应能力。

• 一站式任务开发平台：为开发、测试和部署提供有力保障

1. Git 式项目管理​

天眼查 90% 以上都是 JAR 作业，管理几百个JAR 作业是很头疼的问题，为了方便维护和管理先前我们通过 “开发人员名称-项目名称-模块-环境” 进行命名 JAR 文件名，这样带来了另一个问题，没办法直观区分要维护的作业在那个模块，如果非 owner 维护此作业得通过项目文档和代码来查看逻辑，需要找到项目代码与对应分支、作业的启动脚本等，这样大幅度增加开发人员工作量。

在 StreamPark 中我们惊喜地发现有项目管理功能，类似于 Git 集成，可以很好的解决了我们的痛点，我们通过简化的命名规范，实现了项目、人员、分支和环境的隔离。现在，我们能够瞬间定位到任意作业的代码和文档，极大提高了作业的可维护性和开发效率，显著提升了我们的运维效率。

2. 秒级精确告警和自动运维​

下面是我们一个 Flink 线上的任务，在查询过程中访问第三方端时，发生 Connection Time out 等错误（备注：本身 Flink 设置重启策略间隔重启三次，但最终还是失败）

如上图，当收到任务告警时，我们开发同学在群里回复 1 的时候，我们发现作业已经成功被 StreamPark 拉起，只用不到 15 秒就完成了作业的重新提交和运行！

3. 平台用户权限管控​

StreamPark 提供了一套完善的权限管理机制，使得我们可以在 StreamPark 平台上对作业和用户进行精细的权限管理，有效避免了因用户权限过大而可能发生的误操作，减少了对作业运行稳定性和环境配置准确性的影响，对于企业级用户来说，这样的管理机制是非常必要的。

4. Flink SQL 在线开发​

对于许多开发场景中需要提交 Flink SQL 作业的情况，现在我们可以完全摆脱在 IDEA 中编写代码的繁琐步骤。只需使用 StreamPark 平台，就能轻松实现 Flink SQL 作业的开发，以下是一个简单的案例。

5. 完善的作业管理能力​

StreamPark 还有更加完善的作业操作记录，对于一些提交时异常的作业，现可完全通过平台化查看失败日志，包括历史日志信息等。

当然，StreamPark 还为我们提供了更加完善且友好的任务管理界面，可以直观地看到任务的运行情况。

我们企业内部实时项目是高度抽象化代码开发的作业，每次开发新作业只需要修改一些外部传入的参数即可，通过 StreamPark 复制作业功能让我们告别了很多重复性工作，只需要在平台上复制已有作业，略微修改程序运行参数就可以提交一个新的作业！

当然还有更多，这里就不一一列举了，StreamPark 在使用上足够的简单易用，分钟内即可上手使用，功能上足够的专注可靠，引入 StreamPark 以来解决了我们管理 Flink 作业面临的难题，带来了实实在在的方便，显著地提高了人效，给主创团队一个大大的赞！

遇到的问题​

在 StreamPark 落地实践中，我们也遇到了一些问题，这里记录下来，期望给社区的用户带来一些输入和参考。

华为云与开源 Hadoop 存在兼容问题​

我们的作业都是 Flink on Yarn 模式，部署在华为云。在使用 StreamPark 部署作业的过程中发现作业可以成功部署到华为 Hadoop 集群，但是获取作业状态信息时请求 Yarn ResourceManager 被拒绝，我们及时和社区沟通，寻求解决方案，并且记录了 issue: https://github.com/apache/streampark/issues/3566

最后在社区 PMC 成员华杰老师和华为云同学的协助下，成功解决了问题：由于云产品本身内部的安全认证机制导致 StreamPark 无法正常访问云 ResourceManager。

解决方案 (仅供参考 - 根据不同环境添加不同依赖)

将 STREAMPARK_HOME/lib 目录中 HADOOP 相关两个包删除：

hadoop-client-api-3.3.4.jar
hadoop-client-runtime-3.3.4.jar

替换以下华为云 HADOOP 依赖:

commons-configuration2-2.1.1.jar
commons-lang-2.6.0.wso2v1.jar
hadoop-auth-3.1.1-hw-ei-xxx.jar
hadoop-common-3.1.1-hw-ei-xxx.jar
hadoop-hdfs-client-3.1.1-hw-ei-xxx.jar
hadoop-plugins-8.1.2-xxx.jar
hadoop-yarn-api-3.1.1-hw-ei-xxx.jar
hadoop-yarn-client-3.1.1-hw-ei-xxx.jar
hadoop-yarn-common-3.1.1-hw-ei-xxx.jar
httpcore5-h2-5.1.5.jar
jaeger-core-1.6.0.jar
mysql-connector-java-8.0.28.jar
opentracing-api-0.33.0.jar
opentracing-noop-0.33.0.jar
opentracing-util-0.33.0.jar
protobuf-java-2.5.0.jar
re2j-1.7.jar
stax2-api-4.2.1.jar
woodstox-core-5.0.3.jar

其他 BUG​

在深入使用的过程中，我们也发现了一些问题。为了更好地改善与优化 StreamPark 的功能，我们提出了一些具体的建议和解决方案，例如：

• 依赖冲突：加载 Flink 依赖时出现冲突的解决（详见：Pull Request #3568）。

• 服务稳定性：拦截用户程序 JVM 退出，防止 StreamPark 平台因用户程序异常退出（详见：Pull Request #3659）。

• 资源优化：为减轻资源负担，限制 StremaPark 构建项目的并发数，通过配置参数来控制项目最大构建数量（详见：Pull Request #3696）。

带来的收益​

Apache StreamPark 为我们带来了显著的收益，主要体现在其一站式服务能力，使得业务开发人员能够在一个统一的平台上完成 Flink 作业的开发、编译、提交和管理。极大地节省了我们在 Flink 作业开发和部署上的时间，显著地提升了开发效率，并实现了从用户权限管理到 Git 部署、任务提交、告警、自动恢复的全流程自动化，有效解决了 Apache Flink® 运维的复杂性。

目前在天眼查平台，StreamPark 带来的具体成效包括：

• 实时作业上线和测试部署流程简化了 70% 。

• 实时作业的运维成本降低了 80%，开发人员可以更专注于代码逻辑 。

• 告警时效性提高了 5倍 以上，从分钟级降低到秒级，实现了 5秒内 感知并处理任务异常。

• 对于任务失败，StreamPark 能够自动恢复，无需人工干预。

• 通过 GitLab 与 StreamPark 的集成，简化了编译项目和作业提交流程，大幅降低了开发和维护成本。

未来规划​

未来我们计划将内部自研实时计算平台上部署的 300+ Flink 作业和其他方式维护的 500+ Flink 作业全部迁移至 StreamPark 进行统一管理维护，后续遇到一些可优化或可增强功能点，我们会及时与社区开发人员沟通并回馈贡献社区，让 StreamPark 变得更易用、更好用。

在本文的最后，我们衷心感谢 Apache Streampark 社区，特别是 PMC 成员华杰老师，在我们使用 StreamPark 过程中持续地跟进，提供了宝贵的技术支持，我们深刻感受到 Apache StreamPark 社区认真的态度和热情。同时也非常感谢华为云同学在云部署上支持与问题排查。

我们期待未来与 StreamPark 社区继续合作，共同推动实时计算技术的发展，期望 StreamPark 在未来做得越来越好，早日毕业成为新晋 Apache 项目的代表！

导读：本文主要详细介绍欢乐互娱在实战中对大数据技术架构的应用，阐述为何选择 “Kubernetes + StreamPark” 来持续优化和增强现有的架构。不仅系统地阐述了如何在实际环境中部署并运用这些关键技术，更是深入地讲解了 StreamPark 的实践使用，强调理论与实践的完美融合，相信读者通过阅读这篇文章，将有助于理解和掌握相关技术，并能在实践中进步，从而取得显著的学习效果。

Github: https://github.com/apache/streampark

欢迎关注、Star、Fork，参与贡献

供稿单位 | 欢乐互娱

文章作者 | 杜遥

文章整理 | 杨林伟

内容校对 | 潘月鹏

欢乐互娱，是一家全球游戏研发和发行公司；公司产品聚焦在 MMORPG 和 MMOACT 两大品类；欢乐产品理念：“宁做100人尖叫的产品，不做1万人叫好的产品”；欢乐出品，必属精品。《RO仙境传说：爱如初见》上线东南亚，预约期间达成了 1000 万预约的里程碑，上线首日取得五国畅销榜第一，并在日韩美、港澳台等地都有发行，取得了不错的成绩。

1. 业务背景与挑战​

欢乐互娱目前使用的大数据底座是腾讯云的 EMR，数仓架构主要分为了如下几类：

• 离线数仓架构：Hadoop + Hive + Dolphinscheduler + Trino

• 实时数仓架构：Kafka + Flink + StreamPark + Doris

• 流式数仓架构（规划中）：Paimon + Flink + StreamPark + Doris

其中，流式数仓架构是我们 2024 年的重点计划之一，目标是基于 Kubernetes 的弹性特点以提高大数据分析能力及各种数据产品的价值输出。然而，由于早前的架构原因（主要是 Apache Doris 和 EMR 核心节点的混部署），让我们遇到了许多问题，例如：

• 资源争夺：在 YARN 资源调度平台下，Apache Doris、Apache Flink 实时任务、Hive 的离线任务以及 Spark 的 SQL 任务经常争抢 CPU 和内存资源，导致 Doris 查询稳定性下降，查询错误频繁。

• 资源不足：YARN 的机器资源使用率大部分时间位于 70％ 至 80％ 之间，特别是在大量的补数的场景下，集群资源往往不足。

• 人工干预：实时 Flink 的任务越来越多，各游戏的数据在一天内有明显的波峰波谷变化，特别是在周末进行的挂机活动，数据量翻倍，甚至增加至每天超过 100 亿条，而且这需要频繁地手动调整并行度来适应计算压力，以保证数据消费能力。

2. 解决方案选型​

为了解决以上问题，我们寻求能够进行 “资源弹性伸缩” 和 “任务管理” 的相关组件，同时考虑到大数据云原生的趋势，采用云原生的架构迫在眉睫， Kubernetes 架构下能为大数据运维减负、提供高可用、负载均衡、灰度更新等更好更稳定的能力。

同时简化 Apache Flink 实时任务的开发和运维也是不得不面对的问题，自 2022 年中旬开始，就重点研究 Flink 相关的开源和商业化相关的项目，在进行技术选型时，公司主要从几个关键维度进行了深入考察，包括：Kubernetes 容器化部署、轻量程度、多 Flink版本的支持、功能的完备性、多种部署模式、对 CI/CD 的支持以及稳定性、成熟度等，最终不出意外的选择了 Apache StreamPark。

我们在使用 StreamPark 的过程中，对其进行了深入的应用和探索，已经成功实现了100+ Flink 任务轻松部署到 Kubernetes，可以十分方便地进行作业管理。

接下来，将详述我们是如何使用 StreamPark 实现 Flink on kubernetes 在生产环境中的实践过程，尽管内容较长，但是干货满满，内容主要分为以下的几个部分：

• 环境准备篇：这部分介绍 Kubernetes、StreamPark、Maven、Docker、kubectl 工具和 Flink 的安装与配置过程。

• StreamPark 使用篇：这部分介绍如何使用 StreamPark 启动 Session 集群，以及部署 SQL、JAR 作业的流程等。

• Flink 任务应用场景篇：在这一部分，将分享欢乐互娱实际运用 Flink 任务的实践场景。

3. 落地实践 - 环境准备篇​

接下来我们将从安装开始详细介绍 StreamPark 的落地实践,关于腾讯云产品的一些使用步骤，将在文末简要介绍，此处主要分享核心的步骤。

3.1. 准备 Kubernetes 环境​

欢乐互娱的 Kubernetes 环境使用的是腾讯云容器服务产品，其中 Kubernetes 命名空间主要划分如下：

• Apache Doris：Doris 集群 + 3 FE（标准节点） + CN（1 台超级节点）。

• Apache Flink：Flink 集群由一个超级节点组成，这个节点相当于一台超大资源的机器，使用起来非常简单，并且可以迅速弹性扩展到数以万计的 pod。

• BigData：包含各种大数据组件。

另外，我们还有两台原生节点，主要用于部署 StreamPark、Dolphinscheduler 以及 Prometheus + Grafana。集群信息相关截图如下：

3.2. 安装 StreamPark​

我们采用的是 StreamPark 2.1.4 最新的稳定版本，该版本修复了一些 Bug，并增加了一些新的特性，如支持 Flink 1.18、Jar 任务支持通过 pom 或者上传依赖等。

虽然 StreamPark 支持 Docker 和 Kubernetes 部署，但是出于节省时间和对所有大数据组件需要进行顶层设计容器化的考虑，我们当前选择了在云上的 CVM 上进行 StreamPark 的快速搭建，以下是 StreamPark 的安装部署脚本：

#使用 root 用户进入安装目录（需先有 java 环境）和 k8s 环境同一个网段！！！可以省事
cd /data     

#下载二进制安装包
wget https://dlcdn.apache.org/incubator/streampark/2.1.4/apache-streampark_2.12-2.1.4-incubating-bin.tar.gz   

#与提供的值进行比较、保证包的完成性
sha512sum apache-streampark_2.12-2.1.2-incubating-bin.tar.gz  #解压缩
tar -xzvf apache-streampark_2.12-2.1.2-incubating-bin.tar.gz  #改名
mv apache-streampark_2.12-2.1.2-incubating-bin streampark_2.12-2.1.2 #创建软链
ln -s streampark_2.12-2.1.2  streampark

#修改数据库配置
vim /data/streampark/conf/application-mysql.ymlspring:
  datasource:
    username: root
    password: xxxxx
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://10.16.x.x:3306/streampark_k8s?...

# 修改 streampark 核心配置 可以修改下端口（因为 k8s nodeport 端口范围  30000-32767） 故可以配置这个范围 省去端口对外开发再配置  或者账号密码  我们存储用 cos 故不配置 hdfs
vim /data/streampark/conf/application.yml      workspace:
   local: /data/streampark/streampark_workspace #创建需要的目录
   
   
mkdir -p  vim /data/streampark/conf/application.yml

#初始化 streampark 的数据库表 要求环境有 mysql 客户端  执行完可以去 mysql 中看下库表是否存在
mysql -u root -p xxxxx < /data/streampark/script/schema/mysql-schema.sql

#添加依赖的 mysql-connector 包 因为 streampark lib下面没有  在 /data/streampark/lib下执行
wget https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.0.33/mysql-connector-j-8.0.33.jar 

#启动并登陆 可以先验证下 java  环境  java -version 确保没问题   在 /data/streampark/lib下执行
 ./startup.sh 

3.3. 安装 Maven​

在 StreamPark 上配置 Flink 任务时可以通过 maven 下载相关依赖，下面是 Maven 的安装配置：

#下载 maven 同 root 用户操作
cd /data && wget https://dlcdn.apache.org/maven/maven-3/3.9.6/binaries/apache-maven-3.9.6-bin.tar.gz

#检验安装包完整
sha512sum apache-maven-3.9.6-bin.tar.gz 

#解压  软连
tar -xzvf apache-maven-3.9.6-bin.tar.gz 
ln -s apache-maven-3.9.6 maven

# 设置阿里云仓库 maven mirror，加速下载
vim /data/maven/conf/settings.xml

<mirror>
   <id>alimaven</id>
  <mirrorOf>central</mirrorOf>
  <name>aliyun maven</name>
  <url>https://maven.aliyun.com/repository/central</url>
</mirror>

<mirror>
  <id>alimaven</id>
  <name>aliyun maven</name>
  <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
  <mirrorOf>central</mirrorOf>
 </mirror>

#环境变量 最后添加
vim /etc/profile
export MAVEN_HOME=/data/maven
PATH=$MAVEN_HOME/bin:$PATH

#生效 验证
source /etc/profile  && mvn -version

3.4 安装 Docker​

因为 StreamPark 使用 Kubernetes 时，可以使用 Docker 来构建和上传镜像到公司常用的 Harbor 镜像服务中，以下是 Docker 的安装脚本

#卸载旧版本 如果有
sudo yum remove docker \
          docker-client \
          docker-client-latest \
          docker-common \
          docker-latest \
          docker-latest-logrotate \
          docker-logrotate \
          docker-engine

#下载镜像仓库
wget -O /etc/yum.repos.d/docker-ce.repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo      #阿里云docker-ce 镜像

#更新软件包索引 
yum makecache     

#下载安装
yum install docker-ce docker-ce-cli containerd.io -y # docker-ce 社区版 ee 企业版

#启动 查看 
systemctl start docker && docker version

#开机自启
systemctl enable docker

3.5. Kubectl 工具安装​

为了方便与 Kubernetes 集群进行交互、进行配置查看、访问日志等，我们还安装了kubectl 工具。安装 kubectl 前，首先需要先从这里获取 Kubernetes 集群的访问凭证，下载方式如下图：

接着下载配置拷贝到 root 用户目录，指定目录并改名：

# 1）创建默认隐藏目录
mkdir -p /root/.kube   

# 2）上传 k8s 内网访问凭证             
rz cls-dtyxxxxl-config

# 3）修改凭证默认名字              
mv cls-dtyxxxxl-config config  

# 4）将凭证放到指定位置
mv config /root/.kube 

具体安装 kubetcl 客户端命令如下（当然也可以安装 kubectx ，更加方便地去访问多个 kubernetes 集群和切换固定的命名空间）：

# 1）下载最新版
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 2）添加执行权限
chmod +x kubectl

# 3）移动到常用的工具命令位置
mv ./kubectl /usr/local/bin/kubectl

# 4）可以在 /etc/profile 或者 root用户家目录的  .bashrc 中配置
vim /root/.bashrc
export JAVA_HOME=/usr/local/jdk1.8.0_391
PATH=/usr/local/bin:$JAVA_HOME/bin:$PATH

# 5）验证客户端和集群密钥
kubectl cluster-info

最后，还需要创建一个 Flink 专用的账户凭证（后面会用到）：

# 1）创建命名空间
kubectl create namespace flink

# 2）创建 flink 访问 k8s 的账号  记得带命名空间！
kubectl  create serviceaccount flink-service-account -n flink

# 3）给该账号绑定容器操作的一些权限 记得带命名空间！！！
kubectl  create clusterrolebinding flink-role-binding-flink --clusterrole=edit --serviceaccount=flink:flink-service-account -n flink  

3.6. 安装配置 Flink​

我们 Kubernetes 环境选择了 Flink1.17-scala2.12 Java11 的镜像，因为当时 Flink 1.18 有些依赖包不好找。

下载并解压 flink-1.17.2-bin-scala_2.12.tgz 安装包，脚本如下：

cd /data && wget https://dlcdn.apache.org/flink/flink-1.17.2/flink-1.17.2-bin-scala_2.12.tgz

#完整性校验
sha512sum flink-1.17.2-bin-scala_2.12.tgz

#解压
tar -xzvf flink-1.17.2-bin-scala_2.12.tgz

#改名
mv flink-1.17.2-bin-scala_2.12 flink-1.17.2

#软连
ln -s flink-1.17.2 flink

#旧二进制包收纳
mv flink-1.17.2-bin-scala_2.12.tgz /data/softbag   

至此，我们已经把环境搭建好了，下面继续按步骤详细讲解 StreamPark 的使用。

4. 落地实践 - StreamPark 使用篇​

想快速了解 StreamPark 运行作业至 Kubernetes 的读者，可以观看下面的视频：

//视频链接 (Flink On Kubernetes Application 上手教程)

//视频链接 (Flink On Kubernetes Session 上手教程)

4.1. 配置 Flink Home​

登录 StreamPark 之后，切换至 Flink Home 菜单，配置我们在前面解压的 Flink 安装包目录，截图如下：

4.2. 创建 Flink Session​

接着切换到 FlinkCluster，Add New 新增一个 Flink 集群：

配置详情如下，以下是第一部分的配置内容：

配置详解：集群名字和 Kubernetes 集群 ID 我们通常写一样，填写正确的 Kubernetes 服务账号，这里的镜像使用腾讯云 tcr 中的镜像，并使用 lb 作为对外访问 Flink UI 的方式。这里的槽一般设置为 2，任务并行度一般是 2 的倍数，这样就可以让 Session 集群没有闲置的资源）

第二部分的配置内容：

配置详解：我们采取的是 Session 模式，一个 JobManager 管理着很多任务，故资源可以稍微大一些，我们给 2G，经观察可以满足，但是由于任务多，JobManager 的内存分配中 metaspace 消耗比较大，故可以将默认的 256M，改到 500M，经过观察，一个 Session 管理 10 个任务以下，这个配置合理。

TaskManager 内存在 session 配置给出后，在 StreamPark 程序配置页将无法修改，故可以对 Session 项目数据量进行预估，数据量大就可以 把 “CPU : 内存” 调整到 “1 核 : 2G”，当然也可以更大，因为数据处理还有 TaskManager 数量有关，也就是并行度有关，这样基本就可以避免一些 OOM 问题，我们 “1 : 2” Session 集群项目一天处理数据量 60 亿，18 个并行度，仅供参考。默认 cpu: 内存 1 : 1 基本 ok。

最后一部分的内容如下：

这里贴出具体的文本内容：

#访问方式  复用lb+port lb可以提前创建 不用k8s创建  这样ip固定。复用后更加方便
-Drest.port=8091
-Dkubernetes.rest-service.annotations=service.kubernetes.io/qcloud-share-existed-lb:true,service.kubernetes.io/tke-existed-lbid:lb-iv9ixxxxx
-Dkubernetes.rest-service.exposed.type=LoadBalancer

#cp sp  使用s3协议访问腾讯云cos  插件方式依赖包  s3的cos认证
-Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.17.2.jar
-Dcontainerized.taskmanager.env.EANABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.17.2.jar
-Dstate.checkpoints.dir=s3://k8s-bigdata-xxxxxx/flink-checkpoints
-Dstate.savepoints.dir=s3://k8s-bigdata-xxxxx/flink-savepoints

#k8s中的任务调度策略、节点选择策略，因为flink命名空间是逻辑的，而节点选择策略可以让其跑在flink专用的物理超级节点上去
-Dkubernetes.jobmanager.node-selector=usefor:flink
-Dkubernetes.taskmanager.node-selector=usefor:flink

#开启jobmanager高可用 使用 k8s实现方式、 使用cos的目录存储  整体就不用hdfs
-Dhigh-availability.type=kubernetes
-Dhigh-availability.storageDir=s3://k8s-bigdata-xxx/flink-recovery
-Dkubernetes.cluster-id=streampark-share-session
-Dkubernetes.jobmanager.replicas=2

#pod镜像拉取策略和flink取消cp的保留 时区
-Dkubernetes.container.image.pull-policy=Always
-Dexecution.checkpointing.externalized-checkpoint-retention=RETAIN_ON_CANCELLATION
-Dtable.local-time-zone=Asia/Shanghai

#镜像拉取缓存加速  详细下文有解释
-Dkubernetes.taskmanager.annotations=eks.tke.cloud.tencent.com/use-image-cache: imc-6iubofdt
-Dkubernetes.jobmanager.annotations=eks.tke.cloud.tencent.com/use-image-cache: imc-6iubofdt  

备注：Flink 基础信息的可以配置到 conf 文件中，更多程序通用的建议在 session 中写好，StreamPark 中填写 并行度/cp/sp/容错/main 参数等比较合适。

最后启动 Session 集群即可，可以通过 kubectl 命令来查看 Flink kubernetes session 集群是否成功启动：

4.3. 任务配置​

这里将继续展示使用 StreamPark 提交3种类型的任务，分别是 SQL任务、Jar任务 以及 Application 模式任务。

• 提交 Flink SQL 任务

Flink Sql 作业的配置截图如下：

其中的 kubernetes clusterid 填写对应的项目 session 名就行：

动态参数配置如下：

-Dstate.checkpoints.dir=s3://k8s-bigdata-12xxxxx/flink-checkpoints/ro-cn-sync
-Dstate.savepoints.dir=s3://k8s-bigdata-12xxxxxxx/flink-savepoints/ro-cn-sync
-Dkubernetes.container.image.pull-policy=Always
-Dkubernetes.service-account=flink-service-account
-Dexecution.checkpointing.interval=25s
-Dexecution.checkpointing.mode=EXACTLY_ONCE
-Dtable.local-time-zone=Asia/Shanghai
-Drestart-strategy.fixed-delay.attempts=10
-Drestart-strategy.fixed-delay.delay=3min  

• 提交 Flink JAR 任务

Jar 任务基本和 Sql 任务基本一样，配置截图如下：

动态参数如下（如果有配置模版，这里就可以更加精简，因为 StreamPark 支持很好的任务复制，故可以写一标准的 Jar 和 SQL 的任务 demo，剩下任务都采用复制，可大大提高任务开发效率）：

-Dstate.checkpoints.dir=s3://k8s-bigdata-1xxxx/flink-checkpoints/ro-cn-shushu
-Dstate.savepoints.dir=s3://k8s-bigdata-1xxxx/flink-savepoints/ro-cn-shushu
-Dkubernetes.container.image.pull-policy=Always
-Dkubernetes.service-account=flink-service-account
-Dexecution.checkpointing.interval=60s
-Dexecution.checkpointing.mode=EXACTLY_ONCE
-Dstate.checkpoints.num-retained=2
-Drestart-strategy.type=failure-rate
-Drestart-strategy.failure-rate.delay=3min
-Drestart-strategy.failure-rate.failure-rate-interval=30min
-Drestart-strategy.failure-rate.max-failures-per-interval=8

• 提交 Flink Application 任务

当然也可以部署 Application 模式的任务至 Kubernetes，这里贴上示例，首先是第一部分的配置内容：

这是第二部分的配置内容如下：

第三部分的配置内容如下：

动态参数：

详细的配置内容：

-Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.17.2.jar 
-Dcontainerized.taskmanager.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.17.2.jar
-Dstate.checkpoints.dir=s3://k8s-bigdata-xxx/flink-checkpoints/Kafka2Rocketmq2Kafka
-Dstate.savepoints.dir=s3://k8s-bigdata-xxx/flink-savepoints/Kafka2Rocketmq2Kafka
-Dkubernetes.container.image.pull-policy=Always
-Dkubernetes.service-account=flink-service-account
-Dexecution.checkpointing.interval=60s
-Dexecution.checkpointing.mode=EXACTLY_ONCE
-Dstate.checkpoints.num-retained=2
-Drest.port=8092
-Dkubernetes.jobmanager.node-selector=usefor:flink
-Dkubernetes.taskmanager.node-selector=usefor:flink
-Dkubernetes.rest-service.annotations=service.kubernetes.io/qcloud-share-existed-lb:true,service.kubernetes.io/tke-existed-lbid:lb-xxx
-Dkubernetes.rest-service.exposed.type=LoadBalancer
-Dfs.allowed-fallback-filesystems=s3

4.4. 构建任务​

接着对任务进行构建，这里可以很清晰的看到任务构建的每一步骤：

最终可以跑起来观察到任务正在运行：

4.5. 通知告警配置（非必选）​

当然 StreamPark 支持多种通知告警方式（例如：邮箱和飞书等），我们使用的是邮箱的方式，直接界面配置即可：

至此，我们已经分享了如何在 StremPark 中成功地去部署运行在 kubernetes 不同类型的 Flink任务，十分的丝滑！

5. 落地实践 - 作业应用场景篇​

接下来，继续针对作业进行剖析，从调优、实操等场景中让我们更进一步地去了解 Flink 任务的应用。

5.1. 调优建议​

建议一（时区）：容器中需要以utc+8方便看日志，我们可以在conf配置中添加如下：

env.java.opts.jobmanager: -Duser.timezone=GMT+08
env.java.opts.taskmanager: -Duser.timezone=GMT+08

建议二（StreamPark变量管理）：StreamPark 提供变量管理、让我们可以管理一些配置，提高安全和便捷性：

建议三（StreamPark传参）：在 on YARN 上使用 Flink自带的工具类传参数，参数难传递到 Flink 环境去，我们也没深究。我们选择通过 StreamPark 传入程序参数，这样在 YARN 和 kubernetes 都可以用，同时在 kubernetes 的 application 和 session 方式也都可以用，变得更加通用且改动方便，强烈推荐！

建议四（使用Session模式）：尽管 Yarn-application模式提供了高度的任务隔离，但其每个任务都需要独立的 jobmanager 资源，这导致资源消耗过高。此外，合并任务虽然可以减少资源消耗，但会带来工作量大、数据不稳定等问题。相比之下，session 模式允许任务在一个 session 中共享一个 jobmanager 资源，这可以最大限度地节约计算资源，虽然它可能存在单点问题，但可以通过使用两个 jobmanager 实例实现高可用性来解决。更重要的是，session 模式还可以更方便地查看因任务失败而产生的日志，有助于提高故障诊断的效率。因此，鉴于其在资源利用、高可用性和任务故障处理方面的优势，选择 session 模式成为了一种更为理想的选择。

5.2. 数据CDC同步​

【MySQL → Doris】：下面代码主要演示了 MySQL 数据同步至 Apache Doris 的 Flink sql 流水线：

CREATE TABLE IF NOT EXISTS `login_log_mysql` (
 login_log_id      bigint not null,  
 account_id        bigint ,  
 long_account_id   string , 
 short_account_id  string , 
 game_code         string , 
 package_code      string , 
 channel_id        int    ,
 login_at          int    ,  
 login_ip          string ,    
 device_ua         string ,
 device_id         string ,
 device_net        string ,
 device_ratio      string , 
 device_os         string ,
 device_carrier    string ,
 ext               string ,        
 created_at        int    ,  
 updated_at        int    ,  
 deleted_at        int ,
  PRIMARY KEY(`login_log_id`)
 NOT ENFORCED
) with (
  'connector' = 'mysql-cdc',
  'hostname' = '10.xxx.xxx.xxx',
  'port' = '3306',
  'username' = 'http_readxxxxx',
  'password' = 'xxxx@)',
  'database-name' = 'player_user_center',
  -- 'scan.startup.mode' = 'latest-offset',
  'scan.startup.mode' = 'earliest-offset',
  'table-name' = 'login_log_202[3-9][0-9]{2}',
  'server-time-zone' = '+07:00'
);

create table if not EXISTS login_log_doris(
  `date`    date              ,    
   login_log_id    bigint     ,
   account_id    bigint       ,
   long_account_id    string  ,
   short_account_id    string ,
   game_code    string        ,
  `package_code`    string    ,
  `channel_id`    int         ,
   login_at     string      ,
   login_ip    string         ,
   device_ua    string        ,
   device_id    string        ,
   device_net    string       ,
   device_ratio    string     ,
   device_os    string        ,
   device_carrier    string   ,
   ext        string          ,
   created_at      string   ,
   updated_at      string   ,
   deleted_at      string   ,
    PRIMARY KEY(`date`,`login_log_id`)
 NOT ENFORCED
) WITH (
   'connector' = 'doris',
    'jdbc-url'='jdbc:mysql://xxx.xx.xx.xx:9030,xxx.xxx.xxx.xxx:9030,xxx.xxx.xxx.xxx:9030',
    'load-url'='xxx.xx.xx.xx:8030;xxx.xx.xx.xx:8030;xxx.xx.xx.xx:8030',
    'database-name' = 'ro_sea_player_user_center',
    'table-name' = 'ods_login_log',
    'username' = 'root',
    'password' = 'root123',
    'sink.semantic' = 'exactly-once',
    'sink.max-retries' = '10'
);

create view login_log_flink_trans as 
select  
 to_date(cast(to_timestamp_ltz(login_at,0) as varchar) )  , 
 login_log_id     ,  
 account_id       ,  
 long_account_id  , 
 short_account_id , 
 game_code        , 
 package_code     , 
 channel_id,
 cast(to_timestamp_ltz(login_at,0) as varchar) as login_at,
 login_ip         ,    
 device_ua        ,
 device_id        ,
 device_net       ,
 device_ratio     , 
 device_os        ,
 device_carrier   ,
 ext              ,
 cast(to_timestamp_ltz(created_at,0) as varchar) as created_at,
 cast(to_timestamp_ltz(updated_at,0) as varchar) as updated_at,
 cast(to_timestamp_ltz(deleted_at,0) as varchar) as deleted_at
from login_log_mysql;

insert into login_log_doris select * from login_log_flink_trans;

CREATE TABLE IF NOT EXISTS `account_mysql` (
 account_id        bigint ,  
 open_id   string , 
 dy_openid  string , 
 dy_ios_openid  string , 
 ext               string ,        
 last_channel      int    ,  
 last_login_time   int    ,  
 last_login_ip     string ,  
 created_at        int    ,  
 updated_at        int    ,  
 deleted_at        string ,
  PRIMARY KEY(`account_id`)
 NOT ENFORCED
) with (
  'connector' = 'mysql-cdc',
  'hostname' = 'xxx.xx.xx.xx',
  'port' = '3306',
  'username' = 'http_readxxxx',
  'password' = 'xxxxx@)',
  'database-name' = 'player_user_center',
  -- 'scan.startup.mode' = 'latest-offset',
  'scan.startup.mode' = 'earliest-offset',
  'table-name' = 'account_[0-9]+',
  'server-time-zone' = '+07:00'
);

create table if not EXISTS account_doris(
  `date`    date              ,    
   account_id    bigint     ,
   open_id    string  ,
   dy_openid    string ,
   dy_ios_openid    string        ,
   ext        string          ,
  `last_channel`    int         ,
   last_login_time     string      ,
   last_login_ip    string         ,
   created_at      string   ,
   updated_at      string   ,
   deleted_at      string   ,
   PRIMARY KEY(`date`,`account_id`)
 NOT ENFORCED
) WITH (
   'connector' = 'doris',
    'jdbc-url'='jdbc:mysql://xxx.xx.xx.xx:9030,xxx.xx.xx.xx:9030,xxx.xx.xx.xx:9030',
    'load-url'='xxx.xx.xx.xx:8030;xxx.xx.xx.xx:8030;xxx.xx.xx.xx:8030',
    'database-name' = 'ro_sea_player_user_center',
    'table-name' = 'ods_account_log',
    'username' = 'root',
    'password' = 'root123',
    'sink.semantic' = 'exactly-once',
    'sink.max-retries' = '10'
);

create view account_flink_trans as 
select  
 to_date(cast(to_timestamp_ltz(created_at,0) as varchar) )  , 
 account_id     ,  
 open_id  , 
 dy_openid , 
 dy_ios_openid        , 
 ext              ,
 last_channel,
cast(to_timestamp_ltz(last_login_time,0) as varchar) as last_login_time,
 last_login_ip         ,    
 cast(to_timestamp_ltz(created_at,0) as varchar) as created_at,
 cast(to_timestamp_ltz(updated_at,0) as varchar) as updated_at,
 deleted_at
from account_mysql;

insert into account_doris select * from account_flink_trans;

【游戏数据同步】：将海外 filebeat 采集的 kafka 数据拉到国内 kafka，并进行处理元数据加工：

--创建hmt 的kafka source 表
CREATE TABLE kafka_in (
  `env` STRING comment '游戏环境 hdf  /qc/cbt/obt/prod',
  `host` STRING comment '日志所在游戏服务器',
  `tags` STRING comment '日志标签 normal | fix',
  `log`  STRING comment '日志所在文件及偏移量',
  `topic` STRING METADATA VIRTUAL comment 'kafka的topic',
  `partition_id` BIGINT METADATA FROM 'partition' VIRTUAL comment '日志所在的kafka分区', 
  `offset` BIGINT METADATA VIRTUAL comment 'kafka分区的偏移量', 
   `uuid`  STRING comment 'filebeat生成的uuid',
  `message` STRING comment 'tlog信息',
  `@timestamp` STRING comment 'filebeat采集时间',
  `ts` TIMESTAMP(3) METADATA FROM 'timestamp' comment 'kafka存储消息时间'
) WITH (
  'connector' = 'kafka',
  'topic' = 'ro_sea_tlog',
  'properties.bootstrap.servers' = 'sea-kafka-01:9092,sea-kafka-02:9092,sea-kafka-03:9092',
  'properties.group.id' = 'streamx-ro-sea-total',
  'properties.client.id' = 'streamx-ro-sea-total',
  'properties.session.timeout.ms' = '60000',
  'properties.request.timeout.ms' = '60000',
  'scan.startup.mode' = 'group-offsets',
  --'scan.startup.mode' = 'earliest-offset',\
  'properties.fetch.max.bytes' = '123886080',
  'properties.max.partition.fetch.bytes' = '50388608',
  'properties.fetch.max.wait.ms' = '2000',
  'properties.max.poll.records' = '1000',
  'format' = 'json',
  'json.ignore-parse-errors' = 'false'
);

--创建emr 的kafka 正式表
CREATE TABLE kafka_out_sea (
`env` STRING comment '游戏环境 qc/cbt/obt/prod',
`hostname` STRING comment '日志所在游戏服务器',
`tags` STRING comment '日志标签 normal | fix',
`log_offset`  STRING comment '日志所在文件及偏移量',
`uuid`  STRING comment 'filebeat生成的uuid',
`topic` STRING comment 'kafka的topic',
`partition_id` BIGINT comment '日志所在的kafka分区', 
`kafka_offset` BIGINT comment 'kafka分区的偏移量', 
 eventname string comment '事件名',
`message` STRING comment 'tlog信息',
`filebeat_ts` STRING comment 'filebeat采集时间',
`kafka_ts` TIMESTAMP(3) comment 'kafka存储消息时间',
`flink_ts` TIMESTAMP(3)  comment 'flink处理的消息时间'
) WITH (
  'connector' = 'kafka',
  'topic' = 'ro_sea_tlog',
  --'properties.client.id' = 'flinkx-ro-sea-prod-v2',
  'properties.bootstrap.servers' = 'emr_kafka1:9092,emr_kafka2:9092,emr_kafka3:9092',
  'format' = 'json',
  --'sink.partitioner'= 'fixed',
  'sink.delivery-guarantee' = 'exactly-once',
  'sink.transactional-id-prefix' = 'ro_sea_kafka_sync_v10',
  'properties.compression.type' = 'zstd',
  'properties.transaction.timeout.ms' = '600000',
  'properties.message.max.bytes' = '13000000',
  'properties.max.request.size' = '13048576',
  --'properties.buffer.memory' = '83554432',
  'properties.acks' = '-1'
);

--etl 创建目标视图
create view kafka_sea_in_view  as 
select `env`,JSON_VALUE(`host`,'$.name') as hostname,`tags`,`log` as log_offset,`uuid`,
       `topic`,`partition_id`,`offset` as kafka_offset,
     lower(SPLIT_INDEX(message,'|',0)) as eventname,`message`, 
     CONVERT_TZ(REPLACE(REPLACE(`@timestamp`,'T',' '),'Z',''), 'UTC', 'Asia/Bangkok') as filebeat_ts, `ts` as kafka_ts ,CURRENT_TIMESTAMP as flink_ts
from kafka_in;

--写数据到emr  sea topic
insert into kafka_out_sea
select * from kafka_sea_in_view ;

【实时数仓】：分流 Jar 程序和 ods -> dwd sql 加工函数，部分代码截图如下：

以及相关的 Flink sql：

--2 dwd_moneyflow_log
CREATE TABLE kafka_in_money (
`env` STRING   comment '游戏环境 qc/cbt/obt/prod',
`hostname` STRING comment '日志所在游戏服务器',
`uuid` STRING comment '日志唯一id',
`message` STRING comment 'tlog信息',
`filebeat_ts` STRING comment 'filebeat采集时间'
) WITH (
  'connector' = 'kafka',
  'topic' = 'ro_sea_tlog_split_moneyflow',
  'properties.bootstrap.servers' = 'emr_kafka1:9092,emr_kafka2:9092,emr_kafka3:9092',
  'properties.group.id' = 'flinksql_kafka_in_moneyflow_v2',
  'scan.startup.mode' = 'group-offsets',
  --'scan.startup.mode' = 'earliest-offset',
  'properties.isolation.level' = 'read_committed',
  'format' = 'json',
  'json.ignore-parse-errors' = 'false'
);

CREATE TABLE kafka_out_money(
  `date` string not NULL  COMMENT '日期',
  `vroleid`  int NULL COMMENT '角色ID',
  `moneytype` int NULL  COMMENT '货币类型', 
  `env` string NULL COMMENT '游戏环境 hdf  /qc/cbt/obt/prod',
  `hostname` string NULL COMMENT '日志所在游戏服务器',
  `uuid`  string NULL COMMENT 'filebeat 采集生成的uuid',
  `filebeat_ts` string NULL COMMENT 'filebeat采集时间',
   flink_ts string NULL COMMENT 'flink写入的消息时间',  
  `gamesvrid` int  NULL  COMMENT '登录游戏服务器编号', 
  `dteventtime` string NULL  COMMENT  '游戏事件的时间, 格式 YYYY-MM-DD HH:MM:SS', 
  `vgameappid` string NULL COMMENT  '游戏APPID', 
  `platid` int NULL  COMMENT 'ios 0 /android 1', 
  `izoneareaid` int NULL  COMMENT '针对分区分服的游戏填写分区id，用来唯一标示一个区；非分区分服游戏请填写0', 
  `vopenid` string NULL COMMENT '用户OPENID号', 
  `vrolename` string NULL COMMENT '角色姓名', 
  `jobid` int  NULL  COMMENT '角色职业   0=巫师 1=……', 
  `gender` int NULL  COMMENT '角色性别 0=男  1=女', 
  `ilevel` int NULL  COMMENT '角色基础等级', 
  `ijoblevel` int NULL  COMMENT '角色职业等级', 
  `playerfriendsnum` int NULL  COMMENT '玩家好友数量', 
  `chargegold` int NULL  COMMENT '角色充值经历（累计充值）',
  `iviplevel` int NULL  COMMENT '角色VIP等级', 
  `createtime` string NULL  COMMENT  '账号创建时间',
  `irolece` int NULL  COMMENT '战力/评分',
  `unionid` int NULL  COMMENT '公会ID',
  `unionname`  string NULL COMMENT '公会名称', 
  `regchannel` int NULL  COMMENT '注册渠道', 
  `loginchannel` int NULL  COMMENT '登录渠道', 
  `sequence` int NULL  COMMENT '用于关联一次动作产生多条不同类型的货币流动日志', 
  `reason` int NULL  COMMENT '行为（货币流动一级原因）',
  `subreason` int NULL  COMMENT '流向（物品流向定义）', 
  `imoney` int NULL  COMMENT '货币变更数量',
  `aftermoney` int NULL  COMMENT '动作后的金钱数',
  `afterboundmoney` int NULL  COMMENT '动作后的绑定金钱数',
  `addorreduce` int NULL  COMMENT '增加或减少: 0是增加; 1是减少', 
  `serialnum` string NULL COMMENT  '流水号', 
  `sourceid` int NULL  COMMENT '渠道号', 
  `cmd` string NULL COMMENT  '命令字', 
  `orderid` string NULL COMMENT  '订单id(包含喵果增加和喵果减少，也包含现金充值订单id)', 
  `imoneytype` int NULL  COMMENT '货币类型2', 
  `distincid` string NULL COMMENT  '访客ID', 
  `deviceuid` string NULL COMMENT  '设备ID', 
  `guildjob` int NULL  COMMENT '公会职位', 
  `regtime` string NULL  COMMENT  '账号注册时间'
) WITH (
   'connector' = 'doris',
    'jdbc-url'='jdbc:mysql://xxx:9030,xxx:9030,xxx:9030',
    'load-url'='xx:8030;xxx:8030;xxx:8030',
    'database-name' = 'ro_sea',
    'table-name' = 'dwd_moneyflow_log',
    'username' = 'root',
    'password' = 'root123',
    'sink.semantic' = 'exactly-once'
);

create view kafka_out_money_view1  as 
select  IF(to_date(SPLIT_INDEX(message,'|',2)) > CURRENT_DATE + interval '1' day,CURRENT_DATE,to_date(SPLIT_INDEX(message,'|',2))) as `date`,
        `env`,`hostname` as hostname,`uuid`,
    try_cast(SPLIT_INDEX(message,'|',1) as int) as gamesvrid               ,                                  
        SPLIT_INDEX(message,'|',2) as dteventtime             ,                                  
        SPLIT_INDEX(message,'|',3) as vgameappid              ,                                  
        try_cast(SPLIT_INDEX(message,'|',4) as int) as platid                  ,                                  
        try_cast(SPLIT_INDEX(message,'|',5)  as int) as izoneareaid             ,                                  
        SPLIT_INDEX(message,'|',6) as vopenid                 ,                                  
        try_cast(SPLIT_INDEX(message,'|',7) as int) as vroleid                 ,                                  
        SPLIT_INDEX(message,'|',8) as vrolename               ,                                  
        try_cast(SPLIT_INDEX(message,'|',9)  as int)  as jobid                   ,                                  
        try_cast(SPLIT_INDEX(message,'|',10) as int) as gender                  ,                                  
        try_cast(SPLIT_INDEX(message,'|',11) as int) as ilevel                  ,                                  
        try_cast(SPLIT_INDEX(message,'|',12) as int) as ijoblevel               ,                                  
        try_cast(SPLIT_INDEX(message,'|',13) as int) as playerfriendsnum        ,                                  
        try_cast(SPLIT_INDEX(message,'|',14) as int) as chargegold              ,                                  
        try_cast(SPLIT_INDEX(message,'|',15) as int) as iviplevel               ,                                  
        SPLIT_INDEX(message,'|',16) as createtime              ,                                  
        try_cast(SPLIT_INDEX(message,'|',17) as int)  as irolece                 ,                                  
        try_cast(SPLIT_INDEX(message,'|',18) as int) as unionid                 ,                                  
        SPLIT_INDEX(message,'|',19) as unionname               ,                                  
        try_cast(SPLIT_INDEX(message,'|',20) as int) as regchannel              ,                                  
        try_cast(SPLIT_INDEX(message,'|',21) as int) as loginchannel            ,                                  
        try_cast(SPLIT_INDEX(message,'|',22) as int) as `sequence`                ,                                  
        try_cast(SPLIT_INDEX(message,'|',23) as int) as `reason`                 ,                                  
        try_cast(SPLIT_INDEX(message,'|',24) as int) as subreason               ,                                  
        try_cast(SPLIT_INDEX(message,'|',25) as int) as moneytype               ,                                  
        try_cast(SPLIT_INDEX(message,'|',26) as int) as imoney                  ,                                  
        try_cast(SPLIT_INDEX(message,'|',27) as int) as aftermoney              ,                                  
        try_cast(SPLIT_INDEX(message,'|',28) as int) as afterboundmoney         ,                                  
        try_cast(SPLIT_INDEX(message,'|',29) as int) as addorreduce             ,                                  
        SPLIT_INDEX(message,'|',30) as serialnum               ,                                  
        try_cast(SPLIT_INDEX(message,'|',31) as int) as sourceid                ,                                  
        SPLIT_INDEX(message,'|',32) as `cmd`                    ,                                  
        SPLIT_INDEX(message,'|',33) as orderid                 ,                                  
        try_cast(SPLIT_INDEX(message,'|',34) as int) as imoneytype              ,                                  
        SPLIT_INDEX(message,'|',35) as distincid               ,                                  
        SPLIT_INDEX(message,'|',36) as deviceuid               ,                                  
        try_cast(SPLIT_INDEX(message,'|',37) as int) as guildjob                ,                                  
        SPLIT_INDEX(message,'|',38) as regtime ,
      filebeat_ts,CURRENT_TIMESTAMP  as flink_ts
from kafka_in_money;

insert into kafka_out_money
select 
cast(`date` as varchar) as `date`,
`vroleid`,
`moneytype`,
`env`,
`hostname`,
`uuid`,
`filebeat_ts`,
cast(`flink_ts` as varchar) as flink_ts,
`gamesvrid`,
`dteventtime`,
`vgameappid`,
`platid`,
`izoneareaid`,
`vopenid`,
`vrolename`,
`jobid`,
`gender`,
`ilevel`,
`ijoblevel`,
`playerfriendsnum`,
`chargegold`,
`iviplevel`,
`createtime`,
`irolece`,
`unionid`,
`unionname`,
`regchannel`,
`loginchannel`,
`sequence`,
`reason`,
`subreason`,
`imoney`,
`aftermoney`,
`afterboundmoney`,
`addorreduce`,
`serialnum`,
`sourceid`,
`cmd`,
`orderid`,
`imoneytype`,
`distincid`,
`deviceuid`,
`guildjob`,
`regtime`
from kafka_out_money_view1;

【广告系统】：使用 Flink SQL 将一行日志数据进行切分解析出各个字段的数据并完成业务计算:

CREATE TABLE IF NOT EXISTS ods_adjust_in (
  log STRING
) WITH (
  'connector' = 'kafka',
  'topic' = 'ad_adjust_callback',
  'properties.bootstrap.servers' = 'emr_kafka1:9092,emr_kafka2:9092,emr_kafka3:9092',
  'properties.group.id' = 'ods_adjust_etl_20231011',
  'properties.max.partition.fetch.bytes' = '4048576',
  'scan.startup.mode' = 'group-offsets',
  'properties.isolation.level' = 'read_committed',
  'format' = 'raw'
);

CREATE TABLE IF NOT EXISTS ods_af_in (
  log STRING
) WITH (
  'connector' = 'kafka',
  'topic' = 'ad_af_callback',
  'properties.bootstrap.servers' = 'emr_kafka1:9092,emr_kafka2:9092,emr_kafka3:9092',
  'properties.max.partition.fetch.bytes' = '4048576',
  'properties.group.id' = 'ods_af_etl_20231011',
  'scan.startup.mode' = 'group-offsets',
  'properties.isolation.level' = 'read_committed',
  'format' = 'raw'
);

CREATE TABLE IF NOT EXISTS ods_mmp_out (
  `date` DATE,
  `mmp_type` STRING,
  `app_id` STRING,
  `event_name` STRING,
  `event_time` TIMESTAMP(3),
  `mmp_id` STRING,
  `distinct_id` STRING,
  `open_id` STRING,
  `account_id` STRING, 
  `os_name` STRING, -- platform
  `country_code` STRING,
  `install_time` TIMESTAMP(3),
  `bundle_id` STRING,
  `media` STRING,
  `channel` STRING,
  `campaign` STRING,
  `campaign_id` STRING,
  `adgroup` STRING,
  `adgroup_id` STRING,
  `ad` STRING,
  `ad_id` STRING,
  `flink_ts` TIMESTAMP(3) comment 'flink处理的消息时间',
  `device_properties` STRING,
  `log` STRING
) WITH (
    'connector' = 'kafka',
    'topic' = 'ods_mmp_log',
    'properties.bootstrap.servers' = 'emr_kafka1:9092,emr_kafka2:9092,emr_kafka3:9092',
    'scan.topic-partition-discovery.interval'='60000',
    'properties.group.id' = 'mmp2etl-out',
    'format' = 'json'
);

INSERT INTO ods_mmp_out
SELECT
   `date`
  ,'Adjust' as `mmp_type`
  ,`app_token` as `app_id`
  ,`event_name`
  ,`event_time`
  ,`adid` as `mmp_id`
  ,`distinct_id`
  ,`open_id`
  ,`account_id`
  ,`os_name`
  ,`country_code`
  ,`install_time`
  ,'' as `bundle_id`
  ,'' as `media`
  ,`network` as `channel`
  ,`campaign`
  ,REGEXP_EXTRACT(`campaign`, '([\\(=])([a-z0-9]+)', 2) as `campaign_id`
  ,`adgroup`
  ,REGEXP_EXTRACT(`adgroup`, '([\\(=])([a-z0-9]+)', 2) as `adgroup_id`
  ,`creative` as `ad`
  ,REGEXP_EXTRACT(`creative`, '([\\(=])([a-z0-9]+)', 2) as `ad_id`
  ,`flink_ts`
  ,`device_properties`
  ,`log`
FROM (
  SELECT
     to_date(FROM_UNIXTIME(cast(JSON_VALUE(log,'$.created_at') as bigint))) as `date`
    ,JSON_VALUE(log,'$.app_token') as `app_token`
    ,JSON_VALUE(log,'$.adid') as `adid`
    ,LOWER(REPLACE( TRIM( COALESCE(JSON_VALUE(log,'$.event_name'), JSON_VALUE(log,'$.activity_kind')) ), ' ', '_')) as `event_name`
    ,TO_TIMESTAMP(FROM_UNIXTIME(cast(JSON_VALUE(log,'$.created_at') as bigint))) as `event_time`
    ,TO_TIMESTAMP(FROM_UNIXTIME(cast(JSON_VALUE(log,'$.installed_at') as bigint))) as `install_time`
    ,LOWER(CASE WHEN (JSON_VALUE(log,'$.network_name') = 'Unattributed') THEN COALESCE(JSON_VALUE(log,'$.fb_install_referrer_publisher_platform'),'facebook') ELSE JSON_VALUE(log,'$.network_name') END) AS `network`
    ,LOWER(CASE WHEN (JSON_VALUE(log,'$.network_name') = 'Unattributed') THEN (concat(JSON_VALUE(log,'$.fb_install_referrer_campaign_group_name'), '(', JSON_VALUE(log,'$.fb_install_referrer_campaign_group_id'), ')')) ELSE JSON_VALUE(log,'$.campaign_name') END) AS `campaign`
    ,LOWER(CASE WHEN (JSON_VALUE(log,'$.network_name') = 'Unattributed') THEN (concat(JSON_VALUE(log,'$.fb_install_referrer_campaign_name'), '(', JSON_VALUE(log,'$.fb_install_referrer_campaign_id'), ')')) ELSE JSON_VALUE(log,'$.adgroup_name') END) AS `adgroup`
    ,LOWER(CASE WHEN (JSON_VALUE(log,'$.network_name') = 'Unattributed') THEN (concat(JSON_VALUE(log,'$.fb_install_referrer_adgroup_name'), '(', JSON_VALUE(log,'$.fb_install_referrer_adgroup_id'), ')')) ELSE JSON_VALUE(log,'$.creative_name') END) AS `creative`
    ,JSON_VALUE(log,'$.os_name') as `os_name`
    ,JSON_VALUE(log,'$.country_code') as `country_code`
    ,JSON_VALUE(JSON_VALUE(log,'$.publisher_parameters'), '$.ta_distinct_id') as `distinct_id`
    ,JSON_VALUE(JSON_VALUE(log,'$.publisher_parameters'), '$.open_id') as `open_id`
    ,JSON_VALUE(JSON_VALUE(log,'$.publisher_parameters'), '$.ta_account_id') as `account_id`
    ,CURRENT_TIMESTAMP as `flink_ts`
    ,JSON_OBJECT(
       'ip' VALUE JSON_VALUE(log,'$.ip')
      ,'ua' VALUE JSON_VALUE(log,'$.ua')
      ,'idfa' VALUE JSON_VALUE(log,'$.idfa')
      ,'idfv' VALUE JSON_VALUE(log,'$.idfv')
      ,'gps_adid' VALUE JSON_VALUE(log,'$.gps_adid')
      ,'android_id' VALUE JSON_VALUE(log,'$.android_id')
      ,'mac_md5' VALUE JSON_VALUE(log,'$.mac_md5')
      ,'oaid' VALUE JSON_VALUE(log,'$.oaid')
      ,'gclid' VALUE JSON_VALUE(log,'$.gclid')
      ,'gbraid' VALUE JSON_VALUE(log,'$.gbraid')
      ,'dcp_wbraid' VALUE JSON_VALUE(log,'$.dcp_wbraid')
    ) as `device_properties`
    ,`log`
  FROM ods_adjust_in 
  WHERE COALESCE(JSON_VALUE(log,'$.activity_kind'), JSON_VALUE(log,'$.event_name')) not in ('impression', 'click')
)
UNION ALL 
SELECT
  to_date(CONVERT_TZ(JSON_VALUE(log,'$.event_time'), 'UTC', 'Asia/Shanghai')) as `date`
  ,'AppsFlyer' as `mmp_type`
  ,JSON_VALUE(log,'$.app_id') as `app_id`
  ,LOWER(REPLACE( TRIM(JSON_VALUE(log,'$.event_name') ), ' ', '-')) as `event_name`
  ,TO_TIMESTAMP(CONVERT_TZ(JSON_VALUE(log,'$.event_time'), 'UTC', 'Asia/Shanghai')) as `event_time`
  ,JSON_VALUE(log,'$.appsflyer_id') as `mmp_id`
  ,JSON_VALUE(JSON_VALUE(log,'$.custom_data'), '$.ta_distinct_id') as `distinct_id`
  ,JSON_VALUE(JSON_VALUE(log,'$.custom_data'), '$.open_id') as `open_id`
  ,JSON_VALUE(JSON_VALUE(log,'$.custom_data'), '$.ta_account_id') as `account_id`
  ,LOWER(JSON_VALUE(log,'$.platform')) AS `os_name`
  ,LOWER(JSON_VALUE(log,'$.country_code')) as `country_code`
  ,TO_TIMESTAMP(CONVERT_TZ(JSON_VALUE(log,'$.install_time'), 'UTC', 'Asia/Shanghai')) as `install_time`
  ,LOWER(JSON_VALUE(log,'$.bundle_id')) AS `bundle_id`
  ,LOWER(JSON_VALUE(log,'$.media_source')) AS `media`
  ,LOWER(JSON_VALUE(log,'$.af_channel')) AS `channel`
  ,CONCAT(LOWER(JSON_VALUE(log,'$.campaign')), ' (', LOWER(JSON_VALUE(log,'$.af_c_id')), ')') AS `campaign`
  ,LOWER(JSON_VALUE(log,'$.af_c_id')) AS `campaign_id`
  ,CONCAT(LOWER(JSON_VALUE(log,'$.af_adset')), ' (', LOWER(JSON_VALUE(log,'$.af_adset_id')), ')') AS `adgroup`
  ,LOWER(JSON_VALUE(log,'$.af_adset_id')) AS `adgroup_id`
  ,CONCAT(LOWER(JSON_VALUE(log,'$.af_ad')), ' (', LOWER(JSON_VALUE(log,'$.af_ad_id')), ')') AS `ad`
  ,LOWER(JSON_VALUE(log,'$.af_ad_id')) AS `ad_id`
  ,CURRENT_TIMESTAMP as `flink_ts`
  ,JSON_OBJECT(
     'ip' VALUE JSON_VALUE(log,'$.ip')
    ,'ua' VALUE JSON_VALUE(log,'$.user_agent')
    ,'idfa' VALUE JSON_VALUE(log,'$.idfa')
    ,'idfv' VALUE JSON_VALUE(log,'$.idfv')
    ,'gps_adid' VALUE JSON_VALUE(log,'$.advertising_id')
    ,'android_id' VALUE JSON_VALUE(log,'$.android_id')
    ,'oaid' VALUE JSON_VALUE(log,'$.oaid')
  ) as `device_properties`
  ,`log`
FROM ods_af_in;