京東為什么要做萬臺規模的Hadoop？

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

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

Hadoop 概述

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

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

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

從愿景上，Hadoop 致力于解決復雜數據的處理和運算，處理結構化和非結構化數據存儲，提供分布式海量數據并行處理。

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

在Hadoop 2.0 YARN 架構下，主要有以下幾個組件：

1. ResourceManager：主節點服務，負責維護節點信息和負責資源管理與作業調度, 可以部暑兩臺并利用Zookeeper 實現高可用

2. NodeManager：計算節點服務，負責提供計算和管理當前節點上的Container進程。可以部署1~N臺

3. ApplicationMaster：用戶每提交一個應用都會包含一個ApplicationMaster, 負責與RM通訊申請或釋放資源與NM通訊啟動和停止Task. 監控任務的運行狀態

4. Container：Container是YARN中的資源抽象，它封裝了多個緯度的資源，如CPU、內存、磁盤等

5. Client：負責提交作業，同時提供一些命令行工具

京東Hadoop分布式資源管理與作業調度介紹

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

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

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

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

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

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

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

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

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

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

真實生產環境中平臺會把資源按照一定的使用規則進行劃分，并分配相關的權限給對應的人或部門，從而避免某些用戶惡意提交作業到別人的資源池。同時平臺也細化了操作權限避免某些用戶惡意操作別人的作業（如：停止執行）。 

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

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

1. 客戶端先將作業提交請求發送給Router 

2. Router根據配置的調度信息將作業請求轉發給對應的子集群 

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

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

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

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

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

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

具體提交流程如下：

1. Client 提交作業到Router上

2. Router 獲取邏輯隊列調度策略信息

3. 將作業提交請求轉提到對應的ResourceManager上，并保存Application相關信息到StateStore中

4. ResourceManager接收到請求后啟動AppMaster, AppMaster啟動之后向AMRMProxy發起資源請求

5. AMRMProxy 接收到這個請求之后，從State&Store Policy中讀取策略信息，判斷這個作業是否需要跨子集群運行

6. 向對應的子集群發送資源請求，AppMaster負責啟動請求到的Container

超大規模Hadoop集群優化策略&優化思路

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

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

還有其他一些ResourceManager性能相關的代碼優化，如：簡化資源計算流程，拆分鎖等等。

在MapReduce方面優化了服務性能和框架功能。主要與Shuffle 服務相關。

優化&分析&測試工具    

Benchmark

• HiBench  https://github.com/intel-hadoop/HiBench
• Hadoop 自帶 Benchmark

JVM分析工具

• http://gceasy.io/
• http://fastthread.io

Linux 性能分析

• Perf
• NMON
• Google Tools

未來展望與期待

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

一、如何利用集團內的資源節省成本

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

二、大數據平臺產品化

京東在大數據處理方面積累了豐富的經驗，同時沉淀出了一些很優秀的中間件和服務產品，未來我們將陸續把這些產品云化對外提供服務。