KaggleのTalkingDataでSQL可視化ツールを比較した際のメモ。
前書き
普段業務ではRedashからPostgreSQLにクエリーを投げているが、他のデータ分析ツールの組み合わせも試してみたいなと思っていたところ、ちょうどTalkingDataのコンペがやっていたので、そのデータを使い比較してみた。
Embulk + PostgreSQL + Redash (on local Mac)
EmbulkはTreasure Data主導で開発されているデータ転送ツール。同じくTreasure Data主導で開発されているFluentdは主にlogデータの転送に使われるが、Embulkは主にMySQLなどのDBの内容を転送するのに使われる。
スキーマ推定機能もあり、推定用のseedファイルさえ作れば embulk guess コマンドで転送用の設定ファイルが自動作成できる。
# seed.yml example in: type: file path_prefix: "./input/train.csv" out: type: stdout
基本は自分の使いたい入力と出力に合わせたJDBCのドライバを入れて使う。今回はCSVの入力とPostgreSQLの出力を選んだ。組み合わせの自由度のためか推定できるタイプが制限されており(boolean, long, double, string, json, timestamp)、例えばPostgreSQLではIPアドレス型もあるがそういったものは選べない。
localで試した印象としては数GBのデータセットでも転送に時間がかかった。通常のWebサービスのバッチ処理では定時で深夜にまわすことが多いが、データ分析コンペではその時欲しいことも多いのでサクサク環境が整わないのはストレスかもしれない。
可視化はlocalでRedashのdockerを動かした。こちらもlocalだとクエリーが返ってくるのが遅かった。
Embulk + PostgreSQL + Metabase (on local Mac)
QiitaでMetabaseいいよという記事を見て上記構成のRedash部分を差し替えてみた。
Metabaseにはデータソースをある程度自動で分析する機能があり、それがworkすればよかったのだが、自分の環境だとデータのロードが終わらなかった。数GBでもこれだったので、業務でログ分析する際のツールとしてはつらいかもしれない。
いいところもあげると、SQLのWhere句をExcelのフィルターのように作れる機能があり、非エンジニアでも使えるという意味ではよさそうだった。
AWS Glue + Athena + Redash
localに限界を感じたのでクラウドに移行した。
AWSにはAthenaというS3にcsvファイルを突っ込めばテーブル定義をするだけでRDB相当の機能を提供してくれるサービスがあり、それを使用した。AWS Glueという別のサービスを使えばスキーマ推定もしてくれ、テーブル定義も自動で済む。
S3にcsvファイルを入れるだけで済めばいいのだが、Athenaはログデータを入れることに最適化されており、ディレクトリを切る必要がある。/train.csvではダメで/train/0.csv, /train/1.csv のように親ディレクトリを作成する必要があり、その点は少し面倒。
クエリーのレスポンスが数秒で返ってきたので速度は良好だが、AthenaはFacebookのPrestoをベースにしており、Offset句が使えない。データのとある行からとある行まで見ようと思ったら指定する方法がなく絶望した。
また、AWS Glueのスキーマ推定機能はEmbulkより弱く、datetime型をstringにされた。
BigQuery + Data Studio
GoogleのBigQueryにもスキーマ推定機能があり、Athenaのように変にdirectoryをきる必要もないのでお手軽。csvファイルをインポートするだけで高速にレスポンスが返ってくる環境が手にはいる。難点を言えばテーブルの指定方法が通常のSQLより冗長な気がした。
可視化もGCPで揃えようと思いData Studioも検討したが、Data Studioは可視化に特化したサービスであり、RedashやMetabaseのようなクエリーインターフェースはなく、データ分析には適さない印象。
所感
それぞれ一長一短があり一筋縄ではいかなかった。今回試した中での最適はBigQuery + Redashだと思う。
Future Work
Superset, Redshift, Elastic Stack
