根據監控物件的不同，監控系統可以分為系統監控、應用監控和業務監控。「實時交易監控系統」屬於業務監控，主要用於監控客戶的購買行為及訂單情況，一般用於支援公司的日常運營決策和重大營銷活動，如「雙11」、「雙12」及「雙旦」等，對資料的實時性要求較高。「實時交易監控系統」對資料的一般處理流程：實時捕獲資料庫中交易資料的變更、實時計算訂單各維度的指標、再實時推送指標到瀏覽器大屏。通過採集、計算、展示三個階段的實時性來保證整個監控系統的時效性，延遲可控制在秒級或亞秒級以內。
這個是效果圖，企業內上線的專案監控的需求會有很多，這個是簡易版的，做了很多的需求刪減。
通過「實時交易監控系統」的開發，來講解典型的大資料實時解決方案的過程及原理，包括資料採集（kafka+canal）、資料計算（spark streaming/storm/kafka stream）、資料儲存(hbase)、資料應用及視覺化（echarts）等。
監控系統概述
包含要素:
全方位的監控指標
異常告警通知:告警觸發閾值、告警監控物件、告警通知接收人以及傳送渠道
視覺化圖表分析
監控規則配置化
應用場景:
業務質量實時關注
業務異常提前發現
業務精細化運營/運維
實施流程:
指標採集->指標加工->指標儲存->指標視覺化
專案技術架構流程圖
看圖方式為從上往下、從左往右來看，以箭頭的指向，箭頭指向的是原資料的流向到最終展示的路徑。
mysql為例，mysql的交易資料binlog，裡面的訂單資料、使用者的註冊資料或者使用者的購買資訊。原資料怎麼實時的往後面流轉呢？這裡就用到了alibaba canal開源元件，實時監控資料變更與捕獲在推送到kafka。
kafka是乙個大型的訊息佇列緩衝區，是個集群模式的訊息緩衝區，可以存大量的緩衝資料，如果我們的交易量較大的時候會用到kafka做乙個訊息緩衝作用，形成一些原始的交易資料。
緩衝完之後，會再進入到實時計算框架spark streaming中，spark streaming會消費kafka裡面的這些訂單資料，從spark streaming這一段的分支，分別是做監控的思路
綠色箭頭方案：
spark streaming把資料處理成我們想要的metric，做一些聚合與指標的處理，metric又會回流到kafka當中。
在處理完指標之後，會啟乙個nodejs的乙個服務，這個服務會再次去消費metric的這個kafka，然後通過socket.io這樣的乙個web socket雙向互動的工具在把資料推送到瀏覽器，然後就會看到整個資料是從資料庫抽取出來，一系列的傳遞在實時推送到瀏覽器的，實時的處理鏈路就清晰了，在看到實時的動態變化的大屏。只要mysql裡面有交易發生，那整個資料流就會通過這樣乙個管道最後到達瀏覽器。
紅色箭頭方案：
spark streaming把基礎資料加工完成之後，會放到hbase裡。根據hbase裡有沒有新增的指標，有新增指標在傳輸過去做變動展示，瀏覽器做不定時的重新整理。
了解了大資料的入門所必須的基礎知識點，不用多說，最後的實戰訓練是最重要的，進行一些實際專案的操作練手，可以幫助我們更好的理解所學的內容，同時對於相關知識也能加強記憶，在今後的運用中，也可以更快的上手，對於相關知識該怎麼用也有了經驗。
分享給喜歡大資料，有夢想成為大資料架構師的程式設計師們，希望能夠幫助到你們，一起進步吧！
大資料業務分析基本步驟
做什麼事情都要有流程，要知道做什麼，怎麼做，of course，bigdata也不例外。通俗的說就是你要做什麼，你要怎麼做，你要做成什麼，你要解決什麼問題，你的思路是什麼。把需要進行資料分析的事情，拆解成一段一段的來完成，先給自己定個小目標，掙他乙個y,哈哈哈 先分析什麼，後分析什麼，就不會覺得從何...
QoS 無線資料業務的基礎
從上面的例子中可以看到 qos 對無線資料業務的重要性，當然傳輸速率只是 qos 眾多屬性中的乙個，下文從我理解的角度來說說重要的屬性。順序按照屬性在 qos 結構中的先後次序。還要宣告的是，在 rel 6 的 qos 可以分為相互參照的兩部分，即 r97 98 qos 版本和 rel 6 qos ...
大資料業務到底該由哪位企業高管負責？
文章講的是大資料業務到底該由哪位企業高管負責，到目前為止，我們還很難說清到底由 c什麼o 來打理大資料方面的事務。對於cio們而言，如果他們想要承擔起這份職責，首先需要把注意力從技術轉移到業務創新身上。許多企業都面臨著相同的難題 到底應該由誰來統領企業中的資料與分析工作?答案多種多樣，cio只不過候...