Repro Tech Meetup で「Repro における Presto の安定化・パフォーマンス改善の歩み」を発表しました
Repro Tech: 実践・並列分散処理基盤の自社枠として、自分が Repro に入社してから Presto 関連で行った改善について発表しました。
なお、当日の発表資料は https://repro-tech.connpass.com/event/131612/presentation/ にまとまっています。
Presto 関連で他にやったこと
タイトルに「歩み」と書いたものだから、事細かに色んな話をしたかったんですが、1 時間以上かかりそうだったんでだいぶ削りました。
例えば他には以下のような問題の調査や解消を行いました。詳細を聞きたい方はご飯にでも誘ってください。
- EC2 インスタンスに独自のホスト名を割り当てるようにしたら EMR のクラスタの起動に失敗することが増えた話
- Presto Query は Failed になっているのに Presto Client では正常終了したように見えていて困った話
row_number()
の代わりにrank()
を使って高速化した話- https://github.com/prestodb/presto/pull/9686 がマージされる前の話なので今だと
row_number()
も速いかも
- https://github.com/prestodb/presto/pull/9686 がマージされる前の話なので今だと
- 無駄な window 関数を削って高速化した話
- Presto 経由で Hive テーブルの存在するはずのパーティションに対して drop partition しても
NoSuchObjectException
で失敗することがある話- Hive metastore にリクエストを投げて timeout すると Presto 側でリトライするが、1 回目のリクエストが通っているものだから 2 回目のリクエストで
NoSuchObjectException
が返っていた
- Hive metastore にリクエストを投げて timeout すると Presto 側でリトライするが、1 回目のリクエストが通っているものだから 2 回目のリクエストで
- 時刻情報が string (e.g.
"2019-01-25 07:46:24 UTC"
) で保存されているテーブルに対して timestamp への cast をなくすだけで数倍速くなった話CAST(time AS TIMESTAMP) >= timestamp '2019-06-12-09:19:00'
みたいなのをSUBSTR(time, 1, 19) >= '2019-06-12-09:19:00'
みたいにした- 時刻情報を timestamp で保存する別テーブルに移行することで更に数倍速くなった
- Hive on Tez で “Container is running beyond physical memory limits.” に悩まされた話
- Parquet の圧縮に Snappy を使うと起こるエラーらしい
- 詳細は Hive on Tez で Parquet を Snappy で圧縮すると起きる Container is running beyond physical memory limits. を解消する - あらびき日記