Google File SystemとBigTable 〜Wakhok マルレク・サブセミナー「Googleの分散処理技術」一日目〜
秋葉原の稚内北星学園大学東京サテライト校で行われたマルレク・サブセミナーに行ってきました。
http://www.wakhok.ac.jp/tyo-sat/subsemi2007.html
今日は一日目で「GoogleFileSystemとBigTable」。
開始に15分ほど遅れてしまいあわてて会場に駆け込むと、ぎゅうぎゅう詰めでほぼ満席。70〜80人くらいいたかな、すごい熱気でした。
おなじみ丸山先生が独特の雰囲気で講演をしており、急いで空いてる席を見つけて着席。配布資料は残念ながら無く、また、丸山先生の説明が早いこと、資料が多いこと。ノートをとるのと話を聞くのとで、いっぱいいっぱいな二時間でした。
では簡単に、興味深かったことをノートから抜粋。
「GoogleFileSystem」
- 大切なのは「Co-Designe」。システムを前提としてインフラをデザインする。Googleの競争力の源泉。
- GFSの特徴：巨大なファイル、ブロック(チャンク)サイズは64MB、ファイルは追記型でランダムI/Oは考慮しない。
- MasterServerとChankServerの構成。
- Chankは64MBの固定長でデータは三重かされている。（３つのチャンクサーバーに分散）
- ChankHandle、クラスタ内で一意のID（クラスタはおおむね2000台以上のサーバー郡）
- I/OはChankHandleとLocation(サーバー)で特定される
- 全てのメタデータはMasterServer上で管理され、Client側にもキャッシュする
- Masterは１つということが大切、デザインをシンプルにする
- メタデータは３つ：ファイルとチャンクの名前空間、ファイルからチャンクのマッピング、チャンクの複製の場所
- メタデータへの変更は全てOperationLogとしてDiskiへ書き出す
「BigTable」
- ペタサイズのデータを格納する巨大な分散ファイルシステム
- BigTableにはWebのIndexing、GoogleEarth、GoogleFinance等のデータが格納されている
- 数十億のURL、100TB以上の衛星画像等。クロールデータだけで800TB
- rawレベルではGFSを利用している
- データ（ROW）は３次元情報で一意に特定（行、列、タイムスタンプ）
- カラムは２重構造、familly:quaifier ⇒ anchor:cnn.com、anchor:my.look.com等
- famillyでアクセスコントロール、カラムの数は可変
- Tablet：行の境界で分割される。１つ100〜200MB
- TabletServer：100Tablet程度までの責任を持つ
- SSTable：メモリ上のデータ(memtable)がパーシストされたもの。データは圧縮されている
- Readのときはメモリ→SSTableの順で読み込み。SSTableは解凍しながら複数のSSTableをマージしながらReadされる
- 書き込みLogはある
- 小圧縮：memtableの大きさが閾値を超えたら内容をSSTableに書き出す（GFS上）その際は圧縮して
- 大圧縮：複数のSSTableをまとめて１つのSSTableにする(削除データのデフラグも実施)JOB実行はバックグラウンドでスケジュール
- LocalityGroup：カラム毎に切り出したデータ（カラムの切り口でグルーピングしたもの）
- PageRankやLangというfamillyで切り出す（マスタ化ってイメージかな）
ざざざっとこんな感じでした。伝え切れなくて、申し訳ない。
でも、基礎技術的な感じがあるし、ものすごくCo-Designeだし、自分の仕事にすぐに活かせるかというと、それは難しいだろうな。
でも次回のMapReduceは別。どうにか今の仕事に展開できないかを真剣に考えてみたいと思います。丸山先生も「次回は大事だよ」とのこと。次回は早めに会場入りして、もう少しスクリーンが見やすい席に座りたいと思います。
