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

在当今以数据为核心的商业环境中，企业正面临着海量数据的处理和分析挑战。为克服传统数据仓库在处理速度、灵活性和成本效率方面的局限，小红书数据仓库团队引入如 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 日志查询效率低下，用户体验受损。用户在进行日志查询时，常常面临长时间的等待，甚至在数据量过大时无法完成查询，这些问题严重制约了数据驱动决策的效率和效果。

在处理 UBT 日志数据时，我们曾采用一种朴素的方法：将数据从主表抽取到多个分流表中，以便下游业务方能够针对特定需求进行查询。这种方法在业务逻辑相对简单时，能够有效减少查询的数据量，提高查询效率。

然而，随着业务复杂度的增加，这种方法暴露出一系列问题：

• 成本与复杂性增加：随着业务规则的多样化，分流表的数量迅速增长，导致计算和存储成本不断攀升，且难以管理。

  
  

• 数据一致性挑战：对分流规则的任何变更都需回刷大量历史数据，这不仅耗时耗力，还可能引入数据不一致的风险。

  
  

• 数据冗余与维护困难：个性化的分流规则缺乏通用性和排他性，数据在不同规则间重复存储，增加了维护的难度。

  
  

这种基于自定义规则的分流策略，在面对日益增长的数据量时，不仅资源消耗巨大，而且难以维护，严重影响了数据的实时性和查询效率。在某些情况下，缺乏分流表支持的原日志查询变得异常困难。

3.2 查询性能优化

在流量数据分析中，点位(埋点)作为描述用户特定行为的关键标识，也是业务数仓数据加工的基础粒度。面对小红书线上近万个点位的庞大数据量，我们实施了一系列查询性能优化策略，以提升数据处理效率。

我们认识到，通过点位限制帮助用户缩小数据范围，加速后续的业务逻辑处理，可有效提升查询性能。然而，传统的分区策略在面对庞大的点位数量时显得力不从心，Hive Metastore 难以承受巨大的分区规模。因此，我们的目标转变为如何能购针对特定点位的数据进行快速定位并筛选，实现数据范围的精确缩小。

从这一视角出发，数据湖为我们提供了新的视角和解决方案。我们采用了全局排序的方法，将相同点位的数据集中存储，而将不同点位的数据分散存储在不同的文件中。这种策略不仅提升了文件过滤的效率，还通过引入 Iceberg 技术，将点位的 min-max 信息存储在 meta 文件中。这样，在任务规划阶段，查询引擎就能利用这些信息进行文件过滤，显著减少了实际查询过程中需要处理的文件数量，从而实现了查询性能的大幅提升。

性能优化方案如下：

• 全局排序：按照点位 ID 进行全局排序，实现了自定义的数据抽样和分区划分的逻辑，并且为大点位划分更多分区，解决了大小点位数据倾斜问题，从而提高单个点位的计算效率。另外，为解决随机采样可能存在误差的问题，我们借助 Spark Sql 的自动查询优化（AQE）功能作为兜底，并开发了 bypass hash 函数，以便在 Spark 中实现自定义分区，根据数据生成的 partition_id 来划分分区。

  
  

• 分区排序与去重：若日志数据存在重复的情况，按照传统思路，需要先去重然后再排序来优化查询，这会带来两次 shuffle，显著增加计算成本。为了解决这一问题，我们基于全局排序采取了一种创新的方法：在数据按点位 ID 排序的同时，直接在排序过程中识别并过滤掉重复的数据。

  
  

• Iceberg 视图生成：为了确保与现有 Hive 生态系统的兼容性，我们在 Hive 表上建立了外部 Iceberg 表级视图。这一视图通过扫描数据文件并提交文件 metric 信息，使得下游系统能够基于 Iceberg 的 MinMax 提升查询性能，并且能直接读取视图进行数据消费，简化了数据访问流程。

  
  

通过这些优化，UBT Iceberg 表的查询性能得到了显著提升，用户在查询特定点位数据时的时长缩短了约 80～90%，极大地提高了数据处理的效率和用户体验。

3.3 新分流方案

上述性能优化提升了用户对点位的查询效率。点位是用户使用日志的基础粒度，我们开始进一步考虑以点位为基础，构建一套新的分流体系，旨在替代原有的分流表体系。新体系的设计遵循了三个核心原则：确保分流查询性能满足用户需求、最小化存储和计算开销、以及限制分流表的数量以避免无序增长。基于这些原则，我们设计了以下新分流方案：

• 分流转换功能：新方案实现了在 Spark 执行计划层，自动将对分流表的查询转换为对 Iceberg 表中特定点位集合的查询，从而提高了查询效率。

  
  

• 业务场景导向：新分流体系以通过构建实际业务场景作为准入标准，每个业务场景对应一个分流表，同时通过上线流量产品注册收拢分流表的创建，这样既明确了分流的业务含义，也杜绝了分流数量的无限制上涨。

  
  

• 视图封装：在分流转化函数外层，我们封装了分流表视图，这使得下游业务方无需感知内部优化，简化了数据访问流程。

  
  

新分流表不再直接存储数据，也无需任务调度，从而避免了计算和存储资源的消耗。更新分流表时，只需调整点位集合，无需回刷历史数据。得益于之前的查询性能优化，新分流方案在满足业务需求的同时，也保持了高效的查询性能。

相较于旧方案，新分流方案每天可节省数十万 GB/Hour 的计算资源和几百 TB 的存储资源，同时任务产出时效提升了约 30 分钟，查询性能得到了数十倍的提升。这一改进不仅提升了数据处理效率，也为未来的数据分析和业务决策提供了更坚实的基础。

渠道归因作为分析用户行为路径、埋点归因的关键工具，对于社区、电商和直播等业务的流量分析至关重要。它不仅支持流量来源和转化分析，还有助于深入理解用户路径。作为数据仓库的基础服务，渠道归因要求具备高实效性、准确性和稳定性。

在早期的渠道归因实践中，我们使用 Flink 处理 UBT 日志数据，为每条数据附加用户从打开 App 到当前页面的完整跳转路径，并直接写入云存储。由于小红书的 Flink 集群部署在公有云，而离线数据和处理引擎位于 A 云，我们通过 Discp 操作将数据从公有云迁移到 A 云。这种架构导致时效性差，因为跨云同步和分区任务在离线侧完成，且每天需要占用额外的存储资源，增加了成本。

为了解决这些问题，我们对渠道归因数据架构进行了彻底改造。我们移除了原有的离线 Discp 任务和 Spark 分流，转而采用 Flink 与 Iceberg 的结合，实现了在实时数据写入过程中的自动分流。这一改造不仅优化了任务处理的负载均衡，还确保了分区数据文件数量的可控性，从而保障了离线数据产出的时效性和查询效率。通过这些改进，离线数据的产出时效提升了 90%，从而尽早释放离线集群资源，保障了其他离线作业的稳定性。同时，实时渠道产出的数据现在也能支持交易、直播、广告等实时业务场景，为企业提供更快速、更灵活的数据分析能力。

Iceberg 的实时读写能力使其成为流批一体的理想存储解决方案。然而，由于实时链路和离线链路位于不同的云平台，我们不得不在两个云上分别备份数据。为了解决这一问题，我们设计了两条独立的数据处理链路：实时业务消费实时分流任务的数据，而离线侧则消费 Iceberg 数据。在新架构中，渠道归因数据首先写入 Kafka，然后分为实时分流作业和实时入湖作业。实时入湖作业按业务分区，将数据写入 Iceberg。Iceberg 收集各分区的最新统计信息，并根据这些信息重新分配业务分区的并发处理，确保整体处理均衡。离线侧通过定期轮询 Iceberg 的元信息，监听当前处理的数据时间，触发下游的小时级或天级任务调度。这一改造显著提升了数据处理的灵活性和效率。

小红书的反爬虫日志，由于接入了整个公司的反爬场景（ Scenarioid ），导致整体数据量庞大。它作为反爬虫日志的核心，其庞大的数据量在生产过程中消耗了大量计算和存储资源。特别是，不同云之间的跨云文件传输过程，每天传输数百 TB 数据，占据了 20% 的带宽资源，尤其是在业务高峰期时，对跨云传输服务造成巨大的负载压力，从而严重影响跨云传输服务的稳定性。

解决该问题的核心难点在于，在大数据量及有限时间内的条件下，如何有效降低跨云传输的文件大小。为了有效降低跨云传输的数据量，我们结合数据湖团队的流批一体工具链，对汉姆拉比数据链路进行了优化，采取以下策略：

• 数据同步策略调整：不再直接同步公有云上的 Agent-smith 日志，而是通过 Kafka2Iceberg 任务，将汉姆拉比 Kafka 数据同步到公有云上的 Iceberg 表，Iceberg 底层基于 Parquet 文件格式，其列存储格式和索引排序机制可以提升重复字段的压缩效率，因此最终跨云同步的对象变成了经过压缩的 Iceberg 表，从而极大提升了同步效率。

  
  

• 数据压缩与批量处理：在 Kafka 中，我们针对场景（ Scenarioid ）字段进行 shuffle，并通过每 5 分钟 checkpoint 机制批量导入数据到Iceberg 表，同时在导入过程中对文件进行 Parquet 压缩。这种 shuffle 和 压缩的结合显著提高了数据的压缩率。

优化后成果显著，新链路的数据到岗时间比老链路提前了约 85 分钟，专线带宽节省了 83%，存储空间也减少了 83%。这些改进不仅提高了数据处理效率，还为公司节省了宝贵的资源，确保了数据链路的高效运行。

为了提升直播业务的数据处理能力，我们基于数据湖技术对直播实时链路进行了全面改造，实现了流批一体的数据处理架构。这一架构不仅在交易实时数仓领域得到了成功应用，还显著提升了直播间入口曝光和点击行为事实明细表的数据处理效率。

如下图所示，直播入口曝光点击流量经分流后进入直播处理链路，此时会写入数据湖，作为历史数据回溯使用，而 Kafka 链路则基于 Flink 任务加工生成实时离线一致的 DWD 层，同步入湖和 Kafka，满足实时、近实时、离线的直播下游使用需求。

通过采用 Flink 与 AWS Iceberg 的结合，以及多个用户自定义函数（UDF），我们成功地将原有的 UBT 链路切换至新的架构。这一转变不仅还原了大部分字段，还确保了数据校验的一致性。目前，新链路已稳定运行，显示出以下显著优势：

• 流批一体：实时和离线逻辑的统一，确保了数据的一致性。字段解析和逻辑处理集中在实时处理中，避免一点改动涉及多张表的问题。

  
  

• 统一数据源：实时和离线分析使用相同的数据源，进一步保障了实时与离线指标的一致性。

  
  

• 维护成本降低：公共层的人力维护成本大幅减少，迭代和开发工作现在只需单一人员完成。

此外，数据湖技术还显著提升了直播数仓的实时开发效率和数据质量。例如，AWS Iceberg 支持离线任务调度，实现流批一体，而相对便宜的 COS Iceberg 提供了成本效益更高的数据入湖存储，适用于日常的数据校验、Kafka 即时查询和 Case 排查等需求。

COS Iceberg 的引入解决了 Kafka 数据存储时间短和即时查询不便的问题，使得实时开发更加便捷。实时写入任务，如 Starrocks、Redkv、ES 等，都会同时写入 COS Iceberg，便于问题排查和数据校验。Iceberg 中存储的分区、Offset等元信息，对于排查字段状态、乱序等问题尤为有用。

数据湖技术的 upsert 能力为数仓架构带来了显著的升级。对于日志表等 Append 类型表，实现流批一体相对容易，但对于需要更新操作的 Upsert 表，数据湖必须具备相应的能力。为此，数据湖团队早期开发并上线了 Iceberg v10 表，该表支持 upsert 功能。如下图所示，在这一架构下，数仓团队已成功应用于域内和域外订单表，通过 Package_id 和 Sku_id 的联合主键进行更新，使得表既可以作为增量表，也可以作为全量表使用。此外，基于 As Of Time 的时间切片查询功能，全量表仅需存储一份数据，这不仅方便了实时离线数据的对齐和历史状态查询，还弥补了离线链路数据归档后状态回溯更新成本高的问题。

展望未来，数据湖团队将继续开发和迭代 Apache Paimon，数仓也将采用 Paimon 来构建支持 upsert 场景的流批一体架构，进一步提升数据处理的灵活性和效率。这将为实时分析和历史数据管理提供更加强大和灵活的工具，确保数据湖技术在数仓架构中的全面应用和持续优化。

结合数仓与数据湖技术的相关实践，从落地效果上看，我们已经在三个关键领域实现了显著的收益：

• 产出时效：通过准实时链路的改造，我们显著提升了数据处理的时效性。ODS 和 DWD 层的数据时效提升了 50%。同时 0-2 点为资源空闲时间段，提前产出能够留给下游任务更多的空间，提升空闲时间段的资源利用率。

  
  

• 成本收益：主要分为存储成本收益、计算资源成本收益和人力成本收益。例如，“汉姆拉比数据链路”优化后，新链路节省了 83% 的存储空间。在计算资源方面，" UBT 链路优化查询效率提升"项目每天节省了数十万 GB/Hour 的计算资源和几百 TB 的存储资源。人力成本方面，流批一体架构的实现减少了公共层的维护和开发工作，如"直播准实时链路提升"项目，现在仅需一人即可完成迭代和开发。

  
  

• 数据质量：通过 "MQ + Flink + Iceberg" 的流批一体架构，我们确保了实时和离线数据的一致性，有效解决了数据不一致的问题，从而提升了数据质量。这在"渠道归因数据链路架构"和"直播准实时链路提升项目"中得到了验证。

数据湖技术为数仓提供了一种高效、低成本且响应迅速的解决方案，有效满足了公司对数据时效性日益增长的需求。

展望未来，我们计划在数据引擎团队的支持下，利用数据湖技术大规模构建，低成本的次实时数据解决方案。这些方案将针对那些不需要极快速响应的业务场景，旨在成为实时分析的首选。通过这种方式，实现开发效率和资源成本的双重优化。

此外，我们还将探索“数据湖 + OLAP 引擎”的组合策略，以构建新的业务交付标准。这种策略将结合数据湖的灵活性和 OLAP 引擎的高性能，为数仓提供更强大的数据处理能力，支持更复杂的分析需求，提高数据迭代的效率，同时保持成本效益。我们致力于通过这些创新推动数仓技术的持续进步，为公司的数据分析和决策提供更坚实的支持。诚挚邀请您的加入，一起探索数仓和数据湖技术的无限可能。