Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/3079
@MikeThomsen the advantage is not having to write the parquet out to local
disk somewhere, and then have a disconnected flow where another part reads it
back in. With this approach the data stays in NiFi's repositories and the
ConvertAvroToParquet can be directly connected to the next processor.
I will try to give this a review in the coming days... Since this processor
is already developed, the best approach here maybe to commit this as is
(assuming the processor works as expected) and then afterwards refactor the
utility classes into a nifi-parquet-utils under
nifi-nar-bundles/nifi-extension-utils and this way the code can be shared by
this processor and the eventual record writer.
---
