一、V1.0架构存在的问题

V1.0这个架构里面其实存在三个主要的问题

1、SparkStreaming程序的实时性不够

其实说实话，针对目前的粉丝实时关注数据，使用SparkStreaming程序来维护问题也不大，但是我们程序猿是要有追求的，既然有更好的方案，那我们肯定不能使用差的，所以这块我们我们需要使用Flink来实现，它可以提供真正意义上的实时。

、三度关系推荐数据适合存储在缓存系统中(Redis)

咱们前面把最终计算好的三度关系数据保存在了MySQL中。
其实这种数据是比较适合存储到一些基于内存的缓存系统中的，对查询的性能要求比较高，并且这些数据也是有时效性的，需要定时更新和删除老数据，所以说此时，使用redis是比较合适的，redis的查询性能比较高，并且redis中可以给key设置一个生存时间，可以实现定时删除过期数据的效果。
咱们这份数据是有2个字段，第一列是主播uid，第二列是待推荐的主播uid
存储到redis里面的话value使用list类型即可，在list类型里面存储待推荐的主播列表

3、为了规范数据使用，建议开发数据接口

咱们前面把存储系统直接暴露给其他业务部门，是不太安全的，并且他们使用起来也不方便，在实际工作中，各个业务部门之间进行数据交互，正规流程都是提供接口。
还有一个原因是这样的，我们在开发一个功能的时候，假设需要前端和后端同时开发，这个时候我们就需要提前把数据接口定义好，先提供假数据，这样前端和后端可以同时进行开发，前端在开发页面功能的时候就可以使用我们提供的数据接口了，当我们把后端功能搞定以后，修改数据接口的底层逻辑代码，接入真实的数据即可，这个时候对前端而言是没有任何影响的，就算后期我们修改表结构了，对前端也没有什么影响，只要接口没有变就行，这样也可以实现前端和后端的解耦。

二、技术选型

接下来再来回顾一下技术选型，看看在V2.0中有哪些变化
还是这4大块

在数据采集这块，去掉了Sqoop，因为在这里我们需要将三度关系数据导出到redis中，sqoop是不支持的，所以我们需要开发flink程序实现数据导出功能。

在数据存储这块，我们把MySQL改为了Redis

在数据计算这块，我们把Spark计算引擎改为了Flink，在V2.0中，我们将之前使用Spark开发的代码都使用Flink重新实现一遍。

数据展现模块没有变化。

三、整体架构设计

这是最新的架构图，在这里面，替换了Spark计算引擎和MySQL数据库，引入了Flink和Redis
以及在这里引入了数据接口模块，通过接口对外提供数据。
其它的地方没有变化。

注意：其实针对离线计算使用Spark或者Flink没有多大区别，不过我们还是希望一个项目中的计算框架相对来说是统一的，这样好管理，也好维护，所以在V2.0架构中，不管是离线计算还是实时计算，都使用Flink实现。

四、数据采集模块开发

数据采集模块没有变化，所以在这就不再分析了。