http://www.sohu.com/a/126082450_355140

目前大數(shù)據(jù)存儲(chǔ)查詢方案大概可以分為：Hbase系、Dremel系、預(yù)聚合系、Lucene系，本文作者將就自身的使用經(jīng)驗(yàn)說(shuō)說(shuō)這幾個(gè)系的優(yōu)缺點(diǎn)，如有紕漏，歡迎一起探討。

寫在前面

近些年，大數(shù)據(jù)背后的價(jià)值也開始得到關(guān)注和重視，越來(lái)越多的企業(yè)開始保存和分析數(shù)據(jù)，希望從中挖掘大數(shù)據(jù)的價(jià)值。大數(shù)據(jù)產(chǎn)生的根本還是增量數(shù)據(jù)，單純的用戶數(shù)據(jù)不足以構(gòu)成大數(shù)據(jù)，然而用戶的行為或行為相關(guān)的日志的數(shù)據(jù)量，加之隨著物聯(lián)網(wǎng)的發(fā)力，產(chǎn)生的增量數(shù)據(jù)將不可預(yù)估，存儲(chǔ)和查詢?cè)隽繑?shù)據(jù)尤為關(guān)鍵。所以，在筆者的工作經(jīng)歷中，本著以下的目標(biāo)，尋找更優(yōu)的大數(shù)據(jù)存儲(chǔ)和查詢方案：

數(shù)據(jù)無(wú)損：數(shù)據(jù)分析挖掘都依賴于我們保存的數(shù)據(jù)，只有做到數(shù)據(jù)的無(wú)損，才有可能任意的定義指標(biāo)，滿足各種業(yè)務(wù)需求。

保證數(shù)據(jù)實(shí)時(shí)性：數(shù)據(jù)的實(shí)時(shí)性越來(lái)越重要，實(shí)時(shí)的數(shù)據(jù)能夠更好的運(yùn)維產(chǎn)品和調(diào)整策略，價(jià)值更高。單進(jìn)程每秒接入3.5萬(wàn)數(shù)據(jù)以上，數(shù)據(jù)從產(chǎn)生到能夠查詢到結(jié)果這個(gè)間隔不會(huì)超過(guò)5秒。

業(yè)務(wù)需求快速響應(yīng)：隨著越來(lái)越快的業(yè)務(wù)發(fā)展和數(shù)據(jù)應(yīng)用要求的提高，數(shù)據(jù)的查詢需要更靈活，快速響應(yīng)不同且多變的需求。最好是任意定義指標(biāo)后能夠?qū)崟r(shí)查詢出結(jié)果。

數(shù)據(jù)靈活探索性：探索性數(shù)據(jù)分析在對(duì)數(shù)據(jù)進(jìn)行概括性描述，發(fā)現(xiàn)變量之間的相關(guān)性以及引導(dǎo)出新的假設(shè)。到了大數(shù)據(jù)時(shí)代，海量的無(wú)結(jié)構(gòu)、半結(jié)構(gòu)數(shù)據(jù)從多種渠道源源不斷地積累，不受分析模型和研究假設(shè)的限制，如何從中找出規(guī)律并產(chǎn)生分析模型和研究假設(shè)成為新挑戰(zhàn)。因此，探索性數(shù)據(jù)分析成為大數(shù)據(jù)分析中不可缺少的一步并且走向前臺(tái)。

超大數(shù)據(jù)集，統(tǒng)計(jì)分析秒級(jí)響應(yīng)：萬(wàn)億數(shù)據(jù)量級(jí)，千級(jí)維度（非稀疏）的統(tǒng)計(jì)分析秒級(jí)響應(yīng)。

目前大數(shù)據(jù)存儲(chǔ)查詢方案大概可以分為：Hbase系、Dremel系、預(yù)聚合系、Lucene系，筆者就自身的使用經(jīng)驗(yàn)說(shuō)說(shuō)這幾個(gè)系的優(yōu)缺點(diǎn)，如有紕漏，歡迎一起探討。

數(shù)據(jù)查詢包括大體可以分為兩步，首先根據(jù)某一個(gè)或幾個(gè)字段篩選出符合條件的數(shù)據(jù)，然后根據(jù)關(guān)聯(lián)填充其他所需字段信息或者聚合其他字段信息，本文中提到的大數(shù)據(jù)技術(shù)，都將圍繞這兩方面。

一、Hbase系

筆者認(rèn)為Hbase系的解決方案（例如Opentsdb和Kylin）適合相對(duì)固定的業(yè)務(wù)報(bào)表類需求，只需要統(tǒng)計(jì)少量維度即可滿足業(yè)務(wù)報(bào)表需求，對(duì)于單值查詢有優(yōu)勢(shì)，但很難滿足靈活聚合數(shù)據(jù)的場(chǎng)景。

Hbase的表包含的的概念有rowkey、列簇、列限定符、版本(timestamp)和值，對(duì)應(yīng)實(shí)際Hdfs的存儲(chǔ)結(jié)構(gòu)可以用下圖做一個(gè)簡(jiǎn)單總結(jié)：

Hbase表中的每一個(gè)列簇會(huì)對(duì)應(yīng)一個(gè)實(shí)際的文件，某種層面來(lái)說(shuō)，Hbase并非真正意義的列式存儲(chǔ)方案，只是列簇存儲(chǔ)。每個(gè)文件有若干個(gè)DataBlock(數(shù)據(jù)塊默認(rèn)64k)，DataBlock是HBase中數(shù)據(jù)存儲(chǔ)的最小單元，DataBlock中以KeyValue的方式存儲(chǔ)用戶數(shù)據(jù)（KeyValue后面有timestamp，圖中未標(biāo)注），其他信息主要包含索引、元數(shù)據(jù)等信息，在此不做深入探討。每個(gè)KeyValue都由4個(gè)部分構(gòu)成，分別為key length，value length，key和value。其中key的結(jié)構(gòu)相對(duì)復(fù)雜，包括rowkey、列、KeyType等信息，而value值對(duì)應(yīng)具體列值的二進(jìn)制數(shù)據(jù)。為了便于查詢，對(duì)key做了一個(gè)簡(jiǎn)單的倒排索引，直接使用了java的ConcurrentSkipListMap。

Hbase管理的核心思想是分級(jí)分塊，存儲(chǔ)時(shí)根據(jù)Rowkey的范圍不同，分散到不同的Region，Region又按照列簇分為不同的Store，每個(gè)Store實(shí)際上又包括StoreFile(對(duì)應(yīng)Hfile)和MemStore，然后由RegionServer管理不同的Region，RegionServer即對(duì)應(yīng)具體的進(jìn)程，分散不同的機(jī)器，提供分布式的存儲(chǔ)和查詢。查詢時(shí)，首先獲取meta表（一種特殊的Region）所在的RegionServer，通過(guò)meta表查找表rowkey相對(duì)應(yīng)的Region和RegionServer信息，最后連接數(shù)據(jù)所在的RegionServer，查找到相應(yīng)的數(shù)據(jù)。

Hbase的這種結(jié)構(gòu)，特別適合根據(jù)rowkey做單值查詢，不適合scan的場(chǎng)景，因?yàn)榇蟛糠諷can的情況基本上需要掃描所有數(shù)據(jù)，性能會(huì)非常差。雖然也有擴(kuò)展的Hbase二級(jí)索引方案，但基本上都是通過(guò)協(xié)處理器，需要另外建立一份rowkey的對(duì)應(yīng)關(guān)系，Scan的時(shí)候先通過(guò)二級(jí)索引查找rowkey，然后在根據(jù)rowkey查找相應(yīng)的數(shù)據(jù)。

這種方式一定程度上能加快數(shù)據(jù)掃描，但那對(duì)于一些識(shí)別度不高的列，如性別這樣的字段，對(duì)應(yīng)的rowkey相當(dāng)之多，這樣的字段在查找二級(jí)索引時(shí)的作用很小，另外二級(jí)索引所帶來(lái)的IO性能的開銷都會(huì)隨之增加。而在需要聚合的場(chǎng)景，對(duì)于Hbase而言恰恰需要大量scan數(shù)據(jù)，會(huì)非常影響性能。Hbase只有一個(gè)簡(jiǎn)單rowkey的倒排索引，缺少列索引，所有的查詢和聚合只能依賴于rowkey，很難解決聚合的性能問(wèn)題。

隨著Hbase的發(fā)展，基于Hbase做數(shù)據(jù)存儲(chǔ)包括Opentsdb和Kylin也隨之產(chǎn)生，例如Kylin也是一種預(yù)聚合方案，因其底層存儲(chǔ)使用Hbase，故筆者將其歸為Hbase系。在筆者看來(lái)，Opentsdb和Kylin的數(shù)據(jù)結(jié)構(gòu)極其相似，都是將各種維度值組合，結(jié)合時(shí)間戳拼成rowkey，利用字典的原理將維度值標(biāo)簽化，達(dá)到壓縮的目的。如此，可以滿足快速查詢數(shù)據(jù)的需要，但同時(shí)也會(huì)受限于Hbase索引，聚合需要大量scan，并不能提升數(shù)據(jù)聚合的速度。

為了避免查詢數(shù)據(jù)時(shí)的聚合，Kylin可以通過(guò)cube的方式定制數(shù)據(jù)結(jié)構(gòu)，在數(shù)據(jù)接入時(shí)通過(guò)指定metric來(lái)提前聚合數(shù)據(jù)。這樣雖然在一定程度上解決了數(shù)據(jù)聚合慢的情況，但這是一種典型的空間換時(shí)間的方案，組合在維度多、或者有高基數(shù)維度的情況，數(shù)據(jù)膨脹會(huì)非常嚴(yán)重，筆者曾遇到存儲(chǔ)后的數(shù)據(jù)比原始數(shù)據(jù)大90倍的情況。另外，業(yè)務(wù)的變化會(huì)導(dǎo)致重建cube，難以靈活的滿足業(yè)務(wù)需要。

二、Dremel系

Parquet作為Dremel系的代表，相對(duì)Hbase的方案，Scan的性能更好，也避免了存儲(chǔ)索引和生成索引的開銷。但對(duì)于數(shù)據(jù)還原和聚合，相對(duì)直接使用正向索引來(lái)說(shuō)成本會(huì)很高，而且以離線處理為主，很難提高數(shù)據(jù)寫的實(shí)時(shí)性。

Google的Dremel，其最早用于網(wǎng)頁(yè)文檔數(shù)據(jù)分析，所以設(shè)計(jì)為嵌套的數(shù)據(jù)結(jié)構(gòu)，當(dāng)然它也可以用于扁平的二維表數(shù)據(jù)存儲(chǔ)。開源技術(shù)中，Parquet算是Dremel系的代表，各種查詢引擎(Hive/Impala/Drill)、計(jì)算框架甚至一些序列化結(jié)構(gòu)數(shù)據(jù)（如ProtoBuf）都對(duì)其進(jìn)行了支持，甚至Spark還專門針對(duì)Parquet的數(shù)據(jù)格式進(jìn)行了優(yōu)化，前途一片光明，本文主要結(jié)合Parquet來(lái)展開論述。

可以用下圖簡(jiǎn)單表示Parquet的文件格式：

Parquet的數(shù)據(jù)水平切分為多個(gè)Row Group，Row Group為數(shù)據(jù)讀寫的緩存單元，每個(gè)Row Group包含各個(gè)的數(shù)據(jù)列(Column Chunk)，數(shù)據(jù)列有若干Page，Page是壓縮和編碼的單元，其相應(yīng)存儲(chǔ)的信息包括元數(shù)據(jù)信息(PageHeader)、重復(fù)深度(Repetition Levels)、定義深度(Definition Levels)和列值(Values)信息。

Page實(shí)際有三種類型：數(shù)據(jù)Page、字典Page和索引Page。數(shù)據(jù)Page用于存儲(chǔ)當(dāng)前行組中該列的值，字典Page存儲(chǔ)該列值的編碼字典，每一個(gè)列塊中最多包含一個(gè)字典Page，索引Page目前還不支持，未來(lái)可能會(huì)引入Bloom Filter，能夠判斷列值是否存在，更有利于判斷搜索條件，提升查詢速度。

從Parquet的存儲(chǔ)結(jié)構(gòu)來(lái)看，Parquet沒(méi)有嚴(yán)格意義上的索引，在查詢的過(guò)程中需要直接對(duì)Row Group的列數(shù)據(jù)進(jìn)行掃描，有兩方面來(lái)保證查詢優(yōu)化，一個(gè)是映射下推(Project PushDown)，另外一個(gè)是謂詞下推(Predicate PushDown)。

映射下推主要是利用列式存儲(chǔ)的優(yōu)勢(shì)，查詢數(shù)據(jù)時(shí)只需要掃描查詢中需要的列，由于每一列的所有值都是連續(xù)存儲(chǔ)的，所以分區(qū)取出每一列的所有值就可以實(shí)現(xiàn)TableScan算子，而避免掃描整個(gè)文件內(nèi)容。

謂詞下推在數(shù)據(jù)庫(kù)之類的查詢系統(tǒng)中最常用的優(yōu)化手段之一，通過(guò)將一些過(guò)濾條件盡可能的在最底層執(zhí)行，減少上層交互的數(shù)據(jù)量，從而提升性能。另外，針對(duì)謂詞下推Parquet做了更進(jìn)一步的優(yōu)化，優(yōu)化的方法是對(duì)每一個(gè)Row Group的每一個(gè)Column Chunk在存儲(chǔ)的時(shí)候都計(jì)算對(duì)應(yīng)的統(tǒng)計(jì)信息，包括該Column Chunk的最大值、最小值和空值個(gè)數(shù)。通過(guò)這些統(tǒng)計(jì)值和該列的過(guò)濾條件可以判斷該Row Group是否需要掃描。未來(lái)還會(huì)增加諸如Bloom Filter和Index等優(yōu)化數(shù)據(jù)，更加有效的完成謂詞下推。

通過(guò)這兩方面的優(yōu)化，Parquet的查詢時(shí)掃描數(shù)據(jù)的性能能夠得到大幅度提升。那Parquet如果填充數(shù)據(jù)（不同的列拼成一行記錄）和聚合數(shù)據(jù)呢？

主要是使用了Striping/Assembly算法實(shí)現(xiàn)的，該算法的思想是將數(shù)據(jù)的值分為三部分：重復(fù)深度(Repetition Levels)、定義深度(Definition Levels)和列值(Values)。通過(guò)重復(fù)深度可以在讀取的時(shí)候結(jié)合Schema的定義可以知道需要在哪一層創(chuàng)建一個(gè)新的repeated節(jié)點(diǎn)（如第一層的的為0，表示是新記錄，否則則表示repeat的數(shù)據(jù)），然后通過(guò)定義深度知道該值的路徑上第幾層開始是未定義，從而還原出數(shù)據(jù)的嵌套結(jié)構(gòu)，如此便能清楚的把一行數(shù)據(jù)還原出來(lái)。由于缺少行號(hào)對(duì)應(yīng)的列正向索引，沒(méi)有辦法直接尋址，單純的依賴于Striping/Assembly算法還原數(shù)據(jù)或者聚合處理，相對(duì)來(lái)說(shuō)成本會(huì)高很多。

另外，Parquet的實(shí)時(shí)寫方面是硬傷，基于Parquet的方案基本上都是批量寫。一般情況，都是定期生成Parquet文件，所以數(shù)據(jù)延遲比較嚴(yán)重。為了提高數(shù)據(jù)的實(shí)時(shí)性，還需要其他解決方案來(lái)解決數(shù)據(jù)實(shí)時(shí)的查詢，Parquet只能作為歷史數(shù)據(jù)查詢的補(bǔ)充。

Parquet存儲(chǔ)是相對(duì)索引的存儲(chǔ)來(lái)說(shuō)，是一種折中處理，沒(méi)有倒排索引，而是通過(guò)Row Group水平分割數(shù)據(jù)，然后再根據(jù)Column垂直分割，保證數(shù)據(jù)IO不高，直接Scan數(shù)據(jù)進(jìn)行查詢，相對(duì)Hbase的方案，Scan的性能更好。這種方式，避免了存儲(chǔ)索引和生成索引的開銷，隨著索引Page的完善，相信查詢性能值得信賴。而對(duì)于數(shù)據(jù)還原和聚合也沒(méi)有利用正向索引，而是通過(guò)Striping/Assembly算法來(lái)解決，這種方式更好能夠很取巧的解決數(shù)據(jù)嵌套填充的問(wèn)題， 但是相對(duì)直接使用正向索引來(lái)說(shuō)成本會(huì)很高。

另外，由于是基于Row Group為讀寫的基本單元，屬于粗粒度的數(shù)據(jù)寫入，數(shù)據(jù)生成應(yīng)該還是以離線處理為主，很難提高數(shù)據(jù)寫的實(shí)時(shí)性，而引入其他的解決方案又會(huì)帶來(lái)存儲(chǔ)架構(gòu)的復(fù)雜性，維護(hù)成本都會(huì)相應(yīng)增加。

三、預(yù)聚合系

最近幾年，隨著OLAP場(chǎng)景的需要，預(yù)聚合的解決方案越來(lái)越多。其中比較典型的有Kylin、Druid和Pinot。預(yù)聚合的方案，筆者不想做過(guò)多介紹，其本身只是單純的為了滿足OLAP查詢的場(chǎng)景，需要指定預(yù)聚合的指標(biāo)，在數(shù)據(jù)接入的時(shí)候根據(jù)指定的指標(biāo)進(jìn)行聚合運(yùn)算，數(shù)據(jù)在聚合的過(guò)程中會(huì)丟失metric對(duì)應(yīng)的列值信息。

筆者認(rèn)為，這種方式需要以有損數(shù)據(jù)為代價(jià)，雖然能夠滿足短期的OLAP需求，但是對(duì)于數(shù)據(jù)存儲(chǔ)是非常不利的，會(huì)丟掉數(shù)據(jù)本身存在的潛在價(jià)值。另外，查詢的指標(biāo)也相對(duì)固定，沒(méi)有辦法靈活的自由定義所需的指標(biāo)，只能查詢提前聚合好的指標(biāo)。

四、Lucene系

Lucene算是java中最先進(jìn)的開源全文檢索工具，基于它有兩個(gè)很不錯(cuò)的全文檢索產(chǎn)品ElasticSearch和Solr。Lucene經(jīng)過(guò)多年的發(fā)展，整個(gè)索引體系已經(jīng)非常完善，能夠滿足的的查詢場(chǎng)景遠(yuǎn)多于傳統(tǒng)的數(shù)據(jù)庫(kù)存儲(chǔ)，這都?xì)w功于其強(qiáng)大的索引。但對(duì)于日志、行為類時(shí)序數(shù)據(jù)，所有的搜索請(qǐng)求都也必須搜索所有的分片，另外，對(duì)于聚合分析場(chǎng)景的支持也是軟肋。

Lucene中把一條數(shù)據(jù)對(duì)應(yīng)為一個(gè)Document，數(shù)據(jù)中的字段對(duì)應(yīng)Lucene的Field，Field的信息可以拆分為多個(gè)Term，同時(shí)Term中會(huì)包含其所屬的Field信息，在Lucene中每一個(gè)Document都會(huì)分配一個(gè)行號(hào)。然后在數(shù)據(jù)接入時(shí)建立Term和行號(hào)的對(duì)應(yīng)關(guān)系，就能夠根據(jù)字段的信息快速的搜索出相應(yīng)的行號(hào)，而Term與行號(hào)的對(duì)應(yīng)關(guān)系我們稱之為字典。大部分時(shí)候查詢是多個(gè)條件的組合，于是Lucene引入了跳表的思想，來(lái)加快行號(hào)的求交和求并。字典和跳表就共同組成了Lucene的倒排索引。Lucene從4開始使用了FST的數(shù)據(jù)結(jié)構(gòu)，即得到了很高的字典壓縮率，又加快了字典的檢索。

為了快速的還原數(shù)據(jù)信息和聚合數(shù)據(jù)，Lucene還引入了列正向索引和行正向索引。列正向索引主要是行號(hào)和Term的對(duì)應(yīng)關(guān)系，行正向主要是行號(hào)和Document的對(duì)應(yīng)關(guān)系。這兩種索引都是可以根據(jù)需要配置使用，例如只有單純的查詢，只是用行正向索引就可以，為了實(shí)現(xiàn)數(shù)據(jù)的聚合則必須列正向索引。

有了這些索引后，就可以通過(guò)Term來(lái)查詢出行號(hào)，利用正向索引根據(jù)行號(hào)還原數(shù)據(jù)信息，或者對(duì)數(shù)據(jù)進(jìn)行聚合。

另外，為了滿足全文檢索的需求，Lucene還引入了分詞、詞向量、高亮以及打分的機(jī)制等等。總的來(lái)看，Lucene的整個(gè)索引體系比較臃腫，其設(shè)計(jì)的根本還是搜索引擎的思想，滿足全文檢索的需求。

Lucene本身是單機(jī)版的，沒(méi)有辦法分布式，也就以為著其能處理的還是小數(shù)據(jù)量。ElasticSearch提供了Lucene的分布式處理的解決方案，其核心思想是將Lucene的索引分片。

在寫入場(chǎng)景中，對(duì)于同一個(gè)index的數(shù)據(jù)，會(huì)按照設(shè)定的分片數(shù)分別建立分片索引，這些分片索引可能位于同一臺(tái)服務(wù)器，也可能不同。同時(shí)，各分片索引還需要為自己對(duì)應(yīng)的副本進(jìn)行同步，直到副本寫入成功，一次寫入才算完整的完成。當(dāng)然，單個(gè)文檔的寫入請(qǐng)求只會(huì)涉及到一個(gè)分片的寫入。搜索場(chǎng)景則大致是逆過(guò)程，接受請(qǐng)求的節(jié)點(diǎn)將請(qǐng)求分發(fā)至所有承擔(dān)該分片查詢請(qǐng)求的節(jié)點(diǎn)，然后匯總查詢請(qǐng)求。這里值得注意的是，任意一個(gè)搜索請(qǐng)求均需要在該index的所有分片上執(zhí)行。

由于ElasticSearch是一個(gè)搜索框架，對(duì)于所有的搜索請(qǐng)求，都必須搜索所有的分片。對(duì)于一個(gè)針對(duì)內(nèi)容的搜索應(yīng)用來(lái)說(shuō)，這顯然沒(méi)有什么問(wèn)題，因?yàn)閷?duì)應(yīng)的內(nèi)容會(huì)被存儲(chǔ)到哪一個(gè)分片往往是不可知的。然而對(duì)于日志、行為類數(shù)據(jù)則不然，因?yàn)楹芏鄷r(shí)候我們關(guān)注的是某一個(gè)特定時(shí)間段的數(shù)據(jù)，這時(shí)如果我們可以針對(duì)性的搜索這一部分?jǐn)?shù)據(jù)，那么搜索性能顯然會(huì)得到明顯的提升。

同時(shí)，這類數(shù)據(jù)往往具有另一個(gè)非常重要的特征，即時(shí)效性。很多時(shí)候我們的需求往往是這樣的：對(duì)于最近一段時(shí)間的熱數(shù)據(jù)，其查詢頻率往往要比失去時(shí)效的冷數(shù)據(jù)高得多，而ElasticSearch這樣不加區(qū)分的分片方式顯然不足以支持這樣的需求。

而另外一方面，ElasticSearch對(duì)于聚合分析場(chǎng)景的支持也是軟肋，典型的問(wèn)題是，使用Hyperloglog這類求基數(shù)的聚合函數(shù)時(shí)，非常容易發(fā)生oom。這固然跟這類聚合算法的內(nèi)存消耗相對(duì)高有關(guān)（事實(shí)上，hll在基數(shù)估計(jì)領(lǐng)域是以內(nèi)存消耗低著稱的，高是相對(duì)count，sum這類簡(jiǎn)單聚合而言）。

五、Tindex

數(shù)果智能根據(jù)開源的方案自研了一套數(shù)據(jù)存儲(chǔ)的解決方案，該方案的索引層通過(guò)改造Lucene實(shí)現(xiàn)，數(shù)據(jù)查詢和索引寫入框架通過(guò)擴(kuò)展Druid實(shí)現(xiàn)。既保證了數(shù)據(jù)的實(shí)時(shí)性和指標(biāo)自由定義的問(wèn)題，又能滿足大數(shù)據(jù)量秒級(jí)查詢的需求，系統(tǒng)架構(gòu)如下圖，基本實(shí)現(xiàn)了文章開頭提出的幾個(gè)目標(biāo)。

Tindex主要涉及的幾個(gè)組件

Tindex-Segment,負(fù)責(zé)文件存儲(chǔ)格式，包括數(shù)據(jù)的索引和存儲(chǔ)，查詢優(yōu)化，以及段內(nèi)數(shù)據(jù)搜索與實(shí)時(shí)聚合等。Tindex是基于Lucene的思想重構(gòu)實(shí)現(xiàn)的，由于Lucene索引內(nèi)容過(guò)于復(fù)雜，但是其索引的性能在開源方案中比較完善，在數(shù)據(jù)的壓縮和性能之間做了很好的平衡。我們通過(guò)改造，主要保留了其必要的索引信息，比原有的Lucene節(jié)省了更多的存儲(chǔ)空間，同時(shí)也加快了查詢速度。主要改進(jìn)有以下幾點(diǎn)：

1、高效壓縮存儲(chǔ)格式

對(duì)于海量行為數(shù)據(jù)的存儲(chǔ)來(lái)說(shuō)，存儲(chǔ)容量無(wú)疑是一個(gè)不容忽視的問(wèn)題。對(duì)于使用索引的方案來(lái)說(shuō)，索引后的數(shù)據(jù)容量通常相對(duì)原有數(shù)據(jù)會(huì)有一定程度的膨脹。針對(duì)這類情況，Tindex針對(duì)索引的不同部分，分別使用了不同形式的壓縮技術(shù)，保障了能夠支持高效查詢的同時(shí)僅僅需要較少的容量。對(duì)于數(shù)據(jù)內(nèi)容部分，使用字典的方式編碼存儲(chǔ)，每條記錄僅僅存儲(chǔ)文檔編號(hào)。對(duì)于字典本身的存儲(chǔ)，使用了前綴壓縮的方式，從而降低高基數(shù)維度的空間消耗。實(shí)際情況下，使用 Tindex 壓縮后的數(shù)據(jù)占用的存儲(chǔ)容量?jī)H僅為原始數(shù)據(jù)的1/5左右。

2、列式倒排和正向索引的存儲(chǔ)

由于實(shí)際使用中，往往需要同時(shí)支持搜索和聚合兩種場(chǎng)景，而這兩種方式對(duì)于索引結(jié)構(gòu)的需求是完全相反的。針對(duì)這兩種情況，Tindex結(jié)合了倒排索引和列正向索引這兩種不同類型的索引。對(duì)于倒排索引部分，使用字典和跳表等技術(shù)，實(shí)現(xiàn)了數(shù)據(jù)的快速檢索，而對(duì)于正向部分，則通過(guò)高效的壓縮技術(shù)，實(shí)現(xiàn)了對(duì)于海量行下指定列的快速讀取。同時(shí)，根據(jù)不同的情況，可以選擇性的只建立其中一種索引（默認(rèn)情況對(duì)于每一列均會(huì)同時(shí)建兩種索引），從而節(jié)省大約一般的存儲(chǔ)空間和索引時(shí)間。

Tindex-Druid，負(fù)責(zé)分布式查詢引擎、指標(biāo)定義引擎、數(shù)據(jù)的實(shí)時(shí)導(dǎo)入、實(shí)時(shí)數(shù)據(jù)和元數(shù)據(jù)管理以及數(shù)據(jù)緩存。之所以選擇Druid是因?yàn)槲覀儼l(fā)現(xiàn)其框架擴(kuò)展性、查詢引擎設(shè)計(jì)的非常好，很多性能細(xì)節(jié)都考慮在內(nèi)。例如：

• 堆外內(nèi)存的復(fù)用，避免GC問(wèn)題；

• 根據(jù)查詢數(shù)據(jù)的粒度，以Sequence的方式構(gòu)建小批量的數(shù)據(jù)，內(nèi)存利用率更高；

• 查詢有bySegment級(jí)別的緩存，可以做到大范圍固定模式的查詢；

• 多種query，最大化提升查詢性能，例如topN、timeSeries等查詢等等。

框架可靈活的擴(kuò)展，也是我們考慮的一個(gè)很重要的元素，在我們重寫了索引后，Druid社區(qū)針對(duì)高基數(shù)維度的查詢上線了groupByV2，我們很快就完成了groupByV2也可見其框架非常靈活。

在我們看來(lái)，Druid的查詢引擎很強(qiáng)大，但是索引層還是針對(duì)OLAP查詢的場(chǎng)景，這就是我們選擇Druid框架進(jìn)行索引擴(kuò)展的根本原因。 另外其充分考慮分布式的穩(wěn)定性，HA策略，針對(duì)不同的機(jī)器設(shè)備情況和應(yīng)用場(chǎng)景，靈活的配置最大化利用硬件性能來(lái)滿足場(chǎng)景需要也是我們所看重的。

在開源的Druid版本上自研，繼承了Druid所有優(yōu)點(diǎn)的同時(shí)，對(duì)查詢部分代碼全部重新實(shí)現(xiàn)，從而在以下幾個(gè)方面做了較大改進(jìn)：

1、去掉指標(biāo)預(yù)聚合，指標(biāo)可以在查詢時(shí)自由定義：

對(duì)于數(shù)據(jù)接入來(lái)說(shuō)，不必區(qū)分維度和指標(biāo)，只需要定義數(shù)據(jù)類型即可，數(shù)據(jù)使用原始數(shù)據(jù)的方式進(jìn)行存儲(chǔ)。當(dāng)需要聚合時(shí)，在查詢時(shí)定義指標(biāo)即可。假設(shè)我們要接入一條包含數(shù)字的數(shù)據(jù)，我們現(xiàn)在只需要定義一個(gè)float類型的普通維度。

2、支持多種類型：

不同于原生的Druid只支持string類型維度的情況，我們改進(jìn)后的版本可以支持string, int, long, float、時(shí)間等多種維度類型。在原生的Druid中，如果我們需要一個(gè)數(shù)值型的維度，那么我們只能通過(guò)string來(lái)實(shí)現(xiàn)，這樣會(huì)帶來(lái)一個(gè)很大的問(wèn)題，即基于范圍的過(guò)濾不能利用有序的倒排表，只能通過(guò)逐個(gè)比較來(lái)實(shí)現(xiàn)（因?yàn)槲覀儾荒馨炎址笮‘?dāng)成數(shù)值大小，這樣會(huì)導(dǎo)致這樣的結(jié)果‘12’ < ’2’），從而性能會(huì)非常差，因?yàn)閿?shù)值類型維度很容易出現(xiàn)高基維。對(duì)于改進(jìn)后的版本，這樣的問(wèn)題就簡(jiǎn)單多了，將維度定義為對(duì)應(yīng)的類型即可。

3、實(shí)現(xiàn)數(shù)據(jù)動(dòng)態(tài)加載：

原有的Druid線上的數(shù)據(jù)，需要在啟動(dòng)時(shí)，全部加載才可以提供查詢服務(wù)。我們通過(guò)改造，實(shí)現(xiàn)了LRU策略，啟動(dòng)的時(shí)候只需要加載段的元數(shù)據(jù)信息和少量的段信息即可。一方面提升了服務(wù)的啟動(dòng)時(shí)間，另外一方面，由于索引文件的讀取基本都是MMap，當(dāng)有大量數(shù)據(jù)段需要加載，在內(nèi)存不足的情況，會(huì)直接使用磁盤swap Cache換頁(yè)，嚴(yán)重影響查詢性能。數(shù)據(jù)動(dòng)態(tài)加載的很好的避免了使用磁盤swap Cache換頁(yè)，查詢都盡量使用內(nèi)存，可以通過(guò)配置，最大限度的通過(guò)硬件環(huán)境提供最好的查詢環(huán)境。

HDFS，大數(shù)據(jù)發(fā)展這么多年，HDFS已經(jīng)成為PB級(jí)、ZB級(jí)甚至更多數(shù)據(jù)的分布式存儲(chǔ)標(biāo)準(zhǔn)，很成熟了，所以數(shù)果也選用HDFS，不必重新造輪子。Tindex與HDFS可以完美結(jié)合，可以作為一個(gè)高壓縮、自帶索引的文件格式，兼容Hive，Spark的所有操作。

Kafka/MetaQ,消息隊(duì)列，目前Tindex支持kafka、MetaQ等消息隊(duì)列，由于Tindex對(duì)外擴(kuò)展接口都是基于SPI機(jī)制實(shí)現(xiàn)，所以如有需要也可以擴(kuò)展支持更多的消息隊(duì)列。

Ecosystem Tools,負(fù)責(zé)Tindex的生態(tài)工具支持，目前主要支持Spark、Hive，計(jì)劃擴(kuò)展支持Impala、Drill等大數(shù)據(jù)查詢引擎。

支持冷數(shù)據(jù)下線，通過(guò)離線方式（spark/Hive）查詢，對(duì)于時(shí)序數(shù)據(jù)庫(kù)普遍存在的一個(gè)問(wèn)題是，對(duì)于失去時(shí)效性的數(shù)據(jù)，我們往往不希望它們繼續(xù)占據(jù)寶貴的查詢資源。然后我們往往需要在某些時(shí)候?qū)λ麄儾樵儭?duì)于Tindex而言，可以通過(guò)將超過(guò)一定時(shí)間的數(shù)據(jù)定義為冷數(shù)據(jù)，這樣對(duì)應(yīng)的索引數(shù)據(jù)會(huì)從查詢節(jié)點(diǎn)下線。當(dāng)我們需要再次查詢時(shí)，只需要調(diào)用對(duì)應(yīng)的離線接口進(jìn)行查詢即可。

SQL Engine,負(fù)責(zé)SQL語(yǔ)義轉(zhuǎn)換及表達(dá)式定義。

Zookeeper,負(fù)責(zé)集群狀態(tài)管理。

未來(lái)還會(huì)持續(xù)優(yōu)化改造后的Lucene索引，來(lái)得到更高的查詢性能。優(yōu)化指標(biāo)聚合方式，包括：小批量的處理數(shù)據(jù)，充分利用CPU向量化并行計(jì)算的能力；利用code compile避免聚合虛函數(shù)頻繁調(diào)用；與大數(shù)據(jù)生態(tài)對(duì)接的持續(xù)完善等等。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9981526.html

總結(jié)

以上是生活随笔為你收集整理的万亿级日志与行为数据存储查询技术剖析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。