在《什么的是用户画像》一文中，我们已经知道用户画像对于企业的巨大意义，当然也有着非常大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？
挑战大数据
随着互联网的崛起和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能获取的每一个用户的数据量是非常巨大的，而用户量本身更是巨大的，我们面临的是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) 数据集市,为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。面向应用。
当然最终提供的服务不仅仅是可视化的展示，还有实时数据的提供，最终形成用户画像的实时服务，形成产品化。