截止到現(xiàn)在數(shù)據(jù)架構中關于Ods層的定義、設計應用已經呈現(xiàn)多樣化，而且也出現(xiàn)像數(shù)據(jù)湖這樣的概念，不深究數(shù)據(jù)湖的定義與存在的意義，僅是把Ods作為分析一個深入研究的對象來做。

Ods出現(xiàn)時，數(shù)據(jù)倉庫架構必定包含Ods（Operational Data Store)，因為ods的主要目的是為了屏蔽數(shù)據(jù)倉庫與業(yè)務系統(tǒng)，降低他們之間的耦合。對ODS的描述不在少數(shù)，這個概念應該是90年代初提出的，郁悶派掌門inmon和球派老大kimball都有文章或著書論及，比如inmon就有一本書，Building the Operational Datastore。

inmon和kimball關于ODS的概念基本差不多，都是集成地，是面向主題地，是易變地，并且是反應當前狀態(tài)地。相比較數(shù)據(jù)倉庫系統(tǒng)的定義，發(fā)現(xiàn)后兩個特點正好相反。但是這兩派對于ODS的實現(xiàn)可就不一樣的，inmon贊成使用高度范式化的數(shù)據(jù)模型來為ODS建模，而kimball提倡使用維度建模來實現(xiàn)ODS，和后面的DW、DM使用統(tǒng)一的維表。

ODS說我為什么這么難

從前有一個ods，用戶需要它出現(xiàn)時，它就會出現(xiàn)，不需要時就會默默匿在后面，用戶不同的需要，它就會表現(xiàn)出不同的習性，用戶訴求它作為日常報表數(shù)據(jù)基礎時，它就會每日從業(yè)務系統(tǒng)數(shù)據(jù)源去同步數(shù)據(jù),現(xiàn)在很多企業(yè)都是這樣T+1 的去同步數(shù)據(jù)。

后來出現(xiàn)了一種需求，需要在企業(yè)不同系統(tǒng)同步一些重要數(shù)據(jù)，例如各種重要枚舉值、客戶信息、訂單信息、支付信息、交易信息、金融信息等，這些數(shù)據(jù)一天更新一次是無法滿足企業(yè)某些人的強烈欲望，那就改成一個小時讓使用者爽著。

在后來呢，企業(yè)的業(yè)務跑的太快了，業(yè)務剛上線，產品技術消耗了幾天幾夜上線相關與產品后已經著急的做下一個迭代去了，但是運營后臺就很少有資源去完善，業(yè)務告訴數(shù)據(jù)平臺，我們的運營數(shù)據(jù)查詢也是屬于數(shù)據(jù)，數(shù)據(jù)平臺來做了吧，小時級的數(shù)據(jù)同步也無法滿足應用了，客戶信息、支付狀態(tài)、地址等都是隨時而變化的，那就上幾分鐘級別的吧。

再后來，秒級的 ，業(yè)務說我的明細數(shù)據(jù)怎么還不出來，投訴投訴投訴，Ods說我我罷工不干了，找個弟弟繼續(xù)頂上去，實時計算等一系列的對于近乎實時日志級別處理技術就光大了，在這里不做討論，在于近乎實時，分鐘級、10分鐘級別、小時級別 采用到的技術實現(xiàn)與代價是不同的。

ods隨著業(yè)務的訴求自己也越來痛苦，人家業(yè)務都在精細化了，那我ods的方法論為啥不做更加精細化呢。

ODs類型重新分類與變化處理

對于數(shù)據(jù)倉庫/數(shù)據(jù)平臺來講， 數(shù)據(jù)都是記錄歷史變化的，他的定義中也明確提到這一點，所以數(shù)據(jù)倉庫/平臺中的事實表一般都有時間或時間戳字段來支持記錄的歷史變化，而且不光是事實表，維表也要體現(xiàn)歷史變化，其中，代理鍵就起了一定的作用，但是在業(yè)務系統(tǒng)是屬于頻繁變更記錄的，很少在業(yè)務系統(tǒng)用保存歷史數(shù)據(jù)的這個對于業(yè)務系統(tǒng)數(shù)據(jù)庫來說是有很大很大的壓力。所以在業(yè)務系統(tǒng)與數(shù)據(jù)平臺層面存在一個緩沖區(qū)域，記錄的是最近時間的業(yè)務系統(tǒng)的原子數(shù)據(jù)，忽略了一些歷史信息。

截止到現(xiàn)在ods的發(fā)展這些年大家對于ods的討論還是按照兩類的標準劃分，事件型(Transaction Grain)、周期快照型(Piriodic Snapshot Grain)，但是按照特性來分還可以把周期快照在拆分一種叫累積快照型(Accumulating Snapshot Grain)

系統(tǒng)中存在一種數(shù)據(jù)，如果用ER圖表示的話，他們多是被別的數(shù)據(jù)參照，這種數(shù)據(jù)叫做“主數(shù)據(jù)”。顧名思義，這些數(shù)據(jù)是很重要的，是系統(tǒng)的核心數(shù)據(jù)，被引用的越多越重要。例如產品數(shù)據(jù)、客戶數(shù)據(jù)，以及一系列的代碼數(shù)據(jù)，都屬于主數(shù)據(jù)。而主數(shù)據(jù)在ODS層中的存儲一般都是選擇快照型的形態(tài)存儲。

• 快照型數(shù)據(jù)反應的是最近一點時刻，主數(shù)據(jù)的狀態(tài)信息，例如客戶的狀態(tài)，客戶的信用度等，他們都通過update操作將前次狀態(tài)或信用度都更新掉了。

• 事件型，而另一種數(shù)據(jù)形態(tài)，記錄是事件的發(fā)生，例如記錄一次通話，記錄一次開帳等，日志表也屬于這種形態(tài)，它反應的是對數(shù)據(jù)的歷史操作。這兩種形態(tài)的數(shù)據(jù)一個較大的區(qū)別就是前者會不斷被更新，而后者一般不會做更新操作。

• 累積快照型，它記錄是一個時間點上實體的狀態(tài)，這種數(shù)據(jù)從實體的生命周期一開始一直更新到生命結束，例如用戶表中，從用戶創(chuàng)建開始，用戶開機、停機、狀態(tài)改變都會直接更新這些數(shù)據(jù)，最后，用戶銷戶了，更新他的有效標志，從此這條記錄基本不會再修改了。從大的方向來說這個歸類在周期快照型表中，表示是期末那一刻的狀態(tài)值，例如充值余額可以記錄在用戶表中同時也可能會在月帳單表中出現(xiàn)。而時點值一般在事件型數(shù)據(jù)中是不會出現(xiàn)的。時期值一般存在于事件型核周期快照型表中，因為他表示發(fā)生值，在累積快照型中沒有這種值。當然，有時候你可以從另一個角度將累積快照型看作是一種事件型表，因為前者記錄實體的生命周期變化，因此這些變化，你甚至可以看作是一種事件。從而，再以用戶表為例，你可以統(tǒng)計新增用戶多少，離網用戶多少等時期值。

理解這三種數(shù)據(jù)形態(tài)對于數(shù)據(jù)抽取有一些幫助。數(shù)據(jù)倉庫日常的ETL工作中，不可能總是處理全量數(shù)據(jù)，那個量就太大了，必須尋找增量（Ps 當然現(xiàn)在因為部分同學在處理數(shù)據(jù)時直接做全量快照同步，每天稱呼資源最近很緊張，如果扒開內部看一下，每天存的是昨日的全量快照）。

這里的增量不是指增加的數(shù)據(jù)量，還包括修改的和刪除的數(shù)據(jù)。增量的支持對數(shù)據(jù)源系統(tǒng)是一個很大的考驗，對于快照型數(shù)據(jù)，數(shù)據(jù)源在實時變化，如何捕捉一個時間段內所有發(fā)生變化的數(shù)據(jù)？

• 一種方法是加入時間戳，所有插入、更新操作都能反應到時間戳，通過選取時間戳在某個時間周期內，就可以得到該周期內的增量數(shù)據(jù)，從而減少數(shù)據(jù)量的處理。但是這種方式沒法得到刪除的數(shù)據(jù)。

• 還有一種方式得到快照型數(shù)據(jù)增量，通過數(shù)據(jù)變更日志，因為每條日志反應的是記錄的變化，一個時間周期內出現(xiàn)在日志中的主數(shù)據(jù)，就是該周期的增量。這種方式還能處理刪除數(shù)據(jù)，但是到了ODS層，通常也不建議刪除任何數(shù)據(jù)。

通過這兩種方式獲取快照型數(shù)據(jù)增量都有一些問題。主要是數(shù)據(jù)源的支持程度，例如是否有時間戳字段？日志是否記錄每種主數(shù)據(jù)變化？有些系統(tǒng)的答案是否。例如數(shù)據(jù)源的用戶表、客戶表就很少有時間戳，而對日志，很可能不能反應所有數(shù)據(jù)狀態(tài)變化，以前遇到過一種情況，系統(tǒng)有用戶開機日志，停機日志，但這些日志是屬于營業(yè)模塊的，而當另一個信用監(jiān)控模塊對用戶作出欠費停機處理后，日志中就沒有。

接觸過一些企業(yè)的數(shù)據(jù)平臺，內部都在稱呼ETL窗口期過長、數(shù)據(jù)計算存儲資源不夠，那會因為不管是什么表每張表都存的昨日全量數(shù)據(jù)、保存下就是好幾年的，本來做增量處理每天變化也就幾百兆，非要一次保存十幾個G的全量數(shù)據(jù)。在這個處理過程中，一邊是全量處理的性能矛盾，一邊是增量支持不力的矛盾，需要一種平衡。

比如對于用戶增量數(shù)據(jù)，在用戶表中有一系列時間字段，如開戶時間、開機時間、停機時間、銷戶時間等，通過這些時間的判斷，也能得出一種增量，只不過略顯麻煩，而且也不能保證數(shù)據(jù)源對這些時間的維護是一致的。

對于事件型數(shù)據(jù)，處理增量相對直觀一些，因為這種數(shù)據(jù)一般都有時間字段或時間戳。但是增量抽取同樣存在一些問題。主要是對歷史數(shù)據(jù)的修改，嚴格意義上，事件發(fā)生了，既成事實，不要在修改這些數(shù)據(jù)，要修改也只是另外一次事件了。但是數(shù)據(jù)源存在這種現(xiàn)象去修改歷史記錄，甚至還有手工修改的，根本無法通過時間信息來獲取增量。例如話單重批和帳務調賬等操作很多都是修改歷史數(shù)據(jù)。面對這種情況，有時就得作出選擇，忽略這些數(shù)據(jù)變化。

再談ods的設計

ods的設計中曾經有兩種考慮，一是設計標準化的ods，和oltp系統(tǒng)松耦合，它從一個概念高度對企業(yè)信息模型進行建模，這接近inmon的思路。然而，誰能說他能夠設計一個這樣的模型，現(xiàn)實的項目周期壓力、數(shù)據(jù)準確性壓力都不允許這樣做。

另一種思路，是完全按照數(shù)據(jù)源結構來設計ods，oltp表結構如何，ods表結構就是如何，到dw層再整合。從現(xiàn)實角度看，后一種思路更加適用，因為它可以縮短開發(fā)周期，能夠很快讓客戶看到東西。

如果把數(shù)據(jù)倉庫系統(tǒng)比作人的大腦，DW是深度記憶區(qū)，ODS是淺度記憶區(qū)。當人接收外界的信息后，記憶在淺度區(qū)，經過溫習或者某些深刻的印象，這些信息又都被記錄到深度區(qū)中。而對于DM層是否可以比作語言區(qū)域呢？通過對記憶區(qū)信息的邏輯加工，進行夸大（那些夸夸其談的人），或進行巧妙刪減（那些有意隱瞞真相的人）等等，將記憶的信息傳播給外界。

ods 是夾在業(yè)務系統(tǒng)與數(shù)據(jù)平臺系統(tǒng)的一層夾心餅干，假如業(yè)務的客戶有相同的業(yè)務流程 但是數(shù)據(jù)模型不一樣，在構建ods是基于業(yè)務模型去構建還是基于數(shù)據(jù)模型去做設計呢？

而且對于ods的模型設計也因為對于業(yè)務理解、數(shù)據(jù)理解、數(shù)據(jù)平臺的實踐度都有很大的關系。

現(xiàn)在Ods 的設計大部分還是一個業(yè)務源接口表對應Ods一張表，這樣對于ODS設計是方便了，而且做ETL也好做，主要的工作也就是清洗臟數(shù)據(jù)和作一些代碼轉換工作。如果是存在多個ODs項目或這個因為業(yè)務各種頻繁變化導致的ods存在大量累計歷史表，很難形成可復用部分的，不管是在哪個階段，對業(yè)務模型的理解和裁減恐怕也不是一件輕松的事情。

作者： 松子(李博源) 自由撰稿人，數(shù)據(jù)產品 & BI 老兵一枚。