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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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