Github user steveloughran commented on a diff in the pull request:
https://github.com/apache/spark/pull/14731#discussion_r78932779
--- Diff: docs/streaming-programming-guide.md ---
@@ -644,13 +644,44 @@ methods for creating DStreams from files as input
sources.
</div>
</div>
- Spark Streaming will monitor the directory `dataDirectory` and process
any files created in that directory (files written in nested directories not
supported). Note that
-
- + The files must have the same data format.
- + The files must be created in the `dataDirectory` by atomically
*moving* or *renaming* them into
- the data directory.
- + Once moved, the files must not be changed. So if the files are
being continuously appended, the new data will not be read.
-
+ Spark Streaming will monitor the directory `dataDirectory` and process
any files created in that directory.
+
+ + A simple directory can be supplied, such as
`hdfs://namenode:8040/logs/`.
+ All files directly such a path will be processed as they are
discovered.
+ + A regular expression can be supplied instead, such as
+ `hdfs://namenode:8040/logs/2016-*-31`.
+ Here, the DStream will consist of all files directly under those
directories
+ matching the regular expression.
+ That is: it is a pattern of directories, not of files in
directories.
+ + All files must be in the same data format.
+ * A file is considered part of a time period based on its
modification time
+ ânot its creation time.
+ + Files must be created in/moved under the `dataDirectory`
directory/directories by
+ an atomic operation. In HDFS and similar filesystems, this can be
done *renaming* them
+ into the data directory from another part of the same filesystem.
+ * If a wildcard is used to identify directories, such as
`hdfs://namenode:8040/logs/2016*`,
+ renaming an entire directory to match the path will add the
directory to the list of
+ monitored directories. However, unless the modification time of the
directory's files
+ are within that of the current window, they will not be recognized
as new files.
+ + Once processed, changes to a file will not cause the file to be
reread.
+ That is: Updates are ignored.
+ + The more files under a directory/wildcard pattern, the longer it
will take to
+ scan for changes âeven if no files have actually changed.
+
+ Special points for object stores
--- End diff --
w.r.t slow renames, I think people just need to be aware that it can be
slow and windows need to plan for it. I'm soon to work on faster renames on S3
[HADOOP-13600](https://issues.apache.org/jira/browse/HADOOP-13600), but it will
still be a non-atomic, O(largest-blob) operation
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
