我們使用人工智能和機器學(xué)習(xí)技術(shù)優(yōu)化汽車保險和貸款的比價和購買流程。隨著數(shù)據(jù)不斷增長，AWS Redshift 開始出現(xiàn)速度慢、成本高的缺陷。改用 ClickHouse 后，查詢性能顯著提升，成本大幅降低。然而，我們隨之遇到了存儲相關(guān)的挑戰(zhàn)，如磁盤故障和數(shù)據(jù)恢復(fù)。為了減少維護工作，我們引入了高 wydaj 分布式文件系統(tǒng) JuiceFS，并創(chuàng)新地利用其快照功能為 ClickHouse 建立了主副本架構(gòu)。此架構(gòu)保證了數(shù)據(jù)的分布和穩(wěn)定，同時大大提高了系統(tǒng)性能和數(shù)據(jù)恢復(fù)能力。一年多的運行顯示，該架構(gòu)沒有宕機或復(fù)制錯誤，達(dá)到了預(yù)期的性能效果。

我們公司使用人工智能 (ai) 和機器學(xué)習(xí)來簡化汽車保險和汽車貸款的比較和購買流程。隨著數(shù)據(jù)的增長，aws redshift 出現(xiàn)了問題，它速度慢且成本高。改用 clickhouse 后，我們的查詢性能更快，成本也大大降低。但這也帶來了磁盤故障和數(shù)據(jù)恢復(fù)等存儲挑戰(zhàn)。

為了避免大量的維護工作，我們采用了高性能的分布式文件系統(tǒng) JuiceFS，并創(chuàng)新性地利用其快照功能為 ClickHouse 實現(xiàn)了主副本架構(gòu)。該架構(gòu)在保證數(shù)據(jù)高可用和穩(wěn)定性的同時，大幅提升了系統(tǒng)性能和數(shù)據(jù)恢復(fù)能力。運行一年多來，沒有宕機和復(fù)制錯誤，達(dá)到了預(yù)期的性能。

在這篇文章中，我將深入探討我們在應(yīng)用方面面臨的挑戰(zhàn)、我們找到的解決方案以及我們的未來計劃。我希望這篇文章能為初創(chuàng)公司和大公司的小團隊提供寶貴的見解。

數(shù)據(jù)架構(gòu)：從 Redshift 到 ClickHouse

最初，我們選擇 Redshift 進(jìn)行分析查詢。然而，隨著數(shù)據(jù)量的增長，我們遇到了嚴(yán)重的性能和成本挑戰(zhàn)。例如，在生成漏斗和 A/B 測試報告時，我們面臨長達(dá)數(shù)十分鐘的加載時間。即使在合理大小的 Redshift 集群上，這些操作也太慢了。這導(dǎo)致我們的數(shù)據(jù)服務(wù)不可用。

因此，我們尋求一種更快、更具成本效益的解決方案，盡管 ClickHouse 在實時更新和刪除方面存在局限性，但我們還是選擇了它。改用 ClickHouse 帶來了顯著的好處：

• 報告加載時間從幾十分鐘縮短到幾秒鐘。我們能夠更高效地處理數(shù)據(jù)。

• 總支出被削減至不超過原來的25%。

我們的設(shè)計以 ClickHouse 為中心，Snowflake 作為 ClickHouse 無法處理的 1% 數(shù)據(jù)處理的備份。這種設(shè)置實現(xiàn)了 ClickHouse 和 Snowflake 之間的無縫數(shù)據(jù)交換。

杰瑞數(shù)據(jù)架構(gòu)

ClickHouse 部署和挑戰(zhàn)

我們最初維持獨立部署的原因如下：

• 性能： 單機部署避免了集群的開銷，在同等計算資源的情況下，性能表現(xiàn)良好。

• 維護成本： 獨立部署的維護成本最低，不僅包括集成維護成本，還包括應(yīng)用數(shù)據(jù)設(shè)置、應(yīng)用層暴露維護成本。

• 硬件能力：當(dāng)前硬件可以支持大規(guī)模獨立 ClickHouse 部署。例如，我們現(xiàn)在可以在 AWS 上獲得具有 24 TB 內(nèi)存和 488 個 vCPU 的 EC2 實例。這在規(guī)模上超過了許多已部署的 ClickHouse 集群。這些實例還提供滿足我們計劃容量的磁盤帶寬。

因此，從內(nèi)存、CPU、存儲帶寬等方面考慮，獨立的ClickHouse是一個可以接受的解決方案，并且在可預(yù)見的未來將是有效的。

但是，ClickHouse 方法存在一些固有問題：

• 硬件故障可能會導(dǎo)致 ClickHouse 長時間停機。這會威脅應(yīng)用程序的穩(wěn)定性和連續(xù)性。

• ClickHouse數(shù)據(jù)遷移和備份仍然是一項艱巨的任務(wù)。它們需要一個可靠的解決方案。

我們在部署ClickHouse之后，遇到了以下問題：

• 擴展和維護存儲：由于數(shù)據(jù)的快速擴展，維持適當(dāng)?shù)拇疟P利用率變得困難。

• 磁盤故障： ClickHouse 的設(shè)計目標(biāo)是盡可能地利用硬件資源，以提供最佳的查詢性能。因此，讀寫操作會頻繁發(fā)生。它們經(jīng)常會超出磁盤帶寬。這會增加磁盤硬件故障的風(fēng)險。當(dāng)發(fā)生此類故障時，恢復(fù)可能需要幾個小時到十幾個小時。這取決于數(shù)據(jù)量。我們聽說其他用戶也有類似的經(jīng)歷。雖然數(shù)據(jù)分析系統(tǒng)通常被認(rèn)為是其他系統(tǒng)數(shù)據(jù)的副本，但這些故障的影響仍然很大。因此，我們需要為任何硬件故障做好準(zhǔn)備。數(shù)據(jù)遷移、備份和恢復(fù)是極其困難的操作，需要花費更多的時間和精力才能成功完成。

我們的解決方案

我們選擇 JuiceFS 來解決我們的痛點，原因如下：

• JuiceFS 是唯一可以在對象存儲上運行的 POSIX 文件系統(tǒng)。

• 無限容量：自從開始使用它以來，我們就不必?fù)?dān)心存儲容量。

• 顯著節(jié)省成本：使用 JuiceFS 的費用比使用其他解決方案的費用要低得多。

• 強大的快照功能：JuiceFS 在文件系統(tǒng)層面有效實現(xiàn)了 Git 的分支機制。當(dāng)兩個不同的概念如此無縫地融合時，它們往往會產(chǎn)生極具創(chuàng)意的解決方案。這使得以前具有挑戰(zhàn)性的問題變得更容易解決。

構(gòu)建 ClickHouse 的主副本架構(gòu)

我們產(chǎn)生了將 ClickHouse 遷移到基于 JuiceFS 的共享存儲環(huán)境的想法。《探索 ClickHouse 的存儲計算分離》這篇文章給了我們一些啟發(fā)。

為了驗證這個方案，我們進(jìn)行了一系列的測試，結(jié)果顯示開啟緩存后，JuiceFS 的讀取性能已經(jīng)接近本地磁盤，和本文的測試結(jié)果類似。

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

我們針對 JuiceFS 掛載做的調(diào)優(yōu)調(diào)整如下：

• 為了異步寫入并防止可能出現(xiàn)的阻塞問題，我們啟用了寫回功能。

• 在緩存設(shè)置中，我們設(shè)置attrcacheto為“3,600.0 秒”和cache-size“2,300,000”。我們啟用了元緩存功能。

• 考慮到 JuiceFS 上的 I/O 運行時間可能比本地驅(qū)動器更長，我們引入了塊中斷功能。

提高緩存命中率是我們的優(yōu)化目標(biāo)，我們使用 JuiceFS 云服務(wù)將緩存命中率提升到 95%。如果需要進(jìn)一步提升，我們會考慮增加更多磁盤資源。

ClickHouse 和 JuiceFS 的結(jié)合，大大減輕了我們的運維負(fù)擔(dān)，不再需要頻繁擴容磁盤，而是專注于監(jiān)控緩存命中率，大大緩解了擴容磁盤的緊迫性。而且，一旦發(fā)生硬件故障，也不需要進(jìn)行數(shù)據(jù)遷移，大大降低了可能的風(fēng)險和損失。

JuiceFS 快照功能提供的便捷數(shù)據(jù)備份和恢復(fù)選項讓我們受益匪淺。借助快照，我們可以查看數(shù)據(jù)的原始狀態(tài)，并在將來的任何時間恢復(fù)數(shù)據(jù)庫服務(wù)。這種方法通過在文件系統(tǒng)級別實施解決方案來解決以前在應(yīng)用程序級別處理的問題。此外，快照功能非?？焖偾医?jīng)濟，因為只存儲一份數(shù)據(jù)副本。JuiceFS 社區(qū)版用戶可以使用克隆功能實現(xiàn)類似的功能。

此外，由于無需遷移數(shù)據(jù)，停機時間也大幅減少。我們可以快速響應(yīng)故障，或者讓自動化系統(tǒng)在另一臺服務(wù)器上掛載目錄，確保服務(wù)連續(xù)性。值得一提的是，ClickHouse 的啟動時間僅為幾分鐘，這進(jìn)一步提高了系統(tǒng)恢復(fù)速度。

此外，遷移后我們的讀取性能保持穩(wěn)定。整個公司都沒有發(fā)現(xiàn)任何差異。這證明了該解決方案的性能穩(wěn)定性。

最后，我們的成本大幅降低。

為何要建立主副本架構(gòu)

遷移到 ClickHouse 后，我們遇到了幾個問題，導(dǎo)致我們考慮構(gòu)建主副本架構(gòu)：

• 資源爭用導(dǎo)致性能下降。在我們的設(shè)置中，所有任務(wù)都在同一個 ClickHouse 實例上運行。這導(dǎo)致提取、轉(zhuǎn)換和加載 (ETL) 任務(wù)與報告任務(wù)之間頻繁發(fā)生沖突，從而影響整體性能。

• 硬件故障導(dǎo)致停機。我們公司需要隨時訪問數(shù)據(jù)，因此長時間的停機是不可接受的。因此，我們尋求解決方案，最終找到了主副本架構(gòu)的解決方案。

JuiceFS 支持在不同位置掛載多個掛載點，我們嘗試將 JuiceFS 文件系統(tǒng)掛載到其他地方，并在同一位置運行 ClickHouse，但在實施過程中遇到了一些問題：

• ClickHouse 通過文件鎖定機制限制一個文件只能由一個實例運行，這帶來了挑戰(zhàn)。幸運的是，這個問題很容易解決，只需修改 ClickHouse 源代碼來處理鎖定即可。

• 即使在只讀操作期間，ClickHouse 也會保留一些狀態(tài)信息，例如寫入時緩存。

• 元數(shù)據(jù)同步也是一個問題。在 JuiceFS 上運行多個 ClickHouse 實例時，某個實例寫入的某些數(shù)據(jù)可能無法被其他實例識別。修復(fù)該問題需要重啟實例。

因此我們使用 JuiceFS 快照來設(shè)置主副本架構(gòu)。此方法的工作方式與常規(guī)的主備份系統(tǒng)類似。主實例處理所有數(shù)據(jù)更新，包括同步和提取、轉(zhuǎn)換和加載 (ETL) 操作。副本實例專注于查詢功能。

ClickHouse 主副本架構(gòu)

如何為 ClickHouse 創(chuàng)建副本實例

1. 創(chuàng)建快照

我們使用 JuiceFS 快照命令從主實例上的 ClickHouse 數(shù)據(jù)目錄創(chuàng)建一個快照目錄，并在此目錄上部署一個 ClickHouse 服務(wù)。

2.暫停Kafka消費者隊列

在啟動 ClickHouse 實例之前，我們必須停止使用來自其他數(shù)據(jù)源的有狀態(tài)內(nèi)容。對我們來說，這意味著暫停 Kafka 消息隊列，以避免與主實例爭用 Kafka 數(shù)據(jù)。

3. 在快照目錄上運行 ClickHouse

啟動ClickHouse服務(wù)后，我們注入了一些元數(shù)據(jù)，向用戶提供有關(guān)ClickHouse創(chuàng)建時間的信息。

4.刪除ClickHouse數(shù)據(jù)變異

在副本實例上，我們刪除了所有數(shù)據(jù)變異以提高系統(tǒng)性能。

5. 執(zhí)行連續(xù)復(fù)制

快照僅保存創(chuàng)建時的狀態(tài)。為了確保讀取最新數(shù)據(jù)，我們會定期用副本實例替換原始實例。此方法簡單易用且高效，因為每個副本實例都以兩個副本和一個指向副本的指針開始。即使我們需要十分鐘或更長時間，我們通常每小時運行一次以滿足我們的需求。

我們的 ClickHouse 主副本架構(gòu)已經(jīng)穩(wěn)定運行了一年多，無一失敗，完成了超過 2 萬次復(fù)制操作，可靠性非常高。負(fù)載隔離和數(shù)據(jù)副本的穩(wěn)定性是提升性能的關(guān)鍵。我們成功將整體報表可用性從不到 95% 提升到了 99%，而且沒有做任何應(yīng)用層優(yōu)化。此外，該架構(gòu)支持彈性伸縮，靈活性大大提升， 讓我們可以按需開發(fā)和部署新的 ClickHouse 服務(wù)，無需復(fù)雜的操作。

下一步

我們未來的計劃：

• 我們將開發(fā)一個優(yōu)化的控制界面來自動化實例生命周期管理、創(chuàng)建操作和緩存管理。

• 我們還計劃優(yōu)化寫入性能，從應(yīng)用層來說，由于對 Parquet 開放格式的支持非常到位，我們可以將大部分負(fù)載直接寫入 ClickHouse 之外的存儲系統(tǒng)，更加方便訪問，這樣就可以使用傳統(tǒng)方式實現(xiàn)并行寫入，從而提升寫入性能。

• 我們注意到一個新項目 chDB，它允許用戶直接在 Python 環(huán)境中嵌入 ClickHouse 功能，而無需 ClickHouse 服務(wù)器。將 CHDB 與我們當(dāng)前的存儲解決方案相結(jié)合，我們可以實現(xiàn)完全無服務(wù)器的 ClickHouse。這是我們目前正在探索的方向。

路由網(wǎng)(www.lu-you.com)您可以查閱其它相關(guān)文章！