基於Hadoop的大資料平臺實施——整體架構設計

大資料的熱度在持續的升溫，繼雲端計算之後大資料成為又一大眾所追捧的新星。我們暫不去討論大資料到底是否適用於您的公司或組織，至少在網際網路上已經被吹噓成無所不能的超級戰艦。好像一夜之間我們就從網際網路時代跳躍進了大資料時代！關於到底什麼是大資料，說真的，到目前為止就和雲端計算一樣，讓我總覺得像是在看電影《雲圖》——雲裡霧裡的感覺。或許那些正在向你推銷大資料產品的公司會對您描繪一幅烏托邦似的美麗畫面，但是您至少要保持清醒的頭腦，認真仔細的慎問一下自己，我們公司真的需要大資料嗎？

做為一家第三方支付公司，資料的確是公司最最重要的核心資產。由於公司成立不久，隨著業務的迅速發展，交易資料呈幾何級增加，隨之而來的是系統的不堪重負。業務部門、領導、甚至是集團老總整天嚷嚷的要報表、要分析、要提升競爭力。而研發部門能做的唯一事情就是執行一條一條複雜到自己都難以想象的SQL語句，緊接著系統開始罷工，記憶體溢位，當機........簡直就是噩夢。OMG！please release me！！！

其實資料部門的壓力可以說是常人難以想象的，為了把所有離散的資料彙總成有價值的報告，可能會需要幾個星期的時間或是更長。這顯然和業務部門要求的快速響應理念是格格不入的。俗話說，工欲善其事，必先利其器。我們也該鳥槍換炮了......。

網上有一大堆文章描述著大資料的種種好處，也有一大群人不厭其煩的說著自己對大資料的種種體驗，不過我想問一句，到底有多少人多少組織真的在做大資料？實際的效果又如何？真的給公司帶來價值了？是否可以將價值量化？關於這些問題，好像沒看到有多少評論會涉及，可能是大資料太新了（其實底層的概念並非新事物，老酒裝新瓶罷了），以至於人們還沉浸在各種美妙的YY中。

做為一名嚴謹的技術人員，在經過短暫盲目的崇拜之後，應該快速的進入落地應用的研究中，這也是踩著“雲彩”的架構師和騎著自行車的架構師的本質區別。說了一些牢騷話，當做發洩也好，博眼球也好，總之，我想表達的其實很簡單：不要被新事物所迷惑，也不要盲目的崇拜任何一樣新事物，更不要人云亦云，這是我們做研究的人絕對要不得。

說了很多也是時候進入正題了。公司高層決定，正式在集團範圍內實施大資料平臺（還特地邀請了一些社群的高手，很期待.......），做為第三方支付公司實施大資料平臺也無可厚非，因此也積極的參與到這個專案中來。正好之前關於OSGi的企業級框架的研究也告一段落，所以想利用CSDN這個平臺將這次大資料平臺實施過程記錄下來。我想一定能為其它有類似想法的個人或公司提供很好的參考資料！

第一記，大資料平臺的整體架構設計

1. 軟體架構設計

大資料平臺架構設計沿襲了分層設計的思想，將平臺所需提供的服務按照功能劃分成不同的模組層次，每一模組層次只與上層或下層的模組層次進行互動（通過層次邊界的介面），避免跨層的互動，這種設計的好處是：各功能模組的內部是高內聚的，而模組與模組之間是鬆耦合的。這種架構有利於實現平臺的高可靠性，高擴充套件性以及易維護性。比如，當我們需要擴容Hadoop叢集時，只需要在基礎設施層新增一臺新的Hadoop節點伺服器即可，而對其他模組層無需做任何的變動，且對使用者也是完全透明的。

整個大資料平臺按其職能劃分為五個模組層次，從下到上依次為：

執行環境層：

執行環境層為基礎設施層提供執行時環境，它由2部分構成，即作業系統和執行時環境。

(1)作業系統我們推薦安裝REHL5.0以上版本(64位)。此外為了提高磁碟的IO吞吐量，避免安裝RAID驅動，而是將分散式檔案系統的資料目錄分佈在不同的磁碟分割槽上，以此提高磁碟的IO效能。

(2)執行時環境的具體要求如下表：

名稱版本說明

JDK1.6或以上版本Hadoop需要Java執行時環境，必須安裝JDK。

gcc/g++3.x或以上版本當使用Hadoop Pipes執行MapReduce任務時，需要gcc編譯器，可選。

python2.x或以上版本當使用Hadoop Streaming執行MapReduce任務時，需要python執行時，可選。

基礎設施層：

基礎設施層由2部分組成：Zookeeper叢集和Hadoop叢集。它為基礎平臺層提供基礎設施服務，比如命名服務、分散式檔案系統、MapReduce等。

(1)ZooKeeper叢集用於命名對映，做為Hadoop叢集的命名伺服器，基礎平臺層的任務排程控制檯可以通過命名伺服器訪問Hadoop叢集中的NameNode，同時具備failover的功能。

(2)Hadoop叢集是大資料平臺的核心，是基礎平臺層的基礎設施。它提供了HDFS、MapReduce、JobTracker和TaskTracker等服務。目前我們採用雙主節點模式，以此避免Hadoop叢集的單點故障問題。

基礎平臺層：

基礎平臺層由3個部分組成：任務排程控制檯、HBase和Hive。它為使用者閘道器層提供基礎服務呼叫介面。

(1)任務排程控制檯是MapReduce任務的排程中心，分配各種任務執行的順序和優先順序。使用者通過排程控制檯提交作業任務，並通過使用者閘道器層的Hadoop客戶端返回其任務執行的結果。其具體執行步驟如下：

任務排程控制檯接收到使用者提交的作業後，匹配其排程演算法；

請求ZooKeeper返回可用的Hadoop叢集的JobTracker節點地址；

提交MapReduce作業任務；

輪詢作業任務是否完成；

如果作業完成傳送訊息並呼叫回撥函式；

繼續執行下一個作業任務。

作為一個完善的Hadoop叢集實現，任務排程控制檯儘量自己開發實現，這樣靈活性和控制力會更加的強。

(2)HBase是基於Hadoop的列資料庫，為使用者提供基於表的資料訪問服務。

(3)Hive是在Hadoop上的一個查詢服務，使用者通過使用者閘道器層的Hive客戶端提交類SQL的查詢請求，並通過客戶端的UI檢視返回的查詢結果，該介面可提供資料部門準即時的資料查詢統計服務。

使用者閘道器層：

使用者閘道器層用於為終端客戶提供個性化的呼叫介面以及使用者的身份認證，是使用者唯一可見的大資料平臺操作入口。終端使用者只有通過使用者閘道器層提供的介面才可以與大資料平臺進行互動。目前閘道器層提供了3個個性化呼叫介面：

(1)Hadoop客戶端是使用者提交MapReduce作業的入口，並可從其UI介面檢視返回的處理結果。

(2)Hive客戶端是使用者提交HQL查詢服務的入口，並可從其UI介面檢視查詢結果。

(3)Sqoop是關係型資料庫與HBase或Hive互動資料的介面。可以將關係型資料庫中的資料按照要求匯入到HBase或Hive中，以提供使用者可通過HQL進行查詢。同時HBase或Hive或HDFS也可以將資料導回到關係型資料庫中，以便其他的分析系統進行進一步的資料分析。

使用者閘道器層可以根據實際的需求無限的擴充套件，以滿足不同使用者的需求。

客戶應用層：

客戶應用層是各種不同的終端應用程式，可以包括：各種關係型資料庫，報表，交易行為分析，對賬單，清結算等。

目前我能想到的可以落地到大資料平臺的應用有：

1.行為分析：將交易資料從關係型資料庫匯入到Hadoop叢集中，然後根據資料探勘演算法編寫MapReduce作業任務並提交到JobTracker中進行分散式計算，然後將其計算結果放入Hive中。終端使用者通過Hive客戶端提交HQL查詢統計分析的結果。

2.對賬單：將交易資料從關係型資料庫匯入到Hadoop叢集，然後根據業務規則編寫MapReduce作業任務並提交到JobTracker中進行分散式計算，終端使用者通過Hadoop客戶端提取對賬單結果檔案(Hadoop本身也是一個分散式檔案系統，具備通常的檔案存取能力)。

3.清結算：將銀聯檔案匯入HDFS中，然後將之前從關係型資料庫中匯入的POSP交易資料進行MapReduce計算(即對賬操作)，然後將計算結果連線到另外一個MapReduce作業中進行費率及分潤的計算(即結算操作)，最後將計算結果導回到關係型資料庫中由使用者觸發商戶劃款(即劃款操作)。

部署架構設計

關鍵點說明：

1.目前整個Hadoop叢集均放置在銀聯機房中。

2.Hadoop叢集中有2個Master節點和5個Slave節點，2個Master節點互為備份通過ZooKeeper可實現failover功能。每個Master節點共享所有的Slave節點，保證分散式檔案系統的備份存在於所有的DataNode節點之中。Hadoop叢集中的所有主機必須使用同一網段並放置在同一機架上，以此保證叢集的IO效能。

3.ZooKeeper叢集至少配置2臺主機，以避免命名服務的單節點故障。通過ZooKeeper我們可以不再需要F5做負載均衡，直接由任務排程控制檯通過ZK實現Hadoop名稱節點的負載均衡訪問。

4.所有伺服器之間必須配置為無金鑰SSH訪問。

5.外部或內部使用者均需要通過閘道器才能訪問Hadoop叢集，閘道器在經過一些身份認證之後才能提供服務，以此保證Hadoop叢集的訪問安全。

長按識別關注我們，每天都有精彩內容分享哦！~