大数据离线项目总结
2023-03-27 15:39:18 0 举报AI智能生成
对大数据项目所有设计的需求以及实现思路的总结
作者其他创作
大纲/内容
难点设计ID_MAPPING
只使用设备id
适用场景：适合没有用户注册体系，或者极少数用户会进行多设备登录的产品，如工具类产品、搜索引擎、部分小型电商等。这也是绝大多数数据分析产品唯一提供的方案。
局限性：同一用户在不同设备使用会被认为是不同的用户，对后续的分析统计有影响
不同用户在相同设备使用会被认为是一个用户，对后续的分析统计也会有影响
局限性：同一用户在不同设备使用会被认为是不同的用户，对后续的分析统计有影响
不同用户在相同设备使用会被认为是一个用户，对后续的分析统计也会有影响
关联设备id和登录id（一对一）
适用场景：需要贯通一个用户在一个设备上注册前后的行为
需要贯通一个注册用户在不同设备上登录之后的行为
局限性：一个设备id只能和一个登录id关联，而事实上一台设备可能有多个用户使用
一个登录id只能和一个设备id关联，而事实上一个用户可能用一个登录id在多台设备上登录
需要贯通一个注册用户在不同设备上登录之后的行为
局限性：一个设备id只能和一个登录id关联，而事实上一台设备可能有多个用户使用
一个登录id只能和一个设备id关联，而事实上一个用户可能用一个登录id在多台设备上登录
关联设备id和登录id（多对一）
适用场景：一个用户在多个设备上进行登录是一种比较常见的场景，比如Web端和App端可能都需要进行登录。
支持一个登录id下关联多设备id之后，用户在多设备下的行为就会贯通，被认为是一个id发生的。
局限性：一个设备id只能和一个登录id关联（而事实上一台设备可能有多个用户使用）。
一个设备id一旦跟某个登录id关联或者一个登录id和一个设备id关联，就不能解除（自动解除）
支持一个登录id下关联多设备id之后，用户在多设备下的行为就会贯通，被认为是一个id发生的。
局限性：一个设备id只能和一个登录id关联（而事实上一台设备可能有多个用户使用）。
一个设备id一旦跟某个登录id关联或者一个登录id和一个设备id关联，就不能解除（自动解除）
关联设备id和登录id（动态修正）
修正之处，一个设备id被绑定到某个登录id之后，如果该设备在后续一段时间（比如一个月内）
被一个新的登录id更频繁使用，则该设备id会被调整至绑定登录id。
被一个新的登录id更频繁使用，则该设备id会被调整至绑定登录id。
拉链表概念及实现
以订单表为例，表中90%的数据基本不会随着时间而变化，只有最近一段时间内的数据会有变化，对于这种类型的表，我们往往需要保存好每一条数据的每一天的状态，但又想节省存储空间；使用拉链表，来实现每条数据每天状态的变化情况。
优点：既能保留每天状态，又比较节省存储空间
弊端：使用、查询的时候，略增加了一点复杂性。
优点：既能保留每天状态，又比较节省存储空间
弊端：使用、查询的时候，略增加了一点复杂性。
实现流程
行为域ODS开发
ODS层功能
主要作用：直接映射操作数据（原始数据），数据备份
建模方法：与原始数据结构保持完全一致
存储周期：相对来说，存储周期较短；视数据规模、增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择三个月或者半年；存一年的土豪公司。
建模方法：与原始数据结构保持完全一致
存储周期：相对来说，存储周期较短；视数据规模、增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择三个月或者半年；存一年的土豪公司。
入仓方案
1、Spark解析：通过Spark程序解析Json文件再写入Hive表中
2、getJsonObject（）：将整个Json看作一个字段先存入Hive表中，再通过Hive自带的函数解析再写入另一张表
3、JsonSerDe：通过Hive兼容的Json解析器直接将Json数据解析到一张表中。（Hive3.x之后提供原生JsonSerDe）
2、getJsonObject（）：将整个Json看作一个字段先存入Hive表中，再通过Hive自带的函数解析再写入另一张表
3、JsonSerDe：通过Hive兼容的Json解析器直接将Json数据解析到一张表中。（Hive3.x之后提供原生JsonSerDe）
注意
一旦使用了JsonSerDe进行建表，则用spark-hive进行表读取时，会缺少类，并出现jackson版本冲突 ，可添加依赖进行解决
行为域DWD开发
技术选型
由于本层数据ETL的需求较为复杂，用hive sql实现非常困难，因而此环节需要用spark程序来实现
ETL需求分析
清洗过滤
1、去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）
2、过滤掉json格式不正确的（脏数据）
3、过滤掉日志中缺少关键字段（deviceid/properties/eventid/sessionid缺一不可）的记录
4、过滤掉日志中不符合时间段的记录（由于app上报日志可能的延迟，有数据延迟到达）
5、对于web端日志，过滤爬虫请求数据（通过useragent标识来分析）
2、过滤掉json格式不正确的（脏数据）
3、过滤掉日志中缺少关键字段（deviceid/properties/eventid/sessionid缺一不可）的记录
4、过滤掉日志中不符合时间段的记录（由于app上报日志可能的延迟，有数据延迟到达）
5、对于web端日志，过滤爬虫请求数据（通过useragent标识来分析）
数据解析
将json打平，解析成扁平格式
注意：properties字段不用扁平化，转成Map类型存储即可
注意：properties字段不用扁平化，转成Map类型存储即可
SESSION分割
1、对于web端日志，按天session分割，不需要处理
2、对于app日志，由于使用了会话保持策略，导致app进入后台很长时间后，再恢复前台，依然是同一个session，不符合session分析定义，需要按事件间隔事件切割（业内通用：30分钟）
3、对于wx小程序日志，与app类似，session有效期很长，需要按事件间隔事件切割（业内通用：30分钟）
2、对于app日志，由于使用了会话保持策略，导致app进入后台很长时间后，再恢复前台，依然是同一个session，不符合session分析定义，需要按事件间隔事件切割（业内通用：30分钟）
3、对于wx小程序日志，与app类似，session有效期很长，需要按事件间隔事件切割（业内通用：30分钟）
数据规范处理
Boolean字段，在数据中有使用1/0/-1标识的，也有用true/false标识的，统一为Y/N/U
字符串类型字段，在数据中有空串，有null值，统一为null值
日期格式统一，2020/9/2 2020-9-2 2020-09-02 20200902 都统一成yyyy-MM-dd
小数类型，统一成decimal
字符串，统一成String
时间戳，统一成bigint
字符串类型字段，在数据中有空串，有null值，统一为null值
日期格式统一，2020/9/2 2020-9-2 2020-09-02 20200902 都统一成yyyy-MM-dd
小数类型，统一成decimal
字符串，统一成String
时间戳，统一成bigint
数据集成
1、将日志中的GPS经纬度坐标解析成省、市、县（区）信息；（为了方便后续的地域维度分析）
2、将日志中的IP地址解析成省、市、县（区）信息；
注意：app日志何wxapp日志，有采集到的用户事件行为时所在地gps坐标信息；web日志则无法收集到用户的gps坐标，但可以收集到IP地址；
gps坐标可以表达精确的地理位置，而IP地址只能表达准确度较低而且精度较低的地理位置。
2、将日志中的IP地址解析成省、市、县（区）信息；
注意：app日志何wxapp日志，有采集到的用户事件行为时所在地gps坐标信息；web日志则无法收集到用户的gps坐标，但可以收集到IP地址；
gps坐标可以表达精确的地理位置，而IP地址只能表达准确度较低而且精度较低的地理位置。
ID_MAPPING
实现：为每一个用户每一条访问记录，标识一个全局唯一id（给匿名访问记录，绑定到一个id上）
选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、session等用户相关的分析功能。
本需求的意义：
1、只使用deviceid来做用户标识的方案：一部设备上可能出现A账号何B账号，就会被认为是一个人；同一个账号，在不同的设备上登录使用，这些行为数据会被认为是多个人
2、只用account来做用户标识的方案：一部设备可能出现A账号和B账号，会被正确识别2个人；同一个账号，在不同的设备上登录使用，这些行为数据会被正确识别为1个人；当一部设备上产生了一些匿名行为日志，我们会看这部设备上最近一段时间内出现的账号登录次数谁多，就算给谁！（设备被动态绑定了一个账号）。本质上，就形成了“设备”和“账号”的绑定（动态）只要识别出来一个用户，则为这个用户专门生成一个整数类型的自增的全局唯一id（guid）
选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、session等用户相关的分析功能。
本需求的意义：
1、只使用deviceid来做用户标识的方案：一部设备上可能出现A账号何B账号，就会被认为是一个人；同一个账号，在不同的设备上登录使用，这些行为数据会被认为是多个人
2、只用account来做用户标识的方案：一部设备可能出现A账号和B账号，会被正确识别2个人；同一个账号，在不同的设备上登录使用，这些行为数据会被正确识别为1个人；当一部设备上产生了一些匿名行为日志，我们会看这部设备上最近一段时间内出现的账号登录次数谁多，就算给谁！（设备被动态绑定了一个账号）。本质上，就形成了“设备”和“账号”的绑定（动态）只要识别出来一个用户，则为这个用户专门生成一个整数类型的自增的全局唯一id（guid）
新老访客标记
新访客，标记为1
老访客，标记为0
老访客，标记为0
保存结果
最后，将数据输出为parquet格式，压缩编码用snappy
注意：parquet和orc都是列式存储的文件格式，两者对于分析运算性的读取需求，都有相似有点。在实际性能测试中（读、写、压缩性能），orc略优于parquet
此处可选择orc，也可以选择parquet，选择parquet的理由则是，parquet格式的框架兼容性更好，比如impala支持parquet但不支持orc
注意：parquet和orc都是列式存储的文件格式，两者对于分析运算性的读取需求，都有相似有点。在实际性能测试中（读、写、压缩性能），orc略优于parquet
此处可选择orc，也可以选择parquet，选择parquet的理由则是，parquet格式的框架兼容性更好，比如impala支持parquet但不支持orc
业务域DWD开发
主要表类型
本层存储的业务表，主要就是ods中的各种增量导入数据进行全量合并后生成的全量快照表，或者拉链表。
快照表和拉链表，都是分区全量表！只不过快照表需要保存每一天的分区，才能查询到每一天的该表的数据状态；
而拉链表则只需要北流最后一天的分区即可。
快照表和拉链表，都是分区全量表！只不过快照表需要保存每一天的分区，才能查询到每一天的该表的数据状态；
而拉链表则只需要北流最后一天的分区即可。
增量合并成全量快照
为了便于后续的统计分析方便，用增量抽取策略抽取过来的增量数据 ，都要每天进行滚动合并。
合并的技术手段：
1、方便起见，可以使用sqoop merge命令进行
2、如果有特别的情况，可以自己写spark程序来实现
3、直接用hive的sql来实现（分组top1模式或者full join模式）
合并的技术手段：
1、方便起见，可以使用sqoop merge命令进行
2、如果有特别的情况，可以自己写spark程序来实现
3、直接用hive的sql来实现（分组top1模式或者full join模式）
0 条评论
下一页
