2026-03-28 过程文档 #15 — Pinterest 基础设施与 ML 平台演化¶
关联报告： 2026-03-28_pinterest技术演化调研.md
调研时间： 2026-03-28
信源主力： Pinterest Engineering Blog (Medium), High Scalability
搜索过程¶
- 搜索：
Pinterest engineering blog technical evolution architecture history 2013 2024 - 搜索：
Pinterest "building a dynamic and responsive" 2015 architecture migration - 搜索：
Pinterest Apache Pinot open source origin story - Fetch：
medium.com/pinterest-engineering/a-decade-of-ai-platform-at-pinterest-4e3b37c0f758✅ 全文获取 - Fetch：
highscalability.com/scaling-pinterest✅ 全文获取 - Fetch：
medium.com/pinterest-engineering/building-a-dynamic-and-responsive-pinterest✅ 全文获取
发现与分析¶
阶段一：早期架构混战与返璞归真（2010–2014）¶
信源： High Scalability 转载 Pinterest 工程师 Marty Weiner 文章 [B级] URL： https://highscalability.com/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a/
事实： - 2010年3月上线，Rackspace 单机，Python + MySQL - 2011年1月：迁移 AWS，2名工程师，加 MongoDB（计数器） - 2011年中（"实验危机"）：每月翻倍增长，乱加技术 → Cassandra + Membase + Redis + Memcache + Elasticsearch + MongoDB 并存，各自在压力下以不同方式崩溃 - 2012年1月（"成熟转折"）：只保留 MySQL（分片）+ Redis + Memcache + Solr，删除 Cassandra/MongoDB/Elasticsearch
分析（边搜边写）： Pinterest的早期教训是教科书级的：技术多样性在初创阶段看似灵活，实则在高速增长下制造多个独立故障点。他们的解法不是更好的分布式，而是选择成熟工具+水平扩展。2012年这次"减法"让他们用了同样的技术栈撑到了数亿MAU。
引用："Architecture is doing the right thing when growth can be handled by adding more of the same stuff."（同一类型机器横向扩，而不是换技术）
到2012年规模： 180台Web Engine, 240台API Engine, 88个MySQL分片——全部靠横向扩展实现。
阶段二：从静态预生成到实时动态架构（2015）¶
信源： Pinterest Engineering Blog, "Building a dynamic and responsive Pinterest" [A级] URL： https://medium.com/pinterest-engineering/building-a-dynamic-and-responsive-pinterest-7d410e99f0a9
事实： - 2015年时后端大部分是 Java；内容是预生成存在 HBase，用户登录时直接 serve - 问题：特征可能是数周前的；每个用户的内容必须提前计算（包括不活跃用户）；多个实验并行会复制存储，成本"巨大" - 解决：构建9个实时系统，在请求时动态获取和打分
9个系统： | 系统 | 职责 | |------|------| | Apiary | 用户→Board 实时映射 | | Polaris | Board→Pin 映射 + 过滤 | | RealPin | 可定制对象实时检索 | | Aperture | 曝光历史追踪 | | Scorpion | 统一ML排名引擎 | | Counter service | 计数信号聚合 | | Rockstore | 特征数据存储 | | Pixie | 图算法推荐（Board级） | | Feed Generator | 整体编排层 |
分析： Scorpion 在此阶段首次出现，定位是"统一ML排名平台"。这是Pinterest ML基础设施的起点——从此以后所有排名场景都复用这个引擎，也是后来2022年GPU化改造的前身。
阶段三：ML 平台十年演化（2014–2025）¶
信源： Pinterest Engineering Blog, "A Decade of AI Platform at Pinterest" [A级] URL： https://medium.com/pinterest-engineering/a-decade-of-ai-platform-at-pinterest-4e3b37c0f758
完整分期：
3.1 各团队各自为政（2014–2017）¶
- Home Feed、Related Pins、Ads 团队各自维护独立训练/推理栈（scikit-learn、xgboost、LightGBM、Vowpal Wabbit）
- 出现"training-serving skew"：线上线下特征处理不一致导致性能意外下降
- Linchpin DSL（2015）： Home Feed 工程师建的领域专用语言，统一特征变换 + 模型实现，用 Thrift 数据结构。成功，但遇到复杂数据源时需要自定义 C++，脆弱
- Scorpion（2016–2017）： C++ 推理服务，与缓存 Pin 数据共置，实现"每次请求评分数千 Pin"的效率
- 2017年底：组建两人 ML 平台团队
分析： 组织原因驱动技术碎片化——每个产品团队优化自己的engagement指标，天然不会投资跨团队基础设施。直到 ML 被认定为公司级增长杠杆，平台才有组织理由存在。
3.2 小团队证明价值（2018–2019）¶
- EzFlow（2018）： 代码优先的训练编排工具（DAG + 依赖去重缓存）。技术上解决了问题，但采用滞后——工程师宁愿维护旧栈，因为切换不影响产品指标
- Galaxy： 将大型 Hadoop 任务拆解为模块化的用户/Board/Pin 信号，各团队自持
- 早期训练平台： 轻量级 Kubernetes + TensorFlow + 超参调优
- 关键教训："Adoption follows alignment"——解决技术痛点不等于有人用，需要组织激励对齐
3.3 DNN 突破与统一表示（2019–2020）¶
- AutoML（2019–2020）： Home Feed 团队自动化 DNN 配置，效果"engagement 大幅提升，新 DNN 快速上线"。但强绑 Home Feed 的 Thrift 数据结构，Ads 要用必须 fork，无法推广
- Unified Feature Representation (UFR)（2020）： 平台团队的回应——单一容器可转化为 TF/PyTorch 张量，支持手工特征和原始输入。类似 Twitter DataRecord、Facebook FBLearner schema。让 Linchpin 可以被废弃（特征变换移入模型内部）
3.4 大规模标准化与组织升级（2021–2022）¶
- MLEnv（2021）： 统一构建+运行时栈（Monorepo, Docker, CI/CD, TF+PyTorch）。一年内使用率从 <5% → ~95%
- 随后 PyTorch 成为唯一标准（"momentum 和开发者体验明显领先"）
- TabularML（2021–2022）： 列式 Parquet 格式统一训练数据集。存储成本减半，特征回填速度翻倍
- ML Dataset Store： 管理 TabularML 数据集（回填、标签迭代、成本追踪、访问控制）
- ML Foundations： 跨 Ads/Core/ML Platform 协调投资的组织机制
- ML Scorecard： 对主要 ML 产品在数据/训练/部署/监控维度打分，让 ML 速度成为组织级可追踪指标
分析： 2021年是转折点。ML 被确认为"最大增长杠杆也是最大瓶颈"，VP 级认可让基础设施工作脱离"painful but not critical"象限。MLEnv <5%→95% 的采用曲线证明：当激励和痛点同时上升时，采用会加速。
3.5 GPU 时代的 Scaling（2022–2025）¶
GPU Serving 突破（2022–2023）： - 问题：CPU serving 无法支撑实时 Transformer 模型的延迟/成本 - Scorpion GPU 重建：SSD 缓存合并、最小化 CPU-GPU 切换、动态 batch、自定义 CUDA 运算、半精度推理 - 结果：Homefeed 参与度 +16%，同时实现 100× 更大的架构而不增加成本和延迟
关联系统： - Remote Inference： CPU/内存密集任务（数据获取）与 GPU 计算分离，独立扩容 - Ray for Training： 分布式 CPU 集群实时预处理训练数据→流入 GPU 训练器，跳过重度 Spark 预处理 - Model Farm： 不同 host 服务不同模型子集，应对实验模型 GPU 内存限制 - Kubernetes 迁移： 改善集群启动速度和批量整合效率
大规模 ID Embedding（2023）： - 预训练 Embedding 捕获整体模式，但缺乏细粒度行为细节 - 引入十亿参数 ID Embedding 表，在训练中持续更新 - 解法：分布式模型并行训练（跨 GPU 分片）+ 混合 CPU/GPU serving（高内存 CPU 存 embedding，GPU 执行推理）+ INT4 量化 - 覆盖 Related Pins、Homefeed、Ads
长用户序列（2024）： - 从数百个最近动作 → 16k+ 用户动作（跨越数年） - 解法：请求级去重（大序列处理一次，共享给数千候选打分）+ 稀疏张量处理 + Triton 自定义 GPU kernel - 平台工程师开始需要理解 Transformer 内部结构（attention机制）才能优化——平台与模型边界模糊化
Foundation Ranking Models（2025）： - ATG 团队：跨所有用户 surface 行为预训练共享模型，再按场景微调 - 复用 2023 混合 CPU/GPU 架构 + 2024 量化技术
3.6 LLM 与生成式 AI（2024–现在）¶
不同于推荐系统的压力：大算力 + 低QPS，需要 KV caching、prompt 管理、动态控制流、更紧密的研究-生产循环。
信源记录¶
| 信源 | URL | 级别 | 日期 | 要点 |
|---|---|---|---|---|
| Pinterest Eng Blog — A Decade of AI Platform | https://medium.com/pinterest-engineering/a-decade-of-ai-platform-at-pinterest-4e3b37c0f758 | A | 2025 | ML平台十年完整复盘，系统、数字、教训俱全 |
| High Scalability — Scaling Pinterest | https://highscalability.com/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a/ | B | 2012 | 早期架构危机与返璞归真 |
| Pinterest Eng Blog — Dynamic Pinterest | https://medium.com/pinterest-engineering/building-a-dynamic-and-responsive-pinterest-7d410e99f0a9 | A | 2015 | 9个实时系统替换预生成内容架构 |
遗留问题¶
- Scorpion 2015版本 vs 2022 GPU重建版 的具体指标对比没有完整数据
- Galaxy → 现代 Feature Store 的完整迁移路径不清晰
- Pinterest 是否用了 Apache Pinot？（注：Pinot 起源于 LinkedIn，非 Pinterest）