共计 4234 个字符，预计需要花费 11 分钟才能阅读完成。
本文由美团研究员、实时计算负责人鞠大升分享，次要介绍 Flink 助力美团数仓增量生产的利用实际。内容包含：
- 数仓增量生产
- 流式数据集成
- 流式数据处理
- 流式 OLAP 利用
- 将来布局
一、数仓增量生产
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 解决，达到真正的流批一体。
