简述流计算的场景

从我最开始接触的流计算场景来阐述最近的一些心得，先以场景入手。

典型场景：实时推荐、设备检测、欺诈检测、实时报表/数仓（构建）

一般有三种方式，一种是基于物品：根据用户喜欢的物品标签，寻找相似标签下的物品推荐给用户。一种是根据用户：通过用户标签寻找相似用户，将相似用户下喜欢的物品推荐给用户。最后一种是根据标签：总结用户喜欢过的物品有什么特征，将包含这些特征的物品推荐给用户。

基于标签的实时推荐，关键是将兴趣标签划分了两部分，长期、短期兴趣标签。长期标签为不会发生频繁变化的标签，一般为性别、年龄、消费习惯、居住地等，可以用离线计算。短期标签为通过用户当前行为（几分钟内用户浏览或者点击了哪些内容）通过流计算得到的标签。

这个场景中的流计算就比较简单了，主要是解析数据与简单清晰。

这两个案例的大的架构差别不大。

这个案例大家在双十一的时候，看淘宝的实时交易就很清楚了。交易数据一般是存放在关系型数据库中，阿里通过DTS工具将RDS中的数据变化转化成流式数据。

最后说下实时数仓

这里引用下美团的实时数仓案例。

传统数仓模型

实时数仓模型

实时数仓和传统数仓的对比主要可以从四个方面考虑：

第一个是分层方式，离线数仓为了考虑到效率问题，一般会采取空间换时间的方式，层级划分会比较多；则实时数仓考虑到实时性问题，一般分层会比较少，另外也减少了中间流程出错的可能性。

第二个是事实数据存储方面，离线数仓会基于 HDFS，实时数仓则会基于消息队列（如 Kafka）。

第三个是维度数据存储，实时数仓会将数据放在 KV 存储上面。

第四个是数据加工过程，离线数仓一般以 Hive、Spark 等批处理为主，而实时数仓则是基于实时计算引擎如 Storm、Flink 等，以流处理为主

准实时数仓模型

在以上两种数仓模型之外，美团发现业务方在实践过程中还有一种准实时数仓模型，其特点是不完全基于流去做，而是将明细层数据导入到 OLAP 存储中，基于 OLAP 的计算能力去做汇总并进行进一步的加工。

实时数仓建设方案对比

下面对实时数仓的两种建设方式，即准实时数仓和实时数仓两种方式进行了对比。它们的实现方式分别是基于 OLAP 引擎和流计算引擎，实时度则分别是分钟和秒级。

在调度开销方面，准实时数仓是批处理过程，因此仍然需要调度系统支持，虽然调度开销比离线数仓少一些，但是依然存在，而实时数仓却没有调度开销。

在业务灵活性方面，因为准实时数仓基于 OLAP 引擎实现，灵活性优于基于流计算的方式。

在对数据晚到的容忍度方面，因为准实时数仓可以基于一个周期内的数据进行全量计算，因此对于数据晚到的容忍度也是比较高的，而实时数仓使用的是增量计算，对于数据晚到的容忍度更低一些。

在扩展性方面，因为准实时数仓的计算和存储是一体的，因此相比于实时数仓，扩展性更弱一些。

在适用场景方面，准实时数仓主要用于有实时性要求但不太高、数据量不大以及多表关联复杂和业务变更频繁的场景，如交易类型的实时分析，实时数仓则更适用于实时性要求高、数据量大的场景，如实时特征、流量分发以及流量类型实时分析。

关于实时数仓，会在其他文章中详述，内容还是很多的。