OLAP 重新定义：2026 年的分布式格局
十年前，OLAP 的代名词是 Vertica、Redshift、Snowflake 等中央集权式大规模分布式集群。2026 年的面貌已截然不同。无服务化的 ClickHouse Cloud 实现了按秒级别的弹性伸缩，DuckDB 则以单进程处理数百 GB 数据，在浏览器内通过 WASM 运行的 DuckDB 直接从前端查询 S3 上的 Parquet 文件，这一架构已成为现实。
KGA 在 2026 年 Q1 收到的 23 个数据分析基础设施咨询中，从一开始就选择「将一切集中于 Snowflake/BigQuery」架构的只有 9 个。其余 14 个选择了「以中央数据仓库（Snowflake 或 BigQuery）与现场轻量级 OLAP（ClickHouse/DuckDB）分工协作」的混合架构。事实上，按用途分工后，总成本削减 30%～50% 的案例十分常见。
ClickHouse Cloud 在 2026 年的定位
ClickHouse Cloud 凭借 2024 年的无服务化支持、2025 年的 SharedMergeTree（计算与存储完全分离）以及 2026 年的 Query Condition Cache 与 Parallel Replica 自动化，在运维便利性与性能两方面均达到了最高水准。KGA 的广告投放客户每秒摄入 200 万事件，同时保持仪表盘秒级响应，而成本比以往降低了 40%。
ClickHouse 在以下所有特性均具备时表现最为突出。
- 仅追加的时序/事件日志写入：广告曝光、游戏事件、IoT 遥测、APM 追踪、网站分析。
- 以单表或少数表为主的聚合查询：GROUP BY、SUM、COUNT、PERCENTILE。
- 低延迟的交互式仪表盘：要求 P95 响应时间在 500ms 以内的场景。
- 高基数维度的聚合：按 user_id、session_id、trace_id 轴进行分析。
反之，多表 join 频繁、update/delete 高发、以即席探索为主的工作负载，用 Snowflake/BigQuery 更为直接。2026 年的 ClickHouse 通过 Parallel Hash Join、Grace Hash Join 的成熟大幅提升了 join 能力，但在 10 张以上表的星型模式中，其他 MPP 仍更稳定。
DuckDB 1.2 的冲击
DuckDB 是「进程内 OLAP 数据库」，可作为库嵌入应用程序。1.2 版本有三项重要进化。
HTTP server 模式：原本仅以库形式存在的 DuckDB，现在可以作为 HTTP 服务器启动。从 Python/Go/TypeScript 通过 HTTP 发送查询、以 JSON/Arrow IPC 接收结果的架构已经稳定。作为轻量级数据 API 的后端，比 ClickHouse 的构建速度更快。
Iceberg/Delta 读写：1.1 版本实现了 Iceberg 读取，1.2 版本实现了 Iceberg 写入。可从 DuckDB 直接读写 S3 上的 Iceberg 表，实现对数据湖的轻量访问。
WASM 性能：浏览器内运行的 DuckDB-WASM 通过 SIMD 优化与并行 Worker 支持，已能发挥桌面版 60%～70% 的性能。Observable、Evidence.dev、Perspective 等 BI 工具均构建于此，「仅在浏览器内分析 100GB Parquet」得以完全在客户端完成。
KGA 的政府客户使用 DuckDB-WASM 实现了开放数据的可视化仪表盘。浏览器直接读取 S3 上的公开 Parquet，所有聚合与可视化均在客户端处理。服务器端计算资源为零，扩展成本实质上也为零，通过了 100 万用户的负载测试。
MotherDuck 的商业化落地
MotherDuck 是以 DuckDB 为基础的托管服务，从 2024 年 Beta 版，到 2025 年 GA，再到 2026 年，已在中小规模分析工作负载中作为 Snowflake/BigQuery 的现实替代方案站稳脚跟。
最大特点是「混合执行」。查询的一部分（文件读取、过滤）在云端执行，其余部分在本地 DuckDB 执行，从而在最小化数据传输的同时充分利用本地计算资源。对于 Python 开发者而言，在 notebook 内 attach motherduck 后，即可无缝 JOIN 云端的大型表与本地 CSV/Parquet，这种体验在其他地方难以获得。
定价也颇具吸引力：10GB 以下数据可在免费额度内运行；100GB～1TB 规模的分析，成本约为 Snowflake 的五分之一。但对于超过 10TB 的规模或并发用户超过 50 人的仪表盘用途，Snowflake/ClickHouse 更为合适。
Turso 与 LibSQL 的独特路线
Turso 是基于 SQLite 分支 LibSQL 的边缘分布式 SQL 数据库，严格来说偏向 OLTP 而非 OLAP，但 2026 年引入的 Analytics 扩展（类似 AlloyDB Columnar，并用行式与列式存储的机制）使其也能应对中小规模分析。
其特点在于可将数据库复制到全球各地边缘节点的多租户架构。从 Cloudflare Workers 或 Vercel Edge Functions 查询的延迟可达个位数毫秒。在 IoT 设备制造商或 SaaS 的仪表盘场景中，当需要解决地理分布用户的响应性能问题时，这一方案尤为适用。
作为纯 OLAP 用途，其性能不及 DuckDB/ClickHouse，但在「希望以单一数据库兼顾 OLTP 和轻量分析」或「需要边缘部署」的场景中，是首选方案。
分层存储与冷热数据设计
- 年 OLAP 运维中不可或缺的是分层存储（tiered storage）。ClickHouse Cloud 通过 SharedMergeTree 将 S3/GCS 作为主存储、本地 NVMe 作为缓存层的结构设为默认。Snowflake/BigQuery 结构类似，但 ClickHouse 的优势在于可以显式调优缓存策略。
KGA 的广告客户采用了三层设计：「过去 30 天 = 热（NVMe 缓存常驻）、31～180 天 = 温（S3，按需加载至 NVMe）、181 天以后 = 冷（S3 Glacier，查询时直接走 Athena）」，将存储成本削减了 80%。查询性能上，热/温层实质相同，仅冷层慢 10～20 倍，但需要交互式访问 180 天以上历史数据的需求极为罕见，因此可以接受。
日语工作负载的陷阱
以下列举日本企业数据分析特有的五个问题。
1. 时区：JST（UTC+9）与 UTC 混用导致日期边界差一天的 bug，在 2026 年仍频繁出现。ClickHouse 使用 `DateTime64` 的 `'Asia/Tokyo'` 时区参数明确指定，BigQuery/Snowflake 则彻底执行「UTC 存储 + 展示时转换」策略。DuckDB 自 1.2 版本引入 `TIMESTAMPTZ` 类型后趋于稳定。
2. 多字节字符与排序规则：包含全角空格、半角/全角字母数字、旧字体的客户名/商品名比较，仅靠 UTF-8 字节比较是不够的。ClickHouse 通过 ICU 扩展处理，DuckDB 通过 NFKC 规范化函数处理。用作聚合键时，在数据摄入时提前做规范化处理是铁律。
3. 汉字数字与和历：在政府机构项目中，难以避免处理「令和六年三月」这类表达。不要在 SQL 层面解决，而应在摄入时将其规范化为 ISO 8601 存储，这才是健全的做法。
4. CP932/Shift_JIS 混入：从遗留核心系统导出的 CSV 中仍会出现。DuckDB 的 `read_csv` 自 1.2 版本起正式 GA 地支持 `encoding` 参数。ClickHouse 通过 `INPUT` 函数进行转换。
5. 半角片假名：银行系统数据中至今仍存在，使用 NFKC 转换为全角后「ｶ」和「カ」变为相同值，但若原数据以半角作为键，则会出现问题。转换规则应尽早确定并文档化。
2026 年推荐架构
KGA 向客户推荐的「现代分析数据栈」分工如下。
- 中央数据仓库（Snowflake / BigQuery / Databricks）：全公司横向分析、财务、经营指标。通过 Iceberg（Lakehouse）写入向外开放。
- 实时 OLAP（ClickHouse Cloud）：秒级仪表盘、广告/游戏/IoT 事件、APM。
- Notebook / 局部分析（DuckDB + MotherDuck）：数据科学家的探索性分析、中间数据集市生成。
- 浏览器端可视化（DuckDB-WASM）：公开仪表盘、内部 BI 的轻量前端。
- 边缘 OLTP+Analytics（Turso）：地理分布 SaaS 的租户级数据库。
通过 Semantic Layer（如 Cube.dev）整合这五层，并支持 LLM Agent 以自然语言调取所有数据的架构，正是 2026 年版「现代数据栈」的最终形态。与其单一厂商通吃，不如按职责选择最优工具，再以元数据与语义层连接，从长远来看在成本效率与扩展性上是最高的。