Hadoop年度回顧與2016發展趨勢

 

Hadoop 2015 技術發展與 2016 發展趨勢

Hadoop 部分分為 HDFS 和 YARN 兩部分，首先介紹 HDFS 在 2015 年的進展。

HDFS

HDFS 在 2015 年有幾個重大特性發布，我列出三個最為突出的：

1. 異構存儲介質
2. Truncate 操作的支持，也就是 append 逆操作（HDFS-3107）
3. 異構數據塊的支持，即同一文件數據塊大小可以不一樣，用戶可在 append API 中設置 CreateFlag.APPEND 或 CreateFlag.NEW_BLOCK，以決定是繼續往最后一個 block 中寫數據，還是寫到一個新的 block 中。

異構存儲介質的支持，使得 HDFS 朝著異構混合存儲方向發展。

我們都知道，HDFS 之前是一個以磁盤單存儲介質為主的分布式文件系統。但隨著近幾年新存儲介質的興起，支持多存儲介質早就提上了日程。目前，HDFS 已經對多存儲介質有了良好的支持，包括 Disk、Memory 和 SSD 等。

HDFS 具體支持的介質如下：

• ARCHIVE：高存儲密度但耗電較少的存儲介質，通常用來存儲冷數據。
• DISK：磁盤介質，這是HDFS最早支持的存儲介質。
• SSD：固態硬盤，是一種新型存儲介質，目前被不少互聯網公司使用。
• RAM_DISK ：數據被寫入內存中，同時會往該存儲介質中再（異步）寫一份。

這是 HDFS 異構存儲介質示意圖，我們可以通過參數 dfs.datanode.data.dir 指定每塊盤的類型，這樣，當寫文件時，可以指定文件存儲到某種存儲介質上。

這張表給出了 HDFS 支持的存儲策略，不同的策略，存儲方式是不同的。用戶可以針對不同類型的文件，定制相應的存儲策略。

說到異構存儲，很多人可能會想到 Spark 社區提出的 Tachyon，它是 Distributed cache system on HDFS，最初是為了解決不同應用程序間共享 RDD 而產生的，現已發展成通用系統。

但很不幸，HDFS 社區的也正在做類似的事情，有兩個重大 feature，大家可以關注下：

• Centralized CacheManagement (HDFS-4949)，允許用戶指定將某些文件或目錄緩存到內存中。
• DDM：Discardable Distributed Memory（HDFS-5851），使用 YARN 作為資源管理系統，管理內存資源。

在 HDFS 之上單獨搞多存儲介質支持是不太友好的，最好跟 Hadoop 中資源管理系統 YARN 做一個結合，所以，有人預測，HDFS 和 YARN 的關系會逐步朝下圖展示的方式發展：

也就是說，YARN 統一管理異構存儲介質和資源，包括磁盤，SSD，網絡，CPU 和 memory，并將這些資源分配給 MapReduce，HBase，甚至 HDFS。

YARN

在2015年，YARN 取得了重大進展，本來準備了 5 個特性，由于時間關系，今天主要介紹三個：

1. 基于標簽的調度
2. 對長服務的支持
3. 對 Docker 的支持

這個特性使得 YARN 能夠更好地支持異構集群調度。它的基本思想是，管理員可為每個 NodeManager 賦予一個或多個標簽（就是一字符串），之后在調度器中配置資源隊列與 label 的對應關系（目前僅支持 Capacity Scheduler），這樣，管理員就實現了：按照節點類型將 YARN 分成若干個邏輯上相互獨立（可能交叉）的集群。這種集群跟物理上獨立的集群很不一樣，用戶可以很容易地通過動態調整 label，實現不同類型節點數目的增減，這具有很好的靈活性。

給大家舉兩個例子，這都是在 Hulu 內部的實際應用：

1. 一個 Hadoop 集群，20 臺服務器，一半高配置，一半低配置，如何將 Spark 作業僅運行在高配置的 NodeManager 上。
2. 一個 Hadoop 集群，1,000 臺機器，只想讓 Docker 運行在某 10 個 NodeManager 上（安裝和維護 Docker engine 麻煩）。

這兩種應用場景，都可以很好地使用標簽調度解決

這是一個可能的部署圖。YARN 在 2015 年新增的另外一個重大特性是：支持長服務。

YARN 的最終定位是通用資源管理和調度系統，包括支持像類似 MapReduce，Spark 的短作業和類似 Web Service，MySQL 的長服務。 支持長服務是非常難的一件事情，YARN 需要解決以下問題：服務注冊、日志滾動、ResourceManager HA、NodeManager HA（NM 重啟過程中，不影響 Container）和 ApplicationMaster 永不停止，重啟后接管之前的 Container。

目前 Apache 有個二級項目叫 Apache Slider，可以幫助用戶把已有應用或服務運行在 YARN 上，比如 HBase，Presto 等都已經通過 Slider 部署到 YARN 上。

YARN 第三個重大特性是實現了一個簡易版 Docker On YARN。

實現思路是：YARN 的 ContainerExecutor 是可插拔的，目前提供了兩種實現：DefaultContainerExecutor 和 LinuxContainerExecutor，而 Docker On YARN 正是通過引入第三種 ContainerExecutor 實現的，叫 DockerContainerExecutor

在 YARN 上運行一個 Docker Container 的方式如下，大家感受下：

當然，目前 YARN 自帶的 Docker On YARN 是有很多局限性的，包括：

• ContainerExecutor 是系統級別配置，只能配置一個，這意味著用戶如果在 YARN 中運行 Docker Container，就不能再運行 MapReduce，Spark 等其他類型的應用程序。
• 難以同時運行多個 Docker Container 。
• 需自己編寫 Application On YARN 解決容錯等問題。

為此，Hulu 內部自己開發了 Voidbox，一個較好的 Docker On YARN 方案。Hulu 的 Docker On YARN 方案叫 Voidbox，它提供了豐富的編程 API，支持 DAG Batch job 和 Long running Service 兩種應用，具備良好的容錯性。

由于篇幅關系，感興趣的同學可參考我的技術博客：http://dongxicheng.org/mapreduce-nextgen/voidbox-docker-on-hadoop-hulu/

2016 年發展趨勢

對于 HDFS，會朝著異構存儲介質方向發展，尤其是對新興存儲介質的支持。對于 YARN，會朝著通用資源管理和調度方向發展，而不僅僅限于大數據處理領域，包括對 MapReduce、Spark 短作業的支持，以及對 Web Service 等長服務的支持。

Q & A

1、Yarn 支持長服務？什么是長服務？長連接服務嗎？

長服務是指永不停止的應用應用程序（除非異常退出或用戶主動關閉），比如 Web Server，MySQL 等，長服務是相對短作業而言的，短作業是指分鐘，小時級別就會退出的應用程序。

2、我們用 0.x 版本的 Hadoop 的時候，集群從 100 臺升級到 200 臺調度器遇到瓶頸。Yarn 的調度算法有這方面的優化嗎？一般能達到多大的集群？

Yarn 有優化的，規模上千臺都不會有瓶頸，應該沒有問題。0.x 版本調度器實現非常差，遇到瓶頸不足為奇。

3、講的例子中一部分高配機器，一部分低配機器，運行某任務只用高配的，是為什么，多一些不更好嗎？還是說為了防止出現低配節點過長時間等待的問題？

一般而言，公司的集群都是異構的，比如剛開始（N年前）買的是 24GB 機器，后來又買了 48GB 機器，最近買的是 128GB 內存，對于一些特殊的應用，對資源要求比較高，比如 Spark，機器越好，跑的越快，這時候將 Spark 運行在高配置機器上是很好地選擇（如果同時運行在高配置和低配置機器中，可能讓慢任務拖后腿，非常不利于 Spark 的運行），低配置的可以用來跑 MapReduce 等離線應用。你說的防止出現低配節點過長時間等待的問題，也是一個原因。

4、上文提到了 YARN 新特性支持 Docker，Docker 也有一個資源管理項目 Mesos，如果 YARN 從 Mesos 來獲取資源的話是否也是可行？ 因為在晚上的時候業務對資源使用是一個峰谷，而離線任務恰恰在晚上需要大量計算資源。

YARN 從 Mesos 來獲取資源是可行的，好像也有開源項目（需要對 YARN 進行適當修改）在做。但是我懷疑這種方案的維護成本，YARN 和 Mesos 都是一個分布式資源管理系統，是復雜度較高的系統，將兩個系統疊加起來用，穩定性是不容易保證的。

5、Storm、MR，Spark 這些 CPU 密集型的任務是否應該放到不同 YARN 中？

Storm、MR，Spark 這些任務（他們全是 CPU 密集型的，Spark 是內存密集型，MR 是 IO 密集型）可以混合運行在 YARN 集群中，讓 YARN 統一管理和調度，很多公司都是這么做的，包括 Hulu，Yahoo！等。