[
https://issues.apache.org/jira/browse/BEAM-9856?focusedWorklogId=430466&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-430466
]
ASF GitHub Bot logged work on BEAM-9856:
----------------------------------------
Author: ASF GitHub Bot
Created on: 04/May/20 23:52
Start Date: 04/May/20 23:52
Worklog Time Spent: 10m
Work Description: jaketf edited a comment on pull request #11596:
URL: https://github.com/apache/beam/pull/11596#issuecomment-623766796
@chamikaramj thanks for the suggestion. I will look into using BoundedSource
API.
Unfortunately, regular DoFns don't cut it because a single elements outputs
are committed atomically (see this
[conversation](https://github.com/apache/beam/pull/11538#discussion_r416927740)).
Basically we have one input element (HL7v2 store) exploding to many, many
output elements (all the messages in that store) in a single ProcessElement
call. I'm trying to explore strategies for splitting up this listing.
I originally chose splittable DoFn over BoundedSource based off the
sentiment of this statement:
> **Coding against the Source API involves a lot of boilerplate and is
error-prone**, and it does not compose well with the rest of the Beam model
because a Source can appear only at the root of a pipeline. -
https://beam.apache.org/blog/2017/08/16/splittable-do-fn.html
The blog also mentions
- A Source can not emit an additional output (for example, records that
failed to parse).
- Healthcare customers feeding requirements for this plugin want DLQ on
all sinks and sources. To be consistent with the streaming API provided in
`HL7v2IO.Read` I wanted to provide DLQ in `HLv2IO.ListMessages`. However, I
believe this is more of a nice to have for batch use cases (because there's no
room for passing ListMessages bad messages IDs like there is in HL7v2IO.Read).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 430466)
Time Spent: 1h 40m (was: 1.5h)
> 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: 1h 40m
> 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)
