徐化巖 初彥龍

1(冶金自動化研究設計院混合流程工業(yè)自動化系統(tǒng)及裝備技術國家重點實驗室 北京 100071)2(遼寧警察學院治安管理系 遼寧 大連 116036)

0 引 言

時序數(shù)據(jù)即時間序列數(shù)據(jù)，指按照時間先后順序變化、帶時間標簽的數(shù)據(jù)。時序數(shù)據(jù)主要由電力、化工、冶金等各類型實時監(jiān)測、檢查與分析設備所采集、產生的數(shù)據(jù)，這些數(shù)據(jù)的典型特點是：(1) 采樣頻率快，每秒甚至幾十毫秒采樣一次；(2) 測點多信息量大，一個千萬噸級鋼鐵聯(lián)合企業(yè)共有約50萬個在線監(jiān)測點，如果每秒采集后不壓縮存儲，一天需要800 GB存儲空間；(3) 數(shù)據(jù)按照時間順序產生，一經產生不再變化；(4) 一次讀取的數(shù)據(jù)量大，繪制一條24小時秒級曲線需要讀取86 400條數(shù)據(jù)；(5) 沒有關系數(shù)據(jù)的并發(fā)寫入/更改情況，沒有讀寫共享沖突問題；(6) 單點數(shù)據(jù)價值小，對數(shù)據(jù)一致性要求沒有業(yè)務數(shù)據(jù)嚴格。

目前，工業(yè)領域普遍的做法是使用商業(yè)實時數(shù)據(jù)庫軟件，如OSIsoft PI、Wonderware Insql、GE IHistorian等，作為時序數(shù)據(jù)庫的存儲和讀取工具。隨著大數(shù)據(jù)技術的發(fā)展，近年來也有一些基于HBase、MongoDB[1]等大數(shù)據(jù)平臺的研究。

2013年，Errplane公司將influxDB[2]開源，經過不斷改進現(xiàn)已在開源時序數(shù)據(jù)庫中排名第一[3]。influxDB參考O’Neil P等[4]提出應用于BigTable[5]的日志結構合并樹(Log Structured Merge Tree，LSM)，提出了時間結構合并樹(Time Structured Merge Tree，TSM)，針對時序數(shù)據(jù)的讀寫分別進行了優(yōu)化設計。在寫入時，將數(shù)據(jù)追加寫入到日志文件(Write Ahead Log，WAL)中，并在內存中進行緩存，當內存緩存達到一定大小時創(chuàng)建新的日志文件，并啟動壓縮線程，將數(shù)據(jù)按照讀取優(yōu)化的方式壓縮成TSM數(shù)據(jù)文件。根據(jù)官方提供的數(shù)據(jù)[2]，influxDB與其他幾個時序數(shù)據(jù)庫的性能比較如表1所示。

表1 開源時序數(shù)據(jù)庫性能對比表

influxDB起源于對服務器運行情況進行監(jiān)控這一特定領域，設計了較為復雜的元數(shù)據(jù)模型以便能夠保存除測點、時間、取值之外的附加屬性信息。數(shù)據(jù)存儲時的鍵為含有測點名、屬性類型、取值類型的字符串，不僅占用空間多，而且索引時需要根據(jù)字符串長度計算數(shù)據(jù)位置，增加了檢索計算量，這一復雜設計對于工業(yè)時序數(shù)據(jù)而言是多余的。本文參考influxDB的引擎代碼，改進了TSM文件結構，實現(xiàn)了工業(yè)時序數(shù)據(jù)庫引擎，并進行了性能測試。

1 時序數(shù)據(jù)庫引擎結構

引擎自頂而下包括數(shù)據(jù)庫實例、存儲策略、存儲分片幾個層次，如圖1所示。每個數(shù)據(jù)庫實例包含一個或更多存儲策略，用于定義存儲時長，存儲策略包含多個存儲分片，每個存儲分片負責一段時間的數(shù)據(jù)，超過時長的過期數(shù)據(jù)會以存儲分片為單位進行整體刪除，以提高刪除效率。每個存儲分片里包含一個內存緩存區(qū)、一個或更多日志文件、多個數(shù)據(jù)文件，以及用于處理寫入、壓縮、讀取的線程。

圖1 時序數(shù)據(jù)庫引擎結構示意圖

在寫入時，系統(tǒng)根據(jù)數(shù)據(jù)點所屬數(shù)據(jù)庫實例名找到數(shù)據(jù)庫實例，由數(shù)據(jù)庫實例找到數(shù)據(jù)點所屬數(shù)據(jù)存儲策略，然后由存儲策略根據(jù)數(shù)據(jù)的時間范圍找到命中的存儲片區(qū)，如果片區(qū)不存在則創(chuàng)建片區(qū)，并將數(shù)據(jù)分發(fā)給片區(qū)執(zhí)行寫入。存儲片區(qū)負責將數(shù)據(jù)同時寫入到內存緩存與日志文件中，日志文件定時壓縮為數(shù)據(jù)文件，數(shù)據(jù)文件再逐步壓縮為更大的數(shù)據(jù)文件，直到數(shù)據(jù)文件大小達到上限不再壓縮。寫入流程如圖2所示。

圖2 數(shù)據(jù)寫入及文件壓縮流程圖

在讀取時，系統(tǒng)首先找到所有命中的存儲片區(qū)，由片區(qū)判斷是從其內存緩存中讀取還是從其數(shù)據(jù)文件中讀取。如果是從數(shù)據(jù)文件中讀取，利用文件中的索引快速定位數(shù)據(jù)位置，讀取后由系統(tǒng)將所有命中片區(qū)返回的結果按照時間先后順序合并，返回最終查詢結果。讀取流程如圖3所示。

圖3 數(shù)據(jù)讀取流程圖

2 TSM文件結構設計

TSM采用內存緩存和WAL日志文件來保證高效寫入，內存緩存目的是代替日志文件提供對臨近數(shù)據(jù)的高效讀取，日志文件的目的是在數(shù)據(jù)庫重啟后能夠重建內存緩存，日志文件不用于讀取數(shù)據(jù)。由于磁盤的順序寫入速度快而隨機寫入速度慢(尋道和旋轉延遲)，而時序數(shù)據(jù)的特點是大量數(shù)據(jù)實時采集、實時寫入，為了提高寫入效率將一批數(shù)據(jù)(一般為5 000到10 000點)按照數(shù)據(jù)類型、點位編號、點數(shù)、時間、值、時間、值、…、數(shù)據(jù)類型等順序編碼為字節(jié)流，如圖4所示，再利用snappy算法[6]壓縮后寫入WAL日志文件。同時，將寫入日志文件的數(shù)據(jù)以點位編號、時間、值的結構存入內存緩存區(qū)，內存緩存區(qū)與日志文件保持同步。日志文件大小固定，當達到規(guī)定大小時自動生成一個新的日志文件。

圖4 WAL日志文件結構圖

TSM數(shù)據(jù)文件中包含5字節(jié)文件頭、多個數(shù)據(jù)塊、一個索引塊和8字節(jié)文件尾，如圖5所示。文件頭存放數(shù)據(jù)庫引擎的幻數(shù)和版本號；數(shù)據(jù)塊區(qū)由若干組4字節(jié)校驗和與N字節(jié)數(shù)據(jù)塊組成；校驗和是數(shù)據(jù)塊的32位循環(huán)冗余校驗碼；數(shù)據(jù)塊為數(shù)據(jù)點的一組按時間排序后的數(shù)據(jù)經過壓縮后得到的字節(jié)數(shù)組；索引塊由點位編號、數(shù)據(jù)類型、數(shù)據(jù)塊數(shù)量、數(shù)據(jù)塊索引1、數(shù)據(jù)塊索引2等構成，每個數(shù)據(jù)塊索引包含數(shù)據(jù)塊起始時間、數(shù)據(jù)塊結束時間、數(shù)據(jù)塊在文件中的起始位置、數(shù)據(jù)塊字節(jié)數(shù)構成；文件尾8字節(jié)用于保存索引塊在TSM數(shù)據(jù)文件中的起始字節(jié)位置。

圖5 TSM數(shù)據(jù)文件結構圖

3 數(shù)據(jù)的無損壓縮方法

時序數(shù)據(jù)包含點名、時間和數(shù)值信息，寫入一組時序數(shù)據(jù)時，如圖6所示，壓縮器遍歷每個點，判斷數(shù)值的數(shù)據(jù)類型是整數(shù)、浮點數(shù)、布爾值還是字符串，分別調用相應的壓縮方法進行壓縮，時間類型調用時間壓縮方法壓縮，將兩者壓縮得到的字節(jié)數(shù)組合并后寫入到數(shù)據(jù)文件中。整數(shù)、浮點數(shù)、布爾、字符串、時間五種數(shù)據(jù)類型的壓縮算法如下所述。

圖6 數(shù)據(jù)壓縮流程圖

整數(shù)的壓縮方法為：第一個整數(shù)不壓縮，從第二個整數(shù)開始計算與前一個數(shù)的差值，并對差值通過ZigZag編碼[7]將差值為負數(shù)的變?yōu)檎龜?shù)，然后分三種情況進行壓縮：(1) 如果連續(xù)兩個以上差值相等，則只存儲差值及差值出現(xiàn)的次數(shù)；(2) 如果差值超過十六進制數(shù)值0x0800000000000000，不壓縮；(3) 否則，將差值采用simple8b算法[8]進行壓縮。

浮點數(shù)的壓縮方法[9]為：第一個浮點數(shù)不壓縮，從第二個浮點數(shù)開始與前一個數(shù)進行異或計算，得到一個64位無符號整數(shù)作為差值，當兩個浮點數(shù)數(shù)值接近時得到的差值很小。當差值為0時僅存1位0；不為零時存1位1，然后用5位存儲64位中位于左端的0的數(shù)量，用6位存儲居右端的0的數(shù)量，再將非零位截取出來存儲。

布爾值的壓縮方法為：直接將布爾值用1位存儲到字節(jié)末尾(每個字節(jié)有8位)，當存滿1個字節(jié)后分配一個新字節(jié)。

字符串的壓縮方法為：將字符串順序添加到字節(jié)流后用snappy算法[6]壓縮。

時間類型的壓縮方法為：第一個時間不壓縮，從第二個時間開始與前一個時間進行差值計算。第一個差值不壓縮，然后從第二個差值開始計算與前一個差值的差值。如果差值的差值為0(當數(shù)據(jù)的存儲間隔相同時)，僅存儲0和0出現(xiàn)的次數(shù)；否則采用simple8b算法[8]存儲該差值的差值。

4 讀寫性能測試

influxDB開源代碼[10]采用GO語言實現(xiàn)，本文將引擎部分用.net framework 4.5重新實現(xiàn)，通過隨機數(shù)發(fā)生器每秒生成50 000點整型隨機數(shù)，進行了性能測試。測試硬件設備為一臺ThinkPad T550筆記本電腦，CPU：i5 5200U 2.2 G雙核，內存：8 GB，硬盤：256 GB固態(tài)硬盤。

寫入測試是每秒隨機發(fā)生5萬點整型數(shù)據(jù)，重復3 600次寫入，寫入平均耗時310毫秒。讀取性能測試進行了兩組，一組測試從1條/點到200條/點，分200次讀取5萬點的數(shù)據(jù)，讀取的數(shù)據(jù)條目數(shù)從5萬條到1 000萬條，如圖7所示，讀取耗時從2.8秒到9.2秒，隨著條數(shù)增加耗時呈線性增長趨勢；另一組測試分50次固定讀取100萬條數(shù)據(jù)，點數(shù)從1 000開始以1 000點步長一直增長到5萬點，得到的曲線如圖8所示，隨著點數(shù)增加，用時從0.6秒到3.3秒呈線性增長趨勢。

根據(jù)測試結果，引擎能夠實現(xiàn)單實例每秒5萬點的數(shù)據(jù)寫入，讀取相同記錄數(shù)的情況下，點數(shù)越少速度越快，這主要是在TSM文件中，一段時間內相同點的數(shù)據(jù)是按時間順序連續(xù)存儲的，而不同點的數(shù)據(jù)是間隔存儲的，因此點數(shù)越多文件位置的計算越多?？紤]到工業(yè)時序數(shù)據(jù)庫應用以單點歷史曲線讀取為主，TSM文件結構有利于提高讀性能。

引擎的時間消耗中，用于集合運算和比較約占1/3，五種數(shù)據(jù)類型的壓縮和解壓縮約占2/3。由于.net framework相較.net core集合運算性能差距較大，加上浮點數(shù)、整數(shù)壓縮算法性能還有提升空間，引擎通過.net core重新編譯并采用性能更高的壓縮算法后，讀寫性能會有較大提升。

圖7 5萬點數(shù)據(jù)讀取速度曲線

圖8 100萬條數(shù)據(jù)讀取速度曲線

5 結 語

本文按照工業(yè)時序數(shù)據(jù)的特點，參考influxDB思想設計了工業(yè)時序數(shù)據(jù)庫的引擎。引擎自頂而下包括數(shù)據(jù)庫實例、存儲策略、存儲分片幾個層次，每個存儲分片里包含一個內存緩存區(qū)、一個或更多日志文件、多個數(shù)據(jù)文件，以及用于處理寫入、壓縮、讀取的線程。本文簡化了TSM文件結構，數(shù)據(jù)點位關鍵字由influxDB的字符型改為整型，降低了存儲占用和索引計算量。最后，進行了引擎的開發(fā)和性能測試。

未來，還需要做三個方面的改進：一是利用.net core重新編譯提高性能；二是壓縮解壓縮部分替換為性能更高的算法庫；三是增加分布式冗余機制，以便實現(xiàn)更大規(guī)模的數(shù)據(jù)吞吐量，并提高數(shù)據(jù)容錯能力。