大家好，很開心在今天的峰會和大家一起分享ApacheIoTDB 的核心技術剖析的內(nèi)容。

首先，還是簡單的自我介紹一下，我是孫金城，花名 金竹，來自阿里巴巴，從2016年開始一直投入在開源建設中，目前是ApacheFlinkPMC成員，ApacheBeamCommitter和ApacheIoTDB的PMC成員。同時也是Apache 軟件基金會的成員，ApacheMember。

那么，今天我們會有4個部分的內(nèi)容，首先是和大家一起聊聊IoT領域的發(fā)展趨勢。

目前5G正當時，馬老師也曾說過，5G催化了IoT的發(fā)展，80%的5G利好會體現(xiàn)在物聯(lián)網(wǎng)領域。那么，這并不是一個預言而是一個現(xiàn)實，目前中國和美國工業(yè)互聯(lián)網(wǎng)，以及德國的工業(yè)4.0都在蓬勃發(fā)展中。

?

其實，早在2018年Gartner就評估出云向邊緣計算挺進是十大戰(zhàn)略技術趨勢，在2019年和2020年也連續(xù)強調(diào)賦權和賦能邊緣，云邊端一體成為IoT領域的典型架構。

同時，國務院在2017年就發(fā)布了工業(yè)互聯(lián)網(wǎng)的指導意見，并給出階段性的基建目標。

從數(shù)據(jù)庫領域的權威排名情況看，時序數(shù)據(jù)數(shù)據(jù)庫從2018年開始，熱度不斷攀升，同時涌現(xiàn)出很多優(yōu)秀的時序數(shù)據(jù)庫產(chǎn)品，比如Influxdb，opentsdb以ApacheIoTDB。

目前時序數(shù)據(jù)庫有30多個，從架構的角度又可以分為三大類

第一類，以TimescaleDB為代表基于關系的時序數(shù)據(jù)庫

第二類，以OpenTSDB為代表的基于KV的時序數(shù)據(jù)庫

第三類，專門為時序數(shù)據(jù)數(shù)據(jù)而生的 InfluxDB和AapacheIoTDB。

那么這三類數(shù)據(jù)庫有怎樣的特點呢？

基于關系的時序數(shù)據(jù)庫是建立在B+tree的數(shù)據(jù)結構之上的，在寫入上有先天的局限。基于KV的時序數(shù)據(jù)庫在索引的建立上存儲弊端，導致查詢能力受限。那么基于LSMTree的InfluxDB和IoTDB在架構上都解決了高吞吐寫入問題，同時IoTDB官方也給出了一些性能測試數(shù)據(jù)。我們看到IoTDB不論是寫入還是查詢都有很大的優(yōu)勢。那么這些造就這些優(yōu)勢的本質(zhì)是什么呢？就是我們今天要與大家分享的核心內(nèi)容。

那么我們一起來看看IoTDB的核心技術點，這一部分可能會有點復雜，需要大家集中精力我們一起討論。

技術都是以解決實際問題為根本的，首先我們要看看IoT時序數(shù)據(jù)的領域問題有哪些。

時序數(shù)據(jù)的來源有多種，交通設施，智能樓宇，以及工況指標數(shù)據(jù)等。尤其在領域數(shù)據(jù)規(guī)模是一個不容忽視的現(xiàn)實問題，比如金風發(fā)電案例，2w個風機，每個風機500個測點，以50Hz的頻率進行采集，數(shù)據(jù)量達到了5億/秒的吞吐需求。

所以IoT領域的時序數(shù)據(jù)存儲計算涉及到了 存儲成本/寫入吞吐/查詢性能 三個非常重要的領域問題。

同時還有一個客觀存在的問題就是亂序問題，這個是青海大數(shù)據(jù)平臺在2018年真實數(shù)據(jù)情況，IoT工業(yè)領域的時序數(shù)據(jù)亂序是一種常態(tài)。

好，面對上面的問題IoTDB基于LSMtree的架構進行設計，LSM樹的核心思想就是放棄部分讀能力，換取寫入能力的最大化。核心思路其實非常簡單，就是假定內(nèi)存足夠大，因此不需要每次有數(shù)據(jù)更新就必須將數(shù)據(jù)寫入到磁盤中，而可以先將最新的數(shù)據(jù)駐留在內(nèi)存中，等到積累到一定程度后，再使用歸并排序的方式將內(nèi)存中的數(shù)據(jù)合并追加到磁盤隊尾。我們來看一下這個基于LSM Tree的寫入過程：

一個數(shù)據(jù)寫入到來之后，先進行WAL的落盤。寫WAL是為了恢復，真正的有序?qū)懭胍獙?shù)據(jù)寫入內(nèi)存，也就是Mem-Table，然后對Mem-Table進行排序，數(shù)據(jù)寫入到內(nèi)存之后，就表示寫入成功了。

那么寫到內(nèi)存之后會怎樣操作呢？就是要解決落盤問題。當內(nèi)存數(shù)據(jù)到達一定規(guī)模，就需要寫入磁盤，LSM Tree的做法是將要刷磁盤的Mem-Table變成immutable，刷磁盤同時不影響寫入請求，在創(chuàng)建一個新的Mem-table。同時我們對持久化的數(shù)據(jù)進行合并和索引的建立。

那么查詢邏輯是怎么樣的呢？查詢邏輯最核心的是要查詢索引,首先在內(nèi)存Mem-table里面查詢，然后在immutable Mem-table里面進行查找，然后是磁盤Flie里面進行查找。當然這里有Bloom filter輔助查詢。Bloom filter本質(zhì)就是一個bitmap，每個key數(shù)據(jù)用k個獨立的hash就行計算，填充bitmap，數(shù)據(jù)查詢時候Bloomfilter說沒有一定沒有，Bloomfilter說有，不一定有，還要繼續(xù)索引查找。

那么，IoTDB架構設計是對LSM的優(yōu)化加強，針對IoT時序數(shù)據(jù)亂序問題進行了重點設計考慮，從內(nèi)存到文件存儲都有有序和亂序數(shù)據(jù)的特殊處理，更大程度的解決亂序問題。同時IoTDB具有查詢優(yōu)化機制，可以為用戶提供極致的查詢性能。這些從宏觀的角度我們可以感知IoTDB的優(yōu)秀，但是具體細節(jié)上有怎樣的設計考慮呢，我們接下來看細節(jié)。

IoTDB本質(zhì)是一個數(shù)據(jù)庫，是一個存儲系統(tǒng)，那么最終數(shù)據(jù)是以文件的方式進行存儲管理，IoTDB設計了自己的TsFile格式，那么怎樣的文件格式設計才能滿足高效的寫入和快速的讀取呢？

首先以實際的查詢需求來反推TsFile的文件格式，通常我們更希望同一個設備的數(shù)據(jù)存儲在一起，并且每一個Measurement信息在磁盤上連續(xù)存儲是最高效的。

所以，在邏輯上IoTDB將一個設備的數(shù)據(jù)抽象為一個ChunkGroup，每個ChunkGroup進行獨立的云數(shù)據(jù)管理。

同時，對每個Measurement數(shù)據(jù)集中存儲到一個Chunk中。

同時，在實際的工業(yè)場景中，我們大多會根據(jù)時間區(qū)間查詢某些工況信息。

所以我們也需要針對時間區(qū)間進行抽象，IoTDB里面將chunk數(shù)據(jù)按時間區(qū)間再劃分為若干的Page信息。

那么，這樣的數(shù)據(jù)結構抽象，本質(zhì)上是在最終達到怎樣的目的呢？

那就是充分利用邊緣端有限的內(nèi)存資源，最大程度的減少磁盤的IO。我們以最優(yōu)的方式構建索引樹。

那么，索引樹的節(jié)點信息保存那一層的數(shù)據(jù)抽象信息比較合適呢？是保存pange信息？還是chunk信息，還是全部信息，在有限的資源情況下，如何取舍？

那么這個取舍的原則就是，在內(nèi)存大小一定的情況下，內(nèi)存中的索引信息越完整越好。根本目的是為了減少磁盤IO。

既然page是細粒度的數(shù)據(jù)塊，那么是否可以將所有page的元信息進行索引樹構建呢？

其實通過剛才的風機案例，我們會發(fā)現(xiàn)工業(yè)場景7*24小時的不間斷數(shù)據(jù)采集，每秒5億的數(shù)據(jù)點，會形成海量的page，將page作為索引樹節(jié)點信息，構建的樹將將是一個巨大的樹，即便是將所有chunk信息都加載到內(nèi)存也是一個巨大的挑戰(zhàn)。

那么最初，我們是利用了Device和Measurement的粒度進行索引信息的構建的。也就是我們針對ChunkGroup和Chunk進行Meta信息的構建。

這是IoTDB0.8版本TsFile的完整結構，其中包括了data和tsFile的Meta信息/Device的Metat信息/Chunk的Meta信息。查詢一個設備工況信息時候?qū)ξ募淖x取過程是這樣的：

第一，讀取4個字節(jié)的MetaSize，

第二，根據(jù)Meta的內(nèi)容，進行二分查找，設備信息，比如d信息。

第三，根據(jù)Device的MetadataIndex的offset定位到Device的Meta數(shù)據(jù)。

第四，讀取當前設備下所有的ChunkMeta信息到內(nèi)存。

那么，這里在實際的生產(chǎn)過程中我遇到了一個設備有幾十萬的工況數(shù)據(jù)采集，加載與當前查詢無關的Chunk信息也是一種極大的性能消耗。那么如何解決呢？

未來解決上面的問題，提供極致的查詢性能，我們需要優(yōu)化Meta信息的利用，在0.10版本我們根據(jù)設備和工況信息構建一顆B+Tree。假設一個設備有150個Measurement采集，我們從0.8到0.10進行了meta信息優(yōu)化。

首先是對Chunk信息進行細粒度的時間切片，如圖的TimeSeriesmeta；

更重要的是，我們對 Measurement進行了更高一層的邏輯抽象，LEAF_MEASUREMENT節(jié)點，這樣我們就可以構建一顆索引樹。

這樣的索引樹，當我們查詢某個設備的某個Measurement信息時候，比如查詢s0,那么優(yōu)化后的索引結構，我們不需要將設備下的所有的Measurement的Meta信息全部讀取，我們只需要讀取s0-s9的數(shù)據(jù)就可以了。那么，這里內(nèi)容的理解需要有一點磁盤數(shù)據(jù)塊管理和讀取的知識背景，磁盤數(shù)據(jù)塊管理和B+Tree的數(shù)據(jù)結構性感內(nèi)容大家可以掃描二維碼，查看更細節(jié)的內(nèi)容剖析。

如果大家理解剛才對Measurement的中間層抽象優(yōu)化的話，那么相信大家同樣會秒懂，對于設備很多的情況下，也可以對設備的Meta信息進行一層INTERNAL_DEVICE節(jié)點抽象的原因了。

這樣IoTDBv0.10對DEVICE和MESUREMENT進行了中間節(jié)點優(yōu)化抽象，進而優(yōu)化內(nèi)存的利用/數(shù)據(jù)的解析和降低磁盤IO的成本，極大的提高查詢性能。

這個就是v0.10版本中完整的TsFile的數(shù)據(jù)結構。我們以一個具體的查詢來完整的梳理一下查詢邏輯：

假設我們要查詢 時間區(qū)間在(20,80)的設備d1的s1的采集點信息：SELECT sensor_1 FROM root.device_1 WHERE time > 20 and time < 80

• 讀取TsFile的MetaDataSize信息
• 根據(jù)MetaDataSize和offset獲取MetaData的位置
• 根據(jù)TsFile的MetaData獲取IndexNodes的Offset信息我們要查詢device_1的信息，根據(jù)device的offset信息2535讀取MetadataIndexNodes的data內(nèi)容
• 我們要查詢sensor_1的信息，根據(jù)sensor_1的offset信息2175讀取TimeseriesMetadata信息
• 我們要查詢時間區(qū)間是（20，80）的信息，根據(jù)offset1487，讀取Chunk信息
• 根據(jù)ChunkHeader的offset12讀取ChunkHeader內(nèi)容

最后順序讀取Chunk里面的PageHeader，如果Page的時間區(qū)間在（20，80），那么就來讀取PageData

雖然查找的步驟很多，但是內(nèi)部是B+Tree的索引結構，并輔助bloom filter等加速機制，查詢性能還是非常棒的！！！

那么其實IoTDB整體還是非常復雜的，內(nèi)部細節(jié)很多，上面我們介紹的是Meta設計和讀取過程細節(jié)，對于IoTDB在寫上的設計也是很巧妙的，也有很多的細節(jié)需要和大家進行介紹。

會涉及到ChunkGourp/chunk/等部分的細致考慮，今天我們不進行展開，后續(xù)我會在公眾中為大家細致剖析。

從細節(jié)跳出來我們在宏觀上了解IoTDB的話，我們會發(fā)現(xiàn)IoTDB不僅在數(shù)據(jù)的讀寫上有優(yōu)勢，而且還對工業(yè)標準進行了集成，也更加注重和大數(shù)據(jù)生態(tài)的集成。非常適合企業(yè)構建云邊端一體的存儲計算體系平臺。

好的，下面我們快速了解一下IoTDB的現(xiàn)狀和未來規(guī)劃。

IoTDB已經(jīng)在2020年的9月份得到了最權威的開源社區(qū)的認可，成為了Apache 頂級項目。Apache 開源社區(qū)對項目的畢業(yè)控制非常嚴格，IoTDB成為頂級項目足以證明其優(yōu)秀和潛力。

剛才我們也提到，ApacheIoTDB 非常注重工業(yè)領域標準集成，與Apache 頂級項目PLC4X有很好的生態(tài)集成和線下互動。

得到了多方的認可，包括工信部的認可和業(yè)界肯定，在2020年度也成為了開源中國，年度最受歡迎的開源項目。

關于未來的規(guī)劃，圖中棕色部分是已經(jīng)具備的功能，橙色部分是目前社區(qū)重點規(guī)劃的部分。那么更多的功能規(guī)劃和開發(fā)也歡迎在做的各位進行積極參與。J

好，接下來我們快速看一下IoTDB的現(xiàn)有投產(chǎn)應用案例。

那么目前IoTDB已經(jīng)投產(chǎn)與各種工業(yè)領域，包括風電行業(yè)，工程機械，氣象大數(shù)據(jù)平臺和城市軌道等項目中，其中在中車青島四方車輛的合作項目中，一臺IoTDB實例替換了老系統(tǒng)的10多條Cassandra實例。每天管理4000億的數(shù)據(jù)點信息。

同時，IoTDB在德國和美國也有推廣和應用，如圖是IoTDB在德國的行業(yè)應用。

當然，還有更多的應用案例在進行中。。。

作者介紹

孫金城，51CTO社區(qū)編輯，Apache Flink PMC 成員，Apache Beam Committer，Apache IoTDB PMC 成員，ALC Beijing 成員，Apache ShenYu 導師，Apache 軟件基金會成員。關注技術領域流計算和時序數(shù)據(jù)存儲。