前言

互聯網的高速發展，行業內事實的分工有了精細化，不過網上的段子還停留在那些程序員加班熬夜掉光頭發的梗，很多人的觀念也是停留在敲敲打打就倒騰出一個軟件的層面吧，前一陣接觸了一些求職者，面向的是大數據開發工程師、數據開發、數倉工程師的這些崗位，其實面向的工種就是寫SQL的那群人，但是發現基本都是一開頭就是結束。因為技術人員都是覺得高并發，底層，百度起來也方便,這寫個SQL能聊出什么花來呢，今天我就以ODS的話題，聊一聊關于數倉里面的一些事情。

不斷變化的數倉

數倉一面戛然而止的問題

但凡數據開發，一定會問一個問題:“你了解數倉分層么”，我們收到幾乎清一色的回答都是，知道啊，就是ods,dwd,dws,adm呀，進一步問一下，為什么需要這樣子劃分呢？或者比如說如果不要dwd可以么？這種時候很多情況要么是說團隊內這樣子劃分的，要么也說不上所以然來，然后就沒有然后了。

回顧數倉

這個是阿里巴巴Dataphin中的數倉劃分，原文

傳統的數據其實就是ods->dwd->dws->adm這種劃分，實際上圖中給我們的是叫做
ods->cdm->ads這種劃分，dwd、dim、dws其實是在cdm里面的，目測也不是那么一串下去的。再看看下圖京東的劃分。

一看還多出來了一些緩沖層啥的，其他也不枚舉了，數倉的劃分一直就沒有規定說一定需要怎么劃分，只是在數據加工的時候有些本身的形態，需要估計整個數倉的業務覆蓋、性能、質量、成本以及團隊協作效率的因素，這個時候出來的形態才是真正的樣子。

ODS的話題

ods和煉油的對應關系

其實面試中如果問了數倉分層的話，一定會接著問(ods|dwd|dws|adm)是什么這類的問題，常規的對ods的回答大部分就是上游、或者業務數據流入、這些其實都對，但是總感覺少了點什么，觸及不到面試官的興奮點。我們一定聽說過大數據就是石油的比喻，這個比喻其實不光是宏觀層面，細節層面也是使用的，石油也是經過原油多到工序加工出來的，對于我們的ODS來說就是對應的原油了，我們可以看看石油的加工鏈路：

我們再看看數據的鏈路

其實里面核心的邏輯就是，原油經過不斷提煉，在各個階段都可以加工出各種產品，
數據的提煉也是，在ods層面可以也可以加工出各種結果，這種情況取決ods數據的易用程度，大部分情況來說可以有以下的情況：

ODS的劃分

模擬信號數據 Analog data

模擬信號相對于數字量而言，指的是取值范圍是連續的變量或者數值。模擬數據是指在某個區間產生的連續值，例如，聲音、圖像、溫度、壓力，當然這個是工業上的概念搬過來而已，在我們實際大數據處理的時候，例如監控類程序，我們一般會在內存維護一個監控量，再開一個后臺線程去讀取，還有就是一些程序內部的Metrics信息，還有一些業務監控指標，日志流量這種數據、這一類的特點我們都可以用發送到Kafka消息中，然后用Flume或者Flink之類的進行落盤分析。這一類數據一般沒有明確的結構，比如啥里頭的JSON啦，需要再加工才能方便使用。

應用程序數據 application data

這一類是指應用程序和業務處理產生、傳統的數據放在數據庫中（dbms）這類數據特點是數據比較規范，有明確的結構，基本數據庫里面的信息拿過來就可以用。

文本數據 textture data

這一類數據就是不會按照特定的格式存儲，像網頁啦，文檔啦，一些直接的文件格式oss信息之類的，這種一般需要比較麻煩的解析才能使用

ods越煉越香

這類的特點就是真正的原始數據，里面的信息是最全的，這類數據的價值在于隨著數據加工技術的不斷升級，里面過去一些信息沒有加工的在未來有可能存在新的價值。大數據的歷史并不長，所以記得也必將清楚。大數據的加工一直是不斷變化的，大概09-15年左右，那時候我們倒騰一個手寫的mapreduce jar還是比較興奮的階段，工作中大部分還是處于hive階段，那個時候hadoop可以做到比較大量的存儲，那段時間互聯網也是高速發展階段，已經可以大量采集流量日志了，但是真正的加工也只是計算pv，uv之類的事情，進一步加工的情況不多，再到后面的階段，流量信息里面的地理位置信息，電量，wifi信號強度，ip地址啥的也會用來做風控使用。再然后呢，隨著機器學習技術的不斷引進，這些數據價值也不斷體現出來，瀏覽頁面的順序，角度，海拔，還有一些生物信息面部信息指紋也被采集。有人比較好奇，為毛一開始不就可以加工么？這個就是我們的煉油技術了，一方面我們需要知道怎么使用、一方面有時效要求、還一方面需要時效性上有要求才能有效果。大家熟知的各大app推薦技術，一說的大家腦袋里面可以蹦出來很多淘寶、京東、抖音、快手、小紅書，像商品推薦，內容推薦這類現在生活依賴的功能想必都很熟悉，因為互聯網上面的信息是海量，我們又要快速的推薦，需要技術上做到實時，如果我昨天的數據你今天推薦出來，效果不好，要實現這個事情，需要不斷升級系統算法，這個時候才會去提出對這類數據的實時依賴，這就是前后的原因。

ods數據的進一步規范

互聯網應用走入尋常百姓家，有一個很涉及我們個人事情，那就是隱私保護，實際上前面很多年的軟件沒有太多限制的，安卓早期版本一開始就可以拿到你手機的root權限，然后上傳你手機的信息，所以我們在互聯網上都是裸奔的，這個背景上，國家也是對個人信息立法，企業應當遵循各類通用法。

那這個對ODS是有什么影響么？影響就大了，在以前的加工采集數據的時候ods來說沒太多約束，但是在個人信息保護法之后，數據的采集，加工都要遵循這類法規，那么具體ods來說則是會進一步被限制采集的范圍，方式方式，簡單理解來說未來你想拿ods數據的話需要合法，在使用方式上會有法律主體，加密策略，合約等方式，ods也需要帶上這一類使用范圍的聲明。實際的例子：ods在采集個人信息的時候，需要用戶進行授權，如果沒有實際的授權則是非法的，這個時候ods的數據范圍就只能在約束范圍內。可以想到，這個需要一定隱私技術實現的，立法的時間也還不是很久，所以是進一步的規范，那么在不久的幾年里面我們ods呈現出來的形態就會發生很大的變化了。

ods的加工特性

不進行任何數據加工

和其他的數據加工不同，ods是強調盡量保持他原有的樣子，簡單來說，數據內容不允許加工的，因為一旦加工了的話就破壞了最開始的樣子，比如說一些字段null，有些強迫癥的同學喜歡轉化掉，或者過濾掉，這種事情是萬萬不可以的，因為ods內容不僅僅可以分析業務的指標，同時還能表達出異常情況，比如數據上因為某些系統異常出現了一些Exception的數據，對于實際業務分析可能是沒價值，但是對于系統運維同學來說是可以通過這種數據了解到那個時候的異常情況的。

盡量保持全部內容

這個是指存在一些例如日志上面某些數據看起來確實無用，看著很雞肋就干掉，這個也是不合理的，還是前面的情況，這類信息可能是有不同的使用場景，也有可能短期內還不好加工出來，但是未來會用到

需要可以還原歷史

如果是每日增量數據，則需要保存全部的歷史分區，如果是變化數據，則需要保留每日快照。實際情況是有一份增量數據和一份全量數據。這個反例就是比如數據每日發生變化，一開始業務覺得是可以使用最新的，但是ods如果只是保留最新的話，未來某一天需要看歷史的時候沒辦法去做分析，因為ods不存在，所以下游的dwd更加沒辦法加工了

不太關注業務內容

ODS比較成熟的狀態是已經工具化接入了，所以ods運維人員處于ods運維的角色，但并不真正負責里面的內容，當然一旦關心內容的話就會很重，在數倉分層中因為也會有下游的dwd層，實際的重數據業務可以依賴dwd，因為這個是一個需要投入很大的工作，同時和ods需要保持原始樣子，所以不進行加工，自然也不關注業務內容

保證數據完整性

可能大部分的思維上ods的抽取就是凌晨00:00就抽取就是了，這個在實際情況不是這樣子的，首先，業務上是比較難保證那一天的業務真的就在00:00點完成的，尤其是像流量那種，在大促的時候會存在延遲的情況，ODS普遍存在的問題就是數據漂移，數據缺失，類似23:58發生的業務實際要到00:15或者更晚才完成，ods的策略一般是盡量保證數據的完整性，可以多出來數據，但是不能少。一些常見的措施，例如前后跨15分鐘數據抽取，在財務數據處理的時候需要配合在線系統做日切檢查的方式，還有就是監控數據的完整性，其他嚴格的可以做冪等校驗。

ods穩定性影響

時效、穩定這個其實在任何一個數據開發都有要求，只不過針對ods來說是很底盤的存存在，一旦核心ods延遲，那么整個公司的資源都會強制加劇，這個事情是比較殘酷的，對ods來說也是不關注數據內容，所以可以通用化采用一些優化策略，類似分桶，hash之類的操作，需要把時效最大化

ods一般模型設計

一般的ods怎么做模型設計呢？簡單說道說道~

模型設計

ods因為他處于最上游的特點，所以設計上一般面向的是時效不同的鏈路，常規來說一般是需要天全量表、天增量表、小時表,比如說訂單表:

ods_pay_order_dd ods_pay_order_delta ods_pay_order_delta_hh

鏈路設計

數據的接入情況很多，系統的數據一般是接入從庫，抽取工具也是sqoop,Datax等方式抽取，當下比較多的情況一般是監聽binlog的方式獲取增量數據，通過增量還原出當天的數據，如圖所示：

日切檢查

日切本身是賬務上面的概念，在銀行、財務這一類對數據質量強要求的場景時，是需要做日切的操作的，但是隨著大數據的技術發展，業務上對數據的準確性的要求是不斷提高，對大數據場景來說之前常規的保證數據的做法一般是把定時的時間往后做調整，但是這種方式只是減少了數據丟失的概率，還是有隱患，現在的數據處理是增加檢查節點，這類檢查節點就是日切。舉例說明，概念上來說日終是銀行系統每天下班前，是柜面業務的帳務結算，終了軋帳。日初是指開始上班做的工作前期準備工作的統稱。

ods掛在在線跑批的鏈路之后再開始工作，這類操作就是日切檢查。

后記

ods其實還涉及到流批一體操作、在離線聯調、模板化加工等諸多話題，作為一個數倉人員來說，ods其實是最最基礎的數據依賴，本身的生命周期還是需要有了解的，實際上ods的穩定帶來的效益是整體業務的一個穩態，在數倉鏈路中屬于那種不會掛在臺面上卻是至關重要的角色。

總結

以上是生活随笔為你收集整理的大数据开发第一站ODS篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。