1.3　數據倉庫構建方法論

目前，關于數據倉庫的構建，主要有以下兩種方法論：

（1）Inmon提出的傳統的數據倉庫構建方法；

（2）Ralph Kimball提出的敏捷數據集市構建方法。

這兩種方法論各有優劣，我們逐一來看。

1.3.1　傳統的數據倉庫構建方法

數據倉庫之父Inmon所提出的數據倉庫構建方法，通常也被稱為傳統的數據倉庫構建方法。此種方法期望能夠從整個企業的全局視角入手，建立企業級的數據模型，從而建立起數據倉庫，然后根據各個部門的要求，進而從數據倉庫中取出相應的數據，形成能夠滿足各個部門需求的數據集市。其構建流程如圖1-1所示。

傳統的數據倉庫構建方法的優勢如下。

（1）能夠在一開始就從企業的全局來審視IT系統及數據現狀。這樣做的好處極為明顯，因為在項目初期就能夠去考慮如何構建整個企業的數據視圖，所以能夠充分了解企業現狀，進而引出下一個優勢。

（2）能夠借助搭建數據倉庫的機會，梳理整個企業現有的IT系統和數據，進而為將來的數據治理，甚至是數字化運營打下良好的基礎。

（3）企業級的數據倉庫項目技術含量高，采用的工具和技術也比較多。若企業可以通過自己的IT部門來完成這樣的項目，則能夠很好地鍛煉相關的技術人員。

（4）構建數據倉庫的過程，其實也是對企業現有業務流程進行梳理的過程。

但是，這種數據倉庫的構建方法存在不少問題。

（1）實施難度大。構建企業級的數據倉庫，需要設計企業級的數據視圖，這就對設計人員提出了極高的要求。另外，在進行ETL處理時，需要從多個不同的IT系統、數據源、各種文件，甚至外部數據源中抽取數據，有時可能需要大量的開發工作。并且，來自不同IT系統的數據，往往會存在大量的數據不一致、相互沖突、重復，甚至無法區分誰對誰錯的情況。筆者曾經參與過數個企業級數據倉庫項目，遇到的此類問題真是太多了。

（2）項目周期長。一般的企業級數據倉庫項目，其實施周期至少在半年以上。其間一旦出現關鍵參與人員中途退出或其他意外情況，就很容易導致項目延期。雖然在IT行業中項目延期是常事，但是數據倉庫項目的延期現象尤為突出。

（3）前期成本高。構建企業級的數據倉庫，需要在前期就進行大量的人力、財力投入，需要購置大量的設備，組建由多人構成的實施團隊。雖然現在可以通過使用公有云來降低硬件成本，但是其他的前期投入依然居高不下。

（4）敏捷性較差。由于此種構建數據倉庫的方法周期較長，因此缺乏敏捷性，尤其是在業務上。如果在項目后期才發現早期設計的數據模型有問題，那么返工的成本就比較高。

綜上所述，可以看出，傳統的數據倉庫構建方法是一種典型的優缺點都極為明顯的方法。

1.3.2　敏捷數據集市構建方法

與之相對，Kimball提出的敏捷數據集市構建方法（有時也稱為自底向上方法）則在相當大的程度上避免了傳統數據倉庫構建方法的一些缺點，同時又有著自己獨特的優勢。該方法從一個較小的業務場景入手，快速構建數據模型，收集數據并構建數據集市，然后逐步擴展，最終形成整個企業級的數據倉庫。敏捷數據集市構建流程如圖1-2所示。

與傳統的方法相比，敏捷數據集市構建方法的優勢極為明顯。

（1）前期投入成本低，試錯成本低。由于是從一個小的業務場景開始的，所以此種構建方法屬于典型的“船小好調頭”。企業可以選取最緊要、最容易出成果、數據質量最好的場景下手。這樣做項目成功率就比較高。另外，由于是從小處著手的，因此即使失敗了成本也不會太高。

（2）以業務為導向。數據模型的構建和數據集市的搭建都是從業務出發的，更容易獲得業務部門的認可。而我們都知道，業務部門的配合，是數據倉庫項目成功的關鍵因素之一。并且，以業務為導向的另一個好處就是能夠盡快出成果，無論對于業務部門，還是高層而言，這都是一件能夠影響全局的事情。

（3）周期短、見效快。由于敏捷數據集市構建方法的切入點小，因此接下來的數據收集與維度模型創建的工作量和技術難度也就比較低，故而在較短的時間內就能夠完成數個業務場景的模型構建和結果展示。項目周期一般以周計。

（4）具有足夠的敏捷性。切入點小，項目周期短，帶來的好處就是整個項目將具有相當高的敏捷性。當發現初期的數據模型或分析方向有誤時，可以隨時調整，即便全部返工，其帶來的損失也相當小。

（5）技術難度低。敏捷數據集市構建方法，由于是從小的業務場景入手的，初期的數據量不大，可以選擇IT人員比較熟練的工具和技術，所以技術上的難度就會比較低。這對于提高項目的成功率，以及加強參與人員的信心極為重要。

當然，敏捷數據集市構建方法也有自己的缺點。

（1）初期無法獲得企業的全局視圖。敏捷數據集市的構建是從小處著手的，固然技術難度和工作量都降了下來，但對于設計人員而言，看到的往往是部分數據和業務，一葉障目，不見泰山，這樣就很容易到后期發現前期不少的數據模型之間存在沖突。畢竟設計整個企業的數據模型，與設計部分業務場景或者部門級的數據模型，其設計思路、工具及技術都可能是不同的。

（2）存在多次返工的可能。敏捷數據集市帶來了較低的試錯成本，但是項目出現返工的可能性也會隨之增大，尤其是在項目初期。

（3）無法對IT人員進行很好的鍛煉。畢竟項目的技術難度等都已經大幅下降了。

當然，我們在這里探討傳統數據倉庫構建方法和敏捷數據集市的構建方法之間的優劣，其目的并非在于讓企業必須選擇某一種構建方法，而是希望通過列出不同構建方法之間的差異，讓企業根據自己的實際情況自主決策。對于一些具有較強IT技術實力的大企業而言，一上來就實施企業級的數據倉庫項目，雖然風險較大，但所帶來的收益也是相當可觀的；而對于IT實力較弱，或者需要借助外部資源來構建數據倉庫的企業而言，采用敏捷數據集市構建方法則是相對比較合適的選擇。

1.3.3　Oracle推薦的數據倉庫構建方法

Oracle的相關產品很早就開始支持數據倉庫技術了，無論是Oracle系列各版本的數據庫、當年的OWB和BIEE，還是后來的OGG、ODI，以及現在的ADW和OAC等諸多產品，都可以應用到企業級數據倉庫項目的實施當中。并且隨著當前云計算技術的發展，以及Oracle正逐步在全球構建自己的數據中心和Region，結合Oracle多年來在實施眾多數據倉庫項目上的經驗和成熟產品，基于敏捷數據集市的構建方法論，Oracle也提出了自己的敏捷數據平臺構建方法。其數據平臺架構簡圖如圖1-3所示。

與傳統的數據倉庫構建方法相比，Oracle推薦的這種方法，有自己明顯的特征。

（1）業務導向。此種方法完全以企業的最終業務為導向，直接從業務中的關鍵問題，也就是從業務運行中的痛點、難點出發，直擊痛處，這樣就能夠快速見效，樹立企業建立敏捷數據平臺的信心，并且對企業業務的促進作用更直接、更有效。

（2）由小及大。從一個或幾個業務痛點出發，然后逐步擴展，數據集市也隨之增加，最終將整個企業的數據打通，并納入該數據平臺中。

（3）簡化流程。數據可以直接從業務系統或其他原有位置進入數據集市，并按照業務分析的需求逐步擴充，然后進入數據倉庫，從而形成整個企業的敏捷數據平臺。

（4）敏捷高效。項目的實施周期短，業務上見效快，這對于數據分析和業務洞察都極有好處。

不僅如此，而且Oracle推薦的方法是完全基于公有云的，因此云計算有與生俱來的彈性，也就是按需擴展和縮容的能力。各個企業完全可以根據自己的需要，隨時在線擴充自己數據平臺的CPU或存儲容量，業務應用完全不會中斷，可以保持全程在線。

另外，Oracle推薦的這種敏捷數據平臺構建，與傳統的數據倉庫構建方法并非排斥的關系。對于沒有數據倉庫或數據平臺的企業而言，完全可以采用Oracle的這種構建方法；而對于已有數據倉庫的企業而言，Oracle推薦的方法依然可以起到加成的作用，也就是在現有的數據倉庫之上，提供強大的敏捷性和彈性，從而能夠讓企業更從容地應對瞬息萬變的市場需求。

從產品上來說，Oracle推薦的方法是基于ADW和OAC這兩款關鍵的基于Oracle公有云的成熟產品。本書后面的內容將為讀者深入介紹這兩款產品的功能、技術特征，以及如何使用。

Oracle的售前專家曾經在一次用戶的數據平臺項目實施中，特意將Oracle推薦的基于ADW+OAC的方案與傳統的數據倉庫進行了對比，具體內容如表1-1所示（當然，不同的數據倉庫或數據平臺項目的差異性極大，因此表中數據僅作為參考）。