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

目前大資料儲存查詢方案大概可以分為：Hbase系、Dremel系、預聚合系、Lucene系，本文作者將就自身的使用經驗說說這幾個系的優缺點，如有紕漏，歡迎一起探討。

寫在前面

近些年，大資料背後的價值也開始得到關注和重視，越來越多的企業開始儲存和分析資料，希望從中挖掘大資料的價值。大資料產生的根本還是增量資料，單純的使用者資料不足以構成大資料，然而使用者的行為或行為相關的日誌的資料量，加之隨著物聯網的發力，產生的增量資料將不可預估，儲存和查詢增量資料尤為關鍵。所以，在筆者的工作經歷中，本著以下的目標，尋找更優的大資料儲存和查詢方案：

1. 資料無損：資料分析挖掘都依賴於我們儲存的資料，只有做到資料的無損，才有可能任意的定義指標，滿足各種業務需求。

2. 保證資料實時性：資料的實時性越來越重要，實時的資料能夠更好的運維產品和調整策略，價值更高。單程序每秒接入3.5萬資料以上，資料從產生到能夠查詢到結果這個間隔不會超過5秒。

3. 業務需求快速響應：隨著越來越快的業務發展和資料應用要求的提高，資料的查詢需要更靈活，快速響應不同且多變的需求。最好是任意定義指標後能夠實時查詢出結果。

4. 資料靈活探索性：探索性資料分析在對資料進行概括性描述，發現變數之間的相關性以及引匯出新的假設。到了大資料時代，海量的無結構、半結構資料從多種渠道源源不斷地積累，不受分析模型和研究假設的限制，如何從中找出規律併產生分析模型和研究假設成為新挑戰。因此，探索性資料分析成為大資料分析中不可缺少的一步並且走向前臺。

5. 超大資料集，統計分析秒級響應：萬億資料量級，千級維度（非稀疏）的統計分析秒級響應。

目前大資料儲存查詢方案大概可以分為：Hbase系、Dremel系、預聚合系、Lucene系，筆者就自身的使用經驗說說這幾個系的優缺點，如有紕漏，歡迎一起探討。

資料查詢包括大體可以分為兩步，首先根據某一個或幾個欄位篩選出符合條件的資料，然後根據關聯填充其他所需欄位資訊或者聚合其他欄位資訊，本文中提到的大資料技術，都將圍繞這兩方面。

一、Hbase系

筆者認為Hbase系的解決方案（例如Opentsdb和Kylin）適合相對固定的業務報表類需求，只需要統計少量維度即可滿足業務報表需求，對於單值查詢有優勢，但很難滿足靈活聚合資料的場景。

Hbase的表包含的的概念有rowkey、列簇、列限定符、版本(timestamp)和值，對應實際Hdfs的儲存結構可以用下圖做一個簡單總結：

Hbase表中的每一個列簇會對應一個實際的檔案，某種層面來說，Hbase並非真正意義的列式儲存方案，只是列簇儲存。每個檔案有若干個DataBlock(資料塊預設64k)，DataBlock是HBase中資料儲存的最小單元，DataBlock中以KeyValue的方式儲存使用者資料（KeyValue後面有timestamp，圖中未標註），其他資訊主要包含索引、元資料等資訊，在此不做深入探討。每個KeyValue都由4個部分構成，分別為key length，value length，key和value。其中key的結構相對複雜，包括rowkey、列、KeyType等資訊，而value值對應具體列值的二進位制資料。為了便於查詢，對key做了一個簡單的倒排索引，直接使用了java的ConcurrentSkipListMap。

Hbase管理的核心思想是分級分塊，儲存時根據Rowkey的範圍不同，分散到不同的Region，Region又按照列簇分為不同的Store，每個Store實際上又包括StoreFile(對應Hfile)和MemStore，然後由RegionServer管理不同的Region，RegionServer即對應具體的程序，分散不同的機器，提供分散式的儲存和查詢。查詢時，首先獲取meta表（一種特殊的Region）所在的RegionServer，通過meta表查詢表rowkey相對應的Region和RegionServer資訊，最後連線資料所在的RegionServer，查詢到相應的資料。

Hbase的這種結構，特別適合根據rowkey做單值查詢，不適合scan的場景，因為大部分Scan的情況基本上需要掃描所有資料，效能會非常差。雖然也有擴充套件的Hbase二級索引方案，但基本上都是通過協處理器，需要另外建立一份rowkey的對應關係，Scan的時候先通過二級索引查詢rowkey，然後在根據rowkey查詢相應的資料。

這種方式一定程度上能加快資料掃描，但那對於一些識別度不高的列，如性別這樣的欄位，對應的rowkey相當之多，這樣的欄位在查詢二級索引時的作用很小，另外二級索引所帶來的IO效能的開銷都會隨之增加。而在需要聚合的場景，對於Hbase而言恰恰需要大量scan資料，會非常影響效能。Hbase只有一個簡單rowkey的倒排索引，缺少列索引，所有的查詢和聚合只能依賴於rowkey，很難解決聚合的效能問題。

隨著Hbase的發展，基於Hbase做資料儲存包括Opentsdb和Kylin也隨之產生，例如Kylin也是一種預聚合方案，因其底層儲存使用Hbase，故筆者將其歸為Hbase系。在筆者看來，Opentsdb和Kylin的資料結構極其相似，都是將各種維度值組合，結合時間戳拼成rowkey，利用字典的原理將維度值標籤化，達到壓縮的目的。如此，可以滿足快速查詢資料的需要，但同時也會受限於Hbase索引，聚合需要大量scan，並不能提升資料聚合的速度。

為了避免查詢資料時的聚合，Kylin可以通過cube的方式定製資料結構，在資料接入時通過指定metric來提前聚合資料。這樣雖然在一定程度上解決了資料聚合慢的情況，但這是一種典型的空間換時間的方案，組合在維度多、或者有高基數維度的情況，資料膨脹會非常嚴重，筆者曾遇到儲存後的資料比原始資料大90倍的情況。另外，業務的變化會導致重建cube，難以靈活的滿足業務需要。

二、Dremel系

Parquet作為Dremel系的代表，相對Hbase的方案，Scan的效能更好，也避免了儲存索引和生成索引的開銷。但對於資料還原和聚合，相對直接使用正向索引來說成本會很高，而且以離線處理為主，很難提高資料寫的實時性。

Google的Dremel，其最早用於網頁文件資料分析，所以設計為巢狀的資料結構，當然它也可以用於扁平的二維表資料儲存。開源技術中，Parquet算是Dremel系的代表，各種查詢引擎(Hive/Impala/Drill)、計算框架甚至一些序列化結構資料（如ProtoBuf）都對其進行了支援，甚至Spark還專門針對Parquet的資料格式進行了優化，前途一片光明，本文主要結合Parquet來展開論述。

可以用下圖簡單表示Parquet的檔案格式：

Parquet的資料水平切分為多個Row Group，Row Group為資料讀寫的快取單元，每個Row Group包含各個的資料列(Column Chunk)，資料列有若干Page，Page是壓縮和編碼的單元，其相應儲存的資訊包括元資料資訊(PageHeader)、重複深度(Repetition Levels)、定義深度(Definition Levels)和列值(Values)資訊。

Page實際有三種類型：資料Page、字典Page和索引Page。資料Page用於儲存當前行組中該列的值，字典Page儲存該列值的編碼字典，每一個列塊中最多包含一個字典Page，索引Page目前還不支援，未來可能會引入Bloom Filter，能夠判斷列值是否存在，更有利於判斷搜尋條件，提升查詢速度。

從Parquet的儲存結構來看，Parquet沒有嚴格意義上的索引，在查詢的過程中需要直接對Row Group的列資料進行掃描，有兩方面來保證查詢優化，一個是對映下推(Project PushDown)，另外一個是謂詞下推(Predicate PushDown)。

對映下推主要是利用列式儲存的優勢，查詢資料時只需要掃描查詢中需要的列，由於每一列的所有值都是連續儲存的，所以分割槽取出每一列的所有值就可以實現TableScan運算元，而避免掃描整個檔案內容。

謂詞下推在資料庫之類的查詢系統中最常用的優化手段之一，通過將一些過濾條件儘可能的在最底層執行，減少上層互動的資料量，從而提升效能。另外，針對謂詞下推Parquet做了更進一步的優化，優化的方法是對每一個Row Group的每一個Column Chunk在儲存的時候都計算對應的統計資訊，包括該Column Chunk的最大值、最小值和空值個數。通過這些統計值和該列的過濾條件可以判斷該Row Group是否需要掃描。未來還會增加諸如Bloom Filter和Index等優化資料，更加有效的完成謂詞下推。

通過這兩方面的優化，Parquet的查詢時掃描資料的效能能夠得到大幅度提升。那Parquet如果填充資料（不同的列拼成一行記錄）和聚合資料呢？

主要是使用了Striping/Assembly演算法實現的，該演算法的思想是將資料的值分為三部分：重複深度(Repetition Levels)、定義深度(Definition Levels)和列值(Values)。通過重複深度可以在讀取的時候結合Schema的定義可以知道需要在哪一層建立一個新的repeated節點（如第一層的的為0，表示是新記錄，否則則表示repeat的資料），然後通過定義深度知道該值的路徑上第幾層開始是未定義，從而還原出資料的巢狀結構，如此便能清楚的把一行資料還原出來。由於缺少行號對應的列正向索引，沒有辦法直接定址，單純的依賴於Striping/Assembly演算法還原資料或者聚合處理，相對來說成本會高很多。

另外，Parquet的實時寫方面是硬傷，基於Parquet的方案基本上都是批量寫。一般情況，都是定期生成Parquet檔案，所以資料延遲比較嚴重。為了提高資料的實時性，還需要其他解決方案來解決資料實時的查詢，Parquet只能作為歷史資料查詢的補充。

Parquet儲存是相對索引的儲存來說，是一種折中處理，沒有倒排索引，而是通過Row Group水平分割資料，然後再根據Column垂直分割，保證資料IO不高，直接Scan資料進行查詢，相對Hbase的方案，Scan的效能更好。這種方式，避免了儲存索引和生成索引的開銷，隨著索引Page的完善，相信查詢效能值得信賴。而對於資料還原和聚合也沒有利用正向索引，而是通過Striping/Assembly演算法來解決，這種方式更好能夠很取巧的解決資料巢狀填充的問題， 但是相對直接使用正向索引來說成本會很高。

另外，由於是基於Row Group為讀寫的基本單元，屬於粗粒度的資料寫入，資料生成應該還是以離線處理為主，很難提高資料寫的實時性，而引入其他的解決方案又會帶來儲存架構的複雜性，維護成本都會相應增加。

三、預聚合系

最近幾年，隨著OLAP場景的需要，預聚合的解決方案越來越多。其中比較典型的有Kylin、Druid和Pinot。預聚合的方案，筆者不想做過多介紹，其本身只是單純的為了滿足OLAP查詢的場景，需要指定預聚合的指標，在資料接入的時候根據指定的指標進行聚合運算，資料在聚合的過程中會丟失metric對應的列值資訊。

筆者認為，這種方式需要以有損資料為代價，雖然能夠滿足短期的OLAP需求，但是對於資料儲存是非常不利的，會丟掉資料本身存在的潛在價值。另外，查詢的指標也相對固定，沒有辦法靈活的自由定義所需的指標，只能查詢提前聚合好的指標。

四、Lucene系

Lucene算是java中最先進的開源全文檢索工具，基於它有兩個很不錯的全文檢索產品ElasticSearch和Solr。Lucene經過多年的發展，整個索引體系已經非常完善，能夠滿足的的查詢場景遠多於傳統的資料庫儲存，這都歸功於其強大的索引。但對於日誌、行為類時序資料，所有的搜尋請求都也必須搜尋所有的分片，另外，對於聚合分析場景的支援也是軟肋。

Lucene中把一條資料對應為一個Document，資料中的欄位對應Lucene的Field，Field的資訊可以拆分為多個Term，同時Term中會包含其所屬的Field資訊，在Lucene中每一個Document都會分配一個行號。然後在資料接入時建立Term和行號的對應關係，就能夠根據欄位的資訊快速的搜尋出相應的行號，而Term與行號的對應關係我們稱之為字典。大部分時候查詢是多個條件的組合，於是Lucene引入了跳錶的思想，來加快行號的求交和求並。字典和跳錶就共同組成了Lucene的倒排索引。Lucene從4開始使用了FST的資料結構，即得到了很高的字典壓縮率，又加快了字典的檢索。

為了快速的還原資料資訊和聚合資料，Lucene還引入了列正向索引和行正向索引。列正向索引主要是行號和Term的對應關係，行正向主要是行號和Document的對應關係。這兩種索引都是可以根據需要配置使用，例如只有單純的查詢，只是用行正向索引就可以，為了實現資料的聚合則必須列正向索引。

有了這些索引後，就可以通過Term來查詢出行號，利用正向索引根據行號還原資料資訊，或者對資料進行聚合。

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

Lucene本身是單機版的，沒有辦法分散式，也就以為著其能處理的還是小資料量。ElasticSearch提供了Lucene的分散式處理的解決方案，其核心思想是將Lucene的索引分片。

在寫入場景中，對於同一個index的資料，會按照設定的分片數分別建立分片索引，這些分片索引可能位於同一臺伺服器，也可能不同。同時，各分片索引還需要為自己對應的副本進行同步，直到副本寫入成功，一次寫入才算完整的完成。當然，單個文件的寫入請求只會涉及到一個分片的寫入。搜尋場景則大致是逆過程，接受請求的節點將請求分發至所有承擔該分片查詢請求的節點，然後彙總查詢請求。這裡值得注意的是，任意一個搜尋請求均需要在該index的所有分片上執行。

由於ElasticSearch是一個搜尋框架，對於所有的搜尋請求，都必須搜尋所有的分片。對於一個針對內容的搜尋應用來說，這顯然沒有什麼問題，因為對應的內容會被儲存到哪一個分片往往是不可知的。然而對於日誌、行為類資料則不然，因為很多時候我們關注的是某一個特定時間段的資料，這時如果我們可以針對性的搜尋這一部分資料，那麼搜尋效能顯然會得到明顯的提升。

同時，這類資料往往具有另一個非常重要的特徵，即時效性。很多時候我們的需求往往是這樣的：對於最近一段時間的熱資料，其查詢頻率往往要比失去時效的冷資料高得多，而ElasticSearch這樣不加區分的分片方式顯然不足以支援這樣的需求。

而另外一方面，ElasticSearch對於聚合分析場景的支援也是軟肋，典型的問題是，使用Hyperloglog這類求基數的聚合函式時，非常容易發生oom。這固然跟這類聚合演算法的記憶體消耗相對高有關（事實上，hll在基數估計領域是以記憶體消耗低著稱的，高是相對count，sum這類簡單聚合而言）。

五、Tindex

數果智慧根據開源的方案自研了一套資料儲存的解決方案，該方案的索引層通過改造Lucene實現，資料查詢和索引寫入框架通過擴充套件Druid實現。既保證了資料的實時性和指標自由定義的問題，又能滿足大資料量秒級查詢的需求，系統架構如下圖，基本實現了文章開頭提出的幾個目標。

Tindex主要涉及的幾個元件

Tindex-Segment,負責檔案儲存格式，包括資料的索引和儲存，查詢優化，以及段內資料搜尋與實時聚合等。Tindex是基於Lucene的思想重構實現的，由於Lucene索引內容過於複雜，但是其索引的效能在開源方案中比較完善，在資料的壓縮和效能之間做了很好的平衡。我們通過改造，主要保留了其必要的索引資訊，比原有的Lucene節省了更多的儲存空間，同時也加快了查詢速度。主要改進有以下幾點：

1、高效壓縮儲存格式

對於海量行為資料的儲存來說，儲存容量無疑是一個不容忽視的問題。對於使用索引的方案來說，索引後的資料容量通常相對原有資料會有一定程度的膨脹。針對這類情況，Tindex針對索引的不同部分，分別使用了不同形式的壓縮技術，保障了能夠支援高效查詢的同時僅僅需要較少的容量。對於資料內容部分，使用字典的方式編碼儲存，每條記錄僅僅儲存文件編號。對於字典本身的儲存，使用了字首壓縮的方式，從而降低高基數維度的空間消耗。實際情況下，使用 Tindex 壓縮後的資料佔用的儲存容量僅僅為原始資料的1/5左右。

2、列式倒排和正向索引的儲存

由於實際使用中，往往需要同時支援搜尋和聚合兩種場景，而這兩種方式對於索引結構的需求是完全相反的。針對這兩種情況，Tindex結合了倒排索引和列正向索引這兩種不同型別的索引。對於倒排索引部分，使用字典和跳錶等技術，實現了資料的快速檢索，而對於正向部分，則通過高效的壓縮技術，實現了對於海量行下指定列的快速讀取。同時，根據不同的情況，可以選擇性的只建立其中一種索引（預設情況對於每一列均會同時建兩種索引），從而節省大約一般的儲存空間和索引時間。

Tindex-Druid，負責分散式查詢引擎、指標定義引擎、資料的實時匯入、實時資料和元資料管理以及資料快取。之所以選擇Druid是因為我們發現其框架擴充套件性、查詢引擎設計的非常好，很多效能細節都考慮在內。例如：

• 堆外記憶體的複用，避免GC問題；

• 根據查詢資料的粒度，以Sequence的方式構建小批量的資料，記憶體利用率更高；

• 查詢有bySegment級別的快取，可以做到大範圍固定模式的查詢；

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

框架可靈活的擴充套件，也是我們考慮的一個很重要的元素，在我們重寫了索引後，Druid社群針對高基數維度的查詢上線了groupByV2，我們很快就完成了groupByV2也可見其框架非常靈活。

在我們看來，Druid的查詢引擎很強大，但是索引層還是針對OLAP查詢的場景，這就是我們選擇Druid框架進行索引擴充套件的根本原因。 另外其充分考慮分散式的穩定性，HA策略，針對不同的機器裝置情況和應用場景，靈活的配置最大化利用硬體效能來滿足場景需要也是我們所看重的。

在開源的Druid版本上自研，繼承了Druid所有優點的同時，對查詢部分程式碼全部重新實現，從而在以下幾個方面做了較大改進：

1、去掉指標預聚合，指標可以在查詢時自由定義：

對於資料接入來說，不必區分維度和指標，只需要定義資料型別即可，資料使用原始資料的方式進行儲存。當需要聚合時，在查詢時定義指標即可。假設我們要接入一條包含數字的資料，我們現在只需要定義一個float型別的普通維度。

2、支援多種型別：

不同於原生的Druid只支援string型別維度的情況，我們改進後的版本可以支援string, int, long, float、時間等多種維度型別。在原生的Druid中，如果我們需要一個數值型的維度，那麼我們只能通過string來實現，這樣會帶來一個很大的問題，即基於範圍的過濾不能利用有序的倒排表，只能通過逐個比較來實現（因為我們不能把字串大小當成數值大小，這樣會導致這樣的結果‘12’ < ’2’），從而效能會非常差，因為數值型別維度很容易出現高基維。對於改進後的版本，這樣的問題就簡單多了，將維度定義為對應的型別即可。

3、實現資料動態載入：

原有的Druid線上的資料，需要在啟動時，全部載入才可以提供查詢服務。我們通過改造，實現了LRU策略，啟動的時候只需要載入段的元資料資訊和少量的段資訊即可。一方面提升了服務的啟動時間，另外一方面，由於索引檔案的讀取基本都是MMap，當有大量資料段需要載入，在記憶體不足的情況，會直接使用磁碟swap Cache換頁，嚴重影響查詢效能。資料動態載入的很好的避免了使用磁碟swap Cache換頁，查詢都儘量使用記憶體，可以通過配置，最大限度的通過硬體環境提供最好的查詢環境。

HDFS，大資料發展這麼多年，HDFS已經成為PB級、ZB級甚至更多資料的分散式儲存標準，很成熟了，所以數果也選用HDFS，不必重新造輪子。Tindex與HDFS可以完美結合，可以作為一個高壓縮、自帶索引的檔案格式，相容Hive，Spark的所有操作。

Kafka/MetaQ,訊息佇列，目前Tindex支援kafka、MetaQ等訊息佇列，由於Tindex對外擴充套件介面都是基於SPI機制實現，所以如有需要也可以擴充套件支援更多的訊息佇列。

Ecosystem Tools,負責Tindex的生態工具支援，目前主要支援Spark、Hive，計劃擴充套件支援Impala、Drill等大資料查詢引擎。

支援冷資料下線，通過離線方式（spark/Hive）查詢，對於時序資料庫普遍存在的一個問題是，對於失去時效性的資料，我們往往不希望它們繼續佔據寶貴的查詢資源。然後我們往往需要在某些時候對他們查詢。對於Tindex而言，可以通過將超過一定時間的資料定義為冷資料，這樣對應的索引資料會從查詢節點下線。當我們需要再次查詢時，只需要呼叫對應的離線介面進行查詢即可。

SQL Engine,負責SQL語義轉換及表示式定義。

Zookeeper,負責叢集狀態管理。

未來還會持續優化改造後的Lucene索引，來得到更高的查詢效能。優化指標聚合方式，包括：小批量的處理資料，充分利用CPU向量化平行計算的能力；利用code compile避免聚合虛擬函式頻繁呼叫；與大資料生態對接的持續完善等等。