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