【數倉】數據倉庫的指標庫(五)

本文要來說說,數倉中的數據指標庫

 

數倉系列:

【數倉】數據倉庫的思考(一):https://blog.csdn.net/lsr40/article/details/105576047

【數倉】數據倉庫的建設(二):https://blog.csdn.net/lsr40/article/details/105639190

【數倉】數據倉庫的元數據管理(三):https://blog.csdn.net/lsr40/article/details/105654112

【數倉】數據倉庫的數據質量任務監控(四):https://blog.csdn.net/lsr40/article/details/105689342

 

一、遇到的場景

不知道大家在日常工作中是否會經常遇到如下類似的問題:

問題一:

BI團隊:爲什麼 A 頁面上的數據和 B 頁面上的數據對不上?

開發:我去看看(一段時間後),A 是來自 a 表,B 是來自 b 表,一個包含通過公式一算出來的,另一個是公式二算出來的

問題二:

數據開發:同樣的指標在不同的項目裏被用到,開發 A 同學從 a 表裏取了數據,開發 B 同學從 b 表裏取了數據,我應該從哪裏取數據?指標的邏輯變了2張表都需要做對應的修改?

問題三:

數據開發和 BI 工程師:沒有現成的指標,我要的指標數據怎麼來?問數倉同學然後口口相傳?

 

如果大家遇到過上述類似的問題,說明需要指標庫這樣的一套指標管理工具來規範指標的定義與維護。

 

問題1體現的是指標定義不夠清晰明確,兩個頁面上的指標定義其實是不同的,但是頁面上的看到的可能是同一個中文名稱或者名稱很類似,又或者同樣一個含義的指標在不同的界面上展示的名稱卻不相同,讓人產生歧義。

問題2體現的問題是同一個指標因爲由不同的數據開發同學來製作,可能會被重複開發,不但造成資源浪費,還會造成維護困難。

問題3體現的問題是對於需要新開發的指標

1、缺少現成的指標開發工具

2、該使用數倉中哪一層的哪些表,表情況和是否有什麼需要注意的?

3、甚至要數的同事都描述不清楚要的數據是什麼樣子的,然後一直讓出數據的同事返工

我覺得這太過分了,自己要什麼都說不清楚, 然後一直開發完讓別人返工!!!

 

隨着數據需求越來越多,並且要數的部門越來越多,指標定義混亂,描述不清,就會導致數倉同事工作被頻繁打斷,不停在跟新的人解釋某個指標是怎麼生成的,口口相傳是最可怕的(因爲會有巨大的時間成本消耗,並且可能會有誤差)

 

二、指標分類

當然,我說的分類僅僅是我個人的見解,大家也可以有各自的分類方式!

1、原生指標(不需要附加公式)

原生指標,指的是,做數倉的時候,我們做出來的一些基礎指標

例如:pv,uv,rank(按照某個字段排序),ratio(佔比),轉化率等,這類實際的,通用型的指標,計算方式全國甚至全世界都統一的指標,我們認爲是原生指標

2、衍生指標(需要自定義規則,添加公式生成的指標)

衍生指標 = 原生指標(可以是保存到表中的或者重新算的) +  修飾詞(where條件)+ 維度(group by )

這個就很多了,例如:各個公司可能會根據uv做出一些推及全網的各種指標(明顯使用了公式),某些效果,價值指標,甚至tgi可能也不是使用大家統一認定的公式生成的,

衍生指標一定要記錄相應信息:

中文,英文,使用公式/存儲過程,維度(日,周,月,或者其他維度),修飾詞(where條件),樣例模板sql,用於哪個產品,從哪張表開始存在,中文說明備註信息,製作人,生成時間,修改時間等

還需要根據各自公司的需求,去增加或者減少字段

順便提一句,同一類型的產品,所要計算的指標還是會比較類似的,比如做app產品,可能就會有活躍用戶,留存,新增,使用時長,用戶類型(輕度用戶,重度用戶),渠道(投放和收益分析)等,可以相互借鑑,這就偏數據分析了,不是本文的重點,所以我就提一嘴~

 

三、構建生成體系

生成指標的最簡單的方式,當然是給到相應的計算方法和表,讓數據需求方直接去表裏面跑個sql,獲得數據,導出到excel

但這樣的方式,未免太過簡陋,既沒有權限的控制,也會導致部分數據需求方水平不行sql寫的太爛,影響數據庫性能,影響正常的流程。

所以最好的方式是,能夠開發成一個平臺,讓數據需求方申請對應的表權限,選擇修飾詞,選擇維度,選擇原生指標,傳入公式,獲得想要的指標,並且提供不同的導出數據的方式

並且要思考下,如果用戶選擇的修飾詞,維度,原生指標已經生成過相應的指標,是否要提示用戶來避免重複開發和計算?

 

當然所有的工作,任務,都必須是要有意義的,並不能因爲想做而做,特別是數倉中的各個部分,必須是要能解決現實工作中遇到的各類問題,否則數倉只會變成雞肋,所有的職員都不願意用這套體系(因爲難用,或者其他原因),這樣耗時耗力做出來的數倉反而會變成給大家添麻煩的系統!!

 

好了數倉的系列應該到這裏告一段落了,當然每個人的理解都不一樣,我只是分享我自己的看法,如果大家有什麼問題,歡迎留言討論~

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章