​
本文由美团研究员、实时计算负责人鞠大升分享，主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括：

先介绍一下美团数仓的架构以及增量生产。如下图所示，这是美团数仓的简单架构，我把它叫做三横四纵。所谓三横，第一是贯穿全链路的元数据以及血缘，贯穿数据集成、数据处理、数据消费、以及数据应用的全过程链路。另外一块贯穿全链路的是数据安全，包括受限域的认证系统、权限系统、整体的审计系统。根据数据的流向，我们把数据处理的过程分为数据集成、数据处理、数据消费、以及数据应用这 4 个阶段。

我们目前在 Flink 上面应用比较广泛的地方，包括从 Kafka 把数据导到 Hive，包括实时的处理，数据导出的过程。今天的分享就集中在这些方面。

美团的 Flink 目前大概有 6000 台左右的物理机，支撑了 3 万左右的作业。我们消费的 Topic 数在 5 万左右，每天的高峰流量在 1.8 亿条每秒这样的水平上。

美团 Flink 主要应用的场景包括四大块。

接下来我要引入增量生产的概念。离线数仓关注的三块需求，第一个就是时效性。第二个就是质量，产出的数据的质量。第三个就是成本。

关于时效性，有两个更深层次的含义，第一个叫做实时，第二个叫准时。并不是所有的业务需求都是实时的，很多时候我们的需求是准时。比如做经营分析，每天拿到相应的昨天的经营数据情况即可。实时数仓更多的是解决实时方面的需求。但是在准时这一块，作为一个企业，更希望在准时跟成本之间做一个权衡。所以，我把数仓的增量生产定义为对离线数仓的一个关于准时跟成本的权衡。另外，数仓增量生产解决比较好的一个方面是质量，问题能够及时发现。

数仓增量生产的优势有两点：

如下图所示，我们期望做的实际上是第二幅图。我们期望把离线的生产占用的资源降低，但同时希望它的产出时间能够提前一步。

我们来看一下流式数据集成的第一代。当数据量非常小以及库非常少的时候，直接做一个批的传输系统。在每天凌晨的时候把相应的 DB 数据全部 load 一遍，导到数仓里面。这个架构优势是非常简单，易于维护，但是它的缺点也非常明显，对于一些大的 DB 或者大的数据，load 数据的时间可能需要 2~3 个小时，非常影响离线数仓的产出时间。

基于这个架构，我们增加了流式传递的链路，我们会有经过流式传输的采集系统把相应的 Binlog 采集到 Kafka，同时会经过一个 Kafka 2 Hive 的程序把它导入到原始数据，再经过一层 Merge，产出下游需要的 ODS 数据。

数据集成 V2.0 的优势是非常明显的，我们把数据传输的时间放到了 T+0 这一天去做，在第二天的时候只需要去做一次 merge 就可以了。这个时间可能就从 2~3 个小时减少到一个小时了，节省出来的时间是非常可观的。

在形式上，数据集成的第三代架构前面是没什么变化的，因为它本身已经做到了流式的传输。关键是后面 merge 的流程。每天凌晨 merge 一个小时，仍然是非常浪费时间资源的，甚至对于 HDFS 的压力都会非常大。所以在这块，我们就迭代了 HIDI 架构。

这是我们内部基于 HDFS 做的。

我们设计 HIDI，核心的诉求有四点。第一，支持 Flink 引擎读写。第二，通过 MOR 模式支持基于主键的 Upsert/Delete。第三，小文件管理 Compaction。第四，支持 Table Schema。

基于这些考虑，我们来对比一下 HIDI，Hudi 和 Iceberg。

HIDI 的优势包括：

劣势包括：不支持增量读。

Hudi 的优势包括：

劣势包括：

Iceberg 的优势包括：支持和 Flink 集成。

劣势包括：

支持基于 Join 的 Upsert/Delete 

流式读取未支持。

如下图所示，我们有数据产生，数据集成，ETL 生产三个阶段。把流式数据集成做到 T+0，ETL 的生产就可以提前了，节省了我们的成本。

我们来讲一下 ETL 的增量生产过程。我们的数据从前面进来，到 Kafka 之后，有  Flink 实时，然后到 Kafka，再到事件的服务，甚至到分析的场景中，这是我们自己做的分析链路。

下面是批处理的一个链路，我们通过 Flink 的集成，集成到 HDFS，然后通过  Spark 去做离线生产，再经过 Flink 把它导出到 OLAP 的应用中。在这样的架构中，增量的生产实际上就是下图标记为绿色的部分，我们期望用 Flink 的增量生产的结构去替换掉 Spark。

这样的一个架构有三个核心的能力：

我们的全量用于查询和修复数据，而我们的增量是用来进行增量的生产。SQL 化是 ETL 增量生产的第一步，今天分享的主要是说我们基于 Flink SQL 做的实时数仓平台对这一块的支持。

如下图所示，这是实时数仓的模型。业界应该都看过这样的一个模型。

实时数仓的平台架构，分为资源层、存储层、引擎层、SQL 层、平台层、还有应用层。在这里重点强调两点：

这是我们数仓平台的一个 Web IDE。在这样的一个 IDE，我们支持了一个 SQL 的建模的过程，支持了 ETL 的开发的能力。

下面看关于流式的导出跟 OLAP 的应用这一块。如下图所示，是异构数据源的同步图。业界有很多开源的产品做这一块。比如说，不同的存储里面，数据总是在其中进行交换。我们的想法是做一个 Datalink 这样的一个中间件，或者是中间的平台。然后我们把 N 对 N 的数据交换的过程，抽象成一个 N 对 1 的交换过程。

异构数据源的第一版是基于 DataX 来做同步的架构。在这套架构里面，包含了工具平台层、调度层、执行层：

在这样的一个架构里面，发现两个核心的问题。第一个问题就是扩展性的问题。开源的单机版的 DataX 是一个单机多线程的模型，当我们需要传输的数据量非常大的时候，单机多线程模型的可扩展性是很大的问题。第二个问题在调度层，我们需要去管理机器、同步的状态、同步的任务，这个工作非常繁琐。当我们的调度执行机发生故障的时候，整个灾备都需要我们单独去做这块的事情。

基于这样的架构，我们把它改成了一个 Flink 的同步的架构。前面不变，还是工具平台层。在原有的架构里面，我们把调度层里面关于任务调度和执行机的管理这一块都交给了 Yarn 去做，这样我们就从中解脱出来了。第二个，我们在调度层里面的任务状态管理可以直接迁移到 cluster 里面去。

基于 Flink 的 Datalink 的架构优势非常明显。

我们看一下基于 Flink 的同步架构的关键设计，这里总结的经验有四点：

基于 Flink 我们做了 Datalink 这样的一个数据导出的平台，基于 Datalink 的导出平台做了 OLAP 的生产平台，在这边除了底层的引擎层之外，我们做了平台层。在这上面，我们对于资源、模型、任务、权限，都做了相应的管理，使得我们进行  OLAP 的生产非常快捷。

这是我们的 OLAP 生产的两个截图。一个是对于 OLAP 中的模型的管理，一个是对于 OLAP 中的任务配置的管理。

经过相应的迭代，我们把 Flink 用到了数据集成、数据处理、离线数据的导出，以及  OLAP 生产的过程中。我们期望未来对于流批的处理能够是统一的，希望数据也是流批统一的。我们希望，不管是实时的链路，还是增量处理的链路，在未来数据统一之后，统一用 Flink 处理，达到真正的流批一体。