該項(xiàng)目來(lái)自于開源軟件供應(yīng)鏈點(diǎn)亮計(jì)劃 - 暑期2021的Apache IoTDB - Apache Skywalking適配器項(xiàng)目。目前已提交至Skywalking社區(qū)（IoTDB storage plugin #7766），正在接受社區(qū)評(píng)審。

實(shí)現(xiàn)思路

項(xiàng)目目標(biāo)是為Skywalking開發(fā)一個(gè)使用IoTDB進(jìn)行相關(guān)數(shù)據(jù)讀寫的適配器。可以參考Skywalking目前已有的采用InfluxDB、H2和Elasticsearch的適配器。Skywalking給出了存儲(chǔ)拓展的開發(fā)指南，參考鏈接。此外，需要使用Skywalking和InfluxDB的調(diào)試過(guò)程，以便充分了解Skywalking的接口和使用方式。

IoTDB建議使用其提供的原生客戶端封裝: Session或Session Pool與IoTDB服務(wù)端進(jìn)行交互。

開發(fā)平臺(tái)：Win10，IoTDB版本：0.12.2

相關(guān)概念

Skywalking的存儲(chǔ)模型

Skywalking 8.0+的存儲(chǔ)模型大致分為4類：Record，Metrics，NoneStream，ManagementData。它們都實(shí)現(xiàn)了StorageData接口。StorageData接口必須實(shí)現(xiàn)id()方法，下面分別介紹4類存儲(chǔ)模型：

• Record：Record大部分是原始日志數(shù)據(jù)或任務(wù)記錄。這些數(shù)據(jù)需要持久化，無(wú)需進(jìn)一步分析。所有Record類的模型均具備time_bucket字段，用于記錄當(dāng)前Record所在的時(shí)間窗口。具體例子有：SegmentRecord，AlarmRecord，BrowserErrorLogs，LogRecord，ProfileTaskLogRecord， ProfileThreadSnapshotRecord，TopN。

  • SegmentRecord：Trace Segment明細(xì)記錄模型。由skywalking-trace-receiver-plugin插件接收并解析Skywalking Agent發(fā)送來(lái)的鏈路數(shù)據(jù)后得到TraceSegment。
  • AlarmRecord：報(bào)警明細(xì)記錄模型。在指標(biāo)觸發(fā)報(bào)警規(guī)則時(shí)，會(huì)產(chǎn)生對(duì)應(yīng)的報(bào)警明細(xì)數(shù)據(jù)模型。
  • TopN：TopN是采樣模型，具備statement字段（用于描述采樣數(shù)據(jù)的關(guān)鍵信息），latency字段（用于記錄采樣數(shù)據(jù)的延遲），
    trace_id字段（用于描述采樣數(shù)據(jù)的關(guān)聯(lián)分布式鏈路ID），service_id字段（用于記錄服務(wù)ID）。目前采樣模型默認(rèn)只有TopNDatabaseStatement。
    • TopNDatabaseStatement：按照延遲排序的DB采樣記錄。

• Metrics：Metrics表示統(tǒng)計(jì)數(shù)據(jù)，是通過(guò)OAL腳本或硬編碼對(duì)源（Source）數(shù)據(jù)進(jìn)行聚合分析后生成的存儲(chǔ)模型。它的生命周期由TTL（生存時(shí)間）控制。所有Metrics類的模型均具備time_bucket和entity_id字段。例如：NetworkAddressAlias，Event，InstanceTraffic，EndpointTraffic， ServiceTraffic，EndpointRelationServerSideMetrics，ServiceInstanceRelationServerSideMetrics， ServiceInstanceRelationClientSideMetrics，ServiceRelationServerSideMetrics，ServiceRelationClientSideMetrics

• NoneStream：NoneStream基于Record，支持time_bucket轉(zhuǎn)換為TTL。例如：ProfileTaskRecord

• ManagementData：UI模板管理相關(guān)的數(shù)據(jù)，默認(rèn)只有一個(gè)UITemplate實(shí)現(xiàn)類

部分參考《Apache Skywalking實(shí)戰(zhàn)》第9章：SkyWalking OAP Server存儲(chǔ)模型

IoTDB的數(shù)據(jù)模型

參考IoTDB官方數(shù)據(jù)模型介紹。簡(jiǎn)單來(lái)說(shuō)，可以用樹結(jié)構(gòu)來(lái)認(rèn)識(shí)IoTDB的數(shù)據(jù)模型。如果按照層級(jí)劃分，從高到低依次為：Storage Group -> (LayerName) -> Device -> Timeseries。從最上層到其下某一層稱為一條路徑（Path），最上層是Storage Group，倒數(shù)第二層是Device，倒數(shù)第一層是Timeseries，中間可以有很多層，每一層姑且稱之為L(zhǎng)ayerName。

值得注意的是，每個(gè)Storage Group需要一個(gè)線程，所以Storage Group過(guò)多會(huì)導(dǎo)致存儲(chǔ)性能下降。此外，LayerName的值存儲(chǔ)在內(nèi)存中，而Timeseries的值及其下的數(shù)據(jù)存儲(chǔ)在硬盤中。

Skywalking的IoTDB-adapter存儲(chǔ)方案

概念劃分

Skywalking的每個(gè)存儲(chǔ)模型可以認(rèn)為是一個(gè)Model，Model中包含了多個(gè)Column，每個(gè)Column中具備ColumnName和ColumnType屬性，分別表示Column的名字和類型，每個(gè)ColumnName下存儲(chǔ)多個(gè)數(shù)據(jù)類型為ColumnType的數(shù)據(jù)Value。從關(guān)系型數(shù)據(jù)庫(kù)的角度來(lái)看的話，Model即是關(guān)系表，Column即是關(guān)系表中的字段。

方案一：類似關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)方案（無(wú)法實(shí)現(xiàn)）

將Skywalking的所有存儲(chǔ)模型都寫入IoTDB的一個(gè)存儲(chǔ)組中，例如root.skywalking存儲(chǔ)組。Model對(duì)應(yīng)Device，Column對(duì)應(yīng)Timeseries。即Skywalking的“Database -> Model -> Column”對(duì)應(yīng)到IoTDB的“Storage Group -> Device -> Timeseries”。該方案的IoTDB存儲(chǔ)路徑只有4層：root.skywalking.ModelName.ColumnName。該方案的優(yōu)點(diǎn)是邏輯清晰，實(shí)現(xiàn)難度較低，但由于數(shù)據(jù)都存儲(chǔ)在硬盤上，查詢效率相對(duì)較差。

驗(yàn)證結(jié)果：該方案無(wú)法實(shí)現(xiàn)
原因：部分存儲(chǔ)接口需要實(shí)現(xiàn)group by entity_id的查詢功能，但I(xiàn)oTDB只支持group by time。需要采用方案二并通過(guò)group by level來(lái)實(shí)現(xiàn)。

方案二：引入索引的存儲(chǔ)方案

由于IoTDB的每個(gè)LayerName存儲(chǔ)于內(nèi)存中，可以將其認(rèn)為是一種索引，可以充分利用LayerName的這個(gè)特性提高IoTDB的查詢性能。

依然將Skywalking的所有存儲(chǔ)模型都寫入IoTDB的一個(gè)存儲(chǔ)組中，例如root.skywalking存儲(chǔ)組。Model對(duì)應(yīng)一個(gè)LayerName，需要索引的Column也對(duì)應(yīng)于LayerName，不過(guò)LayerName并不存儲(chǔ)ColumnName，而是存儲(chǔ)對(duì)應(yīng)的Value，相當(dāng)于需要索引的一個(gè)Column的不同Value存儲(chǔ)在同一分支下的同一層。不需要索引的Column依然對(duì)應(yīng)Timeseries，即路徑的最后一層。最終將導(dǎo)致同一個(gè)Model的數(shù)據(jù)分散到多個(gè)Device中。

由于該方案丟失了需要索引的ColumnName，所以需要通過(guò)硬編碼記錄需要索引的ColumnName及ColumnType。此外為了避免存儲(chǔ)的混亂，還需要保證一個(gè)Model下多個(gè)索引Column的順序。計(jì)劃通過(guò)硬編碼存儲(chǔ)Model需要索引的Column的存儲(chǔ)順序。

該方案的IoTDB存儲(chǔ)路徑長(zhǎng)度是不定的，索引的Column越多，路徑的長(zhǎng)度越長(zhǎng)。例如:

當(dāng)前有model1(column11, column12)，model2(column21, column22, column23)，model3(column31)，下劃線說(shuō)明該字段需要索引。

• 需要具備索引的Model：
  • root.skywalking.model1_name.column11_value.column12_name
  • root.skywalking.model2_name.column21_value.column22_value.column23_name
• 不需要具備索引的Model:
  • root.skywalking.model3_name.column31_Name

插入：

-- 插入model1insert into root.skywalking.model1_name.column11_valuevalues (timestamp, column12_value);-- 插入model2insert into root.skywalking.model2_name.column21_value.column22_valuevalues (timestamp, column23_name);

查詢：

-- 查找model1的所有數(shù)據(jù)select *from root.skywalking.model1_name;-- 查找model2中column22_value="test"的數(shù)據(jù)select *from root.skywalking.model2_name.*.test;-- 按照column21分組統(tǒng)計(jì)model2中column23的和select sum(column23)from root.skywalking.model2_name.*.*group by level = 3;

該方案的優(yōu)點(diǎn)是實(shí)現(xiàn)了索引功能，類似InfluxDB的tag，但邏輯較復(fù)雜，實(shí)現(xiàn)難度較大。另一方面還需進(jìn)一步確定哪些Column需要作為索引列，這一點(diǎn)可以參考Elasticsearch（StorageEsInstaller），InfluxDB（TableMetaInfo），MySQL（MySQLTableInstaller）的實(shí)現(xiàn)，以及ModelColumn的isStorageOnly屬性。

該方案將部分?jǐn)?shù)據(jù)通過(guò)LayerName存儲(chǔ)在內(nèi)存中，在海量數(shù)據(jù)的情況下可能會(huì)導(dǎo)致內(nèi)存開銷較大。此外，由于同一個(gè)Model的數(shù)據(jù)被分散到了多個(gè)Device中，所以查詢往往需要跨多個(gè)Device進(jìn)行查詢。但在這一方面，IoTDB對(duì)于跨Device的聚合查詢、排序查詢、分頁(yè)查詢的支持還不夠完善，在一些情況下需要使用暴力法將所有符合條件的數(shù)據(jù)都查出來(lái)，然后再自行實(shí)現(xiàn)聚合、排序、分頁(yè)的功能。具體描述可參考下文在IoTDB社區(qū)提交的Issue和Discussion。

• Issue:
  • Hope select function, “top_k” and “bottom_k”, could support “group by level” #3905
  • Hope fuzzy query could support multi-device #3945
  • “group by level” cannot get the node name #4006
• Discussion:
  • 一個(gè)有關(guān)排序查詢的問(wèn)題（A problem about sort query）#3888
  • 一個(gè)有關(guān)聚合查詢的問(wèn)題（A problem about aggregation query）#3907

已確定采用索引的字段

id
entity_id
node_type
service_group
service_id
trace_id

此外，可以將time_bucket轉(zhuǎn)換為IoTDB自帶的時(shí)間戳timestamp后進(jìn)行存儲(chǔ)，而無(wú)需另行存儲(chǔ)time_bucket

方案的性能測(cè)試

參考來(lái)自開源軟件供應(yīng)鏈點(diǎn)亮計(jì)劃 - 暑期2021的兼容InfluxDB協(xié)議或客戶端項(xiàng)目的設(shè)計(jì)文檔，可以看到，使用索引的情況和不使用索引的情況在查詢時(shí)間上有數(shù)倍的差距。

Skywalking-IoTDB適配器的設(shè)置參數(shù)

1. host，IoTDB主機(jī)IP，默認(rèn)127.0.0.1
2. rpcPort，IoTDB監(jiān)聽端口，默認(rèn)6667
3. username，用戶名，默認(rèn)root
4. password，密碼，默認(rèn)root
5. storageGroup，存儲(chǔ)組名稱，默認(rèn)root.skywalking
6. sessionPoolSize，SessionPool大小，默認(rèn)16
7. fetchTaskLogMaxSize，在一次請(qǐng)求中獲取的TaskLog數(shù)量的最大值，默認(rèn)1000

遇到的問(wèn)題及解決方案

問(wèn)題1：Skywalking部分存儲(chǔ)接口要求order by查詢，但I(xiàn)oTDB僅支持order by time。這本來(lái)可以使用選擇函數(shù)top_k和bottom_k來(lái)過(guò)濾數(shù)據(jù)。但在使用索引方案的情況下，由于數(shù)據(jù)點(diǎn)分散在多個(gè)device中，top_k和bottom_k函數(shù)無(wú)法過(guò)濾數(shù)據(jù)，也無(wú)法使用類似group by level的合并device的查詢方法，具體的描述可參考：Discussion #3888, Issue #3905

• 解決方案：目前除暴力法全部查詢出來(lái)再排序以外暫無(wú)其他解決方案。

問(wèn)題2：Skywalking部分存儲(chǔ)接口要求group by entity_id的分組聚合查詢，但I(xiàn)oTDB僅支持group by time和group by level

• 解決方案：采用方案二，并將entity_id作為L(zhǎng)ayerName存儲(chǔ)，通過(guò)group by level實(shí)現(xiàn)分組查詢。

問(wèn)題3：在使用索引方案的情況下，由于數(shù)據(jù)點(diǎn)分散在多個(gè)device中，聚合函數(shù)的使用必須要通過(guò)group by level才能正確統(tǒng)計(jì)數(shù)據(jù)。但在此情況下，group by level和where同時(shí)使用得不到預(yù)期的結(jié)果。應(yīng)該要加上align by device語(yǔ)義才行，但加上以后就會(huì)引起IllegalPathException，推測(cè)是因?yàn)镮oTDB不能同時(shí)支持group by level和align by device的語(yǔ)義。具體描述可以參考Discussion #3907

• 解決方案：運(yùn)用align by device和where過(guò)濾查詢所有數(shù)據(jù)后自行實(shí)現(xiàn)聚合函數(shù)的功能。

問(wèn)題4：Skywalking的存儲(chǔ)接口要求模糊查詢，但I(xiàn)oTDB使用like的模糊查詢并不支持跨device查詢，不適用于方案二。此外，IoTDB的字符串函數(shù)string_contains只能返回true/false，并不會(huì)對(duì)數(shù)據(jù)進(jìn)行過(guò)濾。具體描述可以參考：Issue #3945

• 解決方案：最初使用select *, string_contains獲得查詢結(jié)果后再根據(jù)true/false循環(huán)過(guò)濾。后來(lái)@ijihang提交的PR#3953 ，使like支持跨device查詢和align by device。所以該問(wèn)題可以直接使用類似MySQL的模糊查詢即可，再次感謝。

問(wèn)題5：Skywalking的存儲(chǔ)接口要求模糊查詢和過(guò)濾查詢。由于采用了索引方案，所以需要跨device查詢，但使用string_contains函數(shù)的過(guò)濾查詢對(duì)多個(gè)device之間采用了and的語(yǔ)義，無(wú)法正確過(guò)濾數(shù)據(jù)，如果是or的語(yǔ)義應(yīng)該就可以正確過(guò)濾數(shù)據(jù)了。同時(shí)string_contains也不支持使用align by device。以上這種情況僅支持對(duì)time的過(guò)濾。

• 解決方案：最初使用select *, string_contains from root.skywalking.xxx.* where time > ?獲得結(jié)果后自行對(duì)其他條件過(guò)濾。后來(lái)采用類似問(wèn)題4的解決方案，直接使用類似MySQL的模糊查詢和過(guò)濾查詢即可。

總結(jié)

當(dāng)前的存儲(chǔ)方案還存在使用暴力法進(jìn)行查詢的情況，即使通過(guò)Skywalking社區(qū)的審查，性能也是不足的，具有數(shù)據(jù)傳輸開銷大、系統(tǒng)處理資源占用大的問(wèn)題。暫時(shí)還沒有好的方法可以解決，要等后續(xù)IoTDB針對(duì)這類場(chǎng)景增加不同語(yǔ)義的關(guān)鍵字或者完善現(xiàn)有的查詢語(yǔ)義才行。