用户画像系统架构——从零开始搭建实时用户画像(二)

​

​ 在《什么的是用户画像》一文中，咱们已经知道用户画像对于企业的巨大意义，固然也有着很是大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？

挑战

• 大数据

  随着互联网的崛起和智能手机的兴起，以及物联网带来的各类可穿戴设备，咱们能获取的每个用户的数据量是很是巨大的，而用户量自己更是巨大的，咱们面临的是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一样能够完成咱们的需求，二者的取舍仍是依照具体状况来作分析。

传统架构以下：

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

参考文献

《用户画像：方法论与工程化解决方案》

更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算”