ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2014-05-06

データ分析環境について書いてみる

ログをHDFSに集めてHiveでETLや集計を行い集計結果をRDBMSに蓄積してレポーティングツールで可視化するというのは一般的な話だと思います。

データの流れでいうと

App -> HDFS -> RDBMS -> レポーティングツール

という感じです。

他にもPrestoのようなlow latencyなツールが加わることがあると思います。これらのツールをどう組み合わせてどうETLをまわしていくのがいいのかつらつらと最近考えております。

僕が経験したのはPythonでETL処理を書いて(内部的にはhiveserverにhiveクエリを投げたり、MySQLに集計結果を保存したり)、スケジューリングはcron, Azkabanで、集計結果はMySQLでレポーティングツールは自作でというものです。adhocなデータ分析はshib使います。まあこれでも十分運用回ってるんだけど、他にも良い方法が無いものかなとつらつら考えています。

そんな背景のもとネットサーフィンしてて現時点で思っていることを書いておきます。


1. ETL処理はRuby/PythonのようなLL言語が良いと思う。

Javaだとコンパイルしてパッケージングしてとかがちょっと面倒。サーバーに直接ログインしてソースをちょろっと修正して実行というのがやりたいのでLL言語の方が良い。

データが本番にしか無くテストも本番でしかできないというパターンがあるのでサーバー上で直接いろいろやれるのは重要。GUIでETL処理するツールってのもあるんだけどなんというかつらそう。スクリプトの管理ができないんじゃないのかな。

ちなみにSpotityはLuigiというPython製のツールを使ってETL処理をしているっぽい。

ちょっと気になったけどジョブ管理の機能も持っていそうでちょっと機能がリッチすぎるかなあというのが個人的な印象。

ETL処理の1個1個はたいしたことやらない、例えばHiveでselectしてMySQLにinsertする、ぐらいでその処理の1つが1つのPythonファイルになってそれをつなげるのは別途Azkabanのようなジョブ管理ツールに任せればいいんじゃねって思ってる。ま、この辺は各社の環境依存ですが。


2. Azkaban2意外と良いんじゃね

今まで古いAzkabanしか使っていなかったのですが、Azkaban2になってがらっと変わりました。

で、ちょっと試してみたんですが、以前できなかった下記ができるようになっていて意外と良いのではという印象を持っています。まだproductionには入れてないですが。

  • JP1用語でいうジョブネット単位で依存関係を定義できない。ジョブ単位での依存関係の定義はできますが、ジョブを複数まとめたジョブネット単位での依存関係が定義できません。
  • 日付を指定してジョブ実行ができない。
  • 月次処理ができない。
  • ジョブの削除がWebからできない。
  • 認証機構がない。

3. 集計結果格納用のRDBMSはとりあえずMySQLで良いと思うけどスケールするかは疑問

集計結果が少ないうちはいいけど、これが増えてくるとRDBMSが肥大化してきてつらい。レポーティングツールからクエリ投げても結果が返ってくるまで時間がかかるようになる。こうなってくるとNetezzaのようなDWHアプライアンスの出番かもしれないけど、値段がねえ。。。もちろん人件費に比べれば安いという話はあるし、十分選択肢に入ると思うんだけど、DWHアプライアンスってそんなにスケールしないと思うんだよね。10TB超えたら難しいんじゃないかな。あとベンダーロックインされちゃうしね。

Facebook and Vertica: A Case for MPP Databasesを見る限りFacebookはVerticaを使っているのかもしれないし、Avatara: OLAP for Web-scale Analytics Products - 2012/09 | LinkedIn Data Teamを見る限りLinkedinはVoldemortを使っているのかもしれない。


4. アドホック分析はshib

定期的に提供するレポートじゃなくてアドホックにデータ欲しいってことはあるのでそういう場合はshibを使う。Huahin Managerと連携すればジョブのキャンセルもできる。shibはHTTP JSON APIも提供しているのでshibをgatewayにしてジョブを実行という手段もあるけど、hiveserver不安定だしどうなんだろ。LL言語からHive CLIを実行するというETL処理で良いような気がしている。


5. Prestoの使いどころ

BIツールが直接Hiveにつなぐのは個人的に無い(Hiveはバッチ処理だし、JDBC不安定だし、途中でキャンセルできないから)と思ってるんだけど、Prestoならありかも。

その場合PrestoのJDBC経由でつなぐのがいいのか、Prestogresを使ってそれ経由がいいのかはわからない。

ODBCだったらPrestogres経由しか選択肢無いのかも。


6. データ分析者との役割分担

定型的なレポートじゃなくてもっと複雑な分析をしたいって場合はデータ分析者が頑張るしかないって部分はあると思う。GUIでぽちぽち条件を変えて実行すれば好きなだけデータが取れるというような状況になるのは難しくて、いろんなところからデータをexportしてExcelにくわせて〜みたいな部分はどうしても出てくるんじゃなかろうか。ここでいうデータ分析者がエンジニアではない企画者であるケースも多くて、そういう人にshib使ってクエリ書いてよっていうのもハードル高い部分はあると思うけど、最初のサンプルだけ書いて渡せば結構やってくれると思う。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/wyukawa/20140506/1399357053