[
https://issues.apache.org/jira/browse/BEAM-12093?focusedWorklogId=581194&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-581194
]
ASF GitHub Bot logged work on BEAM-12093:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 12/Apr/21 17:50
Start Date: 12/Apr/21 17:50
Worklog Time Spent: 10m
Work Description: egalpin edited a comment on pull request #14347:
URL: https://github.com/apache/beam/pull/14347#issuecomment-817842196
Thanks @echauchot for sharing that thread. I really like a lot of what
@ludovic-boutros proposed and have many shared goals; in particular,
implementing the pattern where successful and failed writes can be returned via
`MultiOutputReceiver`. I believe the multi-output pattern could fit within the
current IO with some additional effort (since order of request and response
entities is guaranteed[1]), and I had planned to do that as a follow-up so as
to not introduce even more changes in one PR.
At the same time, I also see the argument that in many ways using the
low-level client results in "reinventing the wheel" for a number of features
(with good justification, IMO, of enabling cross-version support).
I'd be very willing to contribute to brainstorming (and implementation once
we reach that point) if others are open to that.
[1]
https://discuss.elastic.co/t/order-of-actions-in-bulk-api-via-http-between-request-and-response-is-guaranteed/122499/2
--
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: 581194)
Time Spent: 2h (was: 1h 50m)
> Overhaul ElasticsearchIO#Write
> ------------------------------
>
> Key: BEAM-12093
> URL: https://issues.apache.org/jira/browse/BEAM-12093
> Project: Beam
> Issue Type: Improvement
> Components: io-java-elasticsearch
> Reporter: Evan Galpin
> Priority: P2
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The current ElasticsearchIO#Write is great, but there are two related areas
> which could be improved:
> # Separation of concern
> # Bulk API batch size optimization
>
> Presently, the Write transform has 2 responsibilities which are coupled and
> inseparable by users:
> # Convert input documents into Bulk API entities, serializing based on user
> settings (partial update, delete, upsert, etc)
> # Batch the converted Bulk API entities together and interface with the
> target ES cluster
>
> Having these 2 roles tightly coupled means testing requires an available
> Elasticsearch cluster, making unit testing almost impossible. Allowing access
> to the serialized documents would make unit testing much easier for pipeline
> developers, among numerous other benefits to having separation between
> serialization and IO.
> Relatedly, the batching of entities when creating Bulk API payloads is
> currently limited by the lesser of Beam Runner bundling semantics, and the
> `ElasticsearchIO#Write#maxBatchSize` setting. This is understandable for
> portability between runners, but it also means most Bulk payloads only have a
> few (1-5) entities. By using Stateful Processing to better adhere to the
> `ElasticsearchIO#Write#maxBatchSize` setting, we have been able to drop the
> number of indexing requests in an Elasticsearch cluster by 50-100x.
> Separating the role of document serialization and IO allows supporting
> multiple IO techniques with minimal and understandable code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
