Apache Doris 在 2026 年 6 月剛發布 3.0.6 版，GitHub 累積接近一萬五千顆星。它把自己定位成「即時資料倉庫」，對外用 MySQL wire protocol、底層是 MPP 架構的 columnar engine——這個在 ClickHouse 跟 Snowflake 之間長期空缺的位置，這兩年慢慢被它跟 StarRocks 填了起來。
ClickHouse 過去幾年是自架 OLAP 的預設選項，但它有兩個會在實戰打到的限制。一個是 update 跟 delete 走 ReplacingMergeTree、CollapsingMergeTree 那條路，本質上是 eventual consistency，對於需要訂單狀態、使用者餘額即時刷新的場景並不友善。另一個是它的 SQL 方言跟 client driver 跟 MySQL 不相容，現有的 BI 工具、ORM、舊系統要全部換 connector。Doris 把這兩個痛點一次處理掉，這也是它在 2025 到 2026 年被點名的原因。
update 寫不順是 ClickHouse 在實戰會打到的天花板
ClickHouse 為了寫入吞吐犧牲了 update 跟 delete 的即時性。它的 MergeTree 本質是 append-only 設計，所謂的 update 其實是再寫一筆新版本進去，等下一次 merge 才會真的覆蓋舊資料。寫入吞吐被推到極致的代價，是任何需要「立刻讀到最新值」的場景都得繞——往往要在應用層加一層快取，或在查詢時自行加 FINAL 關鍵字付出更高的計算成本。
對於 log analytics、event tracking 這類 append-heavy 工作負載，這個 trade-off 很值得。但只要場景跨進電商訂單、SaaS 計量、IoT 設備狀態，事情就不一樣——這類資料天生就是 mutable 的，每分鐘可能有幾千筆 update 而不是 insert，ClickHouse 在這條路上就會卡住。
Apache Doris 的 Unique Key 模型直接針對這件事設計。它有一個 Merge-on-Write 模式，寫入當下就完成主鍵衝突的處理，之後的查詢直接讀最新版本而不需要 FINAL。官方在 ClickBench 與 SSB 的比對裡，update-intensive 工作負載上 Doris 比 ClickHouse 快了 18 到 34 倍，差距足以讓原本得在應用層自行包覆 dedup 邏輯的團隊把那層拿掉。
MySQL 協議讓 OLAP 接回原本的客戶端
這是 Doris 跟 ClickHouse、StarRocks 最不同的設計決定。它在 wire protocol 層面相容 MySQL——也就是說，任何能連 MySQL 的 driver、ORM、BI 工具，理論上都能直接連 Doris 而不需要換 connector。Tableau、Metabase、Superset、PowerBI 的 MySQL connector、PHP 的 PDO、Python 的 PyMySQL、Java 的 mysql-connector-j 全部都不需要改寫。
這件事的實際意義要放回團隊現實情境才看得出來。典型場景是公司本來把所有業務資料放在 MySQL 上，BI 工具直接接 read replica；做大之後 replica 開始追不上 OLAP query 的壓力，工程師會評估上 ClickHouse。但這時候會碰到三件事：所有的 dashboard query 要重寫成 ClickHouse 方言、BI 工具要重接 connector、ORM 那層要動。
換成 Doris，第一個動作就是把 read replica 換掉，BI 那邊感覺不到差別，只覺得 query 突然從 30 秒變成 200 毫秒。這對不想把整套技術棧大改一次的團隊是很關鍵的賣點。當然 Doris 並不是 100% MySQL 相容——沒有 unsigned 整數、沒有 BIT、沒有 BLOB，欄位定義也得指定 DUPLICATE / AGGREGATE / UNIQUE 三選一的 key model；但對於 read-mostly 的分析場景，這些差異多半不會踩到。
v3.0 後的儲存運算分離把長期成本壓下來
3.0 版本帶來的儲存運算分離模式（Storage-Compute Decoupled）是 Doris 把成本曲線重新拉低的關鍵。在這個模式下，BE node 不再保留資料本體，全部 offload 到 S3 相容的物件儲存——可以是 AWS S3、MinIO、自家 Garage、阿里雲 OSS、GCS、Azure Blob。BE 只負責計算跟快取 hot data。
這個改動的實務意義是：冷資料的儲存成本從 NVMe SSD 直接掉到物件儲存的等級。一份 50 TB 的歷史報表資料原本要堆滿好幾顆企業級 SSD，現在丟進 MinIO 就行，BE 那邊只要備好夠跑 working set 的快取容量。對於資料保留期長、查詢只集中在最近一週的工作負載，這套架構幾乎是最佳解。
另一個附帶好處是 compute 群組可以多套並存。ETL 寫入用一組 BE、BI 查詢用另一組、AdHoc analysis 再開一組，三組共享同一份資料但彼此 CPU 隔離。這在過去要靠 ClickHouse 的 distributed table 加上一堆讀寫分離規則才能做到。
VPS 自架的實際拆法
把 Doris 真正塞進 VPS 環境最常見的做法是兩組節點：Frontend (FE) 跟 Backend (BE) 各自部署。FE 負責解析 SQL、規劃查詢、保管 metadata；BE 真的去算結果。正式環境通常會把 FE 跑成三台 Observer 加上一台 Leader 的小 quorum，但對於月查詢量不大的中型部署，單台 FE 加三台 BE 就夠用。
硬體規格上，BE 是吃 CPU 跟記憶體的主力。官方建議至少 8 核心 32 GB 記憶體配 NVMe SSD，但實務上 4 核 16 GB 也能跑得動展示流量。3.0 之後的儲存分離模式可以把 BE 規格進一步壓低——本地碟只放快取，主體跑 S3，BE 換成記憶體吃飽的機種就能撐住。
部署上唯一比較麻煩的是 BE 對於 swap、transparent huge page 跟 vm.overcommit_memory 有特定要求，這些在開機腳本裡先處理好之後維運就單純了。FE 跟 BE 之間靠 RPC 通訊，所以同機房內網延遲很重要——這也是為什麼 Doris 在臺灣自架時，把整個 cluster 都擺在同一個機房的同一個機櫃會比跨機房可靠得多。
Doris、ClickHouse、StarRocks 該怎麼選
三套都是 MPP columnar database，但分工不太一樣。如果工作負載是 append-only 的 log 跟 event，每天 TB 級新資料但幾乎不 update，ClickHouse 的 raw scan throughput 仍然是頂規。如果需要大量的 multi-table join、面向終端使用者的低延遲 dashboard，StarRocks 的 cost-based optimizer 跟 colocated join 通常會勝出。
Apache Doris 的甜蜜點是「需要 update、需要 MySQL 客戶端相容、需要在 VPS 等中型自架環境上跑」這個交集。對於從 MySQL 主庫往上爬到需要 OLAP 的中型團隊，Doris 是門檻最低的下一步。對於已經有 ClickHouse 但卡在 update 場景的團隊，把那部分 workload 切到 Doris 通常比改 ClickHouse 表結構來得乾淨。
純就生態系成熟度，ClickHouse 仍然是書面資料、社群討論、第三方整合最多的選項。Doris 因為早期主要用戶集中在亞太區，英文文件偶爾會比中文文件落後幾個版本。要真正評估時，建議直接用自家 production 的 query pattern 在三套上各跑一遍，多花一個工程師週做基準，比導入後再換成本低得多。
即時分析倉庫的位置已經被重排
即時分析倉庫這個品類在 2026 年已經沒有什麼新概念，真正在拉開差距的是「跟現有技術棧的整合成本」。Doris 透過 MySQL 協議把這個成本壓到最低，這是它在 ClickHouse 跟 Snowflake 之間找到自己位置的方式——既不是 append-only 跑得最快的那個，也不是 SaaS 帳單最痛的那個，而是讓 BI 工具不用換 connector 的那個。
對於想在臺灣機房自架即時分析倉庫的團隊，硬體規格、機房線路品質、IPv6 出口與 IP Transit 頻寬都會直接影響整套系統的可用性。NCSE Network 提供位於是方電訊機房的 Intel Gold CPU 加 NVMe SSD VPS、原生雙堆疊 IPv6 與穩定的 IP Transit 線路，適合架設 FE 加 BE 多節點的 Doris cluster。需要進一步討論硬體配置或機房代管選項，可參考 ncse.tw 上的 VPS 與 IP Transit 方案。
