云上数据平台格局演变：从引擎之争走向开放生态

执行摘要：当前数据产业正从单一引擎竞争转向多云、多引擎协同的开放架构。本文梳理云数据平台现状与竞争格局，分析上游计算存储、中游ETL编排与查询、下游BI应用的产业链结构，对比BigQuery与Databricks等平台差异，并探讨DuckDB等轻量方案与开放表格式对成本与生态的影响，研判未来趋势。

产业现状与竞争格局

云上数据平台市场正处于深度重构期。过去十年，行业围绕“哪个查询引擎更快、哪个仓库更强”展开竞争；如今，随着数据湖开放表格式（如 Apache Iceberg、Delta Lake）成为事实标准，竞争焦点正从引擎之争转向生态之争。本章梳理当前主要玩家的市场定位与格局演变。

一、市场总体格局

当前云数据平台市场大致分为三大阵营：

全托管云原生仓库阵营：以 Google BigQuery 为代表，主打存算分离、Serverless 体验与极致易用性，深度绑定 Google Cloud 生态。

湖仓一体平台阵营：以 Databricks 为代表，源于 Spark 生态，强调数据工程、AI/ML 与数据分析的一体化，通过 Delta Lake 与 Unity Catalog 构建开放格式加统一治理的护城河。

云厂商全家桶阵营：以 AWS 为典型，不依赖单一“超级平台”，而是提供 Redshift、Athena、EMR、Glue、S3 Tables、MWAA、OpenSearch 等模块化产品矩阵，由客户自由组合。

需要指出的是，“三阵营”的边界正在快速模糊：BigQuery 引入对开放格式的支持，Databricks 深化 Serverless 能力，AWS 则通过开放表格式整合其分散的产品线。

二、主要玩家定位分析

Google BigQuery：定位为“零运维的分析引擎”，其核心优势在于跨项目、跨组织的数据共享能力与按量计费模式，对分析型工作负载和 GCP 原生客户吸引力强。但在数据工程侧（复杂 ETL、流处理、ML 训练）相对依赖生态补齐。

Databricks：定位为“湖仓一体 + AI 平台”，是唯一同时具备数据工程、BI、实时分析与生成式 AI 基础设施的独立厂商。其增长动力很大程度来自 AI 浪潮，客户将模型训练与数据治理收敛到同一平台。作为中立项，它同时运行在 AWS、Azure、GCP 之上，这也是云厂商既合作又竞争的微妙关系来源。

AWS：市场份额上仍是云基础设施的领导者，其数据战略的关键转变是全面拥抱开放表格式。近期多项产品动作体现了这一逻辑：

• Amazon EMR 引入 multi-catalog 能力，支持跨账户、跨表格式查询，打破格式与账户边界；
• Amazon S3 Tables 与 Glue 组合，可与 DuckDB 等轻量引擎搭配构建低成本 ETL 链路；
• MWAA 编排的 ETL 管道可接 OpenSearch 做监控，体现“模块拼装”而非“单一平台”的思路。

这意味着 AWS 的竞争策略是：把数据存储层（S3）做成行业公地，把平台层开放给多种引擎（包括第三方开源引擎），以生态广度对抗对手的垂直深度。

三、格局演变的驱动力

1. 开放表格式成为博弈焦点。Iceberg 的中立性使其成为多阵营争夺的“公共基础设施”，围绕其捐赠、治理与实现路径，各厂商存在持续博弈，但客观结果是有利于客户的数据可迁移性。

2. AI 负载重塑需求。非结构化数据、向量检索与特征工程需求上升，使“仓库”与“湖”的技术分野弱化，AI 能力成为新的竞争维度。

3. 成本透明化。以 DuckDB 为代表的轻量引擎证明：部分场景下“便宜的工具 + 对象存储”即可替代重量级平台，倒逼大平台在计费模式上竞争。

四、小结

总体来看，市场格局尚未收敛：BigQuery、Databricks、AWS 系产品分别以易用性、AI 一体化、生态广度为核心筹码。行业叙事已从“选哪个引擎”转向“进入谁的生态”，而开放表格式与客户对避免锁定的诉求，将持续压缩纯营销叙事的空间，把竞争拉回到互操作性、总拥有成本与真实工作负载表现的维度上。下一章将深入分析这一转变的技术基础。

产业链上游：存储与计算底座

一、开放表格式成为存储层新基建

数据平台产业链上游正在经历一场静默的标准化进程。以 Apache Iceberg、Apache Hudi、Delta Lake 为代表的开放表格式，已从单一引擎的私有协议演进为跨厂商通用的存储层"事实标准"。AWS 推出 S3 Tables，将 Iceberg 表格式的管理能力内化为对象存储的原生服务，标志着云厂商首次在存储底座层面直接拥抱开放表格式，而非通过计算引擎间接支持。

这一变化的意义在于：存储层与计算层之间的接口被明确地标准化和产品化。S3 Tables 提供自动压缩、快照管理、垃圾回收等表维护能力，将过去由 Spark、Trino 等引擎承担的元数据运维职责下沉到存储服务，降低了用户维护 Iceberg 表的运维成本。对上游产业链而言，这意味着"对象存储 + 开放表格式"成为新的基础设施组合，任何符合开放格式规范的计算引擎均可直接对接，引擎之间的切换成本显著降低。

二、存算分离重构产业链分工

存算分离架构是这一轮上游重构的核心驱动力。其产业链逻辑可以从三个层面观察：

其一，存储层价值上移。 在传统存算一体架构（如 MPP 数据库）中，存储与计算深度绑定，供应商通过整机销售或一体化服务获取全链条价值。存算分离后，数据资产沉淀在开放的存储层（S3 及其表格式之上），用户对存储层的粘性高于对计算引擎的粘性，上游存储服务成为数据平台的"引力中心"。

其二，计算层竞争加剧。 由于表格式接口开放，计算引擎的可替换性大幅提升。AWS Glue 上运行 DuckDB 处理 S3 Tables 中的数据，即是"轻量级引擎 + 托管存储"组合的代表——对于中小规模 ETL 场景，DuckDB 这类嵌入式引擎无需集群即可完成列式读取与转换，与 S3 Tables 的 Iceberg 接口直接集成，显著降低了批处理成本。这表明计算层的竞争正在从"单引擎全能"转向"场景化最优"，EMR、Glue、MWAA 等不同形态的计算与编排服务在同一存储底座上协同工作。

其三，元数据目录成为新的咽喉环节。 多 catalog 能力的出现——如 Amazon EMR 支持跨账户、跨表格式（Iceberg、Hudi、Delta Lake）联合查询——说明上游正在构建统一的元数据访问层。谁控制 catalog 与权限体系，谁就掌握了开放生态中的调度权。可以预见，围绕 catalog 的产业博弈将持续：云厂商将其产品化为托管服务，中立数据平台则通过 open catalog 规范争取跨云一致性。

三、上游格局演进的路径

四、观察与判断

从产业分析视角看，上游格局呈现三个趋势：

1. 标准化红利释放：开放表格式抹平了引擎间的数据壁垒，用户可以在 EMR 上做大规模批处理、在 Glue + DuckDB 上做轻量 ETL、通过 OpenSearch 监控 MWAA 编排的管道运行，不同组件围绕同一存储底座自由组合。

2. 竞争焦点转移：厂商间的差异化不再依赖存储锁定，而是转向表维护性能（如 S3 Tables 的自动优化）、查询性价比以及 catalog 生态的完整性。关于各引擎优劣的营销叙事正在被可复现的基准测试取代，技术选型趋于务实。

3. 开放与锁定并存：开放表格式降低了数据迁移成本，但 catalog 权限、跨账户治理、托管服务的集成便利性仍构成新的粘性来源。上游产业链的价值分配，将从"格式之争"转向"治理与运营能力之争"。

总体而言，上游存储与计算底座正在从垂直一体化走向"开放格式 + 托管服务"的水平化分工。对产业参与方而言，能否在开放标准之上提供更优的运维体验与治理能力，将成为决定上游竞争位置的关键变量。

产业链中游：ETL与查询引擎

在数据平台产业链中，中游承担着承上启下的关键角色：上游的存储层（如对象存储、表格式）提供数据底座，下游的分析与消费层依赖干净、可用、可查询的数据资产。中游的核心任务是两件事——数据的加工与编排（ETL/ELT），以及数据的统一查询与访问。本章围绕AWS体系内的Glue、EMR、MWAA三类工具，以及多目录、多引擎查询能力，分析中游格局的演变逻辑。

一、编排与ETL工具的分工

中游工具链呈现“各司其职、松散耦合”的格局，三类代表性服务覆盖了不同的抽象层次：

• AWS Glue：无服务器化的数据集成服务，覆盖数据目录、ETL作业、数据质量等能力。其价值在于降低了ETL的运维门槛——用户无需管理集群，按作业运行付费。在成本敏感的中小规模数据处理场景中，Glue配合DuckDB等轻量级查询引擎运行于S3 Tables之上，可以以较低成本完成常规转换任务，体现了“轻量化ETL”的趋势：并非所有数据管道都需要重型分布式引擎。
• Amazon EMR：托管的大数据集群服务，承载Spark、Hive、Presto/Trino、Flink等开源引擎，适合大规模、高吞吐的批处理与复杂计算。EMR的多目录能力允许在单个集群内跨账户、跨表格式（如Iceberg、Hudi、Delta Lake、Hive Metastore等）联合查询，这直接改变了此前“一种表格式绑定一个目录、一个引擎”的割裂状态。
• Amazon MWAA：基于Apache Airflow的托管编排服务，负责将分散的ETL任务组织成有依赖关系的DAG工作流，并提供调度、重试、监控等治理能力。实践中，MWAA编排的管道常与OpenSearch等可观测性服务集成，实现对管道运行状态的集中监控——这意味着中游正在从“跑通数据流”走向“管好数据流”。

三者构成典型的分层分工：EMR负责重计算，Glue负责轻集成与元数据，MWAA负责编排治理。这种分工本身也是一种产业信号：数据中游没有出现“单一引擎统治一切”的局面，而是围绕存储层形成组合式工具栈。

二、多目录与多引擎：打破数据孤岛

中游格局演变中最值得关注的方向，是查询层的解耦。历史上，数据平台的技术选型往往在引擎层面锁定：选择某数仓引擎，即意味着接受其存储格式、元数据目录与配套生态。这种绑定带来了两个问题：

1. 迁移成本高：元数据与表格式深度耦合，更换引擎意味着大规模的数据重写与管道重构；

2. 集成效率低：企业内部多账户、多团队各自建仓，跨账户、跨格式的联合分析需要搬运数据或维护多套查询入口。

多目录能力的出现改变了这一逻辑。EMR的多目录查询允许用户在一个会话中挂载多个元数据目录，透明地访问不同账户、不同表格式下的数据，无需数据拷贝。对数据集成效率的提升体现在三个层面：

• 接入效率：新数据源以“注册目录”方式接入，而非ETL搬迁接入；
• 开发效率：分析师用同一套SQL语义访问异构数据，减少引擎切换与语法适配；
• 组织效率：跨账户查询以元数据联邦替代数据集中化，降低了数据治理的集中化压力。

与之呼应的是表格式层面的竞争收敛。Iceberg等开放表格式逐渐成为事实标准，使得存储与计算解耦从理念变为工程现实——同一张Iceberg表可以被EMR上的Spark、Glue作业乃至第三方引擎访问。中游的竞争焦点因此从“谁的引擎更快”转向“谁开放的接口更兼容”。

三、引擎之争的产业逻辑

围绕中游选型，市场上存在大量厂商营销叙事的交锋，例如某云数仓与某湖仓平台的对比争论。从产业分析视角看，这类“引擎之争”的客观事实是：不同引擎在架构取舍上各有侧重——数仓引擎在极致查询性能与托管体验上占优，湖仓架构在开放存储与生态兼容上占优；而基准性能差异往往高度依赖负载特征、数据规模与工程调优水平，脱离具体场景的横向对比参考价值有限。

对采购方的产业逻辑启示在于：当存储层足够开放（开放表格式+开放目录接口）时，引擎层面保持多供应商可替换性成为可能，这将议价权从引擎厂商部分转移回数据所有者一方。这也是中游“从引擎之争走向开放生态”的核心动力。

四、中游格局的演变路径

综上，产业链中游正经历从“工具各自为战”到“开放生态协同”的转型：Glue、EMR、MWAA在分工中形成组合栈，多目录与开放表格式打通了数据访问的横向壁垒，而引擎层面的竞争则被引导向性价比、可观测性与生态兼容等更务实的维度。对企业而言，中游选型的关键判断标准应从“绑定哪个引擎”转向“能否在开放接口之上灵活替换引擎”。

产业链下游：监控、治理与应用

数据平台的竞争焦点正从引擎性能转向下游环节。监控、治理与分析应用构成了数据价值的“最后一公里”，也是当前产业格局中变化最活跃的领域。

监控体系：OpenSearch 成为可观测性的事实中枢

随着数据管道规模扩大，编排与监控的耦合需求日益突出。以 MWAA（Managed Workflows for Apache Airflow）编排的 ETL 管道为例，业界普遍采用 Amazon OpenSearch Service 作为日志与指标的汇聚层：Airflow 任务日志、DAG 运行状态、失败重试记录被集中索引后，可进行异常检测、告警与根因定位。这一模式的价值在于将原本分散在各个任务节点上的运维信息统一到可查询、可可视化的界面，把“管道是否健康”从被动排查变为主动监测。

数据可观测性的产业意义正在被重新定价。上游引擎层（Spark、Trino、DuckDB 等）的同质化程度提高后，平台厂商的差异化更多体现在下游：日志留存策略、告警响应时延、跨集群的可观测性覆盖范围，成为企业选型时的重要考量。对云厂商而言，监控能力同时也是锁定效应的来源——日志与指标沉淀在自有体系中，迁移成本随之上升。

治理与互操作：多目录（Multi-Catalog）打破格式壁垒

治理层的核心矛盾是“格式与目录的归属权”。Amazon EMR 引入的多目录（multi-catalog）查询能力，允许在同一查询中跨账号、跨表格式访问数据——例如同时查询 Iceberg、Hive 与外部目录中的表。这在产业逻辑上是一次重要让渡：查询层不再强制要求数据迁入单一格式或单一账号边界，而是通过目录联邦实现互操作。

对下游而言，这一变化直接降低了治理成本。企业无需为跨部门、跨云账号的数据访问重建复制管道，权限治理可以在目录层统一收口。这也回应了市场对开放表格式（open table format）生态的期待：Iceberg 等格式的普及使存储层趋于标准化，竞争重心进一步向目录、查询与监控迁移。

分析场景：成本与能力的再平衡

在 BI 与分析应用层，市场讨论已从“选 BigQuery 还是 Databricks”这类引擎之争，转向基于实际工作负载的评估。行业观察普遍指出，营销口径的基准对比对真实选型参考有限，企业更应关注：查询模式的分布（Ad-hoc 与报表占比）、并发规模、存储计算耦合度以及总体拥有成本。

与此同时，轻量化技术路线在成本敏感场景获得关注。AWS Glue 结合 DuckDB 与 S3 Tables 的组合即为典型案例：DuckDB 以嵌入式引擎处理中小规模分析，S3 Tables 提供托管的表格式管理，Glue 承担服务化编排。这条路线表明，下游分析并非必须依赖重型分布式引擎——按负载规模匹配引擎，本身已成为一种架构治理策略。

下游价值评估

综合来看，下游环节的价值结构呈现三个趋势：

其一，可观测性从成本项变为价值项。数据管道故障的业务传导速度加快，使监控能力从“附属功能”升级为采购决策的核心指标。其二，治理层的开放化正在重塑竞争边界。多目录与开放表格式压缩了存储锁定空间，竞争进一步向服务和生态质量转移。其三，下游是差异化竞争的缓冲带。当引擎性能趋同，监控体验、治理便利性与成本弹性将成为云数据平台下一阶段博弈的主要战场。

趋势判断与展望

一、三条主线正在收敛

过去五年，数据平台领域的竞争集中在“引擎之争”：各家厂商围绕查询引擎、执行框架的性能差异展开对标。但综合当前产业动态，我们认为竞争重心正在转移，三条技术主线趋于收敛。

第一，开放表格式成为事实标准。 以 Apache Iceberg 为代表的开放表格式正在成为湖仓架构的底座。以 AWS 为例，S3 Tables 提供了对 Iceberg 的原生托管支持，EMR 则通过 multi-catalog 能力支持跨账户、跨表格式的联合查询，用户无需为访问不同格式的数据而迁移或复制。表格式开放化意味着数据资产与计算引擎解耦，数据的“所有权”回归用户侧。

第二，多目录架构成为组织级标配。 企业数据往往分散在多个账户、多个目录服务中。EMR 的 multi-catalog 实践表明，主流平台已不再强求用户将元数据收敛到单一目录，而是提供联邦式的目录访问能力。这与大型企业多团队、多账户的治理现实相匹配，也降低了平台锁定的切换成本。

第三，按需计算与轻量引擎兴起。 DuckDB 与 Amazon S3 Tables 结合、运行在 AWS Glue 上的 ETL 方案展示了“够用且便宜”的路线：对于中小规模数据任务，无需常驻集群或重型分布式引擎，按需启动的嵌入式/轻量引擎可显著降低成本。计算粒度从“集群级”细化到“任务级”，付费模式与实际负载进一步对齐。

二、平台竞争的逻辑转变

技术主线的收敛直接改变了竞争维度。参考素材中的观点具有代表性：基于营销材料在 BigQuery 与 Databricks 之间做选择，往往偏离了实际需求。当主流引擎在标准负载下的性能差距缩小、且都能通过开放格式访问同一份数据时，功能对标的价值递减。竞争焦点转向两个维度：

• 生态整合能力：编排、监控、治理、目录的端到端协同。例如 MWAA 编排的 ETL 管道接入 OpenSearch 进行监控，体现的是平台“粘性”从引擎性能转向周边工具链的完整度。
• 成本效率：单位数据处理成本、闲置资源率、存储与计算的独立伸缩能力。按需计算路线的兴起本质上是用户对成本效率投票的结果。

三、对产业格局的影响判断

基于上述趋势，我们提出四点判断：

1. 数据可移植性成为采购硬指标。 开放表格式+多目录架构使“数据跟着格式走、计算按需换”成为可行路径，用户议价能力上升，平台切换的隐性成本下降。

2. 引擎差异化空间收窄，厂商转向“全栈税”与“体验税”。 竞争优势将更多来自托管服务的运维体验、治理合规能力和与既有云资产的集成深度。

3. 成本效率竞争催生分层计算市场。 重型分布式引擎与轻量嵌入式引擎将长期共存，分别服务于大规模复杂负载与中小规模高频任务，混合编排成为常态。

4. 互操作性带来新的博弈与合规要求。 跨账户、跨格式的联邦查询涉及数据主权与访问审计，随着数据跨境与隐私监管趋严，平台需要在开放性与治理合规之间取得平衡；围绕开放格式标准的社区治理主导权，也可能成为厂商间博弈的议题之一，但产业逻辑仍指向更大的开放。

四、结语

数据平台的竞争正在从“谁的引擎更快”走向“谁的生态更开放、谁的单位成本更低”。对用户而言，这意味着更低的锁定风险与更灵活的架构选择；对厂商而言，护城河的构建逻辑需要重写——从封闭引擎的性能优势，转向开放生态中的集成深度与运营效率。未来两到三年，开放表格式、多目录架构与按需计算的组合有望成为主流架构范式，平台格局将围绕这一范式重新洗牌。