Downloaded 64 times
![[CWT2017]Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ環境の変化](https://cdn.slidesharecdn.com/ss_thumbnails/dlcwt2017infrastructureascodef-171108044056-thumbnail.jpg?width=640&height=640&fit=bounds)
CDH4.1オーバービュー
- 1. CDH4.1オーバービュー Cloudera カスタマーオペレーションズエンジニア 嶋内 翔 2012年11月7日 1
- 2. アジェンダ • CDH概要とその歴史 • CDH4での変更点 • HDFS HA • HDFS HA(QJMベース) • MapReduce v2 • Flume NG 2
- 3. 自己紹介 • 嶋内 翔(しまうち しょう) • 2011年4月にClouderaの最初の日本人社員として入 社 • カスタマーオペレーションズエンジニアとしてテクニ カルサポート業務を担当 • email: sho@cloudera.com • twiHer: @shiumachi 3
- 4.
- 5. CDHとは何か? • Cloudera’s DistribuMon including Apache Hadoop • エンタープライズ向けに開発された100%オープン ソースのHadoopディストリビューション • Apache Hadoopを中心に、10以上のオープンソース コンポーネントを含む 5
- 6. CDH 開発の歴史 2012/06 § 高可用性ネームノード(NFS) § 複数のデータ処理フレームワーク（MR1とMR2） Q3 2009 Q2 2011 § etc… 2009 2010 2011 2012 2012/06 2012/09 2012/09 Q1 2010 § 高可用性ネームノード(クォーラムベースストレージ) § Hue の Oozie ワークフローGUI と日本語化 § 統計分析用PigライブラリDataFu § etc… 6
- 7. CDHの主要コンポーネント Webインタフェースと HadoopとRDBMSとの連携 分散ログストリーミング処理 ビルド/テスト: APACHE BIGTOP フレームワーク APACHE Sqoop APACHE Flume Hue クラウドでの分散処理ライブラリ ワークフローとスケジューリング APACHE Whirr APACHE Oozie 分散協調サービス 高級言語とライブラリ APACHE ZooKeeper APACHE Hive, APACHE Pig, APACHE Mahout 分散データベース 大規模分散処理基盤 APACHE HBase APACHE MapReduce 分散ファイルシステム APACHE HDFS 7
- 8.
- 9. CDH4リリース番号 • リリース番号の表記が変わりました • CDH3 以前: CDH3u0, CDH3u1, CDH3u2 … • CDH4: CDH X.Y.Z • X: メジャーバージョン(大規模な変更を含む) • Y: マイナーバージョン(CDH3以前の update に相当) • Z: ポイントバージョン(重大なバグ修正のみ) • 最新版は CDH4.1.1 • 多分もうすぐCDH4.1.2が出ます 9
- 10. コンポーネントバージョン一覧 コンポーネント CDH3u5 CDH4.1.1 Avro 1.5.4 1.5.4 FlumeOG 0.9.4 -‐-‐ (0.9.4) FlumeNG 1.2.0 1.2.0 Hadoop 0.20.2 2.0.0 Hadoop MRv1 -‐-‐ 0.20.2 HBase 0.90.4 0.92.1 Hive 0.7.1 0.9.0 Hue 1.2.0.0 2.1.0 10
- 11. コンポーネントバージョン一覧 コンポーネント CDH3u5 CDH4.1.1 Mahout 0.5 0.7 Oozie 2.3.2 3.2.0 Pig 0.8.1 0.10.0 DataFu (Pig UDF ライブラリ) -‐-‐ 0.0.4 Sqoop 1.3.0 1.4.1 Whirr 0.5.0 0.8.0 ZooKeeper 3.3.5 3.4.3 11
- 12. Hadoop • 大きな変更 • MapReduce version 2 (YARN というフレームワークがベース) • HDFS HA(高可用 HDFS) • NFS共有ディレクトリ(CDH4.0) • クォーラムベースストレージ共有ディレクトリ(CDH4.1) • HDFS フェデレーション • パラメータ名が大きく変更 • 例: fs.default.name は fs.defaultFS に変更 • 古いパラメータ名を使っていても deprecated という WARN ログ が出るだけで実害なし • 既存のMapReduceアプリケーションはそのままCDH4で 使用可能 • ただしCDH4環境で再コンパイルが必要 12
- 13. Hadoop (続き) • REST over HTTPインタフェースの追加 • HHpFs • WebHDFS • MapReduceシャッフルフェーズでの暗号化(CDH4.1) • libhdfs でのダイレクト読み込み(HDFS-‐2834, HDFS-‐3110) (CDH4.1) • C++ クライアントからの読み込みが2-‐3倍高速になった • Impala が高速な理由の一つ 13
- 14. HBase • コプロセッサ(HBASE-‐2000) • HFile v2 (HBASE-‐3857) • 分散ログスプリッティング • その他さまざまな機能追加 • Web UI の表示情報量が増えた • ログからスロークエリを調べやすくなった 14
- 15. Hive • 新しいデータ型のサポート • BINARY (HIVE-‐2380) • TIMESTAMP (HIVE-‐2272) • JDBC日付文字列フォーマット準拠の形式 • ビットマップインデックス(HIVE-‐1803) • hHps://cwiki.apache.org/confluence/display/Hive/IndexDev+Bitmap • プラグイン・デベロッパ・キット(PDK)(HIVE-‐2244) • Hive拡張を作りやすくする • 現在UDFのみサポート • hHps://cwiki.apache.org/confluence/display/Hive/PluginDeveloperKit • JDBCドライバの改善 • Hiveserver2 (HIVE-‐2935) (CDH4.1) • 複数ユーザからの同時接続など、従来のHiveserverにはなかった機 能を追加 15
- 16. Pig • UDFでJavaScriptサポート(PIG-‐1794) • 組み込みPig(PIG-‐1479) • Python, Ruby でもUDFを記述可能 • hHp://archive.cloudera.com/cdh4/cdh/4/pig/udf.html • マクロ(PIG-‐1793) • define my_macro(A, sortkey) returns C { … } という形式でマクロを定義 可能 • project-‐range 記法(PIG-‐1693) • col0, col1 .. col3 と書くと、 col0, col1, col2, col3 に展開してくれる • hHp://archive.cloudera.com/cdh4/cdh/4/pig/basic.html#expressions • その他の機能・改善 • エラーメッセージの改善 • combinerの最適化 • ILLUSTRATE コマンドのバグ修正 16
- 17. CDH4.1 DataFu • 統計分析用 Pig UDF(ユーザ定義関数)ライブラリ • LinkedIn が開発 • PageRank、セッション化といった高度なデータ解析に 役立つライブラリ集 ranks = FOREACH edges GENERATE group as topic, FLATTEN(PageRank(edges.(s,e))) as (source,rank); 17
- 18. Flume • Flume NG (1.x 系) • 従来のFlume (以下 Flume OG) を大きくリファクタリング • Flume NG = New GeneraMon (新世代) • Flume OG = Old GeneraMon (旧世代) • HBase シンクのサポート(CDH4.1) • Flume OG (0.9.x 系) • CDH4 でもアドオンとして利用可能 18
- 19. Oozie • DistCp アクションのサポート (OOZIE-‐11) • 「バンドル」を追加 • コーディネートジョブ(定期実行ジョブ)をグループ化できる • サポートするDBの追加 • MySQL, Oracle は以前から使える • PostgreSQL(OOZIE-‐22, CDH3u2以降でも使用可) 19
- 20. Sqoop • カスタムタイプマッピング(SQOOP-‐342) • hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/ SqoopUserGuide.html#_controlling_type_mapping • 今までDBスキーマの型とJava/Hiveの型のマッピングは自動だったが、これにより任意のマッ ピングを行えるようになった • -‐-‐map-‐column-‐java, -‐-‐map-‐column-‐hive オプションで指定 • 境界クエリサポート(SQOOP-‐331) • hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/ SqoopUserGuide.html#_selecMng_the_data_to_import • 今までは -‐-‐split-‐by で指定した列の最大と最小の値を元に、分割するときの境界線を決めて いた • -‐-‐boundary-‐query により、境界条件を決定するためのクエリを任意に指定できるようになった • Date/Time インクリメンタルアペンド(SQOOP-‐321) • hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/ SqoopUserGuide.html#_incremental_imports • 今までは数値のみがインクリメンタルインポートの対象だったが、これにより日付型も対象に • IBM DB2 コネクタのサポート(SQOOP-‐329) • 将来のCDH4 では Sqoop2 を追加する予定 20
- 21. Whirr • サポート対象サービスの追加 • MapReduce v2 (YARN) • Chef (WHIRR-‐49) • Ganglia(WHIRR-‐258) • Mahout (WHIRR-‐384) • EC2クラスタコンピュートグループのサポート(WHIRR-‐63) (CDH4.1) • Chef はメインストリームのサービスには(まだ)使われていな い • 今後の設定管理の自動化に期待 • Mahout インストールが可能に • CDHバージョンではないことに注意 • CDH4 ではさらに追加設定パラメータあり • 詳細はドキュメント参照 21
- 22. Hue • Hue2 にメジャーアップデート • UIが大きく変更。Cloudera Manager に近くなった • 旧UIで問題となっていたメモリリークを解決 • HDFS ファイルブラウザのためにDN/NNへのプラグイン を導入する必要がなくなった • OpenLDAPやAcMveDirectory からユーザをインポートで きるようになった • OozieからMapReduceジョブを実行するようになった • Oozie ワークフロービルダー(CDH4.1) • アプリケーション単位のアクセスコントロール • 日本語対応！ • Hue 1.x 系の SDK とは非互換なので注意 22
- 23.
- 24.
- 25.
- 26. HDFS HA(高可用性 HDFS) • 従来のHadoopではネームノードは単一障害点 (SPOF)だった • ネームノードのダウンタイム発生ケースは2種類 • 障害停止(低確率) • 計画停止(確実に発生) • 現在はHDFS HA機能があるためSPOFはなくなった • 上記のダウンタイムの問題は解決できる • 自動フェイルオーバ可能 • 特殊なサーバを必要とせず、Hadoopと同じスペック のノードで構築可能(CDH4.1) 26
- 27. HDFS HA アーキテクチャ • ネームノードのペアを使う • アクティブとスタンバイ • クライアントとデータノードはアクティブNNとのみ通信する • スタンバイNNは共有ストレージを参照してアクティブノード の状態を取得可能 • スタンバイネームノードはチェックポイントを行う • よってHAではセカンダリネームノードは不要 27
- 28. アーキテクチャ Daemon Daemon リーダー選択 ZooKeeper リーダー選択 フェイルオーバ フェイルオーバ コントローラ コントローラ 状態監視 editlog 状態監視 コマンド 編集ログ コマンド (フェンシング) ネームノード ネームノード (アクティブ) (スタンバイ) Daemon Daemon データノード ブロックレポート ブロックレポート 28
- 29. フェイルオーバとフェンシング • 起動時にアクティブなNNを選出 • 必ず1個のアクティブしか起動しないことを保証 • CDH4では手動・自動フェイルオーバをサポート • スプリットブレイン時のデータ破壊を防ぐ • 共有リソースのフェンシング • DN、及び共有ストレージ上のNNのメタデータ • NNのフェンシング • 共有リソースをフェンスできなかった場合 • クライアントフェイルオーバ • クライアントはフェイルオーバ後に新しいNNにアクセスで きる 29
- 30. 手動フェイルオーバの方法 • hdfs haadmin -‐failover nn01 nn02 • 手動フェイルオーバはこのコマンドで実行 • フェンシングとスタンバイNNへのフェイルオーバを実施 30
- 31. 自動フェイルオーバ • 自動フェイルオーバはZooKeeperを使う • ZooKeeper はHBaseでも使われている協調サービス • 設定方法は以下のような流れ 1. NNで自動フェイルオーバ用の設定を行う 2. NNを起動する 3. ZooKeeper フェイルオーバコントローラ(ZKFC)デーモンを 起動する • ZKFCは全NNと同一ノードで起動しなければいけない • 運用監視ソフトからもZKFCを監視するのを忘れずに 31
- 32. 自動フェイルオーバの流れ • 単純に kill -‐9 するだけ • フェイルオーバは5秒で開始される • デフォルト値。設定変更可能 • ha.zookeeper.session-‐Mmeout.ms (ミリ秒単位) 32
- 33. CDH4.1 HDFS HA (QJMベース) 33
- 34. HDFS HA での共有ストレージ • スタンバイNNは、アクティブNNのトランザクションロ グ(edits)を読み込むことで名前空間を同期する • mkdir(/foo) などの操作はアクティブNNによってロギング される • スタンバイNNは定期的に新しいeditsを読み込み、自身の メタデータを最新に保つ • よって高信頼な共有ストレージはcorrectな(正しい) オペレーションに必須 34
- 35. 共有ストレージ(フェーズ1) • 運用者は従来の共有ストレージデバイスを設定する (SAN, NAS) • アクティブ/スタンバイの両方のNNから共有ストレー ジをNFSマウントする • アクティブNNが書き込み、スタンバイNNが読み込む 35
- 36. NFSベースのアーキテクチャ Daemon Daemon リーダー選択 ZooKeeper リーダー選択 フェイルオーバ フェイルオーバ コントローラ コントローラ 共有ストレージ(NFS) 状態監視 editlog 状態監視 コマンド 編集ログ コマンド (フェンシング) ネームノード ネームノード (アクティブ) (スタンバイ) Daemon Daemon データノード ブロックレポート ブロックレポート 36
- 37. NFSベースの手法の欠点 • カスタムハードウェア • 多くのお客様はデータセンタにSAN/NASを持っていない • 多くのお金、時間がかかり、高い専門性が必要 • HDFS外から監視する別システムが必要 • SPOFを外に出しただけで、なくしたわけじゃない • 複雑 • ストレージのフェンシング、NFSマウントオプション、ボン ディング、etc. • NFS自身の問題 • クライアントの実装にバグが多い、タイムアウト時の挙動 のコントロールが大変、etc. 37
- 38. ストレージの改善のための要件 • 特別なハードウェアを必要としないこと(PDU、NAS) • カスタムのフェンシング設定を必要としないこと • 設定が複雑＝設定ミスしやすい • SPOFがないこと • ストレージにSPOFを丸投げするのはよくない • 完全な分散システムが必要 38
- 39. ストレージ改善のための要件(続き) • 耐障害性 • Nノードクラスタが(N-‐1)/2ノードまでの耐障害性を持つこと • スケーラビリティを持つこと • 書き込みは並列に行われる • 書き込みが遅いノードを待たない • 既存のハードウェアに共存可能であること(JT、NN、 SBNなどと共有) 39
- 40. CDH4.1 QuorumJournalManager • QuorumJournalManager(クライアント) • クォーラムジャーナルマネージャ • JournalManager インタフェースの実装 • FileJournalManager 実装の置き換え • JournalNode(サーバ) • ジャーナルノード • 奇数ノードで稼働するスタンドアロンデーモン • editsの書き込み先ストレージとして機能 • 将来的には他のデーモン内部で稼働できるようにする予 定 40
- 41. CDH4.1 QJMベースのアーキテクチャ Daemon Daemon リーダー選択 ZooKeeper リーダー選択 フェイルオーバ ローカル フェイルオーバ コントローラ ストレージ コントローラ 状態監視 ジャーナル 状態監視 ノード コマンド コマンド ネームノード ネームノード (アクティブ) (スタンバイ) Daemon Daemon データノード ブロックレポート ブロックレポート 41
- 42. CDH4.1 QJMベースのアーキテクチャ NameNode Quorum JournalManager JournalNode JournalNode JournalNode ローカルディスク ローカルディスク ローカルディスク 42
- 43. CDH4.1 コミットプロトコル • NNはローカルのeditsに書き込む • FSEditLog.logSync()により全てのJNにHadoop RPC を 通じてeditsを送信する • CDH4からeditsは細かく分割されているためデータは小さ い • 過半数のノードから成功のACKが返るのを待つ • これにより遅いJNや障害の発生したJNがNNのレイテンシ に与える影響を最小限にとどめることが可能 • NNのレイテンシ ≒ JNのレイテンシの中間値 43
- 44. CDH4.1 ジャーナルノードのフェンシング • QJMインスタンスにはユニークなエポック番号が割り 当てられる • クライアントNN間での強い順序付けを提供 • それぞれの IPC はクライアントのエポックを持つ • JNは今まで見たことのある最も高いエポックをディスク上 に保持する • その値よりも小さいエポックからのリクエストは全て拒否 する。その値よりも大きいエポックはディスクに記録される • Paxos 等でも使われている手法 44
- 45. CDH4.1 エポックを使ったフェンシング • 暗黙的にフェンシングを行う • NNがアクティブになると、それより前のアクティブNN はフェンスアウトされる • 新しいアクティブNNはより高いエポック数を持つ • よって一旦新しいアクティブNNからのリクエストを受け入 れたJNはエポック数を更新するため、古いアクティブNNか らのリクエストを受けつけない • これにより、複雑で間違いやすいカスタムフェンシン グの設定をなくすことができた 45
- 46. CDH4.1 セグメントリカバリ • 通常、過半数に満たないJNは同期されない • 障害発生後、全てのJNは異なる数のトランザクションを 持ちうる • 例: JN1 がダウンし、JN2はトランザクションID150が書き込まれ る前にクラッシュした • JN1: edits なし • JN2: edits 101-‐149 を持つ • JN3: edits 101-‐150 を持つ • アクティブになる前、最後のバッチについてコンセンサス をとる必要がある • コンセンサスの解決には Paxos アルゴリズムを使ってい る 46
- 47.
- 48. MapReduce v2 (MRv2) • Apache Hadoop 0.23 系(現 2.0 系) で開発された • CDH4より導入 • 汎用分散処理フレームワークYARNの上で実装 • MapReduce以外の分散処理にも対応 • Hamster: MPI • Hama: バルクシンクロナスプロセッシング BSP • Giraph: グラフ処理 • 超大規模クラスタを構築可能(最大10000ノード) • MRv1 では最大4000ノード • アーキテクチャが大きく変更された • APIは変更なし。よってMRプログラムは再コンパイルするだけで動作する • コミュニティ版では MRv2 のみ使用可能だがCDH4では MRv1、MRv2 両 方使用可能 • CDH4.1では商用環境でMRv1の利用を推奨 • MRv2はまだ開発用途としての利用を推奨 48
- 49. MRv1のアーキテクチャ MapReduce Job Submission • MRv1 には JobTrackerとTaskTracker の2つのサービ スがある A client submits a job to the JobTracker • – JobTracker assigns a job ID JobTracker(マスタ): 1クラスタに1つ – Client calculates the input splits for the job • TaskTracker(スレーブ): 1クラスタに多数 – Client adds job code and configuration to HDFS Client TaskTracker JobTracker TaskTracker TaskTracker TaskTracker 49
- 50. MRv2のアーキテクチャ (cont’d) MRv2 System Architecture Slave nodes run individual tasks similar to MRv1 • ResourceManagerとNodeManager ResourceManager(マスタ): 1クラスタに1つ • For each job, one slave node is Application Master • NodeManager(スレーブ): 1クラスタに多数 – Manages application lifecycle • ジョブ毎に、スレーブノードはApplicaMonMaster を動作させる – Negotiates resource “containers” from Resource Manager • このApploicaMonMaster が1回のMRジョブを管理する – Monitors tasks running on the other slave nodes Node Manager Node Manager App Master - Job #2 Resource Manager Scheduler Application Manager App Master - Job #1 Node Manager Node Manager Copyright © 2010-2012 Cloudera. All rights reserved. Not to be reproduced without prior written consent. 04-27 50
- 51.
- 52. Flume オーバービュー • Flume は生成される大量のデータを効率よく移動させる ための分散サービス • ログデータを直接HDFSに投入するのに理想的 • 従来は Flume OG がメインだった • CDH3 から追加 • CDH4 ではアドオンとして利用可能だが、フェードアウトする予 定 • Flume NG は CDH4 の一部として存在 • Flume NG の API は Flume OG と非互換 • しかし大半のコンセプトは Flume NG でもそのまま使われている • よりわかりやすくシンプルなアーキテクチャ • メモリ消費量が少なくなった 52
- 53. Flume の構成例 Webサーバ エージェント エージェント メールサーバ エージェント エージェント Unix syslog エージェント 圧縮 暗号化 Hadoop クラスタ 53
- 54. Flume NG アーキテクチャ概要 • プロデューサ・コンシューマモデル • 多くのコンポーネントがプラガブル コンポーネント 機能 Agent(エージェント) Flumeが動作するJVM。複数のソースとシンクを持つ Source(ソース) データをイベントの形式で生成する。個別のスレッドで動作 Sink(シンク) チャネルからイベントを受け取る。個別のスレッドで動作 Channel(チャネル) ソースとシンクを接続する(キューのように) Event(イベント) 単一のデータ。例: ログ1行、AVROオブジェクト、etc 54
- 55.
- 56. まとめ • CDHはHadoopをエンタープライズでも使えるようにし たオープンソースのディストリビューションです • CDH4ではHDFS HAを始め、プロダクションで運用す るための便利な機能が追加されています Hadoop を使うなら まずCDH4を選びましょう ダウンロードはこちら hHp://www.cloudera.com/downloads/ 56
- 57. CDHコミュニティ・MLの紹介 CDH ユーザ メーリングリスト(日本語) cdh-‐user-‐jp@cloudera.org CDH の質問についてはこちら Cloudera ニュースレター hHp://www.cloudera.co.jp/newsleHer Cloudera に関するニュースをお届けします CDHの最新情報・使い方なども紹介します 57
- 58.