中國移動運營分析實時監控平臺之專案背景和專案需求
1. 專案背景
中國移動公司旗下擁有很多的子機構,基本可以按照省份劃分. 而各省份旗下的充值機構也非常的多.
目前要想獲取整個平臺的充值情況,需要先以省為單元,進行省份旗下的機構統計,然後由下往上一層一層的統計彙總,過程太過繁瑣,且統計週期太長. 且充值過程中會涉及到中國移動資訊系統內部各個子系統之間的介面呼叫, 介面故障監控也成為了重點監控的內容之一.
為此建設一個能夠實時監控全國的充值情況的平臺, 掌控全網的實時充值, 各介面呼叫情況意義重大.
2. 技術選型
2.1. 難點分析
移動公司旗下子充值機構眾多, 充值資料量大.
資料實時性要求高
2.2. 可用技術選型
實時流式計算框架 Storm
實時流式計算框架 Spark Streaming
實時流式計算框架 Flink
2.3. 對比分析
Storm、Spark streaming、Flink 都是開源的分散式系統，具有低延遲、可擴充套件和容錯性諸多優點，允許你在執行資料流程式碼時，將任務分配到一系列具有容錯能力的計算機上並行執行,都提供了簡單的 API 來簡化底層實現的複雜程度。
Apache Storm
在 Storm 中，先要設計一個用於實時計算的圖狀結構，我們稱之為拓撲（topology）。這個拓撲將會被提交給叢集，由叢集中的主控節點（master node）分發程式碼，將任務分配給工作節點（worker node）執行。一個拓撲中包括 spout 和 bolt 兩種角色，其中 spout 傳送訊息，
負責將資料流以 tuple 元組的形式傳送出去；而 bolt 則負責轉換這些資料流，在 bolt 中可以完成計算、過濾等操作，bolt 自身也可以隨機將資料傳送給其他 bolt。由 spout 發射出的 tuple是不可變陣列，對應著固定的鍵值對。
Apache Spark
Spark Streaming 是核心 Spark API 的一個擴充套件，它並不會像 Storm 那樣一次一個地處理資料流，而是在處理前按時間間隔預先將其切分為一段一段的批處理作業。Spark 針對持續性資料流的抽象稱為 DStream（DiscretizedStream），一個 DStream 是一個微批處理（micro-batching）的 RDD（彈性分散式資料集）；而 RDD 則是一種分散式資料集，能夠以兩種方式並行運作， 分別是任意函式和滑動視窗資料的轉換。
Apache Flink
Flink 是一個針對流資料和批資料的分散式處理引擎。它主要是由 Java 程式碼實現。對 Flink 而言，其所要處理的主要場景就是流資料，批資料只是流資料的一個極限特例而已。再換句話說，Flink 會把所有任務當成流來處理，這也是其最大的特點。Flink 可以支援本地的快速迭代，以及一些環形的迭代任務。並且 Flink 可以定製化記憶體管理。在這點，如果要對比 Flink 和 Spark 的話，Flink 並沒有將記憶體完全交給應用層。這也是為什麼 Spark 相對於 Flink，
更容易出現 OOM 的原因（out of memory）。就框架本身與應用場景來說，Flink 更相似與
Storm。
業務節點分為 PC 端和手機端:
PC 端一共有 11 臺, flume 會監控每臺節點生成的日誌檔案, 一共有 11 個 Flume 節點手機端一共有 8 臺,flume 會監控每臺節點生成的日誌檔案, 一共有 8 個 Flume 節點.
支付結果通知和充值結果通知:
該業務有 4 臺節點, flume 會監控每臺節點生成的日誌檔案, 一共有 4 個 Flume 節點. 機器配置?
- 專案資料量
資料量每天大概 2000 到 3000 萬筆的下單量, 每條資料大概在 0.5KB 左右,下單量資料大概在 15GB 左右.
最後充值成功的大概 500 到 1000 萬,平時充值成功的大概五六百萬筆.
月初和月末量比較大