事務型處理與統(tǒng)計分析的區(qū)別
早期的數(shù)據(jù)庫是服務于商業(yè)社會的歌懒，每次數(shù)據(jù)庫讀寫就意味著某種交易啦桌。隨著數(shù)據(jù)庫的應用逐漸從商業(yè)領域擴展到無所不在，過去一系列操作必須在一個邏輯單元完成的事務及皂，目前也不那么在意了甫男。過去數(shù)據(jù)庫操作主要是事務型的，也就是我們根據(jù)一些key验烧，用索引去數(shù)據(jù)庫里面找到一小部分數(shù)據(jù)板驳。數(shù)據(jù)基于用戶的操作進行新增和更新。操作數(shù)據(jù)庫的系統(tǒng)往往都是交互式的碍拆，也叫在線事務處理若治。(online transaction processing, OLTP)
但是時代變了，數(shù)據(jù)庫廣泛用于數(shù)據(jù)分析感混，特點和之前全然不同,經(jīng)常分析師需要掃描整表的某一個或幾個很小的列端幼，計算各種統(tǒng)計結果。假設你的表是一個交易記錄弧满，那數(shù)據(jù)分析經(jīng)常會這么查婆跑。
我們一月每個商店的總收入是多少？
最近這次促銷活動讓我們多賣了多少香蕉庭呜？
哪一款嬰兒食品和X牌的尿布在一塊賣的最好
這些查詢是和BI比較相關的滑进，為了與剛才的OLTP做區(qū)分，管這種查詢被稱作在線分析處理.(online analytic processing, OLAP),可以用表格簡單對比下他們的區(qū)別募谎。
| 特點 | OLTP | OLAP |
|---|---|---|
| 讀 | 每次根據(jù)key查很少數(shù)據(jù) | 查詢大量數(shù)據(jù)郊供，算統(tǒng)計數(shù)字 |
| 寫 | 基于用戶輸入,隨機寫,低延遲 | 批量導入，或者基于時間流 |
| 用途 | 通過應用服務用戶 | 給內(nèi)部決策提供分析 |
| 數(shù)據(jù)呈現(xiàn)方式 | 數(shù)據(jù)的最終狀態(tài) | 數(shù)據(jù)的全歷史狀態(tài) |
| 數(shù)據(jù)規(guī)模 | GB 到TB | TB 到PB |
起初近哟，關系數(shù)據(jù)庫在兩種場景下都挺好用的驮审，但是后來很多公司就不在OLAP場景用關系數(shù)據(jù)庫了，轉而用了一個新的數(shù)據(jù)庫, 數(shù)據(jù)倉庫(data warehouse)
數(shù)據(jù)倉庫
一個公司可能有多個OLTP的系統(tǒng)吉执，服務于不同的應用和用戶疯淫。往往這些系統(tǒng)和對應的存儲服務于線上業(yè)務，所以他們對于可靠性和耗時有著非常嚴苛的要求戳玫。DBA也通常禁止分析員在數(shù)據(jù)庫上跑些臨時的分析任務熙掺，因為這些任務往往會掃描大量數(shù)據(jù)，影響線上的服務質(zhì)量和數(shù)據(jù)一致性咕宿。
數(shù)據(jù)倉庫則是一個獨立的數(shù)據(jù)庫币绩，分析員可以在上面查詢到核心數(shù)據(jù)但不影響線上的服務質(zhì)量蜡秽。數(shù)據(jù)倉庫上面存儲著一個OLTP系統(tǒng)數(shù)據(jù)的只讀備份。數(shù)據(jù)從OLTP系統(tǒng)到數(shù)據(jù)倉庫的過程稱作ETL(Extract–Transform–Load),如圖Figure 3-8
之所以維護一個單獨的數(shù)據(jù)倉庫缆镣，而不是讓分析員直接查詢線上的OLTP數(shù)據(jù)庫芽突，有一個好處是數(shù)據(jù)倉庫可以針對分析員做專門的優(yōu)化。事實已經(jīng)證明董瞻，第二章討論的那些索引技術，對于分析員來說沒什么用∧坪現(xiàn)在就來看看專門為分析員優(yōu)化的數(shù)據(jù)存儲引擎長什么樣。
OLTP 和數(shù)據(jù)倉庫的分歧
大部分的數(shù)據(jù)倉庫都是關系型的抄伍，因為SQL對于分析員來說用著很爽。另外還配以各種圖形化的工具截珍，幫助分析員生成SQL，可視化結果云稚。讓他們更容易的來探索數(shù)據(jù)沈堡。 內(nèi)容都很虛，沒什么值錢的诞丽，列些數(shù)據(jù)工具名字拐格，商業(yè)化的工具有Teradata, Vertica, SAP HANA, ParAccel。開源的工具有Hive, Spark SQL, Impala, Presto, Apache Tajo, and Apache Drill
分析學的數(shù)據(jù)結構, 星形和雪花形
第二章講了各種各樣的數(shù)據(jù)模型以應對不同的線上業(yè)務的需求懂衩，但是離線分析用的數(shù)據(jù)模型就種類很少了，絕大部分數(shù)據(jù)倉庫的數(shù)據(jù)模型都很規(guī)范浊洞，也就是星形結構胡岔。如Figure3-9的例子是一個零售商的數(shù)據(jù)倉庫。倉庫的核心是一張事實表(Fact Table),例子中對應fact_salesb表,每行記錄了一個事件靶瘸，這個例子中每行表示一個顧客在特定時間買了某一樣商品毛肋。一般來說事實表是每一個事件一行記錄润匙，這樣可以給分析員最大的靈活性。但這就意味著事實表無比巨大趁桃，像沃爾瑪肄鸽，蘋果他們都有幾十PB的數(shù)據(jù)倉庫，絕大部分都是這類事件數(shù)據(jù)典徘。
事實表中的某些列對應某些屬性逮诲，比如價格，而另外一些列相當于指向其他表的外鍵梅鹦。一般來說對于一個事件，表示他的維度包括齐唆，5個W加一個H, who, when, what, why, where, how。舉個例子茉帅，product表里面存儲了所有商品的基礎信息和id,fact_sales用外鍵的方式存儲了在這次交易中锭弊，哪件商品被賣出去了。
很多時候連時間味滞、日期這種字段也都是用外鍵的方式存儲而不是直接寫到事實表里面，因為日期也可能有很多屬性昨凡，比如是否是節(jié)假日攒暇。這樣就能讓分析員方便的分析節(jié)假日和非節(jié)假日之間的區(qū)別了
星形結構顧名思義，就是在數(shù)據(jù)可視化的時候有一張事實表形用，事實表與若干個屬性表相連证杭，就好像星形一樣解愤。星形的一種變形是雪花形結構，當屬性還有子屬性的時候送讲，比如一個商品又包含品牌惋啃，分類這些字段，這些又對應一張屬性表边灭。
一般來說數(shù)據(jù)倉庫的列數(shù)都特別多，往往都有上百列称簿，屬性表也都很大，包含所有能幫助分析者的字段憨降。例如店的大小该酗，店內(nèi)是否有面包店，上次裝修是什么時候垂涯，距離最近的高速有多遠航邢。但凡可能用的上的都往里面放。
