數(shù)據(jù)組織的五大核心技術(shù)
要高效地使用數(shù)據(jù),就必須要有組織,因此業(yè)界對數(shù)據(jù)的結(jié)構(gòu)化組織有很多探索。
1. Cube技術(shù)概念
OLAP的目標(biāo)是滿足決策支持或者滿足在多維環(huán)境下特定的查詢和報表需求,它的技術(shù)核心是“維”這個概念。“維”(Dimension)是人們觀察客觀世界的角度,是一種高層次的類型劃分。“維”一般包含著層次關(guān)系,這種層次關(guān)系有時會相當(dāng)復(fù)雜。通過把一個實體的多項重要屬性定義為多個維,使用戶能對不同維上的數(shù)據(jù)進(jìn)行比較。因此,OLAP也可以說是多維數(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ù)在剩余維上的分布。如果剩余的維只有兩個,則是切片;如果有三個,則是切塊。
- 旋轉(zhuǎn)是為了變換維的方向,即在表格中重新安排維的放置(如行列互換)。
OLAP有多種實現(xiàn)方法,根據(jù)存儲數(shù)據(jù)的方式不同可以分為ROLAP、MOLAP、HOLAP。ROLAP表示基于關(guān)系型數(shù)據(jù)庫的OLAP實現(xiàn)(Relational OLAP)。以關(guān)系型數(shù)據(jù)庫為核心,以關(guān)系型結(jié)構(gòu)進(jìn)行多維數(shù)據(jù)的表示和存儲。ROLAP將多維數(shù)據(jù)庫的多維結(jié)構(gòu)劃分為兩類表:一類是事實表,用來存儲數(shù)據(jù)和維關(guān)鍵字;另一類是維表,即對每個維至少使用一張表來存放維的層次、成員類別等維的描述信息。維表和事實表通過主關(guān)鍵字和外關(guān)鍵字聯(lián)系在一起,形成了“星形模式”。對于層次復(fù)雜的維,為避免冗余數(shù)據(jù)占用過大的存儲空間,可以使用多張表來描述,這種星形模式的擴展稱為“雪花模式”。其特點是將細(xì)節(jié)數(shù)據(jù)保留在關(guān)系型數(shù)據(jù)庫的事實表中,聚合后的數(shù)據(jù)也保存在關(guān)系型數(shù)據(jù)庫中。這種方式查詢效率最低,不推薦使用。
MOLAP表示基于多維數(shù)據(jù)組織的OLAP實現(xiàn)(Multidimensional OLAP)。以多維數(shù)據(jù)組織方式為核心,也就是說,MOLAP使用多維數(shù)組存儲數(shù)據(jù)。多維數(shù)據(jù)在存儲中將形成“立方塊(Cube)”的結(jié)構(gòu),在MOLAP中對“立方塊”的“旋轉(zhuǎn)”、“切塊”、“切片”是產(chǎn)生多維數(shù)據(jù)報表的主要技術(shù)。其特點是將細(xì)節(jié)數(shù)據(jù)和聚合后的數(shù)據(jù)均保存在Cube中,所以以空間換效率,查詢時效率高,但生成Cube時需要大量的時間和空間。
HOLAP表示基于混合數(shù)據(jù)組織的OLAP實現(xiàn)(Hybrid OLAP)。如低層是關(guān)系型的,高層是多維矩陣型的。這種方式具有更好的靈活性。其特點是將細(xì)節(jié)數(shù)據(jù)保留在關(guān)系型數(shù)據(jù)庫的事實表中,但是聚合后的數(shù)據(jù)保存在Cube中,聚合時需要比ROLAP更多的時間,查詢效率比ROLAP高,但低于MOLAP。
Cube是典型的以空間換時間的技術(shù)。為了提高查詢效率,提前以各種維度把數(shù)據(jù)組織好,如圖10.14所示。
圖10.14
2. Kylin
Apache Kylin是由eBay開源的分布式分析引擎,提供基于Hadoop的SQL查詢接口及多維分析(OLAP)能力,以支持超大規(guī)模數(shù)據(jù)。Kylin的架構(gòu)如圖10.15所示。
kylin核心思路是給數(shù)據(jù)建cube,然后將結(jié)果cube結(jié)果存儲在HBASE上提供對外查詢使用。
圖10.15
3. ORCFile
ORCFile(Optimized Row Columnar)是Hive 0.11版本中引入的新的存儲格式,是對之前的RCFile存儲格式的優(yōu)化,是HortonWorks開源的。ORCFile的存儲格式如圖10.16所示。
圖10.16
可以看到,每個ORC文件由一個或多個Stripe組成,每個Stripe的大小為250MB,這個Stripe實際上相當(dāng)于RCFile里的RowGroup,不過大小由4MB擴展到250MB,能夠提升順序讀的吞吐率。
每個Stripe都包含IndexData、RowData及StripeFooter三部分。StripeFooter包含流位置的目錄;RowData在表掃描的時候會用到;IndexData包含每列的最大值和最小值及每列所在的行。行索引里提供了偏移量,它可以跳到正確的壓縮塊位置。
通過行索引,可以在Stripe快速讀取的過程中跳過很多行。在默認(rèn)情況下,最多可以跳過10 000行。
因為可以通過過濾預(yù)測跳過很多行,因而可以在表的SecondaryKeys進(jìn)行排序,從而可以大幅地減少執(zhí)行時間。
每個文件都有一個FileFooter,里面存放的是每個Stripe的行數(shù)、每個Column的數(shù)據(jù)類型等信息;每個文件的尾部是一個PostScript,里面記錄了整個文件的壓縮類型及FileFooter的長度信息等。在讀取文件時,會跳到文件尾部讀PostScript,從里面解析到FileFooter長度;再讀FileFooter,從里面解析到各個Stripe信息;再讀各個Stripe,即從后往前讀。
ORCFile的主要特點如下:
- 混合存儲結(jié)構(gòu),先按行存儲,一組行數(shù)據(jù)叫Stripes,Stripes內(nèi)部按列存儲。
- 支持各種復(fù)雜的數(shù)據(jù)類型。
- 在文件中存儲了一些輕量級的索引數(shù)據(jù)。
- 基于數(shù)據(jù)類型的塊模式壓縮:Integer類型的列用行程長度編碼(Run-Length Encoding,RLE);String類型的列用字典編碼。
4. Parquet
開源項目Parquet是Hadoop上一種支持列式存儲的文件格式,起初只是Twitter和Coudera在合作開發(fā),發(fā)展到現(xiàn)在已經(jīng)有包括Criteo公司在內(nèi)的許多其他貢獻(xiàn)者了。Parquet用Dremel的論文中描述的方式,把嵌套結(jié)構(gòu)存儲為扁平格式。
盡管Parquet是一個面向列的文件格式,但不要期望每列一個數(shù)據(jù)文件。Parquet在同一個數(shù)據(jù)文件中保存一行中的所有數(shù)據(jù),以確保在同一個節(jié)點上進(jìn)行處理時,一行的所有列都可用。Parquet所做的是設(shè)置HDFS塊大小和最大數(shù)據(jù)文件大小為1GB,以確保I/O和網(wǎng)絡(luò)傳輸請求適用于大批量數(shù)據(jù)。
在一個大小為1GB的HDFS文件中,一組行的數(shù)據(jù)會重新排列,以便第一行的所有值被重組為一個連續(xù)的塊;然后是第二行的所有值,以此類推。
為了在列式存儲中可以表達(dá)嵌套結(jié)構(gòu),用definitionlevel和repetitionlevel兩個值來描述,分別表達(dá)某個值在整個嵌套格式中的最深嵌套層數(shù),以及在同一個嵌套層級中的第幾個值。
Parquet使用一些自動壓縮技術(shù),如行程長度編碼(Run-Length Encoding,RLE)和字典編碼(Dictionary Encoding),基于實際數(shù)據(jù)值進(jìn)行分析。通過字典使數(shù)據(jù)值被編碼成緊湊的格式,同時使用壓縮算法,編碼的數(shù)據(jù)可能會被進(jìn)一步壓縮。Impala創(chuàng)建的Parquet數(shù)據(jù)文件可以使用Snappy、Gzip進(jìn)行壓縮,或不進(jìn)行壓縮;Parquet文件還支持LZO壓縮,但是目前Impala不支持LZO壓縮的Parquet文件。
除了應(yīng)用到整個數(shù)據(jù)文件的Snappy或Gzip壓縮外,RLE和字段編碼是Impala自動應(yīng)用到Parquet數(shù)據(jù)值群體的壓縮技術(shù)。
綜合來看,ORCFile和Parquet本質(zhì)上都是列式存儲,大同小異。Parquet的主要特點是支持嵌套格式,ORCFile的主要特點是Strips中有輕量級的IndexData,所以這兩種數(shù)據(jù)存儲格式完全可以相互借鑒融合。另外,列式存儲不是Hadoop首創(chuàng)的,而是從傳統(tǒng)數(shù)據(jù)庫中發(fā)展而來的。
5. Google Mesa數(shù)據(jù)模型
Google發(fā)表了一篇有關(guān)大數(shù)據(jù)系統(tǒng)的論文,討論了一個名為Mesa的數(shù)據(jù)倉庫系統(tǒng),它能處理近實時數(shù)據(jù),即使在整個數(shù)據(jù)中心斷線后還能正常工作。
Mesa是一個高度可擴展的分析數(shù)據(jù)倉庫系統(tǒng),能存儲與Google廣告業(yè)務(wù)有關(guān)的關(guān)鍵測量數(shù)據(jù)。Mesa能滿足復(fù)雜和具有挑戰(zhàn)性的用戶與系統(tǒng)需求,包括近實時數(shù)據(jù)提取和查詢,同時在海量數(shù)據(jù)和查詢量中保持高可用性、可靠性、容錯率和擴展性。Mesa每秒能處理數(shù)百萬行更新,每天能進(jìn)行數(shù)十億次查詢,抓取數(shù)萬億行數(shù)據(jù)。Mesa能進(jìn)行跨數(shù)據(jù)中心復(fù)制,即使在整個數(shù)據(jù)中心發(fā)生故障時,也能以低延遲返回一致和可重復(fù)的查詢結(jié)果。
針對數(shù)分鐘更新吞吐量、跨數(shù)據(jù)中心等嚴(yán)苛需求,已有的商業(yè)數(shù)據(jù)倉庫系統(tǒng)(處理周期往往以天和周來計算)和Google的解決方案包括BigTable、MegaStore、Spanner和F1都無法滿足要求。BigTable無法提供必要的原子性,MegaStore、Spanner和F1無法滿足峰值更新需求。此外,Google自己開發(fā)的Tenzing、Dremel,以及Twitter開發(fā)的Scribe、LinkedIn的Avatara、Facebook的Hive及Hadoop DB等Web規(guī)模數(shù)據(jù)倉庫處理的都是批量負(fù)載。
Mesa的主要特點如下:
- 近實時地更新吞吐量。支持持續(xù)更新,每秒支持?jǐn)?shù)百萬行更新。
- 同時支持低時延查詢性能和批量大量查詢。99%的查詢在幾百毫秒之內(nèi)返回。
- 跨數(shù)據(jù)中心備份。
HDFS最早設(shè)定的是數(shù)據(jù)不更新,只增量疊加。傳統(tǒng)數(shù)據(jù)倉庫(如Greenplum、Treadata、Oracle RAC)通常會遇到兩個問題:
- 更新的throughput不高。
- 更新影響查詢。
為了解決這兩個問題,Google的Mesa系統(tǒng)設(shè)計了一個MVCC的數(shù)據(jù)模型,通過增量更新和合并技術(shù),將離散的更新I/O轉(zhuǎn)變成批量I/O,平衡了查詢和更新的沖突,提高了更新的吞吐量。
Mesa設(shè)計了一個多版本管理技術(shù)來解決更新的問題:
- 使用二維表來管理數(shù)據(jù),每張表都要制定Schema,類似于傳統(tǒng)的數(shù)據(jù)庫。
- 每個字段用Key/Value來管理。Schema就是Key的集合。
- 每個字段指定一個聚合函數(shù)F(最常見的是SUM)。
- 數(shù)據(jù)更新進(jìn)來的時候,按照MVCC增量更新,并給增量更新指定一個版本號N和謂詞P。
- 查詢進(jìn)來的時候,自動識別聚合函數(shù),把所有版本的更新按照聚合函數(shù)自動計算出來。
- 多版本如果永遠(yuǎn)不合并,則存儲的代價會非常大。而且因為每次查詢需要遍歷所有版本號,所以版本過多會影響查詢。因此,定期合并是必需的。
- Mesa采用兩段更新的策略。更新數(shù)據(jù)按版本號實時寫入,每10個版本自動合并;每天全量合并一遍,合并成一個基礎(chǔ)版本。
【本文為51CTO專欄作者“大數(shù)據(jù)和云計算”的原創(chuàng)稿件,轉(zhuǎn)載請通過微信公眾號獲取聯(lián)系和授權(quán)】