據(jù)研究機構(gòu)Forrester預(yù)測，物聯(lián)網(wǎng)所帶來的產(chǎn)業(yè)價值要比互聯(lián)網(wǎng)高30倍，到2020年，中國物聯(lián)網(wǎng)產(chǎn)業(yè)將成長為一個超過五萬億規(guī)模的巨大市場。

5G、AI、區(qū)塊鏈等新一代信息技術(shù)與物聯(lián)網(wǎng)加速融合。在智能互聯(lián)的愿景中，物聯(lián)網(wǎng)系統(tǒng)的機器、設(shè)備和傳感器收集的數(shù)據(jù)，通過人工智能技術(shù)進(jìn)行分析與關(guān)聯(lián)，以更有意義的方式服務(wù)用戶。然而，隨著物聯(lián)網(wǎng)數(shù)據(jù)量的增長，“時序數(shù)據(jù)庫”成為企業(yè)面臨的“必答題”。

高性能時序數(shù)據(jù)庫，是物聯(lián)網(wǎng)的數(shù)據(jù)存儲底座

時序數(shù)據(jù)庫是一種針對時序數(shù)據(jù)進(jìn)行垂直優(yōu)化的數(shù)據(jù)庫，專門用于存儲和管理時序數(shù)據(jù)。向宇舉例到，某個酒店在晚上8：00有200個房間被入住，那個8：00時間點上存儲的200的數(shù)字就是時序數(shù)據(jù)。

在物聯(lián)網(wǎng)和運維監(jiān)控場景下，如服務(wù)器CPU和內(nèi)存使用量、電動汽車的工況數(shù)據(jù)、或是應(yīng)用服務(wù)的業(yè)務(wù)指標(biāo)等等，各種被采集的數(shù)據(jù)指標(biāo)項多達(dá)千萬甚至上億，甚至一次采集的指標(biāo)數(shù)據(jù)就可能超過數(shù)10GB，這些數(shù)據(jù)都必須要在規(guī)定時間內(nèi)全部寫入數(shù)據(jù)庫。并且，指標(biāo)數(shù)據(jù)通常間隔幾秒就會被采集一次，如此海量的時序數(shù)據(jù)必然要求數(shù)據(jù)庫要具備大并發(fā)寫入能力和很高的數(shù)據(jù)壓縮效率。

此外，時序業(yè)務(wù)通常還需要將數(shù)據(jù)從數(shù)據(jù)庫中檢索出來，以近乎實時的可視化方式展現(xiàn)，方便分析和決策，這對數(shù)據(jù)庫的查詢性能也有著嚴(yán)格的要求。在這種場景下，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫最大的問題在于數(shù)據(jù)缺少壓縮，查詢效率低下，時序數(shù)據(jù)庫一開始就被設(shè)計為高吞吐、低時延、高數(shù)據(jù)壓縮率，以滿足物聯(lián)網(wǎng)和運維監(jiān)控場景下對性能和儲存成本的訴求。也正是因為時序數(shù)據(jù)庫的這些特點，在制造業(yè)、銀行金融、社交媒體、能源、智慧家居等行業(yè)領(lǐng)域都有大量的應(yīng)用場景。

凝結(jié)10多年軟硬件技術(shù)經(jīng)驗，未來挑戰(zhàn)重重

根據(jù)IDC的一份白皮書預(yù)測，到2025年全球數(shù)據(jù)總量將達(dá)到175ZB，這其中30%為時序數(shù)據(jù)。時序數(shù)據(jù)庫是在最近10年才真正發(fā)展起來，這期間出現(xiàn)了許許多多的時序數(shù)據(jù)庫，光DBEngines網(wǎng)站收錄的全球時序數(shù)據(jù)庫就多達(dá)有30多種。

向宇談到，相比關(guān)系型數(shù)據(jù)庫，時序數(shù)據(jù)庫略微簡單一些，沒有復(fù)雜的事務(wù)支持，也沒有針對單條數(shù)據(jù)的更新和刪除操作。但要做好一個時序數(shù)據(jù)庫并非易事，就像造車一樣，要造好一輛車，單純購買零件組裝測試是遠(yuǎn)遠(yuǎn)不夠的，還需要考慮質(zhì)量、性能、舒適性、功能性、安全性等等，一輛車凝結(jié)著人類智慧與文化的結(jié)晶。

打造一款時序數(shù)據(jù)庫，需要凝結(jié)數(shù)十年數(shù)據(jù)庫領(lǐng)域發(fā)展的硬件和軟件技術(shù)和經(jīng)驗，如存儲、安全、分布式系統(tǒng)、編譯、算法、數(shù)據(jù)結(jié)構(gòu)、架構(gòu)設(shè)計等等，更要做到系統(tǒng)安全、可靠、穩(wěn)定、高效和多場景通用。“未來會有越來越多的企業(yè)希望利用時序數(shù)據(jù)庫挖掘出更多有價值的信息，時序數(shù)據(jù)庫在海量時間線管理、數(shù)據(jù)壓縮、讀寫性能等方面正面臨著巨大的技術(shù)挑戰(zhàn)。”向宇講到。

云原生存算分離架構(gòu)，華為云數(shù)據(jù)創(chuàng)新Lab實踐

時序數(shù)據(jù)庫，作為整個物聯(lián)網(wǎng)的數(shù)據(jù)存儲底座，同時也是云廠商基礎(chǔ)設(shè)施的重要部分。作為全球云服務(wù)提供商，華為云的迅速發(fā)展，其背后是大量基礎(chǔ)設(shè)施的擴張，如何能把所有的基礎(chǔ)設(shè)施和云服務(wù)完全監(jiān)控起來，是擺在運維團隊面前不得不去解決的技術(shù)問題。現(xiàn)有的開源時序數(shù)據(jù)庫已經(jīng)不能滿足華為云監(jiān)控數(shù)據(jù)日益增長的訴求，監(jiān)控指標(biāo)數(shù)量從數(shù)百萬迅速增加到數(shù)十億，每秒數(shù)據(jù)寫入量從數(shù)億條迅速增長到數(shù)十億條，迫切需要一款自研的時序數(shù)據(jù)庫可以支撐運維團隊的監(jiān)控系統(tǒng)。

在2018年開始，向宇所在的華為云數(shù)據(jù)創(chuàng)新Lab開始著眼于未來物聯(lián)網(wǎng)和運維監(jiān)控場景下的時序數(shù)據(jù)存儲與管理，自研時序數(shù)據(jù)庫GaussDB（for Influx）。在經(jīng)過內(nèi)部場景的驗證后，GaussDB（for Influx）于2020年正式上線對外商用。

GaussDB（for Influx）采用云原生存儲與計算分離架構(gòu)，支持分鐘級彈性節(jié)點擴縮容，做到不遷移數(shù)據(jù)的同時還把事情給做了；支持億級時間線，每天萬億條數(shù)據(jù)寫入不是問題；支持?jǐn)?shù)據(jù)無損壓縮，采用自適應(yīng)數(shù)據(jù)壓縮算法，將數(shù)據(jù)壓縮比提高到1:20；運用MPP架構(gòu)、向量化、預(yù)聚合等相關(guān)技術(shù)，相比開源的OpenTSDB、InfluxDB等時序數(shù)據(jù)庫，對于像單時間線條件查詢和多維聚合查詢這類在時序數(shù)據(jù)庫中較為常見的查詢，性能上有很大幅度的提升。

向宇介紹到，華為云的一個業(yè)務(wù)從Cassandra切換到GaussDB（for Influx）后，計算節(jié)點從總共39個（熱集群18個，冷集群9個，大數(shù)據(jù)分析集群 12個）降低到了9個節(jié)點，縮減4倍計算節(jié)點。存儲空間消耗從每天1TB降低到100GB以內(nèi)，縮減10倍存儲空間消耗。

目前華為云時序數(shù)據(jù)庫GaussDB（for Influx）已經(jīng)服務(wù)15+內(nèi)部和外部客戶，已成為華為云基礎(chǔ)設(shè)施重要組成部分。

研發(fā)之路沒有現(xiàn)成的參考答案，迎難而上正面“剛”

回想時序數(shù)據(jù)庫GaussDB（for Influx）研發(fā)過程的時候，向宇說道，一個系統(tǒng)從誕生到成熟，往往伴隨著長期的Bug修復(fù)和結(jié)合場景的持續(xù)優(yōu)化。因為任何人都無法提前把所有的應(yīng)用場景都想到并且測試覆蓋到，GaussDB（for Influx） 也不例外。

當(dāng)初研發(fā)GaussDB（for Influx）時，向宇團隊遇到的第一個問題就是“進(jìn)程OOM（內(nèi)存耗盡觸發(fā)操作系統(tǒng)保護機制）退出”。大家都知道，出現(xiàn)OOM只可能有兩個原因，一是內(nèi)存泄漏，二是內(nèi)存真實使用過多。

眾所周知，數(shù)據(jù)庫里面的數(shù)據(jù)是存放到磁盤文件，高效率的數(shù)據(jù)檢索往往需要在內(nèi)存中建立文件索引，方便快速定位數(shù)據(jù)在文件中的位置。在時序數(shù)據(jù)庫中，當(dāng)數(shù)據(jù)在數(shù)據(jù)庫中保留的時間越長，數(shù)據(jù)文件就會越大，文件數(shù)量也就越多。程序重啟過程中，需要將每個數(shù)據(jù)文件的元數(shù)據(jù)讀取到內(nèi)存組織為索引，這里的元數(shù)據(jù)主要包括當(dāng)前文件存放有多少時間線，每個時間線的數(shù)據(jù)在文件中的偏移量等等。在運維監(jiān)控的場景下，時間線的數(shù)量是呈指數(shù)增長，當(dāng)時序數(shù)據(jù)庫的時間線超過億級，虛擬機規(guī)格不變的情況下，問題出現(xiàn)了，元數(shù)據(jù)無法全部存放內(nèi)存再轉(zhuǎn)化為索引，于是程序出現(xiàn)OOM無法重啟。

向宇進(jìn)一步闡述道，時序數(shù)據(jù)庫難就難在這里，因為絕大部分用戶或者場景不會達(dá)到出現(xiàn)問題的時間線和數(shù)據(jù)量，面對計算資源有限，而數(shù)據(jù)量太大的情況，行業(yè)中并無行之有效的現(xiàn)成方法，解決這樣的問題，往往需要結(jié)合技術(shù)和經(jīng)驗。舉個例子，程序重啟過程中加載元數(shù)據(jù)，為避免在內(nèi)存積壓太多數(shù)據(jù)，可以選擇限流的方式，那么每次處理的數(shù)據(jù)量閾值應(yīng)當(dāng)如何設(shè)置就依賴長期的系統(tǒng)開發(fā)經(jīng)驗，太大可能問題還會存在，太小又耗時過長。

“有問題不可怕，可怕的是沒有問題。當(dāng)問題發(fā)生時，我們的選擇是正面‘硬剛’，出現(xiàn)一個消滅一個！”向宇談到。不難看出，也正是他們的這種不畏艱難，用“匠人”精神開發(fā)出華為云基礎(chǔ)設(shè)施重要組成部分，并且已經(jīng)服務(wù)15+內(nèi)部和外部客戶的華為云時序數(shù)據(jù)庫GaussDB（for Influx）。

原文標(biāo)題：爆文速遞| 華為云專家向宇：工欲善其事必先利其器，才能做數(shù)據(jù)的“管家”

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