网易云音乐实时计算平台设计及实践

作者 | 李涵淼

编辑 | 李雪薇

本文根据网易云音乐Flink & Calcite contributor李涵淼在ITPUB技术栈系列线上沙龙活动分享整理而成。

本次ITPUB技术栈线上沙龙2020上，网易云音乐Flink & Calcite contributor李涵淼分享了关于网易云音乐基于Flink实时数仓实践，内容包括实时数仓版本的演进过程，具体实现和***实践。

▲网易云音乐 Flink & Calcite contributor李涵淼

嘉宾简介：Flink & Calcite contributor。拥有多年的流计算研发经验，熟悉流计算生态圈，参与和设计了网易云音乐实时计算平台、实时数仓、Notebook、批流一体等项目。目前专注于Flink SQL的研究，致力于打造方便、易用、稳定的大数据SQL生态系统。

背景介绍

截止到今天为止，网易云音乐实时计算平台的机器数量有150多个，运行任务有700个，数据峰值的QPS有400万。李涵淼透露道，“大概有180多个开发者在用这个实时计算平台。”

在业务覆盖层面，跟实时有关的基本是全覆盖，包括实时报表、实时特征、实时索引，以及实时业务等。实时计算平台是从2018年上半年开始做的，期间经历了两个版本的迭代，直到2020上半年，任务增长了将近200%。

网易云是基于1.7的版本，做的实时计算平台version-1设计。大家都知道，Flink已经更新到1.11版本了，它集成了很多Blink的优秀特性。在被阿里收购以后，Flink从1.9版本开始，每一个版本迭代，代码的改动都是非常多的。

因为社区版本的Flink 1.7不支持SQL DDL，所以为了方便用户的使用，我们基于Antlr的自定义SQL语法，包含DDL和维表JOIN。此外网易云计算，实时平台的第一版本没有数据血缘追踪功能，问题定位的时候比较困难。

实时平台的第一版本没有元数据管控，Jar任务的游离。它的任务监控是不健全的。当问题出现的时候，我们收集的指标不足以定位问题。现在来看，实时平台第一版本的问题是非常多的。

实时数仓建设

实时数仓版本是基于Flink 1.9版本做的，它主要的特性包括：与元数据中心的整合，使得用户不用过多地定义数据的格式；提供SQL和SDK给用户使用；端到端血缘收集；数据源和任务监控完善。

▲实时数仓的架构图

从最源头开始看实时数仓的架构图，SQL和SDK作为输入，直接去走Planner。Planner和SQL打通，可以解析整体的SQL语句。接下来，会有一个Catalog的注入，它接的是MetaHub（云数据中心）。

所有的元数据都被管控起来，就形成了一个系统，也就是元数据中心。它可以管理所有存在元数据系统的存储，并具备独立模块管理MQ元数据、插拔式元数据管理、统一数据类型、元数据检索等功能。

数仓建设分为三个部分：统一表表示格式 (catalog.db.table) 、数仓分层，以及表权限管理。在做实时数仓时，我们完全以现有离线的数仓模式，复制出来一个实时数仓的表。

SDK提供封装内部SQL执行逻辑，简易的API，以及数据血缘收集。上图是用SDK做的一个DEMO，这是真实的一个业务代码。之前是用了将近190多行代码去实现的，在封装之后总体不过十几行代码，方便用户使用。

从数据、数据源、数据写出，我们均提供细粒度任务级别指标监控和MQ数据量监控。李涵淼认为，“当平台做到一定程度的时候，这种集群级别的监控是必不可少的。监控做的完善，对平台是一个很好的补充。”

实时数仓实践

实时数仓第一个很典型的实践就是ABTest，把原始数据存到HIVE里面去，再用Spark做清洗和聚合，然后再输到上层的表里。值得注意的是，实时数仓和离线数仓的分层，其实是一致的。

实时数仓版ABTest摆脱了之前HIVE+Spark的处理模式，应用效果非常好。

实时数仓第二个典型的实践是实时报表，如上图所示，网易云音乐直播播放量的统计表格。实时报表建立任务更容易，数据问题定位更清晰。

第三个典型的实践是实时特征，具备特征复用和特征血缘展示。我们做过一个统计，各个算法团队做出来的任务，输出的特征很多都是重复的，这无形中就造成了资源的浪费，增加了团队开发的成本。

实时数仓对特征做了分层，所有的表根据业务做了隔离，并全部统一起来。算法团队如果想用一些特征的话，他可以直接在平台上搜索相关特征，然后根据其中包含的信息，做进一步的操作。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!