============================================ Java読書会BOF 「Hadoop 第2版」を読む会 第6回 ============================================ .. csv-table:: 開催概要 "日時", "2012年3月17日(土) 10:00 - 17:00" "場所", "川崎市教育文化会館 第３会議室" "出席者(敬称略)", "村山、松永、高橋(智)、門脇、高橋(徹)、岩室、吉本、今井(書記)" "会場費", "300円/ひとり" 議事 ==== 10章 Hadoopクラスタの管理 ------------------------- 10.1 HDFS --------- 10.1.1 永続的データ構造 ----------------------- * (本節とは直接関係無いが、)100～1000ノードあるようなクラスタのVer.UPは 大変そうだがどうやってするのだろう？ 一度システムをとめるのか？ 動かしたまま一部分ずつVer.UPしていくのか？ -> 本書のあとのほうで出てくるようだ。 10.1.1.1 ネームノードのディレクトリ構造 --------------------------------------- 10.1.1.2 ファイルシステムのイメージと編集ログ --------------------------------------------- 10.1.1.3 セカンダリネームノードのディレクトリ構造 ------------------------------------------------- 10.1.1.4 データノードのディレクトリ構造 --------------------------------------- 10.1.2 セーフモード ------------------- 10.1.3 監査ログ --------------- 10.1.4 ツール ------------- 10.1.4.1 dfsadmin ----------------- * 誤字 p.323 表10-2 -upgradeProgressの説明内 アップフレード -> アップグレード 10.1.4.2 ファイルシステムのチェック(fsck) ----------------------------------------- * 脱字 p.325 中ほど 箇条書き -deleteオプションを... の行末 削除されファイルは -> 削除されたファイルは 10.1.4.3 データノードブロックスキャナ ------------------------------------- 10.1.4.4 バランサー ------------------- 10.2 モニタリング ----------------- 10.2.1 ロギング --------------- 10.2.1.1 ログレベルの設定 ------------------------- 10.2.1.2 スタックトレースの取得 ------------------------------- 10.2.2 メトリクス ----------------- 10.2.2.1 FileContext -------------------- * p.331 ログファイル出力例 * 時刻は出力されないのだろうか? * 何につかうのだろう? * 管理者がグラフ化して変化をみるとか。 10.2.2.2 GangliaContext ----------------------- * p.331 * GangliaはHadoop専用のツールではない。 * Log4JのAppenderでGlangliaに送ることができる? * 結構著明なところでけっこう使われている様だ。 * グラフ化は結構自分ですると面倒なので、外部に出しても良いような データであれば便利だと思う。 10.2.2.3 NullContextWithUpdateThread ------------------------------------ 10.2.2.4 CompositeContext ------------------------- * p.332 ``jvm.filename`` や ``jvm.servers`` には、 ``sub1`` や ``sub2`` などの サブコンテキスト番号は無くても良いのか? -> サブコンテキスト番号が無い場合は全コンテキスト共通の定義になる。 ``filename`` は全体共通の定義になるがsub2のGangliaContextでは関係ないから 結果的にsub1のFileContexだけのための定義になっているのではないか。 ``servers`` もGangliaContextだけのための定義になっているのではないか。 10.2.3 Java Management Extensions --------------------------------- 10.3 メンテナンス ----------------- 10.3.1 ルーチンの管理手順 ------------------------- 10.3.1.1 メタデータのバックアップ --------------------------------- 10.3.1.2 データのバックアップ ----------------------------- * p.336 l.5 カッコ内の「できればバージョンの異なるHDFSが動作していること」は なぜ好ましいのか？ * 新しいものはバグが含まれていることが多いから。 * 同じバージョンではバグがあった場合、バグのために全HDFSが同時に 駄目になり、データが失われる可能性が高いから。 10.3.1.3 ファイルシステムのチェック ----------------------------------- 10.3.1.4 ファイルシステムのバランサー ------------------------------------- 10.3.2 ノードの参加と脱退 ------------------------- 10.3.2.1 新しいノードの参加 --------------------------- 10.3.2.2 古いノードの脱退 ------------------------- 10.3.3 アップグレード --------------------- 10.3.3.1 HDFSのデータとメタデータのアップグレード ------------------------------------------------- * p.341 最下行 ``/previous/VERSION`` は、上の ``/current`` と同じ位置(インデント)だろう。 * p.342 中ほどの「アップグレードの確認」l.1 * 「この出力が表示されたら、」の「この」はどれ? -> 下記2行のこと:: Upgrade for versio -18 has been completed. Upgrade is not finalized. * is not finalized はおかしい？ -> この後、オプションでロールバックかファイナライズするから、 まだファイナライズしていないと注意しているだけ。 * p.342 アップグレードのロールバックは、メタデータだけが変わっているから 新しいものを捨てて、古いものを生かせば容易にできるのだろう。 11章 Pig -------- 11.1 Pigのインストールと実行 ---------------------------- 11.1.1 実行の種類 ----------------- 11.1.1.1 ローカルモード ----------------------- * p.347 プロンプトの ``grunt`` は、豚の鳴き声 11.1.1.2 MapReduceモード ------------------------ 11.1.2 Pigプログラムの実行 -------------------------- 11.1.3 Grunt ------------ 11.1.4 Pig Latinのエディタ -------------------------- * p.349 PigPenは、豚小屋 * p.349 Pig Latinとは言葉あそびのこと。p.354の脚注にあった。 11.2 例 ------- * pp.351-352 * データ量が大量のときはどうなるのだろう。結果の保存でリソースが足りなくなる とかにはならないのか? * ``filtered_records`` などの左辺には右辺の結果が入るのではなく、ステートメント が入るだけで、DUMPで実行されるのではないだろうか。であれば最後に絞り込まれて いれば、途中のデータ量は気にしなくても良いはず。 * p.357 に、:: Pigが処理を開始するきっかけになるのは、DUMPステートメントです。... とある。 11.2.1 サンプルの生成 --------------------- * pp.352-353 tenperature 9999 など、元のデータにないデータも出ていることに注目 * quality が 1 しか無いのはなぜ? * 0, 4, 5, 9 は、1と同じ扱いで特殊な値ではないから? * それ以外の値はステートメントからどんな値があるかわからないから? 11.3 データベースとの比較 ------------------------- 11.4 Pig Latin -------------- 11.4.1 構造 ----------- 11.4.2 ステートメント --------------------- 11.4.3 式 --------- 11.4.4 型 --------- * 誤字 p.360 下からl.4 PigStorate -> PigStorage * p.361 表11-6 マップ型の説明 「アトム」ってさらっと書いているけど、「アトム」が何なのかの説明はないなぁ。 11.4.5 スキーマ --------------- 11.4.5.1 バリデーションとnull ----------------------------- 11.4.5.2 スキーマのマージ ------------------------- 11.4.6 関数 ----------- 11.5 ユーザー定義関数 --------------------- 11.5.1 フィルタUDF ------------------ 11.5.1.1 型の活用 ----------------- 11.5.2 評価UDF -------------- 11.5.3 ロードUDF ---------------- 11.5.3.1 スキーマの利用 ----------------------- 11.6 データ処理オペレータ ------------------------- 11.6.1 データのロードとストア ----------------------------- 11.6.2 データのフィルタリング ----------------------------- 11.6.2.1 FOREACH...GENERATE --------------------------- * p.378 year_stats.pigの下からl.5 GENERATE FLATTEN(group) の、groupはどこで定義されているのか? * FOREACH grouped_records の後に、GENERATE groupが抜けている のでないか? -> × * p.385 「11.6.3.4 GROUP」によると、``GROUP`` がグループ化に使用された フィールドにgroupというエイリアスをつけるらしい。 * 何度もGROUPすると、groupエイリアスは上書きされるのか? -> GRUOPのステートメントが代入(?)されている、grouped_records の group という意味だから、他とぶつかることはないはず。 11.6.2.2 STREAM --------------- 11.6.3 データのグループ化と結合 ------------------------------- 11.6.3.1 JOIN ------------- 11.6.3.2 COGROUP ---------------- * p.383 max_temp_station_name.pigのコード IsGoodQuality()は一度しか使用されないのにDEFINEされていて、 CutLoadFunc()は二度使用されているのにDEFINEされていない。 11.6.3.3 CROSS -------------- 11.6.3.4 GROUP -------------- 11.6.4 データのソート --------------------- 11.6.5　データのUNIONと分割 --------------------------- .. note:: 次回は、p.388「11.7 実践Pig」からです。