为什么选择 Flink 做实时处理

优质博文：IT-BLOG-CN
  为什么选择 Flink

【1】流数据更真实地反映了我们的生存方式（实时谈天）；
【2】传统的数据架构是基于有限数据集的（Spark 是基于微批次数据处理）；
【3】我们的目标：低耽误、高吞吐（分布式架构，可能会出现次序上的杂乱，比如统计1个小时内，可能在1小时的时间，可能有的数据还在处理，会耽误到达几毫秒，这个可以通过设置来规避）、结果的正确性和良好的容错性；
哪些行业必要处理流数据（任选一个进行创业吧）

【1】电商和市场营销： 数据报表、广告投放、业务流程必要。例如：实时智能推荐 利用Flink流计算帮助用户构建更加实时的智能推荐系统，帮助企业提升销售额，创造更大的贸易代价；
【2】物联网（IOT）： 传感器实时数据采集和显示、实时报警，交通运输业 复杂事件处理 对于复杂事件处理，比较常见的案例紧张集中于工业领域，例如对车载传感器、机械设备等实时故障检测，这些业务范例通常数据量都非常大，且对数据处理的时效性要求非常高。通过利用Flink提供的CEP（复杂事件处理）进行事件模式的抽取，同时应用Flink的Sql进行事件数据的转换，在流式系统中构建实时规则引擎，一旦事件触发报警规则，便立即将告警结果传输至下游通知系统，从而实现对设备故障快速预警监测，车辆状态监控等目的；
【3】电信业： 基站流量调配；
【4】银行和金融业： 实时结算和通知推送，实时检测异常举动（不消再到晚上进行才进行批处理计算）。实时欺诈检测 在金融领域的业务中，经常出现各种范例的欺诈举动，例如名誉卡欺诈、信贷申请欺诈等，而怎样保证用户和公司的资金安全，是来比年来许多金融公司及银行共同面临的挑战。随着非法分子欺诈手段的不断升级，传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能必要几个小时才气通过生意业务数据计算出用户的举动指标，然后通过规则辨别出具有欺诈举动嫌疑的用户，再进行案件调查处理，在这种情况下资金可能早已被非法分子转移，从而给企业和用户造成大量的经济丧失。而运用Flink流式计算技术可以大概在毫秒内就完成对欺诈判定举动指标的计算，然后实时对生意业务流水进行规则判定或者模型预测，如许一旦检测出生意业务中存在欺诈嫌疑，则直接对生意业务进行实时拦截，避免因为处理不实时而导致的经济丧失；实时数仓与ETL
结合离线数仓，通过利用流计算诸多优势和SQL灵活的加工能力，对流式数据进行实时清洗、归并、结构化处理，为离线数仓进行补充和优化。另一方面结合实时数据ETL处理能力，利用有状态流式计算技术，可以尽可能低落企业由于在离线数据计算过程中调度逻辑的复杂度，高效快速地处理企业必要的统计结果，帮助企业更好地应用实时数据所分析出来的结果。
【5】流数据分析： 实时计算各类数据指标，并利用实时结果实时调整在线系统相干策略，在各类内容投放、无线智能推送领域有大量的应用。流式计算技术将数据分析场景实时化，帮助企业做到实时化分析Web应用或者App应用的各项指标，包括App版本分布情况、Crash检测和分布等，同时提供多维度用户举动分析，支持日志自主分析，助力开辟者实现基于大数据技术的风雅化运营、提升产品质量和体验、增强用户黏性。
【6】实时报表分析： 实时报表分析是比年来很多公司采用的报表统计方案之一，其中最紧张的应用便是实时大屏展示。利用流式计算实时得出的结果直接被推送到前端应用，实时显示出紧张指标的变更情况。最典范的案例便是淘宝的双十一运动，每年双十一购物节，除疯狂购物外，最引人注目的就是天猫双十一大屏不停跳跃的成交总额。在整个计算链路中包括从天猫生意业务下单购买到数据采集、数据计算、数据校验，最终落到双十一大屏上展现的全链路时间压缩在5秒以内，顶峰计算性能高达数三十万笔订单/秒，通过多条链路流计算备份确保十拿九稳。而在其他行业，企业也在构建自己的实时报表系统，让企业可以大概依托于自身的业务数据，快速提取出更多的数据代价，从而更好地服务于企业运行过程中。
传统数据处理架构

企业刚开始紧张进行事务处理：CRM 产生事件——在 Order 中进行逻辑处理——最终反馈给Click，数据都是通过关系型数据库获取，那么当对数据进行统计时，数据量大的时间就会碰到瓶颈。OLTP 特点是快速响应。缺点是数据量大时不易扩展。
微服务架构： 微服务架构将系统拆解成不同的独立服务模块，每个模块分别使用各自独立的数据库，这种模式解决了业务系统拓展的问题，但是也带来了新的问题，那就是业务生意业务数据过于分散在不同的系统中，很难将数据进行集中化管理，对于企业内部进行数据分析或者数据发掘之类的应用，则必要通过从不同的数据库中进行数据抽取，将数据从数据库或业务系统中周期性地同步到数据仓库中，然后在数据仓库中进行数据的抽取、转换、加载（ETL），从而构建成不同的数据集市和应用，提供给业务系统使用。但是对于一些时间要求比较高的应用，例如实时报表统计，则必须有非常低的延时展示统计结果，为此业界提出一套 Lambda架构方案来处理不同范例的数据。

分析处理： 将数据从业务数据库复制到数仓，再进行分析和查询。OLAP 特点是对大数据的数据分析，缺点是离线分析。

流处理的演变： Lambda 架构，用两套系统，同时保证低耽误和结果正确。例如使用 Hadoop MapReduce进行批量数据的处理，使用Apache Storm进行实时数据的处理。这种架构在一定程度上解决了不同计算范例的问题，但是带来的问题是框架太多会导致平台复杂度过高、运维本钱高等。在一套资源管理平台中管理不同范例的计算框架使用也是非常困难的事情。总而言之，Lambda 架构是构建大数据应用程序的一种很有效的解决方案，但是还不是最完美的方案。后来随着Apache Spark的分布式内存处理框架的出现，提出了将数据切分成微批的处理模式进行流式数据处理，从而可以大概在一套计算框架内完成批量计算和流式计算。但因为Spark本身是基于批处理模式的原因，并不能完美且高效地处理原生的数据流，因此对流式计算支持的相对较弱，可以说Spark的出现本质上是在一定程度上对Hadoop架构进行了一定的升级和优化。

有状态的流式处理： 我们平常开辟的Java应用系统时没有状态的。数据产生的本质，实在是一条条真实存在的事件，前面提到的不同的架构实在都是在一定程度违反了这种本质，必要通过在一定时延的情况下对业务数据进行处理，然后得到基于业务数据统计的正确结果。实际上，基于流式计算技术局限性，我们很难在数据产生的过程中进行计算并直接产生统计结果，因为这不仅对系统有非常高的要求，还必须要满足高性能、高吞吐、低延时等浩繁目标。而有状态流计算架构的提出，从一定程度上满足了企业的这种需求，企业基于实时的流式数据，维护全部计算过程的状态，所谓状态就是计算过程中产生的中心计算结果，每次计算新的数据进入到流式系统中都是基于中心状态结果的根本上进行运算，最终产生精确的统计结果。基于有状态计算的方式最大的优势是不必要将原始数据重新从外部存储中拿出来，从而进行全量计算，因为这种计算方式的代价可能是非常高的。从另一个角度讲，用户无须通过调度和协调各种批量计算工具，从数据仓库中获取数据统计结果，然后再落地存储，这些操作全部都可以基于流式计算完成，可以极大地减轻系统对其他框架的依赖，减少数据计算过程中的时间斲丧以及硬件存储。将数据存储在本地内存，假如处理的过程中某个节点挂了，数据怎样保存。就有了 RemoteStorage（内存的一个快照）实现了毫秒级别的耽误。但是问题是分布式项目不能保证数据处理的次序，不能保证数据的正确性，在并发性上和吞吐量上存在瓶颈。Stom的实现方式。

   假如计算的结果能保持一致，实时计算在很短的时间内统计出结果，批量计算则必要等候一定时间才气得出，相信大多数用户会更加倾向于选择使用有状态流进行大数据处理。
  流处理的演变： 整合 Spark Streaming 的高吞吐和精确性（使用的时间必要设置500ms之上耽误）和 Storm的低耽误。Flink通过实现Google Dataflow流式计算模型实现了高吞吐、低耽误、高性能兼具实时流式计算框架。同时Flink支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现丢失，Flink周期性地通过分布式快照技术 Checkpoints实现状态的长期化维护，使得即使在系统停机或者异常的情况下都能计算出精确的结果。而 Flink也在每一次的 Release版本中，不断推出新的特性，例如Queryable State功能的提出，容许用户通过长途的方式直接获取流式计算使命的状态信息，数据不必要落地数据库就能直接从Flink流式应用中查询。对于实时交互式的查询业务可以直接从Flink的状态中查询最新的结果。在未来，Flink将不仅作为实时流式处理的框架，更多的可能会成为一套实时的状态存储引擎，让更多的用户从有状态计算的技术中获益。

Flink 的紧张特点

事件驱动（Event-driven）

基于流的世界观： 在Flink 的世界观中，齐备都是由流构成的，离线数据是有界的流；实时数据是一个没有边界的流：这就是所谓的有界流和无界流。

分成API 的设置： 越顶层越抽象，表达含义越简明，使用越方便。越底层越详细，表达能力越丰富，使用越灵活。

Flink 的其他特点

【1】同时支持高吞吐、每秒处理数百万个事件，毫秒级耽误、高性能： Flink是目前开源社区中唯一集高吞吐、低耽误、高性能三者于一身的分布式流式数据处理框架。像Apache Spark也只能兼顾高吞吐和高性能特性，紧张因为在Spark Streaming流式计算中无法做到低耽误保障；而流式计算框架Apache Storm只能支持低耽误和高性能特性，但是无法满足高吞吐的要求。而满足高吞吐、低耽误、高性能这三个目标对分布式流式计算框架来说是非常紧张的。
【2】支持事件时间（event-time）和处理时间（processing-time）语义： 在流式计算领域中，窗口计算的职位举足轻重，但目前大多数框架窗口计算采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时间。Flink可以大概支持基于事件时间（Event Time）语义进行窗口计算，也就是使用事件产生的时间，这种基于事件驱动的机制使得事件即使乱序到达，流系统也可以大概计算出精确的结果，保持了事件本来产生时的时序性，尽可能避免网络传输或硬件系统的影响。
【3】精确一次（exactly-once）的状态一致性保证： 所谓状态就是在流式计算过程中将算子的中心结果数据保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中心结果中计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，这种方式极大地提升了系统的性能，并低落了数据计算过程的资源斲丧。对于数据量大且运算逻辑非常复杂的流式计算场景，有状态计算发挥了非常紧张的作用。
【4】支持高度灵活的窗口（Window）操作： 在流处理应用中，数据是连续不断的，必要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去的1分钟内有多少用户点击某一网页，在这种情况下，我们必须界说一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行再计算。Flink将窗口划分为基于Time、Count、Session，以及Data-driven等范例的窗口操作，窗口可以用灵活的触发条件定制化来到达对复杂的流传输模式的支持，用户可以界说不同的窗口触发机制来满足不同的需求。
【5】基于轻量级分布式快照（Snapshot）实现的容错： Flink可以大概分布式运行在上千个节点上，将一个大型计算使命的流程拆解成小的计算过程，然后将tesk分布到并行节点上进行处理。在使命执行过程中，可以大概自动发现事件处理过程中的错误而导致数据不一致的问题，比如：节点宕机、网路传输问题，或是由于用户因为升级或修复问题而导致计算服务重启等。在这些情况下，通过基于分布式快照技术的Checkpoints，将执行过程中的状态信息进行长期化存储，一旦使命出现异常停止，Flink就可以大概从Checkpoints中进利用命的自动恢复，以确保数据在处理过程中的一致性。
【5】与浩繁常用存储系统的链接： kafka、redis、hive、dfs等服务器进行链接
【6】Save Points（保存点）： 高可用，动态扩展，实现724小时全天候运行，对于724小时运行的流式应用，数据源源不断地接入，在一段时间内应用的终止有可能导致数据的丢失或者计算结果的不正确，例如进行集群版本的升级、停机运维操作等操作。值得一提的是，Flink通过Save Points技术将使命执行的快照保存在存储介质上，当使命重启的时间可以直接从事先保存的Save Points恢复原有的计算状态，使得使命继承按照停机之前的状态运行，Save Points技术可以让用户更好地管理和运维实时流式应用。
【7】基于JVM实现独立的内存管理： 内存管理是全部计算框架必要重点思量的部门，尤其对于计算量比较大的计算场景，数据在内存中该怎样进行管理显得至关紧张。针对内存管理，Flink实现了自身管理内存的机制，尽可能减少JVM GC对系统的影响。别的，Flink通过序列化/反序列化方法将全部的数据对象转换成二进制在内存中存储，低落数据存储的巨细的同时，可以大概更加有效地对内存空间进行利用，低落GC带来的性能降落或使命异常的风险，因此Flink较其他分布式处理的框架会显得更加稳定，不会因为JVM GC等问题而影响整个应用的运行。
Flink vs Spark Streaming

流（Stream）和微批（micro-batching）

数据模型： spark 采用RDD模型，spark streaming 的 DStream 实际上也就是一组小批数据 RDD 的聚集。Flink 根本数据模型是数据流，以及事件（Event）序列。
运行时架构： spark 是批计算，将 DAG 划分为不同的 stage，一个完成后才可以计算下一个。Flink 是标准的流执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。
学习建议

【1】先实践再理论： 先学习应用，尝试构建复杂的 Flink Application
【2】横向扩展： 在构建复杂 Flink 生财产务后，横向使用学习 Storm、Spark、DataFlow 等系统，知识是演化过来的，必有前置和铺垫。多横向看看，打开视野。
【3】关注 Apache Flink 以及 Flink China 社区： 多交流，多提问，多输出。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。