当前位置: > >Flink核心开发者告诉你Lambda大数据双资料流架构如何再强化

Flink核心开发者告诉你Lambda大数据双资料流架构如何再强化

02-19,IT资讯Flink核心开发者告诉你Lambda大数据双资料流架构如何再强化最新消息报导,口袋科技网(http://www.kotoo.com)IT资讯
图片来源: 

iThome

大数据分析热门话题,近几年从批次分析,转而聚焦在串流分析技术和架构,不只Hadoop推出Lambda双资料流架构,新一代大数据平台Spark爆红,新兴开源串流分析框架Flink也成为Apache顶级专案之一,阿里巴巴、Uber及Netflix等大型公司相继採用Flink来打造大数据分析引擎。台湾也不落人后,参与了这一波大数据技术演进的过程,其中,任职于台湾新创公司VMFive软体工程师戴资力,正是全球 23位维护Flink专案的核心开发者(Committer)之一。

戴资力表示,为了加强企业系统即时分析的需求,「必须重新探讨Lambda架构是否存在问题,以及进行改善的空间。」例如,如何修改Lambda架构,满足即时分析有态(Stateful)资料的需求,或是对有态资料进行常见资料库的资料查询操作。

不仅如此,甚至在国外也有人提出新观念,试图将资料库元件抽离于大数据平台中,直接利用串流处理器作为资料储存媒介。

戴资力引用Twitter的营运数据作为例子,每月活跃使用人数超过3亿,站方每秒必须处理超过1百万则曝光(Impression)推文,在1小时内,使用者更会产生出破1亿则不重複的曝光讯息。

而后端系统除了以1小时为单位,整合平台上所有的讯息,并且将统计数据储存至Key Value资料库外,也要满足即时串流需求,让开发者可以产生任意时间区间内的统计报表。为了一次满足批次处理、即时串流的需要,「大多都会採用Lambda架构。」

常见的批次处理流程中,通常资料会先利用Aka、Kafka等元件处理成便于批次处理的格式后,进一步引入HDFS等分散式档案系统,透过Spark、Hadoop等大数据引擎,对资料进行映射(Map)、简化(Reduce)的批次处理,最后储存在Key Value资料库中,让使用者可以从前端介面捞取资料,执行Query服务。

而即时串流分析程序中,常常使用Kafka作为前端资料的接收器,经过Apache Storm、Spark等即时串流计算引擎,完成资料处理后,系统也会不停更新资料库的内容,将最新结果储存在资料库快取区中,「经过1小时之后,快取区内储存的数值就会归零,重新计算。」

过去架构中,即时串流分析只是辅助

在设计大数据架构处理资料时,企业往往会利用Lambda架构让资料进行双分流处理,同时满足批次程序以及串流分析的需求。但是,这个常见的架构,过去考量的设计理念,在于以批次处理为主,而串流分析作为辅助角色。

而在Lambda双资料流架构的批次处理、即时串流分析流程,戴资力分别从每秒查询次数(QPS,Queries Per Second)、容错能力,以及计算结果正确性这三大面向,进行剖析、评估。

在批次任务中,虽然平台得应付大量载入(Bulk Load)的工作任务,只要先前定义资料处理的时间区间,以及预先準备足够运算资料,大致都能顺利完成任务,「因为它算是容易掌握的工作,可以被归类爲批次处理优点。」

在系统容错方面,虽然Spark、Hadoop内建的机制相当完善,即便中间资料处理过程有误,系统也都能确保程序正常执行。

「不过,批次处理系统所产出的统计结果,究竟是否正确?」戴资力举例,像是资料流入分散式档案系统时,表面上资料是按照使用者需求,以每小时为单位切分,「实际上资料不停地流入,只是开发者让系统周期性地执行批次工作。」而部分Log资料,经过许多不同批次程序处理后,会产生一批当下无法处理的中介资料(Intermediate Data),「系统得要区分出这些中介资料,并将它们派送到另外的批次处理程序中运算。」

此外,批次处理先天不适合处理串流资料的特性,也会造成产出结果有误。例如,当开发者明确定义以1小时为单位进行批次处理,可是「应该要整点到达的资料,却延迟5分钟后才到。」因此,按时启动的批次处理程式,就无法及时处理到迟到的这批资料。

串流分析的先天不足

不止批次处理,即时串流分析也是存在不少问题。戴资力表示,串流程序处理的资料本身并不会记录状态(Stateless),而是储存在外部的快取资料库中。假设数据处理过程中产生任何错误,开发者无法确认后续的资料是否受到影响,「串流分析处理最大的问题,就是难以确认产出的数据是否正确。」也因此,在Lambda架构问世后,串流分析被认为较为不稳定,多半视它作为辅助角色,除了不能保障串流分析产出的结果全为正确,「即使快取资料失效,批次处理架构也有额外一份备份资料。」戴资力说。

另外,快取资料储存的工作流量,与即时串流资料的流入量成正比,「要付出非常高的处理成本,而且系统很难进行水平扩充。」戴资力认为,这个弱点,对于Twitter这样规模的网路公司,迟早会衍生出严重的效能瓶颈问题。

串流分析是Flink的核心

那么现有的Lambda架构,究竟要如何利用同时支援批次处理、即时串流分析的Flink改善?戴资力认为,Flink的设计理念以资料串流(Data Stream)为核心,应将批次处理视为特例,採取有限串流(Bounded Streams)的作法。

先从批次处理的产生的困难切入,改善它先天不适合处理即时分析的特性,「如果无法支援处理有态资料的即时分析,很难把批次处理架构替换掉」,在此就要借助Flink支援有态资料的即时分析能力。

戴资力举例,利用Kafka作为前端的资料收集器,再搭配Flink,同样也可以完成资料的映射、简化处理。而Flink底层每个运算子(Operator)皆为有态,「Kafka读取到哪笔资料的记录,都会储存在Flink内部,不会另外将状态资料储存在外部资料库。」

不过,这样的架构还不足以替换掉Lambda架构,因为使用者并没办法即时取得资料,而且每隔一段时间所累积的资料,仍然要储存在外部,「这样就回到一个问题,使用者是否需要建置快取资料库?」

假使有4笔相异的资料A、B、C及D,经过分流,资料A及B的状态已经储存在甲节点上;资料C与D则储存在乙节点上,「其实Flink内部的State Management,已经默默内建了储存Key Value的资料库。」

既然Flink如此设计,同时它也支援有态资料即时串流分析,开发者就可直接执行Query操作,不需要建立额外的快取储存。「执行Query、资料传送都需要额外的I/O。」戴资力认为,如此就可以完整地取代Lambda架构,「Key Value储存一样存在,但不是只有特定时间才能取得资料」,即使批次处理还没结束,使用者照样可以执行Query操作,取得想要的资料。他也预告,在今年会推出的Flink 1.2版中,将会释出可查询状态功能(Queryable State)。

虽然过去也有人提出Kappa架构,标榜所有资料全都是即时串流处理,然而,戴资力认为,当时串流处理器的技术还没有很成熟,「还无法全面引入串流分析。」戴资力说。

Flink专案核心开发者戴资力表示,虽然透过Flink,已经可以达到相当精简架构,但是在更极端的设计中,还可以把Key Value资料库定期储存的资料,转移到Flink,让串流处理器做为资料库。图片来源/戴资力

精简架构新思维:将串流处理器变成资料库

不过这个看似已经非常精简的架构,其实还是有修改空间。目前仍然需要建立Key Value资料库及Query服务,才能读取资料,「如果更极端的设计,把Key Value资料库定期储存的资料,转移到Flink呢?」他笑说,目前他没有办法保证如此架构实作上没有问题,但这也是国外IT界近年逐渐兴起的概念:串流处理器即资料库(Stream Processor as Database)。戴资力表示,如此一来,几乎不需要外部资料库元件存在了。

声明:

·凡注明为其他媒体来源的信息,均为转载自其他媒体,转载并不代表本网赞同其观点,也不代表本网对其真实性负责。如系原创文章,转载请注明出处。

·您若对该稿件内容有任何疑问或质疑,请即联系,本网将迅速给您回应并做处理。

邮箱:mail@kotoo.com

+1 已赞
已有8人赞过
评论13

发表评论请 登录
  • 最新
  • 最热
评论举报

请选择举报理由

17 13

已收藏
去我的收藏夹 >

已取消收藏
去我的收藏夹 >