Hudi 是一个高效的事务型数据湖仓平台，其**特征是一个放开性的表格局定义和一套片面的事务数据库**层。这一**层不只支持索引性能，还能高效地处置并发事务，并具有弱小的变卦数据捕捉才干。在数据管道中，Hudi 能够从抢先数据源如 Kafka 接纳数据，并应用 Spark 和 Flink 等口头引擎启动数据导入与处置。平台还提供智能文件大小调整、增量处置和变卦捕捉等性能，以优化数据的清算与转换。此外，Hudi 具有丰盛的表服务才干，如数据清算和聚类，确保数据治理的高效性。Hudi 已与泛滥数据生态系统组件宽泛集成，包括目录同步和多种查问引擎，以成功数据处置的多样化和灵敏性。
上图是 Hudi 的架构分层图，展现了其作为数据湖仓平台的三个**层级。最底层用绿色示意的是放开的存储层，担任底层数据的存储，经常使用诸如 Parquet、Avro 和 ORC 等开源文件格局。其上一层是事务性数据库**层，该层定义了数据表格局、数据表服务、索引机制以及并发控制，确保了数据的分歧性和高效处置。最顶层是放开平台服务层，提供了一套开发的 API，支持与各类集成生态技术的读写操作，并成功了平台的性能性，包括元数据服务、数据入湖工具和与不同查问引擎的集成。这些层级独特造成了 Hudi 的平台架构，使得用户和开发人员能够间接与平台服务及工具交互，而机器则经过底层的读写支持与数据库**层交互。在 Hudi 1.0 版本中，这些架构层级经过了新的性能和性能优化，以满足现代数据治理的需求。
Hudi 1.0 的设想源于对 Hudi 生长历程的回忆。Hudi 最后旨在处置大规模数据摄取、增量数据处置和极速创立的疑问，并须要与 Presto、Spark、Flink、Trino 等查问引擎集成。只管这些引擎在列式数据查问方面表现杰出，但它们的整合环节却充溢应战。
作为湖仓畛域的先锋，Hudi 曾被称为事务性数据湖。在生态系统的早期阶段，Hudi 做出了一些激进的设计选用，例如为不同的查问引擎开发了各自的衔接器。在过去的五年中，Hudi 社区蓬勃开展，同时也暴显露更多元化的需求，特意是在事务性操作、极速更新和删除性能方面。因此，Hudi 团队意识到有必要对现有设计启动深档次的从新思索和优化，以顺应一直变动的数据处置需求。
Hudi 1.0 的五大开展方向表现了对数据湖架构的深度思索和对未来规划的远见：
在对比数据库的经典设计架构与 Hudi 的架构时，咱们可以看到 Hudi 在数据湖仓畛域成功了一个相似数据库的性能档次。最顶层的客户端模块是用户与系统交互的接口，担任处置 SQL 层的恳求。在此之下，Hudi 集成了不同查问引擎的查问解析和优化性能，目前关键依赖各引擎自身的优化，但未来或者引入 Hudi 外部的优化机制。
蓝色的模块代表与外部系统的集成，而两边的方块则展现了 Hudi 成功的事务性治理机制，这与传统数据库中的锁治理、日志治理等模块相对应。曾经成功的组件用绿色方块示意，而像缓存治理这样的未来愿景则用其余色彩示意，这标明了 Hudi 1.0 版本的开展方向。
接上去，将引见 Hudi 1.0 的一些关键性能。Hudi 1.0 版本的设计理念可以在其RFC（Request for Comments）文档中找到，该文档详细引见了版本的关键设计方向和预期特性。
接上去将重点讨论几个关键性能，首先是 Hudi 的 LSM tree 期间线。Hudi 的期间线实质上是一个无法变的事务日志，记载了表上一切已成功买卖的详细信息。这个事务日志通常会随着每次提交而线性增长。Hudi 0.x 版本保养了两个期间线：生动期间线和归档期间线。生动期间线用于极速检索最新信息，而归档期间线则用于满足特定场景下的历史数据查问需求。由于归档数据驳回了不同的存储机制，访问这些数据的老本相对较高。
为了优化 Hudi 期间线的存储效率，咱们思索驳回 LSM tree 这种经过验证的高效数据结构，它特意适宜处置大规模写入操作。在 Hudi 1.0 中，咱们从新成功了写入期间线的机制，如今每次写入都会记载其起始和完结期间。此外，咱们将现有的线性存储结构转换成了 LSM tree 结构，这准许启动更高效的紧缩操作。
LSM tree 的长处在于其树形分层结构，能够在顶层（如内存或缓存）极速检索信息，同时在更长的期间线上，可以经过紧缩多个事务到更大的 parquet 文件中，来提高读取效率和存储效率。这种结构不只优化了数据的极速访问，还优化了全体存储的紧凑性和性能。
接上去对 LSM Tree 期间线启动了一系列测试，其中包括模拟了 100 万次提交的买卖日志。在无需加载一切元数据的状况下，仅访问开局期间和完结期间以及事务中触及的文件，咱们成功了在 367ms 内加载整个期间线。这一性能优化得益于将期间线数据存储为 parquet 文件，这不只缩小了读取所需的元数据量，还提供了更高的读取灵敏性，从而清楚提高了加载效率。
接上去讨论另一个关键性能：函数索引。Hudi 的版本曾经集成了一个多形式索引子系统，支持文件索引、列统计和布隆过滤器等性能，且这些索引可以异步构建。在 Hudi 1.0 中，咱们宿愿进一步增强多形式索引的通用性。遭到数据库索引机制的启示，咱们思索了基于 R 树的空间索引和基于 Lucene 的搜查索引等初级性能。例如，PostgreSQL 能够在表白式上创立索引，这启示了咱们成功函数索引的思绪。函数索引的引入将使 Hudi 的索引性能愈加灵敏和弱小，从而提高查问效率和处置复杂查问的才干。
函数索引的一个典型用例是在处置蕴含组织 ID 和期间戳的事情流数据时。通常，咱们宿愿依据组织 ID 启动分区，而后进一步依据期间戳细分。例如，假设有1,000 个组织的一整年数据，咱们或者会创立 365,000 个分区。但是，这种做法或者会造成数据歪斜和少量小文件的疑问，这既影响了存储效率，也降落了查问性能。
为了处置这个疑问，Hudi 1.0 引入了函数索引。咱们仅依据组织 ID 启生物理分区，而后为期间戳定义一个函数，比如将 Unix 期间戳转换为小时，并记载每个小时的最大值和最小值。这样就可以在索引中成功高效的>
函数索引的经常使用可以经过一个繁难的示例来解释。在左侧的 SQL 示例中，经常使用 city 来分区，同时还有一个期间戳字段。咱们不须要针对期间戳进一步分区，而是可以经常使用 create index 的语法来生成一个新的索引，该索引将期间戳转换为小时。一旦生成了这个索引，随后的 SELECT 语句就可以应用期间戳启动高效的数据跳过。
在右侧的两个 Spark DAG（有向无环图）演示中，展现了在有函数索引和没有函数索引的状况下，数据跳过是如何成功的。经常使用函数索引，Spark 查问可以更有效地跳过不相关数据，从而提高查问性能和缩小资源消耗。这种索引战略不只简化了数据分区，还优化了全体的数据处置效率。
另一个关键的性能改良是 Hudi 新开发的文件组读取器和写入器。Hudi 借鉴建之初就设计了一个基于主键的概念。在 MOR（Merge-On-Read）表类型中，咱们成功了一个兼并操作，从第一天起就支持快照查问，即实时地将日志数据兼并到基础文件中。这一机制确保了即使在数据一直写入和更新时，也能高效地口头查问操作，提供了对历史和最新数据的一致视图。
关于 Hudi 中的兼并操作，咱们发现了潜在的优化空间。详细来说，咱们可以在记载日志的同时，记载下日志所需更新的基础文件的位置信息。这样，在启动兼并操作时，能够间接定位到文件的详细位置，从而高效地口头兼并。
此外，Hudi 1.0 参与了对局部更新（partial update）的优先支持。传统的日志文件自动记载整条更新语句，但在许多状况下，只有记载更新的字段。经过仅记载更新的字段及其值和位置，能够极大优化兼并环节。
设计文件组读取器和写入器的另一个好处是，它使得与各种查问引擎的集成变得愈加简便。这种设计一致了接口，使得裁减对不同引擎的支持变得愈加繁难，从而优化了 Hudi 的全体灵敏性和可裁减性。
针对基于位置的兼并操作，咱们启动了一系列基准测试。这些测试触及了两个不同规模的兼并表，一个蕴含 500GB、7.5 亿条记载，另一个蕴含 1TB、15 亿条记载。每条记载大概 1KB 大小，表蕴含 1000 个分区，每个文件大概 256MB。
在测试中，咱们首先批量加载数据，而后口头删除和更新操作，更新表中 50% 的记载。经过经常使用文件组读取器并应用位置信息启动兼并操作，咱们观察到了 12% 到 20% 的性能优化。这一优化随着数据量的参与而变得愈加清楚。关于详细的性能数据和详细剖析，可以参考 Hudi 的 PR 10167。
在局部更新（partial update）的测试中，咱们观察到了更为清楚的性能优化。上图中展现了更新操作的结果对比。当经常使用全量更新，即整条记载的一切字段与仅更新局部字段时，更新的提早降落了 1.4 倍。同时，写入的文件大小缩小了 70 倍，这是由于咱们节俭了少量未更新的数据。由于写入更为高效，节俭了空间，兼并操作也变得更为高效，咱们观察到了 5.7 倍的性能优化。这些优化不只提高了更新操作的效率，还清楚缩小了存储空间的占用。
最后一个重点性能是非阻塞并发控制。这个设计基于一个经常出现场景：一个每分钟写入的进程和每小时口头一次性的 GDPR 删除作业。假设驳回失望锁机制，删除作业或者会频繁遇到抵触，由于删除操作是随机的，这会造成删除作业在大少数状况下都须要重试，从而糜费资源。
Hudi 从一开局就驳回了 MVCC（多版本并发控制）机制。在写入侧，准许不加阻塞地写入，而在经常使用 MOR 形式时，在兼并侧口头异步兼并操作。此外，咱们可以应用兼并的时机启动类聚操作，以优化存储。这种设计确保了在处置并发写入和删除操作时，系统的效率和资源应用率失掉提高。
为了处置多个写入器并发控制的疑问，Hudi 支持失望锁的经常使用，也引入了早期抵触检测机制。此外，Hudi 探求了更通用的非阻塞多版本并发控制机制。在 Hudi 1.0 中，咱们成功了一个基于 MOR 写入环节的非阻塞并发控制。
当 MOR 写入操作在不同写入器上生成不同的日志文件时，Hudi 最后不会阻塞写入环节。经过经常使用全局干燥递增的期间戳来记载每个写入的开局和完结期间，咱们可以在兼并或快照读取阶段处置潜在的抵触。这种方法准许在写入时坚持非阻塞形态，从而提高了写入效率，同时确保了数据的最终分歧性。
当天的重点内容曾经引见终了。关于 Hudi 1.0，这里再提供一些额外信息。Hudi 1.0 的技术文档曾经宣布，可以在相应的链接中查阅。此外，相关的RFC 文档和设计文档也已地下，供社区参考。Hudi 1.0 beta1 的 jar 包也曾经发布。这些资源将为宿愿深化了解 Hudi 1.0 的用户和开发者提供协助。
最后，展现一下 Hudi 社区的生动状况。社区十分欢迎新成员的参与，这里提供了丰盛的文档链接和资源，以便大家更好地了解和介入 Hudi 名目。此外，欢迎关注 Hudi 的群众号来失掉最新信息，也欢迎参与咱们的社区，独特推进 Hudi 的开展。