大數據生態圈與IBM Platform Symphony架構設計

作者：沈釗偉

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

分布式大數據框架的分類

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

圖1. 大數據行業相關的領域

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

圖2. 分布式大數據基礎架構關系圖

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

大數據案例舉例

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

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

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

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

圖3. 示例方案的架構圖

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

Platform Symphony簡介

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

圖4. Platform Symphony基礎模塊

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

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

圖5. Platform Symphony與大數據生態圈的關系

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

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

圖6. 示例案例架構圖(Platform Symphony)

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

Platform Symphony與Yarn的對比

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

圖7. Symphony中SOAM的架構設計

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

圖8是Yarn的架構設計：

圖8. Yarn的架構設計

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

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

結束語

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

作者：沈釗偉(shenzhaowei@foxmail.com)，2011年加入IBM CSTL(西安)至今，一直從事分布式計算以及大數據相關的研發工作。 責編：周建丁(zhoujd@csdn.net)

via:csdn

End.