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. 近实时分析

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

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

3. 增量处理管道

Hadoop提供的一项基本功能是构建基于表的派生链,并通过DAG表示整个工作流。工作流通常取决于多个上游工作流输出的新数据,传统上新生成的DFS文件夹/Hive分区表示新数据可用。例如上游工作流U可以每小时创建一个Hive分区,并在每小时的末尾(processing_time)包含该小时(event_time)的数据,从而提供1小时的数据新鲜度。然后下游工作流DU完成后立即开始,并在接下来的一个小时进行处理,从而将延迟增加到2个小时。

上述示例忽略了延迟到达的数据,即processing_timeevent_time分开的情况。不幸的是在后移动和物联网前的时代,数据延迟到达是非常常见的情况。在这种情况下,保证正确性的唯一方法是每小时重复处理最后几个小时的数据,这会严重损害整个生态系统的效率。想象下在数百个工作流中每小时重新处理TB级别的数据。

Hudi可以很好的解决上述问题,其通过记录粒度(而非文件夹或分区)来消费上游Hudi表HU中的新数据,下游的Hudi表HD应用处理逻辑并更新/协调延迟数据,这里HUHD可以以更频繁的时间(例如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统一存储。

上一篇:【CSS页面】超出隐藏 渐变隐藏


下一篇:Apache Hudi:云数据湖解决方案