OLAP 資料庫:是什麼、真實使用情境和主要供應商

OLAP 資料庫是什麼、與 OLTP 有何不同、搭配真實 SQL 的實用案例,以及 2026 年的主要供應商。

OLAP 是什麼(以及不是什麼)
- OLAP 不是什麼
OLAP vs OLTP:解釋一切的差別
- 為什麼欄式儲存改變了一切
歷史:從立方體到欄式(以及為什麼和你有關)
星狀 schema:OLAP 資料如何建模
用真實 SQL 講的實用案例
2026 年的主要 OLAP 供應商
怎麼選:我用四個問題給出的標準
關於為什麼這件事比看起來更重要的反思
結論
常見問題

OLAP 是什麼(以及不是什麼)

OLAP 是 Online Analytical Processing(線上分析處理)的縮寫。它是一種工作負載類別,而不是某個具體產品。

這個區分比看起來更重要。當有人說「我們需要一個 OLAP」時,他描述的其實是一種模式:掃描並彙總數百萬到數十億筆資料,以回答業務問題的查詢。「過去三年按產品和地區看月營收」是一個 OLAP 查詢,無論你是在 Excel 裡對著 1998 年的立方體跑,還是今天對著一張十億筆資料的表跑。

這個詞是 E. F. Codd——關聯式模型同一位 Codd——在 1993 年一篇題為 Providing OLAP to User-Analysts: An IT Mandate 的論文裡提出的,他在文中定義了分析系統的十二條規則。

一個幾乎沒人提到的誠實註腳:那篇論文是由 Arbor Software 贊助的,這家公司做的是 Essbase,最早的 OLAP 產品之一。那十二條規則出奇貼切地描述了 Essbase 已經在做的事。這是一次披著學術論文外衣的精彩行銷操作;然而它提出的核心觀點——分析型負載需要和事務型不同的設計——卻完全正確,並在三十年後仍在定義這個領域。

「Online」這個詞也容易誤導。它跟網際網路毫無關係:在 1993 年它指的是互動式,相對於夜間產生的批次報表。

OLAP 不是什麼

它和資料倉儲不是一回事。 OLAP 是一種處理類別;資料倉儲是一種基礎架構模式。資料倉儲是為承載 OLAP 負載而建造的,但 OLAP 也可以跑在即時資料庫、嵌入式引擎和語意層上。

它們不是「寬欄」資料庫。 因為名稱的緣故,這是一個經典又情有可原的誤解。Cassandra、HBase 和 Bigtable 被描述成「欄式」,但內部其實是列儲存:它們按分區鍵把列分組,把欄位當鍵值對存在每一列裡。它們服務於彈性 schema 的 OLTP 負載,而不是分析彙總。如果有人給你的 dashboard 提議用 Cassandra,這裡存在一個誤會。

它不是「大數據」的同義詞。 5 GB 的資料完全可以構成一個完全正當的 OLAP 負載。定義這種模式的是查詢的形狀,而不是資料量。

OLAP vs OLTP:解釋一切的差別

OLTP(Online Transaction Processing,線上交易處理)是 PostgreSQL、MySQL 或 Oracle 在做的事:以交易和強一致性,非常快地讀寫少量列。「給我看一下訂單 8821。」「庫存減一個。」

OLAP 在幾乎所有維度上都相反:

	OLTP	OLAP
儲存	按列	按欄
讀取模式	少欄、少列	多列、少欄
寫入模式	單列變更、高頻率	批次插入、幾乎只附加
目標延遲	毫秒級	亞秒到秒級
並發	數千使用者、簡單查詢	數十或數百、複雜查詢
Schema	正規化(3NF)	星型或反正規化的寬表
典型問題	「訂單 X 的狀態是什麼?」	「訂單按地區如何演變?」
例子	PostgreSQL、MySQL、Oracle	ClickHouse、Snowflake、BigQuery、DuckDB

兩種設計天然不相容,而這正是兩者都存在的原因。一個為以交易完整性寫一列而最佳化的引擎,不可能同時也為掃描四億列並把它們壓成一個數而最佳化。

為什麼欄式儲存改變了一切

實體上的差別很容易看清。一個按列儲存的資料庫在磁碟上是這樣的:

[id:1|país:ES|ingresos:42|fecha:...] [id:2|país:MX|ingresos:17|fecha:...]

要加總 ingresos,你必須連 país、fecha 和其他你不關心的三十幾個欄位一起讀出來。欄式資料庫則把每一欄分開存:

ingresos: [42, 17, 88, 12, ...]
país:     [ES, MX, ES, AR, ...]

如果你的表有 40 欄,而你的查詢只用 2 欄,你就只讀 5% 的資料。而且相鄰值型別相同、又常常重複,壓縮效果好得多:磁碟上位元組數更少,I/O 更少,查詢更快。

在此之上,現代引擎還加入了向量化執行(用 SIMD 指令批次處理欄位,而不是逐列)、資料跳過(稀疏索引和 min/max 統計,跳過整個資料區塊不讀)、以及運算與儲存分離。

模型	儲存	查詢路徑	強項	問題
MOLAP	預先彙總立方體(Essbase、Analysis Services)	MDX → 查立方體	在預先定義維度上亞秒級回應	建置要幾小時;加維度儲存就爆炸;schema 死板
ROLAP	關聯表(Snowflake、BigQuery、ClickHouse)	SQL → 按需求彙總	臨機查詢、任意維度、彈性 schema	單次查詢延遲較高(除非引擎非常快)
HOLAP	兩者混合	彙總走立方體、明細走 SQL	私有技術棧裡的歷史折衷	維運兩套系統的成本

星狀 schema:OLAP 資料如何建模

分析領域的主導邏輯模型是星狀 schema:中央一張事實表,周圍是維度表。

事實表存放可度量的事件,列多欄少:一次銷售、一次點擊、一次感測器讀數。維度表存放描述性脈絡:這個客戶是誰、這個商品屬於什麼品類、這家店在哪個地區。

-- 事實表:不停增長
CREATE TABLE hechos_ventas (
    fecha       Date,
    producto_id UInt32,
    cliente_id  UInt32,
    tienda_id   UInt16,
    unidades    UInt32,
    importe     Decimal(12, 2)
) ENGINE = MergeTree
ORDER BY (tienda_id, fecha, producto_id);

-- 維度:小而穩定
CREATE TABLE dim_producto (
    producto_id UInt32,
    nombre      String,
    categoria   LowCardinality(String),
    marca       LowCardinality(String)
) ENGINE = MergeTree ORDER BY producto_id;

這裡有個把理論和實務分開的細節。在經典資料倉儲裡,星狀 schema 是教條。在現代欄式 OLAP 引擎裡,很多時候應該反正規化,把 categoria 和 marca 直接塞進事實表裡。聽起來像異端——你在重複資料——但因為這些欄位用 LowCardinality 壓縮效果驚人,儲存成本幾乎為零,而每次查詢都省下一個 JOIN。

我的規則:幾乎不變的東西(產品品類、門店國家)一開始就反正規化;經常變化或體量大的東西保留為獨立維度。

用真實 SQL 講的實用案例

到這裡,OLAP 就不再是理論了。這些才是你真正會遇到的模式。

1. 產品分析:轉換漏斗

產品裡最常見的情境。你想知道有多少人從看頁面走到註冊,再走到購買,以及他們在哪裡流失。

標準 SQL 裡這是 CTE 和自連接的惡夢。在現代 OLAP 引擎裡它是一個函式:

SELECT nivel, count() AS usuarios
FROM (
    SELECT
        usuario_id,
        windowFunnel(86400)(
            timestamp,
            evento = 'pageview',
            evento = 'signup',
            evento = 'purchase'
        ) AS nivel
    FROM eventos
    WHERE fecha >= today() - 30
    GROUP BY usuario_id
)
GROUP BY nivel
ORDER BY nivel;

windowFunnel(86400) 統計每個使用者在 24 小時窗口裡連續完成了幾步。結果直接給你漏斗的形狀。

為什麼這裡需要 OLAP: 這條查詢會碰觸一個月內每個使用者的每個事件。在數千萬筆的 Postgres 上,這是一次會壓垮生產資料庫的循序掃描。

2. 可觀測性:日誌、指標、trace

日誌是 OLAP 最典型的案例,但很多人看不出來,因為他們把它和 Elasticsearch 綁在一起。它是帶時間戳的事件,寫得多、按彙總讀、幾乎不更新。

SELECT
    toStartOfMinute(timestamp)                    AS minuto,
    servicio,
    count()                                       AS total,
    countIf(nivel = 'ERROR')                      AS errores,
    round(countIf(nivel = 'ERROR') / count(), 4)  AS tasa_error,
    quantile(0.95)(duracion_ms)                   AS p95,
    quantile(0.99)(duracion_ms)                   AS p99
FROM logs
WHERE timestamp >= now() - INTERVAL 3 HOUR
GROUP BY minuto, servicio
HAVING tasa_error > 0.01
ORDER BY minuto DESC;

一次掃過算出百分位、錯誤率、按分鐘分組。加一個 TTL 讓 90 天前的資料自動刪除,你就有一套完整的可觀測性平台。

一條改變了我算盤的經濟提示: 把日誌從 SaaS 可觀測性方案搬到自架的 OLAP 資料庫,是小專案能拿到的最大成本削減之一。日誌平台的計價按接入量算,而日誌量只會成長。

3. 電商和 BI dashboard

經典情境:按多個維度彙總的業務指標。

SELECT
    toStartOfWeek(fecha)                       AS semana,
    categoria,
    sum(importe)                               AS ingresos,
    count()                                    AS pedidos,
    uniq(cliente_id)                           AS clientes,
    round(sum(importe) / count(), 2)           AS ticket_medio,
    round(sum(importe) / uniq(cliente_id), 2)  AS ingreso_por_cliente
FROM hechos_ventas
WHERE fecha >= today() - 180
GROUP BY semana, categoria
ORDER BY semana DESC, ingresos DESC;

注意 uniq():它用 HyperLogLog 近似計數 distinct,典型誤差低於 1%,記憶體消耗比 uniqExact() 低得離譜。對業務 dashboard 來說,這種近似完全可以接受,而效能差距巨大。

4. 時序和 IoT

感測器、基礎設施指標、市場價格。高頻到達、以較低解析度被查詢的資料。

SELECT
    toStartOfFifteenMinutes(timestamp)  AS intervalo,
    sensor_id,
    round(avg(temperatura), 2)          AS media,
    min(temperatura)                    AS minima,
    max(temperatura)                    AS maxima,
    count()                             AS lecturas
FROM metricas_sensores
WHERE timestamp >= now() - INTERVAL 7 DAY
  AND sensor_id IN (101, 102, 103)
GROUP BY intervalo, sensor_id
ORDER BY intervalo;

讓這件事可持續的模式是漸進式降采样:秒級讀數存一週、小時級存一年、日級無限期保存。用彙總 TTL,這件事是自動的。

5. 面向使用者的分析(嵌入式分析)

最嚴苛的情境。這不是三個人看的內部 dashboard:這是你產品裡的「統計」分頁,所有客戶同時查詢。

SELECT
    toDate(timestamp)     AS dia,
    count()               AS visitas,
    uniq(visitante_id)    AS visitantes,
    countIf(rebote)       AS rebotes
FROM eventos_web
WHERE tenant_id = {tenant:UInt32}      -- 永遠放在 ORDER BY 第一位!
  AND timestamp >= {desde:DateTime}
GROUP BY dia
ORDER BY dia;

這裡設計的關鍵是 tenant_id 作為排序鍵的第一欄。這樣每個客戶只掃描自己的資料,即使表裡有所有客戶合起來幾十億筆,延遲也能維持在毫秒級。這是一個能擴充的功能和一個客戶來了一百個就垮掉的功能之間的差別。

6. 留存與佇列分析

某月註冊的使用者中,幾個月後還有多少活躍。

SELECT
    cohorte,
    mes_relativo,
    uniq(usuario_id) AS usuarios
FROM (
    SELECT
        usuario_id,
        fecha,
        toStartOfMonth(min(fecha) OVER (PARTITION BY usuario_id)) AS cohorte,
        dateDiff('month', cohorte, toStartOfMonth(fecha))         AS mes_relativo
    FROM eventos
)
GROUP BY cohorte, mes_relativo
ORDER BY cohorte, mes_relativo;

小心 OVER 的位置:它必須緊貼 min(fecha),在 toStartOfMonth() 內部。如果你寫 toStartOfMonth(min(fecha)) OVER (...),ClickHouse 會把 toStartOfMonth 當成視窗函式,然後報 Aggregate function with name 'toStartOfMonth' does not exist。

這種查詢——對整張表做視窗——正是會把事務資料庫壓垮、而欄式庫幾秒就能解決的事。

2026 年的主要 OLAP 供應商

市場分成了五個相當清晰的類別。我按它們與真實專案的契合度排序,而不是按市佔率。

即時 OLAP 引擎(開源)

亞秒延遲、持續接入、面向即時 dashboard 和嵌入式分析。

ClickHouse 是這個類別的標竿。欄式、單一二進位、Apache 2.0 授權、從筆電擴充到數百節點。它是自架的預設選擇,也有自己的託管服務(ClickHouse Cloud)。要細節,我有 ClickHouse 完整指南。

Apache Druid 多年在大規模即時時序分析上表現突出。對來自 Kafka 的接入非常強,但維運成本高:六種行程加 ZooKeeper。

Apache Pinot 誕生於 LinkedIn,為數億使用者提供分析。它是為超高並發下的最低延遲最專門設計的,缺點同樣是維運複雜。

StarRocks 和 Apache Doris 是近親,欄式 MPP,JOIN 最佳化器比 ClickHouse 更強。如果你的 schema 是正規化的數倉,是好選擇。

託管雲資料倉儲

零維運、幾乎無限擴充、按用量計費。

Snowflake 普及了運算與儲存分離,主導企業市場。在資料治理和權限方面非常成熟。按 warehouse 運算時間收費。

Google BigQuery 是真正的 serverless:不管理叢集,寫 SQL 就行。主要按掃描資料量收費,這意味著寫得差的查詢會很貴。

Amazon Redshift 是 AWS 生態的選項。更老、需要更多手動調校,但與 Amazon 其他服務原生整合。

Databricks SQL 是 lakehouse 架構的參考,把資料工程、機器學習和分析統一在同一份儲存上。當有非結構化資料和 AI 管線時很強。

Azure Synapse 為已經生活在微軟生態裡的人補齊了三大雲供應商的陣容。

我對這個類別的警告(在比較文章裡重複過,這裡也適用):按用量計費的模式,正好懲罰的是互動式分析的典型模式,也就是大量頻繁的小查詢。一個每 30 秒自動刷新的 dashboard 可能產生不成比例的帳單。如果你預算吃緊,變動的帳單是業務風險,不只是技術風險。

嵌入式引擎

沒有伺服器,跑在你的行程裡。

DuckDB 是分析版的 SQLite:pip install duckdb 你就拿到一個向量化欄式引擎,方言相容 PostgreSQL。它直接讀 Parquet 和 CSV。對能裝進一台機器的資料集,在簡潔上無敵。MotherDuck 是它的雲層。

chDB 是嵌入 Python 的 ClickHouse 引擎,API 風格類似 pandas。

專用型

kdb+ 主導高頻交易。在時序上極快,有自己的語言(q),價格也配得上它的利基。

QuestDB 是開源的、面向時序、帶擴充 SQL。

TimescaleDB——這家公司在 2025 年改名為 TigerData,但開源延伸仍叫 TimescaleDB——把 PostgreSQL 變成時序資料庫。如果你已經在用 Postgres,而且資料量中等,這是摩擦最小的遷移。

Firebolt 和 SingleStore 在高效能加雲管理的利基市場競爭。

資料湖上的查詢引擎

Trino(原 PrestoSQL)和 Apache Spark SQL 查詢的是以開放格式(Apache Iceberg、Delta Lake 或 Parquet)存在物件儲存上的資料。它們不是資料庫:它們是把 SQL 放在你的檔案之上的引擎。

這個類別正在模糊「資料湖」和「OLAP 資料庫」的邊界。很多欄式引擎——ClickHouse 也是——已經能直接讀 Iceberg 和 Parquet,這意味著你可以不接入任何東西就查詢你的湖。

以及更上層的

值得提一下,OLAP 是處理層,不是展示層。Tableau、Looker、Power BI、Metabase 和 Grafana 是 BI 工具,連到 OLAP 資料庫以在背後執行查詢。資料庫提供速度和結構;BI 提供介面。

怎麼選:我用四個問題給出的標準

翻譯成實操決策。

你的資料裝得下一台機器(例如幾百 GB 以內)? 從 DuckDB 起步。零維運、效能出色、SQL 熟悉。這是最被忽視、又最常正確的推薦。

你需要一個帶持續寫入和多個讀者的共享服務嗎? ClickHouse。這是當今效能與維運複雜度的最佳平衡點,並且一跑在普通的 VPS 上。

你已經在 PostgreSQL 裡,資料量中等? TimescaleDB。你加的是一個延伸而不是一個新服務。無聊的選項往往是正確的。

你有團隊、有預算、把零基礎架構放在首位? Snowflake、BigQuery 或 Databricks。第一天就設好成本告警。

以及先於這一切的問題:你真的需要 OLAP 嗎? 如果你最大的表有 200 萬筆,而你的查詢在 Postgres 裡 200 ms 就回來了,答案是不需要。加一套分析系統就是加一個要維護、備份、監控的服務。時機到了的信號很具體:某條對你產品至關重要的彙總超過 5 秒,而你已經嘗試過加索引。

關於為什麼這件事比看起來更重要的反思

很多年裡,我都以為「OLAP」是企業術語,是給在銀行裡擺弄立方體的人用的。這是開發者中相當普遍的偏見,而它讓我付出了昂貴代價。

讓我改觀的,是意識到幾乎每個數位產品都在產生事件資料,而幾乎沒人利用它們,因為預設的基礎架構——關聯式資料庫——讓查詢這些資料很痛苦。於是它們被丟掉、被存進一張沒人敢碰的表、或者付錢給一個只給你本來能有的 10% 的分析 SaaS。

採用 OLAP 資料庫並沒有改變我能測量的東西,它改變了我提問的頻率。一條查詢要 40 秒時,一次工作階段我探索兩個假設;要 300 毫秒時,我探索二十個。而正是這種頻率差異,最終產出了你沒在找的發現。

這才是支持 OLAP 的真正論點,它不會出現在任何 benchmark 裡:不是查詢變快了,而是你問了更多問題。

結論

OLAP 既不是某項具體技術,也不是一時風尚:它就是為回答「關於大資料量的問題」而建造的系統類別,以不同名字存在了三十年。徹底改變的是實作:從夜裡建置的僵硬立方體,到在原始資料上毫秒級彙總的欄式引擎。

對今天的小專案而言,這種演進意味著一件非常具體的事:2005 年需要一個專屬團隊和一份六位數授權的分析能力,今天能裝進一個跑在每月 20 歐元 VPS 上的二進位裡。

如果你想從理論走到能跑起來的東西,最短路徑是:

ClickHouse 是什麼、怎麼安裝 —— 從零到真實查詢,只要五分鐘。
ClickHouse 的替代方案:比較 —— 用本文的選項按標準做選擇。
進階最佳化指南 —— 具體化檢視、projection、編碼和 TTL。

相關文章

2026 年 ClickHouse 的替代方案:帶表格的誠實比較

ClickHouse 是什麼:特色與一步步安裝(2026 指南)

ClickHouse 進階指南:最佳化、具體化檢視和真實技巧

頻道影片

最新

頻道影片

最新