以上架構設計適合小規模的應用場景，難以解決大規模采集數據場景下的動環監控業務應用，本文提出一種集群大數據平臺技術架構，以滿足動環監控系統對大規模測點實時性采集和處理、大數據高效存儲和查詢、分布式容錯處理等要求，同時為第三方SC、SC、大數據分析、其它應用提供共享服務。另外，還制定測點和設備編碼規范、測點和設備命名規范、事件和轉臺字典規范以及服務接口標準化規范等。技術架構設計包括數據采集、分布式消息隊列(Kafka集群)、在線實時處理(Storm集群)、數據存儲中心、共享服務、配置管理等部分。技術架構如下圖所示:

       1、面向不同層次的數據采集。支持面向第三方集中監控中心(SC)和第三方現場監控單元(FSU)數據采集;同時，支持面向動力系統和環境系統的現場監控單元數據直采(一體式或主從式FSU)。依據不同的規約協議定制開發采集程序，底層采集數據統一匯聚至分布式消息隊列(Kafka集群)。定制ETL單元采集數據推送至分布式消息隊列(Kafka集群)，由在線實時處理(Storm集群)應用，基于配置管理預先定義的點表映射關系進行處理，轉換成動環監控平臺自定義編碼;而現場監控單元，基于配置管理預先定義的點表映射關系，將底層動力和環境系統產生的測量數據，直接轉換成動環監控平臺自定義編碼，無需在線實時處理(Storm集群)應用進行點表映射處理。

       2、集群式消息隊列。在支持各個子系統本身業務應用要求的前提下，采集數據集中匯總到消息中間件(Kafka)緩沖，每一個采集服務器在消息隊列中采用唯一標識的主題(Topic)存儲，消息中間件中的數據存儲格式采用JSON格式;集中存儲的優勢在于:平臺級應用方無須關注實現各個廠家不同的通訊方式和交互流程，在數據匯總的方式上基于互聯網的公開標準進行了統一，數據格式可以不統一。傳統做法是要求數據格式的統一，將復雜的數據格式處理轉嫁給了數據采集方，增加了數據采集方的工作量，另外，所謂的統一格式，也不能得到廣泛認可，消息隊列的通訊方式是公認的技術。

       3、實時高并發數據處理機制。統一業務數據格式(設備編號、測點編號、測點數值、測點類型、采集時間等)，預先定義映射關系，將不同數據格式的底層采集數據，統一格式化成標準的業務數據;對于模擬量、計算量、開關量實時數據的處理和存儲。

       4、混合數據存儲模式。針對不同類型數據，依據業務應用實際要求，選擇合適的存儲模式進行數據持久化處理，并對外提供數據。對于文件、圖像、視頻以文件方式存儲;實時測點數據存儲在內存數據庫(Redis集群)，事件狀態數據局域(Redis)的消息訂閱機制，及時向外部應用推送;歷史測點數據存儲在時間序列數據庫(OpenTSDB集群)，配置管理、基礎信息、業務數據、主題分析數據存儲在關系數據庫(MySQL集群)。

       5、開放式共享服務接口。事件、狀態、告警等即時消息，通過消息隊列訂閱機制對外推送;提供RESTful Web服務共享接口，為遠程控制操作、實時數據和歷史數據查詢提供應用基礎;同時，平臺對外開發時間序列數據庫、內存數據庫、消息隊列訪問方式。

       6、可拓展業務應用。共享服務支持第三方集控中心(SC)、SC、大數據分析應用、其它應用等二次開發。

       7、標準化、規范化。動環監控平臺制定規范化和標準化的編碼、命名、字典、接口定義，基于標準化、規范化基礎，提供可視化的配置管理工具。

來源：機房監控 http://www.28ut.com