一、美团数仓架构图

如上图，是美团最新的数仓架构图。

整个架构图分为三层，从下往上看，最下面一层是数据安全，包括受限域认证系统、加工层权限系统，应用层权限系统，安全审计系统，来保证最上层数据集成与处理的安全；

中间一层是统一的元数据中心和全链路血缘，覆盖了全链路的加工过程；

最上层根据数据的流向，分成数据集成，数据处理，数据消费，数据应用，四个阶段；

在数据集成阶段，对于不同的数据来源（包括用户行为数据，日志数据，DB 数据，文件数据），都有相对应的数据集成系统，把数据收集到统一的存储之中，包括 Kafka 和 Hive 等。

在数据处理阶段，有一个面向用户的数据开发平台（万象平台），可以使用两条数据处理链路来加工数据，一个是流式处理链路，一个是离线处理链路。

数据加工好了之后，使用内部自研的 DeltaLink 同步数据到其他的应用中，例如即席分析，即席查询，报表等应用。

上图中标红的地方，Kafka -> HDFS，Flink，DeltaLink 是本次重点分享的内容。

二、美团当前 Flink 应用场景和规模

美团 Flink 应用场景包括：

实时数仓、经营分析、运营分析、实时营销
推荐、搜索
风控、系统监控
安全审计

Flink 集群规模如下（高峰流量是每天最高峰的流量）：

三、基于 Flink 的流式数据集成

数据集成经历了多个版本的迭代

1. 数据集成 V1.0

V1.0 版本很简单，是完全批量同步的架构。

在数据量比较少的情况下，这样的批同步的架构，优势很明显，架构简单，非常简单易于维护。

但是缺点也很明显，光是数据传输就 1 - 2 个小时。

2. 数据集成 V2.0

在 V2.0 中，增加了流式传输的链路（下面的链路），把数据实时传输到 ODS 中（批量传输的链路仍然是必须的，作为第一次全量的导入）。

流式传输系统，使用 canal （阿里开源）采集 Mysql 的 binlog 日志到 kafka。后边有一个 Kafka2Hive 系统，这个系统经过了多个版本的迭代。

Kafka2Hive 模块，最开始是使用 Camus ，每一个小时拉一次数据，跑在 Spark 上。后面改成使用 SparkStreaming ，但是 Spark Streaming 在资源的利用方面有一些问题的，所以最终弄全部迁移到了 Flink 框架上来。

这样的架构，优势是非常明显的：把数据传输放在了 T+0 的时间去做，T + 1 的时间只需要经过一次 Merge 即可，花费的时间可能就从 2 - 3 个小时减少到 1 个小时了，提升是非常明显的。

3. 数据集成 V3.0

数据集成 V3.0 的架构，前面的部分和 V2.0 一样，关键的是后面这一部分。

在 V2.0 架构中，凌晨需要对数据做一次 Merge，这个操作对于 Hdfs 的压力非常大，要把几十 T 的数据读过来，清洗一遍，再把几十 T 的数据写入到 Hdfs。

所以，在 V3.0 架构中，引用了 Hidi 架构（Hidi 是美团内部基于 Hdfs 开发的类似 Hudi 或者 Iceberg 的文件格式）。

4. 美团自研的 Hidi

要做到增量生产，最关键的特性在于

支持增量读取，也就是读取当前时间到前一段时间的数据，才能做到增量；
支持基于主键的 Upsert/Delete。Hidi 是美团在 2，3 年前，在内部自研的架构，此架构的特性在于：
支持 Flink 引擎读写；
通过 MOR 模式支持基于主键的 upsert/Delete；
小文件管理 Compaction；
Table Schema

可以对比 Hidi、Hudi、Iceberg，如下：

Hudi 最亮眼的特性是支持基于主键的 Upsert/Delete，但劣势是深度和 Spark 绑定，但在国内 Flink 框架这么火热的情况下，难免会有点美中不足。

Iceberg 不依赖于执行引擎，可以深度和 Flink 集成。

美团自研的 Hidi 则根据自己的需求实现了诸多的特性，目前仍然在完善中。

四、基于 Flink 的增量生产

1、传统离线数仓特性分析

一般我们说数仓，都是指离线数仓。离线数仓有三个重要的指标，一是时效性，二是质量，三是成本。

首先是时效性，有两个更深层次的含义，一个是实时，一个是准时。

实时就是实时流式处理，来一条处理一条，实时处理消耗的资源很多。

准时，就是按时处理。比如广告需求，可能只需要在每个整点，统计过去一小时或者在每个整点统计当天的数据即可，没有必要做到实时，只需要到点能产出数据就行。

所以，总结下来，离线数仓和实时数仓各有利弊，离线数仓在质量和成本上会有优势，但是时效性不足；实时数仓，在时效性上很有优势，但是质量和成本都略逊色。

2. 增量生产

如下图，是离线数仓、实时数仓和增量计算的对比

所谓增量计算，就是企业在时效性、质量、成本上做一个权衡，时效性需要高一点，但是不用做到 RealTime，OnTime 也可以接受（ 8 点看报表，提前到 3 点计算好也没有很大的意义），但是质量要高，成本也需要尽量少。

3. 增量计算的优点

增量计算最大的优点，就是可以尽快的发现问题。

一般我们会在第二天花 8 个小时到 12 个小时，把前一天的数据生产出来。但是如果第二天发现数据错了，可能要花一天的时间去修复数据，这个时候，准时性和质量都被打破了。

如下图，横坐标是时间（T 表示当天，T+1 表示第二天），黑色线表示离线生产，大概利用 T + 1 一半资源去生产。红色线是实时生产，在当天就生产数据，占用的资源比离线计算高。

下图是增量生产的示意图。

绿色线是增量计算，在当天就计算好。

黑色线是离线计算，在第二天的前半天计算。

增量计算，是在当天计算，在当天就能提前发现问题，避免 T + 1 修复数据。并且还可以充分利用资源，提前产出数据的时间，并且占用资源更少。

4. 增量生产架构图

下图是美团增量生产的架构图（目前的架构正在逐步完善中，还没有完全实现）

如图，最上面是实时处理的链路，Flink 消费 Kafka 数据到下游的 kafka，输出结果给下游使用或者供 OLAP 分析。

下面的链路是批处理，首先 kafka 数据经过 Flink 集成到 HDFS，再通过 Spark 做离线的生产，最终经过 Flink 导出到 OLAP 应用里面去。

上文提到的增量生产，就是图中标绿色的部分，希望可以用增量生产来替换掉 Spark 离线计算，做到计算引擎的统一。

要能支持增量生产，需要具备几个核心的能力：

Flink SQL 能力能够对齐 Spark SQL；
Hidi 支持 Upsert/Delete 特性（Hidi 已支持）；
Hidi 支持全量和增量的读取，全量读取用于查询和修复数据，增量读取用来增量生产；

五、实时数仓模型与架构

如下图是实时数仓的模型，基本上都见过

下图是实时数仓平台的架构图

整个架构，分为资源层、存储层、引擎层、SQL 层、平台层和应用层。

六、流式导出与 OLAP 应用

1. 异构数据源的同步

如上图，是异构数据源的同步。数据会在不同的存储系统中交换，所以我们做了一个 Deltalink 的平台，把数据 N 对 N 的交换过程，抽象成 N 对 1 的交换过程。

我们也迭代改进了很多版本。

2. 第一版实现

第一版是基于 DataX （阿里开源）来做同步，包含工具平台层，调度层，执行层。

工具平台层，对接用户，用来配置同步任务，配置调度，运维任务；
调度层，负责任务的调度，管理任务状态管理，以及执行机的管理，这其中有非常多的额外工作都需要自己做；
执行层，通过 DataX 进程，以及 Task 线程从源存储同步到目标存储。

但劣势也很明显，开源版的 DataX 是一个单机多线程的模型，当数据量非常大的时候，单机多线程是成为了瓶颈，限制了可扩展性；

然后在调度层，需要管理机器，管理同步的任务和状态，非常繁琐；

当调度执行机发生故障的时候，整个灾备都需要单独去做。

3. 第二版实现

在第二版中，改成了基于 Flink 同步的架构，看起来就清爽了很多。

工具平台层没有变，调度层的任务调度和执行机管理都交给 Yarn 去做。

调度层的任务状态管理，可以迁移到 Client 中去做。

基于 Flink 的 DeltaLink 的架构，解决了可扩展性问题，而且架构非常简单。

当把同步的任务拆细之后，可以分布式的分布到不同的 TaskManager 里去执行。

并且离线和实时的同步，都可以统一到 Flink 框架中去，这样离线和实时同步的 Source 和 Sink 组件都可以共用一套。

4. 基于 Flink 的同步架构关键设计

避免跨 TaskManager 的 Shuffle，避免不必要的序列化成本；Source 和 Sink 尽量在同一个 TaskManager；
务必设计脏数据收集旁路和失败反馈机制；数据同步遇到脏数据的时候，比如失败了 1% 的时候，直接停下来；
利用 Flink 的 Accumulators 对批任务设计优雅退出机制；数据传输完之后，通知下游数据同步完了；
利用 S3 统一管理 Reader/Writer 插件，分布式热加载，提升部署效率；很多传输任务都是小任务，而作业部署时间又非常长，所以需要要提前部署插件；

5. 基于 Flink 的 OLAP 生产平台

基于 Flink 做了 Deltalink ，数据导出的平台；

基于数据导出的平台，做了 OLAP 平台，对于资源，模型，任务和权限都做了管理。

七、未来规划

经过多次迭代，把 Flink 用到了数据集成、数据处理、离线数据导出、OLAP 等场景，但事情还没有结束。

未来的目标，是要做到流批一体，把离线作业都迁移到 Flink 上来；

同时数据也要做到批流一体，这个很重要。如果数据仍然是两份，是两套 Schema 定义，那么不管如何处理，都需要去对数据，就不是真正的流批统一。

所以不管是计算还是存储，都使用 Flink，达到真正的流批一体。

Flink 数据湖 助力美团数仓增量生产