SparkStreaming和Kafka整合是如何保证数据零丢失.PDF

Spark Streaming和Kafka整合是如何保证数据零丢失 Spark大数据博客 - Spark Streaming和Kafka整合是如何保证数据零丢失 当我们正确地部署好Spark Streaming，我们就可以使用Spark Streaming提供的零数据丢失机制。为了体验这个关键的特性，你需要满足以下几个先决条件： 1、输入的数据来自可靠的数据源和可靠的接收器； 2、应用程序的metadata被application的driver持久化了(checkpointed ); 3、启用了WAL特性(Write ahead log)。 下面我将简单地介绍这些先决条件。 可靠的数据源和可靠的接收器 对于一些输入数据源（比如Kafka），Spark Streaming可以对已经接收的数据进行确认。输入的数据首先被接收器（receivers ）所接收，然 后存储到Spark中（默认情况下，数据保存到2个执行器中以便进行容错）。数据一旦存储到Spar k中，接收器可以对它进行确认（比如，如果消费Kafka里面的数据时可以更新Zookeeper里面的 偏移量）。这种机制保证了在接收器突然挂掉的情况下也不会丢失数据：因为数据虽然被接收， 但是没有被持久化的情况下是不会发送确认消息的。所以在接收器恢复的时候，数据可以被原端 重新发送。 1 / 6 Spark Streaming和Kafka整合是如何保证数据零丢失 Spark大数据博客 - 元数据持久化(Metadata checkpointing) 可靠的数据源和接收器可以让我们从接收器挂掉的情况下恢复（或者是接收器运行的Exectu or和服务器挂掉都可以）。但是更棘手的问题是，如果Driver挂掉如何恢复？对此开发者们引入 了很多技术来让Driver从失败中恢复。其中一个就是对应用程序的元数据进行Checkpint。利用这 个特性，Driver可以将应用程序的重要元数据持久化到可靠的存储中，比如HDFS、S3；然后Driv er可以利用这些持久化的数据进行恢复。元数据包括： 1、配置； 2、代码； 3、那些在队列中还没有处理的batch（仅仅保存元数据，而不是这些batch中的数据） 2 / 6 Spark Streaming和Kafka整合是如何保证数据零丢失 Spark大数据博客 - 由于有了元数据的Checkpint，所以Driver可以利用他们重构应用程序，而且可以计算出Driv er挂掉的时候应用程序执行到什么位置。 可能存在数据丢失的场景 令人惊讶的是，即使是可靠的数据源、可靠的接收器和对元数据进行Checkpint，仍然不足 以阻止潜在的数据丢失。我们可以想象出以下的糟糕场景： 1、两个Exectuor已经从接收器中接收到输入数据，并将它缓存到Exectuor的内存中； 2、接收器通知输入源数据已经接收； 3、Exectuor根据应用程序的代码开始处理已经缓存的数据； 4、这时候Driver突然挂掉了； 5、从设计的角度看，一旦Driver挂掉之后，它维护的Exectuor也将全部被kill； 6、既然所有的Exectuor被kill了，所以缓存到它们内存中的数据也将被丢失。结果，这些已 经通知数据源但是还没有处理的缓存数据就丢失了； 7、缓存的时候不可能恢复，因为它们是缓存在Exectuor的内存中，所以数据被丢失了。 这对于很多关键型的应用程序来说非常的糟糕，不是吗？ WAL（Write ahead log） 为了解决上面提到的糟糕场景，S