1. 小红书数据框架的演进
2. 通用增量计算概述
分享嘉宾｜马尔科（吴浩亮） 小红书 交易、基础数仓负责人
编辑整理｜Yuxiao
内容校对｜郭慧敏
出品社区｜DataFun
01
小红书数据框架的演进
在小红书 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 左右。
在小红书复杂的业务体系下，实现这样的查询性能是十分困难的。因此，在底层能力构建业务经营数据自助体系的基础上，2025 年小红书正在尝试向 AI 方向探索，将所有数据资产有机整合，构建自己的 BI 平台，具备逻辑视图和物化加速的能力。
在逻辑视图方面，收敛数据集数量，统一口径定义，降低理解成本，提升数据集在整体业务的覆盖，降低数仓 ETL 的加工成本，同时也会根据用户的查询做智能按需裁剪。
在物化加速方面，减少数据层。之前会在 dws 层后使用高度汇总层（app 层或汇总层），后来小红书通过搭建基于 dws 层的看板报表，识别用户 pattern，总结如何物化。这样，整体的汇总逻辑就不会冗余在汇总层和各种 App 层，而是精准落在 dws 层。得益于此，在日常用户使用报表时，看到指标卡上的数据，能够分享给其他用户，再快速下钻获得明细和所有下钻洞察。
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 的数据能快速给用户一些分析建议，以发挥更大的数据价值。
02
通用增量计算
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. 通用增量计算及 SPOT 标准
通用增量计算是一种同时面向高性能和低延迟优化的新计算模式，是继批处理、流计算和交互计算之后的第四代数据处理流程。它能完美满足 Kappa 架构设计，同时也能满足奖章模型的体系。同时，它是一个通用的分布式架构，不仅能支持关系计算，也能支持非关系计算，可以支持多种语言。以上是增量计算的特性。
通用增量计算的 4 个标准（SPOT 标准）：
第一个标准 S：系统应能支持一套标准的全量数据表达，这里的全量意味着所有算子都要支持，不能部分算子支持增量，而另外部分算子不支持，这会给业务开发人员造成过高的成本。
第二个标准 P：系统要同时具备高性能和低成本。
第三个标准 O：系统要 Open，因为现在是数据+AI 的时代，需要双引擎，整个处理流程也需要具备 open 的层次，以便不同的引擎能消费同样的数据。
第四个标准 T：系统能做到灵活的调节。即当业务需要调节时，不需要修改代码和系统。
基于以上标准，云器科技也有一些增量计算的落地。以小红书为例，该落地实现了三个三分之一：第一、资源成本降低至之前的三分之一，降低了大量计算冗余和存储冗余；第二、平台的组件数量降低到了原来的三分之一，现在只需要一份存储和一个计算引擎；第三、开发成本降低到原来的三分之一，只需开发一套 pipeline 就能解决所有问题。
3. 云器科技的实践
最佳实践的标准化设计：一套湖仓架构作为底盘，同时支持结构化和非结构化数据的存储，中间支持基于增量的结构化和非结构化数据的处理。结构化数据用 SQL 表达和关系型表达，非结构化数据处理用 AI function，最终生成统一知识库。知识库包含结构化数据的表、半非结构化数据的向量和标量索引，以及未来可能产生的更多索引。最后是面向 AI 的 MCP server 和面向对话的接口。
