談談資料倉庫架構的發展和分類

最近在網上看到了一篇關于各種資料倉庫的架構的文章,将其轉載記錄下.

總之沒有最好的架構,還是要根據業務需求來選擇适合的架構,才能達到效果,使客戶滿意.

Jerome 20061210

最近大家對資料倉庫架構的讨論又多了起來，我在這裡對一些架構進行一下簡單的整理。目的是給大家樹立一個靶子，大家可以在這篇文章後盡情的批判和補充。

我把我聽說過的架構都歸整在一起，分了六類，其中和很多說明是我個人的了解，不見得正确，大家多多指導。

1．獨立的資料集市架構（Independent data mart architecture）

獨立的資料集市架構有時也稱為獨立的資料倉庫架構，應該是出現最早的架構方式，也是很常見的方式。特别是對于中小企業、中小開發公司，出于成本和見效快的考慮都會采用這種架構方式。大家對這種架構方式一定也很熟。

這種架構方式的缺點也很明顯，不是企業内一緻的資料，産生資訊孤島。當然我企業就是很小，就一個系統，不用整合，一個資料集市足以的情況下采用這種方式也沒什麼。先期小投資，讓企業看看效果，以後發展大了再考慮重建立立資料倉庫。

2．聯邦式資料倉庫架構（Federated data warehouse architecture）

這種架構方式我之前寫過一點簡單介紹，當然，我對這種方式也不熟，介紹的也是亂七八糟。我想它的出現應該是由于，企業發展的初期建立了幾個獨立的資料集市架構，後來發現這樣不行，資料沒整合，要解決資訊孤島得想辦法。推倒重建當然好，不過投入太大，以前的資料集市還想用，怎麼辦。于是，想出另一種辦法，在各個獨立的資料集市間建立一些對照表，在不推倒它們的基礎上能進行一下資料交換。後來，慢慢發現，早想好整合政策，直接這樣建資料倉庫也可以，于是，地域聯邦、功能聯邦的概念也就都提出來了。

聯邦架構的缺點也很明顯，除非建立之初就采用類似總線架構的方法實作資料一緻，否則很容易出現資料不一緻，導緻整合的不徹底。如果之初就考慮好的話，和總線架構的差别就不大了。當然，對于臨時解決企業原有獨立資料集市的資料交換問題，聯邦架構還是有一定作用的。

3．集中式架構（Centralized architecture）

集中式架構方式的出現，辨別着資料倉庫架構已經進入比較成熟的時期。他的架構方式是建立實體的EDW，即中心資料倉庫，資料都集中的EDW中，應用和分析程式都在EDW中進行通路，資料是全企業内一緻的。随着ROLAP的發展，在這種集中式架構中建立ROLAP開始比較流行，常見的MicroStrategy公司的解決方案就是在EDW中建立ROLAP。ROLAP單獨建表儲存中繼資料，隻儲存次元模型的關系，不儲存次元模型的資料，由MicroStrategy的應用去解析，加上應用伺服器作為緩存，速度還可以。

這種方式也有一些缺點，如擴充能力差，對EDW所在的RDBMS要求太高，随着資料量和分析的逐漸增長，就不得不再把資料進行分離。如果在EDW的基礎上進行資料分離，為不同的應用單獨建立資料集市或者挖掘倉庫，集中式結構也就演變成Hub and Spoke架構方式。

4．集線器和車輪輻條架構（Hub and spoke architecture）

其實我更想直接稱之為企業資訊工廠架構（Corporate information factory architecture），集線器和車輪輻條架構聽起來比較别扭，叫起來也不響亮。而企業資訊工廠應該是這種架構方式的最出色的代表。從名稱我們也能大概猜個差不多，中心資料倉庫EDW從各個源系統收集資料，将資料提供給各個資料集市和挖掘倉庫，功能和集線器很相似，是以稱為Hub。如果大家把圖畫出來，可能會更形象一些，EDW和各個源資料庫及資料集市、挖掘倉庫之間都連一條線，看起來就向一個車輪，這些連線就像車輪輻條，是以稱為Spoke。而這種采用中心資料倉庫EDW內建資料，再分散到各個資料集市使用資料的方式就形象的稱為Hub and spoke architecture。

這種架構方式當然也有缺點，雖然是在內建的中心資料倉庫EDW上建立資料集市，但是這些資料集市之間還是不能進行資料交換的，大家建立的方法和ETL程式都會不同，各個資料集市之間的資料不見得的是一緻的。而且這種架構方式開始變得複雜。

5．總線架構（Bus architecture）

總線架構和Hub and spoke architecture的最大差別，應該是次元模組化的原子層和一緻性次元的建立。正因為預先建立的總線架構和一緻性次元，是以這種架構可以保證在逐漸建立資料集市的過程中還能保證企業資料的一緻性。總線架構是資料倉庫架構方式從複雜走向簡單的一步，将次元模組化的資料倉庫原子層和資料集市合而為一，一層就把資料倉庫建立好的，還能支援各種資料集市分析應用。

當然總線架構也有缺點，中心資料倉庫以次元模型儲存，對于特殊的非次元型分析應用會有局限性，支援的不好。

6．複合式架構（Composite architecture）

複合式架構是我自己起的一個名字，當然它可能有自己的名字但是我不知道，歡迎大家指導。這種架構方式是綜合考慮Hub and spoke architecture和Bus architecture兩種架構方式，或者說綜合兩種方式得出的一種架構方式。這個，innovate511可能更有發言權，CDW架構應該就是這種架構方式的代表。

複合式架構的缺點也是很明顯，架構過于複雜，（比CIF還要複雜），企業内資料量大的話，每一次搬動都會非常麻煩。

呵呵，簡單的整理的各種架構，也大略談了一些缺點，至于那種架構好，那種不好，我不想和大家争論，我想它們都有自己的适用範圍吧。歡迎大家對我文章中的錯誤和描述不清的地方進行指導。

土包子 20061210

innovate511 20061211

覺得還是和具體情況有關吧。

有多大規模的項目、企業期望（包括期望的生命周期）、企業投資等都有關系。當然，正如前面分析到的，目前已上項目中，各種架構都嘗試過了，優缺點都很明顯。

不過複合式架構的缺點，我覺得并非搬動麻煩，而是整體要求很高，無論是EDW資料整合，還是類似HUB的CDW建設，再到資料集市，接口很多，對設計要求高，而對開發和測試的要求也很高，任何一步沒走好，都可能導緻項目瀕臨失敗。這也是90年代很多想模仿CDW思想的項目失敗的重要原因。但是效果也是很明顯的，即使數萬計的最終使用者，各個部門世界各地的分公司的四大BI需求全部能滿足，由于所有複雜資料轉換問題都在背景已經完成了，BI工具可以更穩定更快速地實作BI。同時由于非常靈活，也能滿足更多資料源和業務的加入，實作系統長期使用，避免重複投資帶來的資金投入過大、穩定性降低、一緻性在重複上項目後不能保證、前期項目維護問題太多導緻最終使用者不滿等缺點。

至于資料搬動問題，我覺得不是大問題，因為沒一步也可以看成一個獨立的整體，隻要按照流程移植，是不存在風險的，包括利用Kimball的思想進行DMR（Data Mart Restructure），資料集市也可以不斷擴大或者拆分來滿足更複雜BI整體需求，在這些靈活度方面我還是很有信心的。

Qing 20061211

這兩天關于資料倉庫架構的讨論甚歡，看了jerome、innovate的介紹，有些東西清晰了不少。Jerome提出六種架構，Innovate提出架構面臨的四種需求，以及四級架構抽象級别。下面我就充當主持人的角色，再歸納一下這個六、四、四，各位還請繼續探讨。

六種架構（Jerome提出）：

1、獨立資料集市：如果你對建構一個大型資料倉庫沒把握，可以從獨立的資料集市入手；

2、聯邦式：如果你已經有若幹資料集市，但又不想建立一個實體集中的資料倉庫，可以考慮聯邦式的；

3、集中式：針對不同資料源，建立實體集中的資料倉庫，任何分析都從中取數；

4、CIF式：如果你有決心要建構一個大大的資料倉庫，充分規劃好這個資訊工廠。建立實體集中資料倉庫，并且為專門應用建立資料集市；

5、總線式：如果你想快一點看到效果，又不想向獨立資料集市那樣，可能浪費投資，采用總線架構；統一規劃，盡快實施。

6、複合式：綜合CIF，偏向資料的用CIF，偏向應用的用總線架構。

我想，對于電信行業的經營分析系統來說，大部分是比較符合"集中式"的，因為它從不同資料源實體集中了資料，并且沒有單獨建構資料集市，大多隻是在資料倉庫架構裡面劃出一層DM層出來（不知道算不算）。當然，也有可能是使用總線架構的，畢竟這個見效快一點，在目前這個階段，"快"還是一個優先考慮的因素。

架構四種需求（Innovate提出）：

1、對資料的整合需求；

2、對業務的分解需求；

3、對資料的效率需求；

4、對需求變化的需求；

Innovate對這四種需求并沒有多說，為什麼分成這4種，是否還有别的類别？看起來業務的分解和需求變化都是指業務需求（可能隻是前者是現有業務的功能分解，後者是業務需求的變化吧）。如果要對需求進行分類，還得看看都是什麼角色提出這些需求的。處理資料的人，希望架構能夠友善自己，使用資料的，希望能夠快速、安全地通路......我想這就是需求分類的依據。

架構的四層抽象級别（Innovate提出）：

1、整體IT架構；諸如硬體、網絡體系，或SOA等等；

2、資料倉庫架構；諸如前面介紹的總線式、CIF架構等；

3、功能架構；如何支撐ETL、OLAP、報表展現、Portal等等功能；

4、應用架構；如何支撐具體的業務，例如對客戶通話行為的分析，這是電信行業相關的。

将架構分成不同的抽象級别，這是顯而易見的。例如SOA肯定是比J2EE更加抽象的，J2EE也許不适合資料倉庫系統的架構，但SOA卻能适合。到了第三層架構，至少都是能夠适合不同行業的資料倉庫項目的，但到了第四層，便隻是服務于專門的行業了。

[email protected] 20061212

請教一個電子政務方面的案例：如何對已經自成體系的垂直系統進行資料整合?

在市區的電子政務中，要對市級的各個部門進行資料整合。因為這些部門多數都是自上而下的系統，是由國家中央、省到地方市區的。比如公安、稅務、人民銀行都是自成體系的業務系統。再如國家統計局各個專業名額（人口，工業，農業等等）的資訊系統也都是自成體系的，從中央推向地方區鎮，而要想得到市區一級的綜合統計名額（人均純收入，GDP，社會消費零售額等），就必須對各個專業名額進行整合，它們都是異構的資料庫和資料标準（叫資料集市？），而整合形成的資料平台叫資料倉庫？是形成一個中間件式統一規劃的資料标準還是做接口表呢？如果要想橫向協同利用各個局的資料，比如市區政府想利用這些資料，應該采取上述的哪種方案呢？我想雖然我們應用目标的出發點不一樣，但是碰到的資料整合問題應該是相通的吧。

goldenfish 20061213

這種情況下資料整合的挑戰首先來源于管理模式。市區政府想要利用這些資料，但這些資料的所有權并不直接屬于市區政府。以前遇到的情況是，市長辦公會請各部門一把手去，專門讨論如何給資料的問題。每個部門都說自己的明細資料機密性很高，搞不好就引起社會問題，不願意給，能不能隻給報表？如果給的話，能不能給去年的資料？或者給的話，隻給一次？要想動态實時的拿到這些資料，更是不可能的任務。大的國企也有這個問題，法人層級太多，總部想要下面的資料也是被推三阻四，軟磨硬泡的不給。

其次，市區一級的綜合統計名額體系如何建立。從一個市區的角度自定義一套綜合統計名額體系，有點勉為其難。與國家統計局的統計口徑是否保持一緻？如果全然一緻，為什麼不從本市的統計局直接取？當然，統計局可能走的是一套自己的統計方法、例如抽樣；自己的頻度，例如一季一次；可能隻向上級統計機構負責，而不向平級下級負責等等，以至于統計局的資料很難直接使用。統計名額體系的建立要把各主要業務部門的核心名額彙聚到一起，剔除重疊和不一緻，有些需對跨部門的資料進行合并。這個名額體系的建立也是很大的挑戰。

最後才是技術架構如何建立的問題。沒有通用的或絕對正确的技術架構。它是解決具體問題的，随着實際狀況的不同而調整。由于上述管理的和安全的原因，從源系統直接取數恐怕是很難實作的，退而求其次，隻能要接口表或接口檔案。如果不能從源系統的資料直接導出，可能還要定義接口格式，由開發系統的廠商提供。接口表（或接口檔案）放置到從接口緩沖區轉移到一個集中的場地（伺服器）進行資料整合。統一規劃的資料标準很難限制到每個部門的業務系統，畢竟都是垂直條線下來的；現實一點，隻能限制接口标準。在設計中還要考慮資料如何存儲（資料結構）、取數的頻度、資料保留多久、整合後資料是否有需要回流到源系統等問題。此外，還要考慮有部分資料很難取到原始明細，要有人工補錄的手段。

Qing 20061213

看到這個問題，頭腦中首先碰出來的一個想法是——"可以用聯邦式資料倉庫的架構"。因為對于已經自成體系的系統，将資料整合到一個實體資料倉庫是否現實？後來看到goldenfish的回複，提到首要的挑戰在于"管理模式"。應該就是這個道理吧。管理的整合比資料整合要難，何不避難從簡？

當然，由于對電子政務中的系統不甚了解，不管此處說得是否合理，能夠對思路有所開拓就足夠了。

為什麼當初的第一反映是"聯邦式資料倉庫"呢，如此問自己？也許正是餘山老師提到了自成體系的系統，這些系統由不同開發商完成，也沒有什麼統一的标準，系統的設計思想、編碼肯定是千奇百怪，而且涉及到安全性的問題。是以我想，可能用一種虛拟的資料倉庫更加合适，即實際的資料都還是位于各自的系統當中，而所謂資料整合，是建立一個可以容納所有這些系統（現實一點，可能是這些系統的交集部分）的架構，架構裡面放置的是類似"資料指針"那樣的東西，這是虛拟的，當你需要查詢什麼資料的時候，其實這個架構是将查詢定位給具體的系統了。比如要查詢某個人的信貸、犯罪、稅務情況，好似從一個統一的平台輸入了ID号，傳回以上若幹資訊，但資料都還是存放在金融、公安和稅務的系統裡面的。

由此深入思考，我認為與其說這個案例是"資料的整合"，不如說是"應用的整合"。是以，根本也用不上上面提到的資料倉庫架構，也不是什麼"聯邦式架構"，可能應該在面向服務架構（SOA）中尋找答案。

建立一個資料倉庫，不如建立一些标準，可以将每個獨立系統想象成為一個服務提供者，它可以提供什麼服務，是經過注冊的。比如金融系統可以根據一個個人ID給出此人的帳戶、貸款、信用等資訊，可以根據一個公司的代碼，給出公司的資訊，或者可以提供年度的統計名額等等。當然，這些資訊的提取應該是基于金融系統内部的資料倉庫的，總不能從業務系統去取。此處關鍵的就是如何定義這些"服務提供者"提供的服務，也就是标準。輸入什麼、輸出什麼、甚至是輸入輸出的規格标準化（例如身份ID的要求，輸出資料中，性别的編碼規則）、權限控制、如何注冊這些服務等等。

有這樣的标準，具體的實作交給獨立系統的實作廠商。而至于基于這些服務能夠作甚麼用途，那得具體看應用而定。

goldenfish3 20061213

資料整合和應用整合有些差別。通常，應用整合指EAI，現在已經轉向以SOA的理念實作EAI。資料整合通常指通過資料整合層或資料內建平台、EDW等進行的資料內建（Integration）/整合（Consolidation）/融合（Mediation）。廣義的應用整合包含業務應用間的資料內建，即A的資料送往B，例如保險營業系統中的保單收費送往财務系統入帳。但應用整合更多是指A系統要求B完成一個操作，B完成後傳回一個确認，以及這樣的多步操作形成一個流程，流程內建是應用整合（內建）的進階應用。資料整合往往是為分析目的完成的。不同系統的資料送往一個內建平台，進行資料清洗和整合，為了實作分析應用。兩者結合起來，可以稱之為企業整合（EI）。

如上所述，兩者是有交叉的。特别是SOA與主資料管理相結合之後，主資料內建通過SOA實作，主資料為業務系統形成統一的視圖（在電信裡已經有SID的應用）。這種理念的出現展現了SOA對傳統業務系統架構的沖擊，也是應用整合的一個發展方向。但主資料管理并不能替代資料內建，不能替代資料的清洗整合。兩者服務于不同的目的，有不同（盡管可能有所重疊）的範圍。倒是EII的出現對傳統的資料整合架構有所沖擊。EII展現了一種實時資料內建的理念，來自不同源系統的資料不集中存儲，而是使用的時候邊傳輸邊內建。但顯然，目前EII的實作不能隔離對業務系統資料庫的通路壓力，對于大量資料很難有效處理。

[email protected] 20061213

感謝諸位賜教。如上所言，管理的整合很難。但正是管理的界限形成了資料統一規劃的界限，異構系統就是這樣形成的。對于一個企業來說，消除部門的異構資料還可以通過統一規劃的方法來達到共享，而對于像市級的各個專業局就是難以實作了。

就我目前調研的情況看，在市區一級的ＯＡ系統，聯合審批（所謂陽光政務），還有财政局因為要對其它部門實作統一國庫支付（兩千以上的采購），這些系統的橫向協同比較緊密，好像可以進行統一的資料規劃整合。

劉慶最後的應用整合提法令我很開竅，打個比喻，是否如同XML網絡消除異構的方法，不是在文字的存儲編碼上去統一整合，而是在顯示界面的語言上統一整合？這樣就能與作業系統，資料庫，字元資料的儲存标準都無關？進而達到統一。

火焰 20061220

個人認為總線機制的發展前景更好些，擴充性比較好，可以在大型的企業中依此建立多級的資料倉庫以及BI應用，至于缺點中所說的内容，竊以為不是大問題，每個資料倉庫都會有特殊的應用，每個總線上的元件總是會有元件自身的特色，隻要這種應用所使用的标準是統一的，或者使用的範圍不廣，不會對整個總線的架構産生很大的影響。