近实时摄取
将外部源(如事件日志、数据库、外部源)的数据摄取到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(用于分发)
通过将每次运行的Spark管道更新插入的输出转换为Hudi数据集，Hudi可以再次有效地解决这个问题，然后可以以增量方式获取尾部数据(就像Kafka topic一样)然后写入服务存储层。