多云环境下实时计算场景实践经验

介绍

随着这几年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 日常也会不定期写一些文章和思考。 欢迎感兴趣的朋友 一起探讨 学习， 好了 我们下期再见~~~。