冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

データ分析環境を作りかけのメモ

一度リリースしたサービスを成長させるんだったら実際の各種データを元に仮説を立てて検証したいところ。アクセスログやアプリケーションデータやGoogle Analyticsの分析データなど、運用時に種々のデータが蓄積されていきます。それぞれでも有用なデータなわけですが、バラバラなままでは活用が難しいこともあります。データは繋いで使ってこそ、意味がある。

というわけで、データ分析環境をどうやって作るか考えて、ここ数週間、要件を書く合間を縫って検証してきた内容と気づきをまとめます。

想定されるデータソース

現状、扱っているデータソース(Analyticsをデータソースと言っちゃうのはあれですが)は以下三つ。

そして、導入を検討しているものとして

  • Neo4j

があります *1

Re:dash

とにかく異なるデータソースをつなぐ環境が欲しい、というわけでRe:dashの導入を検討しました。

redash.io

Re:dashは様々なデータソースをまとめてSQLでクエリを書いてビジュアライズできるソフトウェアです *2

どうも、クエリの結果はRe:dash側にスナップショットをとってる感じがするので、ビューをつくってグラフやなんかでデータを表示させるためのフロントエンドという操作感。Elasticsearchにおけるkibanaのような位置付けで、もっと多くのデータソースに対応できる、というイメージでいいかと思います。

インストールやセットアップなどは公式ドキュメント通りにできたので割愛します。Docker上に環境作れるのはいいですね。

対応していないデータソースへの対応

結構な数のデータソースに対応しているんですが、それでもまだ対応していないものがあります。今回の検証に関わるところだと、

の二つ。

このような場合に検討するのは、

  • 無理くりロードするクエリランナを書く
  • 対応しているデータソースにインポートしてから読み込む

のどちらか、ですね。まず最初は前者を検討してみることにしました。

Pythonクエリランナ

このような未対応データソースへの対応なのかどうかわかりませんが、Pythonクエリランなというのがあります。

Supported Data Sources — Re:dash documentation

なんか、100%セキュアな状態で使ってね、とか怖いこと書いてますが、ローカルでDockerイメージ立ち上げて検証する分には問題ないでしょう。

実際のPythonでのクエリのイメージはここを読んでみてください。

gist.github.com

他のクエリ結果の取得ができるようですね。 ドキュメントに記載がなかったのでソース見てみましたが、提供されているAPIはこの辺っぽいです。

github.com

get_query_resultの引数がidだけなので、パラメータありのクエリは無理?

Neo4jのクエリを書いてみる

注意:結局できなかったのと、やりながら重要なことに気づいてしまったので中途半端に終わります

neo4j.com

Neo4jはPythonのライブラリがあります。というわけで、クエリを書いてみようと思いました。やってみたことは以下。

  • Neo4jのPythonライブラリをインストールしたRe:dashイメージを作る(イメージのビルドとrunは成功)
  • クエリを書いて実行

クエリはこんな感じです。

from neo4j.v1 import GraphDatabase, basic_auth


  driver = GraphDatabase.driver("bolt://localhost", auth=basic_auth("neo4j", "neo4j"))
  session = driver.session()


  session.run("CREATE (a:Person {name:'Arthur', title:'King'})")


  result = session.run("MATCH (n:Person) WHERE n.born >= 1970 RETURN n.name AS name, n.born AS born")
  for record in result:
      print("%s %s" % (record["title"], record["name"]))


  session.close()

これが、どうもライブラリを参照できてないわけです。そもそもPythonクエリランナがどういう参照の仕方をしているかよくわかってないので、pipでインストールするだけでOKなの?とか諸々調査が必要しなきゃいかんかな、と思い始めていたわけですが。。。

ここでふと気づく

で、ここで気づいてしまったわけです。ここまで考えてたことって、本番系を直接データソースとして取り込むやり方の検証なんですよね。何かの拍子にスロークエリ投げてしまったら本番系に影響出してしまう可能性もあるわけです。今更ながらこれはだめじゃん、と。

というわけで、基本的なデータのみ定期的にEmbulkでRedshift突っ込んで読めればいいのでは、ということで今はEmbulkとdigdagの検証に入ってます。この辺が検証終わったらまたRe:dashの検証を再開する予定です。もっと早く気付こう。。。

Embulk — Embulk 0.8 documentation

What’s Digdag? — Digdag 0.8 documentation

*1:導入が決定したわけではないです

*2:一部SQL未対応のデータソースあり。Elasticsearchとか