了解 Yuno 如何利用 Apache Hudi 实现数据基础架构转型，优化数据湖性能，将成本降低 70%，并实现实时数据洞察。了解 Hudi 的高级功能（如时间旅行、索引和自动文件管理）如何提高效率和可扩展性，从而彻底改变 Yuno 的数据管理策略。

　　数据是我们一切工作的核心，推动整个公司的洞察、决策和创新。

　　然而随着数据量和复杂性的增加，在保持效率、一致性和成本效益方面面临重大障碍。因此，我们的主要目标是增强我们的数据管理能力。我们需要一个解决方案，它可以更好地控制我们的表，提高性能，并提供高度的组织性。

　　我们新系统的标准很明确：它必须符合 ACID 标准（原子性、一致性、隔离性和持久性标准），并且能够有效地处理更新插入和删除。在评估了几个选项后，Apache Hudi 成为理想的选择。

　　Apache Hudi 是一个数据湖框架，它通过支持对大型数据集进行高效的摄取、更新和删除来简化云存储上的数据管理。它还提供增量摄取和与实时数据源的出色兼容性等优势。

　　该图说明了 VPC （Virtual Private Cloud） 环境中湖仓一体的架构

　　针对不同用例进行高度定制

　　在深入研究具体策略之前，了解 Apache Hudi 在不同用例中提供的灵活性非常重要。无论是优化读取还是写入性能，Hudi 都能提供针对特定需求量身定制的选项。

　　1. COW 和 MOR

　　Apache Hudi 提供了丰富的选项，但做出的最基本选择是选择最适合需求的表类型。此决定取决于要优先考虑读取性能还是写入性能。

　　如果需要更快的写入性能并且可以容忍较慢的读取，则 MOR（读取时合并）策略更合适。

　　如果想以牺牲较慢的写入速度为代价进行优化以实现更快的读取速度，则应使用 COW（写入时复制）策略。

　　下表说明了 'Copy on Merge' 和 'Merge on Read' 之间的比较

　　2. 分区 + INDEX

　　虽然在 COW 和 MOR 之间进行选择至关重要，但这只是拼图的一部分。随着数据集的增长，仅靠分区不足以确保性能。这就是索引成为提高查询效率和减少延迟的关键因素的地方。

　　在处理海量数据集时，更新、更新插入或读取特定行等操作通常会遇到常见的挑战。对表进行分区是必不可少的，但这只是起点。随着数据的增长，即使是分区表也可能变得很大，需要有效地确定哪个分区包含要查找的特定行。

　　为了减少延迟、最大限度地减少读取的数据量并提高查询性能，需要的不仅仅是分区，还需要考虑索引。这就是 Apache Hudi 的亮点，它为多模态索引提供了强大的支持。

　　在 Hudi 提供的各种索引策略中，Record Level Index （RLI） 最为核心。RLI 利用HBase能力在元数据文件夹中的存储键值 ，与其他全局索引相比可提供卓越的查找性能。

　　但是，并非每个使用案例都需要全局索引。对于这些情况，Hudi 提供了有效的替代方案，例如众所周知的 Bloom Index，针对特定需求量身定制，而无需全局索引的开销。

　　3. 表维护

　　除了索引之外，有效维护表对于长期性能优化也至关重要。这包括确保高效的文件管理，例如文件大小调整、聚簇、清理和压缩。这些功能都有助于保持数据处理的顺畅和高效。

　　在性能方面，聚簇服务与索引一样重要。当对频繁查询的数据进行物理排序时，查询引擎的执行效率更高。Apache Hudi 原生支持具有多种策略的集群，以满足不同的需求。

　　文件大小调整服务解决了文件过小等常见问题，这些问题会显著降低数据湖中的读取性能。当表被碎片化为许多小文件时，查询需要更多的请求，从而导致处理时间增加。适当的文件大小还可以提高压缩率，因为大小不佳的文件会导致压缩效率低下，从而导致更大的存储要求。

　　清理服务对于回收过时数据版本所占用的空间非常重要。通过清理旧版本可以释放存储空间并保持更高效的表结构。

　　Apache Hudi 完全支持所有这些功能。可以内联（作为管道的一部分）或作为单独的作业异步运行这些流程，具体可以按需选择。

　　4. 调试和数据审计的时间旅行

　　除了性能优化之外，Hudi 的时间旅行功能还通过提高数据完整性并实现高效的调试和审计来增加另一层价值。此功能在长期保持数据质量方面起着关键作用。

　　Apache Hudi 的突出特点之一是其时间旅行功能，它允许回滚到以前版本的表。此功能改变了我们的调试和数据审计流程，显著提高了我们的 QA 运营效率。访问和查看历史数据状态的能力使我们能够快速识别和解决问题，最终增强整体数据完整性。

　　5. 现实生活中的 COW 示例

　　为了更好地理解 COW （Copy on Write） 表如何与内联聚簇和清理一起操作，请查看下面的示例。

　　实施挑战

　　与任何高级技术一样，实施 Apache Hudi 也有其自身的一系列挑战。在我们的案例中，Spark 的复杂性和大量新的 Hudi 选项带来了一些困难。为了解决这些问题，我们为大多数使用案例开发了模板，并将 DBT（数据构建工具）整合到我们的工作流程中。

　　这种抽象使我们能够充分利用 Spark SQL 及其高性能内置函数，而不会被 Spark 的复杂性所淹没。通过创建可重用的模板，我们显著缩短了开发时间，并保持了数据处理管道的一致性。

　　此外我们按照奖章架构构建了数据湖，通常包括：

　　Landing

　　我们存储原始数据，不进行任何转换，并使用原始扩展名（如果适用）。

　　Raw

　　我们将数据转换为 Parquet 格式以供使用，但不执行任何其他类型的数据转换。

　　Master

　　使用 Hudi 表，源可以是原始表或主 Hudi 表以创建新模型。

　　这种结构与 DBT 一起确保了高效的数据处理并支持我们不断增长的工作负载。

　　资源管理

　　随着数据操作的增长，高效管理资源是确保可扩展性的关键。为了实现这一点，我们在 DBT 存储库中创建自定义配置文件，以根据工作负载大小和复杂性分配资源。

　　为了有效地管理我们的资源，我们在 DBT 存储库的 profiles.yml 文件中创建了不同的配置文件 — XS、S、M、L 和 XL。这些配置文件使我们能够根据工作负载的大小和复杂性适当地分配资源，从而确保各种使用案例的高效和可扩展性能。

　　AWS Glue 集成

　　在解决了最初的挑战之后，我们寻求进一步的简化。dbt-glue 连接器的集成使我们能够抽象出 Spark 和 Hudi 的复杂性，从而为我们的运营提供更多的控制和效率。

　　dbt-glue 连接器消除了管理 Spark 集群的需要，使我们能够在 AWS Glue 上无缝运行所有内容。为了进一步简化我们的操作，我们使用 dbt-glue 连接器的一个分支调整了我们的 DBT 存储库，以更好地满足我们的 Hudi 要求。通过创建预定义的模板，我们简化了实施过程，并定制了我们的设置以使用 Hudi 0.14.1 版本。

　　在整个过程中，我们确定了工作流中常用的关键选项，例如记录级别索引 （RLI）、Glue 数据目录同步以及最小和最大文件大小。这些选项可以嵌入到代码中以自定义模板并优化操作。

　　通过使用 AWS Glue 连接器，我们显著降低了管理 Spark 和 Hudi 的复杂性，同时保持了高性能和灵活性。

　　实施 Hudi 的编排和收益

　　为了确保工作流程的顺利和自动化，我们使用 Airflow 进行编排，从而简化了作业调度和监控。这与AWS Glue 设置相结合帮助我们实现了显著的性能改进和成本降低。

　　为了有效地管理我们的数据工作流，我们使用 Airflow 进行编排，确保顺利运行，而不会产生不必要的复杂性。通过利用 Airflow，我们能够轻松地有效地安排、监控和管理我们的 ETL 作业。

　　与 AWS Glue 配合使用获得了可扩展的无服务器环境，无需手动管理基础设施，使我们能够专注于数据处理任务。这种工具组合有助于简化运营并优化性能。

　　实施 Apache Hudi 的结果令人印象深刻。通过整合 Hudi 的高级功能，我们发现最需要资源的流程的成本降低了近 70% 。Hudi 的功能（例如时间旅行、索引和文件管理）大大提高了我们的数据管理效率。这不仅帮助我们降低了成本，还提高了数据管道的整体性能，使其更具可扩展性和成本效益。

　　未来规划

　　实施这些优化后，我们计划将高性能工作负载迁移到数据湖，此举旨在进一步降低成本并提高可扩展性。

　　展望未来，我们计划将高性能工作负载从 Snowflake 仓库迁移到数据湖 。这一战略举措旨在进一步降低成本，并使 Snowflake 能够直接从数据湖中读取某些模型，从而优化我们的资源并提高效率。通过移动这些工作负载，我们希望利用数据湖的可扩展性，同时保持 Snowflake 的分析功能。

　　我们的最终愿景是发展成为一个数据湖仓一体，整合整个公司的所有数据运营。这个统一的平台将推动洞察和创新，在整个组织中培养数据驱动的文化。数据湖仓一体结合了数据湖和数据仓库的最 佳功能，为分析和运营工作负载提供单一平台。这种集成将使我们能够更有效地管理数据并实时获得可操作的见解。

　　我们已经在进行下一步工作，并使用 Hudi 的另一个出色工具 HoodieStreamer 在我们的数据湖中获取实时数据。这一进步将使我们能够利用实时数据洞察，将运营推向新的高度。实时数据处理使我们能够立即对变化做出反应，从而改善决策流程和运营效率。

　　原文链接：https://www.y.uno/post/how-apache-hudi-transformed-yunos-data-lake