大數據的熱度在持續的升溫，繼雲計算以後大數據成爲又一大衆所追捧的新星。咱們暫不去討論大數據究竟是否適用於您的公司或組織，至少在互聯網上已經被吹噓成無所不能的超級戰艦。好像一晚上之間咱們就從互聯網時代跳躍進了大數據時代!關於到底什麼是大數據，說真的，到目前爲止就和雲計算同樣，讓我總以爲像是在看電影《雲圖》——雲裏霧裏的感受。或許那些正在向你推銷大數據產品的公司會對您描繪一幅烏托邦似的美麗畫面，可是您至少要保持清醒的頭腦，認真仔細的慎問一下本身，咱們公司真的須要大數據嗎?html
作爲一家第三方支付公司，數據的確是公司最最重要的核心資產。因爲公司成立不久，隨着業務的迅速發展，交易數據呈幾何級增長，隨之而來的是系統的不堪重負。業務部門、領導、甚至是集團老總成天嚷嚷的要報表、要分析、要提高競爭力。而研發部門能作的惟一事情就是執行一條一條複雜到本身都不可思議的SQL語句，緊接着系統開始罷工，內存溢出，宕機........簡直就是噩夢。OMG!please release me!!!python
其實數據部門的壓力能夠說是常人不可思議的，爲了把全部離散的數據彙總成有價值的報告，可能會須要幾個星期的時間或是更長。這顯然和業務部門要求的快速響應理念是格格不入的。俗話說，工欲善其事，必先利其器。咱們也該鳥槍換炮了......。算法
網上有一大堆文章描述着大數據的種種好處，也有一大羣人不厭其煩的說着本身對大數據的種種體驗，不過我想問一句，到底有多少人多少組織真的在作大數據?實際的效果又如何?真的給公司帶來價值了?是否能夠將價值量化?關於這些問題，好像沒看到有多少評論會涉及，多是大數據太新了(其實底層的概念並不是新事物，老酒裝新瓶罷了)，以致於人們還沉浸在各類美妙的YY中。數據庫
作爲一名嚴謹的技術人員，在通過短暫盲目的崇拜以後，應該快速的進入落地應用的研究中，這也是踩着「雲彩」的架構師和騎着自行車的架構師的本質區別。說了一些牢騷話，當作發泄也好，博眼球也好，總之，我想表達的其實很簡單：不要被新事物所迷惑，也不要盲目的崇拜任何同樣新事物，更不要人云亦云，這是咱們作研究的人絕對要不得。編程
說了不少也是時候進入正題了。公司高層決定，正式在集團範圍內實施大數據平臺(還特意邀請了一些社區的高手，很期待.......)，作爲第三方支付公司實施大數據平臺也無可厚非，所以也積極的參與到這個項目中來。正好以前關於OSGi的企業級框架的研究也告一段落，
因此想利用CSDN這個平臺將此次大數據平臺實施過程記錄下來。我想必定能爲其它有相似想法的我的或公司提供很好的參考資料!須要大數據的能夠加我扣扣羣大數據零基礎到項目實戰，專一大數據分析方法,大數據編程，大數據倉庫，大數據案例，人工智能,數據挖掘都是純乾貨分享，進羣獲取永久免費權限410391744安全
第一記，大數據平臺的總體架構設計服務器
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集羣的訪問安全。
你們喜歡多多關注，會不按期分享乾貨。