小红书 App 作为月活用户超过 3.5 亿的生活兴趣社区，围绕“社区+电商+商业化”核心业务，通过 UGC 内容驱动“种草-拔草”的业务闭环，持续提升用户规模和粘性。与此同时，其日志规模达到日均几千亿，由此催生了大量的实时、离线数据需求。
本文将分享在 Big AI Data 时代下，小红书数据架构的演进历程，重点介绍如何基于新一代通用增量计算替换现有 Lambda 架构，从而实现架构复杂度、资源成本、开发成本均降低 1/3 的显著成果。同时，文章也将阐述增量计算的定义与标准。
1. 小红书数据架构的演进
在小红书 APP 中，用户可以浏览社区笔记、与朋友进行互动、观看直播、在商城购买商品，这些业务均由数据强力驱动。小红书庞大的用户体量及其超高的业务复杂度，对数据平台的数据能力提出了巨大挑战。
1.1 小红书业务及数据概览
目前，小红书的整体数据平台采用业界通用的数仓标准和建模方式进行维护管理，涵盖自建的调度平台、运维平台、资产管理平台、治理平台、报表平台等一系列产品型工具，共同辅助数据资产在企业中发挥更大价值。
其中，数据价值输出主要分为四类：
- 数据分析：例如支持面向高管的报表、支持一线运营及销售的自助分析产品；
- 数据产品：例如小红书面向广告主、商家、博主、内部需求方的数据平台；
- 数据服务：例如提供给推荐、搜索、算法团队的用户画像以及特征标签等；
- AI 相关：例如使用 AI 帮助用户更轻量地获取数据洞察、生成数据报告和给出经营建议等。
2024 年，小红书的基础设施层从 AWS 迁移至阿里云，迁移数据量达 500PB，涉及任务 11 万，参与人数 1500 人，覆盖部门 40 多个，整体迁移和改造的复杂度创下了业界记录。截至目前，小红书已有部分业务在自建云上试跑，未来将向混合云架构发展。
1.2 数据架构的演进迭代
从小红书的视角来看，让数据在企业内部发挥更大价值的关键在于极致的效率。这涉及到一个重要命题：企业的高管和一线人员（包括运营和销售团队）都需要学会使用数据。提高数据的使用渗透率是数据在企业内部发挥更大价值的前提。为此，小红书进行了四次数据架构的迭代，旨在降低数据获取成本、提高使用效率，并降低业务人员使用数据的门槛。
小红书的 1.0 数据架构基于 ClickHouse 进行即席分析。该架构相对简单，主要通过离线数仓加工宽表数据，然后加载到 ClickHouse 中，供运营团队获取数据。相较于原始数据架构，Spark SQL 的响应速度从分钟级提升到 ClickHouse 的秒级。然而，该架构存在明显缺点：
- 成本高：ClickHouse 集群的搭建及资源成本较高，其对 CPU 和内存要求较高；
- 扩容难：ClickHouse 采用存算一体架构，在业务快速扩张时，扩容面临数据搬迁问题；
- 数据时效性差：数据通过 Spark T+1 加工后导入 ClickHouse，存在数据搬迁的时间成本，导致业务人员获取的数据可能已不具备时效性。
针对 1.0 数据架构的痛点，小红书基于开源 ClickHouse 开发了存算分离的 Lambda 数据架构（2.0 版本）。
在 2.0 数据架构中，小红书将 ClickHouse 本身的 MergeTree File 同步到对象存储及本地 SSD 存储中，有效扩展了 ClickHouse 可查询数据的时间范围，并极大地降低了数据成本。
同时，2.0 架构引入 Lambda 架构，将 Flink 生产的实时数仓数据和 Spark 生产的离线数仓数据以 ClickHouse 作为中心节点进行合并，统一提供给业务方，实现了从天级别到实时数据的指标洞察。此外，小红书还利用 ClickHouse 的多类型关联、物化视图以及索引加速能力，优化了用户查询和数据获取效率。
小红书 App 迭代速度快，要求产品团队能够快速进行数据洞察。因此，App 内所有用户行为日志经 Flink 加工后同步到 ClickHouse 中。目前，每天约有 6000 亿条数据量同步进入 ClickHouse，同时也会同步用户笔记的画像、标签等数据，以便进行联合分析。
由于涉及的用户数据体量巨大，查询性能优化成为亟需解决的问题。普通分析通常需要查看 7 天或 14 天的数据，涉及近 10 万亿规模数据，且要求 10 秒级的响应，这是一个巨大的技术挑战。为此，小红书团队进行了多项性能优化，以下挑选部分优化点进行说明：
- 按照用户进行分统，ClickHouse 进行 local join，以满足用户特征和行为分析需求；
- 抽象所有日志中的可枚举字段创建物化视图，使 70%的用户查询能够命中物化视图，将 6000 亿日增数据压缩到 200 亿左右；
- 构建灵活索引以优化具体查询场景，例如，根据用户 ID 构建 BloomFilter 索引，以快速获取某个用户的具体行为。
此时，小红书的数据平台已实现秒级分析能力，支持万亿级数据规模在 10 秒内响应，为内部 200 多个产品提供自助能力，业务方不再需要向数据部门提交数据需求。
随着业务发展，大量业务数据资产仍存储在数据仓库中。2.0 架构面临三个问题：首先是存在两套数据存储。数仓数据存储在对象存储上，而 ClickHouse 文件以 MergeTree 形式存储在 ClickHouse 中，这增加了存储成本和数据不一致的风险。其次是存在两套计算框架。Flink 和 Spark 在计算语义上有所差异，生产环境中的实现代码也不同，可能导致整体指标质量问题。另外，ClickHouse 缺少 ETL 能力，写入 ClickHouse 的数据意味着数据终点，不像流式数据可在 Kafka 之间流转进行增量消费。以上三个痛点促使小红书构建 3.0 架构以寻求解决方案。
小红书的对应解决方案是采用 Lakehouse 架构，整合数据湖和数据仓库的优势。在该架构下，Flink 负责日志处理及入湖，Iceberg 存储数据，Spark 运行任务，StarRocks 进行作业查询。数仓加工出的数据，如 dws 宽表，由 StarRocks 进行快速 T+1 分析。若需进行实时数据探查，可直接使用 ods 中的 Iceberg 数据。
优化查询性能依然是 3.0 架构的重中之重。小红书希望用户查询进入平台后能获得秒级响应。团队分析了过去遇到的问题，发现在业务快速变化背景下，表的 schema 迭代快，用户命中预先设计索引的概率降低，随时间推移索引逐渐失效，导致之后需要全表扫描。在 Lakehouse 架构下，小红书启动了自动 Z-Order 排序、智能排序以优化查询性能。主要逻辑相对简单：收集 StarRocks 日常用户查询，总结当前业务常用筛选经验，智能感测当前索引与用户真实查询的差异，识别后在 Iceberg 数据入湖后启动异步作业，进行 Z-Order data file 的 rewrite。如此能保证 80%~90%的用户查询命中 Z-Order 排序。对比优化前后效果，优化前单表查询约是 5.5TB+，而经过优化，扫描数据量可迅速缩减为 600GB+，提升约 10 倍。
除此之外，小红书还进行了其他多方面优化。综合来看，得益于排序键和数据分布等方面的优化，湖上存储的压缩率相比 ClickHouse 提高了 1 倍。在查询性能方面，采用 3.0 存算分离架构后，整体查询性能相比 ClickHouse 优化了 3 倍，加上 local cache 的加持，基本能保证 P90 查询时延在 5 秒左右。
在小红书复杂的业务体系下实现如此查询性能十分困难。因此，在底层能力构建业务经营数据自助体系的基础上，2025 年小红书正在尝试向 AI 方向探索，有机整合所有数据资产，构建自己的 BI 平台，具备逻辑视图和物化加速能力。
在逻辑视图方面，通过收敛数据集数量、统一口径定义来降低理解成本，提升数据集在整体业务的覆盖率，并降低数仓 ETL 加工成本。同时，平台也会根据用户的查询做智能按需裁剪。
在物化加速方面，减少数据层级。此前会在 dws 层后使用高度汇总层（app 层或汇总层）。小红书通过搭建基于 dws 层的看板报表，识别用户模式，总结如何物化。这样，整体的汇总逻辑就不会冗余在汇总层和各种 App 层，而是精准落在 dws 层。得益于此，用户在使用报表时，能将指标卡上的数据分享给其他用户，并快速下钻获得明细和所有下钻洞察。
1.3 Lakehouse 3.0 的收益
首先，3.0 架构上线后，已基本覆盖业务体系的核心场景。小红书追求的目标是所有一线业务用户的渗透率达到 70%，这可能是 AI 在企业内部加速数据使用的门槛，因为如果没有人使用数据，AI 的应用价值就更难以体现。
其次，官方数据集收敛到 300 个，覆盖了核心分析场景。在当前 AI 能力和底座能力下，如果 AI 面对数百 PB 级数据量去理解所有数据资产并给出准确答案是不切实际的。因此，需要做减法，将范围缩小到足够小，将数据资产和业务标签做得足够精细，以便 AI 给出更准确的答案，在生产中提供真正有价值的建议。
最后，在 3.0 架构下，湖仓数据整体规模已超过 300PB，日增 4PB，且均能准实时入湖。
2024 年小红书基本完成了湖仓体系的整体演进，但仍面临一个问题：如何在湖仓体系架构下提升数据时效性。
在构建实时数仓时，通常一个实时任务的开发成本是离线任务的三倍，且后续持续面临数据回刷、资源锁定、任务稳定性、带状态恢复等问题。因此，尽管现有实时数仓有大量技术加持，其稳定性仍远不如 Spark 的 T+1 离线数仓。所以，目前大部分数据资产仍在离线进行 ETL 加工。
2025 年，小红书调研了增量计算，旨在寻找一套类似于 Snowflake 的架构，能够像处理离线数据一样处理实时数据，以减少成本。随后，小红书与云器科技共同探索了增量计算在真实业务场景中的应用，并定义了 Dynamic Table，其中包含所有 ETL 逻辑。这些 ETL 逻辑基本涵盖了当前 Spark 加工中涉及的常用算子，如 union、各类 join 等。在挑选小红书一些核心离线链路和实时链路进行验证后，得出以下结论：
从功能验证角度来看：一、将当前 Spark 作业改写为增量计算作业的成本不高，大量业务脚本可以直接复制使用；二、数据准确性验证通过；三、可以在新鲜度间隔与成本间做灵活调节。
从性能验证角度来看：一、在将整个时效性从 T+1 变为每 5 分钟刷新（fresh per 5 min）的状态下，纯增量表相比 Spark 离线性能还能提升 1~2 倍；二、在全量订单表更新场景下，成本基本能与 Spark 齐平；三、在实时汇总任务中，相对于传统 Flink 开发，其资源成本约为 Flink 的四分之一左右。
基于上述结论，小红书在真实业务场景中进行了落地实践并获得了有效反馈：
- 支持非结构化数据存储，高效分析：算法体系会涉及大量非结构化数据存储，且需要实现高效分析。小红书采用 Json Flatter 优化存储的压缩和查询性能，使 Json 不再以字符串形式存在，而是具体物化到列，极大优化了压缩和查询性能。
- 倒排索引优化，Date Skipping 效率提升 10 倍：在实验过程中，会将用户所有所处的实验组压缩成一个字段，一个用户可能参与上千个实验。如何快速索引到对应用户，以及聚合用户实验组下的所有用户指标，小红书采用了倒排索引进行优化，快速提升查询性能，整体效率提升了 10 倍。
- 一体化架构，链路更清晰，开发维护成本更低：用户行为分析平台覆盖产品需求，经营分析覆盖一线业务（包括运营、销售）需求。在算法方面，算法团队需要进行大量策略迭代实验来验证算法是否有效，这需要大量实时数据反馈，及时避免无效策略产生资损或流量损失。因此，算法团队对数据的时效性要求和指标覆盖度要求较高。这些需求基本上可以用离线的 Spark 在增量计算下进行复刻来快速支持。
增量计算业务已在社区、搜索、商业、电商等多个业务场景上线，成为算法同学日常工作的必备工具。相较于以前的实时链路，增量方案在投入 1800 core 的情况下能达到之前 5000 core 投入的计算能力；从整体开发成本上看，约等于当前 Spark T+1 的离线计算。
常用的计算模式横向对比如上图所示。从真实业务落地的视角来看，增量计算目前仍处于早期阶段，但其在分钟级延迟数据场景、资源消耗、开发成本以及数据更新频率上已达到较好平衡，预计在更多场景普及下，增量计算模式会有更多应用落地。
1.4 应用场景总结及展望
小红书的未来架构演变预计与业内发展方向趋同：一、流批一体，追求开发架构在生产中的落地；二、湖仓一体，湖仓一体在小红书内部已是相对成熟架构，但仍会持续探索如何在 Iceberg 下更快速地提升查询性能及降低数据实验成本；三、在 AI 体系下，如何让整个 Lakehouse 的数据能快速为用户提供分析建议，以发挥更大的数据价值。
2. 通用增量计算
2.1 什么是通用增量计算
在数据处理领域，有一个经典理论称为“数据不可能三角”，即企业不可能同时获得数据的新鲜度、成本和效能，现实中通常只能实现其中两者。根据此理论，诞生了批处理、流计算及交互分析这三种计算形态：批处理追求最佳成本，流计算追求最佳新鲜度，交互分析追求最佳查询性能。
由于数据不可能三角是客观存在且无法打破的，因此需要探索一套更好的架构。为此，产生了四个标准：一、统一的数据，即一份数据；二、统一的计算表达，即无论开发链路速度快慢，都通过一套 SQL 或 Python 代码进行开发；三、灵活的调节能力，通过配置满足不同时期不同业务需求，无需修改架构或调整代码；四、媲美当前各个平衡点最佳的性能，相对于老的组装式架构，拥有更高的性能。这些也是 Kappa 架构最终希望实现的目标。
数据不可能三角及其对应的架构理论是一套通用的处理理论，该架构理论在 AI 侧依然存在，而且 AI 的成本会更高，对时效性要求也可能更高。
奖章模型是近期海外非常流行的一套架构，该模型与数据维度建模中的 ods 层、dws 层有些相似，但核心差别在于奖章模型对数据做了更清晰的抽象。主要区别在于：一、在铜牌数据层，奖章模型认为数据应尽快进入数据存储层或数据湖中；二、在银牌数据层中，数据存储应使用最原始的格式，无论是照片还是 Json，都不要做任何结构化改造，只做数据整理和过滤，不做任何数据建模，因为一旦处理，数据最原始的内容可能丢失；三、在金牌数据层中，即业务层，则最终面向业务进行相关改造。
以 Snowflake 的 AI/ML pipeline 为例，Snowflake 处理的数据内容不再是表，而是文档、音频和视频。但无论处理何种内容，其架构流程都遵循一定的奖章模型规律，是一种面向数据+AI 的模型。在该 Snowflake 架构中，原始数据基本上是最原始的数据量，但中间的 extract 与奖章模型中的 filter, clean 不同，Snowflake 的 extract 可能是处理流程，而到了银牌层之后就变成面向表的格式，在金牌层也是同样的状态。
总结奖章架构的特点如下：首先是非常灵活。当前处于计算模型、AI 运算模型变化非常剧烈的状态，在这种状态下，不知道何时会用到原始数据，因此保留最初的原始数据层次非常关键。其次，随着模型向前推进，数据质量会越来越好，同时数据使用效率也越来越高。例如，在进行一套计算时，若已有 5000 张照片，在做数据提取时，一定要做向量检索提取，而不是每次请求来时重新进行一次照片向量化，这也是一个演进过程。最后，采用增量 ETL 的方式进行整个流程的演进，使流程的成本和时效性达到最佳，这也是增量计算受到欢迎的原因。
2.2 通用增量计算及 SPOT 标准
通用增量计算是一种同时面向高性能和低延迟优化的新计算模式，是继批处理、流计算和交互计算之后的第四代数据处理流程。它能完美满足 Kappa 架构设计，同时也能满足奖章模型的体系。同时，它是一个通用的分布式架构，不仅能支持关系计算，也能支持非关系计算，可支持多种语言。以上是增量计算的特性。
通用增量计算的 4 个标准（SPOT 标准）：
第一个标准 S：系统应能支持一套标准的全量数据表达，这里的全量意味着所有算子都要支持，不能部分算子支持增量，而另外部分算子不支持，这会给业务开发人员造成过高的成本。
第二个标准 P：系统要同时具备高性能和低成本。
第三个标准 O：系统要开放（Open），因为现在是数据+AI 的时代，需要双引擎，整个处理流程也需要具备开放的层次，以便不同的引擎能消费同样的数据。
第四个标准 T：系统能做到灵活调节（Tune）。即当业务需要调节时，不需要修改代码和系统。
基于以上标准，云器科技在增量计算方面也有一些落地实践。以小红书为例，该落地实现了三个三分之一的效益：第一、资源成本降低至之前的三分之一，显著减少了计算和存储冗余；第二、平台的组件数量降低到原来的三分之一，现在只需要一份存储和一个计算引擎；第三、开发成本降低到原来的三分之一，只需开发一套 pipeline 就能解决所有问题。
2.3 云器科技的实践
最佳实践的标准化设计：一套湖仓架构作为底盘，同时支持结构化和非结构化数据存储，中间支持基于增量的结构化和非结构化数据处理。结构化数据使用 SQL 表达和关系型表达，非结构化数据处理使用 AI function，最终生成统一知识库。知识库包含结构化数据的表、半非结构化数据的向量和标量索引，以及未来可能产生的更多索引。最后是面向 AI 的MCP server 和面向对话的接口。
