关于Flink:爱奇艺大数据生态的实时化建设

作者|爱奇艺大数据团队

数据作为互联网时代的根底生产资料，在各大公司企业领有无足轻重的位置。数据的价值在互联网公司的体现，大抵而言能够分成三类：

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 算法模型训练的相干工作。

毫无疑问，实时化肯定是大数据将来最重要的方向之一。爱奇艺大数据团队会沿着上述这些方向持续摸索和倒退，通过技术创新去反对和孵化更多落地的业务场景，持续推动爱奇艺的数据和产品向着实时化的方向倒退。