Flink 助力美团数仓增量生产

Posted 2021-04-02 Flink 中文社区

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

1. 数仓增量生产

2. 流式数据集成

3. 流式数据处理

4. 流式 OLAP 应用

5. 未来规划

Tips：点击文末「阅读原文」即可回顾作者原版分享视频～

一、数仓增量生产

 

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 修复数据。

• 充分利用资源，提前数据产出时间。

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

 

 

二、流式数据集成

 

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 的生产就可以提前了，节省了我们的成本。

 

 

三、流式数据处理

 

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 的开发的能力。

 

 

四、流式 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 中的任务配置的管理。

 

 

五、未来规划

 

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

 

 

---

▼ 关注「Flink 中文社区」，获取更多技术干货 ▼

戳我，回顾作者分享视频！