湖仓能否取代数仓：2026基准与实证

数据仓库在20年里一直是正确答案

数据仓库赢得了它的地位。二十年来，它都是存储结构化数据、强制执行模式，并为仪表盘和报表提供SQL查询的最可靠方式。如果你的工作负载是“分析师针对干净的表编写SQL”，那么数据仓库很难被超越。

这种工作负载仍然存在。但它不再是唯一重要的工作负载，也不再是决定竞争优势的工作负载。在2026年，脱颖而出的组织是那些其数据平台能够从同一个受治理的基础为BI分析师、数据工程师、机器学习模型、流式管道和AI代理提供服务的组织。数据仓库只为其中一种消费者而构建。湖仓则为所有这些消费者而构建。

本文通过基准测试、客户证据和架构分析来论证这一点。我们会直接说明数据仓库仍然具有优势的地方，因为可信度比一味叫好更重要。

湖仓SQL性能是如何赶上的

对湖仓最常见的反对意见一直是SQL性能。“当然，它很灵活，但它在仪表盘方面能比得上我的数据仓库吗？”在2026年，答案是能。

Databricks湖仓的发展轨迹

Databricks报告称，其生产SQL工作负载组合在2024年末比2022年基线快了77%，相当于Databricks性能指数中约4倍的提升。该指数源自BI、ETL和数据探索工作负载中的数十亿次生产查询，而不是单一的合成基准。

这些改进来自Photon向量化执行引擎、查询规划、缓存、预测性优化、连接算法和并发管理方面的复合收益。在最近五个月的测量期内，特定工作负载类别中，BI约提升14%，数据探索约提升13%，ETL约提升9%。

客户实际测量到的结果

最强有力的证据不是合成基准，而是生产结果。Lumen Technologies将133 TB的关键任务电信数据从Cloudera/本地环境迁移到Databricks湖仓，并测得查询性能提升90%，原本需要数小时的查询在几分钟内完成。Lumen还通过使用Databricks湖仓无服务器将计算成本降低了30-40%。Trek Bicycle在迁移到湖仓后，零售分析速度提升了80-90%，从每天一次刷新变为三次。这些不是实验室结果。它们是服务于真实业务运营的生产工作负载。

实时分析：Lakehouse//RT

对于需要在高并发下实现亚秒级延迟的工作负载，Lakehouse//RT是专为分析读取设计的无服务器SQL仓库。Databricks报告其延迟低至10毫秒，每秒可处理多达12,000次查询。它直接查询受治理的湖仓表，从而无需单独的OLAP服务副本、CDC管道或同步层。

这很重要，因为实时分析的传统架构需要在数据仓库之外维护一个单独的服务数据库。湖仓将其整合为一个受治理的层。

数据仓库仍然做不到的事

匹配SQL性能只是前提。支持湖仓的真正理由在于它在SQL之外还能做什么。

1. 原生服务于AI代理和机器学习模型

传统数据仓库是为SQL用户和BI工具构建的。AI代理需要从同一平台获得对结构化表、非结构化文档、嵌入和实时信号的受治理访问。Gartner将这一转变描述为从数据仓库转向更广泛的“分析控制平面”，该平面结合了受治理数据、语义层、AI代理和执行能力。

德勤在2026年报告称，只有约五分之一的公司拥有针对自主AI代理的成熟治理模型。我们认为，前进的道路需要能够共同治理数据、模型和代理行为的平台，而不是只治理表的数据仓库

湖仓将AI视为一等工作负载。为仪表盘提供支持的同一批受治理表，也为模型训练、特征工程、检索增强生成和代理工具调用提供支持。Unity Gateway将治理扩展到AI运行时：控制代理可以调用哪些模型、记录提示和响应、强制执行速率限制，并治理MCP服务器和工具。

2. 处理非结构化和半结构化数据

数据仓库擅长处理行和列。但企业知识存在于文档、电子邮件、PDF、图像、日志和代码中。一项2026年Komprise调查将数据分类和标记确定为为AI准备非结构化数据时的首要挑战，而麦肯锡关于AI数据就绪度的研究强调了将非结构化内容与企业结构化数据连接起来的重要性。

湖仓以开放格式将所有数据类型存储在云对象存储中。结构化表、半结构化JSON、非结构化文档和向量嵌入共存于同一治理模型之下。你不需要为每种数据类型单独建立一个系统。

3. 消除系统间的数据复制

这正是TCO论证变得真实的地方。大多数数据仓库架构要求数据从数据湖流向数据仓库，然后再复制到机器学习环境、特征存储或部门提取中。每一次复制都会带来存储、计算和治理开销。

湖仓通过从同一份受治理数据为所有工作负载提供服务来消除这一点。SQL查询、Spark转换、流式管道、Python笔记本和机器学习训练作业都从相同的Delta Lake或Apache Iceberg™表读取。没有复制，没有同步，没有血缘断裂。

4. 在一个平台上提供流处理和批处理

数据仓库以批处理为先。数据按计划到达，经过转换，数小时后才可查询。湖仓支持流式摄取与批处理并行，数据在几秒而不是几小时内即可查询。对于欺诈检测、运营监控和实时个性化等用例，这是必需项，而不是锦上添花。

5. 运行在您掌控的开放格式上

将存储、计算和专有数据格式紧密耦合的数据仓库会形成转换成本，且随时间推移不断累积。湖仓运行在 Delta Lake 和 Apache Iceberg™ 之上，这些开放表格式可被任何兼容引擎读取。Unity Catalog 提供开放的多引擎目录层，采用 Apache 2.0 许可，而 UniForm 可从 Delta 表生成与 Iceberg 兼容的元数据，使外部引擎无需复制数据即可读取相同数据。

证据：各组织实际测量到的结果

客户故事正是论证从理论走向证据的地方。以下是各组织从数据仓库迁移到湖仓后测量到的结果。

成本降低

这一模式是一致的：成本降低 25-75%，其驱动力不仅来自更便宜的查询，还来自消除冗余系统、重复数据副本和多平台治理开销。

性能提升

迁移速度

迁移时间线已大幅压缩。Lakebridge 可跨 Snowflake、Oracle、Teradata、Redshift、BigQuery 和 SQL Server 自动化评估、转译和核对。Databricks Migration Agent使用 AI 代理跨方言翻译 SQL 脚本，每批最多可转换 300 个文件。这些工具并不能免除人工验证的需要，但它们减少了导致迁移过于缓慢的手动工作。

数据仓库仍然胜出的地方（以及为何其重要性下降）

以下是数据仓库仍保持优势的方面：

• 可预测的开箱即用 SQL 性能。调优良好的数据仓库需要较少的数据工程工作即可提供快速的仪表板查询。湖仓的性能对文件大小、分区策略、聚类、统计信息和压缩更为敏感。维护不善的湖仓即便硬件相同，也可能比数据仓库慢得多。
• 对仅 SQL 工作负载而言管理更简单。如果您的计算 90% 以上是结构化 SQL 仪表板，且团队完全专注于 SQL，那么数据仓库可能需要的运维开销更少。
• 成熟的高并发 BI 服务。Snowflake 的多集群数据仓库和 Interactive Warehouses 专为数千个并发短查询而构建。湖仓 SQL 引擎具有竞争力，但可能需要更多配置才能匹配这一特定模式。

但这些优势在 2026 年已不那么重要：属于“仅 SQL BI”的企业数据工作负载占比正在缩小。Forrester 2026 年第三季度 Wave评估了 14 家领先的湖仓供应商。Gartner 于 2025 年发布了其首份《数据湖仓平台市场指南》，随后又在 2026 年发布了《湖仓参考架构》。两家公司现在都将湖仓视为主流企业数据平台类别。这告诉我们，数据仓库的优势是真实存在的，但随着 AI、流式处理和非结构化数据成为企业核心需求，这些优势正日益狭窄。

正在胜出的架构

那些报告取得最佳成果的组织，并非用湖仓取代数据仓库。他们运行的湖仓是一个更好的数据仓库，并且还兼具其他一切能力。

该架构如下所示：

• 一个统一的受治理数据基础构建于云对象存储上的开放表格式（Delta Lake、Apache Iceberg™）之上，由 Unity Catalog 治理。
• 多个工作负载引擎在同一数据上运行：Databricks 湖仓用于 SQL 分析，Lakehouse//RT 用于亚秒级服务，Apache Spark™ Declarative Pipelines 用于 ETL，Lakeflow Jobs 用于编排，Agent Bricks 用于 AI 代理，Lakebase 用于运营/事务工作负载。
• 统一治理通过 Unity Catalog 和 Unity Gateway 覆盖数据、模型、代理、工具和 AI 流量。
• 开放互操作性通过 UniForm（Delta 表可作为 Iceberg 读取）、Unity Catalog（开放的多引擎目录）以及用于 Power BI、Tableau、Looker 和其他 BI 工具的标准 JDBC/ODBC 连接实现。

如果您仍在使用数据仓库，该怎么办

您不需要明天就迁移所有内容。但您应该开始衡量差距。

1. 量化您的隐性成本。将您在数据仓库、独立的 ML 平台、流式处理基础设施、数据湖、治理工具以及它们之间的数据副本上的支出相加。这才是您真正的 TCO，而不仅仅是数据仓库账单。
2. 运行并排的概念验证。选择一个高价值领域。在您的数据仓库和 Databricks 湖仓上运行相同的查询。在真实的并发条件下测量 p50、p95 和 p99 延迟。测量每 1,000 次查询的成本。然后加入数据仓库无法服务的 ML 和流式处理工作负载，并测量平台总成本。
3. 从新工作负载开始。如果迁移感觉有风险，请将您的下一个 AI、流式处理或数据工程项目构建在湖仓上。让数据仓库处理现有 BI，同时让湖仓在新用例上证明自己。
4. 使用 Lakebridge 评估迁移复杂性。评估阶段是免费的，它能为您具体呈现针对您特定 SQL 资产的迁移涉及哪些内容。
5. 设定明确的迁移关口。在每个领域，除非湖仓在查询性能、数据对账、可用性和安全性方面达到或超过仓库，否则不要迁移。

长期以来，仓库一直是正确的答案。如今，湖仓才是正确的答案，不是因为仓库坏了，而是因为问题变了。

开始使用：

• 在 Databricks 上尝试 TPC-DS 评估
• 阅读从仓库到湖仓的迁移指南
• 免费试用 Databricks

常见问题解答

对于 SQL 查询，湖仓真的比数据仓库更快吗？对于大多数工作负载，湖仓在 SQL 性能上现已达到或超过仓库。Databricks Lakehouse 自 2022 年以来提升了 77%，独立的 TPC-DS 测试显示，在 1-TB 工作负载上，p50 延迟为亚秒级，成本比经典计算低 74%。在具有热缓存的高并发短查询方面，仓库可能仍略占优势，但差距很小且正在缩小。

从仓库迁移到湖仓能节省多少成本？已公布的客户结果显示成本降低 25% 至 75%。AXA Japan 将仓库成本降低了 60%。节省来自消除冗余系统和数据副本，而不仅仅是更便宜的查询。

那我现有的 Power BI 和 Tableau 等 BI 工具怎么办？它们通过标准 JDBC/ODBC 连接与 Databricks Lakehouse 原生兼容。您现有的仪表板和报表无需重建即可连接到湖仓表。AI/BI Dashboards 和 Genie Agents 在此基础上增加了自然语言分析功能。

从仓库到湖仓的迁移需要多长时间？这取决于复杂度，但时间线已经缩短。Vivriti Capital 在大约 8 周内从 Redshift 迁移。IndusInd Bank 在 15 个月内迁移了 44 个业务领域的 1.5 PB 数据。Lakebridge 和 Agentic Code Converter 可自动化评估、SQL 翻译和数据对账，以加速迁移过程。

湖仓能处理实时分析吗？可以。Lakehouse//RT 可直接在受治理的湖仓表上以高并发提供亚秒级分析查询。Databricks 报告称，在每秒 12,000 次查询下延迟低于 100 毫秒。对于流式摄取，Zerobus 和 Apache Spark™ Declarative Pipelines 可提供亚秒级的数据新鲜度。