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公司目前正在探索的方向。