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

## 1.近实时摄取 将数据从外部源如事件日志、数据库提取到[Hadoop数据湖](http://martinfowler.com/bliki/DataLake.html) 中是一个很常见的问题。在大多数Hadoop部署中，一般使用混合提取工具并以零散的方式解决该问题，尽管这些数据对组织是非常有价值的。 对于RDBMS摄取，Hudi通过Upserts提供了更快的负载，而非昂贵且低效的批量负载。例如你可以读取MySQL binlog日志或[Sqoop增量导入](https://sqoop.apache.orghttps://img.qb5200.com/download-x/docs/1.4.2/SqoopUserGuide.html#_incremental_imports)，并将它们应用在DFS上的Hudi表，这比[批量合并作业](https://sqoop.apache.orghttps://img.qb5200.com/download-x/docs/1.4.0-incubating/SqoopUserGuide.html#id1770457)或[复杂的手工合并工作流](http://hortonworks.com/blog/four-step-strategy-incremental-updates-hive/)更快/更高效。 对于像[Cassandra](http://cassandra.apache.org/) / [Voldemort](http://www.project-voldemort.com/voldemort/) / [HBase](https://hbase.apache.org/)这样的NoSQL数据库，即使规模集群不大也可以存储数十亿行数据，此时进行批量加载则完全不可行，需要采用更有效的方法使得摄取速度与较频繁的更新数据量相匹配。 即使对于像[Kafka](https://kafka.apache.org/)这样的不可变数据源，Hudi也会强制在DFS上保持最小文件大小，从而解决Hadoop领域中的[古老问题](https://blog.cloudera.com/blog/2009/02/the-small-files-problem/)以便改善NameNode的运行状况。这对于事件流尤为重要，因为事件流（例如单击流）通常较大，如果管理不善，可能会严重损害Hadoop集群性能。 对于所有数据源，Hudi都提供了通过提交将新数据原子化地发布给消费者，从而避免部分提取失败。 ## 2. 近实时分析 通常实时[数据集市](https://en.wikipedia.org/wiki/Data_mart)由专门的分析存储，如[Druid](http:/https://img.qb5200.com/download-x/druid.io/)、[Memsql](http://www.memsql.com/)甚至[OpenTSDB](http://opentsdb.net/)提供支持。这对于需要亚秒级查询响应（例如系统监视或交互式实时分析）的较小规模（[相对于安装Hadoop](https://blog.twitter.com/2015/hadoop-filesystem-at-twitter)）数据而言是非常完美的选择。但由于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`分开的情况。不幸的是在后移动和物联网前的时代，数据延迟到达是非常常见的情况。在这种情况下，保证正确性的唯一方法是每小时重复处理[最后几个小时](https://falcon.apache.org/FalconDocumentation.html#Handling_late_input_data)的数据，这会严重损害整个生态系统的效率。想象下在数百个工作流中每小时重新处理TB级别的数据。 Hudi可以很好的解决上述问题，其通过记录粒度（而非文件夹或分区）来消费上游Hudi表`HU`中的新数据，下游的Hudi表`HD`应用处理逻辑并更新/协调延迟数据，这里`HU`和`HD`可以以更频繁的时间（例如15分钟）连续进行调度，并在`HD`上提供30分钟的端到端延迟。 为了实现这一目标，Hudi从流处理框架如[Spark Streaming](https://spark.apache.orghttps://img.qb5200.com/download-x/docs/latest/streaming-programming-guide.html#join-operations)、发布/订阅系统如[Kafka](http://kafka.apache.orghttps://img.qb5200.com/download-x/documentation/#theconsumer)或数据库复制技术如[Oracle XStream](https:/https://img.qb5200.com/download-x/docs.oracle.com/cd/E11882_01/server.112/e16545/xstrm_cncpt.htm#XSTRM187)中引入了类似概念。若感兴趣可以在[此处](https://www.oreilly.com/ideas/ubers-case-for-incremental-processing-on-hadoop)找到有关增量处理（与流处理和批处理相比）更多优势的更详细说明。 ## 4. DFS上数据分发 Hadoop的经典应用是处理数据，然后将其分发到在线存储以供应用程序使用。例如使用Spark Pipeline将Hadoop的数据导入到ElasticSearch供Uber应用程序使用。一种典型的架构是在Hadoop和服务存储之间使用`队列`进行解耦，以防止压垮目标服务存储，一般会选择Kafka作为队列，该架构会导致相同数据冗余存储在DFS（用于对计算结果进行离线分析）和Kafka（用于分发）上。 Hudi可以通过以下方式再次有效地解决此问题：将Spark Pipeline 插入更新输出到Hudi表，然后对表进行增量读取（就像Kafka主题一样）以获取新数据并写入服务存储中，即使用Hudi统一存储。