背景
靠文章生存的大厂们简书
/小红书
/CSDN
(PS:好吧你们仨记得给我广告费),对优秀的文章进行大数据分析的工作必不可以少了,本系列文章将会从关于文章的各个维度进行实战分析,这系列文章新手可借着踏入大数据研发的大门,至于大数据的大佬们可以一起来相互伤害,至少为什么取名为 ''百亿级流量实时分析统计'' 看完后整个系列的文章你就知道了,相信大家都是会举一反三的孩子们。
作者
网名:大猪佩琪
姓名:不晓
年龄:不知
身高:不祥
性别:男
日志结构
日志存储结构设计如下,肯定很多小伙伴要问为什么设计成JSON
形式?多占空间?多...
统一回复:可读、易排查
{
"time": 1553269361115,
"data": {
"type": "read",
"aid": "10000",
"uid": "4229d691b07b13341da53f17ab9f2416",
"tid": "49f68a5c8493ec2c0bf489821c21fc3b",
"ip": "22.22.22.22"
}
}
参数
名称 | 值 | 说明 |
---|---|---|
time | 精确到毫秒 | 时间 |
type |
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|20190101000000|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)
设计原则:唯一性,通过ID能直接找到用户信息。
现在还没涉及到程序设计与实现篇章,后续将会在 "百亿级流量实时分析统计" 系列文章中逐一实现。
百亿级流量实时分析统计下篇文章 [ 百亿级流量实时分析统计 - 数据结构设计 ]
网友评论