释放数据湖潜力：小红书如何实现数仓效率与成本的双重优化

在当今以数据为核心的商业环境中，企业正面临着海量数据的处理和分析挑战。为克服传统数据仓库在处理速度、灵活性和成本效率方面的局限，小红书数据仓库团队引入如 Apache Iceberg 等数据湖技术，将其与数仓架构相结合，以释放数据湖在查询性能、实时数据处理和成本效益方面的潜力。

小红书数据仓库团队通过一系列创新实践，如 UBT 链路优化查询效率、渠道归因数据架构改造、汉姆拉比数据链路优化以及直播准实时链路提升等，证明了数仓与数据湖技术的结合能带来显著的业务价值：不仅提升用户体验，还实现了计算和存储资源的大幅度节约，同时确保了数据的高质量和一致性。

未来，团队计划继续利用数据湖技术构建准实时的数据新架构，以满足企业对数据时效性的多样化需求。

过去十多年，Hive/Spark on HDFS 作为离线数据仓库的事实标准，在实践中得到了广泛应用。然而，随着业务对数据时效性和查询性能要求的提升，Hive 的传统架构开始显现出其局限性。具体表现在：

• 数据变更成本高昂：即使仅变更一条记录，也需要重新刷新整个分区的数据；
• 数据产出时效性差：分区数据通常需要 T+1 日期才能完成；
• 数据查询性能缓慢：查询相关数据通常需要扫描目录中的所有文件，大表查询耗时且效率低下；
• 资源利用率不足：所有天级调度任务的资源消耗全部集中在调度期间，容易导致多任务抢占资源，影响资源使用效率。

这些性能问题严重制约了数据仓库在支持业务决策中的作用。为了应对这些挑战，我们积极探索新方向，力求在满足业务日益多样化的需求下，总结出一些通用化、低成本的数仓架构新方案以解决上述问题。本文详细记录了我们在数仓架构和数据湖技术结合方面的深入探索和实践，期待对您有帮助，欢迎结合自己兴趣和相关业务自主选择阅读。

数据湖技术近年来在数据管理领域引起了广泛关注，其优势在于提供了一种灵活且高效的数据存储和处理方式。一方面，在 Apache Iceberg、Apache Hudi 等知名开源项目的推动下，社区气氛十分活跃；另一方面，处于链路上下游的数仓软件和数据分析引擎，也开始积极拥抱开放的数据湖格式，如 Doris 系的开源数仓和 Starrocks 引擎，它们能够查询 Iceberg 数据，进一步证明了数据湖技术的实用性和前瞻性。

不同于原有的 Hive 数仓架构，Iceberg 依托于其文件级数据追踪的技术架构，展现出以下显著优势：

• 查询性能提升：Iceberg 支持异步数据重组(如 Zorder)，结合动态列全局排序和索引机制，大幅减少查询时的文件读取量，显著提升查询效率和 shuffle 性能。
• 增量读写能力：小红书自研的 Iceberg 适配了 Spark 引擎，支持 update、merge into、delete 等语义，能够对指定文件进行删除和更新操作。相较于 Hive 的分区目录完全重刷，可将更新成本降低至文件粒度。
• 流批一体架构：Iceberg 基于增量读写机制，通过适配 Flink 等实时引擎的读写，形成了“MQ + Flink + Iceberg”的流批一体架构。对于近实时的需求，这种架构既可以提升数据产出的时效性，也可以省去维护 Lambda 架构所需的人力和资源成本。
• 成本效应显著：Iceberg 底层采用 Parquet 文件格式，其列存储格式和索引排序机制通过提升重复字段的压缩效率，进而节约了存储成本。

UBT 日志（User Behavior Tracking），全称用户行为追踪日志，详细记录了用户在特定平台、应用或网站上行为轨迹，如页面访问、图片曝光、按钮点击等。作为流量数据的核心组成部分，UBT 也是小红书数据仓库中数据量最大、查询频次最多的数据表之一。随着小红书用户基数的快速增长和使用时长的增加，流量数据规模不断膨胀，导致 UBT 日志查询效率低下，用户体验受损。用户在进行日志查询时，常常面临长时间的等待，甚至在数据量过大时无法完成查询，这些问题严重制约了数据驱动决策的效率和效果。

3.1 历史方案回顾

在处理 UBT 日志数据时&