导读：

小红书App是一个聚焦年轻人的生活兴趣社区，每月约有超过4亿人在小红书中分享生活和兴趣爱好。小红书围绕“社区+电商+商业化”为核心，通过UGC内容驱动“种草-拔草”的业务闭环，不断提升APP用户规模和用户粘性，与此同时，日志规模达到日均几千亿，并由此催生了大量的实时、离线的数据需求。

本文与大家分享在Big AI Data时代下，小红书的数据架构的演进，目前基于新一代通用增量计算替换现有Lambda架构，实现架构复杂度降低1/3，资源成本降低到1/3、开发成本降低到1/3。 并介绍了增量计算的定义与标准。

本文围绕下面内容展开：

• 第一部分：小红书数据框架的演进
  • 小红书业务及数据概览
  • 数据架构的演进迭代
  • 新一代增量计算应用场景总结及展望
• 第二部分：通用增量计算概述

小红书数据框架的演进

在小红书APP中，用户可以浏览社区笔记、与朋友进行互动、可以观看直播，也可以在商城购买商品，而这些都是强数据驱动的业务。小红书用户的体量以及其业务复杂度超高，因此对其数据平台对应的数据能力有着比较大的挑战。

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

目前，小红书的整体数据平台是采用业界通用的数仓标准和建模方式来进行维护管理的，包括但不限于自建的调度平台、运维平台、资产管理平台、治理平台、报表平台等一系列产品型工具能力，共同辅助数据资产在企业中发挥更大的价值。其中，价值输出主要分为四类：

第一类是数据分析 。例如支持面向高管的报表、支持一线运营及销售的自助分析产品；

第二类是数据产品 。例如小红书面向广告主、商家、博主、内部需求方的数据平台；

第三类是数据服务 。例如提供给推荐、搜索、算法团队的用户画像以及特征标签等；

第四类是AI相关 。例如使用AI来帮助用户更轻量地获取数据洞察、生成数据报告和给出经营建议等。

2024年，小红书的基础设施层从AWS迁移至阿里云，迁移数据500PB，任务11万，参与人数1500人，涉及部门40多个，整体的迁移和改造的复杂度创下了业界记录。截至目前，小红书已有部分业务在自建云上试跑，未来将向混合云架构发展。

2. 数据架构的演进迭代

从小红书的视角来看，让数据在企业内部发挥更大价值的关键是极致的效率。这涉及到一个重要命题：企业的高管和一线人员（包括运营和销售团队）都需要学会使用数据。提高数据的使用渗透率是数据在企业内部发挥更大价值的前提。为此，小红书进行了四次数据架构的迭代，以降低数据的获取成本、提高使用效率、以及降低数据对业务同学的门槛。

1.0的数据架构是基于ClickHouse的即席分析。此时架构相对简单，主要是离线数仓将数据宽表加工后加载到ClickHouse中，供运营团队获取数据。与原始数据架构相比，Spark SQL的响应速度从分钟级提升到了ClickHouse的秒级。然而，该架构也存在明显缺点：

• 成本高 。ClickHouse集群的搭建成本较高（包括资源成本），其对CPU和内存的要求较高；
• 扩容难 。因为ClickHouse是存算一体的架构，在业务快速扩张时，扩容会面临数据搬迁的问题；
• 数据时效性差 。因为数据是通过Spark T+1加工后再导入到ClickHouse，期间存在数据搬迁的时间成本，这导致业务人员获取数据可能已不具备时效性。

针对1.0数据架构的痛点，小红书基于开源社区的ClickHouse，开发了存算分离的Lambda数据架构。

在2.0的数据架构中，小红书实现了把ClickHouse本身的MergeTree File同步到对象存储以及本地的SSD存储中。很好地扩展了ClickHouse能够查询的数据时间范围，也极大地降低了数据成本。

同时，在2.0的数据架构中，也引入了Lambda架构，将Flink生产的实时数仓数据和Spark生产的离线数仓数据，以ClickHouse作为中心节点进行合并后提供给业务，实现了天级别到实时数据的指标洞察。此外，小红书还利用ClickHouse的多类型关联、物化视图以及索引加速能力，优化了用户查询和获取数据的效率。

小红书App的迭代速度非常快，需要对应的产品团队快速地进行数据洞察。因此需要将小红书App内发生的所有用户行为日志，经过Flink加工后同步到ClickHouse中。目前，每天大约有6000亿条数据量会同步进入ClickHouse，同时也会同步用户笔记的画像、标签等数据，以便进行联合分析。

由于涉及的用户数据体量非常大，因此查询性能的优化是急需解决的问题。普通分析至少需要查看7天或14天的数据，涉及近10万亿规模数据，且需要10s级的响应，这是一个非常巨大的技术挑战。因此，小红书的团队对此进行了非常多的性能优化，这里从中挑选一些优化点进行说明。

• 按照用户进行分桶，ClickHouse做local join，以满足用户特征和行为分析的工作；
• 通过抽象所有日志中的可枚举字段创建物化视图，70%的用户查询都能命中物化视图，将6000亿日增的数据压缩到200亿左右；
• 构建灵活的索引以优化具体查询场景，例如，根据用户ID构建BloomFilter索引，以快速获取某个用户的具体行为。

此时，小红书的数据平台已经实现了秒级的分析能力，支持万亿级数据规模的10s内响应，为内部200+产品提供自助能力，不再需要向业务数据部门提数据需求来获取数据洞察。

随着业务发展，大量业务数据资产仍存在于数据仓库中。2.0的架构面临三个问题：首先是存在两套数据存储。数仓是存在对象存储上，而ClickHouse文件是以MergeTree形式存储在ClickHouse中，这两套存储会增加存储成本和数据不一致的风险。其次，两套计算框架。Flink和Spark在计算语义上有所差异，生产环境中的实现代码也不同，这可能导致整体指标质量存在问题。另外，ClickHouse缺少ETL能力。写入ClickHouse的数据意味着数据终点，不像流式数据可以在Kafka之间流转进行增量消费。以上三个痛点形成了3.0架构需要解决的问题。

小红书的对应解决方案是采用Lakehouse，基于湖上建仓（Lakehouse）架构来整合数据湖和数据仓库的优势。Flink负责日志处理及入湖，Iceberg存储数据，Spark运行任务，StarRocks进行作业查询。从数仓加工出的数据，如dws宽表，由StarRocks进行快速T+1分析。若需进行实时数据探查，可直接使用ods中的Iceberg数据。

优化查询性能仍然是3.0架构的重中之重。小红书希望用户query进入平台后能够获得秒级响应，因此，分析了过去遇到的问题，发现在业务变化较快的背景下，表的schema迭代快，用户命中预先设计的索引概率在降低，随时间推移，索引也在逐渐失效，这导致之后需要将所有数据都进行全表扫描。在Lakehouse架构下，小红书启动了自动Z-Order排序、智能排序以查询性能优化。主要逻辑相对简单，即收集StarRocks日常用户的query，总结出当前业务常用筛选经验，智能感测当前索引与用户真实查询的差异，识别后，在Iceberg数据入湖后启动异步作业，进行Z-Order data file的rewrite，如此能保证80%~90%的用户查询命中Z-Order排序。对比优化前后的效果，优化前单表query查询约是5.5TB+，而经过优化，扫描数据量可迅速缩减为600GB+，约有10倍提升。

除此之外，小红书还进行了其他方面的诸多优化，综合下来，得益于排序键和数据分布等方面的优化，在湖上存储的压缩率相比ClickHouse提高了1倍，而在查询性能方面，采用3.0存算分离架构后，整体查询性能相比以前ClickHouse优化了3倍，加上local cache的加持，基本上能保证P90查询时延在5s左右。

3.0 Lakehouse的收益

首先，3.0的架构上线后，已基本覆盖业务体系的核心场景。小红书追求的目标是所有一线业务用户的渗透达到70%，这可能是AI在企业内部加速数据使用的一个门槛，因为如果没人用数据，AI就更不会有人用。

其次，官方数据集收敛到了300个，覆盖了核心分析场景。基于目前AI能力和底座能力情况，如果AI面对的是数百PB级数据量的情况下，让AI去理解所有数据资产并给出准确答案是不切实际的，因此要做减法，把范围缩小到足够小，把数据资产和业务标签做得足够精，来让AI给出更准确的答案，在生产中给出真正的好建议。

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

在2024年小红书已经基本完成了湖仓体系的整体演进，但依然面临着问题，即在湖仓体系架构下，如何提升数据时效性。

在构建实时数仓时，一般情况下一个实时任务的开发成本是离线任务的三倍，且后续会持续面临数据回刷、资源锁定、任务稳定性、带状态恢复等问题。因此，尽管现在的实时数仓有大量技术加持，但仍然远远没有Spark的T+1离线数仓稳定。所以，目前大部分数据资产仍在离线进行ETL加工。

2025年，小红书进行了增量计算的调研，以找寻一套类似于Snowflake的架构，能够让实时数据和离线数据一样处理，以减少成本。之后与云器科技一起探索了增量计算在真实业务场景中的应用，定义了Dynamic Table，包含所有的ETL逻辑，这些ETL逻辑基本涵盖了当前Spark加工中涉及的常用算子，如union、各类join等。在挑选了小红书的一些核心离线链路和实时链路进行验证后，得到的结论是：

从功能验证 角度来看：

• 将当前Spark作业改写为增量计算作业的成本不高，大量业务脚本可以直接复制使用；
• 数据准确性验证通过；
• 可以在freshness间隔与成本间做灵活调节。

从性能验证 角度来看：

• 在将整个时效性从T+1变成fresh per 5 min的状态下，纯增量表相比Spark离线性能还能提升1~2倍；
• 在全量订单表更新的场景下，成本基本能与Spark齐平；
• 在实时汇总任务中，相对于传统的Flink开发，其资源成本约为Flink的四分之一左右。

基于以上的结论，小红书在真实业务场景中做了一定的落地并得到有效反馈：

• 支持非结构化数据存储，高效分析。算法体系会涉及大量非结构化数据的存储，且需要实现高效的分析。在此，小红书采用了 Json Flatter来优化存储的压缩和查询性能，使Json不再以字符串形式存在，而是具体物化到列，这能极大优化压缩性能和查询性能。

• 倒排序引优化，Date Skipping效率提升10倍。在实验过程中会将用户所有所处的实验组压缩成一个字段，一个用户可能参与上千个实验，如何快速索引到对应用户，以及聚合用户实验组下的所有用户指标，小红书采用了倒排索引进行优化，快速提升查询性能，整体效率提升了10倍。

• 一体化的架构，让整个链路更清晰，开发维护成本更低。在用户行为分析平台覆盖了产品需求，经营分析覆盖了一线业务，包括运营、销售的需求，而在算法方面，算法团队需要进行大量的策略迭代实验来验证算法是否有效。在这个过程中，需要大量的实时数据来反馈，及时避免一些无效策略产生资损或流量损失。因此，算法团队对数据的时效性要求较高，对指标的覆盖度要求也较高。而这些需求则也是可以基本上用离线的Spark在增量计算下进行复刻来快速支持的。

增量计算业务已上线社区、搜索、商业、电商等多个业务场景，成为算法同学日常工作必备工具。相较于以前的实时链路，增量方案能够在投入1800core的情况下达到之前5000core投入的计算；从整体开发成本上看，约等于现在的Spark T+1 的离线计算。

将一些常用的计算模式进行横向对比，具体如上图。从真实业务落地的视角来看，现在增量计算还处于早期阶段，但增量计算在分钟级延迟的数据场景、资源消耗、开发成本以及数据更新频率上已达到较好平衡，预计在更多场景普及下，增量计算模式也会有更多应用落地。

3. 应用场景总结及展望

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

• 流批一体，追求开发架构在生产中的落地； • 湖仓一体，湖仓一体在小红书内部已是相对成熟架构，但仍然会不停地探索在Iceberg下如何更快速地提升查询性能，以及降低数据实验成本； • 在AI体系下，如何让整个Lake House的数据能快速给用户一些分析建议，以发挥更大的数据价值。

通用增量计算

什么是通用增量计算

在数据处理领域，有一个经典理论叫数据的不可能三角，即企业不可能同时获得数据的新鲜度、成本和效能，而现实中一般只能得到其中两个，而无法三者全部获得。根据数据的不可能三角理论，诞生了批、流及交互这三种计算形态：批处理面向最好的成本，流计算面向最好的新鲜度，交互分析面向最好的查询性能。

由于数据的不可能三角是客观存在且无法被打破的，因此需要探索一套更好的架构，为此产生了四个标准：

• 统一的数据，即一份数据；
• 统一的计算表达，即不论开发链路速度快慢，只通过一套SQL或Python代码进行开发；
• 灵活的调节能力，通过配置进行以满足不同时期不同业务的需求，而不需要修改架构或调整代码；
• 媲美当前各个平衡点最好的性能，相对于老的组装式架构，拥有更高的性能。而这些也是Kappa架构最终希望实现的目标。

数据的不可能三角以及对应的架构理论是一套通用的处理理论，该架构理论在AI侧依然存在，而且AI的成本会更高，对时效性要求也可能更高。

奖章模型是最近海外非常流行的一套架构，该模型有些像数据维度建模中的ods层、dws层，但核心差别在于奖章模型对数据做了更清晰的抽象。

主要区别是：

• 在铜牌数据层，奖章模型认为数据应尽快进入数据存储层或数据湖中；
• 在银牌数据层中，数据存储应使用最原始的格式，无论是照片还是Json，都不要做任何的结构化改造，只做数据的整理和过滤，不做任何的数据建模，因为一旦做了处理，数据最原始的内容就可能丢失；
• 在金牌数据层中，也就是业务层，则会最终面向业务进行相关的改造。

以Snowflake的AI/ML pipeline为例，Snowflake处理数据的内容不再是表，而是文档、音频和视频，但无论处理何种内容，其架构流程都遵循一定的奖章模型规律，是面向数据+AI的模型。在这个Snowflake的架构里面，其原始数据基本上是最原始的数据量，但中间的extract与奖章模型中的filter,clean不同，Snowflake的extract可能是处理流程，而到了银牌层之后就变成面向表的格式，在金牌层也是同样的状态。

总结奖章架构的特点如下：首先是非常灵活。现在处于计算模型、AI运算模型变化非常剧烈的状态，在这种状态下，是不知道何时会用到原始数据的，所以保留最初的原始数据层次非常关键。其次，随着模型向前推进，数据质量会越来越好，同时数据使用效率也越来越高。例如，在做一套计算时，已有5000张照片，在做数据提取时，一定要做向量检索提取，而不是每次请求来时重新做一次照片向量化，这也是一个演进过程。最后、使用增量ETL的方式做整个流程的演进，使流程的成本和时效性达到最好，这也是增量计算受到欢迎的原因。

通用增量计算及SPOT标准

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

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

第一个标准S：系统应能支持一套标准的全量数据表达，这里的全量意味着所有算子都要支持，不能部分算子支持增量，而另外部分算子不支持，这会给业务开发人员造成过高的成本。

第二个标准P：系统要同时具备高性能和低成本。

第三个标准O：系统要Open，因为现在是数据+AI的时代，需要双引擎，整个处理流程也需要具备open的层次，以便不同的引擎能消费同样的数据。

第四个标准T：系统能做到灵活的调节。即当业务需要调节时，不需要修改代码和系统。

基于以上标准，云器科技也有一些增量计算的落地。以小红书为例，该落地实现了三个三分之一：

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

云器科技的实践

最佳实践的标准化设计：一套湖仓架构作为底盘，同时支持结构化和非结构化数据的存储，中间支持基于增量的结构化和非结构化数据的处理。结构化数据用SQL表达和关系型表达，非结构化数据处理用AI function，最终生成统一知识库。知识库包含结构化数据的表、半非结构化数据的向量和标量索引，以及未来可能产生的更多索引。最后是面向AI的MCP server和面向对话的接口。

以上就是本次分享的全部内容，完整版会议材料可通过下方链接获取：https://yunqi.tech/resource/event/event_generic_incremental_compute_da2025.pdf

🎁 新用户专享福利

✅  1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验

➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package