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

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

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

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

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

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

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

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

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

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

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

Platform Symphony簡介

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

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

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

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

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

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

Platform Symphony與Yarn的對比

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

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

下圖是Yarn的架構設計：

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

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

結束語

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