大数据学习：Spark Streaming 整合Kafka

针对于流计算处理任务，Spark推出了Spark Streaming，而作为流计算引擎，不免地需要与其他相关的组件工具配合，共同完成数据处理任务，比较典型的场景，就是与kafka的整合使用。今天的大数据学习分享，我们就具体来讲讲Spark Streaming 整合Kafka的具体实现。


一、Spark整合kafka连接方式

①Receiver方式

为了保证数据安全，要将数据写入磁盘记录日志【Write Ahead Log】，效率低

使用Kafka老版本的消费API，偏移量记录在Zookeeper中，效率低

②直连方式

建议使用Kafka 0.10及以上版本

使用Kafka底层高效API

一个Kafka Topic分区对应一个RDD的分区，即RDD分区的数量和Kafka分区的数量是一一对应的，生成的Task直接连到Kafka topic的Leader分区拉取数据，一个消费者Task对应一个Kafka分区

可以通过编程自己管理偏移量

支持动态topic订阅

在Driver端调用foreachRDD获取DStream中的KafkaRDD，传入foreachRDD方法的函数在Driver端会周期性的执行

KafkaDStream必须先就调用foreachRDD方法【或tansform】才能获取到KafkaRDD，只有KafkaRDD中有偏移量

KafkaRDD实现了HasOffsetRanger接口，可以获取Kafka分区的偏移量，一个批次处理完后，可以将偏移量写入到Kafka、MySQL或Redis

二、Spark整合kafka存储偏移量方案

发生故障时的Kafka交付语义取决于存储偏移量的方式和时间。Spark输出操作至少一次。因此，如果希望等效于一次语义，则必须在幂等输出之后存储偏移量，或者在输出中将偏移量存储在原子事务中。通过这种集成，您可以按照增加可靠性（和代码复杂度）的顺序，使用3种方法来存储偏移量。

①CheckPoints

如果启用Spark checkpointing，则偏移量将存储在检查点中。这很容易实现，但是有缺点。输出操作必须是幂等的，否则将获得重复的输出。交易不是一种选择。此外，如果应用程序代码已更改，则无法从检查点恢复。对于计划的升级，可以通过与旧代码同时运行新代码来减轻这种情况（因为输出无论如何都需要等幂，因此它们不应冲突）。但是对于需要代码更改的计划外故障，除非有另一种方法来识别已知的良好起始偏移，否则将丢失数据。

②Kafka本身特殊的topic

Kafka具有偏移提交API，该API在特殊的Kafka主题中存储偏移量。默认情况下，新使用者将定期自动提交偏移量。与检查点相比，它的好处是，无论对应用程序代码进行的更改如何，Kafka都是持久存储。但是，Kafka不是事务性的，因此输出必须仍然是幂等的。

③自定义数据存储

对于支持事务的数据存储，即使在失败情况下，将偏移与结果保存在同一事务中也可以使两者保持同步。这相当于一次语义。即使是由于聚合而产生的输出（通常很难使等幂），也可以使用此策略。

关于大数据学习，Spark Streaming 整合Kafka，以上就为大家做了简单的介绍了。在企业级的大数据场景下，Spark Streaming和kafka的整合是一种很常见的形式，作为开发者需要有基本的掌握。成都加米谷大数据，专业大数据培训机构，大数据开发、数据分析与挖掘，零基础就业班本月正在招生中，课程大纲及学习视频可联系客服获取！