數據湖存儲架構選型

做者簡介
鄭鍇,花名鐵傑,阿里巴巴高級技術專家,Apache Hadoop PMC。深耕分佈式系統開發和開源大數據多年,目前專一於在阿里雲上研發業界領先的 Hadoop/Spark 大數據平臺和數據湖解決方案產品。

本文內容來自由阿里雲計算平臺事業部與阿里雲開發者社區聯合主辦的 大數據+AI meetup 2020第二站·上海 講師鄭鍇的分享《數據湖存儲架構選型》


1、數據湖是個潮流

簡單來說,數據湖的理念就是說從一個企業的視角來說,把整個數據集中的統一的存儲在一塊兒,主要經過 BI 和 AI 的手段來計算分析原始的數據。數據的類型不光是結構化、半結構化的,還包括音視頻,這樣的一些材料。
咱們爲何要基於數據湖來作這樣的一個轉型呢,數據湖可以給咱們帶來什麼樣的好處呢。
第一,打破數據孤島。就是說原始的數據咱們先不考慮怎麼去處理它、分析它,甚至是說咱們先不考慮它到底會不會解決很大的業務上面的問題,咱們先把它放在一塊兒,打破數據孤島,爲後面的業務發展演化和計算,可能就提供了很好的一個機會。
第二,基於統一的、集中的整個數據的收集,能夠支持各類各樣的計算。
第三,彈性。咱們數據湖自己是有彈性的,而後支持的計算也是有彈性的。彈性可能在雲上面帶來成本的很大的伸縮性的空間,爲咱們優化存儲和計算的成本帶來了這樣一個可能。
第四,管理。咱們把數據放在一塊兒,能夠提供統一的、集中的這樣一個管理控制。
熟悉 Hadoop 整個生態的話,過去常常會談到一個很是大的、很是複雜的生態的大圖。那個圖裏面涉及到很是多的組件,結構關係很是複雜。而基於數據湖的架構,能夠獲得大大的簡化。
以下圖所示,最下面是數據湖自己,基於這樣的一個數據湖存儲,咱們能夠有一個統一的元數據服務,作數據湖的建立管理,而後圍繞數據湖作數據的治理開發,和各類數據源的集成打通。可是這個並非目的,最主要的做用仍是說咱們要作計算。數據湖的計算,簡單來說就是說咱們有各類各樣的開源的 BI 的引擎,或者 AI 的引擎,每一個引擎可能有本身的集羣,而後基於數據湖來進行相應的計算場景的處理。而後知足咱們最上面的基於數據湖的各類應用,好比說數據大屏,數據報表,數據挖掘,機器學習。

2、湖存儲/加速:挑戰很大

數據湖架構裏面,對於存儲的挑戰很大。
第一,最大的一個因素是數據量的問題。按照數據湖的理念,咱們要把全部的數據所有都放在一塊兒,那麼在數據的規模上來說是很是大的,數據規模能夠膨脹到 PB、EB 級別。
第二,文件的規模。從存儲系統的角度來說,文件的規模能夠說也是很是大,要麼就是層次很是深,要麼就是很是扁平。扁平就是說一個目錄下可能會有幾百萬的文件數,造成這樣一個超大的目錄。
第三,成本。我要收集那麼多的數據,我要把所有原始的數據放在一塊兒,成本上怎麼去優化。
另一個挑戰就是說,按照數據湖的架構,它背後的本質是存儲和計算分離。如今是專業化的分工,存儲的作存儲,計算的作計算,這個帶來很是大的研發效率的這樣一個提高。可是分離了以後,怎麼知足計算的吞吐,怎麼知足計算對性能的這樣一個需求,這也是帶來很大挑戰的一個緣由。
另外,在數據湖的整個的方案下面,要考慮到計算場景是很是豐富的,計算的環境也是錯綜複雜的。大數據,咱們要支持分析、交互式、實時計算。而後 AI 有本身的各類各樣的引擎來訓練。
而後是計算的場景,包括 EMR 、ECS 自建、雲原生、混合雲。這樣的一些環境可能都會涉及到,咱們怎麼提供一個統1、集中的存儲的解決方案,來知足這樣一個豐富的計算場景和環境。
假設咱們可以克服數據量上面的挑戰,知足各類計算的環境,也可以提供緩存加速,也可以知足存儲的這樣一個性能。如今架構師決定了咱們要作數據遷移,實施層面的挑戰是什麼。咱們要作大量數據的遷移,以後要作正確性的比對。另外,好比說, Hive 數倉,Spark 做業,可能上千上萬的做業咱們決定要遷移,遷移了以後要作結果的比對。遷移上來以後,可能我過去有一套成熟的治理、運維的體系,在新的架構下面,我怎麼可以儘可能少改,可以繼續獲得支持。這是實施層面的挑戰。

3、完美選項之 checklist

數據湖架構下面,從存儲、加速的視角,咱們能夠看到有這樣一些挑戰,那麼理想的選型是什麼樣子的,要考慮到哪些因素,這裏作了一個總結。
  • 第一, 基於對象存儲,大規模存儲能力。
  • 第二,大目錄元數據操做能力。
  • 第三,策略靈活的緩存加速能力。
  • 第四,和計算打通優化的能力。
  • 第五,支持數據湖新型表格存儲的能力。
  • 第六,歸檔/壓縮/安全存儲的能力。
  • 第七,全面的大數據+ AI 生態支持。
  • 第八,強大遷移能力,甚至是無縫遷移能力。
以上就是做爲一個理想的數據湖的存儲、加速方案,最好具有的一個 checklist 。考慮升級到數據湖架構的這樣一些架構師能夠對照一下這個 checklist ,來作方案的選型。

4、阿里雲上的 JindoFS

接下來看一下阿里雲上面在作的 JindoFS 這樣一個方案具體是什麼樣的狀況。簡單來說咱們在作三個事情。
第一個事情就是說,咱們是基於阿里雲 OSS ,就是面向 Hadoop , Spark 和 AI 的生態,作了這樣的一個 SDK ,而後是優化版本的。咱們知道 Hadoop 是具備 OSS 的支持的,咱們爲何要作一個新的。簡單來說,就是說咱們要作好優化。首先,咱們要作好元數據操做的優化,特別是對於大目錄要作好優化。另一個就是 Rename 優化。咱們知道對象存儲一個關鍵的元數據操做就是目錄的 rename 操做,它是一個很是大的挑戰,這是對象存儲的本質決定的。由於對象存儲不是文件系統,它其實沒有目錄的概念,它的目錄徹底是模擬出來的。也就是說,你對一個目錄進行操做,就必需要對成千上萬個對象相應的進行操做來模擬。甚至是說,在一些計算場景裏面,是否是可以作到跳過 rename 。另一個是讀寫 IO 優化,能不可以充分的利用好對象存儲帶來的水平擴展的這樣一個能力,來作好lO的優化。最後, OSS 的多版本,或者 OSS 的歸檔,咱們是否是可以支持。以上是咱們第一個層面的工做。
第二個事情是爲 OSS 存儲提供一個緩存加速的分佈式系統。首先是數據的一致性,包括元數據的一致性和緩存數據的一致性。而後是磁盤緩存,包括寫時緩存,讀時緩存,以及磁盤的負載均衡。最後是水位清理,包括緩存塊 LRU 淘汰。
第三個事情是說,咱們也打造了一個基於 OSS 的存儲擴展的系統。首先是管理元數據,包括內存緩存,細粒度鎖。其次是文件數據分塊存放, OSS 1備份,緩存1備份。而後是性能優化,元數據操做廣泛 > HDFS ,緩存讀 + OSS 讀 > HDFS 。最後是高擴展,基於 OSS 的大規模水平擴展。
下面對照以前提到的 checklist ,看一下 JindoFS 的支持狀況。
  • 第一,基於對象存儲,大規模存儲能力。支持,基於阿里雲對象存儲 OSS , OSS 支持 EB 級海量存儲。

  • 第二,大目錄元數據操做能力。支持,JindoFS 在超大目錄數據加載、檢索、統計、rename 上具備幾倍的性能優點。

  • 第三, 緩存加速的能力。支持,JindoFS 支持在大數據分析場景、交互式查詢場、機器學習訓練 場景和雲原生應用場景提供策略靈活的分佈式緩存加速能力;緩存加速的性能提高大於 50% 的效果優於開源方案。

  • 第四,和計算打通優化的能力。支持,和 JindoFS co-design 的 JindoTable 提供對數倉表的緩存、計算加速、治理優化和歸檔存儲支持。

  • 第五,支持數據湖新型表格存儲的能力。支持,JindoFS 提供 Delta 、Hudi 和 Iceberg 所須要的存儲接口和事務支持語義,並支持 Flink 實時入湖。

  • 第六,歸檔/壓縮/安全存儲的能力。支持, JindoFS 在目錄、表、分區級別支持 OSS 歸檔;提供透明壓縮;支持 AK 免密保護,Ranger 受權和審計擴展功能。

  • 第七,全面的大數據+ AI 生態支持。支持,JindoFS 全面兼容和支持開源生態,提供:Hadoop JindoFS SDK;Jindo Job Committer ; POSIX fuse 支持 JindoFuse ;TensorFlow FileSystem ;Flink connector ;Kite SDK 。

  • 第八,強大遷移能力甚至是無縫遷移的能力。部分支持,提供優化的 JindoDistCp 工具,支持 Hadoop 數據源導入。


本次分享詳細PPT請掃碼下方二維碼關注「數據湖技術圈」微信公衆號回覆「1101數據湖領取」!

推薦相關閱讀:

數據湖架構,爲何須要「湖加速」?

更多數據湖相關信息交流請加入 阿里巴巴數據湖技術釘釘羣

本文分享自微信公衆號 - Delta Lake技術圈(deltalake-emr2020)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。web

相關文章
相關標籤/搜索