小 T 導讀：在北京智慧建築邊緣側採集資料儲存的方案中，面臨著在有限的計算資源下，如何實現最高效的資料儲存、分析和計算的問題。經過調研與測試，最終選擇了由 TDengine 處理時序資料，SQLite 處理關係資料，以此更好地實現邊緣側的資料自治。本文講述了他們的選型和建模思路以及落地後的效果展示，作為經驗參考分享給有需要的讀者。

公司簡介

北京智慧建築科技有限公司作為北京市在智慧建築和智慧城市領域的創新平臺，是冬奧科技平臺公司、智慧冬奧國家重點專案設計單位和核心實施單位，同時，北智建作為國家高新技術企業，致力於打造中國最大的智慧建築 AIoT 平臺。

在雲端計算模式中，採集的資料必須要傳到雲上進行集中式的儲存、歸檔及分析，依託雲端計算資源進行復雜的計算，再將所得到的指導性結論通過網路下發給終端。而對於邊緣計算，即把一部分的儲存和計算的能力下沉到邊緣側（即裝置側），由於終端裝置可以較獨立地進行資料儲存、計算、決策和應用，因此邊緣側會更加智慧，對雲端依賴更小，資料處理的時效性也更高，且不再受網路影響。

一般來說，邊緣側往往是一些能夠大量鋪設的小型智慧終端，出於成本考慮，其配置的記憶體、CPU 等硬體資源和計算能力都很有限。邊緣計算的難點就在於能否在有限的計算資源下，實現最高效的資料儲存、分析和計算。總結下來，邊緣計算對資料庫能力的要求主要反映在以下幾個方面，這也是我們在選擇資料庫時的重點考量維度：

• 超高讀寫效能
• 低硬體開銷
• 通用介面，適配邊緣側多樣計算需求
• 實時資料的快取能力、流式計算能力
• 歷史資料持久化儲存、高效壓縮能力
• 歷史資料回溯能力、按時間視窗的統計聚合能力

一、技術選型

整體而言，時序資料庫具備上述各項能力，也是邊緣側採集資料儲存的最佳選擇。但市面上時序資料庫產品眾多，如何篩選也是一個難點。

如 OpenTSDB（底層基於 HBase 改造）、InfluxDB 等一類的時序資料庫，其執行起來的硬體資源開銷過高，對於邊緣側來說還是太重了。後來我們觀察到了一個極輕量化的開源時序資料庫 —— TDengine，當時它的整個安裝包只有 2 MB 多，使用 C 語言完全自主研發，核心功能就是一個高效能分散式時序資料庫。具體優勢彙總如下：

• TDengine 社群已經發布了支援 ARM64 處理器的版本，可以順暢地執行在樹莓派等主流的邊緣側硬體上，同時提供對實時資料的快取、歷史資料的回溯、按時間段進行聚合計算等多種能力。
• TDengine ARM 版本支援的介面也有很多種，與正常叢集版幾乎沒有區別。同時，它還提供了一個 taos shell 客戶端，讓除錯人員可以方便地去檢視 TDengine 的執行狀態。
• 支援包括 C/C++、JAVA、Python、RESTful、Go 在內的多種語言，學習成本低
• 安裝超級簡單，無任何依賴

• 使用便捷

SQLite VS TDengine

另外提起邊緣側、嵌入式裝置中的資料儲存，那就不得不提 SQLite。SQLite 是一個不需要後臺的超輕量級資料庫，即插即用的特點也讓它成為世界上裝機量最高的資料庫。SQLite甚至在官網上將自身定位與 fopen() 對標，而不再是作為一款資料庫。SQLite 提供的一系列 API 都是對標關係型資料庫的，它甚至還支援了事務，因此業界常常把它用作嵌入式關係型資料庫。其與 TDengine 的各項對比如下：

從上面的比較中我們可以看到，TDengine 和 SQLite 要處理的問題側重點不同，各有所長。從我們自身業務的切實需求出發，兩者並非必須要進行取捨，而是可以根據業務需求靈活搭配使用——由 TDengine 處理時序資料，由 SQLite 處理關係資料，以此更好地實現邊緣側的資料自治。基於此，在儲存方面我們決定採用 TDengine + SQLite 的組合形式。

二、架構與具體實現

技術架構

• 物理檢視

• 邏輯檢視

在邊緣端日誌功能（為邊緣端的裝置提供日誌上報）的設計上，我們採用 TDengine 對日誌進行儲存，該功能的設計是為出現異常狀況的裝置提供溯源依據，在與告警功能配合下可以讓開發人員快速定位到問題，及時進行解決。此外在邊緣端進行日誌處理，就能利用邊緣端的算力減輕中臺的壓力，還可以支撐 2 萬裝置異常情況下的日誌併發寫入。

對於裝置的採集值，我們同樣採用 TDengine 進行儲存和檢索。以往採用關係型資料庫進行儲存時，在裝置比較多、資料量龐大的情況下，查詢會非常的慢，體驗感極差。反觀 TDengine 高壓縮演算法能提升 10 到 20 倍的壓縮效能，降低儲存壓力的同時也解決了資料儲存成本高的問題，還達到了降低硬體成本的效果。

建表建庫思路

• 直接輸入 taos 進入 TDengine 介面
• SHOW DATABASES 檢視資料庫
• USE db_name; 選擇資料庫
• SHOW TABLES; 查看錶
• CREATE DATABASE 建立庫
• CREATE TABLE 建立表
• INSERT INTO 插入資料
• SELECT 查詢資料

三、落地效果

在產品開發初期階段，我們也嘗試過其他型別的資料庫解決方案，但都因為各種問題而擱置了。因為研發團隊精力人力有限，我們沒有考慮過自己搭建一套大資料處理平臺，畢竟要充分整合 Kafka、HBase、Hadoop、Spark 這一系列開源框架不僅意味要花費大量人力，還需要更多的時間去除錯開源框架本身的問題，融合及聯調不同框架也存在著很多資料一致性的問題，同時也意味著後期運維成本的大幅度增加，穩定性也是個不小的未知數。

所幸遇到了 TDengine，它幫助我們在邊緣側解決了一個很大的問題，即邊緣儲存的問題。因為很多時候邊緣是佈署在資源比較少的機器上面，甚至是 ARM 的工業盒子上面，在資源使用上非常的苛刻，而現在得益於 TDengine 超強的壓縮演算法，我們使用非常小的儲存空間就儲存了幾千萬資料，壓縮率遠超 1/20，在單機上面佈署一個 TDengine 伺服器就可以輕輕鬆鬆地儲存上億的資料。

此外它還擁有超強的計算能力，佔用的資源也非常小，在我們的業務中千萬級資料檢索時間達到了毫秒級，從使用者角度來說產品體驗非常好。在運維層面，TDengine 提供標準的 SQL 語法，有過 SQL 使用經驗的同學基本上很快就能上手，學習成本接近於零。

四、寫在最後

事實上，TDengine 這款產品我已經關注很久了，我也和濤思的同學們提出過一些在使用過程中發現的 Bug，從最初的版本到現在的產品，TDengine 變得更加強大和成熟。作為它的“老朋友”，我在此也提出兩個改進優化建議，以便幫助它更好的成長：

• 現在安裝 TDengine Server 時要向下相容 TaosClient，如果在升級 Server 時，我不需要再在自己的伺服器上面同時升級 TaosClient，可以減少一些部署步驟。
• 如果我們用 kubernetes 進行部署，POD 刪掉重啟後服務就無法啟動了，還需要在掛載的資料資料夾裡面手動去修改配置，非常地不靈活。

我們與TDengine的合作不會止於此，未來等到 TDengine 更加成熟穩定後，不僅我們的邊緣計算儲存要使用它，甚至我們的中臺資料也要遷移到上面。

想了解更多 TDengine 的具體細節，歡迎大家在GitHub上檢視相關原始碼。