Spark Streaming使用Kafka保证数据零丢失

来自: https://community.qingcloud.com/topic/344/spark-streaming使用kafka保证数据零丢失

spark streaming从1.2开始提供了数据的零丢失,想享受这个特性,需要满足如下条件:

  1. 数据输入需要可靠的sources和可靠的receivers
  2. 应用metadata必须通过应用driver checkpoint
  3. WAL(write ahead log)

可靠的sources和receivers

spark streaming可以通过多种方式作为数据sources(包括kafka),输入数据通过receivers接收,通过replication存储于spark中(为了faultolerance,默认复制到两个spark executors),如果数据复制完成,receivers可以知道(例如kafka中更新offsets到zookeeper中)。这样当receivers在接收数据过程中crash掉,不会有数据丢失,receivers没有复制的数据,当receiver恢复后重新接收。

metadata checkpoint

可靠的sources和receivers,可以使数据在receivers失败后恢复,然而在driver失败后恢复是比较复杂的,一种方法是通过checkpoint metadata到HDFS或者S3。metadata包括:

  • configuration
  • code
  • 一些排队等待处理但没有完成的RDD(仅仅是metadata,而不是data) 

这样当driver失败时,可以通过metadata checkpoint,重构应用程序并知道执行到那个地方。

数据可能丢失的场景

可靠的sources和receivers,以及metadata checkpoint也不可以保证数据的不丢失,例如:

  • 两个executor得到计算数据,并保存在他们的内存中
  • receivers知道数据已经输入
  • executors开始计算数据
  • driver突然失败
  • driver失败,那么executors都会被kill掉
  • 因为executor被kill掉,那么他们内存中得数据都会丢失,但是这些数据不再被处理
  • executor中的数据不可恢复

WAL

为了避免上面情景的出现,spark streaming 1.2引入了WAL。所有接收的数据通过receivers写入HDFS或者S3中checkpoint目录,这样当driver失败后,executor中数据丢失后,可以通过checkpoint恢复。

At-Least-Once

尽管WAL可以保证数据零丢失,但是不能保证exactly-once,例如下面场景:

  • Receivers接收完数据并保存到HDFS或S3
  • 在更新offset前,receivers失败了

  • Spark Streaming以为数据接收成功,但是Kafka以为数据没有接收成功,因为offset没有更新到zookeeper

  • 随后receiver恢复了
  • 从WAL可以读取的数据重新消费一次,因为使用的kafka High-Level消费API,从zookeeper中保存的offsets开始消费

WAL的缺点

通过上面描述,WAL有两个缺点:

  • 降低了receivers的性能,因为数据还要存储到HDFS等分布式文件系统
  • 对于一些resources,可能存在重复的数据,比如Kafka,在Kafka中存在一份数据,在Spark Streaming也存在一份(以WAL的形式存储在hadoop API兼容的文件系统中)

Kafka direct API

为了WAL的性能损失和exactly-once,spark streaming1.3中使用Kafka direct API。非常巧妙,Spark driver计算下个batch的offsets,指导executor消费对应的topics和partitions。消费Kafka消息,就像消费文件系统文件一样。

  1. 不再需要kafka receivers,executor直接通过Kafka API消费数据
  2. WAL不再需要,如果从失败恢复,可以重新消费
  3. exactly-once得到了保证,不会再从WAL中重复读取数据

总结

主要说的是spark streaming通过各种方式来保证数据不丢失,并保证exactly-once,每个版本都是spark streaming越来越稳定,越来越向生产环境使用发展。

参考

原文链接: https://github.com/jacksu/utils4s/blob/master/spark-knowledge/md/spark_streaming使用kafka保证数据零丢失.md

[email protected]

时间: 2024-11-26 00:38:43

Spark Streaming使用Kafka保证数据零丢失的相关文章

Spark Streaming和Kafka整合保证数据零丢失

当我们正确地部署好Spark Streaming,我们就可以使用Spark Streaming提供的零数据丢失机制.为了体验这个关键的特性,你需要满足以下几个先决条件: 1.输入的数据来自可靠的数据源和可靠的接收器: 2.应用程序的metadata被application的driver持久化了(checkpointed ); 3.启用了WAL特性(Write ahead log). 下面我将简单地介绍这些先决条件. 可靠的数据源和可靠的接收器 对于一些输入数据源(比如Kafka),Spark S

160728、Spark Streaming kafka 实现数据零丢失的几种方式

定义 问题开始之前先解释下流处理中的一些概念: At most once - 每条数据最多被处理一次(0次或1次) At least once - 每条数据最少被处理一次 (1次或更多) Exactly once - 每条数据只会被处理一次(没有数据会丢失,并且没有数据会被多次处理) High Level API   如果不做容错,将会带来数据丢失因为receiver一直在接收数据,在其没有处理的时候(已通知zk数据接收到),executor突然挂掉(或是driver挂掉通知executor关闭

Spark Streaming的容错和数据无丢失机制

实时的流式处理系统必须是7*24运行的,同时可以从各种各样的系统错误中恢复,在设计之处,Spark Streaing就支持driver和worker节点的错误恢复.然后,在使用某些数据源的时候,错误恢复时输入数据可能会丢失.在spark 1.2中,加入write ahead logs(日志)这个初步方案用来改进恢复机制,保证数据的无丢失. 背景 spark和rdd的设计保证了集群中worker节点的容错性.spark streaming构建在spark之上,所以它的worker节点也是同样的容错

Spark Streaming、Kafka结合Spark JDBC External DataSouces处理案例

场景:使用Spark Streaming接收Kafka发送过来的数据与关系型数据库中的表进行相关的查询操作: Kafka发送过来的数据格式为:id.name.cityId,分隔符为tab 1 zhangsan 1 2 lisi 1 3 wangwu 2 4 zhaoliu 3 MySQL的表city结构为:id int, name varchar 1 bj 2 sz 3 sh 本案例的结果为:select s.id, s.name, s.cityId, c.name from student s

kafka + spark Streaming + Tranquility Server发送数据到druid

花了很长时间尝试druid官网上说的Tranquility嵌入代码进行实时发送数据到druid,结果失败了,各种各样的原因造成了失败,现在还没有找到原因,在IDEA中可以跑起,放到线上就死活不行,有成功了的同仁希望贴个链接供我来学习学习:后来又尝试了从kafka实时发送到druid,还是有些错误,感觉不太靠谱:最后没办法呀,使用Tranquility Server呗 _ _! Tranquility Server的配置和启动请移步:https://github.com/druid-io/tran

[转帖]kafka 如何保证数据不丢失

https://www.cnblogs.com/MrRightZhao/p/11498952.html 一般我们在用到这种消息中件的时候,肯定会考虑要怎样才能保证数据不丢失,在面试中也会问到相关的问题.但凡遇到这种问题,是指3个方面的数据不丢失,即:producer consumer 端数据不丢失  broker端数据不丢失下面我们分别从这三个方面来学习,kafka是如何保证数据不丢失的 一.producer 生产端是如何保证数据不丢失的 1.ack的配置策略 acks = 0 生产者发送消息之

Spark Streaming容错的改进和零数据丢失

本文来自Spark Streaming项目带头人 Tathagata Das的博客文章,他现在就职于Databricks公司.过去曾在UC Berkeley的AMPLab实验室进行大数据和Spark Streaming的研究工作.本文主要谈及了Spark Streaming容错的改进和零数据丢失. 以下为原文: 实时流处理系统必须要能在24/7时间内工作,因此它需要具备从各种系统故障中恢复过来的能力.最开始,Spark Streaming就支持从driver和worker故障恢复的能力.然而有些

spark streaming 对接kafka记录

spark streaming 对接kafka 有两种方式: 参考: http://group.jobbole.com/15559/ http://blog.csdn.net/kwu_ganymede/article/details/50314901 Approach 1: Receiver-based Approach 基于receiver的方案: 这种方式使用Receiver来获取数据.Receiver是使用Kafka的高层次Consumer API来实现的.receiver从Kafka中获

Spark Streaming和Kafka整合开发指南(一)

Apache Kafka是一个分布式的消息发布-订阅系统.可以说,任何实时大数据处理工具缺少与Kafka整合都是不完整的.本文将介绍如何使用Spark Streaming从Kafka中接收数据,这里将会介绍两种方法:(1).使用Receivers和Kafka高层次的API:(2).使用Direct API,这是使用低层次的KafkaAPI,并没有使用到Receivers,是Spark 1.3.0中开始引入的.这两种方法有不同的编程模型,性能特点和语义担保.下文将会一一介绍. 基于Receiver