小红书 App 作为月活跃用户突破 3.5 亿的生活兴趣社区，以“社区+电商+商业化”为核心，通过 UGC 内容驱动“种草-拔草”的业务闭环。随着用户规模与业务复杂度持续攀升，日志规模日均达到数千亿，催生了海量的实时与离线数据需求。本文将深入解析小红书数据架构的四次迭代历程，揭示其如何基于新一代通用增量计算替代现有 Lambda 架构，实现架构复杂度降低 1/3、资源成本降低到 1/3、开发成本降低到 1/3 的技术突破。

01 小红书数据框架的演进

1. 小红书业务及数据概览

小红书整体数据平台采用业界通用的数仓标准与建模方式维护管理，包含自建的调度平台、运维平台、资产管理平台、治理平台、报表平台等一系列产品型工具能力。这些工具共同助力数据资产在企业中发挥更大价值。价值输出主要分为四类：

• 数据分析：支持面向高管的报表，以及面向一线运营和销售的自助分析产品。
• 数据产品：面向广告主、商家、博主、内部需求方的数据平台。
• 数据服务：提供给推荐、搜索、算法团队的用户画像及特征标签。
• AI 相关：借助 AI 帮助用户更轻量地获取数据洞察、生成数据报告和给出经营建议。

2024 年，小红书完成了从 AWS 到阿里云的大规模云迁移，迁移数据量高达 500PB，任务 11 万，参与人数 1500 人，涉及部门 40 多个。目前已有部分业务在自建云上试跑，未来将向混合云架构发展。

2. 数据架构的演进迭代

小红书认为，让数据在企业内部发挥更大价值的关键在于极致的效率。为此，团队进行了四次数据架构迭代，核心目标是降低数据获取成本、提升使用效率、降低数据对业务同学的门槛。

1.0 架构：基于 ClickHouse 的即席分析

1.0 架构相对简单：离线数仓将数据宽表加工后加载到 ClickHouse 中，供运营团队获取数据。相比原始 Spark SQL，响应速度从分钟级提升到了秒级。但该架构存在三个明显短板：

• 成本高：ClickHouse 集群搭建成本较高，对 CPU 和内存要求严苛。
• 扩容难：ClickHouse 采用存算一体架构，业务快速扩张时，扩容面临数据搬迁问题。
• 数据时效性差：数据通过 Spark T+1 加工后再导入 ClickHouse，存在数据搬迁的时间成本。

2.0 架构：存算分离的 Lambda 架构

针对 1.0 的痛点，小红书基于开源社区版 ClickHouse，开发了存算分离的 Lambda 数据架构。核心变化包括：

• 将 ClickHouse 的 MergeTree File 同步到对象存储及本地 SSD 存储中，扩展了查询时间范围，降低了数据存储成本。
• 引入 Lambda 架构，将 Flink 生产的实时数仓数据和 Spark 生产的离线数仓数据，以 ClickHouse 为中心节点进行合并，实现了从天级别到实时数据的指标洞察。
• 利用 ClickHouse 的多类型关联、物化视图以及索引加速能力，优化查询效率。

目前，每天约有 6000 亿条数据量同步进入 ClickHouse。面对万亿级数据规模的查询挑战（至少 7 天或 14 天，近 10 万亿数据，要求 10s 级响应），小红书团队进行了大量性能优化：

• 按照用户进行分统，ClickHouse 做 local join，满足用户特征和行为分析。
• 通过抽象所有日志中的可枚举字段创建物化视图，将 6000 亿日增数据压缩到 200 亿左右。
• 构建灵活的索引（如根据用户 ID 构建 BloomFilter 索引），优化具体查询场景。

最终实现了万亿级数据规模在 10s 内的响应，为内部 200+ 产品提供自助分析能力。

3.0 架构：基于 Lakehouse 的湖上建仓

2.0 架构面临三个核心问题：

• 存在两套存储（数仓的对象存储与 ClickHouse 的 MergeTree 存储），增加了存储成本和数据不一致风险。
• 存在两套计算框架（Flink 和 Spark），计算语义差异可能导致指标质量偏差。
• ClickHouse 缺少 ETL 能力，写入的数据是终点，无法像流式数据一样进行增量消费。

解决方案是采用Lakehouse（湖上建仓）架构：Flink 负责日志处理及入湖，Iceberg 存储数据，Spark 运行任务，StarRocks 进行作业查询。

查询性能优化是核心：在业务变化快、表 schema 迭代频繁的情况下，预先设计的索引逐渐失效。小红书启动了自动 Z-Order 排序和智能排序优化：收集 StarRocks 日常用户的 query，智能感测索引与用户真实查询的差异，在 Iceberg 数据入湖后启动异步作业进行 Z-Order data file 重写，确保 80%~90% 的用户查询命中 Z-Order 排序。优化后，单表 query 从约 5.5TB+ 扫描量缩减到 600GB+，提升约 10 倍。

在 3.0 架构下，湖仓数据整体规模超过 300PB，日增 4PB，均能准实时入湖。

3.0 架构的收益

• 基本覆盖业务体系的核心场景，一线业务用户渗透率达到 70%。
• 官方数据集收敛到 300 个，覆盖核心分析场景，让 AI 能更准确地给出答案。
• 湖仓数据整体规模超过 300PB，日增 4PB，均能准实时入湖。

小提示： 构建高效率的数据架构，关键在于“做减法”。与其让 AI 面对数百 PB 级的庞大数据，不如将数据资产和业务标签做得足够精，把范围缩小到足够小，才能获得更准确的 AI 分析结果。

4.0 架构的探索：通用增量计算

尽管 3.0 架构已基本完成湖仓体系演进，但依然面临数据时效性挑战。传统实时数仓中，一个实时任务的开发成本是离线任务的三倍，且面临数据回刷、资源锁定、任务稳定性等问题。因此，目前大部分数据资产仍在离线进行 ETL 加工。

2025 年，小红书与云器科技一起探索了增量计算在真实业务场景中的应用，定义了 Dynamic Table，包含所有的 ETL 逻辑，基本覆盖了当前 Spark 加工涉及的常用算子（如 union、各类 join 等）。验证结论如下：

• 功能验证：改写 Spark 作业为增量计算作业的成本不高，大量业务脚本可直接复制；数据准确性验证通过；可在 freshness 间隔与成本间灵活调节。
• 性能验证：在将时效性从 T+1 变成 fresh per 5 min 的状态下，纯增量表相比 Spark 离线性能提升 1~2 倍；在全量订单表更新场景下，成本基本与 Spark 齐平；在实时汇总任务中，资源成本约为 Flink 的四分之一。

增量计算业务已上线社区、搜索、商业、电商等多个业务场景，成为算法同学日常工作必备工具。

常见问题： 增量计算方案对比传统方案在资源消耗上具体表现如何？

以具体数据为例：相较于以前的实时链路，增量方案能够在投入 1800 core 的情况下达到之前 5000 core 投入的计算能力，整体开发成本约等于 Spark T+1 的离线计算。

3. 应用场景总结及展望

小红书的未来架构演变预计与业内发展方向趋同：

• 流批一体：追求开发架构在生产中的落地。
• 湖仓一体：在 Iceberg 下继续探索如何更快提升查询性能，降低数据实验成本。
• AI 体系：让 Lake House 的数据能快速给用户提供分析建议，发挥更大数据价值。

02 通用增量计算

1. 什么是通用增量计算

在数据处理领域，有一个经典理论——数据的不可能三角：企业不可能同时获得数据的新鲜度、成本和效能，现实中一般只能得到其中两个。这催生了批处理、流计算及交互分析三种计算形态。

为了突破这个三角，业界产生了四个标准：

• 统一的数据：只需一份数据。
• 统一的计算表达：无论开发链路速度快慢，只通过一套 SQL 或 Python 代码进行开发。
• 灵活的调节能力：通过配置满足不同时期不同业务的需求，无需修改架构或调整代码。
• 媲美各平衡点最好的性能：相对老的组装式架构，拥有更高的性能。

这些标准也是 Kappa 架构最终希望实现的目标。

目前流行的奖章模型（Medallion Architecture）是与之匹配的架构，其对数据做了更清晰的三层抽象：

• 铜牌数据层：数据应尽快进入数据存储层或数据湖中。
• 银牌数据层：数据应使用最原始的格式（如照片、Json），不做任何结构化改造，只做整理和过滤，确保数据原始内容不丢失。
• 金牌数据层：面向业务层进行最终的改造。

奖章架构的特点是：非常灵活（保留原始数据层）、数据质量逐渐提升（越向前推进质量越好）、使用增量 ETL 方式使流程成本和时效性达到最优。

2. 通用增量计算及 SPOT 标准

通用增量计算是一种同时面向高性能和低延迟优化的新计算模式，是继批处理、流计算和交互计算之后的第四代数据处理流程。它能完美满足 Kappa 架构设计和奖章模型体系，是一个通用的分布式架构，支持关系计算和非关系计算，支持多种语言。

通用增量计算有 4 个标准（SPOT 标准）：

• S - 全量数据表达：系统应支持一套标准的全量数据表达，所有算子都必须支持增量，不能部分支持，部分不支持。
• P - 高性能和低成本：系统要同时具备高性能和低成本。
• O - 开放：系统需要开放，让不同的引擎能消费同样的数据。
• T - 灵活调节：当业务需要调节时，不需要修改代码和系统。

基于增量计算的实践，小红书实现了三个“三分之一”：

• 资源成本降低到之前的三分之一，降低了大量计算冗余和存储冗余。
• 平台组件数量降低到原来的三分之一，现在只需一份存储和一个计算引擎。
• 开发成本降低到原来的三分之一，只需开发一套 pipeline 就能解决所有问题。

3. 云器科技的实践

最佳实践的标准化设计包括：一套湖仓架构作为底盘，支持结构化和非结构化数据的存储；中间支持基于增量的结构化和非结构化数据处理（结构化数据用 SQL 和关系型表达，非结构化数据用 AI function）；最终生成统一知识库（包含结构化数据表、非结构化数据的向量和标量索引等），并面向 AI 提供 MCP server 和对话接口。

常见问题： 增量计算如何支持非结构化数据的高效分析？

小红书采用了 Json Flatter 技术，将 Json 不再以字符串形式存在，而是具体物化到列，极大优化了压缩性能和查询性能。同时，通过倒排索引优化，使 Date Skipping 效率提升 10 倍，能够快速索引到参与特定实验的用户并聚合指标。

总结

小红书通过四次数据架构迭代，从 ClickHouse 的即席分析，到存算分离的 Lambda 架构，再到 Lakehouse 湖上建仓，最终探索出基于通用增量计算的第四代数据处理流程。这一过程中，不仅实现了架构复杂度降低 1/3、资源成本降低到 1/3、开发成本降低到 1/3 的显著成果，更为数据+AI 时代的数据处理提供了全新的实践范式。对于同样面临海量数据处理挑战的企业来说，小红书的增量计算实践提供了宝贵的参考与借鉴。