1.大数据时代已经到来，企业希望从用户行为数据中分析出有价值的东西，利用大数据来分析用户的行为与消费习惯，可以预测商品的发展的趋势，提高产品质量，同时提高用户满意度。
2.什么是用户画像：
通过不同的维度，去描述一个人，认识一个人，了解一个人。用户画像也叫用户信息标签化、客户标签；根据用户社会属性、生活习惯和消费行为等信息而抽象出的一个标签化的用户模型。从电商的角度看，根据你在电商网站上所填的信息和你的行为，可以用一些标签把你描绘出来，描述你的标签就是用户画像。构建用户画像的核心工作即是给用户贴“标签”，而标签是通过对用户信息分析而来的高度精炼的特征标识。
3.用户画像的意义：
罗振宇在《时间的朋友》演讲里面举了一个例子：当一个坏商家掌握你的购买数据之后就可以根据你的喜好决定给你发商品的类型、真伪来提高利润，但这也说明了利用用户画像可以做到“精准营销”，当然这是极其错误的用法。
其意义大体上表现在一下几个方面：
3.1 精准营销，分析产品潜在用户，针对特定群体利用短信邮件等方式进行营销
3.2 用户统计，比如中国城市上班族购买书籍类型人数 TOP10；
3.3 数据挖掘，构建智能推荐系统，利用关联规则计算，喜欢红酒的人通常喜欢什么运 动品牌，利用聚类算法分析，喜欢红酒的人年龄段分布情况
3.4 进行效果评估，完善运营，提高服务质量，
3.5 对服务或者产品进行私人订制，个性化服务某一类群体甚至每一位用户（未来趋势）。
3.6 业务经营分析以及竞争分析，制定企业发展战略。
4. 构建用户画像：
4.1 数据源端数据收集：网站交易数据，用户行为数据，网络日志数据。
4.2 数据预处理：清洗、结构化、标准化
4.3 行为建模：文本挖掘、自然语言处理、机器学期、预测算法、聚类算法、
4.4 用户画像：基本属性、购买能力、兴趣爱好、心理特征、社交网络、
有些标签是可以直接获取到的，有些标签需要通过数据挖掘分析到！
5. 源数据：
5.1 静态信息数据：用户填写的个人资料，或者由此通过一定的算法，计算出来的数
据。如果有不确定的，可以建立模型来判断，比如用户的性别注册没有填写，可以建立 模型，根据用户的行为来判断用户性别是什么，或者它的概率。
5.2 动态信息数据：用户行为产生的数据：注册、游览、点击、购买、签收、评价、
收藏等等，用户比较重要的行为数据：游览商品，收藏商品、加入购物车、关注商品
根据这些行为特性可以计算出：用户注册时间、首单时间、纠结商品、最大消费、订单数量、退货数量、败家指数、品牌偏好等等
6.用户画像构成：
标签：表现了内容，用户喜好的内容，表现在兴趣、偏好、需求，例如A用户的标签为：Nike，篮球鞋等等。
权重：表现了指数，是指用户在标签上的喜好程度，例如：A用户的用户画像：Nike-0.8、篮球鞋-0.9.
7.用户画像建模（建表）：
7.1用户基本属性表：根据用户填写的基本标签和推算出来的标签，
主要数据来源：用户表、用户调查表、用户价值模型表、孕妇模型表、马甲模型表
特殊的标签可以通过以上的数据加上算法得到：身高、体重、性别模型、孩子性别概率、潜在汽车用户概率、是否孕妇、孩子年龄概率、手机品牌、更换手机频率、是否有小孩，是否有车，使用手机档次，疑似马甲标准、疑似马甲账号数、用户忠诚度、用户购物类型
模型算法--性别模型：
实际开发中，及时用户填写性别还是要用算法计算一次确定性别，性别可以说是影响消费模型的最重要因素之一。
模型算法---用户忠诚度模型：
忠诚度分类：（1 忠诚型用户2 偶尔型用户3 投资型用户4 游览型用户-1 未识别）、总体规则是判断+聚类算法（1、游览用户型：只游览不购买的2、购买天数大于一定天数的为忠诚用户3、购买天数小于一定天数，大部分是有优惠才购买的）
模型算法---用户身高尺码模型：通过得到用户身材身高尺码来判断推荐用户适合的服装鞋帽等等。
模型算法---用户马甲标志模型：
马甲值用户注册的账号，分析相同访问地址账号、同一台手机多次登录、收货手机号相同为同一个人所有。
模型算法---手机相关标签模型：
对于手机类营销意义重大，使用手机品牌，关注手机品牌，使用手机档次，关注手机档次，使用手机情况（每天手机登录时间推算手机损耗），更换手机频率。
7.2 用户消费订单表：
根据用户消费提取用户标签，了解用户消费情况与能力，最终目的是根据这些标签做推荐与营销。
主要数据来源：订单表、退货表、用户表、购物车表。
订单表可以得到标签：第一次消费时间、最近一次消费时间、首单距今时间、尾单距今时间------分析用户什么时候来购买商品以及多久没有购买了。最小消费金额、最大消费金额，累计消费金额、累计使用代金券金额、累计使用代金券次数。-----分析用户总体消费情况。客单价、近 60 天客单价）-----分析用户消费水平。常用收货地址、常用支付方式----分析用户常用的消费属性，方便做定向营销
退货表可以得到标签：近 30 天购买次数(含退拒)、近 30 天购买金额（含退拒）----分析用户最近的消费能力。退货商品数量、退货商品金额、拒收商品数量、拒收商品金额、最近一次退货时间-----分析用户拒收和退货习惯。
购物车表可以得到相关标签：最近 30 天购物车次数、最近 30 天购物车商品件数、最近 30 天购物车提交商品件数、最近 30 天购物车放弃件数、最近 30 天购物车成功率------分析用户购物车使用习惯
订单表和用户表可以得到相关标签：学校下单总数、单位下单总数、家里下单总数、上午下单总数、下午下单总数、晚上下单总数----分析用户购物时间与地点习惯。
7.3 客户购买类目表：
根据客户购买类目的情况提取客户标签，用于了解类目的购买人群情况和针对某一类目的营销等。
主要数据来源：订单表、购物车表、类目维表
类目维表可以得到相关标签：不同级别的分类id与名称。分析用户都购买了 哪些类目。
订单表和类目维表可以得到相关标签：最近一个月或者多个月购买的次数、类目与金额
购物车表和类目维表可以得到相关标签：最近一段时间内用户购物车的类目、次数与金额，分析用户最近都挑选了哪些类目。
7.4 用户访问信息表：
根据用户访问情况提取标签，根据用户访问习惯做营销
主要数据来源：点击流日志行为表（PC/APP 端）
点击流日志行为表可以得到相关标签:根据不同时间段访问的ip地址、所在省份城市、使用的浏览器、计算机的操作系统、以及访问日期与访问次数，分析出用户在这个时间段的访问情况
8.用户画像的环境搭建：
8.1技术选择：数据分析计算一般用hive，但是hive语句转化为mr程序执行需要大量时间，所以用spark整合hive，用spark读取hive元数据这样的方法就可以实现快速为用户打上标签构建用户画像。
8.2整合步骤：将hive-site.xml文件拷贝到Spark的conf目录下，这样就可以通过这个配置文件找到 Hive 的元数据以及数据存放位置。如果hive的元数据在mysql中我们还需要准备好 Mysql相关驱动
操作指令：/var/local/spark/bin/spark-sql --master spark://当前服务器ip：端口号
--executor-memory （x）g --total-executor-cores （y）
整合成功就可以用spark操作hive。（例如创建数据库与数据表）
在spark/bin目录下执行，x：运行需要内存大小xg 运行需要核数y核。
注意：在spark2.0以前这样操作没有问题，但是在2.0版本以后这样操作会把操作得到创建的数据库与数据表的信息保存在当前spark/bin目录下的spark-warehouse文件下（本地），而不是存在hdfs上（应该存放在hive表对应的hdfs存放目录），这样不利于操作与不安全。所以在spark2.0版本以后主要在操作指令后面加上一句：
spark-sql --master spark://当前服务器ip：端口号
--executor-memory （x）g --total-executor-cores （y）
--conf spark.sql.warehouse.dir=(hive存储目录)hdfs://ip地址：端口号/usr/hive/warehouse
9.用户画像数据仓库：
9.1数据仓库分层的意义：
空间换时间：数据模型多层次，避免开发者直接操作原始数据，效率更高
复杂问题简单化：每一层处理单一的步骤与问题，这样也便于维护，出现问题从该层次角度开始修复。
便于处理业务变化：业务发生变化，只需要调整底层数据，高层次不需要改动。
9.2 数据仓库标准上可以分为四层：ODS（临时存储层）、PDW（数据仓库层）、MID（数据集市层）、APP（应用层）
9.3 ODS层：
临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。一般情况这个层的数据元数据中的数据。ODS 层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存 3-6 个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存
9.4 PDW层：
数据仓库层：即对源系统数据进行了清洗（去除了杂质）后的数据。在 PDW 层会保存BI系统中所有的历史数据。
9.5 MID层：
数据集市层： 这层数据是面向主题来组织数据的，通常是星形或雪花结构的数
据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。
9.6 APP层：
应用层： 这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或
雪花结构的数据。从数据粒度来说是高度汇总的数据。
10.用户画像数据开发：
10.1 步骤：数据开发前置依赖-需求确定-建模确定表结构-实现方案确定
10.2数据开发过程-表落地-写 sql 语句实现业务逻辑-部署代码-数据测试-试运行与上线
11.分层表的建立：
11.1分层表举例：客户的基本属性表
建立属于ODS层的客户基本属性表，这个表中的字段都是来源于元数据，例如：用户id、性别、登录名、邮箱、所在省份城市、手机号等等
建立属于PDW层的客户基本属性表，这个表来源于ODS层的客户基本属性表，有需求可以进行清洗，字段与ODS层一部分相同。
建立属于MID或者APP层的用户基本属性表，这个表的基本字段数据来源于PDW层但是又应用了机器学习（机器学习以后会发布相关技术博客）技术与高等算法产生了新的字段，比如：是否是潜在汽车购买者、是否是高频率更换手机用户、用户对我们网站的忠诚度等等（这些字段就是大数据在电商领域的灵魂字段）。
注意：一般情况对于不同的分层建立一个对应的分层数据库，要对表进行分区（一般是按照时间分区），因为我们的数据量比较大，可以按照时间间隔来对所有分层的表进行分区，而且也可以方便我们在以后准确的找到我们想要时间间隔的表与数据。还有利于我们数据可视化中的某些效果展现。
11.2宽表：
与上面的基本属性表逻辑相同，但是在MID或者APP层是一张宽表，表示其基本字段来源于PDW层不同的属性表（比如：来源于PDW的两张表）只需要注意在写入宽表的时候从两张表查询数据即可。
宽表的数据还可能来自于其他MID或者APP层的表，同理无论我们数据来源是哪里，我们的最终目的都是为了自己最好想要的结果，
很多时候我们最终都会构建成一张宽表，用来最终的展现。
12 最终宽表汇总模型表：
最终宽表汇总模型表位于APP层，一般情况下我们都是规定好了最终宽表的结构，它的字段由我们数据可视化的需求来决定可能有几百个、几十个，可能其中一个字段、几个字段来自于其他的宽表，可能字段由其他临时表计算得来，重要的字段由高等算法，机器学习得来等等。但是我们目的是明确的，就是在我们最终宽表需求的前提下，通过分层逻辑去设计表，通过计算去得到中间表，最终得到自己想要的宽表。（这里我们介绍表的逻辑，表字段的细节不做介绍，实际开发中是很复杂的，每一个最终宽表都是来源于很多宽表的，而每一个宽表又来源于不同层的不同的表，但是我们的操作方式sparksql是类似于sql语句的，要有很强的sql语句功底，有时候我们一条插入语句很可能就五、六百行乃至上千行）
13 最终宽表的存储
13.1 上面我们做的是用spark操作hive的层面，需要将最终得到的宽表存储起来，我们存储的最终选择有很多，Mysql和Oracle这种关系型数据库也可以用来存储，但是我们数据比较大，关系比较复杂，有时候需要新增标签属性（新增字段）而且前台查询需要耗费大量时间，所以实际开发中一般都将最终宽表映射（导入）到Hbase集群分布式列存储数据库中，hive与HBASE能够互相映射。
13.2 hive与HBASE整合：
我们如果搭建好hive数据仓库与HBASE集群不整合是不能够互相映射的，而版本兼容是能否映射的一个前提，在我们搭建任何功能分布式集群的时候，不仅仅hive与HBASE存在版本兼容问题，几乎任何技术功能模块都存在版本兼容问题，这需要我们在最初架构的时候做好各个版本兼容资料的收集，防止出现这个问题。
13.3 hive与HBASE哪些版本是兼容的：
hive0.90与hbase0.92是兼容的，早期的hive版本与hbase0.89/0.90兼容。
hive1.x与hbase0.98.x或则更低版本是兼容的。
hive2.x与hbase1.x及比hbase1.x更高版本兼容。
13.4 hive与HBASE不兼容的解决办法
hive-hbase-handler.jar的作用在hbase与hive整合的时候发挥了重要作用，有了这个包，hbase与hive才能通信。
我们需要做的是创建java的maven工程，下载自己对应版本hive的源码，找到它的hbase-handler文件导入工程，添加自己对应版本的hadoop、hive、HBASE相关依赖，然后打包导出，
修改相关配置文件：
hive的配置文件hive-site.xml（添加zk集群地址）
hive配置文件hive-env.sh，将hbase/bin目录下的包导入到hive环境变量中。
将我们导出的hive-hbase-handler.jar包替换掉hive/bin目录中的自带的hive-hbase-handler.jar包。
13.5 hive与hbase整合以后的状态：
Hive与hbase整合以后，有两种对应映射方式（hive-hbase，hbase-hive），我们可以建立一个hive的表映射到一个hbase表，也可以建立一个hbase的表映射到hive表，无论哪一种映射方式都会让着两个表处于相互感知的状态，保持数据的一致性，修改新增任何一个表，另一个表都会随之改变（建表时与另一个表映射的命令语句可以网络搜索查找，这里不做多余说明）。
这样就将hive的最终宽表成功映射到hbase集群中。
14 对应的hbase集群中的数据查询：
14.1我们已经把最终的数据保存到了hbase中，只需要查询显示即可，但是这里有一个问题，我们的数据中标签种类很多，查询的时候很不方便，这里可以用Phoenxi来解决，将hbase与Phoenxi整合，将hbase的表映射到Phoenxi中的映射表，这样就可以用简单的类似sql语句来查询并且在前端显示。
14.2 Phoenxi与Phoenxi安装与部署：
14.2.1 什么是Phoenxi：
Phoenix是一个HBase的开源SQL引擎。你可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据。也就是说你可以用sql语句来查询nosql类型的hbase数据库。Hive和impala虽然也可以这样做，但是Hive和impala还可以查询文本文件，Phoenix的特点就是，它只能查Hbase，别的类型都不支持！但是也因为这种专一的态度，让Phoenix在Hbase上查询的性能超过了Hive和Impala！
结论就是：hbase是一个nosql类型的分布式集群数据库，用了Phoenxi以后我们就可以把它看做传统的sql类型数据库，方便操作。
14.2.2 Phoenxi的效率：
Phoenxi会不影响hbase的效率？答案是不会，用了Phoenxi与自己手写hbase 语句相比效率会更高，少写了很多代码，此外Phoenxi还优化一些性能，实现二
级索引来提升非主键字段查询的性能。统计相关数据来提高并行化水平，并帮助
选择最佳优化方案。跳过扫描过滤器来优化IN，LIKE，OR查询。优化主键的来均 匀分布写压力。
14.2.3 Phoenxi安装部署：
14.2.3.1首先提前安装好ZK集群、hadoop集群、Hbase集群，
14.2.3.2在官网下载安装：http://mirrors.cnnic.cn/apache/phoenix/
14.2.3.3 在指定目录解压安装，
14.2.3.4 将Phoenxi目录下的phoenix-（phoenix版本）-HBase-（hbase版本）-server.jar、phoenix-core-（phoenix版本）-（hbase版本）.jar拷贝到各个 hbase的lib目录下
14.2.3.5将hbase的配置文件hbase-site.xml、 hadoop/etc/hadoop下的 core-site.xml 、hdfs-site.xml放到phoenix/bin/下，替换phoenix原来的 配置文件。
14.2.3.6 重启hbase集群。
14.2.3.7 测试语句和Phoenxi操作语句可以网站搜索，这里不做说明（我们连接数据库的软件SQLyog与Navicat都可以连接Phoenxi进行对Phoenxi表的操作）。
15 建立hbase表的映射Phoenxi表
两个表为互为映射感知的状态，与hive与hbase相同，无论两个表怎样操作，在另一个表都会自动感知到，并且做出修改（注意在Phoenxi建的表名需要与hbase对应映射的表名一致）。
16 数据可视化
这里我们可以用一些数据可视化工具来把我们Phoenxi表中的数据展现出来，也可以自己建立一个java-maven项目。但是目的都是一个就是要把数据呈现出来，并且最好可以做到筛选查询，这里我们介绍几种可视化工具。
16.1Jupyter
大数据可视化的一站式商店
JupyteR是一个开源项目，通过十多种编程语言实现大数据分析、可视化和软件开发的实时协作。它的界面包含代码输入窗口，并通过运行输入的代码以基于所选择的可视化技术提供视觉可读的图像。
但是，以上提到的功能仅仅是冰山一角。 Jupyter Notebook可以在团队中共享，以实现内部协作，并促进团队共同合作进行数据分析。团队可以将Jupyter Notebook上传到GitHub或Gitlab，以便能共同合作影响结果。团队可以使用Kubernetes将Jupyter Notebook包含在Docker容器中，也可以在任何其他使用Jupyter的机器上运行Notebook。在最初使用Python和R时，JupyterNotebook正在积极地引入Java，Go，C＃，Ruby等其他编程语言编码的内核。
除此以外，Jupyter还能够与Spark这样的多框架进行交互，这使得对从具有不同输入源的程序收集的大量密集的数据进行数据处理时，Jupyte能够提供一个全能的解决方案。
16.2Tableau
AI，大数据和机器学习应用可视化的最佳解决方案
Tableau是大数据可视化的市场领导者之一，在为大数据操作，深度学习算法和多种类型的AI应用程序提供交互式数据可视化方面尤为高效。
Tableau可以与AmazonAWS，MySQL，Hadoop，Teradata和SAP协作，使之成为一个能够创建详细图形和展示直观数据的多功能工具。这样高级管理人员和中间链管理人员能够基于包含大量信息且容易读懂的Tableau图形作出基础决策。
16.3GoogleChart
Google支持的免费而强大的整合功能
谷歌是当今领导力的代名词。正如谷歌浏览器是当前最流行的浏览器一样，谷歌图表也是大数据可视化的最佳解决方案之一，更不用说它是完全免费的，并得到了Google的大力技术支持。为什么它能得到Google的支持？因为通过Google Chart来分析的数据显然是要用于训练Google研发的AI，这样的合作对于各方来说都是双赢的。
Google Chart提供了大量的可视化类型，从简单的饼图、时间序列一直到多维交互矩阵都有。图表可供调整的选项很多。如果需要对图表进行深度定制，可以参考详细的帮助部分。
该工具将生成的图表以HTML5 / SVG呈现，因此它们可与任何浏览器兼容。Google Chart对VML的支持确保了其与旧版IE的兼容性，并且可以将图表移植到最新版本的Android和iOS上。更重要的是，Google Chart结合了来自Google地图等多种Google服务的数据。生成的交互式图表不仅可以实时输入数据，还可以使用交互式仪表板进行控制。
16.4 D3.js
以任何您需要的方式直观地显示大数据
D3.js代表DataDriven Document，一个用于实时交互式大数据可视化的JS库。由于这不是一个工具，所以用户在使用它来处理数据之前，需要对Java有一个很好的理解，并能以一种能被其他人理解的形式呈现。除此以外，这个JS库将数据以SVG和HTML5格式呈现，所以像IE7和8这样的旧式浏览器不能利用D3.js功能。
从不同来源收集的数据如大规模数据将与实时的DOM绑定并以极快的速度生成交互式动画（2D和3D）。 D3架构允许用户通过各种附件和插件密集地重复使用代码。
16.5 百度echarts
是国产的一个大数据可视化工具，效果展现好，逼真效果明显，用途比较广泛，适用性强，
可以访问http://echarts.baidu.com/examples/这个地址学习一些案列。
17 总结：
17.1 用户画像项目的整体流程：数据源端----hadoop集群----hive数据仓库---spark集群（sparkSql处理）---hive数据仓库---hbase集群----Phoenix---web显示（数据可视化）
17.2 我们在流程中全程对数据的处理用的sql语句，可以把它封装在shell脚本里面，然后用任务调度框架（azkaban、ooize、Zeus）定时来执行。
17.3 周期设置：
对于用户基本数据、交易数据、访问信息数据、是离线分析计算的，可以每天定时去执行任务，按天分区，将所有历史数据汇总统计分析，最后生成宽表模型。
最终的宽表模型并不需要每天去执行跑sql生成，它是对以往大量数据的分析处理，可以几个月半年为周期（这个要根据不同企业不同需求来指定）。