Treasure Dataではfluentd, 各種SDK, Data Connectorなどで収集されたデータに対して、Hive, Prestoによる分散SQLクエリが実行できます。特にPrestoはこの1年で大きく進化しましたので、ここでその内容について紹介していきたいと思います。
Prestoクエリの利用量は増え続けていて、2015年12月現在、Treasure Dataの利用統計では、
- １日あたり5万クエリ (月換算で150万クエリ)
- １日あたり10兆 (10 trillion) レコード
を処理しています。2015年の始まりの時点では、1日あたりおよそ5000クエリ、1兆レコードという数字でしたので、この１年でほぼ10倍になった計算になります。昨年末のPrestoサービスの開始にあたり、CTOの太田と相談して10倍スケールできるように準備をしていたのですが、想定していたより早くこの規模になりました。今後も利用規模に応じてスケールアウトできるように対応していきます。
参考までに、Facebook社内では月数百万クエリ、数兆レコード/日を処理しているということなので、Treasure DataのPresto利用量は既にFacebookを超えており、現在世界一だと思われます。
Prestoの利用者
Treasure Dataのお客様では、US側ではWarner Bros Games, Pebble Smartwatchなど、日本ではGREE, クックパッド, リクルートライフスタイル/マーケティングパートナーズ、パイオニアなど、すでに100社以上の企業で積極的にPrestoを利用していただいております。
Prestoのインストールやクエリの実行そのものはさほど難しくありません。そのため、開発元のFacebook以外にもNetflix, Airbnb, Dropboxなど、既にデータを持っていてエンジニアリングリソースを運用に当てられる企業が積極的にPrestoを利用しています。
しかし、Prestoはクエリレイヤーでしかありませんので、データの収集、保管、クエリ結果の管理などは独自に行う必要があります。そのため日々Prestoを使って分析を続けるためには、
- データをロスなく集め続けるシステム
- クエリ高速化のためのコネクタ開発
- マシンのインフラ管理
- 障害、問題発生時などのトラブルシューティング
など、多くの開発・運用リソースが必要となります。Treasure Dataの強みは、データの収集から保管、解析、各種サービスへの出力機能などを一括して提供し、そのシステムを運用し続けているところにあります。
Prestoコミュニティ
Prestoは2013年末にFacebookがオープンソースとして公開して以来、Facebookのメンバー中心にGitHub上で開発が進められています。現在、Facebookには12人のエンジニアがPrestoの開発チームに所属しているようです。Treasure Dataも開発に貢献しており、これまでUDF機能の追加、各種関数の追加、様々なバグ修正を行ってきました。今年から、老舗のDBベンダーであるTeradataがオンプレミスクラスタを運用している顧客向けにPrestoのサポートを提供していく準備を進めており、20人近くのエンジニアをPresto関連の開発に投入しています。
Treasure DataもFacebookやTeradataのエンジニア達と密に交流しており、今後の開発ロードマップの議論に加わっています。Silicon Valley, Boston, 東京と時差が大きい箇所にいるエンジニア同士なので、Slackなども活用してコミュニケーションを取っていますが、Treasure DataのUSオフィスはFacebook本社のすぐ近くということもあり、直接議論しに行くこともあります。
今年の11月には、TeradataのオフィスのあるBostonでもPresto Meetupが開かれました。
Prestoの進化
2015年のPrestoのバージョンは0.90から0.128(2015年12月現在）まで上がりました。Treasure Dataでは最新版の0.128を提供しており、最新の機能をほぼ遅延なく提供できています。
この1年の大きな変更としては、
- クエリ性能の劇的な改善
- レコード単位の処理から、ページ単位での処理への切り替えによる高速化
- ノード内のタスク処理のマルチスレッド化
- 巨大クエリへのリソース割り当ての効率化 (phased exeuction)
- UTF8のサポート
- 日本語を標準で扱えるようになりました。
- normalize関数（半角カナ、①などを1というNFKC形式で正規化し、特殊文字を含んだ文字列の比較がしやすくなります）もLivesenseとTreasure Dataの協力により実現しました。
- クラスタリソースマネージャー
- サブタスクごとではなく、クエリごとのメモリ使用量管理に切り替わり、大きなデータを扱うクエリを実行しやすくなりました。
などがありました。Treasure DataのPresto利用者向けには、td-prestoコネクタを実装しており、
- マシンリソースの増強によるクエリ性能の改善
- クエリの待ち時間の低減
- INSERT INTO/CREATE TABLE AS によるテーブル作成の高速化、1-hourパーティショニングの実現
- クエリのリトライ機能の強化
- TD_CURERNCY_CONV （通貨レートの変換), TD_IP_TO_CONTRY_CODE/NAME (IPアドレスから国名を検索), TD_LAT_LONG_TO_COUNTRY(緯度経度情報から国名を導出する)などのUDFを追加
- サポートによる、クエリの修正や、より速いクエリへの書き換えの提案
などを行ってきました。この間、SQLというインターフェースには大きな変更がないものの、Presto内部のSPIや実装に大幅な変更が何度もあり、コネクタを独自に実装している方は最新版に追従するのが大変だったのではないかと思われます。
Prestoの信頼性
HiveはSQLをMapReduceプログラムに置き換え、各ステージごと中間データをディスクに保存することで耐障害性を上げています。一方、Prestoは「Hiveより速くする」ことを目的として設計されており、ディスクを一切使わずに、クエリの各ステージ間でネットワーク越しにデータを転送しながら処理を進めます。そのため、理論的に耐障害性はHiveより劣りますが、実際には99.5%のクエリがエラーなしで成功しており、Treasure Dataが独自に実装したクエリのリトライ処理により、ネットワークやマシンの障害があった場合でも、最終的に99.999%のクエリが成功しています。 この数値を100%に近づけ、サービスの安定性を向上させることが今後の目標でもあります。
Prestoクエリの処方箋
1秒間に数百万ものレコードを簡単に処理できてしまうPrestoですが、そのためにかえって効率の悪いクエリを書いて処理が数分〜数十分かかってしまうことがあります。陥りやすい罠と、SQLの改善方法を以下にまとめましたので参考にしていただけると幸いです。
- Presto Query FAQs (英語)
またリブセンスの吉田様がPrestoクエリの書き方のコツについて非常に丁寧にまとめてくれています。こちらも併せてご覧ください。
Prestoの今後
来週にも2016年のPresto開発のロードマップを議論するミーティングがありますが、大きなものとしては以下が挙げられます：
- クエリオプティマイザの新フレームワーク
- コストベースのクエリ最適化を導入したい
- SQLを標準に近づける
- TCP-H, TPC-DSベンチマークをクエリの修正なしに動作させられるようにする
- presto raptorコネクタによる中間ストレージ
- ローカルディスクを用いて、クエリ結果のキャッシュ、高速化を行う
- Materialized Viewのサポート
- coordinatorからのクエリ結果出力の並列化
- Treasure Dataの場合はINSERT INTO/CREATE TABLE ASを使うことで結果の出力性能が改善されます
Treasure Dataとしては、さらなるクエリ性能の高速化はもちろん、UIの改良、システムの安定性、動作のわかりやすさなど、SQLを通して皆様がデータをより手軽に扱っていただけるよう開発を進めてまいりますので、今後ともよろしくお願い申し上げます。