引 言
“乾道變化，各正性命”，很多情況下，事物的價值和內涵往往存在於變化中，人們對於事物的變化規律的探究也一直沒有停歇。從遠古時期人們記錄天象變化、總結四季更替、到現代人們記錄設備運行狀態、個人活動記錄、股票變化情況等等，記錄這些觀測對象的變化情況，並加以分析的需求，自古至今一直存在。這種需求伴隨著物聯網、工業互聯網、智能運維等應用的蓬勃發展變得愈發重要。
物聯網誕生於1999年，在其理念和技術的不斷革新下，無處不在的設備和設施正在被越來越多的通過網絡連接起來，並不斷向雲端發送實況數據。
近些年，工業4.0和工業互聯網成為發展焦點。在這次工業革命中，工業生產和運維過程中機械設備產生的數據成為了新的核心資產。
隨著Devops的興起，運維人員開始追求對IT基礎設施、各種服務的運行情況瞭如指掌的境界，從而開始大量採集對這些設施、進程、用戶的監控數據。
上述這些場景中產生的數據，主要都是用來描述一個對象在時間維度上的變化的數據，這類數據就被稱為時間序列數據。
時間序列數據其實離我們很近。例如，用蘋果手機可以看到手機的電量變化情況，谷歌地圖的“時間線”功能（用於記錄個人的位置服務）記錄的個人位置移動，安裝了健康應用的每小時步數統計，佩戴的智能手錶檢測的心率變化都是時序數據；家裡安裝的溫溼度傳感器採集到的家裡的溫溼度變化，空氣淨化器採集的PM2.5變化，智能插線板顯示的用電功率變化，都是時序數據；每天使用的各種網站服務記錄的個人行為信息也是時序（文本）數據。
時間序列數據也可能離我們更遠，但時刻影響著我們的衣食住行。機房的每臺服務器的CPU、內存、網絡帶寬佔用情況的實時變化，氣象觀測站觀測的每刻氣象情況變化，汽車、飛機行駛過程中採集的位置、速度、油耗等各種指標值，發電廠、光纖製造塔裡的惰性氣體含量變化都是時序數據。可見，時序數據無處不在。
時序數據的定義
研究時序數據的人很多。美國國家標準化委員會NIST將時序數據定義為一系列等時間間隔到達的某個變量的值。TKDE上對時序數據的定義則放鬆了等時間間隔的約束：一系列時間戳遞增的數據點。事實上，通過研究實際場景，我們可以得到更確切的時間序列數據的定義。
以國家級氣象觀測站為例，全國有近6萬個氣象觀測站，每個氣象觀測站有70種氣象物理量需要採集。某市地鐵每列列車擁有3200個指標需要測量，全市列車數達300列。服務器運維監控中，一臺服務器需要同時監測IOPS、CPU、網絡等十餘項指標，而服務器中的重要進程還需要監測CPU佔用率、存活時間等指標。這些例子中展現出兩個概念：設備與度量指標。所謂度量指標（又被稱為工況、測點）是指用戶關心的能反映目標的某種狀況的數據項，例如CPU利用率、溫度、溼度等等。設備是指一個擁有一系列度量指標的實體，例如一臺服務器、一個進程、一列車、一個氣象觀測站等等。一個設備的一個度量指標形成了一條時序數據的唯一標識。隨著時間推移，這條時序數據會產生一系列（時間戳，值）的二元組數據點，構成了時間序列數據集。因此，我們定義一條時間序列是由一個時間序列標識（設備和度量指標），一系列時間戳和數據值對組成的無限集。一個時間序列數據庫將管理百萬甚至千萬條這樣的時間序列。
如圖所示，在對汽車的狀態監控中，汽車可以作為設備（國家、地區、車牌號組成了設備ID），而剩餘油量、車速則是兩個度量指標。因此該圖中有4條時間序列（2個設備，2種度量指標），其中3個序列有2個點，一個序列沒有數據。
時序數據的管理需求
工業中的時間序列數據具有超高通量的特點。由於工業設備的數量可能非常龐大，同時每一個設備上都會有著上百種傳感器同時採集數據，並且這些設備很多都是 7*24 小時不間斷地運行，因此其採集的時間序列數據是源源不斷的。以我國某企業製造的風機組管理為例。當前其擁有近3萬颱風機，其中 多數風機可以採集時序數據並向數據中心回傳。以每個風機上約 100 種測點(傳感器)為例，總時間序列數量可達數百萬條。以其 SCADA 系統中的 7 秒時間間隔採集數據 為例，一天將產生 271.5 億個數據點。又以某市地鐵應用為例，單列車擁有 3200 個測點，當前採集頻率為 500 毫秒/次，共有 180 列車，其每秒的吞吐量達 118 萬點每秒。未來的採集間隔將縮短至 200 毫秒，列車數量將增至 300 列，則每秒吞吐量將達 492 萬點每秒。可見，必須首先解決數據的存儲效率問題，才能有效管理工業場景中的時序數據，從而進一步利用其價值。更甚至，由於這些數據是昂貴的設備在真實生產環境中產生的，其數據價值遠高於模擬仿真數據，隨意刪除這些數據將給日後的數據分析帶來巨大的損失，因此全時全量的存儲是必需的。
在此基礎上，工業中的時間序列數據還具有低質亂序傳輸的特點。在一些實 際應用場景中，時間序列數據存在亂序的問題。例如:在物聯網與工業傳感網中， 因為基礎設施或者網絡的不穩定，數據的採集和回傳會出現中斷，在這類情況下數據會出現一定範圍的亂序;還有一些比較嚴重的情況，數據在進入存儲系統之前需要經過 kafka等流式處理系統的處理，同一條時間序列數據可能會被 kafka 的多個 partition 消費，從而導致數據在寫入存儲系統的時候出現亂序。此外，由於 PLC 與 DTU 模塊的銜接或網絡等問題，一些數據點會在回傳前或者回傳過程中丟 失，造成數據缺失等質量低下問題。
此外，工業中的時間序列數據具有高質全序查詢的特點。時序數據雖然在寫 入過程中存在亂序現象，但用戶在查詢過程中，大多都是要求按照時間維度順序讀取數據。此外，工業互聯網中設備的每個傳感器會產生一條甚至多條時間序列數據，這些時序數據最有效的存儲方式是採用列式存儲。然而，實際應用中需要對一個設備的多個度量指標數據，或多個設備的數據同時進行分析，這就要求必須將多條列式存儲的時序數據進行連接查詢(即按時間戳對齊查詢)。該查詢的性能對數據分析的效率起到了決定性作用。
時序數據的分割也是面向時間序列數據的一種典型查詢應用。由於某些設備往往是在怠速和帶負荷工作兩種狀態之間頻繁切換，而怠速狀態下的數據也有可能會被持續採集。這時候若將整條時序數據看做一體，則會對平均值、趨勢等分析造成影響，因此將一條時序拆分成若干子序列，是時序數據特有的高級查詢。
最後，工業應用不僅對時間序列數據的管理提出了高要求，還對時間序列數 據的分析效率提出了需求。由於工業時序數據具有體量大的特點，在分析時將數據從 OLTP 型數據庫中經過數據重組織、進而 ETL 到支持 OLAP 的系統或者大數 據計算平臺上是一個費時費力的過程。因此，如何實現系統的查詢分析一體化，也是亟待解決的問題之一。
現在有很多種數據庫可以用於管理時序數據，包括關係數據庫和NoSQL數據庫和時序數據庫，但是他們都存在或多或少的問題。以關係數據庫為例，其 schema是有限制的:比如MySQL InnoDB中單表的列數上限為1017列，PostGreSQL的列數上限是1400多列。然而，一個設備可能擁有上千個測點甚至上萬個測點，一張關係表的列數是不夠的。此外，在關係數據庫中若單表的行數超過千萬量級，性能往往會大幅下滑。因此就需要DBA進行復雜和精細的水平垂直分庫分表。帶來了使用上的不便。此外，關係數據庫的寫入性能也遠遠達不到時序數據的要求。對於以鍵值為代表的NoSQL數據庫而言，其高速的寫入性能在一定程度上解決了關係數據庫的性能問題，靈活的schema也解決了關係數據庫的錶行、列數量的限制，但是其能夠支持的查詢往往沒有關係數據庫豐富。前文提到的時序數據時間維度的查詢、值查詢、多序列聚合、多序列時間對齊等查詢都存在較大的挑戰。TimescaleDB、OpenTSDB、KairosDB等基於關係數據庫或NoSQL數據庫的系統在一定程度上解決了上述的問題，但難以根本上解決，例如TimescaleDB隨著導入時間的增加其導入速度速率會不斷地下降。KairosDB在壓縮、查詢和寫入性能上表現都不夠突出。一些原生的時序數據庫如InfluxDB針對時間序列數據進行了專屬的文件結構優化和專屬查詢優化，然而在一些工業場景下仍然存儲無法存儲全量數據、性能不足的問題。
綜上，我們認為時序數據庫應該具有以下功能。
Apache IoTDB時序數據庫
為了解決以上問題，滿足工業領域時序數據的存儲、查詢特點，清華大學軟件學院從零設計並實現了高效輕量的物聯網時序數據庫 IoTDB。在研發過程中，突破多項核心技術，提出時間序列存儲格式、針對時間序列數據改進的LSM引擎、海量數據範圍的新型聚合索引、設計雙層元數據組的分佈式架構。2018年11月，經國際頂級開源基金會Apache評估和認可，IoTDB成功進入Apache孵化器，成為中國高校目前唯一主導的Apache項目。現已有來自德國、澳大利亞、美國、印度等國外以及阿里、聯想、華為、四維圖新的開發者。
IoTDB具有以下特點：
（1）開放的架構：IoTDB 架構圖如下所示，採用存儲和查詢分離的架構，將底層存儲開放給上層應用，一份數據既支持實時查詢，也支持大數據分析，避免了數據遷移代價。
（2）新型文件存儲格式：底層存儲採用針對時間序列優化的文件格式 TsFile，採用靈活的元數據管理和寫入控制，支持各時間序列獨立寫入，採用時間序列原生的列式存儲與序列編碼、壓縮方式。
（3）高速數據寫入：IoTDB 提供數千萬點每秒的寫入吞吐，同時具有低延遲。支持單節點每秒數千萬點的寫入速度，可處理亂序、重複數據，有效管理萬億數據點。
（4）高效的索引結構：如聚合索引PISA支持高效的聚合查詢、多分辨率數據查詢。KV-index支持複雜的子序列匹配等高級查詢。
（5）與大數據系統充分集成，支持MapReduce、Spark、Grafana、Zeppelin、Flink、RocketMQ、Kafka、Pulsar等。
Committer情況
IoTDB社區的發起人來自於清華大學，由清華大學軟件學院王建民教授立項，黃向東等前後三十餘名博士生、碩士生一直參與其中進行的初期開發。這些開發者們畢業後繼續在清華大學、微軟、頭條等企業仍然保持著對項目的貢獻。
在德國和歐洲地區，在工業4.0的熱潮下，IoTDB社區吸引了Julian等許多歐洲開源人士的關注。目前，在PLC4X、Karaf等社區開源貢獻者的幫助下，IoTDB已經與這些項目進行了集成，並正在與StreamPipes、Prometheus等項目展開集成。
在國內，阿里等大型IT企業對時序數據庫的關注也來越高，IoTDB社區目前與Flink、RocketMQ社區緊密合作，大量這些社區的開發者們同時也是IoTDB社區的貢獻者。
國內的主要工業互聯網企業，如海爾、聯想、東方國信、深信服等，也都紛紛參與到了IoTDB的貢獻中。
背景資料：
木蘭開源社區 （https://mulanos.cn/）是2018年國家重點研發計劃“雲計算和大數據開源社區生態系統”項目重點成果，由中國電子技術標準化研究院牽頭，聯合北京大學、國防科大、聯想、騰訊雲，以及開源中國、北航、中科院軟件所、西南大學、華為、阿里雲、浪潮、新華三、中電標協、中科院東莞育成中心、湖南酷得共16家單位共同承擔。木蘭開源社區立足中國，面向國際，聯合匯聚國內開源生態圈相關方，共同打造國內開源生態，推動本土開源項目孵化，在推動培育開源貢獻文化的同時，與國內外各開源社區融合發展。
閱讀更多 電子標準院 的文章
