位元組跳動基於ClickHouse優化實踐之“高可用”

来源:https://www.cnblogs.com/bytedata/archive/2022/09/15/16696415.html
-Advertisement-
Play Games

更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【1】進入官方交流群 相信大家都對大名鼎鼎的ClickHouse有一定的瞭解了,它強大的數據分析性能讓人印象深刻。但在位元組大量生產使用中,發現了ClickHouse依然存在了一定的限制。本篇將詳細介紹我們是如何為ClickHouse增強 ...


更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【1】進入官方交流群

 

相信大家都對大名鼎鼎的ClickHouse有一定的瞭解了,它強大的數據分析性能讓人印象深刻。但在位元組大量生產使用中,發現了ClickHouse依然存在了一定的限制。本篇將詳細介紹我們是如何為ClickHouse增強高可用能力的。

位元組遇到的ClickHouse可用性問題

隨著位元組業務的快速發展,產品快速擴張,承載業務的ClickHouse集群節點數也快速增加。另一方面,按照天進行的數據分區也快速增加,一個集群管理的庫表特別多,開始出現元數據不一致的情況。兩方面結合,導致集群的可用性極速下降,以至於到了業務難以接受的程度。直觀的問題有三類:

1、故障變多

典型的例子如硬體故障,幾乎每天都會出現。另外,當集群達到一定的規模,Zookeeper會成為瓶頸,增加故障發生頻率。

2、故障恢復時間長

因為數據分區變多,導致一旦發生故障,恢復時間經常會需要1個小時以上,這是業務方完全不能接受的。

3、運維複雜度提升

以往只需要一個人負責運維的集群,由於節點增加和分區變多,運維複雜度和難度成倍的增加,目前運維人數增加了幾人也依然拙荊見肘,依然難保證集群的穩定運行。

可用性問題已經成為制約業務發展的重要問題,因此我們決定將影響高可用的問題一一拆解,並逐個解決。

提升高可用能力的方案

一、降低Zookeeper壓力

問題所在:

原生ClickHouse 使用 ReplicatedMergeTree 引擎來實現數據同步。原理上,ReplicatedMergeTree 基於 ZooKeeper 完成多副本的選主、數據同步、故障恢復等功能。由於 ReplicatedMergeTree 對 ZooKeeper 的使用比較重,除了每組副本一些表級別的元信息,還存儲了邏輯日誌、part 信息等潛在數量級較大的信息。Zookeeper並不是一個能做到良好線性擴展的系統,當ZooKeeper 在相對較高的負載情況下運行時,往往性能表現並不佳,甚至會出現副本無法寫入,數據也無法同步的情況。在位元組內部實際使用和運維 ClickHouse 的過程中,ZooKeeper 也是非常容易成為一個瓶頸的組件。

改造思路:

ReplicatedMergeTree 支持 insert_quorum,insert_quorum 是指如果副本數為3,insert_quorum=2,要成功寫入至少兩個副本才會返回寫入成功。

新分區在副本之間複製的流程如下:

 

 

可以看到,反覆在 zookeeper 中進行分發日誌、數據交換等步驟,這正是引起瓶頸的原因之一。

為了降低對 ZooKeeper 的負載,在ByteHouse中重新實現了一套 HaMergeTree 引擎。通過HaMergeTree降低對 ZooKeeper 的請求次數,減少在 ZooKeeper 上存儲的數據量,新的 HaMergeTree 同步引擎:

1)保留ZooKeeper上表級別的元信息;

2)簡化邏輯日誌的分配;

3)將 part 信息從 ZooKeeper 日誌移除。

 

 

HaMergeTree 減少了操作日誌等信息在zookeeper裡面的存放,來減少zookeeper的負載,zookeeper裡面只是存放log LSN, 具體日誌在副本之間通過gossip協議同步回放。

在保持和ReplicatedMergeTree完全相容的前提下,新的 HaMergeTree 極大減輕了對 ZooKeeper 的負載,實現了 ZooKeeper 集群的壓力與數據量不相關。上線後,因Zookeeper導致的異常大量減少。無論是單集群幾百甚至上千節點,還是單節點上萬張表,都能保障良好的穩定性。

二、提升故障恢復能力

問題所在:

雖然所有數據從業者都在做各種努力,想要保證線上生產環境不出故障,但是現實中還是難以避免會遇到各式各樣的問題。主要是由下麵這幾種因素引起的:

軟體缺陷:軟體設計本身的Bug引起的系統非正常終止,或依賴的組件相容引發的問題。

硬體故障:常見的有磁碟損壞、內容故障、CPU故障等,當集群規模擴大後發生的頻率也線性增加。

記憶體溢出導致進程被停止:在OLAP資料庫中經常發生。

意外因素:如斷電、誤操作等引發的問題。

由於原生ClickHouse希望達到極致性能的初衷,所以在ClickHouse系統中元數據常駐於記憶體中,這導致了ClickHouse server重啟時間非常長。因而當故障發生後,恢復的時間也很長,動輒一到兩個小時,相當於業務也要中斷一到兩個小時。當故障頻繁出現,造成的業務損失是無法估量的。

改造思路:

為瞭解決上述問題,在ByteHouse中採用了元數據持久化的方案,將元數據持久化到RocksDB, Server啟動時直接從RocksDB載入元數據,記憶體中也僅僅存放必要的Part信息。因此可以減少元數據對記憶體的占用,以及加速集群的啟動以及故障恢復時間。

如下圖所示,元數據持久化整體上採用了RocksDB+Meta in Memory的方式,每個Table都會對應一個RocksDB資料庫存放該表所有Part的元信息。Table首次啟動時,從文件系統中載入的Part元數據將被持久化到RocksDB中;之後重啟時就可以直接從RocksDB中載入Part。每個表從RocksDB或者文件系統載入的Part將只在記憶體中存放必要的Part信息。在實際使用Part時,將通過記憶體中存放的Part元信息去RocksDB中讀取並載入對應Part。

 

 

完成元數據持久化後,在性能基本無損失的情況下,單機支持的part不再受記憶體容量的限制,可以達到100萬以上。最重要的是,故障恢復的時間顯著縮短,只需要此前的幾十分之一的時間就可以完成。例如在原生ClickHouse中需要一到兩個小時的恢復時間,在ByteHouse中只需要3分鐘,大大提高的系統的高可用能力,為業務提供了堅實保障。

三、其他方面

除了以上兩點,在ByteHouse中在其他很多方面都為高可用能力做了增強,如通過HaKafka引擎提升了數據寫入的高可用性,提升實時數據寫入的容錯率,可自動切換主備寫入;增加了監控運維平臺,實現對關鍵指標的監控、告警;增加多種問題診斷工具,能實現故障的快速定位。

對於數據分析平臺來說,穩定性是重中之重。我們對ByteHouse的高可用能力的提升是不會停止的,在極致性能的背後,力圖為用戶提供最強有力的穩定性保障。

 

立即跳轉火山引擎ByteHouse官網瞭解詳情


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • sed高階用法 sed編輯器 sed是一種流編輯器,流編輯器會在編輯器處理數據之前基於預先提供的一組規則來編輯數據流。 1.sed編輯器工作流程 sed編輯器可以根據命令來處理數據流中的數據,這些命令要麼從命令行中輸入,要麼存儲在一個命令文本文件中。 sed的工作流程主要包括讀取、執行和顯示三個過程 ...
  • 個人學習-Linux文件系統架構 1. 參考文章 [1]https://blog.csdn.net/Holy_666/article/details/86532671 [2]CSDN博主土豆西瓜大芝麻:[Linux的VFS詳解]:https://blog.csdn.net/jinking01/art ...
  • Linux的哲學思想 優勢 一切都是一個文件。(包括硬體,文本,二進位,源代 碼) 系統中擁有小型,單一用途的程式。(一個程式只負責 做好自己的本職工作) 當遇到複雜任務,通過不同功能用途的程式組合起來 完成。 輕量級,一臺服務 dhcp ip 資料庫服務 網 頁 避免令人困惑的用戶界面就是沒有複雜 ...
  • This blog introduces how to do SLAM related development natively on M1(Apple silicon) macbook. Most people come from Ubuntu environment will choose th ...
  • SqlServer對錶的基本操作 手動建庫建表 腳本建庫建表 SQL Server關係資料庫的數據表結構主要是由記錄(行)和欄位(列)構成,每一行代表唯一的一條記錄(Record),而每列則代表所有記錄中的一個域(Field)(也稱為欄位、屬性)。 註意:在同一個資料庫里,表的名字也必須是唯一的。在 ...
  • 本篇文章主要介紹MySQL中的鎖: 1.全局鎖 2.表級鎖(表鎖、意向鎖、元數據鎖 MDL) 3.行級鎖(行鎖、Gap Lock、Next-Key Lock) ...
  • ​ 點亮 ⭐️ Star · 照亮開源之路 https://github.com/apache/dolphinscheduler 本文目錄 1 DolphinScheduler的設計與策略 1.1 分散式設計 1.1.1 中心化 1.1.2 去中心化 1.2 DophinScheduler架構設計 ...
  • ##1.問題原因分析 出現這個問題的原因是插入數據的時候,由於之前沒有使用序列插入,而是直接插入了一個比當前序列nextval還大的值,即直接將id寫死了。後面再使用序列插入的時候,如果序列小於該值的話,是可以正常插入的,當序列號等於之前通過ID寫死的方式插入的ID值時,就會出現這種情況。 2.解決 ...
一周排行
    -Advertisement-
    Play Games
  • 經常看到有群友調侃“為什麼搞Java的總在學習JVM調優?那是因為Java爛!我們.NET就不需要搞這些!”真的是這樣嗎?今天我就用一個案例來分析一下。 昨天,一位學生問了我一個問題:他建了一個預設的ASP.NET Core Web API的項目,也就是那個WeatherForecast的預設項目模 ...
  • 很多軟體工程師都認為MD5是一種加密演算法,然而這種觀點是不對的。作為一個 1992 年第一次被公開的演算法,到今天為止已經被髮現了一些致命的漏洞。本文討論MD5在密碼保存方面的一些問題。 ...
  • Maven可以使我們在構建項目時需要用到很多第三方類jar包,如下一些常用jar包 而maven的出現可以讓我們避免手動導入jar包出現的某些問題,它可以自動下載那須所需要的jar包 我們只需要在創建的maven項目自動生成的pom.xml中輸入如下代碼 <dependencies> <!--ser ...
  • 來源:https://developer.aliyun.com/article/694020 非同步調用幾乎是處理高併發Web應用性能問題的萬金油,那麼什麼是“非同步調用”? “非同步調用”對應的是“同步調用”,同步調用指程式按照定義順序依次執行,每一行程式都必須等待上一行程式執行完成之後才能執行;非同步調 ...
  • 1.面向對象 面向對象編程是在面向過程編程的基礎上發展來的,它比面向過程編程具有更強的靈活性和擴展性,所以可以先瞭解下什麼是面向過程編程: 面向過程編程的核心是過程,就是分析出實現需求所需要的步驟,通過函數一步一步實現這些步驟,接著依次調用即可,再簡單理解就是程式 從上到下一步步執行,從頭到尾的解決 ...
  • 10瓶毒藥其中只有一瓶有毒至少需要幾隻老鼠可以找到有毒的那瓶 身似浮雲,心如飛絮,氣若游絲。 用二分查找和二進位位運算的思想都可以把死亡的老鼠降到最低。 其中,二進位位運算就是每一隻老鼠代表一個二進位0或1,0就代表老鼠存活,1代表老鼠死亡;根據數學運算 23 = 8、24 = 16,那麼至少需要四 ...
  • 一、Kafka存在哪些方面的優勢 1. 多生產者 可以無縫地支持多個生產者,不管客戶端在使用單個主題還是多個主題。 2. 多消費者 支持多個消費者從一個單獨的消息流上讀取數據,而且消費者之間互不影響。 3. 基於磁碟的數據存儲 支持消費者非實時地讀取消息,由於消息被提交到磁碟,根據設置的規則進行保存 ...
  • 大家好,我是陶朱公Boy。 前言 上一篇文章《關於狀態機的技術選型,最後一個真心好》我跟大家聊了一下關於”狀態機“的話題。從眾多技術選型中我也推薦了一款阿裡開源的狀態機—“cola-statemachine”。 於是就有小伙伴私信我,自己項目也考慮引入這款狀態機,但網上資料實在太少,能不能系統的介紹 ...
  • 使用腳本自動跑實驗(Ubuntu),將實驗結果記錄在文件中,併在實驗結束之後將結果通過郵件發送到郵箱,最後在windows端自動解析成excel表格。 ...
  • 話說在前面,我不是小黑子~ 我是超級大黑子😏 表弟大周末的跑來我家,沒事幹天天騷擾我,搞得我都不能跟小姐姐好好聊天了,於是為了打發表弟,我決定用Python做一個小游戲來消耗一下他的精力,我思來想去,決定把他變成小黑子,於是做了一個坤坤打籃球的游戲,沒想到他還挺愛玩的~ 終於解放了,於是我把游戲寫 ...