摘要：特點(diǎn)有聚合運(yùn)算相關(guān)算法，時(shí)序數(shù)據(jù)庫相對(duì)于關(guān)系型數(shù)據(jù)庫沒有特別復(fù)雜的查詢，最常見的使用類型是寬表使用，在此基礎(chǔ)上做一些聚合算法插值查詢。

首先簡單介紹一下網(wǎng)易杭州研究院情況簡介，如下圖所示：

我們公司主要從事平臺(tái)技術(shù)開發(fā)和建設(shè)方面，工作的重點(diǎn)方向主要在解決用戶在數(shù)據(jù)治理中的各種問題，讓用戶能更高效地管理自己的數(shù)據(jù)，進(jìn)而產(chǎn)生更大的價(jià)值，比如如何整合現(xiàn)有功能流程，節(jié)省用戶使用成本；增加新平臺(tái)不斷調(diào)研，豐富平臺(tái)功能；新平臺(tái)功能、性能改造，從而滿足用戶大規(guī)模使用需求；根據(jù)業(yè)務(wù)實(shí)際需求，輸出相應(yīng)解決方案等。今天分享的內(nèi)容主要是從數(shù)據(jù)庫內(nèi)核到大數(shù)據(jù)平臺(tái)底層技術(shù)開發(fā)，分享網(wǎng)易數(shù)據(jù)科學(xué)中心多年大數(shù)據(jù)建設(shè)經(jīng)驗(yàn)。

1.數(shù)據(jù)庫技術(shù)

數(shù)據(jù)技術(shù)主要有InnoSQL和NTSDB，NTSDB是最近研發(fā)的新產(chǎn)品，預(yù)計(jì)明年將向外推薦此產(chǎn)品，InnoSQL屬于MySQL分支方面的研究大概從2011年開始的，InnoSQL的主要目標(biāo)是提供更好的性能以及高可用性，同時(shí)便于DBA的運(yùn)維以及監(jiān)控管理。

RocksDB是以樹的形式組織數(shù)據(jù)的產(chǎn)品，MySQL有一個(gè)MyRocks產(chǎn)品，我們內(nèi)部將其集成到InnoSQL分支上。這樣做的原因是公司有很多業(yè)務(wù)，很多都是利用緩存保持其延遲，其規(guī)模會(huì)越來越大，這樣就導(dǎo)致緩存、內(nèi)存成本很高；其業(yè)務(wù)對(duì)延遲要求不是特別高，但要保持延遲穩(wěn)定（小于50毫秒）。RocksDB能夠很好地將緩存控制的很好，隨著緩存越來越大，有的公司會(huì)將其放到HBase上，但是其延遲有時(shí)波動(dòng)會(huì)很大，如小米HBase很強(qiáng)，但還是做了一個(gè)基于K-V模式的緩存處理，主要解決延遲波動(dòng)問題。我們主要是基于開源產(chǎn)品來解決，如將RocksDB集成起來解決公司業(yè)務(wù)對(duì)延遲穩(wěn)定的一些需求。InnoRocks由于是基于LSM，因此對(duì)寫入支持非常好，后續(xù)有內(nèi)部測試數(shù)據(jù)可以展示。還有就是LSM壓縮比很高，網(wǎng)易一種是替換緩存，一種是普通數(shù)據(jù)庫存儲(chǔ)，目前還是用InnoDB存儲(chǔ)，如果用InnoRocks存儲(chǔ)會(huì)節(jié)省很多存儲(chǔ)空間；還有一個(gè)就是結(jié)合DB做擴(kuò)展，將其集成到公司內(nèi)部。

上圖是寫入對(duì)比，是一個(gè)普通的寫入測試，其主介質(zhì)是遞增型的，對(duì)于兩個(gè)都是一個(gè)順序讀寫過程；如果要完全對(duì)比還要測試RFID寫入測試，這樣能夠明顯反應(yīng)RocksDB和InnoDB的差距。圖中RocksDB寫入性能比InnoDB要好，讀取性能InnoDB性能比RocksDB。300GB原始數(shù)據(jù)，分別導(dǎo)入到Inno DB(未壓縮)和Inno Rocks后的存儲(chǔ)容量對(duì)比，Inno DB為315GB左右，Inno Rocks為50 ~ 60GB，存儲(chǔ)容量是Inno DB的20%到30%。

InnoRock一般場景是替換InnoDB寫入，因?yàn)槠鋵懭胄阅?、壓縮性能更好、成本也更低。另一方面能夠解決InnoDB延遲不穩(wěn)定，替換大量的緩存應(yīng)用，只要其對(duì)相應(yīng)時(shí)間沒有特殊要求。

（1）大量數(shù)據(jù)寫入場景，比如日志、訂單等；
（2）需要高壓縮以便存儲(chǔ)更多的數(shù)據(jù)，Inno DB --> Inno Rocks；
（3）對(duì)寫入延遲波動(dòng)比較敏感，HBase --> Inno Rocks；
（4）相對(duì)較低的延遲要求(10 ~ 50ms)下替換緩存場景(延遲<5ms)，節(jié)省內(nèi)存成本， Redis --> Inno Rocks。

InnoSQL是MySQL一個(gè)分支，同時(shí)還做了一個(gè)時(shí)序數(shù)據(jù)庫。其不依賴第三方存儲(chǔ)，重新做了一套。其架構(gòu)也是列式存儲(chǔ)，支持倒排索引等不同索引組織形式。對(duì)大型數(shù)據(jù)公司時(shí)序數(shù)據(jù)庫集中在訪問時(shí)通過什么去訪問，我們提供SQL層給外部應(yīng)用去訪問，應(yīng)用簡單。

NTSDB特點(diǎn)有聚合運(yùn)算相關(guān)算法，時(shí)序數(shù)據(jù)庫相對(duì)于關(guān)系型數(shù)據(jù)庫沒有特別復(fù)雜的查詢，最常見的使用類型是寬表使用，在此基礎(chǔ)上做一些聚合算法、插值查詢。

NTSDB應(yīng)用場景很多，很多應(yīng)用都可以基于時(shí)序數(shù)據(jù)庫來做，最常見的就是監(jiān)控系統(tǒng)，有一些外部應(yīng)用也會(huì)對(duì)接監(jiān)控系統(tǒng)。外部應(yīng)用中，現(xiàn)在RIT比較火，時(shí)序是其中比較重要的一環(huán)，很多設(shè)備目前都需要聯(lián)網(wǎng)，數(shù)據(jù)的產(chǎn)生都是以時(shí)間的形式產(chǎn)生，有的通過規(guī)則引擎處理存儲(chǔ)在時(shí)序數(shù)據(jù)庫中。

2.大數(shù)據(jù)技術(shù)

我們大數(shù)據(jù)平臺(tái)整合了一些開源社區(qū)的一些組件，內(nèi)部進(jìn)行一些產(chǎn)品化的改造和bug修復(fù)。最頂層是大數(shù)據(jù)接入層，作為大數(shù)據(jù)平臺(tái)，業(yè)務(wù)平臺(tái)很多數(shù)據(jù)來源于數(shù)據(jù)庫，也有很大一部分來源于日志。通過NDC做全量數(shù)據(jù)導(dǎo)入，如有些數(shù)據(jù)在Oracle中，通過NDC導(dǎo)入，后續(xù)可以通過數(shù)據(jù)變更來進(jìn)行同步，還有一個(gè)通過dataStream將日志數(shù)據(jù)錄入大數(shù)據(jù)平臺(tái)。數(shù)據(jù)存儲(chǔ)層大都差不多，都用HDFS 存儲(chǔ)，搭載一些HBase分布式存儲(chǔ)；數(shù)據(jù)計(jì)算大都是離線計(jì)算平臺(tái)，內(nèi)存計(jì)算是基于Spark；數(shù)據(jù)加工和一般大數(shù)據(jù)平臺(tái)都差不多，我們加入了自助分析、任務(wù)運(yùn)維，后續(xù)會(huì)詳細(xì)介紹。接下來介紹自助分析里面應(yīng)用的一個(gè)插件Impala，以及分布式存儲(chǔ)系統(tǒng)中的Kudu平臺(tái)。

應(yīng)用Impala目標(biāo)是解決大數(shù)據(jù)量下的ad-hoc查詢問題，ad-hoc是介于OITP和OIAP中間的一層，OITP是響應(yīng)層很快，毫秒級(jí)；OIAP查詢有時(shí)會(huì)耗時(shí)很久。ad-hoc定位與1分鐘到幾分鐘，現(xiàn)在很多業(yè)務(wù)需要ad-hoc提供，如公司報(bào)表，有時(shí)需要實(shí)時(shí)計(jì)算，響應(yīng)在5秒-1分鐘延遲。

Impala架構(gòu)特點(diǎn)就是每一個(gè)節(jié)點(diǎn)都是無狀態(tài)節(jié)點(diǎn)，節(jié)點(diǎn)查詢地位一樣，查詢無論發(fā)送到哪一個(gè)節(jié)點(diǎn)都可以生成查詢計(jì)劃、產(chǎn)生結(jié)果。查詢打到哪一個(gè)節(jié)點(diǎn)就能生成執(zhí)行計(jì)劃，將對(duì)應(yīng)的節(jié)點(diǎn)分配給對(duì)應(yīng)的處理節(jié)點(diǎn)，將所有節(jié)點(diǎn)返回后做一個(gè)規(guī)則，然后做一個(gè)返回?；舅械腗PP架構(gòu)都是類似。

選擇Impala而不選擇其他工具的原因：首先它有元數(shù)據(jù)緩存，好處是節(jié)點(diǎn)緩存元數(shù)據(jù)做查詢時(shí)不用再去獲取元數(shù)據(jù)，缺點(diǎn)就是元數(shù)據(jù)爆炸問題；再者就是Impala兼容Hive，元數(shù)據(jù)可以和Hive共享；同時(shí)還支持很多算子下推。Impala最好使用方式是通過Impala自己insert然后通過其自己去查，實(shí)際過程是通過Hive和Spark寫入大數(shù)據(jù)平臺(tái)，通過Impala來做查詢。這種方式有些限制就是寫入時(shí)Impala無法感知寫入，還有在Hive更改元數(shù)據(jù)，Impala能讀取數(shù)據(jù)但是無法動(dòng)態(tài)感知，為了解決這個(gè)問題官方提供手動(dòng)刷新操作。

Impala缺陷就是所有節(jié)點(diǎn)都是MPP結(jié)構(gòu)，沒有統(tǒng)一的Master入口，負(fù)載均衡不易控制。底層數(shù)據(jù)權(quán)限粒度控制不夠，HDFS轉(zhuǎn)HBase是以同級(jí)HBase身份訪問，Impala訪問底層需要以Impala身份訪問。這種問題尤其在同一平臺(tái)下分有很多業(yè)務(wù)時(shí)，用Hive寫數(shù)據(jù)時(shí)，訪問權(quán)限就會(huì)有問題，因此我們?cè)趦?nèi)部權(quán)限訪問方面做了改造。每個(gè)coordinator節(jié)點(diǎn)都能接收SQL，沒有集中統(tǒng)一的SQL管理，如果掛掉所有歷史信息都無法追蹤。

我們基于Impala問題做了相應(yīng)整改：

（1）首先是基于Zookeeper的Load Balance機(jī)制；
（2）管理服務(wù)解決SQL無法持續(xù)化問題，管理服務(wù)器保存最近幾天的SQL和執(zhí)行過程，便于后續(xù)SQL審計(jì)，超時(shí)SQL自動(dòng)kill；
（3）管理權(quán)限將底層權(quán)限分的很細(xì)；
（4）元數(shù)據(jù)緩存問題，增加與Hive的元數(shù)據(jù)同步功能，Hive記錄元數(shù)據(jù)變更，Impala拉取變更自動(dòng)同步，這種只能緩解元數(shù)據(jù)爆炸問題。
遺留的問題就是元數(shù)據(jù)容量，過濾智能解決部分問題；還有一個(gè)就是底層IO問題，因?yàn)殡x線寫入和Impala查詢是同一份數(shù)據(jù)，如果寫入吃掉很多IO，查詢就會(huì)出現(xiàn)問題。離線本身對(duì)IO敏感很低。除此之外我們還引入了ES技術(shù)，公司ES業(yè)務(wù)也有很多，碰到問題就是ES在SQL支持方面不是很好，目前我們的Impala支持一些ES的查詢。

Kudu用于解決離線數(shù)據(jù)實(shí)時(shí)性問題，HDFS存K-v數(shù)據(jù)，類似IOAP訪問，Hive是來做離線分析的，Kudu就是想同時(shí)做這兩件事情的背景下產(chǎn)生的。行為數(shù)據(jù)是在離線平臺(tái)上，用戶數(shù)據(jù)是實(shí)時(shí)在數(shù)據(jù)庫中，如快遞行業(yè)經(jīng)常需要追蹤快遞的位置，離線平臺(tái)就要經(jīng)常做自助分析，需要將數(shù)據(jù)庫中的狀態(tài)實(shí)時(shí)同步到離線平臺(tái)上去。目前做法就是數(shù)據(jù)庫批量寫入Hive表中，同時(shí)你的批量不能太小，容易產(chǎn)生很多小文件，這樣可能造成數(shù)據(jù)實(shí)時(shí)性很差，一般是半小時(shí)到一小時(shí)的延遲。大部分業(yè)務(wù)可接受，但是對(duì)于對(duì)延遲敏感的業(yè)務(wù)可能不支持，Kudu就是解決半小時(shí)到一小時(shí)的數(shù)據(jù)實(shí)時(shí)性。

Kudu是一個(gè)存儲(chǔ)平臺(tái)，不依賴于任何第三方存儲(chǔ)系統(tǒng)，目前更類似于數(shù)據(jù)庫形式，Impala既能訪問Hive中的數(shù)據(jù)，也能訪問Kudu中的數(shù)據(jù)，這樣的好處是兩邊的數(shù)據(jù)可以進(jìn)行聯(lián)合查詢。Kudu現(xiàn)在也支持Spark，也可以直接通過API訪問。上圖是Kudu的結(jié)構(gòu)劃分到內(nèi)部數(shù)據(jù)組織形式，Kudu支持Tablelet操作而HDFS不支持。前面的結(jié)構(gòu)和HBase挺像，不同的是數(shù)據(jù)組織形式是不一樣的，Kudu可以做一些分析性的業(yè)務(wù)查詢。最主要的區(qū)別是數(shù)據(jù)存儲(chǔ)格式不一樣，Kudu是Column Family級(jí)別列存，先整個(gè)切一塊然后再做列組形式。

Kudu跟HDFS相比性能還是有差距，Kudu由于需要支持update，在內(nèi)存 & 磁盤上數(shù)據(jù)的存儲(chǔ)采用Base + delta形式，Base記錄基本的數(shù)據(jù)，delta記錄修改的數(shù)據(jù)，所以數(shù)據(jù)讀取時(shí)需要同時(shí)讀取Base + delta兩部分?jǐn)?shù)據(jù)。

Kudu優(yōu)化主要是：

（1）支持Kudu tablet的split；
（2）支持指定列的TTL功能；
（3）支持Kudu數(shù)據(jù)Runtime Filter功能；
（4）支持Kudu創(chuàng)建Bitmap索引。
我們主要是按照HBase進(jìn)行優(yōu)化，在有需要情況下優(yōu)化，HBase有而Kudu沒有就對(duì)照的做。

Impala里面對(duì)HDFS有一個(gè)Runtime Filter功能，Kudu表上沒有，我們先分析下它到底有什么作用，是不是有性能上的改進(jìn)，將其移植過來。Runtime Filter主要是用在大表和小表做關(guān)聯(lián)時(shí)使用，在關(guān)聯(lián)時(shí)做成hash表，綁定到所有大表節(jié)點(diǎn)上去，在大表掃數(shù)據(jù)時(shí)利用hash表做過濾，因此在底層掃描就已經(jīng)過濾掉很多數(shù)據(jù)，就可以省略很多不必要的計(jì)算。上圖是Kudu的是否有Runtime Filter的結(jié)果對(duì)比，可以看出減少了很多計(jì)算量，原先需要幾秒，現(xiàn)在只需秒級(jí)顯示結(jié)果。結(jié)果對(duì)比有了很大的改進(jìn)，雖然還是有差距，目前也在改進(jìn)，目標(biāo)是和Impala相差不是很大。

還有一個(gè)場景就是在Kudu上做Bitmap索引，主要面向的業(yè)務(wù)是寬表的多維過濾，有些表的查詢會(huì)依據(jù)后面的實(shí)例去確定查詢，這種用Bitmap做比一個(gè)個(gè)找出來查詢性能要優(yōu)越很多。另一個(gè)好處就是group by，因?yàn)槠湟獙⑾嗤愋秃喜⒌揭涣?，主要是做hash或者排序，這種查詢會(huì)很快，而不用做全局排序。Bitmap應(yīng)用的限制就是數(shù)據(jù)離散性不能太好，dinstct count的值不能太多，向數(shù)據(jù)庫中主鍵不適合做Bitmap，像省份等值比較少的適合做Bitmap。

應(yīng)用后用TPC-H中的一張表測試，Bitmap主要應(yīng)用多維場景過濾，從一列過濾、兩列過濾、到五維過濾整個(gè)表現(xiàn)很好，性能提升有十幾倍提升。如果數(shù)據(jù)從數(shù)據(jù)庫導(dǎo)入大數(shù)據(jù)平臺(tái)離線分析其實(shí)時(shí)性比較慢，主要局限小文件以及導(dǎo)入批量大小問題,利用Kudu就不用考慮，可以直接通過Kudu實(shí)現(xiàn)數(shù)據(jù)變更導(dǎo)入大數(shù)據(jù)支持實(shí)時(shí)聯(lián)查。而且可以實(shí)時(shí)同步Oracle和MySQL數(shù)據(jù)到Kudu中，進(jìn)行聯(lián)查就可以了，如果沒有就需要同步查詢可能需要半小時(shí)才能返回結(jié)果。

作者介紹：

蔣鴻翔，2011年加入網(wǎng)易，網(wǎng)易數(shù)據(jù)科學(xué)中心首席架構(gòu)師?！禡ySQL內(nèi)核：InnoDB存儲(chǔ)引擎卷1》作者之一，網(wǎng)易數(shù)據(jù)庫內(nèi)核和數(shù)據(jù)倉庫平臺(tái)負(fù)責(zé)人，長期從事數(shù)據(jù)庫內(nèi)核技術(shù)和大數(shù)據(jù)平臺(tái)底層技術(shù)開發(fā)，主導(dǎo)網(wǎng)易數(shù)據(jù)庫內(nèi)核整體技術(shù)方案和大數(shù)據(jù)平臺(tái)先進(jìn)技術(shù)調(diào)研和實(shí)現(xiàn)，先后主導(dǎo)了內(nèi)部MySQL分支InnoSQL、HBase、自研時(shí)序數(shù)據(jù)庫、自研實(shí)時(shí)數(shù)據(jù)倉庫等各種不同的平臺(tái)，具有豐富的數(shù)據(jù)庫內(nèi)核和大數(shù)據(jù)平臺(tái)相關(guān)經(jīng)驗(yàn)。

分享嘉賓：蔣鴻翔 網(wǎng)易 數(shù)據(jù)科學(xué)中心 首席架構(gòu)師
內(nèi)容來源：DataFun Talk《網(wǎng)易數(shù)據(jù)基礎(chǔ)平臺(tái)建設(shè)》
出品社區(qū)：DataFun
點(diǎn)擊免費(fèi)試用網(wǎng)易猛犸一站式大數(shù)據(jù)管理和應(yīng)用開發(fā)平臺(tái)服務(wù)

文章來源： 網(wǎng)易云社區(qū)