首頁>Club>

22
回覆列表
  • 1 # 開悟科技

    資料處理的準確性校驗一直是個難題,是否存在一些針對據處理準確性的通用做法呢?

    下面是一些對於資料進行計算處理後,保證資料準確性的個人實踐:

    對於大部分資料來說,資料處理可以分為以下五個步驟

    1.資料採集;2.資料傳輸(實時/批量);3.資料建模/儲存;4.資料計算/分析;5.資料視覺化展示/挖掘

    針對上面五點分別展開介紹:

    一、資料採集

    1.針對不通的資料來源,需要做到每個資料來源獲取資料能夠獨立。

    2.採集過程需要監控,傳輸之前如有條件,可以做到本地有備份資料,便於異常查詢時進行資料比對。

    二、資料傳輸(實時/批量)

    資料來源本地已經做到有備份的情況下,對於傳輸異常的時候,需要支援重試,儲存端需要支援去重。

    三、資料建模/儲存

    資料儲存可以針對結果集合進行冗餘分類儲存,便於資料進行比對,針對儲存需要進行副本備份,同時資料可以考慮按生效記錄進行疊加儲存,支援回溯歷史的儲存結構進行儲存。

    四、資料計算/分析/挖掘

    資料進行計算,分析的時候需要進行步驟分解,便於準確性的分析和統計

    1.計算之前,支援測算,同時支援資料進行分批計算,需要能匯出本批次清單基礎資料(例如人員或者id),便於資料核對。

    2.計算之中,支援快速少量指定的典型資料測算,支援選擇,是否儲存參與計算過程的全部的中間變數。

    3.計算之後,可以選擇,支援匯出本次計算過程中的所有參與變數和中間變數引數,可以線下根據資料列表對應的引數,進行計算,從而進行資料準確性的核對。

    計算過程中,支援針對有問題的資料ID進行染色,染色後的資料,所有的中間過程變數全部進行列印輸出。

    五、資料視覺化展示

    視覺化挖掘過程,需要主要前臺圖形化介面的資料量

  • 2 # 資料分析不是個事兒

    從業多年,在資料準確性上摔過不少跟斗,總結了一些切實有效的方法,能夠幫你儘可能的規避錯誤,確保資料的準確性,分享給大家

    對資料上游的管理

    雖然看上去,資料分析師是掌握資料資源的人,但從資料的生產流程來看,資料分析師其實位於資料的下游,資料需要至少先經過採集環節、清洗環節、儲存環節才能被資料分析師拿到,甚至有的體量特別大的資料,他的調取和處理環節也不能被資料分析師控制。所以,想要最終做出的資料不出錯,那就要先確保我們的資料上游是準確的。

    雖然資料上游一般是由其他業務或技術人員負責,但資料分析師也可以通過提需求或生產過程參與的方式,對資料上游進行管理:

    採集環節,負責採集環節的業務或技術人員往往會把注意力聚焦在採集實現方式上,而忽略了採集來的資料本身對應的業務含義,資料分析師需要在這個環節上跟他們反覆說明根據業務含義反推出來的採集細節,確保大家在理解和實際執行上沒有偏差,最好在設定一些採集質量的控制點,幫助業務或技術人員做好採集工作。例如,APP的資料採集經常需要前端技術同學進行打點採集,這時資料分析師應該和技術同學一起討論打點方案的各個細節,比如“啟動”這個點對應的業務含義是想計算每天的活躍使用者數量,那麼啟動點的採集就應該既包含點選APP圖示啟動又包含後臺呼啟,其中後臺呼啟與上一次退入後臺的時間間隔應該至少大於30秒,否則可能被認為是使用者的正常操作而非完成一次使用後的退出,30秒也是根據業務實際情況人為討論設定的。清洗環節,分析師應該在確認採集環節的細節後跟數倉工程師溝通資料清洗的規則,比如某個欄位可能會含有某些方面的髒資料,需要通過何種規則被清洗掉。例如,打點採集上來的行為資料可能會因為使用者手機網路環境問題或其他前端原因而導致上報的行為時間戳錯誤,那麼清洗的時候就應該利用獲取到的資料上報時間戳去填充或直接去掉這條記錄。儲存環節,資料分析師應該根據具體業務的實際需求,向數倉工程師提出相關的結果表建表需求,和與之配套的排程需求,同時也可以利用上一節梳理過的資料分析指標體系參與到數倉結構規劃的討論中。例如,公司管理層需要每天關注的核心資料指標最好統一放在一張結果表裡儲存(為了提升BI的計算效率),管理層每天要在早上10點看到,那麼對應的資料分析師應該在早上8點看到(以便提前發現問題並留出修正時間),結合資料採集和數倉拉取時間那麼保險起見應該在7點完成底層表排程。調取環節,我建議資料分析師能夠梳理出一個常用的數倉表文檔,便於平時日常的資料調取,而如果用到相對陌生的表則應該先與數倉工程師溝通確認表的欄位含義、資料來源頭等再進行調取使用。處理環節,遇到體量比較大的資料需要藉助工程師進行處理時,應該先明確好資料處理的要求和步驟,最好落實成一個執行文件再交給工程師讓他按此進行處理,處理結束後要對資料結果進行核驗。設立資料“安檢站”

    “大包小包過機安檢”只要你坐過北京的地鐵,相信這句話一定耳熟能詳,為了確保所有旅客不把易燃易爆等危險品帶入地鐵內危及他人安全,地鐵在每個進站口設定安檢站對所有過往人員物品進行檢查。雖然避免資料錯誤的最主要方法就是檢查,但全流程無休止的資料檢查顯然是費時費力且效率低的,我們其實也可以在資料流入流出的關鍵節點設立“安檢站”,只在這個時候進行資料檢查。

    一般我會在這些地方設立“安檢站”:

    資料調取完成,如果原材料出錯,後面一切都錯,所以你需要把住資料流入的第一道關。資料處理完成,你需要利用資料處理後的結果進行分析判斷,如果處理結果出錯,你可能會因此錯失關鍵線索而在問題裡打轉,會浪費遠比你檢查一下資料而多的多的時間。資料報告撰寫完成,這是資料流出前的最後一道關,當然要仔細檢查一遍,出了這個“安檢站”,資料錯誤就會暴露在外無法再挽回了。

    幾種行之有效的檢查方法:

    直接核對,拿處理前和處理後的某條資料對比,雖然簡單粗暴,但對於一些關鍵資料的確認很有必要。勾稽關係驗證,利用資料與資料之間的邏輯或計算關係,來驗證資料的準確性。比如,A+B=C或者A>B>C。參照對比,跟歷史或同類資料對比,看看資料是否存在比較大幅的差異,如果出現差異又沒有對應的背景原因的話,那很有可能資料錯了。比如,平時的月新增使用者是30萬人,但最新一個月變成200萬,且這一個月並沒有追加大成本做推廣,那麼很有可能是資料錯誤。穿行測試,偷師審計中經常使用的一個方法,審計上的穿行測試(walk through testing)是指追蹤交易在財務報告資訊系統中的處理過程,而我們這裡的穿行測試是通過一個例項資料去檢查資料中的各個環節是否符合邏輯,比如用幾個少量的購買使用者ID去使用者活躍資料、使用者廣告瀏覽和點選資料、使用者購買資料等中去找他們實際的資料記錄看看與邏輯是否吻合。這個方法一般用在資料調取完成後的檢查。業務事實判斷,一個很鬱悶卻經常發生的事情——資料分析師檢查了幾輪都沒發現的錯誤,卻會被老闆輕易發現。老闆其實並不比分析師掌握更多的資料,他們只是對業務更熟悉,他們會根據業務的實際情況對具體資料有一個預判,比如某個商品昨天的銷量,資料分析師看到的只是個數字,而老闆看到的卻是這個產品經歷了怎樣的設計和討論、前期做過多少次頭腦風暴或市場調查、與之匹配的推廣投入是多少、同類型競品大概能賣出多少等等,這些事實讓那個簡單的數字變得豐富,而數字但凡出現一點點錯誤都會與那些歷歷在目的實時場景不符。我們可以學習老闆們的這一點,也找尋一些業務事實或者直接詢問業務人員業務情況來輔助我們對資料準確性做判斷。確保資料準確的幾個日常習慣

    除了上述成體系的錯誤規避手段外,幾個日常的好習慣也可以讓我們儘可能的離錯誤遠一點:

    養成資料監測習慣。每天要把重要的資料指標全部過一遍,最好能結合業務變化進行資料監測,這個過程可以通過寫每天的資料日報完成。很多重大的資料排程問題我都是靠資料監測發現的。先於其他人看到資料。每天儘量早點到辦公室,在其他同事尤其是老闆還沒開啟每天的BI報表之前,先看到資料,如果發現問題能夠及時糾正或至少能先行通報資料錯誤。別太相信自己的記憶。人腦不是電腦,一定有記不清記不準的情況,所以如果能有足夠的時間查詢一下資料,就別自己靠記憶去回答資料問題。儘量為自己爭取多一點時間。很多錯誤往往是我們準備時間不夠,慌亂中壓力大容易錯,又缺少必要的實際檢查,所以儘量為自己爭取多一點資料準備的時間是很有必要的。永遠帶著電腦。既然不能依靠人腦,那就只能依靠電腦,在任何可能會發生資料查詢的時間和空間內最好都帶著你的電腦。如果發現數據錯誤,一定要及時承認並在第一時間修正,如果想掩飾一個錯誤,那麼就可能會引發更多的錯誤。

    以上,是確保資料準確的大致經驗總結,幾句最關鍵的話再重複嘮叨一下:

    信任是資料分析師立足的根本,一點點的資料錯誤就可能將積累了幾年的信任迅速毀掉。永遠別忘記檢查,無論時間多緊迫,無論任務難度多小,無論資料提供給誰資料分析是個“勤”行,一定要儘可能深入業務和技術的各個層面,一定要跑在別人看資料的前面。

  • 中秋節和大豐收的關聯?
  • 快30歲了,失業了怎麼辦?