用户画像的技术选型与架构实现

这里讲解下用户画像的技术架构和整体实现，那么就从数据整理、数据平台、面向应用三个方面来讨论一个架构的实现（个人见解）。

数据整理：

1、数据指标的的梳理来源于各个系统日常积累的日志记录系统，通过sqoop导入hdfs,也可以用代码来实现，比如spark的jdbc连接传统数据库进行数据的cache。还有一种方式，可以通过将数据写入本地文件，然后通过sparksql的load或者hive的export等方式导入HDFS。

2、通过hive编写UDF 或者hiveql 根据业务逻辑拼接ETL，使用户对应上不同的用户标签数据（这里的指标可以理解为为每个用户打上了相应的标签），生成相应的源表数据,以便于后续用户画像系统，通过不同的规则进行标签宽表的生成。

数据平台

1、数据平台应用的分布式文件系统为Hadoop的HDFS，因为Hadoop2.0以后,任何的大数据应用都可以通过ResoureManager申请资源，注册服务。比如(sparksubmit、hive）等等。而基于内存的计算框架的出现，就并不选用hadoop的MapReduce了。当然很多离线处理的业务，很多人还是倾向于使用Hadoop,但是hadoop的封装的函数只有map和Reduce太过单一，而不像spark一类的计算框架有更多封装的函数（可参考博客spark专栏）。可以大大提升开发效率。

2、计算的框架选用Spark以及RHadoop,这里Spark的主要用途有两种，一种是对于数据处理与上层应用所指定的规则的数据筛选过滤，(通过Scala编写spark代码提交至sparksubmit)。一种是服务于上层应用的SparkSQL（通过启动spark thriftserver与前台应用进行连接）。 RHadoop的应用主要在于对于标签数据的打分，比如利用协同过滤算法等各种推荐算法对数据进行各方面评分。

3、MongoDB内存数据的应用主要在于对于单个用户的实时的查询，也是通过对spark数据梳理后的标签宽表进行数据格式转换(json格式）导入mongodb,前台应用可通过连接mongodb进行数据转换，从而进行单个标签的展现。（当然也可将数据转换为Redis中的key value形式，导入Redis集群)

4、mysql的作用在于针对上层应用标签规则的存储，以及页面信息的展现。后台的数据宽表是与spark相关联，通过连接mysql随后cache元数据进行filter,select,map,reduce等对元数据信息的整理,再与真实存在于Hdfs的数据进行处理。

面向应用

1、从刚才的数据整理、数据平台的计算，都已经将服务于上层应用的标签大宽表生成。（用户所对应的各类标签信息）。那么前台根据业务逻辑，勾选不同的标签进行求和、剔除等操作，比如本月流量大于200M用户（标签）+本月消费超过100元用户（标签）进行和的操作，通过前台代码实现sql的拼接，进行客户数目的探索。这里就是通过jdbc的方式连接spark的thriftserver，通过集群进行HDFS上的大宽表的运算求count。（这里要注意一点，很多sql聚合函数以及多表关联join 相当于hadoop的mapreduce的shuffle,很容易造成内存溢出，相关参数调整可参考本博客spark栏目中的配置信息） 这样便可以定位相应的客户数量，从而进行客户群、标签的分析，产品的策略匹配从而精准营销。