Structured Streaming(阿里 云魄 直播视频记录)

Structured Streaming 简介

流式处理理的难点

• 数据复杂性
  • 多种数据源
  • 多种数据格式
  • 数据清洗
• 设计与使用
  • Low-level APIs（偏底层的API，对开发人员不友好）, Map、Reduce等
  • 与ML、批处理结合
• failover（容错处理）

Structured Streaming特点

针对以上的问题，structured streaming 作出了对应的解决

• 丰富的数据源支持
  • 多种数据源 kafka 等，也有其他数据源在第三方库里给出提供。
  • 内建avro支持，schema信息
  • 数据去重，event time （对数据进行清洗）
• 设计与使用
  • high level apis,DataFrame
  • 交互式查询、在线ML
• exactly once 语义

工作原理

micro-batch 处理模式

• trigger
  • one batch （只执行一次，一次性的batch job）
  • fixed interval (固定的interval 来执行)
  • default 不设置trigger的话有一个默认值（前一个mini batch 执行完会紧接着执行下一个mini batch）
• 生成mini batch job
• sql engine
• source->operation-sink

工作流程：设置完trigger 生成mini batch job ，每个mini batch job 中都会进行以下处理流程，
使用spark sql 底层的sql引擎，将DataFrame转换为Rdds ，从source端获取数据，进行处理，sink端写出到外部存储。一个mini batch job结束之后下一个mini batch job 又以相同的方式生成Rdd，在source ->operation 在到sink 写出。每个mini batch job之间呢不是独立的需要有个state操作。如上图t2时的mini batch job 需要获取到t1 mini job 的 state 进行相关的更新。

continuous处理理模式

• Continuous trigger
• DataFrame->RDDs
• 各partition log running task
• source->operation->sink
  
  工作流程：需要把trigger 设置成continuous trigger ,和micro-batch 中trigger 不同之处是，设置的checkpoint interval，每次把checkpoint 写到可靠的外部存储系统的trigger。
  一个continuous 作业的处理过程是：
  也是使用spark sql 底层的sql引擎，将DataFrame转换成逻辑执行计划，最后转化成物理执行计划，在转化成Rdds。source就会不断的从外部获取数据，进行处理，最后通过sink写出。
  因为spark 分布式系统会把rdd分成很多partition，然后就会每个task执行partition。这里会和micro的模式有个区别,task 是log running task ，执行完当前partition数据之后 不会结束。会不停的从source拉数据写入sink。因为这里只有通过一次dataframe 到 rdd的转换,后面直接是拿到这个rdd，之后进行source-operation-sink的操作。所以处理时延是非常低的可以达到亚秒级别，micro-batch的处理模式，会把一个作业分成mini-batch，所以整体来说还是一个批处理的job。所以处理时延是在秒级的。

exactly once - source

• Source get offset
• wal before execution
• sink commit
• 出错、重启后重新执行
  
  理解：exactly once 语义，streaming execution 会从source 获取到一个available offset，本次要处理的offset。source会通过offset 从input端拿到要处理的数据，通过处理 写到sink端在写出，会进行commit操作，streaming execution 会把这种commit 信息会记录到hdfs系统。source也会把available offset也会被存储到hdfs.每次处理前后都会把信息进行存储，若这之间出错，会进行重新执行。

exactly once - sink 容错

• File sink
  • 每个batch 写入目录
  • 所有file写入成功，file path 写入 commit log中
  • 部分失败，重新写入
    
    解释：source 实现可重复执行的，sink端要实现一个密等的操作才能实现exactly once的语义。

exactly once – state store 容错

• 更新的数据被持久化到hdfs
• StatestoreCoordiator
  • 控制executor 各个partition state store 操作
• 失败重启后恢复数据
  

Spark 2.4新特性

• [SPARK-24662] Support the LIMIT operator for streams in Append or Complete
  mode

  • 只支持complete/append模式

• [SPARK-24565] Exposed the output rows of each microbatch as a DataFrame using foreachBatch

  • 支持一些rdd操作:在线ML

  • output写⼊多个location （支持rdd操作的sink,来弥补spark 不支持的外部数据源）

  • 对于continuous作业，可以使用foreach方法进行操作。

• [SPARK-24763] Remove redundant key data from value in streaming
  aggregation （按照key聚合的数据，不仅在key中也在value,这里加了个可选项，可以选择value中是否含有对应key值）

• [SPARK-25399] Fixed a bug where reusing execution threads from continuous processing for microbatch streaming can result in a correctness issue（两种模式是代码兼容的，代码可以相互转换，但是之前有个bug，之前相互转换的数据会有错误，所以这个进行了bug修复。）

• [SPARK-24730] Support for choosing either the min or max watermark when there are multiple input streams in a query（可以在多个流中选择最小的或者最大的watermark进行设置）

Stateful 操作

分类

• stateless操作
  • 每个批次执行相互独立
• stateful 操作
  • spark 通过watermarking丢弃的数据 groupby/join/deduplication
  • 用户自定义去除旧的数据 mapGroupsWithState/flatMapGroupsWithState
    

groupby操作

• aggregation: df.groupBy().avg(“key”);
• aggregation: by event time df.groupBy(window(“timestamp”,“10mins”)).avg(“value”)
• Aggregation by both: df.groupBy(window($“timestamp”,“10 minutes”),“key”).count

stateful 操作问题

• 旧数据持续更新state
• state持续增长
  spark 通过Watermarking 来解决上面两个有可能撑爆内存的问题。
• 捕获event time最大值
• next batch
  • watermarker 里的数据被聚合
  • watermarker外的数据被丢弃
    
    解释：当前时间的event time是12点10分（作为max event time），我们watermark 设置的是1分钟，batch的时间也是1分钟，当下一个event 过来的时候也就是是12点11分的时候，要是来的数据还属于上一个批次的作业的时候呢，那么这个数据将会被处理，要是更晚的event time到达的则会被丢弃。

官网例子：

watermarking 举例

• 数据去重

userActions.withWatermark(“timestamp”,“10 seconds”).dropDuplicates(“uniqueRecordId”)

mapGroupsWithState/flatMapGroupsWithState(自己管理state的API)

• ⾃定义state数据类型
• 自定义state操作
• 自定义state 状态管理
• timeout
  • value=empty
  • hasTimedOut=true

def mappingFunction(key: String, value: Iterator[Int], state: GroupState[Int]): String = { if (state.hasTimedOut) {
// 处理理超时 state.remove()
} else {
val existingState = state.getOption.getOrElse(new UserStatus()) val newState = existingState.handle(value) //业务处理理，更更新state state.update(newState)
state.setTimeoutDuration("1 hour")
}
// return something }
dataset.groupByKey(...) .mapGroupsWithState(GroupStateTimeout.ProcessingTimeTimeout)(mappingFunction)

continuous aggregation 操作

前面介绍的操作，都是micro-batch支持的操作，下面的操作数据continuous

• 处于实验阶段，不支持生产
• 只支持map filter 等操作
• 不支持聚合，如果要执行聚合，需要coalesce(1).

使用场景

周期行的处理最近的数据

• Trigger 设置成Once 只执行一次
• 处理上一个batch到最近的数据
• 周期性启动job
  

低时延获取数据更新

• stateful 操作
• 数据存储kv数据库，方便key查询
  • redis structured streaming a perfect combination to scale out your continuous applications

结合维表

• join 数据合并
• 重启作业获取更新的数据
  

Change data capture

• 采集Mysql 数据导入 Hive
• binlog -> streaming -> delta

参考：databricks blog

数据写入多个表

• 多个query 流
  • 解析一次，写入中间表
  • 读取中间表，写入数据表
    
• foreachBatch操作
  • 解析一次，写入多个数据表
  • 没有可靠行保证

SPARK+AI SUMMIT 2019 案例

• Streaming + Batch + SQL
  Near Real-Time Analytics with Apache Spark: Ingestion, ETL, and Interactive Queries
• NHSD
  how australias national health services directory improved data quality reliability and integrity with databricks delta and structured streaming
• Zalando
  Continuous Applications at Scale of 100 Teams with Databricks Delta and Structured Streaming
• PySpark API
  writing continuous applications with structured streaming pyspark api