Cisco Talos 用 ClickHouse Cloud 管理 2 兆筆威脅情報資料
ClickHouse Blog · 2026-06-15
Cisco 旗下威脅情報部門 Cisco Talos 將其檔案雜湊信譽服務從自管 ClickHouse 叢集遷移至 ClickHouse Cloud，整個過程維持零停機、100% 資料比對準確率。生產環境目前存有近 2 兆筆資料列，每日新增約 270 億筆，壓縮後佔 192 TB（未壓縮約 2 PB）。
原本的問題
舊架構以 Amazon EKS 上的 32 個高運算節點自行管理 ClickHouse，每個節點掛載 7 個 EBS 磁碟區。資料從 Databricks Delta Tables（S3 上的 Parquet 檔案）流入，需要一套客製化事件驅動 Serverless 管線負責編排與攝取，維護這套管線耗費大量工程時間。除了基礎設施成本，SOC 2 合規稽核的負擔也隨之增加。
隨著資料量持續擴張，自管叢集的人力與成本壓力逐漸蓋過了自建的靈活性優勢。Cisco Talos 工程師 Senay Goitom 描述：維護這套管線讓團隊無法專注在新產品開發。
採用的方法
遷移分四個階段進行：第一階段以 Terraform 模組建立基礎設施，同時設定 ClickPipes（ClickHouse Cloud 的托管攝取服務）與 SSO/SAML 整合；第二階段建立新資料管線並回填 12 個月歷史資料；第三階段以影子流量同時打向新舊後端進行驗證；第四階段完成切換並透過隨機抽樣 1,000 個以上的檔案雜湊值做最終比對。
新架構採用 Amazon EventBridge + SQS + ClickPipes 取代原有的客製化編排程式，後端資料表改用 SharedMergeTree 引擎搭配物件儲存，並透過 AWS PrivateLink 路由查詢流量。智慧分區策略讓原本在攝取時完成的聚合工作轉移到查詢時執行，簡化了寫入路徑。
實際效果
遷移後，每日攝取 3,000 個 S3 物件，從物件落地到可查詢狀態的佇列延遲不超過一分鐘，且無任何資料遺失。針對 1,000 個以上隨機雜湊值的 API 回應驗證達到 100% 比對率，消費端服務感知零影響。
成本面，Cisco 表示儲存費用降低約 90%，整體 TCO（總擁有成本）降低約 75%——此為 Cisco 自身聲稱的數字，並非獨立驗證結果。每年節省超過 300 個工程人時，原本維護自管叢集與客製管線的時間得以重新投入新產品開發，SOC 2 合規的行政開銷也隨托管服務轉移而減少。
ClickHouse 開源十年：從 Yandex 內部工具到 2,000 位貢獻者
ClickHouse Blog · 2026-06-15
2016 年 6 月 15 日，ClickHouse 以一個網站、一個 Debian 套件庫與一份說明文件正式公開，距今恰好十年。創始工程師 Alexey Milovidov 在這篇回顧文章中梳理了這個資料庫從第一行程式碼到擁有 2,000 位以上貢獻者的完整歷程。
背景
ClickHouse 的起點比多數人預期的更早。2008 年底至 2009 年初，Milovidov 在 Yandex 建立了 OLAPServer 原型，用於網頁分析；2009 年 5 月 29 日的第一筆 commit 是針對 libc 時間函式的效能最佳化。2012 年，Michael Kolupaev 成為第二位全職開發者，同年完成 ClickHouse server 與 client 的初版實作。
2014 年是關鍵轉折：ReplicatedMergeTree 引擎落地，系統開始跨多個資料中心部署，並啟動與 CERN 的合作。2015 年 Milovidov 發表技術文章引起商業社群注意，促成了隔年的開源決定。
核心改動
Milovidov 描述 ClickHouse 是一個罕見的、完全從零實作的資料庫系統，沒有借用任何現有資料庫引擎。核心架構依序演化：欄式儲存（IColumn、Field 類別）→聚合函式框架→表格引擎→LZ4 壓縮整合→區塊串流與處理器查詢管線→遞迴下降 SQL 剖析器→以增量背景排序為核心的 MergeTree。每一層都在前一層穩定後才加入，形成今日高效能的垂直堆疊。
開源策略上，Milovidov 強調 ClickHouse 採取他稱為「第三級開源」的做法：透明開發、公開路線圖、程式碼審查系統與完整說明文件，而非僅將程式碼丟上 GitHub。所有 2,000 位以上貢獻者的名字同時出現在 changelog 與資料庫本身的 system.contributors 資料表中。
影響範圍
十年下來，ClickHouse 已成為分析型資料庫領域的標竿之一，Cloudflare、Uber、Spotify 等大型網際網路公司皆公開描述其使用案例。開源社群的參與加速了功能迭代，也讓邊緣案例的修復速度遠超過單一公司內部的開發節奏。
Milovidov 在文章最後提到，開源發布本身並非終點，而是一個持續改善透明度與協作深度的過程。對於一個原本只為解決 Yandex 網頁分析問題而建立的工具，這十年的演化路徑遠超出最初的預期。
原始來源：Ten years of ClickHouse in open source — ClickHouse Blog
ClickHouse Cloud 推出 Postgres 對 Postgres ClickPipes 托管遷移服務
ClickHouse Blog · 2026-06-11
ClickHouse Cloud 在 2026 年 6 月 11 日推出 Postgres to Postgres ClickPipes，將原本需要手動操作 pg_dump/pg_restore 加上 CDC 管線的 Postgres 資料庫遷移流程，封裝為一套托管服務。作者 Amogh Bharadwaj 說明了這個功能針對的痛點與實作機制。
原本的問題
傳統 Postgres 遷移面臨四個主要障礙。工具鏈複雜度首當其衝：使用者需自行安裝命令列工具、產生 schema dump、正確還原並協調整個流程，而 pg_dump/pg_restore 把 Postgres 的內部細節直接暴露給使用者，提高出錯機率。
規模效能也是問題——大型資料集的標準邏輯複寫流程可能耗時數小時，且進度與失敗的可視性很低。更棘手的是，上線期間的遷移必須依賴高可靠的 CDC（Change Data Capture） 持續同步目標端；任何 CDC 中斷都可能導致切換後資料不一致，是整個流程最脆弱的環節。
採用的方法
ClickPipes Postgres-to-Postgres 的核心由 PeerDB 技術驅動。Schema 遷移部分自動處理安全連線（TLS、憑證、Private Link）、Postgres 角色衝突以及來源與目標版本相容性；schema dump 以單一交易方式套用，支援冪等重試，並提供即時錯誤通知。
資料搬移採用平行初始載入機制大幅縮短遷移時間。CDC 階段支援自動傳播新增欄位與處理 TOAST 資料，Pull 與 Push 流程獨立運行並各自具備重試邏輯，系統依據重試失敗次數觸發通知，避免靜默失敗。服務部署在 ClickHouse Cloud 同一區域，減少資料傳輸延遲。
影響範圍
這項功能將原本需要資深資料庫管理員介入的遷移工作降低為托管操作，對中小型工程團隊而言尤其顯著。整合 ClickHouse 分析能力的路徑也更短——遷移完成後可直接透過已說明文件化的 Postgres-ClickHouse 整合與 pg_clickhouse 擴充套件銜接分析工作負載。
此功能目前在 ClickHouse Cloud 上提供，與既有的 Kafka、S3、Kinesis 等 ClickPipes 來源並列為產品線的一部分，定位為解決 Postgres 遷移「最後一哩」複雜度的托管解決方案。
原始來源：Introducing Postgres to Postgres ClickPipes in ClickHouse Cloud — ClickHouse Blog