「如何实现流动式软件发布」线上课堂开课啦,快来报名参与课堂抽奖吧~ 了解详情
写点什么

爱奇艺大数据生态的实时化建设

2021 年 4 月 12 日

爱奇艺大数据生态的实时化建设

数据作为互联网时代的基础生产资料,在各大公司企业拥有举足轻重的地位。数据的价值在互联网公司的体现,大致而言可以分成三类:

(1)发掘数据中的信息来指导决策,如产品运营、用户增长相关的 BI 报表

(2)依托数据优化用户体验和变现效率,如信息分发场景下的个性化推荐、效果广告等

(3)基于数据统计的业务监控,如监控大盘、安全风控等


在这些体现大数据价值的业务场景上,存在一个普遍的规律,即数据产生的价值,随着时间的推移而衰减。因此,随着公司业务的发展,传统的 T+1 式(隔日)的离线大数据模式越来越无法满足新兴业务的发展需求。开展实时化的大数据业务,是企业深入挖掘数据价值的一条必经之路。


爱奇艺大数据团队自 2014 年开始引入 Kafka、Storm、Spark Streaming 等实时化技术,2017 年引入 Apache Flink 实时计算框架,逐步建设了一套打通数据采集、加工、分发、分析、应用等完整数据流程的实时大数据体系。这套实时大数据体系支持了峰值超过 3000 万 QPS 的实时数据处理,支持了如春晚直播、青春有你、尖叫之夜等大型活动的实时计算需求。本文将介绍爱奇艺实时大数据体系的主要架构、平台功能以及发展过程中的一些思考。

传统实时 ETL 模式的问题

在实时技术发展初期,大团队为各业务提供的是单纯的日志数据的实时解析服务。通过 Flink ETL 程序,将用户端上报日志、后台服务器日志、数据库 binlog 日志,解析成 key-value 组装的 json 形态的结构化数据,发送到 Kafka 中供各业务使用。其中,ETL 逻辑可以由外部配置平台注入,方便在解析逻辑修改时可以动态加载,减少 Flink 任务的重启频率。这个实时 ETL 的体系如下图所述:


随着实时大数据业务的发展,它的弊端不断出现:

(1)实时数据大量重复生产,各业务烟囱式开发,数据难以复用

(2)数据治理水平低下,数据生产者不知道数据在被谁消费

(3)稳定性差,不能抵御 Flink 和 Kafka 故障


为了解决这些问题,爱奇艺大数据团队开始建设实时大数据体系,推出管理 Kafka 的流数据服务平台、基于 Flink 的实时数据生产平台、基于 Kafka 的实时数仓等组件,打通实时数据流程。

实时数仓与传统数仓的区别

在传统的 BI 体系中,基于离线大数据构建数据仓库的过程,大部分是 T+1 的隔日离线计算。即每天凌晨开始从原始日志数据构建数仓,将多层级的离线计算任务,通过工作流系统进行串联。数仓构建任务失败后可以有由工作流系统触发任务重跑。一般来说,离线数仓构建任务的失败重跑,只影响数据生产出来的时间,不影响数据的完整性、正确性。


在设计离线数仓模型和对应的计算任务时,一般会从以下几个角度去兼顾平衡:

(1)数据膨胀的成本约束(Hive 存储)

(2)计算资源的成本约束(YARN 队列)

(3)开发的人力成本约束

(4)用户体验,包含数据的时效性以及数仓表使用的便捷性


在实时数仓中,这几个约束条件发生了巨大的变化:


基于这些变化,构建实时数仓的时候,切记不能照搬离线数仓的分层模型和构建逻辑,需要结合实时大数据业务的需求,按照实时业务的特点进行构建。实时数仓的构建,核心有以下几个特点:


1、重视数仓的水平拆分。在离线数仓中,数据的载体是 Hive 表,借助 Hive 的分区字段和谓词下推机制,我们可以在各个层级构建一些稍大的表,而将关键的维度字段设置成分区,使用户在查大表的时候达到查小表的效果。在实时数仓中,数据的载体是 Kafka 队列,如果向用户提供一个大流,需要用户在消费数据实时过滤出其中的一小部分数据进行使用,那么对 Kafka 的带宽资源和 Flink 的计算资源都是极大的浪费。因此,我们需要尽量将常用的维度进行水平拆分构建,例如“移动端用户行为”“PC 端用户行为”可以拆分到两个流供用户使用。


2、重视维度退化。在离线数仓中,一个维度放在事实表里还是放在维度表里是一件可权衡的事情。一些不太常用的维度可以保留在维度表里,让用户查询使用时再进行 Join。而在实时数仓里,用户在使用数据时如果需要进行“实时流 Join 维度表”的操作,涉及实时计算中比较复杂的流与外部表 Join 的操作,对应的 Flink 代码开发和优化难度都较高。因此,在建设实时数仓时应该尽量帮助数据下游方减少这些代价,提前将会用到的维度退化到数仓的事实流中,将实时流变成一个宽流,避免下游业务方在使用数据时,自行去处理流 Join 外部表的这类复杂场景。


3、重视层级缩短。在实时数仓的构建过程中,数据在多层级 Kafka 中传递,数据处理的链路越长,数据的延迟越大、稳定性越差。因此,在实时数仓中,要尽可能引导用户使用短链路生产的实时数据。我们建议,实时数仓下游使用的数据,在数仓构建中经过的 Kafka 层级最好控制在 4 层以内,例如在 ODS 层、DWD 层之后,最多再加工一次就可以交付用户使用。在很多实时报表的场景上,我们可以选择将 DWD 层的实时数据灌入 OLAP 体系(如 Druid、Clickhouse),将用户的数据清洗过滤聚合需求转移到 OLAP 层,减少实时数据在数仓层的加工处理。

流数据服务平台

实时数仓的载体是 Kafka 服务,然而,Kafka 作为一个分布式消息队列,它原生的组织和管理方式仍然是一个资源型服务,向用户交付的是 Kafka 集群。这种管理组织方式对于开展实时大数据业务而言,有一些显著的缺点,例如难以注册和管理数据的输入和输出,无法构建数据血缘链路和高可用体系等等。


为了更好地支持实时数仓等业务的开展,爱奇艺大数据团队建设了流数据服务平台,以一种面向数据的角度,重新组织和管理 Kafka 服务。



流数据服务平台,自下而上分为三层:

1、运维管理层:负责 Kafka、Pulsar、RocketMQ 等消息队列集群的资源和运维管理,包括资产登记、容量管理、集群监控、自动化运维、工单审批体系等。

2、流数据管理层:负责登记和管理所有流数据的元信息,面向用户提供数据地图(检索寻找数据)、数据质量监控(生产延迟、消费积压等等)、数据血缘追踪、一键 HA 切换集群等功能。

3、客户端 SDK 层:封装原生 Kafka Client,向用户提供 Flink、Spark、Java 等场景下的 Kafka SDK,将读写操作全部封装在 SDK 中,对用户屏蔽 Kafka 集群版本和地址信息,由 SDK 通过心跳向配置中心获取数据地址。同时 SDK 还具备生产消费任务的自动登记注册、Kafka 切换时触发任务重启等功能。


依托流数据服务平台,我们大幅提升了 Kafka 的运维管理和服务提供能力:

1、基于 SDK 的访问控制模式,极大提高了实时大数据的治理水平。用户看到和访问的都是流数据,无需再关心 Kafka 集群和地址等信息。

2、在 Kafka 集群发生故障灾难时,运维人员可以简单的在后台切换数据流对应的 Kafka 集群,生产消费两侧的流任务同时重启,即可将故障的 Kafka 从链路中摘除,替换成备用的 Kafka 集群。

3、流数据服务平台能根据 SDK 上报的信息,分析并绘制数据血缘,用于数据链路排障、数据热度分析、数仓模型优化。

4、依托流数据的元数据中心,提供数据地图的产品,供用户方便的查询检索数据及其 Schema 相关信息,提高流数据的复用性。


附图:Kafka 故障时,通过 SDK 使读写两侧流量请快速切换到备集群

实时数据生产分发平台

Kafka 服务的高度治理化是实时数仓工作的基础,下一步要建设的是构建实时数仓的工具平台,通过平台降低用户开发管理实时数据处理任务的成本。


爱奇艺大数据团队建设了实时数据生产分发平台 Talos。Talos 平台兼具实时数据处理和数据集成分发功能,支持用户通过自定义数据处理逻辑,将实时数据加工处理后分发到下游数据流或其他异构存储中。



Talos 平台上,用户可以通过简单拖拽生成 DAG 图的方式构建自己的数据处理逻辑,也可以通过 SQL 算子来表达处理逻辑。对于实时计算的新手用户,使用 DAG 图可以直观看到数据的处理逻辑和含义。在调试任务时,Talos 平台支持查看数据在 DAG 图中每一步的变化值,非常有利于排查复杂数据处理逻辑中的问题,解决了传统 Flink SQL 任务调试不便的痛点。


附图:通过拖拽算子形成 DAG 图的方式构建数据处理逻辑


在爱奇艺的实时数仓体系中,实时数据的接入、处理、分发任务都通过 Talos 平台构建和维护,数仓建设者只需要关心数仓模型的定义和设计,无需撰写 Flink 代码,也不用关心 Flink 实时计算任务的提交管理和运维监控等工作,极大的简化了数仓的开发和维护成本。

实时分析平台

在实时大数据的下游业务场景中,实时报表和实时分析是最普遍的一种需求场景。传统的 Kafka->Flink SQL/Spark SQL->MySQL 的实时报表模式只适用于一些指标固定的实时报表,欠缺灵活性。


爱奇艺大数据团队基于 Druid+Spark/Flink 建设了一套实时分析平台(Realtime Analytics Platform,简称 RAP), 打通了实时数仓到实时分析的链路,大幅简化了实时报表的生产和使用成本。


在 RAP 平台中,我们将实时数仓中生成的 Kafka 流,通过 Druid 的 Kafka Index Service (简称 KIS) 直接导入 Druid。用户通过平台提供的 Web 向导配置,自动建立 OLAP 模型、查询统计条件,即可生产对应的实时报表。同时,平台也提供了如 Ad-hoc 分析、实时指标报警、实时数据发布、Grafana 图表输出等功能,方便用户快速接入使用。


更多关于 RAP 平台的介绍,可以阅读《爱奇艺大数据实时分析平台的建设与实践》

爱奇艺实时大数据的主要应用

依托以上这些平台建设,实时大数据技术在爱奇艺各个业务线都实现了落地。主要有三种典型的应用场景,即实时监控、实时数据分析、在线学习训练等。


在实时监控场景中,用户可以依托实时大盘进行指标观察,或者将关键指标配置成实时监控报警,也可以将实时日志流灌入 Elasticsearch 等系统中进行实时日志查询等。



在实时数据分析场景中,比较典型的是实时运营。通过实时大数据体系,为运营部门提供更实时的运营效果数据,从而可以及时调整内容运营策略,进行流量资源再分配,助力用户增长。



除了 BI 报表和分析类场景外,实时数据在效果广告、信息流推荐等场景上也有大量落地,帮助推荐、广告等团队实现近线/在线机器学习、模型快速迭代、AB 测试结果的实时观察统计等。


未来展望

随着公司业务的发展,实时大数据的需求场景逐渐多样化,爱奇艺实时大数据体系会朝着以下几个方向继续迭代:


1、流批一体:在存储和计算两个方向上探索流批一体的应用场景,逐渐替代传统 MapReduce/Spark 离线任务的数仓构建,围绕 Flink 引擎构建流批一体的数仓体系。

2、湖仓一体:打通实时流灌入数据湖(Iceberg)的数据通路,依托实时更新的数据湖体系,支持更多更丰富的 OLAP 业务场景

3、ETL->ELT:引导实时数仓的架构变迁,将实时数据构建环节中的部分计算转移到实时数仓下游的 OLAP 体系和数据湖中,依托 OLAP 引擎的强大性能来满足用户的过滤/聚合等需求,将实时数仓的链路做短,提升实时数据的质量和稳定性、降低延迟。

4、BI+AI:打通实时数据生产->实时特征生产->在线模型训练->线上推理的链路,方便用户一站式的实现从数据准备到 AI 算法模型训练的相关工作。



毫无疑问,实时化一定是大数据未来最重要的方向之一。爱奇艺大数据团队会沿着上述这些方向继续探索和发展,通过技术创新去支持和孵化更多落地的业务场景,继续推动爱奇艺的数据和产品向着实时化的方向发展。


本文转载自:爱奇艺技术产品团队(ID:iQIYI-TP)

原文链接:爱奇艺大数据生态的实时化建设

2021 年 4 月 12 日 07:001773

评论

发布
暂无评论
发现更多内容

技术人小故事-团队愿景篇-第3段

Ian哥

28天写作

架构师训练营大作业二

一马行千里

架构师训练营第 1 期

架构师训练营第十二周作业1

韩儿

大作业(一)

Pyr0man1ac

大作业(二)

TheSRE

大作业1

架构师设计大作业一

小诗

「架构师训练营第 1 期」

Java并发编程总结

topsion

Java 并发编程 多线程

28 天带你玩转 Kubernetes-- 第三天(K8s 安装)

Java全栈封神

Kubernetes k8s 28天写作 k8s安装

架构师训练营第 1 期 - 大作业 (二)

wgl

架构师训练营第 1 期

给我结果

三只猫

28天写作

架构师训练营第 1 期 - 大作业(二)

鲁小鲁

架构师训练营第 1 期

架构师训练营大作业二

kawayi

十一周作业

价值 - 什么是有价值的事?(3)

石云升

读书笔记 28天写作 价值

架构训练营第十二周作业

一期一会

hdfs hive 大数据MapReduce

架构师训练营第 1 期 - 大作业 (一)

wgl

架构师训练营第 1 期

大作业(二)

Pyr0man1ac

软件架构总结图

dll

架构师训练营 4 期 第2周

引花眠

架构师训练营 4 期

【薪火计划】10 - 目标计划管理

brave heart

管理 28天写作

SpringMVC学习!

程序员的时光

程序员 28天写作

记一次缓存服务器迁移史,心塞!

冰河

高并发 高性能 分布式缓存 数据同步 服务器迁移

十二、数据应用(一)

Geek_28b526

二层环路故障处理

架构师训练营大作业一

kawayi

架构师训练营大作业(一)

月殇

「架构师训练营第 1 期」

架构师训练营大作业(二)

月殇

第 12 周 系统架构作业

心在那片海

大作业2

大作业

solike

爱奇艺大数据生态的实时化建设-InfoQ