譯者 | 李睿

審校 | 重樓

美國汽車服務應用程序開發商Jerry公司使用人工智能(AI)和機器學習（ML）來簡化汽車保險和汽車貸款的比較和購買過程。隨著數據的增長，該公司在使用AWS Redshift時遇到了一些問題，例如速度緩慢且價格昂貴。在該公司改用ClickHouse之后加快了查詢性能，并大幅地降低了成本，但這也帶來了磁盤故障和數據恢復等存儲方面的挑戰。

為了避免大量的維護工作，Jerry公司采用了高性能的分布式文件系統JuiceFS，創新地使用其快照功能來實現ClickHouse的主-副本架構。該架構保證了數據的高可用性和穩定性，同時顯著提高了系統性能和數據恢復能力。一年多來，JuiceFS一直在持續運行，并且沒有發生停機和復制錯誤，提供了預期的性能。

本文將深入探討Jerry公司采用的應用程序面臨的挑戰、采用的解決方案以及未來實施的計劃。希望這篇文章能為初創公司和大公司的開發團隊提供有價值的見解。

數據架構：從Redshift到ClickHouse

最初，Jerry公司選擇Redshift進行分析查詢。然而，隨著數據量的增長，遇到了嚴重的性能和成本挑戰。例如，當生成漏斗和A/B測試報告時，面臨著長達數十分鐘的加載時間。即使在規模合理的Redshift集群上，這些操作也太慢了，這使得該公司的數據服務不可用。

因此，Jerry公司急需尋求一個更快、更經濟的解決方案，因此選擇了ClickHouse，盡管它在實時更新和刪除方面存在局限性。而切換到ClickHouse帶來了顯著的好處：

• 報告加載時間從幾十分鐘減少到幾秒鐘，能夠更有效地處理數據。
• 總支出被削減到不超過原來的25%。

Jerry公司的設計以ClickHouse為中心，使用Snowflake作為ClickHouse無法處理的1%數據處理的備份。這個設置實現了ClickHouse和Snowflake之間的無縫數據交換。

圖1 Jerry公司的數據架構

ClickHouse的部署和挑戰

Jerry公司最初保持獨立部署有以下幾個原因：

• 性能：獨立部署避免了集群的開銷，并且在相同的計算資源下表現良好。
• 維護成本：獨立部署的維護成本最低。這不僅包括集成維護成本，還包括應用程序數據設置和應用程序層的公開維護成本。
• 硬件功能：目前的硬件可以支持大規模獨立ClickHouse部署。例如，Jerry公司現在可以在AWS上獲得具有24TB內存和488個vCPU的EC2實例。這在規模上超過了許多已經部署的ClickHouse集群。這些實例還提供了滿足計劃容量的磁盤帶寬。

因此，考慮到內存、CPU和存儲帶寬，獨立的ClickHouse是一個可接受的解決方案，在可預見的未來將是有效的。

然而，ClickHouse方法也存在一些固有問題：

• 硬件故障可能導致ClickHouse長時間停機，這將威脅到應用程序的穩定性和持續性。
• ClickHouse的數據遷移和備份仍然是艱巨的任務，它們需要可靠的解決方案。

在部署ClickHouse之后，Jerry公司遇到了以下問題：

• 擴展和維護存儲：由于數據的快速擴展，保持適當的磁盤利用率變得困難。
• 磁盤故障：ClickHouse旨在積極利用硬件資源，以提供最佳的查詢性能。因此，讀寫操作頻繁發生。它們經常超出磁盤帶寬。這增加了磁盤發生硬件故障的風險。當這種故障發生時，數據恢復可能需要幾個小時到十個多小時。這取決于數據量。其他用戶也有類似的經歷。雖然數據分析系統通常被認為是其他系統數據的副本，但這些故障的影響仍然很大。因此，需要為任何硬件故障做好準備。數據遷移、備份和恢復是非常困難的操作，需要花費更多的時間和精力才能成功完成。

Jerry公司的解決方案

Jerry公司采用JuiceFS來解決其痛點，原因如下：

• JuiceFS是唯一可以在對象存儲上運行的POSIX文件系統。
• 無限容量：自從開始使用JuiceFS以來，就不必擔心存儲容量。
• 顯著的成本節約：與其他解決方案相比，使用JuiceFS的費用顯著降低。
• 強大的快照功能：JuiceFS在文件系統級別有效地實現了Git分支機制。當兩個不同的概念如此無縫地融合在一起時，它們通常會產生極具創造性的解決方案。這使得以前具有挑戰性的問題更容易解決。

構建ClickHouse的主-副本架構

Jerry公司提出了將ClickHouse遷移到基于JuiceFS的共享存儲環境的想法。《探索ClickHouse的存儲和計算分離》一文提供了一些見解。

為了驗證這種方法，Jerry公司進行了一系列測試。結果表明，在啟用緩存之后，JuiceFS的讀取性能接近本地磁盤的讀取性能，這與本文中的測試結果類似。

雖然寫入性能下降到磁盤寫入速度的10%到50%，但這是可以接受的。

Jerry公司對JuiceFS安裝所做的調整如下：

• 為了異步寫入和防止可能的阻塞問題，啟用了回寫功能。
• 在緩存設置中，將attrcacheto設置為“3,600.0秒”，將緩存大小設置為“2,300,000”。啟用了元緩存功能。
• 考慮到JuiceFS上的I/O運行時間可能比本地磁盤驅動器上的更長，引入了塊中斷特性。

提高緩存命中率是Jerry公司的優化目標。使用JuiceFS云服務將緩存命中率提高到95%。如果需要進一步改進，會考慮添加更多的磁盤。

ClickHouse和JuiceFS的結合大幅減少了Jerry公司的運營工作量，并且不再需要頻繁地擴展磁盤空間。與其相反，Jerry公司專注于監控緩存命中率。這顯著地緩解了磁盤擴展的緊迫性。此外，在發生硬件故障時不需要進行數據遷移。這顯著地降低了可能的風險和損失。

Jerry公司從JuiceFS快照功能提供的簡單數據備份和恢復選項中受益匪淺。借助快照，可以查看數據的原始狀態，并在將來的任何時候恢復數據庫服務。這種方法通過在文件系統級別實現解決方案來解決以前在應用程序級別處理的問題。此外，快照功能非常快速和經濟，因為只存儲數據的一個副本。JuiceFS社區版的用戶可以使用克隆功能來實現類似的功能。

此外，在不需要數據遷移的情況下，停機時間顯著減少。Jerry公司可以快速響應故障或允許自動系統將目錄掛載到另一臺服務器上，從而確保服務的連續性。值得一提的是，ClickHouse的啟動時間只有幾分鐘，這進一步提高了系統恢復速度。

此外，讀性能在遷移后保持穩定，Jerry公司的員工都沒有發現任何差異。這證明了該解決方案的性能穩定性。

最后，Jerry公司的成本大幅下降。

為什么要設置主-副本架構

在遷移到ClickHouse之后遇到了幾個問題，促使Jerry公司考慮構建主-副本架構：

• 資源爭用導致性能下降。在Jerry公司的設置中，所有任務都運行在同一個ClickHouse實例上。這導致了提取、轉換和加載(ETL)任務和報告任務之間的頻繁沖突，從而影響了整體性能。
• 硬件故障導致停機。Jerry公司需要隨時訪問數據，所以長時間的停機是不可接受的。因此尋求一種解決方案，這使Jerry公司找到了主-副本架構的解決方案。

JuiceFS支持在不同位置的多個掛載點。Jerry公司嘗試在其他地方掛載JuiceFS文件系統，并在同一位置運行ClickHouse。然而，在實施過程中遇到了一些問題：

• 通過文件鎖定機制，ClickHouse限制一個文件只能由一個實例運行，這帶來了挑戰。幸運的是，通過修改ClickHouse源代碼來處理鎖定，這個問題很容易解決。
• 即使在只讀操作期間，ClickHouse也保留了一些狀態信息，例如write-time緩存。
• 元數據同步也是一個問題。當在JuiceFS上運行多個ClickHouse實例時，一個實例寫入的一些數據可能無法被其他實例識別。而解決這個問題需要重新啟動實例。

因此，Jerry公司使用JuiceFS快照來設置主-副本架構。這種方法的工作原理類似于常規的主備份系統。主實例處理所有數據更新，包括同步和提取、轉換和加載(ETL)操作。副本實例主要關注查詢功能。

圖2 ClickHouse主-副本架構

如何為ClickHouse創建副本實例

（1）創建快照

使用JuiceFS快照命令從主實例上的ClickHouse數據目錄創建快照目錄，并在該目錄上部署ClickHouse服務。

（2）暫停Kafka消費者隊列

在啟動ClickHouse實例之前，必須停止使用來自其他數據源的有狀態內容。這意味著暫停Kafka消息隊列，以避免與主實例競爭Kafka數據。

（3）在快照目錄下執行ClickHouse命令

在啟動ClickHouse服務之后，注入了一些元數據，向用戶提供有關ClickHouse創建時間的信息。

（4）刪除ClickHouse數據突變

在副本實例上，刪除了所有數據突變，以提高系統性能。

（5）執行連續復制

快照只保存創建時的狀態。為了確保它讀取最新的數據，Jerry公司定期用副本替換原始實例。這種方法使用簡單且高效，因為每個副本實例都以兩個副本和指向其中一個副本的指針開始。即使需要10分鐘或更長時間，通常也會每小時運行一次以滿足Jerry公司的需求。

Jerry公司的ClickHouse主-副本架構已經穩定運行了一年多，完成2萬多次無故障復制操作，證明了其高可靠性。工作負載隔離和數據副本的穩定性是提高性能的關鍵。在沒有任何應用層優化的情況下，Jerry公司成功地將總體報告可用性從不到95%提高到99%。此外，該架構支持彈性擴展，極大地增強了靈活性。這使Jerry公司能夠根據需要開發和部署新的ClickHouse服務，而無需復雜的操作。

Jerry公司未來的計劃

• 將開發一個優化的控制界面來自動化實例生命周期管理、創建操作和緩存管理。
• 還計劃優化寫性能。從應用層來看，考慮到對Parquet開放格式的強大支持，可以直接將大多數負載寫入ClickHouse外部的存儲系統中，以便于訪問。這允許Jerry公司使用傳統的方法來實現并行寫入，從而提高寫入性能。
• Jerry公司注意到chDB這個新項目，它允許用戶直接在Python環境中嵌入ClickHouse功能，而不需要運行ClickHouse服務器。結合CHDB和目前的存儲解決方案，可以實現一個完全無服務器的ClickHouse。這是Jerry公司目前正在探索的方向。

原文標題：Why and How We Built a Primary-Replica Architecture of ClickHouse，作者：Tao Ma