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

 

 

我們公司主要從事平臺(tái)技術(shù)開(kāi)發(fā)和建設(shè)方面，工作的重點(diǎn)方向主要在解決用戶在數(shù)據(jù)治理中的各種問(wèn)題，讓用戶能更高效地管理自己的數(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ù)庫(kù)內(nèi)核到大數(shù)據(jù)平臺(tái)底層技術(shù)開(kāi)發(fā)，分享網(wǎng)易數(shù)據(jù)科學(xué)中心多年大數(shù)據(jù)建設(shè)經(jīng)驗(yàn)。

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

 

 

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

 

 

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

 

 

上圖是寫入對(duì)比，是一個(gè)普通的寫入測(cè)試，其主介質(zhì)是遞增型的，對(duì)于兩個(gè)都是一個(gè)順序讀寫過(guò)程;如果要完全對(duì)比還要測(cè)試 RFID 寫入測(cè)試，這樣能夠明顯反應(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 一般場(chǎng)景是替換 InnoDB 寫入，因?yàn)槠鋵懭胄阅�、壓縮性能更好、成本也更低。另一方面能夠解決 InnoDB 延遲不穩(wěn)定，替換大量的緩存應(yīng)用，只要其對(duì)相應(yīng)時(shí)間沒(méi)有特殊要求。

(1)大量數(shù)據(jù)寫入場(chǎng)景，比如日志、訂單等;

(2)需要高壓縮以便存儲(chǔ)更多的數(shù)據(jù)，Inno DB --> Inno Rocks;

(3)對(duì)寫入延遲波動(dòng)比較敏感，HBase --> Inno Rocks;

(4)相對(duì)較低的延遲要求 (10 ~ 50ms) 下替換緩存場(chǎng)景 (延遲 <5ms)，節(jié)省內(nèi)存成本， Redis --> Inno Rocks。

 

 

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

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

 

 

 

 

NTSDB 應(yīng)用場(chǎng)景很多，很多應(yīng)用都可以基于時(shí)序數(shù)據(jù)庫(kù)來(lái)做，最常見(jiàn)的就是監(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ò)規(guī)則引擎處理存儲(chǔ)在時(shí)序數(shù)據(jù)庫(kù)中。

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

 

 

我們大數(shù)據(jù)平臺(tái)整合了一些開(kāi)源社區(qū)的一些組件，內(nèi)部進(jìn)行一些產(chǎn)品化的改造和 bug 修復(fù)。最頂層是大數(shù)據(jù)接入層，作為大數(shù)據(jù)平臺(tái)，業(yè)務(wù)平臺(tái)很多數(shù)據(jù)來(lái)源于數(shù)據(jù)庫(kù)，也有很大一部分來(lái)源于日志。通過(guò) NDC 做全量數(shù)據(jù)導(dǎo)入，如有些數(shù)據(jù)在 Oracle 中，通過(guò) NDC 導(dǎo)入，后續(xù)可以通過(guò)數(shù)據(jù)變更來(lái)進(jìn)行同步，還有一個(gè)通過(guò) 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ì)介紹。接下來(lái)介紹自助分析里面應(yīng)用的一個(gè)插件 Impala，以及分布式存儲(chǔ)系統(tǒng)中的 Kudu 平臺(tái)。

 

 

 

 

應(yīng)用 Impala 目標(biāo)是解決大數(shù)據(jù)量下的 ad-hoc 查詢問(wèn)題，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)都是無(wú)狀態(tài)節(jié)點(diǎn)，節(jié)點(diǎn)查詢地位一樣，查詢無(wú)論發(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è)返回。基本所有的 MPP 架構(gòu)都是類似。

 

 

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

 

 

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

 

 

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

(1)首先是基于 Zookeeper 的 Load Balance 機(jī)制;

(2)管理服務(wù)解決 SQL 無(wú)法持續(xù)化問(wèn)題，管理服務(wù)器保存最近幾天的 SQL 和執(zhí)行過(guò)程，便于后續(xù) SQL 審計(jì)，超時(shí) SQL 自動(dòng) kill;

(3)管理權(quán)限將底層權(quán)限分的很細(xì);

(4)元數(shù)據(jù)緩存問(wèn)題，增加與 Hive 的元數(shù)據(jù)同步功能，Hive 記錄元數(shù)據(jù)變更，Impala 拉取變更自動(dòng)同步，這種只能緩解元數(shù)據(jù)爆炸問(wèn)題。

遺留的問(wèn)題就是元數(shù)據(jù)容量，過(guò)濾智能解決部分問(wèn)題;還有一個(gè)就是底層 IO 問(wèn)題，因?yàn)殡x線寫入和 Impala 查詢是同一份數(shù)據(jù)，如果寫入吃掉很多 IO，查詢就會(huì)出現(xiàn)問(wèn)題。離線本身對(duì) IO 敏感很低。除此之外我們還引入了 ES 技術(shù)，公司 ES 業(yè)務(wù)也有很多，碰到問(wèn)題就是 ES 在 SQL 支持方面不是很好，目前我們的 Impala 支持一些 ES 的查詢。

Kudu 用于解決離線數(shù)據(jù)實(shí)時(shí)性問(wèn)題，HDFS 存 K-v 數(shù)據(jù)，類似 IOAP 訪問(wèn)，Hive 是來(lái)做離線分析的，Kudu 就是想同時(shí)做這兩件事情的背景下產(chǎn)生的。行為數(shù)據(jù)是在離線平臺(tái)上，用戶數(shù)據(jù)是實(shí)時(shí)在數(shù)據(jù)庫(kù)中，如快遞行業(yè)經(jīng)常需要追蹤快遞的位置，離線平臺(tái)就要經(jīng)常做自助分析，需要將數(shù)據(jù)庫(kù)中的狀態(tài)實(shí)時(shí)同步到離線平臺(tái)上去。目前做法就是數(shù)據(jù)庫(kù)批量寫入 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ù)庫(kù)形式，Impala 既能訪問(wèn) Hive 中的數(shù)據(jù)，也能訪問(wèn) Kudu 中的數(shù)據(jù)，這樣的好處是兩邊的數(shù)據(jù)可以進(jìn)行聯(lián)合查詢。Kudu 現(xiàn)在也支持 Spark，也可以直接通過(guò) API 訪問(wèn)。上圖是 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 沒(méi)有就對(duì)照的做。

 

 

 

 

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

 

 

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

 

 

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

作者：蔣鴻翔，2011 年加入網(wǎng)易，網(wǎng)易數(shù)據(jù)科學(xué)中心首席架構(gòu)師。

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。