きょうはなんと5歳のブライアンからとてもエキサイティングな質問です。「グーグルはPrecolator、DremelそしてPregelをどう使っているのですか？実際のところをおしえてくさい。」
matt：PrecoltorとDremelとPregelが何か？これらは完全に違うツールなのですが..うーん。精神的に社内のコードネームと外向きのコードネームとうまく翻訳しなければなりませんが、今日は極力ストレートな説明を心がけますね。
matt:Precolatorは基本的にビックテーブルの最上位のTableです。昔のグーグルのインデクシングはバッチモードといった手法でされていました。うーん5歳児にわかりやすく説明すると、電車を待つことを想像してください。1時間に1本とか1日に1本とか。電車を待っている人は次の電車がきて全員が乗り込んでいきますね。つまり次の電車がくるまでみんな待たなければならいのです。
matt:CaffeineとPreclatorというのは関連するものなのですが、昔のバッチインデックス概念をインクリメンタルなインデクシング（差分インデックス）に応用した（改善した）というイメージをまずは思い浮かべてください！
たとえば、Taxi乗り場ですと、タクシーに乗りたい人は、待っているタクシーに次から次へと乗っていくことができますよね。1日1本しか来ない電車だと、数千もの（多くの）人がホームでさんざん待って、電車がきたらみんなが一斉に乗り込むことなります。
前者のタクシーの例がインクリメンタルインデックス、後者の1日1本の電車がバッチインデックスの例だと考えてみてください。Caffeineというのは外向きに公表している全般的なシステムのことなのですが、PrecolatorはCaffeineを動かすためのサブセットなシステムなんです。Precolatorは全体のシステムがきちんと動くことをチェックしているような感じですね。
matt:はい、次はDremelですね。Dremelはですねぇ。。一種の。。OK、ではこれもたとえを使って説明しましょう。たとえば、僕のデータベース、永遠に増え続けるデータベースを使うことを想像してみてください。そのデータはかなりの大きなサイズのデータベースの一部として機能します。Dremelはこの僕のデータに当たる部分になるでしょうか？難しいですが、ここにはアーキテクチュアルな違いがあるんですが、実際には、Dremelは全webサイトのデータベースを取り扱うことを可能にしているんです。巨大なデータベースに対するクエリー（問い合わせ）をめちゃくちゃなスピードで走らせることができるんです。
なので、さまざまな人がデータ分析にDremelを活用していますし、我々スパムチームのスパムファイターも活用している非常にファンタスティックなツールです。それから付け加えておくと多くの人がかかわっていますし、時にはオープンソースのインプリもしたりもしています。
Dremelは非常に大きなデータベースから分析に必要なデータを取り出すことができる素晴らしい道具なのですね。
matt:はい、最後はPregelですね。これは基本的には、グラフ問題を取り扱うシステムです。2009年にあるリサーチブログで面白い投稿があったのですが、すべてのグラフリソースをライブラリーとして実行するとしたらある種のコードを個々のマシン自体に組込みしなければならず、さらにそのブログではページランクのスコアリングプログラムはたった15行のコードでなされている！とか書かれていました。この15行のコードは非常に高価なコードになるわけですが、ただし、アーキテクチャーが秀逸である必要があり、マシンに正しく組み込まれる必要があるという内容でした。
想像できる人は想像できると思いますが、例えば、グーグルに新しい人がきたとしましょう。ある人は良いページランクを結果として出すことができたり、ある人は全く違ったページランクをもらう事もあるでしょう。例えば、オンラインレピュテーションに関するリンクグラフとかその他、別のタイプのグラフ問題などを目の当たりにするかもしれません。たとえば、人々との関係性などに関するグラフ（Google+とか？？）ですね。想像つくと思いますが、こうしたグラフなどのスコアによる競争は非常にスピード感をもって処理されるものだったりするのですが、Pregelはこうしたグラフ間の問題を取り持つものなのです。
グーグルの面白いところは、内部に巨大なインフラストラクチャーやそれを支える巨大なマシンリソースがあるという点です。非常に速い処理能力と、実験などができるプラットフォームで、こうしたリソースを活用し、さまざまなシグナルを発見したり、改善点を見つけ出したり、効率的にクロールするにはどうすればいいかとか、そして上位レベルのアーキテクチャー上で、どうデプロイすればいいか等まで、また、オープンソースなどでダウンサイジングした環境でクイックな実験ができたり、それを大きくスケールしたり..さまざまなことがトライアウトできる環境がと整っているといえるところでしょうか？
matt:今日は、刺激的な質問をしてくれてどうもありがとうございました！参考になったかなぁ?
ネズミ小僧：今回は意外にもマット・カッツさんから、かなり技術的な内部の質問に対する答えが聞けたので正直驚いています。
5歳児？からの質問だったからわざと油断したのでしょうか？でもこの方本当に5歳児なのでしょうかね？
最近は、キーバリュー型のデータベースとかHadoopのようなオープンソースなどのお話などをする技術者と話す機会がめっきりなくなるような仕事をしているのですが、グーグルのmapreduleとかBigTableとか昔はドキュメントを読みましたが忘れかけていました。
Hadoopのようなオープンな分散処理データベースや処理速度を重視したNoSQLなキーバリュー型のデータベースとかメムキャッシュとかすごいテクノロジーがあったなぁと懐かく伺いましたが、今日はいつものノリとは、ちょっと違う技術的なお話でしたが、これは裏を返せばマット・カッツさんがいかにビデオで分かり易くWebSpamなどの事についてお話しているかの裏返しでもあるかもしれません。
Hadoopなどは得意とする処理とそうでないものがありますが、グーグルのオリジナルのアーキテクチャーには、Precolator、DremelそしてPregelによりビッグデータの分散処理やボトムネックを作らず瞬時にクエリーでデータを取り出すキーバリュー的な要素、またグラフライブラリをキューブな観点で関連付けするようなメカニズムまでGoogleのアーキテクチャーはエンジニアでないと実感しにくい部分はあるのですがやはりスケールが桁外れな感じですね。
私がびっくりしたのが、データセンターごと分散処理のノードとして使っているような記事を拝見したことです。
電気代をいかに安く抑えるかという点で、屋外に空冷のコンテナデータセンターを作っていて、じゃぁ雨が降ったらどうするの？という疑問に、別の晴れているエリアのデータセンターのノードをホットスワップさせるから問題ないとかいう発想はスケールの大きさに驚いた記憶がありました。
分散データベースに興味のある方はこちらやこちらなど、もしくはHadoopのドキュメントが参考になるかもしれません。どこかで英文のPDFのドキュメントがDLできるところがあったのですが、ちょっと忘れてしまいました。GoogleScholorでBigdataTableofGoogle mapreduceと検索すると出てくるかもしれません。（今週はドタバタしていたので今日は寝ようとメールの確認だけと思いましたが、2つもビデオがあがっていたので、執筆しましたが、逐語訳性や誤字脱字等はご了承ください。）
リンクのついてないページの品質をグーグルはどうやって見ているのですか?...
同じURLへ一つのページから2つのリンクが張られている場合どうなるのでしょうか?...
マット・カッツさんマッドな間伐ってどれぐらいの勢いでやっているのでしょう？...
ウェブスパムチームにお聞きします。これまでを振り返って後悔したなぁ！といった施策はありますか？...
バックリンクの重要度は今後減ってゆくのでしょうか？...
2014年03月07日 
