作者 | 吳怡燃 

成都創(chuàng)新互聯(lián)主要從事網(wǎng)頁設(shè)計、PC網(wǎng)站建設(shè)（電腦版網(wǎng)站建設(shè)）、wap網(wǎng)站建設(shè)（手機(jī)版網(wǎng)站建設(shè)）、響應(yīng)式網(wǎng)站設(shè)計、程序開發(fā)、網(wǎng)站優(yōu)化、微網(wǎng)站、小程序設(shè)計等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們在互聯(lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)積累了豐富的成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、網(wǎng)絡(luò)營銷經(jīng)驗，集策劃、開發(fā)、設(shè)計、營銷、管理等多方位專業(yè)化運(yùn)作于一體。

轉(zhuǎn)自 | 京東技術(shù)

京東為什么要做萬臺規(guī)模的Hadoop？

隨著京東的業(yè)務(wù)增長，原有的Hadoop集群已經(jīng)無法滿足高速增長的存儲與計算需求。拆分集群雖然可以分擔(dān)一部分壓力，但帶來了另外的一些問題，如拆分集群之后假如某個業(yè)務(wù)無法避免的需要另外一個集群上的數(shù)據(jù)，這時便帶來了跨集群讀數(shù)據(jù)的問題，嚴(yán)重影響了作業(yè)執(zhí)行效率。另一方面，各個集群總有閑忙時間，在某個集群閑時這些資源是浪費(fèi)的并沒有產(chǎn)生價值。

為了增加生產(chǎn)效率和節(jié)約成本，必須要將之前分散在各處的集群資源統(tǒng)一管理起來，組成一個超大集群對外提供服務(wù)，并且要讓各種并行框架可以利用它的存儲和計算資源進(jìn)行業(yè)務(wù)處理。

Hadoop 概述

Hadoop 作為大數(shù)據(jù)的處理平臺已經(jīng)有十幾年的發(fā)展歷史。其設(shè)計思想是使用廉價的臺式機(jī)組成一個大的集群做分布式計算與數(shù)據(jù)存儲，利用冗余備份的方式保證數(shù)據(jù)的安全性和高可用，通過并行計算的方式完成超大數(shù)據(jù)集的快速處理。

通過增加節(jié)點的方式提升Hadoop集群的計算和存儲能力。通常在分布式并行處理數(shù)據(jù)時，移動計算代碼的成本會低于移動數(shù)據(jù)，所以Hadoop的MapReduce框架計算時會將計算代碼分發(fā)到每個數(shù)據(jù)節(jié)點上執(zhí)行，利用數(shù)據(jù)本地性較少的網(wǎng)絡(luò)交互提升性能。

過去Hadoop 2.0版本之前，Hadoop在設(shè)計上包含兩部分，第一部分是分布式存儲HDFS，另一部分是MapReduce 計算框架。自Hadoop2.0 版本之后，計算框架部分做了優(yōu)化升級變成了我們現(xiàn)在用的YARN (Yet Another Resource Negotiator) , YARN提供了分布式資源管理和作業(yè)調(diào)度的功能，同時提供了統(tǒng)一的編程模型，通過這個編程模型很多計算框架可以遷移到Y(jié)ARN上來。

從愿景上，Hadoop 致力于解決復(fù)雜數(shù)據(jù)的處理和運(yùn)算，處理結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)存儲，提供分布式海量數(shù)據(jù)并行處理。

回想過去我們使用MPI、OpenMP去實現(xiàn)一個分布式處理程序，那時我們需要自己控制程序的遠(yuǎn)程啟動與停止，同時要自己編寫容錯代碼?，F(xiàn)在Hadoop通過優(yōu)化和抽象將這些繁瑣的、能夠通用的功能都封裝到了框架中，讓開發(fā)者只需要關(guān)注自己的業(yè)務(wù)邏輯代碼而不需要再寫一些錯誤重試和通訊相關(guān)的代碼，大大增加了開發(fā)效率。同時使用那些并不太擅長編寫代碼的數(shù)據(jù)工程師也可以輕松使用Hadoop集群去實現(xiàn)自己的分布式處理分析程序。

在Hadoop 2.0 YARN 架構(gòu)下，主要有以下幾個組件：

1. ResourceManager ：主節(jié)點服務(wù)，負(fù)責(zé)維護(hù)節(jié)點信息和負(fù)責(zé)資源管理與作業(yè)調(diào)度, 可以部暑兩臺并利用Zookeeper 實現(xiàn)高可用 2. NodeManager ：計算節(jié)點服務(wù)，負(fù)責(zé)提供計算和管理當(dāng)前節(jié)點上的Container進(jìn)程。可以部署1~N臺 3. ApplicationMaster ：用戶每提交一個應(yīng)用都會包含一個ApplicationMaster, 負(fù)責(zé)與RM通訊申請或釋放資源與NM通訊啟動和停止Task. 監(jiān)控任務(wù)的運(yùn)行狀態(tài) 4. Container ：Container是YARN中的資源抽象，它封裝了多個緯度的資源，如CPU、內(nèi)存、磁盤等 5. Client ：負(fù)責(zé)提交作業(yè)，同時提供一些命令行工具

京東Hadoop分布式資源管理與作業(yè)調(diào)度介紹

京東從很早之前就開始使用Hadoop，踩了很多坑，從過去摸著石頭過河到現(xiàn)在小有所成，無論是業(yè)務(wù)問題還是Hadoop框架本身的問題，我們都遇到過。

通過解決這些問題我們對Hadoop做了很多功能升級與修改，其中有一些功能回饋到了社區(qū)，另外一些沉淀到了我們自己的分支版本中。今天我們的Hadoop大數(shù)據(jù)平臺提供了豐富的功能、完善的工具，為京東大數(shù)據(jù)業(yè)務(wù)保駕護(hù)航。

目前在京東大數(shù)據(jù)環(huán)境下，為滿足不同業(yè)務(wù)對運(yùn)行環(huán)境需求，我們利用Docker On YARN的模式把運(yùn)行環(huán)境隔離做了隔離，允許每個人定制自己的運(yùn)行環(huán)境安裝自己的算法庫。使用Linux CGroup的模式支持嚴(yán)格的計算資源隔離，保證每個作業(yè)的計算資源不受其他作業(yè)影響。另擴(kuò)展了資源與調(diào)度模型，增加了GPU和其他硬件的調(diào)度支持。為業(yè)務(wù)方統(tǒng)一了日志查詢工具幫助快速定位錯誤。

過去大數(shù)據(jù)平臺這邊有各種小集群，如：Presto, Alluxio 等，每個小集群都有自己的一批機(jī)器，每臺機(jī)器上可能只部署一個服務(wù)，這些服務(wù)對機(jī)器的利用率并不高，甚至是浪費(fèi)的，痛定思痛，我們決定利用YARN統(tǒng)一進(jìn)行資源管理與調(diào)度。經(jīng)過幾年的發(fā)展，我們將大部分的并行框架都移植到了YARN上運(yùn)行（如：Presto、Alluxio），利用YARN的優(yōu)勢和調(diào)度特點充分的利用這些機(jī)器資源，大大提升了集群資源利用率。

  

同時我們也自研了Tensorflow On YARN 、Caffe On YARN 等一系列的深度學(xué)習(xí)框架與工具幫助算法工程師直接使用Hadoop集群進(jìn)行算法處理。大大加快了算法與業(yè)務(wù)迭代速度。讓大數(shù)據(jù)平臺獲得了深度學(xué)習(xí)處理的能力。

 

后來為了更好的支持異地多活和跨地域擴(kuò)展能力，我們再次改造升級實現(xiàn)了萬臺Hadoop集群分布式資源管理與調(diào)度系統(tǒng)，解決了之前單集群擴(kuò)展瓶頸和無法有效支撐跨機(jī)房調(diào)度與災(zāi)備的問題。該系統(tǒng)已經(jīng)在線上部署，并經(jīng)過了今年618的大促考驗，可以說是穩(wěn)如磐石。

系統(tǒng)逐步鋪開上線之后我們將京東跨地域的幾個大數(shù)據(jù)機(jī)房實現(xiàn)了互聯(lián)，同時我們的HDFS也配套實現(xiàn)了同樣的跨機(jī)房功能，也在這時京東大數(shù)據(jù)處理平臺系統(tǒng)真正擁有了跨地域的部署與擴(kuò)展能力。

系統(tǒng)具有非常強(qiáng)的靈活性，可以通過修改調(diào)度路由策略和存儲數(shù)據(jù)映射表，輕松的做到跨機(jī)房的作業(yè)遷移和數(shù)據(jù)遷移。同機(jī)房內(nèi)不同集群之間可以實現(xiàn)作業(yè)跨子集群運(yùn)行充分利用各集群資源，功能可隨時根據(jù)子集群負(fù)載動態(tài)開關(guān)，無需用戶參與，對用戶完全透明。

為了使新的大數(shù)據(jù)平臺系統(tǒng)更友好更易于管理使用，團(tuán)隊開啟了界面化項目。我們利用WEB技術(shù)實現(xiàn)了面向管理員的大數(shù)據(jù)平臺管理系統(tǒng)，使用這套管理系統(tǒng)之后可以靈活方便的上下線子集群，實時管理和修改調(diào)度策略，不再需要像以前一樣登陸到對應(yīng)的物理服務(wù)器上執(zhí)行相關(guān)命令。通過標(biāo)準(zhǔn)化系統(tǒng)化，我們將運(yùn)維命令封裝在了代碼里，每個命令執(zhí)行前后都有相關(guān)的校驗與權(quán)限認(rèn)證，減少人工操作時出現(xiàn)的誤操作，如果發(fā)生錯誤系統(tǒng)將自動回滾。

平臺提供了基于用戶級的權(quán)限管理，可以很靈活的管理集群中計算資源的權(quán)限，以實現(xiàn)控制每個用戶可以使用的計算資源量大小和資源池使用權(quán)限認(rèn)證。

真實生產(chǎn)環(huán)境中平臺會把資源按照一定的使用規(guī)則進(jìn)行劃分，并分配相關(guān)的權(quán)限給對應(yīng)的人或部門，從而避免某些用戶惡意提交作業(yè)到別人的資源池。同時平臺也細(xì)化了操作權(quán)限避免某些用戶惡意操作別人的作業(yè)（如：停止執(zhí)行）。 

之前大數(shù)據(jù)平臺會存在多個集群，每個集群對應(yīng)自己的客戶端，每個客戶端對應(yīng)自己的配置文件，運(yùn)維起來麻煩不利于管理。

調(diào)度架構(gòu)修改升級完之后，從邏輯上可以理解為增加了一層調(diào)度抽象（Router），由原來的兩級調(diào)度變成了三級調(diào)度。也就是子集群的策略選擇。現(xiàn)在的作業(yè)提交流程是：

1. 客戶端先將作業(yè)提交請求發(fā)送給Router  2. Router根據(jù)配置的調(diào)度信息將作業(yè)請求轉(zhuǎn)發(fā)給對應(yīng)的子集群  3. 子集群收到作業(yè)請求之后安排作業(yè)的運(yùn)行

在這種方式下，每個客戶端使用同樣的一套配置文件，保證了客戶端輕量級，不再像之前一樣需要區(qū)分集群信息。所有的調(diào)度策略與邏輯都封裝在Router組件中。（所有的調(diào)度策略和控制信息我們保存在DBMS中）

增加了作業(yè)的動態(tài)跨子集群借用資源功能，可以隨時控制某個隊列中的相關(guān)作業(yè)是否需要跨子群執(zhí)行。方便單個子集群在資源緊張時動態(tài)去借用另一個空閑集群的資源。

增加了邏輯隊列名的概念，對于用戶來說他們只需要關(guān)心自己的邏輯隊列名，而真正運(yùn)行作業(yè)是在哪個物理隊列則不需要他們關(guān)心，通過這個功能平臺端可以隨時控制邏輯隊列真正運(yùn)行在哪個子集群的哪個物理隊列。達(dá)到快速遷移或容災(zāi)的目的。

為了避免Router意外丟失或掛掉，在Router組件方面，我們單獨開發(fā)了高可用和負(fù)載均衡功能，整個集群會部署多臺Router節(jié)點，每個機(jī)房都會有一個或多個Router, 客戶端的請求會根據(jù)負(fù)載和距離從分散的多個Router服務(wù)器上選擇一個最合適的。同時我們支持任何時間點Router掛掉（如果Router的連接狀態(tài)不可用客戶端會自動切換到另外一個Actvie的Router）

下面是這個架構(gòu)的邏輯框圖，包含了整個架構(gòu)中所有組件。其中新增是Router和State&Policy Store 兩個組件，前者直接對接Client 屏蔽后端RM子集群相關(guān)信息提供提交與作業(yè)信息查詢的功能，可以同時部署多臺對外提供服務(wù)。后者負(fù)責(zé)保存當(dāng)前所有子集群的狀態(tài)信息、Active RM 的地址信息和調(diào)度策略信息。（每隔一段時間子集群會以心跳的方式匯報自己當(dāng)前的服務(wù)狀態(tài)并存儲到StateStore中）目前我們支持多種調(diào)度策略可以滿足多種場景下的調(diào)度需求。

具體提交流程如下：

1. Client 提交作業(yè)到Router上 2. Router 獲取邏輯隊列調(diào)度策略信息 3. 將作業(yè)提交請求轉(zhuǎn)提到對應(yīng)的ResourceManager上，并保存Application相關(guān)信息到StateStore中 4. ResourceManager接收到請求后啟動AppMaster, AppMaster啟動之后向AMRMProxy發(fā)起資源請求 5. AMRMProxy 接收到這個請求之后，從State&Store Policy中讀取策略信息，判斷這個作業(yè)是否需要跨子集群運(yùn)行 6. 向?qū)?yīng)的子集群發(fā)送資源請求，AppMaster負(fù)責(zé)啟動請求到的Container

超大規(guī)模Hadoop集群優(yōu)化策略&優(yōu)化思路

原生的調(diào)度器，存在很多問題。其中最主要的是性能問題，為此我們自研了一個基于隊列鏡像的多路分配策略，大大提升了ResourceManager調(diào)度器的性能，讓我們單個YARN子集群擁有了超過萬臺規(guī)模資源管理與調(diào)度能力。

另一方面豐富了調(diào)度器分配資源的算法邏輯，增加多個維度的排序篩選規(guī)則，多個規(guī)則之間可以組合使用，如：基于內(nèi)存、基于負(fù)載 、基于使用率等等。

還有其他一些ResourceManager性能相關(guān)的代碼優(yōu)化，如：簡化資源計算流程，拆分鎖等等。

在MapReduce方面優(yōu)化了服務(wù)性能和框架功能。主要與Shuffle 服務(wù)相關(guān)。

優(yōu)化&分析&測試工具

    

Benchmark

• HiBench  https://github.com/intel-hadoop/HiBench

• Hadoop 自帶 Benchmark

JVM分析工具

• http://gceasy.io/

• http://fastthread.io

Linux 性能分析

• Perf

• NMON

• Google Tools

未來展望與期待

京東大數(shù)據(jù)平臺的實踐提供了一種可供參考的技術(shù)架構(gòu)與實施方式。未來，京東大數(shù)據(jù)平臺依然會在電商級分布式架構(gòu)與技術(shù)方案演進(jìn)方向繼續(xù)前進(jìn)。對此我們也有一些新的功能即將上線。

一、如何利用集團(tuán)內(nèi)的資源節(jié)省成本

過去每年的大促都需要根據(jù)往年的流量進(jìn)行機(jī)器的采購，大促結(jié)束之后這些機(jī)器利用率很低浪費(fèi)了大量成本，為了解決這個問題，目前的大數(shù)據(jù)平臺已經(jīng)與集團(tuán)內(nèi)的專有云-阿基米德完成了對接，平臺可以通過自動伸縮的方式彈性使用云資源，未來的大促中將利用這個功能去承接一部分計算任務(wù)。

二、大數(shù)據(jù)平臺產(chǎn)品化

京東在大數(shù)據(jù)處理方面積累了豐富的經(jīng)驗，同時沉淀出了一些很優(yōu)秀的中間件和服務(wù)產(chǎn)品，未來我們將陸續(xù)把這些產(chǎn)品云化對外提供服務(wù)。

作者 | 吳怡燃

京東大數(shù)據(jù)平臺高級技術(shù)專家，擅長大數(shù)據(jù)平臺的資源管理與調(diào)度系統(tǒng)的開發(fā)與建設(shè)。目前專注于以萬臺分布式調(diào)度系統(tǒng)及深度學(xué)習(xí)平臺的開發(fā)與建設(shè)。

網(wǎng)站名稱：京東萬臺規(guī)模Hadoop集群|分布式資源管理與作業(yè)調(diào)度-創(chuàng)新互聯(lián)
新聞來源：http://vcdvsql.cn/article34/djpepe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、網(wǎng)站內(nèi)鏈、域名注冊、關(guān)鍵詞優(yōu)化、移動網(wǎng)站建設(shè)、網(wǎng)站設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)