【高手問答 284 期彙總】 —— 為什麼說存算分離是大資料平臺的未來

語言: CN / TW / HK

隨著累積的資料量的增大,大資料業務量的增多,資料儲存和處理的成本越來越高,企業資料基礎設施的投資越來越大。同時,大資料處理元件多,不同元件使用不同的資料處理格式,比如大家熟悉的資料湖、資料倉庫使用的就是不同的格式,多樣化的資料格式導致資料儲存變得複雜,系統中應對不同的場景,往往同樣的資料需要儲存多份,不同元件之間還需要大量的資料拷貝和格式轉換,消耗大量的資源。

在當前越來越強調雲原生的環境下,儲存計算分離已經是大勢所趨。傳統基於 HDFS 的大資料平臺架構在雲上已經不太適合,隨著資料量的增長 HDFS 的高運維成本問題也會逐漸凸顯。同時由於物件儲存並不是一個完備的檔案系統(比如無法原子重新命名目錄、list 目錄效能差等),無法完整替代 HDFS,Hadoop 社群為了支援物件儲存用了很多折衷方案來實現,但是實際效果並不好。

JuiceFS 是一款開源分散式檔案系統,創新地將物件儲存作為底層儲存介質,實現了儲存空間的無限擴充套件。任何存入 JuiceFS 的檔案都會按照特定規則被拆分成固定大小的資料塊儲存在物件儲存,資料塊的元資料則儲存在 Redis、MySQL、TiKV 等資料庫中。同時 JuiceFS 的 Hadoop Java SDK 完全相容 HDFS API,提供完整的檔案系統特性,大資料元件可以無縫從 HDFS 遷移到 JuiceFS。

本期高手問答 6 月 9 日 - 6 月 15 日,我們邀請到 Juicedata 技術專家 @高昌健,和大家一起探討關於存算分離架構下的大資料儲存系統選型相關的問題。

可討論的問題包括但不限於:

  • 存算架構的發展歷程
  • 大資料平臺的架構設計
  • 資料湖、湖倉一體架構設計
  • 存算分離的優缺點
  • HDFS、物件儲存、JuiceFS 等儲存系統的特性比較

嘉賓介紹:

高昌健

十年網際網路行業從業經歷,曾在知乎、即刻、小紅書多個團隊擔任架構師職位,專注於分散式系統、大資料、AI 領域的技術研究。現在 Juicedata 擔任技術專家,參與建設 JuiceFS 開源社群。


問答彙總

問:HDFS,  JuiceFS, NFS 這三者的儲存格式有啥優點和缺點?

答:HDFS 和 JuiceFS 比較類似,會對儲存的檔案進行分塊(block),區別在於 HDFS 預設分塊的大小是 128MiB,JuiceFS 是 4MiB。分塊的好處是對於大檔案可以分散儲存,提高讀寫併發,缺點是粒度越大對小檔案越不友好(HDFS 是一個很好的例子)。而 NFS 主要是一種協議,儲存格式依賴的是作業系統的檔案系統。

問:想了解下 JuiceFS 是否適用於  windows  server 的平臺儲存平臺? 如果有需要在 windows server 做儲存 ,有什麼推薦的框架嗎?  

答:JuiceFS 同時支援 Linux、Windows、macOS 3 種平臺,因此可以在 Windows Server 上使用 JuiceFS,有興趣可以參考這個文件

問:大批量的小檔案,JuiceFS 處理怎麼樣,JuiceFS 的架構上有沒有什麼突出的優勢,使用了什麼設計模式?

答:相比一些常見的分散式檔案系統(比如 HDFS),在儲存同樣數量檔案的條件下(比如都儲存 1 億個小檔案),JuiceFS 元資料引擎所需的儲存空間更小(比如用 Redis 儲存每個 inode 只需要 300 位元組記憶體),因此 JuiceFS 可以很輕鬆地支撐儲存數十億、甚至上百億的小檔案。

問:存算分離的缺點是啥?什麼情況不建議用,什麼場景用了沒必要?

答:1. 存算分離架構的缺點是相比存算耦合架構效能會有下降(網路 IO 延遲),以及某些儲存系統(比如物件儲存)因為缺失了檔案系統的一些特性(比如目錄原子重新命名、強一致性等)從而影響計算任務的效能和穩定性; 2. 不建議使用的場景:大資料平臺沒有上雲的需求,計算任務沒有彈性伸縮的需求。

問:1. 可理解成大資料平臺未來一定是存算分離的嗎。2. 上面說的存算一體,缺點是在雲上不夠靈活,沒法充分發揮雲上資源彈性伸縮的特點;是雲本身的問題,還是說存算一體只要離開了雲就能靈活了。

答:1. 是的,這是我們的理解。雲原生已經是大勢所趨,大資料生態的各種元件也都在朝著雲原生的方向迭代; 2. 是存算一體架構的問題,和是否使用雲沒有關係,不管是公有云還是私有云。

問:在雲上如何跟 JuiceFS 結合使用?

答:JuiceFS 的架構主要由元資料引擎、資料儲存和客戶端組成,元資料引擎可以用很多流行的資料庫(如 Redis、MySQL、PostgreSQL 等),在雲上一般也都有託管服務可以開箱即用;資料儲存主要支援物件儲存(如 AWS S3、阿里雲 OSS、騰訊雲 COS 等),JuiceFS 已經支援超過 30 種物件儲存。

問:是將計算叢集和儲存叢集分開麼,有沒有相關的介紹?

答:客戶端在大資料平臺上是通過 JuiceFS Hadoop Java SDK 來使用,計算引擎(如 Spark、Hive 等)通過這個 SDK 來訪問 JuiceFS。通過這種架構就可以將計算叢集和儲存叢集分離,更多關於 JuiceFS 的介紹可以參考官方文件

問:JuiceFS 相對 HDFS 資料壓縮比怎麼樣?

答:JuiceFS 預設不會對資料進行壓縮,使用者可以自己手動開啟,可選的壓縮演算法包括 Zstandard 和 LZ4。不過在大資料平臺這個場景不建議開啟壓縮功能,因為大資料平臺常用的資料格式(如 Parquet、ORC)已經對資料進行了壓縮,重複壓縮並沒有明顯收益。

問:物件儲存在 list objects 和 copy object 等操作方面效能不算太好,在存算分離的場景裡是怎麼解決這類效能問題的呢?

答:物件儲存執行這兩種操作效能不好的本質原因是物件儲存的元資料設計上並沒有類似檔案系統的目錄結構,因此 list 一個目錄其實是遍歷所有包含這個字首的 key。JuiceFS 的元資料是完全按照檔案系統來設計的,因此任何元資料相關的操作都能很快完成並保證一致性(比如重新命名一個目錄)。具體可以參考文件