數倉整體說明:
1.1使用到的技術
使用flume進行資料採集,hdfs為儲存平台,hive進行操作,sparksql為技術引擎,yarn作為資源排程平台,rookeeper為任務排程平台,altas管理元資料,
1.2分層設計
ads為服務層
dwd為數倉彙總層,
ods詳細設計:公司使用者規模一般在1000萬左右,平均日活400萬,這個還要根據後面所在格式具體情況而定,每個使用者平均訪問1.2次,訪問時長大概在10分鐘左右,每天產生的日誌大概在3億條,然後每條日誌大概在0.5k,每日增長144g,每月大概在4.3t,每月估計增長在20%左右,ods運算元據
dim儲存維表
ods:存放flume採集過的原始資料,
主要是對進行ods層資料做etl處理後的資料扁平化處理,以parquet檔案格式儲存,一般大概在3-6個月
使用flume從kafka裡面進行採集,
我們會把使用者,產品,活動,等一些資訊存放到mysql中,
dwd層詳細設計在這個環節由於etl的需求較為複雜,用sql實現較為困難,因此這個環節我們是用spark來實現的,
這個過程主要做一些資料清洗
比如使用session分割,對資料進行規範化處理,比如資料有空字串就統一為null,進行標識,
維度整合
比如講日誌中gps經緯度座標解析成省,市,縣,這樣比使用ip位址進行定位更為精確,在如何解析地理位置上,我們用了geohash編碼技術,(也是一種演算法)將經緯度座標轉化為乙個個字串,
[gerhash編碼不斷通過二分法來劃分舉行範圍] 從而來生成0/1二進位製碼,並且聲成的字串長度越長,表達的精度越高,越逼近jps
的具體座標
[gerhash編碼不斷通過二分法來劃分舉行範圍] 從而來生成0/1二進位製碼,並且聲成的字串長度越長,表達的精度越高,越逼近jps
的具體座標
1.當時我們開始就使用裝置id,因為大部分的使用者都只有乙個id賬號,所以通過這個就可以識別使用者,但是他也有缺陷,比如同一使用者在不同裝置使用會被認為是不同使用者,
反之,不同使用者使用相同裝置,
或者多使用者在裝置不足的情況下共同使用裝置,都會對後續的分析統計帶來影響,
2.關聯裝置id和登入id(一對一) 一台裝置可能有多個使用者進行使用,乙個使用者可能使用乙個id在多台機器上使用,但是在識別的時候還是算最初哪台機器的id號,這樣也會有一定的侷限性,
3.關聯裝置id和登入id(多對一的關係)
之後，使用者在多裝置下的行為就會貫通，被認為是乙個id 發生的。
但也有侷限性,但是一台裝置可能有多個使用者進行登入,
因此我們最後選擇的方案是關聯裝置id和登入id進行動態關聯,
就是乙個裝置id被繫結到乙個登入id之後,如果該裝置在後期被其他使用者頻繁的使用,則該裝置會重新繫結到其他的id中,
具體操作就是:比如每個裝置第一次被使用者登入,那麼就與該使用者進行繫結並且使用打分制打100分,如果後面這個裝置被其他使用者登入,那麼也使用打分制但是以十分的間隔逐漸減少的形式進行打分比如打90分,這時候,裝置id還是和第乙個使用者id進行繫結,如果後面還是第二個使用者進行登入那麼給他打80 ,通過累加可知,使用者第二個使用者比第乙個使用者的份數多,這樣該裝置就接觸與第乙個使用者的繫結,從而與第二個使用者進行繫結,後面根據這樣的思路進行操作
我的工作日誌1
來這家公司三周了 工作基本進入正軌 也已經熟悉了周圍的生活。工作有條不紊的進行中，大面上完成的還可以吧，但具體細節方面，依然很亂，例如控制項大小，驗證，什麼情況下可用，什麼情況下不可用，這些都要慢慢完善，等待開會統一中，呵呵。因為很多地方需求並不完善，boss 們還在討論中，我們只是在開發需求相對比...
我的工作日誌1
來這家公司三周了 工作基本進入正軌 也已經熟悉了周圍的生活。工作有條不紊的進行中，大面上完成的還可以吧，但具體細節方面，依然很亂，例如控制項大小，驗證，什麼情況下可用，什麼情況下不可用，這些都要慢慢完善，等待開會統一中，呵呵。因為很多地方需求並不完善，boss 們還在討論中，我們只是在開發需求相對比...
資料倉儲1 數倉的意義
在進行資料分析的時候，我們總會遇到一些名詞，比如資料倉儲。資料倉儲是資料分析中乙個比較重要的東西，資料倉儲是乙個面向主題的 整合的 相對穩定的 反應歷史變化的資料集合。下面就說一下資料分析中的資料倉儲。對資料分析的理解大家應該都是比較熟悉的，資料分析的流程有很多，首先需要進行對業務的理解，然後就是對...