在《什么的是用户画像》一文中，我们已经知道了用户画像对于企业的重大意义，当然也有很大的实时难度。那么用户画像的系统架构有哪些难点和需要考虑的关键问题呢？
挑战大数据随着互联网和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能从每个用户身上获取的数据量是巨大的，用户本身的量更大。我们面对的是TB级和PB级的数据，必须有一套高可用性和可扩展性的系统架构，能够支撑大数据量，以支持用户画像分析的实现。毫无疑问，大数据时代的到来，让这一切成为可能。近年来，以Hadoop为代表的大数据技术如雨后春笋，每隔一段时间就有新的技术诞生，不断推动业务向前发展，使得我们可以对用户画像进行简单的统计、复杂的分析和机器学习。因此，整体的用户画像系统必须建立在大数据架构之上。
Hadoop在实时性,兴起之初，大部分计算都是通过批处理来完成的，也就是T 1的处理模式。你要等一天才能知道前一天的结果。但是在用户画像领域，我们需要越来越多的实时考虑，需要第一时间得到各个维度的结果。在实时计算的前期，只有Storm占主导地位，但是Storm对时间窗、水印、触发器都没有很好的支持，保证数据一致性会耗费大量的性能。但Kafka、Flink等实时流计算框架的出现改变了这一切，数据一致性、事件时间窗、水印、触发器都变得容易实现。实时OLAP框架Druid使得交互式实时查询成为可能。这些高性能的实时框架成为我们构建实时用户画像的最强支撑。
数据仓库的概念在数据仓库有着悠久的历史。在我们获得了海量的数据之后，如何把数据变成我们想要的样子，这都需要ETL，也就是对数据进行提取、转换、加载，并把数据转换成我们想要的样子，存储在目标端的过程。毫无疑问，hive是离线数据存储的最佳选择，hive使用的新引擎tez也有非常好的查询性能。最近新版本的Flink也支持Hive，性能非常好。但在实时用户画像架构中，Hive是作为日常归档仓库存在的，作为历史数据形成的最终存储场所，同时也提供了查询历史数据的能力。Druid作为性能良好的实时数据仓库，将联合提供数据仓库查询和分析支持，Druid和Flink将联合提供实时处理结果。实时计算不再只是实时数据访问的一部分，而是真正起到了主导作用。所以两者的区别只在于数据处理过程。实时流处理是流的重复处理，形成一个又一个流表，而数据仓库的其他概念基本相同。数据仓库的基本概念如下：DB是已有的数据源(也叫各系统的元数据)，可以是mysql、SQLserver、文件日志等。数据仓库的数据源一般存在于现有的业务系统中。ETL是Extract-Transform-Load的缩写，用来描述将数据从源迁移到目标的几个过程：Extract，数据提取，即从数据源读取数据。转换，即数据转换，将原始数据转换为所需的格式和尺寸。如果在数据仓库场景中使用，Transform还包括数据清理，它清除掉噪声数据。Load data，将处理后的数据加载到目标，如数据仓库。ODS(业务数据存储)的业务数据是从数据库到数据仓库的过渡。ODS的数据结构一般与数据源一致，便于降低ETL的复杂度，ODS的数据周期一般较短。ODS数据最终流入dwdwdw(Data Warehouse)数据仓库，是数据的目的地。在这里，所有来自ODS的数据都会被长期保存，不会被修改。DM(Data Mart)数据集市(Data Mart)是独立于数据仓库的一部分数据，用于特定的应用目的或范围，也可以称为部门数据或主题数据。面向应用。
当然，最终提供的服务不仅仅是可视化展示，还有实时数据的提供，最终形成用户画像的实时服务，形成产品化。在整个数据处理过程中，我们还需要自动调度任务，消除我们的重复性工作，实现系统的自动运行。气流是一个非常好的调度工具。与旧的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同样可以完成我们的需求，两者的取舍还是依照具体情况来做分析。
传统架构如下：
这样我们就形成，数据存储，计算，服务，管控的强有力的支撑，我们是否可以开始搭建大数据集群了呢？其实还不着急，在开工之前，需求的明确是无比重要的，针对不同的业务，电商，风控，还是其他行业都有着不同的需求，对于用户画像的要求也不同，那么该如何明确这些需求呢，最重要的就是定义好用户画像的标签体系，这是涉及技术人员，产品，运营等岗位共同讨论的结果，也是用户画像的核心所在，下一篇，我们将讨论用户画像的标签体系。未完待续~
如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，
咱们下期见！学习更多JAVA知识与技巧，关注与私信博主（666）
