隨著開源社區(qū)不斷的壯大，很多以前鮮為人知的技術(shù)慢慢地走進(jìn)了大眾IT人員的視野。對(duì)一個(gè)數(shù)據(jù)中心而言，最火的兩個(gè)技術(shù)領(lǐng)域便是云計(jì)算與大數(shù)據(jù)。其中每個(gè)領(lǐng)域都有一些代表的項(xiàng)目，如云計(jì)算領(lǐng)域的OpenStack、CloudStack等，那么大數(shù)據(jù)領(lǐng)域又有哪些知名的項(xiàng)目呢?當(dāng)面對(duì)這樣的問題時(shí)，很多人可能會(huì)快速地回答：Hadoop、Hive、Hbase以及后來的Yarn(Hadoop二代)、Mesos、Spark、Storm、Flink等。這些答案無疑都是正確的，然而對(duì)于整個(gè)大數(shù)據(jù)生態(tài)圈而言，會(huì)有很多不同的場景需要不同的框架和平臺(tái)應(yīng)用去處理，例如流計(jì)算任務(wù)、批處理任務(wù)或者存儲(chǔ)的構(gòu)建、數(shù)據(jù)的導(dǎo)入等等。我們可以看到一些企業(yè)已經(jīng)開始將一部分業(yè)務(wù)或者數(shù)據(jù)遷移到大數(shù)據(jù)的平臺(tái)，尤其是一些大型的互聯(lián)網(wǎng)企業(yè)。那么，一個(gè)企業(yè)該如何選擇一個(gè)適合的平臺(tái)甚至一個(gè)框架?這個(gè)問題不太容易回答。本文致力于介紹整個(gè)大數(shù)據(jù)的生態(tài)圈以及IBM Platform Symphony產(chǎn)品，希望讀者能從中得到這個(gè)問題的線索或答案。

分布式大數(shù)據(jù)框架的分類

在詳細(xì)介紹Platform Symphony與大數(shù)據(jù)生態(tài)圈的關(guān)系之前，讓我們先了解一下整個(gè)大數(shù)據(jù)生態(tài)圈的組成。我個(gè)人的理解是，目前這個(gè)行業(yè)可以簡單的分為三大層次：分別是數(shù)據(jù)源、數(shù)據(jù)處理以及數(shù)據(jù)分析。數(shù)據(jù)分析是直接將大數(shù)據(jù)轉(zhuǎn)換為商業(yè)價(jià)值的領(lǐng)域，在數(shù)據(jù)分析的領(lǐng)域會(huì)提出各種業(yè)務(wù)需求;數(shù)據(jù)處理領(lǐng)域則是負(fù)責(zé)實(shí)現(xiàn)數(shù)據(jù)分析提出的需求，這一領(lǐng)域也就是我們經(jīng)常說的基礎(chǔ)設(shè)施架構(gòu)層(Infrastructure);數(shù)據(jù)源指的就是數(shù)據(jù)產(chǎn)生的地方。在這三塊之間也有一些銜接的軟件領(lǐng)域，不過往往也都?xì)w在了數(shù)據(jù)處理領(lǐng)域(基礎(chǔ)架構(gòu)層)，例如銜接數(shù)據(jù)源與數(shù)據(jù)處理層的數(shù)據(jù)導(dǎo)入工具(如Sqoop等)，以及銜接數(shù)據(jù)分析和數(shù)據(jù)處理的應(yīng)用接口(如：SQL接口的Hive，以及流接口的Spark Streaming、Storm等)。在大數(shù)據(jù)的這三大領(lǐng)域中有很多開源以及非開源的產(chǎn)品，熟知的開源的Hadoop、Spark、Mesos等，都屬于數(shù)據(jù)處理領(lǐng)域，也就是基礎(chǔ)架構(gòu)這一層次。IBM Platform Symphony也屬于這個(gè)部分。 綜上所述，如果宏觀的抽象出整個(gè)大數(shù)據(jù)生態(tài)涉及的相關(guān)領(lǐng)域，大致如圖所示：

基于對(duì)大數(shù)據(jù)相關(guān)領(lǐng)域的宏觀描述，下來我們就再談下基礎(chǔ)架構(gòu)這一塊。目前大多開源相關(guān)的大數(shù)據(jù)框架基本都可以歸屬到基礎(chǔ)設(shè)施架構(gòu)這個(gè)層次。為了更好的理解各個(gè)框架之間的關(guān)系，我們又將基礎(chǔ)設(shè)施架構(gòu)這塊分為四層，分別是數(shù)據(jù)存儲(chǔ)層、集群資源管理層、計(jì)算引擎層、以及應(yīng)用接口層。除了一些提供易用性、可維護(hù)性以及健壯性的框架之外(一般也可以統(tǒng)稱為管理類)，其他大部分都可以歸在這四類。例如HDFS屬于數(shù)據(jù)存儲(chǔ)層，Mesos和Yarn則屬于集群資源管理層，Hadoop MapReduce、Storm、Spark等則歸屬于計(jì)算引擎層，Hive、Pig則為數(shù)據(jù)查詢提供接口。Ambari則是一個(gè)提升易用性和可維護(hù)性的工具，Zookeeper提供了健壯性(HA)。這些系統(tǒng)之間具體的關(guān)系，可以參見下面的簡圖：

目前開源的大數(shù)據(jù)框架所支持的操作系統(tǒng)大多數(shù)都只支持了Linux，不過這一問題相信未來會(huì)有所解決，畢竟大多大數(shù)據(jù)框架的實(shí)現(xiàn)語言都是與操作系統(tǒng)無關(guān)的Java(Scala)。

大數(shù)據(jù)案例舉例

通過以上的介紹，我們了解了其中一部分大數(shù)據(jù)相關(guān)的開源架構(gòu)，但可能沒法短期內(nèi)將其對(duì)應(yīng)到實(shí)際的案例中。因此，這里用一個(gè)很簡單的查詢業(yè)務(wù)架構(gòu)作為例子，來說明這些框架之間的具體關(guān)系。由于傳統(tǒng)的業(yè)務(wù)架構(gòu)會(huì)將大部分?jǐn)?shù)據(jù)保存在數(shù)據(jù)庫中，所以這里假設(shè)有一個(gè)MySQL數(shù)據(jù)庫保存了海量的客戶終端信息(例如電話號(hào)碼、話單以及動(dòng)態(tài)GPS紀(jì)錄)，如果要將查詢業(yè)務(wù)遷移到大數(shù)據(jù)平臺(tái)，首先要做的便是數(shù)據(jù)遷移(Data Movement)。

對(duì)于數(shù)據(jù)遷移的場景我們可以使用Sqoop工具進(jìn)行數(shù)據(jù)導(dǎo)入。簡單來說，Sqoop是一個(gè)用MapReduce框架實(shí)現(xiàn)的應(yīng)用，并且Sqoop只有Map的實(shí)現(xiàn)。Sqoop的Map任務(wù)會(huì)并行的從數(shù)據(jù)庫中讀取表的信息，并保存到Hadoop的HDFS中。Sqoop本身也可以實(shí)現(xiàn)反向的導(dǎo)入，也就是從HDFS到數(shù)據(jù)庫，不過這里我們用不到。了解了Sqoop的大致實(shí)現(xiàn)，我們可以知道Sqoop的運(yùn)行離不開Hadoop的支持。另外需要注意的是，在這個(gè)例子中的數(shù)據(jù)是結(jié)構(gòu)化的DB數(shù)據(jù)。如果是非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)，Sqoop可能就無能為力了。對(duì)于非結(jié)構(gòu)化的數(shù)據(jù)，有興趣的讀者可以研究下Flume等的使用。

當(dāng)數(shù)據(jù)遷移完成之后，我們可以通過Hive提供SQL的支持。上層應(yīng)用便可以方便的通過SQL語句查詢HDFS中的用戶信息。從這里我們也要了解到Hive本身并不是數(shù)據(jù)庫，它只是提供SQL支持的一種接口實(shí)現(xiàn)。Hive會(huì)將查詢語句轉(zhuǎn)換為MapReduce任務(wù)來執(zhí)行。對(duì)于響應(yīng)時(shí)間要求高的客戶，可能Hive并不能滿足需求。有興趣的讀者也可以在類似的案例中使用Hbase。Hbase是一個(gè)分布式的列式數(shù)據(jù)庫，其底層存儲(chǔ)也是使用HDFS。不過與Hive不同，其是一款真正的數(shù)據(jù)庫。在大多的場景中，Hbase的響應(yīng)延遲會(huì)比Hive小很多。篇幅有限，這里就不過多介紹Hbase。

到這里我們知道整個(gè)方案至少需要有Sqoop、Hive、HDFS以及MapReduce的實(shí)現(xiàn)框架。那么Hadoop Yarn除了支持MapReduce的Workload之外，還有什么作用?為了回答這個(gè)問題，我們需要引入另一個(gè)重要的概念“多租戶”。在Hadoop一代中只有對(duì)MapReduce任務(wù)的支持，而今隨著數(shù)據(jù)中心的發(fā)展，往往是多種計(jì)算框架并存的。在我們這個(gè)例子中，數(shù)據(jù)遷移一旦完成，批處理的查詢?nèi)蝿?wù)又不是很頻繁的話，就會(huì)造成集群資源的浪費(fèi)。那么為了最大化的提高集群資源利用率，就必須允許多種計(jì)算框架之間的資源共享。而Yarn作為一個(gè)集群資源的管理者，就可以很好協(xié)調(diào)多種計(jì)算框架之間的資源分配和管理。當(dāng)然，這也需要計(jì)算框架本身的支持。MapReduce是Yarn內(nèi)置的一種計(jì)算框架，已經(jīng)由Hadoop社區(qū)實(shí)現(xiàn)。但對(duì)于其他的計(jì)算框架，則需要其他社區(qū)根據(jù)Yarn的API來實(shí)現(xiàn)對(duì)應(yīng)的App Master。為了方便用戶部署和管理集群，我們可以使用Ambari。該案例的整體架構(gòu)圖如圖。

如果引申該案例的話，我們可以在上圖的其他Framework中應(yīng)用更多的計(jì)算框架。例如當(dāng)該案例的集群又需要處理流數(shù)據(jù)的話，那么我們可以在Other中使用Spark以及Storm等。目前Yarn已經(jīng)支持在其上運(yùn)行Spark和Storm等計(jì)算框架。對(duì)于部分應(yīng)用也可以使用Apache Slider來部署到Y(jié)arn之上。篇幅有限，這里就不過多的介紹這些框架了。

Platform Symphony簡介

簡單來說，Platform Symphony是一個(gè)提供數(shù)據(jù)分發(fā)、任務(wù)調(diào)度以及資源管理的企業(yè)級(jí)分布式計(jì)算框架，并且支持異構(gòu)化的IT環(huán)境。Platform Symphony由兩層架構(gòu)組成，一層是負(fù)責(zé)資源管理的EGO(全稱Enterprise Grid Orchestrator)，另一層是任務(wù)管理的SOAM(全稱Service-Oriented Architecture Management)。在Symphony的集群中，用戶需要根據(jù)Symphony提供的API實(shí)現(xiàn)Client和Service程序。Symphony涉及的基礎(chǔ)模塊如圖4。

如圖4所示，Client程序用于提交任務(wù)到Symphony集群，Symphony會(huì)在EGO層為該類應(yīng)用申請計(jì)算資源，接著在對(duì)應(yīng)的機(jī)器上啟動(dòng)用戶的Service。Service接收任務(wù)數(shù)據(jù)并進(jìn)行計(jì)算，最終會(huì)通過Symphony將任務(wù)結(jié)果返回Client程序。PMC是Symphony提供的一個(gè)專業(yè)WEB操作界面，其可以定制Symphony集群的配置，以及管理任務(wù)等。CLI是Symphony提供的命令行工具的集合，對(duì)于習(xí)慣使用命令操作的用戶來說，更加方便和高效。Knowledge Center是Symphony產(chǎn)品文檔的WEB接口，用戶可以在其中找到Symphony各個(gè)功能的介紹和使用方法。

那么Platform Symphony在大數(shù)據(jù)中的基礎(chǔ)架構(gòu)層扮演怎樣的角色，又可以替代哪些開源的框架呢?帶著問題，我們來理解下圖。

從圖5中我們可以看出，在大數(shù)據(jù)應(yīng)用場景中，Platform Symphony既處在資源管理層，也涵蓋了計(jì)算引擎層。因此很多原有的大數(shù)據(jù)應(yīng)用，都可以很平滑的遷移到Symphony的集群中運(yùn)行，例如Hive、Pig等。并且用戶以前在Hadoop MapReduce上開發(fā)的應(yīng)用也可以很平滑的運(yùn)行在Symphony之上。

對(duì)比開源的框架，Platform Symphony中的EGO相似與Yarn和Mesos，都處于集群的資源管理層。SOAM則處于計(jì)算引擎層，也就是計(jì)算框架，負(fù)責(zé)任務(wù)管理和調(diào)度。Symphony MapReduce是Symphony內(nèi)置的一種應(yīng)用(Hadoop MapReduce也是內(nèi)置于Yarn的一種應(yīng)用)。用戶其實(shí)可以根據(jù)Symphony的API實(shí)現(xiàn)各種不同的Symphony應(yīng)用。目前Symphony已經(jīng)與開源Yarn、Spark、Docker集成，也就是說用戶之前在Yarn和Spark上面的應(yīng)用，都可以直接通過Symphony管理和調(diào)度集群資源。另外，也可以將Symphony的用戶實(shí)例運(yùn)行在Docker容器中。同時(shí)Symphony也支持了通過Ambari部署和管理集群，從而方便用戶使用Platform Symphony替代部分開源框架。如果將Symphony應(yīng)用到之前我們給的示例方案中，大致架構(gòu)如下圖。

與開源框架不同，Symphony最終是通過其中的EGO模塊實(shí)現(xiàn)應(yīng)用之間的資源管理和共享。值得一提的是，Symphony的實(shí)現(xiàn)語言是以C和C++為主，其支持的平臺(tái)也涵蓋了市面上大多的操作系統(tǒng)，例如Windows、Linux、Solaris以及AIX等。篇幅有限，這里沒有過多的闡述Symphony的內(nèi)部架構(gòu)，后續(xù)文章中，我們再來探討Symphony的詳細(xì)功能和設(shè)計(jì)。

Platform Symphony與Yarn的對(duì)比

很多人提到大數(shù)據(jù)，可能只意識(shí)到了之前我們提到的開源框架，其實(shí)是先入為主了。Hadoop MapReduce和Spark之類，這些都只是不同的計(jì)算框架而已。Symphony的用戶完全可以根據(jù)自己的業(yè)務(wù)計(jì)算邏輯，實(shí)現(xiàn)自己的Symphony應(yīng)用。拿MapReduce而言，它也只是Symphony的一個(gè)應(yīng)用。這也間接說明了Symphony的另一個(gè)優(yōu)勢，多租戶的概念。也就是說，Symphony中可以同時(shí)運(yùn)行多種類型的應(yīng)用。用過Yarn的讀者，可能覺得Symphony有些類似于Yarn。這里就將Symphony的各個(gè)模塊與YARN做個(gè)簡單的對(duì)比。在對(duì)比之前，我們需要先介紹一些Symphony的概念，如下圖。

Symphony中的SOAM是一個(gè)面向服務(wù)的中間件，其由Session Director(SD)、Session Manager(SSM)、Service Instance Manager (SIM)和Service Instance(SI)組成。Client就是用戶根據(jù)Symphony SDK開發(fā)的客戶端程序，用戶從Client提交計(jì)算任務(wù)。Client會(huì)先和SD建立連接，SD會(huì)找到該類型應(yīng)用的SSM。SSM用于管理一類應(yīng)用的任務(wù)。如果該類型SSM不存在，SD會(huì)向EGO層申請管理節(jié)點(diǎn)的資源，并啟動(dòng)SSM。SSM會(huì)根據(jù)用戶提交的任務(wù)向EGO層申請一定的計(jì)算資源。拿到計(jì)算資源后SOAM層會(huì)在計(jì)算節(jié)點(diǎn)啟動(dòng)SIM和SI(一般一個(gè)Slot啟動(dòng)一個(gè)SI實(shí)例)。然后SSM會(huì)發(fā)送任務(wù)和數(shù)據(jù)到SIM，進(jìn)而到SI完成計(jì)算。SIM會(huì)管理用戶的Service進(jìn)程，如果用戶的Service遇到一些錯(cuò)誤，SIM會(huì)根據(jù)用戶配置做出對(duì)應(yīng)的行為，我們稱之為Error Handing。

下圖是Yarn的架構(gòu)設(shè)計(jì)：

同樣Yarn的Client也是用來提交任務(wù)的，在Yarn中RM會(huì)申請資源啟動(dòng)App Master。這一步類似于SOAM中SD申請資源啟動(dòng)(或找到)SSM。Yarn中App Master會(huì)向RM申請資源啟動(dòng)container運(yùn)行MR任務(wù)，并收集任務(wù)狀態(tài)。這里類似于SSM向EGO申請資源啟動(dòng)SIM和SI，并發(fā)送任務(wù)和收集任務(wù)結(jié)果的過程。SSM和App Master一樣，是管理和調(diào)度任務(wù)的模塊，在一個(gè)集群中可以存在多個(gè)(多種不同類型的應(yīng)用)。很多人都很贊嘆Yarn架構(gòu)的前沿性，尤其與Hadoop一代比較，Yarn將資源管理層單獨(dú)抽象出來，這樣使得Hadoop的架構(gòu)更加清晰。而Symphony十幾年前就已經(jīng)這樣設(shè)計(jì)了，可見Symphony設(shè)計(jì)的前瞻性。

當(dāng)然Symphony與Yarn也有一些差異，例如默認(rèn)情況下(Yarn可以配置)，Yarn的App Master是啟動(dòng)在Yarn的Container中，與真正的計(jì)算實(shí)例的Container并無特殊對(duì)待。也就是說啟動(dòng)App Master的機(jī)器，有隨機(jī)性。而Symphony一般只能啟動(dòng)SSM在Symphony的管理節(jié)點(diǎn)。一般情況下，管理節(jié)點(diǎn)的硬件性能要求會(huì)高于計(jì)算節(jié)點(diǎn)，而SSM等管理進(jìn)程對(duì)內(nèi)存以及CPU計(jì)算能力的消耗一般也會(huì)比較大，所以在管理節(jié)點(diǎn)啟動(dòng)SSM這樣的重量級(jí)進(jìn)程是有技術(shù)背景的。再例如Yarn沒有Resource Group的概念，如果需要將某些特殊的任務(wù)調(diào)度到某一群特定機(jī)器時(shí)，Yarn顯得有些笨重，因?yàn)閅arn目前只能通過標(biāo)簽調(diào)度(Tag Policy)去做。Symphony可能只需要設(shè)定幾個(gè)Resource Group，并設(shè)計(jì)不同優(yōu)先級(jí)即可(Symphony很早前也支持了Tag的調(diào)度策略)。與所有的開源框架相比，Symphony支持更多的OS平臺(tái)以及硬件平臺(tái)。例如Hadoop目前還沒支持Windows，而Symphony很早就支持了。更多的差異化，可以在IBM的Knowledge Center找到。

結(jié)束語

開源技術(shù)的發(fā)展確實(shí)降低了大數(shù)據(jù)計(jì)算的門檻，因而很多企業(yè)也開始了各自的大數(shù)據(jù)之路。不過一個(gè)符合企業(yè)特定使用的分布式框架往往需要經(jīng)歷數(shù)年甚至十年的進(jìn)化，才會(huì)趨于穩(wěn)定和成熟。所以并不是每個(gè)企業(yè)都適合直接去使用開源的產(chǎn)品，往往更多的是使用某些公司包裝過的開源產(chǎn)品，從而減少維護(hù)和開發(fā)的成本。對(duì)于IBM Platform Symphony來說，它是一個(gè)經(jīng)歷十年以上磨練的分布式計(jì)算產(chǎn)品，憑借其技術(shù)沉淀，已經(jīng)在國外銀行業(yè)應(yīng)用了很多年，歷史遠(yuǎn)遠(yuǎn)早于Hadoop。隨著大數(shù)據(jù)在國內(nèi)的興起，Symphony也一直致力于解決國內(nèi)大數(shù)據(jù)場景的問題和瓶頸，發(fā)揮其優(yōu)勢。目前Platform Symphony已經(jīng)支持了多維度資源調(diào)度，并且支持通過Ambari安裝部署Symphony集群。最新的發(fā)行版中也支持了Spark、Yarn和Docker。用戶可以很平滑將開源框架中的應(yīng)用運(yùn)行在Symphony上。