一、大數據集群技術的概述

讓我們從有趣的 “啤酒與尿布” 故事說起，在美國沃爾瑪連鎖超市，人們發現了一個特別有趣的現象：尿布與啤酒這兩種風馬牛不相及的商品居然擺在一起，但這一奇怪的舉措居然使尿布和啤酒的銷量大幅增加了。這并非一個笑話，而是一個真實案例。

[[181333]]

原來，美國的婦女通常在家照顧孩子，所以她們經常會囑咐丈夫在下班回家的路上為孩子買尿布，而丈夫在買尿布的同時又會順手購買自己愛喝的啤酒。這個發現為商家帶來了大量的利潤，但是如何從浩如煙海卻又雜亂無章的數據中，發現啤酒和尿布這個看似不相干的物品銷售之間的聯系呢?這就是大數據的威力。

大數據在我們的生活中，發揮著越來越明顯的作用。比如，大數據輔助購物平臺推薦適合客戶的產品，大數據輔助避免堵車，大數據輔助做健康檢查，大數據娛樂等。

對于很多公司來說，數據是有的，但是是”死”數據，并不能發揮作用，或者產生的價值不到實際價值的冰山一角。如果想從大數據中獲利，數據的采集、挖掘和分析等環節缺一不可，其中，大數據分析技術是重中之重，目前的大數據分析技術有 Hadoop、Spark、Strom 中。

要想從一大堆看似雜亂無章的數據中總結出規律，需要對這些數據進行一番非常復雜的計算分析。

由于數據量之大，對計算的速度和精度要求都比較高，單純的通過不斷增加處理器的數量來增強單個計算機的計算能力已經達不到預想的效果，那么，大數據處理的方向逐漸的朝著分布式的計算集群來發展，將分布在不同空間的計算機通過網絡相互連接組成一個有機的集群，然后將需要處理的大量數據分散到這個集群中，交由分散系統內的計算機組，同時計算，***將這些計算結果合并得到最終的結果。

盡管分散系統內的單個計算機的計算能力不強，但是由于每個計算機只計算一部分數據，而且是多臺計算機同時計算，所以就分散系統而言，處理數據的速度會遠高于單個計算機。

那么如何部署和管理大數據集群，則是業界持續討論的話題，本文以 IBM Platform Converge 為例，來闡述大數據集群部署、架構以及管理。IBM Platform Converge 是一種復雜的大數據處理平臺(方案)，此方案可以從若干個物理機/虛擬機(可能在云端)開始，可以比較方便的部署一個大數據集群，并且管理和監控此集群。

此平臺包括了若干個大數據技術和集群技術，比如 xCAT、Spark、ELK、GPFS 等。此集群的優點是節點的數量和存儲的空間都具有彈性，也就是說，可以隨時根據業務和應用的需求，來增加或者刪除集群中的節點和存儲空間，依次來節省成本。

二、大數據集群技術的架構與分析

一般來說，大數據集群的構架，主要分為幾層：硬件層、OS 層、基礎設施管理層、文件系統層、大數據集群技術層以及上層應用，如下圖 1 所示。

圖 1 大數據集群的架構

首先最下層為硬件，這些硬件可能為不同的廠商機器，比如 IBM、HP、DELL 或者聯想等服務器，也有可能包括不同的構架，比如 System X 或者 IBM POWER 等機器。這些機器有可能在機房，也有可能在云端(包括公有云和私有云)。硬件之上，需要安裝運行操作系統(OS)，一般為 Linux OS，比如 Redhat、SUSE、Ubuntu 等。

在基礎設施管理層，主要管理資源(更多的是軟件資源)以及資源的虛擬化等，比如網絡資源/設備、計算資源、內存、Slots 等的統一管理和優化分配，在此層，同時肩負著部署大型 Cluster 的任務，也就是將各個分散的節點通過 IBM SCF(Spectrum Cluster Foundation)軟件，統一部署為一個整體。

在 IBM SCF 集群中，分為管理節點和計算節點。部署的順序為，需要首先安裝管理節點，然后按照不同的硬件、網絡、OS 等配置集，來部署出計算節點。為了提高集群的魯棒性，IBM SCF 本身支持高可用性(HA)，在安裝完管理節點之后，使用類似的方法，來部署出備份的管理節點。

并行的文件系統，是大數據集群的重中之重，因為大數據有兩個主要的特征，其一是數據量比較大，起步可能就以 PB 為單位，如此巨量數據的存儲成為了集群需要解決的關鍵問題之一;另外一個特征是處理速度要快，隨著集群技術的發展，并行化的思想尤為明顯，并行化的計算產品和工具也層出不窮。

所以，并行的文件系統是大數據集群中不可或缺的一部分。比如，在 Hadoop 時代，HDFS 就在 Hadoop 陣營中，貢獻了中流砥柱的作用。另外一個出色的并行文件系統為 IBM Spectrum Scale，其前身為 IBM GPFS，經過近來的版本迭代和發展，已經***的支持目前流行的大數據計算模式，比如 Spark 等。

在資源管理和大數據集群層，主要部署兩方面的組件，一是大數據分析處理組件，二是資源調度和管理組件。

在一般情況下，這二者都是有機的結合在一起，組成一個產品。隨著大數據的發展，大數據的分析和處理技術如井噴一般涌現出來。比如有 Hadoop, Spark, Storm, Dremel/Drill 等大數據解決方案爭先恐后的展現出來，需要說明的是，這里所有的方案不是一種技術，而是數種，甚至數十種技術的組合。

就拿 Hadoop 來說，Hadoop 只是帶頭大哥，后面的關鍵的小弟還有：MapReduce, HDFS, Hive, Hbase, Pig, ZooKeeper 等等，大有”八仙過海，各顯神通”的氣勢和場面。資源調度管理，主要是維護、分配、管理、監控軟硬件資源，包括節點、網絡資源、CPU、內存等，根據數據處理的需求來分配資源，并負責回收。

在此模型中，我們使用了 Spark 來處理大數據，使用 IBM Platform Enterprise Grid Orchestrator (EGO)來管理和監控資源。IBM Platform 是一種資源管理和調度、服務管理的工具。類似于大家熟知的 Mesos 或者 Yarn。

由于 IBM Platform EGO 目前并非開源產品，在此做一簡單介紹。在 IBM Platform EGO 中，VEM kernel daemon (VEMKD)是 VEM 內核后臺程序，一般運行在管理節點上，會啟用其它后臺程序并對分配請求做出響應。EGO Service Controller (EGOSC)屬于 EGO 服務控制器，負責向 VEMKD 申請相應資源并控制服務實例。流程處理管理器(簡稱 PEM)負責 VEMKD 中的啟用、控制以及監控活動，同時收集并發送運行時資源的使用情況。EGO 中 Consumer，代表的是能夠從集群處申請資源的一個實體。

單一 Consumer 可以是業務服務、包含多種業務服務的復雜業務流程、單一用戶或者一整條業務線。和開源的 Spark 一樣，Spark 和 EGO 使用相同的 DAGScheduler 和 TaskScheduler，構架圖如圖 2 所示。

EGOSchedulerBackend 根據 Taskscheduler 提供的 task 和 task stage 等信息，負責從目前的 EGO 框架中獲得資源。用戶可以自定義資源分配方案，通過 Consumer 來分配資源。EGOSchedulerBackend 一旦獲得資源，就可以通過 EGO Container 接口開始運行 Spark Executor。

EGOSchedulerBackend 監控 Spark Executor 運行的生命周期，以及資源使用情況和 task 狀態等，比如當 task 完成時，EGOSchedulerBackend 觸發調度邏輯來滿足更多資源的獲取或者資源的釋放。

最上層為應用和業務，客戶只需要提交 Spark Application 即可，集群負責統一的管理和調度，并返回執行結果。

三、大數據集群的部署

3.1 硬件的部署

在此集群部署中，借助了比較成熟的硬件部署工具 Extreme Cloud Administration Toolkit (xCAT), xCAT 是一個開源的集群管理工具，能用于裸機部署，其架構如圖 3 所示。

xCAT 可以自動發現硬件，開機之后，可以由 xCAT 從裸機自動引導安裝，當然，也可以提前導入 client node 信息，xCAT 可以基于 IPMI 進行遠程硬件控制，如開關機，如收集 CPU 的溫度等狀態信息，支持 X86_64、POWER、System Z 等硬件類型。

支持的目前所有主流的操作系統，如 RHEL,CentOS, Fedora, Ubuntu, AIX, Windows, SLES, Debian 等。xCAT 各個組件的結構和流程如下圖所示。在 xCAT 部署的集群中，主要有三種 Node: 管理節點(Management Node)、服務節點(Service Node)、計算節點(Compute Node)，如果并非特別大的集群，一般情況下，服務會被省略掉，只有管理節點和計算節點。管理節點上啟動 DHCPD、tftpd、httpd、DNS、ntpd、syslogd、DB 等服務。

3.2 軟件的部署

軟件部署主要在集群已經建立完成的基礎上，并行在各個節點上安裝大數據分析處理系統，在”資源管理和大數據集群”層，部署 Spark Cluster，并和 Platform EGO 深度集成，一些管理和監控等方面的程序也相繼安裝。還有，在提交應用之前，需要先創建 SIG(Spark Instance Group)，并啟動 SIG，在創建 SIG 之后，也為 Platform EGO 來管理和控制其相關的服務。

3.3 高可用性(HA)部署

在 IBM Platform Converge 中，高性能部署的構架如下圖所示。通常有三個節點構成，分別為主管理節點 Management Node 1(MN1)、次管理節點 Management Node 2(MN2)和第三管理節點 Management Node 3(MN3)。但是需要說明的是，在 failover 切換的過程中，必須保證 MN1 和 MN2 其中一個健在，因為 MN3 只是負責 IBM Spectrum Scale 的 HA 過程，主要的服務和進程只運行在 MN1 和 MN2 上，在這二者之間進行切換。高可用性的部署如圖 4 所示。

四、大數據集群的管理與監控

在大數據集群中，管理和維護是一件非常麻煩的事情，有可能會出現各種各樣的問題，如果出現了，***的辦法是分析 LOG 和監控，在運維過程中，管理員需要不時的查看監控，并善于從監控中找到問題，及時的分析和解決 Cluster 中的報警(Alert)。以下展示了基本的 Cluster 的監控指標，比如 CPU、內存、存儲資源、網絡等。

在此集群中，監控主要采用的是 ELK 的日志監控分析系統，大致流程為，有 Beats 來收集日志和數據，然后發給 Logstash 來分析和處理日志再由 Elasticsearch 存儲和檢索，***由 Kibana 來在 Web GUI 頁面上展示出來。接下來，我們展示出幾個方面的集群的監控。

4.1 CPU 的監控

圖 5 展示了 Spark 集群中的 CPU 利用率的監控。如果 Spark 集群中的節點可能較多，可以使用 Kibana 的功能，來展示出 CPU 利用率***的幾個節點(圖中展示的是 5 個節點的情況)，以便了解哪些節點的負載較重，當然也可以展示出整個系統平均的負載情況。

4.2 內存的監控

眾所周知，Spark 是一種內存利用率非常高的技術，換句話說，Spark 集群對內存的要求較高。Spark 集群的管理者需要實時的掌握內存的使用情況。如圖 6 所示，展示出了集群中內存占用率比較高的節點的情況。

圖 6 內存監控

4.3 磁盤和文件系統的監控

圖 7 展示了總體磁盤的個數，有問題磁盤的個數，和總體磁盤的使用率，對磁盤利用率的監控可以有效的防止因存儲空間不夠而影響應用的運行。

五、結束語

近幾年來，數據的價值正得到越來越多的人的重視，如何讓數據”活起來”，一直是 IT 界持續討論的話題，在這種利益的驅動下，大數據的分析技術可謂是”遍地開花”，大數據集群的部署方案也層出不窮，針對不同的場景和不同的需求，各大 IT 公司都在爭先恐后的提出各種各樣的方案和技術。

如何選擇合適的方案，主要可以從技術選題、穩定問題、高可用性、可擴展性、監控等方面入手。IBM Platform 致力于大數據的分析和部署的研究工作，從以上幾個方面來看，IBM Platform Converge 是較為出色的大數據集群部署解決方案。

36大數據(www.36dsj.com)成立于2013年5月，是中國訪問量***的大數據網站。36大數據(微信號:dashuju36)以獨立第三方的角度，為大數據產業生態圖譜上的需求商 、應用商、服務商、技術解決商等相關公司及從業人員提供全球資訊、商機、案例、技術教程、項目對接、創業投資及專訪報道等服務。