实时数仓系列-网易云音乐基于flink+kafka的实时数仓建设实践

大数据生态 大数据生态     2022-11-28     146

关键词:

简介:本文由网易云音乐实时计算平台研发工程师岳猛分享,主要从以下四个部分将为大家介绍 Flink + Kafka 在网易云音乐的应用实战

  1. 背景

  2. Flink + Kafka 平台化设计

  3. Kafka 在实时数仓中的应用

  4. 问题 & 改进


直播回放:https://developer.aliyun.com/live/2894


一、背景介绍


(一)流平台通用框架

目前流平台通用的架构一般来说包括消息队列、计算引擎和存储三部分,通用架构如下图所示。客户端或者 web 的 log 日志会被采集到消息队列;计算引擎实时计算消息队列的数据;实时计算结果以 Append 或者 Update 的形式存放到实时存储系统中去。

目前,我们常用的消息队列是 Kafka,计算引擎一开始我们采用的是 Spark Streaming,随着 Flink 在流计算引擎的优势越来越明显,我们最终确定了 Flink 作为我们统一的实时计算引擎。


(二)为什么选 Kafka?

Kafka 是一个比较早的消息队列,但是它是一个非常稳定的消息队列,有着众多的用户群体,网易也是其中之一。我们考虑 Kafka 作为我们消息中间件的主要原因如下:

  • 高吞吐,低延迟:每秒几十万 QPS 且毫秒级延迟;

  • 高并发:支持数千客户端同时读写;

  • 容错性,可高性:支持数据备份,允许节点丢失;

  • 可扩展性:支持热扩展,不会影响当前线上业务。


  • (三)为什么选择 Flink?

    Apache Flink 是近年来越来越流行的一款开源大数据流式计算引擎,它同时支持了批处理和流处理,考虑 Flink 作为我们流式计算引擎的主要因素是:

  • 高吞吐,低延迟,高性能;

  • 高度灵活的流式窗口;

  • 状态计算的 Exactly-once 语义;

  • 轻量级的容错机制;

  • 支持 EventTime 及乱序事件;

  • 流批统一引擎。


  • (四)Kafka + Flink 流计算体系

    基于 Kafka 和 Flink 的在消息中间件以及流式计算方面的耀眼表现,于是产生了围绕 Kafka 及 Flink 为基础的流计算平台体系,如下图所示:基于 APP、web 等方式将实时产生的日志采集到 Kafka,然后交由 Flink 来进行常见的 ETL,全局聚合以及Window 聚合等实时计算。


    (五)网易云音乐使用 Kafka 的现状

    目前我们有 10+个 Kafka 集群,各个集群的主要任务不同,有些作为业务集群,有些作为镜像集群,有些作为计算集群等。当前 Kafka 集群的总节点数达到 200+,单 Kafka 峰值 QPS 400W+。目前,网易云音乐基于 Kafka+Flink 的实时任务达到了 500+。

    二、Flink+Kafka 平台化设计


    基于以上情况,我们想要对 Kafka+Flink 做一个平台化的开发,减少用户的开发成本和运维成本。实际上在 2018 年的时候我们就开始基于 Flink 做一个实时计算平台,Kafka 在其中发挥着重要作用,今年,为了让用户更加方便、更加容易的去使用 Flink 和 Kafka,我们进行了重构。

    基于 Flink 1.0 版本我们做了一个 Magina 版本的重构,在 API 层次我们提供了 Magina SQL 和 Magina SDK 贯穿 DataStream 和 SQL 操作;然后通过自定义 Magina SQL Parser 会把这些 SQL 转换成 Logical Plan,在将 LogicalPlan 转化为物理执行代码,在这过程中会去通过 catalog 连接元数据管理中心去获取一些元数据的信息。我们在 Kafka 的使用过程中,会将 Kafka 元数据信息登记到元数据中心,对实时数据的访问都是以流表的形式。在 Magina 中我们对 Kafka 的使用主要做了三部分的工作:

  • 集群 catalog 化;

  • Topic 流表化;

  • Message Schema 化。



  • 用户可以在元数据管理中心登记不同的表信息或者 catalog 信息等,也可以在 DB 中创建和维护 Kafka 的表,用户在使用的过程只需要根据个人需求使用相应的表即可。下图是对 Kafka 流表的主要引用逻辑。


    三、Kafka 在实时数仓中的应用


    (一)在解决问题中发展

    Kafka 在实时数仓使用的过程中,我们遇到了不同的问题,中间也尝试了不同的解决办法。

    在平台初期, 最开始用于实时计算的只有两个集群,且有一个采集集群,单 Topic 数据量非常大;不同的实时任务都会消费同一个大数据量的 Topic,Kafka 集群 IO 压力异常大;

    因此,在使用的过程发现 Kafka 的压力异常大,经常出现延迟、I/O 飙升。

    我们想到把大的 Topic 进行实时分发来解决上面的问题,基于 Flink 1.5 设计了如下图所示的数据分发的程序,也就是实时数仓的雏形。基于这种将大的 Topic 分发成小的 Topic 的方法,大大减轻了集群的压力,提升了性能,另外,最初使用的是静态的分发规则,后期需要添加规则的时候要进行任务的重启,对业务影响比较大,之后我们考虑了使用动态规则来完成数据分发的任务。


    解决了平台初期遇到的问题之后,在平台进阶过程中 Kafka 又面临新的问题:

  • 虽然进行了集群的扩展,但是任务量也在增加,Kafka 集群压力仍然不断上升;

  • 集群压力上升有时候出现 I/O 相关问题,消费任务之间容易相互影响;

  • 用户消费不同的 Topic 过程没有中间数据的落地,容易造成重复消费;

  • 任务迁移 Kafka 困难。


  • 针对以上问题,我们进行了如下图所示的 Kafka 集群隔离和数据分层处理。其过程简单来说,将集群分成 DS 集群、日志采集集群、分发集群,数据通过分发服务分发到 Flink 进行处理,然后通过数据清洗进入到 DW 集群,同时在 DW 写的过程中会同步到镜像集群,在这个过程中也会利用 Flink 进行实时计算的统计和拼接,并将生成的 ADS 数据写入在线 ADS 集群和统计 ADS 集群。通过上面的过程,确保了对实时计算要求比较高的任务不会受到统计报表的影响。


    通过上面的过程,确保了对实时计算要求比较高的任务不会受到统计报表的影响。但是我们分发了不同的集群以后就不可避免的面临新的问题:

  • 如何感知 Kafka 集群状态?

  • 如何快速分析 Job 消费异常?


  • 针对上面两个问题,我们做了一个 Kafka 监控系统,其监控分为如下两个维度,这样在出现异常的时候就可以进行具体判断出现问题的详细情况:

  • 集群概况的监控:可以看到不同集群对应的 Topic 数量以及运行任务数量,以及每个 Topic 消费任务数据量、数据流入量、流入总量和平均每条数据大小;

  • 指标监控:可以看到 Flink 任务以及对应的 Topic、GroupID、所属集群、启动时间、输入带宽、InTPS、OutTPS、消费延迟以及 Lag 情况。


  • (二)Flink + Kafka 在 Lambda 架构下的运用

    流批统一是目前非常火的概念,很多公司也在考虑这方面的应用,目前常用的架构要么是 Lambda 架构,要么是 Kappa 架构。对于流批统一来讲需要考虑的包括存储统一和计算引擎统一,由于我们当前基建没有统一的存储,那么我们只能选择了 Lamda 架构。

    下图是基于 Flink 和 Kafka 的 Lambda 架构在云音乐的具体实践,上层是实时计算,下层是离线计算,横向是按计算引擎来分,纵向是按实时数仓来区分。


    四、问题&改进


    在具体的应用过程中,我们也遇到了很多问题,最主要的两个问题是:

  • 多 Sink 下 Kafka Source 重复消费问题;

  • 同交换机流量激增消费计算延迟问题。


  • (一)多 Sink 下 Kafka Source 重复消费问题

    Magina 平台上支持多 Sink,也就是说在操作的过程中可以将中间的任意结果插入到不同的存储中。这个过程中就会出现一个问题,比如同一个中间结果,我们把不同的部分插入到不同的存储中,那么就会有多条 DAG,虽然都是临时结果,但是也会造成 Kafka Source 的重复消费,对性能和资源造成极大的浪费。

    于是我们想,是否可以避免临时中间结果的多次消费。在 1.9 版本之前,我们进行了 StreamGraph 的重建,将三个 DataSource 的 DAG 进行了合并;在 1.9 版本,Magina 自己也提供了一个查询和 Source 合并的优化;但是我们发现如果是在同一个 data update 中有对同一个表的多个 Source 的引用,它自己会合并,但是如果不是在同一个 data update 中,是不会立即合并的,于是在 1.9 版本之后中我们对 modifyOperations 做了一个 buffer 来解决这个问题。


    (二)同交换机流量激增消费计算延迟问题

    这个问题是最近才出现的问题,也可能不仅仅是同交换机,同机房的情况也可能。在同一个交换机下我们部署了很多机器,一部分机器部署了 Kafka 集群,还有一部分部署了 Hadoop 集群。在 Hadoop 上面我们可能会进行 Spark、Hive 的离线计算以及 Flink 的实时计算,Flink 也会消费 Kafka 进行实时计算。在运行的过程中我们发现某一个任务会出现整体延迟的情况,排查过后没有发现其他的异常,除了交换机在某一个时间点的浏览激增,进一步排查发现是离线计算的浏览激增,又因为同一个交换机的带宽限制,影响到了 Flink 的实时计算。


    为解决这个问题,我们就考虑要避免离线集群和实时集群的相互影响,去做交换机部署或者机器部署的优化,比如离线集群单独使用一个交换机,Kafka 和 Flink 集群也单独使用一个交换机,从硬件层面保证两者之间不会相互影响。

    五、Q & A


    Q1:Kafka 在实时数仓中的数据可靠吗?

    A1:这个问题的答案更多取决于对数据准确性的定义,不同的标准可能得到不同的答案。自己首先要定义好数据在什么情况下是可靠的,另外要在处理过程中有一个很好的容错机制。

    Q2:我们在学习的时候如何去学习这些企业中遇到的问题?如何去积累这些问题?

    A2:个人认为学习的过程是问题推动,遇到了问题去思考解决它,在解决的过程中去积累经验和自己的不足之处。

    Q3:你们在处理 Kafka 的过程中,异常的数据怎么处理,有检测机制吗?

    A3:在运行的过程中我们有一个分发的服务,在分发的过程中我们会根据一定的规则来检测哪些数据是异常的,哪些是正常的,然后将异常的数据单独分发到一个异常的 Topic 中去做查询等,后期用户在使用的过程中可以根据相关指标和关键词到异常的 Topic 中去查看这些数据。



      Flink Forward Asia 2020  
    官网上线啦

    洞察先机,智见未来, Flink Forward Asia 2020 盛大开启!诚邀开源社区的各方力量与我们一起,探讨新型数字化技术下的未来趋势,共同打造 2020 年大数据领域的这场顶级盛会!大会官网已上线,点击「阅读原文」即可预约峰会报名~

    (点击可了解更多议题投递详情)

    戳我报名!

    网易云音乐实时数仓2.0进阶之路

    云音乐从2018年开始搭建实时计算平台,经过两年的发展实时计算已经渗透到云音乐的各个业务当中:运营需要实时的统计报表做精细化的运营算法同学需要实时的特征数据来提升推荐效果、需要实时的AB数据来降低试错... 查看详情

    阿里云flink+hologres:构建企业级一站式实时数仓

    ...以最大化发挥数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的快速探索。在业务建设过程中,实时数仓需要支持数据实时写入与更新、业务敏捷快速响应、数据自助分析、运维操作便捷、云原生弹性扩缩容等... 查看详情

    个推techday直播回顾|分享基于flink的实时数仓搭建秘诀附课件下载

    ...#xff08;个推)的资深数据研发工程师为大家详细解读了实时数仓架构演进,分享了实时数仓的技术选型要点,并结合实战案例详细剖析实时数仓搭建秘诀。点击查看课程回顾视频>> 个推TechDay治数训练营——基于Fli... 查看详情

    个推techday直播回顾|分享基于flink的实时数仓搭建秘诀附课件下载

    ...#xff08;个推)的资深数据研发工程师为大家详细解读了实时数仓架构演进,分享了实时数仓的技术选型要点,并结合实战案例详细剖析实时数仓搭建秘诀。点击查看课程回顾视频>> 个推TechDay治数训练营——基于Fli... 查看详情

    基于flink+iceberg的全场景实时数仓建设实践

    ...0c;主要介绍腾讯大数据部门基于ApacheFlink和ApacheIceberg构建实时数仓的应用实践,介绍主要包括如下几个方面:背景及痛点数据湖ApacheIceberg介绍Flink+Iceberg构建实时数仓未来规划一、背景及痛点如下图所示,这是当前... 查看详情

    快手基于flink构建实时数仓场景化实践

    简介: 一文了解快手基于Flink构建的实时数仓架构,以及一些难题的解决方案。本文整理自快手数据技术专家李天朔在5月22日北京站FlinkMeetup分享的议题《快手基于Flink构建实时数仓场景化实践》,内容包括:快... 查看详情

    基于flink构建实时数仓实践

    ...会员、游戏等非常多的业务板块。与此同时产品及运营对实时数据需求逐渐增多,帮助他们更快的做出决策,更好的进行产品迭代,实时数仓的建设变得越发重要起来。本文主要介绍用户增长业务基于Flink构建实时数... 查看详情

    基于emrolap的开源实时数仓解决方案之clickhouse事务实现

    ...作,支持了Flink到ClickHouse的Exactly-Once写入来保证整个实时数仓数据的准确性。本文介绍了基于EMROLAP的开源实时数仓解决方案。作者简介:阿里云EMR-OLAP团队;主要负责开源大数据OLAP引擎的研发,例如ClickHouse,... 查看详情

    基于emrolap的开源实时数仓解决方案之clickhouse事务实现

    ...作,支持了Flink到ClickHouse的Exactly-Once写入来保证整个实时数仓数据的准确性。本文介绍了基于EMROLAP的开源实时数仓解决方案。作者简介:阿里云EMR-OLAP团队;主要负责开源大数据OLAP引擎的研发,例如ClickHouse,... 查看详情

    flink系列之:基于scala语言实现flink实时消费kafkatopic中的数据(代码片段)

    Flink系列之:基于scala语言实现flink实时消费KafkaTopic中的数据一、引入flink相关依赖二、properties保存连接kafka的配置三、构建flink实时消费环境四、添加Kafka源和处理数据五、完整代码六、执行程序查看消费到的数据一、引入fli... 查看详情

    aliexpress基于flink的广告实时数仓建设

    ...者。 放心关注我,获取更多行业的一手消息。摘要:实时数仓以提供低延时数据指标为目的供业务实时决策,本文主要介绍基于Flink的广告实时数仓建设,主要包括以下内容:1.建设背景2.技术架构3.数仓架构4. 实时OLAP5.... 查看详情

    aliexpress基于flink的广告实时数仓建设

    摘要:实时数仓以提供低延时数据指标为目的供业务实时决策,本文主要介绍基于Flink的广告实时数仓建设,主要包括以下内容:1.建设背景2.技术架构3.数仓架构4. 实时OLAP5.实时保障6.未来规划建设背景广告是目前互联网流量... 查看详情

    基于flink+iceberg的全场景实时数仓建设实践

    ApacheFlink是目前大数据领域非常流行的流批统一的计算引擎,数据湖是顺应云时代发展潮流的新型技术架构,以Iceberg、Hudi、Delta为代表的解决方案应运而生,Iceberg目前支持Flink通过DataStreamAPI/TableAPI将数据写入Iceberg的... 查看详情

    基于flink构建企业级实时数仓(附项目源码)

    ...景,要把链路延时降低到秒级,就需要基于Flink的实时数仓出马了。企业级实时数仓的应用场景很多,比如:实时OLAP分析;实时数据看板;实时业务监控;实时数据接口服务。很多公司实时数仓的 查看详情

    实时数仓flink生产环境部署+提交作业步骤(代码片段)

    文章目录1、基础环境2、开发环境2.1、pom.xml2.2、log4j.properties2.3、测试用的代码2.3.1、Flink执行环境工具2.3.2、Kafka工具2.3.3、测试Flink读写Kafka2.3.4、测试FlinkSQL读写Kafka2.4、打包后上传到服务器3、生产环境3.1、Flink安装3.2、FlinkonYARN... 查看详情

    实时数仓flink生产环境部署+提交作业步骤(代码片段)

    文章目录1、基础环境2、开发环境2.1、pom.xml2.2、log4j.properties2.3、测试用的代码2.3.1、Flink执行环境工具2.3.2、Kafka工具2.3.3、测试Flink读写Kafka2.3.4、测试FlinkSQL读写Kafka2.4、打包后上传到服务器3、生产环境3.1、Flink安装3.2、FlinkonYARN... 查看详情

    快手基于flink构建实时数仓场景化实践

    ...在5月22日北京站FlinkMeetup分享的议题《快手基于Flink构建实时数仓场景化实践》,内容包括:快手实时计算场景快手实时数仓架构及保障措施快手场景问题及解决方案未来规划1.快手实时计算场景快手业务中的实时计算场... 查看详情

    美团基于flink的实时数仓平台建设新进展

    ...k系统性学习笔记1.平台建设现状美团于2018年首次引入Flink实时计算引擎,当时的实时数仓概念还不太普及,平台只提供了FlinkJar任务的生命周期管理和监控报警。2019年,我们注意到实时计算的主要应用场景是解决离线... 查看详情