在整个数据的处理过程中我们还需要自动化的调度任务，免去我们重复的工作，实现系统的自动化运行，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同样可以完成我们的需求，两者的取舍还是依照具体情况来做分析。
传统架构如下：
这样我们就形成，数据存储，计算，服务，管控的强有力的支撑，我们是否可以开始搭建大数据集群了呢？其实还不着急，在开工之前，需求的明确是无比重要的，针对不同的业务，电商，风控，还是其他行业都有着不同的需求，对于用户画像的要求也不同，那么该如何明确这些需求呢，最重要的就是定义好用户画像的标签体系，这是涉及技术人员，产品，运营等岗位共同讨论的结果，也是用户画像的核心所在，下一篇，我们将讨论用户画像的标签体系。未完待续~
参考文献
《用户画像：方法论与工程化解决方案》
更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算”