Cloudera 新製品紹介セミナーに行ってきたよ

例によって社外のセミナー（今日は「Cloudera 新製品紹介セミナー」）に参加してきましたので、ブログを書いておこうと思います。
所感などはのちほど追記することとして、まずはメモを取り急ぎ、公開しておこうと思います。

まず、セミナーの概要としては以下のようなものでした。

日程：2013年4月19日（金）18:30〜21:00

会場：コンベンションルーム AP八重洲通り 12F受付

http://www.ap-tokyoyaesu.com/info/access.html

タイトル：エンタープライズクリティカル機能を充実させる「Cloudera 新製品紹介セミナー」

参加費：無料

アジェンダ

18:15 受付開始

18:30 開会・ご挨拶代表取締役社長ジュセッペ小林氏

18:45 「Cloudera 新製品」のご紹介プロダクトマネージャー Jairam Ranganathan氏

19:45 Q&A

20:00 懇親会

21:00 閉会

以降からが QA を含むセミナーのメモです。

18:30 開会・ご挨拶代表取締役社長 from ジュセッペ小林氏

新製品の紹介
- Cloudera を知っている人も多いかと思うが、 Hadoopからはじまった企業。
- 大きな力を注いでHadoop自体も拡張してきている。
- 分析基盤としての流れは変わっていないが、基幹（Enterprise）のBigdata基盤として使われるようになってきている。
- Hadoopだけでなくそのまわりを補完する機能が要望されてきている。活用のためのMiddlewareを提供し始めている。その紹介をしたい。
Hadoop屋からBigdata Platform屋に変身しはじめているということを認知してほしくて今回は集まっていただいた。
- CDHやCloudera Managerもそれに合わせて変わってきている。それを確認していってほしい。

18:45 Product Updates & New Product Introduction - 「 Cloudera 新製品」のご紹介 from プロダクトマネージャー Jairam Ranganathan氏

➤ Overview & Product vision

Product Vision
- Hadoop のメリットはご存知のとおりだとおもうが、分散型のプラットフォームとして大規模処理をうごかすのに使われてきた
- ここ数年でHadoop上のデータ量もより膨大に、MRにもより多くの要望があがるようにあがってきた
将来的にどのようなものを見込んでいるか？
- あらゆるデータのクエリ、処理、検索ができる単一のプラットフォーム
- 数千台までスケール、事前のスキーマ設計不要、TBあたりのコストが低減
プラットフォームのコンポーネント
- 全部をClouderaで提供するわけではないかも、たとえばMathならRを使ったほうがいいかもしれない
- いいものがあれば、それを柔軟に取り組んでいく予定だということを強調
- Hadoopのようにスケーラブルで耐障害性が高くコモディティHWの上でうごくようにしていきたい
Cloudera Enterprise
- あたらしく追加になったものに今日はFocusをあてていきたい
- Impala
- BDR（Cloudera Managerの一部になっているがバックアップ機能）

➤ New Product

Impala
- Hadoop内データのリアルタイムクエリ
- いろんな意味合いでHiveと親和性。ODBC,JDBC Driver
- 一番の違いはパフォーマンス
- ファイルフォーマット、圧縮技術は継承
- もちろんOSS
- なぜすごいのか？
  - そもそもなぜこの課題に挑戦しようとしたのか？Hiveを使う人はデータの中身を見たい人、しかし遅い。
  - 間違ったクエリを実行したとしても、その結果をしるのが一日後になってしまったりする。失敗するなら早く知りたいよね、と。
  - はやいレイテンシでクエリを実行できるメリットは多いだろうというところからモチベーションはきている。
  - Analyst がフットワーク軽く調査を大量データの調査を行うためのもの。これをつかうことによってHadoopをより高めることができると思っている。
  - ※アーキテクチャの説明のメモは割愛（リアルタイムクエリエンジン「Cloudera Impala紹介セミナー」でとったメモの公開 #impala2013 - #garagekidztweetz をはじめ、何度かきいたことがあるので）
  - State Store, Planner,Cordinator，Query Executerの役割の話
  - Simpleなクエリを実行したときの裏側の動作の話
  - ImpalaとHiveの比較の話
- Parquetとは？
  - Dremel フォーマットがベース
  - 汎用的なHadoopファイルフォーマット
  - ClouderaとTwitterが共同で開発したOSS
  - カラムナコンテナフォーマット
  - MRにも対応している
- Parquet の機能：
  - Rowgroupフォーマット：ファイルには複数の水平されたスライスを収納
  - １つの分割ファイルに各カラムの格納をサポート
  - 細かく構造化されたデータ
  - ネイティブ型に列の値を格納
  - 高速検索を実現するIndexページのサポート
  - 高圧縮を実現する拡張可能な値のエンコード
  - Disk は遅いので上記のようなことができることはメリットになると認識している
- 今後のImpalaのRoadmap
- GA版
  - HiveQLに酷似
  - HDFS、HBaseストレージサポート
  - Text file, Sequence file, Avro, RCFile and LZO
  - Parquet列志向型フォーマット
  - DDLのサポート (except Create Table as Select)
  - Snappy, Gzip サポート
  - 完全分散集計、Top-n計算
  - 結合パーティション
- 本番展開に向けたガイダンス
  - Resourse isolation within MR Cluster (MR とImpalaのリソース配分を調整できる)
  - Load balancing across Impalads
- Impala Roadmap
  - UDF support
  - SQL authorization, DDL completely support (Hive also not support though)
  - Windowing function
  - Order by with limit
  - 構造化データ形態
- ランタイムの最適化
  - 遅延ノードの扱い（現状はない）
  - 結合の最適化（よりコストベースなオプティマイザを提供することを目指している）
  - テーブルキャッシュ（同じテーブルにアクセスすることは多いのでキャッシュすることでより高速な処理を実現することを目指す）
- その他：
  - より豊富なリソース管理（MRに40%、Impalaに60％といったようなに加えてユーザによって切り分けもできるように、たとえばマーケティング部に60％割り当てるとか。上限値の設定も考えている）
  - クエリのFTサポート
- Cloudera アプローチの優位点は何か？
  - 以下の3つと比べた
  - MRの高速化を最初は考えた（フレームワークの制約によりどこまでも高速化できるというわけにはいかなかった、アグリゲーションなどの実現）
  - リモートクエリも考えた、しかしNWがボトルネックになってしまう
  - サイドストレージも考えた、しかしそのためには真ん中にETLの処理が発生してしまう、DBに最適化したフォーマットにしないといけないのでMRができない

Impala について質問はなかったが、ぜひ使ってみてほしい、簡単だから
資料についてはのちほどDownloadできるようになる

BDR
- なぜつくったのか？
  - より大事なデータをHadoop上に格納する人が増えてきている。これまではやるとしても内製でつくるしかなかった。
  - Hadoop、HBase、Hiveそれぞれでそのやり方も違うときている。（つまりはそれらを補完するように作りこみをしなければならないということ）
  - だから、そういった面倒を取り除くためにつくった
- バックアップ＆DRポリシーをシンプルに
  - 中央一元的なポリシー設定
  - モニタリングとアラート
- 最初のバージョンはDRだけです。バックアップはないよ、と。
  - 最初はHDFSとHiveのDR
  - 重要なデータだけを選択することができる（Hiveならテーブル単位、HDFSはファイル単位）
- 分散コピー
  - Distcp の拡張、HDFS Federation、HAなどなど
- メタストアのレプリケーション
  - 差分更新
- HBase（HBaseスナップショットv1対応、ただし BDR1.0ではサポートしていない）
Cloudera Navigator
- なんで作ったのか？
- （基本的にはあくまでDatamanagement）
- Hadoopをより活用していくようになる過程で、データソースの数がどんどん増えていく。どんどん使用ユーザも増えていく。そしてより重要なデータを格納するようになっていく。
- 結果として、
- データのライフサイクルを考えるようにもなっていくだろう。データの系統も知りたくなるだろう。アクセスコントロールをしたくもなるだろう。
- 例えば
- どういったマーケティングキャンペーンについてどういったユーザが反応したか知りたいが、アナリストはどんなデータがあるのか知らないことがあるかもしれない。
- アナリストがどういったデータがどこにどのように入っているのかを用意に知ることができるようになりたいのではないか？
- ただし、Version1.0ではアクセスコントロールと監査だけ
- 認証そのものについてはKerberosで実現されていると思うが、誰がどこから何を見に来たのかといったことは容易にわからない、それを見える化する
- 課題
  - 発見という意味ではメタデータの検索、ブラウズ。データセット、ビュースキーマ、関連メタデータ。

➤ Update Products

Cloudera Manager 4.5
- 知っている人が多いと思うのでさらっとした説明。
- 1つのツールですべてに対応（複雑なマネジメント、監視やらワークフローやらを）
- 個別機能を提供するサードパーティはあるけども（たとえばモニタリングならSplunkなど）、ワンストップは嬉しかろうと
- ワンストップにすることによってHadoopの状況が文脈としてわかる
Hadoop管理の代替品としての比較
- Horton WorksやMapRとの比較
CDH 4.2
- HBase スナップショット
- JT の高可用性
- Hive の改善 Hive 0.10
HCatalog の追加サポート
- プラガブルソート
- HDFS
ショートサーキットの読み込み

QA

Q. 監査ログ自体はどこに格納されるか？
- A. 現状はSQLDBにいれている（将来は要望があればHDFSも考える）
- A. log4j とは別
- A. HadoopのAuditとは集める情報がべつなので重複はしない
Q. Seems Cloudera Navigator is a independent tool from Cloudera manager. As a user point of view, Cloudera navigator become a one part of Cloudera manager seems more useful. Do you have any plan for make Cloudera navigator as one part of Cloudera manager?
- A. Can call from Cloudera Manager. the process are independet though.
Q. CDHでもparquitも必要では？
- A. いつかはあれだけど、すぐにつかえるようになるはず
- A. 具体的なスケジュールはまだないけども
Q. JT HA
- A. Cloudera Managerでいつから使われるか？
- A. こっちもこっから数カ月後に対応するはず
Q. Impala、すべてのSQLを対応するつもりか？
- A. Traditional DB insert is difficult, Like Hive already supported.
Q. ImpalaがSQLに対応すれば、NoSQLいらないのでは？
- A. あくまでAnalytics目的（すくなくとも現状、短期的には）