tft每日頭條

 > 科技

 > 數據治理的難點和困難

數據治理的難點和困難

科技 更新时间:2025-02-26 04:11:54

如果你常常對數據準确性而煩惱,大部分時間都用于處理數據而不是對業務進行思考分析的話,那麼你需要好好對數據進行治理了。

數據治理的難點和困難(有效數據治理的6大原則)1

一、為什麼要進行數據治理

不知道你是否有這樣的感受,看到數據後,一臉懵逼,不知道各個表和字段代表什麼意思,再看看别的同事寫的SQL,一條SQL語句有幾百行,各種表關聯,然後問了其中一個同事,他說“别提了,數據都不準,我快被數據折磨死了!”,此時你是不是“想死”!欲哭無淚……

究其背後的原因,是因為負責的人隻是問題使然,哪有問題哪裡去補,沒有整體的統籌規劃,一步錯,步步錯,數據最後是越來越重,查詢越來越複雜,數據準确性還沒有人敢打保票,同時修複的難度也大大增加。

二、如何進行數據治理

如果要想将數據治理好的話,需要遵循以下六大原則、合理制定數據中間表模型以及埋點采集到應用全流程的把控。

1. 六大原則

原則1:關鍵概念多方共識

關鍵概念若涉及多方,比如成交客戶的定義,要确保公司内部和客戶相關的所有業務人員理解一緻。

你或許會說,成交客戶還不好理解麼,就是購買了我公司産品且簽署合同的用戶就是一個成交客戶,但是實際情況遠非如此,筆者當時處理該塊的業務時,問不同的業務人員得到的結果都不一樣,這樣就造成了數據指标統計的歧義甚至數據的不準确。

  1. 當一個合同主體變換名稱(含工商注冊名稱變更、更換簽約公司等),那麼這個客戶算一個成交客戶嗎?
  2. 同一個 集團/公司 下,不同的 子公司/業務線/部門 用同一個名字簽署多個不同合同,屬于單個成交客戶還是多個成交客戶?
  3. 當合同還在「待确認」或未拿到合同編号時,如果客戶運營人員已經開始服務客戶,那麼這個客戶算一個成交客戶嗎?……

原則2:某個類型的值經常發生變動,則需要冗餘一個通用字段冗餘值

筆者是深受其害,以前每個月底都需要找開發、業務人員對一遍數據,舉個例子:

查詢原始指标:soure_type為A,B的任務産出的金币數額為消費指标,SQL已針對該指标做了類型篩選。某一天業務運營人 員上線新的任務,C類型的任務會貢獻金币流水,但是開發未告知數據人員,導緻原來的關鍵指标數值出現差錯。

處理過數據的同學都知道,某個指标的實現可能和其它幾個關鍵指标相關,那麼該指标的異常排查就需要逐個檢查是哪個相關指标出問題了,查找到原因可能2,3天的時間就沒了,但如果事先開發人員冗餘了一個通用字段代表該類消費指标,那麼後續不管業務人員上線多少個消費類型的任務,都不會對原來的指标産生影響。

原則3:每個實體都有唯一、不變的ID,最好沒有實際意義

一是為了實體的唯一性,二是為了表關聯或更新時不受業務的影響。

原則4:涉及協作的數據,發現問題要從修改源頭做起,保證下一次拿到正确的數據

協作的數據可以說是一個串聯的過程,源頭的數據會逐層影響下層的數據,不要為了一時方便,隻修改目前發現問題的地方,要從修改源頭做起,方便他人即方便自己。

原則5:編寫操作清單,操作前請三思

數據間存在關聯,把數據間的關聯關系陳列清楚、注意事項标注清楚,操作前一一核對,小數據量驗證無錯後,大數據量執行。

原則6:系統工程的方法管理數據,盡可能使用系統,監控數據錯誤并及時修複。

将使用數據的相關方都畫在一張系統循環圖中,觀察數據錯誤産生于系統哪個環節,如何影響後續各個環節,避免惡性循環的産生。

2. 合理制定數據中間表模型

一款産品的存在是為了解決某類用戶群體的需求痛點,并在此基礎上進行盈利;數據分析的存在也是為了輔助挖掘和發現潛在用戶需求并進行優化和運營。

而數據的準确性和數據查取的效率依賴于底層的數據采集和中間層的數據中間表的構建。

關于底層的數據采集方法詳見:産品經理給開發提埋點需求的正确姿勢

用戶的需求隐藏在用戶行為中,從聚合用戶行為的角度構建數據中間表方便數據查詢和分析。

用戶行為分析模型

以用戶觀看短視頻這個用戶行為來說

數據治理的難點和困難(有效數據治理的6大原則)2

  • WHO:即觀看視頻的人是誰,可以唯一标識用戶身份,如設備ID,注冊後的用戶ID。如果和第三方合作的話,可以對一個用戶生成一個唯一标識ID,用戶串聯設備ID和注冊後的用戶ID。
  • WHEN:觀看視頻發生的實際時間,一般會記錄客戶端時間和服務端時間。
  • WHAT:即用戶觀看視頻這個行為。
  • HOW:記錄用戶觀看視頻的方式,如所在頻道、觀看時長、視頻類型等等
  • WHERE:記錄用戶在哪個省份、城市、IP下觀看視頻的,同時還會記錄網絡類型、應用版本、操作系統等其它環境信息。

構建包含完整用戶行為的數據中間表

構建好的業務指标體系的高效計算和快速有條理展現依賴于數據倉庫中間表的建設,若中間表設計不合理,就會導緻滿足基本業務分析需求時一步不能計算出來且邏輯關聯多導緻實時計算等待時間過長,這樣就增加了數據分析的等待成本以及業務人員查詢的成本。

所以一張數據中間表應該包含用戶完整的行為信息和動态屬性信息,而要描述用戶的完整行為就需要按照用戶行為模型記錄上述信息,但實際情況是,我們所記錄的表數據是分割的。

比如,觀看視頻這個表一般隻會記錄和視頻相關的信息,用戶的How、WHERE信息會分部在其它表中,這樣就增加了表關聯的複雜度,邏輯複雜不利于分析,所以我們需要構建一個用戶行為中間表,裡面包含了上述5個方面的詳細信息。

同時通過事件名稱冗餘某一類的埋點行為數據,如可将金融相關的埋點,作為值傳給事件名稱,這樣查和金融相關的埋點數據時隻查這一張中間表即可。

除了用戶行為類的中間表外,還有一張存儲用戶基本信息的,因為除了和用戶行為相關的動态信息外,還有專屬于該用戶的靜态信息,如年齡、性别、注冊時間、注冊地等。

3. 埋點采集到應用全流程框架

數據中間表的數據底層來源于基礎埋點數據,基礎埋點數據的準确性是基礎中的基礎,而埋點數據的采集往往會涉及産品方、數據方、業務方、技術方,四方配合不好的話,就會影響數據的準确性,到需要用數據時發現數據采集錯誤,隻能等待下次發版修改,效率低下,延誤時機。

故需要梳理一套埋點流程規範,以提高整個配合過程的效率、數據準确性、業務支持的及時性。

數據治理的難點和困難(有效數據治理的6大原則)3

若有數據産品角色,第二部分主要由數據産品負責,數據分析師要密切配合數據産品,因為最終需要分析數據的是數據分析師。

數據治理的難點和困難(有效數據治理的6大原則)4

三、數據治理後的數據狀态是怎樣的?

我想,數據治理好後,起碼可以省50%的數據修改反複的時間,将更多的精力用在業務分析上,同時數據是準确的,可以正确引導業務決策。

另外降低了SQL複雜度,産品運營等業務人員可以通過簡單的SQL查詢所要看到的指标。常用指标有:次數、人數、人均次數、總金額等數值指标,再結合數據中間表中構建的各種維度,就能實現多維交叉分析。

最後舉個SQL實現例子:

select ymd,cc,count(*) ,count(distinct uid) from table_name where ymd between ‘20190701’ and ‘20190712’ and event_type=’clicktask’ group by ymd,cc order by ymd desc;

作者:北極星,神策數據分析師,知乎專欄:數據分析方法與實踐,緻力于通過數據分析實現産品優化和精細化運營。

本文由 @北極星 原創發布于人人都是産品經理。未經許可,禁止轉載

題圖來自 Unsplash ,基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!

查看全部

相关科技资讯推荐

热门科技资讯推荐

网友关注

Copyright 2023-2025 - www.tftnews.com All Rights Reserved