在《什么的是用户画像》一文中，我们已经知道用户画像对于企业的巨大意义，当然也有着非常大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？
挑战
-
大数据
随着互联网的崛起和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能获取的每一个用户的数据量是非常巨大的，而用户量本身更是巨大的，我们面临的是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同样可以完成我们的需求，两者的取舍还是依照具体情况来做分析。
传统架构如下：
这样我们就形成，数据存储，计算，服务，管控的强有力的支撑，我们是否可以开始搭建大数据集群了呢？其实还不着急，在开工之前，需求的明确是无比重要的，针对不同的业务，电商，风控，还是其他行业都有着不同的需求，对于用户画像的要求也不同，那么该如何明确这些需求呢，最重要的就是定义好用户画像的标签体系，这是涉及技术人员，产品，运营等岗位共同讨论的结果，也是用户画像的核心所在，下一篇，我们将讨论用户画像的标签体系。未完待续~
参考文献
《用户画像：方法论与工程化解决方案》
更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算” 获取用户画像相关资料 请关注 “实时流式计算” 回复 “用户画像”
