Skip to content

Instantly share code, notes, and snippets.

@descico

descico/presto-code-split.md

Last active August 13, 2017 01:50
Show Gist options
  • Save descico/ee7a52732cee2e1dbd15 to your computer and use it in GitHub Desktop.
Save descico/ee7a52732cee2e1dbd15 to your computer and use it in GitHub Desktop.
Download ZIP
Presto の話。ただし最近ほとんど触っていなかったので情報は古いので注意せよ。
Raw
presto-code-split.md

Split を worker Node に割り当てる処理について

  • やっているのは NodeScheduler のcomputeAssignments のようだ。
  • locationAwareScheduling と isRemotelyAccessible() によって処理は分岐する、と考えておいて良い
  • ここでしばしば紹介される minCandidates パラメータが登場する。コードを読む限り、これ、「Split を処理する Node の候補をいくつ選ぶか」というだけであるっぽい。
  • 少なくとも minCandidates の数だけ Node を選び、その中から現在持っているタスクが少ない Node を選んでいるのである。
  • だから、 minCandidates は別に並列度とは関係ないわけで、結果的にパフォーマンスに寄与するかどうかは微妙な感じもある。
  • "max number of workers to run a stage in parallel (default: 10) " という説明は誤りなのではないか、という話。
  • この minCandidates が node-scheduler.min-candidates であることも確認済みである。
  • 指摘もあったが誰も反応していない https://groups.google.com/forum/#!msg/presto-users/Ft71bkwElkQ/v85ROXC82hIJ
  • これが Hive Connector を使うときの肝で、このパラメータを HDFS のレプリカ数にしておけば、「できる限りローカルからデータを取る」ということができる。
Raw
presto-gui.md

GUI ツール

Hue + Prestogres

  • 上に書いたとおりで、 Prestogres 経由で Presto にアクセス。使えることは確認済み。
  • Hue のチューニング次第か。

shib

  • https://github.com/tagomoris/shib
  • 直接確認したが、あくまで、クエリの実行と結果の取得のためで、 Presto クラスタの状況のモニタリングとかのためではない。
  • 開発言語・実行環境は JavaScript + Node.js

Airpal

  • https://github.com/airbnb/airpal
  • 開発言語等は Java + DropWizard + Apache Shiro
  • DropWizard はウェブアプリケーションフレームワークである。個人的にとても興味があるが、まだ使ったことがない。
  • Apache Shiro は authentication/authorization のフレームワークである。LDAP も使えるようだ。
  • ただしこれも、クエリの実行と結果の取得のためであり、 Presto クラスタのモニタリングとかはできないようだ。

presto-console

  • https://github.com/sanjuusan/presto-console
  • 俺が書いた。
  • こんなものすごいオフィシャルっぽい名前はやめたいけど、いい名前が考えられない。
  • どうせクエリの実行と結果の取得は Hue などがあるわけだし、ということで、そういう機能はない。
  • サーバとクエリの一覧を出すだけである。クエリの中止もできる。

GUI ツールの比較

name URL クエリ実行 クエリキャンセル クエリ状況確認 ノード状況確認 結果ダウンロード その他情報 認証機構 認可機構
純正ツール https://github.com/facebook/presto/tree/master/presto-main/src/main/resources/webapp × ◯ ◯ ◯ × REST API と同じポートで / にアクセスすれば良い × ？
Airpal https://github.com/airbnb/airpal ◯ ？ ◯ ？ △ CSV での結果ダウンロードに S3 を使うらしい Apache Shiro ？
Shib https://github.com/tagomoris/shib ◯ ◯ ◯ × ◯ TSV, CSV でダウンロードできる。 ◯（※1） ◯（※2）
yanagishima https://github.com/wyukawa/yanagishima ◯ ？ ？ ？ ？ see also http://d.hatena.ne.jp/wyukawa/20150427/1430133743 なし ×
- https://github.com/sanjuusan/presto-console × ◯ ◯ ◯ × 自作 × ×
Hue ◯ × × × × Prestogres 経由で使う ◯ ×
Raw
presto-hiveconnector.md

Hive Connector 関係

同梱されている hive-apache-X.Y.jar のバージョン

  • 0.104 までは 0.13 だったが、 0.105 以降は 0.14 になっている。
  • このバージョンが Hive のバージョンと対応しているのか知らないが、恐らく、対応しているのであろう。
  • これが関係しているかはわからないが、 Hive 0.13 を使っている環境で Presto 0.115 を動かしたところ、 Hive テーブルと対応づいている SymlinkText の中身のパスが hdfs ではなく file で解釈され、結果、クエリが失敗した。

トラブルシューティング

LzoCodec が見つからない

  • LzoCodec が見つからない、と言われる話もある prestodb/presto#856
  • ということで plugins/hive-hadoop2 の下に hadoop-lzo の jar をコピーするなどしたらとりあえずこれは解決した
  • が、 select の結果で値が全部 NULL で表示されている、という問題が出ている
  • ↑これ、単に create table の仕方が悪かっただけだった。デフォルトは列デリミタがない、という話。

クエリを実行するも HIVE_CURSOR_ERROR と言われる

  • いろいろ原因はあるのかもしれないが、今のところ明確にわかっているのは、対象のファイルが bzip2 だと HIVE_CURSOR_ERROR と言われる。
  • ごくまれにクエリが成功しているっぽいケースもあるが、基本的には失敗する。
  • bzip2 について、ここでは "Inconsistent restults" になる、という話があがっている。 https://groups.google.com/forum/#!searchin/presto-users/bz2/presto-users/GVdMQwVEgCM/3oG0ImQYZ4YJ
    • Sundstorm さんは "We don't actively support bz2 since it is not a very good compression algorithm" とも言っている。
    • Presto で bzip2 が動かないことの言い訳というわけではないが、 Presto が CPU がボトルネックになるということを考えると CPU をとてもたくさん使う bzip2 は Presto 向きではない、と言っている。
      • "You are trading off a small amount of disk space for 5-10x increase in CPU usage. Since Presto is typically CPU bound, this is a particularly poor choice for presto."
      • "That said, there is no reason Presto shouldn't work with BZ2 compression."
    • と思ったが、また別のやりとりでは... https://groups.google.com/forum/#!searchin/presto-users/bz2/presto-users/dXqfDIkrWbY/zMfO6kESTEcJ
      • サンドストームさんが "Quick note on BZ2. Presto doesn't support bz2." と言っている。

HiveConnector だと insert できない

  • これは Hive そのものでもいろいろ制約があるはずなので、仕方なさそう。
  • https://groups.google.com/forum/#!searchin/presto-users/hive$20insert/presto-users/gCIK_RavqFc/JHcCApTsM7QJ
  • CREATE TABLE AS は使えるらしいので、それで済む要件ならば、良い...と思ったが、 CREATE TABLE 自体、 HiveConnector でできないのでは。
  • Hive の CREATE TABLE は標準的な SQL とは違うので、それこそ無理な気はするが...
  • と思ったが、実際に試したり、コードを見てみた感じ、 CREATE TABLE AS はできるっぽい。どういうことなんだこれは。。。

authorization の話

  • 結局 HiveSplitManager#getPartitionSplits をどうにかすればいいっぽい。
  • で、あとは、クエリを投げたユーザーが誰なのか、というのを取り出せれば良い。が、取り出せそうな気配がない。
  • issue これ prestodb/presto#2957 対応される気配がない。
  • なお、基本的には worker を動かしているユーザーで HDFS にアクセスに行くようだ。 HDFS 側で group の制御をうまくできている場合、「とにかくアクセスできるようにする」ならば、 worker を動かすユーザーを適宜グループに属させるなどでコントロールすることもできよう。
Raw
presto-parameters.md

Presto そのもののパラメータ

task.shard.max-threads

  • https://groups.google.com/forum/#!msg/presto-users/7aJ68pn0_oI/mzntBKvNeL4J
  • "The default number of threads per box will be 4x the number of cores on your machine, but this is configurable with the option "task.shard.max-threads"." とのこと
  • http://d.hatena.ne.jp/wyukawa/20140719/1405775230 にも同様の記述がある
  • 確かにソースコードに "private int maxShardProcessorThreads = Runtime.getRuntime().availableProcessors() * 4;" という記述がある
  • https://github.com/facebook/presto/blob/master/presto-main/src/main/java/com/facebook/presto/execution/TaskManagerConfig.java
  • これ、性質的には「より性能を引き出すための設定」というよりは「性能を抑えるための設定」なのではないだろうか。特に DataNode や NodeManager と共存させようとなった場合には、これで抑えてやらないとすぐに負荷が上がり過ぎてしまいそうである。
  • このパラメータである程度抑えるか、あるいは、 cgroups で CPU Affinity を指定するか、という話だろう。というか、 CPU Affinity を設定している場合、実際、どうでもよいような気もする。
  • 結局のところ、たくさんジョブを並走させたとき、このパラメータが大きければ結果としてスループットも下がるだろうと考えられる。つまり、このパラメータとマシンパワーと実行速度のバランスをよく考えろ、という話になるのだろう。
  • もう少し書くと、マシンのパワーあるいは cgroups による制限がハードリミットであり、次のこのパラメータでの絞り込みになる、という話だろうと。

query.initial-hash-partitions

node.data-dir

  • これを設定しておくと、 Presto を起動した際に、このディレクトリに以下をつくる
  • Presto のインストールディレクトリの etc への symlink
  • Presto のインストールディレクトリの plugin への symlink
  • var ディレクトリ。そのなかに log, run がある。
  • 設定していない場合、これはつくらずインストールディレクトリのを利用するようだ。
  • ログが書き出される場所になるので、それをわけたければ便利だろうが、 etc, plugin への symlink は本当に必要なのだろうか？

task.max-memory

  • この値が JOIN できるテーブルの大きさの閾値になるような感覚の値である。
  • なお、 -Xmx < task.max-memory の場合は、単にジョブが失敗するようだ。

query.max-history

  • てっきり、 coordinator で保存するクエリの履歴の数かと思ったら、そうでもないっぽい
  • あるいは query.max-age との兼ね合いなのかもしれない。詳しくは見ていない。
  • こういうのはコード読んだほうが早そう...
  • CLI のヒストリの数でもないようだ

query.max-concurrent-queries

  • 文字通りっぽい
  • これを 1 に設定し、何かクエリを走らせ、完了する前にもうひとつ実行すると、待たされる。最初のクエリが完了すると、2つめが動き出す。
  • 待たされている時の state は QUEUED である。
  • なおこれは、 airlift の AsyncSemaphore のパラメータとして使っており、つまり、並列数制御は Presto 側ではなくあくまで airlift に任せているようだ。

query.max-queued-queries

  • 1 以上にしないとダメっぽい。0 にするとそもそも worker が起動しない。
  • この値を 1 にして、1つクエリを実行し、終わるまでにもう1つ実行しようとすると Too many queued queries! と言われる。

discovery.uri

  • 末尾に / （スラッシュ）がつくとダメのようだ。
Raw
presto-restapi.md

REST API

curl -H "X-Presto-Schema:default" -H "X-Presto-Catalog:hive" -H "X-Presto-User:bob" -d "select count(*) from users" http://presto-coordinator:8080/v1/statement
  • 以下の手順で使うことになる
  1. クエリを /v1/statement に POST する
  2. レスポンスの nextUri を見る。終わっていればここに結果が入る。
  3. 2.のレスポンスの nextUri を見る。これをやると 1. の nextUri は見れなくなる。

REST API 一覧（"@Path" で検索した結果）

name method 内容
/v1/execute POST クエリの実行
/v1/node GET ノード一覧
/v1/node/failed GET コケてるノード一覧？
/v1/query-execution/{queryId} GET クエリの実行状況
/ui/query-execution?{queryId} GET これはブラウザで見る用のクエリ実行状況。緑ノードが実行中、青ノードが完了。かっこいいけど微妙かもしれぬ。
/v1/query GET 実行したクエリの一覧。何件まで出してるかわからん。
/v1/query/{queryId} GET クエリの情報取得
/v1/query POST クエリの実行
/v1/query/{queryId} DELETE クエリのキャンセル
/v1/query/stage/{stageId} DELETE ステージのキャンセル。ステージは1つ以上のタスクを持つ。また、ステージは0個以上のステージを持つ。ステージの親玉は outputStage であり、これはクエリと 1:1 対応である。
/v1/stage/{stageId} DELETE ステージのキャンセル
/v1/statement POST クエリの実行
/v1/statement/{queryId}/{token} GET クエリの実行状況
/v1/statement/{queryId}/{token} DELETE クエリのキャンセル
/v1/task GET 全タスク情報取得。タスクとは、実際に各 worker が処理する単位である。
/v1/task/{taskId} POST タスク生成？
/v1/task/{taskId} GET タスク情報取得
/v1/task/{taskId} DELETE タスクのキャンセル
/v1/task/{taskId}/results/{outputId}/{token} GET タスクの結果確認？
/v1/task/{taskId}/results/{outputId} DELETE タスクの削除？中断？
/v1/thread GET 動いているスレッドの状況。
/ui/thread GET 動いているスレッドの状況を可視化したもの
/v1/jmx/mbean GET JMX の MBean の値全部。よって、かなりでかいレスポンス。これは Presto そのものではなく、 airlift で実装しているもの（jmx-http/src/main/java/io/airlift/jmx/MBeanResource.java）
/v1/service/presto GET ノード情報。/v1/node よりわかりやすい
Raw
presto-treasuredata.md

TreasureData の場合

  • クエリ失敗時に自動的にリトライするように手が入っている
  • ストレージが S3 上の MPC(MessagePack Columnar)である。MPCは高速化の一因となっている。
  • 高速化については、まじめなパフォーマンスチューニングをやっている。以下に例を示す。
  • YourKit https://www.yourkit.com/ でまじめにプロファイリングはしている。もちろん前提知識も多いだろうが。
  • sun.misc.Unsafe パッケージを使い、 TypeProfile を生成しないように reflection でなんとかする、みたいなことをやっている。
  • ルックアップテーブルを static イニシャライザでつくって、というようなこともやっている。
  • GC は G1GC を使っている。これやらないと、ヒープ使用量がギザギザで、ピークのときに重いのがくるとヤバイ、とのこと。
  • Presto の設定自体は、わりとふつうにやっている。もちろん min-candidates や initial-hash-partitions などは調整しているが。
  • ASM http://asm.ow2.org/ を使って、バイトコードを操作して、というようなこともやっている。
  • 実行速度が担保できるようなチューニングをしているようだ。
  • coordinator はやはり SPOF であるが、彼らの場合、ストレージクラスタと処理クラスタが別であり、処理クラスタをクラスタごと切り替える、という運用方針なので、 coordinator もそれに従っている。つまり、 coordinator 自体が冗長構成を取れるように手を加えていたりはしない。
Raw
presto.md

Presto の話

概要など

  • http://prestodb.io/overview.html ここを読めという感じである。
  • とにかくお手軽に使えそうな感じがある
  • "Presto compiles queries to bytecode at runtime and thus produces many classes, so we enable class unloading." とのこと

Java のバージョンの話

Hadoop での利用

  • "Presto supports reading Hive data from the following versions of Hadoop:" とあるぐらいで Hadoop がらみは Hive が前提らしい。
  • ファイルフォーマットとしては、 "The following file formats are supported: Text, SequenceFile, RCFile, ORC" とのこと。
    • ここで ORC が出てくるのである。Parquet はでてこないのか。
  • Hive の場合 Hive Metastore を使うとのこと。HMS を使わないという手はないようだ。
  • Hive コネクタの場合は insert できないとのこと
  • http://stackoverflow.com/questions/27291013/prestodb-insert-fails-with-null-error-message
  • テーブルも作れない、とオフィシャルには書いてあるが、できてるっぽい事案がある。
  • https://groups.google.com/forum/#!searchin/presto-users/permission/presto-users/nzaDMXP7AxA/Aq8vrb-kJoMJ
  • HDFS 読み込みについて short circuit read には対応していないらしい。
  • が、一方で、 short circuit read も良し悪しっぽいので、まあいいか、とも思うが、 Presto の場合、悪しの面が出るかどうか謎い
  • 悪し、というのは、 DataNode を経由しないことで、かえって柔軟性が落ちるケースがある、という話である。ディスク故障のときとか。
  • HiveConnector による HDFS へのアクセスはあくまで、 worker の起動に利用したユーザーが使われるようだ。なので、仮に worker を bob で起動し、 client を alice で起動していたとしても、 HDFS へのアクセスは bob によるものなので、 bob が見られるファイルにしかアクセスできない。

その他のストレージの話

  • Cassandra もストレージとして利用できるようだ。

他のツールにあるけど Presto にはない機能、機構や欠点

  • 調べたところ、 2015-01-15 現在（つまり、 0.89 時点）、クエリキャッシュもリザルトキャッシュもない
  • もちろん HDFS 側で OS のキャッシュに乗る、とかはあるのだろうが。
  • そもそも、 Presto が処理するデータのボリュームと、用途を考えると、クエリキャッシュはいいとしてもリザルトキャッシュは不要だろうし、クエリキャッシュも、ひょっとしたら「全体から見たら微々たるもの」かもしれない。
  • そういう話題はあった https://groups.google.com/forum/#!topic/presto-users/CzB1kv_3dR8
  • 2015-08 ごろに確認した情報では、クエリキャッシュはあるらしい。
  • やっぱり coordinator は SPOF
  • FULL OUTER JOIN は version 0.89 現在、サポートされていない
  • worker を graceful に落とす方法がいまのところないっぽい
  • パッチは書かれている https://groups.google.com/forum/#!searchin/presto-users/presto$20permission/presto-users/cmhx6HzJwFU/P-h7t0Mb9kcJ
  • Non-equi joins not supported である。
  • GROUP BY している場合、 select にあるキーは GROUP BY にもないとダメっぽい。
  • つまり select foo, bar, count(*) のとき group by には foo, bar いずれも存在しないとダメっぽい。
  • 全般的に、型のチェックは Hive に比べれば厳密のようである。
  • どうやら Hive の場合は、型推論をしているようなところがある。シングルクォートで囲んだ数値を bigint として扱っているケースがある。
  • 0.100 現在、まだ、 Hive テーブルでの decimal 型は使えない
  • https://groups.google.com/forum/#!msg/presto-users/ROnD-M-7sNU/diewbOIYDlsJ

挙動の特徴

Prestogres

Prestgres を利用して Hue から Presto にアクセスする

セットアップの手順の評価

  • オフィシャルドキュメント http://prestodb.io/docs/current/installation/deployment.html に従うだけで良い。
  • 唯一の注意点は上にも書いているが Java8 の bin を環境変数 PATH に入れること、というぐらい。
  • あとは、 Hadoop にも言えることだが、 ulimit -n の値つまり open files の値を増やしておけ、というぐらいであろうか。

data locality ローカリティ の話

  • https://groups.google.com/forum/#!topic/presto-users/DDomQMbuJ98
  • prestodb/presto#894
  • prestodb/presto#1770
  • hive.force-local-scheduling=true にして、全ノード（coordinator も worker も）再起動すれば良い
  • ひょっとしたら coordinator だけでよかったかもしれない。少なくとも worker だけ再起動した場合は反映されなかった。
  • ただし、このパラメータ、本当に "force" のようで、 worker が動いているノードにブロックが存在しない場合は、 "No nodes available to run query" になるようだ。
  • ソースコードを追っていくと、 forcelocalscheduling という文字列でなく、 remotelyaccessible という文字列で検索することになる。読めばわかる。
  • NodeScheduler#computeAssignments や selectCandidateNodes で見ている
  • remotelyAccessible の否定は、確かに forceLocalScheduling であるな。そういうこともあるから、 forceLocalScheduling でないときでも、なるべくローカルを優先させる、という実装にしたいのだが、現在は、そういうケースでも selectRandomNodes を呼び出している

利用リソースの制限

  • cgroups を使えば良い。
  • ネットワークの帯域制限のためには、これに加えて tc を使うことになる。
  • see also https://gist.github.com/sanjuusan/6791c7c3045ad5848552
  • cgroups の適用に際しては、 launcher のプロセスIDだけを tasks に書き出すだけではダメである。実際には大量のスレッドが生成されており、 Linux だとそれもまたプロセスIDが振られているためである。
  • ps コマンドで -T オプションをつけて実行してみるとわかる。
  • 正確には、 launcher を起動し、そこからスレッドが生成される前に tasks に追加していれば、そのスレッドは自動的に tasks に登録されるはずである。
  • この事象を回避するのは簡単で、 libcgroup パッケージをインストールし、それに含まれる cgexec を利用して launcher を起動すれば良い、というだけである。
  • libcgroup 自体は cgroups を利用する上で必須ではないが、上記のようなケースがあると、実質的には必須と言える。
  • ただし、ネットワークに関しては、 Hive Connector では、結局、 DataNode からの pull によるネットワーク利用がメインになるため、 tc は意味はない（tc は送るときの帯域を絞るだけ）。この問題は、帯域を絞るという話ではなく、ローカリティの考慮で解決すればよい。ただし、これをやる場合、すべての DataNode のサーバで worker も動かす必要があるだろう。
  • 他にリソースの制限方法として worker のスレッド数を "task.shard.max-threads" で絞るというのもあるのだろうが、 cgroups が使えるなら、それに越したことはないだろう。

see also

負荷を気にしないといけない環境での導入の手順 HiveConnector のみ利用する場合

HiveConnector のための準備

  • HiveMetaStore を動かす。

リソース制限系の準備（cgroups, tc）

  • libcgroup を入れる。cgexec を使って launcher を起動するため。
  • chkconfig cgconfig on しておく
  • /etc/cgconfig.conf に presto 用の設定を追加しばらまき、 service cgconfig restart する。
  • iperf を入れる。worker の実行自体には関係はないが、 cgroups net_cls + tc による帯域制限を確認するために
  • tc による設定を各サーバで実行する
  • 念のため iperf で設定のとおりの帯域制限ができているか確認する

Presto 本体

  • Presto の公式サイトにあるセットアップ手順をこなす。設定ファイルも用意する。
  • hadoop-lzo の jar を plugin/hive-hadoop2 にコピーする
  • 展開した presto のディレクトリを worker を動かすサーバにばらまく
  • なお、 node.properties と config.properties はそれぞれノードごと・役割毎に異なるだろうから、 symlink で対処するのがよいだろう。
  • deploy 用のスクリプトで symlink を適切につくれば良い。
  • worker を動かすサーバで node.data_dir に指定したディレクトリをつくる
  • もちろん Hadoop 関係のファイルもばらまいておく。というか、 DataNode が動いている場合は不要のはずではある。
  • /etc/security/limits.d/presto.conf をつくる。実際はファイル名は任意。nofile, nproc をデカくする設定を仕込んでおく。そしてばらまく。
  • PATH に Java8 の bin を通してから launcher を cgexec で起動する
  • 上に書いてあるが、 Presto は JAVA_HOME は見ない。PATH しか見ない。

設定できるパラメータ名の調べ方

  • ソースコードを "@Config(" で grep すれば良い

Error: Constraint violation with property prefix '': environment is malformed (for class io.airlift.node.NodeConfig)

OS 側の設定

limits

  • /etc/security/limits.conf や limits.d 以下のファイルで設定するアレである。
  • Presto もそれなりに使うようであり、また Presto を動かすノードでは DataNode も動かしていることを考えると、結局、 presto ユーザーでもつくり、それに対して設定するのが良さそうである。

Hive との function の違い

function 違い
from_unixtime Presto では返り値は timestamp であり、直接 substr にかけられない。Hive では string を返す。
datediff/date_diff Hive の datediff は「日」の差を取るだけ。 Presto の date_diff は差をとる単位を第一引数で指定できる。
substring/substr Presto には substring はない。 substr はあるし、使い方も同じ。
= など各種比較演算子 Presto は Hive と違って比較の際に型が不一致だととにかくエラーにするので、 cast する必要がある。

Presto におけるアクセスコントロール

（調べている）

deserializer does not exist

メトリクスの取得

  • Java なので JMX でとるが、ぱっと見たところでは、生の JMX でのアクセスするためのポート番号などがわからない。
  • しかし Presto の場合 JMX Connector があり、それを使えば SQL で JMX の情報を取り出すことができる。
  • これはつまり Presto によって Presto の JMX を取り出すような話である。
  • もちろん、 REST API でも JMX Connector を指定すれば、取り出すことができる。
  • それ以外に https://github.com/xerial/presto-metrics このようなツールもある。
  • これのコードを少し読む限り、ストレートに REST API で JMX にアクセスできるっぽい https://github.com/xerial/presto-metrics/blob/master/lib/presto/metrics/client.rb

information schema っぽいテーブル

presto:default> show tables from sys;
  Table
---------
 catalog
 node
 query
 task
(4 rows)

ORC

  • 以下のような構成の Presto クラスタで、以下のような特徴のファイルを、非圧縮、gzip、ORC(zlib)の3種用意し、あるキーで group by して count したときについて記す。
  • worker 数は約 100 。それぞれのスペックは明かさないが、最近のサーバで使うようなスペックを想像してもらえば良い。
  • ファイルは10列程度のタブ区切り（いわゆるTSV）
  • 全体で1300万行ぐらい、group by のキーのカーディナリティは4万ぐらい
  • 非圧縮でファイルサイズは6GB程度。gzip, ORC(zlib)はそれぞれ500MB程度、400MB程度、であった。
    • ORC は default で内部を zlib （gzip と同等だろう）で圧縮している
  • ORC は非圧縮の元々のブロック数の数だけファイル自体が分割されている。結果として、1ファイルあたり 10MB 程度であった。
  • クエリの実行時間は、非圧縮、 gzip はそれぞれ10秒程度だったが、 ORC については概ね1秒未満であった。
  • ということで、 Presto に限った話ではないだろうが、 ORC にするとより高速な集計が望めるケースは多いだろう。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment