[
https://issues.apache.org/jira/browse/BEAM-9856?focusedWorklogId=435240&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-435240
]
ASF GitHub Bot logged work on BEAM-9856:
----------------------------------------
Author: ASF GitHub Bot
Created on: 19/May/20 22:42
Start Date: 19/May/20 22:42
Worklog Time Spent: 10m
Work Description: jaketf commented on a change in pull request #11596:
URL: https://github.com/apache/beam/pull/11596#discussion_r427641350
##########
File path:
sdks/java/io/google-cloud-platform/src/main/java/org/apache/beam/sdk/io/gcp/healthcare/HL7v2IO.java
##########
@@ -415,10 +423,29 @@ private Message fetchMessage(HealthcareApiClient client,
String msgId)
}
}
- /** List HL7v2 messages in HL7v2 Stores with optional filter. */
+ /**
+ * List HL7v2 messages in HL7v2 Stores with optional filter.
+ *
+ * <p>This transform is optimized for dynamic splitting of message.list
calls for large batches of
+ * historical data and assumes rather continuous stream of sendTimes. It
will dynamically
+ * rebalance resources to handle "peak traffic times" but will waste
resources if there are large
+ * durations (days) of the sendTime dimension without data.
+ *
+ * <p>Implementation includes overhead for: 1. two api calls to determine
the min/max sendTime of
+ * the HL7v2 store at invocation time. 2. initial splitting into
non-overlapping time ranges
+ * (default daily) to achieve parallelization in separate messages.list
calls.
+ *
+ * <p>This will make more queries than necessary when used with very small
data sets. (or very
+ * sparse data sets in the sendTime dimension).
+ *
+ * <p>If you have large but sparse data (e.g. hours between consecutive
message sendTimes) and
+ * know something about the time ranges where you have no data, consider
using multiple instances
+ * of this transform specifying sendTime filters to omit the ranges where
there is no data.
Review comment:
That's great to know! will remove this guidance as it will lead to
unnecessary complexity.
----------------------------------------------------------------
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: 435240)
Time Spent: 7.5h (was: 7h 20m)
> 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: P3
> Time Spent: 7.5h
> 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)
