You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Sean Owen (JIRA)" <ji...@apache.org> on 2014/12/04 12:42:12 UTC

[jira] [Commented] (SPARK-4734) [Streaming]limit the file Dstream size for each batch

    [ https://issues.apache.org/jira/browse/SPARK-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234146#comment-14234146 ] 

Sean Owen commented on SPARK-4734:
----------------------------------

I don't quite understand this suggestion. In general, if processing time exceeds the batch duration, you simply need a longer batch duration or need to speed up your processing. Lots of small files are a problem in general, for shuffle -- although less so for a sort-based shuffle.

The basic solution there is: don't design your system to put lots of tiny files on HDFS.

Are you suggesting capping the amount of data in each batch? This does not solve either problem. Either you are just running more, smaller batches, or you are dropping data. In any event this amounts to a significant change in semantics. This doesn't sound likely.

> [Streaming]limit the file Dstream size for each batch
> -----------------------------------------------------
>
>                 Key: SPARK-4734
>                 URL: https://issues.apache.org/jira/browse/SPARK-4734
>             Project: Spark
>          Issue Type: New Feature
>          Components: Streaming
>            Reporter: 宿荣全
>            Priority: Minor
>
> Streaming scan new files form the HDFS and process those files in each batch process.Current streaming exist some problems:
> 1.When the number of files is very large(the count size of those files is very large) in some batch segement.The processing time required will become very long.The processing time maybe over slideDuration time.Eventually lead to dispatch the next batch process is delay.
> 2.when the size of total file Dstream  is very large in one batch,those  dstream data do shuffle after memory will be n times increasing occupation,app will be slow or even terminated by operating system.
> So if we set a upper limit value of input data for each batch to control the batch process time,the job dispatch delay and the process delay wil be alleviated.
> modification:
> Add a new parameter "spark.streaming.segmentSizeThreshold" in InputDStream (input data base class).the size of each batch process segments  will be set in this parameter from [spark-defaults.conf] or setting in source.
> all implements class of InputDStream will do corresponding action be aimed at the segmentSizeThreshold.
> This patch is a modification about FileInputDStream ,so when find new files      ,put those files's name and size in a queue and take elements package to a batch data with totail size < segmentSizeThreshold  in FileInputDStream.Please look source about detailed logic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org