天天看點

資料湖存儲架構選型

作者簡介

鄭锴,花名鐵傑,阿裡巴巴進階技術專家,Apache Hadoop PMC。深耕分布式系統開發和開源大資料多年,目前專注于在阿裡雲上研發業界領先的 Hadoop/Spark 大資料平台和資料湖解決方案産品。

本文内容來自由阿裡雲計算平台事業部與阿裡雲開發者社群聯合主辦的大資料+AI meetup 2020第二站·上海講師鄭锴的分享《資料湖存儲架構選型》

資料湖存儲架構選型

一、資料湖是個潮流

簡單來講,資料湖的理念就是說從一個企業的視角來講,把整個資料集中的統一的存儲在一起,主要通過 BI 和 AI 的手段來計算分析原始的資料。資料的類型不光是結構化、半結構化的,還包括音視訊,這樣的一些材料。

資料湖存儲架構選型

我們為什麼要基于資料湖來做這樣的一個轉型呢,資料湖能夠給我們帶來什麼樣的好處呢。

第一,打破資料孤島。就是說原始的資料我們先不考慮怎麼去處理它、分析它,甚至是說我們先不考慮它到底會不會解決很大的業務上面的問題,我們先把它放在一起,打破資料孤島,為後面的業務發展演化和計算,可能就提供了很好的一個機會。

第二,基于統一的、集中的整個資料的收集,可以支援各種各樣的計算。

第三,彈性。我們資料湖本身是有彈性的,然後支援的計算也是有彈性的。彈性可能在雲上面帶來成本的很大的伸縮性的空間,為我們優化存儲和計算的成本帶來了這樣一個可能。

第四,管理。我們把資料放在一起,可以提供統一的、集中的這樣一個管理控制。

資料湖存儲架構選型

熟悉 Hadoop 整個生态的話,過去經常會談到一個非常大的、非常複雜的生态的大圖。那個圖裡面涉及到非常多的元件,結構關系非常複雜。而基于資料湖的架構,可以得到大大的簡化。

如下圖所示,最下面是資料湖本身,基于這樣的一個資料湖存儲,我們可以有一個統一的中繼資料服務,做資料湖的建立管理,然後圍繞資料湖做資料的治理開發,和各種資料源的內建打通。但是這個并不是目的,最主要的作用還是說我們要做計算。資料湖的計算,簡單來講就是說我們有各種各樣的開源的 BI 的引擎,或者 AI 的引擎,每個引擎可能有自己的叢集,然後基于資料湖來進行相應的計算場景的處理。然後滿足我們最上面的基于資料湖的各種應用,比如說資料大屏,資料報表,資料挖掘,機器學習。

資料湖存儲架構選型

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

資料湖架構裡面,對于存儲的挑戰很大。

第一,最大的一個因素是資料量的問題。按照資料湖的理念,我們要把所有的資料全部都放在一起,那麼在資料的規模上來講是非常大的,資料規模可以膨脹到 PB、EB 級别。

第二,檔案的規模。從存儲系統的角度來講,檔案的規模可以說也是非常大,要麼就是層次非常深,要麼就是非常扁平。扁平就是說一個目錄下可能會有幾百萬的檔案數,形成這樣一個超大的目錄。

第三,成本。我要收集那麼多的資料,我要把全部原始的資料放在一起,成本上怎麼去優化。

資料湖存儲架構選型

另外一個挑戰就是說,按照資料湖的架構,它背後的本質是存儲和計算分離。現在是專業化的分工,存儲的做存儲,計算的做計算,這個帶來非常大的研發效率的這樣一個提升。但是分離了之後,怎麼滿足計算的吞吐,怎麼滿足計算對性能的這樣一個需求,這也是帶來很大挑戰的一個原因。

資料湖存儲架構選型

另外,在資料湖的整個的方案下面,要考慮到計算場景是非常豐富的,計算的環境也是錯綜複雜的。大資料,我們要支援分析、互動式、實時計算。然後 AI 有自己的各種各樣的引擎來訓練。

然後是計算的場景,包括 EMR 、ECS 自建、雲原生、混合雲。這樣的一些環境可能都會涉及到,我們怎麼提供一個統一、集中的存儲的解決方案,來滿足這樣一個豐富的計算場景和環境。

資料湖存儲架構選型

假設我們能夠克服資料量上面的挑戰,滿足各種計算的環境,也能夠提供緩存加速,也能夠滿足存儲的這樣一個性能。現在架構師決定了我們要做資料遷移,實施層面的挑戰是什麼。我們要做大量資料的遷移,之後要做正确性的比對。另外,比如說, Hive 數倉,Spark 作業,可能上千上萬的作業我們決定要遷移,遷移了之後要做結果的比對。遷移上來之後,可能我過去有一套成熟的治理、運維的體系,在新的架構下面,我怎麼能夠盡量少改,能夠繼續得到支援。這是實施層面的挑戰。

三、完美選項之 checklist

資料湖架構下面,從存儲、加速的視角,我們可以看到有這樣一些挑戰,那麼理想的選型是什麼樣子的,要考慮到哪些因素,這裡做了一個總結。

  • 第一, 基于對象存儲,大規模存儲能力。
  • 第二,大目錄中繼資料操作能力。
  • 第三,政策靈活的緩存加速能力。
  • 第四,和計算打通優化的能力。
資料湖存儲架構選型
  • 第五,支援資料湖新型表格存儲的能力。
  • 第六,歸檔/壓縮/安全存儲的能力。
  • 第七,全面的大資料+ AI 生态支援。
  • 第八,強大遷移能力,甚至是無縫遷移能力。

以上就是作為一個理想的資料湖的存儲、加速方案,最好具備的一個 checklist 。考慮更新到資料湖架構的這樣一些架構師可以對照一下這個 checklist ,來做方案的選型。

四、阿裡雲上的 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 資料源導入。
資料湖存儲架構選型