流式处理框架的演变

流式处理框架的演变

一、 传统数据处理的架构

1.1 事务处理

（1）简介：数据计算（compute）和数据存储分开（storage），实时与数据库进行交互并给用户response。
（2）优点：实时性高。
（3）缺点：能够同时处理的数据量有限，不能应对高并发。

1.2 分析处理

（1）简介：把数据从业务数据库进行ETL清洗、整合、提取出来，然后统一放到数据仓库中去，然后用数据分析的引擎进行查询分析处理，最后将结果生成报表或即席查询（注：即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。）
（2）优点：离线分析处理、高吞吐量、可应对高并发
（3）缺点：实时性不高、延迟高

二、 第一代流处理框架（有状态的流式处理）

（1） 简介

思考怎样将高吞吐量和高并发以及实时性同时兼顾呢？
首先要保持事务处理的原则，来一个处理一个，而传统事务处理的性能瓶颈在于于关系型数据库的实时交互（如做联表查询等）。所以有了如上图所示的第一代流式处理框架，在传统事务处理的基础上进行改进，将从关系型数据库获取相关数据改为将相关数据放到本地内存中，将其存成一个本地状态（local state），如果状态有更新，则将本地状态修改就好了，这样当客户端请求来了的时候直接从本地状态中获取相关数据然后返回response节省了大量的网络IO等操作，如果应对高并发，则可以做集群处理。应对服务器掉电导致存在内存中的本地状态丢失，可以做一个周期性检查点（periodic checkpoint），将periodic checkpoint放在远程的存储空间中，这样当节点故障之后进行恢复可以从远程存储空间将之前存盘的状态恢复就可以了。

（2）优点

可以应对高并发、有容错机制、实时性有保证。

（3）缺点

分布式架构下数据经过不同的分区任务进行处理之后到最后汇总可能存在时序混乱，造成结果不准确。

三、 第二代流处理框架（lambda架构）

（1）简介

lambda架构是第二代流处理架构，它同时运用了两套系统，两套架构，来同时保证了低延迟和结果准确。如果所示，lambda架构也是事件触发，分批处理层和流处理层两套处理，流处理会实时的很快速的让用户得到一个近似正确的结果存入Speed Table，批处理会将数据进行积攒，到了一定批量后执行计算得到一个精确的结果，并将其存入Batch Table，在Application应用程序上需要做出判断什么时候拿Speed Table表中的近似正确结果什么时候拿Batch Table中的精确结果。这样用户侧的感受是，发起request之后，会立即得到一个近似正确的结果，然后过一段时间后再看，会得到百分百正确的结果

（2）缺点

一个业务需求需要维护两套不同的系统，一旦需求做更改，则要同时改动两套系统，代价很高

四、 第三代流处理框架

（1） 如上图所示Spark Streaming、Storm、Flink反映了这三种第三代流处理引擎的特点。

五、Flink特点

（1）简介

传统的事务处理如第一章1.1所示（本节不做概述），Flink流程与其很相似，Application将事件日志读取进来，跟第一代流处理器一样也是将例如关系型数据库等其他维度数据保存成内部State并且考虑到容错将其checkpoint定期的存盘放到远程的存储空间中，将数据进行处理之后写入到下游输出的事件中去，或者触发一个action操作。

（2） 特点

1. 支持事件时间（event-time）和处理时间（processing-time）语义。
2. 精确一次（exactly-once）的状态一致性保证，即当出现故障时，也能保证数据都只会被消费一次，保证数据准确性。
3. 低延迟，每秒处理数百万个事件、毫秒级延迟。
4. 与众多常用存储系统的连接。
5. 高可用、动态扩展、实现7*24小时全天候运行。