大数据的「两个轮回」：从 Hadoop 黑盒到虚拟化层，一场百年的合久必分

引言：一个来自大数据内部的周期率观察

年底总结时，一个很自然的追问是：大数据平台的发展到底遵循什么逻辑？

如果把视线拉长——从 Google 三篇论文激发 Hadoop 横空出世，到 Spark 批/Flink 流/Presto 实时的生态割据，再到数据中台被吐槽制约业务、云原生与大模型同时涌入——会发现一条清晰的线索：技术为业务服务，需求是系统演进的起点和动力。

但需求只是表层。真正驱动大数据领域反复重塑的，是两股更深层的力量：技术轮回和架构轮回。它们构成了一个「计算周期率」——合久必分，分久必合。

第一阶段：爆发——Hadoop 打开黑盒

早期的经营分析依托于业务系统本身的数据，很快暴露出三个致命问题：历史数据保存对业务库造成压力、分析工作干扰线上服务、多业务线间数据割裂和口径冲突。

这催生了两条解决路径：改良派强化数据库的 HTAP 能力（同时支持 TP+AP），改革派则剥离分析需求、走向集中式数据仓库。

数据仓库理论在落地中总结出 Inmon vs Kimball 两大实践流派，而传统数据库（如 Oracle）在支撑集约数据时开始力不从心。Google 三篇论文激发 Hadoop 横空出世——以分布式+一致性为底色，Hadoop 打开了数据库的黑盒，泛 Hadoop 生态则开启了漫长的填坑与重组历程。

以计算为例，Spark 批、Flink 流、Presto/SR 实时，各自身怀绝技领一块地盘。同样的故事在大数据领域的每一层、从宏观到微观都在上演。

第二阶段：盘整——复杂系统的调节回路显现

在一片热火朝天中，问题开始变得严重：

• 方法论层面：热炒的数据中台开始被吐槽制约业务发展。数据中台将平台、数据、服务三要素同时集中，数据容易流通但对数据的认知不行——数据的源端、加工、使用三分离，在大中台的加工端累积了认知和处理瓶颈。
• 基础设施层面：泛 Hadoop 生态极速扩张后，复杂度、系统间一致性、碎片化的人力与学习成本、设备压力开始逼近拐点。复杂系统的调节回路开始显现威力。
• 外部环境：云的发展催生云原生探索与数据领域产生化学反应；AI 尤其是大模型的火热，让从业者开始重新思考 B/A（Business/AI）两者的定位和结合方式。

平台目标的三个层次

一个成熟的数据平台体系要可持续演进，需要回答三个底层问题：

1. 第一层价值（用户需求源头）：更自然的数据表达与更强大的处理能力、更好的软硬件协同。
2. 第二层价值（供给侧优化）：更低的平台使用和运营成本。社区各存算引擎正在融合更多场景（湖仓一体、流批一体、AP/SP 一体），各原子模块（KV、算子、共识、RPC、shuffle、调度、查询优化）能力在趋同复用，不断的洗牌事实上在促进标准化技术供应链的崛起。
3. 第三层价值（跨周期）：方法论层面，数据的产生、处理、消费分离导致组织与合规困境。出路在哪？

技术轮回：重组的尽头是 big-data-base

Hadoop 打开了数据库的黑盒，而泛 Hadoop 生态则开启了漫长的填坑与重组历程。

天下大势，合久必分、分久必合。大数据领域的技术轮回，本质上是一次次打开黑盒又重新封装的过程。从 Hadoop 打开数据库黑盒，到 Spark/Flink/Presto 各自分化，再到引擎内部各层标准逐步确定——重组的尽头，或许就是「big-data-base」大数据库。

大数据库是一个逻辑概念，其核心在于虚拟化层——虚拟表、虚拟引擎、虚拟元数据湖、虚拟集群。这四个虚拟化抽象，构成了从碎片化生态走向逻辑统一的桥梁。

架构轮回：DataMesh 与去中心化的必然

数据中台将平台、数据、服务三要素集中，但数据的集中带来了产生、处理、消费角色的分离，在组织与合规上陷入困境。

数据湖+隐私计算从技术角度发起了第一轮冲击：数据湖的 schema-on-read 模式消解了加工端瓶颈，将职责部分让渡到数据源端；隐私计算则在合规约束下探索了可行路径。然而，权责缺乏定义、服务集中、数据集中的自证困境仍然在期待更高阶的框架解法。

DataMesh 方法论应运而生（由 Zhamak Dehghani 于 2019 年在 ThoughtWorks 提出，2022 年出版专著 Data Mesh: Delivering Data-Driven Value at Scale），其四大原则精准对标了中台困境：

1. Data as a product——数据即产品，强化源端责任
2. Decentralized domain ownership——去中心化的领域所有权
3. Self-serve data infrastructure——自助式数据基础设施
4. Federated computational governance——联邦计算治理

在 DataMesh 的构思里，基于 ETL 的数据中心化流转开始让位于平台的去中心化部署延伸。但这里会面临两个关键挑战：domain 数据源端的再定义与颗粒度把握、数据平台集中建设与去中心部署带来的新技术挑战。

虚拟化层：两个轮回的交汇点

虚拟化层的本质，是提出一个标准、简单、以用户为中心的倡议。它从三个维度展开：

1. 虚拟集群（统一资源模型）

用户感知到的资源本质上是一个「货币」值——存算单元或成本分摊。核心问题是：资源的自由流通。在异构且各自池化的环境中，纵向多层调度、横向多池都对资源流通形成障碍。

借鉴货币跨系统流通依赖清算机构的思路，虚拟集群需要独立的资源清算能力作为流通突破口，由此展开工作资源预估、资源整体协同和优化。从时分型（Spark 批调度）到空分型（Flink TM 自动扩缩），虚拟集群聚焦于解决引擎之上的弹性。

2. 虚拟表（统一数据模型）

表和 SQL 是用户与平台之间最典型的接口。但与资源不同，表和 SQL 在不同计算生态中存在较多差异且与用户强绑定。平台的统一必须不影响到单一生态的用户——这是虚拟表设计的铁律。

虚拟表主要服务于两个维度的融合：

• 生态融合：湖仓一体需要统一 Catalog 解决多个表生态的组织与可见问题。
• 演进透明：新引擎出现后对用户无感替换，需要抽象通用的数据模型及表定义（如湖仓表、主键/Upsert 模型、通用表格式）。

平台应提供基本的元数据转换、数据流转和优化能力：自适应表由平台自动处理，非自适应表由用户管理触发。

3. 虚拟引擎（SuperSQL）

三大 SQL 生态（MySQL、PostgreSQL、Hive/Spark）在语法、语义、函数、数据隐式转换方面差异显著。计算一体来自两个方向的努力：

• 虚拟引擎：对用户抽象标准 SQL 语法，通过统一查询端缝合多个计算引擎，提供一致的自适应计算能力。平台提供 SQL 方言转换、函数生成等能力。
• 统一引擎：引擎内核按模块逐步标准化趋同，单一计算引擎通过策略组合适应更多场景。

4. 虚拟元数据湖

当前开源的 HMS（Hive Metastore）存在两大问题：企业级特性欠缺（多租户、安全权限考虑不足），以及元数据割裂（Iceberg 去中心化 vs Snowflake 中心化）。

独立元数据服务层的本质，是将元数据的视角从基于计算转变为基于数据要素本身。这个转变不仅能更好地支撑计算，还能挖掘出更多有趣的计算模式。元数据互联则成为另一个自然延伸——为 DataMesh 的落地打下基础。

海外业务：新架构的完美落地场景

中心化和去中心化并不天然对立，实际上可以通过不同颗粒度在不同层级达成统一。而海外业务提供了一个完美的新架构落地场景：

• 增量业务：非存量博弈，阻力相对较小
• 非自建 IaaS：必须依赖外部混合多云基础设施
• 合规要求：必须去中心化多属地部署

这三个条件恰好构成了虚拟化层和 DataMesh 理念的理想试验田——在增量场景中验证架构，再逐步向存量业务扩展。

总结：把视角聚焦到计算

回顾整个演进逻辑，大数据领域的发展可以浓缩为两条主线：

技术线：数据库 → Hadoop（打开黑盒）→ Spark/Flink/Presto（分化的生态）→ 标准化技术供应链（原子模块趋同）→ big-data-base（逻辑统一的大数据库）。

架构线：业务系统内嵌分析 → 集中式数据仓库 → 数据中台（集中化顶峰）→ 数据湖+隐私计算（第一轮去中心化冲击）→ DataMesh（方法论层面的去中心化）→ 虚拟化层（技术层面的统一桥梁）。

两条线在虚拟化层交汇——通过虚拟表、虚拟集群、虚拟引擎、虚拟元数据湖四个抽象，对内进行自优化，对用户屏蔽复杂多变的大数据生态，推动数据架构逐步走向逻辑统一与使用极简。

既然是深水区，必然面临巨大的挑战——技术的、认知的、利益的。能做的大概就是走下去，把其他的都交给时间。

---

本文基于三篇内部技术随笔整理改写，原文涉及天穹平台「一体化+平台大脑」专项、虚拟化层上下篇的完整论述。文中提及的 DataMesh、湖仓一体、SuperSQL 等方向在社区均有对应开源项目可供参考：虚拟表方向有 Apache Amoro（原 Arctic，湖仓表管理）和 Gravitino（统一元数据湖），虚拟引擎方向有 Substrait（跨引擎中间表示），湖仓格式有 Apache Iceberg / Delta Lake / Apache Hudi。