分佈式數據作業系列之
總述
（ChongQing , Dss Team , rlma , 2014/04/26）
隨着信息技術發展，雲計算、大數據已成爲當代IT的熱門話題，海量信息的搜索和深度數據的挖掘更是炙手可熱。民航業快速擴大，各種民航信息數據迅猛增長，這對於中國航信來說既是機遇又是挑戰，利用這些豐富的民航數據資源，我們可以深度分析航班經營情況及盈利模式，可以挖掘民航業中的潛在價值，更可以分析旅客行爲習慣，不光爲航空公司提供決策支持，更爲社會市場經營與商業規劃提供可靠的數據參考和分析。
然後，民航數據的大量性和快速增長性又給我們帶來了巨大的挑戰，如何實現數據的快速導入，如何實現數據的優質存儲，如果實現信息的準確分析，這些問題都是我們在這個過程中必然要解決的。
今年初，新一代產品線成立了DSS（決策分析）子項目，在這裏我們面對全民航所有的航班和銷售數據，面對每小時過億的數據存儲，面對大量數據的快速分析。經過一段時間的技術試驗和數據分析，傳統的數據存儲模式已經不能滿足我們在數據快速導入及分析上的需求，爲了更好的完成目標，項目組積極研發探索，結合當代雲計算與大數據思想，實現了一套自己的分佈式數據作業框架，使得集羣計算利用率得到較大提升，系統TPS較傳統模式也有了巨大改進。就此項技術而言，雖不能同HADOOP一類的優秀框架媲美，但在過程中我們用自己的技術和方式去改進實現，這一路的探索和實踐，僅此想和大家做一些交流和分享。
一、背景及目標
DSS目前主要實現航信DIP指令數據數據快速導入存儲，並就數據實現實時、快速的分析。
DIP數據是航信指令數據，分爲FDL、FLP、FLR、RO四類指令數據，各類數據已壓縮文件形式存放於數據服務FTP文件系統中，每小時都會更新一次（以RO爲例，一天將產生18個數據壓縮文件），系統要將每小時產生更新的數據文件下載、解壓、解析並存儲。
4類指令數據將解析成BFG、BLG、BSG、BLC、BSB等粒度的數據信息，下圖爲一個小時產生的數據信息統計。
從統計來看，系統將實現一小時1700萬條數據存儲，數據庫數據大小1.2G，一天下來數據記錄數約1.7億，數據庫空間消耗12G。
就目前數據存儲而言，規定採用的是EDB關係數據庫，如此一來，不論是在存儲和分析上都面臨很大的壓力。也許有人會說，對於如此大的數據還使用關係數據庫來存儲，整個存儲和分析的成本和開銷相對NOSQL模式都大很多，爲什麼還要繼續折騰。我想告訴大家的是，在我們產品研發過程中，很多時候不是我們的要求決定環境，而是我們怎麼去適應環境，在現有環境下去優化和提升。
二、傳統實踐
傳統模式下，對於數據導入我們採用一些數據訪問框架技術實現數據插入，如SpringTemplate等實現數據Insert。結合多線程，採用定時器在每個數據採集時間點啓動多線程實現數據下載、解壓、解析和存儲。爲每個數據文件啓動多線程執行作業，想通過併發來提高數據操作的吞吐量和性能。
但多次測試和實踐結果顯示，儘管系統的線程數擴大到1000個，數據的吞吐量仍然上不去，系統CPU利用率仍然保持在20%左右。對問題進行分析得出結論：
（1）多線程並不意味着高併發
多線程大家都知道是程序異步處理的一種實現，通過多線程可實現多個任務同時作業來提高效率。但從計算機原理來說，任何計算機執行單元都將被編譯爲多個指令集，CPU以輪詢的方式對各個指令進行處理，比如對於單CPU的計算機來說，每個單位時間內被處理的指令只有一個，只是這個時間非常短暫，以至於我們感覺不到這個間隔，認爲不線程就是被同時處理的。所以，線程數的設計和CPU的核數及其處理能力密切相關，更多的去發起線程只會加重系統資源及CPU時間片的搶佔，不論是從內存還是CPU上的消耗都很大。
（2）數據庫瓶頸
數據庫瓶頸表現在數據插入時消耗時間較長，運行時間越久插入越慢。原因在於數據插入時需要維護對應的數據索引，數據越大維護的成本就越高，同時，多線程對一個表操作時，寫數據塊過程就會造成排隊，一方面降低了數據庫吞吐，另一方面讓其他線程處於等待狀態，數據吞吐量較低，且長時間的idle使得CPU利用率也上不去。針對這個數據庫優化我們會在以後和大家分享。
三、分佈式數據作業
經過傳統方式實踐得知，多線程並不能真正意義上提高整個系統的吞吐和資源利用率，採用分佈式數據作業的模式就由然而生了。
和雲計算的思想一致，分佈式數據作業的目的是通過使用更多的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過程中產生的中間數據，某些子查詢結果緩存後再下次遇到類似子查詢將從緩存讀取，降低數據庫訪問壓力，同時提高數據查詢執行效率。
四、小結
到此，我們結束了分佈式數據作業的總述，從背景目標到分佈式數據作業的由來及整體機制給大家做了介紹，具體的各個技術實現我們團隊將在之後給大家分別一一分享，請大家繼續關注。