分析:大數據環境下如何優雅地設計數據分層
佚名
()最近出現了好幾次同樣的對話場景:問:你是做什么的?答:最近在搞數據倉庫。問:哦,你是傳統行業的吧,我是搞大數據的。答:……
發個牢騷,搞大數據的也得建設數據倉庫吧。而且不管是傳統行業還是現在的互聯網公司,都需要對數據倉庫有一定的重視,而不是談一句自己是搞大數據的就很厲害了。數據倉庫更多代表的是一種對數據的管理和使用的方式,它是一整套包括了etl、調度、建模在內的完整的理論體系。現在所謂的大數據更多的是一種數據量級的增大和工具的上的更新。兩者并無沖突,相反,而是一種更好的結合。
話說,單純用用Hadoop、Spark、Flume處理處理數據,其實只是學會幾種新的工具,這是搞工具的,只是在數據倉庫中etl中的一部分。
當然,技術的更新往往能領到一個時代的變革,比如Hadoop的誕生,光是深入研究一個大數據組件就要花很大的時間和精力。但是在熱潮冷卻之后,我們更應該考慮地是如何更好地管理和使用自己的數據。
對于數據的從業者來講,要始終重視緊跟技術的變革,但是切記數據為王,在追求技術的極致的時候,不要忘了我們是搞數據的。
文章主題
吐槽完畢,本文主要講解數據倉庫的一個重要環節:如何設計數據分層!
本文對數據分層的討論適合下面一些場景,超過該范圍場景or數據倉庫經驗豐富的大神就不必浪費時間看了。
數據建設剛起步,大部分的數據經過粗暴的數據接入后就直接對接業務。數據建設發展到一定階段,發現數據的使用雜亂無章,各種業務都是從原始數據直接計算而得。各種重復計算,嚴重浪費了計算資源,需要優化性能。
文章結構
最初在做數據倉庫的時候遇到了很多坑,由于自身資源有限,接觸數據倉庫的時候,感覺在互聯網行業里面的數據倉庫成功經驗很少,網上很難找到比較實踐性強的資料。而那幾本經典書籍里面又過于理論,折騰起來真是生不如死。還好現在過去了那個坎,因此多花一些時間整理自己的思路,幫助其他的小伙伴少踩一些坑。
為什么要分層?這個問題被好幾個同學質疑過。因此分層的價值還是要說清楚的。分享一下經典的數據分層模型,以及每一層的數據的作用和如何加工得來。分享兩個數據分層的設計,通過這兩個實際的例子來說明每一層該怎么存數據。給出一些建議,不是最好的,但是可以做參考。
為什么要分層
我們對數據進行分層的一個主要原因就是希望在管理數據的時候,能對數據有一個更加清晰的掌控,詳細來講,主要有下面幾個原因:
清晰數據結構:每一個數據分層都有它的作用域,這樣我們在使用表的時候能更方便地定位和理解。數據血緣追蹤:簡單來講可以這樣理解,我們最終給業務誠信的是一能直接使用的張業務表,但是它的來源有很多,如果有一張來源表出問題了,我們希望能夠快速準確地定位到問題,并清楚它的危害范圍。減少重復開發:規范數據分層,開發一些通用的中間層數據,能夠減少極大的重復計算。把復雜問題簡單化。講一個復雜的任務分解成多個步驟來完成,每一層只處理單一的步驟,比較簡單和容易理解。而且便于維護數據的準確性,當數據出現問題之后,可以不用修復所有的數據,只需要從有問題的步驟開始修復。屏蔽原始數據的異常。屏蔽業務的影響,不必改一次業務就需要重新接入數據。
數據體系中的各個表的依賴就像是電線的流向一樣,我們都希望它是很規整,便于管理的。但是,最終的結果大多是第一幅圖,而非第二幅圖。