1. 问题与动机
工业级 DLRM 的核心 scaling 维度已经从「特征数量」迁移到「用户行为序列长度」。论文 Section 2.2 指出：在工业 ranking 场景下，user interaction history (UIH) 序列特征已经"占据训练数据总量与读带宽的大头"；当用户序列被推到 4K 以上时，他们将其形象地称为撞上 "Fat Row Wall"——基础设施的需求开始反超模型质量带来的边际收益。
「Fat Row」是指现行业界默认范式：把每个 ranking 请求对应的完整 UIH 序列，提前物化进每条训练样本。问题在于一个 lookback 窗口内同一用户的历史会被在 K 条样本中复制 K 次（论文 Figure 2 给出量化结果：当开启超长 UIH 时，"数据支撑服务的总资源消耗已经超过 GPU 训练消耗本身"）。在多租户共享 union dataset 场景下问题被放大：召回模型只需要约 100 个事件，精排模型需要 10000+ 事件，但 union dataset 必须按最大需求装载，导致小模型也被迫读取大量自己用不到的数据。
这是 HSTU、ULTRA-HSTU 等下一代 trillion-parameter sequential transducer 架构能否真正 scale 的卡点：模型能学，但数据基础设施已经先撑不住。
2. 方法详解
整体方案是把存储中心化范式翻成"compute-centric late materialization"：UIH 只在归一化、不可变的存储里存一份，训练时用版本指针即时重建序列。
Versioned Late Materialization 协议（Section 3.3）：UIH 被双协议拆成 Mutable（近期事件）+ Immutable（长期历史）两层。推理时只记录极轻量的版本元数据 (start_ts, end_ts, sequence_length, checksum)，不再写完整序列。训练时通过"Time-Travel"过程，按记录的时间边界对不可变层做有界 range scan，将近期与历史两段拼接重建出训练用的 UIH。这套双协议保证了 streaming + batch 两种训练形态下的 O2O 一致性：物理 snapshot 阻断 mutable 端的迟到写入污染，bounded range scan 在 immutable 端排除了推理时点之后的事件，checksum 校验确认重建保真度。
可扩展 UIH 存储（Section 4.1）：mutable store 用快速 merge 操作 + blind-write append，且在排序服务侧加 write-through cache；immutable store 是只读优化的归一化仓库，每天通过离线 ETL 做 offload compaction，把分区合并为按时间排序的完整序列，单层 layout（避免多层 LSM 合并放大）。Schema 走"多维度投影"：以 (user_id, feature_group, subsequence_timestamp) 复合键组织，支持两种 pushdown——序列长度投影（只读模型需要的那段 stripe）与特征组投影（只读模型需要的列）。在编码层使用 trait-aware columnar encoding，针对时间戳走 delta 编码、类别元数据走 dictionary 压缩。
训练侧物化（Section 4.2）：用 Disaggregated Data Preprocessing (DPP) 把序列重建放到独立 preprocessing 集群，监控 GPU starvation 比例自动扩容；trainer 端做 rebatching 把小 base batch 合成完整训练 batch（带来 +15% 吞吐）。Latency masking 上用 pipelined I/O prefetch（预取下一 batch，+10% 吞吐）和 partial projection pushdown 把模型对序列长度/特征组的需求显式暴露给存储层。Data-affinity 优化：在 ingestion 阶段就按用户聚簇训练样本，使得同一 session 多条样本的 UIH 检索可以摊销；同时让主训练数据与 immutable storage 做对称分片，消除跨网络 fanout——两项合计批训练读带宽 −60%、单 worker 吞吐 +28%。
3. 核心技术贡献
1）Fat Row 问题的形式化：第一次量化论证"预物化序列冗余 > GPU 训练算力"的临界点（Section 2），把推荐训练数据基础设施从"工程后端话题"提升为决定模型能力上限的一等问题。
2）版本化晚物化协议：通过物理 snapshot + 有界 range scan + checksum 三重机制，在 streaming/batch 两种训练形态下都严格保证 O2O 一致性，杜绝了"future leakage"。这是过去基于"快照视图"或"时间窗对齐"的方案做不到的。
3）多租户感知的存储工程：单层 immutable layout 配合 (user, feature_group, ts) 多维投影，把召回（短序列）、精排（长序列）这种异质租户的 I/O 需求统一在一份共享数据上，每个租户只读自己需要的部分。论文报告 immutable storage 在单位 host 资源下实现 3.4× 的读吞吐，是这一切能 scale 的物理底座。
4）端到端 deployment：不仅设计协议与存储，还落地了 disaggregated preprocessing、pipelined prefetch、data-affinity sharding 三套训练侧加速，使整个 pipeline 在工业流量下真的跑得比 Fat Row 快。
4. 实验结果分析
系统效率（Table 1，3 个模型租户共享 union dataset）：主写带宽 −46.2%；长序列模型 A 主读带宽 −70.3%；序列查找带宽相对增加 +62.7%（这一项被新增），但因 immutable storage 单位资源吞吐高 3.4×，整体仍是净收益；模型 A 单 batch loading 延迟 +9.7%，而短序列模型 B、C 反而 −26.4% ~ −36.2%。这说明长序列租户付出可控的小延迟代价，换来短序列租户的显著加速。
模型质量（Figure 4 + Table 2）：在公平基线下，把 UIH 长度从 4K 推到 64K，Platform A 的 Normalized Entropy 累计提升 ~5%，仅 4K→64K 这段就 +1.2% NE；Platform B 4K→10K 提升 +0.65% NE。同时严格验证"晚物化重建出的序列在 256–4K 范围与 Fat Row 的 NE 持平"，证明它没有引入质量损失，只是放开了上限。
线上 A/B（Table 2）：Platform A（4K→16K）topline +0.22%、消费指标 +4.1%、互动指标最高 +4.3%；Platform B（4K→10K）topline +0.14%、消费 +0.79%、互动最高 +1.7%。文章直接给出工业语境下的注解："此规模下 1% NE 提升即被认为成功，这些收益在 Fat Row 范式下根本拿不到。"
值得注意的是 ablation 隐含的关键结论：把 latency masking + data-affinity 关掉后，长序列租户 batch 延迟增加得多得多，说明 disaggregated preprocessing 不只是工程加速，而是支撑长序列训练能跑起来的必要条件。
5. 局限与未来方向
文章未单独写 Limitations 节，但隐含承认几点：
- 整个方案严重依赖"读优化的 immutable 层吞吐显著高于主存储"，离开这种存储引擎的环境下复现需要重做底层；
- Latency masking 复杂度上升——需要额外的 preprocessing 集群、pipelined prefetch、affinity sharding 多重机制配合，长序列租户仍有 ~10% 单 batch 延迟；
- 每日 offload compaction pipeline 需要处理 right-to-delete（隐私合规）、schema 升级等运维问题，这些在论文里只是一笔带过；
- 多维投影 schema 设计复杂度高，需要存储引擎层面的工作量。
未明确讨论的现实问题：当训练任务非常多样、每个租户的特征组合都不同时，多维投影的 metadata 维护本身可能成为新的瓶颈。
6. 工业实践意义
这篇文章本质上是「下一代生成式/序列化推荐系统的训练基础设施蓝图」，对任何想 scale UIH 长度的团队都是必须读的工程手册。
直接可借鉴：
- 不要再 Fat Row。当用户序列预计要超过几千事件时，预物化范式必然撞墙，要从 day 1 就规划"用户行为只存一份"的 normalized 仓库 + 训练时 late materialization；
- 版本指针 + bounded scan 是 O2O 一致性的关键。社区/电商场景里"未来事件泄漏"问题极隐蔽，明确 (start_ts, end_ts, checksum) 协议能避免线上踩坑；
- 多租户共享数据集合。召回、粗排、精排原则上读一份用户事件流，通过 schema 投影 pushdown 各取所需，不要再为每个模型单独跑 ETL；
- 训练数据 pipeline 也要 disaggregate。把 GPU starvation 当成主要监控指标，独立 preprocessing 集群按需扩容，比堆 GPU 性价比高得多。
部署考量：immutable storage 引擎是核心选择题——Meta 内部用的是与 HBase/RocksDB 类似但深度定制的列存，自建团队短期内更现实的路径是用 Iceberg + Parquet 或 Hudi + ORC 起步，先把"normalize once + range-scan reconstruction"协议跑通，再迭代到 trait-aware 编码。计算端走 Spark / Ray Data 做 disaggregated preprocessing 也都跑得通。社区平台自己的尺度通常达不到 Meta 量级，但只要 UIH 长度过千，就值得现在就把这套范式打底，否则未来任何"长序列实验"都会被基础设施先封死。