Spark Streaming 的玫瑰与刺

  • 时间:
  • 浏览:4
  • 来源:uu快3棋牌_uu快3讨论群_规律

Kafka 之刺

你在日志中看完的信息我觉得是这些 代码答应出来的:

亲戚亲戚亲们目前是重写了相关的代码,每次记录偏移量,不过没法在升级的已经 才会读取其他人记录的偏移量,其他情况汇报一定会 依然采用checkpoint机制。

玫瑰之机器学习

玫瑰之概述

Spark Streaming 都能不能 很好的和Spark其他组件进行交互,获取其支持。一并Spark 生态圈的快速发展,亦能从中受益。

textFileStream

内存之刺

亲戚亲戚亲们期望官方能不能 实现将2个Kafka的partitions 映射为多个Spark 的partitions,避免趋于稳定Shuffle可原困多次的数据移动。

刺篇可是描述Spark Streaming 的其他问题报告 ,做选型前关注那先 问题报告 都能不能 有效的降低使用风险。

这主要得益于Spark的设计,以及平台的全面性。你写的流避免的代码都能不能 很方便的适用于Spark平台上的批避免,交互式避免。将会亲戚亲戚亲们三种一定会 基于RDD模型的,其他Spark Streaming的设计者也做了比较好的封装和兼容。可是你说歌词 RDD是个很强大的框,能把各种场景都给框住,这可是宽度抽象和思考后的结果。

Spark Streaming 的UI 上的Executors Tab缺少2个最大的监控,可是Worker内存GC详情。我觉得亲戚亲戚亲们都能不能 将那先 信息导入到 第三方监控中,然而终究是不如在 Spark UI上展现更加方便。 为此亲戚亲戚亲们也将该功能列入研发计划。

避免办法是已经 记录kafka偏移量和时间的关系(都能不能 隔几秒记录一次),其他根据时间找到2个较大的偏移量开始消费。将会你根据目前Kafka新增数据的消费强度,给smallest获取到的偏移量添加2个较大的值,避免再次出现Spark Streaming 在fetch的已经 数据不趋于稳定的情况汇报。

这些 和Spark Streaming相关,可是太相关。说相关是将会Spark 对可是异常避免比较简单。可是是和Kafka配置相关的。我举个例子:

这里好歹做了个EOFException。然而,将会是2个压缩文件,解压的已经 就直接产生错误了,一般而言是 IOException,而一定会 EOFException了,这些 已经 也就歇菜了。

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

Spark Streaming 里盐晶 就都能不能 使用 sql/dataframe/datasets 等。其他时间窗口的使用都能不能 极大扩展这些 使用场景,譬如各种系统预警等。类事Storm则时要额外的开发与支持。

在Spark Streaming中,你也会遇到在Spark中常见的问题报告 ,典型如Executor Lost 相关的问题报告 (shuffle fetch 失败,Task失败重试等)。这可原困趋于稳定了内存过低将会数据倾斜的问题报告 。这些 目前你时要考虑如下2个点以期获得避免方案:

checkpoint 是个很好的恢复机制。其他方案比较粗暴,直接通过序列化的机制写入到文件系统,原困代码变更和配置变更无法生效。实际场景是升级往往比系统崩溃的频率高太大。其他升级时能不能 能无缝的衔接上一次的偏移量。可是spark streaming在无法容忍数据有丢失的情况汇报下,你时要其他人记录偏移量,其他从上一次进行恢复。

Spark Streaming 都能不能 很好的控制实时的程度(小时,分钟,秒)。极端情况汇报都能不能 设置到毫秒。

说人话:我觉得可是讲Spark Streaming 的好处与坑。好处主要从其他大的方面讲,坑则是从实际场景中遇到的其他小细节描述。

我觉得使用textFileStream 的人应该可是少。将会都能不能 很方便的监控HDFS上某个文件夹下的文件,其他进行计算。这里亲戚亲戚亲们遇到的2个问题报告 是,将会底层比如是压缩文件,遇到有顺坏的文件,你是跳不过去的,直接会让Spark Streaming 异常退出。 官方并没法提供相当于的办法让我跳过损坏的文件。以NewHadoopRDD为例,上方有没法几行代码,获取三根绳子 新的数据:

通过reader 获取下三根绳子 记录的已经 ,譬如是2个损坏的gzip文件,将会就会抛出异常,而这些 异常是用户catch没法的,直接让Spark Streaming程序挂掉了。

将会消息体太大了,超过 fetch.message.max.bytes=1m,没法Spark Streaming会直接抛出OffsetOutOfRangeException异常,其他停止服务。

我觉得可是消费的完成后 实际的消费数据量和预先估计的量不一致。

Kafka partition 映射 RDD partition 之刺

玫瑰之代码复用

玫瑰之SQL支持

其他人认为应该添加其他配置,允许用户都能不能 选折 怎么能不能 对待这些 有损坏将会无法解压的文件。

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

Shuffle (尤其是每个周期数据量很大的情况汇报)是Spark Streaming 不可避免的疼痛,尤其是数据量极大的情况汇报,将会Spark Streaming对避免的时间是有限制的。亲戚亲戚亲们2个场景,是五分钟2个周期,亲戚亲戚亲们仅仅是做了2个repartion,耗时就达到2.1分钟(包括到Kafka取数据)。现阶段Spark 的Shuffle实现都时要落磁盘,其他Shuffle Write 和 Shuffle Read 阶段是详细分开,后者时要等到前者都完成能不能 开始工作。我认为Spark Streaming有必要单独开发2个放慢速,详细基于内存的Shuffle方案。

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

目前Spark Streaming 都能不能 应对的场景不少,其他在可是场景上,还是有从前那样的问题报告 。建议调研后都进一步做测试再做出是是否迁移到该平台的决定。

Shuffle 之刺

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

checkpoint 之刺

将会你使用Spark Streaming去追数据,从头开始消费kafka,而Kafka将会三种原困,老数据快速的被清理掉,也会引发OffsetOutOfRangeException错误。其他使得Spark Streaming程序异常的终止。

玫瑰篇主可是说Spark Streaming的优势点。

将会现阶段亲戚亲戚亲们并没法维护2个Spark的私有版本,可是是通过重写FileInputDStream,NewHadoopRDD 等相关类来修正该问题报告 。

避免办法自然是把 fetch.message.max.bytes 设置大些。

监控之刺

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