怎樣的架構設計才是真正的資料倉儲架構（轉載）
這是2006年發生在ttnn上的一段有趣的交流...也許有助於我們對ODS的瞭解
innovate511
檢視個人資料
（1 個使用者） 更多選項 2006年2月22日, 下午2時25分
發件人："innovate511"
日期：Tue, 21 Feb 2006 22:25:13 -0800
當地時間：2006年2月22日(星期三) 下午2時25分
主題：怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
國外大專案之所以把Architecture工作和data
model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
fact
table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
huhaifei
檢視個人資料
更多選項 2006年2月23日, 上午10時40分
發件人：huhaifei
日期：Thu, 23 Feb 2006 10:40:26 +0800
當地時間：2006年2月23日(星期四) 上午10時40分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
按照對業務和資料的理解後，如何去進行架構設計呢，一個好的合格的架構設計包括哪幾方面內容呢？大家按照各自經驗給些意見和指導。。。
2006/2/22, innovate511:
> 在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
--
胡海飛
DW & BI,EAI,IRP
MSN：flyingfox1...@hotmail.com
QQ:6184771
劉慶
檢視個人資料
（1 個使用者） 更多選項 2006年2月23日, 下午1時03分
發件人："劉慶"
日期：Thu, 23 Feb 2006 13:03:19 +0800
當地時間：2006年2月23日(星期四) 下午1時03分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
架構設計究竟怎麼進行，包括什麼內容。前兩天一個朋友熬夜要完成這份文件，因為第二天就要提交，看，這本身是有問題的吧。架構設計怎麼如此倉促？它的設計對以後整個專案的體系都是影響重大。所以，我想如果僅僅是寫一份客戶需要的《總體設計文件》，ctrlc，ctrlv也就夠了。然而如果是要實在考慮如何架構一個BI系統，有必要琢磨一下。
首先看看架構設計中包括那些內容，再來反過來看看它為什麼人服務。
架構中重點是描述系統的結構，以及他們之間的關聯、互動介面。BI系統可以劃分成業務模型、後設資料、資料質量、介面平臺、報表集市、指標庫等。可以看到，這裡命名這些模組都是靜態的名詞，而不是動詞，例如業務建模、資料質量管理等，之所以如此，是因為這是在描述系統的結構而非功能。
業務模型是存放業務資料的結構，可以再細分，成ODS、DW（還可以細分）、DM等，它是支撐業務分析需求的，例如報表、儀表盤、OLAP、專題應用等。而後設資料是為整個系統資料的形態和資料流動的過程起到支撐作用，也就是說資料從源頭開始，到最終的使用者眼前，其來龍去脈，每個環節的狀態都需要掌握。而資料質量模組是為衡量資料來源質量、ETL過程處理質量提供支撐。介面平臺是處於源系統和資料倉儲系統之間的，方便明確界定雙方職責的模組。報表集市為報表應用提供支援，指標庫為績效管理需求提供支援，後兩者其實還可以歸入業務模型一類，因為它們都是服務於分析需求的。
之所以分成若干模組，是為了讓架構清晰，降低這些模組之間的耦合，如此的構成是否合理呢？還得看看這個架構面臨的需求到底是什麼，將系統的使用者分為兩大類角色：
1、 系統運營角色，他們對系統的正常執行、維護負責；
2、 業務分析角色，他們需要從這個系統得到資料分析的功能；
顯然，第二種角色的分析資料來源都都將來自業務模型模組。而第一種角色將從剩下的模組中滿足自己的需要，可以說，他們絕對不直接和業務模型這個模組打交道。在架構設計中，重點應該放在如何滿足系統管理使用者的需求上面，當然是"重點"，而非捨棄業務分析角色，畢竟在業務模型模組中，根據業務的特點、資料量的特點、分析應用的特點，來進一步細化。
這裡有個自己的理解要說明一下，架構設計應該是於具體業務關係不大的，這種架構應該是半通用的。之所以是半通用，在系統功能上面，BI專案大同小異，而在業務需求上面，架構中只需要對客戶的業務、分析需求分成幾個大類，例如按行業分業務模型，按OLAP、報表來為分析應用分類，不要太過細節。
來看看這系統運營角色的需求罷，還可以對這類角色細分成：
1、 開發設計者。之所以將開發者作為系統的使用者，是因為資料倉儲專案應該看作一個過程，而不是產品，因此在開發階段，其實其架構最重要的使用者就是開發者，當然要為之提供便利。
2、 系統管理員。系統交付之後，如何監控系統執行、發現資料質量問題、應付新的分析需求等。
那麼對於開發實施人員，他需要進行系統部署、ETL的開發除錯、質量的稽核；設計人員，需要進行模型的變更、系統調優、作系統一致性分析等；而系統管理員則需要監控ETL過程、監控系統執行、響應系統警報、介面資料管理等。這些都可以看作是用例。
面對這些用例，它們是架構設計的"需求"，如何滿足他們，並且保持良好的體系和清晰的結構。能夠易於維護，且能夠滿足日後肯定會增加的業務需求。
說了這麼多，主要要表述的觀點是：
1、架構設計主要面向系統使用者為主；
2、架構設計的內容主要包括：系統功能需求、分析需求分類；支援這兩者的後臺結構，結構的粗略劃分，以讓其內部能夠保持簡單的互動方式。
3、架構設計和詳細設計究竟如何界定的？在架構設計中，不要出現諸如"欠費賬齡"、"信用等級"這樣的業務術語。
goldenfish3
檢視個人資料
更多選項 2006年2月23日, 下午3時34分
發件人：goldenfish3
日期：Thu, 23 Feb 2006 15:34:12 +0800
當地時間：2006年2月23日(星期四) 下午3時34分
主題：Re: Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
與架構設計相關聯的是倉庫的容量規劃。包括用什麼樣的硬體、軟體、多大的儲存，滿足什麼樣的效能，在未來1年、至若干年如何擴充以適應需求增長。資料倉儲的容量規劃也可以是個單獨的話題，但在我們的實施中，它屬於架構設計部分，而且是個難點。
happy
檢視個人資料
更多選項 2006年2月23日, 下午4時53分
發件人："happy"
日期：Thu, 23 Feb 2006 16:53:1 +0800
當地時間：2006年2月23日(星期四) 下午4時53分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
想請教一個問題，增加分表指的是什麼意思？
是指由於轉換規則太複雜，把原來的一次轉換分成多次轉換，把轉換的中間資料放在臨時表中呢？
還是由於表中記錄數很大，所以按照業務需求、以及今後查詢的特點進行的分割槽處理呢？
還是在剛開始設計事實表時，根據業務的不同進行分類，把不同業務資料分別放在不同的表中呢？
謝謝
happy
- 隱藏被引用文字 -
- 顯示引用的文字 -
-----Original Message-----
>在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
>關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
>對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
>我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
>國外大專案之所以把Architecture工作和data
>model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
>fact
>table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
>由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
>在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
--------------------------
thanks！
happy
xiningd...@prient.com
2006-02-23
innovate511
檢視個人資料
更多選項 2006年2月23日, 下午6時11分
發件人："innovate511"
日期：Thu, 23 Feb 2006 02:11:50 -0800
當地時間：2006年2月23日(星期四) 下午6時11分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我也比較瞭解國內的實際情況，往往是給客戶的設計資料比較詳細，而內部的設計會粗一些，甚至的有的乾脆省略了。而客戶只關心大概的東西，看你能不能滿足他們的分析需求，或者你能給他們帶來什麼分析，具體的事情他們不需要管太多。
從業務角度講，有兩種情況，一是客戶比較盲目，沒有明確的分析需求，這個時候主要就是從現有的資料來源出發，再到前端應用的一種從底到頂的一種設計；二是客戶有明確的分析需求，這個時候既要從現有從底到頂的設計，還要看現有資料來源是否能滿足客戶特殊的分析需求，如果不能滿足，需要儘早提出，並和客戶解決資料來源的問題，從這個角度說，又是從頂到底的一種模式。
從資料角度講，如何把資料來源到前端應用的線牽起來，通俗的說是一個大的ETL過程，但是龐大的系統需要考慮ETL後的資料質量、一致性、效率等很多因素，於是這個問題需要廠商自己處理，客戶不會非常關心，所以才有很多遺留問題。
hujue1982@gmail.com
檢視個人資料
更多選項 2006年2月23日, 下午6時13分
發件人："hujue1...@gmail.com"
日期：Thu, 23 Feb 2006 02:13:32 -0800
當地時間：2006年2月23日(星期四) 下午6時13分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我想增加分表是按照業務的區別將資料分為多個事實表存放，這樣毫無關聯的資料就可以分別存放在不同的事實表中。之前我參與的一個電力決策系統，其中層次就設計分成了5個層次：ODS，臨時層，DW，聚合層，DM，這樣雖然ETL起來比較麻煩，但是非常靈活，可以方便地根據使用者需求而改變；其中事實表也是按照不同的業務分成了多個事實表
- 隱藏被引用文字 -
- 顯示引用的文字 -
happy wrote:
> 想請教一個問題，增加分表指的是什麼意思？
> 是指由於轉換規則太複雜，把原來的一次轉換分成多次轉換，把轉換的中間資料放在臨時表中呢？
> 還是由於表中記錄數很大，所以按照業務需求、以及今後查詢的特點進行的分割槽處理呢？
> 還是在剛開始設計事實表時，根據業務的不同進行分類，把不同業務資料分別放在不同的表中呢？
> 謝謝
> happy
> -----Original Message-----
> >在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
> >關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
> >對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
> >我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
> >國外大專案之所以把Architecture工作和data
> >model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
> >fact
> >table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
> >由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
> >在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
> --------------------------
> thanks！
> happy
> xiningd...@prient.com
> 2006-02-23
innovate511
檢視個人資料
更多選項 2006年2月23日, 下午8時03分
發件人："innovate511"
日期：Thu, 23 Feb 2006 04:03:10 -0800
當地時間：2006年2月23日(星期四) 下午8時03分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
所以分表，就是同一個資料來源，本來可以放在一個事實表，但由於資料量太大，或者業務太複雜，一個事實表很難包含所有主題的資訊，於是考慮按照某種業務需求分成多個相似主題的事實表。這個沒有統一的定論，需要按實際需求設計。比如一個主題分為日報、週報、月報等不同的分析週期，那麼可以分為xx_day_fact,xx_wkly_fact,month_wkly_fact；如果使用者經常察看的日分析是2個月的資料，那麼你的當前事實表只存2個月的資料，其他的放在xx_his_fact中，再久的放到磁帶庫（比如2年前的）。類似的分類分表的方法很多，就不一一介紹了。
而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
fact
table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
劉慶
檢視個人資料
更多選項 2006年2月24日, 下午12時11分
發件人："劉慶"
日期：Fri, 24 Feb 2006 12:11:09 +0800
當地時間：2006年2月24日(星期五) 下午12時11分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
這個confirm table，一直沒整明白是幹啥的。按照Innovate的描述，它是一種"聚合一個涵蓋豐富資訊的事實表"。如此，我理解的confirm
table，恐怕就是那種主題表，例如使用者資訊表（一系列），這些表的粒度是其描述的實體決定的，針對這種實體的彙總資訊表。常見的實體包括使用者、客戶、渠道、產品、資源、競爭對手等。
其實業務資料模型設計，區分成ODS、DW和DM，他的*架構*目的有二：
1、為了能夠滿足使用者可能變化的分析需求；
2、要不就是為了查詢效能的需求。
confirm
table概念的提出總歸是要解決這兩個問題或其中一個吧。如果是上面理解的那種，目前很多公司的模型設計已經有這樣的分層，直接從事實表（ODS表）建立一個若干維度若干度量的彙總表，那是很早以前的做法了。
至於"分表"這種叫法，覺著是個比較含糊的術語。在專案實施中，存在一種現象。為了滿足使用者新需求的時候，或提高效能，去修改模型，可能就需要"分表"，但通常會出現諸如tmp_xxx的臨時表，甚至是以設計者名字命名的表，將他們當作臨時表，但很可能他們並非臨時的，會融入到實際的流程當中，導致混亂。這是因為在架構的時候缺乏概念設計的結果。整個系統的架構應該能夠形成一個概念體系，底層物理的每個表，每個操作都能夠歸屬到某個邏輯或是概念上。
例如增加一個臨時的彙總表，那麼就嚴格規定，此表不能放入常規的ETL流程當中，因為那樣會導致概念混亂。如果按照週期分表，同樣在上層應該是有"不同週期主題表"的概念。
所謂概念，其實就是給個名份。資料倉儲中分那麼多層次，ods、dw不都是資料倒來倒去嗎，甚至都可以叫它們作"中間表"，可這不是一個清晰的概念，於是就產生了細分。就像你叫一個人，"哎，女人"，這多不尊敬人，如果叫"小麗啊"，人家就愛聽了。
On 2/23/06, innovate511 wrote:
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
> 而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
> ...
happy
檢視個人資料
更多選項 2006年2月24日, 下午12時54分
發件人："happy"
日期：Fri, 24 Feb 2006 12:54:28 +0800
當地時間：2006年2月24日(星期五) 下午12時54分
主題：Re: Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
謝謝innovate511對我問題的解答，還是有幾個問題再請教一下：
>分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，>中間的資料就斷了，資料質量無法保證。
innovate兄提到如果中間資料按照上面的操作是非常不規範的，因為在ETL過程中斷時會產生資料質量的問題。這一點我還不是很明白。因為我在ETL了的過程中，有一些資料質量的控制方法。如果ETL過程中斷，我會在日誌中記錄中斷的情況，包括涉及哪些資料，在哪一環節出現錯誤。這些資料是不會再進入下面的環節的。我會透過對日誌的分析來重新對這些資料進行ETL，並修改ETL的結果。我想這樣是不是可以解決資料質量的問題呢？
我理解的中間資料不是按照業務來區分的，它只是為了某些原因，比如ETL的效能最佳化、更好維護等等才採取的方式，不知道這樣方式是否確實存在資料不規範的隱患呢？還請innovate兄幫我再分析一下吧。
>而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
>fact
>table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
>tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
查了一下，沒有找到confirm fact table的資料，希望innovate兄再多解釋一下。如果在設計資料倉儲時做到一個資料倉儲的事實表可以和多個資料集市的事實表包含1:n的關係的話，那當然好了。不知如何在實際中滿足這樣的設計？是否要全面瞭解企業的需求，對業務理解很深才行啊？我們現在其實很多時候都在根據一堆業務指標來構造資料倉儲的事實表，構造完後，如果有新的需求、新的指標，就會在原來的事實表上修改或者新建一個事實表。請問如何避免這樣的現象？
謝謝
happy
-----Original Message-----
>分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
>而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
>所以分表，就是同一個資料來源，本來可以放在一個事實表，但由於資料量太大，或者業務太複雜，一個事實表很難包含所有主題的資訊，於是考慮按照某種業務需求分成多個相似主題的事實表。這個沒有統一的定論，需要按實際需求設計。比如一個主題分為日報、週報、月報等不同的分析週期，那麼可以分為xx_day_fact,xx_wkly_fact,month_wkly_fact；如果使用者經常察看的日分析是2個月的資料，那麼你的當前事實表只存2個月的資料，其他的放在xx_his_fact中，再久的放到磁帶庫（比如2年前的）。類似的分類分表的方法很多，就不一一介紹了。
>而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
>fact
>table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
>tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
--------------------------
thanks！
happy
xiningd...@prient.com
2006-02-24
innovate511
檢視個人資料
更多選項 2006年2月24日, 下午2時30分
發件人："innovate511"
日期：Thu, 23 Feb 2006 22:30:51 -0800
當地時間：2006年2月24日(星期五) 下午2時30分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我以前就說過，有好多人想在ODS層做所謂的彙總表作為前端查詢的做法是非常不明智和不科學的。資料倉儲是個工程，你想怎麼做都可以一定程度地實現客戶的需求，所以才會出現很多廠商想當然地去做，因為他們覺得那樣也能滿足客戶的需求，但是他們沒有搞清楚，什麼的方式才是最佳的。
大家很多都看過Inmon和Kimball的書，他們都或多或少提到過confirm
table的概念和思路，就像劉慶說的，confirm
table的出現的主要目的就是能夠滿足使用者可能變化的分析需求和查詢效能的需求，增加資料倉儲的靈活性、穩定性和高效性。至於為啥ODS層用作前端查詢不好，我也大概說過，ODS層的作用應是承上（資料來源）啟下（DW）的作用，如果你非要給個介面給前端查詢，還做個類似confirm
table的事實表，那不是功能和DW、DM有重疊了？客戶訪問要大大增加系統壓力，作為資料前沿的介面，系統壓力也很大，你如果保證高效？既然ODS到DW還可能經過1到多次的ETL，你怎麼能保證客戶最終查詢和分析的資料一致性？
我不知道“建立一個若干維度若干度量的彙總表”是建立一個彙總表，還是聚集事實表，這是兩個不同的概念。confirm
table既聚集事實表是指經過了所有設計好的ETL後，再把相似的事實表聚集在一起，也就是他還是事實表，不是經過sum,count的彙總表。
說到這裡，不得不說分表了。前面說到了ETL完成後相關主題的事實表要聚集到一個事實表裡，那麼意味著前面我們已經做過拆分，這就是所謂的一個大主題的事實表拆分成分表了。我們這裡說的分表，和劉慶提到的很多專案，包括大型專案中的tmp表有類似的作用，但是並不是我做到專案做到一半，突然發現資料量太大，得找個分表分散ETL壓力，而是在開始設計中設計好的一個步驟，一個層，要不然為啥總體設計要一個有經驗有理論的人設計，隨便找個做過大型專案ETL的人設計不就完了？
再細說的分表的命名，如果資深的DW人，一看到分表基本都是tmp_xxx命名的話，只能說明這個專案是“修補型專案”，也就是走一步看一步，發現問題，我再改建模，我再改ETL，後設資料管理也得修改。之所以後來專案都很重視後設資料管理，是啥原因？沒有後設資料管理，ETL不照做麼？因為大家都知道後設資料有效的管理，能讓你“站得高，看得遠”，能把握ETL全域性。那麼一個“修補型專案”好，還是你前期架構設計好了，按照設計開發就是好呢？一看就明白了，這也是我最近各大論壇和網站提到的架構設計的重要性，我想我不提出來，也有人出來，就像當年很多人提出後設資料管理的重要性一樣。
innovate511
檢視個人資料
更多選項 2006年2月25日, 上午1時43分
發件人："innovate511"
日期：Fri, 24 Feb 2006 09:43:13 -0800
當地時間：2006年2月25日(星期六) 上午1時43分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
to happy
不好意思，我有個事情沒有澄清清楚，分表可以分為業務分表，和過渡分表。你說的那種情況基本屬於過渡分表，目的就是為了分散ETL壓力，而最後需要彙總成一個事實表。
對於過渡分表，很多國內公司使用tmp_xx，我覺得很遺憾，且不說感覺這是個臨時表，就命名來說，專案裡其他人可能不知道這個表是幹嘛的。最主要的是，過渡分表並不是tmp的，應該屬於專案的一個重要環節，它們在完成ETL使命後需要重新回到一起，最後到所謂的confirm
fact table裡面。
再說一下業務分表，所謂業務分表，並不是我們想怎麼分就怎麼分，而是根據實際情況。比如客戶有固定的日、周、月、季、年等多個週期，那麼週資料完全可以自己有一個事實表、年資料也可以。同樣，舉個簡單例子，大客戶的分析維和普通客戶的維有很多不同之處，但是分析的指標卻有很多共同點，而且如果調研結果是大客戶資訊全部來自大客戶系統的話，難道你不覺得大客戶和普通客戶的事實表分開，是非常合理的麼？領導最後可能需要一個總體客戶的分析，這個時候你在完成所有ETL後，可以再彙總到一個confirm的聚集事實表裡，這樣既方便管理、效率高、資料質量有保障，而且方便安全管理，因為客戶很可能不希望某些部門的員工不能看大客戶的資訊，大客戶部門只能看大客戶資訊，而老總都能看。
至於confirm table的相關定義和資料，Kimball的Data warehouse
life cycle
toolkit裡邊就有。而且我以前在文章中也舉個具體的例子，如何實現分表後又能高效聚集到confirm
fact table中。
剛才我說到的這些設計細節，專案的Architecture或者consultant應該可以透過詳細調研後預測這些問題，然後設計出架構來，然後data
modeler根據相關架構設計去建模。而不是上面提到的，專案遇到困難了，於是需要修改相關設計，作出很多臨時表來應付。作為設計者最好是很資深的人，或者有更資深的顧問幫助設計，不說預測好幾年情況，能預測3-5年客戶應該就很滿足了，但是如果專案才開始實施幾個月就發現不對，那預測了什麼呢？
dumpedjoe
檢視個人資料
更多選項 2006年2月25日, 下午1時39分
發件人："dumpedjoe"
日期：Sat, 25 Feb 2006 05:39:09 -0000
當地時間：2006年2月25日(星期六) 下午1時39分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
在專案（不僅僅是dw）中，架構設計師能夠根據自身的技能和經驗對於今後要面對的效能、資料質量、可擴充套件性等要求給出相應的應對方法是一個基本要求，問題是好的資料倉儲架構是什麼樣的，針對不同的系統狀況和業務需要，哪些是作為標準元件必需引入的，哪些是可以根據具體情況進行裁剪或合併的，我想這也是胡海飛希望大家能夠深入探討的，當然inmon和kimball以及其它各位老大早就給出了他們的答案，在這裡我們對具體細節討論一下，比如分表、confirm
fact table、ods等等。
在這裡說說我對ods的理解，和innovate511
略有不同，作為可選元件，ods是dw的一個補充，對於使用者明確的查詢和統計需求，為了減輕源系統的壓力，引入ods，在其中針對確定的需求進行聚合，提供給前端操作型業務人員進行查詢，dw在一定程度上能夠滿足這樣的需求，但是分析型業務人員和操作性型業務人員的目的完全不同，雖然前者偶爾會訪問到操作型人員經常訪問的資料。
源系統
/
明確的查詢需求 分析需求
/
Ods dw or dm
/
操作型業務人員 分析人員
對於無批次查詢需求的專案來說，ods就沒有必要，也不能成為某一個層次，更不能承上啟下。
至於分表命名為tmp_***，我認為只要它是在設計階段就明確了應用在哪個方法上，它就沒有問題，只能說命名方法不好，如果在設計階段未定義，這樣搞才是一個"修補型專案"。
對於dw專案，架構設計對於專案的影響相對其他專案來說要大一些，除了已經討論的，大家是否有其他的應對，或者我們可以提煉一下，形成一個當前的最佳實踐應用到後續專案中。即使沒有結果也是很好的交流。
innovate511
檢視個人資料
更多選項 2006年2月25日, 下午2時54分
發件人："innovate511"
日期：Fri, 24 Feb 2006 22:54:47 -0800
當地時間：2006年2月25日(星期六) 下午2時54分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
首先，架構設計的重要性，是針對專案越龐大（包括資料量和業務複雜度），越是重要。舉個很簡單的例子，我做過得最小的專案，就是某地級市電信運營商的競爭對手分析，就那麼一個主題，資料量也不大，需要啥架構呢？只要業務明確，你想咋做都可以，前端報表和OLAP都做得不錯，客戶就能滿意。所以我前面的講的假設，基本是大專案基礎上。
那麼我說的情況，都是客戶有批次查詢、隨時對各個主題查詢的可能。在大專案中，Operational
Data Store，從定義來講，結構還是OLTP，所以被認為“The
ODS stage is sometimes skipped if it is a replication of the
operational
databases”，那麼如果資料來源很複雜，有多個資料來源的話，將是必須的。
有一點我要說明的是，如果有的ODS層也有事實表什麼的拿給前端查詢，就和本身的定義不符，已經是DW的概念，作為前端應用，那是data
mart的責任。所以我的建議是，不要把查詢看作是獨立的應用，也不要把ODS輕易忽略掉。
我剛才說的重點，並不是他命名，命名只是個表面現象，因為既然專案需要一箇中間層來過渡，為啥設計的時候沒有考慮到呢，非要臨到應用才臨時搞個臨時表過渡？
DW專案的專案質量保證還有個重點，就是開發和測試，我可以另外開一個話題討論。至於也是至關重要的客戶交流、調研，做個N多專案的人都有經驗，我就不另外開話題了。
dumpedjoe
檢視個人資料
更多選項 2006年2月26日, 下午1時04分
發件人："dumpedjoe"
日期：Sun, 26 Feb 2006 05:04:31 -0000
當地時間：2006年2月26日(星期日) 下午1時04分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
主題少，資料量小，業務明確就不要架構我不能認同，好的架構是對後續會發生的常見問題有好的應對，難道等該專案結束後，客戶覺得不錯，再加個主題，資料量增長了以後我們再引入架構重新搞一次？這個暫且不談，還是說說ODS，再次強調一下“明確”，如果查詢需求明確，用data
mart來應對不是好的方法，data
mart對於查詢應該是集中在分析型業務人員在分析之後，對於分析結果可能產生的查詢要求，類似CIF中提到discover（是不是這角色不確定，呵呵），比如某人某天發現怎麼某客戶的貢獻度比上月差很多啊，鑽取到原子資料來看看，而ODS應對的是習慣性的查詢要求，每天都要做，一做一大批，業務系統和dm能做啊，可是對於正常響應業務或分析操作就有影響。
我很認同查詢不是獨立的應用，在bi系統中，分析和查詢的需求都會有，所以我們才不能一股腦將查詢需求丟給dm，ods的必要性也在於此。而且在ods中圍繞“明確”的需求在源業務表上作聚合沒問題，什麼都不幹搞它做什麼，與資料來源的多少無關，它也不是事實表。
大家對海量資料的情況下，使用何種架構能夠保證裝載和轉換的效能聊聊吧，：）。
innovate511
檢視個人資料
更多選項 2006年2月26日, 下午1時46分
發件人："innovate511"
日期：Sat, 25 Feb 2006 21:46:45 -0800
當地時間：2006年2月26日(星期日) 下午1時46分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
樓上有沒有想過，dm獨立一個邏輯塊出來，供前端查詢？我前面提到過，DM可以是很豐富的一大塊，既可以豐富DW的事實表，也可以豐富出來供前面所有應用使用，再複雜的應用，最好的辦法就是分層或者分模組。目前我見過得專案中，這種方式應該是最好的，還有其他疑問麼？
之所以最佳的辦法是在DM這一層供客戶查詢，就是考慮到了客戶複雜的，批次的查詢需求。在ODS查詢的話，客戶需要一個複雜的查詢，難道你需要關聯好多大表，如果實在太難，你就對客戶說，不好意思，邏輯太複雜，實現不了？客戶肯定就會納悶，既然你能實現複雜的報表和OLAP分析，為啥我複雜的查詢不行呢？
還有，ODS層在絕大多數專案中，是供DW的資料來源，不知道你把ODS作為查詢資料來源後，DW是否透過直接透過各個資料來源直接裝載呢，還是ODS也擔當這個功能呢？
至於如何保證裝載和轉換的效能，在設計中，設計者總體思路是估量專案的資料量和業務量，然後就可以定論如何分層，分表如何分。kimball他們在書中只是寫了大概要有staging
area,
conform層等，其實現實的大型專案中，還可以多加一些過渡層，以保證效率。因為不同專案選擇ETL方式不同，有的選擇使用工具，有的選擇自己開發。如果自己開發的話，所有轉換都在儲存過程中進行，對於海量資料來說不是最好的辦法，因為佔用資料庫的資源太大。建議把資料拿到c/java等程式裡轉換後，再load回去，減少資料庫負擔。這裡說到了部分軟體工程的問題了。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時12分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:12:42 -0000
當地時間：2006年2月27日(星期一) 上午9時12分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
目前我見過得專案中，這種方式應該是最好的，還有其他疑問麼？
- :-))))
客戶複雜的，批次的查詢需求。在ODS查詢的話，客戶需要一個複雜的查詢，難道你需要關聯好多大表,如果實在太難，你就對客戶說，不好意思，邏輯太複雜，實現不了？
- 明確？聚合！
ODS層在絕大多數專案中，是供DW的資料來源 - ???
如果自己開發的話，所有轉換都在儲存過程中進行，對於海量資料來說不是最好的辦法，因為佔用資料庫的資源太大。建議把資料拿到c/java等程式裡轉換後，再load回去，減少資料庫負擔。這裡說到了部分軟體工程的問題了。-
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時23分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:23:33 -0000
當地時間：2006年2月27日(星期一) 上午9時23分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
CIF有專門的章節描述ODS,ODS有以下特點：
面向主題的
整合的
易變的
明細的
反映當前資料值的
ODS是企業資料架構中最為複雜的一種形態，既要滿足資料事務操作要求，又要滿足資料分析要求,中國電信的CTG-MBOSS規劃中對ODS有比較明確的要求，但在CTG-MBOSS規範中，ODS也做了一定的變更處理。在雲南電信以及上海電信的ODS系統建設中（雲南電信ODS已經初驗，上海電信的ODS算是上線了），ODS的定位就比較模糊，其主要功能是給資料倉儲提供資料，但大致來講，ODS有以下四種型別：
I
類ODS，與應用系統的資料延遲為1~2秒，實時或近似實時
II 類ODS，與應用系統的資料延遲為2~4小時
III 類ODS，與應用系統的資料延遲為12~24小時
IV 類ODS，資料倉儲中部分決策分析資料迴流至ODS中
目前應用的比較多的是IV
類ODS，因為一旦將決策分析結果載入到ODS中，重要決策資訊的高效能聯機支援將成為可能，舉例如下：
客戶細分與評價
銀行客戶貸款
ODS與資料倉儲的重要區別如下：
ODS只儲存明細資料
ODS中儲存的資料一般不超過一個月
ODS支援事務更新操作
在ODS中存在3種不同的時間窗處理：
OLTP時間段，與應用系統保持同步更新（通常採用訊息機制）
批處理時間段，從應用系統中接收批次資料（通常採用ETL的方式）
DSS時間段，從資料倉儲中接收決策支援資料
由於ODS需要滿足上述不同處理型別的效能要求，導致ODS無法對任何一種型別進行最佳化，只能進行折衷考慮，這也正是ODS的技術複雜原因所在。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時46分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:46:01 -0000
當地時間：2006年2月27日(星期一) 上午9時46分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
The frequency of update and degree of integration of an ODS vary based
on the specific requirements.
Most commonly, an ODS is implemented to deliver operational reporting,
especially when neither the legacy nor more modern on-line transaction
processing (OLTP) systems provide adequate operational reports. These
reports are characterized by a limited set of fixed queries that can be
hard-wired in a reporting application.
please reference page 41 for more detail information in
innovate511
檢視個人資料
更多選項 2006年2月27日, 上午11時19分
發件人："innovate511"
日期：Sun, 26 Feb 2006 19:19:30 -0800
當地時間：2006年2月27日(星期一) 上午11時19分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
所以我對現在很多人對概念的操作深惡痛絕，搞了半天本質的東西還是沒變。IV類ODS就是我說的那種形式的DM，非要說成ODS，從結構層次來說，它已經是面向最終客戶應用，被最終ETL的，準備好的資料，在傳統定義中，應該類似DM的作用。所以無論怎麼定義，本質的東西要抓住。正如我說的，DW的資料來源來自聚合業務系統資料的ODS，這個ODS的功能就是集合的、比較乾淨的OLTP系統，而後面有定義個IV類ODS，從架構層次來說，已經變了本質，是經過ETL的，符合客戶查詢需求的。兩者一個在系統架構的前面，一個在系統架構的後面，為何要使用同一概念，標新立異？莫名其妙。
還有比較反感的定義就是什麼實時資料倉儲，無論你怎麼設計資料倉儲，始終脫離不了“歷史的”特性，何來實時之說，蒙客戶呢？現在客戶懂得可比以前多了。
innovate511
檢視個人資料
更多選項 2006年2月27日, 上午11時56分
發件人："innovate511"
日期：Sun, 26 Feb 2006 19:56:02 -0800
當地時間：2006年2月27日(星期一) 上午11時56分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
I do not have this DOC in my computer now, and it'd been written nearly
10 years, Kimball also said, Source systems are not queried in the
broad and unexpected ways.
Since DW has been developed over 20 years, concepts and methods have
been prompted too, so for whatever DOC of whoever wrote, we need
analyze first, which can solve our problem, which is the best method
for our customer.
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 下午12時00分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 04:00:14 -0000
當地時間：2006年2月27日(星期一) 下午12時00分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
innovate511過於激動了，呵呵。
我認為把專案中成熟的東西用概念“封裝”一下是走向成熟的標誌，不是包裝啊，個人觀點，就好像kimball把dw分為四個component，幾位老大都是做概念封裝嘛，有能出書而且易懂順便搞點小錢。
我想大家早就瞭解了概念的相對性，例如實時，現在的客戶不好蒙哦，但是和他們說實時也不至於讓他們如此狂躁，呵呵。
不說了，到此為止，言語如有不敬之處，innovate511休怪，非我本意，就技術問題討論討論而已。
劉慶
檢視個人資料
更多選項 2006年2月27日, 下午12時22分
發件人："劉慶"
日期：Mon, 27 Feb 2006 12:22:27 +0800
當地時間：2006年2月27日(星期一) 下午12時22分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
對於innovate提到的"第四類ODS就是之前提到的DM，並且是面向最終客戶應用的"說法，在下不贊同。
而對於dumpedjoe說得"第四類ODS是目前我們專案常見的"，也不是非常認同。
這種ODS是一種比較理想化的，但至少在我所經歷的專案中從來沒有過。但奇怪的是，在我們第一個專案中就考慮到了將分析的結果返回到ODS中，比如客戶的信用度評分、價值度評分等。然而這還不能起到作用，所以最後摒棄這種做法。這可以和電信經分裡面經常提的"閉環反饋"有些關聯吧。然而這不是技術的事，還得看最後分析的結果是否融入業務的流程裡面，例如客戶真的能夠用信用度模型來給每個客戶評分，顯然，現在還不能做到這一步。
可以說，BI系統的此類模型被認可的不多。因此，也談不上將分析結果返回到ODS，那是無用之舉。
但即便將這些分析結果返回到ODS，並不是說ODS就面向客戶應用了。
資料倉儲是幹什麼的，儲存企業活動歷史資料的，這些資料反映了企業的生產、銷售、財務、市場活動的一舉一動，而資料分析顯然也是企業活動的一種，當然也有必要記錄它們的歷史。因此，從DM中將資料返回給ODS，用"返回"這個詞有些不準確，此時，DM已經像是一個資料來源了，可以將它和ERP、CRM系統同等看待。這些分析結果，例如使用者信用度吧，同樣是用來作分析用的，可以它們進行聚類，評定A、B、C等級，作為OLAP的維度等等。
看我說的有道理吧，嘿嘿。
On 2/27/06, innovate511 wrote:
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 所以我對現在很多人對概念的操作深惡痛絕，搞了半天本質的東西還是沒變。IV類ODS就是我說的那種形式的DM，非要說成ODS，.....
> 還有比較反感的定義就是什麼實時資料倉儲，無論你怎麼設計資料倉儲，始終脫離不了"歷史的"特性，何來實時之說，蒙客戶呢？現在客戶懂得可比以前多了。
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午12時35分
發件人："innovate511"
日期：Sun, 26 Feb 2006 20:35:32 -0800
當地時間：2006年2月27日(星期一) 下午12時35分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
呵呵，我說話不是針對某個人，因為很多地方都在炒概念，我比較反感，我和一個業界朋友一樣，贊同用最樸實易懂的方法，有層次有序地給出專案方案，做好專案，這才是客戶真正想要的，而不是簡單的概念炒作。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 下午1時39分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 05:39:21 -0000
當地時間：2006年2月27日(星期一) 下午1時39分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
可以再探討一下，第四類ods是比較實際的，對於國內的客戶來說，因為種種原因，一般都不願意將dm中的分析結果分享（比返回和迴流應該要好理解些，但資料流向不直觀，呵呵）給使用ods的操作型業務人員，從技術角度來說實現這一點並不難，主要是應用物件的不同導致了很少採用該方案，而在我經歷的一些專案中，客戶確實傾向採用該方案，因為組織架構的不同，對於客戶信用度以及貢獻度等等需要進行主題聚合或跨主題聚合的指標，能夠提供給操作型業務人員作為客戶評估的一個參照是很重要和必要的，這就類似於SE中的PDCA迴圈。
我想此方案應用的差異和組織結構密切相關，組織結構和該組織在業務領域的成熟度又有關係，這應該是當前國內應用較少的一個原因。
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午4時42分
發件人："innovate511"
日期：Mon, 27 Feb 2006 00:42:19 -0800
當地時間：2006年2月27日(星期一) 下午4時42分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
anyway,
如果專案實際情況是，ODS使用的機器有寬裕的負載，而DM的機器很一般，不能給客戶足夠的支援，ok,
你可以把這部分工作拿到DOS機器上去完成，只要能準確、按時完成客戶的需求，就是好的專案。但是把這個層邏輯上歸為ODS層太為牽強，別人很可能不知道你想幹什麼。
happy
檢視個人資料
更多選項 2006年2月27日, 下午4時51分
發件人："happy"
日期：Mon, 27 Feb 2006 16:51:2 +0800
當地時間：2006年2月27日(星期一) 下午4時51分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我還是老老實實的從41頁開始重新看了一遍Kimball關於ODS的描述。看了三位關於ODS的討論，我也結合自己的經驗說兩句。
我想在專案中我們進行架構設計時，一定會考慮這麼幾個問題：
a 什麼是ODS？
b 針對現在的需求是否需要採用ODS?
c 如果用，ODS將要在架構處於什麼角色，要完成什麼功能？
第一個問題，大家都已經很瞭解了，操作型資料儲存區，是為了方便資料倉儲而存在的。ODS既然是存在於OLTP和DW之間，那麼在ODS中的資料就肯定與OLTP和DW的不同。在ODS中是儲存一個月的資料，還是二個月、三個月？是隻儲存原子資料，還是進行一些聚合的處理？這些都應該和你想要ODS完成什麼功能有關。
什麼功能沒有ODS就肯定實現不了？當然沒有了！ODS只是為了方便DW的實現而存在的，方便ETL的實現，當然也可以讓它實現一些資料的展現的功能了。innovate511肯定是從設計角度考慮，每一個層次都要有明確的功能，如果也讓ODS來實現後臺實現的資料展現功能，從設計上來看就顯得混亂。對吧？並且對於ODS身兼ETL、展現、還要加上資料更新（ODS的特點）三職，是否可以很好處理多個資料來源的轉換、更新、是否保證資料展現的準確性、以及效能如何控制等方面考慮的。從技術這個角度看，ODS確實有些任務不明確，可能由此會導致資料在ODS層上如何存在的問題。作為DW的資料中轉站，為了和多個資料來源同步，它一定要儲存最明細資料；如果要在ODS上實現資料展現（我想應該是從OLTP中分離出來的查詢），那麼為了效能一定要進行不同粒度的彙總，彙總的粒度應該也和資料倉儲中的粒度不同。是有些亂！但是我倒是不反對這麼設計。理由：我認為在ODS中實現的查詢，很來應該是存在於OLTP中的，應該與在DM中的資料分析不同。因為這是從業務角度考慮的，在實際業務中，這部分業務需求是很頻繁的（相對DM中的），所以把這些相對頻繁、簡單的查詢從複雜的關聯查詢中分離出來也是一種設計方式。
對於第四類ODS，就是劉慶說的閉環管理需求的實現。但是我有一個不明白的。為什麼DM中分析的結果要返回到ODS中呢？為什麼不返回到OLTP中呢？我們決策出來的結果，應該是為了影響實際業務的流程的，而不是給ODS操作者看的。不知這樣理解對不對？
說到實時資料倉儲（準確的說應該是near realtime），我想應該也是從業務角度出發的一種設想。innovate511老兄肯定做過很多國外的專案，國外企業本身的管理水平應該比我們高。對於如何使用資料倉儲、使用決策分析的結果、並且如何應用到企業日常的管理上應該都有很多的經驗。我想還要請innovate511老兄多給我們講一講。near realtime data warehouse就是想把從歷史資料中分析出來的結果與沒有進入到資料倉儲中的資料結合在一起使用，比如：在稅務行業，每月企業報稅就是集中在三、四天，在這幾天中資料的變化會很劇烈，沒準剛才還沒有完成任務，下一分鐘就完成。稅務的領導就是想實時看這些資料。所以我們在給客戶實現準實時資料倉儲時，採用EAI和DW相結合的方式。
ODS正如幾位所討論的，在資料倉儲架構中是非常重要的，我們這麼花精力討論是很值得的，也希望有更多的話題把我們聚到一起。:)
thanks
致
禮！
happy
2006-02-27
_ _ _ _
/_/_/_/_/
/_/_/_/_//
/_/_/_/_///
\_\_\_\_///
\_\_\_\_//
\_\_\_\_/
丁西寧
資料倉儲諮詢顧問
蓬天資訊系統（北京）有限公司
Prient Corporation
Power Realtime Intelligent ENTerprise
北京市朝陽區東大橋路8號尚都國際中心25層
電話：8610-58700800 ext 843
傳真：8610-58700800 ext 808
手機：86-13910959723
E-mail：xiningd...@prient.com
MSN:happyj...@hotmail.com
BLOG:http://java.mblogger.cn/happyjava
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午5時40分
發件人："innovate511"
日期：Mon, 27 Feb 2006 01:40:50 -0800
當地時間：2006年2月27日(星期一) 下午5時40分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
首先我要說明的是，查詢功能方面，OLTP系統架構沒有經過DW彙總過後的conform
table強，這是很顯然的，客戶的查詢不會簡單地按照OLTP系統的邏輯，一個一個得查詢，可能是一個複雜的查詢，這個時候OLTP要做的事情就是多表關聯，而我們的彙總conform
table是經過聚合的表，不需要關聯就可以滿足客戶的各種複雜的查詢需求。這是我不明白為啥要在ODS層做資料展現的原因之一。
其次，既然ODS是OLTP系統到DW之間的一個邏輯層，那就沒有經過複雜的ETL，對不？舉個很簡單的例子，某大客戶經理要查某區縣欠費100元-200元之間的屬於某大型單位的年齡在30歲以上客戶詳細資料已經最近的消費明細，那是否要在ODS中關聯好幾個表來達到他們頻繁的查詢目的呢？
我也做過很多國內專案，客戶的有的及時性需求是存在的，但是不普遍，沒有非要給出個新概念給客戶感覺這個新概念肯定ok的必要吧，除非這些客戶對資料倉儲的瞭解都比較業餘。所謂near
realtime只是針對某個很棘手的分析主題，能快速相應客戶資訊的變化，這種情況一般為單一主題的情況，完全可以和“傳統DW”分開來設計和實施（看具體情況，只是邏輯上至少要分開）。這樣的需求一般資料量不會很大，這是能快速相應，接近事實的前提，技術和設計上沒有什麼需要革新。
innovate511
檢視個人資料
（1 個使用者） 更多選項 2006年2月22日, 下午2時25分
發件人："innovate511"
日期：Tue, 21 Feb 2006 22:25:13 -0800
當地時間：2006年2月22日(星期三) 下午2時25分
主題：怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
國外大專案之所以把Architecture工作和data
model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
fact
table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
huhaifei
檢視個人資料
更多選項 2006年2月23日, 上午10時40分
發件人：huhaifei
日期：Thu, 23 Feb 2006 10:40:26 +0800
當地時間：2006年2月23日(星期四) 上午10時40分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
按照對業務和資料的理解後，如何去進行架構設計呢，一個好的合格的架構設計包括哪幾方面內容呢？大家按照各自經驗給些意見和指導。。。
2006/2/22, innovate511
> 在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
--
胡海飛
DW & BI,EAI,IRP
MSN：flyingfox1...@hotmail.com
QQ:6184771
劉慶
檢視個人資料
（1 個使用者） 更多選項 2006年2月23日, 下午1時03分
發件人："劉慶"
日期：Thu, 23 Feb 2006 13:03:19 +0800
當地時間：2006年2月23日(星期四) 下午1時03分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
架構設計究竟怎麼進行，包括什麼內容。前兩天一個朋友熬夜要完成這份文件，因為第二天就要提交，看，這本身是有問題的吧。架構設計怎麼如此倉促？它的設計對以後整個專案的體系都是影響重大。所以，我想如果僅僅是寫一份客戶需要的《總體設計文件》，ctrlc，ctrlv也就夠了。然而如果是要實在考慮如何架構一個BI系統，有必要琢磨一下。
首先看看架構設計中包括那些內容，再來反過來看看它為什麼人服務。
架構中重點是描述系統的結構，以及他們之間的關聯、互動介面。BI系統可以劃分成業務模型、後設資料、資料質量、介面平臺、報表集市、指標庫等。可以看到，這裡命名這些模組都是靜態的名詞，而不是動詞，例如業務建模、資料質量管理等，之所以如此，是因為這是在描述系統的結構而非功能。
業務模型是存放業務資料的結構，可以再細分，成ODS、DW（還可以細分）、DM等，它是支撐業務分析需求的，例如報表、儀表盤、OLAP、專題應用等。而後設資料是為整個系統資料的形態和資料流動的過程起到支撐作用，也就是說資料從源頭開始，到最終的使用者眼前，其來龍去脈，每個環節的狀態都需要掌握。而資料質量模組是為衡量資料來源質量、ETL過程處理質量提供支撐。介面平臺是處於源系統和資料倉儲系統之間的，方便明確界定雙方職責的模組。報表集市為報表應用提供支援，指標庫為績效管理需求提供支援，後兩者其實還可以歸入業務模型一類，因為它們都是服務於分析需求的。
之所以分成若干模組，是為了讓架構清晰，降低這些模組之間的耦合，如此的構成是否合理呢？還得看看這個架構面臨的需求到底是什麼，將系統的使用者分為兩大類角色：
1、 系統運營角色，他們對系統的正常執行、維護負責；
2、 業務分析角色，他們需要從這個系統得到資料分析的功能；
顯然，第二種角色的分析資料來源都都將來自業務模型模組。而第一種角色將從剩下的模組中滿足自己的需要，可以說，他們絕對不直接和業務模型這個模組打交道。在架構設計中，重點應該放在如何滿足系統管理使用者的需求上面，當然是"重點"，而非捨棄業務分析角色，畢竟在業務模型模組中，根據業務的特點、資料量的特點、分析應用的特點，來進一步細化。
這裡有個自己的理解要說明一下，架構設計應該是於具體業務關係不大的，這種架構應該是半通用的。之所以是半通用，在系統功能上面，BI專案大同小異，而在業務需求上面，架構中只需要對客戶的業務、分析需求分成幾個大類，例如按行業分業務模型，按OLAP、報表來為分析應用分類，不要太過細節。
來看看這系統運營角色的需求罷，還可以對這類角色細分成：
1、 開發設計者。之所以將開發者作為系統的使用者，是因為資料倉儲專案應該看作一個過程，而不是產品，因此在開發階段，其實其架構最重要的使用者就是開發者，當然要為之提供便利。
2、 系統管理員。系統交付之後，如何監控系統執行、發現資料質量問題、應付新的分析需求等。
那麼對於開發實施人員，他需要進行系統部署、ETL的開發除錯、質量的稽核；設計人員，需要進行模型的變更、系統調優、作系統一致性分析等；而系統管理員則需要監控ETL過程、監控系統執行、響應系統警報、介面資料管理等。這些都可以看作是用例。
面對這些用例，它們是架構設計的"需求"，如何滿足他們，並且保持良好的體系和清晰的結構。能夠易於維護，且能夠滿足日後肯定會增加的業務需求。
說了這麼多，主要要表述的觀點是：
1、架構設計主要面向系統使用者為主；
2、架構設計的內容主要包括：系統功能需求、分析需求分類；支援這兩者的後臺結構，結構的粗略劃分，以讓其內部能夠保持簡單的互動方式。
3、架構設計和詳細設計究竟如何界定的？在架構設計中，不要出現諸如"欠費賬齡"、"信用等級"這樣的業務術語。
goldenfish3
檢視個人資料
更多選項 2006年2月23日, 下午3時34分
發件人：goldenfish3
日期：Thu, 23 Feb 2006 15:34:12 +0800
當地時間：2006年2月23日(星期四) 下午3時34分
主題：Re: Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
與架構設計相關聯的是倉庫的容量規劃。包括用什麼樣的硬體、軟體、多大的儲存，滿足什麼樣的效能，在未來1年、至若干年如何擴充以適應需求增長。資料倉儲的容量規劃也可以是個單獨的話題，但在我們的實施中，它屬於架構設計部分，而且是個難點。
happy
檢視個人資料
更多選項 2006年2月23日, 下午4時53分
發件人："happy"
日期：Thu, 23 Feb 2006 16:53:1 +0800
當地時間：2006年2月23日(星期四) 下午4時53分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
想請教一個問題，增加分表指的是什麼意思？
是指由於轉換規則太複雜，把原來的一次轉換分成多次轉換，把轉換的中間資料放在臨時表中呢？
還是由於表中記錄數很大，所以按照業務需求、以及今後查詢的特點進行的分割槽處理呢？
還是在剛開始設計事實表時，根據業務的不同進行分類，把不同業務資料分別放在不同的表中呢？
謝謝
happy
- 隱藏被引用文字 -
- 顯示引用的文字 -
-----Original Message-----
>在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
>關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
>對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
>我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
>國外大專案之所以把Architecture工作和data
>model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
>fact
>table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
>由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
>在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
--------------------------
thanks！
happy
xiningd...@prient.com
2006-02-23
innovate511
檢視個人資料
更多選項 2006年2月23日, 下午6時11分
發件人："innovate511"
日期：Thu, 23 Feb 2006 02:11:50 -0800
當地時間：2006年2月23日(星期四) 下午6時11分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我也比較瞭解國內的實際情況，往往是給客戶的設計資料比較詳細，而內部的設計會粗一些，甚至的有的乾脆省略了。而客戶只關心大概的東西，看你能不能滿足他們的分析需求，或者你能給他們帶來什麼分析，具體的事情他們不需要管太多。
從業務角度講，有兩種情況，一是客戶比較盲目，沒有明確的分析需求，這個時候主要就是從現有的資料來源出發，再到前端應用的一種從底到頂的一種設計；二是客戶有明確的分析需求，這個時候既要從現有從底到頂的設計，還要看現有資料來源是否能滿足客戶特殊的分析需求，如果不能滿足，需要儘早提出，並和客戶解決資料來源的問題，從這個角度說，又是從頂到底的一種模式。
從資料角度講，如何把資料來源到前端應用的線牽起來，通俗的說是一個大的ETL過程，但是龐大的系統需要考慮ETL後的資料質量、一致性、效率等很多因素，於是這個問題需要廠商自己處理，客戶不會非常關心，所以才有很多遺留問題。
hujue1982@gmail.com
檢視個人資料
更多選項 2006年2月23日, 下午6時13分
發件人："hujue1...@gmail.com"
日期：Thu, 23 Feb 2006 02:13:32 -0800
當地時間：2006年2月23日(星期四) 下午6時13分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我想增加分表是按照業務的區別將資料分為多個事實表存放，這樣毫無關聯的資料就可以分別存放在不同的事實表中。之前我參與的一個電力決策系統，其中層次就設計分成了5個層次：ODS，臨時層，DW，聚合層，DM，這樣雖然ETL起來比較麻煩，但是非常靈活，可以方便地根據使用者需求而改變；其中事實表也是按照不同的業務分成了多個事實表
- 隱藏被引用文字 -
- 顯示引用的文字 -
happy wrote:
> 想請教一個問題，增加分表指的是什麼意思？
> 是指由於轉換規則太複雜，把原來的一次轉換分成多次轉換，把轉換的中間資料放在臨時表中呢？
> 還是由於表中記錄數很大，所以按照業務需求、以及今後查詢的特點進行的分割槽處理呢？
> 還是在剛開始設計事實表時，根據業務的不同進行分類，把不同業務資料分別放在不同的表中呢？
> 謝謝
> happy
> -----Original Message-----
> >在各個網站和論壇，一說到資料倉儲，基本都想到了"ETL※DW※OLAP"，一說到資料倉儲設計，就是按照行業規範和客戶需求調研，設計主題，然後設計對應的事實表、維表。但是，這就是真正的資料倉儲總體設計麼？
> >關於上面說的主題設計，以及前端展現，這是給客戶的終端使用者看的，他們只關心你能給他們帶來什麼，是否滿足他們的報表、查詢和分析需求。但是對於廠商自己來說，需要清楚自己實施專案時要幹什麼，就像複雜的ETL開發需要後設資料去規範和指引一樣，專案的資料流邏輯，是否有設計規範。
> >對於一個大型資料倉儲專案來說，如果粗獷地設計為ODS，DW,DM三大層次，那麼在具體實施的時候，可能會因為資料量大，需要過渡層，於是隨手在DW層增加些分表，到DM後，前端應用覺得查詢太慢，於是也增加一些分表，再彙總。這樣就陷入了無休止的維護和盲目地修改中。據我所知，能知道增加分表作為過渡層，已經算是不錯的，有的專案看著ETL太慢，只是找尋資料庫和ETL程式碼的原因，於是經常有工程師到處問，幾億的資料量如何增加效率呢，資料庫還需要什麼最佳化呢？其實即便你除了2億紀錄的那個表，那麼隨著客戶資訊的增加，以後3億、4億紀錄你能按時ETL完成？
> >我看到很多朋友，包括比較資深的朋友，一提到那種架構就搖頭，太空礦了，沒法入手，也沒法討論。其實很多專案開發的時候，分了一些事實表分表，我看有的電信行業架構設計還把主題分為經營分析和大客戶兩個業務層，這不也是一種設計的進步麼？
> >國外大專案之所以把Architecture工作和data
> >model的工作分開，就是因為兩者完全可以獨立，一個優秀的架構設計，可以應用在不同行業，而不是做一個行業的專案，設計一個架構。可能有人要問，不同客戶的資料量和業務複雜程度都不一樣，你如何規範？那麼一個合格的架構設計，應該是分層的，比如，首先分出ODS,DW,DM，標出ODS接受哪些資料來源，ODS如何把資料流向DW，DW如何流向DM，具體點可以把一些邏輯上的資料庫標上，就像後設資料管理圖一樣。第二層就是各個邏輯層內部設計，ODS一個或者數個資料庫，對應到哪些DW對應的邏輯資料庫，DW在處理ETL過程中，需要幾個過渡層，如果資料量不大的話，只需要一個confirm層ETL到confirm
> >fact
> >table足夠，如果資料量大，看來還需要一個過渡層才能流向DM層。DM層是面向各個前端應用的邏輯層，大型專案一般都是DW的一個事實表對應多個DM層的事實表。第三層設計是把業務邏輯融入架構中，說明各個邏輯層中業務邏輯的變化。
> >由此可見，資料倉儲專案並不是完全是純粹的業務驅動，也不是完全的資料驅動，應該是兩者同時驅動的MATRIX架構。一個合格的資料倉儲架構設計，不但要清除業務流程，還應該清楚資料流程，光有後設資料驅動ETL開發也不能讓資料倉儲更有條理。當然一個專案要實施很合格，光靠架構也不夠，具體的開發和測試這樣的具體工作也很關鍵，不在此次討論範圍。
> >在這只是拋磚引玉，只是提醒下，資料倉儲架構設計，並不是空曠，虛無的東西，也不只是業務的驅動和主題的劃分。"ETL※DW※OLAP"只是些表面的東西，作為設計者，應該需要知道內部更多，更深入的東西。
> --------------------------
> thanks！
> happy
> xiningd...@prient.com
> 2006-02-23
innovate511
檢視個人資料
更多選項 2006年2月23日, 下午8時03分
發件人："innovate511"
日期：Thu, 23 Feb 2006 04:03:10 -0800
當地時間：2006年2月23日(星期四) 下午8時03分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
所以分表，就是同一個資料來源，本來可以放在一個事實表，但由於資料量太大，或者業務太複雜，一個事實表很難包含所有主題的資訊，於是考慮按照某種業務需求分成多個相似主題的事實表。這個沒有統一的定論，需要按實際需求設計。比如一個主題分為日報、週報、月報等不同的分析週期，那麼可以分為xx_day_fact,xx_wkly_fact,month_wkly_fact；如果使用者經常察看的日分析是2個月的資料，那麼你的當前事實表只存2個月的資料，其他的放在xx_his_fact中，再久的放到磁帶庫（比如2年前的）。類似的分類分表的方法很多，就不一一介紹了。
而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
fact
table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
劉慶
檢視個人資料
更多選項 2006年2月24日, 下午12時11分
發件人："劉慶"
日期：Fri, 24 Feb 2006 12:11:09 +0800
當地時間：2006年2月24日(星期五) 下午12時11分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
這個confirm table，一直沒整明白是幹啥的。按照Innovate的描述，它是一種"聚合一個涵蓋豐富資訊的事實表"。如此，我理解的confirm
table，恐怕就是那種主題表，例如使用者資訊表（一系列），這些表的粒度是其描述的實體決定的，針對這種實體的彙總資訊表。常見的實體包括使用者、客戶、渠道、產品、資源、競爭對手等。
其實業務資料模型設計，區分成ODS、DW和DM，他的*架構*目的有二：
1、為了能夠滿足使用者可能變化的分析需求；
2、要不就是為了查詢效能的需求。
confirm
table概念的提出總歸是要解決這兩個問題或其中一個吧。如果是上面理解的那種，目前很多公司的模型設計已經有這樣的分層，直接從事實表（ODS表）建立一個若干維度若干度量的彙總表，那是很早以前的做法了。
至於"分表"這種叫法，覺著是個比較含糊的術語。在專案實施中，存在一種現象。為了滿足使用者新需求的時候，或提高效能，去修改模型，可能就需要"分表"，但通常會出現諸如tmp_xxx的臨時表，甚至是以設計者名字命名的表，將他們當作臨時表，但很可能他們並非臨時的，會融入到實際的流程當中，導致混亂。這是因為在架構的時候缺乏概念設計的結果。整個系統的架構應該能夠形成一個概念體系，底層物理的每個表，每個操作都能夠歸屬到某個邏輯或是概念上。
例如增加一個臨時的彙總表，那麼就嚴格規定，此表不能放入常規的ETL流程當中，因為那樣會導致概念混亂。如果按照週期分表，同樣在上層應該是有"不同週期主題表"的概念。
所謂概念，其實就是給個名份。資料倉儲中分那麼多層次，ods、dw不都是資料倒來倒去嗎，甚至都可以叫它們作"中間表"，可這不是一個清晰的概念，於是就產生了細分。就像你叫一個人，"哎，女人"，這多不尊敬人，如果叫"小麗啊"，人家就愛聽了。
On 2/23/06, innovate511
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
> 而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
> ...
happy
檢視個人資料
更多選項 2006年2月24日, 下午12時54分
發件人："happy"
日期：Fri, 24 Feb 2006 12:54:28 +0800
當地時間：2006年2月24日(星期五) 下午12時54分
主題：Re: Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
謝謝innovate511對我問題的解答，還是有幾個問題再請教一下：
>分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，>中間的資料就斷了，資料質量無法保證。
innovate兄提到如果中間資料按照上面的操作是非常不規範的，因為在ETL過程中斷時會產生資料質量的問題。這一點我還不是很明白。因為我在ETL了的過程中，有一些資料質量的控制方法。如果ETL過程中斷，我會在日誌中記錄中斷的情況，包括涉及哪些資料，在哪一環節出現錯誤。這些資料是不會再進入下面的環節的。我會透過對日誌的分析來重新對這些資料進行ETL，並修改ETL的結果。我想這樣是不是可以解決資料質量的問題呢？
我理解的中間資料不是按照業務來區分的，它只是為了某些原因，比如ETL的效能最佳化、更好維護等等才採取的方式，不知道這樣方式是否確實存在資料不規範的隱患呢？還請innovate兄幫我再分析一下吧。
>而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
>fact
>table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
>tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
查了一下，沒有找到confirm fact table的資料，希望innovate兄再多解釋一下。如果在設計資料倉儲時做到一個資料倉儲的事實表可以和多個資料集市的事實表包含1:n的關係的話，那當然好了。不知如何在實際中滿足這樣的設計？是否要全面瞭解企業的需求，對業務理解很深才行啊？我們現在其實很多時候都在根據一堆業務指標來構造資料倉儲的事實表，構造完後，如果有新的需求、新的指標，就會在原來的事實表上修改或者新建一個事實表。請問如何避免這樣的現象？
謝謝
happy
-----Original Message-----
>分表目前在很多專案中已經使用，只是還是比較隨意，沒有在總體架構設計中作為一個層出現。
>而且在實際專案中，分表和你說的中間資料是兩回事，而且規範的資料倉儲不會把任務流程中的資料放在臨時表中，那是非常不規範的，因為如果一旦有問題，中間的資料就斷了，資料質量無法保證。
>所以分表，就是同一個資料來源，本來可以放在一個事實表，但由於資料量太大，或者業務太複雜，一個事實表很難包含所有主題的資訊，於是考慮按照某種業務需求分成多個相似主題的事實表。這個沒有統一的定論，需要按實際需求設計。比如一個主題分為日報、週報、月報等不同的分析週期，那麼可以分為xx_day_fact,xx_wkly_fact,month_wkly_fact；如果使用者經常察看的日分析是2個月的資料，那麼你的當前事實表只存2個月的資料，其他的放在xx_his_fact中，再久的放到磁帶庫（比如2年前的）。類似的分類分表的方法很多，就不一一介紹了。
>而所謂的中間資料，也並不是簡單的彙總，以前的一些專案，很多根本沒用國外很成熟的概念confirm
>fact
>table聚合一個涵蓋豐富資訊的事實表，而直接彙總，是一個很典型的案例。一般標準點的專案會把confirm
>tables作為一個層，出現在總體架構設計中，成為前端應用匯總資訊的重要通道。
--------------------------
thanks！
happy
xiningd...@prient.com
2006-02-24
innovate511
檢視個人資料
更多選項 2006年2月24日, 下午2時30分
發件人："innovate511"
日期：Thu, 23 Feb 2006 22:30:51 -0800
當地時間：2006年2月24日(星期五) 下午2時30分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我以前就說過，有好多人想在ODS層做所謂的彙總表作為前端查詢的做法是非常不明智和不科學的。資料倉儲是個工程，你想怎麼做都可以一定程度地實現客戶的需求，所以才會出現很多廠商想當然地去做，因為他們覺得那樣也能滿足客戶的需求，但是他們沒有搞清楚，什麼的方式才是最佳的。
大家很多都看過Inmon和Kimball的書，他們都或多或少提到過confirm
table的概念和思路，就像劉慶說的，confirm
table的出現的主要目的就是能夠滿足使用者可能變化的分析需求和查詢效能的需求，增加資料倉儲的靈活性、穩定性和高效性。至於為啥ODS層用作前端查詢不好，我也大概說過，ODS層的作用應是承上（資料來源）啟下（DW）的作用，如果你非要給個介面給前端查詢，還做個類似confirm
table的事實表，那不是功能和DW、DM有重疊了？客戶訪問要大大增加系統壓力，作為資料前沿的介面，系統壓力也很大，你如果保證高效？既然ODS到DW還可能經過1到多次的ETL，你怎麼能保證客戶最終查詢和分析的資料一致性？
我不知道“建立一個若干維度若干度量的彙總表”是建立一個彙總表，還是聚集事實表，這是兩個不同的概念。confirm
table既聚集事實表是指經過了所有設計好的ETL後，再把相似的事實表聚集在一起，也就是他還是事實表，不是經過sum,count的彙總表。
說到這裡，不得不說分表了。前面說到了ETL完成後相關主題的事實表要聚集到一個事實表裡，那麼意味著前面我們已經做過拆分，這就是所謂的一個大主題的事實表拆分成分表了。我們這裡說的分表，和劉慶提到的很多專案，包括大型專案中的tmp表有類似的作用，但是並不是我做到專案做到一半，突然發現資料量太大，得找個分表分散ETL壓力，而是在開始設計中設計好的一個步驟，一個層，要不然為啥總體設計要一個有經驗有理論的人設計，隨便找個做過大型專案ETL的人設計不就完了？
再細說的分表的命名，如果資深的DW人，一看到分表基本都是tmp_xxx命名的話，只能說明這個專案是“修補型專案”，也就是走一步看一步，發現問題，我再改建模，我再改ETL，後設資料管理也得修改。之所以後來專案都很重視後設資料管理，是啥原因？沒有後設資料管理，ETL不照做麼？因為大家都知道後設資料有效的管理，能讓你“站得高，看得遠”，能把握ETL全域性。那麼一個“修補型專案”好，還是你前期架構設計好了，按照設計開發就是好呢？一看就明白了，這也是我最近各大論壇和網站提到的架構設計的重要性，我想我不提出來，也有人出來，就像當年很多人提出後設資料管理的重要性一樣。
innovate511
檢視個人資料
更多選項 2006年2月25日, 上午1時43分
發件人："innovate511"
日期：Fri, 24 Feb 2006 09:43:13 -0800
當地時間：2006年2月25日(星期六) 上午1時43分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
to happy
不好意思，我有個事情沒有澄清清楚，分表可以分為業務分表，和過渡分表。你說的那種情況基本屬於過渡分表，目的就是為了分散ETL壓力，而最後需要彙總成一個事實表。
對於過渡分表，很多國內公司使用tmp_xx，我覺得很遺憾，且不說感覺這是個臨時表，就命名來說，專案裡其他人可能不知道這個表是幹嘛的。最主要的是，過渡分表並不是tmp的，應該屬於專案的一個重要環節，它們在完成ETL使命後需要重新回到一起，最後到所謂的confirm
fact table裡面。
再說一下業務分表，所謂業務分表，並不是我們想怎麼分就怎麼分，而是根據實際情況。比如客戶有固定的日、周、月、季、年等多個週期，那麼週資料完全可以自己有一個事實表、年資料也可以。同樣，舉個簡單例子，大客戶的分析維和普通客戶的維有很多不同之處，但是分析的指標卻有很多共同點，而且如果調研結果是大客戶資訊全部來自大客戶系統的話，難道你不覺得大客戶和普通客戶的事實表分開，是非常合理的麼？領導最後可能需要一個總體客戶的分析，這個時候你在完成所有ETL後，可以再彙總到一個confirm的聚集事實表裡，這樣既方便管理、效率高、資料質量有保障，而且方便安全管理，因為客戶很可能不希望某些部門的員工不能看大客戶的資訊，大客戶部門只能看大客戶資訊，而老總都能看。
至於confirm table的相關定義和資料，Kimball的Data warehouse
life cycle
toolkit裡邊就有。而且我以前在文章中也舉個具體的例子，如何實現分表後又能高效聚集到confirm
fact table中。
剛才我說到的這些設計細節，專案的Architecture或者consultant應該可以透過詳細調研後預測這些問題，然後設計出架構來，然後data
modeler根據相關架構設計去建模。而不是上面提到的，專案遇到困難了，於是需要修改相關設計，作出很多臨時表來應付。作為設計者最好是很資深的人，或者有更資深的顧問幫助設計，不說預測好幾年情況，能預測3-5年客戶應該就很滿足了，但是如果專案才開始實施幾個月就發現不對，那預測了什麼呢？
dumpedjoe
檢視個人資料
更多選項 2006年2月25日, 下午1時39分
發件人："dumpedjoe"
日期：Sat, 25 Feb 2006 05:39:09 -0000
當地時間：2006年2月25日(星期六) 下午1時39分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
在專案（不僅僅是dw）中，架構設計師能夠根據自身的技能和經驗對於今後要面對的效能、資料質量、可擴充套件性等要求給出相應的應對方法是一個基本要求，問題是好的資料倉儲架構是什麼樣的，針對不同的系統狀況和業務需要，哪些是作為標準元件必需引入的，哪些是可以根據具體情況進行裁剪或合併的，我想這也是胡海飛希望大家能夠深入探討的，當然inmon和kimball以及其它各位老大早就給出了他們的答案，在這裡我們對具體細節討論一下，比如分表、confirm
fact table、ods等等。
在這裡說說我對ods的理解，和innovate511
略有不同，作為可選元件，ods是dw的一個補充，對於使用者明確的查詢和統計需求，為了減輕源系統的壓力，引入ods，在其中針對確定的需求進行聚合，提供給前端操作型業務人員進行查詢，dw在一定程度上能夠滿足這樣的需求，但是分析型業務人員和操作性型業務人員的目的完全不同，雖然前者偶爾會訪問到操作型人員經常訪問的資料。
源系統
/
明確的查詢需求 分析需求
/
Ods dw or dm
/
操作型業務人員 分析人員
對於無批次查詢需求的專案來說，ods就沒有必要，也不能成為某一個層次，更不能承上啟下。
至於分表命名為tmp_***，我認為只要它是在設計階段就明確了應用在哪個方法上，它就沒有問題，只能說命名方法不好，如果在設計階段未定義，這樣搞才是一個"修補型專案"。
對於dw專案，架構設計對於專案的影響相對其他專案來說要大一些，除了已經討論的，大家是否有其他的應對，或者我們可以提煉一下，形成一個當前的最佳實踐應用到後續專案中。即使沒有結果也是很好的交流。
innovate511
檢視個人資料
更多選項 2006年2月25日, 下午2時54分
發件人："innovate511"
日期：Fri, 24 Feb 2006 22:54:47 -0800
當地時間：2006年2月25日(星期六) 下午2時54分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
首先，架構設計的重要性，是針對專案越龐大（包括資料量和業務複雜度），越是重要。舉個很簡單的例子，我做過得最小的專案，就是某地級市電信運營商的競爭對手分析，就那麼一個主題，資料量也不大，需要啥架構呢？只要業務明確，你想咋做都可以，前端報表和OLAP都做得不錯，客戶就能滿意。所以我前面的講的假設，基本是大專案基礎上。
那麼我說的情況，都是客戶有批次查詢、隨時對各個主題查詢的可能。在大專案中，Operational
Data Store，從定義來講，結構還是OLTP，所以被認為“The
ODS stage is sometimes skipped if it is a replication of the
operational
databases”，那麼如果資料來源很複雜，有多個資料來源的話，將是必須的。
有一點我要說明的是，如果有的ODS層也有事實表什麼的拿給前端查詢，就和本身的定義不符，已經是DW的概念，作為前端應用，那是data
mart的責任。所以我的建議是，不要把查詢看作是獨立的應用，也不要把ODS輕易忽略掉。
我剛才說的重點，並不是他命名，命名只是個表面現象，因為既然專案需要一箇中間層來過渡，為啥設計的時候沒有考慮到呢，非要臨到應用才臨時搞個臨時表過渡？
DW專案的專案質量保證還有個重點，就是開發和測試，我可以另外開一個話題討論。至於也是至關重要的客戶交流、調研，做個N多專案的人都有經驗，我就不另外開話題了。
dumpedjoe
檢視個人資料
更多選項 2006年2月26日, 下午1時04分
發件人："dumpedjoe"
日期：Sun, 26 Feb 2006 05:04:31 -0000
當地時間：2006年2月26日(星期日) 下午1時04分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
主題少，資料量小，業務明確就不要架構我不能認同，好的架構是對後續會發生的常見問題有好的應對，難道等該專案結束後，客戶覺得不錯，再加個主題，資料量增長了以後我們再引入架構重新搞一次？這個暫且不談，還是說說ODS，再次強調一下“明確”，如果查詢需求明確，用data
mart來應對不是好的方法，data
mart對於查詢應該是集中在分析型業務人員在分析之後，對於分析結果可能產生的查詢要求，類似CIF中提到discover（是不是這角色不確定，呵呵），比如某人某天發現怎麼某客戶的貢獻度比上月差很多啊，鑽取到原子資料來看看，而ODS應對的是習慣性的查詢要求，每天都要做，一做一大批，業務系統和dm能做啊，可是對於正常響應業務或分析操作就有影響。
我很認同查詢不是獨立的應用，在bi系統中，分析和查詢的需求都會有，所以我們才不能一股腦將查詢需求丟給dm，ods的必要性也在於此。而且在ods中圍繞“明確”的需求在源業務表上作聚合沒問題，什麼都不幹搞它做什麼，與資料來源的多少無關，它也不是事實表。
大家對海量資料的情況下，使用何種架構能夠保證裝載和轉換的效能聊聊吧，：）。
innovate511
檢視個人資料
更多選項 2006年2月26日, 下午1時46分
發件人："innovate511"
日期：Sat, 25 Feb 2006 21:46:45 -0800
當地時間：2006年2月26日(星期日) 下午1時46分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
樓上有沒有想過，dm獨立一個邏輯塊出來，供前端查詢？我前面提到過，DM可以是很豐富的一大塊，既可以豐富DW的事實表，也可以豐富出來供前面所有應用使用，再複雜的應用，最好的辦法就是分層或者分模組。目前我見過得專案中，這種方式應該是最好的，還有其他疑問麼？
之所以最佳的辦法是在DM這一層供客戶查詢，就是考慮到了客戶複雜的，批次的查詢需求。在ODS查詢的話，客戶需要一個複雜的查詢，難道你需要關聯好多大表，如果實在太難，你就對客戶說，不好意思，邏輯太複雜，實現不了？客戶肯定就會納悶，既然你能實現複雜的報表和OLAP分析，為啥我複雜的查詢不行呢？
還有，ODS層在絕大多數專案中，是供DW的資料來源，不知道你把ODS作為查詢資料來源後，DW是否透過直接透過各個資料來源直接裝載呢，還是ODS也擔當這個功能呢？
至於如何保證裝載和轉換的效能，在設計中，設計者總體思路是估量專案的資料量和業務量，然後就可以定論如何分層，分表如何分。kimball他們在書中只是寫了大概要有staging
area,
conform層等，其實現實的大型專案中，還可以多加一些過渡層，以保證效率。因為不同專案選擇ETL方式不同，有的選擇使用工具，有的選擇自己開發。如果自己開發的話，所有轉換都在儲存過程中進行，對於海量資料來說不是最好的辦法，因為佔用資料庫的資源太大。建議把資料拿到c/java等程式裡轉換後，再load回去，減少資料庫負擔。這裡說到了部分軟體工程的問題了。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時12分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:12:42 -0000
當地時間：2006年2月27日(星期一) 上午9時12分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
目前我見過得專案中，這種方式應該是最好的，還有其他疑問麼？
- :-))))
客戶複雜的，批次的查詢需求。在ODS查詢的話，客戶需要一個複雜的查詢，難道你需要關聯好多大表,如果實在太難，你就對客戶說，不好意思，邏輯太複雜，實現不了？
- 明確？聚合！
ODS層在絕大多數專案中，是供DW的資料來源 - ???
如果自己開發的話，所有轉換都在儲存過程中進行，對於海量資料來說不是最好的辦法，因為佔用資料庫的資源太大。建議把資料拿到c/java等程式裡轉換後，再load回去，減少資料庫負擔。這裡說到了部分軟體工程的問題了。-
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時23分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:23:33 -0000
當地時間：2006年2月27日(星期一) 上午9時23分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
CIF有專門的章節描述ODS,ODS有以下特點：
面向主題的
整合的
易變的
明細的
反映當前資料值的
ODS是企業資料架構中最為複雜的一種形態，既要滿足資料事務操作要求，又要滿足資料分析要求,中國電信的CTG-MBOSS規劃中對ODS有比較明確的要求，但在CTG-MBOSS規範中，ODS也做了一定的變更處理。在雲南電信以及上海電信的ODS系統建設中（雲南電信ODS已經初驗，上海電信的ODS算是上線了），ODS的定位就比較模糊，其主要功能是給資料倉儲提供資料，但大致來講，ODS有以下四種型別：
I
類ODS，與應用系統的資料延遲為1~2秒，實時或近似實時
II 類ODS，與應用系統的資料延遲為2~4小時
III 類ODS，與應用系統的資料延遲為12~24小時
IV 類ODS，資料倉儲中部分決策分析資料迴流至ODS中
目前應用的比較多的是IV
類ODS，因為一旦將決策分析結果載入到ODS中，重要決策資訊的高效能聯機支援將成為可能，舉例如下：
客戶細分與評價
銀行客戶貸款
ODS與資料倉儲的重要區別如下：
ODS只儲存明細資料
ODS中儲存的資料一般不超過一個月
ODS支援事務更新操作
在ODS中存在3種不同的時間窗處理：
OLTP時間段，與應用系統保持同步更新（通常採用訊息機制）
批處理時間段，從應用系統中接收批次資料（通常採用ETL的方式）
DSS時間段，從資料倉儲中接收決策支援資料
由於ODS需要滿足上述不同處理型別的效能要求，導致ODS無法對任何一種型別進行最佳化，只能進行折衷考慮，這也正是ODS的技術複雜原因所在。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 上午9時46分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 01:46:01 -0000
當地時間：2006年2月27日(星期一) 上午9時46分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
The frequency of update and degree of integration of an ODS vary based
on the specific requirements.
Most commonly, an ODS is implemented to deliver operational reporting,
especially when neither the legacy nor more modern on-line transaction
processing (OLTP) systems provide adequate operational reports. These
reports are characterized by a limited set of fixed queries that can be
hard-wired in a reporting application.
please reference page 41 for more detail information in
innovate511
檢視個人資料
更多選項 2006年2月27日, 上午11時19分
發件人："innovate511"
日期：Sun, 26 Feb 2006 19:19:30 -0800
當地時間：2006年2月27日(星期一) 上午11時19分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
所以我對現在很多人對概念的操作深惡痛絕，搞了半天本質的東西還是沒變。IV類ODS就是我說的那種形式的DM，非要說成ODS，從結構層次來說，它已經是面向最終客戶應用，被最終ETL的，準備好的資料，在傳統定義中，應該類似DM的作用。所以無論怎麼定義，本質的東西要抓住。正如我說的，DW的資料來源來自聚合業務系統資料的ODS，這個ODS的功能就是集合的、比較乾淨的OLTP系統，而後面有定義個IV類ODS，從架構層次來說，已經變了本質，是經過ETL的，符合客戶查詢需求的。兩者一個在系統架構的前面，一個在系統架構的後面，為何要使用同一概念，標新立異？莫名其妙。
還有比較反感的定義就是什麼實時資料倉儲，無論你怎麼設計資料倉儲，始終脫離不了“歷史的”特性，何來實時之說，蒙客戶呢？現在客戶懂得可比以前多了。
innovate511
檢視個人資料
更多選項 2006年2月27日, 上午11時56分
發件人："innovate511"
日期：Sun, 26 Feb 2006 19:56:02 -0800
當地時間：2006年2月27日(星期一) 上午11時56分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
I do not have this DOC in my computer now, and it'd been written nearly
10 years, Kimball also said, Source systems are not queried in the
broad and unexpected ways.
Since DW has been developed over 20 years, concepts and methods have
been prompted too, so for whatever DOC of whoever wrote, we need
analyze first, which can solve our problem, which is the best method
for our customer.
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 下午12時00分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 04:00:14 -0000
當地時間：2006年2月27日(星期一) 下午12時00分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
innovate511過於激動了，呵呵。
我認為把專案中成熟的東西用概念“封裝”一下是走向成熟的標誌，不是包裝啊，個人觀點，就好像kimball把dw分為四個component，幾位老大都是做概念封裝嘛，有能出書而且易懂順便搞點小錢。
我想大家早就瞭解了概念的相對性，例如實時，現在的客戶不好蒙哦，但是和他們說實時也不至於讓他們如此狂躁，呵呵。
不說了，到此為止，言語如有不敬之處，innovate511休怪，非我本意，就技術問題討論討論而已。
劉慶
檢視個人資料
更多選項 2006年2月27日, 下午12時22分
發件人："劉慶"
日期：Mon, 27 Feb 2006 12:22:27 +0800
當地時間：2006年2月27日(星期一) 下午12時22分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
對於innovate提到的"第四類ODS就是之前提到的DM，並且是面向最終客戶應用的"說法，在下不贊同。
而對於dumpedjoe說得"第四類ODS是目前我們專案常見的"，也不是非常認同。
這種ODS是一種比較理想化的，但至少在我所經歷的專案中從來沒有過。但奇怪的是，在我們第一個專案中就考慮到了將分析的結果返回到ODS中，比如客戶的信用度評分、價值度評分等。然而這還不能起到作用，所以最後摒棄這種做法。這可以和電信經分裡面經常提的"閉環反饋"有些關聯吧。然而這不是技術的事，還得看最後分析的結果是否融入業務的流程裡面，例如客戶真的能夠用信用度模型來給每個客戶評分，顯然，現在還不能做到這一步。
可以說，BI系統的此類模型被認可的不多。因此，也談不上將分析結果返回到ODS，那是無用之舉。
但即便將這些分析結果返回到ODS，並不是說ODS就面向客戶應用了。
資料倉儲是幹什麼的，儲存企業活動歷史資料的，這些資料反映了企業的生產、銷售、財務、市場活動的一舉一動，而資料分析顯然也是企業活動的一種，當然也有必要記錄它們的歷史。因此，從DM中將資料返回給ODS，用"返回"這個詞有些不準確，此時，DM已經像是一個資料來源了，可以將它和ERP、CRM系統同等看待。這些分析結果，例如使用者信用度吧，同樣是用來作分析用的，可以它們進行聚類，評定A、B、C等級，作為OLAP的維度等等。
看我說的有道理吧，嘿嘿。
On 2/27/06, innovate511
- 隱藏被引用文字 -
- 顯示引用的文字 -
> 所以我對現在很多人對概念的操作深惡痛絕，搞了半天本質的東西還是沒變。IV類ODS就是我說的那種形式的DM，非要說成ODS，.....
> 還有比較反感的定義就是什麼實時資料倉儲，無論你怎麼設計資料倉儲，始終脫離不了"歷史的"特性，何來實時之說，蒙客戶呢？現在客戶懂得可比以前多了。
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午12時35分
發件人："innovate511"
日期：Sun, 26 Feb 2006 20:35:32 -0800
當地時間：2006年2月27日(星期一) 下午12時35分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
呵呵，我說話不是針對某個人，因為很多地方都在炒概念，我比較反感，我和一個業界朋友一樣，贊同用最樸實易懂的方法，有層次有序地給出專案方案，做好專案，這才是客戶真正想要的，而不是簡單的概念炒作。
dumpedjoe
檢視個人資料
更多選項 2006年2月27日, 下午1時39分
發件人："dumpedjoe"
日期：Mon, 27 Feb 2006 05:39:21 -0000
當地時間：2006年2月27日(星期一) 下午1時39分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
可以再探討一下，第四類ods是比較實際的，對於國內的客戶來說，因為種種原因，一般都不願意將dm中的分析結果分享（比返回和迴流應該要好理解些，但資料流向不直觀，呵呵）給使用ods的操作型業務人員，從技術角度來說實現這一點並不難，主要是應用物件的不同導致了很少採用該方案，而在我經歷的一些專案中，客戶確實傾向採用該方案，因為組織架構的不同，對於客戶信用度以及貢獻度等等需要進行主題聚合或跨主題聚合的指標，能夠提供給操作型業務人員作為客戶評估的一個參照是很重要和必要的，這就類似於SE中的PDCA迴圈。
我想此方案應用的差異和組織結構密切相關，組織結構和該組織在業務領域的成熟度又有關係，這應該是當前國內應用較少的一個原因。
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午4時42分
發件人："innovate511"
日期：Mon, 27 Feb 2006 00:42:19 -0800
當地時間：2006年2月27日(星期一) 下午4時42分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
anyway,
如果專案實際情況是，ODS使用的機器有寬裕的負載，而DM的機器很一般，不能給客戶足夠的支援，ok,
你可以把這部分工作拿到DOS機器上去完成，只要能準確、按時完成客戶的需求，就是好的專案。但是把這個層邏輯上歸為ODS層太為牽強，別人很可能不知道你想幹什麼。
happy
檢視個人資料
更多選項 2006年2月27日, 下午4時51分
發件人："happy"
日期：Mon, 27 Feb 2006 16:51:2 +0800
當地時間：2006年2月27日(星期一) 下午4時51分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
我還是老老實實的從41頁開始重新看了一遍Kimball關於ODS的描述。看了三位關於ODS的討論，我也結合自己的經驗說兩句。
我想在專案中我們進行架構設計時，一定會考慮這麼幾個問題：
a 什麼是ODS？
b 針對現在的需求是否需要採用ODS?
c 如果用，ODS將要在架構處於什麼角色，要完成什麼功能？
第一個問題，大家都已經很瞭解了，操作型資料儲存區，是為了方便資料倉儲而存在的。ODS既然是存在於OLTP和DW之間，那麼在ODS中的資料就肯定與OLTP和DW的不同。在ODS中是儲存一個月的資料，還是二個月、三個月？是隻儲存原子資料，還是進行一些聚合的處理？這些都應該和你想要ODS完成什麼功能有關。
什麼功能沒有ODS就肯定實現不了？當然沒有了！ODS只是為了方便DW的實現而存在的，方便ETL的實現，當然也可以讓它實現一些資料的展現的功能了。innovate511肯定是從設計角度考慮，每一個層次都要有明確的功能，如果也讓ODS來實現後臺實現的資料展現功能，從設計上來看就顯得混亂。對吧？並且對於ODS身兼ETL、展現、還要加上資料更新（ODS的特點）三職，是否可以很好處理多個資料來源的轉換、更新、是否保證資料展現的準確性、以及效能如何控制等方面考慮的。從技術這個角度看，ODS確實有些任務不明確，可能由此會導致資料在ODS層上如何存在的問題。作為DW的資料中轉站，為了和多個資料來源同步，它一定要儲存最明細資料；如果要在ODS上實現資料展現（我想應該是從OLTP中分離出來的查詢），那麼為了效能一定要進行不同粒度的彙總，彙總的粒度應該也和資料倉儲中的粒度不同。是有些亂！但是我倒是不反對這麼設計。理由：我認為在ODS中實現的查詢，很來應該是存在於OLTP中的，應該與在DM中的資料分析不同。因為這是從業務角度考慮的，在實際業務中，這部分業務需求是很頻繁的（相對DM中的），所以把這些相對頻繁、簡單的查詢從複雜的關聯查詢中分離出來也是一種設計方式。
對於第四類ODS，就是劉慶說的閉環管理需求的實現。但是我有一個不明白的。為什麼DM中分析的結果要返回到ODS中呢？為什麼不返回到OLTP中呢？我們決策出來的結果，應該是為了影響實際業務的流程的，而不是給ODS操作者看的。不知這樣理解對不對？
說到實時資料倉儲（準確的說應該是near realtime），我想應該也是從業務角度出發的一種設想。innovate511老兄肯定做過很多國外的專案，國外企業本身的管理水平應該比我們高。對於如何使用資料倉儲、使用決策分析的結果、並且如何應用到企業日常的管理上應該都有很多的經驗。我想還要請innovate511老兄多給我們講一講。near realtime data warehouse就是想把從歷史資料中分析出來的結果與沒有進入到資料倉儲中的資料結合在一起使用，比如：在稅務行業，每月企業報稅就是集中在三、四天，在這幾天中資料的變化會很劇烈，沒準剛才還沒有完成任務，下一分鐘就完成。稅務的領導就是想實時看這些資料。所以我們在給客戶實現準實時資料倉儲時，採用EAI和DW相結合的方式。
ODS正如幾位所討論的，在資料倉儲架構中是非常重要的，我們這麼花精力討論是很值得的，也希望有更多的話題把我們聚到一起。:)
thanks
致
禮！
happy
2006-02-27
_ _ _ _
/_/_/_/_/
/_/_/_/_//
/_/_/_/_///
\_\_\_\_///
\_\_\_\_//
\_\_\_\_/
丁西寧
資料倉儲諮詢顧問
蓬天資訊系統（北京）有限公司
Prient Corporation
Power Realtime Intelligent ENTerprise
北京市朝陽區東大橋路8號尚都國際中心25層
電話：8610-58700800 ext 843
傳真：8610-58700800 ext 808
手機：86-13910959723
E-mail：xiningd...@prient.com
MSN:happyj...@hotmail.com
BLOG:http://java.mblogger.cn/happyjava
innovate511
檢視個人資料
更多選項 2006年2月27日, 下午5時40分
發件人："innovate511"
日期：Mon, 27 Feb 2006 01:40:50 -0800
當地時間：2006年2月27日(星期一) 下午5時40分
主題：Re: 怎樣的架構設計才是真正的資料倉儲架構（原創）
答覆作者 | 轉發 | 列印 | 單個帖子 | 顯示原始郵件 | 報告此帖 | 查詢此作者的帖子
首先我要說明的是，查詢功能方面，OLTP系統架構沒有經過DW彙總過後的conform
table強，這是很顯然的，客戶的查詢不會簡單地按照OLTP系統的邏輯，一個一個得查詢，可能是一個複雜的查詢，這個時候OLTP要做的事情就是多表關聯，而我們的彙總conform
table是經過聚合的表，不需要關聯就可以滿足客戶的各種複雜的查詢需求。這是我不明白為啥要在ODS層做資料展現的原因之一。
其次，既然ODS是OLTP系統到DW之間的一個邏輯層，那就沒有經過複雜的ETL，對不？舉個很簡單的例子，某大客戶經理要查某區縣欠費100元-200元之間的屬於某大型單位的年齡在30歲以上客戶詳細資料已經最近的消費明細，那是否要在ODS中關聯好幾個表來達到他們頻繁的查詢目的呢？
我也做過很多國內專案，客戶的有的及時性需求是存在的，但是不普遍，沒有非要給出個新概念給客戶感覺這個新概念肯定ok的必要吧，除非這些客戶對資料倉儲的瞭解都比較業餘。所謂near
realtime只是針對某個很棘手的分析主題，能快速相應客戶資訊的變化，這種情況一般為單一主題的情況，完全可以和“傳統DW”分開來設計和實施（看具體情況，只是邏輯上至少要分開）。這樣的需求一般資料量不會很大，這是能快速相應，接近事實的前提，技術和設計上沒有什麼需要革新。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/6517/viewspace-145544/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 資料倉儲架構分層設計架構
- 什麼是真正的架構設計？架構
- 分層架構在資料倉儲的應用架構
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 我們需要怎樣的湖倉一體架構？架構
- 資料倉儲(5)數倉Kimball與Inmon架構的對比架構
- 論資料倉儲架構前需要考慮的問題架構
- 談談資料倉儲架構的發展和分類架構
- 美團DB資料同步到資料倉儲的架構與實踐架構
- 雲端計算儲存之Ceph架構是怎麼樣的？架構
- Java軟體架構設計慨論(轉載)--設計模式和系統架構的關係Java架構設計模式
- 架構師眼中的文化：試用期才是真正的考察時間架構
- Java架構-到底什麼才是業務架構？Java架構
- Nebula 架構剖析系列（一）圖資料庫的儲存設計架構資料庫
- 架構設計之資料分片架構
- 主流資料庫架構設計資料庫架構
- 馬蜂窩資料倉儲的架構、模型與應用實踐架構模型
- 資料倉儲架構師的崗位職責和崗位要求架構
- 本地讀寫的多活資料儲存架構設計要義架構
- DW2.0-下一代資料倉儲架構架構
- 架構之:資料流架構架構
- 遊戲架構 遊戲架構設計(8)遊戲架構
- 架構設計思想-微服務架構設計模式架構微服務設計模式
- 基於雲原生架構的新一代資料倉儲平臺架構
- App架構設計經驗談:資料層的設計APP架構
- 資料脫敏大資料架構設計大資料架構
- 架構師修煉之道（二）——架構？設計？架構師？架構
- 架構設計架構
- iOS應用架構談：架構設計的方法論iOS應用架構
- 架構實戰--軟體架構設計的過程架構
- PetShop的系統架構設計（一）(轉）架構
- 大型網站架構之:MySpace的體系架構一（轉載）網站架構
- 大型網站架構之:MySpace的體系架構二（轉載）網站架構
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 面向資料的架構架構
- 資料倉儲之大規模並行處理架構原理NY並行架構
- 架構設計之一——基礎架構架構
- 資料倉儲設計(轉)