共计 5692 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：本文整顿自美团零碎研发工程师汤楚熙，在 Flink Forward Asia 2022 实时湖仓专场的分享。本篇内容次要分为四个局部：
- 建设背景
- 外围能力设计与优化
- 业务实际
- 将来瞻望
点击查看原文视频 & 演讲 PPT
一、美团增量数仓的建设背景
美团数仓架构的诞生是基于这样的技术假如：“随着业务数据越积越多，增量数据 / 存量数据 的比值呈降落趋势，采纳增量计算模式性价比更高。”
当然也与底层技术的倒退有很强的相关性，Flink、Hudi 等具备增量计算、更新能力的技术框架，为增量数仓落地的提供了必要条件。
从工夫线上看，增量数仓架构的演进过程可大抵划分为三个阶段：
- 第一个阶段，2019 到 2020 年。这个阶段，业务心愿在离线数仓的能力之上，失去更陈腐的数据，即实时数仓。所以咱们借鉴了离线数仓的模型概念，提出了实时数仓的模型形象。
- 第二个阶段，2020 到 2021。这个阶段实时数仓的生产工作还大量依赖 JavaAPI，对开发效率有较大的影响，所以咱们要放慢 FlinkSQL 的落地，晋升数仓开发的效率。
- 第三个阶段，从 2021 年到当初。这个阶段随着数据湖技术的逐步成熟，咱们开始尝试整合离线跟实时数仓架构，进而提出了一套增量数仓的新架构。
目前美团外部会有 M、B、C、D 端等四大类业务场景，不同的场景之间对数据一致性、时效性的要求有穿插，但又不完全相同，须要寻找一套尽可能适配所有这些场景的技术架构。
首先咱们会想到的是 Lambda 架构，它会通过实时链路解决高时效性的用数场景的需要；并通过离线链路来解决一些长业务周期的指标计算的需要；以及对数据一致性要求较高的场景的用数需要。
Lambda 架构最大的问题生产链路过于简单，一方面造成较高的资源老本，另外是昂扬运维的老本。
比方对高数据新鲜度的场景，高度依赖 Kafka，而其最后的架构设计就没有充分考虑到对数据一致性的保障。
业务会通过排序、幂等解决等伎俩就义计算资源，达成了数据一致性。
此外还有的问题是，运维门槛高。一个的典型的案例是，美团某 B 端业务场景对数据新鲜度要求较高，其交易主题表要求在 Flink 作业中保留 180 天状态数据，单任务状态大小 >50TB，改口径后的间接生产上游 MQ 回溯数据，时长会超过 1 天，业务方很难承受，目前只能被动革新成先刷离线不变数据，再刷增量变更数据。
对时延不敏感，但须要可能灵便的将数据按不同粒度进行组织拜访的离线场景，重度依赖于 Hive，而其的最后也并未思考到数据高效的更新的能力。
典型的例子是，离线数仓最新快照事实表的生产场景，这种类型数据在业务上很常见，要求将上游的按天、小时生产的 DeltaRecord 与上游表中的存量数据快照做 Merge，实践上只需从存量快照数据中按 DeltaRecord 的 key 取出全副变更记录，Merge 之后再笼罩写即可。但以后离线数仓的广泛做法是全量加载存量快照数据，再与增量数据做归并排序后取最新一条，未变更记录的加载是非必要且浪费资源的。
咱们冀望增量数仓架构，可能很好的同时兼顾数据的时效性和数据一致性，并且低成本的实现数据的合并计算、高效组织。
绝对基于 Kafka 构建的实时数仓来看，增量数仓须要晋升回溯场景的效率、升高为保证数据一致性的资源开销。
绝对基于 Hive 构建离线数仓，在没有就绪工夫提前的前提要求下，可持续沿用批模式来执行增量数据合并，晋升计算效率。
二、外围能力设计与优化
2.1 增量数仓存储架构
实现增量计算、更新，引入了一套反对事务管理、主键和 CDC 能力，可同时按局部行和列进行更新，并且对查问敌对的新的存储引擎。这个新存储引擎的名字咱们外部叫做 Beluga，它的根本架构是在 Hudi 的根底上，加以革新而来。
革新 Hudi 的动机是，最后 v0.8 不反对 CDC。思考到了这点，咱们引入 Hbase(KV)来生产 Changelog。
Beluga 有三个外围模块：
- Beluga Client，运行在 Flink 作业中，次要用来解决读写申请和事务的协调。
- Beluga Server，是基于 Hbase 来革新实现的，次要承当数据的更新、ChangeLog 的生产能力。
- Beluga File Store，这层是基于 Hudi 来实现，次要用于存储 CDC 数据和快照数据。
2.2 优化分桶策略
Beluga 的增量行更新能力，是借助数据分桶来实现的。
第一步使 Hbase 和 Hudi 的分桶模型对立。这里将 Hbase 的 HRegion 和 Hudi 的 FileGroup 做了一一映射，独特组成了一个分桶。新记录会先过 Hbase 的 Region，而后按需生产出 Changelog，将数据刷入 Hudi。
这样做的益处是，Hudi 自身就能够将 Hbase 作为其内部索引，能够晋升数据的更新效率。
后期测试过程中发现，Hudi 原生的分桶策略，想要正确应用，是有比拟高的门槛的。这个门槛高次要体现在，使用不当会造成性能体现不佳：
- 须要思考估算事务提交的频率与每次提交的数据量，否则会产生较多的小文件，影响读性能。
- 用户须要自行解决分桶间数据歪斜，否则会影响上游有序生产工作的读性能。
- Hudi 的小文件复用策略应用 HDFS 的 append 接口，写性能差。
- 每次制作 Checkpoint 时，须要从新获取 Hudi 元数据，工夫开销大。
为了解决这些问题，Beluga 设计了一套固定分桶策略。通过这套新分桶策略，咱们在数据写入前就确定了其所属的分桶，而不是随着工夫的变动，动静的减少分桶，这样无效管制了文件数的增长。
并且因为引入了 Hbase，对于数据更新操作，能够缩小通过 HDFS 拉取文件结构元数据和索引的频率，进一步晋升读写性能。
面对数据歪斜问题，咱们退出了一套平衡算法，最大水平上保障分桶间的数据量放弃平衡。
2.3 CDC 数据格式优化
Hudi 原生 CDC 能力，依赖 Flink 的回撤机制产生的 Changelog 来实现，但测试的过程中，发现存在数据不统一的危险。
从上图中能够看到，Flink 回撤机制无奈保障，UPDATE 事件的 -U/+U 音讯在一次事务中，同时提交。如果 +U 与 -U 不在一次事务中提交，一旦上游节点产生故障，导致数据失落。对于上游来讲，可能造成永久性的数据不统一。为此，咱们进行了如下优化。
从左图中咱们能够看到，咱们将 UPDATE 事件的 UPDATE_BEFORE 与 UPDATE_AFTER 事件合并到一条记录中，相似 MySQL 的 Binlog。
这样能够保障更好的原子性，打消了数据不统一的危险。并且肯定水平的使数据更紧凑，肯定水平的缩小序列化的开销。而且咱们也理解到 Hudi 在 0.13 后也会采纳相似的设计。
2.4 扩大有状态计算场景
建设实时数仓过程中，咱们发现 Beluga 还能够低成本的解决一些有状态计算场景问题。
比方当业务遇到长周期的多流数据关联时，为了保证数据的一致性，须要在 Flink 状态中保留很长一段时间的数据快照。一方面，因为状态量过大，影响 Checkpoint 制作的稳定性。另一方面，因为 Flink 外部状态无奈在多作业进行共享，有些作为公共维表的数据存储，存在资源节约。
针对这种场景，咱们能够通过 Beluga 的 Hbase 自带的 Cell 级别的更新能力，实现一些长周期、双流关联的业务场景需要。实践上咱们还能够借助 Hbase 的点查能力，反对维度关联 Lookup-join 的场景。
一方面，能够缓解 Checkpoint 的压力。另一方面，数据可跨作业共享，资源利用率也失去了晋升。
2.5 批流一体数据生产、运维能力
数据回溯是很常见的运维场景，已知在达到雷同的计算吞吐量的状况下，流计算模式，要比批模式运行应用更多的计算资源。所以这里会采纳 Flink 批工作实现数据的回溯。
咱们发现，公司一些业务的业务数据的状态流转周期不固定。如一张事实表，依照事件工夫进行分区后，它最近几个物理分区内的数据都有可能被流工作更新。
如果此时不加限度的应用批工作，就可能会笼罩更陈腐的数据，影响最终计算结果。属于典型的写到写的并发抵触。
要解决这个问题，会让业务先停掉流计算工作，再用批工作进行数据笼罩更新。实现批笼罩写之后，再重新启动流工作，回补断流期间的数据。
在一些无写抵触的状况下，能够不停掉流计算工作。等到批工作实现数据更新后，再结合实际状况，抉择通过流工作来回放批未笼罩到的分区数据。这样能够肯定水平的缩小断流时长，放慢了数据回溯的过程。
为了防止用户误操作，咱们在工具链层面，对可能有并发写抵触危险的作业，进行事先拦挡。
三、业务实际
上面这部分讲一下，业务如何借助增量数仓改良其数仓架构问题，重点介绍以下三个案例：
- 案例一：通过增量的计算模式减速数据入仓，从而解决离线数仓就绪工夫晚的问题。
- 案例二：如何利用新的技术架构，通过增量计算模式，无效晋升一些事实表生产效率。
- 案例三：业务如何通过批流一体增量数据生产架构，晋升数仓的开发运维效率。
3.1 案例一：如何减速数据入仓
采纳增量数仓架构呈现之前，业务数据入仓大略要分为以下几个关键步骤。先将 Binlog 和服务器日志收集到 Kafka 中，而后再落 Hive。此刻数据并没有实现荡涤和加工，无奈间接交付给业务应用。接下来再通过一个批处理工作，对 Hive 上的原始日志进行荡涤和转换，落入 Hive 新表。这时才算正式实现数据入仓。
这种计划次要面临以下两点问题：
- 因为采纳批计算模式，凌晨发动工作集中调度时，因资源有余而引起作业大量排队，从而影响作业就绪工夫。
- Binlog 的增量日志须要与 ODS 表中已存在的全量日志进行合并，能力交付给上游应用的。这个行为的工夫开销也较大，会影响到 ODS 层数据的就绪工夫。
在美团的用户行为日志明细数据入仓的场景中，业务的原始日志收集、落 Hive 的过程，问题都不大。但从原始日志荡涤出 PV/MV 事件表时，数据的产出工夫很不稳固。
从图上咱们能够看到，一些极其状况下，这个过程可能继续到两个小时以上，业务的影响面很大。针对此问题，咱们对入仓流程进行了增量化的革新。由 Flink 进行流解决，之后再联合上游业务的理论需要，将荡涤后的数据有抉择的落 Hive 或 Beluga，对接离线数仓和增量数仓。
革新后成果非常明显。流量数据的就绪工夫提前了两小时以上，因不在依赖凌晨的调度，也不会因为资源有余而造成作业长期处于 Pending 状态，资源的利用率失去了晋升。
3.2 案例二，通过增量计算模式来晋升计算效率
场景 -1：晋升明细快照表合并效率。
业务想要一个体现最新的业务停顿数据快照。在离数仓的计算模式下，失去这个快照需采纳批模式，合并每天新增的变更事件到存量快照中。
比方图中的例子，在 T- 1 日产生了一条半年前订单的更新状态。为了保障 fact 层可能提供最新的业务快照，与业务库保持一致。须要将这张表近半年的全副分区，进行一次笼罩更新，计算效率是很差。
为了这么小比例的状态变更，须要拉全量数据进行合并。资源效率和数据就绪工夫，都有较大的负面影响，理论这类明细数据生产非常适合用 Beluga 的增量更新能力，晋升合并效率。
通过革新后，业务不再须要为大量数据的更新行为，重建整张表，无效的节俭计算资源开销，进一步晋升了数据时效性。
场景 -2：晋升累计快照事实表的计算效率
实质上属于累计窗口计算语义。如图所示，上游是一张增量明细表，它将每天的增量数据作为独立分区进行存储。上游表则是一张累计快照事实表，每天会创立一个新的分区，用于存储业务某一时刻，到以后的最新数据的累计值。
依照以后离线数仓的生产模式，每天都须要将上游表的所有分区全副读出来，做一次合并，计算出截止到当天的累计快照值，再写到上游表的新分区中。
但这样会面临一个问题，随着累计天数的减少，前一天累计好的后果，并未被间接用在算第二天的累计指标的计算过程中。每天都须要拉取上游表全副的分区数据，从新进行计算。这样会造成计算的开销越来越大，这个计算效率十分不现实。
上面介绍下如何通过增量数仓来解决这个问题。
针对这类场景，能够通过 Flink 的流计算模式，将每天新增的增量数据与曾经算好的累计状态，在 Flink 作业中间接合并。不仅可能无效利用中间状态，还可能实时将计算后的后果，更新到上游表中，使计算效率和数据新鲜度，都失去了肯定的晋升。
3.3 案例三，通过增量计算模式来晋升计算效率
业务的需要是，既要反对对数据提早比拟敏感并且数据一致性要求较高的 BI 场景，也要反对依赖较长历史周期数据算法的训练场景。
为了保障高时效性，并且不能有太多的反复数据。业务将实时数仓的 Kafka 数据，灌入到 Doris 中，利用 Doris 的主键模型去重。再按 10min 的调度周期，反对较高时效性要求的 BI 报表查问场景。
另外对于一些算法场景，岂但须要长时间周期的特色数据，还需定期与 Hive 上的历史数据做合并。
链路很简单，会带来大量不必要的运维工作。与此同时，链路上多处依赖调度零碎，这会给就绪工夫，带来很多不确定性，更不必提数据一致性的保障。
上面看下增量数仓是如何解决这些问题的。
- 通过 Beluga 替换掉 Kafka 和 Doris。因 Beluga 可保证数据的幂等写和强一致性。能够应用 Flink 流工作，替换掉了原有微批工作，保证数据的时效性。
- 通过 Beluga 存储全量历史快照数据，即便业务的指标须要依赖时间跨度很长的历史数据，也能够基于 Beluga 实现指标计算。
革新后，能够看到链路精简了许多，无效晋升了开发运维效率，且削减了局部冗余资源。
四、将来瞻望
最初，分享下增量数仓的将来的建设布局。
- 继续欠缺 Beluga 的性能和架构，反对批量更新局部列的能力、点查的能力、还有高效的并发控制能力。
- 咱们还会对 Beluga 的事务提交效率进行改良，反对秒级的事务提交，帮忙业务以较低的老本，将离线数仓工作迁徙至增量数仓的工具等能力。
- 在平台化的工作方面，须要一套对立的数仓接入服务，具备流、批工作托管和调度的开发平台。
点击查看原文视频 & 演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://click.aliyun.com/m/1000372333/
