譯者 | 李睿

審校 | 重樓

美國(guó)汽車服務(wù)應(yīng)用程序開(kāi)發(fā)商Jerry公司使用人工智能(AI)和機(jī)器學(xué)習(xí)（ML）來(lái)簡(jiǎn)化汽車保險(xiǎn)和汽車貸款的比較和購(gòu)買過(guò)程。隨著數(shù)據(jù)的增長(zhǎng)，該公司在使用AWS Redshift時(shí)遇到了一些問(wèn)題，例如速度緩慢且價(jià)格昂貴。在該公司改用ClickHouse之后加快了查詢性能，并大幅地降低了成本，但這也帶來(lái)了磁盤(pán)故障和數(shù)據(jù)恢復(fù)等存儲(chǔ)方面的挑戰(zhàn)。

為了避免大量的維護(hù)工作，Jerry公司采用了高性能的分布式文件系統(tǒng)JuiceFS，創(chuàng)新地使用其快照功能來(lái)實(shí)現(xiàn)ClickHouse的主-副本架構(gòu)。該架構(gòu)保證了數(shù)據(jù)的高可用性和穩(wěn)定性，同時(shí)顯著提高了系統(tǒng)性能和數(shù)據(jù)恢復(fù)能力。一年多來(lái)，JuiceFS一直在持續(xù)運(yùn)行，并且沒(méi)有發(fā)生停機(jī)和復(fù)制錯(cuò)誤，提供了預(yù)期的性能。

本文將深入探討Jerry公司采用的應(yīng)用程序面臨的挑戰(zhàn)、采用的解決方案以及未來(lái)實(shí)施的計(jì)劃。希望這篇文章能為初創(chuàng)公司和大公司的開(kāi)發(fā)團(tuán)隊(duì)提供有價(jià)值的見(jiàn)解。

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

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

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

• 報(bào)告加載時(shí)間從幾十分鐘減少到幾秒鐘，能夠更有效地處理數(shù)據(jù)。
• 總支出被削減到不超過(guò)原來(lái)的25%。

Jerry公司的設(shè)計(jì)以ClickHouse為中心，使用Snowflake作為ClickHouse無(wú)法處理的1%數(shù)據(jù)處理的備份。這個(gè)設(shè)置實(shí)現(xiàn)了ClickHouse和Snowflake之間的無(wú)縫數(shù)據(jù)交換。

圖1 Jerry公司的數(shù)據(jù)架構(gòu)

ClickHouse的部署和挑戰(zhàn)

Jerry公司最初保持獨(dú)立部署有以下幾個(gè)原因：

• 性能：獨(dú)立部署避免了集群的開(kāi)銷，并且在相同的計(jì)算資源下表現(xiàn)良好。
• 維護(hù)成本：獨(dú)立部署的維護(hù)成本最低。這不僅包括集成維護(hù)成本，還包括應(yīng)用程序數(shù)據(jù)設(shè)置和應(yīng)用程序?qū)拥墓_(kāi)維護(hù)成本。
• 硬件功能：目前的硬件可以支持大規(guī)模獨(dú)立ClickHouse部署。例如，Jerry公司現(xiàn)在可以在AWS上獲得具有24TB內(nèi)存和488個(gè)vCPU的EC2實(shí)例。這在規(guī)模上超過(guò)了許多已經(jīng)部署的ClickHouse集群。這些實(shí)例還提供了滿足計(jì)劃容量的磁盤(pán)帶寬。

因此，考慮到內(nèi)存、CPU和存儲(chǔ)帶寬，獨(dú)立的ClickHouse是一個(gè)可接受的解決方案，在可預(yù)見(jiàn)的未來(lái)將是有效的。

然而，ClickHouse方法也存在一些固有問(wèn)題：

• 硬件故障可能導(dǎo)致ClickHouse長(zhǎng)時(shí)間停機(jī)，這將威脅到應(yīng)用程序的穩(wěn)定性和持續(xù)性。
• ClickHouse的數(shù)據(jù)遷移和備份仍然是艱巨的任務(wù)，它們需要可靠的解決方案。

在部署ClickHouse之后，Jerry公司遇到了以下問(wèn)題：

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

Jerry公司的解決方案

Jerry公司采用JuiceFS來(lái)解決其痛點(diǎn)，原因如下：

• JuiceFS是唯一可以在對(duì)象存儲(chǔ)上運(yùn)行的POSIX文件系統(tǒng)。
• 無(wú)限容量：自從開(kāi)始使用JuiceFS以來(lái)，就不必?fù)?dān)心存儲(chǔ)容量。
• 顯著的成本節(jié)約：與其他解決方案相比，使用JuiceFS的費(fèi)用顯著降低。
• 強(qiáng)大的快照功能：JuiceFS在文件系統(tǒng)級(jí)別有效地實(shí)現(xiàn)了Git分支機(jī)制。當(dāng)兩個(gè)不同的概念如此無(wú)縫地融合在一起時(shí)，它們通常會(huì)產(chǎn)生極具創(chuàng)造性的解決方案。這使得以前具有挑戰(zhàn)性的問(wèn)題更容易解決。

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

Jerry公司提出了將ClickHouse遷移到基于JuiceFS的共享存儲(chǔ)環(huán)境的想法?！短剿鰿lickHouse的存儲(chǔ)和計(jì)算分離》一文提供了一些見(jiàn)解。

為了驗(yàn)證這種方法，Jerry公司進(jìn)行了一系列測(cè)試。結(jié)果表明，在啟用緩存之后，JuiceFS的讀取性能接近本地磁盤(pán)的讀取性能，這與本文中的測(cè)試結(jié)果類似。

雖然寫(xiě)入性能下降到磁盤(pán)寫(xiě)入速度的10%到50%，但這是可以接受的。

Jerry公司對(duì)JuiceFS安裝所做的調(diào)整如下：

• 為了異步寫(xiě)入和防止可能的阻塞問(wèn)題，啟用了回寫(xiě)功能。
• 在緩存設(shè)置中，將attrcacheto設(shè)置為“3,600.0秒”，將緩存大小設(shè)置為“2,300,000”。啟用了元緩存功能。
• 考慮到JuiceFS上的I/O運(yùn)行時(shí)間可能比本地磁盤(pán)驅(qū)動(dòng)器上的更長(zhǎng)，引入了塊中斷特性。

提高緩存命中率是Jerry公司的優(yōu)化目標(biāo)。使用JuiceFS云服務(wù)將緩存命中率提高到95%。如果需要進(jìn)一步改進(jìn)，會(huì)考慮添加更多的磁盤(pán)。

ClickHouse和JuiceFS的結(jié)合大幅減少了Jerry公司的運(yùn)營(yíng)工作量，并且不再需要頻繁地?cái)U(kuò)展磁盤(pán)空間。與其相反，Jerry公司專注于監(jiān)控緩存命中率。這顯著地緩解了磁盤(pán)擴(kuò)展的緊迫性。此外，在發(fā)生硬件故障時(shí)不需要進(jìn)行數(shù)據(jù)遷移。這顯著地降低了可能的風(fēng)險(xiǎn)和損失。

Jerry公司從JuiceFS快照功能提供的簡(jiǎn)單數(shù)據(jù)備份和恢復(fù)選項(xiàng)中受益匪淺。借助快照，可以查看數(shù)據(jù)的原始狀態(tài)，并在將來(lái)的任何時(shí)候恢復(fù)數(shù)據(jù)庫(kù)服務(wù)。這種方法通過(guò)在文件系統(tǒng)級(jí)別實(shí)現(xiàn)解決方案來(lái)解決以前在應(yīng)用程序級(jí)別處理的問(wèn)題。此外，快照功能非?？焖俸徒?jīng)濟(jì)，因?yàn)橹淮鎯?chǔ)數(shù)據(jù)的一個(gè)副本。JuiceFS社區(qū)版的用戶可以使用克隆功能來(lái)實(shí)現(xiàn)類似的功能。

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

此外，讀性能在遷移后保持穩(wěn)定，Jerry公司的員工都沒(méi)有發(fā)現(xiàn)任何差異。這證明了該解決方案的性能穩(wěn)定性。

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

為什么要設(shè)置主-副本架構(gòu)

在遷移到ClickHouse之后遇到了幾個(gè)問(wèn)題，促使Jerry公司考慮構(gòu)建主-副本架構(gòu)：

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

JuiceFS支持在不同位置的多個(gè)掛載點(diǎn)。Jerry公司嘗試在其他地方掛載JuiceFS文件系統(tǒng)，并在同一位置運(yùn)行ClickHouse。然而，在實(shí)施過(guò)程中遇到了一些問(wèn)題：

• 通過(guò)文件鎖定機(jī)制，ClickHouse限制一個(gè)文件只能由一個(gè)實(shí)例運(yùn)行，這帶來(lái)了挑戰(zhàn)。幸運(yùn)的是，通過(guò)修改ClickHouse源代碼來(lái)處理鎖定，這個(gè)問(wèn)題很容易解決。
• 即使在只讀操作期間，ClickHouse也保留了一些狀態(tài)信息，例如write-time緩存。
• 元數(shù)據(jù)同步也是一個(gè)問(wèn)題。當(dāng)在JuiceFS上運(yùn)行多個(gè)ClickHouse實(shí)例時(shí)，一個(gè)實(shí)例寫(xiě)入的一些數(shù)據(jù)可能無(wú)法被其他實(shí)例識(shí)別。而解決這個(gè)問(wèn)題需要重新啟動(dòng)實(shí)例。

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

圖2 ClickHouse主-副本架構(gòu)

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

（1）創(chuàng)建快照

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

（2）暫停Kafka消費(fèi)者隊(duì)列

在啟動(dòng)ClickHouse實(shí)例之前，必須停止使用來(lái)自其他數(shù)據(jù)源的有狀態(tài)內(nèi)容。這意味著暫停Kafka消息隊(duì)列，以避免與主實(shí)例競(jìng)爭(zhēng)Kafka數(shù)據(jù)。

（3）在快照目錄下執(zhí)行ClickHouse命令

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

（4）刪除ClickHouse數(shù)據(jù)突變

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

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

快照只保存創(chuàng)建時(shí)的狀態(tài)。為了確保它讀取最新的數(shù)據(jù)，Jerry公司定期用副本替換原始實(shí)例。這種方法使用簡(jiǎn)單且高效，因?yàn)槊總€(gè)副本實(shí)例都以兩個(gè)副本和指向其中一個(gè)副本的指針開(kāi)始。即使需要10分鐘或更長(zhǎng)時(shí)間，通常也會(huì)每小時(shí)運(yùn)行一次以滿足Jerry公司的需求。

Jerry公司的ClickHouse主-副本架構(gòu)已經(jīng)穩(wěn)定運(yùn)行了一年多，完成2萬(wàn)多次無(wú)故障復(fù)制操作，證明了其高可靠性。工作負(fù)載隔離和數(shù)據(jù)副本的穩(wěn)定性是提高性能的關(guān)鍵。在沒(méi)有任何應(yīng)用層優(yōu)化的情況下，Jerry公司成功地將總體報(bào)告可用性從不到95%提高到99%。此外，該架構(gòu)支持彈性擴(kuò)展，極大地增強(qiáng)了靈活性。這使Jerry公司能夠根據(jù)需要開(kāi)發(fā)和部署新的ClickHouse服務(wù)，而無(wú)需復(fù)雜的操作。

Jerry公司未來(lái)的計(jì)劃

• 將開(kāi)發(fā)一個(gè)優(yōu)化的控制界面來(lái)自動(dòng)化實(shí)例生命周期管理、創(chuàng)建操作和緩存管理。
• 還計(jì)劃優(yōu)化寫(xiě)性能。從應(yīng)用層來(lái)看，考慮到對(duì)Parquet開(kāi)放格式的強(qiáng)大支持，可以直接將大多數(shù)負(fù)載寫(xiě)入ClickHouse外部的存儲(chǔ)系統(tǒng)中，以便于訪問(wèn)。這允許Jerry公司使用傳統(tǒng)的方法來(lái)實(shí)現(xiàn)并行寫(xiě)入，從而提高寫(xiě)入性能。
• Jerry公司注意到chDB這個(gè)新項(xiàng)目，它允許用戶直接在Python環(huán)境中嵌入ClickHouse功能，而不需要運(yùn)行ClickHouse服務(wù)器。結(jié)合CHDB和目前的存儲(chǔ)解決方案，可以實(shí)現(xiàn)一個(gè)完全無(wú)服務(wù)器的ClickHouse。這是Jerry公司目前正在探索的方向。

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