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

0 0 投票数
文章评分

本文为从大数据到人工智能博主「xiaozhch5」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://lrting.top/backend/1996/

(1)
上一篇 2021-11-11 21:08
下一篇 2021-11-12 19:05

相关推荐

订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x
()
x