Spark+Hbase 億級流量分析實戰（數據結構設計）

背景

靠文章生存的大廠們簡書/小紅書/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']
複製代碼

1. rowkey --------> 49|20190101000000000|f68a5c (時間+用戶ID) **設計原則：**能按時間維度查詢,並且還能打散數據。
2. 過時時間 30天 --------> 夠長的了,反正日誌源文件還在 **設計原則：**其實就是爲了避免佔用那麼多的存儲資源。
3. 預分區 -------->使用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']
複製代碼

1. rowkey --------> 49f68a5c8493ec2c0bf489821c21fc3b (用戶ID,前8位) **設計原則：**惟一性,經過ID能直接找到用戶信息。

如今還沒涉及到程序設計與實現篇章，後續將會在 "百億級流量實時分析統計" 系列文章中逐一實現。

---