一、大數(shù)據(jù)集群技術(shù)的概述

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

[[181333]]

原來，美國的婦女通常在家照顧孩子，所以她們經(jīng)常會囑咐丈夫在下班回家的路上為孩子買尿布，而丈夫在買尿布的同時又會順手購買自己愛喝的啤酒。這個發(fā)現(xiàn)為商家?guī)砹舜罅康睦麧?，但是如何從浩如煙海卻又雜亂無章的數(shù)據(jù)中，發(fā)現(xiàn)啤酒和尿布這個看似不相干的物品銷售之間的聯(lián)系呢?這就是大數(shù)據(jù)的威力。

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

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

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

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

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

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

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

二、大數(shù)據(jù)集群技術(shù)的架構(gòu)與分析

一般來說，大數(shù)據(jù)集群的構(gòu)架，主要分為幾層：硬件層、OS 層、基礎(chǔ)設(shè)施管理層、文件系統(tǒng)層、大數(shù)據(jù)集群技術(shù)層以及上層應用，如下圖 1 所示。

圖 1 大數(shù)據(jù)集群的架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

最上層為應用和業(yè)務，客戶只需要提交 Spark Application 即可，集群負責統(tǒng)一的管理和調(diào)度，并返回執(zhí)行結(jié)果。

三、大數(shù)據(jù)集群的部署

3.1 硬件的部署

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

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

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

3.2 軟件的部署

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

3.3 高可用性(HA)部署

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

四、大數(shù)據(jù)集群的管理與監(jiān)控

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

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

4.1 CPU 的監(jiān)控

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

4.2 內(nèi)存的監(jiān)控

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

圖 6 內(nèi)存監(jiān)控

4.3 磁盤和文件系統(tǒng)的監(jiān)控

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

五、結(jié)束語

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

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

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