分佈式大數據做業系列之總述

分佈式數據做業系列之

總述

（ChongQing  ,  Dss Team  ,  rlma  ,  2014/04/26）

隨着信息技術發展，雲計算、大數據已成爲當代IT的熱門話題，海量信息的搜索和深度數據的挖掘更是煊赫一時。民航業快速擴大，各類民航信息數據迅猛增加，這對於中國航信來講既是機遇又是挑戰，利用這些豐富的民航數據資源，咱們能夠深度分析航班經營狀況及盈利模式，能夠挖掘民航業中的潛在價值，更能夠分析旅客行爲習慣，不光爲航空公司提供決策支持，更爲社會市場經營與商業規劃提供可靠的數據參考和分析。

而後，民航數據的大量性和快速增加性又給咱們帶來了巨大的挑戰，如何實現數據的快速導入，如何實現數據的優質存儲，若是實現信息的準確分析，這些問題都是咱們在這個過程當中必然要解決的。

今年初，新一代產品線成立了DSS（決策分析）子項目，在這裏咱們面對全民航全部的航班和銷售數據，面對每小時過億的數據存儲，面對大量數據的快速分析。通過一段時間的技術試驗和數據分析，傳統的數據存儲模式已經不能知足咱們在數據快速導入及分析上的需求，爲了更好的完成目標，項目組積極研發探索，結合當代雲計算與大數據思想，實現了一套本身的分佈式數據做業框架，使得集羣計算利用率獲得較大提高，系統TPS較傳統模式也有了巨大改進。就此項技術而言，雖不能同HADOOP一類的優秀框架媲美，但在過程當中咱們用本身的技術和方式去改進實現，這一路的探索和實踐，僅此想和你們作一些交流和分享。

1、背景及目標

DSS目前主要實現航信DIP指令數據數據快速導入存儲，並就數據實現實時、快速的分析。

DIP數據是航信指令數據，分爲FDL、FLP、FLR、RO四類指令數據，各種數據已壓縮文件形式存放於數據服務FTP文件系統中，每小時都會更新一次（以RO爲例，一天將產生18個數據壓縮文件），系統要將每小時產生更新的數據文件下載、解壓、解析並存儲。

4類指令數據將解析成BFG、BLG、BSG、BLC、BSB等粒度的數據信息，下圖爲一個小時產生的數據信息統計。

從統計來看，系統將實現一小時1700萬條數據存儲，數據庫數據大小1.2G，一天下來數據記錄數約1.7億，數據庫空間消耗12G。

就目前數據存儲而言，規定採用的是EDB關係數據庫，如此一來，不管是在存儲和分析上都面臨很大的壓力。也許有人會說，對於如此大的數據還使用關係數據庫來存儲，整個存儲和分析的成本和開銷相對NOSQL模式都大不少，爲何還要繼續折騰。我想告訴你們的是，在咱們產品研發過程當中，不少時候不是咱們的要求決定環境，而是咱們怎麼去適應環境，在現有環境下去優化和提高。

2、傳統實踐

傳統模式下，對於數據導入咱們採用一些數據訪問框架技術實現數據插入，如SpringTemplate等實現數據Insert。結合多線程，採用定時器在每一個數據採集時間點啓動多線程實現數據下載、解壓、解析和存儲。爲每一個數據文件啓動多線程執行做業，想經過併發來提升數據操做的吞吐量和性能。

但屢次測試和實踐結果顯示，儘管系統的線程數擴大到1000個，數據的吞吐量仍然上不去，系統CPU利用率仍然保持在20%左右。對問題進行分析得出結論：

（1）多線程並不意味着高併發

多線程你們都知道是程序異步處理的一種實現，經過多線程可實現多個任務同時做業來提升效率。但從計算機原理來講，任何計算機執行單元都將被編譯爲多個指令集，CPU以輪詢的方式對各個指令進行處理，好比對於單CPU的計算機來講，每一個單位時間內被處理的指令只有一個，只是這個時間很是短暫，以致於咱們感受不到這個間隔，認爲不線程就是被同時處理的。因此，線程數的設計和CPU的核數及其處理能力密切相關，更多的去發起線程只會加劇系統資源及CPU時間片的搶佔，不管是從內存仍是CPU上的消耗都很大。

（2）數據庫瓶頸

數據庫瓶頸表如今數據插入時消耗時間較長，運行時間越久插入越慢。緣由在於數據插入時須要維護對應的數據索引，數據越大維護的成本就越高，同時，多線程對一個表操做時，寫數據塊過程就會形成排隊，一方面下降了數據庫吞吐，另外一方面讓其餘線程處於等待狀態，數據吞吐量較低，且長時間的idle使得CPU利用率也上不去。針對這個數據庫優化咱們會在之後和你們分享。

3、分佈式數據做業

通過傳統方式實踐得知，多線程並不能真正意義上提升整個系統的吞吐和資源利用率，採用分佈式數據做業的模式就由然而生了。

和雲計算的思想一致，分佈式數據做業的目的是經過使用更多的PC集羣來提升總體的計算能力，實現負責均衡，提高集羣內各個PC的利用率。

分佈式數據做業採用主從集羣部署，就目前的環境而言，咱們採用1主2從的形式做業。基於這樣一個分佈式集羣環境，主要實現分佈式數據導入和分佈式數據查詢兩大功能部件，分別完成數據存儲和數據分析任務。

（一）集羣通訊

在分佈式集羣環境中，各個節點間會經過內部的消息協議實現通訊，完成信息交互及可靠傳輸。

對於分佈式集羣通訊，技術上大體分爲兩類：

一類是基於調用的通訊，經過遠程方法調用，實如今分佈式節點上執行目標方法後得到返回，以此完成各個節點間交互。該類技術比較流行的包括RPC、RMI等方式。RPC是C語言實現的遠程方法調用，其具備跨平臺性，但其不支持基於對象的傳輸。RMI爲JAVA語言實現的遠程方法訪問，其經過序列化對象傳輸技術實現遠程對象傳輸，但其僅限於JAVA調用。

另外一類是基於消息的通訊，經過在網絡間規定協議消息的傳輸來實現交互，相似網絡協議同樣，經過消息的解析來獲取各個節點信息，從而執行相應的響應操做。相對於基於調用的方式，消息通訊節約了通訊中網絡的開銷，相對遠程調用而言帶寬使用較少（有相關實驗分析，可查詢）。但這種方式在易用性上不如遠程調用，開發者須要針對各種消息進行處理。表明技術如Socket技術和JMS消息中間件。

在咱們的分佈式集羣中，咱們選擇結合兩種模式的優勢來實現，採用Socket技術實現消息傳輸，再基於消息使用JAVA動態代理和反射調用來實現了RPC過程調用，讓其成爲咱們分佈式系統環境中集羣通訊的基礎。

（二）分佈式數據導入

分佈式數據導入利用集羣各個節點協同做業完成數據信息的下載、解析、解壓和存儲。主服務器負責數據做業的分配及跟蹤，從服務器執行各個數據任務的解析存儲，整個結構體系以下：

集羣做業過程包括如下環節：

v 任務分配

主服務器加載完各個數據信息後拆分紅多個數據執行單元，將各個執行單元分配至集羣中多個基點執行。

v 任務跟蹤彙報

從服務器在收到任務分配、完成任務、執行失敗等狀況發生時會給主服務器發送相應的消息信息，主服務器根據消息實現各個任務執行單元的監控，統一協調。

v 心跳與負載均衡

心跳機制爲主服務器按期向從服務器發送心跳消息，根據消息恢復判斷各個從服務器是否正常、從服務器性能狀況、任務執行狀況等信息，主服務器根據預設的策略動態調整和優化任務分配及消息滑動窗口，實現各個服務器負載均衡。

v 災難恢復

災難恢復爲系統故障時集羣採用的處理策略，分爲主服務器故障轉移和從服務器故障恢復，重點保證故障災難發生時集羣的可用性。

（三）分佈式數據查詢

分佈式數據查詢主要針對複雜的SQL查詢進行拆分計算，參考MapReduce的計算思想，將複雜SQL查詢split成多個查詢單元，在reduce中實現結果合併，經過合理的設計拆分來下降數據庫查詢壓力，同時充分利用內存計算的快速性。

v SplitReduce

用戶經過在Split和Reduce中定義各自查詢的業務部分，任務啓動後，主服務器將生成多個Split任務實例，分配到各個從服務節點上執行，執行完成後將輸出結果返回，主服務器根據Reduce業務完成數據的合併，最終完成整個計算。

v 分佈式緩存

分佈式緩存主要緩存split及Reduce過程當中產生的中間數據，某些子查詢結果緩存後再下次遇到相似子查詢將從緩存讀取，下降數據庫訪問壓力，同時提升數據查詢執行效率。

4、小結

到此，咱們結束了分佈式數據做業的總述，從背景目標到分佈式數據做業的由來及總體機制給你們作了介紹，具體的各個技術實現咱們團隊將在以後給你們分別一一分享，請你們繼續關注。