問題背景

發電設備中常常會放置傳感器（DCS）來采集數據以監控設備運轉的狀況，某集團設計的電力監控統計系統，需要實時采集傳感器的數據后保存，然后提供按時段的實時查詢統計功能。

系統設計規模將支持20萬個傳感器（以下稱為測點），采集頻率為每秒一個數據，即每秒總共會有20萬條數據，總時間跨度在1年以上。在這個基礎上實現任意指定時段的多個測點數據統計，包括最大、最小、平均、方差、中位數等。

系統原結構圖為：

系統中，用戶期望的統計響應延遲為：從20萬個測點中任取100個測點，統計頻率最高可能每隔若干秒調用一次，從總時間跨度中統計任意一天的數據，預期執行時間在1分鐘內，另外還會有少許離線任務，最長的時間段跨度長達一年。

現有的數據中臺中沒有計算能力，僅存儲數據，計算時需要通過RESTful接口取出數據再統計。經測試，通過RESTful接口從數據中臺取數，取出100個測點一天的數據量就需要10分鐘時間，還沒有開始計算，取數的時間已經遠遠超出了完成計算的預期時間。

基于現有結構，完成上述統計任務，性能上無法達到預期要求，需要將數據重新存儲。

解決辦法

第一步，梳理數據和計算要求

數據結構如下：

計算要求為：在每秒生成20萬條記錄的時序數據中，任意時間段內，從20萬個測點中任取100個測點的數據，分別基于每個測點的數值序列統計最大、最小、方差、中位數等結果。

第二步，確定存儲和計算方案

20萬測點一天的數據，僅Value字段，就要200000*86400*4字節，至少64g內存，當總時間跨度為1年時，數據量會有數十T，單臺服務器內存顯然裝不下。多臺服務器集群，又會帶來很高的管理和采購成本。

簡單按時間為序存儲的數據，可以迅速找到相應時間區間，但即使是這樣，單個測點一天也有86400條記錄，20萬個測點共17.28億條，每次統計都要遍歷這個規模的數據，也很難滿足性能要求。

那么測點號上建立索引是否可行？

索引只能快速定位數據，但這些數據如果在外存中不是連續存儲的，硬盤有最小讀取單位，會導致大量無用數據量讀出，使得計算變得很慢，同樣也無法滿足性能要求。此外，索引占用空間會隨著數據量增大而增大，并且插入數據的維護開銷也更大。

如果數據可以按測點號物理有序存儲，并在測點號上建立索引，相比時序物理有序存儲，查找時，待查找的測點記錄變得緊湊了，需要讀入的塊也就少了。100個測點的數據存成文本約300m不到，這樣即使使用外存也可以滿足性能要求。

只有歷史冷數據時，處理起來比較簡單，定時將數據按指定字段排序即可。但實際上，每秒都會有20萬個測點的新數據，因為歷史數據規模巨大，如果每次獲取幾秒熱數據都與歷史數據整體按測點號、時間排序，即使不算排序，僅是重寫一遍的時間成本上都無法接受。

這時，需要將冷熱數據區分對待。不再變化的冷數據可以按測點次序準備好。這里有一點變通，因為要將非常早期的數據刪除（比如一年前的），如果所有冷數據都按測點排序時，會導致數據維護比較麻煩，刪除早期數據會導致重寫一遍所有數據。因此，可以設計為先按時間分段，每段時間內的數據按測點、時間有序，整體數據還是按時間有序。任務需求是按天計算，這里按天分段就比較合適，更長跨度的離線計算性能損失也不是很大。每當一天過去時，將昨天數據按上述規則排序后存儲，當天的數據作為熱數據處理。但是，當天內的數據量還是太大了，依然無法全部裝入內存，還需要再分。

經過一些測試后確認，我們發現將數據按熱度分為三層可以滿足要求。第一層，十分鐘內的熱數據通過接口讀入內存；第二層，每過10分鐘，將過去10分鐘的內存數據按測點、時間有序保存到外存；第三層，每過一天，將過去24小時內的所有每10分鐘的數據按測點、時間有序歸并?？倲祿椋阂荒甑臄祿?65段每天數據，加144段當天數據和一段內存數據。

分層后的冷熱數據屬于不同的數據源，需要獨立計算同源數據的結果后，再將結果合并起來，算出最終的統計結果。即使計算方差、中位數這種需要全內存統計的情況，100個測點一天的數據量，也只需要64m內存。

第三步，確定技術選型和方案

從上述的存儲方案中得知，需要將實時數據按時間分段，段內按測點號、時間物理有序存儲，常規數據庫顯然沒辦法做到這點。此外，拆分數據需要可以支持按自定義時間段靈活地拆分；數據存儲時要具備高性能索引；冷熱數據屬于不同層（不在同一個數據源），計算時需要分別計算后再合并。

完成該任務，用Java硬編碼工作量巨大，Spark寫起來也很麻煩。開源的集算器SPL語言提供上述所有的算法支持，包括高性能文件、物理有序存儲、文件索引等機制，能夠讓我們用較少的代碼量快速實現這種個性化的計算。

取數不能再用原系統的RESTful接口，也不合適直接通過API從DCS獲取數據。用戶方商定后引入kafka緩沖數據，屏蔽DCS層，同時還可以將DCS的數據提供給不同的消費者使用。變更后的系統結構圖如下：

說明：

1. DCS系統每秒推送20萬個測點數據至Kafka MQ。
2. Kafka MQ到SPL：使用SPL基于Kafka API封裝的Kafka函數，連接Kafka、消費數據。
3. 內存緩沖：循環從Kafka消費數據(kafka_poll)，每輪循環確保10秒以上的數據量，將每輪前10秒的數據補全后，按測點、時間序，保存成文件并讀入內存。
4. 分層數據文件：按不同時間段將冷熱數據文件分層。
5. 統計時將冷熱數據混合計算。
6. 支持每個測點名對應一個CSV文件作為數據源計算。
7. 統計接口以HTTP服務方式供外部應用調用并將統計結果通過回調接口返回給外部應用。

第四步，實施優化方案

現有的RESTful接口取數太慢了，接口變為從kafka消費數據。存儲數據時，將字符串類型的測點名數字化后保存，以獲得更小的存儲量和更好的運算性能。

在第二步中已經提到，數據量較大時，無法將數據都放在內存中計算，所以考慮采用冷熱分層方案，將數據分為三層，每天的冷數據按測點號、時間有序（下文中的所有外存文件存儲均采用該序，不再重復說明），用組表存儲，因為大表對性能的影響很大，存儲成組表有利于提升系統整體性能；當天的每10分鐘的冷數據用，集文件存，因為集文件創建和使用都更簡單，用來存儲小表會很便捷，也不會因為索引塊而降低存儲效率；10分鐘內的熱數據從kafka直接讀到內存，因為數據本身是通過kafka接口獲取的，另外數據可能有一定的延遲，不適合每秒取數即寫出。

測試后發現，10分鐘內的熱數據，從kafka獲取后再解析json，不但需要消耗大量內存，而且解析json也需要花費很長的時間。這樣在內存中直接加載熱數據是沒辦法用來統計計算的，所以將熱數據改為每10秒存成一個集文件。

接下來開始實現統計計算部分。每天組表中的冷數據計算較快，但是當天的144個集文件計算很慢。通過計算可以知道，每10分鐘的數據量約1.2億條記錄，這個規模的數據可以用組表來存儲，另外還可以再加一層每2小時一個組表文件，來減少當天總文件數的數量（從144個變成了24個）。實際上，計算時采用的二分查找是對單個文件內有序的測點號使用的，減少了文件個數，也就是減少了總查找次數。

最終，我們把數據分成了4層。第一層：延遲10秒的集文件熱數據；第二層，每10分鐘的組表冷數據；第三層，每2小時的組表冷數據；第四層，每天的組表冷數據。由于每層數據都按測點號、時間有序，所以每一層都可以用歸并，快速生成下一層數據文件。

這時的冷數據計算已經很快了，可以滿足實際使用，但是熱數據的計算相比冷數據還是很慢。觀察發現，熱數據的所有集文件都加起來大約3G，不算很大，內存可以裝下。實際測試，把文件讀到內存中再查找相比直接外存文件查找可以快出好幾倍。

已知的統計計算，分為最大值、最小值、中位數、方差、平均值等，不盡相同，但是之前的數據查找是一樣的。都用二分法，找出對應測點號組的數據，再用時間過濾，即可得到相應的value值。

實測效果
經過幾天時間的SPL編碼、測試，優化的效果非常明顯。優化之后的測試結果如下（耗時為毫秒）：

說明：測試環境使用的機械硬盤，對并發計算不友好，更換為固態硬盤后，測試結果還會有較大的提升。

后記

解決性能優化難題，最重要的是設計出高性能的計算方案，有效降低計算復雜度，最終把速度提上去。因此，一方面要充分理解計算和數據的特征，另一方面也要熟知常見的高性能算法和存儲方案，才能因地制宜地設計出合理的優化方案。本次工作中用到的基本高性能算法和存儲方案，都可以從下面這門課程中找到：點擊這里學習性能優化課程，有興趣的同學可以參考。

傳統數據庫的功能比較單一，只能解決一個環節的問題，比如內存數據庫解決熱數據問題，大數據平臺解決冷數據。而當前問題需要多種技術組合，如果運用多種產品混合實現，又會帶來架構的復雜性，增加系統的風險。而且業界中的大數據庫產品的架構也較為死板，對存儲層基本不提供可編程能力，很難基于這些產品實現某些特殊設計的方案。

相比之下，集算器則擁有開放的技術架構和強大的編程能力（SPL語言），可以被深度控制，從而實現各種因地制宜設計的方案。

SPL資料

• SPL下載
• SPL源代碼
  歡迎關注我的公告號：字母哥雜談，回復003贈送作者專欄《docker修煉之道》的PDF版本，30余篇精品docker文章。字母哥博客：zimug.com