該項目來自于開源軟件供應鏈點亮計劃 - 暑期2021的Apache IoTDB - Apache Skywalking適配器項目。目前已提交至Skywalking社區（IoTDB storage plugin #7766），正在接受社區評審。

實現思路

項目目標是為Skywalking開發一個使用IoTDB進行相關數據讀寫的適配器。可以參考Skywalking目前已有的采用InfluxDB、H2和Elasticsearch的適配器。Skywalking給出了存儲拓展的開發指南，參考鏈接。此外，需要使用Skywalking和InfluxDB的調試過程，以便充分了解Skywalking的接口和使用方式。

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

開發平臺：Win10，IoTDB版本：0.12.2

相關概念

Skywalking的存儲模型

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

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

  • SegmentRecord：Trace Segment明細記錄模型。由skywalking-trace-receiver-plugin插件接收并解析Skywalking Agent發送來的鏈路數據后得到TraceSegment。
  • AlarmRecord：報警明細記錄模型。在指標觸發報警規則時，會產生對應的報警明細數據模型。
  • TopN：TopN是采樣模型，具備statement字段（用于描述采樣數據的關鍵信息），latency字段（用于記錄采樣數據的延遲），
    trace_id字段（用于描述采樣數據的關聯分布式鏈路ID），service_id字段（用于記錄服務ID）。目前采樣模型默認只有TopNDatabaseStatement。
    • TopNDatabaseStatement：按照延遲排序的DB采樣記錄。

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

• NoneStream：NoneStream基于Record，支持time_bucket轉換為TTL。例如：ProfileTaskRecord

• ManagementData：UI模板管理相關的數據，默認只有一個UITemplate實現類

部分參考《Apache Skywalking實戰》第9章：SkyWalking OAP Server存儲模型

IoTDB的數據模型

參考IoTDB官方數據模型介紹。簡單來說，可以用樹結構來認識IoTDB的數據模型。如果按照層級劃分，從高到低依次為：Storage Group -> (LayerName) -> Device -> Timeseries。從最上層到其下某一層稱為一條路徑（Path），最上層是Storage Group，倒數第二層是Device，倒數第一層是Timeseries，中間可以有很多層，每一層姑且稱之為LayerName。

值得注意的是，每個Storage Group需要一個線程，所以Storage Group過多會導致存儲性能下降。此外，LayerName的值存儲在內存中，而Timeseries的值及其下的數據存儲在硬盤中。

Skywalking的IoTDB-adapter存儲方案

概念劃分

Skywalking的每個存儲模型可以認為是一個Model，Model中包含了多個Column，每個Column中具備ColumnName和ColumnType屬性，分別表示Column的名字和類型，每個ColumnName下存儲多個數據類型為ColumnType的數據Value。從關系型數據庫的角度來看的話，Model即是關系表，Column即是關系表中的字段。

方案一：類似關系型數據庫的存儲方案（無法實現）

將Skywalking的所有存儲模型都寫入IoTDB的一個存儲組中，例如root.skywalking存儲組。Model對應Device，Column對應Timeseries。即Skywalking的“Database -> Model -> Column”對應到IoTDB的“Storage Group -> Device -> Timeseries”。該方案的IoTDB存儲路徑只有4層：root.skywalking.ModelName.ColumnName。該方案的優點是邏輯清晰，實現難度較低，但由于數據都存儲在硬盤上，查詢效率相對較差。

驗證結果：該方案無法實現
原因：部分存儲接口需要實現group by entity_id的查詢功能，但IoTDB只支持group by time。需要采用方案二并通過group by level來實現。

方案二：引入索引的存儲方案

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

依然將Skywalking的所有存儲模型都寫入IoTDB的一個存儲組中，例如root.skywalking存儲組。Model對應一個LayerName，需要索引的Column也對應于LayerName，不過LayerName并不存儲ColumnName，而是存儲對應的Value，相當于需要索引的一個Column的不同Value存儲在同一分支下的同一層。不需要索引的Column依然對應Timeseries，即路徑的最后一層。最終將導致同一個Model的數據分散到多個Device中。

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

該方案的IoTDB存儲路徑長度是不定的，索引的Column越多，路徑的長度越長。例如:

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

• 需要具備索引的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的所有數據select *from root.skywalking.model1_name;-- 查找model2中column22_value="test"的數據select *from root.skywalking.model2_name.*.test;-- 按照column21分組統計model2中column23的和select sum(column23)from root.skywalking.model2_name.*.*group by level = 3;

該方案的優點是實現了索引功能，類似InfluxDB的tag，但邏輯較復雜，實現難度較大。另一方面還需進一步確定哪些Column需要作為索引列，這一點可以參考Elasticsearch（StorageEsInstaller），InfluxDB（TableMetaInfo），MySQL（MySQLTableInstaller）的實現，以及ModelColumn的isStorageOnly屬性。

該方案將部分數據通過LayerName存儲在內存中，在海量數據的情況下可能會導致內存開銷較大。此外，由于同一個Model的數據被分散到了多個Device中，所以查詢往往需要跨多個Device進行查詢。但在這一方面，IoTDB對于跨Device的聚合查詢、排序查詢、分頁查詢的支持還不夠完善，在一些情況下需要使用暴力法將所有符合條件的數據都查出來，然后再自行實現聚合、排序、分頁的功能。具體描述可參考下文在IoTDB社區提交的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:
  • 一個有關排序查詢的問題（A problem about sort query）#3888
  • 一個有關聚合查詢的問題（A problem about aggregation query）#3907

已確定采用索引的字段

id
entity_id
node_type
service_group
service_id
trace_id

此外，可以將time_bucket轉換為IoTDB自帶的時間戳timestamp后進行存儲，而無需另行存儲time_bucket

方案的性能測試

參考來自開源軟件供應鏈點亮計劃 - 暑期2021的兼容InfluxDB協議或客戶端項目的設計文檔，可以看到，使用索引的情況和不使用索引的情況在查詢時間上有數倍的差距。

Skywalking-IoTDB適配器的設置參數

1. host，IoTDB主機IP，默認127.0.0.1
2. rpcPort，IoTDB監聽端口，默認6667
3. username，用戶名，默認root
4. password，密碼，默認root
5. storageGroup，存儲組名稱，默認root.skywalking
6. sessionPoolSize，SessionPool大小，默認16
7. fetchTaskLogMaxSize，在一次請求中獲取的TaskLog數量的最大值，默認1000

遇到的問題及解決方案

問題1：Skywalking部分存儲接口要求order by查詢，但IoTDB僅支持order by time。這本來可以使用選擇函數top_k和bottom_k來過濾數據。但在使用索引方案的情況下，由于數據點分散在多個device中，top_k和bottom_k函數無法過濾數據，也無法使用類似group by level的合并device的查詢方法，具體的描述可參考：Discussion #3888, Issue #3905

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

問題2：Skywalking部分存儲接口要求group by entity_id的分組聚合查詢，但IoTDB僅支持group by time和group by level

• 解決方案：采用方案二，并將entity_id作為LayerName存儲，通過group by level實現分組查詢。

問題3：在使用索引方案的情況下，由于數據點分散在多個device中，聚合函數的使用必須要通過group by level才能正確統計數據。但在此情況下，group by level和where同時使用得不到預期的結果。應該要加上align by device語義才行，但加上以后就會引起IllegalPathException，推測是因為IoTDB不能同時支持group by level和align by device的語義。具體描述可以參考Discussion #3907

• 解決方案：運用align by device和where過濾查詢所有數據后自行實現聚合函數的功能。

問題4：Skywalking的存儲接口要求模糊查詢，但IoTDB使用like的模糊查詢并不支持跨device查詢，不適用于方案二。此外，IoTDB的字符串函數string_contains只能返回true/false，并不會對數據進行過濾。具體描述可以參考：Issue #3945

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

問題5：Skywalking的存儲接口要求模糊查詢和過濾查詢。由于采用了索引方案，所以需要跨device查詢，但使用string_contains函數的過濾查詢對多個device之間采用了and的語義，無法正確過濾數據，如果是or的語義應該就可以正確過濾數據了。同時string_contains也不支持使用align by device。以上這種情況僅支持對time的過濾。

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

總結

當前的存儲方案還存在使用暴力法進行查詢的情況，即使通過Skywalking社區的審查，性能也是不足的，具有數據傳輸開銷大、系統處理資源占用大的問題。暫時還沒有好的方法可以解決，要等后續IoTDB針對這類場景增加不同語義的關鍵字或者完善現有的查詢語義才行。