Hudi简介
Apache Hudi(Hadoop Upserts and Incrementals)是一个开源的数据湖存储框架,旨在支持高效的数据更新、删除和增量处理。Hudi 通过提供数据湖存储的事务能力,简化了数据的管理和查询,使其成为构建实时数据湖的理想选择。
Hudi的产生背景
Hudi是Uber公司开源的数据湖架构,数据湖架构是近些年出现的一种新的技术架构,主要是解决目前大数据中Hive储存的一些痛点。HUDI的名字来自四个英文单词的缩写(Hadoop Upsert Delete and Incremental),顾名思义HUDI就是为大数据增加了修改、删除的特性。
当前大数据生态中数据大多存储在Hive中,但是Hive的数据是基于分区存储的,也就最小的单位是分区,如果数据改变数据的话我们不得不对分区进行重建。针对Hive的这些问题,在Hive3.0中也对架构进行了升级和改进,支持了ACID、行级的更新和删除等功能。然而随着各种计算引擎、储存引擎的发展,为了适应不同的业务应用场景,大数据架构设计都偏向于对计算和存储进行解耦,存储结构不依赖计算引擎,然而Hive3.0中的改进并不支持Spark、Flink等引擎。
Apache Hudi 的产生背景可以追溯到大数据生态系统中对高效数据管理和实时处理需求的不断增长。
- 数据湖的普及。随着大数据技术的发展,数据湖逐渐成为企业存储和分析海量数据的重要架构。数据湖允许将结构化和非结构化数据存储在一个统一的存储系统中,如 HDFS、S3 等。然而,传统的数据湖架构在处理实时数据和频繁更新时面临挑战。
- 实时数据处理的需求。许多企业需要处理实时数据,以便快速做出业务决策。传统的数据湖架构主要设计用于批处理,缺乏对实时数据流和低延迟查询的支持。企业需要一种能够支持实时数据摄取、更新和查询的解决方案。
- 数据更新和删除的复杂性。在数据湖中进行数据更新和删除操作通常非常复杂,因为这些操作需要对大量数据文件进行修改。传统的解决方案通常依赖于全量数据重写,这在处理大规模数据集时效率低下且成本高昂。
- 增量数据处理的需求。随着数据量的增加,企业需要能够识别和处理自上次处理以来的数据变化,而不是每次都处理全量数据。增量数据处理能够显著提高效率,减少计算资源的消耗。
- 数据合规和审计的要求。企业面临越来越多的数据合规和审计要求,需要能够跟踪和恢复历史数据。这需要数据湖具有版本控制和快照恢复的能力,以满足合规性和数据治理的需求。
- Uber 的贡献。Apache Hudi 最初由 Uber 开发,以解决其在大数据处理过程中遇到的这些挑战。Uber 的数据平台需要支持复杂的 ETL 流程、高效的数据更新和实时分析。Hudi 的设计旨在解决这些问题,并提供一种更灵活和高效的数据湖解决方案。
- 开源和社区贡献。在 Uber 内部成功应用后,Hudi 于 2019 年开源,成为 Apache 软件基金会的孵化项目,并于 2020 年成为顶级项目。开源后的 Hudi 吸引了广泛的社区贡献和企业支持,进一步推动了其发展和成熟。
Apache Hudi 的产生背景反映了大数据生态系统中对高效数据管理和实时处理的迫切需求。通过提供事务支持、增量处理和数据版本化等特性,Hudi 解决了传统数据湖架构中的许多挑战,为企业构建现代化数据湖提供了一种强大的解决方案。
Hudi的核心特性
Hudi 有时被定位为“表格格式” 或“事务层”。虽然这没有错,但并不能完全体现 Hudi 所提供的一切。设计者将 Apache Hudi 描述为围绕数据库内核构建的流式数据湖平台(Streaming Data Lake Platform)。
上图从下到上,由左向右看
- hudi 底层的数据可以存储到hdfs、s3、azure、alluxio 等存储
- hudi 可以使用spark/flink 计算引擎来消费 kafka、pulsar 等消息队列的数据,而这些数据可能来源于 app 或者微服务的业务数据、日志数据,也可以是 mysql 等数据库的 binlog 日志数据
- spark/hudi 首先将这些数据处理为 hudi 格式的 row tables (原始表),然后这张原始表可以被 Incremental ETL (增量处理)生成一张 hudi 格式的 derived tables 派生表
- hudi 支持的查询引擎有:trino、hive、impala、spark、presto 等
- 支持 spark、flink、map-reduce 等计算引擎继续对 hudi 的数据进行再次加工处理
Hudi作为一个数据湖方案,他自己本身不产生任何业务数据,可以通过Spark、Flink等工具,接入关系型数据库、日志、消息队列的数据,进行大容量的存储,最终提供给上层查询引擎比如Presto、Hive等进行查询。
相比于传统计算存储架构,HUDI提供了更细粒度的数据处理方式:
- 效率的提升:只更新被修改、删除的数据,而不是更新整个表分区甚至整张表,通过这样的操作,效率提升了一个量级。
- 索引:upsert支持可插拔索引
- ACID语义:增加了ACID语义支持,出现错误可以回滚数据
- 快照:支持读写快照的隔离,读写不相互影响
- 数据恢复:支持保存点数据恢复
- 小文件处理:为行列存储异步合并小文件
- 元数据:支持数据结构变更,并且支持变更的历史跟踪
以下是 Hudi 的一些核心特性:
- ACID 事务支持。Hudi 提供了对数据湖中数据进行原子性、一致性、隔离性和持久性的事务支持。这使得在大规模数据集上进行更新和删除操作更加安全和可靠,避免了数据不一致的问题。
- 增量处理。Hudi 支持增量处理能力,允许用户只处理自上次处理以来的数据变化。这种特性大大减少了数据处理的计算负担,提高了处理效率,尤其适用于需要频繁更新的大数据集。
- 数据布局优化。Hudi 提供了自动的数据布局优化功能,通过合并和压缩数据文件来提升查询性能。它可以根据数据的写入模式和查询模式自动调整数据存储布局,以达到最佳的性能表现。
- 数据版本化和时间旅行。Hudi 支持数据版本化,这意味着用户可以查看和查询历史数据快照。这种能力对于数据审计、合规性检查和恢复历史数据非常有用,允许用户“回到过去”查看特定时间点的数据状态。
- 支持多种表类型。Hudi 支持两种主要的表类型:
- Copy on Write (COW):每次数据更新都会创建新的数据文件,旧文件会被替换。这种模式适合读取密集型工作负载,提供了更好的查询性能。
- Merge on Read (MOR):更新会被写入增量日志文件,并在查询时进行合并。这种模式适合写入密集型工作负载,支持更低的写入延迟。
- 高效的并行写入和合并。Hudi 利用 Apache Spark 的并行处理能力,支持高效的并行数据写入和文件合并。这种能力对于处理大规模数据集至关重要,能够显著提高写入性能和资源利用率。
- 查询引擎集成。Hudi 与多种查询引擎无缝集成,包括 Apache Hive、Apache Spark、Presto、Trino 和 Apache Flink。这使得用户可以使用熟悉的工具和语言来查询 Hudi 数据湖中的数据。
- 数据湖存储支持。Hudi 支持多种底层存储系统,包括 HDFS、Amazon S3、Google Cloud Storage 和 Azure Blob Storage。这种灵活性允许用户根据需要选择最合适的存储解决方案。
- 数据压缩和索引。Hudi 提供了数据压缩和索引功能,以减少存储占用和加速查询操作。索引可以帮助快速定位数据,提高查询效率。
- 总结
Apache Hudi 的核心特性使其成为构建现代数据湖的强大工具。通过支持高效的数据更新、增量处理、数据版本化和多种查询引擎集成,Hudi 解决了传统数据湖架构中的许多挑战,为企业提供了一种灵活、高效的数据管理解决方案。
Hudi 的使用场景
Apache Hudi 是一个功能强大的数据湖框架,适用于多种使用场景,特别是在需要高效数据更新、增量处理和实时分析的环境中。以下是一些典型的 Hudi 使用场景:
- 实时数据湖。Hudi 非常适合构建实时数据湖,支持对数据的频繁更新和低延迟查询。通过支持 ACID 事务和增量处理,Hudi 能够高效地管理和查询实时流数据,如用户活动、传感器数据和交易记录。
- 数据管道与ETL。在数据管道中,Hudi 可以用于高效地执行 ETL(Extract, Transform, Load)操作。它允许从不同数据源摄取数据,进行转换处理,并将结果存储到数据湖中。Hudi 的增量处理能力可以显著减少数据处理时间和资源消耗。
- 数据合规与审计。Hudi 的数据版本化和时间旅行功能支持数据合规性和审计要求。用户可以查看和恢复历史数据快照,以便进行合规检查和数据审计。这对于需要遵循数据保留和合规政策的行业,如金融和医疗,非常重要。
- 数据更新与删除。在需要频繁数据更新和删除的场景中,Hudi 提供了比传统数据湖架构更高效的解决方案。其支持的 ACID 事务允许安全地执行数据更新和删除操作,而不会导致数据不一致。
- 增量数据处理。Hudi 支持增量数据处理,这对于需要定期更新和处理数据的场景非常有用。例如,Hudi 可以用于每日或每小时的数据更新,避免全量数据重写,减少处理时间和计算资源的使用。
- 用户行为分析。在电商、社交媒体和在线服务中,用户行为数据的实时分析对于优化用户体验和提升业务决策至关重要。Hudi 可以帮助企业实时处理和分析用户行为数据,以便快速响应市场变化。
- 大规模数据迁移。在进行数据平台迁移时,Hudi 可以用于逐步迁移数据,同时保持对数据的更新和查询能力。这种能力允许企业在迁移过程中不中断数据服务。
Apache Hudi 提供了一套强大的工具集,适用于多种需要高效数据管理和实时处理的场景。无论是实时数据湖建设、复杂的 ETL 管道,还是需要满足合规要求的数据治理,Hudi 都能够提供灵活且高效的解决方案。其广泛的应用场景使其成为现代数据湖架构中的重要组成部分。
Hudi 的架构
Hudi 组件栈
Apache Hudi 是一个复杂的数据湖框架,提供了一套完整的组件来支持数据的高效存储、管理和查询。以下是 Hudi 的主要组件栈及其功能:
存储层
- 数据文件:Hudi 使用 Parquet、Avro 等格式存储数据。它支持两种主要的存储模式:
- Copy on Write (COW):每次数据更新时会创建新的数据文件,适合读取密集型工作负载。
- Merge on Read (MOR):更新会写入增量日志文件,并在查询时进行合并,适合写入密集型工作负载。
- 增量日志文件:在 MOR 模式下,更新和删除操作记录在增量日志文件中,允许在查询时合并这些变化。
写入服务
- 写操作(Write Client):Hudi 提供写客户端来执行插入、更新和删除操作。写客户端负责处理数据的写入逻辑,并确保 ACID 事务的一致性。
- 提交管理:每次写操作都会创建一个新的提交,Hudi 通过提交文件来跟踪数据的变更历史。
查询服务
- 查询引擎集成:Hudi 与多个查询引擎(如 Apache Spark、Hive、Presto、Trino 和 Flink)集成,允许用户通过这些引擎查询 Hudi 表。
- 增量查询:支持增量查询模式,用户可以查询自上次处理以来的数据变化,这对于实时分析和数据管道非常有用。
- 时间旅行查询:允许用户查询历史数据快照,支持数据版本化和时间旅行功能。
索引服务
- 索引机制:Hudi 使用索引来加速数据定位和更新操作。索引可以是内存中的,也可以是基于文件的,帮助快速查找和更新数据。
数据优化
- 文件合并:Hudi 提供自动的数据文件合并功能,通过合并小文件来优化存储和查询性能。
- 数据压缩:支持数据压缩以减少存储空间的占用。
元数据管理
- 元数据表:Hudi 使用元数据表来跟踪表的状态、提交历史和文件信息。这些信息对于管理和查询数据至关重要。
数据摄取和 ETL 支持
- DeltaStreamer:这是一个内置的工具,用于从各种数据源摄取数据并将其写入 Hudi 表。它支持从 Kafka、DFS 和其他数据源读取数据,并执行简单的 ETL 操作。
配置和管理
- 配置灵活性:Hudi 提供丰富的配置选项,允许用户根据具体的工作负载和性能需求调整系统行为。
- 管理工具:Hudi 提供命令行工具和 API,用于管理表、查看提交历史和进行数据修复等操作。
Apache Hudi 的组件栈提供了一套完整的功能,支持从数据摄取、存储、管理到查询的全流程处理。其灵活的存储模式、强大的事务支持和丰富的查询能力使其成为构建现代数据湖的强大工具。通过与多个大数据引擎的集成,Hudi 能够适应各种复杂的数据处理和分析需求。
Hudi的表格式
Apache Hudi 的表格式是其核心特性之一,支持高效的数据存储、更新和查询。Hudi 提供了两种主要的表格式:Copy on Write (COW) 和 Merge on Read (MOR)。这两种格式各有优缺点,适用于不同的使用场景。
Copy on Write (COW)
工作原理
- 数据更新:在 COW 模式下,每次数据更新时,整个数据文件都会被重写。这意味着旧数据文件会被新的包含更新数据的文件替换。
- 数据存储:COW 表中的数据通常存储为 Parquet 格式,这种格式优化了压缩和查询性能。
优势
- 读取性能高:由于所有数据都存储在压缩良好的列式格式中,COW 表提供了优异的读取性能,适合读取密集型工作负载。
- 简单性:数据更新后立即可用,不需要额外的合并操作。
缺点
- 写入开销大:由于每次更新都会重写整个文件,写入开销较大,不适合频繁更新的场景。
适用场景
- 数据更新较少,查询频繁的场景。
- 需要高查询性能的批处理工作负载。
Merge on Read (MOR)
工作原理
- 数据更新:在 MOR 模式下,更新和删除操作会写入增量日志文件(通常为 Avro 格式)。这些增量文件在查询时与基础数据文件合并。
- 数据存储:基础数据存储在列式格式(如 Parquet)中,而增量变化存储在行式格式(如 Avro)中。
优势
- 写入性能高:由于更新只需写入增量日志文件,MOR 表的写入性能较高,适合频繁更新的场景。
- 灵活性:用户可以根据需要选择在查询时进行合并(牺牲一些查询性能)或定期运行后台合并操作来优化查询性能。
缺点
- 查询性能波动:如果增量文件未及时合并,查询性能可能会受到影响,因为需要在查询时进行合并操作。
适用场景
- 数据更新频繁,写入性能要求高的场景。
- 实时数据摄取和处理,允许一些查询性能延迟的场景。
表结构和元数据
- 主键:Hudi 表通常定义一个主键,用于唯一标识每条记录。这对于支持更新和删除操作至关重要。
- 分区支持:Hudi 支持基于列的分区策略,以提高查询效率和数据管理能力。
- 时间戳列:Hudi 通常使用一个时间戳列来跟踪记录的最后更新时间,这在增量处理和时间旅行查询中非常有用。
Hudi 的表格式设计为满足不同的工作负载需求提供了灵活性。Copy on Write (COW) 提供了高读取性能,适合读取密集型场景,而 Merge on Read (MOR) 提供了高写入性能,适合更新频繁的场景。通过选择合适的表格式,用户可以在写入和查询性能之间找到最佳平衡,满足特定的应用需求。
Hudi 数据管理
Hudi表的数据文件,可以使用操作系统的文件系统存储,也可以使用HDFS这种分布式的文件系统存储。为了后续分析性能和数据的可靠性,一般使用HDFS进行存储。以HDFS存储来看,一个Hudi表的存储文件分为两类。
- .hoodie 文件: 由于CRUD的零散性, 每一次的操作都会生成一个文件,这些小文件越来越多后,会严重影响HDFS的性能,Hudi设计了一套文件合并机制。.hoodie文件夹中存放了对应的文件合并操作相关的日志文件。
- americas和asia相关的路径是实际的数据文件,按分区存储,分区的路径key是可以指定的。
.hoodie文件
Hudi把随着时间流逝,对表的一系列CRUD操作叫做Timeline, Timeline中某一次的操作,叫做Instant。
- Instant Action,记录本次操作是一次数据提交(COMMITS),还是文件合并(COMPACTION),或者是文件清理(CLEANS)
- Instant Time,本次操作发生的时间
- State,操作的状态,发起(REQUESTED),进行中(INFLIGHT),还是已完成(COMPLETED)
数据文件
Hudi真实的数据文件使用Parquet文件格式存储
其中包含一个metadata元数据文件和数据文件parquet列式存储。
Hudi为了实现数据的CRUD,需要能够唯一标识一条记录,Hudi将把数据集中的唯一字段(record key ) +数据所在分区(partitionPath)联合起来当做数据的唯一键。
Hudi数据存储
hudi数据集的组织目录结构与hive非常相似,一份数据集对应一个根目录。数据集被打散为多个分区,分区字段以文件夹形式存在,该文件夹包含该分区的所有文件。
在根目录下,每个分区都有唯一的分区路径,每个分区数据存储在多个文件中
每个文件都有唯一的fileId和生成文件的commit所标识。如果发生更新操作时,多个文件共享相同的fileId,但会有不同的commit
Metadata 元数据
以时间轴(timeline)的形式将数据集上的各项操作元数据维护起来,以支持数据集的瞬态视图,这部分元数据存储于根目录下的元数据目录。一共有三种类型的元数据:
- Commits:一个单独的commit包含对数据集上一批数据的一次原子写入操作的相关信息。我们用单调递增的时间戳来标识commits,标的是一次写入操作的开始。
- Cleans:用于清除数据集中不再被查询所用到的旧版本文件的后台活动。
- Compactions:用于协调hudi内部的数据结构差异的后台活动。例如,将更新操作由基于行存的日志文件归集到列式数据上。
Index 索引
Hudi维护着一个索引,以支持在记录key存在情况下,将新记录的key快速映射到对应的fileId。
- Bloom filter:存储于数据文件页脚。默认选项,不依赖外部系统实现。数据和索引始终保持一致。
- Apache HBase :可高效查找一小批key。在索引标记期间,此选项可能快几秒钟。
Data 数据
Hudi以两种不同的存储格式存储所有摄取的数据,用户可选择满足下列条件的任意数据格式:
- 读优化的列存格式(ROFormat):缺省值为Apache Parquet;
- 写优化的行存格式(WOFormat):缺省值为Apache Avro;
Hudi的查询
Hudi支持三种不同的查询表的方式:Snapshot Queries(快照查询)、Incremental Queries(增量查询)和Read Optimized Queries(读优化查询).
Snapshot Queries(快照查询)
查询某个增量提交操作中数据集的最新快照,先进行动态合并最新的基本文件(parquet)和增量文件(Avro)来提供近实时数据集(通常会存在几分钟的延迟)
读取所有partition下每个FileGroup最新的FileSlice中的文件,Copy On Write表读parquet文件,Merge On Read表读parquet + log文件。
Incremental Queries(增量查询)
仅查询新写入数据集的文件,需要指定一个Commit/Compaction的即时时间(位于Timeline上的某个instant)作为条件,来查询此条件之后的新数据
可查看自给定commit/delta commit即时操作依赖新写入的数据,有效地提供变更流来启用增量数据管道。
Read Optimized Queries(读优化查询)
直接查询基本文件(数据集的最新快照),其实就是列式文件(Parquet)。并保证与非hudi列式数据集相比,具有相同的列式查询性能。
可查看给定的commit/compact即时操作的表的最新快照;
读优化查询和快照查询相同仅访问基本文件,提供给定文件片自上次执行压缩操作以来的数据。通常查询数据的最新程度的保证取决于压缩策略。
Hudi计算模型
hudi是Uber主导开发的开源数据湖框架,所以大部分的出发点都来源于Uber自身场景,比如司机数据和乘客数据通过订单ID来做join等。
在hudi过去的使用场景里,和大部分公司的架构类似,采用批式和流式共存的Lambda架构,后来Uber提出增量Incremental模型,相对批式来讲,更加实时,相对流式而言,更加经济。
批式模型(Batch)
批式模型就是使用MapReduce、Hive、Spark等典型的批计算引擎,以小时任务或者天任务的形式来做数据计算。特性如下:
- 延迟:小时级延迟或者天级别延迟。这里的延迟不单单指的是定时任务的时间,在数据架构里,这里的延迟时间通常是定时任务间隔时间+一系列依赖任务的计算时间+数据平台最终可以展示结果的时间。数据量大、逻辑复杂的情况下,小时任务计算的数据通常真正延迟的时间是2-3小时。
- 数据完整度:数据较完整。以处理时间为例,小时级别的任务,通常计算的原始数据已经包含了小时内的所有数据,所以得到的数据相对较完整。但如果业务需求是事件时间,这里涉及到终端的一些延迟上报机制,在这里,批式计算任务就很难派上用场。
- 成本:成本很低。只有在做任务计算时,才会占用资源,如果不做任务计算,可以将这部分批式计算资源出让给在线业务使用。从另一个角度来说成本是挺高的,如原始数据做了一些增删改查,数据晚到的情况,那么批式任务是要全量重新计算。
流式模型(Stream)
流式模型,典型的就是使用Flink来进行实时的数据计算,特性:
- 延迟:很短,甚至是实时。
- 数据完整度:较差。因为流式引擎不会等到所有数据到齐之后再开始计算,所以有一个watermark的概念,当数据的时间小于watermark时,就会被丢弃,这样是无法对数据完整度有一个绝对的保障。在互联网场景中,流式模型主要用于活动时的数据大盘展示,对数据的完整度要求并不算很高。在大部分场景中,用户需要开发两个程序,一是流式数据生产流式结果,而是批式计算人物,用于次日修复实时结果。
- 成本:很高。因为流式任务时常驻的,并且对于多流join的场景,通常要借助内存或者数据库来做state的存储,不管是序列化开销,还是和外部组件交互产生的额外IO,在大数据量下都是不容忽视的。
增量模型(Incremental)
针对批式和流式的优缺点,Uber提出了增量模型(Incremental Mode),相对批式来讲,更加实时;相对流式而言,更加经济。量模型,简单来讲,就是一mini batch的形式来跑准实时任务。hudi在增量模型中支持了两个最重要的特性:
- Upsert:这个主要是解决批式模型中,数据不能插入、更新的问题,有了这个特性,可以往Hive中写入增量数据,而不是每次进行完全的覆盖。(hudi自身维护了key-file的映射,所以当upsert时很容易找到key对应的文件)
- Incremental Query:增量查询,减少计算的原始数据量。以uber中司机和乘客的数据流join为例,每次抓取两条数据流中的增量数据进行批式的join即可,相比流式数据而言,成本要降低几个数量级。
Hudi与Paimon的对比
Apache Hudi 和 Apache Paimon(原名为 Flink Table Store)都是用于大数据环境的数据湖框架,它们各自提供了对大规模数据集进行管理和查询的能力。尽管它们有许多相似之处,但也有一些关键的区别。以下是对 Hudi 和 Paimon 的对比:
特性 | Apache Hudi | Apache Paimon (Flink Table Store) |
设计目标 | 为数据湖提供高效的更新、删除和增量处理能力 | 流批一体化的数据存储与处理,特别适合与 Flink 集成 |
存储模式 | Copy on Write (COW) 和 Merge on Read (MOR) | 支持版本化的流式存储,优化流数据的高效处理 |
事务支持 | 提供 ACID 事务支持 | 支持事务性操作,适合流数据的更新和管理 |
查询引擎集成 | 支持 Spark、Hive、Presto、Trino、Flink 等多种引擎 | 与 Apache Flink 紧密集成,主要在 Flink 环境中使用 |
增量处理 | 支持增量查询,识别和处理数据变化 | 提供流批一体化的增量处理能力,实时处理流数据更新 |
数据格式 | 基于 Parquet、Avro 等列式和行式格式存储 | 主要面向流数据存储,支持高效的行式和列式存储 |
数据版本化 | 支持时间旅行和数据版本化,允许访问历史数据 | 支持版本化存储,允许在流处理中进行版本管理 |
更新和删除操作 | 通过索引和日志文件高效支持更新和删除 | 支持在流处理中进行高效的更新和删除操作 |
生态系统和社区 | Apache 顶级项目,拥有活跃的社区和广泛的生态系统支持 | 相对较新,但在 Flink 社区中获得关注,特别是流处理场景 |
适用场景 | 适合需要频繁数据更新和低延迟查询的实时数据湖场景 | 适合需要流批一体化处理的场景,特别是在 Flink 环境中 |
Apache Hudi
优势
- 广泛的生态系统支持:Hudi 与多种查询引擎(如 Apache Spark、Apache Hive、Presto、Trino 和 Apache Flink)集成,提供更大的灵活性。
- 事务支持:Hudi 提供强大的 ACID 事务支持,适合需要频繁更新和删除数据的场景。
- 增量处理能力:Hudi 的增量处理功能可以高效地处理数据变化,减少处理时间和计算资源消耗。
- 数据版本化和时间旅行:允许用户查看和查询历史数据快照,适用于数据合规和审计需求。
- 成熟度和社区支持:作为 Apache 的顶级项目,Hudi 拥有一个活跃的社区和丰富的文档资源。
适用场景
- 需要与多种大数据技术栈集成的场景。
- 需要频繁数据更新和低延迟查询的实时数据湖。
- 需要复杂的 ETL 处理和数据版本管理。
Apache Paimon
优势
- 流批一体化处理:Paimon 与 Apache Flink 的紧密集成,特别适合需要流式和批处理结合的场景。
- 高效的流数据处理:设计上针对流数据的高效存储和管理,适合实时数据处理需求。
- 事务性操作:支持事务性操作,适合流数据的更新和管理。
适用场景
- 需要与 Apache Flink 紧密结合的流批一体化处理。
- 主要处理流数据,并需要高效存储和实时更新的场景。
- 在 Flink 环境中开发数据应用的场景。
如果你的数据平台需要与多种查询引擎集成,并且需要强大的事务支持和增量处理能力,那么 Apache Hudi 可能是更好的选择。如果你的应用主要依赖 Apache Flink,并且需要流批一体化处理,那么 Apache Paimon 可能更适合。
参考链接: