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

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

在詳細(xì)介紹Platform Symphony與大數(shù)據(jù)生態(tài)圈的關(guān)系之前，讓我們先了解一下整個大數(shù)據(jù)生態(tài)圈的組成。我個人的理解是，目前這個行業(yè)可以簡單的分為三大層次：分別是數(shù)據(jù)源、數(shù)據(jù)處理以及數(shù)據(jù)分析。數(shù)據(jù)分析是直接將大數(shù)據(jù)轉(zhuǎn)換為商業(yè)價值的領(lǐng)域，在數(shù)據(jù)分析的領(lǐng)域會提出各種業(yè)務(wù)需求;數(shù)據(jù)處理領(lǐng)域則是負(fù)責(zé)實現(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也屬于這個部分。 綜上所述，如果宏觀的抽象出整個大數(shù)據(jù)生態(tài)涉及的相關(guān)領(lǐng)域，大致如圖所示：

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

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

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

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

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

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

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

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

Platform Symphony簡介

簡單來說，Platform Symphony是一個提供數(shù)據(jù)分發(fā)、任務(wù)調(diào)度以及資源管理的企業(yè)級分布式計算框架，并且支持異構(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實現(xiàn)Client和Service程序。Symphony涉及的基礎(chǔ)模塊如圖4。

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

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

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

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

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

Platform Symphony與Yarn的對比

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

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

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

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

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

結(jié)束語

開源技術(shù)的發(fā)展確實降低了大數(shù)據(jù)計算的門檻，因而很多企業(yè)也開始了各自的大數(shù)據(jù)之路。不過一個符合企業(yè)特定使用的分布式框架往往需要經(jīng)歷數(shù)年甚至十年的進(jìn)化，才會趨于穩(wěn)定和成熟。所以并不是每個企業(yè)都適合直接去使用開源的產(chǎn)品，往往更多的是使用某些公司包裝過的開源產(chǎn)品，從而減少維護(hù)和開發(fā)的成本。對于IBM Platform Symphony來說，它是一個經(jīng)歷十年以上磨練的分布式計算產(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)用運行在Symphony上。