五、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 的技术选型，可以参考这⾥。
数据服务层
hbase的特性有哪些数据服务层会提供统⼀的对外查询、多维度的实时汇总，加上完善的租户和权限设计，能够⽀持多部门、多业务的数据需求。另外，基于数据服务层还会有数据的展⽰、⼤屏、指标可视化等。
实时计算平台实际应⽤
美团在公开发表的⽂章中提到，⽬前美团实时计算平台的架构组成：最底层是实时数据收集层，使⽤ 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 在实时数仓的优势和应⽤。总体来看，实时数据平台和实时数仓在业界已
经有了较为成熟的⽅案，我们可以根据已有的⽅案和公司业务设计⾃⼰的实时计算平台和实时数据仓库。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。