clickhouse存算分離在華為云實踐

clickhouse是一款非常優秀的OLAP數據庫系統，2016年剛開源的時候就因為卓越的性能表現得到大家的關注，而近兩年國內互聯網公司的大規模應用和推廣，使得它在業內聲名鵲起，更受到了大家一致的認可。從網絡上公開分享的資料和客戶使用的案例總結來看，clickhouse主要是應用在實時數倉和離線加速兩個場景，其中有些實時業務為了追求極致的性能會上全ssd的配置，考慮到實時數據集的有限規模，這種成本尚能夠接受，但是對于離線加速的業務，數據集普遍會很大，這個時候上全ssd配置的成本就會顯得昂貴了，有沒有辦法既能滿足較高的性能又能把成本控制的盡量低？我們的想法是彈性伸縮，把數據存儲到低廉的對象存儲上面，然后通過動態增加計算資源的方式滿足高頻時段的高性能需求，通過回收計算資源的方式縮減低頻時段的成本，所以我們把目標放在了存算分離這個特性上。

一.存算分離現狀

clickhouse是存算一體的數據庫系統，數據是直接落在本地磁盤上（包括云硬盤），關注社區動態的讀者已經知道最新的版本可以支持數據持久化到對象存儲（aws s3）和HDFS上了，當前這一章節是我們對clickhouse做了簡單的適配性改造，把對象存儲從s3擴展到了obs，然后展示把clickhouse的數據存儲到obs上的過程：

1.配置s3磁盤

2.創建表并灌入數據

3.本地盤數據文件

4.對象存儲obs上數據文件

從上面的圖片可以發現，本地磁盤上的數據文件內容記錄了obs上的對象名(uuid)和對象大小，它反映的是一種clickhouse本地數據文件和obs上對象之間的“映射關系”，注意這個“映射關系”是持久化在本地的，意味著需要冗余以滿足可靠性；而obs上的數據文件名全是uuid。

然后進一步，我們看到社區也在努力把clickhouse往存算分離的方向推進：

v21.3版本引入的Add the ability to backup/restore metadata files for DiskS3，允許把本地數據文件到obs對象的“映射關系”、本地數據目錄結構的元數據屬性等等，放到obs對象的屬性里（object的metadata），這樣解耦了數據“映射關系”和數據目錄在本地的限制，也解除了維持本地“映射關系”文件可靠性而至少雙副本的成本問題；

v21.4版本引入的S3 zero copy replication，使得多個副本間可以共享一份遠端數據，顯著的降低了存算一體引擎多副本的存儲開銷；等等。

但是事實上，通過驗證測試可以發現當前階段存算分離距離可以上生產還有很長路要走，比如：${path}/metadata目錄下的信息（表定義sql文件、atomic庫下表示唯一性的UUID和數據目錄UUID的對應關系等）怎么持久化到對象存儲上、彈性擴容計算資源時候數據如何快速添加到新的計算節點上（縮容時候數據從計算節點移除）、修改本地磁盤文件和修改遠端對象如何保障一致性、節點宕機如何快速恢復等等棘手的問題。

二.我們的實踐

在云原生的時代，存算分離是趨勢也是我們的工作方向，在這一章節我們繼續把obs當作拉遠了的磁盤來使用，接下來的討論將圍繞華為公有云對象存儲obs來展開。

1.引入obs文件語義

首先需要重點介紹下華為云對象存儲obs和其他競品的最大差異化特性：obs的并行文件桶支持文件語義，支持文件和文件夾的rename操作（背后是輕量級的元數據修改）。這點對于我們在接下來的系統設計和彈性伸縮實現上很有價值，所以我們把obs的c驅動集成進了clickhouse，然后修改了clickhouse的處理邏輯，這樣數據在obs上和本地磁盤上長的一模一樣了（原來obs上是扁平、無序的uuid文件名集合）：

Local Disk：

OBS：

有了完整的文件語義數據目錄結構后，再逐一對merge、detach、attach、mutate以及回收part等操作做了適配修改，保持本地磁盤文件和obs對象間的一致性，這是繼續下面兩個場景化應用工作的基礎，現在這部分已經完成。

2.離線場景

From bottom to top，我們再來看系統結構，離線加速場景中因為數據已經全部在對象存儲obs上，數據不再需要備份冗余，所以可以去除對zookeeper的依賴，每個shard一個replica，充分釋放每個節點上每個CPU核的計算能力：

然后是擴縮容節點時候的數據均衡功能，通過obs的rename操作完成對part級別的低成本移動（耗時將在毫秒級，這是個優勢項），如果發生節點宕機，新節點需要從對象存儲側恢復出本地數據文件目錄后再加載。

3.融合場景

ok，在上面離線場景的基礎上我們繼續融入實時場景（下圖中的“實時集群”部分），不同業務的clickhouse集群，可以通過冷熱分離分層存儲的方式（這一功能相對比較成熟，業內普遍采用它來降低實時數倉的存儲成本），把冷數據從實時集群里淘汰出來，再通過obs rename操作掛載到“離線集群”中，這樣我們可以覆蓋數據從實時到離線的完整的生命周期（有些從hive到clickhouse的ETL過程可以被省略了）：

三.未來的展望

前面的實踐是我們在存算分離方向的第一次嘗試，無論是離線場景還是實時融合場景，都是以obs的文件語義為基礎的，當前還在不斷的改進優化中，另外，從宏觀的角度來看，仍舊是把obs作為拉遠了的磁盤來使用，不過感謝obs的高吞吐，相同計算資源的前提下ssd和obs跑Star Schema Benchmark的性能延遲在5x左右，但是存儲成本得到了顯著的10x降低，有可觀的經濟價值。

未來，我們會在前面工作的基礎上，繼續去除obs作為拉遠磁盤的屬性，把單個表的數據統一在一個數據目錄下，收編clickhouse的元數據，把它做成無狀態的計算節點，達到sql on hadoop的效果，類似impala那樣的MPP數據庫。

ClickHouse EI企業智能 MapReduce MapReduce服務 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。