大数据离线项目总结

适用场景：适合没有用户注册体系，或者极少数用户会进行多设备登录的产品，如工具类产品、搜索引擎、部分小型电商等。这也是绝大多数数据分析产品唯一提供的方案。局限性：同一用户在不同设备使用会被认为是不同的用户，对后续的分析统计有影响             不同用户在相同设备使用会被认为是一个用户，对后续的分析统计也会有影响

只使用设备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_MAPPING

以订单表为例，表中90%的数据基本不会随着时间而变化，只有最近一段时间内的数据会有变化，对于这种类型的表，我们往往需要保存好每一条数据的每一天的状态，但又想节省存储空间；使用拉链表，来实现每条数据每天状态的变化情况。优点：既能保留每天状态，又比较节省存储空间弊端：使用、查询的时候，略增加了一点复杂性。

实现流程

拉链表概念及实现

主要作用：直接映射操作数据（原始数据），数据备份建模方法：与原始数据结构保持完全一致存储周期：相对来说，存储周期较短；视数据规模、增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择三个月或者半年；存一年的土豪公司。

ODS层功能

1、Spark解析：通过Spark程序解析Json文件再写入Hive表中2、getJsonObject（）：将整个Json看作一个字段先存入Hive表中，再通过Hive自带的函数解析再写入另一张表3、JsonSerDe：通过Hive兼容的Json解析器直接将Json数据解析到一张表中。（Hive3.x之后提供原生JsonSerDe）

入仓方案

一旦使用了JsonSerDe进行建表，则用spark-hive进行表读取时，会缺少类，并出现jackson版本冲突 ，可添加依赖进行解决

注意

行为域ODS开发

由于本层数据ETL的需求较为复杂，用hive sql实现非常困难，因而此环节需要用spark程序来实现

技术选型

1、去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）2、过滤掉json格式不正确的（脏数据）3、过滤掉日志中缺少关键字段（deviceid/properties/eventid/sessionid缺一不可）的记录4、过滤掉日志中不符合时间段的记录（由于app上报日志可能的延迟，有数据延迟到达）5、对于web端日志，过滤爬虫请求数据（通过useragent标识来分析）

清洗过滤

将json打平，解析成扁平格式注意：properties字段不用扁平化，转成Map类型存储即可

数据解析

1、对于web端日志，按天session分割，不需要处理2、对于app日志，由于使用了会话保持策略，导致app进入后台很长时间后，再恢复前台，依然是同一个session，不符合session分析定义，需要按事件间隔事件切割（业内通用：30分钟）3、对于wx小程序日志，与app类似，session有效期很长，需要按事件间隔事件切割（业内通用：30分钟）

SESSION分割

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

数据规范处理

1、将日志中的GPS经纬度坐标解析成省、市、县（区）信息；（为了方便后续的地域维度分析）2、将日志中的IP地址解析成省、市、县（区）信息；注意：app日志何wxapp日志，有采集到的用户事件行为时所在地gps坐标信息；web日志则无法收集到用户的gps坐标，但可以收集到IP地址；gps坐标可以表达精确的地理位置，而IP地址只能表达准确度较低而且精度较低的地理位置。

数据集成

实现：为每一个用户每一条访问记录，标识一个全局唯一id（给匿名访问记录，绑定到一个id上）选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、session等用户相关的分析功能。本需求的意义：       1、只使用deviceid来做用户标识的方案：一部设备上可能出现A账号何B账号，就会被认为是一个人；同一个账号，在不同的设备上登录使用，这些行为数据会被认为是多个人       2、只用account来做用户标识的方案：一部设备可能出现A账号和B账号，会被正确识别2个人；同一个账号，在不同的设备上登录使用，这些行为数据会被正确识别为1个人；当一部设备上产生了一些匿名行为日志，我们会看这部设备上最近一段时间内出现的账号登录次数谁多，就算给谁！（设备被动态绑定了一个账号）。本质上，就形成了“设备”和“账号”的绑定（动态）只要识别出来一个用户，则为这个用户专门生成一个整数类型的自增的全局唯一id（guid）

ID_MAPPING

新访客，标记为1老访客，标记为0

新老访客标记

最后，将数据输出为parquet格式，压缩编码用snappy注意：parquet和orc都是列式存储的文件格式，两者对于分析运算性的读取需求，都有相似有点。在实际性能测试中（读、写、压缩性能），orc略优于parquet此处可选择orc，也可以选择parquet，选择parquet的理由则是，parquet格式的框架兼容性更好，比如impala支持parquet但不支持orc

保存结果

ETL需求分析

行为域DWD开发

本层存储的业务表，主要就是ods中的各种增量导入数据进行全量合并后生成的全量快照表，或者拉链表。快照表和拉链表，都是分区全量表！只不过快照表需要保存每一天的分区，才能查询到每一天的该表的数据状态；而拉链表则只需要北流最后一天的分区即可。

主要表类型

为了便于后续的统计分析方便，用增量抽取策略抽取过来的增量数据 ，都要每天进行滚动合并。合并的技术手段：       1、方便起见，可以使用sqoop merge命令进行       2、如果有特别的情况，可以自己写spark程序来实现       3、直接用hive的sql来实现（分组top1模式或者full  join模式）

增量合并成全量快照

业务域DWD开发

离线项目总结