01 它是干嘛的
BigQuery 是云端的数据仓库，专门回答「从海量数据里算出统计结论」这一类问题。它不需要你先买机器、建索引、做调优，只要把数据导入、写一句查询语句，它自己分配算力把活干完。它解决的痛点是：传统数据仓库又贵又慢，扩容要提前几周规划，分析师经常要排队等资源。
02 为什么会有它
2010 年之前：查一次全量数据，要排队等到第二天
过去企业分析数据，要专门采购一批昂贵的一体机，价格以百万计。这批机器的容量是固定的，数据涨了要提前几个月申请采购、等设备到货、做迁移；分析师写一条复杂查询，常常要跑几十分钟甚至几小时，跑之前还得先问 DBA 有没有空闲。
为了让查询快一点，得建索引、做分区、调优化参数，这些都是专门技能，只有少数人能掌握。业务部门想临时看一个数据，往往要提需求、排队、等排期，等报告出来，商机早就过去了。
谷歌内部早就有一套处理海量日志的架构，可以在几秒内扫过万亿级别的数据。他们把这套能力做成产品对外开放，就是 BigQuery。它的思路是把难的部分全部藏起来：机器不用你买，容量随数据自动伸缩，查询用大家都熟悉的 SQL 语言。分析师第一次能像用 Excel 一样，直接对几百亿行数据下命令，几秒钟拿到结果，这在以前是不可想象的。
03 它怎么工作
关键有三点：数据按列分开存放，查询时只读需要的列；计算和存储分离，算力随时加；一条查询被拆成许多小任务，分给成千上万台机器同时干，最后汇总。
几百亿行数据，为什么几秒就能查完：列式存储与分布式执行
- 1① 数据按列组织存储
同一列的值连续存在一起。查询只用到少数几列时，就只需要读这几列的数据，跳过大量无关内容，这是速度快的第一层原因。
- 2② 计算与存储分离
数据静静地存在存储层，算力在使用时临时拉起。不用为了跑一次大查询而长期养着几百台机器，用完即释放。
- 3③ 查询被拆成大量小任务
一条语句被拆解成许多可以并行执行的小块，同时分发到成千上万台机器上处理，各自算自己那一部分。
- 4④ 各节点并行扫描
每台机器只读取自己负责的那部分列数据并做初步聚合，机器数量多、列读得少，使得扫描时间被压到很短。
- 5⑤ 汇总返回结果
各节点的中间结果被逐层合并，最终算出完整答案返回给用户。整个过程对用户透明，看到的只是「几秒钟出了结果」。
04 谁在用它
统计每天的订单、活跃用户、留存率，运营人员自己写语句查，不必等技术团队排期出报表。
把应用产生的海量日志导入后集中分析，排查异常、定位问题、观察功能使用情况。
业务数据持续导入，配合可视化工具做成实时看板，管理者随时查看关键指标。
在数据仓库里直接完成数据清洗与特征计算，供模型训练使用，避免数据来回搬运。
把数据集授权给不同团队或外部合作方，在统一口径下各自分析，减少数据口径打架。
05 怎么用
会写基本 SQL 就能上手；导入数据、控制成本是需要额外学习的两件事。
- 01在云控制台创建一个数据集，它是容纳表与查询结果的容器，需要指定数据存放的地区。
- 02把数据导入：可以从文件直接上传，也可以从其他数据库、日志服务持续流入。
- 03在网页查询框里写 SQL 语句直接查询，结果会显示在下方并可导出或另存为表。
- 04用分区与簇化按时间或常用字段组织大表，让查询只扫描相关数据，显著降低费用。
- 05为团队设置权限与预算上限，监控有哪些查询消耗最多，及时优化成本最大的语句。
-- 统计每个渠道在最近 7 天带来的订单数与金额
SELECT
channel,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM
`my_project.sales.orders`
WHERE
order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY
channel
ORDER BY
total_amount DESC;避坑提示
- !计费主要看「查询扫描了多少数据」，写语句时只选需要的列、加上时间范围过滤，能省下大量费用。
- !大表务必按时间分区，否则每次查询都会扫描全部历史数据，又慢又贵。
- !先用少量数据抽样验证语句逻辑，再对全量数据运行，避免一条错误语句烧掉大笔费用。
06 关键概念
- 数据仓库
- 专门为统计分析准备的数据库，适合一次性读取大量数据做汇总，而不是日常逐条增删改。
- 列式存储
- 按列而不是按行存放数据，查询只读需要的列，因此分析类查询特别快。
- Serverless
- 你不需要预先购买和运维服务器，平台按需自动分配算力，用完即释放。
- 分区表
- 把一张大表按时间等维度切成许多小块，查询时只需扫描相关的块，又快又省。