关于Flink:2021-年网易云音乐实时计算平台发展和挑战

网易云音乐从 2018 年开始搭建实时计算平台，通过几年的倒退曾经渗透到云音乐的各个业务当中。本文是大愚老师的一篇实际分享，将从一个日常运维问题登程，率领大家理解云音乐实时计算平台的一些工作进展和将来布局。次要内容为：

1. 平台性能
2. 批流一体
3. 将来布局

网易云音乐实时数仓平台上线当前，通过一年半的倒退，整体实时数仓曾经初具规模，咱们已有实时数仓表 300+，运行中的工作数有 1200+。其中 1000 左右的工作是 SQL 工作，Kafka 总进口流量达到到 18GB/S，总用户数达到了 200+。

数据量和用户的增长也给数据平台的易用性以及稳定性带来了了越来越多的挑战，蕴含 Kafka 的稳定性、集群的稳定性、运维工作的挑战以及很多晚期的技术债；业务的增长，暴露出了基建的单薄，也给咱们积攒了很多平台建设和运维的教训。

一、平台性能

咱们平台整体的的性能大家能够参考《云音乐实时数仓技术改造以及将来的一些布局》，这里将次要介绍咱们最新的一些工作：

“我的工作提早了，怎么扩容都不行，这是为什么？”

在日常运维工作中这是咱们常常遇到的问题，往往也是比拟消耗工夫的问题。导致这种这种问题的起因有很多，为了解决这个问题，咱们做了一些工作来加强咱们的运维能力。

1. IO 指标欠缺

IO 问题是导致以上问题经常出现的起因之一，蕴含音讯读取效率、维表 JOIN 效率、SINK 效率等等，第三方存储的性能以及稳定性，间接影响实时工作的稳定性，为了疾速定位相干问题，咱们增加了很多 IO 相干 Metric 指标。

1.1 Kafka 生产侧的一些性能指标

1.2 读取反序列化指标

蕴含：

• 反序列化的 RT
• 反序列化的谬误比例

在 Format 侧咱们开发了一套 Format 代理，反对在不批改原有 format 代码的状况下，上报相干 metirc 指标，疏忽谬误数据等性能。只有增加属性 format.proxy 指定代理类就能够反对不同形式的 Format 封装。

比方咱们指定 format.proxy=magina，就能够反对上报上述的性能指标；指定 format.proxy=ds 就能够反对解析 ds 封装的日志格局，应用被代理的 Format 解析 DS 中的 Body 局部，不须要独自为 DS 封装的日志格局开发 Format，且同样会上报性能相干指标，反对疏忽谬误音讯等性能。

1.3 维表 JOIN 相干指标

在维表 JOIN 侧, 咱们增加了：

• 数据查问的响应工夫
• 本地缓存的命中率
• 查问产生重试的比例
• 胜利 JOIN 上的数据的比例等

1.4 数据写入的一些性能指标

• 数据序列化的 RT
• 数据写入内部数据源的均匀响应工夫等

整套 IO 相干指标的实现，咱们全副是在 Flink Connector 的顶层接口做了一些公共的封装，重构了相干 Connector 的代码，只有依照咱们本人的接口实现 Connector，无需关怀细节指标的上报，这些指标都会自动化的上报进去。

2. Kafka 分区问题

Kafka 分区的限度也是常常导致咱们程序性能无奈扩大的起因，出于 Exactly Once 的实现、读取性能、以及读取稳定性的思考，Flink 采纳被动拉取的形式读取 Kafka 音讯，这种形式限度了咱们读取 Kafka 音讯的工作数，大大限度咱们工作性能的扩张能力，以上面这个 case 为例：

SET 'table.exec.state.ttl' = '1h';
SET 'table.exec.mini-batch.enabled' = 'true';
SET 'table.exec.mini-batch.allow-latency' = '10s';
SET 'table.exec.mini-batch.size' = '100000';
INSERT INTO music_kudu_online.music_kudu_internal.ads_ab_rtrs_user_metric_hour
SELECT 
from_unixtime(`timestamp`, 'yyyy-MM-dd') as dt,
from_unixtime(`timestamp`, 'HH')         as `hour`,
os, sceneid, parent_exp, `exp`, exp_type, userid,
count(1) pv
FROM iplay_ods.ods_rtrs_ab_log 
INNER JOIN abtest_online.abtest.abtest_sence_metric_relation
FOR SYSTEM_TIME AS OF user_metric.proctime
ON ods_rtrs_ab_log.sceneid = abtest_sence_metric_relation.sceneid 
GROUP BY from_unixtime(`timestamp`, 'yyyy-MM-dd'),  
         from_unixtime(`timestamp`,‘HH’), 
         os, sceneid, parent_exp, `exp`, exp_type, userid

这是一个实时全聚合工作，在原始的 FLINK 中这段 SQL 执行的 DAG 大略是这样的：

如果咱们读取的流表 ods_rtrs_ab_log 有 5 个分区，咱们的 SQL 工作有七个并发，因为受到 Kafka 分区数的影响，加上 FLINK 自身作业链的优化，咱们的音讯的读取、维表 JOIN、MINI BATCH 的操作全副受到了 Kafka 分区的影响，无奈扩大，特地是对于维表 JOIN 这种 IO 操作来说，工作的并发度重大影响了整体程序的性能，这个时候我只能通过扩容 Kafka 的分区数来晋升性能。

然而这种操作十分重，而且很有可能会影响其它读取这张流表的工作；为了解决这个问题，咱们对 Kafka 的 Connector 做了一些革新，反对通过配置多增加一步 Shuffle 操作，比方在下面的配置当中咱们增加了配置：

'connector.rebalance.keys' = 'sceneid,parent_exp,userid'

音讯会在读取当前依照 sceneid,parent_exp,userid 等字段进行 hash 分片，这样大大提高了整体程序的性能扩展性，而且通过指定字段的 keyBy 操作，能够大大提高维表 JOIN 缓存的命中率，进步 MINI BATCH 的性能和效率。

除了以上配置以外，咱们还反对增加随机的 Rebalance 操作、Rescale 操作以及解析行为的拆解，来进一步晋升整体程序性能的扩大，这里须要留神的是额定 Shuffle 操作，会带来更多线程和网络开销，在配置这些操作的同时须要同时关注机器的负载状况，增加额定的 Shuffle 操作尽管能晋升程序的扩展性，然而因为额定网络和线程开销，如果机器自身性能不行的话，很有可能会事与愿违，在雷同的资源状况下性能变得更差，这点须要依据本人程序以及环境状况进行配置。

3. Kafka 应用优化

随着流量的飞速增长 Kafka 的稳定性也是咱们面临的次要难题，包含 Kafka 的机柜带宽问题、跨机房带宽问题、Kafka 扩缩容的抖动问题、还有 Kafka 自身配置问题等等，基本上大家能遇到的问题咱们都遇到了，为了解决以上问题咱们做了以下工作：

3.1 开发镜像服务，解决带宽问题，保障高优先级工作

咱们通过 FLINK 本人开发了一套镜像服务，在不同的机房模块间别离部署了一套 Kafka 集群，通过镜像服务同步两套 Kafak 集群的数据，主 Kafka 提供给比拟重要 P0 级别的实时工作，其它不是特地重要的工作读取镜像集群的数据。

咱们通过 Yarn Label 技术，通过不同队列的抉择来管制工作所在的机房，来缩小跨机房带宽的耗费，为了不便用户切换不同的 Kafka 集群，咱们在 Flink 流表侧也做了一些革新，反对一张流表同时挂载多个 Kafka 集群，只有通过简略的配置就能够随便切换 Kafka 集群，通过一轮工作整顿和切换，Kafka 带宽应用状况有了大大的改善：

3.2 Kafka 监控欠缺

在日常的工作中，咱们发现很多开发对 Kafka 自身并不太理解，运维因为教训的有余在初期对整体 Kafka 的管控也不是那么的严格，导致在应用上有很多问题。所以咱们整合了音乐外部的 Kafka 监控服务的数据，联合咱们平台的工作血统，开发了本人的一套 Kafka 监控服务。

目前这套零碎整体还比拟高级，除了关联了 Kafka、流表、和工作之间的关系以外，咱们还对以下这几种状况做了被动监控：

• Kafka Topic 的分区数的合理性，次要监控音讯队列分区数过少或者过多的状况，次要是过少的状况，避免因为分区数过小，上游工作解决性能跟不上的问题；
• Kafka 分区数据生产平衡问题：避免因为 Kafka 自身分区数据的不平衡导致上游工作解决性能不行的问题；
• Kafka 分区数据生产平衡问题：避免因为 Kafka 自身分区发生变化，而上游工作因为没有开启分区感知，导致一些数据没有生产到等问题；
• 流量激增和激降报警：要害队列流量报警，保障实时数据的品质。

Kafka 版本升级：为了解决自身 Kafka 扩容的稳定性问题、资源隔离问题，通过咱们音乐公共技术团队，在 Kafka 2.X 版本根底上做了一些二次开发工作，将 Kafka 整个服务做了平台化的反对，反对了 Topic 的平滑扩所容，反对资源隔离。

相似 YARN 的 LAEBL 技术，反对针对不同的 TOPIC 划分不同 region 的机器，欠缺的音讯镜像服务，且反对 offset 的复制；对立的 Kafka 运维监控平台，此局部内容后续文章会具体介绍。

3.3 分区流表技术建设

实时数仓上线当前，咱们发现以下几种状况十分影响程序的稳定性以及流表的易用性：

• 很多时候咱们只须要一张流表中 1% 的数据，然而因为没有方法按需读取，所以咱们必须耗费大量的资源去解析读取另外 99% 的数据，导致了大量的资源带宽的耗费，节约了大量的资源，而且自身 SQL 的开发方式自身没有方法按需解析日志，导致咱们必须残缺的解析出每一条音讯，这就导致进一步的计算资源的耗费。

• 当咱们依照教训和业务，将大的 TOPIC 拆分成很多小的 TOPIC 时，一张表变成了很多小表，使用者又必须有很多的教训常识去理解这些 schema 完全相同的小表中别离蕴含了哪些音讯，易用性很差，这样的设计也不合乎数仓的整体设计逻辑，当前如果要做批流表对立元数据的时候，整体也变得不太可能

在离线场景下咱们很有很多伎俩来解决以上问题，缩小不必要的 IO，如数据的分桶、存储有序的数据利用 Parquet 的下推查问的能力、做分区表等伎俩都能够解决以上问题。然而实时表的 Case 下在现有的公开的计划中如同并没有什么好的办法；所以为了解决以上问题，咱们开发了流表的分区计划，整体和 HIVE 表的分区实现思维差不多：

咱们应用 Flink Table Souce 提供的 SupportsFilterPushDown 的接口实现了一套本人的实时流表分区计划，一个分区对应一个 topic，通过用户的查问条件下推过滤掉没有必要的分区，从而缩小没有必要的数据的读取；目前曾经上线了第一版，初步拆分了云音乐曝光日志，顺便还尝试应用 AVRO 的数据格式代替以前的 JSON 格局，实际下来优化成果显著：

• 应用 AVRO 格局格局根本都能带来至多 30+% 的的带宽优化，音讯解析性能绝对音乐的原始日志格局的解析性能晋升一倍.

• 应用分区流表，咱们初步迁徙了了 4 个曝光日志的生产工作，曾经节俭了 7 台物理机，均匀节俭计算和带宽资源 75% 以上。

尽管这些都是比拟极其的 Case，然而从这些例子咱们能够预计分区流表技术全面铺开当前，应用失去的话，相对是一个能带来量变的优化。

二、批流一体

数据实时化始终是咱们云音乐数据平台团队数仓建设的一个比拟大的指标，在这个指标的背地批流一体也是咱们绕不开一个“名词”、“概念”、“技术”、或者是个“产品”。在正式开始分享咱们的工作以前，首先分享下我有一次在电梯间遇到算法同学，而后和算法同学产生的对话：

算法：你们的批流一体什么时候上线？咱们等着用呢？

我：你们目前的诉求是什么呢？

算法：咱们当初很多实时指标都是本人开发，没法在离线当前间接应用现成数仓数据。

从这段对话咱们能够看出，算法同学并不是想要什么批流一体的技术，他们想要的是实时的现成的可用的数仓数据，来晋升他们的开发效率，批流一体的背地，不同角色的业务方的诉求是什么呢？

对于经营、产品、老板、分析师们来说：

他们想要看到的是精确的实时的可剖析的报表数据，关键点在于可剖析上。当后果数据产生异样稳定时，咱们得有实时的明细数据提供剖析查问，来考察产生异样稳定的起因。当老板有一些新的想法，想对现成的报表做下二次剖析时，咱们得有能力提供明细的可剖析的数据来做剖析给出后果。

以实时日活统计来说，咱们罕用的伎俩是将用户 ID 存储的 Redis 这样 KV 存储当中来做去重，或者近似去重，而后计算得出实时的日活数据，然而当日活产生异样稳定时，因为 Reids 的数据不是可剖析的。所以咱们很难疾速给出起因，也没法在当天做剖析，这种计划和后果显然是不合格的。

对于数仓开发来说：

• 对立实时 / 离线数仓元数据管理、对立模型、对立存储，缩小数仓运维建设老本，晋升整体数仓的易用性；
• 对立开发代码，对立一套 SQL 解决离线 / 实时开发问题，升高开发运维老本，彻底解决因为业务了解不同、逻辑不同导致的实时离线数据后果差别大的问题。

对于算法同学来说：

有实时 / 离线对立的数仓表能够能够用应用，对立模型，升高业务了解的门槛，晋升整体数仓数据的易用性，不便好用的数仓元数据管理服务，不便算法同学进行二次的特色开发工作，晋升模型的开发效率。提供精确实时可剖析的算法模型成果数据，晋升算法同学模型迭代的效率

整体总结下来批流一体的指标次要蕴含三个方面：

• 对立代码：一套 SQL 实现实时和离线的相干业务的开发需要；
• 对立数仓元数据：一张表能够同时提供离线读和实时读，对立模型的批流一体的数仓；
• 实时的报表数据：这与对立数仓元数据不同，产品报表数据须要提供秒级的实时的后果的查问能力，而对立数仓数据往往只须要实时的存储即可，对 OLAP 查问的效率，并没有报表数据并没有那么敏感。

1. 对立代码

因为实时 SQL 自身并没有特地的成熟，很多在离线场景下很容易实现的逻辑，在实时场景下要么是不能实现，要么是稳定性有问题。

目前业界都还在摸索当中，阿里目前次要的形式的是应用 FLINK 一套引擎解决实时离线对立 SQL 的问题，然而目前也都是在实际，在下层 ADS 层业务逻辑实现上通过底层数仓的建设屏蔽掉一些实时 SQL 能力的问题，做到产品报表开发上对立一套 SQL。这也是咱们将来能够尝试的方向，除了在下层报表开发上尝试对立 SQL 以外，咱们在对立代码这一块也做了一些工作和布局：

• 对立 UDF，集成降级平台框架到 FLINK1.12 新版本，对立离线实时对立套 UDF；
• 对立元数据管理：在 FlinkSQL 侧咱们继承元数据中心服务，提供 catalog.db.table 这样的数据读取和写入形式，为了对立元数据，同样咱们对 SparkSQL 做了二次的封装，同样和元数据中心做了集成，实现了以 catalog.db.table 这样模式的异构数据源之间的读取和写入。

场景化的配置式的批流一体的对立实现，对于一些简略业务逻辑的场景，咱们后续会开发场景化的批流一体的实现。如批流一体的索引工作、批流一体的 ETL 荡涤平台等等，这块因为资源问题，目前还在布局中。

批流一体 SQL 对立的在目前的技术下，还有一个比拟大的前提是自身日志的复杂程度，这个波及到自身日志埋点规范性和完整性，实时计算不像离线，能够将大量归因逻辑，关联逻辑放在数据侧进行解决，抛开合理性和老本问题，很多工作在离线场景下是能够做的。

然而在实时场景，自身对性能和稳定性都十分的敏感，如果将大量的逻辑都放在数据侧进行解决，自身就会带来很多不能实现的问题、实现起来老本高的问题、很多稳定性、以及数据提早的问题。如果打点做不好，整个实时数仓建设都是问题，所以云音乐也启动了曙光打点我的项目和无数团队单干，彻底重构云音乐各个产品的打点的实现，晋升和欠缺打点的规范性和准确性，升高实时数仓的开发成本问题。

2. 对立数仓元数据

目前业界次要有两类计划：

• 第一种是建设批流映射层的计划，目前阿里公开的计划的就是这种计划，比拟适宜曾经有了实时数仓和离线数仓的老产品，在不改变原有数仓的状况下，构建对立映射层视图，通过视图的形式提供一体化的应用体验，整体的原理参考下图：

• 第二种计划是构建一种新的元数据系统，一套 schema 下同时挂载多种存储，如 HDFS、Kafka 等，在写入数据时同时写入，在读取场景下时，依据读取形式的不同，抉择相应的适合的存储，目前网易数帆无数产品团队开发的 Arctic 采纳的就是这种计划：

整体思路是封装 icberg 和 Kafka 以及 Hbase 等多种存储，在不同场景下应用不同的存储，另外 arctic 还在 iceberg 的根底上做了很多二次开发，来解决 DWS 数据的更新问题，提供相似 Hudi 的 CopyOnWrite 以及 MergeOnRead 等性能，用来解决 Flink 自身用来做全聚合的稳定性问题。目前云音乐曾经在一些新的业务场景做了试用，曾经上线了几十张的的批流一体表，大家如果想进一步理解 arctic 能够找网易数帆无数实时计算团队理解，在此不过多形容。

3. 实时的报表数据

提供实时的报表数据次要依赖 OLAP 引擎和存储，存储侧须要有须要有在提供实时的数据更新能力的同时，还须要有提供秒级别数据的查问能力，很多时候没有方法把将后果间接写到到存储中。因为数据报表自身很多灵活性的查问，如果间接将后果写到存储中，就须要相似 Kylin 那种实时的 Cube 能力，这对开发以及 Flink 自身计算的压力太大，自身也会带来很多资源的和存储的节约，稳定性问题以及开发工作量的问题也会很多，数据的二次剖析能力也会很局限；所以在这一层咱们须要 OLAP 引擎提供至多百亿级别的数据的秒级提早的查问的能力，目前咱们次要的计划采纳的存储有 Kudu 和 Clickhouse 两种，以咱们老版本的 ABTest 为例，咱们采纳的计划如下：

对于实时的最新的小时维度以及天维度的后果咱们通过 Impala 及时读取 Kudu 数据关联出最新的后果；对于历史的一天以前天维度数据或者两个小时以前小时维度的数据咱们采纳 Spark 预计算好存储在后果表当中，两份数据 UNION 在一起提供给用户，保障数据后果的时效性，以及整体数据查问的用户体验。

三、将来布局

** 运维工具的欠缺

**

实时 SQL 的倒退升高了实时数据统计的开发难度，大大降低了实时数据统计的门槛，一方面因为自身实时 SQL 的不成熟而且黑盒，另一方面很多同学带着离线 SQL 的开发教训或者 MYSQL 类数据库的 SQL 教训来开发实时工作，这给平台带来了很大的运维压力，所以运维工具相干的建设，工作实时指标的欠缺是咱们将来次要思考的方向之一。

分区流表技术欠缺

分区流表技术是一个能给云音乐实时平台资源应用，Kafka 压力以及数仓建设带来量变的技术，目前咱们只是实现了一个初版，将来咱们会在分区的动静感知，分区的批改，schema 的批改，以及运维监控以及推广上持续欠缺。

场景化批流一体建设

如批流一体索引工作建设、批流一体 ETL 工具等, 对立日志荡涤规定, 为批流一体数仓打好根底。

批流一体存储摸索

• 调研业界目前的计划, 联合音乐的业务场景, 提供整套解决方案, 升高实时报表的开发门槛, 晋升实时报表的开发效率；
• 批流一体逻辑层建设等。

最初附一张网易数帆无数团队的实时计算解决方案架构图，基于 Apache Flink 构建的高性能、一站式实时大数据处理计划，宽泛实用于流式数据处理场景。

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群；

第一工夫获取最新技术文章和社区动静，请关注公众号～