擁抱時序資料庫，構築IoT時代下智慧康養資料儲存底座
摘要：在HDZ城市行廣州站中，來自華為雲華為雲資料庫創新Lab向宇從時序資料庫的技術角度，解讀一下華為雲時序資料庫GaussDB(for Influx)如何應用在智慧健康養老行業。
本文分享自華為雲社群《擁抱時序資料庫，構築IoT時代下智慧康養資料儲存底座》，作者： 技術火炬手 。
隨著 IoT 技術的快速發展，物聯網裝置產生的資料呈爆炸式增長。這些資料通常隨時間產生，稱之為時序資料。這樣的一種專門用於管理時序資料的資料庫被稱為時序資料庫。
時序資料庫是當前物聯網 IoT垂直領域最為合適的資料庫解決方案。作為物聯網下火熱的智慧健康養老應用，時序資料庫能為智慧健康養老行業帶來哪些貢獻？在HDZ城市行廣州站中，來自華為雲華為雲資料庫創新Lab向宇從時序資料庫的技術角度，解讀一下華為雲時序資料庫GaussDB(for Influx)如何應用在智慧健康養老行業。
時序資料庫助力智慧健康養老場景化應用
從智慧健康養老的全場景圖看到，智慧健康養老整體上分為4個部分：
- 裝置：包括穿戴裝置（比如手環，可以記錄步數和心率）、環境監測裝置（比如室內室外溫度感測器）和醫療健康裝置（比如血壓儀、血糖儀）。這些裝置產生的資料需要上傳到平臺或系統服務進行統一儲存，為更上層的應用提供基本的資料輸入。
- 資料儲存層：相同功能但不同廠商的裝置產生的資料格式可能不盡相同。再者，隨著業務的發展，可能還會接入更多型別裝置，資料量也會越來越大。考慮業務變更和資料庫效能，為最大程度降低對上層應用的影響，把裝置資料與其他業務資料分開儲存。
- 服務層：平臺對外提供的能力，比如安全預警、健康風險評估、其他養老事務管理功能等。
- 端側應用：基於平臺提供的服務，可以開發出APP，利用APP把老人、子女、機構工作人員三類使用者聯絡起來，例如：子女可以通過手機APP實時檢視自己父母的運動情況，健康指標，工作人員可以在終端提交工單等等）。
在物聯網等領域，特別是智慧康養場景下，我們發現有這麼一些資料，他們都有時間屬性，有裝置描述資訊，有采集的資料指標。舉個例子，如下圖所示：
第一列是資料產生的時間，第二列是裝置編號，後面是採集的資料內容，如體溫、心率等。我們把資料劃分為三個部分，時間部分稱為時間戳，裝置編號等描述裝置資訊的部分稱之為資料的標籤，剩餘部分描述了採集的具體指標，稱之為指標項。像這樣的資料，我們就稱之為時序資料，因為它有明顯的時間屬性。那麼這些時序資料，都是有自己的特點：
- 不變性：時序資料在寫入後，一般不會被修改。這個特徵非常適用於壓縮，不因修改某個資料對整個資料塊進行修改。
- 時效性：時間越近的資料被訪問的概率大，時間越是久遠，資料被訪問的概率越低。因此，對於時序的熱資料，可以採用壓縮和解壓速度比較好，壓縮率合理的壓縮演算法，而對於冷資料，非常適合使用更高壓縮比的演算法。
- 資料量龐大：時序資料的採集型別豐富， 隨著採集硬體的普及和採集頻率增加，使得資料量出現暴增，比如自動駕駛中每輛車每天就會採集將近 8T 的資料，頻寬、實時寫入、快速查詢、儲存、耗電以及維護成本都是挑戰。
- 資料使用冷熱：使用者可能對某些資料來源或者時間段的關注遠遠超過其他，因此在海量資料中偏向某些特殊時間段或某些資料來源的資料查詢。
時序資料庫如何選？
從我們的企業應用的情況來看，目前存放時序資料採用的資料庫各種各樣，有用關係資料庫存放，有用NOSQL資料儲存（比如HBASE，Cassandra，MongoDB）,還有就是用到了時序資料庫。我們總結了一下選型資料庫之前需要考慮的一些問題：
- 成本：分為運維成本和儲存成本，比如用HBASE儲存，它的技術棧很長，底層儲存使用的是HDFS。運維就需要一個人既懂時序資料庫，又要懂大資料平臺，成本比較高。其次，資料量逐漸的增加，儲存需要不斷的擴容，成本隨之上來了。所以，既要選擇部署便捷、擴容操作簡單，又要能提供資料壓縮的資料庫。
- 效能：不同的業務對資料庫的效能需求是不一樣的，需要考慮今後業務規模增加後，資料庫能不能支撐預期的裝置數量和資料量。
- 業務變更：對於物聯網而言，由於缺乏標準，各式各樣的裝置都有可能接入，有的裝置可能只有2列資料，有的裝置可能有3列資料，這就要求資料庫支援Schemaless。
- 生態：主要是時序資料庫上下游介面的問題，選擇的資料庫需要考慮其技術生態，資料要能進的來，出的去。比如用了SQLServer存時序資料，想用Granfana展示資料就很困難。
- 資料分析：裝置資料被儲存下來，最終是需要通過資料分析挖掘資料隱藏價值，還要考慮資料庫是否支援資料分析平臺。
鑑於上述行業中存在的問題，以及對未來物聯網發展的信心，華為雲自研GaussDB(for Influx) 基於華為自研的計算儲存分離架構，相容InfluxDB生態的雲原生NoSQL時序資料庫。提供大併發時序資料讀寫、壓縮儲存、多維聚合以及一鍵部署、快速備份恢復、計算儲存獨立擴容、監控告警等服務能力，可以完全滿足康養的需求。
GaussDB(for Influx)時序資料庫依靠華為在資料儲存領域多年的實踐經驗，整合華為雲的計算、儲存、服務保障和安全等方面的能力，大膽在架構、效能和資料壓縮等方面進行了技術創新，達到了較好的效果，對內支撐了華為雲基礎設施服務，對外以服務的形式開放，幫助上雲企業解決相關業務問題。
GaussDB(for Influx)介面完全相容InfluxDB，寫入介面相容OpenTSDB、Prometheus和Graphite。從架構上看，一個時序資料庫叢集可以分為三大元件。它們分別是：
- Shard節點：節點採用無狀態設計，主要負責資料的寫入和查詢。在節點內，除了分片和時間線管理之外，還支援資料預聚合、資料降取樣和TAG分組查詢等專為時序場景而優化的功能。
- Config叢集：儲存和管理叢集元資料，採用三節點的複製集模式，保證元資料的高可靠性。
- 分散式儲存系統：集中儲存持久化的資料和日誌，資料採用三副本方式存放，對上層應用透明。儲存系統為華為自研，經過多年產品實踐檢驗，系統的高可用和高可靠性都得到了驗證。
華為雲時序資料庫應對智慧康養應用場景有妙招
在面對AIoT物聯網典型應用場景中，時序資料庫每天會產生數GB甚至數TB的時序資料。如果無法對這些時序資料進行很好的管理和壓縮，那將會給企業帶來非常高的成本壓力。
GaussDB(for Influx)對資料採用列式儲存，相同型別的資料被集中儲存，更有利於資料壓縮。採用自研的時序資料自適應壓縮演算法，在壓縮前對資料進行抽樣分析，根據資料量、資料分佈以及資料型別選擇最合適的資料壓縮演算法。在壓縮演算法上，相比原生的InfluxDB，重點針對Float、String、Timestamp這三種資料型別進行了優化和改進。
- Float資料型別： 對Gorilla壓縮演算法進行了優化，將可以無損轉換的數值轉為整數，再根據資料特點，選擇最合適的資料壓縮演算法。
- String資料型別：採用了壓縮效率更好的ZSTD壓縮演算法，並根據待壓縮資料的Length使用不同Level的編碼方法。
- Timestamp資料型別：採用差量壓縮方法，最後還針對資料檔案內的Timestamp進行相似性壓縮，進一步降低時序資料儲存成本。
下圖是分別採用實際業務場景的事件日誌資料（資料集1)和雲伺服器監控指標資料 (資料集2）與InfluxDB進行了資料壓縮效率的效能對比。
節約儲存成本並非只有資料壓縮一種辦法。針對時序資料越舊的資料被訪問的概率越低的特點，GaussDB(for Influx)提供了時序資料的分級儲存，支援使用者自定義冷熱資料，實現資料的冷熱分離。熱資料相對資料量小，訪問頻繁，被儲存在效能更好、成本較高的儲存介質上；冷資料相對資料量大，訪問概率低，儲存時間較久，被儲存在成本較低的儲存介質上，進而達到節約儲存成本的目的。根據實際業務資料測算，相同資料量下儲存成本僅有關係型資料庫的1/20。
除了產品本身的技術優勢特點，GuassDB(for Influx)能夠開箱即用，使用者只需要關注應用層就可以，不用關注運維。在使用的過程中，不需要去特意學習新的產品技術，會SQL就可以使用。GaussDB(for Influx)還相容Influx 生態，整個生態下的工具、介面等都可以直接應用。
從資料安全形度看，GaussDB(for Influx)在容災備份方面，支援異地3AZ，可以讓資料儲存在不同的城市，這樣確保資料的安全性。
在智慧康養場景下，最重要的是如何基於資料分析，來進一步對使用者帶來更好地產品服務。GuassDB(for Influx)還提供資料分析平臺，能夠和資料庫融合在一起，可以把相關演算法以熱插拔的方式嵌入到平臺中，從資料庫直接讀取資料進行分析，最終應用在相對應的場景下。這兩邊是以相互感知的形式，分析感知儲存，從而輕量化儲存分析開銷。不管企業在什麼地方，基於GuassDB(for Influx)能夠解決康養企業的資料孤島問題，實現價值共享。
最後，向宇還提前透露了GuassDB(for Influx)的開源計劃，開源的名字叫GeminiTSDB，相容Influx DB介面，採用類SQL查詢語言，提供單機和分散式叢集兩種部署模式，安裝簡單，部署靈活，無須外部依賴，具有高可用、高效能、低時延、低儲存成本、擴充套件靈活等優點,希望大家多多關注！