简介

用户画像，作为一种勾画目标用户、联系用户诉求与设计方向的有效工具，用户画像在各领域得到了广泛的应用。

用户画像最初是在电商领域得到应用的，在大数据时代背景下，用户信息充斥在网络中，将用户的每个具体信息抽象成标签，利用这些标签将用户形象具体化，从而为用户提供有针对性的服务。

还记得年底收到的支付宝年度消费账单吗？帮助客户回顾一年的消费细节，包括消费能力、消费去向、信用额度等等，再根据每位客户的消费习惯，量身定制商品推荐列表……这一活动，将数据这个量化的词以形象生动的表现手法推到了大众面前。

​这就是用户画像在电商领域的一个应用，随着我国电子商务的高速发展，越来越多的人注意到数据信息对于电商市场的推动作用。基于数据分析的精准营销方式，可以最大限度的挖掘并留住潜在客户，数据统计与分析为电商市场带来的突破不可估量。在大数据时代，一切皆可“量化”，看似普通的小小数字背后，蕴藏着无限商机，也正在被越来越多的企业所洞悉。

如何从大数据中挖掘商机？建立用户画像和精准化分析是关键。

用户画像可以使产品的服务对象更加聚焦，更加的专注。在行业里，我们经常看到这样一种现象：做一个产品，期望目标用户能涵盖所有人，男人女人、老人小孩、专家小白、文青屌丝...... 通常这样的产品会走向消亡，因为每一个产品都是为特定目标群的共同标准而服务的，当目标群的基数越大，这个标准就越低。换言之，如果这个产品是适合每一个人的，那么其实它是为最低的标准服务的，这样的产品要么毫无特色，要么过于简陋。

纵览成功的产品案例，他们服务的目标用户通常都非常清晰，特征明显，体现在产品上就是专注、极致，能解决核心问题。比如苹果的产品，一直都为有态度、追求品质、特立独行的人群服务，赢得了很好的用户口碑及市场份额。又比如豆瓣，专注文艺事业十多年，只为文艺青年服务，用户粘性非常高，文艺青年在这里能找到知音，找到归宿。所以，给特定群体提供专注的服务，远比给广泛人群提供低标准的服务更接近成功。

其次，用户画像可以在一定程度上避免产品设计人员草率的代表用户。代替用户发声是在产品设计中常出现的现象，产品设计人员经常不自觉的认为用户的期望跟他们是一致的，并且还总打着“为用户服务”的旗号。这样的后果往往是：我们精心设计的服务，用户并不买账，甚至觉得很糟糕。

​在产品研发和营销过程中，确定目标用户是首要任务。不同类型的用户往往有不同甚至相冲突的需求，企业不可能做出一个满足所有用户的产品和营销。因此，通过大数据建立用户画像是必不可少的。

这只是用户画像在电商领域的应用，事实上用户画像已经不知不觉的渗透到了各个领域，在当前最火的抖音，直播等领域，推荐系统在大数据时代到来以后，用户的一切行为都是可以追溯分析的。

步骤

什么是用户画像？用户画像是根据市场研究和数据，创建的理想中客户虚构的表示。创建用户画像，这将有助于理解现实生活中的目标受众。企业创建的人物角色画像，具体到针对他们的目标和需求，并解决他们的问题，同时，这将帮助企业更加直观的转化客户。

用户画像最重要的一个步骤就是对用户标签化，我们要明确要分析用户的各种维度，才能确定如何对用户进行画像。

​ 在建立用户画像上，有很多个步骤：

首先，基础数据收集，电商领域大致分为行为数据、内容偏好数据、交易数据，如浏览量、访问时长、家具偏好、回头率等等。而金融领域又有贷款信息，信用卡，各种征信信息等等。然后，当我们对用户画像所需要的基础数据收集完毕后，需要对这些资料进行分析和加工，提炼关键要素，构建可视化模型。对收集到的数据进行行为建模，抽象出用户的标签。电商领域可能是把用户的基本属性、购买能力、行为特征、兴趣爱好、心理特征、社交网络大致的标签化，而金融风控领域则是更关注用户的基本信息，风险信息，财务信息等等。随后，要利用大数据的整体架构对标签化的过程进行开发实现，对数据进行加工，将标签管理化。同时将标签计算的结果进行计算。这个过程中需要依靠Hive，Hbase等大数据技术，为了提高数据的实时性，还要用到Flink，Kafka等实时计算技术。最后，也是最关键的一步，要将我们的计算结果，数据，接口等等，形成服务。比如，图表展示，可视化展示。

事实上，在构建用户画像过程中，注重提取数据的多元性而不是单一性，譬如针对不同类型的客户提取不同的数据，又或者针对线上线下的客户分析其中差异。总而言之，保证数据的丰富性、多样性、科学性，是建立精准用户画像的前提。

当用户画像基本成型后，接下来就可以对其进行形象化、精准化的分析。此时一般是针对群体的分析，如可以根据用户价值来细分出核心用户、评估某一群体的潜在价值空间，以此作出针对性的产品结构、经营策略、客户引导的调整。因此，突出研发和展示此类型的产品，又在家具的整体搭配展示中进行相关的主题设计，以此吸引目标人群的关注和购买。

毫无疑问，大数据在商业市场中的运用效果已经突显，在竞争激烈的各个行业，谁能抓住大数据带来的优势，谁才更有机会引领行业的未来。

实时用户画像

现在大数据应用比较火爆的领域，比如推荐系统在实践之初受技术所限，可能要一分钟，一小时，甚至更久对用户进行推荐，这远远不能满足需要，我们需要更快的完成对数据的处理，而不是进行离线的批处理。

现在企业对于数据的实时要求越来越高，已经不满足于T+1的方式，有些场景下不可能间隔一天才反馈出结果。特别是推荐，风控等领域，需要小时，分钟，甚至秒级别的实时数据响应。而且这种秒级别响应的不只是简单的数据流，而且经过与离线计算一样的，复杂的聚合分析之后的结果，这种难度其实非常大。

幸好实时计算框架的崛起足够我们解决这些问题，近年来Flink，Kafka等实时计算技术的框架与技术越来越稳定，足够我们支撑这些使用场景。

在实时用户画像的构建中，通过对实时数据的不断迭代计算，逐渐的不断完善出用户画像的全貌，这也正符合数据传输的本质，这整体架构中，淡化离线计算在之前特别重的作用，只留做归档和历史查询使用，更多的数据通过实时计算进行输出，最终达到对用户画像的目的。

在实时计算的过程需要对数据实时聚合计算，而复杂的标签也需要实时的进行机器学习，难度巨大，但是最终对于画像的实时性有着重大的意义。

本文介绍了用户画像的简介与实时用户画像的重要意义，但是用什么技术架构可以支撑这些想法的实现呢？

通过上面的介绍，我们已经知道用户画像对于企业的巨大意义，当然也有着非常大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？

挑战

大数据

随着互联网的崛起和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能获取的每一个用户的数据量是非常巨大的，而用户量本身更是巨大的，我们面临的是TB级，PB级的数据，所以我们必须要一套可以支撑大数据量的高可用性，高扩展性的系统架构来支撑用户画像分析的实现。毫无疑问，大数据时代的到来让这一切都成为可能，近年来，以Hadoop为代表的大数据技术如雨后春笋般迅速发展，每隔一段时间都会有一项新的技术诞生，不断驱动的业务向前，这让我们对于用户画像的简单统计，复杂分析，机器学习都成为可能。所以整体用户画像体系必须建立在大数据架构之上。

实时性

在Hadoop崛起初期，大部分的计算都是通过批处理完成的，也就是T+1的处理模式，要等一天才能知道前一天的结果。但是在用户画像领域，我们越来越需要实时性的考虑，我们需要在第一时间就得到各种维度的结果，在实时计算的初期只有Storm一家独大，而Storm对于时间窗口，水印，触发器都没有很好的支持，而且保证数据一致性时将付出非常大的性能代价。但Kafka和Flink等实时流式计算框架的出现改变了这一切，数据的一致性，事件时间窗口，水印，触发器都成为很容易的实现。而实时的OLAP框架Druid更是让交互式实时查询成为可能。这这些高性能的实时框架成为支撑我们建立实时用户画像的最有力支持。

数据仓库

数据仓库的概念由来已久，在我们得到海量的数据以后，如何将数据变成我们想要的样子，这都需要ETL，也就是对数据进行抽取（extract）、转换（transform）、加载（load）的过程，将数据转换成想要的样子储存在目标端。毫无疑问，Hive是作为离线数仓的不二选择，而hive使用的新引擎tez也有着非常好的查询性能，而最近新版本的Flink也支持了hive性能非常不错。但是在实时用户画像架构中，Hive是作为一个按天的归档仓库的存在，作为历史数据形成的最终存储所在，也提供了历史数据查询的能力。而Druid作为性能良好的实时数仓，将共同提供数据仓库的查询与分析支撑，Druid与Flink配合共同提供实时的处理结果，实时计算不再是只作为实时数据接入的部分，而真正的挑起大梁。

所以，两者的区别仅在于数据的处理过程，实时流式处理是对一个个流的反复处理，形成一个又一个流表，而数仓的其他概念基本一致。

数仓的基本概念如下：

DB 是现有的数据来源(也称各个系统的元数据)，可以为mysql、SQLserver、文件日志等，为数据仓库提供数据来源的一般存在于现有的业务系统之中。

ETL的是 Extract-Transform-Load 的缩写，用来描述将数据从来源迁移到目标的几个过程：

Extract，数据抽取，也就是把数据从数据源读出来。

Transform，数据转换，把原始数据转换成期望的格式和维度。如果用在数据仓库的场景下，Transform也包含数据清洗，清洗掉噪音数据。

Load 数据加载，把处理后的数据加载到目标处，比如数据仓库。

ODS(Operational Data Store) 操作性数据，是作为数据库到数据仓库的一种过渡，ODS的数据结构一般与数据来源保持一致，便于减少ETL的工作复杂性，而且ODS的数据周期一般比较短。ODS的数据最终流入DW

DW (Data Warehouse)数据仓库，是数据的归宿，这里保持这所有的从ODS到来的数据，并长期保存，而且这些数据不会被修改。

DM(Data Mart) 数据集市，为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。面向应用。

当然最终提供的服务不仅仅是可视化的展示，还有实时数据的提供，最终形成用户画像的实时服务，形成产品化。

在整个数据的处理过程中我们还需要自动化的调度任务，免去我们重复的工作，实现系统的自动化运行，Airflow就是一款非常不错的调度工具，相比于老牌的Azkaban 和 Oozie，基于Python的工作流DAG，确保它可以很容易地进行维护，版本化和测试。

至此我们所面临的问题都有了非常好的解决方案，下面我们设计出我们系统的整体架构，并分析我们需要掌握的技术与所需要的做的主要工作。

系统架构

依据上面的分析与我们要实现的功能，我们将依赖Hive和Druid建立我们的数据仓库，使用Kafka进行数据的接入，使用Flink作为我们的流处理引擎，对于标签的元数据管理我们还是依赖Mysql作为把标签的管理，并使用Airflow作为我们的调度任务框架，并最终将结果输出到Mysql和Hbase中。对于标签的前端管理，可视化等功能依赖Springboot+Vue.js搭建的前后端分离系统进行展示，而Hive和Druid的可视化查询功能，我们也就使用强大的Superset整合进我们的系统中，最终系统的架构图设计如下：

相对于传统的技术架构，实时技术架构将极大的依赖于Flink的实时计算能力，当然大部分的聚合运算我们还是可以通过Sql搞定，但是复杂的机器学习运算需要依赖编码实现。而标签的存储细节还是放在Mysql中，Hive与Druid共同建立起数据仓库。相对于原来的技术架构，只是将计算引擎由Spark换成了Flink，当然可以选择Spark的structured streaming同样可以完成我们的需求，两者的取舍还是依照具体情况来做分析。

传统架构如下：

这样我们就形成，数据存储，计算，服务，管控的强有力的支撑，我们是否可以开始搭建大数据集群了呢？其实还不着急，在开工之前，需求的明确是无比重要的，针对不同的业务，电商，风控，还是其他行业都有着不同的需求，对于用户画像的要求也不同，那么该如何明确这些需求呢，最重要的就是定义好用户画像的标签体系，这是涉及技术人员，产品，运营等岗位共同讨论的结果，也是用户画像的核心所在。

转自：什么是用户画像——从零开始搭建实时用户画像(一)_java领域的博客-CSDN博客