为什么选择 Flink
【1】流数据更真实地反映了我们的生活方式（实时聊天）；
【2】传统的数据架构是基于有限数据集的（Spark 是基于微批次数据处理）；
【3】我们的目标：低延迟、高吞吐（分布式架构，可能会出现顺序上的混乱，比如统计1个小时内，可能在1小时的时候，可能有的数据还在处理，会延迟到达几毫秒，这个可以通过设置来规避）、结果的准确性和良好的容错性；
哪些行业需要处理流数据
【1】电商和市场营销：数据报表、广告投放、业务流程需要；
【2】物联网（IOT）：传感器实时数据采集和显示、实时报警，交通运输业；
【3】电信业：基站流量调配；
【4】银行和金融业：实时结算和通知推送，实时检测异常行为（不用再到晚上进行才进行批处理计算）；
传统数据处理架构
企业刚开始主要进行事务处理：CRM 产生事件——在 Order 中进行逻辑处理——最终反馈给Click，数据都是通过关系型数据库获取，那么当对数据进行统计时，数据量大的时候就会遇到瓶颈。OLTP 特点是快速响应。缺点是数据量大时不易扩展。
分析处理：将数据从业务数据库复制到数仓，再进行分析和查询。OLAP 特点是对大数据的数据分析，缺点是离线分析。
有状态的流式处理：将数据存储在本地内存，如果处理的过程中某个节点挂了，数据如何保存。就有了 RemoteStorage（内存的一个快照）实现了毫秒级别的延迟。但是问题是分布式项目不能保证数据处理的顺序，不能保证数据的准确性，在并发性上和吞吐量上存在瓶颈。Stom的实现方式。
流处理的演变：Lambda 架构，用两套系统，同时保证低延迟和结果准确。问题就是麻烦，需要两套架构。
流处理的演变：整合 Spark Streaming 的高吞吐和正确性（使用的时候需要设置500ms之上延迟）和Storm的低延迟。
Flink 的主要特点
事件驱动（Event-driven）
基于流的世界观：在Flink 的世界观中，一切都是由流组成的，离线数据是有界的流；实时数据是一个没有界限的流：这就是所谓的有界流和无界流。
分成API 的设置：越顶层越抽象，表达含义越简明，使用越方便。越底层越具体，表达能力越丰富，使用越灵活。
Flink 的其他特点
支持事件时间（event-time）和处理时间（processing-time）语义：对时间进行不同的定义；
精确一次（exactly-once）的状态一致性保证：正确性更加准确；
低延迟，每秒处理数百万个事件，毫秒级延迟
与众多常用存储系统的链接：kafka、redis、hive、dfs等服务器进行链接
高可用，动态扩展，实现7*24小时全天候运行
Flink vs Spark Streaming
流（Stream）和微批（micro-batching）
数据模型：spark 采用RDD模型，spark streaming 的 DStream 实际上也就是一组小批数据 RDD 的集合。Flink 基本数据模型是数据流，以及事件（Event）序列。
运行时架构：spark 是批计算，将 DAG 划分为不同的 stage，一个完成后才可以计算下一个。Flink 是标准的流执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。
----关注公众号，获取更多内容----