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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先是對Chunk信息進(jìn)行細(xì)粒度的時間切片，如圖的TimeSeriesmeta；

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

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

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

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

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

假設(shè)我們要查詢 時間區(qū)間在(20,80)的設(shè)備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的索引結(jié)構(gòu)，并輔助bloom filter等加速機(jī)制，查詢性能還是非常棒的！??！

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，還有更多的應(yīng)用案例在進(jìn)行中。。。

作者介紹

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