湖仓一体作为一种新兴的开放数据管理架构，可以充分发挥数据湖的灵活性、丰富的生态系统和数据仓库的企业级数据分析能力，成为企业构建现代数据平台的热门选择。
在之前的直播中，我们分享了 HashData 湖仓一体解决方案的架构设计和 Hive 数据同步。 在本次直播中，我们介绍了 Iceberg 和 Hudi 的功能和支持方案，并详细讲解和演示了 HashData 连接组件的原理和实现流程。 以下内容根据直播文本进行组织。 Hudi和Iceberg技术应用场景
在构建企业数据平台的过程中，随着数据量的不断增加和场景的丰富，每个企业都会根据自己的技术路线和需求，开发不同的架构设计。
数据湖是一种不断发展、可扩展的基础设施，用于大数据存储、处理和分析，使企业能够存储任何规模的结构化和非结构化数据。 随着云存储（尤其是对象存储）技术的逐渐成熟，数据湖解决方案逐渐向云原生靠拢，数据处理方式从批处理向流式处理演进。 在此背景下，现代数据湖需要强大的流批处理能力、高效的数据更新机制、严格的事务支持以及灵活的存储和计算引擎。 面对上述需求，传统的HIVE+HDFS架构数据仓库数据修改成本高，不支持事务（ACID），无法实现流式批处理。
1、数据分析时间等“痛点”不能直接用于构建数据湖。 近年来，Hudi、Iceberg等先进管理技术因其开放的文件存储格式、丰富的事务支持、高效的读写能力，成为企业数据湖建设的主流选择。 胡迪基地该术语与以下方面有关：编写操作流程
Hudi的诞生是为了解决Hadoop系统中的数据更新和增量查询问题，在数据存储和查询方面具有鲜明的特点。
Hudi 的文件布局是其增量查询、数据更新等功能的基础，每个 Hudi 表都有一个固定的目录来存储元数据 （.）。Hoodie） 和数据文件，其中数据文件以分区方式分区，每个分区都有多个数据文件（基本文件和日志文件），这些文件在逻辑上组织为文件和文件组。
base file：以列式格式存储的数据文件，默认为 parquet 格式。 log file：行存储的数据文件采用 **ro 格式，用于存储数据的重做日志，并定期与基础文件合并。 file group：同一分区中具有相同 fileid 的所有基本文件 + 日志文件的集合，一个分区可以有多个文件组。 file slice：基本文件 + 日志文件的集合，在同一分区中具有相同的 fileid 和相同的时刻。
可以理解为Hudi表的时间轴，它记录了Hudi表在不同时间的运行情况，保证了操作的原子性。 时间线由三个字段组成：操作、时间和状态。 Hudi 提供了两种类型的表：copy-on-write（cow 表）和 merge-on-read（mor 表）。
奶牛表：仅使用列式文件格式（如 parquet）来存储数据。 只需通过在写入过程中执行同步合并来更新版本并重写文件适用于更新数据量大、时效性不高的场景
莫尔表：使用基于列的 + 基于行的（例如，**ro）文件格式的组合存储数据，将更新记录到增量文件（基于行），然后压缩以同步或异步生成新版本的列式文件适用于更新数据量少、时效性要求高的场景Hudi 支持三种查询类型：快照查询、读取优化查询和增量查询：
snapshot query：查询最近一次快照的数据，即最新数据。 read optimized query：MOR表独有的查询方式，只读取基文件，不合并日志，因为使用列式文件格式，所以效率更高。
incremental query：需要指定提交时间，然后 Hudi 会扫描文件中的记录，过滤掉提交时间大于 begintime 的时间线记录和基文件，可以有效提高增量数据处理能力。
在 Hudi 数据湖框架中，您可以通过三种方式写入数据：upsert、insert 和 bulk-insert。 其中，UPSERT是默认行为，也是Hudi的核心功能。
图 1：将 Spark 写入 Hudi 的过程如图 1 所示
开始提交：确定上一个任务是否失败，如果失败，则触发回滚操作。 然后，根据当前时间生成事务开始的请求标识元数据。 构造 HoodieRecord RDD 对象：Hudi 根据元数据信息构建 HoodieRecord RDD 对象，方便后续的重复数据删除和数据合并。 重复数据删除：如果一批增量数据中可能存在重复数据，Hudi会根据主键对数据进行重复数据删除，防止重复数据写入Hudi表。 获取数据 fileid 位置信息：在修改记录中，可以根据索引获取当前记录所属文件的 fileld，因为更新操作在数据合并时需要知道要将新的快照文件写入哪个 fileid 文件。 数据合并：在 COW 表模式下，会重写索引命中的 fileid 快照文件。 在 Mor 表模式下，日志文件会根据 fileid 附加到分区中。 完整提交：在元数据中生成 xxxx提交文件：只有生成提交元数据文件，查询引擎才能根据元数据查询更新插入数据。 数据清理：用于删除旧分片和限制表空间的增长，每次写入操作后自动执行清理，时间线服务器上缓存的时间线元数据用于防止扫描整个表。 CompAction 压缩：主要用于 mor 模式，在 mor 模式下会是 xxx日志数据将合并到 xxx 中parquet 快照文件。 LCEBERG基本术语及编写操作流程
Iceberg官网定位为“海量数据分析场景的高效存储格式”，因此没有模拟像Hudi这样的业务数据库（主键+索引）的设计模式来实现数据更新，而是设计了更强大的文件组织形式来实现数据更新操作。 数据文件是Apache冰山表实际存储数据的文件，一般在表的数据存储目录的数据目录下，如果我们的文件格式是parquet，那么文件就设置为“.”。parquet“，iceberg 每次更新都会生成多个数据文件。
快照表示表在特定时间的状态，每个快照列出该表在特定时间的所有数据文件。 数据文件存储在不同的清单文件中，清单文件存储在清单列表文件中，清单列表文件表示快照。
清单文件是一个元数据文件，其中列出了构成快照的数据文件列表。 每一行都包含每个数据文件的详细描述，包括数据文件的状态、文件路径、分区信息、列级统计信息（如每列的最大值和最小值、null 值的数量等）、文件的大小以及文件中数据的行数。 其中，列级统计可以在扫描表数据时过滤掉不需要的文件。 清单文件以 **ro 格式存储，以“.*ro“后缀。 清单列表也是一个元数据文件，其中列出了构建表的快照。 此元数据文件存储清单文件列表，每个清单文件占用一行。 每一行都存储了清单文件的路径、存储的数据文件的分区范围、添加的文件数量、删除的数据文件数量，可用于提供过滤和加快查询速度。 
图 2：Iceberg 写入过程示意图 将数据写入 Iceberg 时，内部工作流程可以总结如下：
生成文件appender：根据配置的文件格式，iceberg会生成相应的fileappender，即实际执行文件写入操作的组件。 写入数据文件：fileappender 负责将数据写入目标文件。 收集统计信息：写入所有数据后，Iceberg 会收集写入的统计数据，如记录计数、下限、上限、值计数等，为后续生成清单文件提供重要的输入文件。 生成清单文件：Iceberg根据统计信息生成对应的清单文件，即数据文件的索引，存储每个数据文件的路径，并根据这些清单文件实现文件的组织和管理。 消息返回：执行程序将生成的清单文件和其他相关信息发送回驱动程序以完成写入过程。
哈希数据连接器的工作原理及其工作原理
数据湖中的数据通常是无组织的或未经处理的，这限制了直接分析的效率。 Hashdata通过自主研发的Hudi和Iceberg连接器，实现了与这两种架构的平滑融合。 HashData 目前支持 Hudi 和 Iceberg 的只读表，但不支持写入。
图 3：如上图所示，hashdata 连接器通过创建外部表来读取 Hudi 和 Iceberg 数据，以进一步分析和使用湖中的数据。
创建外表
首先，你需要有一个需要被 hudi 和 iceberg 阅读的表格。 我们使用 Spark 和 Flink 等组件在 Hudi 和 Iceberg 上创建表并写入数据，并指定 Hudi 和 Iceberg 格式。
在hashdata数据库上提交并创建一个可读的外部表，其中包括路径和目录类型等信息，也就是我们前面提到的与位置相关的信息。
接下来，调用 Hudi 和 Iceberg 客户端，客户端会创建连接并调用 Get Table，并传入外部表的信息，获取 Hudi 和 Iceberg 表的元数据信息，包括表中的字段数、字段名称和数据类型。
根据获取到的元数据，通过映射数据库生成哈希数据表。
至此，创建对应 Hudi 和 Iceberg 的外表的过程就完成了。
以上步骤是通过连接组件完成的，这相当于打包并将表的路径和目录类型等信息传递给连接器。 连接器获取相关表的信息，然后将其传回，哈希数据将信息映射回可读的外部表。
发起SELECT查询语句时，hashdata在内部发起select查询，并通过连接器打包查询的相关参数。 然后，它通过外部扫描过滤器（例如SQL中的WHERE条件）传递到连接器。
然后连接器调用 Hudi 和 Iceberg 的扫描 API，扫描方法会获取传入的参数，并根据这些参数对表相关的所有文件列表进行筛选查询，并返回相关列表文件。
获取文件列表后，外部生成查询计划，完成查询操作，并与Hudi和Iceberg的元数据进行交互。
获取数据后，hashdata 会将文件列表打包并分发到每个 segment 节点，该节点会在文件列表中获取一个分片，并根据这些信息读取数据。 数据返回后，读取数据的整个过程结束。
结论
Hudi和Iceberg是目前主流的数据湖解决方案，广受青睐。 HashData的“湖仓一体”技术方案打通了数据仓库和数据湖，底层支持多种数据类型共存，真正实现数据的相互共享，上层可以通过统一的封装接口进行访问，同时可以支持实时查询和分析，为数据湖架构下企业的数据治理和使用带来更多便利。