Apache Hudi典型应用场景知多少？

1.近实时摄取

将数据从外部源如事件日志、数据库提取到Hadoop数据湖 中是一个很常见的问题。在大多数Hadoop部署中，通常使用混合提取工具并以零散的方式解决该问题，尽管这些数据对组织是很是有价值的。

对于RDBMS摄取，Hudi经过Upserts提供了更快的负载，而非昂贵且低效的批量负载。例如你能够读取MySQL binlog日志或Sqoop增量导入，并将它们应用在DFS上的Hudi表，这比批量合并做业或复杂的手工合并工做流更快/更高效。

对于像Cassandra / Voldemort / HBase这样的NoSQL数据库，即便规模集群不大也能够存储数十亿行数据，此时进行批量加载则彻底不可行，须要采用更有效的方法使得摄取速度与较频繁的更新数据量相匹配。

即便对于像Kafka这样的不可变数据源，Hudi也会强制在DFS上保持最小文件大小，从而解决Hadoop领域中的古老问题以便改善NameNode的运行情况。这对于事件流尤其重要，由于事件流（例如单击流）一般较大，若是管理不善，可能会严重损害Hadoop集群性能。

对于全部数据源，Hudi都提供了经过提交将新数据原子化地发布给消费者，从而避免部分提取失败。

2. 近实时分析

一般实时数据集市由专门的分析存储，如Druid、Memsql甚至OpenTSDB提供支持。这对于须要亚秒级查询响应（例如系统监视或交互式实时分析）的较小规模（相对于安装Hadoop）数据而言是很是完美的选择。但因为Hadoop上的数据使人难以忍受，所以这些系统一般最终会被较少的交互查询所滥用，从而致使利用率不足和硬件/许可证成本的浪费。

另外一方面，Hadoop上的交互式SQL解决方案（如Presto和SparkSQL），能在几秒钟内完成的查询。经过将数据的更新时间缩短至几分钟，Hudi提供了一种高效的替代方案，而且还能够对存储在DFS上多个更大的表进行实时分析。此外，Hudi没有外部依赖项（例如专用于实时分析的专用HBase群集），所以能够在不增长运营成本的状况下，对更实时的数据进行更快的分析。

3. 增量处理管道

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中引入了相似概念。若感兴趣能够在此处找到有关增量处理（与流处理和批处理相比）更多优点的更详细说明。

4. DFS上数据分发

Hadoop的经典应用是处理数据，而后将其分发到在线存储以供应用程序使用。例如使用Spark Pipeline将Hadoop的数据导入到ElasticSearch供Uber应用程序使用。一种典型的架构是在Hadoop和服务存储之间使用队列进行解耦，以防止压垮目标服务存储，通常会选择Kafka做为队列，该架构会致使相同数据冗余存储在DFS（用于对计算结果进行离线分析）和Kafka（用于分发）上。

Hudi能够经过如下方式再次有效地解决此问题：将Spark Pipeline 插入更新输出到Hudi表，而后对表进行增量读取（就像Kafka主题同样）以获取新数据并写入服务存储中，即便用Hudi统一存储。