Hadoop Summit Tokyo 2016に行ってきた

http://hadoopsummit.org/tokyo

チケット代が約4万円で高いと噂になったHadoop Summit Tokyo 2016に行ってきました。

ただ海外ではこのぐらいの値段は普通らしく、むしろ日本が異常に安すぎるという。
そのしわ寄せがイベント運営者にいってしまっているのが現状なので、世界基準を知る良い機会だったかも。

僕は2日間とも最初から参加しました。

基調講演を除くと聞いたセッションは下記の通り。

10/26
Real-time Analytics in Financial: Use Case, Architecture and Challenges

Path to 400M Members: LinkedIn’s Data Powered Journey

Hadoop 3.0 in a Nutshell

Apache Eagle - Monitor Hadoop in Real Time

Using Hadoop to build a Data Quality Service for both real-time and batch data

10/27
Protecting Enterprise Data In Apache Hadoop

Apache Hadoop YARN: Past, Present and Future

How to overcome mysterious problems caused by large and multi-tenancy Hadoop cluster at Rakuten

Network for the Large-scale Hadoop cluster at Yahoo! JAPAN

Why is my Hadoop cluster slow?

Major advancements in Apache Hive towards full support of SQL compliance

Rebuilding Web Tracking Infrastructure for Scale

BOF:Apache Hadoop


全体的な感想を雑に書くと、機会学習ネタを除くとクラウドやセキュリティやストリーミング処理のテーマが多かった気がします。

あと毎回思うけど英語難しい。。。

でもHiveコミッタにhiveserver2不安定なんだけどーって言いましたよ!

技術的なトレンドとしては大規模クラスタを持っているところ向けの機能が充実してきている印象があります。

例えばHadoop 3.0で入るErasure codingとかtimeline server v2がHBase使うとかね。

そういう傾向が見て取れる状況で、僕のような小規模クラスタを運用している身としてはどう運用に落としこむかが課題になってくるのかなとおもってます。

Yahoo Japanと楽天の発表を聞きましたが、前者はエンジニアも多い上にHortonworksからのバックアップもあるので大規模クラスタでも問題なくやっていけると思いますが、楽天の場合はちょっと辛そうだなと思いました。発表内容がトラブルシューティングの話だったのでそう聞こえただけかもしれませんが。

楽天の場合は数百台規模で超大規模というわけではないけど小規模でもない環境で、ユーザが割と自由にクエリ投げたりデータ作れたりする環境みたいなので、クソクエリ問題は当然あります。ただクソクエリ問題はコンピューティングリソースの話なのでそこはまあ比較的やりようがあると思ってます。例えばうちの環境だとshibでクエリを投げる場合にtimeoutを設定していて一定時間過ぎると自動的にkillします。

一方でストレージ絡みの問題は辛い。。。datanodeからのブロックレポートが集中する話が出てましたが、ああいう問題は対応が難しい。

graphite/grafanaでモニタリングしてスレッドダンプ取得してHDFSのソース読んでという話がありましたが、ああいうことをできるエンジニアはそもそもそんなに多くないし、運よくいたとしてもそのエンジニアが疲弊しがちです。

既知バグでアップグレードすれば治るとしても気軽にアップグレードできるものでもない。

なのでコンピューティングノードとストレージノードを分けて運用できると楽なのですが、今後そういう方向にいくのかな。こうするとデータローカリティのメリットはなくなりますが運用が楽になります。

Prestoもストレージもってないからアップグレードが簡単です。

Prestoだったらバグ報告すればすぐ治るし、ロールバックもアップグレードも簡単なのでストレージ運用の辛さがないです。

楽天の事例は僕も以前数百台規模のクラスタを運用した経験からもある程度辛さがわかります。

なので僕の現時点での意見として大規模クラスタを用意してそこにデータを集中させるのは良くないと思ってます。ただしエンジニアリングリソースが豊富であるとかサポートを購入しているとかなら話は別です。あとPresto的な運用ができるなら別。

部署単位でHadoopクラスタを持って必要に応じてデータをコピーして使えば良いんじゃねって思ってます。マイクロサービスならぬマイクロHadoop

そうすればでかいクラスタにならないで負荷も低くなってファイル数も減って、問題に遭遇する可能性が減る。それに新しいクラスタを構築、運用する仕事も増えるのでそういう仕事は新しく入ってきた人に任せやすいです。人は他人の台所で料理したくないものです。マイクロサービスが組織の問題を解決したのと同じ理屈です。