Querying Databricks Apache Iceberg Tables with the borderless Lakehouse

使用 Google Cloud Lakehouse 查询 Databricks Iceberg 表 | Google Cloud 博客

数据分析

使用无边界 Lakehouse 查询 Databricks Apache Iceberg 表

2026 年 10 月 30 日

##### Pramod Niralakeri

战略云工程师

##### 11 月 4 日：Agentic Data Cloud 活动

加入我们的产品负责人，共同构建你的智能体未来

注册

企业组织通常会使用多个数据平台（包括 Databricks）来执行繁重的 Apache Spark 作业，并结合 BigQuery 来支持高并发的分析工作负载。历史上，连接这些系统通常需要构建复杂的管道来在不同环境之间复制数据。这种方法会增加存储成本、引入延迟并分散安全控制。

通过 Google Cloud 的无边界 Lakehouse，你现在可以直接从 BigQuery 查询 Databricks 管理的 Apache Iceberg 表。这种零拷贝方法消除了数据复制的需要：BigQuery 读取 Databricks 写入的相同文件，新变更会在 Lakehouse 下一次计划的元数据刷新后出现（刷新频率可高达每 5 分钟一次）。

#### Lakehouse 与 Databricks 的协作方式

托管的 Iceberg 表会自动生成兼容 Iceberg 的元数据，同时保留原生的 Delta 日志。数据工程团队可以使用 Databricks 将 Parquet 文件一次性存储在 Google Cloud Storage（GCS）中。Lakehouse 不需要将这些信息加载到 BigQuery，而是直接读取 Iceberg 元数据，将 BigQuery 的向量化引擎直接应用于 GCS 中的开放格式文件。

尽管上述示例中 Google Cloud Storage（GCS）是主要存储层，但 Lakehouse 可直接将这种无边界联邦扩展到 Amazon S3 和 Azure Blob Storage 等外部云环境。通过将开放的 Apache Iceberg REST 目录与跨云连接结合，Lakehouse 让 BigQuery 能够在不移动数据的情况下跨云查询数据。每个联邦目录都可以部署在你选择的 Google Cloud 区域（理想情况下是距离数据最近的区域）。这使 BigQuery 能够在数据所在位置直接读取开放格式的 Parquet 文件，实现无需复制管道的多云分析。远程云出站费用仍然适用，但跨云互联（AWS）和 Lakehouse 缓存可以降低这些费用。

除了简单查询外部数据，Lakehouse 框架还建立了引擎之间的真正读写（R/W）互操作性。由于平台基于开放的 Apache Iceberg 基础构建，数据团队可以直接在 BigQuery 中无缝执行多语句 SQL 命令。

#### 集中式安全与治理

在不同系统之间处理访问控制可能会引入安全漏洞。Lakehouse 通过委派访问权限解决这一问题。管理员可以配置一个与服务账户关联的 BigQuery 云资源连接，该服务账户管理 GCS 存储桶的 IAM 权限。授予用户访问 Lakehouse 表实体的权限后，你可以在外部 Iceberg 表上强制实施 BigQuery 控制，包括行级、列级安全性和动态数据脱敏，同时 Databricks 负责数据摄入。

#### 目录联邦与凭证分发

#### 分区裁剪

BigQuery 使用每个表的 Iceberg 元数据来规划查询，然后仅读取相关数据文件。Iceberg 的隐藏分区功能允许您根据逻辑列（如时间戳）进行过滤，而无需了解目录结构。请注意，Databricks 管理的 Iceberg 表不支持分区转换；Databricks 建议改用液态聚类。

标准 WHERE 子句中的过滤条件使 BigQuery 能够利用 Iceberg 的清单文件跳过无法匹配的分区。通过将分区列与字面值进行比较，可以启用裁剪功能。这些清单文件维护详细的列级统计边界，使 BigQuery 能够立即跳过无关的清单记录和不必要的 Parquet 文件。因此，查询仅扫描必要的字节范围，从而加速查询执行并显著减少按需资源消耗和存储扫描成本。

#### 借助 Iceberg 元数据和 Lakehouse 缓存实现快速查询

Iceberg 清单文件已明确标识需要读取的数据文件，因此 BigQuery 不需要为 Iceberg 表维护元数据缓存。对于跨云表（如 Amazon S3 中的表），Lakehouse 缓存（预览版）会将检索到的数据块存储在 Google Cloud 中，以便重复查询可以本地读取。BigQuery 在规划每个查询时直接读取 Iceberg 清单文件；无需启用元数据缓存。这种动态分区裁剪功能可跳过不必要的文件，显著减少运行时间和扫描字节数。

#### 维护和生命周期管理

现代数据湖仓库需要主动维护；缺乏常规维护会导致性能退化为低效的存储库。幸运的是，BigQuery 和 Databricks 都提供了原生功能来保持表的整洁并加速分析工作负载。

#### 保持表的优化

为保持最佳查询性能，需要持续维护数据湖仓库的存储占用。

• 通过 Databricks API 触发定期压缩流水线，将微小的 Parquet 文件合并为更大的优化布局，并使用预测性优化。
• 执行 Databricks VACUUM 命令，清除主动快照之外的未引用文件，避免额外的 GCS 存储成本。

#### 压缩与小文件问题

频繁的写入操作、持续的数据摄入任务和流式工作负载会不断生成数千个微小的 Parquet 文件。这种碎片化会创建存储瓶颈，可能限制 BigQuery 的读取效率。向 GCS 建立数千个网络连接并在大量微小文件间处理元数据页脚会消耗大量计算时间，削弱向量化查询执行的性能优势。

在 Iceberg 中运行常规压缩可解决这些低效问题。Databricks 通过 Liquid Clustering 自动管理此过程，该功能根据访问模式动态调整文件布局，或通过原生表管理工具进行管理。

在 Databricks 上手动合并小文件时，运行 OPTIMIZE 命令：

加载中...

-- 在 Databricks 上运行以合并小文件 -- 在 Databricks 中：OPTIMIZE customer_events; -- 对于在 Databricks 外管理的 Iceberg 表：CALL my_catalog.system.rewrite_data_files( table => 'default.customer_events', strategy => 'binpack', options => map( 'target-file-size-bytes', '268435456', 'min-file-size-bytes', '67108864' ) );

执行此命令会将分散的文件片段聚合为通常在 256MB 到 512MB 之间的较大、结构化块，这有助于提高 BigQuery 的扫描吞吐量。binpack 方法通过优先平衡总文件大小快速运行，尽管其他排序策略可以沿特定列键组织数据集顺序。

#### 管理孤立文件和快照保留（VACUUM）

每次事务更新、记录修改和表压缩操作都会在 Iceberg 中创建新的快照以保持数据集完整性。随着时间推移，与活动表状态分离的历史 Parquet 对象会变成孤立文件。虽然这些遗留文件有助于时间旅行分析，但忽视它们会随着时间推移增加 GCS 存储费用。

数据团队可以使用 Databricks 的 VACUUM 操作扫描并清除废弃的存储文件。

ALTER TABLE customer_events SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = '7 days'); VACUUM customer_events FULL;

标准配置在执行 VACUUM 操作前会强制应用 7 天的保留期限（deletedFileRetentionDuration）。保留此延迟可防止活动分析作业遇到文件缺失错误，同时保持历史恢复选项可用。通过安排常规 VACUUM 作业或让预测性优化自动运行，可以删除未引用的数据文件，并对使用 Iceberg 读取的表删除旧 Iceberg 元数据。这有助于降低存储成本并保持湖仓一体架构的高性能。

#### 结论

将 Databricks Apache Iceberg 数据集连接到湖仓一体架构，可以帮助您通过 BigQuery 激活数据。通过将处理与底层存储分离、采用开放格式、使用标准 REST API 和凭证分发机制，您可以在不迁移数据或牺牲性能的情况下运行可扩展的工程工作负载和并发分析。

将 Databricks Iceberg 读取（UniForm）与湖仓一体联邦、湖仓一体缓存以及常规 OPTIMIZE 和 VACUUM 维护相结合，有助于构建高效的零拷贝湖仓一体架构。这种方法可以降低存储支出，避免脆弱的管道维护，并为现代分析和新兴 AI 工作负载做好数据环境准备。

构建统一架构不再需要在不同平台之间移动数据文件。您今天就可以通过将 Databricks Iceberg 表注册到湖仓一体运行时目录，开始查询这些表以实现双向联邦。通过阅读我们的文档了解更多信息，立即开始使用。