Hadoop構建數(shù)據(jù)倉庫實踐

Hadoop構建數(shù)據(jù)倉庫實踐目錄\h第1章?數(shù)據(jù)倉庫簡介?\h1.1什么是數(shù)據(jù)倉庫\h1.1.1數(shù)據(jù)倉庫的定義\h1.1.2建立數(shù)據(jù)倉庫的原因\h1.2操作型系統(tǒng)與分析型系統(tǒng)\h1.2.1操作型系統(tǒng)\h1.2.2分析型系統(tǒng)\h1.2.3操作型系統(tǒng)和分析型系統(tǒng)對比\h1.3數(shù)據(jù)倉庫架構\h1.3.1基本架構\h1.3.2主要數(shù)據(jù)倉庫架構\h1.3.3操作數(shù)據(jù)存儲\h1.4抽取-轉換-裝載\h1.4.1數(shù)據(jù)抽取\h1.4.2數(shù)據(jù)轉換\h1.4.3數(shù)據(jù)裝載\h1.4.4開發(fā)ETL系統(tǒng)的方法\h1.4.5常見ETL工具\h1.5數(shù)據(jù)倉庫需求\h1.5.1基本需求\h1.5.2數(shù)據(jù)需求\h1.6小結\h第2章?數(shù)據(jù)倉庫設計基礎?\h2.1關系數(shù)據(jù)模型\h2.1.1關系數(shù)據(jù)模型中的結構\h2.1.2關系完整性\h2.1.3規(guī)范化\h2.1.4關系數(shù)據(jù)模型與數(shù)據(jù)倉庫\h2.2維度數(shù)據(jù)模型\h2.2.1維度數(shù)據(jù)模型建模過程\h2.2.2維度規(guī)范化\h2.2.3維度數(shù)據(jù)模型的特點\h2.2.4星型模式\h2.2.5雪花模式\h2.3DataVault模型\h2.3.1DataVault模型簡介\h2.3.2DataVault模型的組成部分\h2.3.3DataVault模型的特點\h2.3.4DataVault模型的構建\h2.3.5DataVault模型實例\h2.4數(shù)據(jù)集市\(zhòng)h2.4.1數(shù)據(jù)集市的概念\h2.4.2數(shù)據(jù)集市與數(shù)據(jù)倉庫的區(qū)別\h2.4.3數(shù)據(jù)集市設計\h2.5數(shù)據(jù)倉庫實施步驟\h2.6小結\h第3章?Hadoop生態(tài)圈與數(shù)據(jù)倉庫?\h3.1大數(shù)據(jù)定義\h3.2Hadoop簡介\h3.2.1Hadoop的構成\h3.2.2Hadoop的主要特點\h3.2.3Hadoop架構\h3.3Hadoop基本組件\h3.3.1HDFS\h3.3.2MapReduce\h3.3.3YARN\h3.4Hadoop生態(tài)圈的其他組件\h3.5Hadoop與數(shù)據(jù)倉庫\h3.5.1關系數(shù)據(jù)庫的可擴展性瓶頸\h3.5.2CAP理論\h3.5.3Hadoop數(shù)據(jù)倉庫工具\h3.6小結\h第4章?安裝Hadoop?\h4.1Hadoop主要發(fā)行版本\h4.1.1ClouderaDistributionforHadoop(CDH)\h4.1.2HortonworksDataPlatform(HDP)\h4.1.3MapRHadoop\h4.2安裝ApacheHadoop\h4.2.1安裝環(huán)境\h4.2.2安裝前準備\h4.2.3安裝配置Hadoop\h4.2.4安裝后配置\h4.2.5初始化及運行\(zhòng)h4.3配置HDFSFederation\h4.4離線安裝CDH及其所需的服務\h4.4.1CDH安裝概述\h4.4.2安裝環(huán)境\h4.4.3安裝配置\h4.4.4ClouderaManager許可證管理\h4.5小結\h第5章?Kettle與Hadoop?\h5.1Kettle概述\h5.2Kettle連接Hadoop\h5.2.1連接HDFS\h5.2.2連接Hive\h5.3導出導入Hadoop集群數(shù)據(jù)\h5.3.1把數(shù)據(jù)從HDFS抽取到RDBMS\h5.3.2向Hive表導入數(shù)據(jù)\h5.4執(zhí)行Hive的HiveQL語句\h5.5MapReduce轉換示例\h5.6Kettle提交Spark作業(yè)\h5.6.1安裝Spark\h5.6.2配置Kettle向Spark集群提交作業(yè)\h5.7小結\h第6章?建立數(shù)據(jù)倉庫示例模型?\h6.1業(yè)務場景\h6.2Hive相關配置\h6.2.1選擇文件格式\h6.2.2支持行級更新\h6.2.3Hive事務支持的限制\h6.3Hive表分類\h6.4向Hive表裝載數(shù)據(jù)\h6.5建立數(shù)據(jù)庫表\h6.6裝載日期維度數(shù)據(jù)\h6.7小結\h第7章?數(shù)據(jù)抽取?\h7.1邏輯數(shù)據(jù)映射\h7.2數(shù)據(jù)抽取方式\h7.3導出成文本文件\h7.4分布式查詢\h7.5使用Sqoop抽取數(shù)據(jù)\h7.5.1Sqoop簡介\h7.5.2CDH5.7.0中的Sqoop\h7.5.3使用Sqoop抽取數(shù)據(jù)\h7.5.4Sqoop優(yōu)化\h7.6小結\h第8章?數(shù)據(jù)轉換與裝載?\h8.1數(shù)據(jù)清洗\h8.2Hive簡介\h8.2.1Hive的體系結構\h8.2.2Hive的工作流程\h8.2.3Hive服務器\h8.2.4Hive客戶端\h8.3初始裝載\h8.4定期裝載\h8.5Hive優(yōu)化\h8.6小結\h第9章?定期自動執(zhí)行ETL作業(yè)?\h9.1crontab\h9.2Oozie簡介\h9.2.1Oozie的體系結構\h9.2.2CDH5.7.0中的Oozie\h9.3建立定期裝載工作流\h9.4建立協(xié)調器作業(yè)定期自動執(zhí)行工作流\h9.5Oozie優(yōu)化\h9.6小結\h第10章?維度表技術?\h10.1增加列\(zhòng)h10.2維度子集\h10.3角色扮演維度\h10.4層次維度\h10.4.1固定深度的層次\h10.4.2遞歸\h10.4.3多路徑層次\h10.4.4參差不齊的層次\h10.5退化維度\h10.6雜項維度\h10.7維度合并\h10.8分段維度\h10.9小結\h第11章?事實表技術?\h11.1事實表概述\h11.2周期快照\h11.3累積快照\h11.4無事實的事實表\h11.5遲到的事實\h11.6累積度量\h11.7小結\h第12章?聯(lián)機分析處理?\h12.1聯(lián)機分析處理簡介\h12.1.1概念\h12.1.2分類\h12.1.3性能\h12.2Impala簡介\h12.3Hive、SparkSQL、Impala比較\h12.3.1SparkSQL簡介\h12.3.2Hive、SparkSQL、Impala比較\h12.3.3Hive、SparkSQL、Impala性能對比\h12.4聯(lián)機分析處理實例\h12.5ApacheKylin與OLAP\h12.5.1ApacheKylin架構\h12.5.2ApacheKylin安裝\h12.6小結\h第13章?數(shù)據(jù)可視化?\h13.1數(shù)據(jù)可視化簡介\h13.2Hue簡介\h13.2.1Hue功能快速預覽\h13.2.2配置元數(shù)據(jù)存儲\h13.3Zeppelin簡介\h13.3.1Zeppelin架構\h13.3.2Zeppelin安裝配置\h13.3.3在Zeppelin中添加MySQL翻譯器\h13.4Hue、Zeppelin比較\h13.5數(shù)據(jù)可視化實例\h13.6小結注：原文檔電子版（非掃描），需要的請下載本文檔后留言謝謝。第1章

?數(shù)據(jù)倉庫簡介?對于每一種技術，先要理解相關的概念和它之所以出現(xiàn)的原因，這對于我們繼續(xù)深入學習其技術細節(jié)大有裨益。本章將介紹數(shù)據(jù)倉庫的定義，它和傳統(tǒng)操作型數(shù)據(jù)庫應用的區(qū)別，以及為什么我們需要數(shù)據(jù)倉庫。在對數(shù)據(jù)倉庫的概念有了一個基本的認識后，向讀者介紹四種常見的數(shù)據(jù)倉庫架構，然后說明ETL這個重要的數(shù)據(jù)倉庫概念。本章最后概要介紹對于一個數(shù)據(jù)倉庫的基本需求和數(shù)據(jù)需求。1.1什么是數(shù)據(jù)倉庫數(shù)據(jù)倉庫的概念可以追溯到20世紀80年代，當時IBM的研究人員開發(fā)出了“商業(yè)數(shù)據(jù)倉庫”。本質上，數(shù)據(jù)倉庫試圖提供一種從操作型系統(tǒng)到?jīng)Q策支持環(huán)境的數(shù)據(jù)流架構模型。數(shù)據(jù)倉庫概念的提出，是為了解決和這個數(shù)據(jù)流相關的各種問題，主要是解決多重數(shù)據(jù)復制帶來的高成本問題。在沒有數(shù)據(jù)倉庫的時代，需要大量的冗余數(shù)據(jù)來支撐多個決策支持環(huán)境。在大組織里，多個決策支持環(huán)境獨立運作是典型的情況。盡管每個環(huán)境服務于不同的用戶，但這些環(huán)境經(jīng)常需要大量相同的數(shù)據(jù)。處理過程收集、清洗、整合來自多個數(shù)據(jù)源的數(shù)據(jù)，并為每個決策支持環(huán)境做部分數(shù)據(jù)復制。數(shù)據(jù)源通常是早已存在的操作型系統(tǒng)，很多是遺留系統(tǒng)。此外，當一個新的決策支持環(huán)境形成時，操作型系統(tǒng)的數(shù)據(jù)經(jīng)常被再次復用。用戶訪問這些處理后的數(shù)據(jù)。1.1.1數(shù)據(jù)倉庫的定義數(shù)據(jù)倉庫之父BillInmon在1991年出版的BuildingtheDataWarehouse一書中首次提出了被廣為認可的數(shù)據(jù)倉庫定義。Inmon將數(shù)據(jù)倉庫描述為一個面向主題的、集成的、隨時間變化的、非易失的數(shù)據(jù)集合，用于支持管理者的決策過程。這個定義有些復雜并且難以理解。下面我們將它分解開來進行說明。面向主題傳統(tǒng)的操作型系統(tǒng)是圍繞組織的功能性應用進行組織的，而數(shù)據(jù)倉庫是面向主題的。主題是一個抽象概念，簡單地說就是與業(yè)務相關的數(shù)據(jù)的類別，每一個主題基本對應一個宏觀的分析領域。數(shù)據(jù)倉庫被設計成輔助人們分析數(shù)據(jù)。例如，一個公司要分析銷售數(shù)據(jù)，就可以建立一個專注于銷售的數(shù)據(jù)倉庫，使用這個數(shù)據(jù)倉庫，就可以回答類似于“去年誰是我們這款產(chǎn)品的最佳用戶”這樣的問題。這個場景下的銷售，就是一個數(shù)據(jù)主題，而這種通過劃分主題定義數(shù)據(jù)倉庫的能力，就使得數(shù)據(jù)倉庫是面向主題的。主題域是對某個主題進行分析后確定的主題的邊界，如客戶、銷售、產(chǎn)品都是主題域的例子。集成集成的概念與面向主題是密切相關的。還用銷售的例子，假設公司有多條產(chǎn)品線和多種產(chǎn)品銷售渠道，而每個產(chǎn)品線都有自己獨立的銷售數(shù)據(jù)庫。此時要想從公司層面整體分析銷售數(shù)據(jù)，必須將多個分散的數(shù)據(jù)源統(tǒng)一成一致的、無歧義的數(shù)據(jù)格式后，再放置到數(shù)據(jù)倉庫中。因此數(shù)據(jù)倉庫必須能夠解決諸如產(chǎn)品命名沖突、計量單位不一致等問題。當完成了這些數(shù)據(jù)整合工作后，該數(shù)據(jù)倉庫就可稱為是集成的。隨時間變化為了發(fā)現(xiàn)業(yè)務變化的趨勢、存在的問題，或者新的機會，需要分析大量的歷史數(shù)據(jù)。這與聯(lián)機事務處理（OLTP）系統(tǒng)形成鮮明的對比。聯(lián)機事務處理反應的是當前時間點的數(shù)據(jù)情況，要求高性能、高并發(fā)和極短的響應時間，出于這樣的需求考慮，聯(lián)機事務處理系統(tǒng)中一般都將數(shù)據(jù)依照活躍程度分級，把歷史數(shù)據(jù)遷移到歸檔數(shù)據(jù)庫中。而數(shù)據(jù)倉庫關注的是數(shù)據(jù)隨時間變化的情況，并且能反映在過去某個時間點的數(shù)據(jù)是怎樣的。換句話說，數(shù)據(jù)倉庫中的數(shù)據(jù)是反映了某一歷史時間點的數(shù)據(jù)快照，這也就是術語“隨時間變化”的含義。當然，任何一個存儲結構都不可能無限擴展，數(shù)據(jù)也不可能只入不出地永久駐留在數(shù)據(jù)倉庫中，它在數(shù)據(jù)倉庫中也有自己的生命周期。到了一定時候，數(shù)據(jù)會從數(shù)據(jù)倉庫中移除。移除的方式可能是將細節(jié)數(shù)據(jù)匯總后刪除、將老的數(shù)據(jù)轉儲到大容量介質后刪除和直接物理刪除等。非易失非易失指的是，一旦進入到數(shù)據(jù)倉庫中，數(shù)據(jù)就不應該再有改變。操作型環(huán)境中的數(shù)據(jù)一般都會頻繁更新，而在數(shù)據(jù)倉庫環(huán)境中一般并不進行數(shù)據(jù)更新。當改變的操作型數(shù)據(jù)進入數(shù)據(jù)倉庫時會產(chǎn)生新的記錄，這樣就保留了數(shù)據(jù)變化的歷史軌跡。也就是說，數(shù)據(jù)倉庫中的數(shù)據(jù)基本是靜態(tài)的。這是一個不難理解的邏輯概念。數(shù)據(jù)倉庫的目的就是要根據(jù)曾經(jīng)發(fā)生的事件進行分析，如果數(shù)據(jù)是可修改的，將使歷史分析變得沒有意義。除了以上四個特性外，數(shù)據(jù)倉庫還有一個非常重要的概念就是粒度。粒度問題遍布于數(shù)據(jù)倉庫體系結構的各個部分。粒度是指數(shù)據(jù)的細節(jié)或匯總程度，細節(jié)程度越高，粒度級別越低。例如，單個事務是低粒度級別，而全部一個月事務的匯總就是高粒度級別。數(shù)據(jù)粒度一直是數(shù)據(jù)倉庫設計需要重點思考的問題。在早期的操作型系統(tǒng)中，當細節(jié)數(shù)據(jù)被更新時，幾乎總是將其存放在最低粒度級別上；而在數(shù)據(jù)倉庫環(huán)境中，通常都不這樣做。例如，如果數(shù)據(jù)被裝載進數(shù)據(jù)倉庫的頻率是每天一次，那么一天之內的數(shù)據(jù)更新將被忽略。粒度之所以是數(shù)據(jù)倉庫環(huán)境的關鍵設計問題，是因為它極大地影響數(shù)據(jù)倉庫的數(shù)據(jù)量和可以進行的查詢類型。粒度級別越低，數(shù)據(jù)量越大，查詢的細節(jié)程度越高，查詢范圍越廣泛，反之亦然。大多數(shù)情況下，數(shù)據(jù)會以很低的粒度級別進入數(shù)據(jù)倉庫，如日志類型的數(shù)據(jù)或單擊流數(shù)據(jù)，此時應該對數(shù)據(jù)進行編輯、過濾和匯總，使其適應數(shù)據(jù)倉庫環(huán)境的粒度級別。如果得到的數(shù)據(jù)粒度級別比數(shù)據(jù)倉庫的高，那將意味著在數(shù)據(jù)存入數(shù)據(jù)倉庫前，開發(fā)人員必須花費大量設計和資源來對數(shù)據(jù)進行拆分。1.1.2建立數(shù)據(jù)倉庫的原因現(xiàn)在你應該已經(jīng)熟悉了數(shù)據(jù)倉庫的概念，那么數(shù)據(jù)倉庫里的數(shù)據(jù)從哪里來呢？通常數(shù)據(jù)倉庫的數(shù)據(jù)來自各個業(yè)務應用系統(tǒng)。業(yè)務系統(tǒng)中的數(shù)據(jù)形式多種多樣，可能是Oracle、MySQL、SQLServer等關系數(shù)據(jù)庫里的結構化數(shù)據(jù)，可能是文本、CSV等平面文件或Word、Excel文檔中的非結構化數(shù)據(jù)，還可能是HTML、XML等自描述的半結構化數(shù)據(jù)。這些業(yè)務數(shù)據(jù)經(jīng)過一系列的數(shù)據(jù)抽取、轉換、清洗，最終以一種統(tǒng)一的格式裝載進數(shù)據(jù)倉庫。數(shù)據(jù)倉庫里的數(shù)據(jù)作為分析用的數(shù)據(jù)源，提供給后面的即席查詢、分析系統(tǒng)、數(shù)據(jù)集市、報表系統(tǒng)、數(shù)據(jù)挖掘系統(tǒng)等。從以上描述可以看到，從存儲的角度看，數(shù)據(jù)倉庫里的數(shù)據(jù)實際上已經(jīng)存在于業(yè)務應用系統(tǒng)中，那么為什么不能直接操作業(yè)務系統(tǒng)中的數(shù)據(jù)用于分析，而要使用數(shù)據(jù)倉庫呢？實際上在數(shù)據(jù)倉庫技術出現(xiàn)前，有很多數(shù)據(jù)分析的先驅者已經(jīng)發(fā)現(xiàn)，簡單的“直接訪問”方式很難良好工作，這樣做的失敗案例數(shù)不勝數(shù)。下面列舉一些直接訪問業(yè)務系統(tǒng)無法工作的原因：某些業(yè)務數(shù)據(jù)由于安全或其他因素不能直接訪問。業(yè)務系統(tǒng)的版本變更很頻繁，每次變更都需要重寫分析系統(tǒng)并重新測試。很難建立和維護匯總數(shù)據(jù)來源于多個業(yè)務系統(tǒng)版本的報表。業(yè)務系統(tǒng)的列名通常是硬編碼，有時僅僅是無意義的字符串，這讓編寫分析系統(tǒng)更加困難。業(yè)務系統(tǒng)的數(shù)據(jù)格式，如日期、數(shù)字的格式不統(tǒng)一。業(yè)務系統(tǒng)的表結構為事務處理性能而優(yōu)化，有時并不適合查詢與分析。沒有適當?shù)姆绞綄⒂袃r值的數(shù)據(jù)合并進特定應用的數(shù)據(jù)庫。沒有適當?shù)奈恢么鎯υ獢?shù)據(jù)。用戶需要看到的顯示數(shù)據(jù)字段，有時在數(shù)據(jù)庫中并不存在。通常事務處理的優(yōu)先級比分析系統(tǒng)高，所以如果分析系統(tǒng)和事務處理運行在同一硬件之上，分析系統(tǒng)往往性能很差。有誤用業(yè)務數(shù)據(jù)的風險。極有可能影響業(yè)務系統(tǒng)的性能。盡管需要增加軟硬件的投入，但建立獨立數(shù)據(jù)倉庫與直接訪問業(yè)務數(shù)據(jù)相比，無論是成本還是帶來的好處，這樣做都是值得的。隨著處理器和存儲成本的逐年降低，數(shù)據(jù)倉庫方案的優(yōu)勢更加明顯，在經(jīng)濟上也更具可行性。無論是建立數(shù)據(jù)倉庫還要實施別的項目，都要從時間、成本、功能等幾個角度權衡比較，認真研究一下是否真正需要一個數(shù)據(jù)倉庫，這是一個很好的問題。當你的組織很小，人數(shù)很少，業(yè)務單一，數(shù)據(jù)量也不大，可能你真的不需要建立數(shù)據(jù)倉庫。畢竟要想成功建立一個數(shù)據(jù)倉庫并使其發(fā)揮應有的作用還是很有難度的，需要大量的人、財、物力，并且即便花費很大的代價完成了數(shù)據(jù)倉庫的建設，在較短一段時間內也不易顯現(xiàn)出價值。在沒有專家介入而僅憑組織自身力量建立數(shù)據(jù)倉庫時，還要冒相當大的失敗風險。但是，當你所在的組織有超過1000名雇員，有幾十個部門的時候，它所面臨的挑戰(zhàn)將是完全不同的。在這個充滿競爭的時代，做出正確的決策對一個組織至關重要。而要做出最恰當?shù)臎Q策，僅依據(jù)對孤立維度的分析是不可能實現(xiàn)的。這時必須要考慮所有相關數(shù)據(jù)的可用性，而這個數(shù)據(jù)最好的來源就是一個設計良好的數(shù)據(jù)倉庫。假設一個超市連鎖企業(yè)，在沒有實現(xiàn)數(shù)據(jù)倉庫的情況下，最終該企業(yè)會發(fā)現(xiàn)，要分析商品銷售情況是非常困難的，比如哪些商品被售出，哪些沒有被售出，什么時間銷量上升，哪個年齡組的客戶傾向于購買哪些特定商品等這些問題都無從回答。而給出這些問題的正確答案正是一個具有吸引力的挑戰(zhàn)。這只是第一步，必須要搞清楚一個特定商品到底適不適合18～25歲的人群，以決定該商品的銷售策略。一旦從數(shù)據(jù)分析得出的結論是銷售該商品的價值在降低，那么必須實施后面的步驟分析在哪里出了問題，并采取相應的措施加以改進。在輔助戰(zhàn)略決策層面，數(shù)據(jù)倉庫的重要性更加凸顯。作為一個企業(yè)的經(jīng)營者或管理者，他必須對某些問題給出答案，以獲得超越競爭對手的額外優(yōu)勢?；卮疬@些問題對于基本的業(yè)務運營可能不是必需的，但對于企業(yè)的生存發(fā)展卻必不可少。下面是一些常見問題的例子：如何把公司的市場份額提升5%？哪些產(chǎn)品的市場表現(xiàn)不令人滿意？哪些代理商需要銷售政策的幫助？提供給客戶的服務質量如何？哪些需要改進？回答這些戰(zhàn)略性問題的關鍵一環(huán)就是數(shù)據(jù)倉庫。就拿“提供給客戶的服務質量如何？”這一問題來說，這是管理者最為關心的問題之一。我們可以把這一問題分解成許多具體的小問題，比如第一個問題是，在過去半年中，收到過多少用戶反饋？可以在數(shù)據(jù)倉庫上發(fā)出對應的查詢，并對查詢結果進行分析。之所以能夠這樣做，是因為數(shù)據(jù)倉庫中含有每一條用戶反饋信息。你可能已經(jīng)想到了，第二個問題自然就是，在這些用戶反饋當中，給出“非常滿意”“一般”“不滿意”的人數(shù)分別有多少？下面的問題就是客戶所強調的需要改進的地方和廣受批評的地方是哪些？這在數(shù)據(jù)倉庫的用戶反饋信息中也有一列來表示，它也能從一個側面反映出客戶關心的問題是哪些。以上這三個問題的答案聯(lián)合在一起，就可以得出客戶服務滿意度的結論，并且準確定位哪些地方急需改進。下面簡單總結一下使用數(shù)據(jù)倉庫的好處：將多個數(shù)據(jù)源集成到單一數(shù)據(jù)存儲，因此可以使用單一數(shù)據(jù)查詢引擎展示數(shù)據(jù)。緩解在事務處理數(shù)據(jù)庫上因執(zhí)行大查詢而產(chǎn)生的資源競爭問題。維護歷史數(shù)據(jù)。通過對多個源系統(tǒng)的數(shù)據(jù)整合，使得在整個企業(yè)的角度存在統(tǒng)一的中心視圖。通過提供一致的編碼和描述，減少或修正壞數(shù)據(jù)問題，提高數(shù)據(jù)質量。一致性地表示組織信息。提供所有數(shù)據(jù)的單一通用數(shù)據(jù)模型，而不用關心數(shù)據(jù)源。重構數(shù)據(jù)，使數(shù)據(jù)對業(yè)務用戶更有意義。向復雜分析查詢交付優(yōu)秀的查詢性能，同時不影響操作型系統(tǒng)。開發(fā)決策型查詢更簡單。1.2操作型系統(tǒng)與分析型系統(tǒng)上一小節(jié)已經(jīng)多次提及操作型系統(tǒng)和分析型系統(tǒng)，本小節(jié)將詳細闡述它們的概念及差異。在一個大組織中，往往都有兩種類型的系統(tǒng)，操作型和分析型，而這兩種系統(tǒng)大都以數(shù)據(jù)庫作為數(shù)據(jù)管理、組織和操作的工具。操作型系統(tǒng)完成組織的核心業(yè)務，例如下訂單、更新庫存、記錄支付信息等。這些系統(tǒng)是事務型的，核心目標是盡可能快地處理事務，同時維護數(shù)據(jù)的一致性和完整性。而分析型系統(tǒng)的主要作用是通過數(shù)據(jù)分析評估組織的業(yè)務經(jīng)營狀況，并進一步輔助決策。1.2.1操作型系統(tǒng)相信從事過IT或相關工作的讀者對操作型系統(tǒng)都不會感到陌生。幾乎所有的互聯(lián)網(wǎng)線上系統(tǒng)、MIS、OA等都屬于這類系統(tǒng)的應用。操作型系統(tǒng)是一類專門用于管理面向事務的應用的信息系統(tǒng)?！笆聞铡币辉~在這里存在一些歧義，有些人理解事務是一個計算機或數(shù)據(jù)庫的術語，另一些人所理解的事務是指業(yè)務或商業(yè)交易，這里使用前一種語義。那么什么是數(shù)據(jù)庫技術中的事務呢？這是首先需要明確的概念。事務是工作于數(shù)據(jù)庫管理系統(tǒng)（或類似系統(tǒng)）中的一個邏輯單元，該邏輯單元中的操作被以一種獨立于其他事務的可靠方式所處理。事務一般代表著數(shù)據(jù)改變，它提供“all-or-nothing”操作，就是說事務中的一系列操作要么完全執(zhí)行，要么完全不執(zhí)行。在數(shù)據(jù)庫中使用事務主要出于兩個目的：（1）保證工作單元的可靠性。當數(shù)據(jù)庫系統(tǒng)異常宕機時，其中執(zhí)行的操作或者已經(jīng)完成或者只有部分完成，很多沒有完成的操作此時處于一種模糊狀態(tài)。在這種情況下，數(shù)據(jù)庫系統(tǒng)必須能夠恢復到數(shù)據(jù)一致的正常狀態(tài)。（2）提供并發(fā)訪問數(shù)據(jù)庫的多個程序間的隔離。如果沒有這種隔離，程序得到的結果很可能是錯誤的。根據(jù)事務的定義，引申出事務具有原子性、一致性、隔離性、持久性的特點，也就是數(shù)據(jù)庫領域中常說的事務的ACID特性。原子性指的是事務中的一系列操作或全執(zhí)行或不執(zhí)行，這些操作是不可再分的。原子性可以防止數(shù)據(jù)被部分修改。銀行賬號間轉賬是一個事務原子性的例子。簡單地說，從A賬號向B賬號轉賬有兩步操作：A賬號提取，B賬號存入。這兩個操作以原子性事務執(zhí)行，使數(shù)據(jù)庫保持一致的狀態(tài)，即使這兩個操作的任何一步失敗了，總的金額數(shù)不會減少也不會增加。一致性數(shù)據(jù)庫系統(tǒng)中的一致性是指任何數(shù)據(jù)庫事務只能以允許的方式修改數(shù)據(jù)。任何數(shù)據(jù)庫寫操作必須遵循既有的規(guī)則，包括約束、級聯(lián)、觸發(fā)器以及它們的任意組合。一致性并不保證應用程序邏輯的正確性，但它能夠保證不會因為程序錯誤而使數(shù)據(jù)庫產(chǎn)生違反規(guī)則的結果。隔離性在數(shù)據(jù)庫系統(tǒng)中，隔離性決定了其他用戶所能看到的事務完整性程度。例如，一個用戶正在生成一個采購訂單，并且已經(jīng)生成了訂單主記錄，但還沒有生成訂單條目明細記錄。此時訂單主記錄能否被其他并發(fā)用戶看到呢？這就是由隔離級別決定的。數(shù)據(jù)庫系統(tǒng)中，按照由低到高一般有讀非提交、讀提交、可重復讀、串行化等幾種隔離級。數(shù)據(jù)庫系統(tǒng)并不一定實現(xiàn)所有的隔離級別，如Oracle數(shù)據(jù)庫只實現(xiàn)了讀提交和串行化，而MySQL數(shù)據(jù)庫則提供這全部四種隔離級別。隔離級越低，多用戶同時訪問數(shù)據(jù)的能力越高，但同時也會增加臟讀、丟失更新等并發(fā)操作的負面影響。相反，高隔離級降低了并發(fā)影響，但需要使用更多的系統(tǒng)資源，也增加了事務被阻塞的可能性。持久性數(shù)據(jù)庫系統(tǒng)的持久性保證已經(jīng)提交的事務是永久保存的。例如，如果一個機票預訂報告顯示一個座位已經(jīng)訂出，那么即使系統(tǒng)崩潰，被訂了的座位也會一直保持被訂出的狀態(tài)。持久性可以通過在事務提交時將事務日志刷新至永久性存儲介質來實現(xiàn)。了解了事務的基本概念后，我們再來看操作型系統(tǒng)就比較容易理解了。操作型系統(tǒng)通常是高并發(fā)、高吞吐量的系統(tǒng)，具有大量檢索、插入、更新操作，事務數(shù)量大，但每個事務影響的數(shù)據(jù)量相對較小。這樣的系統(tǒng)很適合在線應用，這些應用有成千上萬用戶在同時使用，并要求能夠立即響應用戶請求。操作型系統(tǒng)常被整合到面向服務的架構（SOA）和Web服務里。對操作型系統(tǒng)應用的主要要求是高可用、高速度、高并發(fā)、可恢復和保證數(shù)據(jù)一致性，在各種互聯(lián)網(wǎng)應用層出不窮的今天，這些系統(tǒng)要求是顯而易見的。1．操作型系統(tǒng)的數(shù)據(jù)庫操作在數(shù)據(jù)庫使用上，操作型系統(tǒng)常用的操作是增、改、查，并且通常是插入與更新密集型的，同時會對數(shù)據(jù)庫進行大量并發(fā)查詢，而刪除操作相對較少。操作型系統(tǒng)一般都直接在數(shù)據(jù)庫上修改數(shù)據(jù)，沒有中間過渡區(qū)。2．操作型系統(tǒng)的數(shù)據(jù)庫設計操作型系統(tǒng)的特征是大量短的事務，并強調快速處理查詢。每秒事務數(shù)是操作型系統(tǒng)的一個有效度量指標。針對以上這些特點，數(shù)據(jù)庫設計一定要滿足系統(tǒng)的要求。在數(shù)據(jù)庫邏輯設計上，操作型系統(tǒng)的應用數(shù)據(jù)庫大都使用規(guī)范化設計方法，通常要滿足第三范式。這是因為規(guī)范化設計能最大限度地數(shù)據(jù)冗余，因而提供更快更高效的方式執(zhí)行數(shù)據(jù)庫寫操作。關于規(guī)范化設計概念及其相關內容，會在第2章“數(shù)據(jù)倉庫設計”中做詳細說明。在數(shù)據(jù)庫物理設計上，應該依據(jù)系統(tǒng)所使用的數(shù)據(jù)庫管理系統(tǒng)的具體特點，做出相應的設計，畢竟每種數(shù)據(jù)庫管理系統(tǒng)在實現(xiàn)細節(jié)上還是存在很大差異的。下面就以Oracle數(shù)據(jù)庫為例，簡要說明在設計操作型系統(tǒng)數(shù)據(jù)庫時應該考慮的問題。調整回滾段?；貪L段是數(shù)據(jù)庫的一部分，其中記錄著最終被回滾的事務的行為。這些回滾段信息可以提供讀一致性、回滾事務和數(shù)據(jù)庫恢復。合理使用聚簇。聚簇是一種數(shù)據(jù)庫模式，其中包含有共用一列或多列的多個表。數(shù)據(jù)庫中的聚簇表用于提高連接操作的性能。適當調整數(shù)據(jù)塊大小。數(shù)據(jù)塊大小應該是操作系統(tǒng)塊大小的倍數(shù)，并且設置上限以避免不必要的I/O。設置緩沖區(qū)高速緩存大小。合理的緩存大小能夠有效避免不必要的磁盤I/O。動態(tài)分配表空間。合理劃分數(shù)據(jù)庫分區(qū)。分區(qū)最大的作用是能在可用性和安全性維護期間保持事務處理的性能。SQL優(yōu)化。有效利用數(shù)據(jù)庫管理系統(tǒng)的優(yōu)化器，使用最佳的數(shù)據(jù)訪問路徑。避免過度使用索引。大量的數(shù)據(jù)修改會給索引維護帶來壓力，從而對整個系統(tǒng)的性能產(chǎn)生負面影響。以上所講的操作型系統(tǒng)都是以數(shù)據(jù)庫系統(tǒng)為核心，而數(shù)據(jù)庫系統(tǒng)為了保持ACID特性，本質上是單一集中式系統(tǒng)。在當今這個信息爆炸的時代，集中式數(shù)據(jù)庫往往已無法支撐業(yè)務的需要（從某訂票網(wǎng)站和某電商網(wǎng)站的超大瞬時并發(fā)量來看，這已是一個不爭的事實）。這就給操作型系統(tǒng)帶來新的挑戰(zhàn)。分布式事務、去中心化、CAP與最終一致性等一系列新的理論和技術為解決系統(tǒng)擴展問題應運而生。這是一個很大的話題，要想說清楚需要很多的擴展知識和大量篇幅，故這里只是點到為止，不做展開。1.2.2分析型系統(tǒng)在計算機領域，分析型系統(tǒng)是一種快速回答多維分析查詢的實現(xiàn)方式。它也是更廣泛范疇的所謂商業(yè)智能的一部分（商業(yè)智能還包含數(shù)據(jù)庫、報表系統(tǒng)、數(shù)據(jù)挖掘、數(shù)據(jù)可視化等研究方向）。分析型系統(tǒng)的典型應用包括銷售業(yè)務分析報告、市場管理報告、業(yè)務過程管理（BPM）、預算和預測、金融分析報告及其類似的應用。1．分析型系統(tǒng)的數(shù)據(jù)庫操作在數(shù)據(jù)庫層面，分析型系統(tǒng)操作被定義成少量的事務，復雜的查詢，處理歸檔和歷史數(shù)據(jù)。這些數(shù)據(jù)很少被修改，從數(shù)據(jù)庫抽取數(shù)據(jù)是最多的操作，也是識別這種系統(tǒng)的關鍵特征。分析型數(shù)據(jù)庫基本上都是讀操作。2．分析型系統(tǒng)的數(shù)據(jù)庫設計分析型系統(tǒng)的特征是相對少量的事務，但查詢通常非常復雜并且會包含聚合計算，例如今年和去年同時期的數(shù)據(jù)對比、百分比變化趨勢等。分析型數(shù)據(jù)庫中的數(shù)據(jù)一般來自于一個企業(yè)級數(shù)據(jù)倉庫，是整合過的歷史數(shù)據(jù)。對于分析型系統(tǒng)，吞吐量是一個有效的性能度量指標。在數(shù)據(jù)庫邏輯設計上，分析型數(shù)據(jù)庫使用多維數(shù)據(jù)模型，通常是設計成星型模式或雪花模式。關于多維數(shù)據(jù)模型的概念及其相關內容，會在第2章“數(shù)據(jù)倉庫設計”中做詳細說明。在數(shù)據(jù)庫物理設計上，依然以Oracle數(shù)據(jù)庫為例，簡要說明在設計分析型系統(tǒng)數(shù)據(jù)庫時應該考慮的一些問題。表分區(qū)。可以獨立定義表分區(qū)的物理存儲屬性，將不同分區(qū)的數(shù)據(jù)存放到多個物理文件上，這樣做一方面可以分散I/O；另一方面，當數(shù)據(jù)量非常大時，方便數(shù)據(jù)維護；再有就是利用分區(qū)消除查詢數(shù)據(jù)時，不用掃描整張表，從而提高查詢性能。位圖索引。當查詢條件中包含低基數(shù)（不同值很少，例如性別）的列，尤其是包含有這些列上的or、and或not這樣的邏輯運算時，或者從有大量行的表中返回大量的行時，應考慮位圖索引。物化視圖。物化視圖物理存儲查詢所定義的數(shù)據(jù)，能夠自動增量刷新數(shù)據(jù)，并且可以利用查詢重寫特性極大地提高查詢速度，是分析型系統(tǒng)常用的技術。并行化操作?？梢栽诓樵兇罅繑?shù)據(jù)時執(zhí)行并行化操作，這樣會導致多個服務器進程為同一個查詢語句工作，使用該查詢可以快速完成，但是會耗費更多的資源。隨著數(shù)據(jù)的大量積累和大數(shù)據(jù)時代的到來，人們對于數(shù)據(jù)分析的依賴性越來越強，而分析型系統(tǒng)也隨之越來越顯示出重要性。舉一個簡單的例子，在一家醫(yī)院中，保存有20年的非常完整的病人信息。醫(yī)院領導想看到關于最常見的疾病、成功治愈率、實習醫(yī)生的實習天數(shù)等很多相關數(shù)據(jù)的詳細報告。為了滿足這個需求，應用分析型系統(tǒng)查詢醫(yī)院信息數(shù)據(jù)倉庫，并通過復雜查詢得到結果，然后將報告提交給領導做進一步分析。1.2.3操作型系統(tǒng)和分析型系統(tǒng)對比操作型系統(tǒng)和分析型系統(tǒng)是兩種不同種類的信息系統(tǒng)。它們都與數(shù)據(jù)庫技術相關，數(shù)據(jù)庫提供方法支持這兩種系統(tǒng)的功能。操作型系統(tǒng)和分析型系統(tǒng)以完全不同的方式使用數(shù)據(jù)庫，不僅如此，分析型系統(tǒng)更加注重數(shù)據(jù)分析和報表，而操作型系統(tǒng)的目標是一個伴有大量數(shù)據(jù)改變的事務優(yōu)化系統(tǒng)。對于學習數(shù)據(jù)科學及其相關技術的讀者，了解這兩種信息處理方式的區(qū)別至關重要。這也是理解商業(yè)智能、數(shù)據(jù)挖掘、數(shù)據(jù)倉庫、數(shù)據(jù)模型、ETL處理和大數(shù)據(jù)等系統(tǒng)的基礎。通過前面對兩種系統(tǒng)的描述，我們可以對比它們的很多方面。表1-1總結了兩種系統(tǒng)的主要區(qū)別。后面我們進一步討論每一個容易產(chǎn)生疑惑的對比項，以幫助你理解。表1-1操作型系統(tǒng)和分析型系統(tǒng)對比首先兩種系統(tǒng)的側重點不同。操作型系統(tǒng)更適合對已有數(shù)據(jù)的更新，所以是日常處理工作或在線系統(tǒng)的選擇。相反，分析型系統(tǒng)提供在大量存儲數(shù)據(jù)上的分析能力，所以這類系統(tǒng)更適合報表類應用。分析型系統(tǒng)通常是查詢歷史數(shù)據(jù)，這有助于得到更準確的分析報告。其次因為這兩種系統(tǒng)的目標完全不同，所以為了得到更好的性能，使用的數(shù)據(jù)模型和設計方法也不同。操作型系統(tǒng)數(shù)據(jù)庫通常使用規(guī)范化設計，為普通查詢和數(shù)據(jù)修改提供更好的性能。另一方面，分析型數(shù)據(jù)庫具有典型的數(shù)據(jù)倉庫組織形式。基于這兩個主要的不同點，我們可以推導出兩種系統(tǒng)其他方面的區(qū)別。操作型系統(tǒng)上的查詢更小，而分析型系統(tǒng)上執(zhí)行的查詢要復雜得多。所以操作型系統(tǒng)會比分析型系統(tǒng)快很多。操作型系統(tǒng)的數(shù)據(jù)會持續(xù)更新，并且更新會立即生效。而分析型系統(tǒng)的數(shù)據(jù)更新，是由預定義的處理作業(yè)同時裝載大量的數(shù)據(jù)集合，并且在裝載前需要做數(shù)據(jù)轉換，因此整個數(shù)據(jù)更新過程需要很長的執(zhí)行時間。由于操作型系統(tǒng)要做到絕對的數(shù)據(jù)安全和可用性，所以需要實施復雜的備份系統(tǒng)。基本的全量備份和增量備份都是必須要做的。而分析型系統(tǒng)只需要偶爾執(zhí)行數(shù)據(jù)備份即可，這一方面是因為這類系統(tǒng)一般不需要保持持續(xù)運行，另一方面數(shù)據(jù)還可以從操作型系統(tǒng)重復裝載。兩種系統(tǒng)的空間需求顯然都依賴于它們所存儲的數(shù)據(jù)量。分析型系統(tǒng)要存儲大量的歷史數(shù)據(jù)，因此需要更多的存儲空間。1.3數(shù)據(jù)倉庫架構前面兩個小節(jié)介紹了數(shù)據(jù)倉庫、操作型系統(tǒng)、分析型系統(tǒng)等概念，也指出了分析型系統(tǒng)的數(shù)據(jù)源一般來自數(shù)據(jù)倉庫，而數(shù)據(jù)倉庫的數(shù)據(jù)來自于操作型系統(tǒng)。本小節(jié)從技術角度討論數(shù)據(jù)倉庫的組成和架構。1.3.1基本架構“架構”是什么？這個問題從來就沒有一個準確的答案。在軟件行業(yè)，一種被普遍接受的架構定義是指系統(tǒng)的一個或多個結構。結構中包括軟件的構建（構建是指軟件的設計與實現(xiàn)），構建的外部可以看到屬性以及它們之間的相互關系。這里參考此定義，把數(shù)據(jù)倉庫架構理解成構成數(shù)據(jù)倉庫的組件及其之間的關系，那么就有了如圖1-1所示的數(shù)據(jù)倉庫架構圖。下面詳細說明圖1-1中的各個組件及其所起的作用。圖1-1數(shù)據(jù)倉庫架構圖中顯示的整個數(shù)據(jù)倉庫環(huán)境包括操作型系統(tǒng)和數(shù)據(jù)倉庫系統(tǒng)兩大部分。操作型系統(tǒng)的數(shù)據(jù)由各種形式的業(yè)務數(shù)據(jù)組成，這其中可能有關系數(shù)據(jù)庫、TXT或CSV文件、HTML或XML文檔，還可能存在外部系統(tǒng)的數(shù)據(jù)，比如網(wǎng)絡爬蟲抓取來的互聯(lián)網(wǎng)數(shù)據(jù)等，數(shù)據(jù)可能是結構化、半結構化、非結構化的。這些數(shù)據(jù)經(jīng)過抽取、轉換和裝載（ETL）過程進入數(shù)據(jù)倉庫系統(tǒng)。這里把ETL過程分成了抽取和轉換裝載兩個部分。抽取過程負責從操作型系統(tǒng)獲取數(shù)據(jù)，該過程一般不做數(shù)據(jù)聚合和匯總，但是會按照主題進行集成，物理上是將操作型系統(tǒng)的數(shù)據(jù)全量或增量復制到數(shù)據(jù)倉庫系統(tǒng)的RDS中。轉換裝載過程并將數(shù)據(jù)進行清洗、過濾、匯總、統(tǒng)一格式化等一系列轉換操作，使數(shù)據(jù)轉為適合查詢的格式，然后裝載進數(shù)據(jù)倉庫系統(tǒng)的TDS中。傳統(tǒng)數(shù)據(jù)倉庫的基本模式是用一些過程將操作型系統(tǒng)的數(shù)據(jù)抽取到文件，然后另一些過程將這些文件轉化成MySQL或Oracle這樣的關系數(shù)據(jù)庫的記錄。最后，第三部分過程負責把數(shù)據(jù)導入進數(shù)據(jù)倉庫。RDS（RAWDATASTORES）是原始數(shù)據(jù)存儲的意思。將原始數(shù)據(jù)保存到數(shù)據(jù)倉庫里是個不錯的想法。ETL過程的bug或系統(tǒng)中的其他錯誤是不可避免的，保留原始數(shù)據(jù)使得追蹤并修改這些錯誤成為可能。有時數(shù)據(jù)倉庫的用戶會有查詢細節(jié)數(shù)據(jù)的需求，這些細節(jié)數(shù)據(jù)的粒度與操作型系統(tǒng)的相同。有了RDS，這種需求就很容易實現(xiàn)，用戶可以查詢RDS里的數(shù)據(jù)而不必影響業(yè)務系統(tǒng)的正常運行。這里的RDS實際上是起到了操作型數(shù)據(jù)存儲（ODS）的作用，關于ODS相關內容本小節(jié)后面會有詳細論述。TDS（TRANSFORMEDDATASTORES）意為轉換后的數(shù)據(jù)存儲。這是真正的數(shù)據(jù)倉庫中的數(shù)據(jù)。大量的用戶會在經(jīng)過轉換的數(shù)據(jù)集上處理他們的日常查詢。如果前面的工作做得好，這些數(shù)據(jù)將被以保證最重要的和最頻繁的查詢能夠快速執(zhí)行的方式構建。這里的原始數(shù)據(jù)存儲和轉換后的數(shù)據(jù)存儲是邏輯概念，它們可能物理存儲在一起，也可能分開。當原始數(shù)據(jù)存儲和轉換后的數(shù)據(jù)存儲物理上分開時，它們不必使用同樣的軟硬件。傳統(tǒng)數(shù)據(jù)倉庫中，原始數(shù)據(jù)存儲通常是本地文件系統(tǒng)，原始數(shù)據(jù)被組織進相應的目錄中，這些目錄是基于數(shù)據(jù)從哪里抽取或何時抽取建立（例如以日期作為文件或目錄名稱的一部分）；轉換后的數(shù)據(jù)存儲一般是某種關系數(shù)據(jù)庫。自動化調度組件的作用是自動定期重復執(zhí)行ETL過程。不同角色的數(shù)據(jù)倉庫用戶對數(shù)據(jù)的更新頻率要求也會有所不同，財務主管需要每月的營收匯總報告，而銷售人員想看到每天的產(chǎn)品銷售數(shù)據(jù)。作為通用的需求，所有數(shù)據(jù)倉庫系統(tǒng)都應該能夠建立周期性自動執(zhí)行的工作流作業(yè)。傳統(tǒng)數(shù)據(jù)倉庫一般利用操作系統(tǒng)自帶的調度功能（如Linux的cron或Windows的計劃任務）實現(xiàn)作業(yè)自動執(zhí)行。數(shù)據(jù)目錄有時也被稱為元數(shù)據(jù)存儲，它可以提供一份數(shù)據(jù)倉庫中數(shù)據(jù)的清單。用戶通過它應該可以快速解決這些問題：什么類型的數(shù)據(jù)被存儲在哪里，數(shù)據(jù)集的構建有何區(qū)別，數(shù)據(jù)最后的訪問或更新時間等。此外還可以通過數(shù)據(jù)目錄感知數(shù)據(jù)是如何被操作和轉換的。一個好的數(shù)據(jù)目錄是讓用戶體驗到系統(tǒng)易用性的關鍵。查詢引擎組件負責實際執(zhí)行用戶查詢。傳統(tǒng)數(shù)據(jù)倉庫中，它可能是存儲轉換后數(shù)據(jù)的（Oracle、MySQL等關系數(shù)據(jù)庫系統(tǒng)內置的）查詢引擎，還可能是以固定時間間隔向其導入數(shù)據(jù)的OLAP立方體，如Essbasecube。用戶界面指的是最終用戶所使用的接口程序?？赡苁且粋€GUI軟件，如BI套件的中的客戶端軟件，也可能就是一個瀏覽器。1.3.2主要數(shù)據(jù)倉庫架構在數(shù)據(jù)倉庫技術演化過程中，產(chǎn)生了幾種主要的架構方法，包括數(shù)據(jù)集市架構、Inmon企業(yè)信息工廠架構、Kimball數(shù)據(jù)倉庫架構和混合型數(shù)據(jù)倉庫架構。1．數(shù)據(jù)集市架構數(shù)據(jù)集市是按主題域組織的數(shù)據(jù)集合，用于支持部門級的決策。有兩種類型的數(shù)據(jù)集市：獨立數(shù)據(jù)集市和從屬數(shù)據(jù)集市。獨立數(shù)據(jù)集市集中于部門所關心的單一主題域，數(shù)據(jù)以部門為基礎部署，無須考慮企業(yè)級別的信息共享與集成。例如，制造部門、人力資源部門和其他部門都各自有他們自己的數(shù)據(jù)集市。獨立數(shù)據(jù)集市從一個主題域或一個部門的多個事務系統(tǒng)獲取數(shù)據(jù)，用以支持特定部門的業(yè)務分析需要。一個獨立數(shù)據(jù)集市的設計既可以使用實體關系模型，也可以使用多維模型。數(shù)據(jù)分析或商業(yè)智能工具直接從數(shù)據(jù)集市查詢數(shù)據(jù)，并將查詢結果顯示給用戶。一個典型的獨立數(shù)據(jù)集市架構如圖1-2所示。因為一個部門的業(yè)務相對于整個企業(yè)要簡單，數(shù)據(jù)量也小得多，所以部門的獨立數(shù)據(jù)集市具有周期短、見效快的特點。如果從企業(yè)整體的視角來觀察這些數(shù)據(jù)集市，你會看到每個部門使用不同的技術，建立不同的ETL的過程，處理不同的事務系統(tǒng)，而在多個獨立的數(shù)據(jù)集市之間還會存在數(shù)據(jù)的交叉與重疊，甚至會有數(shù)據(jù)不一致的情況。從業(yè)務角度看，當部門的分析需求擴展，或者需要分析跨部門或跨主題域的數(shù)據(jù)時，獨立數(shù)據(jù)市場會顯得力不從心。而當數(shù)據(jù)存在歧義，比如同一個產(chǎn)品，在A部門和B部門的定義不同時，將無法在部門間進行信息比較。圖1-2獨立數(shù)據(jù)集市架構另外一種數(shù)據(jù)集市是從屬數(shù)據(jù)集市。如BillInmon所說，從屬數(shù)據(jù)集市的數(shù)據(jù)來源于數(shù)據(jù)倉庫。數(shù)據(jù)倉庫里的數(shù)據(jù)經(jīng)過整合、重構、匯總后傳遞給從屬數(shù)據(jù)集市。從屬數(shù)據(jù)集市的架構如圖1-3所示。圖1-3從屬數(shù)據(jù)集市架構建立從屬數(shù)據(jù)集市的好處主要有：性能：當數(shù)據(jù)倉庫的查詢性能出現(xiàn)問題，可以考慮建立幾個從屬數(shù)據(jù)集市，將查詢從數(shù)據(jù)倉庫移出到數(shù)據(jù)集市。安全：每個部門可以完全控制他們自己的數(shù)據(jù)。數(shù)據(jù)一致：因為每個數(shù)據(jù)集市的數(shù)據(jù)來源都是同一個數(shù)據(jù)倉庫，有效消除了數(shù)據(jù)不一致的情況。Inmon企業(yè)信息工廠架構Inmon企業(yè)信息工廠架構如圖1-4所示，我們來看圖中的組件是如何協(xié)同工作的。圖1-4Inmon企業(yè)信息工廠架構應用系統(tǒng)：這些應用是組織中的操作型系統(tǒng)，用來支撐業(yè)務。它們收集業(yè)務處理過程中產(chǎn)生的銷售、市場、材料、物流等數(shù)據(jù)，并將數(shù)據(jù)以多種形式進行存儲。操作型系統(tǒng)也叫源系統(tǒng)，為數(shù)據(jù)倉庫提供數(shù)據(jù)。ETL過程：ETL過程從操作型系統(tǒng)抽取數(shù)據(jù)，然后將數(shù)據(jù)轉換成一種標準形式，最終將轉換后的數(shù)據(jù)裝載到企業(yè)級數(shù)據(jù)倉庫中。ETL是周期性運行的批處理過程。企業(yè)級數(shù)據(jù)倉庫：是該架構中的核心組件。正如Inmon數(shù)據(jù)倉庫所定義的，企業(yè)級數(shù)據(jù)倉庫是一個細節(jié)數(shù)據(jù)的集成資源庫。其中的數(shù)據(jù)以最低粒度級別被捕獲，存儲在滿足三范式設計的關系數(shù)據(jù)庫中。部門級數(shù)據(jù)集市：是面向主題數(shù)據(jù)的部門級視圖，數(shù)據(jù)從企業(yè)級數(shù)據(jù)倉庫獲取。數(shù)據(jù)在進入部門數(shù)據(jù)集市時可能進行聚合。數(shù)據(jù)集市使用多維模型設計，用于數(shù)據(jù)分析。重要的一點是，所有的報表工具、BI工具或其他數(shù)據(jù)分析應用都從數(shù)據(jù)集市查詢數(shù)據(jù)，而不是直接查詢企業(yè)級數(shù)據(jù)倉庫。2．Kimball數(shù)據(jù)倉庫架構Kimball數(shù)據(jù)倉庫架構如圖1-5所示。圖1-5Kimball數(shù)據(jù)倉庫架構對比上一張圖可以看到，Kimball與Inmon兩種架構的主要區(qū)別在于核心數(shù)據(jù)倉庫的設計和建立。Kimball的數(shù)據(jù)倉庫包含高粒度的企業(yè)數(shù)據(jù)，使用多維模型設計，這也意味著數(shù)據(jù)倉庫由星型模式的維度表和事實表構成。分析系統(tǒng)或報表工具可以直接訪問多維數(shù)據(jù)倉庫里的數(shù)據(jù)。在此架構中的數(shù)據(jù)集市也與Inmon中的不同。這里的數(shù)據(jù)集市是一個邏輯概念，只是多維數(shù)據(jù)倉庫中的主題域劃分，并沒有自己的物理存儲，也可以說是虛擬的數(shù)據(jù)集市。3．混合型數(shù)據(jù)倉庫架構混合型數(shù)據(jù)倉庫架構如圖1-6所示。圖1-6混合型數(shù)據(jù)倉庫架構所謂的混合型結構，指的是在一個數(shù)據(jù)倉庫環(huán)境中，聯(lián)合使用Inmon和Kimball兩種架構。從架構圖可以看到，這種架構將Inmon方法中的數(shù)據(jù)集市部分替換成了一個多維數(shù)據(jù)倉庫，而數(shù)據(jù)集市則是多維數(shù)據(jù)倉庫上的邏輯視圖。使用這種架構的好處是，既可以利用規(guī)范化設計消除數(shù)據(jù)冗余，保證數(shù)據(jù)的粒度足夠細；又可以利用多維結構更靈活地在企業(yè)級實現(xiàn)報表和分析。1.3.3操作數(shù)據(jù)存儲操作數(shù)據(jù)存儲又稱為ODS，是OperationalDataStore的簡寫，其定義是這樣的：一個面向主題的、集成的、可變的、當前的細節(jié)數(shù)據(jù)集合，用于支持企業(yè)對于即時性的、操作性的、集成的全體信息的需求。對比1.1節(jié)中數(shù)據(jù)倉庫的定義不難看出，操作型數(shù)據(jù)存儲在某些方面具有類似于數(shù)據(jù)倉庫的特點，但在另一些方面又顯著不同于數(shù)據(jù)倉庫。像數(shù)據(jù)倉庫一樣，是面向主題的。像數(shù)據(jù)倉庫一樣，其數(shù)據(jù)是完全集成的。數(shù)據(jù)是當前的，這與數(shù)據(jù)倉庫存儲歷史數(shù)據(jù)的性質明顯不同。ODS具有最少的歷史數(shù)據(jù)（一般是30天到60天），而盡可能接近實時地展示數(shù)據(jù)的狀態(tài)。數(shù)據(jù)是可更新的，這是與靜態(tài)數(shù)據(jù)倉庫又一個很大的區(qū)別。ODS就如同一個事務處理系統(tǒng)，當新的數(shù)據(jù)流進ODS時，受其影響的字段被新信息覆蓋。數(shù)據(jù)幾乎完全是細節(jié)數(shù)據(jù)，僅具有少量的動態(tài)聚集或匯總數(shù)據(jù)。通常將ODS設計成包含事務級的數(shù)據(jù)，即包含該主題域中最低粒度級別的數(shù)據(jù)。在數(shù)據(jù)倉庫中，幾乎沒有針對其本身的報表，報表均放到數(shù)據(jù)集市中完成；與此不同，在ODS中，業(yè)務用戶頻繁地直接訪問ODS。在一個數(shù)據(jù)倉庫環(huán)境中，ODS具有如下幾個作用：充當業(yè)務系統(tǒng)與數(shù)據(jù)倉庫之間的過渡區(qū)。數(shù)據(jù)倉庫的數(shù)據(jù)來源復雜，可能分布在不同的數(shù)據(jù)庫，不同的地理位置，不同的應用系統(tǒng)之中，而且由于數(shù)據(jù)形式的多樣性，數(shù)據(jù)轉換的規(guī)則往往極為復雜。如果直接從業(yè)務系統(tǒng)抽取數(shù)據(jù)并做轉換，不可避免地會對業(yè)務系統(tǒng)造成影響。而ODS中存放的數(shù)據(jù)從數(shù)據(jù)結構、數(shù)據(jù)粒度、數(shù)據(jù)之間的邏輯關系上都與業(yè)務系統(tǒng)基本保持一致，因此抽取過程只需簡單的數(shù)據(jù)復制而基本不再需要做數(shù)據(jù)轉換，大大降低了復雜性，同時最小化對業(yè)務系統(tǒng)的侵入。轉移部分業(yè)務系統(tǒng)細節(jié)查詢的功能。某些原來由業(yè)務系統(tǒng)產(chǎn)生的報表、細節(jié)數(shù)據(jù)的查詢能夠在ODS中進行，從而降低業(yè)務系統(tǒng)的查詢壓力。完成數(shù)據(jù)倉庫中不能完成的一些功能。用戶有時會要求數(shù)據(jù)倉庫查詢最低粒度級別的細節(jié)數(shù)據(jù)，而數(shù)據(jù)倉庫中存儲的數(shù)據(jù)一般都是聚合或匯總過的數(shù)據(jù)，并不存儲每筆交易產(chǎn)生的細節(jié)數(shù)據(jù)。這時就需要把細節(jié)數(shù)據(jù)查詢的功能轉移到ODS來完成，而且ODS的數(shù)據(jù)模型是按照面向主題的方式組織的，可以方便地支持多維分析。即數(shù)據(jù)倉庫從宏觀角度滿足企業(yè)的決策支持要求，而ODS層則從微觀角度反映細節(jié)交易數(shù)據(jù)或者低粒度的數(shù)據(jù)查詢要求。1.4抽取-轉換-裝載前面已經(jīng)多次提到了ETL一詞，它是Extract、Transform、Load三個英文單詞首字母的簡寫，中文意為抽取、轉換、裝載。ETL是建立數(shù)據(jù)倉庫最重要的處理過程，也是最體現(xiàn)工作量的環(huán)節(jié)，一般會占到整個數(shù)據(jù)倉庫項目工作量的一半以上。抽?。簭牟僮餍蛿?shù)據(jù)源獲取數(shù)據(jù)。轉換：轉換數(shù)據(jù)，使之轉變?yōu)檫m用于查詢和分析的形式和結構。裝載：將轉換后的數(shù)據(jù)導入到最終的目標數(shù)據(jù)倉庫。建立一個數(shù)據(jù)倉庫，就是要把來自于多個異構的源系統(tǒng)的數(shù)據(jù)集成在一起，放置于一個集中的位置用于數(shù)據(jù)分析。如果一開始這些源系統(tǒng)數(shù)據(jù)就是兼容的當然最好，但情況往往不是這樣。ETL系統(tǒng)的工作就是要把異構的數(shù)據(jù)轉換成同構的。如果沒有ETL，不可能對異構的數(shù)據(jù)進行程序化的分析。1.4.1數(shù)據(jù)抽取抽取操作從源系統(tǒng)獲取數(shù)據(jù)給后續(xù)的數(shù)據(jù)倉庫環(huán)境使用。這是ETL處理的第一步，也是最重要的一步。數(shù)據(jù)被成功抽取后，才可以進行轉換并裝載到數(shù)據(jù)倉庫中。能否正確地獲取數(shù)據(jù)直接關系到后面步驟的成敗。數(shù)據(jù)倉庫典型的源系統(tǒng)是事務處理應用，例如，一個銷售分析數(shù)據(jù)倉庫的源系統(tǒng)之一，可能是一個訂單錄入系統(tǒng)，其中包含當前銷售訂單相關操作的全部記錄。設計和建立數(shù)據(jù)抽取過程，在ETL處理乃至整個數(shù)據(jù)倉庫處理過程中，一般是較為耗時的任務。源系統(tǒng)很可能非常復雜并且缺少相應的文檔，因此只是決定需要抽取哪些數(shù)據(jù)可能就已經(jīng)非常困難了。通常數(shù)據(jù)都不是只抽取一次，而是需要以一定的時間間隔反復抽取，通過這樣的方式把數(shù)據(jù)的所有變化提供給數(shù)據(jù)倉庫，并保持數(shù)據(jù)的及時性。除此之外，源系統(tǒng)一般不允許外部系統(tǒng)對它進行修改，也不允許外部系統(tǒng)對它的性能和可用性產(chǎn)生影響，數(shù)據(jù)倉庫的抽取過程要能適應這樣的需求。如果已經(jīng)明確了需要抽取的數(shù)據(jù)，下一步就該考慮從源系統(tǒng)抽取數(shù)據(jù)的方法了。對抽取方法的選擇高度依賴于源系統(tǒng)和目標數(shù)據(jù)倉庫環(huán)境的業(yè)務需要。一般情況下，不可能因為需要提升數(shù)據(jù)抽取的性能，而在源系統(tǒng)中添加額外的邏輯，也不能增加這些源系統(tǒng)的工作負載。有時，用戶甚至都不允許增加任何“開箱即用”的外部應用系統(tǒng)，這叫做對源系統(tǒng)具有侵入性。下面分別從邏輯和物理兩方面介紹數(shù)據(jù)抽取方法。1．邏輯抽取有兩種邏輯抽取類型：全量抽取和增量抽取。（1）全量抽取源系統(tǒng)的數(shù)據(jù)全部被抽取。因為這種抽取類型影響源系統(tǒng)上當前所有有效的數(shù)據(jù)，所以不需要跟蹤自上次成功抽取以來的數(shù)據(jù)變化。源系統(tǒng)只需要原樣提供現(xiàn)有的數(shù)據(jù)而不需要附加的邏輯信息（比如時間戳等）。一個全表導出的數(shù)據(jù)文件或者一個查詢源表所有數(shù)據(jù)的SQL語句，都是全量抽取的例子。（2）增量抽取只抽取某個事件發(fā)生的特定時間點之后的數(shù)據(jù)。通過該事件發(fā)生的時間順序能夠反映數(shù)據(jù)的歷史變化，它可能是最后一次成功抽取，也可能是一個復雜的業(yè)務事件，如最后一次財務結算等。必須能夠標識出特定時間點之后所有的數(shù)據(jù)變化。這些發(fā)生變化的數(shù)據(jù)可以由源系統(tǒng)自身來提供，例如能夠反映數(shù)據(jù)最后發(fā)生變化的時間戳列，或者是一個原始事務處理之外的，只用于跟蹤數(shù)據(jù)變化的變更日志表。大多數(shù)情況下，使用后者意味著需要在源系統(tǒng)上增加抽取邏輯。在許多數(shù)據(jù)倉庫中，抽取過程不含任何變化數(shù)據(jù)捕獲技術。取而代之的是，把源系統(tǒng)中的整個表抽取到數(shù)據(jù)倉庫過渡區(qū)，然后用這個表的數(shù)據(jù)和上次從源系統(tǒng)抽取得到的表數(shù)據(jù)作比對，從而找出發(fā)生變化的數(shù)據(jù)。雖然這種方法不會對源系統(tǒng)造成很大的影響，但顯然需要考慮給數(shù)據(jù)倉庫處理增加的負擔，尤其是當數(shù)據(jù)量很大的時候。2．物理抽取依賴于選擇的邏輯抽取方法和能夠對源系統(tǒng)所做的操作和所受的限制，存在兩種物理數(shù)據(jù)抽取機制：直接從源系統(tǒng)聯(lián)機抽取或者間接從一個脫機結構抽取數(shù)據(jù)。這個脫機結構有可能已經(jīng)存在，也可能需要由抽取程序生成。（1）聯(lián)機抽取數(shù)據(jù)直接從源系統(tǒng)抽取。抽取進程或者直連源系統(tǒng)數(shù)據(jù)庫，訪問它們的數(shù)據(jù)表，或者連接到一個存儲快照日志或變更記錄表的中間層系統(tǒng)。注意這個中間層系統(tǒng)并不需要必須和源系統(tǒng)物理分離。（2）脫機抽取數(shù)據(jù)不從源系統(tǒng)直接抽取，而是從一個源系統(tǒng)以外的過渡區(qū)抽取。過渡區(qū)可能已經(jīng)存在（例如數(shù)據(jù)庫備份文件、關系數(shù)據(jù)庫系統(tǒng)的重做日志、歸檔日志等），或者抽取程序自己建立。應該考慮以下的存儲結構：數(shù)據(jù)庫備份文件。一般需要數(shù)據(jù)還原操作才能使用。備用數(shù)據(jù)庫。如Oracle的DataGuard和MySQL的數(shù)據(jù)復制等技術。平面文件。數(shù)據(jù)定義成普通格式，關于源對象的附加信息（列名、數(shù)據(jù)類型等）需要另外處理。導出文件。關系數(shù)據(jù)庫大都自帶數(shù)據(jù)導出功能，如Oracle的exp/expdp程序和MySQL的mysqldump程序，都可以用于生成導出數(shù)據(jù)文件。重做日志和歸檔日志。每種數(shù)據(jù)庫系統(tǒng)都有自己的日志格式和解析工具。3．變化數(shù)據(jù)捕獲抽取處理需要重點考慮增量抽取，也被稱為變化數(shù)據(jù)捕獲，簡稱CDC。假設一個數(shù)據(jù)倉庫系統(tǒng)，在每天夜里的業(yè)務低峰時間從操作型源系統(tǒng)抽取數(shù)據(jù)，那么增量抽取只需要過去24小時內發(fā)生變化的數(shù)據(jù)。變化數(shù)據(jù)捕獲也是建立準實時數(shù)據(jù)倉庫的關鍵技術。當你能夠識別并獲得最近發(fā)生變化的數(shù)據(jù)時，抽取及其后面的轉換、裝載操作顯然都會變得更高效，因為要處理的數(shù)據(jù)量會小很多。遺憾的是，很多源系統(tǒng)很難識別出最近變化的數(shù)據(jù)，或者必須侵入源系統(tǒng)才能做到。變化數(shù)據(jù)捕獲是數(shù)據(jù)抽取中典型的技術挑戰(zhàn)。常用的變化數(shù)據(jù)捕獲方法有時間戳、快照、觸發(fā)器和日志四種。相信熟悉數(shù)據(jù)庫的讀者對這些方法都不會陌生。時間戳方法需要源系統(tǒng)有相應的數(shù)據(jù)列表示最后的數(shù)據(jù)變化?？煺辗椒梢允褂脭?shù)據(jù)庫系統(tǒng)自帶的機制實現(xiàn)，如Oracle的物化視圖技術，也可以自己實現(xiàn)相關邏輯，但會比較復雜。觸發(fā)器是關系數(shù)據(jù)庫系統(tǒng)具有的特性，源表上建立的觸發(fā)器會在對該表執(zhí)行insert、update、delete等語句時被觸發(fā)，觸發(fā)器中的邏輯用于捕獲數(shù)據(jù)的變化。日志可以使用應用日志或系統(tǒng)日志，這種方式對源系統(tǒng)不具有侵入性，但需要額外的日志解析工作。關于這4種方案的特點，將會在本書第7章“數(shù)據(jù)抽取”具體說明。1.4.2數(shù)據(jù)轉換數(shù)據(jù)從操作型源系統(tǒng)獲取后，需要進行多種轉換操作。如統(tǒng)一數(shù)據(jù)類型、處理拼寫錯誤、消除數(shù)據(jù)歧義、解析為標準格式等。數(shù)據(jù)轉換通常是最復雜的部分，也是ETL開發(fā)中用時最長的一步。數(shù)據(jù)轉換的范圍極廣，從單純的數(shù)據(jù)類型轉化到極為復雜的數(shù)據(jù)清洗技術。在數(shù)據(jù)轉換階段，為了能夠最終將數(shù)據(jù)裝載到數(shù)據(jù)倉庫中，需要在已經(jīng)抽取來的數(shù)據(jù)上應用一系列的規(guī)則和函數(shù)。有些數(shù)據(jù)可能不需要轉換就能直接導入到數(shù)據(jù)倉庫。數(shù)據(jù)轉換一個最重要的功能是清洗數(shù)據(jù)，目的是只有“合規(guī)”的數(shù)據(jù)才能進入目標數(shù)據(jù)倉庫。這步操作在不同系統(tǒng)間交互和通信時尤其必要，例如，一個系統(tǒng)的字符集在另一個系統(tǒng)中可能是無效的。另一方面，由于某些業(yè)務和技術的需要，也需要進行多種數(shù)據(jù)轉換，例如下面的情況：只裝載特定的數(shù)據(jù)列。例如，某列為空的數(shù)據(jù)不裝載。統(tǒng)一數(shù)據(jù)編碼。例如，性別字段，有些系統(tǒng)使用的是1和0，有些是‘M’和‘F’，有些是‘男’和‘女’，統(tǒng)一成‘M’和‘F’。自由值編碼。例如，將‘Male’改成‘M’。預計算。例如，產(chǎn)品單價*購買數(shù)量＝金額。基于某些規(guī)則重新排序以提高查詢性能。合并多個數(shù)據(jù)源的數(shù)據(jù)并去重。預聚合。例如，匯總銷售數(shù)據(jù)。行列轉置。將一列轉為多列。例如，某列存儲的數(shù)據(jù)是以逗號作為分隔符的字符串，將其分割成多列的單個值。合并重復列。預連接。例如，查詢多個關聯(lián)表的數(shù)據(jù)。數(shù)據(jù)驗證。針對驗證的結果采取不同的處理，通過驗證的數(shù)據(jù)交給裝載步驟，驗證失敗的數(shù)據(jù)或直接丟棄，或記錄下來做進一步檢查。1.4.3數(shù)據(jù)裝載ETL的最后步驟是把轉換后的數(shù)據(jù)裝載進目標數(shù)據(jù)倉庫。這步操作需要重點考慮兩個問題，一是數(shù)據(jù)裝載的效率問題，二是一旦裝載過程中途失敗了，如何再次重復執(zhí)行裝載過程。即使經(jīng)過了轉換、過濾和清洗，去掉了部分噪聲數(shù)據(jù)，但需要裝載的數(shù)據(jù)量還是很大的。執(zhí)行一次數(shù)據(jù)裝載可能需要幾個小時的時間，同時需要占用大量的系統(tǒng)資源。要提高裝載的效率，加快裝載速度，可以從以下幾方面入手。首先保證足夠的系統(tǒng)資源。數(shù)據(jù)倉庫存儲的都是海量數(shù)據(jù)，所以要配置高性能的服務器，并且要獨占資源，不要與別的系統(tǒng)共用。在進行數(shù)據(jù)裝載時，要禁用數(shù)據(jù)庫約束（唯一性、非空性，檢查約束等）和索引，當裝載過程完全結束后，再啟用這些約束，重建索引，這種方法會很大的提高裝載速度。在數(shù)據(jù)倉庫環(huán)境中，一般不使用數(shù)據(jù)庫來保證數(shù)據(jù)的參考完整性，即不使用數(shù)據(jù)庫的外鍵約束，它應該由ETL工具或程序來維護。數(shù)據(jù)裝載過程可能由于多種原因而失敗，比如裝載過程中某些源表和目標表的結構不一致而導致失敗，而這時已經(jīng)有部分表裝載成功了。在數(shù)據(jù)量很大的情況下，如何能在重新執(zhí)行裝載過程時只裝載失敗的部分是一個不小的挑戰(zhàn)。對于這種情況，實現(xiàn)可重復裝載的關鍵是要記錄下失敗點，并在裝載程序中處理相關的邏輯。還有一種情況，就是裝載成功后，數(shù)據(jù)又發(fā)生了改變（比如有些滯后的數(shù)據(jù)在ETL執(zhí)行完才進入系統(tǒng)，就會帶來數(shù)據(jù)的更新或新增），這時需要重新再執(zhí)行一遍裝載過程，已經(jīng)正確裝載的數(shù)據(jù)可以被覆蓋，但相同數(shù)據(jù)不能重復新增。簡單的實現(xiàn)方式是先刪除再插入，或者用replaceinto、mergeinto等類似功能的操作。裝載到數(shù)據(jù)倉庫里的數(shù)據(jù)，經(jīng)過匯總、聚合等處理后交付給多維立方體或數(shù)據(jù)可視化、儀表盤等報表工具、BI工具做進一步的數(shù)據(jù)分析。1.4.4開發(fā)ETL系統(tǒng)的方法ETL系統(tǒng)一般都會從多個應用系統(tǒng)整合數(shù)據(jù)，典型的情況是這些應用系統(tǒng)運行在不同的軟硬件平臺上，由不同的廠商所支持，各個系統(tǒng)的開發(fā)團隊也是彼此獨立的，隨之而來的數(shù)據(jù)多樣性增加了ETL系統(tǒng)的復雜性。開發(fā)一個ETL系統(tǒng)，常用的方式是使用數(shù)據(jù)庫標準的SQL及其程序化語言，如Oracle的PL/SQL和MySQL的存儲過程、用戶自定義函數(shù)（UDF）等。還可以使用Kettle這樣的ETL工具，這些工具都提供多種數(shù)據(jù)庫連接器和多種文件格式的處理能力，并且對ETL處理進行了優(yōu)化。使用工具的最大好處是減少編程工作量，提高工作效率。如果遇到特殊需求或特別復雜的情況，可能還是需要使用Shell、Java、Python等編程語言開發(fā)自己的應用程序。ETL過程要面對大量的數(shù)據(jù)，因此需要較長的處理時間。為了提高ETL的效率，通常這三步操作會并行執(zhí)行。當數(shù)據(jù)被抽取時，轉換進程同時處理已經(jīng)收到的數(shù)據(jù)。一旦某些數(shù)據(jù)被轉換過程處理完，裝載進程就會將這些數(shù)據(jù)導入目標數(shù)據(jù)倉庫，而不會等到前一步工作執(zhí)行完才開始。1.4.5常見ETL工具傳統(tǒng)大的軟件廠商一般都提供ETL工具軟件，如Oracle的OWB和ODI、微軟的SQLServerIntegrationServices、SAP的DataIntegrator、IBM的InfoSphereDataStage、Informatica等。這里簡單介紹另外一種開源的ETL工具——Kettle。Kettle是Pentaho公司的數(shù)據(jù)整合產(chǎn)品，它可能是現(xiàn)在世界上最流行的開源ETL工具，經(jīng)常被用于數(shù)據(jù)倉庫環(huán)境。Kettle的使用場景包括：在應用或數(shù)據(jù)庫間遷移數(shù)據(jù)、把數(shù)據(jù)庫中的數(shù)據(jù)導出成平面文件、向數(shù)據(jù)庫大批量導入數(shù)據(jù)、數(shù)據(jù)轉換和清洗、應用整合等。Kettle里主要有“轉換”和“作業(yè)”兩個功能模塊。轉換是ETL解決方案中最主要的部分，它處理ETL各階段各種對數(shù)據(jù)的操作。轉換有輸入、輸出、檢驗、映射、加密、腳本等很多分類，每個分類中包括多個步驟，如輸入轉換中就有表輸入、CSV文件輸入、文本文件輸入等很多步驟。轉換里的步驟通過跳（hop）來連接，跳定義了一個單向通道，允許數(shù)據(jù)從一個步驟流向另外一個步驟。在Kettle里，數(shù)據(jù)的單位是行，數(shù)據(jù)流就是數(shù)據(jù)行從一個步驟到另一個步驟的移動。轉換是以并行方式執(zhí)行的，而作業(yè)則是以串行方式處理的，驗證數(shù)據(jù)表是否存在這樣的操作就需要作業(yè)來完成。一個作業(yè)包括一個或多個作業(yè)項，作業(yè)項是以某種順序來執(zhí)行的，作業(yè)執(zhí)行順序由作業(yè)項之間的跳（hop）和每個作業(yè)項的執(zhí)行結果決定。和轉換一樣，作業(yè)也有很多分類，每個分類中包括多個作業(yè)項，如轉換就是一個通用分類里的作業(yè)項。作業(yè)項也可以是一個作業(yè)，此時稱該作業(yè)為子作業(yè)。Kettle非常容易使用，其所有的功能都通過用戶界面完成，不需要任何編碼工作。你只需要告訴它做什么，而不用指示它怎么做，這大大提高了ETL過程的開發(fā)效率。本書第5章將會詳細說明怎樣使用Kettle操作Hadoop數(shù)據(jù)。1.5數(shù)據(jù)倉庫需求本小節(jié)從基本需求和數(shù)據(jù)需求兩方面介紹對數(shù)據(jù)倉庫系統(tǒng)的整體要求。1.5.1基本需求數(shù)據(jù)倉庫的目的就是能夠讓用戶方便地訪問大量數(shù)據(jù)，允許用戶查詢和分析其中的業(yè)務信息。這就要求數(shù)據(jù)倉庫必須是安全的、可訪問的和自動化的。1．安全性數(shù)據(jù)倉庫中含有機密和敏感的數(shù)據(jù)。為了能夠使用這些數(shù)據(jù)，必須有適當?shù)氖跈鄼C制。這意味著只有被授權的用戶才能訪問數(shù)據(jù)，這些用戶在享有特權的同時，也有責任保證數(shù)據(jù)的安全。增加安全特性會影響到數(shù)據(jù)倉庫的性能，因此必須提早考慮數(shù)據(jù)倉庫的安全需求。當數(shù)據(jù)倉庫已經(jīng)建立完成并開始使用后，此時再應用安全特性會比較困難。在數(shù)據(jù)倉庫的設計階段，我們就應該進行如下的安全性考慮：數(shù)據(jù)倉庫中的數(shù)據(jù)對于最終用戶是只讀的，任何人都不能修改其中的數(shù)據(jù)，這是由數(shù)據(jù)的非易失性所決定的。劃分數(shù)據(jù)的安全等級，如公開的、機密、秘密、絕密等。制定訪問控制方案，決定哪些用戶可以訪問哪些數(shù)據(jù)。設計授予、回收、變更用戶訪問權限的方法。添加對數(shù)據(jù)訪問的審計功能。2．可訪問性能夠快速準確地分析所需要的數(shù)據(jù)是輔助決策支持的關鍵。有了數(shù)據(jù)的支持，業(yè)務就可以根據(jù)市場和客戶的情況做出及時地調整。這就要求用戶能夠有效地查找、理解和使用數(shù)據(jù)。數(shù)據(jù)應該是隨時可訪問的。數(shù)據(jù)的可訪問性是一個IT技術的通用特性。這里數(shù)據(jù)可訪問性指的是用戶訪問和檢索數(shù)據(jù)的能力。數(shù)據(jù)倉庫的最終用戶通常是業(yè)務人員、管理人員或者數(shù)據(jù)分析師。他們對組織內的相關業(yè)務非常熟悉，對數(shù)據(jù)的理解也很透徹，但是他們大都不是IT技術專家。這就要求我們在設計數(shù)據(jù)倉庫的時候，將用戶接口設計得盡量友好和簡單，使得沒有技術背景的用戶同樣可以輕易查詢到他們需要的數(shù)據(jù)。3．自動化這里的自動化有狹義和廣義兩個層面的理解。狹義的自動化指的是數(shù)據(jù)倉庫相關作業(yè)的自動執(zhí)行。比如ETL過程、報表生成、數(shù)據(jù)傳輸?shù)忍幚?，都可以周期性定時自動完成。廣義的數(shù)據(jù)倉庫自動化指的是在保證數(shù)據(jù)質量和數(shù)據(jù)一致性的前提下，加速數(shù)據(jù)倉庫系統(tǒng)開發(fā)周期的過程。整個數(shù)據(jù)倉庫生命周期的自動化，從對源系統(tǒng)分析到ETL，再到數(shù)據(jù)倉庫的建立、測試和文檔化，可以幫助加快產(chǎn)品化進程，降低開發(fā)和管理成本，提高數(shù)據(jù)質量。1.5.2數(shù)據(jù)需求通過數(shù)據(jù)倉庫，既可以周期性地回答已知的問題（如報表等），也可以進行即席查詢（ad-hocqueries）。報表最基本的需求就是對預定義好的一系列查詢條件、查詢內容，排序條件等進行組合，查詢數(shù)據(jù)，把結果用表格或圖形的形式展現(xiàn)出來。而所謂的即席查詢不是預定義好的，而是在執(zhí)行時才確定的。換句話說，即席查詢是指那些用戶在使用系統(tǒng)時，根據(jù)自己當時的需求定義的查詢。數(shù)據(jù)庫管理員使用命令行或客戶端軟件，連接數(shù)據(jù)庫系統(tǒng)執(zhí)行各種各樣的查詢語句，是最為常見的一種即席查詢方式。而理想的數(shù)據(jù)倉庫系統(tǒng)，允許業(yè)務或分析人員也可以通過系統(tǒng)執(zhí)行這樣的自定義查詢。為了滿足需求，數(shù)據(jù)倉庫中的數(shù)據(jù)需要確保準確性、時效性和歷史可追溯性。1．準確性想要數(shù)據(jù)倉庫實施成功，業(yè)務用戶必須信任其中的數(shù)據(jù)。這就意味著他們應該能知道數(shù)據(jù)從哪來，何時抽取，怎么轉換的。更重要的是，他們需要訪問原始數(shù)據(jù)來確定如何解決數(shù)據(jù)差異問題。實際上ETL過程應該總是在數(shù)據(jù)倉庫的某個地方（如ODS）保留一份原始數(shù)據(jù)的復制。2．時效性用戶的時效性要求差異很大。有些用戶需要數(shù)據(jù)精確到毫秒級，而有些用戶只需要幾分鐘、幾小時甚至幾天前的數(shù)據(jù)就可以了。數(shù)據(jù)倉庫是分析型系統(tǒng)，用于決策支持，所以實踐中一般不需要很強的實時性，以一天作為時間粒度是比較常見的。3．歷史可追溯性數(shù)據(jù)倉庫更多的價值體現(xiàn)在它能夠輔助隨時間變化的趨勢分析，并幫助理解業(yè)務事件（如特殊節(jié)日促銷等）與經(jīng)營績效之間的關系。1.6小結（1）數(shù)據(jù)倉庫是一個面向主題的、集成的、隨時間變化的、非易失的數(shù)據(jù)集合，用于支持管理者的決策過程。（2）數(shù)據(jù)倉庫中的粒度是指數(shù)據(jù)的細節(jié)或匯總程度，細節(jié)程度越高，粒度級別越低。（3）數(shù)據(jù)倉庫的數(shù)據(jù)來自各個業(yè)務應用系統(tǒng)。（4）很多因素導致直接訪問業(yè)務系統(tǒng)無法進行全局數(shù)據(jù)分析的工作，這也是需要一個數(shù)據(jù)倉庫的原因所在。（5）操作型系統(tǒng)是一類專門用于管理面向事務的應用信息系統(tǒng)，而分析型系統(tǒng)是一種快速回答多維分析查詢的實現(xiàn)方式，兩者在很多方面存在差異。（6）構成數(shù)據(jù)倉庫系統(tǒng)的主要組成部分有數(shù)據(jù)源、ODS、中心數(shù)據(jù)倉庫、分析查詢引擎、ETL、元數(shù)據(jù)管理和自動化調度。（7）主要的數(shù)據(jù)倉庫架構有獨立數(shù)據(jù)集市、從屬數(shù)據(jù)集市、Inmon企業(yè)信息工廠、Kimball多維數(shù)據(jù)倉庫、混合型數(shù)據(jù)倉庫。（8）ETL是建立數(shù)據(jù)倉庫最重要的處理過程，也是最體現(xiàn)工作量的環(huán)節(jié)。（9）Kettle是常用的開源ETL工具。（10）數(shù)據(jù)倉庫的基本需求是安全性、可訪問性、自動化，對數(shù)據(jù)的要求是準確性、時效性、歷史可追溯性。第2章

?數(shù)據(jù)倉庫設計基礎?本章首先介紹關系數(shù)據(jù)模型、多維數(shù)據(jù)模型和DataVault模型這三種常見的數(shù)據(jù)倉庫模型和與之相關的設計方法，然后討論數(shù)據(jù)集市的設計問題，最后說明一個數(shù)據(jù)倉庫項目的實施步驟。規(guī)劃實施過程是整個數(shù)據(jù)倉庫設計的重要組成部分。關系模型、多維模型已經(jīng)有很長的歷史，而DataVault模型相對比較新。它們都是流行的數(shù)據(jù)倉庫建模方式，但又有各自的特點和適用場景。讀者在了解了本章的內容后，可以根據(jù)實際需求選擇適合的方法構建自己的數(shù)據(jù)倉庫。2.1關系數(shù)據(jù)模型關系模型是由E.F.Codd在1970年提出的一種通用數(shù)據(jù)模型。由于關系數(shù)據(jù)模型簡單明了，并且有堅實的數(shù)學理論基礎，所以一經(jīng)推出就受到了業(yè)界的高度重視。關系模型被廣泛應用于數(shù)據(jù)處理和數(shù)據(jù)存儲，尤其是在數(shù)據(jù)庫領域，現(xiàn)在主流的數(shù)據(jù)庫管理系統(tǒng)幾乎都是以關系數(shù)據(jù)模型為基礎實現(xiàn)的。2.1.1關系數(shù)據(jù)模型中的結構關系數(shù)據(jù)模型基于關系這一數(shù)學概念。在本小節(jié)中，解釋關系數(shù)據(jù)模型中的術語和相關概念。為了便于說明，我們使用一個分公司-員工關系的例子。假設有一個大型公司在全國都有分公司，每個員工屬于一個分公司，一個分公司有一個經(jīng)理，分公司經(jīng)理也是公司員工。分公司-員工關系如圖2-1所示。圖2-1分公司-員工關系1．關系由行和列構成的二維結構，對應關系數(shù)據(jù)庫中的表，如示例中的分公司表和員工表。注意，這種認識只是我們從邏輯上看待關系模型的方式，并不應用于表在磁盤上的物理結構。表的物理存儲結構可以是堆文件、索引文件或哈希文件。堆文件是一個無序的數(shù)據(jù)集合，索引文件中表數(shù)據(jù)的物理存儲順序和邏輯順序保持一致，哈希文件也稱為直接存取文件，是通過一個預先定義好的哈希函數(shù)確定數(shù)據(jù)的物理存儲位置。2．屬性由屬性名稱和類型名稱構成的順序對，對應關系數(shù)據(jù)庫中表的列，如地址（VariableCharacters）是公司表的一個屬性。屬性值是屬性的一個特定的有效值，可以是簡單的標量值，也可以是復合數(shù)據(jù)類型值。在關系數(shù)據(jù)模型中，我們把關系描述為表，表中的行對應不同的記錄，表中的列對應不同的屬性。屬性可以以任何順序出現(xiàn)，而關系保持不變，也就是說，在關系理論中，表中的列是沒有順序的。3．屬性域屬性的取值范圍。每一個屬性都有一個預定義的值的范圍。屬性域是關系模型的一個重要特征，關系中的每個屬性都與一個域相關。各個屬性的域可能不同，也可能相同。域描述了屬性所有可能的值。域的概念是很重要的，因為它允許我們定義屬性可以具有的值的意義。系統(tǒng)可因此獲得更多的信息，并且可以拒絕不合理的操作。在我們的例子中，分公司編號和員工編號都是字符串，但顯然具有不同的含義，換句話說，它們的屬性域是不同的。表2-1列出了分公司-員工關系的一些屬性域。表2-1分公司-員工關系的一些屬性域4．元組關系中的一條記錄，對應關系數(shù)據(jù)庫中的一個表行。元組可以以任何順序出現(xiàn)，而關系保持不變，也就是說，在關系理論中，表中的行是沒有順序的。5．關系數(shù)據(jù)庫一系列規(guī)范化的表的集合。這里的規(guī)范化可以理解為表結構的正確性。本節(jié)后面會詳細討論規(guī)范化問題。以上介紹了關系數(shù)據(jù)模型的兩組術語：“關系、屬性、元組”和“表、列、行”。在這里它們的含義是相同的，只不過前者是關系數(shù)據(jù)模型的正式術語，而后者是常用的數(shù)據(jù)庫術語。其他可能會遇到的類似術語還有實體（表）、記錄（行）、字段（列）等。6．關系表的屬性關系表有如下屬性：每個表都有唯一的名稱。一個表中每個列有不同的名字。一個列的值來自于相同的屬性域。列是無序的。行是無序的。7．關系數(shù)據(jù)模型中的鍵（1）超鍵一個列或者列集，唯一標識表中的一條記錄。超鍵可能包含用于唯一標識記錄所不必要的額外的列，我們通常只對僅包含能夠唯一標識記錄的最小數(shù)量的列感興趣。（2）候選鍵僅包含唯一標識記錄所必需的最小數(shù)量列的超鍵。表的候選鍵有三個屬性：唯一性：在每條記錄中，候選鍵的值唯一標識該記錄。最小性：具有唯一性屬性的超鍵的最小子集。非空性：候選鍵的值不允許為空。在我們的例子中，分公司編號是候選鍵，如果每個分公司的郵編都不同，那么郵編也可以作為分公司表的候選鍵。一個表中允許有多個候選鍵。（3）主鍵唯一標識表中記錄的候選鍵。主鍵是唯一、非空的。沒有被選做主鍵的候選鍵稱為備用鍵。對于例子中的分公司表，分公司編號是主鍵，郵編就是備用鍵，而員工表的主鍵是員工編號。主鍵的選擇在關系數(shù)據(jù)模型中非常重要，很多性能問題都是由于主鍵選擇不當引起的。在選擇主鍵時，我們可以參考以下原則：主鍵要盡可能地小。主鍵值不應該被改變。主鍵會被其他表所引用。如果改變了主鍵的值，所有引用該主鍵的值都需要修改，否則引用就是無效的。主鍵通常使用數(shù)字類型。數(shù)字類型的主鍵要比其他數(shù)據(jù)類型效率更高。主鍵應該是沒有業(yè)務含義的，它不應包含實際的業(yè)務信息。無意義的數(shù)字列不需要修改，因此是主鍵的理想選擇。大部分關系型數(shù)據(jù)庫支持的自增屬性或序列對象更適合當作主鍵。雖然主鍵允許由多列組成，但應該使用盡可能少的列，最好是單列。（4）外鍵一個表中的一個列或多個列的集合，這些列匹配某些其他（也可以是同一個）表中的候選鍵。注意外鍵所引用的不一定是主鍵，但一定是候選鍵。當一列出現(xiàn)在兩張表中的時候，它通常代表兩張表記錄之間的關系。如例子中分公司表的分公司編號和員工表的所屬分公司。它們的名字雖然不同，但卻是同一含義。分公司表的分公司編號是主鍵，在員工表里所屬分公司是外鍵。同樣，因為公司經(jīng)理也是公司員工，所以它是引用員工表的外鍵。主鍵所在的表被稱為父表，外鍵所在的表被稱為子表。2.1.2關系完整性上一小節(jié)討論了關系數(shù)據(jù)模型的結構部分，本小節(jié)討論關系完整性規(guī)則。關系數(shù)據(jù)模型有兩個重要的完整性規(guī)則：實體完整性和參照完整性。在定義這些術語之前，先要理解空值的概念。1．空值（NULL）表示一個列的值目前還不知道或者對于當前記錄來說不可用?？罩悼梢砸馕吨粗?，也可以意味著某個記錄沒有值，或者只是意味著該值還沒有提供?？罩凳翘幚聿煌暾麛?shù)據(jù)或異常數(shù)據(jù)的一種方式?？罩蹬c數(shù)字零或者空字符串不同，零和空字符串是值，但空值代表沒有值。因此，空值應該與其他值區(qū)別對待。空值具有特殊性，當它參與邏輯運算時，結果取決于真值表。每種數(shù)據(jù)庫系統(tǒng)對空值參與運算的規(guī)則定義也不盡相同。表2-2到表2-4分別是Oracle的非、與、或邏輯運算真值表。表2-2Oracle邏輯非運算表2-3Oracle邏輯與運算表2-4Oracle邏輯或運算在我們的例子中，如果一個分公司的經(jīng)理離職了，新的經(jīng)理還沒有上任，此時公司經(jīng)理列對應的值就是空值。2．關系完整性規(guī)則有了空值的定義，就可以定義兩種關系完整性規(guī)則了。（1）實體完整性在一個基本表中，主鍵列的取值