[
https://issues.apache.org/jira/browse/BEAM-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16595337#comment-16595337
]
Tim Robertson edited comment on BEAM-5036 at 8/28/18 5:58 PM:
--------------------------------------------------------------
For info on the other rename() methods:
* {{S3FileSystem}} implements {{rename()}} as a [copy and
delete|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/io/amazon-web-services/src/main/java/org/apache/beam/sdk/io/aws/s3/S3FileSystem.java#L597]
* {{GcsFileSystem}} implements {{rename()}} as a [copy and
delete|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/extensions/google-cloud-platform-core/src/main/java/org/apache/beam/sdk/extensions/gcp/storage/GcsFileSystem.java#L122]
* {{LocalFileSystem}} implements {{rename()}} by [making the parent directory
if
necessary|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/core/src/main/java/org/apache/beam/sdk/io/LocalFileSystem.java#L164]
and then does a file move
* {{HDFSFileSystem}} following BEAM-4861 (fixed and ready to merge) now
implements {{rename()}} by creating missing parent directories and doing the
move
The move across different filesystems is not (fully) supported because the
{{FileSystems.rename}} gets only the [filesystem for the source
resource|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/core/src/main/java/org/apache/beam/sdk/io/FileSystems.java#L325].
It is not clear to me what might happen if the source were an
{{HDFSFilesystem}} which itself can span multiple Filesystems. It is also not
currently clear to me where we can best do the check - we could simply log a
warn before the call to rename().
was (Author: timrobertson100):
For info on the other rename() methods:
* {{S3FileSystem}} implements {{rename()}} as a [copy and
delete|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/io/amazon-web-services/src/main/java/org/apache/beam/sdk/io/aws/s3/S3FileSystem.java#L597]
* {{GcsFileSystem}} implements {{rename()}} as a [copy and
delete|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/extensions/google-cloud-platform-core/src/main/java/org/apache/beam/sdk/extensions/gcp/storage/GcsFileSystem.java#L122]
* {{LocalFileSystem}} implements {{rename()}} by [making the parent directory
if
necessary|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/core/src/main/java/org/apache/beam/sdk/io/LocalFileSystem.java#L164]
and then does a file move
* {{HDFSFileSystem}} following BEAM-4861 (fixed and ready to merge) now
implements {{rename()}} by creating missing parent directories and doing the
move
The move across different filesystems is not (fully) supported because the
{{FileSystems.rename}} gets only the [filesystem for the source
resource|https://github.com/apache/beam/blob/release-2.6.0/sdks/java/core/src/main/java/org/apache/beam/sdk/io/FileSystems.java#L325].
It is not clear to me what might happen if the source were an
{{HDFSFilesystem}} which itself can span multiple Filesystems. It is also not
currently clear to me where we can best do the check.
> Optimize FileBasedSink's WriteOperation.moveToOutput()
> ------------------------------------------------------
>
> Key: BEAM-5036
> URL: https://issues.apache.org/jira/browse/BEAM-5036
> Project: Beam
> Issue Type: Improvement
> Components: io-java-files
> Affects Versions: 2.5.0
> Reporter: Jozef Vilcek
> Assignee: Tim Robertson
> Priority: Major
>
> moveToOutput() methods in FileBasedSink.WriteOperation implements move by
> copy+delete. It would be better to use a rename() which can be much more
> effective for some filesystems.
> Filesystem must support cross-directory rename. BEAM-4861 is related to this
> for the case of HDFS filesystem.
> Feature was discussed here:
> http://mail-archives.apache.org/mod_mbox/beam-dev/201807.mbox/%3CCAF9t7_4Mp54pQ+vRrJrBh9Vx0=uaknupzd_qdh_qdm9vxll...@mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
