先週熱が39.3度まで上がって、夜と朝方に未だに咳が止まらない虚弱なタムタムです。
5/30にHadoop Source CodeReading#9がありまして、「Introduce to Hive undocumented feature」というタイトルで発表させていただきました。
完全にネタセッションになってしまいました。
とはいえ、それなりにHiveは使っていたつもりなので何か困ったことがありましたらご相談ください。
HTTPのサーバは、いったん書き直してそのうちGitHubに公開するようにします。
質問があったtimestampの話ですが、
使わない方が良い理由として、
・Timezoneの扱いがちょっと微妙
・UDFのfrom_utc_timestmap, to_utc_timestampがバグってるってレベルじゃない
・一部の処理でメタ情報が正しく扱えない(JDBCからMeta情報がStringになってしまう等)
あたりがあります。
ユースケース的に上記を回避できるのであれば使っても問題ないと思います。
気がついたものはパッチを投げてありますが、コミュニティ純正の0.8, 0.8.1, 0.9, 0.9.1ではひとまず避けた方が良いです。CDH4ではHive0.8系ベースにいくつかのパッチを当てたものを提供してくれるので、Clouderaさんに期待＆素直にCDH使った方が良いと思います。
発表スライドは日本語です。英語じゃないです。ごめんなしあ。。
自己紹介の部分と、見せられないよのページは抜いて、ご指摘があった部分は一部資料を修正してあります。
Slideshareにアップしました。
ここから感想
Hive Tools in NHN Japan (@tagomoris)
NHNでHiveをどういう構成、用途で使っているかのお話。Hiveは集計に特化して使っている感じで、そのためのフロントエンドツールは自作している。GitHubにもそのツールは公開されていて、やっぱりどこも同じようなものを作るよねと思いました。（LD界隈のツールのクォリティが高くて恐れおののきます・・）
ゲームのようにキャンペーンを頻繁にうつサービスは別ですが、そうでないサービスの内容が安定している場合、アドホッククエリを流す事ってほとんどないし一度流したものは定常的に流す事が多いので、そういう意味では理にかなっているツールだなと思いました。
Hive Source Code Reading (@wyukawa)
Hiveのソースコードを読んで、最適化まわりについてのお話です。Hiveの内部処理がどうなっているかの説明といくつかの最適化のポイントの解説でした。結論から言うと、Hiveでの最適化はあまりする必要がないという感じ。というのも、HiveのM/R処理は実はMapReduceデザインパターンに書いてあるような事はだいたい実装されていて、それなりに最適なM/R処理を行うようになっています。逆を言えばHiveで処理できるような単純な集計はM/Rを直接書かないでHiveで処理させた方が効率が良い場合が多いです。
個人的には、Explainを流してStage数がいくつになるのかを確認する程度です。
あとがき
勉強会を主催するということ、会場を提供するということは、とても大変な事だと思います。
自分だったら同じように出来ないです。
@shiumachiさん、@hamakenさん をはじめ、素敵な発表をしていただいた@tagomorisさん, @wyukawaさん、そして会場の準備をしていただいた方々にとても感謝しています。
（挨拶回りしなくてごめんなさい。対面で咳こんじゃうの嫌だったので...)
自分の発表は、内容、スライド、発表の仕方、もろもろ反省点が多いのでみんなの内容を参考にお勉強しますです。