[
https://issues.apache.org/jira/browse/BEAM-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Ferriero updated BEAM-9856:
---------------------------------
Description:
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")
was:
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 )
1. 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")
> 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
>
> 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)
