数仓项目笔记-20200817

一、项目整体背景

1、数据仓库
作为数据的管理和运算中心；
数据存档；
各种统计、运算任务的核心平台；

2、用户画像系统
含义：深入分析用户后给用户打上各种规范标签：年龄，性别，地域特征，偏好特征，价值指数，行为习惯，消费习惯…
作用：对用户进行精准营销，用于支撑精细化营运；

比如，针对不同的人群发放不同的优惠券；
比如，针对不同的人群定制不同的打折规则；
比如，针对不同的人群推行不同的营销活动；
比如，针对流失概率大的人群进行挽留；

3、推荐系统
含义：对不同的人，在不同的场景中，推荐不同的物品的系统
手段：可以根据用户画像及物品相似度，可以根据协同过滤算法等推荐算法
作用：改善用户体验，增加销量
本数据处理系统可以使用离线计算方式实现，也可以使用实时计算方式实现；
更多的是离线和实时结合起来实现；
公司一般会根据不同的需求场景，灵活使用离线和实时技术：

离线：系统化的，计算的数据时间跨度长的，运算量大的任务
实时：对时效要求高的需求

二、项目整体架构

1、预处理
构建各类字典（维表），比如：

地理位置字典
页面信息字典
商品信息字典
用户信息字典
GUID字典（全局用户唯一标识）等
对用户行为事件埋点日志进行数据清洗、解析、通用维度集成、GUID标识等运算

2、数据仓库ODS层
ODS层存储的是源数据；
各类埋点日志表：
各类业务表：

3、数据仓库DWD层：
DWD层相对于ODS层的主要变化为，将ODS中的事实数据中某些字段进行进一步拆分，便于后续查询处理；将ODS中的事实数据集成常用的通用维度信息，比如事件维度类信息

4、数据仓库DWS层
对DWD层的表进行轻聚合运算所得到的各类结果

5、数据仓库ADS层
根据数据分析需求设计出来的各种最终结果表

数仓概念篇1

一、什么是数据仓库

通俗来说，数仓就是一个数据备份和数据分析的系统，不同于数据库

二、报表vs数据可视化vs ETL

报表即统计计算结果，也就是一张数据库表，一般存储在mysql中

所谓可视化，就是将数据库中的数据表，以更友好的方式展（比如图，比如表格）现在一些“界面”上（比如桌面软件，比如web页面，比如excel等），以便于数据运营、分析人员能够更加直观地对数据进行查看和理解、分析

ETL中文全称为：抽取.转换.加载 extract transform load

ETL是传数仓开发中的一个重要环节。它指的是，ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

数仓概念篇2

一、事实和维度

事实： 现实发生的某件事
维度： 衡量事实的一个角度
事实表： 记录事实信息的表；
维度表：记录维度的详细描述信息的表；

二、数仓分层管理

数据仓库中的数据表，往往是分层管理、分层计算的：
ADS层： 应用服务层
DWS层：数仓汇总层
DWD层：数仓明细层
ODS层：操作数据（最原始的数据）层 – 贴源层

数据采集篇：

一、日志埋点技术

二、Flume采集系统架构图

三、4.3Sqoop/DataX采集业务数据

（06）：工程搭建篇

（07）：字典构建篇

一、地理位置字典构建
在埋点日志中，有用户的地理位置信息，但是原始数据形式是GPS坐标；
但是GPS坐标在后续（地理位置维度分析）的分析中不好使用！
直接去匹配两个哪怕距离很近的gps坐标，很可能都匹配不上！
gps坐标的匹配，不应该做这种精确匹配，应该做范围匹配；
用GeoHash编码工具包将gps坐标装换成GEOHASH编码
加工的结果格式要求为：
GEOHASH码， 省，市，区

（08）：ID-MAPPING

在后续的数仓、画像、推荐等模块开发中，我们都需要对每一条行为日志数据标记用户的唯一标识！

（09）：日志预处理篇

1、清洗过滤
去除json数据体中的废弃字段（这是前端开发人员在埋点设计方案变更后遗留的无用字段）：

2、数据解析
将json打平： 解析成扁平格式；
3、数据集成
将日志中的GPS经纬度坐标解析成省、市、县（区）信息；
4、数据修正
5、保存结果
最后，将数据输出为parquet格式，压缩编码用snappy

四、模型设计

4.1 流量域
4.1.1 ODS层
与原始数据保持完全一致
指定用’org.openx.data.jsonserde.JsonSerDe’，作为解析数据的工具，上传采集的数据
例如：用户信息、产品信息、活动信息、团购信息、秒杀信息等
4.1.2 DWD层
清洗过滤数据
(1)去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）：
(2)过滤掉json格式不正确的（脏数据）
(3)过滤掉日志中account及deviceid全为空的记录
(4)过滤掉日志中缺少关键字段（event/eventid/sessionid 缺任何一个都不行）的记录
(5)过滤掉日志中不符合时间段的记录（由于app上报日志可能的延迟，有数据延迟到达）
(6)对于web端日志，过滤爬虫请求数据（通过useragent标识来分析）
数据解析：将json打平，解析成扁平格式
session分割
(1)对于web端日志，按照天然session分割，不需要处理
(2)对于APP日志，由于使用登录保持技术，导致APP进入后台时间很长，在恢复前台，依然是同一个session，不符合session分析定义，需要按事件间隔时间切割
(3)对于wx小程序日志，与APP类似，session有效期很长，需要按事件间隔时间切割
数据规范处理
Boolean字段，在数据中有使用1/0标识，也有使用true/false表示，统一为Y/N/U字符串类型数据，在数据中也有空串，有null值，统一为null值
维度集成
(1)将日志中的GPS经纬度坐标解析成省、市、区信息
(2)将日志的IP地址解析成省、市、区
(3)将日志中的时间戳，解析成年、季度、月、日、年第几周、月第几周、年第几天
新老访客标记
新访客，标记为1
老访客，标记为0
保存结果
最后将数据输出为parquet格式，压缩编码用snappy
parquet和orc都是列式存储的文件格式，在实际性能测试中，orc略优于parquet，但是parquet格式框架兼容性更好
GPS地理位置解析
使用geohash编码：在地球经纬度范围内，不断通过二分来划分矩形范围，通过观察gps坐标点所落的范围，来反复生成0/1二进制码，字符串长度越长，表达的精度就越高
IP地址解析
使用开源工具包ip2region，也需要准备地理位置映射字典
ID_mapping
为用户生成一个全局唯一标识guid
对用户打唯一标识（关联设备ID和账户ID 动态关联）
基本原则多对一，一个设备绑定到同一个账号ID之后，如果后续有一段时间是另外一个账号ID使用，则该设备被调整为绑定后面的ID
也就是：将今日数据按设备分组按时间排序取出每个账号时间最早的一条，依次对其打分，按降序排；将他们以元组形式返回
加载T-1日绑定记录表，将T日数据和T-1日数据全join，将得到的数据进行guid的选取运算
分情况处理：
情况1：历史数据根本没有这个设备
如果是匿名登录，只有设备ID，那么设备ID就是guid
如果是登录状态，那么登录状态就是guid
情况2：今日数据里没有历史数据里的设备
那么就直接将历史的guid作为guid
情况3：今日数据与历史数据都有
则需要对两边list进行分数合并，然后取出分数高的guid作为最终的guid
4.1.2 DWS层（主题建模、维度建模）
存储:HDFS 运算:HIVE/SPARK
主题模板举例
流量概况主题
流量会话聚合天/月表
日新日活维度聚合表
事件会话聚合天/月表
访客连续活跃区间表
新用户留存维度聚合表
运营位维度聚合表
渠道拉新维度聚合表
访客分布维度聚合表
用户事件链聚合表
流量概括主题
|分区日|GUID |会话ID|进入时间|跳出时间|入口页|跳出页|访问页|新老标识|小时段|省|市|区|手机型号|
可以支撑的报表分析举例：
访问次数分析
访问深度分析
访问时长分析
回头访客数分析
流量趋势分析
不同时段流量对比分析
不同地域的流量情况
不同地域的访问次数情况
不同地域的新用户分布情况