业界比较优秀的方案有百度基于doris来实现海量用户的圈选,可以实现千万级人群秒级圈选。但是这种方案比较复杂:
1、需要数仓同学加工二值化tag,构建用户二值化tag到用户bitmap集合的倒排索引
2、需要通过构建哈希分桶列,解决超大bitmap基数交并集问题
3、需要数仓同学构建全局字典,防止不连续id带来的roaring bitmap性能问题
4、需要通过to_bitmap函数解决动态标签与静态标签的组合圈选问题
5、需要团队有doris的运维能力
本博文介绍一种基于spark的轻量级圈选,可以实现千万级人群分钟级(5分钟以内)圈选。
业界还有基于ES、MR、离线+服务bitmap等方案(我们选型时,doris还不火,故不在此列)。
ES:大人群的滚动导出会给集群带来很大压力的;另外就是如果构建一个大而全画像宽表的话,这个表会很稀疏,所以我们会按业务主题构建多个es表,这样就会涉及到多个表之间join的问题,而es是不支持join语义的。
MR:老方案了,性能不大行
es+bitmap方案:这个方案扩展起来有点doris的味道。但是自己开发的话,其实比较复杂,而且没有居多性能优化手段的话,性能没那么理想,大都是比不上spark的。
因此,最后我们选择了spark做为人群圈选的方案。
我们构建了用户画像相关的一站式平台,前端平台包括人群管理、标签管理、画像分析等相关功能。
中间层服务对应包含人群管理中心、人群任务调度、人群解析引擎(负责前端json到Spark SQL的转化)、标签管理中心的模块;当然也包含权限、安全、流控、人群监控等辅助模块。
存储层,我们主要基于spark进行人群定向,依托Hbase/Redis做用户单到点查询,用Mysql做配置信息存储。
我们选取两个主题的画像进行交集圈选,圈选结果千万级,测试结果如下:
用户画像是对现实世界中用户的数学建模
1.源于现实,高于现实
用户画像是描述用户的数据,是符合特定业务需求的对用户的形式化描述
2.源于数据,高于数据
用户画像是通过分析挖掘用户尽可能多的数据信息得到的。
标签是某一种用户特征的符号标示,用户画像是一个整体,各个维度不孤立,标签之间有联系,所以用户画像本质上就是用标签的集合来标示
1.每个标签在特征空间里,都是一个基向量,现实中用户画像需要的用户特征往往是成百上千的标签,所以用户画像是特征空间中的高维向量。用户画像实质上就是特征空间中的高维向量。特征空间的描述最多只能做到三维,四维就是理论上的一个存在了。
2.基向量之间有关联(向量之间会存在一个角度),不一定是正交的。
1.记录和存储亿级用户的画像,非常消耗我们的存储
2.随着用户兴趣的升级,支持和扩展不断增加的维度和偏好
3.毫秒级的更新
4.支撑个性化推荐、广告投放和精细化营销等产品
1.1.明确问题:是要解决分类问题,还是回归问题,是要确定用户是否流失,还是预测下一个月的销量。
1.2.追求需求和数据的匹配:比如评估用户是否存在欺诈行为或流失,都是需要了解用户的用卡习惯
1.3.明确需求:比如风险评估,用户流失都是分类问题,0和1.而聚类问题是对这一批数据未知,不知道把它分成几类,在现实问题中比如,我们有一堆文章进行分类。
1.4.数据的规模、重要特征的覆盖度等
2.1数据集成、数据冗余、数值冲突:数据是多种多样的,可能是微服务的数据,第三方传过来的,等等这些数据都不是很规范,比如,对同一维度的描述,可能有自己的一套定义接口的标准,举例对男女的描述,有的接口可能用M/F,有的用0,1,接口的规范不一样,所以需要进行预处理。
2.2数据采样:保证数据综合的覆盖所有可能出现的情况
2.3数据清洗、缺失值处理与噪声数据
3.1特征概述
数据和特征决定了机器学习的上限,而模型和算法只是逼近这个上限而已
特征:对所需解决问题有用的属性
特征的提取、选择和构造:
1.针对所解决的问题选择最有用的特征集合
2.通过相关系数等方式来计算特征的重要性(人工筛选、算法(随机森林)、PCA自动降维)
3.2特征提取:业务日志、WEB公开数据抓取、第三方合作
3.3特征处理:特征清洗、特征预处理(值处理、特征选择、特征组合、降维)、商业加工
3.4特征监控:
指标:时效性、覆盖率和异常值
可视化和预警:仪表盘监控
统计问题:
1.平滑:针对一些稀疏问题进行处理,在一些样本不够的情况下,一些样本特征比例为0的数据是我们不希望看到的就做平滑处理
2.归一化:归纳和统一,降低数据处理复杂度,把零散的数据降为0~1之间
分类问题:
2.1二分类:常见的算法有LR、SVM、RF、GBDT、NB
2.2多分类:RF、GBDT、最大熵、二分类+one vs all
回归问题:
常用的算法有ALS、Lasso、Ridge、回归树
聚类问题:
Kmeans等
语义分析:涉及到分词、LDA等
高维偏好:有些维度很高处理难度大,就进行降维可使用协同过滤里ALS、Slope算法
2.3常用模型实例
通常一个问题的解决需要尝试2~3种算法,但是最终可能选择其中的一种来上线(AB测试)。
逻辑回归一般效果还不错,模型非常简洁,而且效率很高,最重要的一点是适合并行的分布式处理,所以逻辑回归是用的非常多的非常简单高效的一种算法,下图是逻辑回归与支持向量机的使用准确率比较:
1.架构概述图如下
数据采集—>数据预处理—>数据存储—>离线和实时计算—>存储模型到hive/hbase/redis—>针对不同问题选取不同算法—>结果推送给mysql/redis—>可视化输出
辅助监控系统:
Ozzie:任务调度
Nagios:预警
Ganglia:总体集群的监控
2.详细架构图如下:
需求:性别预测问题
数据:
数据1:用户使用APP的行为数据
数据2:用户浏览网页的行为数据
1.数据挖掘常见问题中的哪一类,分类、聚类、推荐还是其他?
分类
2.数据集规模,数据集是否够大?
分类需要大的数据集
3.问题假设
所提供的数据是否满足所解决问题的假设?
男女行为不同的数据
预处理后的数据如下图:
表1特征工程
1.单个特征的分析
1)数值型特征的处理,比如App的启动次数是个连续值,可以按照低、中、高三个档次将启动次数分段成离散值
2)类别型特征的处理,比如用户使用的设备是三星或者联想,这是一个类别特征,可以采用0-1编码来处理
3)数据归一化
2.多个特征的分析
1)设备类型是否决定了性别?做相关性分析,计算相关系数
2)App的启动次数和停留时长是否完全正相关,结果表明特别相关,去掉停留时长
3)如果特征太多,可能需要做降维处理
表2特征工程
1.典型的文本数据:网页->分词->去停用同->向量化
2.分词
1)jieba分词库等
2)去除停用词,停用词表除了加入常规的停用词外,还可以将DF(Doucument Frequency)比较高的词加入停用词表,作为领域停用词
3)向量化,一般是将文本转化为TF或TF-IDF向量
特征工程-结果
数据1特征工程后的结果
数据2特征工程后的结果
选择算法和模型考虑的因素:
训练集的大小
特征的维度大小
所解决问题是否是线性可分的
所有的特征是独立的吗?
需要不需要考虑过拟合的问题
对性能有哪些要求?
奥卡姆剃刀原理:如无必要,勿增实体
选择算法和模型:
1)LR:
只要认为问题是线性可分的,就可采用LR
模型比较抗噪,而且可以通过L1、L2范数来做参数选择
效率高,可以应用于数据特别大的场景
很容易分布式实现
2)Ensemble方法
根据训练集训练多个分类器,然后综合多个分类器的结果,做出预测
评估方法:混淆矩阵——PR,ROC,AUC
在Mysql中显示所有用户1.登录数据库首先,你需要使用如下命令登录到数据库,注意,必须是root用户哦~## mysql -u root -p2.查询用户表在Mysql中其实有一个内置且名为mysql的数据库,这个数据库中存储的是Mysql的一些数据,比如用户、权限信息、存储过程等,所以呢,我们可以通过如下简单的查询语句来显示所有的用户呢。SELECT User, Host, Password FROM mysql.user
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)