数据库 频道

网易云音乐基于Flink实时数仓实践

  【IT168评论】本次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的处理模式,应用效果非常好。

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

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

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

0
相关文章