Next Previous Up Contents
Next: Feather
Up: Supplied Output Handlers
Previous: ECSV

#### 3.7.4 Parquet

Parquet is a columnar format developed within the Apache project. Data is compressed on disk and read into memory before use. The file format is described at https://github.com/apache/parquet-format. This software is written with reference to version 2.10.0 of the format.

The parquet file format itself defines only rather limited semantic metadata, so that there is no standard way to record column units, descriptions, UCDs etc. By default, additional metadata is written in the form of a DATA-less VOTable attached to the file footer, as described by the VOParquet convention. This additional metadata can then be retrieved by other VOParquet-aware software.

Note:

> The parquet I/O handlers require large external libraries. In previous releases of this software they were not always bundled with the library/application software because of their size, but in the current release they are included in the `topcat-full.jar`, `stilts.jar` and `topcat-all.dmg` files, so it is likely they will be present. So you usually will not encounter this problem, but if these libraries are absent then attempts to read or write parquet files will result in a message like:

>        Parquet-mr libraries not available

> If you can supply the relevant libaries on the classpath at runtime, the parquet support will work; they can be identified as dependencies of org.apache.parquet/parquet-cli/1.13.1.

> The bundled libraries support most, but not all, of the compression formats defined for parquet, currently `uncompressed`, `gzip`, `snappy`, `zstd`, `lz4` and `lz4_raw`. Supplying more of the parquet-mr/parquet-java dependencies at runtime would extend this list. Unlike the rest of TOPCAT/STILTS/STIL which is written in pure java, some of these libraries (currently the snappy and zstd compression codecs) contain native code, which means they may not work on all architectures. At time of writing all common architectures are covered, but there is the possibility of failure with a `java.lang.UnsatisfiedLinkError` on other platforms if attempting to read/write files that use those compression algorithms.

The handler behaviour may be modified by specifying one or more comma-separated name=value configuration options in parentheses after the handler name, e.g. "`parquet(votmeta=false,compression=gzip)`". The following options are available:

`votmeta = true|false`
  If true, rich metadata for the table will be written out in the form of a DATA-less VOTable that is stored in the parquet extra metadata key-value list under the key `IVOA.VOTable-Parquet.content`, according to the VOParquet convention (version 1.0). This enables items such as Units, UCDs and column descriptions, that would otherwise be lost in the serialization, to be stored in the output parquet file. This information can then be recovered by parquet readers that understand this convention. (Default: `true`)
`compression = uncompressed|snappy|zstd|gzip|lz4|lz4_raw`
  Configures the type of compression used for output. Supported values are probably `uncompressed`, `snappy`, `zstd`, `gzip`, `lz4` and `lz4_raw`. Others may be available if the relevant codecs are on the classpath at runtime. If no value is specified, the parquet-mr library default is used, which is probably `uncompressed`. (Default: `null`)
`kvmap = key1:value1;key2:value2;...`
  Can be used to doctor the map of key-value metadata stored in the parquet footer. Map items are specified with a colon, like `<key>:<value>` and separated with a semicolon, so for instance you could write "`kvmap=author:Messier;year:1774`". This will overwrite any map entries that would otherwise have been written. If a value starts with the at sign ("`@`") it is interpreted as giving the name of a file whose contents will be used instead of the literal value. Specifying an empty entry will ensure it is not written into the key=value list.

  The following output format specification would write parquet output including VOParquet metadata from a manually prepared VOTable file `meta.vot`:

         parquet(votmeta=false,kvmap=IVOA.VOTable-Parquet.version:1.0;IVOA.VOTable-Parquet.content:@meta.vot)

`usedict = true|false|null`
  Determines whether dictionary encoding is used for output. This will work well to compress the output for columns with a small number of distinct values. Even when this setting is true, dictionary encoding is abandoned once many values have been encountered (the dictionary gets too big). If no value is specified, the parquet-mr library default is used, which is probably `true`. (Default: `null`)
`groupArray = true|false`
  Controls the low-level detail of how array-valued columns are written. For an array-valued int32 column named IVAL, `groupArray=false` will write it as "`repeated int32 IVAL`" while `groupArray=true` will write it as "`optional group IVAL (LIST) {repeated group list {optional int32 element}}`".

  Although setting it `false` may be slightly more efficient, the default is `true`, since if any of the columns have array values that either may be null or may have elements which are null, groupArray-style declarations for all columns are required by the Parquet file format:

  > "A repeated field that is neither contained by a LIST- or MAP-annotated group nor annotated by LIST or MAP should be interpreted as a required list of required elements where the element type is the type of the field. Implementations should use either LIST and MAP annotations or unannotated repeated fields, but not both. When using the annotations, no unannotated repeated types are allowed."

  If this option is set false and an attempt is made to write null arrays or arrays with null values, writing will fail. (Default: `true`)

If no output format is explicitly chosen, writing to a filename with the extension "`.parquet`" or "`.parq`" (case insensitive) will select `parquet` format for output.

The handler class for files of this format is `ParquetTableWriter`.

Next Previous Up Contents
Next: Feather
Up: Supplied Output Handlers
Previous: ECSV

STIL - Starlink Tables Infrastructure Library
Starlink User Note252
STIL web page: http://www.starlink.ac.uk/stil/
Author email: m.b.taylor@bristol.ac.uk