この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Cloudera World Tokyo 2013に参加してきました。
http://www.cloudera.co.jp/jpevents/cwt2013/index.html
午前中は用事があったので午後からの参加となりました。参加したのは以下のセッションです。
- 13時30分〜14時10分 CDH最新情報
- 14時25分〜15時05分 Hadoopデータプラットフォーム
- 15時30分〜16時10分 SQLで実現するバッチ処理とストリーム処理
- 16時25分〜17時05分 Hadoopの運用
- 17時20分〜18時00分 Hadoop コミュニティと YARN の現状
ということで参加レポートですが、現時点でスライドが公開されていないものが大半だったので、各セッションに関して概要といいつつ詳細まで書いています。ここについてはスライドが公開されたタイミングで差し替えていく予定です。
CDH最新情報
- 講演者：Cloudera株式会社 Systems Engineer 水丸 淳 氏
- http://www.cloudera.co.jp/jpevents/cwt2013/session/001.html
概要
- CDHとは
- Cloudera’s Distribution Including Apache Hadoop
- エンタープライズ向け
- オープンソース。100%Apacheライセンス
- 現在最新は4.4
- CDHの採用理由
- パッケージ化済みなので簡単にインストールできる
- パッチ適用済み
- 実際に多くの顧客で利用されており実績の証明済み
- 統合済みなのでバージョン間、パッチ間の依存障害を回避
- CDHの歴史（各コンポーネントが採用された歴史が一目でわかるスライドでした）
- バージョン表記ルールについて
- CDH5での変更点（まだBeta版なので改めてリリースノートを見て欲しいとのことでした）
- http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH5/latest/CDH5-Release-Notes/CDH5-Release-Notes.html
- CDH4.4とCDH5の各コンポーネントのバージョン一覧
- JDK7対応（JDK6はサポート対象外）
- MapReduce2.0の正式サポート
- MapReduce1.0のおさらい
- YARNのアーキテクチャ解説
- その他、主要コンポーネントの主な変更点の紹介
- Flume
- Twitter Stream対応
- HBase
- サーバー間通信プロトコルがProtocol Buffersに変更
- 将来を見据えてバージョン管理しやすいフォーマットへの変更。
- 下位互換がなくなるので、ローリングアップデート出来ない。
- サーバー間通信プロトコルがProtocol Buffersに変更
- HDFS
- スナップショット機能の追加
- NFSv3対応
- Hue
- Sqoop App, Zookeeper App
- 画面レイアウトが再設計された
- Hive
- 大きく機能強化
- テーブルのtruncate
- ウィンドウ関数をいくつか追加
- メタストアのバージョンチェック
- HQLでUDFが書ける
- Impala
- UDF対応
- メタデータの自動伝搬
- YARNとの統合
- Llama
- Low Latency Application MAster
- ImpalaのYARN対応用に作成。ApplicationMasterを使いまわせるようにする。通常は毎回プロセスを作成するので、その時間を減らすことができる。
- Mahout
- 大きく機能追加
- YARN
- ResourceManagerのHA対応
- Oozie
- 高可用性対応
- Flume
- Clouderaでは人材募集中！
感想など
- HDFSとHBaseのスナップショット機能はすごいなーと思いました。欲しかった人は多いのではないでしょうか。
- ImpalaでUDFサポートは結構大きいのではないでしょうか。UDF書きたい人は多いようなので。
- 最近CDHを追っていなかったのですが、コンポーネントが増えたなぁという印象です。全部必要なお客さんがいるのかなーと思いました。
- ついにJDK7サポートというのは感慨深いです。今年の6月ぐらいまではJDK6のみでJDK7はサポートされていなかったはずなのに。
Hadoopデータプラットフォーム
- 講演者：Cloudera株式会社 プロアクティブサポート・エンジニア 嶋内 翔 氏
- http://www.cloudera.co.jp/jpevents/cwt2013/session/007.html
概要
- 宣伝
- Hadoopオペレーション発売予定！
- インパラ本の日本語PDFが無料公開予定！
- Hadoopシステムの全体構成
- データの取り込み -> 保存&処理 -> 参照
- データの取り込み
- 色々サポート
- Flume
- ログ収集
- 多段にできる
- 圧縮、暗号化のような処理も入れられる
- 出力先の分岐も可能でDWHに入れたりもできる
- Sqoop
- RDMS/DWH連携
- HBase
- REST API を使って入れる
- Flume 経由
- CSVファイルのバルクロード
- HDFS
- put/getコマンド
- CDH4からREST APIをサポート
- CDH5ではNFS経由でも
- Hue
- Webブラウザから
- Hive/Impalaを使ったデータ活用
- Hive
- SQLライク
- MRジョブにコンパイルされる
- Impala
- 低レイテンシー
- MRは使わないので早い
- 生データの活用
- 生データはそのままHDFSに入れるよりは一時加工してから入れたほうがいい
- Hiveに関してはSerDe（サーディ）を使うことでどんなデータも扱える
- スキーマ・オン・リード
- データに外部からスキーマを定義できる
- 外部テーブル
- ファイルシステム上にあるデータをそのままテーブルとして扱える
- テーブルを消してもメタ情報だけなので実データは消えない
- SerDe
- あらゆるデータをHiveのレコードに変換できる
- Javaで書く必要がある
- 生データを少し加工
- ファイル数が多い → NNのヒープを圧迫
- 無圧縮 → ストレージを圧迫
- そのままとよく言うが、あれば一時加工してからという意味。
- ポイント
- 富豪的プログラミングを行う
- ストレージリソースが安い
- 再利用するテーブルは中間テーブルを作る
- ストレージよりも処理時間を優先。ネストが深いSQLはMRジョブ数が多くなる
- なるべくHadoopを使わない
- 基本はローカルでできることはなるべくローカルでやる。Hadoopが必要な処理はそんなに多くない
- フィルタ・集計後に1GB以下ならRやPythonなのでやればいい。もちろんExcelでも
- どちらにするかは試しつつ、最適な方法を採る
- 富豪的プログラミングを行う
- Oozieを使ってワークフロー管理する
- 中間テーブルが多くなって集約できないかという話はよく聞く。しかし、中間テーブルの最適化はやめたほうがいい。クエリはすぐに変化数する。
- Hive
- Cloudera Searchとの統合
- Hadoop上のデータに対してインデックスを貼り、Solrで検索できる
- 利点はいろいろ
- 検索エンジンのように利用できる
- 検索してみて、結果からあたりをつけて分析をできる
- データ基盤におけるクラスタ管理
- Cloudera Managerは素晴らしいと考えているが、クラスタを使うのも管理するのも人の役目。なのでその部分について考えてみたい
- リソース管理
- Hadoopのリソース
- 計算リソース（CPU+メモリ）
- ストレージリソース
- リソースはみんなのもの。譲り合って使いましょう。
- 誰が管理するのか
- 誰に使わせるのか
- Hadoopのリソース
- セキュリティをどうするか
- オペミスは必ず発生する
- HDFSにパーミッションをつける
- HIve権限つける
- マルチテナントでは必須
- Kerberos認証
- Cloudera Navigator
- オペミスは必ず発生する
- どこまで管理するのか
- まとめ
- ツールを使うだけでは解決できない課題は沢山ある。ツールは銀の弾丸ではない。
- 今日の話も正解だと思っているわけではない。みなさんの意見も聞きたい
- Clouderaでは人材募集中！
感想など
- 「生データとは言っても一時加工してから」というのは衝撃でした。確かに前職でもHDFSの容量が足りないので生ログから必要な部分を抜いて残りは捨てていたのですが、後で分析とかしたくなった際に困ることになるのでどうしたものかなーとは思っていました。S3も検討したりしていたのですが、1年で1PBぐらい行きそうで、オーダー的にお値段が、、、という状態でした。ということで、最低限の一時加工は必要ということですね。
- SerDe（サーディ）はずっと読み方がわからなかったのでスッキリしましたｗ
- ジョブに関して富豪的に考えるというのはその通りだと思います。バッチかつ分散可能なので、CPUよりはいかにI/Oを減らすかというのがポイントなので。中間テーブルを作るというものI/O削減を目的に作るというのは非常に納得でした。また、ジョブ全体で中間テーブルの最適化をしすぎないというのも非常に納得です。仕様変更時に却って大変でしょうからね。
- 最後のクラスタの管理について改めて考えてみましょうというのは、沢山のお客様のサポートをしている嶋内さんならではの視点ではないのかと思いました。改めてそれが本当に必要か、どうして必要かを考えてみるのって大切ですよね。
SQLで実現するバッチ処理とストリーム処理
- 講演者：LINE株式会社 田籠 聡 氏
- http://www.cloudera.co.jp/jpevents/cwt2013/session/014.html
概要
こちらはすでに田籠さんがスライドを公開されていたので要点のみ書いてみました。
- LINEでのトラフィック、Hadoopクラスターのバージョン、Hadoopのユースケース
- バッチ処理とストリーミング処理の両方を利用している
- システム全体の構成図
- データ分析に関係するプレイヤーとその全員が読み書きできるSQLが必要
- バッチ処理に関してはHiveを利用しており、その範囲とメリット・デメリット
- ストリーミング処理に関してSQLで書けるようにNorikraを開発した
- http://norikra.github.io
- Norikraの特徴
- スキーマ・レス：仕様変更時にテーブル定義を修正する手間がなくなる
- Join, SubQuery, UDFもサポート
- 複合型をサポート：Nested Hash/ArrayをSQLから直接扱える。
- クエリサンプルの紹介
- LINEでは人材募集中！特にHadoopを扱える人を募集中！！
感想など
- みんな読み書きできるのがSQLなので、SQLで構築するという考え方はなるほどなーと思いました。
- そのSQLでストリーミング処理もできるようにNorikraを開発してしまうとうのは凄まじいなと。そして公開されているのも素晴らしいと思いました。
- EC2上でNorikraのインストールを試してみたのですが、CPUネックのようですね。c1.mediumでももっさりしていました。インストール自体はgemを叩くだけなのでほんと簡単に入りました。後日レポートできればと考えています。
Hadoopの運用
- 講演者：Cloudera株式会社 プロアクティブサポート・エンジニア 嶋内 翔 氏
- http://www.cloudera.co.jp/jpevents/cwt2013/session/019.html
概要
- Cloudera Managerの背景
- クラスタの構築が大変
- インストール手順が複雑
- サーバー数が多くなる
- 100台とか手作業ではやってられない
- 起動・停止の順序の把握が大変
- 設定ファイルの管理
- 更新漏れのノードが出てくる
- ハードウェスペックが揃っていないとさらに管理が大変
- 監視項目の把握も大変
- 全ノードのログ調査はできない
- スレーブだけで1ノードあたりGB単位
- マスターでは1000ノードにアンルと1分でGB単位
- 簡単に構築できる
- 100台でも1時間
- クラスタの構築が大変
- Cloudera Manager
- Standard
- 無償利用
- Enterprise
- 色々できる
- 比較ページは http://www.cloudera.co.jp/products-services/managementapps.html
- Standard
- Cloudera Managerの基本用語
- デプロイメント
- クラスタ
- ホスト
- ラック
- サービス
- ロール
- ロール設定
- 設定
- クラスタ、ホスト、サービス、ロールあたりを押さえる
- 5での新機能
- リソース管理がサービス単位からロール単位
- YARN対応
- HDFS/HBaseスナップショット
- チャート強化
- インストール
- デモビデオを見るとわかる（CM4しかないがほぼ同じ） 5分でHadoop環境を構築するCloudera Managerのインストールデモ動画
- パーセル(Parcel)
- CM4.5から
- root権限不要
- rpmではなくtar.gz
- アップグレート/ダウングレードが簡単にできる
- アップグレートして問題があれば簡単に戻せる
- 設定管理画面
- 設定がまずい場合は警告を出してくれる
- 例えばヒープサイズの桁を間違えた場合など
- Enterprise版は設定をバージョン管理できる
- 地味に便利なのが設定変更後に再起動を促す。再起動を忘れがち。
- マルチクラスタをサポート
- 開発とテストとか
- クライアント設定管理
- クライアント設定とサービス設定は別に管理されている
- クライアントとはサービスを利用すrためにアクセスするノード
- 起動・停止
- 再起動も簡単
- クラスタ単位でもできる
- 依存関係を考慮してくれる
- Enterprise版ならローリングリスタートが可能
- サービスモニタ（HDFS）
- 右側のペインに各種チャートが表示されており、カスタマイズも可能
- ヘルスチェック
- 各種サービスに実際にオペレーションを行って正常に動作するか確認してくれる
- 問題発生時は赤く表示されるのですぐに分かる
- ホストモニタ
- サービスだけでなくハードについても監視できる
- CPU、メモリ、ネットワークなどの負荷が見れる
- ホストインスペクタ
- ホストのヘルスチェックを能動的に行うことも可能
- 以前であればログをもらったり、実際にコマンドを打ったが、ホストインスペクタがあれば事項して終わり
- 各ホストにインストールされているパッケージのバージョンが一致しているかチェックすることもできる
- ホストのヘルスチェックを能動的に行うことも可能
- アクティビティモニタ
- 例えばHiveクエリであればそのクエリ、経過時間、利用しているリースなどがわかる
- 極端に遅いクエリがないかを調べたりできる
- リソース管理
- スケジューラもGUIで設定可能になった
- サービスごとにリソース割当ができる。例えばHBaseにメモリを10%みたいすると、それ以上は利用しないようにできる。
- レプリケーション
- クラスタ間でデータをバックアップできる
- dry-runで見積もり時間を見ることもできる
- スナップショット
- HDFSやHBaseをあらゆるバージョンに復元可能
- スケジューリング可能
- 監査
- Cloudera Navigator
- Cloudra Managerアドオン
- 現在は監査ログの取得ができる
- 今後も機能追加予定
- Cloudera Navigator
- 障害解析
- 検索
- ログ検索
- お客様から圧縮して1GBとかが普通に送られてくる。
- 指定時刻や指定ホストのログを抽出したりできる
- 非常に便利。これだけもCMを利用する価値がある。
- イベント
- サービスの警告などを検索できる
- ヘルスチェックにおいて、イベントのしきい値を柔軟に設定可能
- サポートで障害解析する際に最初に確認するところ
- ログ検索
- 問題箇所のグラフィカルな表示
- チャート
- 各種メトリクスをグラフ表示
- CM4.5から入った
- 新しい機能
- ヒートマップなど追加
- 全サーバーの全ディスクのIOPSヒートマップなど。そこから問題のあるホストを特定できる。
- 指数対数表示も可能
- ヒートマップなど追加
- TSQuery
- チャート生成専用のクエリ言語
- 工夫次第であらゆるチャートが生成可能
- YARNにも対応済み
- UI上で自動補完もしてくれる。
- チャート
- 検索
- Hadoopに取り組む際は象本を読むというのもあるが、まずはCMを試してもらいたい。
- 初心者：時間の短縮
- 熟練者：色々できることが増えているので一度見てほしい
- ML、ニュースレターもあります。
- Clouderaでは人材募集中！
感想など
- 使ったことはないですが、ほんとCloudera Managerは便利そうだと思いました。前職でも設定ファイルの更新漏れとかあった気がしますので。ログを一括して検索できたりするのは超絶便利だと思います。
- ヒートマップとかのモニタも便利なのは間違いないと思います。
- ちなみに、AWS上でのCloudera Managerのインストールはこちらをご参照ください。ほんと簡単にできるようですｗ Cloudera ManagerとCDHをAWS EC2にインストールしてみた
Hadoop コミュニティと YARN の現状
- 講演者：日本電信電話株式会社 ソフトウェアイノベーションセンタ 分散処理基盤プロジェクト 小沢 健史 氏
- http://www.cloudera.co.jp/jpevents/cwt2013/session/026.html
概要
- Tsuyoshi Ozawa
- NTTでリサーチエンジニア
- Hadoopのコントリビューター
- 100patchぐらい送っている
- Hadoop徹底入門2版のYARNの章を書いている
- NTTとHadoop
- なぜHadoop
- 従来はPostgreSQLをやっていたが、データ量が多い場合の対応として取り組んだ
- なぜRDBMSは小さなデータに対して優れているか？
- Schme on Write
- 書き込み時にスキーマに応じて書き込むことで物理配置を最適化
- Hadoopは
- Schme on Read
- 読み込み時にスキーマを適用するので最低限のオーバーヘットがかかる
- NTT自身もユーザーとして利用している
- NTT Dataさんでも導入している
- なぜHadoopコミュニケーションにコントリビューションしたか？
- コミュニティとNTTのニーズに合わないものがあった。
- MapReduceV2が出ても未だにドキュメントがV1のままでそのままでは動かない
- ログが見づらいなどなど
- なので自分で書くことでギャップを埋めようとした。
- 欲しい新機能があればそこを開発するとか。
- 例
- コミュニティとやりたいことが一致したケース
- 運用をより簡単にする
- MapReduceの最適化
- 一致しなかったケース
- 間違った設定を入れるとIllegalArgumentExceptionになっている。どうしたらよいか分からない。
- コミュニティとやりたいことが一致したケース
- コミュニティとNTTのニーズに合わないものがあった。
- 最近やっていること
- コントリビューション
- ResourceManager HA
- 問題点
- シリコン・バレーが中心でタイムラグが17時間あって大変。
- コントリビューション
- NTTだけでなくNTTデータも貢献している。4人コントリビューターがいる。
- なぜHadoop
- Technical Part
- MapReduce
- Shuffle Plugin(MAPREDUCE-4049)
- インフィニバンドでつなぐとローカルに書き込むのが無駄になるが、ユースケースが限られるのでまずはplugableにした。
- MapReduce itself is at stable phase
- Tez/Spark/Impla
- Shuffle Plugin(MAPREDUCE-4049)
- HDFS
- Cach management(HDFS-4949)
- Snapshot(HDFS-2802)
- 単なるコピーだと容量が2倍になるので、差分バックアップとしている。
- Symbolic links(HADOOP-6421)
- YARNとは
- Yet Another Resouce Negotiator
- JobTrackerの役割を2つに分担
- リソース管理
- タスク管理
- MapReduce v2 というとはYARN上で動くMapReduceのことを指す
- なぜYARN
- 様々な種類の処理フレームワークを同じクラスタで実行する
- バッチはMapReduce
- インタラクティブなクエリはImpala
- インタラクティブに高度な分析（機械学習など）はSpark
- MapReduceで繰り返し処理をするとディスクI/Oにコストがかかるので、ここをメモリに書き込むことで高速化できるようにしたもの
- 詳しく知りたい方は徹底入門第2版を買ってください(^^) Hadoop徹底入門 第2版 オープンソース分散処理環境の構築
- 例えばMapReduceとImpalaを同時に動かすとslashingしてしまう。なので、全体のリソース管理をできるようにリソース管理を分離して一元化した。
- Apache Mesosと同じでは？
- だいたい同じ。
- YARNは大規模向け
- ジョブが1000個あってもMasterがジョブごとに作られるのでそこがネックにならない。
- Mesosは小規模向け
- Lower Latency
- マスターが1つなので、スケール時にそこがネックになる
- MapReduce以外あるの？
- すでに17個もあった。
- YARN is becoming a real open kernel! YARN Applications のp20
- GiraphとかSparkなど
- ClouderaもLlamaで本腰を入れて取り組んでいるようにみえる
- ホットトピック
- ResourceManagerが新たなSPOFになったのでそこをHA化
- 落ちるとジョブが実行できなくなる。
- 対応はZookeeperに情報を外出し
- HDFSと同じ対応
- Llama
- ImpalaはLow LatancyなのにAMだとプロセス立ち上げてそこで時間を食う。
- なのでAMを再利用することでそこの時間を削る。
- Multitenant Platform
- Hoya : HBase on YARN
- ResourceManagerが新たなSPOFになったのでそこをHA化
- まとめ
- NTTはHaoopを使っているし、コントリビューションもしています。
- MapReduce
感想など
- 非常に濃くて、雰囲気もHadoopソースコードリーディングみたいな感じで楽しかったです。
- YARNが出てきた背景について説明がありましたが、やっとここで理解出来ました。確かにHBaseに利用しているクラスタ上でMapReduceV1を動かすとHBaseがコケるという話も聞いたことがありますし。そのためJobTrackerの役割をリソース管理とタスク管理に分離することで、クラスタ全体でリソース管理をできるようにするのが目的だったんですね。
- ResourceManagerが新たなSPOFになったというのは、HDFSでも最初のHAでNFSを利用してそこがSPOFというのがあって、ちょっとおもしろかったですｗ とはいえ、HA対応というのはまじめにやると時間がかかるのも当然な気はしますし、まずは動くものを出そうという姿勢もわからなくはないなぁと思いました。
14
