走进 Apache Flink | 学习笔记(二)

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 快速学习走进 Apache Flink

开发者学堂课程【开源 Flink 极客训练营走进 Apache Flink】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/760/detail/13337


走进 Apache Flink


二、唯快不破–流批的本质

讨论流批本质时可以借助数据库辅助理解流与批的区别与联系。

可以用 insert 、update 、delete 来管理数据库,然后用 select 来查询。查询本身就是一种计算,同时还可以利用 trigger 来监控表数据的一些变化。

1.假如有一个需求,要实时显示某种表中的全部数据,应该用什么方式满足该需求?

如果用 insert 传入一个数据,然后用 update 更新一些信息。很容易想到用 select 可以查询表里面的一些数据,然后进行一些可视化的显示和监控。这里需要考虑一个问题,当执行了这一次查询之后,其实是一个手动触发,那么下次如何触发是不可预知的。可能10分钟,可能1小时,可能1天,甚至想起来再查一次,总而言之,无论什么时间去查询一次,不能做到只要数据表有变化就显示出来。如果要达到这样一个效果,可以利用孵化器。

比如定义一个 insert 的触发器,再定义一个 update 的触发器,这里以 insert 的触发器为例。定义完成后其逻辑是只要表里有 insert 数据,就立即触发查询并将结果写入到一个文件中。update 的触发器也同样触发查询并写入一个结果文件中。

对应的触发器及语句来说,就会生成两个结果文件,当执行 insert into 时,生成 trigger1,执行 update 时,再生产一个 trigger2.结果如下:

图片7.png

上图中的 insert 语句是将 clicks 更新为2,第一次查询时只有一个 Mary 1,第二次查询时本质上插入了一个 insert into Bob 1,所以第二次查询时出现了 Bob 1。

注意:该截图显示的是 insert 的触发器,所以两次查询中只有 insert 生效,update 的生效需要真正的去定义 update 的查询后再去进行才会生效。

2.流批计算的背后是在说什么?

图片8.png

既然数据库本身就可以完成流批的计算,为什么还需要很多的大数据批计算流计算的计算框架?

本质上,不管是流还是批,都是对数据的处理,尤其是对大数据的计算处理能力。

随着云计算、物联网、人工智能等信息的到来,人们步入了一个信息的时代。目前全球的数据量呈现几何的增长,下图是预测数据:

图片9.png

全球10年的时间,数据量从16.1ZB 增长到163ZB,该数据量已经远远超过单台计算机的存储和处理能力。(ZB 是一个更难想象的数据)

3.这些数据从哪里来?

目前的数据的确在非常快速的增长,比如 Facebook 的社交平台有几百亿、几千亿的照片信息,一些证券交易市场每天有几TB或十几TB 的交易数据量。

举例阿里巴巴:

图片10.png

10年来,阿里巴巴每年双十一的交易额增长了几千倍。在19年时,Flink 流计算的处理能力创造了25.5亿条每秒的处理记录。从种种事实来看,这些数据都是存在的(不知道不代表不发生),数据量的惊人是存在的,在某种程度上推动了技术的发展。

用户对技术的核心诉求?

首先是能够处理已有的数据,在能够处理已有数据的前提下,要求计算准确、迅速。

4.海量数据的技术支撑?

由谷歌发展的三大理论(三大马车):

图片11.png

解决了分布式存储和分布式计算,解决了这两个问题解决了当前的海量数据的增长,对该数据价值的挖掘提供了技术手段。

谷歌的三大马车描述了如何进行海量数据的分析的计算,但是其真正实现的落地是在谷歌内部。对于谷歌之外的公司完成分布式存储和分布式计算是通过 Apache Hadoop 生态。

图片12.png

 

对于该开源的生态,其体系是一个分布式的批计算框架,一般是若干小时或者若干天的计算延时。在实际的生产业务中,大多数在 T+1 的场景应用会应用 Hadoop 分布式计算(今天看到的结果是为昨天数据的统计分析),所以其很好的完成了在大数据环境中用户对海量数据支撑和计算准确性的需求。

本质是该需求得到满足,但是数小时的延时并不能认为是计算速度快,用户需要的快速是秒或毫秒级别,所以这种批计算没有很好的达到计算的快速问题。

一般来说,数据计算的多个处理环节叫 stage,批计算的逻辑是 stage by stage(当前的 stage 没有完成之前不能启用下一个 stage)。如果 n 个数据转换逻辑,从第一个 stage 的启动处理直到第 n 个 stage 处理完成后,才能有真正的具体结果。在数据量相同的情况下,业务逻辑还是同样的处理逻辑的情况下,降低业务的延时要通过流计算。

图片13.png

5.流计算的方式为什么能够解决该问题?

因为数据的处理就像流水一般,同时启动所有环节和逻辑,哪怕刚流第一滴水,就将这一滴水的处理逻辑都处理完成并输出这一滴水的处理结果留到下一步。这样不用等到所有数据到齐,将所有数据都执行完再输出结果,这种及时的计算模式就是流计算。因为该缘故,促使其在业务延时方面和批计算有天壤之别。

如果不看技术的实现,单从用户视角看流与批的本质区别,那就是“快”。也就是说流与批的本质区别是业务延时上的不同。

图片14.png

其本质上的快是相对的,不同的业务有不同的需求。当前所说的秒、毫秒和数天的延时是两个极端,在实际业务上还有分钟的延时、小时的延时等等小时间间隔的延时。针对这样的需求,在小时和分钟的业务上,无论是批计算还是流计算,都是可能满足的,所以流计算和批计算对用户来说并没有很大的关系,用户更注重计算结果的准确性。

图片15.png

基于现在的分析和判断,对于计算引擎计算从实现的角度看,所谓的触发(秒、小时、天)是引擎内部的触发机制的设计。比如可以每条记录都触发一次并计算输出结果,那么自然而然是最低的延时,如果将数据结果在所有数据结束后再触发一次计算并输出结果,那么延时显示是最高的。如果在触发机制上支持按业务需求指定时间的范围或记录触发计算,对用户而言已经足够。所以流和批本质上的选择,更多的是计算引擎自己的优化。(满足用户的需求即可)

一个流批统一的系统,其本质上是一个计算的模式。

触发批计算是数据结构之后的孵化,对流计算而言,计算引擎的设计会根据流批认知的不同。

6.两种主流的设计方案

目前有两种主流的设计方案,一种是说批是流的一个特点。既然可以每条数据都触发一条计算,那么也可以3条或者5条甚至一个小时后再触发一次,所以流计算引擎自然而然的会支持批计算,所以批计算依赖是流计算的一个特点。另一种说法是流是批的特例,既然能够瓒一批数据,如果每一批的数据只有一条,相对于每一天数据都触发了计算,意味着延时是最低的 ,也就是我们所说的流计算。

针对这两种认知的不同,计算引擎设计方案一种是 Native Streaming 模式,另一种是 Micro-Batching 模式。

图片16.png

Native Streaming 模式就是认为批是流的特例,该概念本质上更贴切流的概念,流监控的一些消息等都是一条一条处理的。Native Streaming 模式每条数据都触发计算这种机制会最大程度的降低计算延时,Native Streaming 模式占据了流计算第一个核心能力。

Micro-Batching 模式是认为流是批的特例,流计算就是将连续不断的批计算、批数据进行持续的计算,如果批足够小,那么延时就足够小,在一定程度上,这种设计满足了百分之九十九的实时计算场景。另外百分之一是架构的原因,因为 Micro-Batching 模式在设计上就有一个瓒批的过程(对批数据进行调用计算的过程),会增加一定的延时。

Apache Flink 是 Native Streaming 模式的一个流批统一的计算模式。

总结:

图片17.png

从数据集和计算过程两个维度看,批计算一定是有限的数据集,一次计算一次数据结果,流计算本身的数据集可以是无限的,有限的数据集合也可以以流的方式计算,同时流计算要进行结果的不断输出,如果结果有更新也要不断的进行历史结果的更新。

具体实例:

图片18.png

 

假设有一张用户点击实现表,表中有时间戳和用户姓名,需求是进行页面的 pv 统计(进行简单的 select count(*)的一个table),对于批查询,手动执行输入即可,执行一次立即输出一个查询结果。

对于目前的 select count(*)FROM user_clicks 会输出6,因为在执行查询的手动孵化有6个点击事件,如果后面还有用户点击事件发生,该结果不会更改,如果想知道最新的结果必须再次手动触发。

如果目前该查询需求用流计算的查询模式,当第一条事件到达时就会触发一次计算,触发计算时该 count 为1,第二条事件到达时又会触发一次计算,count 为2,依此类推,每条数据到达都会触发一次计算,最终第六条数据到达时,和批的计算结果数据集一样,计算逻辑也一样时,则查询的结果和批是一样的。虽然两种计算模式不一样,但是计算结果一样。所以对用户而言,批和流他们能感知的一个是计算结果,一个是计算结果速度的延时。

对于初学者来说,直观的认识到流和批是两种计算方式和计算结果输出方式的不同以及他们最终结果一致性的相同就可以继续后面的内容。

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
1月前
|
SQL Java API
Apache Flink 2.0-preview released
Apache Flink 社区正积极筹备 Flink 2.0 的发布,这是自 Flink 1.0 发布以来的首个重大更新。Flink 2.0 将引入多项激动人心的功能和改进,包括存算分离状态管理、物化表、批作业自适应执行等,同时也包含了一些不兼容的变更。目前提供的预览版旨在让用户提前尝试新功能并收集反馈,但不建议在生产环境中使用。
616 13
Apache Flink 2.0-preview released
|
1月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
72 3
|
2月前
|
SQL 消息中间件 关系型数据库
Apache Doris Flink Connector 24.0.0 版本正式发布
该版本新增了对 Flink 1.20 的支持,并支持通过 Arrow Flight SQL 高速读取 Doris 中数据。
|
3月前
|
消息中间件 监控 数据挖掘
基于RabbitMQ与Apache Flink构建实时分析系统
【8月更文第28天】本文将介绍如何利用RabbitMQ作为数据源,结合Apache Flink进行实时数据分析。我们将构建一个简单的实时分析系统,该系统能够接收来自不同来源的数据,对数据进行实时处理,并将结果输出到另一个队列或存储系统中。
233 2
|
2月前
|
消息中间件 资源调度 API
Apache Flink 流批融合技术介绍
本文源自阿里云高级研发工程师周云峰在Apache Asia Community OverCode 2024的分享,内容涵盖从“流批一体”到“流批融合”的演进、技术解决方案及社区进展。流批一体已在API、算子和引擎层面实现统一,但用户仍需手动配置作业模式。流批融合旨在通过动态调整优化策略,自动适应不同场景需求。文章详细介绍了如何通过量化指标(如isProcessingBacklog和isInsertOnly)实现这一目标,并展示了针对不同场景的具体优化措施。此外,还概述了社区当前进展及未来规划,包括将优化方案推向Flink社区、动态调整算子流程结构等。
400 31
Apache Flink 流批融合技术介绍
|
1月前
|
分布式计算 监控 大数据
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
57 1
|
1月前
|
数据挖掘 物联网 数据处理
深入探讨Apache Flink:实时数据流处理的强大框架
在数据驱动时代,企业需高效处理实时数据流。Apache Flink作为开源流处理框架,以其高性能和灵活性成为首选平台。本文详细介绍Flink的核心特性和应用场景,包括实时流处理、强大的状态管理、灵活的窗口机制及批处理兼容性。无论在实时数据分析、金融服务、物联网还是广告技术领域,Flink均展现出巨大潜力,是企业实时数据处理的理想选择。随着大数据需求增长,Flink将继续在数据处理领域发挥重要作用。
|
1月前
|
消息中间件 druid Kafka
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
76 0
|
3月前
|
Java 微服务 Spring
驾驭复杂性:Spring Cloud在微服务构建中的决胜法则
【8月更文挑战第31天】Spring Cloud是在Spring Framework基础上打造的微服务解决方案,提供服务发现、配置管理、消息路由等功能,适用于构建复杂的微服务架构。本文介绍如何利用Spring Cloud搭建微服务,包括Eureka服务发现、Config Server配置管理和Zuul API网关等组件的配置与使用。通过Spring Cloud,可实现快速开发、自动化配置,并提升系统的伸缩性和容错性,尽管仍需面对分布式事务等挑战,但其强大的社区支持有助于解决问题。
75 0
|
3月前
|
消息中间件 Java 数据处理
揭秘Apache Flink的Exactly-Once神技:如何在数据流海中确保每条信息精准无误,不丢不重?
【8月更文挑战第26天】Apache Flink 是一款先进的流处理框架,其核心特性 Exactly-Once 语义保证了数据处理的精准无误。尤其在金融及电商等高要求场景下,该特性极为关键。本文深入解析 Flink 如何实现 Exactly-Once 语义:通过状态管理确保中间结果可靠存储;利用一致的检查点机制定期保存状态快照;以及通过精确的状态恢复避免数据重复处理或丢失。最后,提供一个 Java 示例,展示如何计算用户访问次数,并确保 Exactly-Once 语义的应用。
94 0

推荐镜像

更多