wyukawa’s blog

2種類のログ解析基盤

Hadoop, Presto, yanagishima

僕は仕事では2種類のログ解析基盤を見ています。

1つ目はどちらかというとエンジニアよりの解析基盤でサービス側のエンジニアがShib, ShibUIを通して好きにクエリを投げることができます。ただしtableをcreateしたりdropしたりinsertしたりはできません。selectのみです。データの更新作業は別途cronのhive batchで行います。データはFluentd経由で各サービスのサーバーから収集します。こっちのシステムは古くからあって僕は引き継いだだけなので見ているとはいってもそんなにやることは無いですし、語れることも少ないです。

2つ目は約1年前に僕が一から構築したシステムでプランナーよりのシステムになってます。僕のチーム内のエンジニアだけがrawデータを触ったり更新したりすることができて、プランナーはレポートを通して加工されたデータを見る形になります。なので1つ目のシステムと違ってクエリを僕のチーム外から投げられることはありません。

こちらのシステムに関しては以前、現在のログ解析基盤 - wyukawa’s blogでも触れました。

最近、Presto 0.101にupgradeしたんですが、unionがあるpresto viewとjoinするとおかしくなるケースがあるようで0.100にrollbackしました。

問題をMLで報告したら、IndexOutOfBoundsException in AddExchanges visitUnion ? Issue #2824 ? facebook/presto ? GitHubが起票されて Translate symbols in ProjectNode in AddExchanges by nileema ? Pull Request #2834 ? facebook/presto ? GitHubで修正が進められているようです。0.102では治っていると期待してます。

https://prestodb.io/docs/current/release/release-0.101.html

を見てもわかるようにPresto 0.101は結構機能追加されておりWeb UIもReactJSを採用して見た目も変わっています。ただまあ僕が踏んだバグもあるのでちょっと待った方が良い気がします。

僕はPrestoのバージョンアップは20回くらいやっていて3回ほどrollbackしています。すぐバージョンアップするんじゃなくてもうちょっと様子見、例えばTreasure Dataがバージョンアップしたらこっちもやるとかしても良いんですけど、うちのユースケースだとCognosからクエリ投げたりするんで他の人が踏まないバグを踏んでそうな気がします。そうなると待ってもしょうがないんで、バグ踏んだら踏んだでさっさとrollbackして問題は報告して修正を待つのが良いと思ってます。

Azkabanは開発はほとんど止まっていてMLもスパムまみれになっていてオワコン感がはんぱないですが、今のところ使い続ける予定です。チーム内でRundeckを検討したんですが、ジョブの並列実行が難しいとかジョブの分岐は出来ても合流は出来ないとか、ジョブ管理ツールとしては致命的な機能不足があるようなので採用は見送ってます。ちなみに僕自身はRundeck試してなくて他の人の調査結果を聞いただけです。

や、それにAzkabanはジョブ失敗したときでもボタン1個で失敗したジョブを再実行出来るので便利なんですよ。不満点はcron書式が書けないことやジョブ定義をDSLっぽく書けないことぐらいかな。

後者に関してはAzkaban Roadmap ? azkaban/azkaban Wiki ? GitHubにあるのですが、実現されることは無いでしょう。

matthayes/azkaban-rb ? GitHubというツールもあるけどこれ動くのかな。。。まあDSLからAzkabanのジョブ定義ファイルを自動生成するツール作ってもいいかなと思ってます。現状だとジョブ毎にジョブ定義ファイルが必要でジョブネットが複雑になるとわかりにくいので1つにまとまってた方が良いんですよね。なのでDSLで1ファイルに書けるとうれしい。

Prestogresは重要な位置を占めています。最初はMySQLに集計結果を格納してたんですけど、MySQLだとウィンドウ関数使えないので国別、日付別のランキングレポートとか作るのが難しい。PostgreSQLならウィンドウ関数使えますが、管理するストレージを増やしたくないのでHiveを直接みれればそれにこしたことはないです。Presto経由でHiveを見れて、Prestoはウィンドウ関数もあるので、これでOKで後はCognosから接続できればいいんだけど、そこはPrestogresで解決しました。

物理テーブルは変えずにPresto viewを作成してそこでウィンドウ関数を使って国別、日付別のランキングレポートとか作ります。これで1つの物理テーブルをもとにいろんなレポートを作ることができます。

今まではPresto view作成はエンジニアの仕事になってたんですが、レポートを作るディレクターがそれもやった方が効率的なので今はディレクターがSQL書いて好きにPresto viewを作成しています。

Presto viewの作成だったら普段のHiveバッチ処理には全く影響が無いし、もともとCognosから参照させることが目的なのでレポート作成者が作るのが手っ取り早いんですよね。

ただし、Shibだとselectしか出来ないのでPresto view作成は出来ないです。なので最初はPrestoのCLIコンソール使ってもらってたんですけど、windowsだとlessが動かないとかあったり、1カラムに入っているデータが長いと\G使っても横に切れちゃうんですよね。json形式でデータを格納しているとよくあります。

DbVisualizerとかも試したんですけど、イマイチちゃんと動かなかったりしたこともあり自作したのがyanagishimaです。yanagishimaでcreate viewしたりdrop viewしたりします。Hiveの物理テーブルのdropはprestoからは出来ないので安全です。

PrestoのWeb UIツールyanagishimaを書きました - wyukawa’s blog

コンセプトは簡単にセットアップできてMySQL Workbenchライクに使えること。

https://bintray.com/artifact/download/wyukawa/generic/yanagishima-0.0.1.zip

をダウンロードして解凍して設定ファイルをちゃちゃっといじってスクリプト実行すればすぐ使えます。

ソースビルドも簡単です。gradlew使っているのでビルドツール不要です。

yanagishimaの今のところの問題点として、パーティション数が多いとツリー展開が遅いです。テーブル数多くても多分同じ。ここはJavaScriptコードの部分を改善すればいいのかもしれませんが、よくわかってないです。あとクエリのキャンセルができないのでPrestoのWeb UIからやることになります。またクエリの結果が多い場合は途中でfetchを止めます。その場合は警告を出します。しきい値は設定ファイルで指定します。

Shibはどちらかというと1つ目のエンジニアよりのログ解析システムでフル活用してます。1つ目はチーム外のエンジニアがアドホッククエリ投げるので認証も入れてます。2つ目のシステムも認証は入れてますが、Apacheのreverse proxy使っているだけでしかもユーザは固定です。用途が違うので欲しいツールもちょっと違ってくるんですね。

まあ、そんな感じです。

Permalink | コメント(0) | トラックバック(0) | 22:31