大數據的OLAP技術
原文 http://www.justinablog.com/archives/1323
在互聯網的技術浪潮沖擊下，不少傳統企業也紛紛涉水大數據技術。以筆者經歷的兩個項目為例，傳統企業與互聯網公司相比有兩個特點：
- 企業應用比較笨重和復雜，云計算等基礎架構平臺，互聯網需要的是水平規模化擴展，但對傳統企業來講，更需要的是垂直一體化部署復雜的依賴并且方便重用；
- 企業數據，包括關系型的交易數據、日志、文檔、電子郵件等等，但總體還是結構化數據占多數；互聯網則是非結構化數據為主，如網頁、圖片、服務器日志等，在網頁搜索或廣告推薦等領域，高維數據分析比較常見。
和企業私有云的架構一樣，對企業的大數據平臺，我們很難直接去簡單復制互聯網的海量存儲或計算平臺技術，如Hadoop、HBase、 Spark；因為這些技術搭建的只是一個數據的基礎設施，要在傳統企業實施“大數據平臺”，我們的思路是，如何將傳統的商業智能運行在“大數據平臺”之 上。
OLAP – 聯機分析
OLAP聯機分析是從多維信息、針對特定問題的聯機數據進行訪問和分析的技術。從分析的角度出發，數據源需提供以下操作支持：
- 維度和指標
- 聚合
- 上卷、下鉆
- 水平、垂直切分
- 排序
下面是一個數據表示例：
| Date | Country | City | OS | Browser | Sale |
|---|---|---|---|---|---|
| 2014-01-23 | China | Beijing | OSX | Chrome | 0.0 |
| 2014-01-24 | China | Shanghai | Windows | IE8 | 8.0 |
| 2014-01-24 | China | Beijing | OSX | Safari | 20.0 |
| 2014-01-25 | China | Chengdu | Linux | Chrome | 12.0 |
| 2014-01-26 | China | Beijing | Windows | Firefox | 30.0 |
| 5 visits4 days | 1 countryChina: 5 |
3 cities: Beijing: 3 Shanghi: 1 Chengdu: 1 |
3 OS-es Windows：2 OSX：2 Linux：1 |
3 browsers Chrome：2 Firefox：1 IE8：1 Safari：1 |
70.04 sales |
上卷至Country維度
SELECT COUNT(visits), SUM(sales) GROUP BY country | Country | Visits | Sales |
|---|---|---|
| China | 5 | $70 |
根據Browser拆分
SELECT COUNT(visits), SUM(sales) GROUP BY country HAVING browser = "Chrome" | Country | Visits | Sales |
|---|---|---|
| China | 2 | $12 |
查詢Sales最高的Browers
SELECT SUM(sales), COUNT(visits) GROUP BY browser ORDER BY sales | Browser | Sales | Visits |
|---|---|---|
| Firefox | $30 | 1 |
| Safari | $20 | 1 |
| Chrome | $12 | 2 |
| IE8 | $8 | 1 |
通常OLAP的多維數據源由數據方（Cube）提供，關系型數據庫或數據倉庫都能提供數據方的設計，相對于數據庫，數據倉庫是昂貴的軟硬件解決方 案，而互聯網普遍采用基于Hadoop技術構建的海量數據處理平臺，在這里是否可以作為數據倉庫的替代品呢？其核心技術還是，如何基于Hadoop來構建 數據方。
Pre-aggregate – 預聚合數據
對數據庫來說，數據聚合通常是實時的。實時聚合的好處是靈活，可以對任意列進行查詢，缺點是CPU、I/O開銷較大，數據量大時查詢緩慢，吞吐量 低；而對Hadoop這樣的非實時計算、大量數據處理的平臺來說，很適合對數據進行預聚合處理，預聚合的優點是查詢快速高效，但缺點是無法靈活查詢，比如 未進行聚合處理的數據。
在基于Hadoop進行預聚合處理上，Adobe提供了一些經驗：
- 數據表設計需要規范
- 超過3個維度、10億條數據時處理會變得復雜
- 維度表之間盡量不要有相關關系
- 只創建必須的索引
領域模型設計
這個步驟的目的是理解數據并且構建出領域模型，包括：
- 源數據如何拆分到不同字段中？
- 哪些字段用于維度？
- 哪些字段用于統計指標？
- 使用什么樣的規則來對數據進行聚合？
- 用戶經常使用的組合查詢是？
- 排序規則？
下面是Adobe SiteCatalyst的設計參考，源數據是一條日志，使用reports.json來描述整個設計：
數據采集優化策略
對歷史數據，采用大量數據批處理來提高吞吐量，對新增的增量數據，盡量達到低延時查詢。一些優化策略包括：
對輸入進行條件過濾：
- FileDateFilter (log name patterns: log-YYYY-MM-dd-HH.log)
- TableInputFormat start/stop row
- File Index in HBase (track processed/new files)
提升Map的任務數：
- CombineFileInputFormat – 2GB-splits => 500 splits for 1TB
- FixedMappersTableInputFormat (e.g. 5-region splits)
數據處理
數據處理的過程包括讀取源數據、預聚合并且生成可供查詢的數據表，對OLAP而言，需要對數據進行以下處理：
- GROUP BY
- COUNT, SUM, AVG
- SORT
- HAVING – 需進行預聚合
以下是Adobe在線數據處理設計和SQL查詢的映射：
在reports.json中定義了觸發各個處理的類：
整個處理過程如下：
