从 POC 到生产！Leboncoin 基于 Apache Hudi 构建 Lakehouse 实践

每天约有 800 万独立访问者访问 Leboncoin，到 2022 年，该网站每月有超过 1000 亿次 HTTP 调用并且启动和运行 700 个应用程序，使其成为访问量最大的法国网站之一。

数据平台团队负责构建和维护平台基础设施以及开发内部 API，负责将 Leboncoin 的生产数据（大量 Kafka 事件）归档到所有团队都可以访问的非常大的数据湖中。

该解决方案在一段时间内发挥了作用，但随后欧洲通用数据保护条例 (GDPR) 合规性成为了一个问题。法律规定，已关闭账户的用户应在 3 年后被删除，不活跃用户应在 5 年后被删除。由于放入湖中的数据是不可变的，因此团队无法轻松删除请求删除帐户的用户的数据。

因此，他们决定使用 Apache Hudi 为数据湖库构建概念验证 (POC)，以测试这是否更适合他们的需求。

本文解释了他们如何将 POC 转变为生产就绪的数据Lakehouse，由于数据平台团队和客户之间的密切合作，该数据Lakehouse现已由 Leboncoin 和 Adevinta（该公司所属的集团）的 5 个团队使用关系管理 (CRM) 功能团队。

为 Hudi Lakehouse 构建 POC：数据平台团队的为期一年的项目

适合工作的工具

为了遵守 GDPR，数据平台团队决定在 2022 年将旧数据湖迁移到基于开放表格式（称为 Lakehouse）的新设计。他们可以使用三个选项，允许根据需要拍摄和删除数据快照：Delta Lake、Apache Iceberg 和 Apache Hudi。经过多次基准测试和测试后，团队选择了 Hudi。

处理速度更快

这种迁移带来了更快、更便宜的 ETL（提取、转换、加载）管道，因为 Hudi 自动提供适当大小的文件来解决数据湖中经常遇到的小文件问题。由于事务查询，表中的记录现在可以更新或删除。还提供了一些新功能，例如表索引和查询旧表快照的能力（也称为时间旅行功能）。

扩展数据Lakehouse的使用

由于 Lakehouse 带来的价值，数据平台团队很快开始考虑将该项目用于不仅仅是存档数据。事实上还有其他用例需要考虑。表是在数据仓库 (Amazon Redshift) 中创建的，目的是删除和更新数据，这在传统数据湖中是不可能的（但现在在数据Lakehouse中是可能的）。数据仓库还提供低延迟，而数据Lakehouse则能够通过并行查询实现更好的性能，且对集群大小没有限制。

结果

Lakehouse实现架构

image.png

• • datalake-archive，其中来自所有微服务的存储数据按 Kafka 日期和时间分区，并使用 Apache Parquet 写入；
• • datalake-ident，根据 GDPR 删除敏感数据，并按真实事件日期和时间进行分区；
• • datalake-pseudo，与 datalake-ident 相同，但个人和机密列是假名的，也按真实事件日期和时间分区。

Lakehouse新架构

在生产中实施 Hudi Lakehouse

第 1 阶段：考虑背景

CRM 团队当时考虑使用数据Lakehouse有两个原因：

• • 1/ 他们正在从 Adobe Campaign 版本 7 迁移到版本 8。由于他们需要构建新的数据管道来为这个新的 Adobe 实例提供数据，因此是时候考虑一种新的数据架构和模型，不再源自数据仓库，而是直接源自数据湖，并创建自己的数据Lakehouse，他们预先计算了 CRM 数据管道（之前位于数据仓库中）所需的表。数据网格方法被用作将 CRM 数据整合到一处并消除对其他团队不必要的依赖。
• • 2/ 消除对商业智能 (BI) 团队维护的 Redshift 数据仓库的依赖已经成为一个持续的主题，该团队在上游预先计算了许多表。

第 2 阶段：与数据领导者和架构师举办研讨会

目前还不清楚将使用哪种技术来解决 CRM 团队的问题。因此，他们与他们所在部门的数据领导者和架构师组织了研讨会，以了解市场上可用的产品以及其他公司正在使用的产品。这就是他们提出 Lakehouse 解决方案的原因，该解决方案使他们能够将所有数据整合到一个地方并管理处理，而无需依赖其他团队。

第 3 阶段：发现Hudi Lakehouse POC

CRM 团队了解到数据平台团队已经在致力于使用 Hudi 开发数据Lakehouse。对于 CRM 团队来说，加入这个项目似乎是一件好事，因为他们无法在只有 3 名数据工程师的情况下从头开始实施一项新技术，因此他们要求加入该项目。

但故事的开始并没有我们想象的那么顺利！首先，数据平台团队向 CRM 团队展示了如何使用 Hudi，并告诉他们现在可以创建自己的表。但事实证明，CRM团队需要的一些功能还没有实现。当他们回到数据平台团队时，他们拒绝了（因为 CRM 提出了很多要求），声称 CRM 团队用例不在他们的路线图上，并且 Hudi 数据Lakehouse项目应该仍然是 POC。

第 4 阶段：与数据平台团队建立密切关系

CRM团队不可能再回到对BI团队的依赖，BI团队也不希望他们处理数据仓库中的数据。因此，有必要继续推进数据Lakehouse：这是他们唯一的选择。经过CRM和数据平台团队之间的多次讨论，一致认为数据平台将帮助CRM实现最初尚未实现的Hudi新功能：例如，允许他们创建空表的init功能对于自我管理来说是必要的。连接和回填。此外数据平台团队会帮助他们调试，找出为什么表处理会从几分钟变成一小时，而没有任何明显的解释，选择正确的索引来获得更好的性能。

阶段5：协同支持多表

此时项目中的每个 Lakehouse 表只有一个数据源表，不允许进行转换或聚合。经过与 CRM 团队几个月的合作（该团队拥有数据平台团队可以应用的用例），创建了数据湖库的扩展和 Airflow 插件。新产品接受 SQL 查询和描述表配置的小 YAML 文件，以自动创建表和 Airflow DAG（有向无环图），其中包含计划将数据插入表的作业。

收益

生产中16张表

到目前为止Hudi Lakehouse 中总共有 16 个 CRM 表（共 400 个表）正在生产中，这些表可以像在数据仓库中一样进行更新或删除。其中分类广告表包含4100万条活跃行，历史数据跨度1个月。每小时更新 10k 到 130k 行，大约需要 5 分钟。Hudi 还用于添加、更新和删除某些仪表板活动表中的数据。

5个不同的用户团队

目前超过 5 个团队使用 Leboncoin 和 Adevinta 的 Hudi Lakehouse。由于 Airflow 插件，数据平台团队成员自己更喜欢使用它来创建表（之前他们必须使用定制的 Spark 作业和 Python 脚本来创建 Airflow DAG）。

未来规划

数据平台团队仍在致力于该项目，以使数据Lakehouse通过以下方式发展：

• • 添加新功能，例如聚簇和记录级索引，以提高表的读写性能。
• • 实施增量查询（读取时合并）以更频繁地更新表：例如每 2 或 5 分钟更新一次，以取代当前每小时更新一次。
• • 支持标准数据转换工具dbt。
• • 增加使用 Hudi 数据 Lakehouse 的团队数量。
• • 从长远来看，用数据Lakehouse取代整个数据仓库。