Flink 助力美团数仓增量生产

简介： 本文由美团研究员、实时计算负责人鞠大升分享，主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括：一、数仓增量生产；二、流式数据集成；三、流式数据处理；四、流式 OLAP 应用；五、将来规划。

1、数仓增量生产

1.美团数仓架构

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

在数据集成阶段，咱们对于公司内部的，好比说用户行为数据、日志数据、DB 数据、还有文件数据，都有相应的集成的系统把数据统一到咱们的数据处理的存储中，好比说 Kafka 中。
在数据处理阶段，分为流式处理链路、批处理链路以及基于这套链路的数仓工做平台（万象平台）。生产出来的数据，通过 Datalink 导入到消费的存储中，最终经过应用以不一样的形式呈现出来。

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

2.美团 Flink 应用概况

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

3.美团 Flink 应用场景

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

• 第一，实时数仓、经营分析、运营分析、实时营销。
• 第二，推荐、搜索。
• 第三，风控、系统监控。
• 第四，安全审计。

4.实时数仓 vs 数仓增量生产

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

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

5.数仓增量生产的优点

数仓增量生产的优点有两点。

• 可以及时发现数据质量问题，避免 T+1 修复数据。
• 充分利用资源，提早数据产出时间。

以下图所示，咱们指望作的其实是第二幅图。咱们指望把离线的生产占用的资源下降，但同时但愿它的产出时间可以提早一步。

2、流式数据集成

1.数据集成 V1.0

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

2.数据集成 V2.0

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

数据集成 V2.0 的优点是很是明显的，咱们把数据传输的时间放到了 T+0 这一天去作，在次日的时候只须要去作一次 merge 就能够了。这个时间可能就从 2~3 个小时减小到一个小时了，节省出来的时间是很是可观的。

3.数据集成 V3.0

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

这是咱们内部基于 HDFS 作的。

4.HIDI

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

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

HIDI 的优点包括：

• 支持基于主键的 Upsert/Delete
• 支持和 Flink 集成
• 小文件管理 Compaction

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

Hudi 的优点包括：

• 支持基于主键的 Upsert/Delete
• 小文件管理 Compaction

劣势包括：

• 写入限定 Spark/DeltaStreamer
• 流读写支持 SparkStreaming

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

劣势包括：

• 支持基于 Join 的 Upsert/Delete
• 流式读取未支持。

5.流式数据集成效果

以下图所示，咱们有数据产生，数据集成，ETL 生产三个阶段。把流式数据集成作到 T+0，ETL 的生产就能够提早了，节省了咱们的成本。

3、流式数据处理

1.ETL 增量生产

咱们来说一下 ETL 的增量生产过程。咱们的数据从前面进来，到 Kafka 以后，有 Flink 实时，而后到 Kafka，再到事件的服务，甚至到分析的场景中，这是咱们本身作的分析链路。

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

2.SQL 化是 ETL 增量生产的第一步

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

• 第一， Flink 的 SQL 的能力要对齐 Spark。
• 第二， 咱们的 Table Format 这一层须要可以支持 Upsert/Delete 这样的主键更新的实时操做。
• 第三， 咱们的 Table Format 可以支持全量和增量的读取。

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

3.实时数仓模型

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

4.实时数仓平台架构

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

• 第一，是对于 UDF 的支持。由于 UDF 是弥补算子能力中的很是重要的一环，咱们但愿在这里面作的 UDF 可以加大对于 SQL 能力的支持。
• 第二，是在这个架构里面只支持了 Flink Streaming 的能力，咱们并无去作 Flink 的批处理的能力，由于咱们设想将来全部的架构都是基于 streaming 去作的，这跟社区的发展方向也是一致的。

5.实时数仓平台 Web IDE

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

4、流式 OLAP 应用

1.异构数据源同步

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

2.基于 DataX 的同步架构

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

• 工具平台层的任务很是简单，主要是对接用户，配置同步任务，配置调度，运维。
• 调度层负责的是任务的调度，固然对于任务的状态管理，以及执行机的管理，不少的工做都须要咱们本身去作。
  在真正的执行层，经过 DataX 的进程，以及 Task 多线程的一个形式，真正执行把数据从源同步到目的地。
• 在这样的一个架构里面，发现两个核心的问题。第一个问题就是扩展性的问题。开源的单机版的 DataX 是一个单机多线程的模型，当咱们须要传输的数据量很是大的时候，单机多线程模型的可扩展性是很大的问题。第二个问题在调度层，咱们须要去管理机器、同步的状态、同步的任务，这个工做很是繁琐。当咱们的调度执行机发生故障的时候，整个灾备都须要咱们单独去作这块的事情。

3.基于 Flink 的同步架构

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

基于 Flink 的 Datalink 的架构优点很是明显。

• 第一， 可扩展性问题获得解决了，同时架构也很是简单。如今当咱们把一个同步的任务拆细以后，它在 TaskManager 里面能够扩散到分布式的集群中。
• 第二， 离线跟实时的同步任务，都统一到了 Flink 框架。咱们全部同步的 Source 和 Sink 的主键，均可以进行共用，这是很是大的一个优点。

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

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

• 第一，避免跨 TaskManager 的 Shuffle，避免没必要要的序列化成本；
• 第二，务必设计脏数据收集旁路和失败反馈机制；
• 第三，利用 Flink 的 Accumulators 对批任务设计优雅退出机制；
• 第四，利用 S3 统一管理 Reader/Writer 插件，分布式热加载，提高部署效率。

4.基于 Flink 的 OLAP 生产平台

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

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

5、将来规划

通过相应的迭代，咱们把 Flink 用到了数据集成、数据处理、离线数据的导出，以及 OLAP 生产的过程当中。咱们指望将来对于流批的处理可以是统一的，但愿数据也是流批统一的。咱们但愿，不论是实时的链路，仍是增量处理的链路，在将来数据统一以后，统一用 Flink 处理，达到真正的流批一体。

做者：阿里云实时计算Flink
原文连接 本文为阿里云原创内容，未经容许不得转载