背景
靠文章生存的大廠們簡書
/小紅書
/CSDN
(PS:好吧你們仨記得給我廣告費),對優秀的文章進行大數據分析的工作必不可以少了,本系列文章將會從關於文章的各個維度進行實戰分析,這系列文章新手可藉着踏入大數據研發的大門,至於大數據的大佬們可以一起來相互傷害,至少爲什麼取名爲 ‘‘百億級流量實時分析統計’’ 看完後整個系列的文章你就知道了,相信大家都是會舉一反三的孩子們。
作者
網名:大豬佩琪
姓名:不曉
年齡:不知
身高:不祥
性別:男
日誌結構
日誌存儲結構設計如下,肯定很多小夥伴要問爲什麼設計成JSON
形式?多佔空間?多…
統一回復:可讀、易排查
{
"time": 1553269361115,
"data": {
"type": "read",
"aid": "10000",
"uid": "4229d691b07b13341da53f17ab9f2416",
"tid": "49f68a5c8493ec2c0bf489821c21fc3b",
"ip": "22.22.22.22"
}
}
參數
名稱 | 值 | 說明 |
---|---|---|
time | 精確到毫秒 | 時間 |
type | login:登錄 /register:註冊 /read:閱讀 /like:喜歡 /comment:評論 /share:分享 /reward:讚賞 /publish:發佈文章 /update:發佈更新 /private:設置私密 /delete:刪除 |
|
aid | 數字 | 文章編號 |
uid | uuid | 用戶編號 |
tid | uuid | 用戶臨時緩存編號 |
ip | ip | IP地扯 |
Hbase結構
日誌表
create 'LOG_TABLE',{NAME => 'info',TTL => '30 DAYS',
CONFIGURATION => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.KeyPrefixRegionSplitPolicy','KeyPrefixRegionSplitPolicy.prefix_length'=>'2'},
COMPRESSION=>'SNAPPY'},
SPLITS => ['20', '40', '60', '80', 'a0', 'c0', 'e0']
- rowkey -------->
49|20190101000000000|f68a5c
(時間+用戶ID)
**設計原則:**能按時間維度查詢,而且還能打散數據。 - 過期時間 30天 --------> 夠長的了,反正日誌源文件還在
**設計原則:**其實就是爲了不佔用那麼多的存儲資源。 - 預分區 -------->使用
rowkey
前兩位,00~ff=256 個region
,表示現在的業務已經可以滿足要求。
**設計原則:**是爲了能儘量打散數據到各臺Region Server
。
用戶表
create 'USER_TABLE',{NAME => 'info',
CONFIGURATION => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.KeyPrefixRegionSplitPolicy','KeyPrefixRegionSplitPolicy.prefix_length'=>'2'},
COMPRESSION=>'SNAPPY'},
SPLITS => ['20', '40', '60', '80', 'a0', 'c0', 'e0']
- rowkey --------> 49f68a5c8493ec2c0bf489821c21fc3b (用戶ID,前8位)
**設計原則:**唯一性,通過ID能直接找到用戶信息。
現在還沒涉及到程序設計與實現篇章,後續將會在 “百億級流量實時分析統計” 系列文章中逐一實現。