揭秘数据湖——长文详解Hudi从内核到实战(二)

发布时间:2021年09月06日作者:atguigu浏览次数:756

Hudi产品定位

近实时摄取

将外部数据(例如事件日志,数据库,外部源)如何摄取到HadoopData Lake是一个众所周知的问题。在大多数Hadoop部署中,经常会以零碎的方式,使用多种摄取工具解决,这些数据对整个组织是最具有价值的。

对于RDBMS关系型的摄入,Hudi提供了更快的Upset操作。例如,你可以通过MySql binlog的形式或者Sqoop导入到hdfs上的对应的Hudi表中,这样操作比Sqoop批量合并job(Sqoop merge)和复杂合并工作流更加快速高效。

对于NoSql的数据库,比如Cassandra,Voldemort,Hbase,这种可以存储数十亿行的数据库。采用完全批量加载是根本不可行的,并且如果摄取数据要跟上通常较高的更新量,则需要更有效的方法。

即使对于像Kafka这样不可变数据库源,Hudi也会在HDFS 上强制执行最小文件大小,从而通过整体解决Hadoop领域中小文件过多问题,改善NameNode的运行状况。对于事件流尤为重要,因为事件流通常较大(例如:点击流),并且如果管理不善,可能会严重损害Hadoop集群。

在所有来源中,Hudi都增加了急需的功能,即通过提交概念将新数据原子推送给消费者,避免摄入数据失败。

近实时分析

通常,实时数据集市由专门的分析存储(例如Druid或Memsql,OpenTSDB)提供支持,对于较低规模的数据,这绝对是完美的,可实现亚秒级响应查询。但是通常这些数据库最终会因为交互性较低的查询而被滥用,导致利用率不足。

另一方面,Hadoop上交互式的SQL解决方案有Presto和Spark sql。将数据的更新时间缩短至几分钟,Hudi可以提供多种高效的替代方案,并可以对存储在DFS中的多个大小表进行实时分析,此外Hudi没有外部依赖,例如专用实时分析的专用HBase集群,因此可以在不增加操作开销的情况下,进行更快更新鲜的分析。

增量处理管道

Hadoop提供的一项基本功能是,通过表示为工作流的DAG来构建彼此衍生的表链。工作流通常取决于多个上游工作流输出的新数据,并且传统上,新数据的可用性由新的DFS文件夹/配置单元分区指示。让我们举一个具体的例子来说明这一点。上游工作流U可以每小时创建一个Hive分区,并在每小时的末尾(processing_time)包含该小时(event_time)的数据,从而提供1小时的有效刷新。然后,下游工作流D在U完成后立即开始,并在接下来的一个小时内进行自己的处理,从而将有效延迟增加到2个小时。

上述范例只是忽略了延迟到达的数据,即,processing_time和event_time分开时。不幸的是,在当今的后移动和物联网前世界中,间歇性连接的移动设备和传感器的最新数据是正常现象,而不是反常现象。在这种情况下,保证正确性的唯一补救方法是每小时一次又一次地重新处理最后几个小时的数据,这会严重损害整个生态系统的效率。例如想象在数百个工作流程中每小时重新处理价值TB的数据。

Hudi通过提供一种以记录粒度(而不是文件夹/分区)消耗上游Hudi表HU的新数据(包括最新数据),应用处理逻辑并有效地更新/协调最新数据的方式再次进行救援。下游护桌HD。在这里,HU和HD可以以更频繁的时间表(例如15分钟)连续进行调度,并在HD上提供30分钟的终端延迟。

为了实现这一目标,Hudi从流处理框架(如Spark Streaming),发布/订阅系统(如Kafka)或数据库复制技术(如OracleXStream)中采用了类似的概念

DFS的数据分散

Hudi可以像Kafka一样,用于数据分散,将每个管道的数据输出到Hudi表中,然后将其递增尾部以获取新数据并写入服务存储中。

与Kudu对比

Apache Kudu是一个存储系统,其目标与Hudi类似,后者的目标是通过对Upserts的一流支持,对PB级数据进行实时分析。一个关键的区别是Kudu还试图充当OLTP工作负载的数据存储,而Hudi并不希望这样做。因此,Kudu不支持增量拉取(截至2017年初),Hudi这样做是为了启用增量处理用例。

Kudu与分布式文件系统抽象和HDFS完全不同,它自己的一组存储服务器通过RAFT相互通信。另一方面,Hudi旨在与底层Hadoop兼容文件系统(HDFS,S3或Ceph)一起使用,并且没有自己的存储服务器,而是依靠Apache Spark来完成繁重的工作。因此,就像其他Spark作业一样,Hudi可以轻松扩展,而Kudu则需要硬件和操作支持,这对于HBase或Vertica这样的数据存储来说是典型的。

与HBase对比

HBase是OLTP工作负载的关键值存储,但鉴于与Hadoop的相似性,用户通常倾向于将HBase与分析相关联。鉴于HBase经过严格的写优化,它支持开箱即用的亚秒级更新,Hive-on-HBase允许用户查询该数据。但是,就分析工作负载的实际性能而言,混合列式存储格式(例如Parquet/ ORC)可以轻松击败HBase,因为这些工作负载主要是读取繁重的工作。Hudi弥补了更快的数据与具有分析性存储格式之间的差距。从操作的角度来看,与仅管理分析用的大型HBase区域服务器场相比,为用户提供可提供更快数据的库更具可扩展性。最终,HBase不像Hudi这样的一流公民来支持诸如提交时间,增量拉动之类的增量处理原语。

Hudi拥有更好数据分析能力。

与Streaming对比

Hudi可以与当今的批处理(写时复制表)和流式(读时合并表)作业集成,以将计算结果存储在Hadoop中。对于Spark应用程序,这可以通过将Hudi库与Spark / Spark流式DAG直接集成来实现。在非Spark处理系统(例如Flink,Hive)的情况下,可以在各个系统中进行处理,然后通过Kafka主题/ DFS中间文件将其发送到Hudi表中。从概念上讲,数据处理管道仅由三个部分组成:源,处理,接收器,用户最终针对接收器运行查询以使用管道的结果。 Hudi可以充当将数据存储在DFS上的源或接收器。 Hudi在给定流处理管道上的适用性最终归结为Presto / SparkSQL / Hive对您的查询的适用性。

想要了解跟多关于大数据培训课程内容欢迎关注尚硅谷大数据培训,尚硅谷除了这些技术文章外还有免费的高质量大数据培训课程视频供广大学员下载学习。


上一篇:
下一篇:
相关课程

java培训 大数据培训 前端培训

关于尚硅谷
教育理念
名师团队
学员心声
资源下载
视频下载
资料下载
工具下载
加入我们
招聘岗位
岗位介绍
招贤纳师
联系我们
全国统一咨询电话:010-56253825
地址:北京市昌平区宏福科技园2号楼3层(北京校区)

深圳市宝安区西部硅谷大厦B座C区一层(深圳校区)

上海市松江区谷阳北路166号大江商厦3层(上海校区)

武汉市东湖高新开发区东湖网谷(武汉校区)

西安市雁塔区和发智能大厦B座3层(西安校区)

成都市成华区北辰星拱青创园(成都校区)