引子
半夜三點，睡夢中被一陣沒人接聽誓不罷休的電話鈴吵醒。睡眼惺忪的接聽了電話，電話那頭傳來了不用聽清任何人類語言就能感受的焦急。讓我趕快打開電腦，說服務整個不工作了！
打開監控看到線程池被打滿。本着“先恢復現場再排查原因”的基本原則，重啟並擴容了一倍的服務器。服務又正常了。完美的做到了“三分鍾定位，十分鍾解決”。但是現場不在了，怎么排查根因呢？答案是：歷史記錄。
為什么要做歷史記錄
歷史記錄是大數據的最重要數據源。通過歷史記錄可以進行事件追溯、未來預判和推薦。舉個例子：
靜兒在網上搜索了“穩定性三十六計”這個詞，找到自己想要的內容了。然后去做別的事情，再打開瀏覽器的時候，發現旁邊的小彈出框里推薦我《穩定性寶典》這本書。
這個推薦效果很多種算法都能實現，比如最近比較火的“協同過濾推薦算法(Collaborative Filtering Recommendation)”。啥是協同過濾推薦算法呢？協同過濾推薦算法簡而言之，就是找到相同興趣的群體，將這個群體中感興趣的其他信息推薦給用戶。
實施的時候可以先建立一個大表，X軸是所有的推薦內容，Y軸是所有的用戶。
然后我們將每個用戶感興趣的XY交叉點都標出來。如圖可以看到對“穩定性三十六計”感興趣的對“穩定性寶典”感興趣的概率也很高。
歷史記錄對於穩定性，也可以將其他同類系統作為用戶，將他們的問題作為推薦項進行協同過濾分析，找到自身的可優化點。系統出了問題需要分析原因時，事件追溯更是必不可少。
怎么做歷史記錄
日志
最常用的事件維度記錄是日志。有存於本地磁盤和集中式日志兩種。
本地磁盤日志就是將日志在程序中控制直接寫入本地磁盤。
集中式日志的架構大同小異，基本結構如下：
- 采集器負責采集數據，並發送給收集器。
- 收集器負責收集采集器發送過來的數據，並定時寫入集群。
- 存儲中心負責對數據分類、排序、去重，把同類型的數據合並。
- 分析和可視化平台負責數據的展示。
以下是常用的數據收集系統的比較
| 產品 | 公司 | 優勢 | 劣勢 |
| Flume NG | Cloundera |
1.支持故障轉移和負載均衡
2.容易水平擴展
3.社區活躍、文檔豐富
4.依賴第三方類庫少
5.通過事務保證數據一致性
6.支持多種存儲
|
1.需要自己實現客戶端代碼
2.對數據的過濾能力差
|
| Scribe |
1.具有很高的容錯性
2.支持水平擴展
|
1.依賴zookeeper或Hash等工具
2.需要自己實現客戶端代碼
3.社區活躍度低、文檔少
3.依賴第三方庫多
4.部署復雜
5.存儲系統類型少
6.數據過濾解析能力差
7.官方已經停止更新和維護
|
|
| Chukwa | Apache |
1.高可靠
2.易擴展
3.社區活躍度較高
4.文檔資料豐富
|
1.依賴hadoop |
| ELK | Elasic.co |
1.提供完整的解決方案
2.支持集群部署和水平擴展
3.社區活躍度高、文檔豐富
4.部署簡單
|
1.占用資源比較高 |
ELK不是一款軟件，而是Elasticsearch、Logstash和Kibana首字母的縮寫。這三者是開源軟件，通常配合一起使用。而且先后歸於Elasic.co公司的名下，所以簡稱ELK Stack。根據Google Trend的信息顯示，ELK已經成為目前最流行的集中式日志解決方案。
Nosql
除了日志，任何有價值的歷史信息都是應該存儲起來做分析的。這時候存儲就是關鍵。因為數據量大，對強一致性沒有苛刻的要求。所以從成本上傳統的關系型數據庫不是首選。一般選擇Nosql數據庫。Nosql數據庫主要有四類：
1.key-value數據庫
| 項目 | 說明 |
| 典型應用場景 | 內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日志系統 |
| 數據模型 | Key指向Value的鍵值對，通常用hash table實現 |
| 強項 | 查找速度快 |
| 弱項 | 數據無結構，通常被當做字符串或者二進制數據 |
| 例子 | Redis、Memcached |
2.列式數據庫
| 項目 | 說明 |
| 典型應用場景 | 分布式的文件系統 |
| 數據模型 | 以列簇式存儲，將統一列數據存在一起 |
| 強項 | 查找速度快，可擴展性強，更容易進行分布式擴展 |
| 弱項 | 功能相對局限 |
| 例子 | Cassandra、HBase |
3.文檔型數據庫
| 項目 | 說明 |
| 典型應用場景 | Web應用，Value是結構化的，容易被解析 |
| 數據模型 | KeyValue的鍵值對，Value為結構化數據 |
| 強項 | 數據結構要求不嚴格，表結構可變、不需要預先定義表結構 |
| 弱項 | 查詢性能不高，缺乏統一的查詢語法 |
| 例子 | CouchDB、MongoDB、Elasticsearch |
4.圖結構數據庫
| 項目 | 說明 |
| 典型應用場景 | 社交網絡，推薦系統等。專注於構建關系圖譜 |
| 數據模型 | 圖結構 |
| 強項 | 利用圖結構相關算法，比如最短路徑尋址，N讀關系查找等 |
| 弱項 | 需要再次計算出所需信息，不容易做分布式集群方案 |
| 例子 | Neo4j、InfoGrid、Infinite Graph |
時序數據庫
時序數據庫全稱為時間序列數據庫。時間序列數據庫主要用於指處理帶時間標簽的數據。帶時間標簽的數據也稱為時間序列數據。
基於時間序列數據的特點，關系型數據庫無法滿足對時間序列數據的有效存儲與處理，因此迫切需要一種專門針對時間序列數據來做優化的數據庫系統，即時間序列數據庫。
目前行業內比較流行的開源時序數據庫產品對比如下：
| InfluxData | Prometheus | Graphite | OpenTSDB | |
| 數據模型 | labels | labels | dot-separated | label |
| 按時間分段管理數據 | ✔️ | ✔️ | ✔️ | 手動 |
| 分布式 | ✔️商業版 | 單機 | 單機 | ✔️ |
| 聚合分析 | 弱 | 弱 | 弱 | 弱 |
| 權限管理 | ✔️商業版 | × | × | × |
| 接口 | 類SQL | REST | REST | REST |
| 社區生態 | +++ | ++ | ++ | ++ |
| 時間序列分析 | 無 | 無 | 無 | 無 |
| 抽取日志指標 | × | × | × | × |
| Rollup | ✔️ | × | ✔️ | × |
總結
Talk is cheap, show me the data!
推薦閱讀
關於作者
一線開發十二年，有日本東京和美國硅谷研發經驗。有百余項技術發明專利，目前任美團點評技術專家。有自己的技術公眾號「編程一生」。如果您在閱讀本書時有什么疑問或者發現本書的錯誤，歡迎在公眾號里給我留言。