以下の2つの記事を読んで GeoParquet を完全に理解しました。...嘘です。あんまり理解できてないので、ちょっと自分の中での整理もかねて記事を書いてみます。
これまでのあらすじ
Apache Parquet は、今年3月にリリースされたバージョン 2.11.0 で GEOMETRY・GEOGRAPHY 型が追加されました（両方書くと長いので、便宜上、以降は「GEOMETRY型」ということにします）。
しかし、その少し前には GeoParquet もバージョン 1.1 をリリースしています。
この2つの規格は微妙に異なっていて、私は「どっちを使えばいいんだ...？」と混乱しました。どうやら、混乱していたのは私だけではないらしく、先月末に「Parquet の GEOMETRY 型と GeoParquet は違う！」というブログ記事が投稿され、注目を集めていました（ちなみに、著者は hyparquet のコントリビューターの人です。hyparquet は最近 Parquet の GEOMETRY 型をサポートしました）。
これに対するアンサーとして書かれたのが、冒頭の1つ目のブログ記事です。その内容をかいつまんで紹介したいと思います。
違い1: bbox
GeoParquet や Parquet の GEOMETRY 型には bbox 情報があり、データの効率的な絞り込みに使うことができます。ただし、この bbox の持ち方が異なります。この変遷について書かれたのが冒頭の2つ目の記事の方です。それによると、こうなっています。
- GeoParquet v1.0: ファイル単位のメタデータにファイル全体の bbox が入っている
- GeoParquet v1.1: bbox 用のカラムに地物ごとの bbox が入っている
- Parquet の
GEOMETRY型: カラムのメタデータに row group 単位の bbox が入っている
もう少し詳しく説明しましょう。
GeoParquet v1.0
ファイルのメタデータに bbox を入れることができるので、データを適切な単位（例えば、メッシュや行政区画など）に分割することで、不要なデータを読むことが避けられます。ただし、ファイルの中の地物はすべて読む必要があります。
GeoParquet v1.1
GeoParquet v1.1 では、bbox カラム（正確には、convering メタデータで指定されたカラム）に行ごとの bbox 情報が入ります。これによって、地物を直接を読む前にまず bbox で絞り込むことができます。複雑なポリゴンのデータとかだと読む量がかなり減ってうれしいですね。
ただし、行ごとに bbox があるので重いです。なんなら、POINT のデータなら bbox カラムの方が大きくなってしまいます。2つ目のブログ記事によると、例えば Overture Maps の建物データでは bbox カラムだけで 25GB（！）にもなります。また、bbox カラムがファイルサイズ全体の 50% を占めるようなケースもあったそうです。これはエッジケースかもしれませんが、必ずしも効率的ではなさそうですね。
in the Overture buildings dataset alone the bbox columns occupy about 25 gigabytes. As a percentage of the whole dataset this is certainly worth the space to support selective reads; however, for local data with fewer attributes, this can approach 50% or more of the entire file!
Parquet の GEOMETRY 型
Parquet は、カラムの統計情報をメタデータとして持つことができます（必須ではない）。Parquet は列指向のデータ形式ですが、列に分かれる前にまず行を束ねた「row group」という単位で分割されています。以下が公式ウェブサイトに載っている図です。
（出典：https://parquet.apache.org/docs/file-format/）
統計情報は、この row group ごとの最大値や最小値などが記録されています。統計情報を使ってフィルタリングして、必要な row group だけを効率的に読むことができるというわけです。GEOMETRY 型の場合は、ここに bbox 情報が書かれます。これによって、GeoParquet v1.1 よりも効率的なフィルタリングが可能になっています。
bbox カラムは結局どうなるの？
ということは、Parquet の GEOMETRY 型があれば GeoParquet v1.1 で追加されたばかりの bbox カラムは不要になってしまうということなのでしょうか...？
答えは、どうやらイエスのようです。冒頭1つ目のブログ記事には以下のように書かれていて、GeoParquet v2.0 では仕様から外れる見込みです。
We’ll also take bbox out of the spec, since it’s main purpose was to provide stats to drive optimized spatial queries, and that’s not needed since Parquet will provide stats on geo types.
違い2: GEOMETRY 型に使えるフォーマット
GeoParquet v1.1 では WKB に加えて GeoArrow が使えるようになりました。一方、Parquet の GEOMETRY 型に使えるのは WKB のみです。この点はどうなるのでしょう？
結論としては GeoArrow は仕様から消えそうです。これも冒頭1つ目のブログ記事からの引用です。
We’d drop support for the Arrow geometry type, as having a native geo parquet geometry achieves one of the main goals behind the arrow geometry, which was native stats and not needing the bbox column.
どうやら、GeoArrow は統計情報を使えるようにするのがモチベーションだったようです。補足すると、GeoArrow は特殊なバイナリフォーマットではなく、Struct<x: double, y: double> のような構造体で、Parquet のネイティブの型で表現できるものです。そういうものなので、統計情報を追加しやすいだろうと考えたようです。しかし、もう GEOMETRY 型で統計情報を使えるようになったなら必要ないよね、と。
個人的には、この方向性は少し残念です。WKB は、データサイズの面では優れていますが、デコードしてからでないと読めないので、その分のオーバーヘッドが気になります。GeoArrow でなくてもいいのですが、DuckDB-spatial の人の提案みたいな、ゼロコピーで扱えるデータフォーマットにいずれ置き換わってほしいな...、と思っています（が、ここまで WKB 一択の状況になってしまっては難しそう。。）。
違い3: primary_column メタデータ
これまでの2つは、Parquet の GEOMETRY 型が GeoParquet の上位版になっている例でしたが、この点は GeoParquet にしかないものです。
GeoParquet には primary_column というメタデータがあります。これは、地物のカラムが複数ある場合に、どのカラムをデフォルトで使うか、というのを指示するためのものです。これは Parquet の仕様には特に定義されていません。
といっても、定義されていないだけで、ファイルには任意のメタデータを追加できるので、これまで通り primary_column を追加することになんら問題はありません。ただ、GeoParquet では「仕様」だったものが、「コミュニティの慣習」に格下げになる、というだけの話です。
まとめ
まだ理解しきれていない点も多いですが、冒頭のブログ記事が出てくれたおかげでかなり見通しがつくようになりました。GeoParquet v2.0 の議論を進める中でいろいろ変わってくることもあるとは思うので、これからもウォッチしていきたいです。
Discussion