[jira] [Commented] (BEAM-59) IOChannelFactory rethinking/redesign

["Amit Sela (JIRA)" <ji...@apache.org>]

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

Amit Sela commented on BEAM-59:
-------------------------------

I've recently tried to work with IOChannelFactory and while I don't have anything smart enough to say towards a solution, I hope that providing my point of view will contribute somehow. 
As mentioned here: https://github.com/apache/incubator-beam/pull/539 the default behaviour of validate prevents me from using TextIO with HDFS without explicitly stating withoutValidation() - it only supports File or GS - HDFS is extremely important when talking about Apache's Hadoop eco-system.
When trying to help people run the Spark runner with GS, I found out I need to register it with IOChannelUtils..
Those problems are because the Spark runner still doesn't implement the primitive Read.from, but even once this happens, there is still room for higher-level abstraction such as TextIO, JsonIO, ParquetIO, etc. and I think they should be as "translatable" as possible, with minimal constraints. Not all runner authors can easily influence the runner, and sometimes a runner will work better with it's own implementation.
I guess what I'm trying to say is that there is a delicate balance between having a robust IO abstraction and making runner author's life easier ;-)

Hope this helps, and hope to go into this deeper sometime soon..

> IOChannelFactory rethinking/redesign
> ------------------------------------
>
>                 Key: BEAM-59
>                 URL: https://issues.apache.org/jira/browse/BEAM-59
>             Project: Beam
>          Issue Type: New Feature
>          Components: sdk-java-core, sdk-java-gcp
>            Reporter: Daniel Halperin
>
> Right now, FileBasedSource and FileBasedSink communication is mediated by IOChannelFactory. There are a number of issues:
> * Global configuration -- e.g., all 'gs://' URIs use the same credentials. This should be per-source/per-sink/etc.
> * Supported APIs -- currently IOChannelFactory is in the "non-public API" util package and subject to change. We need users to be able to add new backends ('s3://', 'hdfs://', etc.) directly, without fear that they will be broken.
> * Per-backend features: e.g., creating buckets in GCS/s3, setting expiration time, etc.



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