首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >了解Structured Streaming

了解Structured Streaming

作者头像
曲水流觞
发布2019-10-27 22:26:49
9840
发布2019-10-27 22:26:49
举报
文章被收录于专栏:曲水流觞TechRill曲水流觞TechRill

Spark Streaming

在2.0之前,Spark Streaming作为核心API的扩展,针对实时数据流,提供了一套可扩展、高吞吐、可容错的流式计算模型。 Spark Streaming会接收实时数据源的数据,并切分成很多小的batches,然后被Spark Engine执行,产出同样由很多小的batchs组成的结果流。

本质上,这是一种micro-batch(微批处理)的方式处理,这种设计让Spark Streaming面对复杂的流式处理场景时捉襟见肘。其实在流计算发展的初期,市面上主流的计算引擎本质上都只能处理特定的场景:storm作为起步非常早的流计算引擎,大部分用于one-by-one式无状态的数据处理场景(虽然提供了Trident API用于有状态的聚合计算,但依然有局限),而spark streaming这种构建在微批处理上的流计算引擎,比较突出的问题就是处理延时较高(无法优化到秒以下的数量级),以及无法支持基于event_time的时间窗口做聚合逻辑。

在这段时间,流式计算一直没有一套标准化、能应对各种场景的模型,直到2015年google发表了The Dataflow Model的论文。

Dataflow模型

在日常商业运营中,无边界、乱序、大规模数据集越来越普遍(例如,网站日志,手机应用统计,传感器网络)。同时,对这些数据的消费需求也越来越复杂,比如说按事件发生时间序列处理数据,按数据本身的特征进行窗口计算等等。同时人们也越来越苛求立刻得到数据分析结果。 作为数据工作者,不能把无边界数据集(数据流)切分成有边界的数据,等待一个批次完整后处理。相反地,应该假设永远无法知道数据流是否终结,何时数据会变完整。唯一确信的是,新的数据会源源不断而来,老的数据可能会被撤销或更新。 由此,google工程师们提出了Dataflow模型,从根本上对从前的数据处理方法进行改进。

定义

对无边界,无序的数据源,允许按数据本身的特征进行窗口计算,得到基于事件发生时间的有序结果,并能在准确性、延迟程度和处理成本之间调整。

构建数据处理管道的四个维度

抽象出四个相关的维度,通过灵活地组合来构建数据处理管道,以应对数据处理过程中的各种复杂的场景

  • what 需要计算什么
  • where 需要基于什么时间(事件发生时间)窗口做计算
  • when 在什么时间(系统处理时间)真正地触发计算
  • how 如何修正之前的计算结果

论文的大部分内容都是在说明如何通过这四个维度来应对各种数据处理场景。

相关概念说明

event_time,事件的实际发生时间 process_time,处理时间,是指一个事件被数据处理系统观察到的时间

 在现实场景中,从一个事件产生,到它被数据分析系统收集到,要经过非常复杂的链路,这本身就会存在一定的延时,还会因为一些特殊的情况加剧这种情况。比如基于移动端APP的用户行为数据,会因为手机信号较差、没有wifi等情况导致无法及时发送到服务端系统。 面对这种时间上的偏移,数据处理模型如果只考虑处理时间,势必会降低最终结果的正确性。

窗口

除了一些无状态的计算逻辑(如过滤,映射等),经常需要把无边界的数据集切分成有限的数据片以便于后续聚合处理(比如统计最近5分钟的XX等),窗口就应用于这类逻辑中,常见的窗口包括:

  • fixed window,固定窗口,按固定的窗口大小定义,比如每小时、天的统计逻辑。
  • sliding window,滑动窗口,除了窗口大小,还需要一个滑动周期,比如小时窗口,每5分钟滑动一次。固定窗口可以看做是滑动窗口的特例,即窗口大小和滑动周期相等。
  • sessions,会话窗口,以某一事件作为窗口起始,通常以时间定义窗口大小(也有可能是事件次数),发生在超时时间以内的事件都属于同一会话,比如统计用户启动APP之后一段时间的浏览信息等。

论文中远不止这些内容,还有很多编程模型的说明和举例,感兴趣的筒子可以自行阅读。(除了论文,Apache Beam是由google发起的开源项目,基本上就是对Dataflow模型的实现,目前已经成为Apache的顶级项目)

Structured Streaming

简介

也许是对Dataflow模型的借鉴,也许是英雄所见略同,spark在2.0版本中发布了新的流计算的API,Structured Streaming。这是一套构建在Spark SQL引擎上的流计算方案,它的突出优势是:

  1. 统一了流、批的编程模型
  2. 支持基于event_time的时间窗口的处理逻辑

基本概念

以表的方式对待流式数据,数据流被看做是一张无界的“输入表”,其中的每个数据项都相当于追加到表中的一行记录。

基于这张输入表的查询会产生“结果表”。每隔一段固定时间间隔(比如1s),会触发一次查询,而这段时间内追加到数据表的记录,会导致结果表的更新,最后,结果表的记录会以某种模式输出到外部系统。笔者使用的2.2.1版本中,支持三种输出模式:

  1. Complete Mode 将整张结果表输出到外部系统,由外部系统决定如何操作这些记录
  2. Append Mode 仅将最近一次触发的查询产生的、追加到结果表的记录输出到外部系统
  3. Update Mode 将最近一次触发的查询产生的、结果表中被更新过的记录输出到外部系统。这种模式与Complete模式的区别是仅输出发生变更的记录,而当你的额查询不包含聚合的时候,它又等用于Append模式。

上图是官方用来解释这种模型的例子。用户在控制台输入的单词,通过nc命令发送到某一端口,而spark程序监听该端口,并定时输出wordcount的结果。

如图所示,该场景下,输入表即用户输入的单词,结果表是wordcount的结果,而控制台就是外部系统。spark程序会定时触发计算逻辑,不停地对输入的单词做统计,并最终以Complete模式输出到控制台。

基于事件时间的处理

在这种无界表的逻辑下,可以轻松应对事件时间的分析场景。因为每个事件都是表中的一条记录,而事件时间则是表中的一列,所以基于事件时间窗口的逻辑就相当于对这一列做groupby。 而针对那些“迟到的数据”,自2.1版本提出的水位线(watermarking)概念,允许用户来定义针对迟到数据的超时时间,spark引擎会结合这个配置来酌情修正内存中保留的聚合结果。下面通过一个例子来详细说明:

这是对wordcount例子的扩展。

  • 数据包含两个维度(即无界表中的两列),timestamp(即事件时间)和word,我们要基于事件时间,做一个滑动窗口(窗口大小10min,滑动周期5min)的wordcount逻辑。
  • 与之前不同,结果表中除了词的统计结果,还要记录它所处的时间窗口,以12:10触发的计算为例,其中包含(12:07,dog)和(12:08,owl)两个事件,由于滑动窗口存在重合,所以计算后的结果表中,12:00-12:10和12:05-12:15两个窗口都包含owl,dog的统计结果。
  • watermarking的逻辑就是在每次触发查询的时候,使用这个窗口中最大的事件时间-用户定义的超时时间得到当前的水位线,处于水位线以上的数据都会被作为有效事件纳入统计逻辑,而处于水位线以下的事件则被作为迟到数据而丢弃,以12:20为例,这个窗口中能检测到的最大事件时间是(12:21,owl),所以12:21-10min=12:11更新当前的水位线,(12:04,donkey)低于水位线,所以不会被更新到结果表中
  • 最后,由于是一update模式输出,所以每次触发查询的时候,结果表中发生更新的数据(紫色的记录)会被展示到控制台

以上复杂的计算场景,大部分逻辑都是由spark引擎自行处理,需要业务人员参与的逻辑很少,代码非常简单:

Dataset<Row> words = ... 
// streaming DataFrame of schema { timestamp: Timestamp, word: String }
// Group the data by window and word and compute the count of each group

Dataset<Row> windowedCounts = words.withWatermark("timestamp", "10 minutes")
   .groupBy(
       functions.window(words.col("timestamp"), "10 minutes", "5 minutes"),
       words.col("word"))
   .count();

最后

虽然目前Structured Streaming还处于比较初级的阶段,2.2版本才宣称达到production程度,而且很多功能与dataflow相比有差距,比如对于exactly once语义的保障,要求外部数据源具备offset定位的能力,还不支持session window,Append模式更新只能支持无聚合操作的场景,还有对于join等操作还有各种限制等等,这些部分和dataflow业已实现的功能还有较大的差距。 但凭借正确的设计理念,spark广大的使用群体、活跃的社区,相信Structured Streaming一定会有更好的发展。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-09-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 曲水流觞TechRill 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Spark Streaming
  • Dataflow模型
    • 定义
      • 构建数据处理管道的四个维度
        • 相关概念说明
          • 窗口
          • Structured Streaming
            • 简介
              • 基本概念
                • 基于事件时间的处理
                • 最后
                相关产品与服务
                流计算 Oceanus
                流计算 Oceanus 是大数据产品生态体系的实时化分析利器,是基于 Apache Flink 构建的企业级实时大数据分析平台,具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点。流计算 Oceanus 以实现企业数据价值最大化为目标,加速企业实时化数字化的建设进程。
                领券
                问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档