在上一篇文章中，我們介紹了運維監控場景下，如何從OpenTSDB遷移到TDengine。

如果應用特別復雜，或者應用領域并不是運維監控場景，本文將更加全面深入地介紹將OpenTSDB應用遷移到TDengine的高級話題。

其他場景的遷移評估與策略

1、TDengine 與 OpenTSDB 的差異

本節將詳細介紹OpenTSDB與TDengine在系統功能層面上存在的差異。

讀完本節之后，你可以全面地評估是否能將某些基于OpenTSDB的復雜應用遷移到TDengine上，以及遷移之后應該注意的問題。

TDengine Database當前只支持Grafana的可視化看板呈現，所以如果應用中使用的是其他看板（例如、等），那么暫時無法直接遷移到TDengine，需要將其重新適配到Grafana才可以正常運行。

截止到2.3.0.x 版本，TDengine Database只能夠支持collectd和StatsD作為數據收集匯聚軟件，當然后面會陸續提供更多的數據收集聚合軟件的接入支持。如果收集端使用了其他類型的數據匯聚器，則需要適配到這兩個數據匯聚端系統，才能正常寫入。除了上述兩個數據匯聚端軟件協議以外，TDengine還支持通過 InfluxDB的行協議和OpenTSDB的數據寫入協議、Json格式將數據直接寫入，可以重寫數據推送端的邏輯，使用TDengine支持的行協議來寫入數據。

此外，如果應用中使用了OpenTSDB的以下特性，在遷移之前還需要了解以下注意事項：

1. /api/stats：如果應用中使用了該項特性來監控OpenTSDB的服務狀態，并在應用中建立了相關的邏輯來聯動處理，那么這部分狀態讀取和獲取的邏輯需要重新適配到TDengine。TDengine提供了全新的處理集群狀態監控機制，來滿足應用對其進行的監控和維護的需求。
2. /api/tree：如果依賴于OpenTSDB的該項特性來進行時間線的層級化組織和維護，那么便無法將其直接遷移至TDengine。TDengine采用了數據庫->超級表->子表這樣的層級來組織和維護時間線，歸屬于同一個超級表的所有的時間線在系統中同一個層級，但是可以通過不同標簽值的特殊構造來模擬應用邏輯上的多級結構。
3. Rollup And PreAggregates：采用了Rollup和PreAggregates，需要應用來決定在合適的地方訪問Rollup的結果，在某些場景下又要訪問原始的結果，這種結構的不透明性讓應用處理邏輯變得極為復雜而且完全不具有移植性。我們認為這種策略是時序數據庫無法提供高性能聚合情況下的妥協與折中。TDengine暫不支持多個時間線的自動降采樣和（時間段范圍的）預聚合，由于 其擁有的高性能查詢處理邏輯，即使不依賴于Rollup 和 （時間段）預聚合計算結果，也能夠提供很高性能的查詢響應，而且讓你的應用查詢處理邏輯更加簡單。
4. Rate: TDengine提供了兩個計算數值變化率的函數，分別是Derivative（其計算結果與InfluxDB的Derivative行為一致）和IRate（其計算結果與Prometheus中的IRate函數計算結果一致）。但是這兩個函數的計算結果與 Rate 有細微的差別，但整體上功能更強大。此外，OpenTSDB提供的所有計算函數，TDengine 均有對應的查詢函數支持，并且TDengine的查詢函數功能遠超過OpenTSDB支持的查詢函數，可以極大地簡化應用處理邏輯。

通過上面的介紹，相信你應該能夠了解OpenTSDB遷移到TDengine帶來的變化，這些信息也有助于你正確地判斷是否可以接受將應用遷移到TDengine之上，體驗TDengine提供的強大的時序數據處理能力。

2、遷移策略

首先將基于OpenTSDB的系統進行遷移涉及到的數據模式設計、系統規模估算、數據寫入端改造，進行數據分流、應用適配工作；之后將兩個系統并行運行一段時間，再將歷史數據遷移到 TDengine 中。當然如果你的應用中有部分功能強依賴于上述OpenTSDB特性，同時又不希望停止使用，可以考慮保持原有的OpenTSDB系統運行，同時啟動 TDengine來提供主要的服務。

數據模型設計

一方面，TDengine 要求其入庫的數據具有嚴格的模式定義。另一方面，TDengine 的數據模型相對于 OpenTSDB 來說又更加豐富，多值模型能夠兼容全部的單值模型的建立需求。 現在讓我們假設一個運維監控場景，我們使用了collectd收集設備的基礎度量（metrics），包含了 memory、swap和disk 等幾個度量，其在 OpenTSDB 中的模式如下：

序號	測量（metric）	值名稱	類型	tag1	tag2	tag3	tag4	tag5
1	memory	value	double	host	memory_type	memory_type_instance	source
2	swap	value	double	host	swap_type	swap_type_instance	source
3	disk	value	double	host	disk_point	disk_instance	disk_type	source

 TDengine要求存儲的數據具有數據模式，即寫入數據之前需創建超級表并指定超級表的模式。對于數據模式的建立，有兩種方式來完成此項工作：

 1）充分利用TDengine對OpenTSDB的數據原生寫入的支持，調用TDengine提供的API將（文本行或 JSON 格式）數據寫入，并自動化地建立單值模型。采用這種方式不需要對數據寫入應用進行較大的調整，也不需要對寫入的數據格式進行轉換。 在C語言層面，TDengine提供了taos_insert_lines來直接寫入OpenTSDB格式的數據（在2.3.x 版本中該函數對應的是 taos_schemaless_insert ）。其代碼參考示例請參見安裝包目錄下示例代碼 schemaless.c。

2）在充分理解TDengine數據模型的基礎上，結合生成數據的特點，手動建立OpenTSDB到TDengine的數據模型調整的映射關系。TDengine能夠支持多值模型和單值模型，考慮到OpenTSDB均為單值映射模型，這里推薦使用單值模型在TDengine中進行建模。

• 單值模型

具體步驟如下：將度量（metrics）的名稱作為 TDengine 超級表的名稱，該超級表建成后具有兩個基礎的數據列—時間戳（timestamp）和值（value），超級表的標簽等效于 度量 的標簽信息，標簽數量等同于度量 的標簽的數量。子表的表名采用具有固定規則的方式進行命名：metric + '_' + tags1_value + '_' + tag2_value + '_' + tag3_value ... 作為子表名稱。

在TDengine中建立3個超級表：

create stable memory(ts timestamp, val float) tags(host binary(12)，memory_type binary(20), memory_type_instance binary(20), source binary(20));
create stable swap(ts timestamp, val double) tags(host binary(12), swap_type binary(20), swap_type_binary binary(20), source binary(20));
create stable disk(ts timestamp, val double) tags(host binary(12), disk_point binary(20), disk_instance binary(20), disk_type binary(20), source binary(20));

對于子表使用動態建表的方式創建如下所示：

insert into memory_vm130_memory_bufferred_collectd using memory tags(‘vm130’, ‘memory’, 'buffer', 'collectd') values(1632979445, 3.0656);

最終系統中會建立 340 個左右的子表，3個超級表。需要注意的是，如果采用串聯標簽值的方式導致子表名稱超過系統限制（191字節），那么需要采用一定的編碼方式（例如 MD5）將其轉化為可接受的長度。

• 多值模型

如果想利用TDengine的多值模型能力，需要首先滿足以下要求：不同的采集量具有相同的采集頻率，且能夠通過消息隊列同時到達數據寫入端，從而確保使用SQL語句將多個指標一次性寫入。將度量的名稱作為超級表的名稱，建立具有相同采集頻率且能夠同時到達的數據多列模型。子表的表名采用具有固定規則的方式進行命名。上述每個度量均只包含一個測量值，因此無法將其轉化為多值模型。

數據分流與應用適配

從消息隊列中訂閱數據，并啟動調整后的寫入程序寫入數據。

數據開始寫入持續一段時間后，可以采用SQL語句檢查寫入的數據量是否符合預計的寫入要求。

統計數據量使用如下SQL語句：

select count(*) from memory

完成查詢后，如果寫入的數據與預期的相比沒有差別，同時寫入程序本身沒有異常的報錯信息，那么可用確認數據寫入是完整有效的。

TDengine不支持采用OpenTSDB的查詢語法進行查詢或數據獲取處理，但是針對OpenTSDB的每種查詢都提供了對應的支持。具體可以參考相關文檔。

TDengine支持以標準的JDBC 3.0接口來操縱數據庫，也可以使用其他類型的高級語言的連接器來查詢讀取數據，以適配應用。具體的操作和使用幫助也請參閱用戶手冊。

歷史數據遷移

1、使用工具自動遷移數據

為了方便歷史數據的遷移工作，我們為數據同步工具DataX提供了插件，能夠將數據自動寫入到TDengine中，需要注意的是DataX的自動化數據遷移只能夠支持單值模型的數據遷移過程。 DataX 具體的使用方式及如何使用DataX將數據寫入TDengine請參見其使用幫助手冊 。

2、手動遷移數據

如果需要使用多值模型寫入數據，就需要自行開發一個將數據從OpenTSDB導出的工具，然后確認哪些時間線能夠合并導入到同一個時間線，再將可以同時導入的時間通過SQL語句寫入數據庫中。

手動遷移數據需要注意以下兩個問題：

1）在磁盤中存儲導出數據時，磁盤需要有足夠的存儲空間以便能夠充分容納導出的數據文件。為了避免全量數據導出后導致磁盤文件存儲緊張，可以采用部分導入的模式，對于歸屬于同一個超級表的時間線優先導出，然后將導出部分的數據文件導入到TDengine系統中。

2）在系統全負載運行下，如果有足夠的剩余計算和IO資源，可以建立多線程的導入機制，最大限度地提升數據遷移效率。考慮到數據解析對于CPU帶來的巨大負載，需要控制最大的并行任務數量，以避免因導入歷史數據而觸發的系統整體過載。

由于TDegnine本身操作簡易性，所以不需要在整個過程中進行索引維護、數據格式的變化處理等工作，整個過程只需要順序執行即可。

當歷史數據完全導入到TDengine以后，此時兩個系統處于同時運行的狀態，之后便可以將查詢請求切換到TDengine上，從而實現無縫的應用切換。