[jira] [Commented] (BEAM-9856) HL7v2IO.ListHL7v2Messages should be refactored to support more parallelization

["Jacob Ferriero (Jira)" <ji...@apache.org>]

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

Jacob Ferriero commented on BEAM-9856:
--------------------------------------

I have begun work on a POC for what this would look like as splittable DoFn in #11596.

> HL7v2IO.ListHL7v2Messages should be refactored to support more parallelization
> ------------------------------------------------------------------------------
>
>                 Key: BEAM-9856
>                 URL: https://issues.apache.org/jira/browse/BEAM-9856
>             Project: Beam
>          Issue Type: Improvement
>          Components: io-java-gcp
>            Reporter: Jacob Ferriero
>            Assignee: Jacob Ferriero
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the List Messages API paginates through in a single ProcessElement Call.
> However we could get a restriction based on createTime using Messages.List filter and orderby.
>  
> This is inline with the future roadmap of  HL7v2 bulk export API becomes available that should allow splitting on (e.g. create time dimension). Leveraging this bulk export might be  a future optimization to explore.
>  
> This could take one of two forms:
> 1. dyanmically splitable via splitable DoFn (sexy, beam idiomatic: make optimization the runner's problem, potentially unnecessarily complex for this use case )
> 2. static splitting on some time partition e.g. finding the earliest createTime and emitting a PCollection of 1 hour partitions and paginating through each hour of data w/ in the time frame that the store spans, in a separate ProcessElement. (easy to implement but will likely have hot keys / stragglers based on "busy hours")
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)