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

公司簡介

北京智能建筑科技有限公司作為北京市在智能建筑和智慧城市領域的創(chuàng)新平臺，是冬奧科技平臺公司、智慧冬奧國家重點項目設計單位和核心實施單位，同時，北智建作為國家高新技術企業(yè)，致力于打造中國最大的智能建筑 AIoT 平臺。

在云計算模式中，采集的數(shù)據必須要傳到云上進行集中式的存儲、歸檔及分析，依托云端計算資源進行復雜的計算，再將所得到的指導性結論通過網絡下發(fā)給終端。而對于邊緣計算，即把一部分的存儲和計算的能力下沉到邊緣側（即設備側），由于終端設備可以較獨立地進行數(shù)據存儲、計算、決策和應用，因此邊緣側會更加智能，對云端依賴更小，數(shù)據處理的時效性也更高，且不再受網絡影響。

一般來說，邊緣側往往是一些能夠大量鋪設的小型智能終端，出于成本考慮，其配置的內存、CPU 等硬件資源和計算能力都很有限。邊緣計算的難點就在于能否在有限的計算資源下，實現(xiàn)最高效的數(shù)據存儲、分析和計算?？偨Y下來，邊緣計算對數(shù)據庫能力的要求主要反映在以下幾個方面，這也是我們在選擇數(shù)據庫時的重點考量維度：

• 超高讀寫性能
• 低硬件開銷
• 通用接口，適配邊緣側多樣計算需求
• 實時數(shù)據的緩存能力、流式計算能力
• 歷史數(shù)據持久化存儲、高效壓縮能力
• 歷史數(shù)據回溯能力、按時間窗口的統(tǒng)計聚合能力

一、技術選型

整體而言，時序數(shù)據庫（Time-Series Database）具備上述各項能力，也是邊緣側采集數(shù)據存儲的最佳選擇。但市面上時序數(shù)據庫產品眾多，如何篩選也是一個難點。

如 OpenTSDB（底層基于 HBase 改造）、InfluxDB 等一類的時序數(shù)據庫，其運行起來的硬件資源開銷過高，對于邊緣側來說還是太重了。后來我們觀察到了一個極輕量化的開源時序數(shù)據庫 —— TDengine，當時它的整個安裝包只有 2 MB 多，使用 C 語言完全自主研發(fā)，核心功能就是一個高性能分布式時序數(shù)據庫。具體優(yōu)勢匯總如下：

• TDengine 社區(qū)已經發(fā)布了支持 ARM64 處理器的版本，可以順暢地運行在樹莓派等主流的邊緣側硬件上，同時提供對實時數(shù)據的緩存、歷史數(shù)據的回溯、按時間段進行聚合計算等多種能力。
• TDengine ARM 版本支持的接口也有很多種，與正常集群版幾乎沒有區(qū)別。同時，它還提供了一個 taos shell 客戶端，讓調試人員可以方便地去查看 TDengine 的運行狀態(tài)。
• 支持包括 C/C++、JAVA、Python、RESTful、Go 在內的多種語言，學習成本低
• 安裝超級簡單，無任何依賴

• 使用便捷

SQLite VS TDengine

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

從上面的比較中我們可以看到，TDengine 和 SQLite 要處理的問題側重點不同，各有所長。從我們自身業(yè)務的切實需求出發(fā)，兩者并非必須要進行取舍，而是可以根據業(yè)務需求靈活搭配使用——由 TDengine 處理時序數(shù)據，由 SQLite 處理關系數(shù)據，以此更好地實現(xiàn)邊緣側的數(shù)據自治?；诖?，在存儲方面我們決定采用 TDengine + SQLite 的組合形式。

二、架構與具體實現(xiàn)

技術架構

• 物理視圖

• 邏輯視圖

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

對于設備的采集值，我們同樣采用 TDengine 進行存儲和檢索。以往采用關系型數(shù)據庫進行存儲時，在設備比較多、數(shù)據量龐大的情況下，查詢會非常的慢，體驗感極差。反觀 TDengine 高壓縮算法能提升 10 到 20 倍的壓縮性能，降低存儲壓力的同時也解決了數(shù)據存儲成本高的問題，還達到了降低硬件成本的效果。

建表建庫思路

• 直接輸入 taos 進入 TDengine 界面
• SHOW DATABASES 查看數(shù)據庫
• USE db_name; 選擇數(shù)據庫
• SHOW TABLES; 查看表
• CREATE DATABASE 創(chuàng)建庫
• CREATE TABLE 創(chuàng)建表
• INSERT INTO 插入數(shù)據
• SELECT 查詢數(shù)據

三、落地效果

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

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

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

四、寫在最后

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

• 現(xiàn)在安裝 TDengine Server 時要向下兼容 TaosClient，如果在升級 Server 時，我不需要再在自己的服務器上面同時升級 TaosClient，可以減少一些部署步驟。
• 如果我們用 kubernetes 進行部署，POD 刪掉重啟后服務就無法啟動了，還需要在掛載的數(shù)據文件夾里面手動去修改配置，非常地不靈活。

我們與 TDengine 的合作不會止于此，未來等到 TDengine 更加成熟穩(wěn)定后，不僅我們的邊緣計算存儲要使用它，甚至我們的中臺數(shù)據也要遷移到上面。