分析型数据库入门：ClickHouse、DuckDB、Snowflake、BigQuery

一个视频，讲透分析型数据库，不用学几个月。

第一章 - 分析型数据库是什么

这一个视频把分析型数据库这一类讲完，对比四个代表：{{ClickHouse}}、{{DuckDB}}、{{Snowflake}}、{{BigQuery}}。

一句话：分析型数据库（OLAP）为{{扫描海量数据做聚合}}而生，回答"十亿行数据能不能马上算完"，而不是"一笔业务能不能马上完成"。

和 OLTP 的分工

OLTP（在线事务）：MySQL、PostgreSQL -> 单行增删改查，快
OLAP（在线分析）：ClickHouse、Snowflake -> 大规模扫描聚合，快

这一类数据库的共同点

• {{列式存储}}：按列存，聚合时只读需要的列。
• 擅长 SUM / AVG / GROUP BY 全表扫描。
• 不适合高频单行更新。

本章小结

OLAP 是"算得快"的库：列式存储 + 向量化执行，专门喂分析报表。

第二章 - 列式存储：为什么分析快

行式 vs 列式

行式按行存，列式按列存。分析时常常只要几列、扫千万行：

行式（按行存）:  [id, name, age, city] [id, name, age, city] ...
列式（按列存）:  id 列全部 | name 列全部 | age 列全部 | city 列全部

算"平均 age"时，列式只读 age 那一列，跳过其余所有列，还方便压缩和向量化。

向量化执行

一次 CPU 指令处理一批数据（SIMD），而不是一行行处理，分析速度再上一个量级。

本章小结

列式存储 + 向量化执行 = 分析查询快几个数量级的两大根基。

第三章 - ClickHouse：MergeTree 与列式分析

是什么

{{ClickHouse}} 是开源的列式分析库，用 {{MergeTree}} 引擎家族，向量化执行，单机就能扫几十亿行。

CREATE TABLE events (
  time    DateTime,
  user_id UInt32,
  amount  Float64
) ENGINE = MergeTree
ORDER BY time;

SELECT user_id, sum(amount)
FROM events
WHERE time > now() - INTERVAL 1 DAY
GROUP BY user_id;

核心：MergeTree

数据按 ORDER BY 键排序写入，后台合并小文件（Merge），范围查询极快。

本章小结

ClickHouse 靠 MergeTree + 列式 + 向量化，是开源 OLAP 的标杆。

第四章 - DuckDB：嵌入式 OLAP

是什么

{{DuckDB}} 是"分析版的 SQLite"：进程内运行、零配置，直接读 Parquet/CSV，专为本地数据科学做分析。

import duckdb
con = duckdb.connect()
con.execute("SELECT city, avg(amount) FROM 'orders.parquet' GROUP BY city")

特点：就地分析文件

不用把数据导入数据库，直接 SQL 查磁盘上的 Parquet、CSV、JSON 文件。

本章小结

DuckDB 让"单机分析本地文件"像 SQLite 一样简单——数据科学家的随身分析引擎。

第五章 - Snowflake：云数据仓库

是什么

{{Snowflake}} 是云上的数据仓库，核心是{{存算分离}}：存储和计算各自独立伸缩，按用量付费。

SELECT category, sum(sales)
FROM orders
GROUP BY category;

存算分离

存储层（便宜、无限扩） <-> 计算层（虚拟仓库，按需开、按秒计费）

闲时把计算仓库关掉只付存储费，忙时开大仓库跑查询。

本章小结

Snowflake 把存储和计算拆开，弹性伸缩、按量付费，是企业级云数仓的代表。

第六章 - BigQuery：谷歌的无服务器仓库

是什么

{{BigQuery}} 是 Google Cloud 的{{无服务器}}数据仓库，不用管任何节点，写 SQL 就查，按扫描数据量计费。

SELECT user_id, sum(amount)
FROM `project.dataset.orders`
GROUP BY user_id;

特点：全托管 + 超大规模

• 无服务器：没有要运维的集群。
• 自动扩容：单条查询可扫 PB 级数据。
• 和 GCP 生态（GCS、Data Studio）天然打通。

本章小结

BigQuery 是无服务器数仓：写 SQL 查海量数据，运维和扩缩容都交给谷歌。

第七章 - 四者对比与选型

一句话选型

本地分析选 {{DuckDB}}，自建海量日志选 {{ClickHouse}}，企业云数仓选 {{Snowflake}}，GCP 上免运维选 {{BigQuery}}。

本章小结

四个 OLAP 分工不同：DuckDB 嵌入、ClickHouse 自建、Snowflake/BigQuery 云托管。

第八章 - 用 Python 连接

ClickHouse：clickhouse-connect

import clickhouse_connect
client = clickhouse_connect.get_client(host='localhost')
res = client.query("SELECT sum(amount) FROM events")

DuckDB：内置模块

import duckdb
print(duckdb.sql("SELECT avg(amount) FROM 'orders.parquet'").fetchall())

Snowflake / BigQuery：各自 SDK

import snowflake.connector          # Snowflake
from google.cloud import bigquery   # BigQuery

本章小结

各库有各自客户端，但都是"连上 -> 写 SQL -> 取结果"，SQL 是通用语言。

第九章 - 什么时候用 OLAP

适合

• 报表、BI、日志分析、海量数据聚合。
• 扫描大表做 SUM / GROUP BY，不是高频单行更新。

不适合

• 高频单行增删改 -> OLTP（MySQL/PostgreSQL）。
• 事务强一致 -> 关系型。

本章小结

OLAP 赢在"大规模聚合扫描"，输在"单行事务更新"——分析归分析，业务归业务。

总结

• 核心回顾：OLAP 靠列式存储 + 向量化执行做大规模聚合；ClickHouse 用 MergeTree 自建极致速度，DuckDB 嵌入式直接读文件，Snowflake 存算分离做云数仓，BigQuery 无服务器全托管。
• 学习路线：先本地 DuckDB 读 Parquet 练 SQL -> 再 Docker 起 ClickHouse 对比 -> 最后了解 Snowflake/BigQuery 的云用法。
• 推荐练习：① 用 DuckDB 直接对一份 Parquet 文件做 GROUP BY 聚合；② 用 ClickHouse 建 MergeTree 表灌百万行数据，跑聚合看耗时；③ 对比 OLTP（SQLite）和 OLAP（DuckDB）对同一份数据做 sum/group 的速度。