產品視角下的資料倉儲
作為一名資料產品經理,看過很多關於數倉建設的文章,這些文章大多是資料工程師所寫,旨在透過通俗易懂的語言告訴大家為什麼要建數倉,建數倉的過程中需要注意哪些事項;今天希望站在資料產品經理的視角來和大家聊一聊數倉建設過程中的幾點事項,視角不同,可能提出的觀點也有所偏差,歡迎大家提出建議,多多交流。
01、數倉主要面向人群是誰
資料產品經理中有一群專門負責數倉建設的產品經理,他們活躍在各個業務中,收集著各類資料需求,最後沉澱成一張張資料表,這一過程中,資料產品經理的需求方主要有(下文中所有資料產品經理均指負責數倉建設方向的資料產品):
1、資料分析師
資料分析師作為業務線最懂資料的人,常年幹著各種髒活累活,比如跑數、搭報表,他們直接面向業務,承接著來自產品、運營、市場等各個方向的各種需求,當他們需要跑某份資料的時候,如果資料表混亂,會降低他們取數的效率,因此資料分析師會經常給資料產品經理提需求,希望建標準數倉表,統一資料標準。
2、商業分析師
這是一群聽起來比較高大上的存在,和資料分析師相比,他們在商業分析上更加專業,他們的需求主要來源於領導層,然後圍繞某方向進行專題分析,構建商業分析框架,從而實現全維度商業分析;商業分析師進行分析所依賴的就是數倉建設的一張張表,尤其是上層的ADS(應用資料層)表,如果這些表說明不準確,存在歧義,會影響他們分分析結果,因此商業分析師也是資料產品經理的需求方;
3、業務產品經理
作為產品的締造者,每一個業務產品經理都想知道自己的產品怎麼樣,使用者反饋如何,很多時候他們會直接向資料分析師提需求,同時也有一部分勤奮好學的業務產品經理會自己去進行跑數,此時他們對於數倉的訴求更多的是想弄清楚他們想要的資料在哪張表裡,表裡的每個欄位代表什麼意思;
4、運營
隨著資訊科技的發展,運營這個崗位越來越細分,有產品運營、活動運營、使用者運營、社群運營等等,不論哪種運營,他們工作中很重要的一個事情就是檢視資料,透過資料對一次活動進行全方位分析,來評估本次活動的收益和效果如何,以便於制定後續的決策。
以上,是數倉主要面向的人群,在這裡沒有寫研發工程師,主要是因為研發工程師也是因為業務產品經理或運營提的需求來向資料側提需,其實最後都是面向產品、運營。
02、數倉主要解決他們的什麼問題
1、降低取數門檻
由於ods層表命名沒有統一規範,資料格式混亂,業務產品經理、運營、資料分析師想要跑一份數的時候,需要諮詢很多人,才能知道某個資料儲存在哪個表裡;然後還要多次確認各個欄位的含義才能最後得到自己想要的資料,整個過程比較繁瑣,存在一定門檻;
透過建設標準數倉,我們會統一資料標準,對每個標準給出準確釋義,幫助使用者快速定位欄位,並瞭解欄位的真實含義;同時將各業務系統資料互聯互通,打破資訊壁壘,降低取數門檻。
2、提升工作效率
在沒有標準數倉的時候,不論是資料分析師還是商業分析師,想要獲取一份資料都需要耗費大量的時間,透過編寫大量的SQL獲取目標資料;
透過建設標準數倉,根據商分、數分的訴求,將資料按照既定的主題進行彙總,透過彙總表的建設,大大降低資料分析師、商業分析師、業務產品經理、運營的取數時間,讓他們有更多的精力去進行資料分析,發現資料背後的問題並制定相應的策略去調整。
3、減少業務調整對上層應用的影響
在沒有數倉時,資料分析師的報表主要依賴於原始ods表,這時如果業務發生調整,此時對應的ods表也會發生變更,此時資料分析師也需要去調整依賴這些表的報表,後續維護成本較高;
透過建設標準數倉,我們將一些公共處理邏輯在dwd層處理掉,數分直接使用dwd層,降低ods層變化對上層報表的影響;
03、我們建的數倉有哪些注意事項
1、資料標準的統一
現有訂單表和登入表,登入表中儲存了使用者ID,欄位名為user_id,訂單表中也儲存了使用者ID,欄位名為uid。此時兩個表中包含的使用者ID均是同一內容,但是使用了兩種不同的欄位名進行描述,欄位出現了歧義便需要人工介入理解進行確認。
所以在建設初期,我們就可以根據業務的梳理,明確資料標準,統一資料格式,在後續的建模過程中統一引用該標準。
2、欄位釋義要準確
欄位一般有屬性、維度、度量三種,我們需要根據每種欄位的特性進行專門的釋義;
(1)屬性:主體的某種屬性,假設主體是使用者,那麼使用者姓名就是使用者的一種屬性,此時需要對這一屬性進行說明,比如使用者姓名是怎麼獲取的,代表什麼意思,如果某屬性是透過資料探勘得來的,需要說明挖掘的規則是什麼;
(2)維度:這是表中最常見的一種欄位,比如使用者性別、城市等;這類欄位經常被用於對比分析;這時我們需要對這一欄位進行解釋說明,告知使用者性別是什麼欄位,如果可列舉,需要給出具體的列舉值,方便後續分析師使用,比如性別,需要給出列舉值男、女、未知;
(3)度量:度量欄位在彙總表中常見,度量也等同於指標,主要用於明確業務統計口徑和邏輯;此時在該欄位的釋義中需要說明計算邏輯和口徑,便於使用者檢視時可以明確對應的計算規則;比如活躍使用者數,需要特別說明活躍的口徑是什麼,是否有過濾掉哪些資料,這些都需要在這裡明確說明;或者將該欄位和資料指標進行聯動,能夠讓使用者檢視該欄位對應的指標定義。
3、血緣清晰
需要把該表的上下游依賴透過清晰的方式呈現出來,便於使用者瞭解該表的上下游依賴,尤其是上游依賴,當資料沒在既定時間就緒時,可以快速進行問題的追蹤定位;
4、支援資料預覽
當使用者檢視某表時,我們直接提供資料預覽的功能,便於使用者快速檢視錶中的資料樣例,好確認資料是否和自己想象的一致。
當我們做好這一切,接下來就是持續建設了,作為一名資料基建的產品經理,旨在透過我們的工作,推動業務資料化和資料業務化,讓資料發揮最大的價值。
來自 “ 一個資料人的自留地 ”, 原文作者:@奈文摩爾;原文連結:https://mp.weixin.qq.com/s/ybbzHPxJ7TzagwJ1ta6YsQ,如有侵權,請聯絡管理員刪除。
相關文章
- AI產品視角下的ChatGPTAIChatGPT
- PayPal如何將Teradata資料倉儲遷移到BigQuery實現產品分析
- Oracle自治資料倉儲榮獲2018年度創新產品獎Oracle
- 大資料小視角1:從行儲存到RCFile大資料
- 資料庫倉庫系列:(一)什麼是資料倉儲,為什麼要資料倉儲資料庫
- ETL資料倉儲的使用方式
- 資料倉儲 - ER模型模型
- [數倉]資料倉儲設計方案
- 資料倉儲與大資料的區別大資料
- 關於資料湖、資料倉儲的想法
- 資料倉儲應該用什麼方案——資料倉儲實施方案概述
- 資料湖和中央資料倉儲的設計
- 什麼是資料倉儲
- 什麼是資料倉儲?
- 資料倉儲經驗概念
- 資料倉儲建模方法論
- 淺談資料倉儲和大資料大資料
- 資料湖會取代資料倉儲嗎?
- 談談資料湖和資料倉儲
- 資料湖 vs 資料倉儲 vs 資料庫資料庫
- 資料中臺以及資料倉儲的介紹
- 資料倉儲(6)數倉分層設計
- 資料倉儲(7)數倉規範設計
- 資料儲存-領存高速海量資料記錄儲存模組產品介紹
- 黑馬PM- B端產品-倉儲模組設計
- Oracle資料倉儲的實時資料採集XSOracle
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 使用資料倉儲BI的6種策略
- 基於OneData的資料倉儲建設
- 資料倉儲基礎介紹
- ABP 資料訪問 - IRepository 倉儲
- 資料倉儲題庫(附答案)
- 如何構建資料倉儲模型?模型
- 資料倉儲之拉鍊表
- 大資料和資料倉儲解決方案大資料
- 資料倉儲被淘汰了?都怪資料湖
- 儲存所有歷史提交資料下遷移git倉庫Git
- 迪斯尼樂園詮釋資料倉儲最佳實踐(下)WE