一、平臺方向

1.概念：就是構建這樣一套元件: 從日誌資料如何高效、穩定、安全、被清洗、被脫敏後進入儲存節點到對映為表結構，再到為分析人員和演算法人員 提供高效、穩定、安全、便捷的查詢服務 （平臺人員去做的事）。（分析人員去做的事）使得分析人員只需要寫一個sql然後通過BI工具進行結果展示 或者採用web開發，進行web展示。演算法人員可以根據相關元件拿到大量離線資料和實時資料去做資料建模和預測。平臺人員的需求方是分析人員和演算法人員，而不是具體的專案需求提出者，與專案需求提出者對接的應該是資料分析人員和演算法人員。平臺人員寫的sql應該是資料抽取、資料清洗相關的sql，而不是用於資料分析和統計相關的sql。

平臺人員在元件上的關注點：多個元件的使用，多個元件如何組合，各個元件原始碼的研究以及在具體專案下對原始碼的調優，最後再加上平臺的運維與升級。

2.平臺人員需要跟進最新元件技術

結合當下最新的開源專案，最流行的元件應用，不斷優化自己的平臺結構。

3.日誌資料分類：

(空調)機器日誌資料：關係型日誌資料+執行時機器自動產生的日誌資料

關係型日誌資料：機器的生產日誌記錄，如生產時間，安裝時間，就是一些關於機器固定的描述性資訊，資料量小，每個機器ID只有一條唯一的記錄。

執行時日誌資料：由機器啟動後自動產生或出現故障時觸發產生， 每個機器ID根據執行時的時間的不同而有多條記錄。每條記錄的列包含一些可變化的數字資訊。

機器資料特點：機器引數可能很多，錯誤資料多，通過gps模組+sim卡網路傳輸 資料易丟失，延遲可能很高（因為延遲導致同一機器 不同表 ，執行資料不同步），清洗困難，適合離線處理，不適合實時處理（清洗），因為實時join會丟資料。

（電商)網路日誌資料：

關係型日誌資料：使用者的個人詳細資訊，快遞員個人資訊，商家個人資訊，每個使用者ID只有一條唯一的記錄。

執行時日誌資料：由相關人員事件觸發產生，使用者的購買記錄，退貨記錄，快遞員送貨記錄，商家出貨記錄，交易記錄。每個ID根據事件發生的時間的不同而有多條記錄

網路日誌資料特點：執行資料 種類多，延遲低，錯誤資料少，適合實時處理（ETL、清洗與細粒度分析統計）也適合離線處理（粗粒度統計， 如按年統計啥的）

4. 日誌採集的幾種方式

離線採集

關係型日誌-->關係型資料庫-->ETL工具(sqoop,kettle,spark)--->hive-->kylin-->tablalu、superset、web前端 （最後加上增量）

資料抽取、轉換、清洗、脫敏、載入工作由ETL工具來做。

實時採集

 獲取執行日誌資料的介面-->kafka(json、string、schemal)-->flume-->hbase/hive

 獲取執行日誌資料的介面-->kafka(json、string、schemal)-->kylin（1.將json等訊息對映為表結構  2.建立model和cube）

 獲取執行日誌資料的介面-->kafka(json、string、schemal)-->spark streaming、flink-->hbase/mysql/redis-->web前後端

 獲取執行日誌資料的介面-->kafka(json、string、schemal)-->spark streaming、flink-->es-->搜尋查詢

一般地資料抽取、轉換、清洗、脫敏、載入工作由kafka的下一級來做。

特殊情況： 獲取執行日誌資料的介面-->kafka(json、string、schemal)-->kylin

可改為：獲取執行日誌資料的介面-->kafka(json、string、schemal)-->flume-->kafka-->kylin 在flume裡面做，如果該工作邏輯比較複雜，也可將flume 改為spark streaming 的rdd 來做。