Back to essays

Data Engineering · Cloud · Cross-cloud

当 Google BigQuery 遇上 Microsoft OneLake：跨云数据湖的三条路径

2026-07-27 · 12 min read · 系列文章 #1 of 3

Audio version · MiniMax TTS · male-qn-jingying

一、为什么跨云数据湖成了 2026 年的标配

三年前，我们还在争论"上云还是下云"。

现在这个问题已经过时了。真正的问题变成了：怎么让数据在多个云之间自由流动。

现实是，几乎每家中大型企业的数据资产都横跨至少两个云：

业务核心跑在 Google Cloud（BigQuery + GCP 原生服务）
企业 BI / 办公协同在 Microsoft 365 / Fabric / Teams
机器学习平台在 AWS SageMaker 或 Databricks

如果你做数据架构，被问得最多的问题一定是：

Google BigQuery 里的业务数据，怎么才能被 Power BI 实时、安全、低成本地用起来？

这篇文章就拆解这件事 —— BigQuery → Microsoft OneLake 的三种主流接入方式，以及我们如何在生产环境选型。

二、OneLake 是什么？为什么它是关键

Microsoft 在 2023 年推出 Fabric 时，把所有数据服务（Synapse、ADLS、Power BI）统一到了一个 Lakehouse 概念下：OneLake。

特性	含义
Delta / Parquet 原生	所有数据默认 Delta Lake 格式，ACID、Time Travel、Schema Evolution 都支持
跨服务共享	Synapse、Power BI、Data Factory、Copilot Studio 读同一份数据
跨云镜像	OneLake 可以反向镜像到 Snowflake / Databricks（OneLake Mirroring）
DirectLake	Power BI 不需要再 import 一份，直接读 Delta 文件（秒级刷新）

OneLake 不是 Azure Blob Storage 的简单升级版——它是"企业级数据语义层"。任何能写 Delta 的工具都能往里写，任何能读 Delta 的工具都能直接读。

所以 BigQuery 数据进 OneLake，本质是：

GCP 上的列式存储 → Azure 上的 Delta Lake

下面讲三种干这件事的方法。

三、方法一：Azure Data Factory + 自托管 Integration Runtime（推荐）

3.1 架构

┌──────────────┐         ┌────────────────────┐         ┌──────────────────┐
│  BigQuery    │         │  Self-Hosted IR    │         │  Fabric          │
│  (GCP)       │  ────▶  │  (Azure VM)        │  ────▶  │  OneLake         │
│              │  jdbc   │  • OAuth 代理       │  Delta  │  Lakehouse       │
│  pricing_prod│  Service│  • 网络出口 IP      │  write  │                  │
└──────────────┘  Account└────────────────────┘         └──────────────────┘

3.2 配置实战

Step 1 — BigQuery 侧准备服务账号

# 在 GCP 控制台创建 Service Account，最小权限：
#   BigQuery Data Viewer (读数据)
#   BigQuery Job User (跑查询)
#   BigQuery Data Editor (可选，写回场景)
# 下载 JSON Key，存到 Self-Hosted IR 机器的 /opt/bq-key.json

Step 2 — 自托管 IR 部署

# 在 Azure VM (推荐 D8s v3, 4 vCPU + 32 GB) 上
# 安装 Integration Runtime：Microsoft Integration Runtime v5+
# 注册到你的 Data Factory
# 把 bq-key.json 拷到这台机器，IR 服务账号有读权限

Step 3 — Linked Service 配置

字段	值
Type	Google BigQuery
Project	`your-gcp-project-id`
Authentication	Service Account
Key File Path	`/opt/bq-key.json`（IR 机器上）
Connection Test	必须能跑通一次 `SELECT 1`

3.3 优缺点

✅ 适合

数据量 10 GB - 10 TB
增量同步 + Schema 演进 + 监控完善
已经有 Azure 团队运维

❌ 不适合

想要秒级实时（Data Factory 最小调度是分钟级）
PB 级数据每天全量
网络出带宽成本敏感

⚠️ 坑

时区 —— BigQuery 默认 UTC，业务日期一定要 CAST(DATE(_PARTITIONTIME, 'Asia/Shanghai') AS DATE)
出网费 —— GCP → Azure 跨云出网按 GB 计费，月 100 GB 量级就要算账
服务账号轮换 —— JSON Key 90 天过期，自动化轮换脚本必须就位

四、方法二：Synapse Link for BigQuery（近实时）

4.1 原理

Synapse Link 是 Microsoft 在 2024 年推出的近实时数据镜像能力。和 Data Factory 不同，它不做 ETL 复制，而是：

BigQuery Change Streams (CDC)
      │
      ▼
Azure Event Hub (or Service Bus)
      │
      ▼
Synapse Link 消费者
      │
      ▼
OneLake Delta 表（持续写入）

延迟可以做到 10-60 秒。

4.2 架构图

┌──────────────┐   CDC    ┌────────────────┐   Stream   ┌─────────────────┐
│  BigQuery    │  ──────▶ │  Event Hub     │  ────────▶ │  OneLake        │
│  Change      │   Log    │  (Azure)       │   Consume  │  (Delta Live)   │
│  Streams     │          │                │            │                 │
└──────────────┘          └────────────────┘            └─────────────────┘
   pricing_prod            bq-cdc-hub                       LH_BigQuery_CDC

4.3 优缺点

✅ 适合

报表要求接近实时（管理层要看实时 GMV 看板）
团队愿意接受 preview 阶段的稳定性风险

❌ 不适合

复杂 BigQuery 特性（ARRAY、STRUCT 嵌套）— 转换有损耗
生产环境必须稳的金融 / 医疗场景（当前还是 Preview，2026 年下半年才 GA）

五、方法三：Spark on Databricks 中转（最灵活）

5.1 架构

┌──────────────┐    JDBC    ┌──────────────────┐    Delta    ┌──────────────┐
│  BigQuery    │  ────────▶ │  Databricks      │  ─────────▶ │  OneLake     │
│              │            │  Spark Cluster   │   Mount     │              │
│  pricing_prod│            │  (复杂 transform)│             │  LH_BigQuery │
└──────────────┘            └──────────────────┘             └──────────────┘
                                │
                                └─ 可加 ML 特征工程 / 数据血缘

5.2 适合场景

BigQuery 数据需要复杂的 schema 转换（如 ARRAY 展开、JSON 解析、UDF 处理）
想要顺便做机器学习特征工程（Databricks 强项）
团队已经有 Databricks 平台

5.3 优缺点

✅ 适合

最灵活，任何 BigQuery 特性都能转换
可以顺便训练 ML 模型，特征直接落 OneLake

❌ 不适合

多一套系统运维（Databricks 集群、job 调度）
成本叠加（BigQuery 扫描费 + Databricks 计算费 + OneLake 存储费）
数据治理割裂（Databricks Unity Catalog 和 Fabric Purview 不互通）

六、选型决策树

                ┌─ 数据量 > 10 TB / 天？ ──────────── YES ──▶ Databricks 中转
                │
你的团队 ────────┤
                │             NO
                │
                ├─ 需要秒级实时？ ───────────────────── YES ──▶ Synapse Link (Preview)
                │
                │             NO
                │
                └─ 团队有 Azure 运维能力？ ────────── YES ──▶ Data Factory + IR ★
                                              │
                                              NO ──▶ 评估 Synapse Link 或外包 Azure 运维

90% 的企业级场景推荐方法一。

七、生产环境的实战清单

不管你选哪种方法，下面这些是必须做的：

7.1 数据契约 (Data Contract)

# BigQuery → OneLake 同步契约示例
table: pricing_prod.daily_sales
owner: data-platform-team@example.com
freshness_sla: 24h
schema:
  - name: business_date
    type: DATE
    nullable: false
    partition_key: true
  - name: product_id
    type: STRING
    nullable: false
  - name: region
    type: STRING
    nullable: false
  - name: gmv_amount
    type: NUMERIC
    nullable: false
    pii: false
pii_reviewed: 2026-06-15
quality_checks:
  - row_count > 0
  - null_rate(gmv_amount) < 1%

没有契约的同步一定会上事故。

7.2 监控告警

alerts:
  - name: SyncLag
    condition: watermark_lag > 4h
    severity: warning
    notify: data-platform-oncall@example.com
  - name: SyncFailure
    condition: pipeline_run_status == "Failed"
    severity: critical
    notify: pagerduty:data-platform
  - name: SchemaDrift
    condition: new_columns_in_source > 0
    severity: warning
    notify: data-governance@example.com

7.3 增量校验

每天同步完成后，跑一次对账：

-- Fabric OneLake 侧
SELECT
  business_date,
  COUNT(*) AS fabric_rows,
  SUM(gmv_amount) AS fabric_gmv
FROM LH_BigQuery_Mirror.daily_sales
WHERE business_date >= CURRENT_DATE - 7
GROUP BY business_date;

-- 对比 BigQuery 侧同一查询
-- 差异 > 0.01% 触发告警

八、常见踩坑

坑 1：分区不对齐

BigQuery 用 _PARTITIONTIME，OneLake 用业务日期分区。两者在跨时区或补数场景下会差一天。

解决：OneLake 端用 CAST(bq_partition AS DATE AT TIME ZONE 'Asia/Shanghai') 作为分区键，源头统一。

坑 2：BigQuery 嵌套字段被拍扁

BigQuery 的 STRUCT<...> 和 ARRAY<STRUCT<...>> 直接同步到 Delta 后会变成 JSON 字符串，Power BI 用起来很痛苦。

解决：在 IR 端用 Spark 或 ADF 的 Data Flow 提前展开，落到 OneLake 时已经是平表。

坑 3：服务账号权限过大

很多团队直接给 BigQuery Admin，然后出事就背锅。

解决：最小权限 BigQuery.DataViewer + BigQuery.JobUser，绝不给 Editor 除非必要。

坑 4：跨云出网费失控

GCP → Azure 出网带宽按 GB 计费，没监控的话月底账单会吓一跳。

解决：在 IR 机器上配 Azure Cost Management alerts，月费用同比 > 30% 自动告警。

九、总结：跨云数据湖的真正难点

技术本身不复杂——BigQuery → Delta Lake 就是 ETL。真正的难点在三件事：

数据契约：源头和目标的 schema 怎么对齐，谁负责，谁审批
SLA 和告警：延迟、失败、漂移的检测和响应机制
跨云成本治理：出网费、扫描费、存储费的可见性和控制

把这三件事做好，你的跨云数据湖就能稳。做不好，再先进的工具也是空中楼阁。

下篇预告：《Power BI DirectLake × Power Apps/Automate：当数据可以自己动手》
数据进了湖，怎么让业务团队直接操作？