如何通过Apache Hudi提升传统批量处理效率？

本文共计2231个文字，预计阅读时间需要9分钟。

1.+ 现状说明

1.1+ 数据湖抽取和计算过程

- 处理更新在1-10%的情况下，是对历史记录的更新。当记录更新时，需要从之前的updated_date分区中删除之前的条目，并将新条目添加到最新分区。

1. 现状说明 1.1 数据湖摄取和计算过程 - 处理更新

在我们的用例中1-10% 是对历史记录的更新。当记录更新时，我们需要从之前的 updated_date 分区中删除之前的条目，并将条目添加到最新的分区中，在没有删除和更新功能的情况下，我们必须重新读取整个历史表分区 -> 去重数据 -> 用新的去重数据覆盖整个表分区

1.2 当前批处理过程中的挑战

这个过程有效，但也有其自身的缺陷：

1. 时间和成本——每天都需要覆盖整个历史表
2. 数据版本控制——没有开箱即用的数据和清单版本控制（回滚、并发读取和写入、时间点查询、时间旅行以及相关功能不存在）
3. 写入放大——日常历史数据覆盖场景中的外部（或自我管理）数据版本控制增加了写入放大，从而占用更多的 S3 存储

借助Apache Hudi，我们希望在将数据摄取到数据湖中的同时，找到更好的重复数据删除和数据版本控制优化解决方案。

2. Hudi 数据湖 — 查询模式

当我们开始在我们的数据湖上实现 Apache Hudi 的旅程时，我们根据表的主要用户的查询模式将表分为 2 类。

• 面向ETL ：这是指我们从各种生产系统摄取到数据湖中的大多数原始/基本快照表。 如果这些表被 ETL 作业广泛使用，那么我们将每日数据分区保持在 updated_date，这样下游作业可以简单地读取最新的 updated_at 分区并（重新）处理数据。