诸葛子房的博客 https://zgzf.online/ 诸葛子房的博客是一个大数据博客，内容包含：大数据、用户画像、Flink等知识，致力于分享大数据、用户画像相关知识 Sun, 25 May 2025 14:01:06 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2025, 诸葛子房 <![CDATA[AI工具使用指南]]> https://zgzf.online/article/d19df8d8-967b-4769-ba73-62f1dfee498b https://zgzf.online/article/d19df8d8-967b-4769-ba73-62f1dfee498b Wed, 14 Feb 2024 00:00:00 GMT
AI工具使用指南
 
AI 时间线
 
kimi ai：擅长长文本解读
https://kimi.moonshot.cn/
文章链接：[url] 1.元数据:标题，作者，链接，标题 2.作者主张，亮点; 3.逐层加深理解; 4.关键术语/概念; 5.文章内的无用信息; 6.摘要核心信息; 7.金句; 8.总结;```
 
]]> <![CDATA[用户画像系列——在线服务调优实践]]> https://zgzf.online/article/8e6decb3-8b74-4db7-b41c-f3dad3b47a0b https://zgzf.online/article/8e6decb3-8b74-4db7-b41c-f3dad3b47a0b Wed, 24 Jan 2024 00:00:00 GMT
前面文章讲到画像的应用的几个方面，其中画像的在线服务应用主要是在推荐场景、策略引擎场景，这两部分场景都是面向线上的c端服务。
推荐场景：根据不同的用户推荐不同的内容，做到个性化推荐，需要读取画像的一些偏好数据，推荐感兴趣的内容。
策略引擎：根据用户的属性进入到不同的页面或者给出不同的策略，比如：普通用户访问不了淘宝的奢侈品入口，北京的活动只能北京用户参加。
所以能看到画像的在线服务的业务要求，流量大、对于耗时敏感（上万或者几十万的QPS、要求在毫秒内返回结果）。
目前业界对于这种c端大流量的服务基本上是采用Redis对数据进行存储，提供对外访问。
下面是画像服务在实际线上遇到的一些问题以及问题定位和处理思路：
(1)遇到的问题——流量高峰期耗时波动有毛刺、full gc 过于频繁
流量高峰期，经常出现耗时波动，观察gc情况，发现GC过于频繁(2天左右一次full gc)
机器配置:4c 8g
jvm参数配置：-Xms6g -Xmx6g -XX:NewRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
单台容器 qps高峰在 600-800
notion image
(2)优化方案一
机器配置:8c 16g
jvm参数:-Xms14g -Xmx14g -XX:NewRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
Full gc:4天一次
但是Survivor 区非常小：只有13M 原因参考 https://zhuanlan.zhihu.com/p/148604647
notion image
notion image
(3)优化方案二
机器配置：8c 16g
jvm参数：-Xms14g -Xmx14g -XX:NewRatio=2 -XX:+UseConcMarkSweepGC -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
Survivor ：478M
notion image
notion image
(4)优化方案三
机器配置：8c 16g
jvm：-Xms14g -Xmx14g -XX:NewRatio=1 -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
提升新生代大小，主要是查询服务的数据中含有很大的对象数据，短暂使用即可回收，不会常驻。
最终优化之后，full gc 维持在1周一次，但是仍然有接口耗时毛刺。
第二步：利用Arthas接口优化实践
核心逻辑主要是从Redis中里面读数据+同时根据权限解析响应有权限的标签返回，下面是利用Arthas对接口的好是分析和较高耗时的时候传递的参数的分析
notion image
notion image
notion image
最终查看这部分耗时较高的id主要是value值数据量非常庞大，导致从Redis读取+解析耗时非常严重甚至达到秒级，虽然最终返回的结果数据不算太大，但是读取和解析耗时非常严重
从调优来看，虽然能通过增大机器资源4c 8g——8c 16g，同时通过调整jvm参数让full gc 能够达到一周一次，但是对于接口波动还是存在问题，主要原因就是某些id对应的value值较大，所以读取和解析耗时严重，因此最终方案应该考虑去对value进行拆分存储，避免一次性取出来过大的数据，将常用数据和非常用数据进行拆分。
本文分析通过调整jvm参数以及利用Arthas进行分析接口耗时情况来进行定位在线服务问题。 博客地址：https://zgzf.online/
]]> <![CDATA[用户画像系列——布隆过滤器在策略引擎中的应用]]> https://zgzf.online/article/aef94a81-b024-4846-a795-206f073c811a https://zgzf.online/article/aef94a81-b024-4846-a795-206f073c811a Mon, 22 Jan 2024 00:00:00 GMT
在用户画像系列——当我们聊用户画像，我们在聊什么？
介绍了用户画像的应用场景:
(1)个性化推荐
通过用户标签给用户推荐合适的商品或者内容
(2)营销圈选
参考：用户画像系列——Lookalike在营销圈选扩量中的应用
(3)策略引擎
根据用户标签命中不同的策略，比如说：高消费人员有奢侈品入口通道
(4)算法模型
(5)画像报告
背景：
这篇文章分享的是用户画像在策略引擎中的应用。首先来了解下策略引擎是干什么的？
比如：当某个用户第一次进入某个平台，会给你弹窗有什么优惠，新用户优惠券等等；或者某个用户消费金额极高，达到一个阈值，认为该用户有极大的消费能力，可以开放奢侈品入口，即：淘宝上的奢侈品频道是根据之前有消费过奢侈品、且高价值的用户才开放的。
notion image
上述是一个简单的策略引擎，通过进行判断当前进入的用户是否满足某个或者多个条件然后进行相应的营销策略
问题和思路：
当引擎策略(或者称之为规则)过于复杂，同时还会经常对规则进行变更，那么是否有一个更加简单的方法来处理呢？即是这篇文章要要分享的通过人群圈选功能，圈出目标用户，定义为人群包，然后当前用户进行平台判断该用户是否在这个人群包里面，因为是线上服务，要求进行用户去查询人群包匹配是否存在的过程需要在毫秒内返回结果
notion image
通过上述方案，只需要修改圈选条件，就能够非常简单的解决，策略条件过于复杂以及经常调整的问题。
线上实际应用以及遇到的问题：
因为要求线上用户访问去人群包进行匹配的过程，需要在毫秒级进行返回，因此需要对于人群包数据进行存储，考虑采用redis 进行存储。
redis数据结构如下：
key：人群包id key_1，value：圈选出来的用户列表[userId_1,userId_2,userId_3等等]
但是随着人群包越来越多，需要的存储也越来越多，通常一个人群包里面的用户少则几万多则上千万甚至亿级。
优化方案：
通过使用redis 的布隆过滤器
由于布隆过滤器存储空间小，并且节省空间，不存储数据本身，仅存储hash结果取模运算后的位标记，整理存储优化极大相对于散列表
]]> <![CDATA[用户画像系列——推荐相关核心标签(偏好类)]]> https://zgzf.online/article/3c97e4d9-3598-4616-b816-b964bd5ae9ad https://zgzf.online/article/3c97e4d9-3598-4616-b816-b964bd5ae9ad Tue, 16 Jan 2024 00:00:00 GMT
一、背景
我们经常在逛购物网站或者刷抖音、听网易云音乐的时候，会有猜你喜欢或者为你推荐这样一个功能，而这依赖的就是用户画像的偏好类标签：比如说明星偏好(喜欢某个明星或者歌手的作品)、类型偏好(比如说：喜欢美妆类、喜欢美食类)
notion image
notion image
notion image
notion image
二、偏好标签加工的核心逻辑
偏好类标签一般都是以用户的行为日志进行加工。
比如说：视频类软件(观影日志、评论日志、点赞日志、收藏日志)——内容偏好、类型偏好、明星偏好，电商类(订单日志、浏览日志、收藏日志、加购物日志)——商品偏好、价格偏好、品牌偏好
下面我们以视频类软件为例来详细讲解下偏好类标签的加工逻辑
1.偏好类事实型：主要是根据用户观影数据来计算用户在某个内容或者类型下的观影总时长和最后一次观影时间
notion image
notion image
notion image
notion image
上面是一张播放行为表，涵盖了基本的播放行为数据，和一张为tag维表(一个电视剧或者电影会打上非常多的标签，表中只是罗列了3个)
根据上述两张表可以生成如下用户观影tag表，能看到一个电视剧或者电影能很明显的
notion image
notion image
根据上述表进行计算得到每个用户在每个标签下的观影总时长，该标签下最后一次观影时间
notion image
这样每个用户的内容偏好标签即可计算完成
notion image
notion image
注：当我们想看用户最近半年的观影偏好时，就用用户最近半年的观影数据来进行计算即可，这样就能动态产出用户观影偏好
细心的读者发现打在某个tag上有观影总时长和最后一次观影时间，观影总时长能看出这个用户对于这种tag的内容非常感兴趣，而最后一次观影时间说明最近用户在观看这部分内容。
相当于总时长代表的是一个长期兴趣，而最后一次观影代表的是用户的一个短期兴趣。比如说：用户男性经常观看古装或者美女，但是最近有一个毕竟火的热点视频，该用户也在观看，但这种只能代表用户最近一段时间的兴趣偏好，当过了这段时间就应该选用长期兴趣标签了。
2.偏好类权重型：主要是根据用户观影数据来计算用户在某个内容或者类型下的观影权重，比如说权重越高说明用户对于某个内容更感兴
notion image
notion image
用户观影权重表
notion image
notion image
notion image
注：权重公式系数非常有讲究，主要看是关注最后一次观影时间还是更加关注播放时长，如果更关注时长则时长权重更大，如果更加关注最后一次观音时间则此处系数应该更大。
notion image
notion image
归一化：直接按照视频id打上标签然后相加权重值明显会超过1，因此需要归一化处理
notion image
notion image
notion image
三、总结
至此即完成了偏好类标签的处理和加工，应用的话，可以在广告、推荐等多个场景进行应用。比如说：某个用户经常看搞笑视频可以给它推荐搞笑的玩具或者视频等等
]]> <![CDATA[用户画像系列——数据中台之OneID (ID-Mapping)核心架构设计]]> https://zgzf.online/article/bb68a83f-521a-4721-ab9e-5a7e55774c90 https://zgzf.online/article/bb68a83f-521a-4721-ab9e-5a7e55774c90 Mon, 15 Jan 2024 00:00:00 GMT
一.引言 大家在上网的过程中是不是经常有这样的体验，我在百度(或者京东、淘宝)上搜索一件商品(比如说：我搜索了一台iphone 手机看了看，但是没买)，奇怪的是过两天，我竟然在某视频平台或者某网页上又看到了它？
而且更加奇怪的是，我明明是在电脑pc 端搜索的手机，但是我在手机上看电影的时候却能看到它，是不是也太奇怪了。
难道我的电脑、我的手机、我的ipad 等等电子设备都被监控了吗？
二、背景 《阿里巴巴大数据之路》中有讲到关于数据中台OneData 的方法论，其中分别涉及到OneModel、OneService、OneID。OneService 在之前的文章中已经有过分享，参考：(1条消息) 某互联网大厂亿级大数据服务平台的建设和实践_诸葛子房的博客-CSDN博客
引言中所提到的小故事其实就是本文着重要分享的关于OneID 的部分
notion image
三、概念介绍
OneID是指同一用户、同一设备的一个唯一ID。
例子一：我用我自己的电脑搜索小米11，我又用这台电脑浏览其他网站，然后这个网站给我弹小米11的广告，对，也许你认为这种都是同一台电脑，非常简单，只需要根据ip等相关信息进行匹配就可以了。
例子二: 我用我自己的电脑搜索小米11，然后用自己的苹果手机，去浏览其他网站，然后其他网站又给我弹了小米11的广告，这怎么识别的呀？
notion image
我们认为这台电脑、这部手机、以及其他的电子设备是可以构成一个唯一的ID，即：OneID
但是你一定会问了，那他们是怎么关联上的呢？而不会关联错呢？比如说没有把我在电脑上搜索的小米11，推到我的手机上，而不是推到我女朋友的手机上
这个映射的过程，称之为：ID-Mapping
四、核心架构设计
1.业务逻辑
当使用安卓手机安装app，启动时会上报 IMEI，Mac地址 ，AndroidID，手机型号等设备信息
同理ios 会上报相关启动信息 idfa，手机设备等信息；pc 浏览器端会上报 cookie、浏览器相关信息。
但是每一次上报的信息不一定完全相同，比如说手机权限问题，浏览器cookie 清空等问题。
LocalID：app 启动会根据AndroidID生成本地id(不需要连网)，记录为本地ID
OneID：app 联网上报的设备相关信息，用来打通多个app以及多端应用的唯一ID
OneID的作用：
(1)打通手机上多个app，比如说：淘宝、支付宝、高德等等是同一个用户(未登录时，登录时用账号id)
(2)打通多端应用，比如说你在手机端看剧，然后pc web 端能知道还是同一用户(解决账号共享无法定位同一用户的问题)
2.生成流程解析
(1)HBase数据表结构设计
安卓端表映射表结构(android_id_mapping)，其他端类似：
OneID imei mac_adress android_id oaid
本地id 和 OneId映射表结构(local_id_mapping)：
LocalID OneID
(2)为了应对高并发场景，将HBase 提前预热至Redis 缓存，redis 表设计
imei_value oneid1,oneid2...
mac_address_value oneid1,oneid2...
(3)ID-Mapping 映射流程
notion image
票选服务：
根据客户端上报的参数信息去redis 里面匹配OneID，核心权重设置
notion image
五、总结
最后来回答下开头提出的两个问题
问题一：我在百度(或者京东、淘宝)上搜索一件商品(比如说：我搜索了一台iphone 手机看了看，但是没买)，奇怪的是过两天，我竟然在某视频平台或者某网页上又看到了它？
在视频平台看视频的时候，获取到浏览器的cookie等相关信息，通过调用百度的服务去匹配同一个设备的最新的搜索数据，然后进行广告投放，做到千人千面
问题二：而且更加奇怪的是，我明明是在电脑pc 端搜索的手机，但是我在手机上看电影的时候却能看到它，是不是也太奇怪了。
手机端装了看电影的app，同时我在pc web 端之前也看在该网站有观影信息，结合账号信息+设备信息+观影信息，生成一个OneID，打通该视频网站，所有端的数据。
后续我在pc web 看电影取获取当前唯一id的所有端的信息，然后调用京东或者淘宝的广告服务，进行投放。
]]> <![CDATA[用户画像系列—如何从0到1建设用户画像]]> https://zgzf.online/article/18fb78ef-6e0f-4506-a5cc-b480b7d8e6fb https://zgzf.online/article/18fb78ef-6e0f-4506-a5cc-b480b7d8e6fb Mon, 15 Jan 2024 00:00:00 GMT
1.用户画像平台该如何建设？
根据上一篇文章，我们讲到用户画像其实就是用户的标签或者特征，首先要明确就是要完成标签的生产和加工，那么涉及到的内容就包括数据的接入、清洗、和最后标签的加工入库。
标签整体流程如下：
notion image
(1)线上日志数据接入和处理
数据分层
notion image
(2)标签的加工和挖掘
a.标签加工根据标签的加工方式分为三类：事实类、统计类、算法类
事实类：主要是基于原始数据同步过来即可，比如：最后一次登录时间
统计类：在原始数据上做一些简单的统计规则，比如：最近一个月活跃天数
算法类：根据用户的行为和交易信息利用算法挖掘出来，比如：工作位置、家庭位置(根据gps信息采用聚类算法挖掘出来)
b.标签加工根据标签的时效性分为三类：离线(T+1)、准实时(T+H)、实时
(3)标签存储和应用
为了应对不同的应用场景，使用不同的数据库作为存储方案
notion image
(4)标签权限管控、标签字典、标签质量
标签权限管控：业务只能使用申请权限了的标签权限，标签权限配置存储在MySQL
标签字典：标签内容数据只存储字典枚举，而不实际存储实际内容(比如：性别标签男女存储为0、1)
标签质量：对于标签的数据质量进行监控、波动告警，包含：标签的覆盖率、标签分布的监控告警
 
2.用户画像建设过程中会用到哪些技术？
(1)大数据相关的一些技术
Java、MySQL、Python、Hive、Spark、Flink、HBase
(2)服务开发
rpc服务
(3)标签挖掘算法
聚类、逻辑回归等，Python、Spark
3.用户画像建设过程中会遇到哪些问题？
(1)降本增效大环境下，用户画像侧如何做好存储和计算性能优化？
a.KV存储采用Protobuf存储，Protobuf编码性能好且压缩比高。因为画像的数据类型一般比较固定、单值或者多值，对序列化反序列化性能以及数据压缩效果有较高要求
b.标签内容字典化
c.画像特征抽取自定义抽取，资源占用低
目前特征抽取主要有单特征抽取和批量特征抽取
单特征：优点，控制灵活。缺点，每个特征都会启动各自的拉取任务，执行效率低且耗费资源。
批量特征抽取：成本可控，但较依赖上游Hive 表数据
因此考虑自定义特征抽取方案，根据标签优先级策略配置抽取策略，既能做到成本可控又能做到满足时效性。
notion image
d.冷热数据分级存储
热数据考虑用更好的硬件设备进行存储(SSD、独立集群等)、冷数据考虑用一般的硬件设备进行存储(HHD、公共集群)
notion image
 
]]>