oneid构建
仅凭userid并不能准确地标识所有的用户，再加上埋点框架的固有缺陷，无法做到统一用户身份识别，故需要构建oneid体系，对同一用户赋予相同的oneid。这也是在构建数仓之时的第一步，由于自身数据埋点框架的特点，我们并不能像第三方sdk一样一开始就对同一个用户做到oneid标识，目前阶段需要在已有埋点日志的基础上通过一定的逻辑构建出oneid。
构建oneid通常有两种方式，第一种是通过生成的uuid和userid进行关联的方式，按照一定的业务规则，有一个uuid对应一个userid的关联方式，也有多个uuid关联一个userid的方式，在关联之后通过一定规则生成oneid，该种方式简单易于理解，通常通过sql就可以很方面的构造出oneid。第二种是通过图计算来进行oneid的构建，主要思想是通过多个用户标识之间的关联关系来合并唯一用户，该方法会比第一种更加精确。
一、如何构建oneid
有我认为比较好的一套方案，是在app架构设计之初就考虑到统一用户身份标识的情况，将每个设备生成的uuid作为userid，但是这种方案依然存在缺陷，第一是无法解决同一设备注册多个账号的情况，第二是拿字符串作为userid，在注册用户数特别大的时候数据库的查找效率低于数字型的查找。
由于各公司情况的不同，这里仅考虑在不涉及外部数据源的前提下，通过清洗日志表数据构建oneid，参考神策中的标识用户逻辑标识用户，考虑方案三关联设备 ID 和登录 ID（多对一）的情况，通过拉链表实现设备 ID 和登录 ID 的动态关联。
二、oneid表格格式
| 设备id | 登录id | oneid | start_time | start_logintime | end_logintime | platform |
|---|---|---|---|---|---|---|
| 获取日志表中16位uuid | uuid对应的userid | 有userid时使用userid，没有时使用uuid，统一使用oneid进行关联。 | uuid首次出现时间 | uuid对应userid登录时间 | uuid对应userid最后登录时间 | uuid对应的platform，排除多终端的影响 |
oneid生成逻辑：取第一次出现的uuid哈希值作为oneid
userid绑定设备id在userid第一次访问的时候
三、构建逻辑
（一）获取uuid和userid的映射关系
使用uuid作为主键，映射最后生成的oneid，同一uuid会对应多个userid，按照以下逻辑进行关联
归为匿名登录之前最近一次登录的用户。
四、数据缺项补正
数据缺项补正
反向补正，即根据新日志对稍早收集的日志中的个别数据项做回补或修订（例如，在用户登录后，对登录前页面日志做身份信息的回补）。
注：日志数据都需要做数据的反向补正，为了统一用户的行为链路
图计算注意事项
去掉弱关联，保留强关联
t和t-1之间的关联问题
选取id特征：
userid,imei,mac,androidid,uuid,imsi