這是學習筆記的第 2269 篇文章後端
讀完須要微信
速讀僅需7分鐘app
最近和幾個同事聊了下關於數據的一些問題，有一個問題引發了個人好奇。那就是數倉體系和大數據體系的數據質量差別。學習
由於各類緣由，一份數據可能會被多處消費使用，有的用做精確數據可視化，好比報表，對帳單等，實時性要求不是很高，通常是T+1的模式，有的用做趨勢分析，或者潛在問題分析，對於數據集的時間週期要求較高，有些須要在海量數據中挖掘更多的數據價值，讓單一的數據經過鏈接產生更多維度的意義，整體來講，你們對數據質量的須要不盡相同，有些人主要關注數據的準確性和一致性，有些人則關注數據的實時性和相關性，所以，只要數據能知足使用目的，就能夠說數據質量符合要求。大數據
來講說困擾個人數據質量疑問，來自於兩撥人的反饋。spa
第一撥人是大數據方向的同事，他們反饋數據的準確性有時候很難保證，致使在作數據稽覈和一些數據統計中，和真實數據的差別較大，這樣也會致使一些工做比較被動，業務側對此的信任度也會大打折扣，而縱觀整個數據鏈路，有些已經能夠實現實時流轉，卻很難直接點出某一處存在明顯瓶頸。
.net
而另一撥人則是作數據統計方向的，他們對於數據有着自然的敏感性，他們對於數據的準確性要求很高。他們反饋數據質量的時機相對要早一些，不過不多反饋數據質量問題，通常就是數據問題須要補錄數據，從新跑一些數據任務。
日誌
讓第一撥人最糾結的是，整個數據流轉的團隊是同一批人，可是數據質量差異卻這麼大。
orm
在個人理解中，數據倉庫體系應該是大數據體系的一部分，或者說是前哨站，經過和兩撥人的溝通，個人小結以下：
blog
1）爲何統計方向的數據倉庫體系的數據準確性要高一些，主要緣由是它們對於數據質量有一套很清晰的評判標準，而且可以反向推進數據流轉體系完善數據質量，好比一張表中的數據有1000萬條，須要流轉到數倉體系，會有多個維度的校驗，好比自增ID,好比ID連續性,數據加載日誌，數據預處理日誌，數據處理日誌，每一步都會詳細的記錄這些數據處理的進度，對於數據流轉體系來講，極可能會有一些數據問題，可是不管是格式仍是數據值，若是出現誤差，在統計體系中會更容易識別和分析出來，而這種反向做用力也能夠促使流轉技術體系不斷的迭代升級，一旦出現問題，能夠要求從新提供數據，這勢必對後端的服務要求也會高一些，即數據處理的冪等性問題。
2）大數據體系的數據質量相對來講難以保障，一方面是由於大數據體系的工做大多數是數據的搬運工，能夠從系統，規劃等層面提出一些數據標準和規範，可是他們每每不是數據使用方，或者說他們的數據使用方對於數據的準確性沒有那麼敏感，因此這方面的把控力有限，也不多聽到大數據側會進行數據補錄的工做。
3）有不少公司的統計數倉體系和大數據體系是割裂的，致使不少統計側的數倉體系存儲容量大到不須要下沉數據到大數據，而大數據側會重複處理同一份數據，多是不一樣的數據通道。
4）對於數據使用的角色定位不夠清晰，好比要求統計體系提供一些數據挖掘，數據趨勢的分析等，或者要求大數據提供很精確的數據報表等，除非整個數據鏈路足夠健壯，有彈性，不然這種定位和角色很難讓你們都找準本身的位置，相反可能會由於業務而產生爲了上某一個技術而硬上的情形。
大家公司的數倉體系和大數據是怎麼玩的，歡迎留言。
QQ羣號：763628645
QQ羣二維碼以下， 添加請註明：姓名+地區+職位，不然不予經過
訂閱個人微信公衆號「楊建榮的學習筆記」，第一時間免費收到文章更新。別忘了加星標，以避免錯過新推送提示。
本文分享自微信公衆號 - 楊建榮的學習筆記（jianrong-notes）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。