読書会(Hadoop 第2版)第2回議事録

[ 戻る ]


Java読書会「Hadoop 第2版」を読む会 第2回 議事録

日時: 2011年11月26日(土) 10:00-17:00
場所: 川崎市産業振興会館 第1会議
参加者: 根本、小棚木、遠藤、高橋(智)、松永、門脇、高橋(徹)、村山、石黒、吉本、今井
書記: 今井
範囲: 3.5.5.2 ファイルのリスト(p.63) 〜 4.3.5.1 Avroのデータ型とスキーマ(p.116)

--------

# 3章 Hadoop分散ファイルシステム
# 3.5 Javaインターフェース
# 3.5.5 ファイルシステムへの問い合わせ

3.5.5.2 ファイルのリスト

3.5.5.3 ファイルパターン

- “グロビング”って一般的な言葉?
 * 文字列一般の話ではなくワイルドカード寄りの言葉だと思う
 * 野球のグローブみたいにガバっととるイメージか。

- パスに日本語は使えるのだろうか?
 * 文字コードだとか、濁音などの合成文字だとか、長音だとか、いろいろあって、
  グロビングが大変そう。
 * そもそも文字コードは何だろう? UNICODE ?
 【宿題】日本語パス名を試してみる

3.5.5.4 パスフィルタ

- globStatus()でPathFilterは一つしか指定できないの?
 * 正規表現でかけるので、正規表現中で複数フィルタを書くことはできる
 * フィルタをピリオドでつなげていくという感じで使いたい
 * 複数フィルタを指定できるPathFilterサブクラスを作ってもよさそう

3.5.6 データの削除

- 「ファイルやディレクトリを完全に削除することができる」(l.1)とあるが、
 参照が消えるだけで実体は消えないのではないだろうか。

- 「(ディレクトリが空でなかった場合は、IOExceptionが投げられます)」は、
 recursiveがfalseの時の事だろう。

- パスの階層に制限はあるのだろうか。

3.6 データフロー

3.6.1 ファイル読み込みの解剖学

- p.69 l.1「(ブロックの所在はメモリに記憶されているので、...」のメモリは、
 どこのメモリ? → クライアントノードだろう。

- クライアントノード、ネームノード、データノードは別システムだと思うが、
 遠くにある時にプロキシなどはどうなるのだろう。

- コラム「ネットワークトポロジとHadoop」の距離はどうして偶数ばかり?
 * パスを上がって1、降りて1と数えている。例えば、同一ラック内別ノードでは、
  /d1/r1/n1 -> /d1/r1 -> /d1/r1/n2 で、距離は2。

3.6.2 ファイル書き込みの解剖学

- HDFSでなくOracleなどの仮想FS上で構築しても良いのではないか
 * RDBMSではスケールしなさそう
 * Oracleでもマルチマスターもある。でも高額。
 * 一台にHDではシークタイムなどに限界があり、大量データでは処理が
  追いつかないからHDFSを使うという前提もある。
 * そもそも、対象にするデータの性質が違うのではないか。

3.6.3 一貫性モデル

- 脚注†の最後、「まだデータがディスクキャッシュの中に残っている可能性は
 あります。」の「キャッシュ」は、ハードディスクドライブ上のキャッシュの
 ことだよね。

- FSDataOutputStream#flush()は何をしているのだろう。

3.6.3.1 アプリケーションのデザインにもたらす影響

3.7 distcpによる並列コピー

- HDFSをブラウズできるようなツールはないのだろうか?
 * クラウディア社が出しているらしい。

- p.76中ほどの、ファイルサイズ1GBとか1,000GBとかは、一ファイルのことではなく
 ファイル群のことではないか。原書ではFilesになってないか。(filesでした。imai)

- mapでコピーするというのは普通のこと?
 * mapはon memoryで入力map出力mapで、外部に対する副作用はないのが普通だと
  思っていたのだが。
 * mapでコピーがどのように実装されているのかが気になる。

3.7.1 HDFSクラスタのバランス調整

3.8 Hadoopアーカイブ

3.8.1 Hadoopアーカイブの使用

- harにするとdistcpで一つのファイルとして効率よくコピーできるのだろうか?
 * harはそれほど凝ったことはしていない。複数ファイルを一箇所で持っているだけ。

3.8.2 制限事項


4章 HadoopのI/O

4.1 データの整合性

4.1.1 HDFSにおけるデータの整合性

- p.82 l.2 誤字
 CRC-32に4バイト長なので、 → CRC-32は4バイト長なので、

4.1.2 LocalFileSystem

4.1.3 ChecksumFileSystem

4.2 圧縮

- zlibを使って圧縮しただけだとDEFLATEフォーマットのファイルができる。

- スプリット可能であれば、MapReduceに特に適しているということは、
 bzip2を使えということ?

4.2.1 コーデック

4.2.1.1 CompressionCodecによるストリームの圧縮と解凍

- p.86 実行例の上 誤字
 gnuzipを使って解凍して → gunzipを使って解凍して

4.2.1.2 CompressionCodecFactoryによるCompressionCodecの推定

- コーデックの推測は、拡張子で判断しないと駄目なのか。ファイルの先頭
 数バイトにマジックナンバーみたいなものはないのか。
 * gzipなどはヘッダを付けているからわかるだろうが、DEFLATEでは単に
  圧縮されたデータだけなのでわからない。

4.2.1.3 ネイティブライブラリ

- nativeって速い?
 * 実行時間は少なくともJavaのほうが速くなることはない。
 * 呼び出しオーバーヘッドも大したことはないはずで、それより圧縮の
  処理のほうが時間がかかり影響が大きいはず。

- なぜ、Windows用のネイティブライブラリはないのだろう。
 * 開発環境がOSSになじまないからか。

- CodecPoolの効果はネイティブライブラリの実装によりそう。例えば毎回
 イニシャライズ処理があるとかなら効果あり。

4.2.2 圧縮と入力スプリット

4.2.3 MapReduceにおける圧縮の利用

- p.91コラム内、Avroの読み方は?
 (ウィキペディアによると、語源のイギリスの航空機会社Avroの読みは
 「アブロまたはアヴロ」とありました。imai)

4.2.3.1 mapの出力の圧縮

- p.92 l.4 脱字
 データの量を減らすけで、 → データの量を減らすだけで、

4.3 シリアライゼーション

- p.94 l.5 誤字
 PRCの → RPCの

4.3.1 Writableインターフェース

4.3.1.1 WritableComparableとコンパレーター

4.3.2 Writableクラス

4.3.2.1 Javaのプリミティブに対するWritableのラッパー

4.3.2.2 テキスト

- p.99 表4-7 U+10400のJavaでの表現 衍字
 \uuD801\uDC00 → \uD801\uDC00

- p.102 ミュータビリティ l.3 脱字
 いずれを呼ぶことで → いずれかを呼ぶことで

4.3.2.3 BytesWritable

4.3.2.4 NullWritable

4.3.2.5 ObjectWritableとGenericWritable

4.3.2.6 Writableコレクション

4.3.3 カスタムWritableの実装

- p.107 下から4行目に、「TextPareは、1つめの文字列の後に2つめの文字列を
 つなげた文字列でソートを行います」とあるが、p.106 の compareTo()だと、
 そうならない場合がある。たとえば、

  (1) first: "a", second: "x"
  (2) first: "ab", second: "z"

 は、つなげると、"ax"と"abz" で、(1) > (2) だが、
 p.106のcompareTo()だと、"a"と"ab"が先に比較され、(1) < (2)になる。

- p.107 l.5
 「write()やreadFields()メソッドの中でオブジェクトをアロケートしない
 よう、注意しなければ」ならないのは、再利用されるのでアロケートするように
 なっていると、何度もシリアライズ、デシリアライズが発生してコストがかかる
 から。

4.3.3.1 高速化のためのRawCoparatorの実装

4.3.3.2 カスタムのコンパレーター

4.3.4 シリアライゼーションフレームワーク

4.3.4.1 シリアライゼーションIDL

4.3.5 Avro

4.3.5.1 Avroのデータ型とスキーマ


以上

次回は、p.116 4.3.5.2 から。

メモ: 会場費3,800円、一人300円負担


[ 戻る ]