?早期，數(shù)據(jù)庫(kù)寫入通常與一筆商業(yè)交易（commercial transaction）相對(duì)應(yīng)：如銷售、訂單等。雖然隨數(shù)據(jù)庫(kù)發(fā)展到不涉及金錢交易的領(lǐng)域，術(shù)語(yǔ) 交易/事務(wù)（transaction） 仍保留下來(lái)，指一組讀寫操作構(gòu)成的一個(gè)邏輯單元。

事務(wù)不一定具備ACID。事務(wù)處理只是意味著允許客戶端進(jìn)行低延遲讀取和寫入，而不是只能周期運(yùn)行（如每天一次）的批量處理作業(yè)。

即使數(shù)據(jù)庫(kù)開始被用于許多不同類型的數(shù)據(jù)，如博客評(píng)論，游戲的動(dòng)作，通訊錄的聯(lián)系人等，但基本訪問(wèn)模式仍類似處理商業(yè)交易。應(yīng)用程序通常使用索引通過(guò)某K查找少量記錄。根據(jù)用戶輸入新增或更新記錄。由于這些應(yīng)用程序是交互式的，這種訪問(wèn)模式被稱為 在線事務(wù)處理（OLTP, OnLine Transaction Processing） 。

但數(shù)據(jù)庫(kù)也越來(lái)越多用于數(shù)據(jù)分析，它們有著很不同的訪問(wèn)模式。通常，分析查詢需掃描大量記錄，每個(gè)記錄只讀取幾列，并計(jì)算匯總統(tǒng)計(jì)信息（如計(jì)數(shù)，總和或平均值），而非將原始數(shù)據(jù)返給用戶。例如，若數(shù)據(jù)是個(gè)銷售交易表，則分析查詢可能包含：

• 一月份每個(gè)商店的總收入？
• 在最近的推廣活動(dòng)中多賣了多少香蕉？
• 哪個(gè)牌子的嬰兒食品最常與X品牌的尿布同時(shí)購(gòu)買？

這些查詢通常由業(yè)務(wù)分析師編寫，并提供給幫助公司管理層做出更好決策（商業(yè)智能）的報(bào)告。為將這種使用數(shù)據(jù)庫(kù)的模式和事務(wù)處理區(qū)分，被稱為在線分析處理（OLAP, OnLine Analytice Processing）。

表1：事務(wù)處理 V.S 分析系統(tǒng)

起初，相同數(shù)據(jù)庫(kù)可同時(shí)用于事務(wù)處理和分析查詢。SQL在這方面證明是非常靈活：可同時(shí)勝任OLTP及OLAP類型查詢。但1980s末和1990s初期，公司放棄使用OLTP系統(tǒng)用于分析，而是在單獨(dú)數(shù)據(jù)庫(kù)上運(yùn)行分析：數(shù)據(jù)倉(cāng)庫(kù)。

數(shù)據(jù)倉(cāng)庫(kù)（data warehouse）

企業(yè)可能有幾十個(gè)不同交易處理系統(tǒng)：面向終端客戶的網(wǎng)站，控制實(shí)體店的收銀系統(tǒng)，跟蹤倉(cāng)庫(kù)庫(kù)存，規(guī)劃車輛路線，供應(yīng)鏈管理，員工管理等。這些系統(tǒng)中每個(gè)都很復(fù)雜，需專人維護(hù)，所以系統(tǒng)最終都是彼此獨(dú)立運(yùn)行。

這些OLTP系統(tǒng)往往對(duì)業(yè)務(wù)運(yùn)作至關(guān)重要，因而通常要求高可用 與處理事務(wù)時(shí) 低延遲。所以DBA會(huì)密切關(guān)注他們的OLTP數(shù)據(jù)庫(kù)，DBA一般不愿意讓業(yè)務(wù)分析人員在OLTP數(shù)據(jù)庫(kù)上運(yùn)行臨時(shí)分析查詢，因?yàn)檫@些查詢通常開銷巨大，會(huì)掃描大量數(shù)據(jù)集，這會(huì)損害并發(fā)執(zhí)行事務(wù)的性能。

相比之下，數(shù)據(jù)倉(cāng)庫(kù)是個(gè)獨(dú)立數(shù)據(jù)庫(kù)，分析人員可查詢他們想要的內(nèi)容而不影響OLTP操作。數(shù)據(jù)倉(cāng)庫(kù)包含公司各種OLTP系統(tǒng)的只讀副本。從OLTP數(shù)據(jù)庫(kù)（使用周期數(shù)據(jù)轉(zhuǎn)儲(chǔ)或連續(xù)更新流）中提取數(shù)據(jù)，轉(zhuǎn)換成適合分析的模式，清理并加載到數(shù)據(jù)倉(cāng)庫(kù)中。將數(shù)據(jù)存入倉(cāng)庫(kù)的過(guò)程稱為“提取-轉(zhuǎn)換-加載（Extract-Transform-Load，ETL）”：

圖8：數(shù)據(jù)倉(cāng)庫(kù)和簡(jiǎn)化的ETL過(guò)程

大廠幾乎都有數(shù)倉(cāng)，但小廠卻少聞。可能是因?yàn)樾S沒(méi)那么多不同OLTP系統(tǒng)，一般只有少量數(shù)據(jù)，完全可以在傳統(tǒng)SQL數(shù)據(jù)庫(kù)中直接查詢分析，甚至可以在Excel分析。而在大廠，做一些在小廠很簡(jiǎn)單的事，往往需大量繁重工作。

使用單獨(dú)的數(shù)倉(cāng)，而非直接查詢OLTP系統(tǒng)進(jìn)行分析，一大優(yōu)勢(shì)是數(shù)倉(cāng)能針對(duì)分析訪問(wèn)模式進(jìn)行優(yōu)化。之前討論的索引算法對(duì)OLTP工作效果很好，但不擅長(zhǎng)應(yīng)對(duì)分析查詢。

OLTP數(shù)據(jù)庫(kù) V.S 數(shù)據(jù)倉(cāng)庫(kù)

數(shù)倉(cāng)的數(shù)據(jù)模型通常是關(guān)系型，因?yàn)镾QL通常很適合分析查詢。有許多GUI數(shù)據(jù)分析工具可生成SQL查詢，可視化結(jié)果，并允許分析人員探索數(shù)據(jù)（通過(guò)下鉆，切片和切塊等操作）。

表面上，數(shù)倉(cāng)和關(guān)系OLTP數(shù)據(jù)庫(kù)相似，因?yàn)樗鼈兌加蠸QL查詢接口。但系統(tǒng)內(nèi)部很不同，它們針對(duì)迥然不同的查詢模式，各自進(jìn)行了優(yōu)化。許多數(shù)據(jù)庫(kù)供應(yīng)商都專注支持事務(wù)處理或分析工作負(fù)載，而不是同時(shí)支持。

一些數(shù)據(jù)庫(kù)（如Microsoft SQL Server和SAP HANA）支持在同一產(chǎn)品中支持事務(wù)處理和數(shù)倉(cāng)。但它們正在日益成為兩個(gè)獨(dú)立的存儲(chǔ)和查詢引擎，這些引擎恰好能通過(guò)一個(gè)通用SQL接口進(jìn)行訪問(wèn)。

最近，大量開源的基于Hadoop的SQL項(xiàng)目出現(xiàn)，雖然還很年輕，但在與商業(yè)數(shù)倉(cāng)系統(tǒng)競(jìng)爭(zhēng)。入Apache Hive，Spark SQL，Cloudera Impala，F(xiàn)acebook Presto。

星型和雪花型的分析模式

根據(jù)應(yīng)用程序需要，在事務(wù)處理領(lǐng)域使用了多種不同數(shù)據(jù)模型。分析型業(yè)務(wù)的數(shù)據(jù)模型則少得多。許多數(shù)倉(cāng)都以相當(dāng)公式化的方式使用，稱為星型模式（也稱為維度建模）。

圖9中的模式顯示了可能在食品零售商處找到的數(shù)倉(cāng)。模式的中心是個(gè)事實(shí)表（該案例中稱為fact_sales）。事實(shí)表的每行表示在特定時(shí)間發(fā)生的事件（這里的每行代表客戶購(gòu)買的產(chǎn)品）。若分析網(wǎng)站流量而非零售量，則每行可能代表一個(gè)用戶的頁(yè)面瀏覽量或點(diǎn)擊量：

圖9：用于數(shù)據(jù)倉(cāng)庫(kù)的星型模式的示例**

一般事實(shí)被捕獲為單獨(dú)事件，因?yàn)檫@樣之后的分析中獲得最大的靈活性。但是，這意味著事實(shí)表可能很大。像蘋果這樣巨頭在數(shù)倉(cāng)可能有幾十PB交易歷史，其中大部分保存在事實(shí)表。

事實(shí)表中的列是屬性，如產(chǎn)品銷售的價(jià)格和從供應(yīng)商處購(gòu)買的成本（可計(jì)算出利潤(rùn)率），其它列是對(duì)其他表（稱為維度表）的外鍵引用。由于事實(shí)表中的每一行都表示一個(gè)事件，因此這些維度代表事件的發(fā)生地點(diǎn)，時(shí)間，方式和原因。

如圖9中，其中一個(gè)維度是銷售的產(chǎn)品。 dim_product? 表中的每行代表一種出售產(chǎn)品，包括庫(kù)存單位（SKU），說(shuō)明，品牌名稱，類別，脂肪含量，包裝尺寸等。fact_sales 表中的每行都使用外鍵表示在特定交易中銷售了哪些產(chǎn)品。（為簡(jiǎn)單起見(jiàn)，如果客戶一次購(gòu)買幾種不同產(chǎn)品，則它們?cè)谑聦?shí)表中被表示為單獨(dú)行）。

日期和時(shí)間通常使用維度表來(lái)表示，因?yàn)檫@允許對(duì)日期的附加信息（如公共假期）進(jìn)行編碼，從而允許查詢區(qū)分假期和非假期的銷售。

“星型模式”名字來(lái)源：當(dāng)表關(guān)系可視化時(shí)，事實(shí)表在中間，被一系列維度表包圍；與這些表的連接就像星星的光芒。

該模板的變體為雪花模式，其中維度被進(jìn)一步分解為子維度。如品牌和產(chǎn)品類別可能有單獨(dú)表格，且dim_product? 表格中的每行都能再次將品牌和類別作為外鍵，而不是將它們作為字符串直接存儲(chǔ)在 dim_product 表。雪花模式比星形模式更規(guī)范化，但星形模式是首選，因?yàn)閷?duì)于分析師，它更簡(jiǎn)單。

典型數(shù)倉(cāng)中，表格通常很寬：

• 事實(shí)表格通常超過(guò)100列，有時(shí)甚至數(shù)百列；
• 維度表也可能很寬，因?yàn)樗鼈儼赡芘c分析相關(guān)的所有元數(shù)據(jù)。如dim_store 表可能包括在每個(gè)商店提供哪些服務(wù)的細(xì)節(jié)，是否具有店內(nèi)面包房，店面面積，商店開張日期，最后一次裝修時(shí)間，距離最近的高速公路有多遠(yuǎn)等。