隨著 IoT 技術的快速發(fā)展，物聯(lián)網(wǎng)設備產(chǎn)生的數(shù)據(jù)呈爆炸式增長。這些數(shù)據(jù)通常隨時間產(chǎn)生，稱之為時序數(shù)據(jù)。這樣的一種專門用于管理時序數(shù)據(jù)的數(shù)據(jù)庫被稱為時序數(shù)據(jù)庫。

時序數(shù)據(jù)庫是當前物聯(lián)網(wǎng) IoT垂直領域最為合適的數(shù)據(jù)庫解決方案。作為物聯(lián)網(wǎng)下火熱的智慧健康養(yǎng)老應用，時序數(shù)據(jù)庫能為智慧健康養(yǎng)老行業(yè)帶來哪些貢獻？華為云數(shù)據(jù)庫專家向宇解讀了時序數(shù)據(jù)庫在智慧健康養(yǎng)老行業(yè)應用之道。

時序數(shù)據(jù)庫助力智慧健康養(yǎng)老場景化應用

從智慧健康養(yǎng)老的全場景圖看到，智慧健康養(yǎng)老整體上分為4個部分：1. 設備：包括穿戴設備（比如手環(huán)，可以記錄步數(shù)和心率）、環(huán)境監(jiān)測設備（比如室內(nèi)室外溫度傳感器）和醫(yī)療健康設備（比如血壓儀、血糖儀）。這些設備產(chǎn)生的數(shù)據(jù)需要上傳到平臺或系統(tǒng)服務進行統(tǒng)一存儲，為更上層的應用提供基本的數(shù)據(jù)輸入。2. 數(shù)據(jù)存儲層：相同功能但不同廠商的設備產(chǎn)生的數(shù)據(jù)格式可能不盡相同。再者，隨著業(yè)務的發(fā)展，可能還會接入更多類型設備，數(shù)據(jù)量也會越來越大?？紤]業(yè)務變更和數(shù)據(jù)庫性能，為最大程度降低對上層應用的影響，把設備數(shù)據(jù)與其他業(yè)務數(shù)據(jù)分開存儲。3. 服務層：平臺對外提供的能力，比如安全預警、健康風險評估、其他養(yǎng)老事務管理功能等。4. 端側(cè)應用：基于平臺提供的服務，可以開發(fā)出APP，利用APP把老人、子女、機構工作人員三類用戶聯(lián)系起來，例如：子女可以通過手機APP實時查看自己父母的運動情況，健康指標，工作人員可以在終端提交工單等等。

面對養(yǎng)老行業(yè)的痛點，云芯科技、藍色健康和智康科技三家企業(yè)與華為云在底層系統(tǒng)、數(shù)據(jù)存儲等方面的合作，在平臺服務層面，正在努力實現(xiàn)這些智慧養(yǎng)老的服務應用。

在物聯(lián)網(wǎng)等領域，特別是智慧康養(yǎng)場景下，我們發(fā)現(xiàn)有這么一些數(shù)據(jù)，他們都有時間屬性，有設備描述信息，有采集的數(shù)據(jù)指標。舉個例子，如下圖所示：第一列是數(shù)據(jù)產(chǎn)生的時間，第二列是設備編號，后面是采集的數(shù)據(jù)內(nèi)容，如體溫、心率等。我們把數(shù)據(jù)劃分為三個部分，時間部分稱為時間戳，設備編號等描述設備信息的部分稱之為數(shù)據(jù)的標簽，剩余部分描述了采集的具體指標，稱之為指標項。像這樣的數(shù)據(jù)，我們就稱之為時序數(shù)據(jù)，因為它有明顯的時間屬性。那么這些時序數(shù)據(jù)，都有自己的特點：

不變性：時序數(shù)據(jù)在寫入后，一般不會被修改。這個特征非常適用于壓縮，不因修改某個數(shù)據(jù)對整個數(shù)據(jù)塊進行修改。

時效性：時間越近的數(shù)據(jù)被訪問的概率越大，時間越是久遠，數(shù)據(jù)被訪問的概率越低。因此，對于時序的熱數(shù)據(jù)，可以采用壓縮和解壓速度比較好，壓縮率合理的壓縮算法，而對于冷數(shù)據(jù)，非常適合使用更高壓縮比的算法。

數(shù)據(jù)量龐大：時序數(shù)據(jù)的采集類型豐富， 隨著采集硬件的普及和采集頻率增加，使得數(shù)據(jù)量出現(xiàn)暴增，比如自動駕駛中每輛車每天就會采集將近 8T 的數(shù)據(jù)，帶寬、實時寫入、快速查詢、存儲、耗電以及維護成本都是挑戰(zhàn)。

數(shù)據(jù)使用冷熱：用戶可能對某些數(shù)據(jù)源或者時間段的關注遠遠超過其他，因此在海量數(shù)據(jù)中偏向某些特殊時間段或某些數(shù)據(jù)源的數(shù)據(jù)查詢。

時序數(shù)據(jù)庫如何選？

從我們的企業(yè)應用的情況來看，目前存放時序數(shù)據(jù)采用的數(shù)據(jù)庫各種各樣，有用關系數(shù)據(jù)庫存放，有用NOSQL數(shù)據(jù)存儲（比如HBASE，Cassandra，MongoDB），還有就是用到了時序數(shù)據(jù)庫。我們總結了一下選型數(shù)據(jù)庫之前需要考慮的一些問題。

成本：分為運維成本和存儲成本，比如用HBASE存儲，它的技術棧很長，底層存儲使用的是HDFS。運維就需要一個人既懂時序數(shù)據(jù)庫，又要懂大數(shù)據(jù)平臺，成本比較高。其次，隨著數(shù)據(jù)量逐漸的增加，存儲需要不斷的擴容，成本隨之增加。所以，既要選擇部署便捷、擴容操作簡單，又要能提供數(shù)據(jù)壓縮的數(shù)據(jù)庫。

性能：不同的業(yè)務對數(shù)據(jù)庫的性能需求是不一樣的，需要考慮今后業(yè)務規(guī)模增加后，數(shù)據(jù)庫能不能支撐預期的設備數(shù)量和數(shù)據(jù)量。

業(yè)務變更：對于物聯(lián)網(wǎng)而言，由于缺乏標準，各式各樣的設備都有可能接入，有的設備可能只有2列數(shù)據(jù)，有的設備可能有3列數(shù)據(jù)，這就要求數(shù)據(jù)庫支持Schemaless。

生態(tài)：主要是時序數(shù)據(jù)庫上下游接口的問題，選擇的數(shù)據(jù)庫需要考慮其技術生態(tài)，數(shù)據(jù)要能進的來，出的去。比如用了SQLServer存時序數(shù)據(jù)，想用Granfana展示數(shù)據(jù)就很困難。

數(shù)據(jù)分析：設備數(shù)據(jù)被存儲下來，最終是需要通過數(shù)據(jù)分析挖掘數(shù)據(jù)隱藏價值，還要考慮數(shù)據(jù)庫是否支持數(shù)據(jù)分析平臺。

鑒于上述行業(yè)中存在的問題，以及對未來物聯(lián)網(wǎng)發(fā)展的信心，華為云自研GaussDB（for Influx） 基于華為自研的計算存儲分離架構，兼容InfluxDB生態(tài)的云原生NoSQL時序數(shù)據(jù)庫。提供大并發(fā)時序數(shù)據(jù)讀寫、壓縮存儲、多維聚合以及一鍵部署、快速備份恢復、計算存儲獨立擴容、監(jiān)控告警等服務能力，可以完全滿足康養(yǎng)的需求。GaussDB（for Influx）時序數(shù)據(jù)庫依靠華為在數(shù)據(jù)存儲領域多年的實踐經(jīng)驗，整合華為云的計算、存儲、服務保障和安全等方面的能力，大膽在架構、性能和數(shù)據(jù)壓縮等方面進行了技術創(chuàng)新，達到了較好的效果，對內(nèi)支撐了華為云基礎設施服務，對外以服務的形式開放，幫助上云企業(yè)解決相關業(yè)務問題。GaussDB（for Influx）接口完全兼容InfluxDB，寫入接口兼容OpenTSDB、Prometheus和Graphite。從架構上看，一個時序數(shù)據(jù)庫集群可以分為三大組件。它們分別是：

Shard節(jié)點：節(jié)點采用無狀態(tài)設計，主要負責數(shù)據(jù)的寫入和查詢。在節(jié)點內(nèi)，除了分片和時間線管理之外，還支持數(shù)據(jù)預聚合、數(shù)據(jù)降采樣和TAG分組查詢等專為時序場景而優(yōu)化的功能。

Config集群：存儲和管理集群元數(shù)據(jù)，采用三節(jié)點的復制集模式，保證元數(shù)據(jù)的高可靠性。

分布式存儲系統(tǒng)：集中存儲持久化的數(shù)據(jù)和日志，數(shù)據(jù)采用三副本方式存放，對上層應用透明。存儲系統(tǒng)為華為自研，經(jīng)過多年產(chǎn)品實踐檢驗，系統(tǒng)的高可用和高可靠性都得到了驗證。

華為云時序數(shù)據(jù)庫應對智慧康養(yǎng)應用場景有妙招在面對AIoT物聯(lián)網(wǎng)典型應用場景中，時序數(shù)據(jù)庫每天會產(chǎn)生數(shù)GB甚至數(shù)TB的時序數(shù)據(jù)。如果無法對這些時序數(shù)據(jù)進行很好的管理和壓縮，那將會給企業(yè)帶來非常高的成本壓力。GaussDB（for Influx）對數(shù)據(jù)采用列式存儲，相同類型的數(shù)據(jù)被集中存儲，更有利于數(shù)據(jù)壓縮。采用自研的時序數(shù)據(jù)自適應壓縮算法，在壓縮前對數(shù)據(jù)進行抽樣分析，根據(jù)數(shù)據(jù)量、數(shù)據(jù)分布以及數(shù)據(jù)類型選擇最合適的數(shù)據(jù)壓縮算法。在壓縮算法上，相比原生的InfluxDB，重點針對Float、String、Timestamp這三種數(shù)據(jù)類型進行了優(yōu)化和改進。

Float數(shù)據(jù)類型：對Gorilla壓縮算法進行了優(yōu)化，將可以無損轉(zhuǎn)換的數(shù)值轉(zhuǎn)為整數(shù)，再根據(jù)數(shù)據(jù)特點，選擇最合適的數(shù)據(jù)壓縮算法。

String數(shù)據(jù)類型：采用了壓縮效率更好的ZSTD壓縮算法，并根據(jù)待壓縮數(shù)據(jù)的Length使用不同Level的編碼方法。

Timestamp數(shù)據(jù)類型：采用差量壓縮方法，最后還針對數(shù)據(jù)文件內(nèi)的Timestamp進行相似性壓縮，進一步降低時序數(shù)據(jù)存儲成本。

下圖是分別采用實際業(yè)務場景的事件日志數(shù)據(jù)（數(shù)據(jù)集1）和云服務器監(jiān)控指標數(shù)據(jù) （數(shù)據(jù)集2）與InfluxDB進行了數(shù)據(jù)壓縮效率的性能對比。節(jié)約存儲成本并非只有數(shù)據(jù)壓縮一種辦法。針對時序數(shù)據(jù)越舊的數(shù)據(jù)被訪問的概率越低的特點，GaussDB（for Influx）提供了時序數(shù)據(jù)的分級存儲，支持用戶自定義冷熱數(shù)據(jù)，實現(xiàn)數(shù)據(jù)的冷熱分離。熱數(shù)據(jù)相對數(shù)據(jù)量小，訪問頻繁，被存儲在性能更好、成本較高的存儲介質(zhì)上；冷數(shù)據(jù)相對數(shù)據(jù)量大，訪問概率低，保存時間較久，被存儲在成本較低的存儲介質(zhì)上，進而達到節(jié)約存儲成本的目的。根據(jù)實際業(yè)務數(shù)據(jù)測算，相同數(shù)據(jù)量下存儲成本僅有關系型數(shù)據(jù)庫的1/20。除了產(chǎn)品本身的技術優(yōu)勢特點，GuassDB（for Influx）能夠開箱即用，用戶只需要關注應用層就可以，不用關注運維。在使用的過程中，不需要去特意學習新的產(chǎn)品技術，會SQL就可以使用。GaussDB（for Influx）還兼容Influx 生態(tài)，整個生態(tài)下的工具、接口等都可以直接應用。從數(shù)據(jù)安全角度看，GaussDB（for Influx）在容災備份方面，支持異地3AZ，可以讓數(shù)據(jù)存儲在不同的城市，這樣確保數(shù)據(jù)的安全性。在智慧康養(yǎng)場景下，最重要的是如何基于數(shù)據(jù)分析，來進一步為用戶帶來更好的產(chǎn)品服務。GuassDB（for Influx）還提供數(shù)據(jù)分析平臺，能夠和數(shù)據(jù)庫融合在一起，可以把相關算法以熱插拔的方式嵌入到平臺中，從數(shù)據(jù)庫直接讀取數(shù)據(jù)進行分析，最終應用在相對應的場景下。這兩邊是以相互感知的形式，分析感知存儲，從而輕量化存儲分析開銷。不管企業(yè)在什么地方，基于GuassDB（for Influx）能夠解決康養(yǎng)企業(yè)的數(shù)據(jù)孤島問題，實現(xiàn)價值共享。

據(jù)悉，GuassDB（for Influx）的開源計劃正在進行中，開源的名字叫GeminiTSDB，兼容Influx DB接口，采用類SQL查詢語言，提供單機和分布式集群兩種部署模式，安裝簡單，部署靈活，無須外部依賴，具有高可用、高性能、低時延、低存儲成本、擴展靈活等優(yōu)點，希望大家多多關注！

原文標題：擁抱時序數(shù)據(jù)庫，構筑IoT時代下智慧康養(yǎng)數(shù)據(jù)存儲底座

文章出處：【微信公眾號：華為開發(fā)者社區(qū)】歡迎添加關注！文章轉(zhuǎn)載請注明出處。
責任編輯:pj