Cloudera World Tokyo 2013に参加しました！ #cwt2013

Thu, 07 Nov 2013 10:11:00 +0900

Cloudera World Tokyo 2013に参加してきました。

午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。私が参加したセッションは大盛況な感じでした。

おみやげとしてカステラも頂いちゃいました！

また、色々なセッションに現れたこんなメッセージ画像も見つけました！

昨日の写真データの整理をしていたら、こんなものが・・・ @shiumachi さんよ・・・ #cwt2013 pic.twitter.com/S0JsxSYXIx
— Kenichiro HAMANO (@hamaken) November 8, 2013

やっぱり、スーツの人が多いなという印象。

名刺を毎回回収されるのはちょっとつらかったです。なにか、いい方法ないですかねぇ。

以下はいつもの個人メモです。

「ビッグデータプラットフォームとして進化するHadoop」

Cloudera株式会社　代表取締役　ジュセッペ小林氏

Costcoなどの写真を元にビッグデータを可視化

BigDataとHadoopの関係

検索、SQL、機会学習、数理処理、データ管理などにもHadoopの活用されつつある。セキュリティ、データ管理、クラスタ上でのツールの実行なども増えてきてる。

「今日ビッグデータは明日のスモールデータ」

アーキテクチャとしてのビッグデータ

多種多様なデータを一箇所に集約し、生データを直接活用できる。 OSSとしての責任も。

データサイエンス

Opsだけでないデータ解析にも活用

「Clouderaのビッグデータプラットフォーム戦略」（仮）

講師：Cloudera, Inc. CTO Dr.Amr Awadallah

レガシーな情報アーキテクチャ→スケールできない、可視化の限界、硬直したスキーマなどなど。

エンタープライズデータハブとしてのHadoopとか。

ビッグデータの歴史と将来展望

講師：国立情報学研究所　アーキテクチャ科学研究系　教授　佐藤一郎氏

ビッグデータの歴史的経緯とか

最初の事例はアメリカの1880年国勢調査。
「ビッグデータがコンピュータを生み出した」。コンピュータがビッグデータを生み出したんじゃない。
少量データにもHadoopを
- バッチ処理のリアルタイム化とか（一晩から10分へ）
原点は検索データのインデクシング
Hadoopを使うのが目的じゃないんだから、構築には手を掛けないのがいいよね。
プラットフォームと発展している

分散システム研究者から見たHadoop

分散ししテムの難しさを、処理範囲を限定することで巧みに回避
データの近くで処理
研究レベルではリアルタイム化や逐次処理化が活発
全工程で逐次・リアルタイムが必要とは限らない
聞いてばかりじゃなくて、動かしてみましょう。

データサイエンス：超並列分散処理を活用した新たなビジネス価値の創出

講師：アクセンチュア株式会社　工藤卓哉氏

「日経BPのビッグデータ総覧2013」に記事書いてる。
多様化するデータ（社外のデータも）をどうやってうまく活用していくか。
データが教えてくれたこと→まず、データありき、まずデータためましょう。それから解析とかすればいいのでは？というはなし？
競合他社さんはNGだけど、ブースでデモ？実機？が見れますと。

Hadoopデータプラットフォーム

Cloudera株式会社　嶋内　翔氏

まずは宣伝

Cloudera Implaraのフリーブックの日本語版
Hadoop Operationの書籍でるよ

プラットフォームを構成するもの

Flume
Sqoop
HBase
Hive
Impala

データ登録してBIアナリストのお仕事にどうやって役立てる？

外部テーブル：Hiveからはテーブルのように見える仕組み。元ファイルは消えない
SerDe（さーでぃー）：データをHiveレコードに変換する仕組み
生データを少し加工しましょう
- 圧縮したりファイル結合したりはしときましょう。
Hadoop活用のポイント
- 富豪的プログラミング。リソースケチるな。
- ローカルでできることはローカル。むりにHadoopでやんなくてもいいですよねと。バランス重要
スケジューリング実行などはOozie使うと便利。（日次集計とか）
Cloudera Searchで元データにインデックス貼れるぞと。検索しながら分析ができる

クラスタ管理とか

Cloudera manager便利ですよ
ストレージリソースの管理。
- 声掛け、管理者が容量チェック、Cloudera Managerのレポート
少数精鋭でHadoop使おう＝手が回らなくなる。
みんなで使おう＝Kerberos認証とか管理をちゃんと考えないと。けど、文化が根付けば強力。Sentry、Cloudera Navigatorとか。
Hadoopシステムの全体構成図。データの流れと各製品のつながり。
We are hiring!ということで、興味のある方は@shiumachiさんにコンタクトをとりましょうとのこと。

SQLで実現するバッチ処理とストリーム処理

LINE株式会社　田籠聡氏

資料：Batch and Stream processing with SQL

LINEのキャラがちらほら出てきた。
SQL好きですか？
ログの量とか。2.1TB/Day
バッチ処理とストリーム
- 速い集計のためにHadoopが重要
エラー系のログとかはストリームで処理したい
アーキテクチャ説明
データ解析する人って色々。
- 管理者
- プログラマ
- サービスディレクタ
- 経営陣
みんなが集計用処理を理解、編集ができるほうがいい。
顔あげたらHiveアイコンだらけだったｗ
Shibとか。
なんでHiveに限るの？
- Hiveに着目したバージョンアップだけを考えれば良くなる。
スケジュールクエリが増えてきて、つらい。
- TimeWindowを固定して集計処理をすることで、回避できる。

Norikra!!

スキーマレス
OSS。Esperベース。
インストールが楽
クエリの動作のお話。
http://norikra.github.io
We Are Hiring!

Hadoop コミュニティと YARN の現状

日本電信電話株式会社　小沢健史氏

なんでHadoop？

PostgreSQLでやってたけど、大きなデータにはHadoopを使おうという感じになってきた。
なんで使い分けるの？
- スキーマ後付け
NTTDocomoのモバイル位置情報の統計処理とか？
技術的な話をするので、HiveTに着替えます！ｗ
YARNのなにが嬉しいの？
- ImpalaとMapReduceが同時に動くような環境の時に、リソースをうまく管理できないのがV1
- そこでYARN
Apache Mesosとだいたい一緒。
Apache MesosとYARNの比較

Norikra on @johtaniの日記 3rd