Spark Streaming 的玫瑰与刺

  • 时间:
  • 浏览:1
  • 来源:uu快3分析_uu快3APP_计划

监控之刺

checkpoint 之刺

玫瑰篇主我希望说Spark Streaming的优势点。

可能性现阶段亲戚亲戚朋友并那末维护另4个Spark的私有版本,所以 是通过重写FileInputDStream,NewHadoopRDD 等相关类来修正该哪几种的大问题。

checkpoint 是个很好的恢复机制。想要 方案比较粗暴,直接通过序列化的机制写入到文件系统,导致 着代码变更和配置变更无法生效。实际场景是升级往往比系统崩溃的频率高很多。想要 升级还能不可否 了还可否 无缝的衔接上一次的偏移量。所以 spark streaming在无法容忍数据有丢失的具体情况下,你还能不可否 了某些人记录偏移量,想要 从上一次进行恢复。

亲戚亲戚朋友目前是重写了相关的代码,每次记录偏移量,不过还能不可否 了在升级的后后才会读取某些人记录的偏移量,某些具体情况都在依然采用checkpoint机制。

Kafka的分区数决定了你的并行度(亲戚亲戚朋友假设你使用Direct Approach的模式集成)。为了获得更大的并行度,则还能不可否 了进行一次repartition,而repartition 就导致 着分析还能不可否 了趋于稳定Shuffle,在流式计算里,可能性会消耗掉亲戚亲戚朋友宝贵的时间。 为了还可否 处里Shuffle,想要 提高Spark Streaming处里的并行度,亲戚亲戚朋友重写了 DirectKafkaInputDStream,KafkaRDD,KafkaUtils等类,实现了另4个Kafka partition 还能不可否 映射为多个RDD partition的功能。譬如你有M个Kafka partitions,则可映射成  M*N个 RDD partitions。 其中N 为>1 的正整数。

说人话:随便说说我希望讲Spark Streaming 的好处与坑。好处主要从某些大的方面讲,坑则是从实际场景中遇到的某些小细节描述。

这里好歹做了个EOFException。然而,可能性是另4个压缩文件,解压的后后就直接产生错误了,一般而言是 IOException,而都在EOFException了,某些后后也就歇菜了。

处里法子是后后记录kafka偏移量和时间的关系(还能不可否 隔几秒记录一次),想要 根据时间找到另4个较大的偏移量后后刚开使消费。可能性你根据目前Kafka新增数据的消费强度,给smallest获取到的偏移量加进去去另4个较大的值,处里出显Spark Streaming 在fetch的后后数据不趋于稳定的具体情况。

处里法子自然是把 fetch.message.max.bytes 设置大些。

textFileStream

Spark Streaming 里火山玻璃就还能不可否 使用 sql/dataframe/datasets 等。想要 时间窗口的使用还能不可否 极大扩展某些使用场景,譬如各种系统预警等。你是什么Storm则还能不可否 了额外的开发与支持。

你在日志中看多的信息随便说说是某些代码答应出来的:

可能性你使用Spark Streaming去追数据,从头后后刚开使消费kafka,而Kafka可能性某些导致 着,老数据快速的被清理掉,也会引发OffsetOutOfRangeException错误。想要 使得Spark Streaming线程运行异常的终止。

而在 HadoopRDD类中,对应的实现如下:

随便说说使用textFileStream 的人应该我希望少。可能性还能不可否 很方便的监控HDFS上某个文件夹下的文件,想要 进行计算。这里亲戚亲戚朋友遇到的另4个哪几种的大问题是,可能性底层比如是压缩文件,遇到有顺坏的文件,你是跳不过去的,直接会让Spark Streaming 异常退出。 官方并那末提供至少的法子你还能不可否 跳过损坏的文件。以NewHadoopRDD为例,顶端有那末几行代码,获取第一根新的数据:

Shuffle (尤其是每个周期数据量很大的具体情况)是Spark Streaming 不可处里的疼痛,尤其是数据量极大的具体情况,可能性Spark Streaming对处里的时间是有限制的。亲戚亲戚朋友有另4个场景,是五分钟另4个周期,亲戚亲戚朋友仅仅是做了另4个repartion,耗时就达到2.1分钟(包括到Kafka取数据)。现阶段Spark 的Shuffle实现都还能不可否 了落磁盘,想要 Shuffle Write 和 Shuffle Read 阶段是全部分开,后者还能不可否 了等到前者都完成还可否 后后刚开使工作。我认为Spark Streaming有必要单独开发另4个更慢速,全部基于内存的Shuffle方案。

Shuffle 之刺

某些和Spark Streaming相关,我希望太相关。说相关是可能性Spark 对所以 异常处里比较简单。所以 是和Kafka配置相关的。我举个例子:

亲戚亲戚朋友期望官方还可否 实现将另4个Kafka的partitions 映射为多个Spark 的partitions,处里趋于稳定Shuffle而导致 着多次的数据移动。

可能性你使用Spark MLlib 做模型训练。恭喜你,首先是所以 算法可能性支持Spark Streaming,譬如k-means 就支持流式数据更新模型。 其次,你还可否 还可否 在Spark Streaming中直接将离线计算好的模型load进来,想要 对新进来的数据做实时的Predict操作。

某些人认为应该加进去去某些配置,允许用户还能不可否 选折 怎样对待某些有损坏可能性无法解压的文件。

通过reader 获取下第一根记录的后后,譬如是另4个损坏的gzip文件,可能性就会抛出异常,而某些异常是用户catch还能不可否 了的,直接让Spark Streaming线程运行挂掉了。

可能性消息体很多了,超过 fetch.message.max.bytes=1m,那末Spark Streaming会直接抛出OffsetOutOfRangeException异常,想要 停止服务。

Spark Streaming 还能不可否 很好的控制实时的程度(小时,分钟,秒)。极端具体情况还能不可否 设置到毫秒。

在Spark Streaming中,你也会遇到在Spark中常见的哪几种的大问题,典型如Executor Lost 相关的哪几种的大问题(shuffle fetch 失败,Task失败重试等)。这就导致 着分析趋于稳定了内存趋于稳定问题可能性数据倾斜的哪几种的大问题。某些目前你还能不可否 了考虑如下几条点以期获得处里方案:

Kafka partition 映射 RDD partition 之刺

玫瑰之代码复用

这主要得益于Spark的设计,以及平台的全面性。你写的流处里的代码还能不可否 很方便的适用于Spark平台上的批处里,交互式处里。可能性亲戚亲戚朋友某些都在基于RDD模型的,想要 Spark Streaming的设计者也做了比较好的封装和兼容。所以 你爱不爱我RDD是个很强大的框,能把各种场景都给框住,这我希望厚度抽象和思考后的结果。

内存之刺

玫瑰之概述

玫瑰之机器学习

对应的错误会从这行代码抛出:

玫瑰之SQL支持

随便说说我希望消费的完成后 实际的消费数据量和预先估计的量不一致。

玫瑰之吞吐和实时的有效控制

Spark Streaming 的UI 上的Executors Tab缺少另4个最大的监控,我希望Worker内存GC详情。随便说说亲戚亲戚朋友还能不可否 将哪几种信息导入到 第三方监控中,然而终究是不如在 Spark UI上展现更加方便。 为此亲戚亲戚朋友也将该功能列入研发计划。

Spark Streaming 还能不可否 很好的和Spark某些组件进行交互,获取其支持。同時 Spark 生态圈的快速发展,亦能从中受益。

刺篇我希望描述Spark Streaming 的某些哪几种的大问题,做选型前关注哪几种哪几种的大问题可是是不是效的降低使用风险。

目前Spark Streaming 还能不可否 应对的场景不少,想要 在所以 场景上,还是有原先那样的哪几种的大问题。建议调研后都进一步做测试再做出是是不是迁移到该平台的决定。

Kafka 之刺