Good point - added. Note that since there is no underlying representation of unions in parquet I have modelled this as separate "memberN" sub-records. This results in a sparsely populated column set but is about the only option I see. 

We use unions heavily to replicate inheritance - so I would draw parallels between what I am doing here and a one table per class hierarchy in an ORM.