據(jù)研究機(jī)構(gòu)Forrester預(yù)測,物聯(lián)網(wǎng)所帶來的產(chǎn)業(yè)價(jià)值要比互聯(lián)網(wǎng)高30倍,到2020年,中國物聯(lián)網(wǎng)產(chǎn)業(yè)將成長為一個(gè)超過五萬億規(guī)模的巨大市場。
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ù)量的增長,“時(shí)序數(shù)據(jù)庫”成為企業(yè)面臨的“必答題”。
高性能時(shí)序數(shù)據(jù)庫,是物聯(lián)網(wǎng)的數(shù)據(jù)存儲(chǔ)底座
時(shí)序數(shù)據(jù)庫是一種針對時(shí)序數(shù)據(jù)進(jìn)行垂直優(yōu)化的數(shù)據(jù)庫,專門用于存儲(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)控場景下,如服務(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ù)庫。并且,指標(biāo)數(shù)據(jù)通常間隔幾秒就會(huì)被采集一次,如此海量的時(shí)序數(shù)據(jù)必然要求數(shù)據(jù)庫要具備大并發(fā)寫入能力和很高的數(shù)據(jù)壓縮效率。
此外,時(shí)序業(yè)務(wù)通常還需要將數(shù)據(jù)從數(shù)據(jù)庫中檢索出來,以近乎實(shí)時(shí)的可視化方式展現(xiàn),方便分析和決策,這對數(shù)據(jù)庫的查詢性能也有著嚴(yán)格的要求。在這種場景下,傳統(tǒng)的關(guān)系型數(shù)據(jù)庫最大的問題在于數(shù)據(jù)缺少壓縮,查詢效率低下,時(shí)序數(shù)據(jù)庫一開始就被設(shè)計(jì)為高吞吐、低時(shí)延、高數(shù)據(jù)壓縮率,以滿足物聯(lián)網(wǎng)和運(yùn)維監(jiān)控場景下對性能和儲(chǔ)存成本的訴求。也正是因?yàn)闀r(shí)序數(shù)據(jù)庫的這些特點(diǎn),在制造業(yè)、銀行金融、社交媒體、能源、智慧家居等行業(yè)領(lǐng)域都有大量的應(yīng)用場景。
凝結(jié)10多年軟硬件技術(shù)經(jīng)驗(yàn),未來挑戰(zhàn)重重
根據(jù)IDC的一份白皮書預(yù)測,到2025年全球數(shù)據(jù)總量將達(dá)到175ZB,這其中30%為時(shí)序數(shù)據(jù)。時(shí)序數(shù)據(jù)庫是在最近10年才真正發(fā)展起來,這期間出現(xiàn)了許許多多的時(shí)序數(shù)據(jù)庫,光DBEngines網(wǎng)站收錄的全球時(shí)序數(shù)據(jù)庫就多達(dá)有30多種。
向宇談到,相比關(guān)系型數(shù)據(jù)庫,時(shí)序數(shù)據(jù)庫略微簡單一些,沒有復(fù)雜的事務(wù)支持,也沒有針對單條數(shù)據(jù)的更新和刪除操作。但要做好一個(gè)時(shí)序數(shù)據(jù)庫并非易事,就像造車一樣,要造好一輛車,單純購買零件組裝測試是遠(yuǎn)遠(yuǎn)不夠的,還需要考慮質(zhì)量、性能、舒適性、功能性、安全性等等,一輛車凝結(jié)著人類智慧與文化的結(jié)晶。
打造一款時(shí)序數(shù)據(jù)庫,需要凝結(jié)數(shù)十年數(shù)據(jù)庫領(lǐng)域發(fā)展的硬件和軟件技術(shù)和經(jīng)驗(yàn),如存儲(chǔ)、安全、分布式系統(tǒng)、編譯、算法、數(shù)據(jù)結(jié)構(gòu)、架構(gòu)設(shè)計(jì)等等,更要做到系統(tǒng)安全、可靠、穩(wěn)定、高效和多場景通用?!拔磥頃?huì)有越來越多的企業(yè)希望利用時(shí)序數(shù)據(jù)庫挖掘出更多有價(jià)值的信息,時(shí)序數(shù)據(jù)庫在海量時(shí)間線管理、數(shù)據(jù)壓縮、讀寫性能等方面正面臨著巨大的技術(shù)挑戰(zhàn)?!毕蛴钪v到。
云原生存算分離架構(gòu),華為云數(shù)據(jù)創(chuàng)新Lab實(shí)踐
時(shí)序數(shù)據(jù)庫,作為整個(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ù)庫已經(jīng)不能滿足華為云監(jiān)控?cái)?shù)據(jù)日益增長的訴求,監(jiān)控指標(biāo)數(shù)量從數(shù)百萬迅速增加到數(shù)十億,每秒數(shù)據(jù)寫入量從數(shù)億條迅速增長到數(shù)十億條,迫切需要一款自研的時(shí)序數(shù)據(jù)庫可以支撐運(yùn)維團(tuán)隊(duì)的監(jiān)控系統(tǒng)。
在2018年開始,向宇所在的華為云數(shù)據(jù)創(chuàng)新Lab開始著眼于未來物聯(lián)網(wǎng)和運(yùn)維監(jiān)控場景下的時(shí)序數(shù)據(jù)存儲(chǔ)與管理,自研時(shí)序數(shù)據(jù)庫GaussDB(for Influx)。在經(jīng)過內(nèi)部場景的驗(yàn)證后,GaussDB(for Influx)于2020年正式上線對外商用。
GaussDB(for Influx)采用云原生存儲(chǔ)與計(jì)算分離架構(gòu),支持分鐘級彈性節(jié)點(diǎn)擴(kuò)縮容,做到不遷移數(shù)據(jù)的同時(shí)還把事情給做了;支持億級時(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ù)庫,對于像單時(shí)間線條件查詢和多維聚合查詢這類在時(shí)序數(shù)據(jù)庫中較為常見的查詢,性能上有很大幅度的提升。
向宇介紹到,華為云的一個(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ù)庫GaussDB(for Influx)已經(jīng)服務(wù)15+內(nèi)部和外部客戶,已成為華為云基礎(chǔ)設(shè)施重要組成部分。
研發(fā)之路沒有現(xiàn)成的參考答案,迎難而上正面“剛”
回想時(shí)序數(shù)據(jù)庫GaussDB(for Influx)研發(fā)過程的時(shí)候,向宇說道,一個(gè)系統(tǒng)從誕生到成熟,往往伴隨著長期的Bug修復(fù)和結(jié)合場景的持續(xù)優(yōu)化。因?yàn)槿魏稳硕紵o法提前把所有的應(yīng)用場景都想到并且測試覆蓋到,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ù)庫里面的數(shù)據(jù)是存放到磁盤文件,高效率的數(shù)據(jù)檢索往往需要在內(nèi)存中建立文件索引,方便快速定位數(shù)據(jù)在文件中的位置。在時(shí)序數(shù)據(jù)庫中,當(dāng)數(shù)據(jù)在數(shù)據(jù)庫中保留的時(shí)間越長,數(shù)據(jù)文件就會(huì)越大,文件數(shù)量也就越多。程序重啟過程中,需要將每個(gè)數(shù)據(jù)文件的元數(shù)據(jù)讀取到內(nèi)存組織為索引,這里的元數(shù)據(jù)主要包括當(dāng)前文件存放有多少時(shí)間線,每個(gè)時(shí)間線的數(shù)據(jù)在文件中的偏移量等等。在運(yùn)維監(jiān)控的場景下,時(shí)間線的數(shù)量是呈指數(shù)增長,當(dāng)時(shí)序數(shù)據(jù)庫的時(shí)間線超過億級,虛擬機(jī)規(guī)格不變的情況下,問題出現(xiàn)了,元數(shù)據(jù)無法全部存放內(nèi)存再轉(zhuǎn)化為索引,于是程序出現(xiàn)OOM無法重啟。
向宇進(jìn)一步闡述道,時(shí)序數(shù)據(jù)庫難就難在這里,因?yàn)榻^大部分用戶或者場景不會(huì)達(dá)到出現(xiàn)問題的時(shí)間線和數(shù)據(jù)量,面對計(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è)置就依賴長期的系統(tǒng)開發(fā)經(jīng)驗(yàn),太大可能問題還會(huì)存在,太小又耗時(shí)過長。
“有問題不可怕,可怕的是沒有問題。當(dāng)問題發(fā)生時(shí),我們的選擇是正面‘硬剛’,出現(xiàn)一個(gè)消滅一個(gè)!”向宇談到。不難看出,也正是他們的這種不畏艱難,用“匠人”精神開發(fā)出華為云基礎(chǔ)設(shè)施重要組成部分,并且已經(jīng)服務(wù)15+內(nèi)部和外部客戶的華為云時(shí)序數(shù)據(jù)庫GaussDB(for Influx)。
原文標(biāo)題:爆文速遞| 華為云專家向宇:工欲善其事必先利其器,才能做數(shù)據(jù)的“管家”
文章出處:【微信公眾號(hào):華為開發(fā)者社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
責(zé)任編輯:pj
-
華為
+關(guān)注
關(guān)注
216文章
34470瀏覽量
251953 -
物聯(lián)網(wǎng)
+關(guān)注
關(guān)注
2909文章
44704瀏覽量
374013 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3816瀏覽量
64457 -
智慧家居
+關(guān)注
關(guān)注
1文章
83瀏覽量
16292
原文標(biāo)題:爆文速遞| 華為云專家向宇:工欲善其事必先利其器,才能做數(shù)據(jù)的“管家”
文章出處:【微信號(hào):Huawei_Developer,微信公眾號(hào):華為開發(fā)者社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論