◈ DB 选型参考
← 返回首页

Google BigQuery

OLAP #BigQuery #Serverless #Dremel #Slot计费 #BigQuery-Omni #BI-Engine #GCP #BigQuery-ML

Google 的 Serverless 数仓标杆——Dremel 血统的存算分离架构，无节点、无集群，查询自动分配 slot：按扫描量（按需）或按 slot 小时（Editions）两种计费模式，Omni 把引擎送到 AWS/Azure 数据所在处；代价是 GCP 深度绑定、按扫描计费下"一个烂 SQL 烧掉预算"、slot 治理是必修课。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商Google Cloud；BigQuery 2010 年发布、2011 年 GA（前身为 Google 内部 Dremel 系统）
国家美国
起源Google 内部 Dremel 对外服务化；2023 年推出 Editions slot 计费体系替代旧 flat-rate
许可证专有商业软件（无开源版本）
商业版说明双模式计费：按需按扫描 TiB（每月首 1 TiB 免费）；Editions 按 slot 小时（三档：Standard/Enterprise/Enterprise Plus，支持 1/3 年承诺折扣）；存储分 active/long-term 两档；BI Engine、Omni、流式写入另计。具体价格随区域与合同变化，本档案不写绝对价格
托管服务GCP 全托管 Serverless；无多云部署（Omni 是跨云查询，不是跨云部署）
主类型云数据仓库（OLAP）
兼具类型库内机器学习（BigQuery ML）、BI 加速（BI Engine）、跨云分析（BigQuery Omni）

硬维度（47 项）

1 静态加密 / TDE 有

  • 默认由 Google 管理密钥加密全部数据；支持客户管理密钥（CMEK），密钥存客户自己的 Cloud KMS 官方文档。
  • 注意：CMEK 是高阶版本（Enterprise Plus 等）能力，Standard 版不可用，选型时看版本矩阵 官方文档。

2 TLS / 传输加密 有（TLS 全链路）

  • 所有 API/控制台/驱动流量走 TLS；VPC-SC（VPC Service Controls）可做私有边界隔离 官方文档。
  • 无明文回退：Serverless 架构下不存在自建式明文端口问题 社区共识。

3 审计 有（Cloud Audit Logs）

  • Cloud Audit Logs 记录数据访问与管理操作，可经 Log Router 接入 SIEM 官方文档。
  • INFORMATION_SCHEMA.JOBS 系列视图可查作业历史、执行者、扫描字节与 slot 消耗，是"谁跑了什么查询、花了多少钱"的主入口 官方文档。
  • 注意：审计日志保留与导出要自己配，长期保留有存储成本 社区共识。

4 认证与权限 有（IAM + 列级/行级 + 脱敏）

  • 身份：GCP IAM 统一身份体系，支持 Google Workspace/Cloud Identity SSO 官方文档。
  • 授权：数据集/表/视图级 IAM；列级访问控制、行级安全（row-level security）、数据脱敏策略（data masking）官方文档。
  • 政策标签（Policy Tags）做数据分类分级，是金融/医疗合规的常用姿势 官方文档。
  • 注意：高阶治理能力（列级安全、CMEK）与版本绑定，Standard 版有功能天花板 官方文档。

5 备份恢复 有

  • 时间旅行：默认 7 天，可查询表的历史版本、恢复误删数据 官方文档。
  • 故障安全期（fail-safe）：时间旅行窗口之外再加 7 天（Google 侧保留，需走支持恢复）官方文档。
  • 表快照、数据集复制、跨区域数据集复制做容灾与归档 官方文档。
  • 注意：7 天窗口比 Snowflake（企业版 90 天）短得多，长期审计/合规归档要靠快照或导出到 GCS，不能依赖时间旅行 社区共识。

6 可观测性 有

  • INFORMATION_SCHEMA.JOBS_BY_PROJECT/ORGANIZATION：查每次查询的扫描字节、slot 消耗、执行时长，是成本归因的金矿 官方文档。
  • Cloud Monitoring 指标与告警；控制台有查询计划可视化（执行树、slot 使用）官方文档。
  • slot 治理靠预留用量视图 + 配额告警；Editions 下"哪个预留被谁占满"是日常问题 社区共识。

7 连接模型 有

  • 以 REST API 为主；官方 JDBC/ODBC 驱动、各语言客户端库齐全，BI 工具直连 官方文档。
  • Serverless 架构下没有"连接"概念：无连接池打爆问题，并发瓶颈在 slot 而不在连接数 官方文档。
  • BI Engine：内存加速层，仪表盘类高频小查询走内存，亚秒返回 官方文档。
  • 注意：BI Engine 按内存容量另计费，不是免费加速 官方文档。

8 事务与隔离级别 有

  • 支持多语句事务与 DML（INSERT/UPDATE/DELETE/MERGE），快照隔离语义 官方文档。
  • 注意：这是分析型事务（ETL 修正、SCD 更新），不是 OLTP；大 DML 的 slot 与时间成本要预估，一次全表 UPDATE 可能很贵（按需模式下按扫描计费）社区共识。

9 复制与一致性 有

  • 跨区域数据集复制做容灾；存储多副本，计算无状态 官方文档。
  • Analytics Hub：跨组织/跨项目共享实时数据集，对方订阅即用，无需复制 官方文档。
  • 无跨云主动-主动写：多活是 GCP 区域内的事，跨云靠 Omni 查询而非写入 社区共识。

10 扩展方式 有

  • 全 Serverless：查询自动分配 slot，用户无节点概念，不用调集群大小 官方文档。
  • Editions 下可设 baseline/max 做自动扩缩，baseline 可为 0（纯按需扩缩）官方文档。
  • 边缘真相：自动扩缩按"分配"而非"使用"计费，60 秒起步——一个 10 秒的查询也占 1 分钟 slot；slot 争抢会导致查询排队，Standard 版有 slot 上限 社区共识。

11 兼容性 有（GoogleSQL + 迁移服务）

  • GoogleSQL 方言（源自 ZetaSQL），标准分析 SQL 模式（窗口函数、CTE、数组/结构体）完备 官方文档。
  • BigQuery Migration Service：Teradata/Oracle/Redshift/Snowflake 的迁移评估与 SQL 翻译 官方文档。
  • 注意：方言与 PG/Oracle 有差异，迁移要改写；"SQL 像"不等于"零改写" 社区共识。

12 许可证与商业模式 有

  • 纯 GCP 商业服务，无开源/自建版本 官方文档。
  • 计费模型（只写计量边界）：按需按扫描 TiB（每月首 1 TiB 免费，单查询 10 MB 起步）；Editions 按 slot 小时（三档费率，支持 1/3 年承诺折扣）；存储分 active/long-term（90 天未改动自动降档）；BI Engine、Omni、流式写入、ML 训练另计 官方文档。
  • 选型铁律：波动/低频负载用按需，稳态/高频用 slot；但 Editions 自动扩缩按分配计费，短查询多的场景可能反而不如按需——POC 必须按真实 workload 测两种账 社区共识。

13 中文资料丰富度 部分支持（官方有中文，社区偏少）

  • 官方文档有中文版，核心概念与计费文档均已汉化 官方文档。
  • 中文社区内容（博客、课程）明显少于 AWS 系；深度调优与 slot 治理的实战内容英文为主 社区共识。

14 性能与延迟特征 有

  • Capacitor 列式存储 + Dremel 执行树，PB 级聚合秒到分钟级是常态 官方文档。
  • BI Engine 内存加速：仪表盘类查询亚秒返回 官方文档。
  • 边界：slot 不足会排队（看 JOBS 视图的等待时间）；冷查询首次执行、跨区/Omni 查询有额外延迟；毫秒级点查不是目标 社区共识。
  • 分区表 + 聚簇是性能与成本的双关键：分区裁剪决定扫描量，扫描量决定按需账单 社区共识。

15 合规与认证 有

  • SOC 1/2/3、ISO/IEC 27001、HIPAA、PCI DSS、FedRAMP 等全覆盖 官方文档。
  • 注意：高阶合规能力（CMEK、大范围审计）与 Enterprise Plus 版本绑定，合规选型要连版本一起看 官方文档。

16 成熟度与社区生态 有

  • 2011 年 GA，十余年生产验证，是 Serverless 数仓的定义者之一 社区共识。
  • 生态：dbt-bigquery 适配器、Looker（Google 收购）/Looker Studio、Vertex AI 联动，GCP 数据栈一体 社区共识。
  • 风险面：Google 产品线调整史（如旧 flat-rate 关停）提醒用户：计费模型会变，合同与架构要留余地 社区共识。

17 标杆用户 有（GCP 公开案例）

  • 公开案例包括 Spotify、The New York Times 等（以 Google Cloud 官网最新披露为准）社区共识。
  • 采用模式常见：BigQuery 做核心数仓 + Looker 做 BI + Vertex AI 做 ML，GCP 生态内闭环 社区共识。
  • 具体名单以官网为准，本档案不堆砌 待验证。

18 生态工具链 有

  • SQL 工作流：Dataform（Google 原生）、dbt-bigquery 适配器 官方文档。
  • BI/ML：Looker、Vertex AI（BigQuery ML 模型可直接部署调用）官方文档。
  • IaC：Terraform Google Provider； ingestion 侧 Data Transfer Service、Datastream 社区共识。

19 云托管与 Serverless 有

  • 零运维是最大卖点：无集群、无节点、无补丁，开箱即查 官方文档。
  • 仅 GCP 部署；BigQuery Omni 是"跨云查询"（引擎去 AWS/Azure 数据处），不是"部署到别云" 官方文档。
  • 注意：Serverless 不等于零账单——slot/扫描/存储照计；"免运维"省的是人力，不是费用 社区共识。

20 数据接入与摄入 有

  • 批量加载（Load Job）免费：GCS/本地文件批量入表不收计算费 官方文档。
  • Storage Write API 流式写入（每月有免费额度），exactly-once 语义；旧版 streaming insert 按量计费 官方文档。
  • Datastream：从 MySQL/PostgreSQL/Oracle CDC 近实时同步到 BigQuery，是官方 CDC 入仓通道 官方文档。
  • Data Transfer Service：定时从 SaaS/其他云/应用导入 官方文档。
  • 边缘：流式写入的去重与延迟语义要显式设计；CDC 链路延迟分钟级 社区共识。

21 外部数据访问 有

  • BigQuery Omni：在 AWS/Azure 上运行 BQ 引擎，直接查当地 S3/Blob 数据，免搬迁；支持跨云 join 与跨云物化视图 官方文档。
  • 外部表/对象表：直查 GCS/S3/Azure 数据；BigLake 统一湖仓表格式与治理 官方文档。
  • 新方向：cross-cloud connections（Preview）：从任意 BQ 区域直查 AWS/Azure/Salesforce，据称比 Omni 更省——Preview 状态，生产选型先观望 厂商口径。
  • 边界：Omni 查询按扫描加价 + 跨云传输费；大数据量反复查仍建议入 BQ 存储；"跨云查询"不等于"跨云免费" 社区共识。

22 CDC 与下游同步 有

  • 入：Datastream 从 MySQL/PG/Oracle CDC 近实时同步，是官方推荐链路 官方文档。
  • 出：EXPORT 到 GCS、Analytics Hub 跨组织共享、Dataflow 下游消费 官方文档。
  • 无 Snowflake Streams 式原生变更流：下游要"增量跟"，靠时间旅行窗口内的变更比对或导出 CDC，语义弱一档 社区共识。

23 TTL 与数据生命周期管理 有（表/分区过期时间原生）

  • 表级 expiration_time、数据集默认过期、分区表 partition_expiration_days 官方文档。
  • 过期自动删且不收删除费，是成本治理常用手段 官方文档。
  • 过期是整表/整分区粒度，无行级 TTL 官方文档。

24 在线 DDL 与 Schema 演进 部分支持

  • 只改定义：加列、改名（RENAME COLUMN）、放宽 REQUIRED→NULLABLE 均为在线元数据操作 官方文档。
  • 重写数据但住哪不变：ALTER COLUMN SET DATA TYPE 仅支持兼容 coercion（INT64→NUMERIC/BIGNUMERIC/FLOAT64 等）；不兼容的改类型必须 CTAS/复制重建表 官方文档。
  • 搬数据：分区/聚簇规格建表后不可原地修改，改聚簇必须重建表（CTAS 或复制表+改名）；重建按扫描字节计查询费 官方文档。
  • 验证约束：PK/FK 只能声明为 NOT ENFORCED、纯信息性（优化器提示，数据违例会算出错误结果）；NOT NULL 在写入时强制执行；列 DEFAULT 只对未来写入生效 官方文档/社区共识。
  • 规模：第二、三类代价 O(n)；PB 级表 CTAS 重建是"数小时 + 按扫描量烧钱"，小表大表两个世界 社区实测。
  • 语义：单条 DDL 原子；DDL 不允许写进事务——改分区/聚簇的多步重建（建新表+删旧+改名）没有原子性，中间有窗口期 社区实测。

25 多租户与资源隔离 有

  • 预留 slot 按项目/团队分配，互不抢占 官方文档。
  • 按需模式靠配额限流，隔离弱于预留 官方文档。
  • 成本归因到项目标签，FinOps 友好 社区共识。

26 跨地域多活 部分支持

  • 数据集跨区复制（BigQuery 跨区域复制）做容灾/就近读 官方文档。
  • 写仍是单区语义，无多活写 官方文档。
  • 复制产生额外存储+作业费用 社区共识。

27 高可用架构与 RTO/RPO 有（托管多区，用户无感知）

  • 计算存储全托管多区复制，故障平台兜底 官方文档。
  • 时间旅行 7 天可恢复误删，用户侧 RPO≈0 官方文档。

28 行级安全与数据脱敏 有

  • BigQuery 提供 Row-level security（行级访问策略）与基于 Policy Tags 的列级动态脱敏（DLP 集成） 官方文档
  • 列级权限通过 Policy Tags + IAM Data Catalog 实现 官方文档
  • 脱敏策略依赖 Cloud DLP，跨项目配置复杂度高 社区实测

29 JSON 与半结构化能力 有（JSON 类型原生，函数丰富）

  • 原生 JSON 数据类型，JSON_QUERY/JSON_VALUE 等函数丰富 官方文档。
  • 按扫描计费，SELECT * 大 JSON 费用惊人 社区实测。

30 全文检索能力 有

  • SEARCH 函数与 search index 支持全文检索 官方文档。
  • 索引有配额与延迟，非实时 官方文档。

31 存储效率与压缩 有

  • 底层 Capacitor 列式存储格式，自动压缩与编码，用户按压缩后用量计费。官方文档
  • 长周期存储自动转入低成本层级，压缩与分层共同降低账单。官方文档
  • 压缩为平台黑盒，无用户可调参数，压缩比不公开披露。待验证

32 开源协议与厂商锁定风险 有

  • Google BigQuery 是 GCP 专属的 serverless 数仓，无开源版本，完全绑定 Google Cloud。官方文档
  • Standard SQL 方言与 BQ 特有函数（ML、GIS、半结构化）深度绑定平台。社区共识
  • 数据以 Capacitor 列存格式存储，迁出需导出转换，超大表成本高昂。社区共识

33 查询优化器与计划稳定性 有

  • Dremel 架构 CBO 全自动优化，EXPLAIN 可用 官方文档。
  • 无 hint 机制，用户不干预计划 官方文档。
  • slot 自动调度使计划翻转风险极低 社区共识。

34 参数调优与自治能力 有

  • Serverless 模式零参数，autoscaling 自动扩缩 slot 官方文档。
  • 调优转为 SQL 改写与成本（slot/字节计费）管理 社区共识。

35 静默数据损坏防护 部分支持

  • 数据文件落 Colossus 分布式文件系统，底层校验、纠删码与冗余由 Google 内部完成。厂商口径
  • 用户侧无页校验开关、校验命令或损坏审计视图。社区共识
  • 时间旅行与快照防的是逻辑损坏，静默位损坏不在用户可观测范围。官方文档

36 存储过程/触发器/过程语言 有（SQL 脚本/存储过程+调度查询）

  • 多语句脚本、存储过程（procedures），scheduled queries 定时调度 官方文档。
  • 去 O 迁移 PL/SQL 需改写 社区共识。

37 约束与数据完整性 部分支持（PK/FK 信息性不强制）

  • 主键/外键为 not enforced 信息性约束 官方文档。
  • 靠上游保证，错误声明影响优化 社区共识。

38 分析 SQL 完备性 有（分析 SQL 强项，函数极全）

  • 窗口函数、CTE、PIVOT、ML 函数，分析 SQL 为强项 官方文档。
  • 方言（GoogleSQL）与标准 SQL 差异，迁移注意 社区共识。

39 被遗忘权与数据擦除 部分支持

  • 删除靠 DML DELETE，无原生擦除工作流 官方文档
  • Time travel（7 天）与快照使被删数据在窗口期内可恢复 官方文档
  • 长期备份与导出表延长残留面 社区共识
  • 无擦除证明 社区共识

40 数据血缘与目录集成 有

  • Dataplex 自动采集列级血缘，Data Catalog 统一发现 官方文档。
  • 血缘覆盖查询/作业全链路 官方文档。

41 存算分离 vs 存算一体 有

  • Colossus 分布式存储 + Dremel 计算，存算分离的开创者 官方文档。
  • 计算资源按 slot 弹性，与存储完全解耦 官方文档。

42 多模能力 部分支持

  • JSON、GEOGRAPHY、BigQuery ML，VECTOR_SEARCH 有限支持 官方文档。
  • 无原生全文/图引擎 社区共识。

43 FinOps 成本可观测性 有

  • dry run 可预估查询扫描量再执行，是成本可观测的标杆实践。官方文档
  • INFORMATION_SCHEMA 按作业/用户归因 slot 与字节用量，custom quotas 限流，预算告警完整。官方文档
  • 账单可导出 BigQuery 做细粒度 FinOps 分析。社区共识

44 驱动与多语言生态 有

  • 官方 Python/Java/Node/Go 客户端库 + REST API 官方文档。
  • JDBC/ODBC 靠 Simba 官方合作驱动 官方文档。
  • dbt 等数仓工具链完备 社区共识。

45 物化视图 有

  • 物化视图增量刷新、查询自动改写 官方文档。
  • 需基表分区对齐等前提，不满足则不增量 官方文档。

46 支持跨云 无（GCP 绑定，无跨云）

  • 仅 GCP，无其他云版本 官方文档。
  • 跨云用 BigQuery Omni 读其他云数据，但计算仍在 GCP 侧 官方文档。
  • 迁出靠导出到 GCS，无跨云复制 社区共识。

47 热点数据更新能力 部分支持

  • 无行锁概念；并发原语是服务端的 DML 调度：每表最多 2 条并发变异 DML（UPDATE/DELETE/MERGE），超出的排队（上限 20 条），每表每 10 秒最多 25 条 DML 官方文档。
  • 排队超 7 小时未执行或超 20 条排队上限的语句直接失败；内核不重试，重试与削峰由应用负责 官方文档。
  • 热点更新天然被串行化：同一行的高频 UPDATE 在队列里排队执行，吞吐上限即配额；代价形态是费用而非锁——按需计费下 UPDATE 按"引用列扫描字节+全表所有列字节"计费，宽表热点更新极贵 社区共识。
  • 未找到官方命名或文档化的热点行机制的证据；配额/排队系统本身就是限流器，超过即失败而非降级 待验证。
  • 推荐模式是 insert-only 建模 + Storage Write API 流式写入 + 周期性 MERGE 合并；代价是流式写入费用、去重逻辑复杂度与读取侧的短暂不一致窗口 社区共识。

招牌能力

写法要求：每个特性 = 它是什么 + 为什么是真本事 + 推到边缘会发生什么。

  1. Serverless 零运维：没有集群这个概念 真本事：查询来了自动分配 slot，查完释放；用户永远不用回答"买多大集群"这个问题。 边缘真相：免的是运维，不是账单——slot/扫描/存储三项照计；slot 争抢排队时，"无集群"意味着你连"加机器"这个选项都没有，只能调预留。
  2. 按扫描/slot 双计费：一种引擎两种买法 真本事：波动负载按扫描付（不用为闲置买单），稳态负载买 slot（可预测）；同一项目下可按 workload 拆分计费模式。 边缘真相：选错模式差出几倍账单；Editions 自动扩缩按分配计费，短查询密集场景可能反而不如按需；这是 BigQuery 选型中最需要 POC 实测的一环。
  3. BigQuery ML：SQL 里跑机器学习 真本事：CREATE MODEL 一条 SQL 训练线性回归、DNN、时序预测，特征工程与 serving 都在数仓内；Vertex AI 联动做深度定制。 边缘真相：模型复杂度上限不如专用 ML 平台；大模型训练按 TiB 另计费，账单要单独建模；"SQL 能跑"不等于"效果够用"。
  4. BigQuery Omni：引擎去数据所在处 真本事：在 AWS/Azure 本地跑 BQ 引擎查 S3/Blob，数据不动；跨云 join 一条 SQL 搞定。 边缘真相：Omni 扫描加价 + 跨云传输费，大扫描场景下"不动数据"可能比"搬数据"更贵；本质是查询方案，不是多云部署方案。
  5. BI Engine：仪表盘的内存加速层 真本事：高频小查询走内存，亚秒返回，BI 体验质变。 边缘真相：按内存容量另计费；加速的是"重复查询模式"，即席探索吃不到红利；容量配小了加速命中率低，配大了浪费。

深水区

以下每条 = 领域 + 机制一句话 + 推到边缘会发生什么 + 选型含义。证据类型已标注。

深水区一：按扫描计费——一个烂 SQL 的代价

  • 领域：成本模型。
  • 机制一句话：按需模式按查询扫描的 TiB 计费，单查询 10 MB 起步，缓存命中与报错查询免费。
  • 边缘行为：没做分区裁剪的 SELECT * 扫描全表，一个查询烧掉数天预算；BI 工具自动生成的宽表查询是重灾区。分区表 + 聚簇 + 只选必要列是保命三件套。
  • 选型含义：上线第一天就建查询治理：INFORMATION_SCHEMA.JOBS 按用户/查询排扫描量，设配额与告警；分析师培训"先 dry run 看扫描量"。
  • 来源：官方文档（计费）+ 社区实践。

深水区二：slot 治理——Editions 的必修课

  • 领域：成本与并发。
  • 机制一句话：Editions 按 slot 小时计费，自动扩缩按"分配"（非"使用"）计费，60 秒起步；三档版本功能差异大。
  • 边缘行为：10 秒的查询占 1 分钟 slot；毛刺负载下自动扩缩冲高 baseline，缩容滞后吃费用；Standard 版 slot 上限 + 无 BQML/列级安全，选错版本=功能天花板。旧 flat-rate 已关停，老用户被迁移过一次，计费模型会变是历史教训。
  • 选型含义：POC 跑真实 workload 对比按需 vs 三档 Editions；baseline 设 0 起步观察，再按稳态水位买承诺折扣。
  • 来源：官方文档 + 社区实践。

深水区三：slot 争抢排队——"无集群"的另一面

  • 领域：并发。
  • 机制一句话：查询排队等 slot，无集群可加。
  • 边缘行为：月末结算/大促期间，ETL 大查询与 BI 小查询争 slot，互相排队；JOBS 视图里排队时间暴涨，但你没有"加机器"这个按钮，只能调预留、错峰或升级版本。
  • 选型含义：按 workload 拆预留（ETL 与 BI 隔离）；监控排队时间，POC 阶段就压测并发。
  • 来源：官方文档 + 社区共识。

深水区四：7 天时间旅行——比想象中短

  • 领域：备份恢复。
  • 机制一句话：历史版本查询窗口 7 天，之后靠 fail-safe（7 天，需走支持）与快照。
  • 边缘行为：合规审计要查 30 天前的数据状态？时间旅行帮不上，只能靠快照/导出策略；"删库跑路"式误操作超过 7 天才发现，恢复路径只剩快照。
  • 选型含义：快照/导出策略是必选项，不是可选项；合规场景把归档链路设计在前。
  • 来源：官方文档 + 社区共识。

深水区五：流式写入语义——去重是你的事

  • 领域：数据接入。
  • 机制一句话：Storage Write API 支持 exactly-once（需去重键），旧版 streaming insert 是 at-least-once。
  • 边缘行为：去重键设计不好，exactly-once 退化成"看起来对"；流式表的查询有短暂不可见窗口，实时仪表盘要接受分钟级延迟。
  • 选型含义：流式链路做端到端对账；延迟 SLA 写进设计文档，不要默认"实时"。
  • 来源：官方文档 + 社区共识。

深水区六：Omni 的真实成本——跨云不免费

  • 领域：多云成本。
  • 机制一句话：Omni 查询在 AWS/Azure 本地执行，按扫描加价，并产生跨云传输费。
  • 边缘行为：大数据量反复扫描的场景，"数据不动"的优雅背后是持续加价账单；算下来可能不如定期同步到 GCP 划算。cross-cloud connections（Preview）据称更省，但 Preview 不可用于生产承诺。
  • 选型含义：Omni 适合"偶发跨云探索"，高频场景做 TCO 对比（Omni 加价 vs 搬数据的一次性成本 + BQ 内查询）。
  • 来源：官方文档 + 社区共识。

深水区七：GCP 锁定——出去的路

  • 领域：厂商锁定。
  • 机制一句话：BigQuery 无开源/自建版本，GoogleSQL 方言、BQML、Omni 全是 GCP 私有能力。
  • 边缘行为：迁移出 GCP 意味着 SQL 改写（GoogleSQL→目标方言）、ML 链路重建（BQML→Vertex 外）、数据从 GCS 搬出（egress 费）；Analytics Hub 的共享关系也要重建。
  • 选型含义：选 BigQuery 就是选 GCP，决策前置问题与 Redshift 相同：未来 3–5 年是否可能多云。
  • 来源：社区共识。

客户经验

政策 Serverless 双轨计费

一句话
On-demand 按扫描字节计费（闲置零成本）+ Enterprise flat-rate slots 封顶可预测负载——同 workload 实测比 Snowflake 便宜 71%。
窄场景
分析师驱动的突发、不可预测查询（白天 9-5 有人、夜间周末接近零）；可预测的持续负载（定时 ETL + 稳定 BI）切 flat-rate。GCP 原生、无专职 FinOps 的中小数据团队——"不用调仓库大小、不用管自动 suspend"本身就是生产力。
机制
on-demand 按扫描字节（$6.25/TB）而非计算时长计费，列存只收实际碰的列；slot 模式是 Borg 集群上的可抢占容量池。关键在闲置成本为零：Snowflake 按 warehouse 按秒计费（auto-suspend 只能缓解不能消除），Databricks 按 DBU+EC2 计费。对"查询量波动大、夜间无人"的 workload，这是结构性成本优势，不是调优能追平的。
生产验证
LeanOps 独立第三方实测（2026）：某 SaaS Snowflake 账单 $108K/月，同 workload BigQuery 混合计费 $31K/月，省 71%、年省 $92.4 万，查询延迟因重做分区反而改善（https://leanopstech.com/blog/snowflake-vs-bigquery-vs-databricks-vs-redshift-cost-2026/）；SmarterX 从 Snowflake 迁 BQ 成本减半（Google 官方博客，厂商口径）（https://cloud.google.com/blog/products/data-analytics/smarterx-migrating-to-bigquery-from-snowflake-cut-costs-in-half）；Bonnier News 选 BQ over Snowflake，存储 $15/TB/月 vs $23/月（https://medium.com/bonniernewstech/why-we-picked-google-bigquery-over-snowflake-as-our-new-data-warehouse-solution-dddf7a441d5f）。
竞品差距
Snowflake warehouse 空转成本，24/7 连续 ETL 贵 3 倍；Databricks DBU+EC2 双重计费，同 workload 贵约 18-27%；Redshift provisioned 24/7 计费，只有 RA3+RI 在"连续可预测 ETL"这个窄场景能反超。"闲置零成本 + 按扫描字节计费"的组合 31 款中没有第二家。
证据等级
独立实测（LeanOps 2026，同 workload 四平台重跑）+ 社区共识；SmarterX 为厂商口径
最后核验
2026-10-01

内核 BI Engine 内存加速层

一句话
BigQuery API 前的 in-memory 加速服务：命中缓存的 dashboard 查询亚秒返回，且不消耗 slots、不产生 on-demand 扫描费。
窄场景
高频重复的 BI 仪表盘（Looker/Tableau/Power BI 直连 BigQuery）；已有 BQ 作数仓、不想再搭 Druid/Pinot/StarRocks serving 层的数据团队。
机制
按 GB 预留内存（1GB 起），查询自动路由（向量化执行 + 自适应缓存），不需要改 SQL。关键机制是计费隔离——走 BI Engine 的查询不烧 slots 也不计扫描字节，等于把"高频小查询"这个最烧钱的 workload 从主计费模型里摘了出去。
生产验证
开源 FinOps 工具 bq-finops-optimizer 把"BI Engine Acceleration Auditor"列为核心功能（查 INFORMATION_SCHEMA 的 BiEngineStatistics 找未被完全加速的查询），工具存在本身证明这是生产高频动作（https://github.com/mbettan/bq-finops-optimizer/blob/HEAD/PRD.MD）；Holistics 2026 指南将其列为选 BQ BI 工具时的必查集成项（https://www.holistics.io/blog/best-bigquery-visualization-tools/）。诚实备注：具名的独立生产案例较少（多为 how-to 而非 war story），此项证据弱于招牌 1。
竞品差距
Snowflake result cache 是 24 小时 + warehouse 本地 SSD 缓存，无"独立内存加速层 + 计费隔离"概念，高频小查询照样烧 credits；Databricks 有缓存但在 DBU 计费模型内；StarRocks/Doris 本身就是亚秒引擎（但那是自建/运维成本换来的）。云数仓里"官方出品的、不计费的 BI 加速层"是 BigQuery 独有的。
证据等级
官方文档（机制）+ 社区实践指南；具名生产案例较少，已标注
最后核验
2026-10-01

生态 GCP 数据引力：GA4/Ads 原生落地

一句话
Google 生态的数据（GA4、Google Ads、Firebase、Workspace）原生、无 ETL 地落在 BigQuery 里——这是 GCP 团队选 BQ 时真正的决策权重。
窄场景
营销/增长数据团队（GA4 事件流、Ads 投放数据每天自动进 BQ，无需建 pipeline）；已在 GCP 上、分析师"本来就在用 BigQuery 查 GA4"的公司；重度依赖 Google 第一方数据资产的团队。
机制
这不是内核能力，是生态引力。GA4→BigQuery 是官方免费 streaming export，Ads 数据经 transfer service 定时同步；对手要拿到同样的数据都要经过 ETL/API 抽取。Bonnier News 选型时写道："a lot of our analysts already had been using BigQuery in some contexts tipped the scales"——分析师用脚投票。
生产验证
Bonnier News（独立工程博客）：分析师习惯是 tipping factor，迁移后关掉了 Redshift 和 Elasticsearch 两个系统（https://medium.com/bonniernewstech/why-we-picked-google-bigquery-over-snowflake-as-our-new-data-warehouse-solution-dddf7a441d5f）；Weld 2026 迁移指南把"GA4 and Google Ads data lands natively in BigQuery"列为 Snowflake→BQ 迁移的首要战略理由（https://weld.app/blog/snowflake-to-bigquery-migration）；Back Market 从 Snowflake+Databricks 迁 BQ（Google 官方博客，厂商口径）（https://cloud.google.com/blog/topics/customers/back-market-migrates-from-snowflake-and-databricks-to-bigquery）。
竞品差距
这是 BigQuery 侧最硬的生态壁垒；Snowflake 靠 multi-cloud 对称优势回应（"BigQuery requires maintaining a Google Cloud presence"）。31 款中没有第二家能吃 Google 第一方数据流。
证据等级
社区共识 + 厂商口径（Back Market/SmarterX 为 Google 官方博客供稿）
最后核验
2026-10-01

避坑 On-demand 的"扫描税"

一句话
按扫描字节计费的另一面：无分区表上的探索性查询、失控的 autoscaling、拍脑袋定的 baseline slots，能让账单在"数据量没涨"的情况下爆炸。
窄场景
谁最容易中招——表没做分区/聚簇、分析师习惯 SELECT * 的团队；从 on-demand 切到 slot capacity、自以为"包月更便宜"的团队。
机制
三层税——扫描税（on-demand $6.25/TB，无分区的大表上一个探索查询就烧 $50-200）；autoscaling 陷阱（slot 自动扩容按 60 秒最小粒度计费，短查询脉冲触发反复的 60 秒计费周期）；baseline 浪费（24×7 计费，"Many teams set the baseline too high because it feels safer"）。
生产验证
Tata Group（GitHub 独立 FinOps 复盘）：数仓账单 $620k/月，"pricing is deceptive"；8 周治理（top 50 查询重构、物化视图、slot 预留）砍掉 $355k/月，降 57%（https://github.com/pratikdhanave/pratikdhanave.github.io/blob/HEAD/articles/28-bigquery-finops.md）；Atgeir 案例："Costs rose sharply under the slot-based model… Storage and ingestion rates had not changed."——账单涨了但数据量没涨（https://medium.com/@marketing_31622/bigquery-cost-optimization-case-study-a1b3af1b711d）。社区工程手册共识：10GB 表全扫描无感，同一张表长到 40TB 就是五位数年账单，代码一行没变。
竞品差距
Snowflake 的"闲置税"是 warehouse 空转，BigQuery 的"扫描税"是查询本身——两种计费模型各有各的坑；Snowflake 至少有 auto-suspend 一刀切的止损，BQ on-demand 下止损只能靠分区/聚簇/配额等"纪律"，对纪律差的团队更危险。官网营销"serverless 零运维"，用户社区的真实共识是"serverless 的账单需要 FinOps 学位"。这是招牌 1 的镜像：省钱的机制和烧钱的机制是同一个。
证据等级
社区共识 + 独立复盘（Tata Group 具名）
最后核验
2026-10-01

用户最买账的 5 点

  1. 零运维：开箱即查 PB 为什么是真的：无集群概念，SQL 提交即跑；Dremel 架构下 PB 级聚合秒到分钟。 边缘与失效条件：免的是运维不是账单；slot 排队时无"加机器"选项。 来源：官方文档 + 社区共识。观察版本：滚动发布（2026-09）。
  2. 双计费模式：波动与稳态各取所需 为什么是真的：按需适合探索，slot 适合稳态；同一组织可按项目拆分。 边缘与失效条件：选错模式差几倍；Editions 治理是持续功课。 来源：官方文档 + 社区实践。观察版本：滚动发布（2026-09）。
  3. BigQuery ML：数据不动就建模 为什么是真的：SQL 建模，特征与数据同处，免搬运；Vertex AI 接力深度场景。 边缘与失效条件：复杂模型上限不如专用平台；训练计费单独建模。 来源：官方文档。观察版本：滚动发布（2026-09）。
  4. GCP 生态一体：从 ingestion 到 AI 为什么是真的：Datastream/Data Transfer 进、BQ 算、Looker 出、Vertex AI 做 ML，IAM 一套身份。 边缘与失效条件：闭环=锁定；非 GCP 主力组织拿不到红利。 来源：官方文档 + 社区共识。观察版本：滚动发布（2026-09）。
  5. 免费额度：上手零门槛 为什么是真的：每月 1 TiB 查询 + 10 GiB 存储免费，学习/POC 零成本。 边缘与失效条件：免费额度只够"学习"，生产 workload 下第一天就超；别用免费额度推算生产账单。 来源：官方文档。观察版本：滚动发布（2026-09）。

吐槽清单

分类吐槽影响版本状态
成本按需模式下一次没做分区裁剪的大查询烧掉数天预算全版本open
成本Editions 自动扩缩按分配计费，短查询密集场景可能贵过按需全版本open
成本BI Engine、Omni、流式写入、ML 训练都是账单外单项，不知情=惊喜全版本open
并发slot 争抢导致查询排队，且无"加机器"选项，只能调预留/错峰全版本open
恢复时间旅行仅 7 天，长期审计要靠快照/导出策略全版本open
治理列级安全、CMEK 等高阶能力与 Enterprise Plus 版本绑定全版本open
锁定无开源/自建版本，深度绑定 GCP，多云组织慎选全版本open
资料中文社区内容少，深度调优与 slot 治理实战以英文为主全版本open
查询毫秒级点查、高并发小查询不是目标（BI Engine 只覆盖重复模式）全版本open
流式流式写入去重与延迟语义要显式设计，默认不"实时"全版本open
历史旧 flat-rate 关停迁移过一次，计费模型会变，架构要留余地历史事件open

判决

适合谁：GCP 主力用户——已有 GCS 数据湖、GCP 生态闭环需求；负载波动大（按需模式免容量规划）；SQL 即席分析为主；想"数据不动就建模"（BigQuery ML）；能接受 slot/扫描账单治理的团队。

不适合谁：多云/跨云部署组织；毫秒级点查、高并发 OLTP 式查询；"开了就行"不想做查询治理与 slot 规划的团队；对"账单可预测性"要求极高且不愿投入 FinOps 的组织；强监管要求本地化部署。

迁移成本：中等。从其他云数仓迁来，SQL 方言改写（GoogleSQL）+ ETL 链路重建是主要工作；Datastream/Transfer Service 覆盖主流源。从 Hadoop/Spark 迁来范式差异大。长期成本在查询治理与 slot 规划，不在迁移本身。

来源与待验证清单

  • 官方文档：Google Cloud BigQuery 文档（计费、Editions、Omni、BI Engine、时间旅行、Datastream、配额）。
  • 第三方分析：BigQuery release notes 镜像（2026-08 cross-cloud connections Preview）、社区成本优化实践（slot/扫描模型描述）。
  • 本轮明确未覆盖：各区域具体 slot/扫描目录价（易变，未引用绝对价格）、cross-cloud connections GA 时间——标待验证，未写入结论。
  • v1.0（2026-09-29）：首版建档。last_reviewed: 2026-09-29，评审对象为 BigQuery 滚动发布版本。