介绍

随着这几年 Flink 社区的推广以及 Flink SQL 以及 Flink CDC 等功能的成熟，国内大厂基本上实时计算的应用场景，都逐步以 Flink 来做解决方案。 笔者也是同样，作为负责公司实时平台建设，也是基于开源 Flink 为内核，构建一整套跨多云，多区域的实时计算平台。

云上解决方案

AWS

AWS 托管的 Apache Flink 服务

AWS 托管的 Apache Flink 服务，支持 Flink SQL 和 jar 方式提交任务，通过 IAM 赋权，可以处理 AWS 基础数据服务如：MSK，S3，Kinesis Data Streams 等。收费模式是按消耗的 KPU（1vCPU 4GB）的量来计费。

AWS EMR Flink

AWS EMR（AWS Elastic MapReduce）是集齐数据接入、存储、计算、交互式查询、机器学习等一系列开源社区组件封装的云上托管大数据平台，用户可以基于 EMR 迅速拉起一套大数据集群，用于大规模数据处理、分析，使用时可根据实际业务所需灵活调配计算资源，一定程度上降低底层基础设施运维成本。Flink 是其中一个可选的开源组件，整体上任务提交是通过 cli 方式或者 zeppelin 方式目前支持的版本最新是 apache flink 1.17 内核

阿里云

实时计算 Flink 版

实时计算 Flink 版是阿里云提供的全托管 Serverless Flink 云服务，具备实时应用的作业开发、数据调试、运行与监控、自动调优、智能诊断等全生命周期能力。内核引擎 100%兼容 Apache Flink，2 倍性能提升，拥有 FlinkCDC、动态 CEP 等企业级增值功能，内置丰富上下游连接器，助力企业构建高效、稳定和强大的实时数据应用。

Flink 的母公司是阿里收购的，同时有对应的商业版本ververica，所以在阿里上使用的是号称 100%兼容开源版的商业版 flink vvr , 同时号称通过基准测试是开源版性能的 2-3 倍。这个笔者没有仔细考证，但是阿里家的 flink 确实会比开源版丰富了很多功能以及组件，大家感兴趣的可以了解下阿里官方关于两者的功能对比，具体原文如下：实时计算Flink版与开源 Apache Flink 性能对比

Aliyun EMR Flink

开源大数据平台 E-MapReduce（简称“EMR”）是云原生开源大数据平台，为客户提供简单易集成的 Hadoop、Hive、Spark、StarRocks、Flink、Presto、ClickHouse 等开源大数据计算和存储引擎。EMR 计算资源支持灵活的弹性控制。EMR 支持 on ECS、on ACK 以及 Serverless 多种部署形态。Flink 是其中一个可选的开源组件，整体上任务提交也是通过 cli 方式目前支持的版本最新是基于 flink 1.15 vvr 内核

华为云

实时流计算服务 CS

不是单独存在的服务，而是数据湖探索 DLI 的一部分，个人没有尝试使用过，看官方文档理解主要就是其中 FLink 任务提交的部分，同样支持 SQL 和 jar 形式，但是整体上版本根据缓慢，截止文章发布只有适配 flink 1.12 和 flink 1.10 版本。

华为云 MRS Flink

云原生数据湖 MRS（MapReduce Service）为客户提供 Hudi、ClickHouse、Spark、Flink、Kafka、HBase 等 Hadoop 生态的高性能大数据组件，支持数据湖、数据仓库、BI、AI 融合等能力。MRS 同时支持混合云和公有云两种形态：混合云版本，一个架构实现离线、实时、逻辑三种数据湖，以云原生架构助力客户智能升级；公有云版本，协助客户快速构建低成本、灵活开放、安全可靠的一站式大数据平台。Flink 是其中一个可选的开源组件，整体上任务提交也是通过 cli 方式目前支持的版本是基于 flink 1.15.0 内核

云上总结

整体上 三朵云（AWS，Aliyun，Huawei），都提供了单独 flink 实时服务以及基于大数据集群的 flink 组件 功能。如果直接使用云上托管服务，整体上手更快，同时资源伸缩是可以快速基于处理数据量的响应，相对的弊端就是，整体服务过于封闭，无法进行定制化改造，随着任务数膨胀，任务与任务之间相对独立，整体维护管理，都需要依赖云服务，进行深度绑定。服务之间的不能公用元数据，数据血缘目前也没有哪家云厂商提供了解决方案。使用集群上 flink 更偏定制化，方便接入公司的服务，以及定制改造。整体基于 yarn 来调度维护，需要维护资源的调度以及资源，前期就需要评估好资源规模以及后续增长。

统一平台解决方案

Flink Catalogs

flink 支持外部 catalogs 解决方案，官方实现了三种，GenericInMemoryCatalog，HiveCatalog，JdbcCatalog 三种实现方式，同时也支持用户自定义 Catalog，官方文档：Flink Catalogs 我们可以外部统一建设 Flink 的 catalog，实现元数据统一运维功能，脱离特定云厂商绑定，同时又可以实现多任务公用元数据。

部署方式 Master-Work

通过统一的运维平台，创建 flink 任务，以及相关 flink 配置项，然后下发 flink cli 命令到每朵云上，相当于每个云集群都需要部署 work 节点，接受平台下发的指令，以及上报对应的任务状态和 mertics 等。

平台总结

基于 Flink Catalog 特性可以构建统一元数据，脱离云厂商绑定，通过 Master-work 模式，可以通过统一运维平台，来运维多云环境。 这套解决方案后面其实可以做很多事情，比如：

1. 统一收集日志，监控指标

2. 多云环境切换，因为任务信息以及元数据都在平台维护，所以云厂商集群主要承担计算资源角色，理论上可以无感切换任务到其他云上（当然每个云环境的 Flink hadoop 版本问题需要兼容，适配）

3. 区域容灾方案，通过这套方案可以做到实时任务 区域级别容灾方案。

实践经验

总结一些 构建平台端过程中，遇到的一些问题以及解决方案

离线实时混部

最初阶段，离线，实时任务部署到在一个集群上，经常会在凌晨之后，离线业务高峰时，发生实时任务异常终止问题。 经排查，主要是基于 hadoop on yarn 集群，yarn 对内存资源管控粒度不够严格，当大量离线任务申请资源时，可能在短时间内，离线任务超过了 yarn 限定的内存资源瓶颈，导致 yarn nodemanager 会自动杀掉节点上的运行容器。spark 离线任务本身，对重试机制友好，flink 实时任务场景，因为业务属性敏感性，不能配置过多重启次数，导致实时任务可能会在此场景下任务终止。

第一版解决方案：

EMR YARN 默认以 capacity-scheduler 策略管理及调度集群计算资源，通过设置离线实时不同队列方式，尝试将整个集群资源分割离线，实时队列。问题依旧会是不是复现，因为本质上无法保证离线任务和实时任务分配到同一 nodemanager 上，所以依旧会有可能发生上述异常情况。

第二版解决方案：

通过 yarn label 方式，单独标识计算节点，通过排他性的方式，独立于其他节点，只允许指定队列任务提交到该节点上。通过此次改造，实时任务稳定性得到了明显提高。但是依旧会有极少状态影响到 flink 实时任务，比如：当离线任务对底层 hdfs 压力过大，导致集群部分 namenode 压力过大，短时间 hdfs 服务波动，因为当时 flink 本身的 checkpoint 以及状态依赖 hdfs 故依旧会影响到 flink 实时任务稳定性。

第三版解决方案：

实时集群独立，存算分离，集群只是被当作计算单元，状态存储放在外置服务（AWS s3 aliyun oss huawei obs）至此，整个集群的稳定性得到了提高，实时流任务的 SLA 的保证基本上等同于集群本身的 SLA 保证以及依赖组件的（Kafka 存储服务）SLA 的保障。

集群部署适配

AWS EMR 集群

1. AWS EMR Master 节点 尽量选配 HA 方式，因为平台架构中 存在 work 节点，部署在 master 节点上，承担任务提交入口的角色，同时 master 如果出现异常情况会导致整个集群不可用

2. AWS EMR core 节点，不需要配置过多，因为本身既是计算资源同时又是承载着 datanode 角色，实时任务本身状态已经不再依赖集群存储，只有少量日志以及任务提交的依赖包会依赖本地存储，所以 core 节点不易过多。并且 core 节点本身后续扩缩容也会存在存储副本数的问题，一般生产环境配置好具体 core 节点数据，后续一般不变更。同时需要注意 EMR 5 及之前版本，默认时强制 AM 只能提交到 core 节点，通过 label 标签进行了限制，这些可以在集群 bootstrap 节点，进行修改。

3. AWS EMR task 节点 ，主要是关注自身业务状况，设置统一实例组，这样以后扩缩容资源比可以更灵活，同时因为实时任务特性，不要选用 spot 模式，不然真的会经常因为申请不到资源或者被抢占走导致任务挂断。

Aliyun EMR 集群

1. aws 上面提到的几点，同样适配于阿里云的 emr ，他们俩基础功能很相似。

2. aliyun emr gateway， 阿里云会有单独设置提交机的功能，这样就不需要把 work 节点部署到 集群内部，可以做到解耦。

3. flink 版本是 vvr 商业版，但是可以根据对应开源版本进行适配，内核都是使用相同的。

Huawei MRS 集群

1. 基本上上面经验套用即可，同时主要时因为华为云 flink 的适配，有些自己的包，同时 obs 的插件支持调试 需要注意下。

服务监控

可观测性 是必不可少的，日常服务监控大家一定要重视

1. 因为三朵云都是基于 flink on yarn 方式部署，所以会通过 yarn 本身的 api 进行基础任务存活监控

2. 同时 flink metrics 推送有很多实现方式，参考官方资料：Flink Metric Reporters 大家可以结合公司自己的运维场景，将 metrics 统一推送 收集，方便监控任务状态

3. 日志收集，集群上的日志是排查问题的重要途经，所以一般我们会将任务异常的日志进行统一收集，这个也可以结合场景来定制化收集

4. 中间件服务监控： 比如 Kafka 的一些重要指标 lag ，req count/s write count/s 这些都可以用来监控整体链路状态，防止突发流量等。

多区域容灾

容灾策略

如果对灾难恢复感兴趣的朋友，可以先了解我这篇文章： 云环境下的灾难恢复解决方案

容灾策略的选择，取决于大家业务场景对 RPO 和 RTO 的要求，当然要求最高的，就是异地多活了，当然实现难度也是最高的。既然已经上云了，当然容灾就会借助云的优势，做成多云多活，这里只是提一些多云多活实践过程中，大家需要关注的点。

实践经验：

1. 定制 flink 版本，适配多云，无法要求每朵云，基础版本完全对齐（AWS，Huawei 是基于 apache 来构建的，Aliyun 是基于商业版的），所以我们如果想平迁多云，则需要自封装内核组件，进行集群间适配，这句话背后的工作量属实不小，但是既然选择多云道路，这个也是必须要做的。

2. 平台端的多云架构，因为元数据已经脱离集群，所以整体上基于 Catalog 保持在外部存储介质（Mysql Postgres )这些也同样要有 多云环境的容灾考虑。

3. 整体服务的 SLA 要考虑到上下游链路服务组件的 SLA，而不单是计算单元本身。

4. 状态存储（checkpoint savepoint state）依托云服务存储，也需要考虑跨区域复制，以及版本快照等功能，以求达到业务要求的 RPO

5. 服务监控的可观测性要充分，云上服务都要认为是不可靠的，基于此观念出发来设计服务的容灾备份功能。笔者实践过程中遇到过不止一次 AWS EMR 故障 导致整体集群不可用。

6. 容灾不要过度设计，都是结合自身业务场景需求，成本考量等综合因素。

总结

以上是笔者个人在实践过程中对云上实时集群的建设上一些总结，可能有些地方还有不足。比如后面建设也在考虑 实现 flink on k8s 方式，实现资源更细粒度的把控，节省成本。

云计算已经是当下技术人员的必学的一门课程，如果有时间也鼓励大家可以多了解学习，提升自己的专业能力，阿里云也有相关认证 ACP 和 ACE，感兴趣的朋友也可以了解一下。如果有任何问题，需要沟通交流也可以添加我的个人微信 coder_wukong，备注：云计算，或者关注我的公众号 WuKongCoder 日常也会不定期写一些文章和思考。欢迎感兴趣的朋友 一起探讨 学习， 好了 我们下期再见~~~。