数据仓库实战 1
数据仓库（Data Warehouse），是为企业所有决策制定过程，提供所有系统数据支持的战略集合。通过对数据仓库中数据的分析，可以帮助企业改进业务流程，控制成本，提高产品质量等。
数据仓库并不是数据的最终目的地，而是为数据的最终目的地做好准备，这些准备包括对数据的：清洗、转义、分类、重组、合并、拆分、统计等。
本次实战需求：
1、数据采集平台搭建
2、实现用户行为数据仓库的分层搭建
3、实现业务数据仓库的分层搭建
4、针对数据仓库中的数据进行留存、转化率、GMV、复购率、活跃等报表分析
技术选型：
数据采集传输：Flume，Kafka，sqoop，LogStash，DataX
数据存储：MySQL，HDFS，
数据计算：Hive，Tez，Spark
数据存储：Presto， Druid
数据架构图
框架版本选型
本次实战选用的是CDH7.1.1
集群资源规划
1、如何确认集群规模（假设每台服务器8T磁盘，128G内存）
每天活跃用户100万，每人一天平均100条 100*100=10000万条
假设每条日志1K左右，每天1亿条 100000000/1024/1204=约100G
半年内不扩容服务器来算：100G*180天 = 约18T
保存3副本：18T*3 = 54T
预留20%-30%Buf = 54/0.7 = 77T
大约8T * 10台服务器
数据生成模块
埋点数据基本格式
包括
•公共字段：基本所有安卓手机都包含的字段
•业务字段：埋点上报的字段，有具体的业务类型
下面是一个示例，表示业务字段的上传
{
"ap":"xxxxx",//项目数据来源 app pc
"cm": { //公共字段
"mid": "", // (String) 设备唯一标识
"uid": "", // (String) 用户标识
"vc": "1", // (String) versionCode，程序版本号
"vn": "1.0", // (String) versionName，程序版本名
"l": "zh", // (String) language系统语言
"sr": "", // (String) 渠道号，应用从哪个渠道来的。
"os": "7.1.1", // (String) Android系统版本
"ar": "CN", // (String) area区域
"md": "BBB100-1", // (String) model手机型号
"ba": "blackberry", // (String) brand手机品牌
"sv": "V2.2.1", // (String) sdkVersion
"g": "", // (String) gmail
"hw": "1620x1080", // (String) heightXwidth，屏幕宽高
"t": "1506047606608", // (String) 客户端日志产生时的时间
"nw": "WIFI", // (String) 网络模式
"ln": 0, // (double) lng经度
"la": 0 // (double) lat 纬度
},
"et": [ //事件
{
"ett": "1506047605364", //客户端事件产生时间
"en": "display", //事件名称
"kv": { //事件结果，以key-value形式自行定义
"goodsid": "236",
"action": "1",
"extend1": "1",
"place": "2",
"category": "75"
}
}
]
}
示例日志（服务器时间戳 | 日志）：
1540934156385|{
"ap": "gmall",
"cm": {
"uid": "1234",
"vc": "2",
"vn": "1.0",
"la": "EN",
"sr": "",
"os": "7.1.1",
"ar": "CN",
"md": "BBB100-1",
"ba": "blackberry",
"sv": "V2.2.1",
"g": "abc@gmail.com",
"hw": "1620x1080",
"t": "1506047606608",
"nw": "WIFI",
"ln": 0
},
"et": [
{
"ett": "1506047605364", //客户端事件产生时间
"en": "display", //事件名称
"kv": { //事件结果，以key-value形式自行定义
"goodsid": "236",
"action": "1",
"extend1": "1",
"place": "2",
"category": "75"
}
},{
"ett": "1552352626835",
"en": "active_background",
"kv": {
"active_source": "1"
}
}
]
}
}下面是各个埋点日志格式，我们以商品列表页为例进行说明，其他的埋点数据格式，可以参见我的。
事件日志数据
商品列表页
事件名称：loading
标签 | 含义 |
|---|---|
action | 动作：开始加载=1，加载成功=2，加载失败=3 |
loading_time | 加载时长：计算下拉开始到接口返回数据的时间，（开始加载报0，加载成功或加载失败才上报时间） |
loading_way | 加载类型：1-读取缓存，2-从接口拉新数据 （加载成功才上报加载类型） |
extend1 | 扩展字段 Extend1 |
extend2 | 扩展字段 Extend2 |
type | 加载类型：自动加载=1，用户下拽加载=2，底部加载=3（底部条触发点击底部提示条/点击返回顶部加载） |
type1 | 加载失败码：把加载失败状态码报回来（报空为加载成功，没有失败） |
模拟数据生成
本次实战我们无法获得生产环境下的埋点数据，因此我们写一些代码来生成模拟数据。
模拟日志行为数据的思路大致为：
for (i = 0; i < 10000; i++) {
switch(flag) {
case(0):
1.创建启动日志bean对象并赋值
2.将bean对象转换为json
3.控制台打印json
case(1):
1.创建一个json对象
2.向json中添加sp值
3.向json中添加cm值
4.随机向json中添加et值(一个事件一个函数)
}
}具体代码我放到了github上 https://github.com/SoundHearer/DataLake
我们将代码打包到cdh3节点，运行后，日志生成在/tmp/logs目录下
[root@cdh3 logs]# ll
total 2068
-rw-r--r-- 1 root root 1402227 Nov 23 18:38 app-2020-11-23.log
-rw-r--r-- 1 root root 710118 Nov 24 01:36 app-2020-11-24.log数据采集
首先我们采用LZO压缩方式，需要在CDH中配置HDFS启动LZO压缩。
LZO压缩 优点 压缩解压速度比较快 , 压缩率也可以 支持切片 是hadoop 比较流行的压缩格式 可以在linux 下安装 lzo命令 使用方便 缺点 压缩率比Gzip低一些 hadoop 本身不支持, 需要自己安装 使用Lzo 格式的文件时需要做一些特殊处理(为了支持 Split 需要建立索引 , 还需要家将 InputFormat 指定为Lzo 格式 [特殊] 使用场景 压缩以后还大于 200M 的文件 , 且文件越大 Lzo 的优势越明显 (原因很简单 , 四种压缩方式 只有BZip2 , Lzo支持切片 , 然后 BZip2 你懂的 , 速度贼慢 , 只能用于特定的场景, 所以 Lzo 是比较经常用的 ) 总结 : 压缩后文件还是比较大 需要切片的情况下 推荐使用
下载parcel包
[root@cdh1 GPLEXTERAS]# ll
total 3144
-rwxr-xr-x 1 root root 3207895 Nov 23 17:37 GPLEXTRAS-6.2.1-1.gplextras6.2.1.p0.4951328-el7.parcel
-rwxr-xr-x 1 root root 41 Nov 23 17:36 GPLEXTRAS-6.2.1-1.gplextras6.2.1.p0.4951328-el7.parcel.sha1
-rwxr-xr-x 1 root root 456 Nov 23 17:18 manifest.json配置parcel库
下载分配激活
在HDFS配置项中搜索“压缩编码解码器”，加入com.hadoop.compression.lzo.LzopCodec
在Hive配置项中搜索“Hive 辅助 JAR 目录”，加入/opt/cloudera/parcels/GPLEXTRAS/lib/hadoop/lib
在Sqoop的配置项中搜索sqoop-env.sh”，加入以下字段
HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/opt/cloudera/parcels/GPLEXTRAS/lib/hadoop/lib/*
JAVA_LIBRARY_PATH=$JAVA_LIBRARY_PATH:/opt/cloudera/parcels/GPLEXTRAS/lib/hadoop/lib/native
重启相关组件