这是 AI 热潮中不为人知的软肋：模型光鲜亮丽，但底层管道却老旧不堪。
你搭建了最先进的 transformer 模型，拿下了 H100 GPU 集群，但随后却要等上 24 小时，让 ETL（Extract，Transform，Load）管道跑完，模型才能真正看见新的销售数据。等推理真正跑起来，客户早已流失。
这就是“数据摩擦税（Data Friction Tax）”，它正在吞噬 AI 的 ROI。
2025 年，行业终于开始修补底层管道。工程团队正从**数据仓库（Data Warehousing）时代，迈向统一数据平台（Unified Data Platforms）**时代，尤其是围绕“零拷贝（Zero-Copy）”理念构建的架构。如果你正在构建 AI 系统，就必须理解：为什么复制数据正在成为一种架构反模式。
问题的本质：为什么 ETL 难以扩展
要理解零拷贝为何重要，得先看看传统技术栈的低效之处。
在一家典型企业里，数据实际上分散在各个“引力井（gravity wells）”中——Salesforce 管 CRM，SAP 管 ERP，AWS S3 存日志。为了分析这些数据，工程师过去通常会搭建管道，把数据从源 A 物理复制到目标 B（通常是 Redshift 或 Snowflake 之类的数据仓库）。
这就带来了一个基本的延迟公式：
每一次复制数据，都会引入：
- 延迟：即“数据陈旧”问题。如果管道每晚跑一次，AI 就永远比现实慢 24 小时。
- 成本：企业要为重复数据支付额外的存储费用。存 1PB 尚可接受，但存 5 份（Raw、Bronze、Silver、Gold、Warehouse）就贵得离谱。
- 序列化开销：把 JSON/CSV 标准化成 Parquet/Avro（SerDes）所消耗的 CPU 成本，本可用于推理。
- 漂移：源 A 的 schema 发生变化（例如，开发者把
user_id重命名为uuid），导致通往目标 B 的管道崩溃。
Dataversity 警告称，源自这些脆弱管道的数据质量问题，可能导致未来一年内 60% 的 AI 项目被放弃。解决方案不是让管道更快，而是没有管道。
数据引力（Data Gravity）的演进
要想理解零拷贝革命，先梳理过去二十年数据架构的演变会很有帮助。整个行业在紧耦合与松耦合之间反复摇摆。
阶段一：单体架构（1990-2010）
最初是 Oracle Database。存储与计算紧耦合，想让查询更快，就买更大的机器。它一致性强、速度快（符合 ACID），但无法横向扩展，最终被 web 规模的数据量压垮。
阶段二：数据湖 / “沼泽”（2010-2018）
Hadoop 时代带来了 HDFS。其理念是“Schema on Read”：先把所有 JSON 日志丢进廉价存储，日后再说。这解决了存储成本问题，却造就了一片“沼泽”：查询性能极差，且缺乏事务导致数据完整性荡然无存。用这些数据训练的 AI 模型经常产生幻觉（hallucinate），因为输入数据要么缺失、要么充满噪声。
阶段三：云数据仓库（2018-2023）
Snowflake 和 BigQuery 把存储（S3/GCS）与计算分离。这是一大突破：存储可以无限扩展，计算集群可以按需启动。但格式仍然是专有的。要用 Snowflake，就必须执行 COPY INTO Snowflake。数据被锁在它们的 micro-partition 里，你仍然要移动字节。
阶段四：零拷贝 Lakehouse（2024+）
这是当前的拐点。数据留在 S3，但采用开放格式（如 Apache Iceberg）。计算引擎（Snowflake、Spark、Trino、Dremio）直接到数据所在的位置访问它。没有 COPY INTO，只有 SELECT * FROM。
技术深潜：零拷贝到底如何运作
“零拷贝（Zero-Copy）”其实是个误称。比特终究存在某块磁盘上。但从架构上看，它意味着系统不再把字节搬到计算侧，而是把计算权限带到字节旁边（更准确地说，是共享指针）。
现代的“开放表格式（Open Table Formats）”，如 Apache Iceberg、Delta Lake 和 Apache Hudi，正是这一切的赋能者。它们让不同计算引擎能够查看对象存储中的同一批文件，而无需“占有”它们。
元数据层
神奇之处发生在元数据层。零拷贝系统不是复制一张 10TB 的表，而是共享一份 manifest 文件：它是指向 S3 中 Parquet 文件列表的指针集合。
当工程师在 Snowflake 中“克隆”一个数据库，或在 Dremio Arctic 中创建一个分支时，系统并不会复制那 10TB 数据。它只复制元数据（仅千字节级别），并让它指向相同的底层存储块。
隔离机制：
零拷贝严重依赖快照隔离（Snapshot Isolation）。
- Manifest List 指向一个特定的“快照”（例如 Snapshot S1）。
- Snapshot S1 指向一组 Manifest Files。
- Manifest Files 指向真正的 Data Files（Parquet）。
当 AI 模型在 10:00 AM 开始训练时，它会锁定在 Snapshot S1。如果 10:05 AM 有一个 ETL 任务更新了这张表，它会创建 Snapshot S2（写入新的 Parquet 文件和新的 Manifest）。AI 模型不受干扰地继续读取 S1。没有锁，也没有读阻塞写。
查询下推优化：
分析引擎把过滤条件下推到源数据库。如果查询是 SELECT * WHERE region = 'Western-Region'，源系统会利用元数据找出哪些 micro-partition 包含 ‘Western-Region’ 数据，只返回这些特定数据块。与全表扫描相比，这能有效把网络传输量减少数个数量级。
“Unistore” 概念
零拷贝的终极目标是统一事务型（OLTP）与分析型（OLAP）工作负载，这个概念通常被称为 HTAP（Hybrid Transactional/Analytical Processing，混合事务/分析处理）。
Snowflake 的 Unistore 和 Databricks 的 Lakehouse 范式旨在弥合这一鸿沟。想象一个零售应用：一笔购买被写入事务型行存储。在传统世界里，这一行要到夜间批处理作业跑完才会出现在分析仓库中。而在零拷贝的 Unistore 世界里，通过统一的表抽象，分析引擎可以立即看到这一行。
对 AI 而言，这是颠覆性的。推荐系统可以在同一会话内就对用户的点击做出反应，而不必等到第二天。
2026 年的现实：“Living Ecosystems”
这种架构转变不只是为了节省磁盘空间，而是为了提升组织敏捷性。
**Slalom 的《2026 年金融服务展望》预测，行业将从“静态、孤立的解决方案”转向“活的、自适应的生态系统（living, adaptive ecosystems）”，数据在其中自由流动。他们认为统一数据基础（Unified Data Foundations）**是实现这一转变的前提。如果银行的欺诈检测 AI 还要等待夜间批处理，那它对 2026 年的实时威胁就毫无用处。报告强调，“治理同时赋能速度与信心（governance enables both speed and confidence）”，这意味着元数据层将成为新的控制平面。
McKinsey 的《Tech Trends》也印证了这一趋势，指出 AI 领域的“执行鸿沟（execution gap）”很大程度上是一个数据可用性问题。他们的分析显示，能够基于实时洞察采取行动的组织，实现两位数增长的可能性要高出 1.6 倍。能够“就地（in-place）”查询数据，意味着可以打造数据产品（Data Products），其他团队无需搭建新管道即可即时消费。
“Headless” 数据架构的崛起
2026 全年，分析师预计“Headless”数据架构将占据主导地位。在这种模式下，存储层和语义层与消费工具完全解耦。
- 存储：S3/Azure Blob（廉价、无限）。
- 格式：Iceberg/Delta（开放、事务化）。
- 目录：Nessie/Unity Catalog（追踪指针的“大脑”）。
- 计算：用户想用什么都行。数据科学家用 PySpark，分析师用 SQL，CEO 用 Dashboard。他们访问的都是同一个 Single Source of Truth。
结论：平台即管道
对数据工程师来说，技能栈正在转变。编写高效的 PySpark ETL 脚本把数据从 A 搬到 B，正不如设计稳健的元数据治理策略来得有价值。价值不在于移动数据，而在于让数据无需移动即可被访问。
传统意义上的管道已死，平台万岁。
资料来源 (5)
- engineering.salesforce.com Zero Copy Revolutionizes Data Cloud
- slalom.com Financial Services Outlook 2026
- dataversity.net Data Management Trends 2026
- mckinsey.com Top Trends in Tech 2025
- arcadia.io Zero-Copy Data Lake
🦋 Bluesky 讨论
在 Bluesky 上讨论