Apache Arrowとは｜1項目だけ読むと触る量が3.0倍違い、全項目なら1.0倍になった

1項目だけ読むと触る量が3.0倍違い、全項目なら1.0倍になる

使う項目の数で差が決まります。全部使えば、並べ方の違いは消えます。

Apache Arrowの中心にあるのは、手元での並べ方です。公式はApache Arrowの重要な構成要素は、手元で使う列ごとの形式であり、表のような構造を持つデータ集合を手元で表すための、標準化された、言語に依らない仕様であると述べています。

列ごとに並んでいると、使う項目だけを連続して読めます。どれだけ違うかを数えました。

読む項目の数を変える

20万件・1件12バイト、合わせて2.3MBです。そこから一部の項目だけを読みます。

注文の記録 200,000件。行ごとに並べると1件 12バイト・合計 2.3MB
一部の項目だけを読むとき、実際に触る量を比べる

読む項目            行ごと（触る量）  列ごと（触る量）  比
金額だけ                           2.3MB             0.8MB    3.0倍
金額と日                           2.3MB             1.1MB    2.0倍
分類と金額と日                        2.3MB             1.3MB    1.7倍
全部                             2.3MB             2.3MB    1.0倍

金額だけなら3.0倍の差です。行ごとの側は、どの行でも2.3MBのまま変わりません。

全部を読むと1.0倍です。並べ方の違いが結果に出なくなります。

連続していることの効き目

公式は量以外の効果も挙げています。とりわけ、連続した列ごとの配置は、現代の処理装置に含まれる最新の一命令多数データの操作を使ったまとめ処理を可能にするという記述です。

同じ種類の値が並んでいれば、まとめて処理できます。飛び飛びに置かれていると、この形が取れません。

ただし量の比がそのまま時間の比になるとは限りません。その点はClickHouseの記事で測っていて、手元に載る規模では時間差が1.1倍にとどまりました。

系をまたぐたびの詰め直しをなくす

同じ形を使っていれば、渡すときに組み替えません。またぐ回数が多いほど効きます。

Apache Arrowが解こうとしている問題を、公式は1文で示しています。ひとつの系から別の系へデータを移すことには、費用のかかる直列化と復元が伴うという記述です。

この費用はまたぐ回数だけかかります。3つの道具を通すなら、3回組み替えます。

詰め直しの重さ

詰め直しにどれだけかかるかは、Avroの記事で測った差が目安になります。

名前つきの文字から読み直す場合、金額の合計を出すのに50.9msかかりました。決まった位置から読むだけなら0.4msです。

つまり1回またぐごとに、この差が積み上がります。形を揃えれば、この分がなくなります。

効いてくる場面

1. 言語をまたぐ。別の言語の道具へ渡す
2. 処理をつなぐ。読み取り、変換、集計を別の道具で行う
3. 同じ機械の中で渡す。書き出して読み直す必要がなくなる
4. 1つの道具で完結する。またがないので効かない

4番目は効きません。またぐ回数が0なら、詰め直しも0だからです。

だから判断の材料はまたぐ回数です。1つの道具で完結しているなら、揃える利点は薄くなります。

1件ずつ扱う処理には向かない

列ごとに並んでいるので、1件の全項目を集めるには項目の数だけ場所を訪ねます。

Apache Arrowの位置づけは、公式によれば大きなデータ集合を処理し運ぶ、性能の高いアプリケーションを組み立てるための、複数の言語にまたがる道具箱です。

「大きなデータ集合」が前提です。1件ずつ扱う場面は想定の外になります。

向かない使い方

1. 1件の詳細を表示する。項目の数だけ場所を訪ねる
2. 1件ずつ足していく。列ごとに書きに行く
3. 1件だけ書き換える。並びを保つ作業が要る
4. 件数が少ない。揃える手間が上回る

前の計測の「全部」の行がこれにあたります。比は1.0倍で、利点がありません。

実際には1.0倍より不利になります。5箇所を訪ねる手間が加わるためです。

使い分け

取引の記録は行ごと、分析は列ごと、という分け方が実際的です。同じデータを両方の形で持つことになります。

その場合、置き場所は2つになります。読む量が3.0分の1になっても、保管する量は2倍です。

この釣り合いはETLの記事で扱った、置き場所と作り直しの比較と同じ形になります。