一、Flink简介
Apache Flink® - Stateful Computations over Data Streams
上面是官网的介绍,翻译过来是流数据上的有状态的计算。
-Flink执行模型:
1.流计算:数据不断产生,一致处于计算状态
2.批处理:完成一定时间段的计算任务
官网给的有中文网站链接,github上面也有很多开源的翻译~https://flink.apache.org/zh/usecases.html
目录
1、时间驱动型应用
2、数据分析应用
典型的数据分析应用实例
3、数据管道应用
典型的数据管道应用实例
-Flink的主要特性包括:批流一体化,精密的状态管理,时间事件支持以及精确一次性的状态一致性保障等。
二、Flink的主要应用
首先他是一类具有状态的应用,从一个或多个时间流提取数据,并根据到来的时间触发计算、状态更新呢或者外部的其它动作。事件驱动应用是在计算存储分离的传统应用基础上进化而来的。在传统架构中,应用需要读写远程事务型数据库。相反,事件驱动型应用是基于状态流处理来完成的。在该设计中,数据和计算不会分离,应用只需访问本地(内存或磁盘)即可获取数据。系统容错性的实现是依赖于定期向远程持久节点存储写入checkpoint。下图是传统应用和事件驱动架构的区别。
Flink官网示例图片
那么他又什么优势呢?
事件驱动类型应用无需查询远程数据库,本地数据访问使得它具有更高的吞吐和更低的延迟。由于定期向远程持久节点存储的checkpoint可以异步、增量完成,因此对于正常事件处理的影响很小(官网的翻译用的是甚微)。事件驱动型应用的优势不仅局限于本地数据访问。传统分层架构下,通常多个应用会共享一个数据库,因此任何对数据库自身的更改(例如:应用更新或者服务扩容导致数据布局发生改变)都需要谨慎协调。反观事件驱动型应用,由于只需要考虑自身数据,因此在更改数据标识或者服务扩容时所需要的协调工作将会大大减少。
Flink时如何支持的呢?
事件驱动型应用会受制于底层流处理系统对时间和状态的把控能力,Flink诸多优秀特质都是围绕这些方面来设计的,它提供了一系列丰富的状态操作原语,允许以精确一次的一致性语义合并海量规模(TB级别)的状态数据。此外,Flink还支持事件时间和自由度极高的定制化窗口逻辑,而且它内置的ProcessFunction支持细粒度时间控制,方便实现一些高级业务逻辑。同时,Flink还拥有一个复杂时间处理(CEP)类库,可以用来检测数据流中的模式。
Flink中针对事件驱动应用的明星特性当属savepoint。Savepoint是一个一致性的状态镜像,他可以用来初始化任意状态的兼容的应用。在完成一次savepoint后,即可放心对应用进行升级和扩容,还可以启动多个版本的应用来完成A/Btest。
典型的事件驱动型应用举例:
什么时数据分析应用:
数据分析任务需要从原始数据中提取有价值的信息和指标。传统的分析方式通常是利用批查询,或将事件记录下来,并基于有限数据集构建应用来完成。为了得到最新数据的分析结果,必须先将它们加入分析数据集并重新执行查询或运行应用,随后将结果写入存储系统或生成报告。
接着一些先进的流处理引擎,还可以实时地进行数据分析,和传统模式下读取有限数据集不同,流式查询或应用会接入实时事件流,并随着事件消费持续产生和更新结果。这些结果数据可能会写入外部数据库系统或者内部状态地形式维护。仪表展示应用可以相应地从外部数据库读取数据或者直接查询应用多的内部状态。
如下图所以,Flink同时支持流式及批量分析应用。
Flink官网示例图片
流式分析应用地优势?
相比批量分析,由于流式分析省掉了周期性地数据导入和查询过程,因此从事件中获取指标地延迟耕地。不仅如此,批量查询必须处理那些由定期导入和输入有界性导致地人工数据边界,而流式查询则无需考虑该问题。
另一方面,流式分析会简化应用抽象。批量查询地流水线通常由多个独立部件组成,需要周期性地调度提取数据和执行查询,如此复杂地流水线操作起来并不容易,一旦某个组件出错,将会影响流水线地后续步骤。而流式分析应用整体运行在Flink之类地高端流处理系统之上,涵盖了从数据接入到连续结果计算地所有步骤,因此可以依赖底层引擎提供地故障恢复机制。
Flink是如何支持流式数据分析地?
它内置了一个符合ANSI标准地SQL接口,将批、流查询地语义统一起来,无论是在记录事件的静态数据集上,还是实时数据流上,相同SQL查询都会得到一致的结果。同时Flink还支持丰富的用户自定义函数,允许在SQL中执行定制化代码。如果还需进一步定制逻辑,可以利用Flink DataStream API和DataSet API进行更低层次的控制。此外,Flink的Gelly库为基于批量数据集的大规模高性能图分析提供了算法和构建模块的支持。
提取-转换-加载(ETL)是一种在存储系统之间进行数据转换和迁移的常用方法。ETL作业通常会周期性的触发,将数据从事务型数据库拷贝到分析性数据库或者数据仓库。
数据管道和ETL作业的用途相似,都可以转换、丰富数据、并将某个存储系统转移到另一个。但数据管道十一持续流模式运行,而非周期性触发。因此,他支持从一个不断生成数据的源头读取数据,并将他们以低延迟移动到终点。例如:数据管道可以用爱监控文件系统目录中的新文件,并将数据写入到事件日志;另一个应用可能会将事件流物化到数据库或者增量构建和优化查询索引。
下图描述了周期性 ETL 作业和持续数据管道的差异。
Flink官网示例图片
数据管道的优势?
和周期性ETL作业相比,持续数据管道可以明显降低将数据移动到目的端的延迟。此外,由于它能够持续消费和发送数据,因此用途更广,支持用例更多。
Flink是如何支持管道应用的?
很多常见的数据转换和增强操作都可以使用Flink'的SQL接口(或者Table Api)以及用户自定义函数解决。如果数据管道有更高的需求,可以选择更通用的DataStream API来实现。Flink为多种数据存储系统内置了连接器。同时它还提供了文件系统的连续数据源以及数据汇,可以用来监控目录变化和以时间分区的方式写入文件。
今天在群里听了大佬的讨论,关于Spark和Flink的--
Spark 和Flink之间的差距很大,Flink的发展也很慢-国内是阿里推动,又是java主场,所以,大家也很愿意转型,尝试。
国外Flink就没有那么多的热度的,所以,我们在国内工作,就要适应国内的技术发展,Spark会了,那学学Flink吧
原文地址——https://flink.apache.org/zh/usecases.html