关于flink:联通实时计算平台演进与实践

摘要：本篇内容整顿自联通大数据技术专家穆纯进在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含：

1. 实时计算平台背景
2. 实时计算平台演进与实际
3. 基于 Flink 的集群治理
4. 将来布局

FFA 2021 直播回放 & 演讲 PDF 下载

一、实时计算平台背景

首先理解一下实时计算平台的背景。电信行业的业务零碎非常复杂，所以它的数据源也是十分多的，目前实时计算平台接入了 30 多种数据源，这 30 多种数据源绝对于总的数据品种来说是比拟小的。即便这样，咱们的数据量也达到了万亿级别，每天有 600TB 的数据增量，而且咱们接入的数据源品种和大小还在持续增长。平台的用户来自于全国 31 个省份公司以及联通团体的各个子公司，尤其是在节假日会有大量用户去做规定的订阅。用户想要获取数据，须要在平台上进行订阅，咱们会将数据源封装成标准化的场景，目前咱们有 26 种标准化场景，撑持了 5000 多个规定的订阅。

订阅场景有三大类。

• 用户行为类的场景有 14 个，比方地位类的场景，是对于用户进入某个区域后停留了多长时间，还有终端登网，是对于用户连贯了哪个网络，4G 还是 5G 网，以及漫游、语音、产品订购等各种场景；
• 用户应用类的场景有 6 个，比方用户应用了多少流量、账户余额是多少、是否有欠费停机等；
• 用户触网类的场景大略有 10 个，比方业务的办理、充值缴费，还有新入户入网等。

对于实时计算平台来说，实时性的要求是很高的。数据从产生到进入咱们的零碎，大略有 5~20 秒的提早，通过零碎失常解决之后大略有 3~10 秒的提早，咱们容许的最大提早是 5 分钟，所以必须做好实时计算平台端到端的提早的监控。

用户定义的场景符合要求的数据起码要下发一次，这个是有严格要求的，不能漏发，而 Flink 很好地满足了这个需要；数据的准确性要求须要达到 95%，平台实时下发的数据会保留一份到 HDFS 上，每天咱们会抽取局部订阅和离线数据，依照雷同的规定进行数据生成以及数据品质比对，如果差别过大就须要找到起因并保障后续下发数据的品质。

本次分享更多的是 Flink 在电信行业的一次企业的深度实际：如何应用 Flink 更好地撑持咱们的需要。

通用的平台无奈撑持咱们的非凡场景，比方以地位类的场景为例，咱们会在地图上画多个电子围栏，当用户进入围栏并在围栏外面停留一段时间，并且满足用户设定性别、年龄、职业、支出等用户特色，这样的数据才进行下发。

咱们的平台能够认为是一个实时场景中台，将数据进行实时的荡涤解决，封装成反对多个条件组合的简单场景，集约化地提供规范实时能力的同时，更进一步凑近业务，提供给业务方简略易用、门槛很低的接入形式。业务方通过调用标准化的接口，通过网关认证鉴权，才能够订阅咱们的场景。订阅胜利之后会将 Kafka 的一些连贯信息和数据的 Schema 返回给订阅用户，用户订阅的筛选条件跟数据流进行匹配，匹配胜利之后会以 Kafka 的模式再进行数据下发。以上就是咱们的实时计算平台与上游零碎交互的流程。

二、实时计算平台演进与实际

2020 年以前，咱们的平台是应用 Kafka + Spark Streaming 来实现的，而且是洽购厂商的第三方的平台，遇到了很多问题和瓶颈，难以满足咱们日常的需要。当初很多企业包含咱们都正在进行数字化改革，零碎的自研比例也越来越高，再加上需要的驱动，自研、可灵便定制、可控的零碎是火烧眉毛了。所以 2020 年咱们开始接触了 Flink，并实现了基于 Flink 的实时计算平台，这个过程中咱们也领会到了开源的魅力，今后也会更多地参加到社区中来。

咱们的既往平台存在很多问题。首先是三方黑盒平台，咱们应用厂商的第三方平台，过多依赖了内部零碎；并且在大并发下内部零碎的负载会十分高，不能灵便定制个性化的需要；Kafka 的负载也特地高，因为每一个规定的订阅都会对应多个 topic，所以随着规定的减少，topic 和分区的数量也会呈线性增长，导致延时比拟高。每个订阅场景会对应多个实时流，而每个实时流都会占用内存和 CPU，场景过多会导致资源耗费增长以及资源负载过高；再就是撑持的体量小，撑持场景的订阅数无限的，比方逢年过节用户订阅的数量剧增，常常须要紧急救火，无奈满足日益增长的需要；此外，监控粒度也不够，无奈灵便定制监控，无奈进行端到端的监控，采纳人肉的排查比拟多。

基于上述问题，咱们全面自研了基于 Flink 的实时计算平台，依据每个场景的特点进行最优的定制，最大化资源的应用效率。同时咱们利用 Flink 的状态缩小内部依赖，升高了程序的复杂度，晋升程序的性能。通过灵便定制实现了资源的优化，雷同体量的需要下大大节约了资源。同时为了保证系统的低提早率，咱们进行了端到端的监控，比方减少了数据的积压、提早、数据断传监控。

整个平台的架构比较简单，采纳了 Flink on Yarn 的运行形式，内部只依赖 HBase，数据是以 Kafka 接入并由 Kafka 下发。

Flink 的集群是独立搭建的，它独享了 550 台服务器，没有和离线计算混用，因为它对稳定性要求比拟高, 须要日均解决 1.5 万亿数据，近 600TB 的数据增量。

咱们对场景深度定制的次要起因是数据量大，同一个场景的订阅又十分多，而且每个订阅的条件又是不一样的。从 Kafka 读取一条数据的时候，这条数据要匹配多个规定，匹配中后才会下发到规定对应的 topic 外面。所以不论有多少订阅，只从 Kafka 中读取数据一次，这样可能升高对 Kafka 的耗费。

手机打电话或者上网都会连贯到基站，雷同基站的数据会按肯定的时长窗口和固定音讯进行压缩，比方三秒钟一个窗口，或者音讯达到了 1000 再进行触发，这样上游接管到的音讯就会有量级的升高。而后是围栏匹配，内部零碎的压力是基于基站规模的，而不是基于音讯数目。再就是充分利用了 Flink 的状态，当人员进入和滞留的时候会存入状态，用 RocksDB 状态后端缩小了内部依赖，简化了零碎的复杂度。此外，咱们还实现了亿级标签的关联不依赖内部零碎。通过数据压缩、围栏匹配、进入驻留、标签关联后，咱们才开始正式匹配规定。

用户订阅场景后，订阅的规定会以 Flink CDC 的形式同步到实时计算平台，这样能够保障提早比拟低。因为人群的进入滞留会存入到状态，基于 RocksDB 的状态后端数据量比拟大，咱们会通过解析状态的数据进行问题排查，比方用户到底有没有在围栏之中。

咱们自定义了 HASH 算法，在不依赖于内部零碎的状况下，实现了亿级标签的关联。

在大并发下，如果每个用户都要关联内部零碎获取标签的信息，那么内部零碎的压力会十分大，尤其是在咱们联通这么大数据量的状况下，依赖于内部零碎建设的老本也很高，这些标签都是离线标签，数据绝对比较稳定，比方有日更的有月更的。所以咱们对用户应用自定义的哈希算法，比方有个手机号，依照哈希算法它被调配到 index 为 0 的 task_0 实例中，再通过离线计算将标签文件中的手机号也依照雷同的哈希算法调配到编号为 0 的 0_tag 中。

task_0 实例在 open 办法中获取本人的 index 编号，即 index=0，而后拼接出标签文件名 0.tag，并将文件加载到本人的内存中。Task_0 实例接管到手机号后就能够从本地内存获取到此手机号的标签数据，不会造成内存的冗余节约，晋升了零碎性能，缩小了内部依赖。

有标签更新的时候，open 办法也会主动加载新的标签，并刷新到本人的内存中。

上图是咱们做的端到端的时延监控。因为咱们的业务对提早要求比拟高，所以咱们进行了事件工夫的打标，比方进出 Kafka 工夫的打标，这里的事件就是音讯。对于算子的提早监控，咱们依据打标的工夫和以后的工夫计算出提早，这里并不是每条音讯来了之后都去计算，而是采纳抽样的形式。

对积压断传也做了监控，是通过采集 Kafka offset 进行前后比照来判断的，另外还有对数据提早的监控，利用事件的工夫和以后的工夫来计算提早，能够监控上游零碎的数据提早。

上图是端到端提早监控和反压监控的图表。能够看到端到端的提早失常是在 2~6 秒之间，也合乎咱们的预期，因为定位的条件是比较复杂的。咱们还对反压进行了监控，通过监控算子 input channel 的使用率来定位每个算子产生的反压，比方第二个图呈现了重大的反压且继续了一段时间，这时候咱们须要定位到具体的算子，而后去排查起因，来保证系统的低提早。

上图是咱们对 Kafka 集群中的每个 topic 分区的 offset，以及对每个消费者生产到的地位进行采集来定位它的断传和积压。

首先制订一个 source 来获取 topic 列表和消费者组列表，再这些列表下发到上游，上游的算子能够采纳分布式的形式去采集 offset 值，也是利用了 Flink 的个性。最初写入 Clickhouse 中进行剖析。

Flink 日常监控次要包含以下几类：

• Flink 作业的监控、告警接入联通对立告警天眼平台；
• 作业的运行状态、checkpoint 的异样耗时；
• 算子的时延、反压、流量、条数；
• taskmanager CPU、内存的使用率，JVM GC 等指标的监控。

三、基于 Flink 的集群治理

咱们还基于 Flink 搭建了咱们的集群治理平台。搭建这个平台的背景是咱们的总集群节点达到了 1 万多台，单集群最大有 900 个节点，总共 40 多个集群，总数据量单正本达到了 100 个 PB，每天有 60 万个作业运行，单个集群的 NameNode 的文件数最大达到了 1.5 亿。

随着公司业务的高速倒退，数据的需要越来越简单，所须要的算力也越来越大，集群的规模也越来越大，承载的数据产品也越来越多，导致 Hadoop 集群面临很大的挑战：

• 文件数比拟多对 nameNode 造成很大的压力，影响存储系统的稳固。
• 小文件特地多，导致读取同样数据量的时候须要扫描更多文件，导致更多 NameNode RPC。
• 空文件多，须要扫描更多的文件，导致更多的 RPC。
• 均匀文件比拟小，从宏观上也体现出了小文件数比拟多的。
• 生产上会继续产生文件，作业输入的文件要进行调优。
• 冷数据多，短少清理的机制，节约存储资源。
• 资源负载高，而且扩容老本又太大，扩容了也无奈撑持太长时间。
• 作业耗时长影响产品的交付。
• 作业耗费资源大，占用太多的 CPU、核数和内存。
• 作业存在数据歪斜，导致执行工夫十分长。

针对这些挑战，咱们搭建了基于 Flink 的集群治理架构，通过采集资源队列的信息，解析 NameNode 的元数据文件 Fsimage，采集计算引擎的作业等信息等，而后对集群做 HDFS 画像、作业画像，数据血统、冗余计算画像、RPC 画像以及资源画像。

资源画像：咱们会同时对多个集群的多个资源队列的状况比方它的 IO、metric 等进行分钟级的采集，能够实时查看整个集群和细分队列的资源应用趋势。

存储画像：咱们以无侵入的形式对多集群的分布式存储进行全局性的多维度的剖析。比方文件数到底散布在哪里，小文件散布在哪里，空文件散布在哪里。对于冷数据的散布，咱们对每个数据库每张表的分区目录也做了精细化的画像。

作业画像：对多集群全产品线不同计算引擎的作业，咱们进行实时采集，从工夫维度、队列维度以及作业提交起源等多个维度，从耗时耗资源，数据歪斜、大吞吐量、高 RPC 的作业等多方面进行洞察，找出有问题的作业，筛选出那些待优化的作业。

数据血统：通过剖析生产环境 10 万级别的 SQL 语句，绘制出无侵入的、全局的、高精准的数据血缘关系。并在任意周期内提供了数据表级 / 账户级的调用频次、数据表的依赖关系、产线加工的流程变更、加工故障的影响范畴和垃圾表的洞察等性能。

此外咱们还做了用户操作审计和元数据方面的一些画像。

上图是集群治理存储大屏。除了一些宏观指标比方总文件数、空文件数、空文件夹，还有冷目录数、冷数据量和小文件的占比等。咱们还对冷数据进行剖析，比方哪些数据最初拜访在某个月的数据量有多大，由此能够看到冷数据的工夫散布；还有比方 10 兆以下、50 兆以下、100 兆以下的文件散布在哪些租户上。除了这些指标，还能够精确定位到哪个库、哪张表、哪个分区存在小文件。

上图是集群治理的成果展现，能够看到资源负载达到 100% 的时长也显著缩短，文件数升高了 60% 以上，RPC 负载也大幅升高。每年会有千万级别的老本节约，解决了长时间的资源缓和问题，升高了扩容的机器数。

四、将来布局

目前咱们还没有一个欠缺的实时流治理平台，且监控比拟扩散，研发通用的治理和监控平台势在必行。

面对日益增长的需要，深度定制化尽管节约了资源，晋升了撑持的规模，然而它的开发效率并不现实。针对数据量不大的场景，咱们也思考了应用 Flink SQL 来搭建通用的平台，以此来晋升研发效率。

最初，咱们还会持续摸索 Flink 在数据湖中的利用。

FFA 2021 直播回放 & 演讲 PDF 下载

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～