要高效地使用數(shù)據(jù)，就必須要有組織，因此業(yè)界對(duì)數(shù)據(jù)的結(jié)構(gòu)化組織有很多探索。

1. Cube技術(shù)概念

OLAP的目標(biāo)是滿足決策支持或者滿足在多維環(huán)境下特定的查詢(xún)和報(bào)表需求，它的技術(shù)核心是“維”這個(gè)概念。“維”(Dimension)是人們觀察客觀世界的角度，是一種高層次的類(lèi)型劃分。“維”一般包含著層次關(guān)系，這種層次關(guān)系有時(shí)會(huì)相當(dāng)復(fù)雜。通過(guò)把一個(gè)實(shí)體的多項(xiàng)重要屬性定義為多個(gè)維，使用戶(hù)能對(duì)不同維上的數(shù)據(jù)進(jìn)行比較。因此，OLAP也可以說(shuō)是多維數(shù)據(jù)分析工具的集合。OLAP的基本多維分析操作有鉆取、切片和切塊，以及旋轉(zhuǎn)等。

• 鉆取是為了改變維的層次，變換分析的粒度。它包括向上鉆取(rollup)和向下鉆取(drilldown)。rollup是在某一維上將低層次的細(xì)節(jié)數(shù)據(jù)概括到高層次的匯總數(shù)據(jù)，或者減少維數(shù);而drilldown則相反，它從匯總數(shù)據(jù)深入到細(xì)節(jié)數(shù)據(jù)進(jìn)行觀察，或增加維數(shù)。

• 切片和切塊是在一部分維上選定值后，觀察數(shù)據(jù)在剩余維上的分布。如果剩余的維只有兩個(gè)，則是切片;如果有三個(gè)，則是切塊。

• 旋轉(zhuǎn)是為了變換維的方向，即在表格中重新安排維的放置(如行列互換)。

OLAP有多種實(shí)現(xiàn)方法，根據(jù)存儲(chǔ)數(shù)據(jù)的方式不同可以分為ROLAP、MOLAP、HOLAP。ROLAP表示基于關(guān)系型數(shù)據(jù)庫(kù)的OLAP實(shí)現(xiàn)(Relational OLAP)。以關(guān)系型數(shù)據(jù)庫(kù)為核心，以關(guān)系型結(jié)構(gòu)進(jìn)行多維數(shù)據(jù)的表示和存儲(chǔ)。ROLAP將多維數(shù)據(jù)庫(kù)的多維結(jié)構(gòu)劃分為兩類(lèi)表：一類(lèi)是事實(shí)表，用來(lái)存儲(chǔ)數(shù)據(jù)和維關(guān)鍵字;另一類(lèi)是維表，即對(duì)每個(gè)維至少使用一張表來(lái)存放維的層次、成員類(lèi)別等維的描述信息。維表和事實(shí)表通過(guò)主關(guān)鍵字和外關(guān)鍵字聯(lián)系在一起，形成了“星形模式”。對(duì)于層次復(fù)雜的維，為避免冗余數(shù)據(jù)占用過(guò)大的存儲(chǔ)空間，可以使用多張表來(lái)描述，這種星形模式的擴(kuò)展稱(chēng)為“雪花模式”。其特點(diǎn)是將細(xì)節(jié)數(shù)據(jù)保留在關(guān)系型數(shù)據(jù)庫(kù)的事實(shí)表中，聚合后的數(shù)據(jù)也保存在關(guān)系型數(shù)據(jù)庫(kù)中。這種方式查詢(xún)效率最低，不推薦使用。

MOLAP表示基于多維數(shù)據(jù)組織的OLAP實(shí)現(xiàn)(Multidimensional OLAP)。以多維數(shù)據(jù)組織方式為核心，也就是說(shuō)，MOLAP使用多維數(shù)組存儲(chǔ)數(shù)據(jù)。多維數(shù)據(jù)在存儲(chǔ)中將形成“立方塊(Cube)”的結(jié)構(gòu)，在MOLAP中對(duì)“立方塊”的“旋轉(zhuǎn)”、“切塊”、“切片”是產(chǎn)生多維數(shù)據(jù)報(bào)表的主要技術(shù)。其特點(diǎn)是將細(xì)節(jié)數(shù)據(jù)和聚合后的數(shù)據(jù)均保存在Cube中，所以以空間換效率，查詢(xún)時(shí)效率高，但生成Cube時(shí)需要大量的時(shí)間和空間。

HOLAP表示基于混合數(shù)據(jù)組織的OLAP實(shí)現(xiàn)(Hybrid OLAP)。如低層是關(guān)系型的，高層是多維矩陣型的。這種方式具有更好的靈活性。其特點(diǎn)是將細(xì)節(jié)數(shù)據(jù)保留在關(guān)系型數(shù)據(jù)庫(kù)的事實(shí)表中，但是聚合后的數(shù)據(jù)保存在Cube中，聚合時(shí)需要比ROLAP更多的時(shí)間，查詢(xún)效率比ROLAP高，但低于MOLAP。

Cube是典型的以空間換時(shí)間的技術(shù)。為了提高查詢(xún)效率，提前以各種維度把數(shù)據(jù)組織好，如圖10.14所示。

圖10.14

2. Kylin

Apache Kylin是由eBay開(kāi)源的分布式分析引擎，提供基于Hadoop的SQL查詢(xún)接口及多維分析(OLAP)能力，以支持超大規(guī)模數(shù)據(jù)。Kylin的架構(gòu)如圖10.15所示。

kylin核心思路是給數(shù)據(jù)建cube，然后將結(jié)果cube結(jié)果存儲(chǔ)在HBASE上提供對(duì)外查詢(xún)使用。

圖10.15

3. ORCFile

ORCFile(Optimized Row Columnar)是Hive 0.11版本中引入的新的存儲(chǔ)格式，是對(duì)之前的RCFile存儲(chǔ)格式的優(yōu)化，是HortonWorks開(kāi)源的。ORCFile的存儲(chǔ)格式如圖10.16所示。

圖10.16

可以看到，每個(gè)ORC文件由一個(gè)或多個(gè)Stripe組成，每個(gè)Stripe的大小為250MB，這個(gè)Stripe實(shí)際上相當(dāng)于RCFile里的RowGroup，不過(guò)大小由4MB擴(kuò)展到250MB，能夠提升順序讀的吞吐率。

每個(gè)Stripe都包含IndexData、RowData及StripeFooter三部分。StripeFooter包含流位置的目錄;RowData在表掃描的時(shí)候會(huì)用到;IndexData包含每列的最大值和最小值及每列所在的行。行索引里提供了偏移量，它可以跳到正確的壓縮塊位置。

通過(guò)行索引，可以在Stripe快速讀取的過(guò)程中跳過(guò)很多行。在默認(rèn)情況下，最多可以跳過(guò)10 000行。

因?yàn)榭梢酝ㄟ^(guò)過(guò)濾預(yù)測(cè)跳過(guò)很多行，因而可以在表的SecondaryKeys進(jìn)行排序，從而可以大幅地減少執(zhí)行時(shí)間。

每個(gè)文件都有一個(gè)FileFooter，里面存放的是每個(gè)Stripe的行數(shù)、每個(gè)Column的數(shù)據(jù)類(lèi)型等信息;每個(gè)文件的尾部是一個(gè)PostScript，里面記錄了整個(gè)文件的壓縮類(lèi)型及FileFooter的長(zhǎng)度信息等。在讀取文件時(shí)，會(huì)跳到文件尾部讀PostScript，從里面解析到FileFooter長(zhǎng)度;再讀FileFooter，從里面解析到各個(gè)Stripe信息;再讀各個(gè)Stripe，即從后往前讀。

ORCFile的主要特點(diǎn)如下：

• 混合存儲(chǔ)結(jié)構(gòu)，先按行存儲(chǔ)，一組行數(shù)據(jù)叫Stripes，Stripes內(nèi)部按列存儲(chǔ)。
• 支持各種復(fù)雜的數(shù)據(jù)類(lèi)型。
• 在文件中存儲(chǔ)了一些輕量級(jí)的索引數(shù)據(jù)。
• 基于數(shù)據(jù)類(lèi)型的塊模式壓縮：Integer類(lèi)型的列用行程長(zhǎng)度編碼(Run-Length Encoding，RLE);String類(lèi)型的列用字典編碼。

4. Parquet

開(kāi)源項(xiàng)目Parquet是Hadoop上一種支持列式存儲(chǔ)的文件格式，起初只是Twitter和Coudera在合作開(kāi)發(fā)，發(fā)展到現(xiàn)在已經(jīng)有包括Criteo公司在內(nèi)的許多其他貢獻(xiàn)者了。Parquet用Dremel的論文中描述的方式，把嵌套結(jié)構(gòu)存儲(chǔ)為扁平格式。

盡管Parquet是一個(gè)面向列的文件格式，但不要期望每列一個(gè)數(shù)據(jù)文件。Parquet在同一個(gè)數(shù)據(jù)文件中保存一行中的所有數(shù)據(jù)，以確保在同一個(gè)節(jié)點(diǎn)上進(jìn)行處理時(shí)，一行的所有列都可用。Parquet所做的是設(shè)置HDFS塊大小和最大數(shù)據(jù)文件大小為1GB，以確保I/O和網(wǎng)絡(luò)傳輸請(qǐng)求適用于大批量數(shù)據(jù)。

在一個(gè)大小為1GB的HDFS文件中，一組行的數(shù)據(jù)會(huì)重新排列，以便第一行的所有值被重組為一個(gè)連續(xù)的塊;然后是第二行的所有值，以此類(lèi)推。

為了在列式存儲(chǔ)中可以表達(dá)嵌套結(jié)構(gòu)，用definitionlevel和repetitionlevel兩個(gè)值來(lái)描述，分別表達(dá)某個(gè)值在整個(gè)嵌套格式中的最深嵌套層數(shù)，以及在同一個(gè)嵌套層級(jí)中的第幾個(gè)值。

Parquet使用一些自動(dòng)壓縮技術(shù)，如行程長(zhǎng)度編碼(Run-Length Encoding，RLE)和字典編碼(Dictionary Encoding)，基于實(shí)際數(shù)據(jù)值進(jìn)行分析。通過(guò)字典使數(shù)據(jù)值被編碼成緊湊的格式，同時(shí)使用壓縮算法，編碼的數(shù)據(jù)可能會(huì)被進(jìn)一步壓縮。Impala創(chuàng)建的Parquet數(shù)據(jù)文件可以使用Snappy、Gzip進(jìn)行壓縮，或不進(jìn)行壓縮;Parquet文件還支持LZO壓縮，但是目前Impala不支持LZO壓縮的Parquet文件。

除了應(yīng)用到整個(gè)數(shù)據(jù)文件的Snappy或Gzip壓縮外，RLE和字段編碼是Impala自動(dòng)應(yīng)用到Parquet數(shù)據(jù)值群體的壓縮技術(shù)。

綜合來(lái)看，ORCFile和Parquet本質(zhì)上都是列式存儲(chǔ)，大同小異。Parquet的主要特點(diǎn)是支持嵌套格式，ORCFile的主要特點(diǎn)是Strips中有輕量級(jí)的IndexData，所以這兩種數(shù)據(jù)存儲(chǔ)格式完全可以相互借鑒融合。另外，列式存儲(chǔ)不是Hadoop首創(chuàng)的，而是從傳統(tǒng)數(shù)據(jù)庫(kù)中發(fā)展而來(lái)的。

5. Google Mesa數(shù)據(jù)模型

Google發(fā)表了一篇有關(guān)大數(shù)據(jù)系統(tǒng)的論文，討論了一個(gè)名為Mesa的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，它能處理近實(shí)時(shí)數(shù)據(jù)，即使在整個(gè)數(shù)據(jù)中心斷線后還能正常工作。

Mesa是一個(gè)高度可擴(kuò)展的分析數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，能存儲(chǔ)與Google廣告業(yè)務(wù)有關(guān)的關(guān)鍵測(cè)量數(shù)據(jù)。Mesa能滿足復(fù)雜和具有挑戰(zhàn)性的用戶(hù)與系統(tǒng)需求，包括近實(shí)時(shí)數(shù)據(jù)提取和查詢(xún)，同時(shí)在海量數(shù)據(jù)和查詢(xún)量中保持高可用性、可靠性、容錯(cuò)率和擴(kuò)展性。Mesa每秒能處理數(shù)百萬(wàn)行更新，每天能進(jìn)行數(shù)十億次查詢(xún)，抓取數(shù)萬(wàn)億行數(shù)據(jù)。Mesa能進(jìn)行跨數(shù)據(jù)中心復(fù)制，即使在整個(gè)數(shù)據(jù)中心發(fā)生故障時(shí)，也能以低延遲返回一致和可重復(fù)的查詢(xún)結(jié)果。

針對(duì)數(shù)分鐘更新吞吐量、跨數(shù)據(jù)中心等嚴(yán)苛需求，已有的商業(yè)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)(處理周期往往以天和周來(lái)計(jì)算)和Google的解決方案包括BigTable、MegaStore、Spanner和F1都無(wú)法滿足要求。BigTable無(wú)法提供必要的原子性，MegaStore、Spanner和F1無(wú)法滿足峰值更新需求。此外，Google自己開(kāi)發(fā)的Tenzing、Dremel，以及Twitter開(kāi)發(fā)的Scribe、LinkedIn的Avatara、Facebook的Hive及Hadoop DB等Web規(guī)模數(shù)據(jù)倉(cāng)庫(kù)處理的都是批量負(fù)載。

Mesa的主要特點(diǎn)如下：

• 近實(shí)時(shí)地更新吞吐量。支持持續(xù)更新，每秒支持?jǐn)?shù)百萬(wàn)行更新。
• 同時(shí)支持低時(shí)延查詢(xún)性能和批量大量查詢(xún)。99%的查詢(xún)?cè)趲装俸撩胫畠?nèi)返回。
• 跨數(shù)據(jù)中心備份。

HDFS最早設(shè)定的是數(shù)據(jù)不更新，只增量疊加。傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)(如Greenplum、Treadata、Oracle RAC)通常會(huì)遇到兩個(gè)問(wèn)題：

• 更新的throughput不高。
• 更新影響查詢(xún)。

為了解決這兩個(gè)問(wèn)題，Google的Mesa系統(tǒng)設(shè)計(jì)了一個(gè)MVCC的數(shù)據(jù)模型，通過(guò)增量更新和合并技術(shù)，將離散的更新I/O轉(zhuǎn)變成批量I/O，平衡了查詢(xún)和更新的沖突，提高了更新的吞吐量。

Mesa設(shè)計(jì)了一個(gè)多版本管理技術(shù)來(lái)解決更新的問(wèn)題：

• 使用二維表來(lái)管理數(shù)據(jù)，每張表都要制定Schema，類(lèi)似于傳統(tǒng)的數(shù)據(jù)庫(kù)。
• 每個(gè)字段用Key/Value來(lái)管理。Schema就是Key的集合。
• 每個(gè)字段指定一個(gè)聚合函數(shù)F(最常見(jiàn)的是SUM)。
• 數(shù)據(jù)更新進(jìn)來(lái)的時(shí)候，按照MVCC增量更新，并給增量更新指定一個(gè)版本號(hào)N和謂詞P。
• 查詢(xún)進(jìn)來(lái)的時(shí)候，自動(dòng)識(shí)別聚合函數(shù)，把所有版本的更新按照聚合函數(shù)自動(dòng)計(jì)算出來(lái)。
• 多版本如果永遠(yuǎn)不合并，則存儲(chǔ)的代價(jià)會(huì)非常大。而且因?yàn)槊看尾樵?xún)需要遍歷所有版本號(hào)，所以版本過(guò)多會(huì)影響查詢(xún)。因此，定期合并是必需的。
• Mesa采用兩段更新的策略。更新數(shù)據(jù)按版本號(hào)實(shí)時(shí)寫(xiě)入，每10個(gè)版本自動(dòng)合并;每天全量合并一遍，合并成一個(gè)基礎(chǔ)版本。

【本文為51CTO專(zhuān)欄作者“大數(shù)據(jù)和云計(jì)算”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)獲取聯(lián)系和授權(quán)】

戳這里，看該作者更多好文