背景

靠文章生存的大厂们简书/小红书/CSDN(PS:好吧你们仨记得给我广告费)对优秀的文章进行大数据分析的工作必不可以少了本系列文章将会从关于文章的各个维度进行实战分析这系列文章新手可借着踏入大数据研发的大门至于大数据的大佬们可以一起来相互伤害至少为什么取名为 ‘‘百亿级流量实时分析统计’’ 看完后整个系列的文章你就知道了相信大家都是会举一反三的孩子们。

作者

网名大猪佩琪

姓名不晓

年龄不知

身高不祥

性别男

日志结构

日志存储结构设计如下肯定很多小伙伴要问为什么设计成JSON形式多占空间多…

统一回复可读、易排查

{

    "time": 1553269361115,

    "data": {

        "type": "read",

        "aid": "10000",

        "uid": "4229d691b07b13341da53f17ab9f2416",

        "tid": "49f68a5c8493ec2c0bf489821c21fc3b",

        "ip": "22.22.22.22"

    }

}

参数

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能直接找到用户信息。

现在还没涉及到程序设计与实现篇章后续将会在 “百亿级流量实时分析统计” 系列文章中逐一实现。