[[403405]]

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

ODS層辨析

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

Inmon VS Kimball

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

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

ODS VS DB VS EDW

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

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

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

ODS層的設計思路

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

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

文件抽取

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

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

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

直連同步

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

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

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

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

日志解析

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

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

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

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

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

該如何選擇同步方式

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

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

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

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

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

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

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

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

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

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

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

ODS層表設計

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

命名

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

存儲

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

ODS層常見的問題

實時和準實時數(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ù)就是為了適應實時性，數(shù)據(jù)源中發(fā)生的更新可以立刻傳送到數(shù)據(jù)倉庫的動態(tài)數(shù)據(jù)中，再經(jīng)過響應的轉(zhuǎn)換，滿足實時的要求。

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

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

• 實時ODS

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

• 準實時ODS

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

• 傳統(tǒng)ODS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 表的生命周期管理

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

• 無下游任務的表 

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