【用户画像(一)】技术选型及ElasticSearch与后台启动命令
画像项目介绍
项目分类
- 数据仓库
- 离线数仓面向数据分析、报表服务
- 分层管理、维度建模
- Hive实现
- 用户画像
- 构建在数据仓库之上
- toC
- toB
- 推荐系统
- 用户画像之上
- 淘宝等电商平台
- 抖音 快手等内容平台
- 广告
- 社交
- Lambda架构
- 离线+实时
- batch layer 批处理层
- speed layer 速度层
- service layer 服务层
- kappa架构-流批一体
What
用户画像 就是给用户打上海量的标签
, 根据用户的目标, 行为和观点差异将用户区分成不同的类型, 从每种类型中提出出关键的信息(标签的名字) 形成人物原型, 实际就是用户信息的标签化
。
- 个体用户画像
- 群体用户画像
Why
- 数据业务化-加深用户认知,指导业务开展
- 数据技术化-构建用户标签,支持上层应用
- 通过已有数据->获取对应的信息->打上相应的标签->指导业务
How
- 数据获取
- 静态数据:用户属性-姓名 性别 年龄。。。。。 用户提供
- 动态数据:用户行为 下单 上课 理赔
- 设计指标
- 构建指标体系-以业务需求为导向
- 明确开发需求-标签怎么来开发
- 项目开发
- 画像平台web项目 前端 后端
- 用户标签计算 大数据
- 标签管理
- 标签计算的调度-多久计算一次
- 标签的更新-旧的标签可能update,新的标签需要与旧的标签进行拼接
- 标签的下线-标签删除
Where
- 数据分析-根据标签维度进行统计分析
- 精准营销
- 搜索引擎
- 广告投放
- 风控检测
- 推荐系统
- 指导产品
画像标签体系
一级标签:行业-电商
二级标签:子行业-仓储
三级标签:标签大类-位置
四级标签:标签的一个类别-省市区 对应一个计算任务
五级标签:四级标签对应的具体值,每个五级标签会有一个标签规则就是标签计算的依据
标签分类
- 用户画像标签可以分为基础属性标签和行为属性标签
标签分层
标签从运算层级角度可以分为三层:事实标签、模型标签、预测标签
- 事实标签(基础标签):是通过对于原始数据库的数据进行统计分析而来的,如用户投诉次数,是基于用户一段时间内实际投诉的行为做的统计
- 模型标签(统计标签):是以事实标签为基础,通过构建事实标签与业务问题之间的模型,进行模型分析得到的。如,结合用户实际投诉次数、用户购买品类、用户支付的金额等,进行用户投诉倾向类型的识别,方便客服进行分类处理
- 预测标签(挖掘标签):是在模型的基础上做预测,如,针对投诉倾向类型结构的变化,预测平台舆情风险指数。
标签属性
标签是用来对用户进行分类
标签属性是用来对标签进行分类
标签属性可以理解为针对标签进行的再标注,这一环节的工作主要目的是帮助内部理解标签赋值
的来源,进而理解指标的含义。可以总结为5种来源:
- 固有属性:是指这些指标的赋值体现的是
用户生而有之或者事实存在的
,不以外界条件或者自身认知的改变而改变的属性。比如:性别、年龄、是否生育等。- 推导属性:由其他属性
推导
而来的属性,比如星座,我们可以通过用户的生日推导,比如用户的品类偏好,则可以通过日常购买来推导。- 行为属性:产品内外实际发生的
行为被记录
后形成的赋值,比如用户的登陆时间,页面停留时长等。- 态度属性:用户
自我表达
的态度和意愿。比如说我们通过一份问卷向用户询问一些问题,并形成标签,如询问用户:是否愿意结婚,是否喜欢某个品牌等。当然在大数据的需求背景下,利用问卷收集用户标签的方法效率显得过低,更多的是利用产品中相关的模块做了用户态度信息收集。- 测试属性:测试属性是指来自用户的态度表达,但并不是用户直接表达的内容,而是通过分析用户的表达,结构化处理后,得出的测试结论。比如心理测试等。
数据架构
- 原始输入层
主要指用户的历史数据信息,如会员信息、消费信息、网络行为信息。经过数据的清洗,从而达到用户标签体系的事实层。
- 事实层
事实层是用户信息的准确描述层,其最重要的特点是,可以从用户身上得到确定与肯定的验证。如用户的人口属性、性别、年龄、籍贯、会员信息等。可以打事实标签
- 模型预测层
通过利用统计建模,数据挖掘、机器学习的思想,对事实层的数据进行分析利用,从而得到描述用户更为深刻的信息。如通过建模分析,可以对用户的性别偏好进行预测,从而能对没有收集到性别数据的新用户进行预测。还可以通过建模与数据挖掘,使用聚类、关联思想,发现人群的聚集特征。打统计类和预测类标签
- 业务模型层
利用模型预测层结果,对不同用户群体,相同需求的客户,通过打标签,建立营销模型,从而分析用户的活跃度、忠诚度、流失度、影响力等可以用来进行营销的数据。
- 业务层
业务层可以是展现层。它是业务逻辑的直接体现,如图中所表示的,有车一族、有房一族等。
技术架构和技术选型
项目技术架构
离线部分
由于业务数据是存储在MySQL中的, 所以需要将数据从MySQL中导出到Hive中
具体的流程如下: mysql->hive->es->spark->es->presto
技术选型
画像用到数据为什么存储在es
- 要和数据仓库团队的人员,工作分工上进行解耦,方便项目和人员的管理
结果数据为什么写入到es
- 支持upsert操作
- 支持搜索功能
计算引擎为什么要用spark
- 比hive计算快
- spark中结构化流和spark MLlib machine learning library
ElasticSearch Stack技术栈
简介
Elastic Stack
是一套构建在开源基础之上,可以让我们安全可靠地采集任何来源、任何格式的数据,并且实时地对数据进行搜索、分析和可视化工具链。
Elastic Stack
的几个特点:采集、转换、搜索、分析、可视化,这些功能分别由ElasticSearch
、Kibana
、Beats
、Logstash
这几个组件来实现。
搜索引擎Lucene
Lucene是一种高性能的全文检索库,在2000年开源,最初由大名鼎鼎的Doug (道格·卡丁)开发。Lucene不是一个完整的全文检索引擎,它只是提供一个基本的全文检索的架构。
基于Lucene的分布式全文检索引擎, 比较出名的两个 :
- ElasticSearch
- 海量数据存储和处理
- 大型分布式集群(数百台规模服务器)
- 处理PB级数据
- 小公司也可以进行单机部署
- 开箱即用
- 简单易用,操作非常简单
- 快速部署生产环境
- 作为传统数据库的补充
- 传统关系型数据库不擅长全文检索(MySQL自带的全文索引,与ES性能差距非常大)
- 传统关系型数据库无法支持搜索排名、海量数据存储、分析等功能
- Elasticsearch可以作为传统关系数据库的补充,提供RDBM无法提供的功能
- Solr
- solr 单独纯粹做查询的效率高于 ES
- 如果写入的频次和读取的频次都比较多, 采用ES的效率要高于Solr
- ElasticSearch 和 Solr 都是基于Lucene开发的
ES核心概念
- 节点(Node)
运行了单个实例的ES主机称为节点,它是集群的一个成员,可以存储数据、参与集群索引及搜索操作。节点通过为其配置的ES集群名称确定其所要加入的集群。
- 集群(cluster)
ES可以作为一个独立的单个搜索服务器。不过,一般为了处理大型数据集,实现容错和高可用性,ES可以运行在许多互相合作的服务器上。这些服务器的集合称为集群。
一个集群会有多个节点组成,一个节点就是一个ES服务实例,通过配置cluster.name=‘’加入集群
- node.master=ture(默认为ture)-候选主节点,只有成为候选主节点的实例才能参与投票选举
- 主节点:负责索引的添加、删除,跟踪其它节点的正常运行,对数据分片的分配,收集集群中各节点的状态信息等
- node.data=ture(默认为ture)数据节点:负责对数据的增、删、改、查、聚合等操作,数据的查询和存储,对机器的io cpu memory要求比较高,一般选择
高配置的机器作为数据节点
- 协调节点:
- 介绍: 其本身不是通过配置来设置,用户的请求会随机分发给一个节点,该节点就成为了协调节点
- 功能:
负责分发客户端的读写请求、收集结果
集群每个节点既可以是候选主节点也可以是数据节点
- 分片(Shard)
ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点,它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能,这每一个物理的Lucene索引称为一个分片(shard)。
这样的好处是可以把一个大的索引拆分成多个,分布到不同的节点上。降低单服务器的压力,构成分布式搜索,提高整体检索的效率(分片数的最优值与硬件参数和数据量大小有关)。分片的数量只能在索引创建前指定
,并且索引创建后不能更改。
4)副本(Replica)
副本是一个分片的精确复制,每个分片可以有零个或多个副本。副本的作用一是提高系统的容错性,当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率,es会自动对搜索请求进行负载均衡。
副本数不能大于节点数
ES数据架构
Elasticsearch与数据库的类比
es7之后就没了type
关系型数据库(比如Mysql) | 非关系型数据库(Elasticsearch) |
---|---|
数据库Database | 索引Index |
表Table | 类型Type |
数据行Row | 文档Document |
数据列Column | 字段Field |
约束 Schema | 映射Mapping |
- 索引(index)
ES将数据存储于一个或多个索引中,索引是具有类似特性的文档的集合。索引相当于SQL中的一个数据库。
- 类型(Type)
类型是索引内部的逻辑分区(category/partition),然而其意义完全取决于用户需求。因此,一个索引内部可定义一个或多个类型(type)。类型相当于“表”。
- 文档(Document)
文档是Lucene索引和搜索的原子单位,它是包含了一个或多个域的容器,基于JSON格式进行表示。相当于mysql表中的row。
- 映射(Mapping)
映射是定义文档及其包含的字段如何存储和索引的过程。
一级分类 | 二级分类 | 具体类型 |
---|---|---|
核心类型 | 字符串类型 | string,text,keyword |
整数类型 | integer,long,short,byte | |
浮点类型 | double,float,half_float,scaled_float | |
逻辑类型 | boolean | |
日期类型 | date | |
范围类型 | range | |
二进制类型 | binary | |
复合类型 | 数组类型 | array |
对象类型 | object | |
嵌套类型 | nested | |
地理类型 | 地理坐标类型 | geo_point |
地理地图 | geo_shape | |
特殊类型 | IP类型 | ip |
范围类型 | completion | |
令牌计数类型 | token_count | |
附件类型 | attachment | |
抽取类型 | percolator |
bit:比特
byte:一个字节=8bit -2^7 ~2^7-1
short:两个字节=16bit -2^15 ~ 2^15-1
integer:四个字节=32bit
long:八个字节=64bit
ES集群架构
一个ES集群可以有多个节点构成,一个节点就是一个ES服务实例,通过配置集群名称cluster.name
加入集群。
- 候选主节点:只有是候选主节点才可以参与选举投票,也只有候选主节点可以被选举为主节点。
- 主节点:负责索引的添加、删除,跟踪哪些节点是群集的一部分,对分片进行分配、收集集群中各节点的状态等,稳定的主节点对集群的健康是非常重要。
- 数据节点:负责对数据的增、删、改、查、聚合等操作,数据的查询和存储都是由数据节点负责,对机器的CPU,IO以及内存的要求比较高,一般选择高配置的机器作为数据节点。
- 协调节点:其本身不是通过设置来分配的,用户的请求可以随机发往任何一个节点,并由该节点负责分发请求、收集结果等操作,而不需要主节点转发。这种节点可称之为协调节点,集群中的任何节点都可以充当协调节点的角色。每个节点之间都会保持联系。
集群中单个节点既可以是候选主节点也可以是数据节点
ES安装部署
- ES不能使用root用户来启动,必须使用普通用户来安装启动
配置普通用户
- 首先必须创建一个普通用户
- 然后把es所在的目录所有者设置为这个普通用户
1 | useradd es |
为普通用户itcast添加sudo权限
- 为了让普通用户有更大的操作权限,我们一般都会给普通用户设置sudo权限,方便普通用户的操作三台机器使用root用户执行visudo命令然后为es用户添加权限
1 | visudo |
上传压缩包并解压
1 | 以下操作 使用root用户创建es的相关的目录 |
修改配置文件
修改elasticsearch.yml
1 | 服务器使用es用户来修改配置文件 |
修改jvm.option
1 | 修改jvm.option配置文件,调整jvm堆内存大小 |
普通用户打开文件的最大数限制
问题错误信息描述:
max file descriptors [4096] for elasticsearch process likely too low, increase to at least [65536]
ES因为需要大量的创建索引文件,需要大量的打开系统的文件,所以我们需要解除linux系统当中打开文件最大数目的限制,不然ES启动就会抛错
使用es用户执行以下命令解除打开文件数据的限制
1
2
3
4
5
6
7 sudo vi /etc/security/limits.conf
添加如下内容: 注意*不要去掉了
* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 4096
此文件修改后需要重新登录用户,才会生效
普通用户启动线程数限制
问题错误信息描述
max number of threads [1024] for user [es] likely too low, increase to at least [4096]
修改普通用户可以创建的最大线程数
max number of threads [1024] for user [es] likely too low, increase to at least [4096]
原因:无法创建本地线程问题,用户最大可创建线程数太小
解决方案:修改90-nproc.conf 配置文件。
1 | 使用es用户执行以下命令修改配置文件 |
普通用户调大虚拟内存
错误信息描述:
max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]
调大系统的虚拟内存
原因:最大虚拟内存太小
每次启动机器都手动执行下。
1 | 执行以下命令 |
修改系统配置(上述已经解决)
$KAFKA_HOME/bin/kafka-server-start.sh $KAFKA_HOME/config/server.properties 2>&1 >> $KAFKA_HOME/kafka-server.log &
nohup /home/es/elasticsearch-7.10.2/bin/elasticsearch 2>&1 &
nohup :守护进程
& : 后台运行
2>&1 : 2-系统错误信息 1-系统信息 >&输出重定向
>> :追加写入
bin/elasticsearch -d
安装可视化插件:elasticsearch-head
安装IK分词器
配置VSCode
RestFulAPI
REST,表示性状态转移(representation state transfer)。简单来说,就是用URI表示资源,用HTTP方法(GET, POST, PUT, DELETE)表征对这些资源的操作。
URI:uniform resource indentify 统一资源标识符
URL:uniform resource locate 统一资源定位符 是URI的一个子集
RESTful API 就是REST风格的API。
- 使用http方法类型判断执行的操作类型
GET - SELECT
POST - UPDATE
PUT - INSERT
DELETE - DELETE
ES操作使用
- 创建索引
1 | PUT /my-index |
- 指定副本、分片数量
1 | // 创建指定分片数量、副本数量的索引 |
- 字段类型
分类 | 类型名称 | 说明 |
---|---|---|
简单类型 | text | 需要进行全文检索的字段,通常使用text类型来对应邮件的正文、产品描述或者短文等非结构化文本数据。分词器先会将文本进行分词转换为词条列表。将来就可以基于词条来进行检索了。文本字段不能用于排序、也很少用于聚合计算。 |
keyword | 使用keyword来对应结构化的数据,如ID、电子邮件地址、主机名、状态代码、邮政编码或标签。可以使用keyword来进行排序或聚合计算。注意:keyword是不能进行分词的。 | |
date | 保存格式化的日期数据,例如:2015-01-01或者2015/01/01 12:10:30。在Elasticsearch中,日期都将以字符串方式展示。可以给date指定格式:”format”: “yyyy-MM-dd HH:mm:ss” | |
long/integer/short/byte | 64位整数/32位整数/16位整数/8位整数 | |
double/float/half_float | 64位双精度浮点/32位单精度浮点/16位半进度浮点 | |
boolean | “true”/”false” | |
ip | IPV4(192.168.1.110)/IPV6(192.168.0.0/16) | |
JSON分层嵌套类型 | object | 用于保存JSON对象 |
nested | 用于保存JSON数组 | |
特殊类型 | geo_point | 用于保存经纬度坐标 |
geo_shape | 用于保存地图上的多边形坐标 |
- 创建测试索引
1 | PUT /job_idx |
- 查看索引
1 | 查看所有索引 |
- 删除索引
1 | delete /job_idx |
- 指定分词器创建索引
1 | PUT /job_idx |
- 添加数据
1 | PUT /job_idx/_doc/29097 |
- 修改数据
1 | POST /job_idx/_update/29097 |
- 删除数据
1 | DELETE /job_idx/_doc/29097 |
- 批量导入数据
1 | 使用Elasticsearch中自带的bulk接口来进行数据导入 |
- 查看索引状态
1 | GET _cat/indices?index=job_idx |
- 根据ID检索数据
1 | GET /job_idx/_search |
- 根据关键词搜索
1 | // 单字段搜索 |
- 分页搜索
1 | GET /job_idx/_search |
ES评分模型
Elasticsearch是基于Lucene的,所以它的评分机制也是基于Lucene的。在Lucene中把这种相关性称为得分(score),确定文档和查询有多大相关性的过程被称为打分(scoring)。
ES最常用的评分模型是 TF/IDF
和BM25
,TF-IDF属于向量空间模型,而BM25属于概率模型,但是他们的评分公式差别并不大,都使用IDF方法和TF方法的某种乘积来定义单个词项的权重,然后把和查询匹配的词项的权重相加作为整篇文档的分数。
在ES 5.0版本之前使用了TF/IDF算法实现,而在5.0之后默认使用BM25方法实现。
- Term Frequency(TF)词频:即单词在该文档中出现的次数,词频越高,相关度越高。
- Document Frequency(DF)文档频率:即单词出现的文档数。
- Inverse Document Frequency(IDF)逆向文档频率:与文档频率相反,简单理解为1/DF。即单词出现的文档数越少,相关度越高。
- Field-length Norm:文档越短,相关性越高,field长度,field越长,相关度越弱
TF/IDF模型是Lucene的经典模型,其计算公式如下:
BM25 模型中BM指的Best Match,25指的是在BM25中的计算公式是第25次迭代优化,是针对TF/IDF的一个优化,其计算公式如下:
- 通过执行计划查看打分过程
1 | GET /job_idx/_search |
标签计算流程
加载数据→标签计算→结果保存
- 一个四级标签就是一个计算任务,所以这个计算任务的输入条件是四级标签的ID
- 四级标签(id = 14),读取四级标签的rule
rule = inType=Elasticsearch##esNodes=up01:9200##esIndex=tfec_tbl_users##esType=_doc##selectFields=id,birthday
1、首先按’##’切分
[inType=Elasticsearch, esNodes=up01:9200, esIndex=tfec_tbl_users, esType=_doc, selectFields=id,birthday]
2、遍历数组,对数组中的每个元素按‘=’切分
dict[‘key’] = ‘value’
dict = {‘inType’ : ‘Elasticsearch’, ‘esNodes’: ‘up01:9200’……}
- 根据解析四级的标签元数据从数据源读取标签计算需要的数据
1 | inType 告诉数据保存的位置 |
- 根据四级标签的ID找对应五级标签的父ID读取五级标签的rule和id
1 | 16,19600101-19691231 |
- 根据五级标签的规则进行标签计算,将计算结果写入到Es保存