読書会(Hadoop 第2版)第2回議事録
[ 戻る ]
Java読書会「Hadoop 第2版」を読む会 第２回 議事録
日時: 2011年11月26日(土) 10:00-17:00
場所: 川崎市産業振興会館 第１会議
参加者: 根本、小棚木、遠藤、高橋(智)、松永、門脇、高橋(徹)、村山、石黒、吉本、今井
書記: 今井
範囲: 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円負担
[ 戻る ]