Github user freeman-lab commented on a diff in the pull request:
https://github.com/apache/spark/pull/3803#discussion_r22496437
--- Diff:
streaming/src/main/scala/org/apache/spark/streaming/StreamingContext.scala ---
@@ -373,6 +393,25 @@ class StreamingContext private[streaming] (
}
/**
+ * Create an input stream that monitors a Hadoop-compatible filesystem
+ * for new files and reads them as flat binary files, assuming a fixed
length per record,
+ * generating one byte array per record. Files must be written to the
monitored directory
+ * by "moving" them from another location within the same file system.
File names
+ * starting with . are ignored.
+ * @param directory HDFS directory to monitor for new file
+ * @param recordLength length of each record in bytes
+ */
+ def binaryRecordsStream(
+ directory: String,
+ recordLength: Int): DStream[Array[Byte]] = {
+ val conf = sc_.hadoopConfiguration
+ conf.setInt(FixedLengthBinaryInputFormat.RECORD_LENGTH_PROPERTY,
recordLength)
+ val br = fileStream[LongWritable, BytesWritable,
FixedLengthBinaryInputFormat](directory, conf)
+ val data = br.map{ case (k, v) => v.getBytes}
--- End diff --
Thanks for flagging this, I wasn't aware of that behavior of ``getBytes``.
I think that, as you suggest, both here and in ``binaryRecords()`` it's not a
problem in practice. The BytesWritable that comes from the
FixedLengthBinaryInputFormat will always be backed by a Byte array that's of
the fixed length. For consistency and good practice I'm happy to make the
change from #2712 both here and in the other method. Or we just add a comment.
Let me know which you'd prefer. One concern might be performance effects, as
mentioned in the other PR? @sryza might have thoughts.
---
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]
