1、引言數據庫
ClickHouse 是一個用於聯機分析( OLAP )的列式數據庫管理系統( DBMS )。它於 2016 年以 Apache 2.0 協議開源,以優秀的查詢性能,深受廣大大數據工程師歡迎。
爲了服務客戶業務,騰訊雲於 2020 年 4 月正式上線 ClickHouse 服務。服務上線以來,迅速得到內外客戶普遍支持,服務業務數量成規模增加。與此同時,運維與管控壓力也隨之而來,用戶對彈性伸縮能力的呼聲愈來愈大。
事實上,ClickHouse 是典型的 Share-Nothing 架構,自然支持彈性伸縮能力。不管是增長節點數量,仍是增長數據分片副本數量都很是容易。圖1 ClickHouse Share-Nothing 架構
可是,ClickHouse 集羣在增長節點後,集羣上的數據集沒法自動均衡分佈。須要人工干預,確保數據均衡。同理,下線集羣節點前,也須要人工干預,將被下線節點的機器遷移到其餘節點。
在生產環境中,運維工做強度隨着集羣中表的數量,數據規模增長而急劇加強。爲了緩解雲上 ClickHouse 用戶運維壓力,將 ClickHouse 數據均衡運維工做自動化是很是有價值的。
本文將帶你們瞭解騰訊雲 ClickHouse 是如何實現無人值守的數據均衡服務,但願與你們一同交流。網絡
2、ClickHouse集羣數據均衡功能缺失架構
將數據所有刪除掉,從後備數據源從新導入數據到 ClickKhouse;app
增長新節點的權重,過必定時間後待數據均衡後,從新調整新增節點權重;運維
其餘,如人工搬運數據到新增節點分佈式
可是不管使用上述哪種種方法,都存在缺陷。好比對於第一個方案而言,若是 ClickHouse 中數據並沒有後備數據源,那麼該方案不可行。即便有後備數據源,從新導入數據耗時,且停服時間與數據量成正比,代價大。
對於第二種方案,須要對新節點進行屢次權限調整。在調整期間,數據存儲壓力向新增節點傾斜,沒法充分利用集羣優點。且容易致使新近數據集中在新增節點上,致使集羣資源浪費,下降查詢效率。
對於第三種方案而言,操做繁雜,在表多,數據量大的狀況下,易出錯。ide
3、雲上ClickHouse解決方案性能
4、結語測試
新擴容節點後,使用數據遷移功能,遷移部分數據至新節點,讓數據在集羣節點上趨於均衡;大數據
縮容節點前,將待下線節點上的數據遷移到其餘節點,避免數據丟失。
數據遷移功能極大的緩解了集羣版 ClickHouse 運維壓力。須要注意的是,數據均衡任務運行過程當中,被遷移的表沒法被業務訪問。