Google Cloud BigQuery 适合哪些业务，什么情况下不应该拿它代替关系数据库

很多企业第一次接触 Google Cloud BigQuery 时，很容易产生一个想法：既然 BigQuery 可以存储海量数据、执行复杂 SQL，而且不需要自己维护数据库服务器，那么是不是可以直接把原来的 MySQL、PostgreSQL 或其他关系数据库全部搬进去？

技术上能不能存数据，与架构上应不应该这么做，是两个不同的问题。

BigQuery 的核心定位是云端数据仓库和分析平台。它擅长的是对大量数据进行扫描、过滤、聚合、关联和统计，而传统关系数据库尤其是面向 OLTP 的系统，擅长的是大量短事务、单行或少量行读取、频繁更新、严格的业务事务以及低延迟在线请求。

两者都可以使用 SQL，也都可以保存结构化数据，但它们优化的工作负载并不相同。

如果把 BigQuery 当成一个“更大的 MySQL”，很容易在系统上线以后才发现，数据库虽然能够运行，整个应用架构却开始变得非常别扭。

BigQuery首先适合分析而不是交易

BigQuery 最典型的应用是 OLAP，也就是在线分析处理。

例如一家零售企业每天产生数百万甚至数亿条销售记录，管理层希望回答的问题可能是过去三年的销售趋势、不同地区的销售结构、不同商品类别的毛利变化、客户购买频率以及营销活动带来的转化情况。

这类查询往往需要扫描大量数据，然后进行 GROUP BY、JOIN、窗口函数以及各种聚合计算。

BigQuery 的列式存储和分布式执行架构就是针对这类任务设计的。

传统关系数据库也可以完成这些 SQL 查询，但当数据规模和并发分析任务不断扩大以后，专门的数据仓库通常更容易承担这种工作负载。

因此，判断一个业务是否适合 BigQuery，第一件事不是看数据到底有多少，而是看这些数据主要拿来做什么。

如果数据主要用于统计、报表、趋势分析、数据挖掘、日志分析、机器学习特征准备或者商业智能，BigQuery 往往非常合适。

如果数据主要用于“用户点击购买以后马上扣库存，然后生成订单，再修改账户余额”，这就已经进入完全不同的数据库问题。

列式存储为什么适合分析查询

传统 OLTP 数据库经常需要快速找到某一条记录。

例如：

SELECT *
FROM orders
WHERE order_id = 123456;

这种查询只需要找到一条订单。

而数据分析更可能是：

SELECT
region,
product_category,
SUM(amount) AS revenue
FROM sales
WHERE order_date >= '2026-01-01'
GROUP BY region, product_category;

第二种查询需要处理大量记录，并从中读取特定列进行聚合。

列式存储在这种工作负载下具有明显优势，因为系统不需要像传统行式存储那样为了计算一个指标而读取大量无关字段。

BigQuery 同时支持分区表和聚类等数据组织方式。合理设计分区和查询条件，可以减少需要处理的数据量。

但这并不意味着“用了 BigQuery，所有查询都会自动很快”。

查询设计、数据模型、分区、聚类、JOIN 方式、数据量以及并发情况仍然会影响实际性能。

日志和事件数据是BigQuery的典型使用场景

网站访问日志、应用日志、广告事件、IoT 数据、用户行为事件等数据，非常适合进入数据仓库。

这类数据具有几个共同特点：数据量大、持续产生、主要用于分析，而且历史数据通常具有长期价值。

例如一个 SaaS 平台每天产生大量用户事件：

login
page_view
search
download
purchase
api_call
error

业务团队可能希望分析过去一年不同客户的使用行为。

如果把所有事件都塞进负责在线交易的 PostgreSQL 或 MySQL，然后让 BI 报表每天扫描大量历史记录，分析任务就可能与线上交易争夺数据库资源。

把分析数据放进 BigQuery，可以让 OLTP 数据库负责在线业务，而数据仓库负责历史分析。

这也是企业经常采用“双数据库”架构的原因。

BigQuery可以和Cloud Storage配合使用

BigQuery 并不要求所有分析数据都首先进入传统数据库。

企业可以把大量原始文件存储在 Google Cloud Storage 中，再根据数据处理需求让 BigQuery 查询或处理相关数据。

Parquet、Avro 等格式特别适合分析型数据处理。

这种架构对于日志、数据湖、批处理以及数据交换非常有用。

但“Cloud Storage 加 BigQuery”并不自动等于完整的湖仓一体架构。

数据湖、数据仓库、数据处理引擎、元数据管理、数据治理以及事务能力涉及不同组件和不同架构设计。

企业应该根据实际需求决定数据到底应该保存在哪里，以及什么数据需要进入 BigQuery 的原生分析存储。

BigQuery也支持实时和近实时数据分析

原稿把 BigQuery 描述成只能做每天一次的数据更新，这也已经过时。

BigQuery 可以接收持续产生的数据，也可以与 Dataflow、Pub/Sub 等 Google Cloud 数据处理服务结合，建立流式数据管道。

例如广告平台可以不断写入曝光、点击和转化事件，然后让分析团队持续观察广告效果。

金融企业也可以把市场事件、交易事件和风险数据持续送入分析平台。

但这里需要区分“实时分析”和“实时交易”。

一个系统可以在几秒或几十秒级别看到新的分析数据，并不意味着它适合承担支付系统那种毫秒级交易事务。

数据进入分析平台的延迟要求，与交易数据库的事务要求是两件事情。

BigQuery并不是不能做事务

这是原稿需要重点修正的地方。

不能简单说“BigQuery采用最终一致性，所以不能满足 ACID”。

BigQuery 本身提供事务能力，并支持多语句事务等功能。

但这并不意味着 BigQuery 就应该拿来替代所有 OLTP 数据库。

数据库的选择不能只看“有没有 ACID”四个字，而应该看事务模式、并发模型、更新频率、数据访问方式以及业务延迟要求。

例如订单系统可能需要在一个事务中修改订单状态、库存记录和其他业务数据，并且大量用户同时执行类似操作。

这种系统通常更适合专门的 OLTP 数据库。

BigQuery 的设计目标依然是分析型工作负载，而不是把每一次用户点击都变成一个数据仓库事务。

高频小查询是BigQuery不适合直接替代关系数据库的重要信号

假设一个 SaaS 网站有一张 users 表。

用户每次打开页面，都需要执行：

SELECT
id,
name,
email,
plan
FROM users
WHERE id = ?;

这类请求可能每秒出现成百上千甚至更多次。

如果每一次网页请求都直接把 BigQuery 当成在线用户数据库，架构就开始偏离它最擅长的工作负载。

这种场景通常更适合 Cloud SQL、AlloyDB、Spanner 或其他针对在线事务设计的数据存储方案，具体选择取决于规模、一致性、可用性以及全球分布需求。

BigQuery 应该更适合回答：

“过去30天所有客户的活跃用户数量是多少？”

而不是承担：

“这个用户刚刚登录，现在请马上把他的账户记录取出来。”

两者都是 SQL，却属于完全不同的系统问题。

频繁更新的数据也需要谨慎

数据仓库最擅长的是大量分析数据。

如果一张表不停进行单行 INSERT、UPDATE、DELETE，并且每一次修改都直接服务于在线业务，就需要认真评估这种设计。

例如库存系统：

库存100件
用户A购买2件
库存变成98件
用户B同时购买3件
库存变成95件

真正复杂的地方并不是 SQL 能不能写出来，而是并发事务、锁定、冲突处理、约束以及业务规则。

如果多个请求同时修改同一个业务对象，数据库需要提供适合这种工作负载的一致性和并发控制能力。

这正是 OLTP 数据库长期优化的领域。

所以不能简单用“BigQuery 能执行 UPDATE”来推导“BigQuery 适合当在线业务数据库”。

SQL 功能相同，不代表数据库工作负载相同。

不要把查询复杂度简单归结为有没有索引

原稿还有一个容易误导的地方，就是把 BigQuery 和关系数据库之间的区别简单描述成“BigQuery 没有索引，所以复杂查询不如传统数据库”。

现代 BigQuery 的数据组织和查询优化机制远比这个说法复杂。

BigQuery 有分区、聚类、缓存、查询优化以及分布式执行机制。

传统关系数据库则可以通过 B-tree、Hash、GiST、GIN 等不同类型的索引以及查询优化器针对特定访问模式进行优化。

两套系统的优化思路不同。

对于一个需要快速查找少量记录的在线请求，传统数据库索引往往非常有效。

对于需要扫描大量历史数据并完成复杂聚合的分析任务，分布式列式数据仓库更有优势。

所以数据库选择不能只问“有没有索引”，而应该问“主要查询模式是什么”。

Cloud SQL、AlloyDB、Spanner和BigQuery不是简单的替代关系

Google Cloud 的数据库产品应该按照业务工作负载理解。

Cloud SQL 主要适合托管 MySQL、PostgreSQL 和 SQL Server 等关系数据库工作负载，适合大量传统企业应用迁移到云端。

AlloyDB 针对 PostgreSQL 兼容性以及高性能数据库工作负载进行了进一步优化。

Spanner 则针对全球分布式关系数据库场景，提供强一致性以及水平扩展能力，适合对全球规模、可用性和一致性都有较高要求的业务。

BigQuery 则主要解决数据仓库和分析问题。

所以一个企业完全可以同时使用它们。

例如：

在线业务数据使用 PostgreSQL
分析数据进入 BigQuery
原始日志和数据文件保存到 Cloud Storage
流式数据通过 Pub/Sub 和 Dataflow 处理

这并不意味着系统设计失败。

相反，这种按照工作负载分工的架构往往比强行让一个数据库承担所有任务更加合理。

BigQuery成本也不能简单理解成按查询量收费

BigQuery 的成本模型并不是简单一句“按照查询次数收费”就能概括。

不同 BigQuery 能力涉及不同的计费方式，查询处理、存储以及容量型计算等都有各自的计费模型和优化方式。

因此，企业评估成本时不能只看“执行了多少条 SQL”。

真正应该关注的是每次查询处理的数据量、查询频率、数据存储规模、计算容量、工作负载峰值以及是否存在大量重复扫描。

一个写得很差的 SQL，即使只执行一次，也可能处理大量数据。

一个设计良好的分析系统则可以通过分区、聚类、合理的数据模型以及查询优化降低处理成本。

因此，BigQuery 成本优化首先是数据和查询工程问题，然后才是简单的价格比较。

不要为了分析而把生产数据库直接暴露给分析查询

很多企业最初会采用一种非常直接的方案：业务数据全部存 PostgreSQL，然后报表系统直接连接生产数据库。

数据量小时，这种方式确实简单。

随着业务增长，问题很快出现。

月底财务报表可能运行一个很重的查询。

市场部门可能同时运行客户行为分析。

BI 系统又不断刷新仪表盘。

与此同时，线上用户还在正常登录、搜索、下订单。

如果分析查询与在线事务共享同一个数据库资源池，分析负载就可能影响线上业务。

这时候把数据同步到 BigQuery 就具有明显价值。

生产数据库负责交易。

BigQuery 负责分析。

两边通过数据管道进行同步。

这样系统边界更加清楚。

数据同步的难点不是把数据复制过去

企业从 PostgreSQL、MySQL 等 OLTP 数据库向 BigQuery 同步数据时，需要考虑 CDC，也就是 Change Data Capture，以及数据延迟、重复事件、删除记录、Schema 演进和失败重试。

例如业务数据库已经删除一条订单记录，分析仓库是否也应该删除？

如果业务数据库修改了一条客户信息，BigQuery 多久应该看到变化？

如果数据管道失败了半小时，恢复以后怎样补数据？

如果一个事件重复发送两次，分析结果会不会被计算两次？

这些才是数据仓库工程真正需要解决的问题。

因此，所谓“把数据库同步到 BigQuery”，并不是简单写一个定时 INSERT 就结束。

对于成熟企业，通常需要根据数据新鲜度要求选择批处理、流处理或者 CDC 架构。

什么时候应该选择关系数据库

如果业务具有以下特征，就应该优先考虑关系数据库或者其他 OLTP 存储方案。

第一，系统大量处理短事务。

第二，用户请求要求低延迟读取少量数据。

第三，数据需要频繁 INSERT、UPDATE、DELETE。

第四，多个业务操作需要明确的事务边界。

第五，业务逻辑严重依赖行级或者对象级状态变化。

第六，应用框架已经围绕 PostgreSQL、MySQL 等关系数据库建立完整生态。

第七，数据库直接位于 Web API、后台服务或者核心交易系统的请求路径上。

这些条件并不意味着 BigQuery 完全不能参与，而是意味着 BigQuery 不应该成为这些在线事务的唯一数据存储。

什么时候BigQuery更有优势

如果业务的主要需求是历史数据分析、商业智能、日志分析、用户行为分析、广告数据分析、IoT 数据分析、数据科学或者大规模聚合查询，那么 BigQuery 的优势会更加明显。

尤其当数据规模持续增长，而且分析人员、BI 工具、数据科学任务和机器学习工作负载需要共享同一套分析数据时，数据仓库的价值会逐渐体现出来。

这时候企业真正需要解决的问题已经不是“哪一种数据库最快”，而是怎样建立一套稳定的数据平台。

一个成熟的SaaS往往同时需要两套数据库思维

以 SaaS 平台为例。

用户注册、登录、订阅、付款、权限、组织关系、API Key 等核心业务数据通常属于在线事务。

这些数据需要严格的业务约束和可靠的事务处理。

用户行为日志、API 调用记录、访问日志、产品使用统计、客户活跃度以及历史经营数据则属于分析型数据。

这些数据需要长期保存并进行大量聚合。

如果强行让一个数据库同时承担这两种工作负载，系统规模扩大以后，优化难度会明显增加。

因此，更合理的思路往往是让 OLTP 数据库承担在线业务，让 BigQuery 承担分析任务。

两者之间通过可靠的数据管道建立数据流动。

这种设计不是简单地“增加一个数据库”，而是在系统架构中明确区分交易数据和分析数据。

BigQuery最值得理解的是它的边界

BigQuery 的价值不是“比 MySQL 更高级”。

它解决的是另一类问题。

当企业开始面对海量历史数据、复杂 SQL、跨业务数据分析、日志分析、BI 报表以及数据科学任务时，传统在线数据库不一定应该继续承担全部工作。

BigQuery 可以把分析工作从核心交易系统中分离出来，让数据仓库承担大量扫描和计算任务。

但如果企业需要的是用户登录时快速读取一条记录、订单提交时完成事务、库存扣减、支付状态更新或者权限数据的实时修改，那么把 BigQuery 当成传统关系数据库的替代品，通常并不是合理的架构选择。

数据库选型最终应该从业务工作负载开始，而不是从产品名称开始。

需要事务，就研究事务模型；需要低延迟在线访问，就研究 OLTP；需要大规模历史分析，就研究 OLAP；需要全球分布式关系数据，就评估 Spanner 等方案；需要 PostgreSQL 兼容的托管数据库，就评估 Cloud SQL 或 AlloyDB；需要大规模数据分析，就评估 BigQuery。

企业云架构真正成熟的标志，并不是所有数据都塞进同一个数据库，而是让不同类型的数据进入适合自己的系统。

BigQuery 最适合成为企业的数据分析引擎和数据仓库，而不是为了追求“云上统一数据库”而强行取代关系数据库。对于绝大多数同时拥有在线业务和数据分析需求的 SaaS、金融、电商、媒体和企业应用，BigQuery 与关系数据库更适合形成分工明确的组合，而不是互相取代。