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

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

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

ODS說我為什么這么難

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

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

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

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

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

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

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

截止到現(xiàn)在ods的發(fā)展這些年大家對(duì)于ods的討論還是按照兩類的標(biāo)準(zhǔn)劃分，事件型(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ù)，被引用的越多越重要。例如產(chǎn)品數(shù)據(jù)、客戶數(shù)據(jù)，以及一系列的代碼數(shù)據(jù)，都屬于主數(shù)據(jù)。而主數(shù)據(jù)在ODS層中的存儲(chǔ)一般都是選擇快照型的形態(tài)存儲(chǔ)。

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

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

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

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

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

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

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

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

接觸過一些企業(yè)的數(shù)據(jù)平臺(tái)，內(nèi)部都在稱呼ETL窗口期過長(zhǎng)、數(shù)據(jù)計(jì)算存儲(chǔ)資源不夠，那會(huì)因?yàn)椴还苁鞘裁幢砻繌埍矶即娴淖蛉杖繑?shù)據(jù)、保存下就是好幾年的，本來做增量處理每天變化也就幾百兆，非要一次保存十幾個(gè)G的全量數(shù)據(jù)。在這個(gè)處理過程中，一邊是全量處理的性能矛盾，一邊是增量支持不力的矛盾，需要一種平衡。

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

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

再談ods的設(shè)計(jì)

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

另一種思路，是完全按照數(shù)據(jù)源結(jié)構(gòu)來設(shè)計(jì)ods，oltp表結(jié)構(gòu)如何，ods表結(jié)構(gòu)就是如何，到dw層再整合。從現(xiàn)實(shí)角度看，后一種思路更加適用，因?yàn)樗梢钥s短開發(fā)周期，能夠很快讓客戶看到東西。

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

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

而且對(duì)于ods的模型設(shè)計(jì)也因?yàn)閷?duì)于業(yè)務(wù)理解、數(shù)據(jù)理解、數(shù)據(jù)平臺(tái)的實(shí)踐度都有很大的關(guān)系。

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

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