ApacheHudi典型应用场景知多少？

ApacheHudi典型应⽤场景知多少？
1.近实时摄取
将数据从外部源如事件⽇志、数据库提取到中是⼀个很常见的问题。

在⼤多数Hadoop部署中，⼀般使⽤混合提取⼯具并以零散的⽅式解决该问题，尽管这些数据对组织是⾮常有价值的。

对于RDBMS摄取，Hudi通过Upserts提供了更快的负载，⽽⾮昂贵且低效的批量负载。

例如你可以读取MySQL binlog⽇志或，并将它们应⽤在DFS上的Hudi表，这⽐或更快/更⾼效。

对于像 / / 这样的NoSQL数据库，即使规模集群不⼤也可以存储数⼗亿⾏数据，此时进⾏批量加载则完全不可⾏，需要采⽤更有效的⽅法使得摄取速度与较频繁的更新数据量相匹配。

即使对于像这样的不可变数据源，Hudi也会强制在DFS上保持最⼩⽂件⼤⼩，从⽽解决Hadoop领域中的以便改善NameNode的运⾏状况。

这对于事件流尤为重要，因为事件流（例如单击流）通常较⼤，如果管理不善，可能会严重损害Hadoop集群性能。

对于所有数据源，Hudi都提供了通过提交将新数据原⼦化地发布给消费者，从⽽避免部分提取失败。

2. 近实时分析
通常实时由专门的分析存储，如、甚⾄提供⽀持。

这对于需要亚秒级查询响应（例如系统监视或交互式实时分析）的较⼩规模（）数据⽽⾔是⾮常完美的选择。

但由于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从流处理框架如、发布/订阅系统如或数据库复制技术如中引⼊了类似概念。

若感兴趣可以在找到有关增量处理（与流处理和批处理相⽐）更多优势的更详细说明。

4. DFS上数据分发
Hadoop的经典应⽤是处理数据，然后将其分发到在线存储以供应⽤程序使⽤。

例如使⽤Spark Pipeline将Hadoop的数据导⼊到ElasticSearch供Uber应⽤程序使⽤。

⼀种典型的架构是在Hadoop和服务存储之间使⽤队列进⾏解耦，以防⽌压垮⽬标服务存储，⼀般会选择Kafka作为队列，该架构会导致相同数据冗余存储在DFS（⽤于对计算结果进⾏离线分析）和Kafka（⽤于分发）上。

Hudi可以通过以下⽅式再次有效地解决此问题：将Spark Pipeline 插⼊更新输出到Hudi表，然后对表进⾏增量读取（就像Kafka主题⼀样）以获取新数据并写⼊服务存储中，即使⽤Hudi统⼀存储。