1 背景
某市公安局對於車輛卡口數據統計分析有如下要求：
- 過車統計功能：根據統計時間設置，可統計指定時間段和時間類型內指定分組的過車總量，過車量趨勢（根據時間類型確定基本統計粒度）；對於指定分組，可下鑽到每個設備的過車總量與過車量趨勢分析。
- 車輛卡口設備故障類型判斷：根據需求分爲4類故障：設備脫機；車道流量異常；URL鏈接無效；校時偏差。車輛卡口設備設置了兩種狀態：在線/脫機狀態，故障/非故障狀態。
- 故障統計功能：分爲實時故障(爲未恢復的故障)統計與歷史故障統計兩類：
實時故障統計：根據指定分組統計各分組類的實時故障數量，並能展示、查詢該分組內的實時故障明細；根據指定分組統計各類型的實時故障數量，並能展示、查詢該分組內的實時故障明細。
歷史故障統計：根據指定分組可進行卡口設備的選擇，根據選擇的設備以及故障類型、時間段可進行設備歷史故障的查詢。 - 設備統計功能：根據指定分組，可統計各分組的設備總數、在線數、脫機數、故障數、在線率。對於各分組可查看設備的故障明細。
- 車輛卡口巡檢和篩選功能：根據圖片抽檢策略創建圖片巡檢任務，可對巡檢結果進行統計。
2 設計思想
視圖庫作爲車輛卡口運維模塊的上游數據服務。是車輛卡口運維模塊的數據來源。車輛卡口運維模塊中的數據統計需求非常多，需要構建一個數據倉庫(Data warehouse)，對來自視圖庫的面向車輛主題的原始數據進行ETL操作，放入存儲容器中。針對視圖庫中發送的數據，在數據倉庫中可創建星形結構模型，在統計時可根據時間維度和行政區劃維度等多維度進行OLAP分析。
視圖庫目前可向外提供時間粒度爲1分鐘的統計數據，通過消息中間件(如kafka)發送。統計數據可按設備、平臺、數據類型等維度提供。在車輛卡口運維模塊中需要根據視圖庫提供的原始粒度數據進行匯聚統計（如車輛卡口運維中判斷實時故障），因而需要緩存這些1分鐘粒度的基本統計數據。在實現中我們使用了時序數據庫工具prometheus來持久化緩存這些1分鐘粒度的原始統計數據，使用ES作爲數據倉庫存儲容器來存儲匯聚統計後的數據（如1小時的統計數據，再由1小時的統計數據匯聚統計爲1天的數據）。
3 系統架構
車輛卡口運維模塊的邏輯結構視圖如下，其中箭頭方向表示數據流向：
視圖庫使用消息中間件(kafka)向車輛卡口運維模塊發送的數據爲：以1分鐘爲統計粒度的視圖庫收到的各數據類型的統計數據（分爲設備與平臺兩個數據來源維度），以1分鐘爲統計粒度的視圖庫發往各訂閱者的統計數據（分爲設備、平臺兩個數據來源維度與訂閱者一個數據推送維度）。這類數據被解析爲prometheus指標數據發送到時序數據庫prometheus中。
車輛卡口運維模塊需要從統一設備服務中獲取系統所管理的採集設備信息（人/車採集設備）。並將獲取的設備集合作爲基準設備集合進行設備故障的判斷：如判斷車輛卡口設備是否脫機，需針對基準設備集合中的每個設備查詢其在prometheus中存放的過去30分鐘過車數據是否爲0。同樣，對於設備與故障的統計也需基於此基準設備集合進行。
對於視圖庫的收發數據統計的最小粒度爲1小時，統計維度可以爲日，周，月，年。因而在ETL模塊中使用定時任務對prometheus中1分鐘的基礎粒度數據進行彙總，在數據倉庫中首先匯聚爲1小時的數據（整點），再根據1小時的數據匯聚爲一天的數據。即在數據庫中存在各類型數據的小時表與天表，視圖庫的收發數據統計根據小時表與天表進行統計。
4 項目實施後的思考
通過兩個月的開發測試，目前此項目目前已經上線，回顧此項目的開發，可以發現：在開發中我們使用了兩個數據容器：
- prometheus:作爲時序數據庫使用，實現了在ETL中的細粒度匯聚，爲實時故障的檢測提供了數據依賴。
- ES：作爲數據倉庫的存儲容器使用，其中存儲的最小粒度數據爲1小時統計數據。
其實在ETL設計中，我還考慮了其它幾種方案和選型： - 使用kafka streams的分組匯
進行細粒度數據的匯聚，與現有方案相比，優點在於免去了引入prometheus的系統開銷，但同時增加了kafka的topic,由於kafka streams只提供流式數據，對於車輛卡口故障統計無法很好實施。 - 使用內存數據庫，細粒度數據存於數據庫中，定時進行彙總和統計並寫入ES，使用思路同prometheus，但內存數據庫不持久化，出現重啓的情況之前的數據會丟失。
最後綜合考慮還是使用了prometheus，既實現了細粒度數據的持久化，還利用prometheus的強大時序統計功能實現了定時匯聚功能和定時數據檢測功能。但由於引入prometheus也帶來了系統開銷的增加。