hudi学习一（初识hudi)

什么是hudi

Hudi（发音为“hoodie”）摄取与管理处于DFS(HDFS 或云存储)之上的大型分析数据集并为查询访问提供三个逻辑视图。

• 读优化视图 - 在纯列式存储上提供出色的查询性能，非常像parquet表。
• 增量视图 - 在数据集之上提供一个变更流并提供给下游的作业或ETL任务。
• 准实时的表 - 使用基于列存储和行存储(例如 Parquet + Avro)以提供对实时数据的查询

通过仔细地管理数据在存储中的布局和如何将数据暴露给查询，Hudi支持丰富的数据生态系统，在该系统中，外部数据源可被近实时摄取并被用于presto和spark等交互式SQL引擎，同时能够从处理/ETL框架（如hive和 spark中进行增量消费以构建派生（Hudi）数据集。

hudi解决什么问题

近实时摄取

将外部源(如事件日志、数据库、外部源)的数据摄取到Hadoop数据湖是一个众所周知的问题。 尽管这些数据对整个组织来说是最有价值的，但不幸的是，在大多数(如果不是全部)Hadoop部署中都使用零散的方式解决，即使用多个不同的摄取工具。

对于RDBMS摄取，Hudi提供 通过更新插入达到更快加载，而不是昂贵且低效的批量加载。例如，您可以读取MySQL BIN日志或Sqoop增量导入并将其应用于 DFS上的等效Hudi表。这比批量合并任务及复杂的手工合并工作流更快/更有效率。

对于NoSQL数据存储，如Cassandra / Voldemort / HBase，即使是中等规模大小也会存储数十亿行。 毫无疑问， 全量加载不可行，如果摄取需要跟上较高的更新量，那么则需要更有效的方法。

即使对于像Kafka这样的不可变数据源，Hudi也可以 强制在HDFS上使用最小文件大小, 这采取了综合方式解决HDFS小文件问题来改善NameNode的健康状况。这对事件流来说更为重要，因为它通常具有较高容量(例如：点击流)，如果管理不当，可能会对Hadoop集群造成严重损害。

在所有源中，通过commits这一概念，Hudi增加了以原子方式向消费者发布新数据的功能，这种功能十分必要。

近实时分析

通常，实时数据集市由专业(实时)数据分析存储提供支持，例如Druid或Memsql或OpenTSDB。 这对于较小规模的数据量来说绝对是完美的(相比于这样安装Hadoop)，这种情况需要在亚秒级响应查询，例如系统监控或交互式实时分析。 但是，由于Hadoop上的数据太陈旧了，通常这些系统会被滥用于非交互式查询，这导致利用率不足和硬件/许可证成本的浪费。

另一方面，Hadoop上的交互式SQL解决方案(如Presto和SparkSQL)表现出色，在 几秒钟内完成查询。 通过将 数据新鲜度提高到几分钟，Hudi可以提供一个更有效的替代方案，并支持存储在DFS中的 数量级更大的数据集 的实时分析。 此外，Hudi没有外部依赖(如专用于实时分析的HBase集群)，因此可以在更新的分析上实现更快的分析，而不会增加操作开销。

增量处理管道

Hadoop提供的一个基本能力是构建一系列数据集，这些数据集通过表示为工作流的DAG相互派生。 工作流通常取决于多个上游工作流输出的新数据，新数据的可用性传统上由新的DFS文件夹/Hive分区指示。 让我们举一个具体的例子来说明这点。上游工作流U可以每小时创建一个Hive分区，在每小时结束时(processing_time)使用该小时的数据(event_time)，提供1小时的有效新鲜度。 然后，下游工作流D在U结束后立即启动，并在下一个小时内自行处理，将有效延迟时间增加到2小时。

上面的示例忽略了迟到的数据，即processing_time和event_time分开时。 不幸的是，在今天的后移动和前物联网世界中，来自间歇性连接的移动设备和传感器的延迟数据是常态，而不是异常。 在这种情况下，保证正确性的唯一补救措施是重新处理最后几个小时的数据， 每小时一遍又一遍，这可能会严重影响整个生态系统的效率。例如; 试想一下，在数百个工作流中每小时重新处理TB数据。

Hudi通过以单个记录为粒度的方式(而不是文件夹/分区)从上游 Hudi数据集HU消费新数据(包括迟到数据)，来解决上面的问题。 应用处理逻辑，并使用下游Hudi数据集HD高效更新/协调迟到数据。在这里，HU和HD可以以更频繁的时间被连续调度 比如15分钟，并且HD提供端到端30分钟的延迟。

为实现这一目标，Hudi采用了类似于Spark Streaming、发布/订阅系统等流处理框架，以及像Kafka 或Oracle XStream等数据库复制技术的类似概念。 如果感兴趣，可以在这里找到有关增量处理(相比于流处理和批处理)好处的更详细解释。

DFS的数据分发

一个常用场景是先在Hadoop上处理数据，然后将其分发回在线服务存储层，以供应用程序使用。 例如，一个Spark管道可以确定Hadoop上的紧急制动事件并将它们加载到服务存储层(如ElasticSearch)中，供Uber应用程序使用以增加安全驾驶。这种用例中，通常架构会在Hadoop和服务存储之间引入队列，以防止目标服务存储被压垮。 对于队列的选择，一种流行的选择是Kafka，这个模型经常导致 在DFS上存储相同数据的冗余(用于计算结果的离线分析)和Kafka(用于分发)

hudi的应用场景

实时数仓

现在的数仓一般使用lamda框架，离线数据 存储到hdfs，通过spark等计算引擎批量写入ldap，实时数据通过flink或者sparkstreaming写入ldap，以次实现实时的服务，hudi很好的解决了这个 问题，因为hudi的支持批量的操作和近实时的分析和摄取很好的解决了lamda架构的复杂性。

ETL

hudi可以和spark很好的结合用于数据的采集，而且Hudi作为CDC管道的输出写入程序，即从数据库binlog生成的事件通过cancel流到Kafka然后再写入hdfs。

对比

Apache Hudi填补了在DFS上处理数据的巨大空白，并可以和这些技术很好地共存。然而， 通过将Hudi与一些相关系统进行对比，来了解Hudi如何适应当前的大数据生态系统，并知晓这些系统在设计中做的不同权衡仍将非常有用。

Kudu

Apache Kudu是一个与Hudi具有相似目标的存储系统，该系统通过对upserts支持来对PB级数据进行实时分析。 一个关键的区别是Kudu还试图充当OLTP工作负载的数据存储，而Hudi并不希望这样做。 因此，Kudu不支持增量拉取(截至2017年初)，而Hudi支持以便进行增量处理。

Kudu与分布式文件系统抽象和HDFS完全不同，它自己的一组存储服务器通过RAFT相互通信。 与之不同的是，Hudi旨在与底层Hadoop兼容的文件系统(HDFS，S3或Ceph)一起使用，并且没有自己的存储服务器群，而是依靠Apache Spark来完成繁重的工作。 因此，Hudi可以像其他Spark作业一样轻松扩展，而Kudu则需要硬件和运营支持，特别是HBase或Vertica等数据存储系统。 到目前为止，我们还没有做任何直接的基准测试来比较Kudu和Hudi(鉴于RTTable正在进行中)。 但是，如果我们要使用CERN， 我们预期Hudi在摄取parquet上有更卓越的性能。

Hive事务

Hive事务/ACID是另一项类似的工作，它试图实现在ORC文件格式之上的存储读取时合并。 可以理解，此功能与Hive以及LLAP之类的其他工作紧密相关。 Hive事务不提供Hudi提供的读取优化存储选项或增量拉取。 在实现选择方面，Hudi充分利用了类似Spark的处理框架的功能，而Hive事务特性则在用户或Hive Metastore启动的Hive任务/查询的下实现。 根据我们的生产经验，与其他方法相比，将Hudi作为库嵌入到现有的Spark管道中要容易得多，并且操作不会太繁琐。 Hudi还设计用于与Presto/Spark等非Hive引擎合作，并计划引入除parquet以外的文件格式。

HBase

尽管HBase最终是OLTP工作负载的键值存储层，但由于与Hadoop的相似性，用户通常倾向于将HBase与分析相关联。 鉴于HBase经过严格的写优化，它支持开箱即用的亚秒级更新，Hive-on-HBase允许用户查询该数据。 但是，就分析工作负载的实际性能而言，Parquet/ORC之类的混合列式存储格式可以轻松击败HBase，因为这些工作负载主要是读取繁重的工作。 Hudi弥补了更快的数据与分析存储格式之间的差距。从运营的角度来看，与管理分析使用的HBase region服务器集群相比，为用户提供可更快给出数据的库更具可扩展性。 最终，HBase不像Hudi这样重点支持提交时间、增量拉取之类的增量处理原语。

流式处理

一个普遍的问题："Hudi与流处理系统有何关系？"，我们将在这里尝试回答。简而言之，Hudi可以与当今的批处理(写时复制存储)和流处理(读时合并存储)作业集成，以将计算结果存储在Hadoop中。 对于Spark应用程序，这可以通过将Hudi库与Spark/Spark流式DAG直接集成来实现。在非Spark处理系统(例如Flink、Hive)情况下，可以在相应的系统中进行处理，然后通过Kafka主题/DFS中间文件将其发送到Hudi表中。从概念上讲，数据处理 管道仅由三个部分组成：输入，处理，输出，用户最终针对输出运行查询以便使用管道的结果。Hudi可以充当将数据存储在DFS上的输入或输出。Hudi在给定流处理管道上的适用性最终归结为你的查询在Presto/SparkSQL/Hive的适用性