加入收藏 | 设为首页 | 会员中心 | 我要投稿 应用网_阳江站长网 (https://www.0662zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 产品 > 正文

2019大数据产业峰会|阿里云郭华:从Flink看大数据实时变化

发布时间:2019-06-05 14:50:12 所属栏目:产品 来源:中国IDC圈
导读:为了深入落实国家大数据战略,推动大数据产业交流与合作,展示我国大数据产业最新发展成果,2019年6月4日至5日,由中国信息通信研究院、中国通信标准化协会主办,大数据技术标准推进委员会承办的2019大数据产业峰会在北京国际会议中心隆重举办。 会上,来

为了深入落实国家大数据战略,推动大数据产业交流与合作,展示我国大数据产业最新发展成果,2019年6月4日至5日,由中国信息通信研究院、中国通信标准化协会主办,大数据技术标准推进委员会承办的2019大数据产业峰会在北京国际会议中心隆重举办。

会上,来自工业和信息化部的领导,我国众多优秀大数据领域服务商、行业应用客户、研究机构、地方大数据主管机构的领导和专家,将对大数据政策、产业、技术的现状与趋势等内容进行交流探讨。

6月5日,在大数据前沿技术分论坛上,阿里云实时计算产品经理郭华为我们带来了《从Flink看大数据实时变化》的精彩演讲。

阿里云实时计算产品经理郭华

阿里云实时计算产品经理郭华

大家好,非常高兴来到这边,我来自阿里云的郭华,今天的题目是《从Flink看大数据实时化》。

讲到Flink或者大数据实时化一般讲到的是流处理系统,今天的主题围绕这三个方面进行展开:流处理概述、流处理一般应用架构、流处理应用场景。

首先从实时性、易用性方面看一下开源大数据引擎这十几年的简单历史,我们都知道开源大数据引擎实际上理论上起源于04年谷歌发表的那篇MapReduce的论文,06年的Hadoop基本上完整实现了论文里描述的当时的系统叫做MapReduce,但是MapReduce在实时性、易用性上都有问题,实时中把大量中间数据放到硬盘中去导致虽然具备大批量的数据处理能力,但是它的数据是比较慢的。另外在易用性方面,只提供了MapReduce,这意味着都必须拆解成Map和、Reduce两个阶段,这意味着一系列的都需要MapReduce串联起来进行调度非常的繁琐。08年facebook启动了一个ladoop项目,大家知道SQL是一个使用门槛非常低的语言,把SQL提交给hive,其实hive是大大降低了MapReduce的应用门槛,所以Hadoop和hive还是标准化的解决方案。05年Spark出现了,在实时性、易用性上都有改变。从实时性上讲,这是Spark最大的亮点,设置了基于内存中间数据,通过这种形式大大加速了批处理内容,从易用性方面提供了RDD的数据抽象,在此基础上提供了非常多的算子,还有了更高的表达灵活度。但是Spark虽然说加速了MapReduce的计算过程,但还不是大数据实时化的系统,真正的流处理是11年研究的。当时它的作者经常处理来自消息队列的数据,这时候他想既然数据是一条条过来的,为什么计算不能一条条处理?在这种思路影响下开发了Storm引擎。Storm也比较成功但是还是初级的引擎,14年的Flink是比Storm成熟的。Storm可以做到至少处理一次,而Flink能够做到确保只处理一次,同时是没有中间阶段的,Flink是有自己的中间状态存储的,所以直接可以在里面进行统计。另外Flink在这个基础上又提供了更高级别的窗口以及更高层次的API、SQL等等,另外Flink除了流处理之外还在流处理基础上又封装了一层批处理引擎,所以我们说Flink叫下一代的大数据引擎,是因为它完整的具备了流和批的处理能力。

从这个版本里面来看,开源大数据的计算引擎主要通过实时性和易用性两个方面演进的,实时性从最开始基于硬盘的批处理、基于内存的批处理、实时的流处理,易用性上从MapReduce到RDD到bolt到了SQL,这是一个简单的历史。

刚才说Storm那种起诉的批处理不是实时化,流处理才是。什么是实时化?是一个事件从发生到把结果发出去的延迟,从这个结果来看批处理,假设有一堆数据,这时候有个需求开发了一个作业,这个作业提交之后把那些数据都读过来进行处理,处理完之后把结果发出去,所以在这种情况下它的延迟是比较高的。具体体现在两个方面:第一,它是由计算驱动的,而计算往往是由调度器发起的,调度器和事件发生本身是没有直接关系的;另外,它每次处理是个全量的处理,把所有数据都捞进来进行计算,计算本身也是比较耗时的。这两种计算影响下延迟是比较高的,基本上是小时级别的延迟。

再看一下流处理,流处理整个模型是不一样的,流处理里面数据是没有终结数概念的,会假设数据源源不断流进来。写个作业提交以后,作业也不会停止。同样从那两个角度来看,首先是由事件驱动的,只要有事件触发计算就会自动进行,这个延迟比较低;另一个它是一个增量的计算,意味着每次只处理一小部分数据,计算过程本身也比较难。综合这两方面,流处理能够做到秒级亚秒级的延迟,所以叫做大数据实时化的引擎。

流处理一般的应用架构,如图是个非常抽象的应用架构,有两个关键点:

1、消息队列;

2、流计算数据。

举例来说不管是WEB、APP或者IoT设备会实时把事件发送到消息队列里面去,目前事件本身就是事件型的,只要发到消息队列里去,流计算处理这些队列,关联一些历史数据进行处理,处理下游既可以是消息型也可以是静态的。消息型的可以供其他流处理系统进行消费,静态的可以做流向分析,当然架构是比较抽象的。

接下来讲几个比较典型的应用场景,一句话说,流计算是广泛的适用于大数据实时化的场景,具体从两个方面展开:

1、从公司维度,公司分成业务部门、数据部门、运维部门。

2、从数据处理的技术维度,把数据处理分成实时APL还有实时统计分析、还有事件驱动型应用。

理论上需要3×3,9个案例才能覆盖所有组合。介于时间关系我今天讲3个,一个是实时索引构建、实时统计数仓、实时异常检测。

实时索引构建。以电商场景为例,我们知道搜索引擎是提供在线搜索服务的,提供搜索服务的前提是数据都已经建立到索引之中了。比如在电商场景下,你的数据源是来自于商品的数据库、店铺数据库、自己统计的销量。搜索商品既要包括搜索数据店铺数据,也要包括销量等等。

首先把这些数据全都读进来,一批读进来之后进行关联,把结果进行拼接,拼接成最后搜索要展示的记录,之后建立到索引里面去,这是一次索引过程。当然商家在不停的发布新品,那些已发布的商品它的信息也在变化,所以还需要一个调度系统定期的刷新这些状态,也就是说它定时的调度、重复批索引的过程。这时候假设这个调度加处理本身需要一个小时,极端情况下就会出现一个问题——假如商家发布了一款商品,有可能N小时之后才会被消费者搜到,这种体验无论对商家还是消费者来讲都是非常不好的。

(编辑:应用网_阳江站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!