技术选型
由于本层数据ETL的需求较为复杂，用hive sql实现非常困难，因而此环节需要用spark程序来实现
ETL需求分析
清洗过滤
1、去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）<br>2、过滤掉json格式不正确的（脏数据）<br>3、过滤掉日志中缺少关键字段（deviceid/properties/eventid/sessionid缺一不可）的记录<br>4、过滤掉日志中不符合时间段的记录（由于app上报日志可能的延迟，有数据延迟到达）<br>5、对于web端日志，过滤爬虫请求数据（通过useragent标识来分析）
数据解析
将json打平，解析成扁平格式<br>注意：properties字段不用扁平化，转成Map类型存储即可
SESSION分割
1、对于web端日志，按天session分割，不需要处理<br>2、对于app日志，由于使用了会话保持策略，导致app进入后台很长时间后，再恢复前台，依然是同一个session，不符合session分析定义，需要按事件间隔事件切割（业内通用：30分钟）<br>3、对于wx小程序日志，与app类似，session有效期很长，需要按事件间隔事件切割（业内通用：30分钟）
数据规范处理
Boolean字段，在数据中有使用1/0/-1标识的，也有用true/false标识的，统一为Y/N/U<br>字符串类型字段，在数据中有空串，有null值，统一为null值<br>日期格式统一，2020/9/2 2020-9-2 2020-09-02 20200902 都统一成yyyy-MM-dd<br>小数类型，统一成decimal<br>字符串，统一成String<br>时间戳，统一成bigint
数据集成
1、将日志中的GPS经纬度坐标解析成省、市、县（区）信息；（为了方便后续的地域维度分析）<br>2、将日志中的IP地址解析成省、市、县（区）信息；<br>注意：app日志何wxapp日志，有采集到的用户事件行为时所在地gps坐标信息；web日志则无法收集到用户的gps坐标，但可以收集到IP地址；<br>gps坐标可以表达精确的地理位置，而IP地址只能表达准确度较低而且精度较低的地理位置。
ID_MAPPING
实现：为每一个用户每一条访问记录，标识一个全局唯一id（给匿名访问记录，绑定到一个id上）<br>选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是漏斗、留存、session等用户相关的分析功能。<br>本需求的意义：<br> 1、只使用deviceid来做用户标识的方案：一部设备上可能出现A账号何B账号，就会被认为是一个人；同一个账号，在不同的设备上登录使用，这些行为数据会被认为是多个人<br> 2、只用account来做用户标识的方案：一部设备可能出现A账号和B账号，会被正确识别2个人；同一个账号，在不同的设备上登录使用，这些行为数据会被正确识别为1个人；当一部设备上产生了一些匿名行为日志，我们会看这部设备上最近一段时间内出现的账号登录次数谁多，就算给谁！（设备被动态绑定了一个账号）。本质上，就形成了“设备”和“账号”的绑定（动态）只要识别出来一个用户，则为这个用户专门生成一个整数类型的自增的全局唯一id（guid）
新老访客标记
新访客，标记为1<br>老访客，标记为0
保存结果
最后，将数据输出为parquet格式，压缩编码用snappy<br>注意：parquet和orc都是列式存储的文件格式，两者对于分析运算性的读取需求，都有相似有点。在实际性能测试中（读、写、压缩性能），orc略优于parquet<br>此处可选择orc，也可以选择parquet，选择parquet的理由则是，parquet格式的框架兼容性更好，比如impala支持parquet但不支持orc
