目前，越来越多的企业，在大数据应用上，都会选择用户画像这一主题，为什么呢？因为用户画像相对于做推荐以及机器学习等简单容易的多，做画像，更多是就是对用户数据的整合，然后做一些用户聚类、用推荐算法，比如基于用户的推荐和基于商品的推荐，获取用户或者进行商品营销应用。
而在我们的实际应用中，不仅有用户画像，而且有关于物的画像，比如设备画像。然而，大多数情况下有一种常见的错误想法是画像维度的数据越多越好，画像数据越丰富越好，费了很大的力气进行画像后，却发现只剩下了用户画像，和业务相差甚远，没有办法直接支持业务运营，投入精力巨大但是回报微小，可以说得不偿失。鉴于此，我们的画像的维度和设计原则都是紧紧跟着业务需求去推动。换句话说，对于数据的应用就是基于业务来做的，业务和数据双向驱动。
本篇文章，并不过多介绍用户画像如果去做，而是去解决用户画像数据存储与快速检索的痛点，如果想仔细了解用户画像，推荐一篇博客：用户画像构建策略及应用实践
在实际的项目中，常用的用户画像数据存储除了常规关系型数据块外，应用比较多的是Hbase和Elasticsearch集群的快速检索。所以在实际使用时，如果选型，要根据具体的业务来选择。下面说说着种方式：
1. 基于Hbase的用户画像
直观的表达就是用Hbase集群来存储用户的数据，使用rowkey快速检索方式来构建查询。
博主曾经接触过一个项目，rowkey基于用户身份证号码设计，因为每个人的身份证就是独一无二的，在根据用户不同维度的信息给用户打标签，做分类到最后做画像。
2. 基于Elasticserch的用户画像
直观的表达就是用ES集群来存储用户的数据，使用ES快速检索方式来构建查询。