Hudi使用场景

近实时摄取

Hudi对各种数据的摄取都有很多的优点。能够帮助合并DFS上的最小文件。这有助于解决HDFS和云存储上的小文件问题，显著提高查询性能。Hudi增加了非常需要的原子提交新数据的能力，使查询永远看不到部分写入，并帮助摄取从失败中优雅地恢复。

将OLTP源(如事件日志、数据库、外部源)中的数据吸收到data Lake中是一个常见问题，不幸的是，这个问题只能通过使用混合的吸收工具以零碎的方式解决。 数据湖的这一“原始数据”层往往形成了创造更多价值的基岩。

对于RDBMS的导入，Hudi通过Upserts提供了更快的加载，而不是使用昂贵和低效的批量加载。 使用类似Debezium或Kafka Connect或Sqoop增量导入工具并将它们应用到DFS上的等价Hudi表中是很常见的。 对于像Cassandra / Voldemort / HBase这样的NoSQL数据存储，即使是中等规模的安装也会存储数十亿行的数据。 毫无疑问，完全批量加载是不可行的，如果摄入要跟上通常的高更新量，就需要更有效的方法。

即使对于像Kafka这样的不可变数据源，也经常需要对存储在DFS上的传入事件进行去副本。 Hudi通过使用不同种类的指标，快速而有效地实现了这一点。

所有这些都是由Hudi DeltaStreamer工具无缝实现的，该工具与其余代码紧密集成，我们总是试图添加更多的数据源，以使用户更容易。 该工具还具有连续模式，在这种模式下，它可以异步地自管理集群/压缩，而不会阻塞数据摄入，极大地提高了数据的新鲜度。

数据删除

Hudi还提供了删除存储在数据湖中的数据的能力，更重要的是通过Merge on Read表类型提供了有效的方法来处理基于user_id(或任何辅助键)的随机删除所导致的写放大。 Hudi优雅的基于日志的并发控制，确保了摄取/写入可以继续发生，因为后台压缩作业分摊了重写数据/强制删除的成本。

Hudi还解锁了数据集群等特殊功能，允许用户优化删除数据布局。 具体来说，用户可以基于user_id聚类旧的事件日志数据，这样，评估数据删除候选的查询就可以这样做，而最近的分区则针对查询性能进行优化，并根据时间戳进行聚类。

统一存储分析

我们生活的世界是两极分化的——甚至在数据分析存储方面——实时和离线/批存储。 通常，实时数据交易由专门的分析存储提供支持，如Druid、Memsql或Clickhouse，由Kafka或Pulsar等事件总线提供支持。 这种模型非常昂贵，除非有一小部分数据湖数据需要次秒级的查询响应，如系统监控或交互式实时分析。

同样的数据在很长一段时间之后(比如每隔几个小时左右)才被输入数据湖存储，然后通过批处理ETL管道运行，以难以忍受的数据新鲜度进行任何接近实时的分析。 另一方面，数据湖提供了对Presto/SparkSQL等交互式SQL引擎的访问，这些引擎可以轻松地横向扩展，并在几秒钟内提供更复杂的查询。

通过将流原语引入数据湖存储，Hudi开辟了新的可能性，它能够在几分钟内接收数据，还能创建比传统批处理快几个数量级的增量数据管道。 与实时数据集市相比，通过将数据更新时间缩短到几分钟，Hudi可以为大量数据应用程序提供更有效的替代方案。 此外，Hudi没有前期服务器基础设施投资，因此能够在更新鲜的分析上进行更快的分析，而不会增加运营开销。 这篇外部文章进一步验证了这个更新的模型。

增量处理管道

数据湖ETL通常涉及通过表示为工作流的dag来构建相互派生的表链。 工作流通常依赖于多个上游工作流输出的新数据，传统上，新数据的可用性由一个新的DFS文件夹/Hive分区表示。 让我们举一个具体的例子来说明这一点。 一个上游工作流U可以每小时创建一个Hive分区，每小时的数据(event_time)在每小时的末尾(processing_time)，提供1小时的有效新鲜度。 然后，一个下游工作流D，在U完成后立即启动，并在接下来的一个小时内进行自己的处理，将有效延迟增加到2小时。

上述范例简单地忽略了晚到的数据，即当processing_time和event_time漂移时。 不幸的是，在今天这个后移动和前物联网的世界，间歇性连接的移动设备和传感器的延迟数据是常态，而不是异常。 在这种情况下，保证正确性的唯一补救措施是重新处理最后几个小时的数据，每小时重复处理一次，这可能会严重损害整个生态系统的效率。 如; 想象一下，在数百个工作流程中，每小时重新处理tb值的数据。

Hudi再次发挥了作用，它提供了一种方式，以记录粒度(而不是文件夹/分区)从上游Hudi表HU消费新数据(包括后期数据)，应用处理逻辑，并有效地更新/协调下游Hudi表HD的后期数据。 在这里，HU和HD可以以更频繁的时间表(比如15分钟)连续调度，并在HD上提供30分钟的端-端延迟。

为了实现这一点，Hudi从流处理框架(如Spark Streaming)、Pub/Sub系统(如Kafka Flink)或数据库复制技术(如Oracle XStream)中接受了类似的概念。 对于更好奇的人，可以在这里找到关于增量处理的好处的更详细的解释 here