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

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

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

Hadoop 概述

Hadoop 作為大數(shù)據(jù)的處理平臺已經(jīng)有十幾年的發(fā)展歷史。其設(shè)計思想是使用廉價的臺式機組成一個大的集群做分布式計算與數(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ù)的處理和運算，處理結(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)程?？梢圆渴?~N臺

3. ApplicationMaster：用戶每提交一個應(yīng)用都會包含一個ApplicationMaster, 負(fù)責(zé)與RM通訊申請或釋放資源與NM通訊啟動和停止Task. 監(jiān)控任務(wù)的運行狀態(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ù)對運行環(huán)境需求，我們利用Docker On YARN的模式把運行環(huán)境隔離做了隔離，允許每個人定制自己的運行環(huán)境安裝自己的算法庫。使用Linux CGroup的模式支持嚴(yán)格的計算資源隔離，保證每個作業(yè)的計算資源不受其他作業(yè)影響。另擴展了資源與調(diào)度模型，增加了GPU和其他硬件的調(diào)度支持。為業(yè)務(wù)方統(tǒng)一了日志查詢工具幫助快速定位錯誤。

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

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

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

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

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

為了使新的大數(shù)據(jù)平臺系統(tǒng)更友好更易于管理使用，團隊開啟了界面化項目。我們利用WEB技術(shù)實現(xiàn)了面向管理員的大數(shù)據(jù)平臺管理系統(tǒng)，使用這套管理系統(tǒng)之后可以靈活方便的上下線子集群，實時管理和修改調(diào)度策略，不再需要像以前一樣登陸到對應(yīng)的物理服務(wù)器上執(zhí)行相關(guān)命令。通過標(biāo)準(zhǔn)化系統(tǒng)化，我們將運維命令封裝在了代碼里，每個命令執(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)自己的配置文件，運維起來麻煩不利于管理。

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

1. 客戶端先將作業(yè)提交請求發(fā)送給Router 

2. Router根據(jù)配置的調(diào)度信息將作業(yè)請求轉(zhuǎn)發(fā)給對應(yīng)的子集群 

3. 子集群收到作業(yè)請求之后安排作業(yè)的運行

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

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

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

為了避免Router意外丟失或掛掉，在Router組件方面，我們單獨開發(fā)了高可用和負(fù)載均衡功能，整個集群會部署多臺Router節(jié)點，每個機房都會有一個或多個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è)是否需要跨子集群運行

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)。對此我們也有一些新的功能即將上線。

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

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

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

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