数仓整体说明:
1.1使用到的技术
使用flume进行数据采集,hdfs为存储平台,hive进行操作,sparksql为技术引擎,yarn作为资源调度平台,rookeeper为任务调度平台,altas管理元数据,
1.2分层设计
ADS为服务层
DWD为数仓汇总层,
ODS详细设计:
ODS操作数据
DIM存储维表
ODS:存放flume采集过的原始数据,
主要是对进行ods层数据做ETL处理后的数据扁平化处理,以parquet文件格式存储,一般大概在3-6个月
公司用户规模一般在1000万左右,平均日活400万,这个还要根据后面所在格式具体情况而定,每个用户平均访问1.2次,访问时长大概在10分钟左右,每天产生的日志大概在3亿条,然后每条日志大概在0.5k,每日增长144G,每月大概在4.3T,每月估计增长在20%左右,
使用flume从kafka里面进行采集,
我们有三类日志数据 app_端埋点日志 web端埋点日志 wx 小程序日志
我们会把用户,产品,活动,等一些信息存放到mysql中,
DWD层详细设计
在这个环节由于etl的需求较为复杂,用sql实现较为困难,因此这个环节我们是用spark来实现的,
这个过程主要做一些数据清洗
比如使用session分割,对数据进行规范化处理,比如数据有空字符串就统一为null,进行标识,
维度集成
比如讲日志中gps经纬度坐标解析成省,市,县,这样比使用ip地址进行定位更为精确,在如何解析地理位置上,我们用了GEOhash编码技术,(也是一种算法)将经纬度坐标转化为一个个字符串,
[gerhash编码不断通过二分法来划分举行范围] 从而来生成0/1二进制码,并且声成的字符串长度越长,表达的精度越高,越逼近jps
的具体坐标
在使用jps的过程中(ID_MAPPPING)为每个用户标识提高用户行为分析
[gerhash编码不断通过二分法来划分举行范围] 从而来生成0/1二进制码,并且声成的字符串长度越长,表达的精度越高,越逼近jps
的具体坐标
1.当时我们开始就使用设备ID,因为大部分的用户都只有一个id账号,所以通过这个就可以识别用户,但是他也有缺陷,比如同一用户在不同设备使用会被认为是不同用户,
反之,不同用户使用相同设备,
或者多用户在设备不足的情况下共同使用设备,都会对后续的分析统计带来影响,
2.关联设备ID和登录ID(一对一) 一台设备可能有多个用户进行使用,一个用户可能使用一个ID在多台机器上使用,但是在识别的时候还是算最初哪台机器的id号,这样也会有一定的局限性,
3.关联设备ID和登录ID(多对一的关系)
一个用户在多个设备上进行登录是一种比较常见的场景，比如 Web 端和 App 端可能都需要进行登录。支持一个登录 ID 下关联多设备 ID 之后，用户在多设备下的行为就会贯通，被认为是一个ID 发生的。
但也有局限性,但是一台设备可能有多个用户进行登录,
因此我们最后选择的方案是关联设备id和登录id进行动态关联,
就是一个设备ID被绑定到一个登录ID之后,如果该设备在后期被其他用户频繁的使用,则该设备会重新绑定到其他的id中,
具体操作就是:比如每个设备第一次被用户登录,那么就与该用户进行绑定并且使用打分制打100分,如果后面这个设备被其他用户登录,那么也使用打分制但是以十分的间隔逐渐减少的形式进行打分比如打90分,这时候,设备ID还是和第一个用户ID进行绑定,如果后面还是第二个用户进行登录那么给他打80 ,通过累加可知,用户第二个用户比第一个用户的份数多,这样该设备就接触与第一个用户的绑定,从而与第二个用户进行绑定,后面根据这样的思路进行操作
