Flink 在实时计算平台和实时数据仓库中的作用

架构选型

首先在架构上，Flink 采用了经典的主从模式，DataFlow Graph 与 Storm 形成的拓扑 Topology 结构类似，Flink 程序启动后，会根据用户的代码处理成 Stream Graph，然后优化成为 JobGraph，JobManager 会根据 JobGraph 生成 ExecutionGraph。ExecutionGraph 才是 Flink 真正能执行的数据结构，当很多个 ExecutionGraph 分布在集群中，就会形成一张网状的拓扑结构。

其次在容错方面，针对以前的 Spark Streaming 任务，我们可以配置对应的 checkpoint，也就是保存点（检查点）。当任务出现 failover 的时候，会从 checkpoint 重新加载，使得数据不丢失。但是这个过程会导致原来的数据重复处理，不能做到“只处理一次”的语义。Flink 基于两阶段提交实现了端到端的一次处理语义。

在任务的反压上，Flink 没有使用任何复杂的机制来解决反压问题，Flink 在数据传输过程中使用了分布式阻塞队列。我们知道在一个阻塞队列中，当队列满了以后发送者会被天然阻塞住，这种阻塞功能相当于给这个阻塞队列提供了反压的能力。

这些优势和特性，使得 Flink 在实时计算平台的搭建上占有一席之地。

实时计算平台整体架构

一般的实时计算平台的构成大都是以下几部分构成。

• 实时数据收集层
  

在实际业务中，大量的实时计算都是基于消息系统进行的数据收集和投递，这都离不开强大的消息中间件。目前业界使用最广的是 Kafka，另外一些重要的业务数据还会用到其他消息系统比如 RocketMQ 等。Kafka 因为高吞吐、低延迟的特性，特别适合大数量量、高 QPS 下的业务场景，而 RocketMQ 则在事务消息、一致性上有独特的优势。

• 实时计算层
  

Flink 在计算层同时支持流式及批量分析应用，这就是我们所说的批流一体。Flink 承担了数据的实时采集、实时计算和下游发送的角色。随着 Blink 的开源和一些其他实时产品的开源，支持可视化、SQL 化的开发模式已经越来越普及。

• 数据存储层
  

这里是我们的实时数据存储层，存储层除了传统 MySQL 等存储引擎以外，还会根据场景数据的不同存储在 Redis、HBase、OLAP 中。而这一层我个人认为最重要的技术选型则是 OLAP。OLAP 的技术选型直接制约着数据存储层和数据服务层的能力。关于 OLAP 的技术选型，可以参考这里。

• 数据服务层
  

数据服务层会提供统一的对外查询、多维度的实时汇总，加上完善的租户和权限设计，能够支持多部门、多业务的数据需求。另外，基于数据服务层还会有数据的展示、大屏、指标可视化等。

实时计算平台实际应用

美团在公开发表的文章中提到，目前美团实时计算平台的架构组成：最底层是实时数据收集层，使用 Kafka 进行数据收集，支撑了大量的实时计算和离线数据拉取任务。

基于实时数据收集层之上，是基于 Flink 的实时计算层，美团选择了 Flink on Yarn 模式，并且选择了 Redis、HBase 和 ElasticSearch 作为数据存储。同时，美团还面向数据开发者进行作业托管、作业调优和诊断报警功能。

整体来看，美团的实时计算平台主要包含作业管理和资源管理两个方面的能力。基于作业管理上可以做到任务的发布、回滚、状态监控等，在资源管理上基于多租户的设计进行业务隔离，并且 Flink Job 采用 on Yarn 的模式，任务之间进行资源隔离。

根据公开的技术分享文档来看，目前美团点评的实时计算平台节点已经达到几千台，在资源的优化上需要做到自动扩容、缩容，另外实时计算任务和离线任务的混合部署也需要考虑到如何进行更细粒度资源的释放。

美团的实时计算平台图

微博的实时计算平台是随着业务线的快速扩张，为了满足业务需求逐渐演变。在初期架构中，仅仅存在计算和存储两层，每次接入一个新的实时计算业务就要重新开发一遍，代码的利用率低下，接入成本很高。

基于上面的需求，微博开发了基于 Flink 的通用组件，用来快速支持实时数据的快速接入。从下到上共分为五层，分别是接入层、计算层、存储层、服务层和应用层。整体的架构图如下图所示：

微博的实时计算平台图

基于微博的实时计算架构，数据从产生进入消息系统，通过 Flink 进行 ETL 进入存储层。根据业务不同的指标和数据需求，写入不同的存储中。统一查询服务则根据目前业务的需要，将查询服务微服务化，从数仓如 Redis、ElasticSearch、MySQL 等不同的存储中直接抽取。

微博的实时计算平台初期架构仅仅包含计算和存储两层，每个新的实时计算需求都要重新开发一遍，代码利用率低、重复开发。不同业务的不同需求对同一个指标的计算没有进行统一。随着数据量和业务的增长，前期架构的弊端开始显现，逐步发展成现在通用的计算架构。

在全新的计算架构下，微博基于 ClickHouse 进行多维度的计算来满足大数据量下的快速查询需求。数据分层上也借鉴了离线数仓的经验，构建了一套多层级的实时数仓服务，并且开发了多种形式的微服务对指标提取、数据聚合、数据质量、报警监控等进行支持。

基于 Flink 的实时数据仓库

我们在之前的课程中提过，Flink 的实际应用场景之一就是实时数据仓库。

实时数仓背景

传统的离线数据仓库将业务数据集中进行存储后，以固定的计算逻辑定时进行 ETL 和其他建模后产出报表等应用。离线数据仓库主要是构建 T+1 的离线数据，通过定时任务每天拉取增量数据，然后创建各个业务相关的主题维度数据，对外提供 T+1 的数据查询接口。

离线数据仓库 ETL 和实时数据仓库的差异图

上图展示了离线数据仓库 ETL 和实时数据仓库的差异，可以看到离线数据仓库的计算和数据的实时性均较差。数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快地达到用户的手中，实时数仓的构建需求也应运而生。

实时数据仓库的建设是“数据智能 BI”必不可少的一环，也是大规模数据应用中必然面临的挑战。

Flink 在实时数仓的优势

Flink 在实时数仓和实时 ETL 中有天然的优势：

状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对状态进行访问和管理，Flink 支持强大的状态管理；

丰富的 API，Flink 提供极为丰富的多层次 API，包括 Stream API、Table API 及 Flink SQL；

生态完善，实时数仓的用途广泛，Flink 支持多种存储（HDFS、ES 等）；

批流一体，Flink 已经在将流计算和批计算的 API 进行统一。

实时数仓的实际应用

离线数据仓库的设计中，我们会把仓库结构分为不同的层次来存储不同的数据，大概可以分为：ODS 源数据、DWD 明细层、DWS 汇总层、ADM 应用层。在实时数据仓库的设计中也可以参考这个设计。

但是需要注意的是，在实时数据模型的处理方式上和离线有所区别。例如，明细层的汇总一般是基于 Flink 等接入 Kafka 消息进行关联的，维度表的数据一般会放在 HDFS、HBase 中作为明细层的补充。另外，在实时数据仓库中要选择不同的 OLAP 库来满足即席查询。

我们来看一下网易严选和美团的实时数据仓库的设计分别是怎样的。

网易严选

网易严选的实时数据仓库设计图

如上图所示，网易严选的实时数据仓库 ODS 层主要是基于 Kafka 的事实数据，经过 Flink 处理后形成 DWD 明细层，在 DWD 层中会关联一些维度和历史数据，并且存入 Redis 中。在 DWS 层中会根据不同的业务场景有不同的存储，高并发查询和写入会基于 HBase 进行。如果你需要基于明细做不同维度的汇总那么就要在 GreenPulm 这个 OLAP 引擎中进行查询分析，另外一些维度较多的查询、排序等直接存储在 Redis 中供查询使用。

我们可以看出网易严选在建设实时数仓的主要考量是计算和存储。在计算上，网易严选选择了 Flink，主要是因为 Flink 的端到端的精确一次语义支持和容错特性。另外在存储方面，网易严选选择把 Flink 处理完的数据备份到 Kafka，并且根据业务场景和数据应用特点选择了不同的存储介质，例如一些高并发查询会基于 HBase 进行，常见的汇总指标会放入 MySQL 中直接使用。

在我们的实际业务场景下，明细和汇总数据会根据查询 QPS、维度的复杂程度等选择不同的介质，其中 HBase、OLAP、Redis 等都是常见存储介质，需要用户根据实际业务进行选择。

美团

下图是美团的实时数仓分层的架构模型图：

ODS 层，基于 MySQL Binlog 和 Kafka 的日志消息；

明细层，基于事实数据关联成明细数据；

汇总层，使用明细数据进行多维度的查询汇总；

应用层，对外提供 HTTP、RPC 等查询服务。

美团的实时数仓分层架构模型图

美团的 ODS 存放的主要是业务数据，其中大多是基于 MySQL 的 Binlog 和消息数据，这也是我们在实际业务中常用的方法。我们在建设实时数据仓库的过程中一个要求就是要和实际业务系统进行解耦，所以消息系统是我们的必然选择。

明细层是根据业务进行的划分，这一层的计算主要是基于 Flink 进行的，这一层承担着业务数据的解析、关联维表、明细存储的功能。

汇总层会基于明细数据进行再次关联和汇总，根据业务需要产出中间层和指标结果层。

最上层是同一对外服务的应用层，这层在我们的实际应用中非常重要。主要是根据外部系统的查询需要提供不同的查询服务，基于 HTTP、RPC 等的查询服务是常见选择，我们需要仔细评估访问的 QPS、查询负载等对接口进行限流、幂等、容错设计。并且需要进行严格的权限设计，防止数据泄露和非法访问。

总结

本课时我们讲解了基于 Flink 的实时计算平台的设计和架构，并且讲解了美团和微博的实时计算平台设计；与此同时还讲解了 Flink 在实时数仓的优势和应用。总体来看，实时数据平台和实时数仓在业界已经有了较为成熟的方案，我们可以根据已有的方案和公司业务设计自己的实时计算平台和实时数据仓库。