快连VPN:速度和安全性最佳的VPN服务
我們使用人工智能和機器學習技術優化汽車保險和貸款的比價和購買流程。隨着數據不斷增長，aws redshift 開始出現速度慢、成本高的缺陷。改用 clickhouse 後，查詢性能顯著提升，成本大幅降低。然而，我們隨之遇到了存儲相關的挑戰，如磁盤故障和數據恢復。爲了減少維護工作，我們引入了高 wydaj 分佈式文件系統 juicefs，並創新地利用其快照功能爲 clickhouse 建立了主副本架構。此架構保證了數據的分佈和穩定，同時大大提高了系統性能和數據恢復能力。一年多的運行顯示，該架構沒有宕機或複製錯誤，達到了預期的性能效果。
我們公司使用人工智能 (AI) 和機器學習來簡化汽車保險和汽車貸款的比較和購買流程。隨着數據的增長，AWS Redshift 出現了問題，它速度慢且成本高。改用 ClickHouse 後，我們的查詢性能更快，成本也大大降低。但這也帶來了磁盤故障和數據恢復等存儲挑戰。
爲了避免大量的維護工作，我們採用了高性能的分佈式文件系統 JuiceFS，並創新性地利用其快照功能爲 ClickHouse 實現了主副本架構。該架構在保證數據高可用和穩定性的同時，大幅提升了系統性能和數據恢復能力。運行一年多來，沒有宕機和複製錯誤，達到了預期的性能。
在這篇文章中，我將深入探討我們在應用方面面臨的挑戰、我們找到的解決方案以及我們的未來計劃。我希望這篇文章能爲初創公司和大公司的小團隊提供寶貴的見解。
數據架構：從 Redshift 到 ClickHouse
最初，我們選擇 Redshift 進行分析查詢。然而，隨着數據量的增長，我們遇到了嚴重的性能和成本挑戰。例如，在生成漏斗和 A/B 測試報告時，我們面臨長達數十分鐘的加載時間。即使在合理大小的 Redshift 集羣上，這些操作也太慢了。這導致我們的數據服務不可用。
因此，我們尋求一種更快、更具成本效益的解決方案，儘管 ClickHouse 在實時更新和刪除方面存在侷限性，但我們還是選擇了它。改用 ClickHouse 帶來了顯著的好處：
報告加載時間從幾十分鐘縮短到幾秒鐘。我們能夠更高效地處理數據。
總支出被削減至不超過原來的25%。
我們的設計以 ClickHouse 爲中心，Snowflake 作爲 ClickHouse 無法處理的 1% 數據處理的備份。這種設置實現了 ClickHouse 和 Snowflake 之間的無縫數據交換。
傑瑞數據架構
ClickHouse 部署和挑戰
我們最初維持獨立部署的原因如下：
性能： 單機部署避免了集羣的開銷，在同等計算資源的情況下，性能表現良好。
維護成本： 獨立部署的維護成本最低，不僅包括集成維護成本，還包括應用數據設置、應用層暴露維護成本。
硬件能力：當前硬件可以支持大規模獨立 ClickHouse 部署。例如，我們現在可以在 AWS 上獲得具有 24 TB 內存和 488 個 vCPU 的 EC2 實例。這在規模上超過了許多已部署的 ClickHouse 集羣。這些實例還提供滿足我們計劃容量的磁盤帶寬。
因此，從內存、CPU、存儲帶寬等方面考慮，獨立的ClickHouse是一個可以接受的解決方案，並且在可預見的未來將是有效的。
但是，ClickHouse 方法存在一些固有問題：
硬件故障可能會導致 ClickHouse 長時間停機。這會威脅應用程序的穩定性和連續性。
ClickHouse數據遷移和備份仍然是一項艱鉅的任務。它們需要一個可靠的解決方案。
我們在部署ClickHouse之後，遇到了以下問題：
擴展和維護存儲：由於數據的快速擴展，維持適當的磁盤利用率變得困難。
磁盤故障： ClickHouse 的設計目標是儘可能地利用硬件資源，以提供最佳的查詢性能。因此，讀寫操作會頻繁發生。它們經常會超出磁盤帶寬。這會增加磁盤硬件故障的風險。當發生此類故障時，恢復可能需要幾個小時到十幾個小時。這取決於數據量。我們聽說其他用戶也有類似的經歷。雖然數據分析系統通常被認爲是其他系統數據的副本，但這些故障的影響仍然很大。因此，我們需要爲任何硬件故障做好準備。數據遷移、備份和恢復是極其困難的操作，需要花費更多的時間和精力才能成功完成。
我們的解決方案
我們選擇 JuiceFS 來解決我們的痛點，原因如下：
JuiceFS 是唯一可以在對象存儲上運行的 POSIX 文件系統。
無限容量：自從開始使用它以來，我們就不必擔心存儲容量。
顯著節省成本：使用 JuiceFS 的費用比使用其他解決方案的費用要低得多。
強大的快照功能：JuiceFS 在文件系統層面有效實現了 Git 的分支機制。當兩個不同的概念如此無縫地融合時，它們往往會產生極具創意的解決方案。這使得以前具有挑戰性的問題變得更容易解決。
構建 ClickHouse 的主副本架構
我們產生了將 ClickHouse 遷移到基於 JuiceFS 的共享存儲環境的想法。《探索 ClickHouse 的存儲計算分離》這篇文章給了我們一些啓發。
爲了驗證這個方案，我們進行了一系列的測試，結果顯示開啓緩存後，JuiceFS 的讀取性能已經接近本地磁盤，和本文的測試結果類似。
雖然寫入性能下降到了磁盤寫入速度的10%到50%，但這對我們來說是可以接受的。
我們針對 JuiceFS 掛載做的調優調整如下：
爲了異步寫入並防止可能出現的阻塞問題，我們啓用了寫回功能。
在緩存設置中，我們設置attrcacheto爲“3,600.0 秒”和cache-size“2,300,000”。我們啓用了元緩存功能。
考慮到 JuiceFS 上的 I/O 運行時間可能比本地驅動器更長，我們引入了塊中斷功能。
提高緩存命中率是我們的優化目標，我們使用 JuiceFS 雲服務將緩存命中率提升到 95%。如果需要進一步提升，我們會考慮增加更多磁盤資源。
ClickHouse 和 JuiceFS 的結合，大大減輕了我們的運維負擔，不再需要頻繁擴容磁盤，而是專注於監控緩存命中率，大大緩解了擴容磁盤的緊迫性。而且，一旦發生硬件故障，也不需要進行數據遷移，大大降低了可能的風險和損失。
JuiceFS 快照功能提供的便捷數據備份和恢復選項讓我們受益匪淺。藉助快照，我們可以查看數據的原始狀態，並在將來的任何時間恢復數據庫服務。這種方法通過在文件系統級別實施解決方案來解決以前在應用程序級別處理的問題。此外，快照功能非常快速且經濟，因爲只存儲一份數據副本。JuiceFS 社區版用戶可以使用克隆功能實現類似的功能。
此外，由於無需遷移數據，停機時間也大幅減少。我們可以快速響應故障，或者讓自動化系統在另一臺服務器上掛載目錄，確保服務連續性。值得一提的是，ClickHouse 的啓動時間僅爲幾分鐘，這進一步提高了系統恢復速度。
此外，遷移後我們的讀取性能保持穩定。整個公司都沒有發現任何差異。這證明了該解決方案的性能穩定性。
最後，我們的成本大幅降低。
爲何要建立主副本架構
遷移到 ClickHouse 後，我們遇到了幾個問題，導致我們考慮構建主副本架構：
資源爭用導致性能下降。在我們的設置中，所有任務都在同一個 ClickHouse 實例上運行。這導致提取、轉換和加載 (ETL) 任務與報告任務之間頻繁發生衝突，從而影響整體性能。
硬件故障導致停機。我們公司需要隨時訪問數據，因此長時間的停機是不可接受的。因此，我們尋求解決方案，最終找到了主副本架構的解決方案。
JuiceFS 支持在不同位置掛載多個掛載點，我們嘗試將 JuiceFS 文件系統掛載到其他地方，並在同一位置運行 ClickHouse，但在實施過程中遇到了一些問題：
ClickHouse 通過文件鎖定機制限制一個文件只能由一個實例運行，這帶來了挑戰。幸運的是，這個問題很容易解決，只需修改 ClickHouse 源代碼來處理鎖定即可。
即使在只讀操作期間，ClickHouse 也會保留一些狀態信息，例如寫入時緩存。
元數據同步也是一個問題。在 JuiceFS 上運行多個 ClickHouse 實例時，某個實例寫入的某些數據可能無法被其他實例識別。修復該問題需要重啓實例。
因此我們使用 JuiceFS 快照來設置主副本架構。此方法的工作方式與常規的主備份系統類似。主實例處理所有數據更新，包括同步和提取、轉換和加載 (ETL) 操作。副本實例專注於查詢功能。
ClickHouse 主副本架構
如何爲 ClickHouse 創建副本實例
1. 創建快照
我們使用 JuiceFS 快照命令從主實例上的 ClickHouse 數據目錄創建一個快照目錄，並在此目錄上部署一個 ClickHouse 服務。
2.暫停Kafka消費者隊列
在啓動 ClickHouse 實例之前，我們必須停止使用來自其他數據源的有狀態內容。對我們來說，這意味着暫停 Kafka 消息隊列，以避免與主實例爭用 Kafka 數據。
3. 在快照目錄上運行 ClickHouse
啓動ClickHouse服務後，我們注入了一些元數據，向用戶提供有關ClickHouse創建時間的信息。
4.刪除ClickHouse數據變異
在副本實例上，我們刪除了所有數據變異以提高系統性能。
5. 執行連續複製
快照僅保存創建時的狀態。爲了確保讀取最新數據，我們會定期用副本實例替換原始實例。此方法簡單易用且高效，因爲每個副本實例都以兩個副本和一個指向副本的指針開始。即使我們需要十分鐘或更長時間，我們通常每小時運行一次以滿足我們的需求。
我們的 ClickHouse 主副本架構已經穩定運行了一年多，無一失敗，完成了超過 2 萬次複製操作，可靠性非常高。負載隔離和數據副本的穩定性是提升性能的關鍵。我們成功將整體報表可用性從不到 95% 提升到了 99%，而且沒有做任何應用層優化。此外，該架構支持彈性伸縮，靈活性大大提升， 讓我們可以按需開發和部署新的 ClickHouse 服務，無需複雜的操作。
下一步
我們未來的計劃：
我們將開發一個優化的控制界面來自動化實例生命週期管理、創建操作和緩存管理。
我們還計劃優化寫入性能，從應用層來說，由於對 Parquet 開放格式的支持非常到位，我們可以將大部分負載直接寫入 ClickHouse 之外的存儲系統，更加方便訪問，這樣就可以使用傳統方式實現並行寫入，從而提升寫入性能。
我們注意到一個新項目 chDB，它允許用戶直接在 Python 環境中嵌入 ClickHouse 功能，而無需 ClickHouse 服務器。將 CHDB 與我們當前的存儲解決方案相結合，我們可以實現完全無服務器的 ClickHouse。這是我們目前正在探索的方向。
以上就是爲什麼以及如何構建 ClickHouse 的主副本架構的詳細內容，更多請關注本站其它相關文章！
