資料倉儲資料架構小序

2022-05-15 18:28:42 字數 874 閱讀 8266

今天遇到乙個數倉工程師經常會遇到的乙個棘手問題,就是要提取乙個**商從2007到2023年來銷售的資料明細,本來從現有的資料作業關係架構圖中很容易取出這些資料,但是第一資料跨度太長,這種非原始資料底層只存了近5年的數;第二如果衝底層重新生成資料,由於**商資料不是直接從底層處理而來,有好幾個前置作業,我必須了解前置作業10年前資料處理邏輯是什麼樣子(對於我這種工作不滿10年的完全是一場災難),只能重新對接業務部,從頭開發一張報表。這樣做實在是太耗費時間和人力了。

由此深深地覺得資料模型結構建設存在重大問題。目前使用的數倉架構實際上是一張業務架構圖,好處在於處理目前架構圖中已有或者相近的資料需求時將是非常簡單高效和快速的,但是,一旦業務有變化,整個架構圖都要改變,越是修改離樹根越近的作業, 相關的後續作業改的越多。更甚者像今天遇到的問題,要從底層處理10年前的資料,最高效的方法是找到10年前的數倉工程師和業務人員。

由此,我認為數倉的資料處理架構圖不應該由業務引導,而是要以資料為動力,通過整理資料的內在聯絡,分門別類,最後形成乙個包羅永珍的資料模型。

當然,資料和業務是不能完全脫離,資料建模就像一棵松樹的成長,資料骨幹要直,所有的枝葉(業務)資料都來自同乙個口徑,不然一百個工程師處理同乙個任務能出一百個哈利波特。由此本人資料建模過程總結:

1首先對業務進行整理,總結歸納業務需求。

2對各個業務的的資料進行分類,例如,本公司資料可以分為訂單資料,**商資料,物流資料,使用者資料,優惠資料等幾大類

3對各大類資料進行維度分析歸類,例如,不論是訂單還是**商都會涉及到地理維度資料,商品維度資料等

4模型建設,模型建設包括事實表建設和維表建設,事實表作為資料最底層,粒度越細越好,例如事實表中訂單銷售銷退資料,最好是精確到商品級,事實表要盡可能少地與維表資料重合,同樣,維表要盡可能精簡,鼓勵使用星型模型,不建議使用雪花模型

Microsoft資料倉儲架構

microsoft 資料倉儲架構 摘要 本文簡單介紹了使用 microsoft 資料倉儲架構的資料倉儲,討論了資料倉儲能夠實現的功能,使用資料倉儲的恰當時機,以及如何將資料倉儲與系統體系結構合成一體。目錄簡介 資料倉儲 作為資料倉儲模型的立方體 使用資料倉儲進行決策 檢視立方體片段和介面 micro...

資料倉儲分層架構

在一篇部落格看見了有關資料倉儲分層的內容,概括如下 複製層 ssa,system of records staging area ssa 直接複製源系統的資料,盡量保持業務資料的原貌 與源系統資料唯一不同的是,ssa 中的資料在源系統資料的基礎上加入了時間戳的資訊,形成了多個版本的歷史資料資訊。原子...

資料倉儲架構分層

資料倉儲簡介 有些人不理解資料倉儲,認為資料倉儲就是獲取資料,只要會使用hadoop spark等大資料工具就懂資料倉儲,這樣的認識太片面。如果要從海量資料中總結出乙個報表或者是多個報表,大資料工程師足以 如果在有限的資源動態的資料情況下,向前可歷史追溯,向後對不斷增加的報表實現相容,這就需要一套科...