필사 모드: 如何解读 2026 年的数据工具地形图 —— 不是工具清单，而是分层决策

• 引言 —— 一张 51 赞的地图，以及地图不会替你决定的事
• 五个层次，以及每层真正的决策
• 采集 —— 决定因素不是连接器，而是所有权
• 存储 —— 格式之争已经结束，战场转移到了目录
• 转换与编排 —— 编译器该放在哪里，以及失败处理模型
• 边界正在松动的地方 —— 计算被拉回本地
• 市场正在向哪里合并
• 真正决定工具选择的六个问题
• 结语 —— 地形会变，问题会留下来
• 参考资料

引言 —— 一张 51 赞的地图，以及地图不会替你决定的事

2026 年 7 月 28 日，面向开发者的数据工具地形指南 登上 GeekNews，获得 51 点赞。原文 面向刚踏入数据领域的软件开发者，完整地走了一遍从采集到存储、处理、编排、消费、治理的全流程。文件格式(CSV、Parquet、ORC、Avro、Arrow)、数据仓库与数据湖与湖仓一体、采集工具(Fivetran、Airbyte、dlt、Debezium)、转换(dbt、SQLMesh)、分布式处理(Spark、Dask、Ray、Flink)、编排(Airflow、Dagster、Prefect)、勋章架构(medallion architecture)、语义层与目录、BI 工具 —— 作为一份清单，内容相当扎实。

这是一张好地图。可地图不会替你选目的地。这个领域真正的难点并不是"该选 Airbyte 还是 Fivetran"，而是在不清楚自己在这一层实际做的是哪项决策的情况下就去选工具。于是六个月后，你在同一层又纠结了一遍同样的问题。

本文重新绘制同一片地形，但在每一层不再罗列工具名称，而是立起决策的轴线。并指出截至 2026 年，这些轴线正在哪些地方开始松动。

五个层次，以及每层真正的决策

划分层次的方式有很多种，但按"决策性质发生变化"的节点来切，正好是五层。

第三列就是本文的全部要点。工具名称三年一换，但那些问题不变。下面逐一展开。

采集 —— 决定因素不是连接器，而是所有权

在采集这一层，人们通常比较的是连接器数量和价格。而实际分出高下的，是另一条轴线。

连接器是自己维护，还是交给别人。 Salesforce、Stripe 这类 SaaS API 会毫无预警地改动 schema、悄悄收紧速率限制、某天突然换掉分页方式。托管式采集服务的价值不在连接器本身，而在于有人替你去追踪这些变化。反过来，如果数据源只是内部的几个 Postgres 实例，那这份人力成本本就不需要购买，此时托管服务按行计费就是纯粹的浪费。

是否需要变更数据捕获(CDC)。 批量重读全量数据，和只读取 WAL 中的变更并流式传输，运维负担完全不在一个量级。Debezium 一类的 CDC 需要在源数据库上占用一个逻辑复制槽，一旦这个槽位滞后，源数据库的磁盘就会被撑满 —— 也就是说，采集流水线的故障会蔓延成生产数据库的故障。是否值得为新鲜度冒这个风险，才是真正的决策所在。

抽取出来的数据 schema 由谁来定义。 原样复制源 schema(ELT 的默认做法)启动快，但只要源团队删掉一个字段，下游就会整体崩溃。明确约定契约的方式更慢，但破坏会止步于采集这个环节。组织规模决定了这个选择 —— 源团队和数据团队坐在同一间办公室，前者就够用；分属不同部门，就需要后者。

用 Python 库直接写流水线(dlt 一类)这条路线最近势头见涨，原因也在这里。这是一种中间地带 —— 连接器自己拥有，但把样板代码交给库去处理，数据源在 10 个以内时，通常是最便宜的方案。

存储 —— 格式之争已经结束，战场转移到了目录

过去这些年，这一层的问题一直是"用 Iceberg、Delta 还是 Hudi"。截至 2026 年，这个问题基本已经有了定论。

Iceberg v3 规范在 2025 年年中获得批准，经过 1.10~1.11 这条发布线，陆续加入了删除向量(deletion vectors)、面向半结构化数据的 variant 类型、行血缘(row lineage)和地理空间类型。Snowflake、Databricks、Amazon S3 Tables 都已宣布 v3 支持进入 GA。这里的关键在于，v3 吸收的这些功能原本正是 Delta Lake 的差异化优势。删除向量和行血缘进入 Iceberg 之后，"要性能还是要互操作性"这个选择题本身就消失了。Databricks 更进一步，为 Iceberg v4 提出了自适应元数据树，并表示 Delta 5.0 也会采用同样的结构。方向是收敛。

格式一旦收敛，锁定会去哪里 —— 目录(catalog)。这是一项服务，负责告诉你有哪些表存在、它们最新的元数据文件在哪里，访问控制、审计和凭证发放都挂在这一层上。Iceberg REST catalog 规范已经成为事实上的接口，Apache Polaris、Unity Catalog、AWS Glue，以及各家云厂商自己的实现都在这之上展开竞争。

而目录这一层目前还参差不齐。v3 的功能要经由 catalog API 才能进来，但并非所有目录都支持创建 v3 表 —— 截至 2026 年年中，据报告 AWS Glue 无法通过 REST 的 CreateTable 路径创建 v3 表(引擎侧或许能处理)。也就是说，"我们在用 Iceberg"这句话已经不再是一个充分的描述了。真正该问的问题是：

• 用的是哪个目录，换成另一个目录时数据要不要重写
• 自己的引擎(Spark、Trino、DuckDB、各家仓库)能不能接入该目录的 REST 实现
• 拥有写权限的引擎有几个 —— 如果不止一个，谁来保证并发写入冲突的处理

有一种方法可以用手而不是用嘴来验证这三点 —— 换一个不是厂商自家控制台的工具，去读同一张表。 半小时就能搞定，也是对"开放"这一说法最诚实的检验。

-- 从 DuckDB 直接连接 REST 目录。
-- 如果不经过仓库自家的控制台就能做到这一点，说明这张表确实是开放的。
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

CREATE SECRET catalog_auth (
    TYPE ICEBERG,
    CLIENT_ID     'svc-analytics',
    CLIENT_SECRET 'redacted'
);

ATTACH 'my_warehouse' AS lake (
    TYPE ICEBERG,
    ENDPOINT 'https://catalog.internal.example.com/api/catalog'
);

SHOW ALL TABLES;
SELECT count(*) FROM lake.analytics.orders WHERE order_date >= DATE '2026-07-01';

-- 如果能看到快照历史，时间旅行和回滚也就属于你了
SELECT * FROM iceberg_snapshots('lake.analytics.orders');

# 不经过目录，只看对象存储本身，表结构是否依然完整可辨
aws s3 ls s3://lake-prod/analytics/orders/metadata/ --human-readable | tail -5
# 如果能看到 v00042-....metadata.json 和 snap-....avro
# 说明就算换掉目录，数据依然原样留在那里

行血缘这类 v3 新增功能实际上是如何存储、又保证了什么，我们在Iceberg v3 行血缘 —— 行 ID 并不存储在文件里一文中单独整理过。

与此同时，这一层还有来自另一个方向的挑战者。DuckDB 基金会打造的 DuckLake 不用文件树来管理元数据，而是把它放进一个 SQL 数据库里。可以用 PostgreSQL、SQLite、DuckDB 作为目录后端，数据本身依然是 Parquet。v1.0 在 2026 年 4 月发布，附带向后兼容保证。它的论点很简单 —— 元数据查询本来就是数据库擅长的事，为什么非要在对象存储上翻找文件树呢。不过目前的采用规模还完全无法与 Iceberg 相比，作为多个引擎共用的组织级标准来看还为时尚早。

转换与编排 —— 编译器该放在哪里，以及失败处理模型

转换层真正的决策是"SQL 在哪里编译、在哪里执行"。 dbt 一系的工具从不直接触碰数据。它们把 SQL 模板展开成依赖图，编译成目标仓库的方言后发送出去，再把结果物化为表或视图。换句话说，它既是编译器，也是构建系统。所以在这一层真正该问的是：

• 工具能不能静态地知道模型之间的依赖图，还是必须实际跑一遍才知道？如果能静态获知，影响分析和局部重跑就成为可能。
• 编译出来的结果能不能在任意引擎上运行？换仓库时要重写多少转换代码，答案就在这里。
• 增量物化的正确性由谁来保证？迟到数据和回填(backfill)是这一层产生 bug 最多的地方。

把这三点放在一起看，就能读出近几年的走向。行业正在从"渲染 Python 模板字符串"转向"真正解析 SQL、静态获知列级血缘"，dbt 的 Fusion 引擎和 SQLMesh 走的是同一个方向。

编排层真正的决策不是调度，而是失败处理。 光靠 cron 也能做调度。引入编排器的理由，是那种"凌晨 3 点的任务失败了，5 点的任务自动停下，等原因修复后只重跑那两个"的行为。所以该问的是：

• 失败的单位是任务还是数据资产？如果是后者，系统就知道"这张表是否是最新的"，并能自行计算重跑范围。
• 回填是不是一等概念？重跑过去 90 天的数据是一个按钮还是一段临时脚本，决定了运维负担的大小。
• 流式处理是否也进入这张图？大多数编排器是为批处理 DAG 设计的，流式流水线有着不同的生命周期。硬塞进同一个工具里，两边都会别扭。

Airflow 2 已经过了 EOL，这一层眼下正处在实实在在的迁移期。迁移到 3.x 时真正的任务清单是什么，我们在Airflow 2 EOL 之后 —— 从 2 迁移到 3 的真实任务清单一文中整理过。

边界正在松动的地方 —— 计算被拉回本地

过去十年的默认假设是"数据大，所以要上集群"。这个假设正在从两个方向被侵蚀。

其一是硬件。 笔记本电脑配备 32~64GB 内存已经是常态，NVMe 的读取速度以 GB/s 计。而大多数分析查询实际触及的数据，远比人们想象的要小得多 —— 借助列式存储只读取所需的列、借助分区裁剪只读取所需的分区，从一张 TB 级的表里只扫描几百 MB 的情况相当常见。

其二是单节点引擎的成熟。 DuckDB、Polars、DataFusion 都具备了向量化执行，以及超出内存容量时向磁盘溢写的能力，并且能直接读取 S3 上的 Parquet 和 Iceberg 表。结果是，那些原本需要"拉起一个集群、把笔记本接上去跑一行 SQL"的工作，相当一部分已经降到了一个单一二进制文件就能搞定的程度。

这股趋势带来三个实际变化。

• 开发循环变短了。 转换逻辑可以在本地对着真实数据样本跑一遍再提交，集群排队队列消失了。
• 成本结构变了。 仓库的计算费用按查询计费，探索性分析一旦转移到本地，这笔账单也就随之消失。
• 边界变得模糊了。 随着 DuckDB 具备了客户端-服务器协议(2026 年 5 月 v1.5.3 中的 Quack 远程协议)，"嵌入式引擎"和"查询服务"之间的界限变得暧昧起来。这个变化究竟改变了什么、又没有改变什么，我们在DuckDB 有了客户端-服务器协议一文中讨论过。

当然，集群并不会因此消失。分界点很清楚 —— 单次查询触及的数据能否装进一台机器的内存和磁盘，以及是否有多人同时在做这件事。前者做不到就需要分布式，后者成立就需要一台服务器。打算把整个组织的夜间批处理都搬到本地引擎上跑，这种计划大多在六个月后就会后悔。反过来，为了一位分析师的探索性工作专门拉起一个 Spark 集群，同样如此。

Spark 那边也没闲着 —— 它的 Python UDF 路径被重新整理为基于 Arrow 实现，Python 与 JVM 之间的序列化成本因此大幅下降。可以参考PySpark 4.2 把 Arrow UDF 设为默认一文。

市场正在向哪里合并

讲完了每一层的决策，也该看看这些层正在如何合并为一体。2026 年最大的事件是 Fivetran 与 dbt Labs 的合并。这笔交易于 2025 年 10 月 13 日宣布，在 2026 年 6 月 1 日完成，是一笔全股票交易，按新闻稿的说法，合并后服务超过 10 万个数据团队。George Fraser 出任 CEO，Tristan Handy 出任 President。(关于合并后 ARR 规模的数字经常被引用，但新闻稿本身并未给出具体数值，因此这里不做引用。)

这次合并的意义，正是前面表格里的第四列。采集和转换归到了同一家公司名下。 过去，"采集用 A、存储用 B、转换用 C、编排用 D"，在每一层拼装出最优解，被视为现代数据栈的美德；而这次合并，某种程度上也是在承认那种拼装成本(元数据在每层边界处断裂、血缘无法贯通、故障原因要跨层追踪)其实相当高昂。

与此同时，这家公司瞄准的对手也很明确 —— Snowflake、Databricks、Microsoft Fabric 这类一体化平台。而它拿出来作为差异化卖点的是开放标准。它把自己的立场押在 SQL 和 Iceberg 之上，并且真的把 dbt Fusion 引擎的运行时以 Apache 2.0 协议放进了 dbt Core v2.0(alpha)。

这里有两点值得读出来。

第一，层的边界不再与厂商的边界重合。 "我们在每一层都用最优工具"这种策略，实际上正在变成"我们用的是三家厂商的组合包"。挑选工具时，需要看清楚这个工具所属的组合包还会一并带来什么。

第二，整合的代价永远是迁移成本。 要验证"建立在开放格式之上"这句承诺是否属实，只有一种办法 —— 数一数删掉这家厂商之后还剩下什么。如果表依然是 Iceberg 格式、目录能够指向另一种实现、转换用的 SQL 能在别的引擎上跑通，这个承诺就是真的。这三条里只要有一条不成立，那就是营销话术。

真正决定工具选择的六个问题

把分层决策压缩成一份清单，就是下面这些。比起厂商对比表，这份清单能快得多地把答案收窄。

1. 这份数据谁在读，需要多新鲜？ 如果只是有人早上看一眼仪表盘，批处理就够了；如果要进入产品界面，就需要一个服务层和延迟预算。这一个问题基本就能决定要不要引入流式处理。
2. 最大的单次查询触及的数据能否装进一台机器？ 能的话，分布式引擎暂时还用不上 —— 这正是上一节讲的那条边界。
3. 这条流水线失败时，什么会自动恢复，什么需要人来处理？ 如果答案是"全靠人"，那应该先修运维模型，而不是先上编排器。
4. 指标的定义唯一地存放在哪里？ 如果 BI 工具、笔记本和产品代码各自在计算"活跃用户数"，再买一个工具也解决不了问题。
5. 删掉这个工具之后，数据会以什么形式、留在什么地方？ 这是检验"开放格式"这一说法的唯一问题。
6. 有多少人来运维这套东西？ 这是最常被忽视、也最常拖垮项目的问题。哪怕只运维好一套 Airflow，也需要人力。一个两人团队如果决定自己包办全部五层，六个月后这个团队做的就不是数据的活儿，而是基础设施的活儿。

原文指南最后谈到的治理，其实和第 6 点说的是同一件事。访问控制、所有权、个人信息血缘、保留策略，都不是靠买一个工具就能解决的，而是要靠人去执行，工具只是让这份执行变得更便宜。

结语 —— 地形会变，问题会留下来

总结一下。

• 不要按层选工具，而是先把这一层的决策想清楚，再挑与之匹配的工具。工具清单三年一换，决策的轴线不变。
• 表格式之争已经随着 Iceberg v3 吸收 Delta 的差异化功能而事实终结。真正的锁定和治理转移到了目录层，而各家目录的实现目前功能还参差不齐。
• 单节点引擎已经把相当一部分原属于集群的工作拉回了本地。分界的标准不是数据本身的大小，而是"能不能装进一台机器"和"是不是多人同时在做"。
• 市场正在跨层合并。Fivetran 与 dbt Labs 的合并就是信号，应对之道是切实验证一家厂商是否真的立足于开放格式之上。
• 工具选择通常在六个问题之内就能有答案，其中最后一个问题(需要多少人来运维)最常被忽视。

地形图很有用，但记住地形图和决定走哪条路是两回事。下次打开工具对比表之前，不妨先用一句话写下自己在这一层到底要做哪项决策。如果这句话写不出来，对比表也帮不上忙。

参考资料

• 面向开发者的数据工具地形指南 —— GeekNews (2026-07-28，51 赞)
• Data Landscape Guide for Developers —— 原文
• Fivetran + dbt Labs 合并完成新闻稿 (2026-06-01)
• Apache Iceberg —— 表规范
• Apache Iceberg —— REST catalog Open API 规范
• Databricks —— Apache Iceberg v3 公开预览发布
• DuckLake —— 用 SQL 数据库做目录的湖仓格式
• DuckDB 发布说明
• Iceberg v3 行血缘 —— 行 ID 并不存储在文件里(相关文章)
• DuckDB 有了客户端-服务器协议(相关文章)
• Airflow 2 EOL 之后 —— 从 2 迁移到 3 的真实任务清单(相关文章)
• PySpark 4.2 把 Arrow UDF 设为默认(相关文章)