當前位置︰首頁 > 新聞資訊 > 正文

Hadoop 迎來 3.x 時代,昔日大數據霸主如何應對雲計算挑戰?2019-08-27 09:39:06 | 編輯︰hely | 查看︰ | 評論︰0

本文將按照存儲和計算兩個方向,分別介紹 Hadoop 社區當前的熱點話題及後續規劃。本文整理自堵俊平、譚望達近日在 Apache Hadoop 技術社區中國 Meetup 上發表的演講。

自 2006 年誕生以來,Hadoop 改變了企業對數據的存儲、處理和分析的過程,形成了一個極其豐富的技術生態圈,並在經歷了大數據技術高速發展之後,迎來了 3.x 的時代。本文將按照存儲和計算兩個方向,分別介紹 Hadoop 社區當前的熱點話題及後續規劃。本文整理自堵俊平、譚望達近日在 Apache Hadoop 技術社區中國 Meetup 上發表的演講。

存儲的三個演進方向

存儲最主要是向三個方向演進︰Scalability、Cloud、Machine Learning。

Scalability 主要是指 Hadoop 的分布式文件系統 HDFS 仍然有提高擴展性的需求和空間,後面會詳細展開講。Cloud 也是一個非常重要的方向,雲上的對象存儲甚至有取代 HDFS 成為雲端大數據默認存儲的趨勢,所以 HDFS 如何與雲端對象存儲配合是一個重要的趨勢。另一方面,隨著機器學習 AI 的興起,從數據存儲的角度來看,這和傳統大數據的存儲方式很不一樣,比如小的數據碎片會很多,這對 HDFS 帶來了很多新場景和新挑戰。

擴展性增強

先看 Scalability 的問題,我們先來回顧一下 HDFS 的架構。

 

 

如圖所示,在 Master 節點也即 Namenode 這里主要有兩部分工作︰一是命名空間管理,另外一個是數據塊管理。分工也很明確︰前者負責維護文件路徑到數據塊 ID 的映射,後者負責從數據塊 ID 到 Datanode 上數據塊位置的映射。兩個映射結合就可以從文件路徑來定位到具體數據塊存儲的位置,便于對數據的訪問。

這里有幾個核心特點︰

Namenode 把所有的元數據信息存到內存中;

元數據信息的操作延遲是非常低的,便于快速響應元數據信息訪問的需求;

它整體的架構和 I/O 模型是易于擴展到 PB 乃至上百 PB 級數據規模的。

這個架構的長處同時也是它的短處。設想當集群擴展至 4000 個節點以上時,並且存儲超過 5 億個文件時,所有元數據(命名空間、塊管理等)要存放在 Namenode 的內存里,同時要考慮到同時並行的文件操作以及數據塊上報、RPC 的響應等因素,這個時候就會遭遇擴展瓶頸。更不幸的是,如果集群存儲的是海量小文件,這個瓶頸期會更快到來。

從上面可以看到,Namenode 很容易成為整個集群擴展性的瓶頸,所以很多優化都是圍繞于此。首先看觀察者 Namenode 這個特性。我們注意到超過一半的對 Namenode 訪問屬于讀訪問,而之前為了實現高可用性,HDFS 早已實現主備(active-standby)架構。如果讀請求可以由之前基本閑置的 standby Namenode 來響應,就可以有效降低對主 Namenode 的壓力。從社區報告的一些生產集群的應用實測可以發現,這個特性可以緩解主 Namenode 大約 20% 的壓力。

其次來看一下 Namenode 聯邦(Federation)這個特性。這個特性有兩個版本︰一個是早期的實現,通過把集群的所有節點劃分成不同的子集群,子集群有獨立的命名空間,用戶 / 客戶端需要顯式的指定子集群的命名空間。這種方式的缺點很明顯,即邏輯上所有數據無法采用統一的命名空間,也無法橫跨多集群來做在平衡等。另外一個是最近開發的基于路由的聯邦(Router Based Federation,簡稱 RBF)特性。這個特性的設計思路是比較通用的方式,包括 YARN 也采用了類似的方案。基本設計理念是提供一個單獨的聯邦層,包含路由(Router)以及狀態存儲 (State Store) 兩大模塊。路由提供和 Namenode 一樣的服務,只是所有的訪問會通過路由進入相應的 HDFS 子集群,反饋相應的結果。而狀態存儲則會保存命名空間和子集群的映射關系,方便路由來跟蹤記錄並提供相應的服務。這種實現方式對客戶端更友好,完全可以達到對客戶端透明。

面向雲的演化

對于 Hadoop 存儲面向雲的演化,主要是看 HDFS 如何跟雲上的對象存儲配合。

 

 

這里有四種不同的架構︰如圖所示,第一種架構是主體采用 HDFS,雲的對象存儲主要起備份和恢復的作用;第二種架構是輸入在雲對象存儲,輸出到 HDFS;第三種架構,輸入輸出都在雲對象存儲,HDFS 用來轉儲中間結果;最後一種,應用無需感知對象存儲,由 HDFS 來負責數據在對象存儲里的寫入與加載。我們認為最後一種是比較理想的一種情況,因為線下運行良好的大數據應用無需任何修改即可遷移至雲端。

針對第四種架構,HDFS 社區開發了對象存儲掛載這個特性。

 

 

如圖所示,在 HDFS 的命名空間的任何位置都可以設置掛載點來掛載遠程的命名空間,標識成 PROVIDED 層次。HDFS 會通過 StoragePolicy 來管理數據在不同層次之間的移轉。

機器學習

針對雲和機器學習場景,Hadoop 社區開發了 OZone 項目。這個前景遠大的產品有很多特點,包括︰無限的擴展能力,強一致性的對象存儲能力,與主流計算調度框架 YARN 和 Kubernetes 無縫對接,以及同時兼容對象存儲與 HDFS API 等。目前 Ozone 還處于 Alpha 階段,下一個 Release 也就是 0.5 Release 是 Beta 版本。在 Ozone 項目上,騰訊的工程師也做出了很多的貢獻,比如像 Topology Awareness(拓撲感知)、性能優化等等。

除了剛才提到的大的場景突破,還有一些持續不斷的改進和優化,也列在這里,包括︰對于非易失性存儲的支持,對新的 trace 框架 -opentracing 的支持,以及擴展性壓力測試工具 Dynamometer 等等。

計算的新功能

下面重點介紹關于計算部分(Compute)的更新,主要包括 YARN 和 Submarine。未來,計算資源會越來越多容器化。以前容器化主要是被 DevOps 和微服務所使用,最近隨著大數據應用的依賴越來越復雜,我們也需要用容器化做更好的依賴管理和資源隔離。

下面是一些重點的計算方面新的功能。

第一個功能是 YARN-5139 Global Scheduling Framework。這是在 3.0.0 里加入的功能,它可以每次看多個節點,里面加入了一些 Ability 優化,就算只有一個 Thread 情況下都可以跑得比較快。另外它加入了多個 allocation threads,可以在並行狀態下進行 allocate。經過一些模擬測試可以看到很多場景下達到 5-10 倍的 allocation throughput,現在到每秒鐘 3000、4000 個 Container 的 allocation 是比較正常通過測試的數值。當然,實際可能會有些出入,如果有更精確的數字,希望大家在社區里跟我們溝通。

對于 Containerization,下面是相關的 Improvement。第一個是在 3.1.0 里已經說 Docker container 是 Ready for production;3.2 和 3.3 也有很多功能和穩定化的東西。3.3 第一個功能是支持 Interactive Docker Shell,用戶可以登陸到你的 Docker container 里 Run 一些命令,不用去 SSH 到對應的節點,這樣比較方便調試。第二塊是 OCI/squashfs(Like runc)的支持。這邊的趨勢是大家很多不希望用 Docker container,希望用其他的 runtime。OCI 和 Squashfs 是對應的標準,社區在比較積極的推進。大部分 Test 都已經有 Patch,應該可以在 3.3 里出現。第三塊是 Docker image localization 和相關的 Improvement。以前 YARN 破 Image 時不太清楚知道到底鋪了多少。這塊可以幫助用戶了解當 Docker image 比較大時到底進度是怎麼樣的。

在 YARN+Cloud 的環境下,也有一些對應的改進。這部分改進目前還在不斷進行中,希望大家多提提需求,看看對應的場景是什麼。第一塊是 Auto scaling,在雲上做擴容、縮容的工作;第二塊是做更好的 Scheduling,比如把 Container 能 pack 到盡量小的漏斗。第三塊,比如 Spot instances,當出現一些 Spot instances 時怎麼做 allocation,保證盡量少對好的 Job 帶來影響。雲上經常會出現有些時候漏斗突然不可用的情況,相對私有的數據中心來講,這條相對更容易出現。這塊也要知道怎麼更好的做 Decommissioning,還有就是對于 Services data 的處理。

這塊場景下大家如果有什麼想法或者在雲上已經有了一些工作,可以到 YARN-9548 上評論。

機器學習這塊的工作主要是 Submarine。Submarine 是 3.2.0 第一次加入到 Hadoop 里作為 YARN 的子項目。在今年早些時間,我們把它剝離成在 Hadoop 下的子項目,跟 YARN 和 HDFS 是平級的。之後我們也做了一個 Release0.2.0,0.3.0 里還有很多新的東西。

下圖是社區的 Release Plan︰

 

 

先回顧一下 2018 年的 Release。2018 年做了 2.6、2.7、2.8 的 Maintenance Release,2.9 是一個新的 Release,做了關于 YARN Federation 和 Optimistic Container,這兩塊都是由微軟去做的。3.0 加入了 EC、全局調度器、Resource types、Timeline V2,3.1 加入了 GPU/FPGA、YARN Service、Placement Constraint 可以做一些相關工作。

2019 年到目前為止做了兩個 Release。3.1.2 是一個 Stabilization Release,3.2 加入了 Node Attribute,可以去 Tach,Node 可以在調度時做相應調度,也加入了 Submarine、HDFS 的 SPS,雲的 Connector 上也有一些比較大的 Improvement。

今年剩下的四個月準備多做幾個 Release。第一個是 2.8.6 社區,很希望能做一些 Maintenance Patch,3.1.3 和 3.2.1 也準備做兩個 Maintenaece Release,剛剛介紹的很多關于 HDFS 和 Hadoop 社區的一些工作,像 Federation、Opentracing,這塊大部分功能都準備放到 3.3 里,還有剛剛提到的一些關于 Docker container 等等功能。現在在 3.3 里的 Patch 已經有 1000 多個,整個 Hadoop 社區都在全力準備盡早把這個版本 Release 出去。

堵俊平,來自騰訊,在騰訊大數據負責海量存儲和海量計算。之前是 Apache Hadoop 社區的 Committer 和 PMC,同時也是 Apache 基金會的 Member。

譚望達,來自 Cloudera,負責計算平台,也是 Hadoop 社區的 Committer 和 PMC。

上一篇︰數據科學中的強大思維 通過 Lisp 語言理解編程算法︰數據結構篇下一篇︰

公眾平台

搜索"raincent"或掃描下面的二維碼

?