[[403405]]

本文轉(zhuǎn)載自微信公眾號「大數(shù)據(jù)技術(shù)與數(shù)倉」，作者西貝。轉(zhuǎn)載本文請聯(lián)系大數(shù)據(jù)技術(shù)與數(shù)倉公眾號。

ODS層辨析

ODS全稱是Operational Data Store，即操作數(shù)據(jù)存儲。

Inmon VS Kimball

Bill.Inmon的定義：ODS是一個面向主題的、集成的、可變的、當(dāng)前的細(xì)節(jié)數(shù)據(jù)集合，用于支持企業(yè)對于即時性的、操作性的、集成的全體信息的需求。常常被作為數(shù)據(jù)倉庫的過渡，也是數(shù)據(jù)倉庫項目的可選項之一。

而Kimball的定義：操作型系統(tǒng)的集成，用于當(dāng)前、歷史以及其它細(xì)節(jié)查詢(業(yè)務(wù)系統(tǒng)的一部分);為決策支持提供當(dāng)前細(xì)節(jié)數(shù)據(jù)(數(shù)據(jù)倉庫的一部分)。

ODS VS DB VS EDW

ODS是用于支持企業(yè)日常的全局應(yīng)用的數(shù)據(jù)集合，ODS的數(shù)據(jù)具有面向主題、集成的、可變的以及數(shù)據(jù)是當(dāng)前的或是接近當(dāng)前的特點。同樣也可以看出ODS是介于DB和DW之間的一種過渡存儲。

值得注意的是，Kimball所說的ODS是物理落地關(guān)系型數(shù)據(jù)庫中，但是在實際生產(chǎn)應(yīng)用中，ODS往往是物理落地在數(shù)據(jù)倉庫中，比如Hive。

通常來說ODS是在數(shù)據(jù)倉庫中存儲業(yè)務(wù)系統(tǒng)源數(shù)據(jù)，所以從數(shù)據(jù)粒度、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)關(guān)系等各個方面都與業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源保持一致。但是，也不能僅僅將ODS層看做是業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的一個簡單備份，ODS和業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的差異主要是由于兩者之間面向業(yè)務(wù)需求是不同的，業(yè)務(wù)系統(tǒng)是面向多并發(fā)讀寫同時有需要滿足數(shù)據(jù)的一致性，而ODS數(shù)據(jù)通常是面向數(shù)據(jù)報表等批量數(shù)據(jù)查詢需求。

ODS層的設(shè)計思路

ODS層數(shù)據(jù)同步

上文提到ODS的數(shù)據(jù)來源于業(yè)務(wù)系統(tǒng)，且ODS落地的系統(tǒng)通常和業(yè)務(wù)系統(tǒng)是不同的，比如常見的將數(shù)據(jù)落到Hive中。所以，首先我們就需要將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)抽取到ODS表中。一般來說，數(shù)據(jù)同步的方式大概可以分為三大類：文件抽取、數(shù)據(jù)庫表的抽取和原始日志的抽取。

文件抽取

通常情況下，ODS層表的存儲位置與業(yè)務(wù)系統(tǒng)表的存儲位置是不一樣的，比如業(yè)務(wù)表存在MySQL中，而ODS層存儲在Hive中。另外，有的時候，ODS層需要對接多個不同類型的業(yè)務(wù)系統(tǒng)庫，比如DB2、Oracle、Mysql等等，一種比較簡單實用的做法是和各個業(yè)務(wù)系統(tǒng)約定好數(shù)據(jù)接口，并讓業(yè)務(wù)系統(tǒng)按照數(shù)據(jù)接口格式生成數(shù)據(jù)文件和完結(jié)標(biāo)示文件給到ODS。

這種方式有兩個明顯的優(yōu)勢：一方面可以降低ODS處理多種類型數(shù)據(jù)庫系統(tǒng)能力需求，另一方面也減少了對業(yè)務(wù)系統(tǒng)的性能影響。但是這種方式也存在一些不足：數(shù)據(jù)的抽取過程和加載過程是分開的，由業(yè)務(wù)系統(tǒng)和ODS分別負(fù)責(zé)，同時接口新增和變更比較麻煩，需要較大的溝通維護(hù)成本，另外，數(shù)據(jù)落地到文件增加了額外的上傳下載工作，會造成效率比較低。

在實際的生產(chǎn)過程中，這種方式的數(shù)據(jù)同步也很少被使用。

直連同步

直連同步是指通過定義好的規(guī)范接口API和基于動態(tài)鏈接庫的方式直接連接業(yè)務(wù)庫，比如ODBC/JDBC等規(guī)定了統(tǒng)一的標(biāo)準(zhǔn)接口，不同的數(shù)據(jù)庫基于這套標(biāo)準(zhǔn)提供規(guī)范的驅(qū)動，從而支持完全相同的函數(shù)調(diào)用和SQL實現(xiàn)。比如經(jīng)常使用的Sqoop就是采取這種方式進(jìn)行批量數(shù)據(jù)同步的。

直連同步的方式配置十分簡單，很容易上手操作，比較適合操作型業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步，但是會存在以下問題：

• 數(shù)據(jù)同步時間：隨著業(yè)務(wù)規(guī)模的增長，數(shù)據(jù)同步花費的時間會越來越長，無法滿足下游數(shù)倉生產(chǎn)的時間要求。
• 性能瓶頸：直連數(shù)據(jù)庫查詢數(shù)據(jù)，對數(shù)據(jù)庫影響非常大，容易造成慢查詢，如果業(yè)務(wù)庫沒有采取主備策略，則會影響業(yè)務(wù)線上的正常服務(wù)，如果采取了主備策略，雖然可以避免對業(yè)務(wù)系統(tǒng)的性能影響，但當(dāng)數(shù)據(jù)量較大時，性能依然會很差。
• 抽取增量數(shù)據(jù)需要依靠修改業(yè)務(wù)系統(tǒng)，新增時間戳字段，并且按時間戳增量抽取的數(shù)據(jù)準(zhǔn)確性不能得到保障，業(yè)務(wù)系統(tǒng)做數(shù)據(jù)補丁不更新時間戳字段將會導(dǎo)致漏數(shù);
• 實時性差，只能在某個時刻抽取數(shù)據(jù)，不能滿足準(zhǔn)實時數(shù)據(jù)需求;

在實際的生產(chǎn)過程中，這種方式的數(shù)據(jù)同步經(jīng)常被使用，值得注意的是：數(shù)據(jù)庫直連抽取比較適用于小批量表的數(shù)據(jù)抽取，對于大批量的數(shù)據(jù)而言，性能會比較差。

日志解析

據(jù)庫日志抽取是指通過分析數(shù)據(jù)庫日志，將業(yè)務(wù)系統(tǒng)的DDL和DML語句在一個鏡像系統(tǒng)還原，并通過數(shù)據(jù)流的方式對外提供實時數(shù)據(jù)服務(wù)。

所謂日志解析，即解析數(shù)據(jù)庫的變更日志，比如MySQL的Binlog日志，Oracle的歸檔日志文件。通過讀取這些日志信息，收集變化的數(shù)據(jù)并將其解析到目標(biāo)存儲中即可完成數(shù)據(jù)的實時同步。這種讀操作是在操作系統(tǒng)層面完成的，不需要通過數(shù)據(jù)庫，因此不會給源數(shù)據(jù)庫帶來性能上的瓶頸。

由于是數(shù)據(jù)庫日志抽取是獲取所有的變更記錄，落地到ODS表的時候我們需要根據(jù)主鍵去重按照日志時間倒排序獲取最后狀態(tài)的變化情況。通常使FULL OUTER JOIN全外連接的方式進(jìn)行Merge數(shù)據(jù)。

數(shù)據(jù)庫日志解析的同步方式可以實現(xiàn)實時與準(zhǔn)實時的同步，延遲可以控制在毫秒級別的，其最大的優(yōu)勢就是性能好、效率高，不會對源數(shù)據(jù)庫造成影響，目前，從業(yè)務(wù)系統(tǒng)到數(shù)據(jù)倉庫中的實時增量同步，廣泛采取這種方式。

當(dāng)然，任何方式都不是完美的，使用日志解析的方式進(jìn)行數(shù)據(jù)同步也會存在一些已知的問題：比如在業(yè)務(wù)系統(tǒng)做批量補數(shù)時會造成數(shù)據(jù)更新量超過處理的能力，從而導(dǎo)致數(shù)據(jù)延遲。另外，這種方式需要額外補數(shù)一個實時抽取的系統(tǒng)，從而也增加了投入和處理的復(fù)雜性。

該如何選擇同步方式

在實際的生產(chǎn)環(huán)境中，直連同步和日志解析是非常普遍的兩種數(shù)據(jù)同步方式，隨著實時技術(shù)的發(fā)展，使得實時數(shù)據(jù)同步的方式變得越來越方便，越來越多的企業(yè)開始嘗試使用日志解析的方式進(jìn)行數(shù)據(jù)同步。這里需要注意的是，每種方式都有其優(yōu)缺點及適用的場景，找到合適的方式就是最好的方式，切不可一味的追求狂拽酷炫的同步技術(shù)，這也是很多技術(shù)人員經(jīng)常犯的錯誤，應(yīng)用和鉆研新技術(shù)是技術(shù)人的追求，但是過猶不及，在解決具體問題的時候，要多方面權(quán)衡。

另外，數(shù)倉的建設(shè)是為業(yè)務(wù)服務(wù)的，應(yīng)該把時間和精力放在如何支持業(yè)務(wù)、如何發(fā)揮數(shù)倉的價值、如何用數(shù)據(jù)為業(yè)務(wù)提供支持決策上來。筆者認(rèn)為，數(shù)倉的建設(shè)不是一堆大數(shù)據(jù)技術(shù)的簡單堆砌，深入理解業(yè)務(wù)和數(shù)據(jù)才是數(shù)倉建設(shè)的第一要義。

ODS層數(shù)據(jù)清洗

關(guān)于ODS層是否做數(shù)據(jù)清洗一直是存在爭議的，但有一點是可以確定的，對于比較重的清洗工作是要留到后面數(shù)倉的ETL過程中進(jìn)行處理。

但是，有這么一種情況：我們在長期的生產(chǎn)實際過程中，發(fā)現(xiàn)部分已知的數(shù)據(jù)問題的處理可以通過自動化的方式來處理，這種方式通常在數(shù)據(jù)入庫之前，做額外的加工處理后再做入庫操作。

數(shù)據(jù)清洗的主要工作是處理那些不符合要求的數(shù)據(jù)，從而提升數(shù)據(jù)質(zhì)量，比如一些常見的問題：錯誤的數(shù)據(jù)、重復(fù)的數(shù)據(jù)

• 錯誤的數(shù)據(jù)

這種錯誤通常是業(yè)務(wù)系統(tǒng)處理不夠健全造成的，比如字符串?dāng)?shù)據(jù)后面有回車空格、日期格式不正確、日期越界等等，這些問題如果不在ODS層做處理，后續(xù)的解析處理過程中也是要留意處理的

• 重復(fù)的數(shù)據(jù)

例如，一些前端系統(tǒng)遷移過后的新老表融合可能會存在大量的重復(fù)歷史數(shù)據(jù)，這也可以在數(shù)據(jù)清洗這一步驟中完成消除重復(fù)數(shù)據(jù)的操作。需要注意的是，在數(shù)據(jù)清洗后還需要對ODS的數(shù)據(jù)做稽核，還需要對臟數(shù)據(jù)做稽核校驗，臟數(shù)據(jù)的校驗主要集中在數(shù)據(jù)量上，如果數(shù)據(jù)量波動特別大則需要人工介入處理。

其實，在大多數(shù)的情況下，是不需要做數(shù)據(jù)清洗處理的，可以把這個清洗環(huán)節(jié)放到后面的明細(xì)層ETL中進(jìn)行處理。

ODS層表設(shè)計

通常而言，ODS層表跟業(yè)務(wù)系統(tǒng)保持一致，但又不完全等同于業(yè)務(wù)系統(tǒng)。在設(shè)計ODS物理表時，在表命名、數(shù)據(jù)存儲等方面都需要遵循一定的準(zhǔn)則。

命名

比如：不管是表命名還是字段命名盡量和業(yè)務(wù)系統(tǒng)保持一致，但是需要通過額外的標(biāo)識來區(qū)分增量和全量表，”_delta”來標(biāo)識該表為增量表。

存儲

另外，為了滿足歷史數(shù)據(jù)分析需求，我們需要在ODS表中加一個時間維度，這個維度通常在ODS表中作為分區(qū)字段。如果是增量存儲，則可以按天為單位使用業(yè)務(wù)日期作為分區(qū)，每個分區(qū)存放日增量的業(yè)務(wù)數(shù)據(jù)。如果是全量存儲，只可以按天為單位使用業(yè)務(wù)日期作為分區(qū)，每個分區(qū)存儲截止到當(dāng)前業(yè)務(wù)時間的全量快照數(shù)據(jù)。

ODS層常見的問題

實時和準(zhǔn)實時數(shù)據(jù)需求、數(shù)據(jù)飄移處理、巨型數(shù)據(jù)量表處理、如何有效控制數(shù)據(jù)存儲。

實時性

實時數(shù)據(jù)倉庫的主要思想就是：在數(shù)據(jù)倉庫中，將保存的數(shù)據(jù)分為兩類，一種為靜態(tài)數(shù)據(jù)，一種為動態(tài)數(shù)據(jù)，靜態(tài)數(shù)據(jù)滿足用戶的查詢分析要求;而動態(tài)數(shù)據(jù)就是為了適應(yīng)實時性，數(shù)據(jù)源中發(fā)生的更新可以立刻傳送到數(shù)據(jù)倉庫的動態(tài)數(shù)據(jù)中，再經(jīng)過響應(yīng)的轉(zhuǎn)換，滿足實時的要求。

由于實時處理的特殊性及復(fù)雜性，很多情況下實時分析是建立在ODS上而不是數(shù)據(jù)倉庫上，因為ODS處理邏輯簡單，數(shù)據(jù)鏈路相對較短，產(chǎn)出更快。

根據(jù)表的刷新頻率，可以將ODS層的表分為三大類：

• 實時ODS

接近實時地與業(yè)務(wù)庫的數(shù)據(jù)保持同步刷新，主要用于實時分析計算，比如實時的反欺詐，天貓雙11實時大屏等等。這類表的ETL是實時進(jìn)行的，一般情況下，這類表會存儲在消息中間件中，比如Kafka，指的注意的是：要求涉及的業(yè)務(wù)過程不能過多，處理的業(yè)務(wù)邏輯不能過于復(fù)雜。這類ODS的表一般只是用于實時計算，相比批處理的表而言，其維護(hù)成本是相對較高的。

• 準(zhǔn)實時ODS

例如15分鐘到1小時刷新一次,這類ODS比實時ODS成本要低些，基本可以滿足大部分的準(zhǔn)實時需求。并且可以根據(jù)實際需求調(diào)整刷新頻率，具有較好的靈活性。在做處理這類準(zhǔn)實時的ODS表時，需要特別注意ETL任務(wù)的產(chǎn)出效率，通常這類任務(wù)的產(chǎn)出時間最多不能超過ODS表的刷新周期時間。例如小時級別的表，任務(wù)不能超過1個小時。

• 傳統(tǒng)ODS

這是離線數(shù)倉最常見的一種表，即T+1，其數(shù)據(jù)一天刷新一次,可以利用業(yè)務(wù)系統(tǒng)的空閑時間進(jìn)行刷新(通常是每天凌晨0-2點),可實現(xiàn)所有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)集成和刷新。刷新頻率的下降也給系統(tǒng)有更多的時間進(jìn)行數(shù)據(jù)更正和清洗。該類ODS層的表是最容易維護(hù)的。

數(shù)據(jù)漂移

所謂數(shù)據(jù)漂移，指的是這樣一種現(xiàn)象：ODS表的同一個業(yè)務(wù)日期數(shù)據(jù)中包含前一天或后一天凌晨附近的數(shù)據(jù)或者丟失當(dāng)天的變更數(shù)據(jù)。

由于ODS需要承接面向歷史的細(xì)節(jié)數(shù)據(jù)查詢需求，這就需要物理落地到數(shù)據(jù)倉庫的ODS表按時間段來切分進(jìn)行分區(qū)存儲，通常的做法是按某些時間戳字段來切分，實際往往由于時間戳字段的準(zhǔn)確性問題導(dǎo)致數(shù)據(jù)飄移問題的發(fā)生。

一般情況下，我們使用的時間戳分為三類：

• 數(shù)據(jù)庫表中用來標(biāo)示數(shù)據(jù)記錄更新的時間戳字段(即數(shù)據(jù)記錄的update時間，如modified_time)
• 數(shù)據(jù)庫日志中標(biāo)示數(shù)據(jù)記錄的更新時間的時間戳字段(如log_time)
• 數(shù)據(jù)庫表中的用來記錄具體業(yè)務(wù)過程的發(fā)生時間(如proc_time)

在實際的生產(chǎn)過程中，以上三個時間戳往往會存在差異：比如由于網(wǎng)絡(luò)或者系統(tǒng)壓力問題，log_time或者modified_time會晚于proc_time。

當(dāng)時用數(shù)據(jù)庫記錄更新時間或者數(shù)據(jù)庫日志更新時間進(jìn)行切分?jǐn)?shù)據(jù)分區(qū)時，有可能會導(dǎo)致凌晨時間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天，如果使用業(yè)務(wù)時間進(jìn)行限制，則會遺漏很多其他過程的變化記錄。

那么，該如何解決上述的問題呢?常見的方式有兩種：

• 多冗余數(shù)據(jù)

基本原則是寧多勿少，即ODS每個時間分區(qū)中向前向后都多冗余一些數(shù)據(jù)，具體的數(shù)據(jù)切分讓下游根據(jù)自身不同的業(yè)務(wù)場景根據(jù)不同的業(yè)務(wù)時間proc_time來限制。這種情況同樣也會存在一些誤差：比如一個訂單是在6.1日支付的，但在6.2號凌晨申請退款關(guān)閉了該條訂單，那該條訂單記錄就會被更新，下游再統(tǒng)計支付訂單狀態(tài)時會錯誤統(tǒng)計。

• 多個時間戳字段限制時間來獲取相對準(zhǔn)確的數(shù)據(jù)
  • 首先確保數(shù)據(jù)不遺漏，根據(jù)log_time分別冗余前一天最后15分鐘的數(shù)據(jù)和后一天凌晨開始15分鐘的數(shù)據(jù)，并用modified_time過濾非當(dāng)天數(shù)據(jù)，此時會過濾掉一部分后一天凌晨開始15分鐘的數(shù)據(jù)，但是還是會冗余一部分前一天的數(shù)據(jù)，由于log數(shù)據(jù)保存了多個狀態(tài)的數(shù)據(jù)，所以還需要根據(jù)log_time進(jìn)行降序排列，獲取最新狀態(tài)的記錄，這樣就去掉了中間狀態(tài)的數(shù)據(jù)。
  • 下一步就是處理漂移到后一天的數(shù)據(jù)，根據(jù)log_time取后一天的15分鐘數(shù)據(jù);針對此數(shù)據(jù)，按照主鍵根據(jù)log_time作升序排列去重。因為我們需要獲取的最接近當(dāng)天記錄變化情況(數(shù)據(jù)庫日志數(shù)據(jù)將保留所有變化的數(shù)據(jù)，但是落地到ODS的表是需要根據(jù)主鍵去重獲取最后狀態(tài)的變化情況)，這樣就會把漂移到后一天的最初狀態(tài)的數(shù)據(jù)篩選出來了。
  • 最后將前兩步的結(jié)果數(shù)據(jù)作全外連接，限定業(yè)務(wù)時間proc_time來獲取我們需要的數(shù)據(jù)

數(shù)據(jù)存儲

• 避免重復(fù)抽取數(shù)據(jù)，

這種情況在中小公司基本上不會存在，但是在大型的集團(tuán)公司，不同的數(shù)據(jù)團(tuán)隊負(fù)責(zé)不同的數(shù)據(jù)集市或者業(yè)務(wù)，會存在重復(fù)同步數(shù)據(jù)源的情況，解決這類問題的首要措施不是技術(shù)上而是管理上的，必須建立統(tǒng)一的ODS層，收攏權(quán)限，由專門的團(tuán)隊統(tǒng)一管控。

• 表的生命周期管理

一般而言，全量表保存3~7天，增量表要永久保存

• 無下游任務(wù)的表 

比如一些表上源表不產(chǎn)生數(shù)據(jù)了，或者該表沒有被下游任務(wù)使用，這種情況下要及時下線同步任務(wù)，避免造成資源的浪費。