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

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

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

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

一、技術選型

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

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

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

• 使用便捷

1.1 SQLite VS TDengine

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

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

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

2.1 技術架構

• 物理視圖

• 邏輯視圖

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

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

2.2 建表建庫思路

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

三、落地效果

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

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

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

四、寫在最后

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

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

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