Days on the Moon

Google の鵜飼文敏さんによる講演会「大規模データ処理を可能にする Google の技術」に行ってきました。内容的には筑波大学で開かれたものと同じではないかと思います (「新ビジネスモデル」がそのままだったことなどから)。以下、上記記事に載っていないことを中心にメモから抜書きを。

此頃 Google にはやる物

現在 Google では Google の使命 (Google's mission is to organize the world's information and make it universally accessible and useful...) の早打ちが流行中。鵜飼さんは 50 秒程度、一番速い人は 30 秒程度。

Google の扱う情報

Google のいう「情報」はインターネット上のものだけに限らない (例: Google ブック検索)。

データセンター構築の方針

初期のころは「いかに狭い部屋にマシンを詰め込むか」、現在は「いかに故障した部品を交換しやすくするか」。

電力コスト

ハードウェア性能は向上したが、性能あたりの電力消費量は改善していない。

4 年間の電力コストがハードウェアコストの半分を超える。

スケール = コスト

大規模なソフトウェアは大規模なハードウェアを要求し、大規模なハードウェアはお金 (コスト) を要求する。

SQL DB は使わない

データの分析は単純なもの (合計、最大値、最小値、上位 k 個、フィルタリングなど) がほとんどで、DBMS の高度な機能は必要ない。

これらの分析処理は可換的、結合的なため処理順は任意。

MapReduce

Google の開発した大規模データ処理のためのプログラミングモデル。自動的並列分散化、耐障害性、I/O 最適化に優れている。

日本語での解説は Radium Software Development に詳しい。講演中に使っていた図及び例もほとんどそのまま。

Map、Reduce 関数は C++ で記述。

Map から Reduce に渡す処理を「シャッフル」と呼んでいた。内容的には「ソート」のほうが適切な気がするのに、なぜ「シャッフル」というのか?

Sawzall

MapReduce 上で動くデータ分析用言語。強い静的型のスクリプト言語。

限定詞によるループ、if の簡略化が可能。when (i : each int; queries[i].language = JAPANESE) { ... } (foreach (queries 中の query) { if (query.language = JAPANESE) { ... } } より最適化しやすいのか?)

Google での利用に最適化されている (フィンガープリントや日付が組み込みのデータ型になっているなど)。

例外処理はなく、異常時には undefined を返す。undefined は無視して処理を進めることも可能。

Bigtable

数千台のサーバ、テラバイト規模のメモリ、ペタバイト規模のディスクを扱い、毎秒 100 万 Read/Write を可能にするデータベースシステム。

疎な分散多次元表。(行, 列, タイムスタンプ) でアクセス。

行に対する操作はアトミック。

連続する数行をタブレットという単位にまとめて管理。

GFS (Google File System)、Chubby、SSTable といった Google のシステムの上に構築。

日本語での解説は steps to phantasien に詳しい。

タブレット

SSTable (不変二次元マップ) とログデータ (SSTable からの更新分) の組み合わせ。

SSTable は書き換えできないので、追加、削除分はログデータに記録する。ログデータがたまってきたら SSTable を作り直す。

データ量がもたらすもの

計算能力が増えると難しい問題が解けるようになるというのはよく知られているが、データ量が増えると解決不能だった問題が解けるようになるというのはあまり知られていない。

データ量の増加が可能にしたアプリケーションの例

スペル訂正 (「もしかして」機能など)。Web を文脈つきの辞書とみなす。

Google が公開している論文など

以上の技術の概要については Papers Written by Googlers で参照できる。

東京オフィスの位置づけ

東京オフィスはローカライズオフィスではない。

質疑応答では「もしかして」機能に関する質問が多く出ていました。「答えられない」という回答もちらほら。

「もしかして」で間違った結果をどう直すか

間違った結果を目視で直したりはしない。すべて機械処理。

テキスト処理は言語非依存。

BM 法を検索したら KMP 法が引っかかった

ユーザによってはそれが正しい。究極的にはパーソナライゼーションで解決すべきこと。

1 日にコードを書く時間は

日によって違うが、1 日 5 時間くらいコードを書く。レビューなどでコードを読む時間も多い。

日本語の処理に使っている知識は

日本語の知識の利用は皆無。品詞情報なども使っていない。

C++ をどのような言語として使っているか

基本的にオブジェクト指向言語として使っているが、部署によっては better C として使ったりテンプレートを使ったりすることも。

例外は使わない。Google の規模だとほぼすべての実行パスを通るため、見た目がわかりやすくなっても処理を追いにくくなる。

Android に関して、Java 言語を使いながら、Java ME 上のライブラリとしてではなく、既存のものと互換性のないプラットフォームとして作り出す必然性は

開発責任者がそのほうがいいと思ったのだろう。

終了後、鵜飼さんとのじゃんけんに勝って Google T シャツをゲット。さらに残って話を聞いていたところ、余った Google T シャツももらったので、結局白黒 2 枚の T シャツ (前面に Google ロゴ、背面に「I'm Feeling Lucky!」)をいただくこととなりました。