解讀clickhouse存算分離在華爲雲實踐

摘要:本文是我們對clickhouse做了最簡單的支持obs的適配改造。

本文分享自華爲雲社區《clickhouse存算分離在華爲雲實踐》,作者: he lifu。

clickhouse是一款非常優秀的OLAP數據庫系統,2016年剛開源的時候就因爲卓越的性能表現得到大家的關注,而近兩年國內互聯網公司的大規模應用和推廣,使得它在業內聲名鵲起,且受到了大家一致的認可。

從網絡上公開分享的資料和客戶使用的案例總結來看,clickhouse主要是應用在實時數倉離線加速兩個場景,其中有些實時業務爲了追求極致的性能會上全SSD的配置,考慮到實時數據集的有限規模,這種成本尚能夠接受,但是對於離線加速的業務,數據集普遍會很大,這個時候上全SSD配置的成本就會顯得昂貴了,有沒有辦法既能滿足較高的性能又能把成本控制的儘量低?我們的想法是彈性伸縮,把數據存儲到低廉的對象存儲上面,通過動態增加計算資源的方式滿足高頻時段的高性能需求,通過回收計算資源的方式控制低頻時段的成本,所以我們把目標放在了存算分離這個特性上。

一.存算分離現狀

clickhouse是存算一體的數據庫系統,數據是直接落在本地磁盤上(包括雲硬盤),關注社區動態的讀者已經知道最新的版本可以支持數據持久化到對象存儲和HDFS上了,以下是我們對clickhouse做了最簡單的支持obs的適配改造,和原生的支持S3一樣:

1.配置S3磁盤

2.創建表並灌入數據

3.檢查本地盤數據

4.檢查對象存儲數據

從上面幾個圖片來看, 可以發現本地磁盤上的數據文件內容記錄了obs上的文件名(uuid),也就是說clickhouse和obs對象之間是通過本地數據文件中的“映射”關係關聯起來的,注意這個“映射”關係是持久化在本地的,意味着需要冗餘以滿足可靠性。

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

  • v21.3版本引入的Add the ability to backup/restore metadata files for DiskS3,允許把本地數據文件到obs對象的映射關係、本地數據的目錄結構等屬性,放到obs對象的屬性裏(object的metadata),這樣解耦了數據目錄必須在本地的限制,也解除了維持映射關係的本地文件可靠性而至少雙副本的條件;
  • v21.4版本引入的S3 zero copy replication,使得多個副本間可以共享一份遠端數據,顯著的降低了存算一體引擎多副本存儲的開銷。

但事實上,通過驗證測試可以發現當前階段存算分離距離可以上生產還有很長路要走,比如:atomic庫下的表怎麼搬到對象存儲上(表定義sql文件中標識唯一性的UUID和數據目錄UUID的對應關係)、彈性擴縮容時候如何快速有效均衡數據(拷貝數據會極大拉長操作窗口)、修改本地磁盤文件和遠端對象如何保障一致性、節點宕機如何快速恢復等等棘手的問題。

二.我們的實踐

在雲原生的時代,存算分離是趨勢也是我們的工作方向,接下來的討論將圍繞華爲公有云對象存儲obs來展開。

1.引入文件語義

這裏需要重點強調下華爲雲對象存儲obs和其他競品的最大差異化點:obs支持文件語義,支持文件和文件夾的rename操作。這點對於我們在接下來的系統設計和彈性伸縮實現上非常有價值,所以我們把obs的驅動集成進了clickhouse,然後修改了clickhouse的邏輯,這樣數據在obs上長的和本地一模一樣了:

Local Disk:

OBS:

有了完整的數據目錄結構後,再支持merge、detach、attach、mutate以及part回收等操作就比較方便了。

2.離線場景

From bottom to top,我們再來看系統結構,離線加速場景中去除了對zookeeper的依賴,每個shard一個replica:

然後是擴縮容節點時候的數據均衡功能,通過obs的rename操作完成對part級別的低成本移動(和clickhouse copier工具的數據重新分發均衡不一樣),節點宕機後新節點從對象存儲側構造出本地數據文件目錄。

3.融合場景

ok,在上面離線場景的基礎上我們繼續融入實時場景(下圖中的“實時集羣”部分),不同業務的clickhouse集羣,可以通過冷熱分離分層存儲的方式(這一功能相對比較成熟,業內普遍採用它來降低存儲成本),把冷數據從實時集羣裏淘汰出來,再通過obs rename操作掛載到“離線集羣”中,這樣我們可以覆蓋數據從實時到離線的完整的生命週期(包括從hive到clickhouse的ETL過程):

三.未來的展望

前面的實踐是我們在存算分離方向的第一次嘗試,還在不斷的改進優化中,從宏觀的角度來看仍舊是把obs作爲拉遠了的磁盤來使用,不過感謝obs的高吞吐,相同計算資源的前提下SSD和obs跑Star Schema Benchmark的性能延遲在5x左右,但是存儲成本得到了顯著的降低10x。未來,我們會在前面工作的基礎上,去除obs作爲拉遠磁盤的屬性,把單個表的數據統一在一個數據目錄下,收編clickhouse的元數據,把它做成無狀態的計算節點,達到sql on hadoop的效果,類似impala一樣的MPP數據庫。

 

點擊關注,第一時間瞭解華爲雲新鮮技術~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章