StructuredStreaming学习笔记(一) —— 简介&背景&概述

本系列主要是StructuredStreaming的一些学习笔记，主要将从如下几个方面进行记录：

1. Structured Streaming简介&背景&概述
2. 入门案例&流程剖析&编程模型
3. Input Sources
4. Output Sinks
5. Output Modes与Streaming Query
6. Triggers
7. 事件事件和窗口操作
8. 处理延迟的数据&watermark

会将内容进行长期更新 ：）

本篇内容 主要整理自GitChat文章：Structured Streaming 开发入门

简介

Structured Streaming作为Spark家族的新成员，通过Spark SQL/DataFrame来处理Batch/Streaming数据，基本的Spark SQL API即可实现离线批处理和流式处理，大大的方便了流式计算的开发，另外还提供了丰富的功能

背景

现在社会数据日益爆炸增长的同时，实时处理这些数据，提供最新的结果来驱动商业决策也变得尤为重要。企业中许许多多的数据来源都需要实时运行，比如手机或者电脑APP的浏览日志、广告点击日志、APP下载日志等等
流式处理系统在过去的几年里有了巨大的进步，就国内来说：storm、Spark Streaming、flink、Kafka Streams等等都是非常流行的一些做法：

• Storm优点明显，延迟非常低，但是缺点也很明显，存在API编写复杂，只能实时，不能像Spark一样全家桶，存在吞吐等问题
• Spark Streaming作为Spark全家桶的一员，Structured Streaming作为构建在它之上的模块，肯定要有明显的优势才行
• Flink和Kafka Streams，官方论文说Structured Streaming比Apache Flink优4.x，比Kafka Streams优90.x
  下面是官方论文的一个对比，用雅虎的benchmark在Kafka Streams、flink、Structured Streaming之间做压测：

概述

API

我们通过使用Spark SQL的批处理API（SQL和DataFrame）来编写Structured Streaming的程序
将输入的数据定义为表，然后就是Spark SQL的处理方式处理表，再将表进行输出。不同的sink可以支持不同的输出方式（output modes），有append、complete、update三种
结构化流相比Spark SQL添加了以下几种API特性：

• Triggers，它控制了计算新结果和更新输出sink的频率
• event time（一种根据事件产生时间来处理数据的方式）
  watermark（一种用来标记数据处理进度的策略）
• 有状态的操作
  一旦数据接收，开始运行。结构化流就可以通过Spark SQL部分对查询进行优化，按指定的策略执行
  和Spark Streaming类似，它能实现动态负载均衡、故障恢复等，除此之外，在处理批数据的时候，结构化流还提供了连续处理模式（Continuous），它能够提供更低的延迟，从而来解决Spark延迟只能到秒级的缺点；当然，速度更快的同时，也牺牲了一些东西

Structured Streaming对比Spark Streaming

Structured Streaming与Spark Streaming不同的点主要体现在以下几个个地方：

• Structured Streaming是一个自增长的查询，可以通过使用Spark SQL/DataFrame API去处理静态的数据；这也就意味着我们可以通过使用Spark batch API就可以去写流式的查询
• Structured Streaming相比Spark Streaming新的地方在于添加了Event Time这一概念
  在Spark Streaming中我们只会在数据来了才会进行处理，这批数据来了多少我们处理多少，没有数据我们就不处理
  但是这一套机制在有些场景我们可能并不需要这样，我们需要Event Time(点击流，数据产生的时间)，根据数据产生的时间来进行处理
  Event Time与Process Time是不一样的。比如，我们经常会在网页端进行埋点，之后我们只要点击页面的日志就会产生一个时间(Event Time，即事件产生的时间)，事件经过ngnix、flume、kafka到我们的Spark中进行计算，到Spark进行处理的时间我们称之为Process Time；而Spark Streaming之前都是根据Process Time进行处理的，而在有些场景下我们会需要Event Time，根据事件产生的先后顺序进行计算
• 支持end-to-end
  Structured Streaming内置了一些connectors，目的是为了让我们写的更方便
  Data sources和sinks提供了简单的transactional model来确保exactly-once
• Structured Streaming在监控上做了些改进，使其更加合理与丰富