user_id|滴滴 x StarRocks:极速多维分析创造更大的业务价值( 二 )
3、数据计算与存储层:
(1)数据计算集群:数据存入Kafka集群后 , 根据不同的业务需求 , 使用Flink或者Spark对数据进行实时和离线ETL , 并批量保存到StarRocks数据仓库
(2)StarRocks数据仓库:Spark+Flink通过流式数据处理方式将数据存入StarRocks , 我们可以根据不同的业务场景在StarRocks里创建明细表、聚合表和更新表以及物化视图 , 满足业务方多样的数据使用要求
4、数据服务层:内部统一指标定义模型、指标计算逻辑 , 为各个应用方提供统一的离线查询接口和实时查询接口
5、漏斗分析系统:支持灵活创建和编辑漏斗 , 支持漏斗数据查看 , 漏斗明细数据导出
6、数据中台:围绕大数据数据生产与使用场景 , 提供元数据管理、数据地图、作业调度等通用基础服务 , 提升数据生产与使用效率
详细设计
目前 , 基于StarRocks的bitmap类型只能接受整型值作为输入 , 由于我们原始表的user_id存在字母数字混合的情况 , 无法直接转换成整型 , 因此为了支持bitmap计算 , 需要将当前的user_id转换成全局唯一的数字ID 。 我们基于Spark+Hive的方式构建了原始用户ID与编码后的整型用户ID一一映射的全局字典 , 全局字典本身是一张Hive表 , Hive表有两个列 , 一个是原始值 , 一个是编码的Int值 。 以下是全局字典的构建流程:
1、将原始表的字典列去重生成临时表:
临时表定义:
create table 'temp_table'{
'user_id' string COMMENT '原始表去重后的用户ID'
}
字典列去重生成临时表:
insert overwrite table temp_table select user_id from fact_log_user_hive_table group by user_id
2、临时表和全局字典进行left join , 悬空的词典项为新value , 对新value进行编码并插入全局字典:
全局字典表定义:
create table 'global_dict_by_userid_hive_table'{
'user_id' string COMMENT '原始用户ID',
'new_user_id' int COMMENT '对原始用户ID编码后的整型用户ID'
}
将临时表和全局字典表进行关联 , 未匹配中的即为新增用户 , 需要分配新的全局ID , 并追加到全局字典表中 。 全局ID的生成方式 , 是用历史表中当前的最大的用户ID加上新增用户的行号:
--4 更新Hive字典表
insert overwrite global_dict_by_userid_hive_table
select user_id, new_user_id from global_dict_by_userid_hive_table
--3 与历史的字段数据求并集
union all select t1.user_id,
--2 生成全局ID:用全局字典表中当前的最大用户ID加上新增用户的行号
(row_number() over(order by t1.user_id) + t2.max_id) as new_user_id
--1 获得新增的去重值集合
from
select user_id from temp_table
where user_id is not null
) t1
left join
推荐阅读
- 警告!|华为联想卷入滴滴高管千万受贿案 判决书曝光浪潮曾向其输送720多万
- IT|滴滴被“围剿”三个月:Q3经调整EBITA由盈转亏 订单量、交易额均下滑
- IT|滴滴三季度收入427亿元环比降13%,投资亏损208亿元
- 注销|中消协点名推荐退订"问题" APP 含曹操出行翼支付滴滴
- join|ClickHouse vs StarRocks选型对比
- 视点·观察|仅156天!滴滴股价腰斩,再赴港上市之路怎么走?
- the|美股周五:特斯拉跌逾6% 滴滴大跌超22%
- 视点·观察|美股退市上港股 滴滴还有劲折腾么?
- IT|投资者割肉止损 滴滴股价跌超22%
- app|滴滴旗下滴滴加油、DiDi-Rider恢复上架?两款App并未下架过