实时计算框架梳理(flink,kafka,hbase/redis,clickhouse)

最近刚学习完实时计算的框架构建，按照自己的理解梳理了一份框架流程图，如有错误欢迎指正。

框架总图：

先明确一个点，实时计算的关键在于数据生产和消费分离。

在最原始的时候，我们有一张维度数据表，可能存在MySQL中，然后有APP在前端或后端进行数据埋点，并采集行为日志。

行为日志本质上是一个文件，APP在产生日志的时候，为了防止单一过大的文件，会采取按时间间隔滚动或者大小滚动产生的机制，例如log4j有RollingFileAppender或者DailyRollingFileAppender的配置项。对于这样的日志文件，可以使用flume采集走，如果行为日志是存储在服务器集群上的，那么每一台服务器都需要安装flume，flume持续监控行为日志的目录。

一旦监控到有数据产生，进入kafka服务器，并建立一个topic，开始了数据处理。处理这样的数据时，通常使用flink，处理数据是模块化处理的，一个flink任务只会做一件事kafka各分区内开始堆积数据时，下游第一个flink开始消费kafka生产的数据，消费数据要遵循并行原则。在ods层中，flink消费数据的方式是对数据进行数据清洗，随后再放回kafka服务器中，并产生一个新的主题dwd。

下一层为dws层，数据在聚合的时候，通常还会分为两三个层次。先是秒级的dws窗口，然后是分钟，小时窗口。

例如处理秒级窗口的时候，用一个flink消费生产的dwd层数据，也就是对dwd数据进行聚合，这时候就需要进行流式处理了。流式处理首先要开时间窗口，画”水位线“，以第一条消息为基准定水位线的起点，然后再由自己设置的分段时间(此处假设5秒)，起点加上这个时间为终点。

当传来的消息时间戳在(t,t+5)的区间中，会进入分区，如果出现一条消息的时间戳大于t+5，那么这个分区就会锁起来，随后flink把这个分区的数据进行计算聚合，然后又进入kafka服务器，形成新的主题，成为秒级聚合的结果。

随后秒级聚合的结果，再进入flink计算得到分钟级结果，小时级也一样，整个过程与秒级几乎一样。

在这个流程中，有一种特殊情况，例如如果dwd层的数据因为各种原因，延时到达了flink，并且对应的时间窗口已经关闭，计算完的数据都已经输送到了下游。那么这样的数据会通过flink的侧输出流(side output)，直接进入dws-sec中，每一个分区都有可能发生这种情况。这样的话，dws-sec中就会包含一些“未计算”的异常数据，这样就需要进行判断数据是否被计算过，没有计算过则需要重新计算，已经完成计算的不做处理，在分级，小时级中，同样也会存在这样的情况，处理方式也一样。

最后的数据呈现，还是要写入到数据库中，看上述流程图可能会有一个误解，认为只有最后一层小时级数据可以写入，实际上每一层数据如果需要都可以写入到数据库中，出口是可以有多个的。数据库一般会使用clickhouse，它特别的点在于具有一个独特的kafka引擎，可以直接指向某个kafka主题形成一张表，极大方便了数据呈现。这样有了一个数据库，就可以进行select语句，把数据放到前端呈现出来。

上述流程还有一个过程刚才没被提及，那就是事实数据与维度数据的绑定，光有事实数据是无法进行数据呈现的(例如只有商品id，没有商品名)，而维度数据放在MySQL中。如果我们直接从MySQL中读取绑定，那必然会因为这个过程的响应慢而大大影响流式处理的速度。可以采取的方法有：用Redis或者Hbase预先把MySQL中的维度数据抽出来，然后数据清洗的过程中就把数据绑定到事实数据上。

整个流程就此结束。