BlogKLabは、多くのスマートフォン向けゲームを開発・提供しています。スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。KLab分析基盤チームの高田です。SDKのKPIレポートシステムを通じて、パートナー向けにシステムを提供しています。2016で発表されたばかりのAWSの新サービスAthenaを試してみました。KLabの分析基盤システムでは、すでにRedshiftやEMRを使用していますが、Athenaには、これらを補うような役割(低コストで導入し、アドホックな分析や定型的なレポートの作成をサポートするといった用途)を期待しています。Athenaとは?ひとことで言えば、Athenaとは、S3上に置いてあるデータを高速にSQLで集計・分析できるサービスです。内部はPrestoをベースとしつつ、独自の改修をくわえて使用しているようです。Serviceブログのこちらの記事も参考になるでしょう。AWSでは以前より、EMRというサービスでHadoopやPrestoの機能を提供していましたが、Athenaでは自前でクラスタを組む必要なしに、クエリ検索機能を使用できます。料金はクエリ量単位(5TBスキャンあたり$5)で設定されています。検索機能のみを提供するサービス形態や、課金形態はGoogleのBigQueryに似たものになっています。データの分散処理用のフレームワーク。Hadoop上で動くクエリエンジン。SQLベースの検索機能を提供。Hiveに似たクエリエンジン。Hadoop上でも動作するがそれ以外のデータソースも選択可能。AWS上でHadoop/Prestoなどの分散システムを提供するサービス。Presto相当の検索機能のみを提供。Amazonクエリ実行画面を試すでは早速クエリの実行を試してみましょう。いうデータベースが最初から作成されており、クエリの実行をすぐに試すことができます。新しいデータベースやテーブルの作成も、Web画面から実行できます。現実的なユースケースでパフォーマンスを見たいので、自前のデータも準備し、普段の分析業務で使用するようなクエリを投げてみます。KLabの分析基盤チームの場合、データの多くは、tsv形式でS3上に置かれています。これをそのまま検索対象にできれば理想的なのですが、残念ながら圧縮形式やディレクトリ構成の問題で、何も手をくわえずに検索対象にするということはできませんでした。※Athenaの検索対象にするためには、ディレクトリ構成に一定のルールが必要です。GZIPのみがサポートされているようです(FAQを参照)。今回は以下の三種類のデータを用意しました。数十MBそれぞれ、S3上の以下のようなパスにアップロードしておきます。Athena用にカラム名を除外し、gzip圧縮しましたが、それ以外はごく普通のtsv形式です。いうパスにアップロードします。それぞれ11月1日から12月5日までのデータをアップロードしてあります。いうパス名は、Athenaにパーティションを認識させるためのルールになります。この形式にのっとらない場合は、手動でパーティションを追加する必要があります。パスはテーブルごとにわける必要があります。s3://--bucket--/athena/dau/dt=2016-12-01/dau_2016-12-01.tsv.gzips3://--bucket--/athena/dau/dt=2016-12-02/dau_2016-12-02.tsv.gzip...s3://--bucket--/athena/install/dt=2016-12-01/install_2016-12-01.tsv.gzip...s3://--bucket--/athena/locale/dt=2016-12-01/locale_2016-12-01.tsv.gzipテーブル作成あとは、Athena上でテーブルを作成するだけで、上記のファイルを検索対象とすることができます。今回は以下のようなテーブルを作成します。TABLE文を実行するだけでも問題ありません。(日付)をパーティションに指定しました。パーティションに指定したカラムは、SQL上で疑似的なカラムとして扱われるため、テーブル本体には同名のカラムを含めることができません。いう名前を設定しておきます。TABLEを実行しても、しばらくの間、古い定義が参照されてしまうという問題がありました。's3://--athena--/athena/locale/'S3上のパーティションを認識させるには、各テーブルについて以下のクエリを実行します。dauパーティションが正常に認識されたかどうかは以下のクエリでパーティション一覧を表示することで確認できます。dau検索いくつかクエリを実行し、性能を見てみます。残念ながらデータそのものはお見せできないのですが、以下、参考のため、クエリと実行時間を掲載しておきます。SQLに準拠ということなので、ある程度は検討がつくのですが)。今回追加したファイルのうち、このlocaleのデータがもっとも巨大です。全体で1.45GBほどあるのですが、単純なCOUNTクエリであれば6秒ほどで返ってきました(スキャン自体は行なっているようです)。1.45GB)DAUを国別に集計してみます。これもlocaleのファイルが大きいためか、20秒ほどかかりました。45.54MB)インストールユーザーの3日後の継続率を集計してみます。3.65MB)3日連続でログインしているユーザー数を出してみます。Athenaが苦手なクエリなのか、スキャン量が少ない割に1分半もかかっています。24.86MB)こちらはサブクエリを使用するように書き変えることで大きく実行時間が変化しました。RedshiftやBigQueryと同じで、直接テーブルをJOINするのはあまり効率がよくないようです。参考のため、修正後のクエリも掲載しておきます。6.97MB)以上のように、いくつかクエリの書き方で気をつけるべき点があるようですが、基本的には十分実用的な性能です。データをカラムごとに格納するフォーマット)。Parquetへの変換方法として、公式ドキュメントで紹介されているHiveによる変換を試してみました(参照)。EMR上でHiveを立ち上げ、S3上のテーブルを読み込ませ、Hive上でテーブルをParquet形式に変換します。以下のようなSQL(HiveQL)スクリプトを用意し、S3上に保存します(DAU以外のテーブルは省略してあります)。残念ながらParquet形式はDATE型に対応していないため、ここでは文字列に変換しています。設定が必要となります。'2016-12-05';awscliを利用し、Hiveを立ち上げて実行させます。--auto-terminateジョブの実行には1時間程度かかりました。ジョブの完了後S3を見ると、確かにファイルが作られています。TABLEを実行し、作成されたParquetファイルを認識させます。p_dauParquet形式の場合、単純なカウントは、ファイルスキャンの必要がなくなるようです。0KB)ただし試した範囲では、スキャン量が増えてしまうこともありました。実行時間もものによっては改善しましたが、大きな変化が見られないケースが多いようです。以下、実行結果の比較をまとめておきます。24.39MBまとめAthenaを使用し、データ分析基盤で日常的に使用するような検索を試してみました。以下は、触ってみた上での個人的な感想です。リリース直後ということもあり、サービスとしての完成度は、まだこれからの印象。ドキュメントなどはまだ不足しているように感じられた。今後はAPIからの操作や、データインポート方法のバリエーションが増えることを期待したい。S3にテキストファイルを置くだけで使用できる気軽さや、値段の安さは魅力的。性能も、定型レポートやアドホックな調査用途を想定すれば、十分実用的なもの。SDKでは、データ分析基盤システムによるKPIレポートへの対応も行なっています。