Flink 方案设计

1：基于 Flink 的实时数据仓库是如何做的？

我们要从 Flink 的优势开始入手，介绍基于 Flink 的实时数仓建设的关键技术选型和整体设计。

传统的离线数据仓库将业务数据集中进行存储后，以固定的计算逻辑定时进行ETL和其他建模后产出报表等应用。离线数据仓库主要是构建 T+1 的离线数据，通过定时任务每天拉取增量数据，然后创建各个业务相关的主题维度数据，对外提供 T+1 的数据查询接口。计算和数据的实时性均较差，业务人员无法根据自己的即时性需要获取几分钟之前的实时数据。数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快地达到用户的手中，实时数仓的构建需求也应运而生。

总之就是一句话：时效性的要求。

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 库来满足即席查询。

此外，可以将自己的实时数据的架构图完整画出来，这样会给人很深刻的印象，你可以参考下面两张架构设计图。

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

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

2：基于 Flink 的实时计算平台是如何做的？

实时计算平台的搭建是随着越来越多的业务场景需要实时计算而产生的。由于离线计算天然时效性不强，一般都是隔天级别的滞后，业务数据随着实践的推移，本身的价值就会逐渐减少。

由于 Flink 在架构、容错、反压上表现出来的优势和特性，使得 Flink 在实时计算平台的搭建上占有一席之地。

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

• 实时数据收集层
  

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

• 实时计算层
  

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

• 数据存储层
  

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

• 数据服务层
  

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

我们在回答这个面试问题时，可以结合自己的实际项目回答，例如，在实时数据收集层中的技术选型是什么、支持了多大的数据量以及取得的业务成果；并且可以把自己的架构图完整地画出来。你也可以参考下面的架构图来画出自己的整体架构图。

美团的实时计算平台图

微博的实时计算平台图

3：有没有做过基于 Flink SQL 的计算平台？你有什么思路？

基于 Flink SQL 的实时计算平台是很多大公司提高开发效率、降低开发成本、降低维护成本作出的选择。一般的 SQL 开发平台都会有以下几个模块：

• SQL 开发和提交模块
• 完善的权限管理体系
• UDF 管理模块
• 资源调度模块
• 日志和监控模块
  

这其中，SQL 的开发和提交是核心，成熟的 SQL 开发平台应该是和公司常用的组件栈打通，基于 Flink 原生的 SQL 模块支持更为丰富的 Source 和 Sink。并且支持丰富的作业配置，如作业 Checkpoint、重启策略等。

权限管理模块中，我们的 SQL 应该在作业级别进行多租户的权限管控，对于原表和目标表更应该精确到开发者级别。

UDF 模块应该支持用户自定义基于业务的复杂 UDF，并且可以快捷方便地更新版本。

资源和调度模块可以支持算子级别的并行度和内存设置，并且应该支持作业在不同集群间进行切换。

日志和监控模块中是我们进行作业调优、异常监控非常重要的模块，我们应该有专门的服务进行日志收集和查询，异常监控方面可以做到指定到人且不同渠道（邮件、电话、钉钉等）的报警。