ラベル 技術習得 の投稿を表示しています。 すべての投稿を表示
ラベル 技術習得 の投稿を表示しています。 すべての投稿を表示

2013年9月5日木曜日

グリーで覚えた&忘れた単語リスト

GREEに入って覚えた言葉と忘れそうになった言葉をなんとなく羅列してみた。まぁ、何を学んで何を忘れていったのか何となく想像できますね。今度もう少し丁寧に整理してみようかな。

覚えた

  • CDN
  • LVS
  • Web Storage
  • App Cache
  • CSRF
  • SPOF
  • UX
  • DAU
  • MAU
  • UU
  • ささる
  • くばる
  • デグレる
  • 上長
  • リア充
  • ネト充
  • スイーツ()
  • ボトラー
  • 懐古虫
  • イカ娘
  • まどマギ
  • プギャー
  • モヒカン
  • マサカリ
  • ラブライブ
  • Homebrew
  • git-flow
  • Coffee Script
  • Tyepe Script
  • Zepto
  • node.js
  • PHP
  • Ethna
  • Shading
  • Master / Slave
  • play framework
  • finagle
  • sbt
  • Redis
  • DDD
  • Monad
  • Scrum

忘れそう

  • Bloomberg Tickers (jb/js/jl/...) 
  • Reconciliation
  • Tweak
  • PNL
  • Delta
  • FUTEQ
  • PVBP
  • Interpolation
  • fix / float leg
  • xccy
  • basis swap (e.g. 3m / 6m)
  • fixing risk
  • LIBOR / TIBOR / EURIBOR
  • Spring Framework
  • RMI
  • RMDS
  • dbunit


2012年4月22日日曜日

Graph APIとGAEでお遊びアプリ

実は先月暇だったので、WebアプリケーションとKVS(Key Value Store)のお勉強をすべく、FacebookのAPIとGAE(Google App Engine) Pythonを使ってFacebookのフィードや友達、所属するグループの簡単な統計情報を表示する小さなアプリケーションを作りました。まぁしょぼいアプリですが、ここでちょろっと紹介します。

http://pei-fbstats.appspot.com/

基本的にはfacebookのGraph APIを使って友達の性別や所属、コメントやLikeの数などを集計しているだけのアプリです。遥か昔に忘れたHTMLの書き方とか、GAEの使い方や初めて書くPythonやjQueryやKVS(結局使わなかったけど)の使い方とかを覚えながら、のべ二週間くらいかけて作りました。Feedのコメント数とかが微妙に上手く取れていないことがあるような気もしたりするので、お遊びの参考程度だと思っててきとーに使ってください。ユニットテストすら書いていないので…。気が向いたらちゃんと確認します。

なんか問題があっても責任はとりませんがw、当初のKVSのお勉強をするという目標とは裏腹に、実はデータは全くKVSにストアしていないのでデータ集めてるとかはないです(KVSは使ってみたし勉強はちゃんとしたけどね!)。でも、毎回Graph API叩くのはさすがにパフォーマンス的にどうかと思うので、cache目的で使った方がいいだろうなぁとは思ってます。まぁでもその目的ならBigtableではなくmemcachedになるか…。でも、たぶん転職直後で忙しくて触ってる暇はもうないですが。

以下、使ってるサービスとかライブラリの説明です。たぶんWebプログラミングに慣れてるひとからするとアホみたいな話でしょうが。僕が5-6年前に大学でやっていた頃と比べると、特にクラウドサービスとかJavascriptのライブラリの充実ぶりが半端無くて、本当に簡単にWebサービスが作れる時代になったんだなぁと実感しました。

GAE
サーバ借りたりとか面倒だし、勝手にスケールしてくれるし(そんなに使う人いないと思うけど)、僕みたいな怠惰な人間には最高のプラットフォームです。余談ですが、GAEではurllib2.urlopenは使えなくてgoogleの用意したurlfetchっていうライブラリを使わないといけないみたいです。socketが使えないのが理由みたい。軽くハマりました。詳しくはここで(The URL Fetch Python API)。

Facebook Graph API
言わずと知れたfacebookのAPIです。リクエストの数が多い時には複数のリクエストをまとめてPOSTできるbatch機能とかもあったりして便利でした。けっこー、レスポンスに時間がかかったりするのでtimeoutとかpagingとかのパラメーターを上手く調整する必要があります。でかいデータにアクセスしようとすると、時間かかったりレスポンスがなかったりするのはこいつのせいです。(嘘です。ぼくが怠惰でエラーハンドリングとかcacheとかしてないせいです。)

jQuery
Webに慣れてる人は何を今更って感じでしょうが、奇跡のライブラリですねこれは。恥ずかしながら今回はじめて使ったのですが、非同期の処理が本当に簡単にできてしまってjavascriptの敷居を一気に下げるツールです。6-7年前に自分でオブジェクト作ってブラウザごとに分岐したりしてAjaxの処理を作っていたのが懐かしい(というか馬鹿みたい)。

simplejson
Graph APIはJSONでデータを返してきますし、このアプリも基本的にサーバ側はJSONでデータを返すだけで、クライアント側がサーバから返ってきたデータを可視化しています。実はJSON形式のデータって今まで使ったことなかったんですが(証券会社勤務だったのでJavaでXMLみたいな堅いメッセージングばっかり)、すごくシンプルなデータ構造ですし、このライブラリを使ったら超簡単に扱えました。pythonの配列や辞書形式のデータとJSONの文法がほとんど同じだったなのですぐに慣れました。python2.6以降ではデフォルトで含まれているみたいですが、GAEがサポートしているpython2.5に含まれていないので自分で落としてきました。このチュートリアルが分かり易かった。

gae-sessions
後はwebappというGAEビルトインのフレームワークにはSession管理機能が含まれていないためgae-sessionsというセッション管理ライブラリを利用しました。たしかmemcachedを使ってるライブラリだったような。

Google Graph Tools
グラフはGoogleのAPIを利用しました。javascriptのオブジェクトにデータ突っ込むと勝手に綺麗なグラフを作ってくれます。pie chartとbar chartしか使わなかったけど本当はもっと色々と細かいことできるみたいです。

Graph API Explore
Graph APIで遊ぶなら必須ツールです。APIがどんなメッセージを返してくるのか簡単にチェックすることができます。

Favicon Generator
faviconはこれでテキトーに作りました。

git
Dropboxをレポジトリにしてgitで管理しました。一度、リファクタリングしたらGitHubに乗せてみようかな。


今後追加してもいいかなぁと思っているもの
  • キャッシュ。毎回時間かかり過ぎだから。
  • 人の名前をクにその人のFBページのリンクをつける。(Google Chart Toolsで簡単にできそう)
  • 自分と一緒にタグ付けされている人のランキング
  • 友達やグループメンバーのフィルタリングツール(友達を所属とか年齢や性別みたいな属性で絞り込むような機能。絞り込み後にメッセージ一斉送信とかできたら更に使えるかなみたいな。)

2012年2月19日日曜日

読書日記「仮想世界錬金術 モバイルソーシャルアプリに見る現代ディジタルコンテンツ革命」

今、破竹の勢いでビジネスが拡大しているモバイルソーシャルゲームについて勉強してみたいと思って読んでみました。僕もモバイルソーシャルゲームは「破壊的イノベーション」の典型例だと思っていて、最近はとても注目しています。グリーやDeNAの好調な業績が世間を驚かせていますが、国内のソーシャルゲーム市場は2012年度には3400億円を突破すると予想されているようです。(矢野経済研究所:ソーシャルゲーム市場に関する調査結果2011より)また、同時に海外市場への進出も急速に進めています。本書ではソーシャルゲームビジネスがいかに拡大してきたか、ソーシャルゲームの基本原理、またそのマーケットについてを実例に基づいて説明しています。

僕が一番面白いと感じたのは、モバイルソーシャルゲームはひたすらEnterを押し続けるような単純なゲームに見えながらも、裏側では以下のような技術やノウハウが凝縮された、かなり高度なサービスだということです。
  • 限られた機能、コンテンツ、UIでいかにユーザを楽しませるか(ゲームニクス理論、エクスペクトロジー、時間の使わせ方など)
  • どうユーザ間のコミュニケーションを楽しませるか
  • データマイニングに基づくチューニング
  • フレームワークを利用した少人数、短期間での開発
  • クラウドサービスや並列処理を利用した負荷分散

個人的には、これからゲームビジネスはどんどんパッケージ型から課金型へビシネスモデルが変換していくと予測しています。据え置き型のゲームも初期の価格設定を低く抑えて、コンテンツやアイテムなどで課金していくのが主流になっていく気がします。正直、僕自身がモバイルソーシャルゲーム(怪盗ロワイヤルとかドリランド)をやった限りでは、システムが単調すぎてのめり込むほど面白いとは思えなかったんだけれども、おそらく今後はスマートフォン向けの新しいゲームがどんどん出てきて、もっとリッチなコンテンツを求めるユーザ層も獲得していくだろうと思っています。メインフレームがオープン系のワークステーションに置き換えていったようにね。海外進出もどんどん進められているようなので、日本のIT企業が海外の市場でどれだけ戦えるのか楽しみですね。

2012年1月27日金曜日

JSONICを使ってみる

ちょっとJavaでJSON形式のデータを扱う必要があったので、JSONICというJSON Parserを利用して見ました。JavaのライブラリではJSON-libというのが定番らしいのだけれど、他に依存するライブラリがあったりして面倒そうだったので、とりあえず一番シンプルそうなJSONICを使いました。

僕はFacebookのGraph APIで返ってきたJSON形式のデータをJavaのオブジェクトとして取り込みたかっただけなので、decodeだけ利用しました。使い方はとても簡単で、JSONのフィールドと対応する変数とaccesserを持ったクラスを指定してやるだけ。

まず、Graph APIはユーザの情報を以下のような形で返してくれます。

{
  "id": "123456789", 
  "name": "Foo Bar", 
  "first_name": "Foo", 
  "last_name": "Bar", 
  .....
}

で、以下のようにidとnameの変数とアクセッサを持ったクラスを定義してやります。

public class FBUser {
   private String id;
   private String name;
 
   public FBUser(){ }

   public String getId() {
      return id;
   }

   public void setId(String id) {
      this.id = id;
   }

   public String getName() {
      return name;
   }

   public void setName(String name) {
      this.name = name;
   } 
}

そして、以下のようにJSONのデータとクラスの型を引数にしてdecodeを呼ぶと、勝手に個々のフィールドに値を入れてくれます。おそらく、リフレクションを使ってJSONのフィールド名からsetterの名前を推測しているのでしょう。例えばフィールドが'id'だったら'FBUser.class.getMethod("setId")'とかね。ちゃんとidとnameがログに出力されました。

String jsonFbUser = FBLoginUtil.getResponseFromURL(FBLoginUtil.getGraphApiUrl() + "me"  + "?access_token=" + accessToken);
final FBUser fbUser = JSON.decode(jsonFbUser, FBUser.class);  
log.info("id:" + fbUser.getId());
log.info("name:" + fbUser.getName());

このブログを書くよりは遥かに短い時間でオブジェクトとして取り込むとこまで出来てしまいました。オジサンの知らない間に世の中便利になってますな。賢い人達、いつもどうもありがとうございます。

2012年1月26日木曜日

gitを使ってみた

gitを使ってDropboxにレポジトリを作ってみた。ついでに、EGITをインストールしてEclipseからcommitとpushができるようにもしました。

最近、一人で開発を始めたのですが、ワークスペースが全部ローカルのMacに入っているので気持ち悪いと思い、Dropboxをレポジトリにしてgitを導入してみた。僕はsubversionしか使ったことないのですが最近の若者に流行りらしいのであえて。一番の違いは、serverで一元的に管理するsubversionとは対照的に、gitはすべてのコピーがマスタレポジトリのフルコピーを持っていて、ヒストリーの確認は勿論、コミットもできる分散レポジトリであるという点みたいですね。

とりあえず、Mac OS X 用のインストーラーがココにあるので、ダウンロードしてインストール。git help とコマンドを打ってみると、add/checkout/diff/commitなどsubversionで見慣れたコマンドが並んでいて一安心。

まず、user.name、user.emailをgit config コマンドで登録します。

git config --global user.name foo
git config --global user.email foo@bar.com

どうやらversion1.7.5からはレポジトリとワークスペースのディレクトリを別にする--separate-git-dirというオプションが追加されたようなのでDropboxだけでレポジトリを管理しようかとも思ったのですが、DropboxをマスタにしてLocalドライブを自分用にした方が分散レポジトリというgitの哲学に合ってるんじゃないかなぁと感じたのでそうしました。毎回マスタにPushするのはちょっと面倒かもしれないけど。


レポジトリを作るのはアホみたいに簡単で、Dropboxに適当なディレクトリを作って(e.g. $HOME/Dropbox/git_repos/MyProject.git)、そこにcdしてgit --bare init とコマンドを打つだけ。

僕はEclipseでGoogle App Engineのアプリケーションを書いているのでEGITというEclipseから使える管理ツールをインストールしました。subversionで言うsubclipseみたいなもので、ちょっと触ったところ使い方は殆ど同じなので、10分位でレポジトリ作ってcommitしてDropboxにpushするところまでできてしまいました。試しに、マスタレポジトリからgit clone で適当なディレクトリにコピーしてみたらちゃんとディレクトリ構造がコピーされました。Dropboxはディレクトリごとに他のユーザと共有とかできるはずなので、$HOME/Dropbox/git_repos/MyProject.git を他のユーザと共有すればマスタリポジトリの共有も出来ますね。

今回の作業では以下のページを参照しました。どうもありがとうございました。
Subversion ユーザーが Git を使ってみた (基本操作編)
Dropboxを利用してGitのプライベートリポジトリをつくる方法
git 1.7.5で追加されたオプションを使ってgit on Dropboxの運用を見直す
EGit/User Guide

2012年1月16日月曜日

読書日記「Web開発者のための 大規模サービス技術入門」

株式会社はてなの伊藤さん(現GREE)と田中さんという、Webに興味のある人なら名前くらいは聞いたことがあるだろう人達の書いた、「Web開発者のための 大規模サービス技術入門」というその名の通り大規模なWebサービスをどう運用していくかを説明している本です。理論的な説明だけではなく、実際にはてなで使われている運用方法などの「泥臭い」部分をかなり詳しく説明してくれているとても実践的な本でした。

この本を読んで、もし自分で大規模サービスを運用が必要になる時には絶対に自分でインフラは持たずにGoogle App Engineのようなクラウドサービスを使おうと思ってしまいました。さすがに自分でここまでする気にはならないですね…。

基本的にはパフォーマンスの問題はCPUかI/Oのどちらかがボトルネックになります。そういう時は単順にtopやsarでどちらの問題か切り分けます。どのプロセスがCPUをどれくらい使ってるかとかI/Oの待ち時間がどれくらいあるのかとかを確認すれば、だいたい目星はつくでしょう。

CPUがボトルネックの場合は以下のような解決方法があります。単純に計算量が足りないだけなので、比較的解決は簡単なようです。
  • サーバを増やして処理を分散させる。この場合はDBと違ってデータのレプリケーションなども必要無いので、比較的簡単にスケールする。
  • アルゴリズムを改善して計算量を減らす

I/O側はCPUのように、サーバの台数を増やすだけでは簡単にスケーリングできないので対応が難しいようですね。Googleが独自の分散ファイルシステムやデータベースを持っているのもそれが理由でしょう。対応の仕方としては以下の方法があるそうです。
  • できる限りキャッシュやメモリのヒット率を高めてディスクアクセスがないようにする。(メモリはディスクアクセスの10万倍以上高速)
  • プログラム変更でメモリの利用が減らせるならそうする。
  • 足りなければメモリを増やす。できないならデータを複数サーバに分散させる。
  • データベース側のスケーリングをする(最終手段)。マスタDB(書き込みを担当するDB)のスケールアウトはACIDが求められるため難しいが、テーブル毎やエントリー毎に別サーバにデータを分散させるようなトリッキーな事をすることもあるようです。TwitterもMySQLの分散とmemcachedで運用しているみたいですね。

RDBの分散やデータの圧縮の話はとても面白いと思いました。RDBのデータを分散するのにテーブル毎に別サーバに分散させたりするので(勿論できるだけ局所性を保つように分散する)、INNER JOINを使わずに複数回クエリを投げるプログラムを書いたりするらしいです。もはや、RDBではないですね。

他にも、データ圧縮をI/Oを減らすためだけとかに使ったりとか、データをページキャッシュにのせるためにアプリケーションで使われる大規模データを一度catしたりとか、面白いノウハウが載っていました。そういえば、僕のサポートしているシステムでもデータをキャッシュに入れるために、再起動するたびにウォームアップさせてるなぁなんて思いながら読みました。

後半のインフラ系の話の部分はまだ読めていないので、また後日にでも。ちらっと見た感じ、SSDを使った高速化とか面白そうだな。明日、Macbook Airが届く僕としては…

2012年1月7日土曜日

読書日記「Webを支える技術-HTTP、URI、HTML、そしてREST 」

ちょっとWeb系の技術の基本的な部分を勉強してみようと思って、「Webを支える技術」という本を読んで見ました。RESTfulな設計の大切さ、URIとHTTPの説明、ハイパーメディアフォーマットなどのWebに使われている基本技術の説明がメインで、最後に少しWebサービスの設計例が載っています。僕のような、コンピュータの基本的な知識はあって、勿論HTMLやJavascriptはある程度書いたことはあるけれども、体系的に勉強した経験がないような人間に丁度よい本でした。

本書ではRoy Fieldingが提唱したREST(Representational State Transfer)というWebのアーキテクチャースタイルを良しとしており、URI(リソース)、HTTP、ハイパーメディアフォーマットについて説明すると同時に、いかにそれらをRESTfulに利用するかについても言及しています。本書では、以下の6つの制約を合わせたアーキテクチャースタイルがRESTであり、実際のアプリケーションは必要に応じていくつかの制約を除外しながら実装すれば良いと述べています。

  1. クライアント/サーバ
  2. ステートレスサーバ
  3. キャッシュ
  4. 統一インターフェース
  5. 階層化システム
  6. コードオンデマンド

個人的には一番印象に残ったのはMethodの説明です。僕が学生時代にWebを少しかじった頃はちょうどSOAPが出てきた頃で、たしかSOAPで実装されたGoogleのWeb検索APIとかで遊んだ記憶があるのですが、今は完全にRESTに基づいてHTTPメソッドを使い分けるのが主流のようですね。5年前の僕がしていたPOSTだけですべての処理をこなすなんていう処理は完全なるアンチパターンのようですね。HTTPには以下の8つのMethodが用意されており、個々の役割は決まっているので用途に応じて使い分けるべきらしいです。
  • GET
  • POST
  • PUT
  • DELETE
  • HEAD
  • OPTIONS
  • TRACE
  • CONNECT

後はHTTP、URIやデータフォーマット(HTML、JSON、microformats、Atom)の説明や、通信プロトコル、ヘッダー、ステータスなどのリファレンス的な情報などの説明もあり、基本的な技術をおさらいするのにはとても便利でした。


2011年9月20日火曜日

読書日記「集合知プログラミング」

O'Reillyの「集合知プログラミング」という本を買ってみました。この本はWeb APIや簡単なPythonのスクリプトを使って最近流行っているデータマイニングを広く浅く紹介している本です。



本当はもう少し統計的な面から捉えた、Rなどで説明している本を読もうかとも思ったのですが、僕から失われたWebサービス対する「勘」のようなものを取り戻すきっかけにならないかと思い、実際に公開されているAPIなどを多く利用しているこの本を選びました。

今回は、協調フィルタリングとクラスタリングを説明した2章と3章だけ読んで見ました。


第二章「推薦を行う」

協調フィルタリング(Collaborative Filtering)の説明です。これはAmazonの行なっているユーザの購入履歴から商品を推薦する機能や、似たようなアイテムを推薦する機能などに応用されている技術です。基本的なコンセプトは単純で、ユークリッド距離や相関係数でユーザやアイテムの類似度を測った後に、その類似度を重みとした加重平均を行ない、その結果を推薦度とします。主に、アイテムベースとユーザベースの2種類の方法があるそうです。

アイテムベース: まず、アイテム間の類似性を測り、ユーザが評価(購入)したアイテムに対し、その類似度に応じた加重平均をして、推薦度を算出。

ユーザベース: まず、ユーザ間の類似性を測り、その類似度に応じた加重平均をして(勿論、似たユーザの重みが大きい)推薦度を算出。

一般に、アイテムベースだと、アイテム間の関係はユーザ間の関係ほど頻繁に変わらないので、バッチなどで前もってデータを用意しておくことができるため、データのメンテナンスは必要になるがパフォーマンスは良く、疎なデータセットに対しても強いそうです。一方、小規模で変更が頻繁に起こるようなデータに対してはユーザベースが強いそうです。


第三章「グループを見つけ出す」


この章では教師なし学習の一種であるクラスタリングについて説明しています。第二章で測定したようなアイテムやユーザ間の類似度(もしくは距離)を元にして、似たアイテムをクラスタとして集めていくという方法です。本書ではブログをクラスタリング対象とし、ブログ内の単語の出現頻度をベクトル(列)とすることによってブログ間の距離を表現するという例を用いています。階層型クラスタリングとK-mean法によるクラスタリング手法を説明しています。

階層型クラスタリング: 
まず個々のブログをクラスタとし、すべての個々のクラスタ間の距離を測り、一番近い2つのクラスタを結合し新たなクラスタとする、という処理を繰り返す。これにより、すべてのブログを階層的に並べることができます。すべてのクラスタ間の距離を測る必要があるため計算量が膨大(クラスタリング対象の数の二乗 x ベクトル数)になる。(学生の時に悩まされました。疎なベクトルに対して使えるトリッキーなベクトル圧縮や計算方法を利用した記憶があります。)ブログと単語の列、行を入れ替えても動作するが、行(単語)の数が多くなるため計算量が増し、列(ブログ)の数が減るため精度が下がる可能性が高い。

K-mean法:
まず、任意の数の重心ををランダムに配置し、それに近い単語群でクラスタを形成する。さらに、形成されたクラスタの重心から近い単語群で新たなクラスタを作るという処理を、クラスタ内の単語が変化しなくなるまで繰り返す。はじめに選択されてた重心に結果が左右されるが、個々の単語の距離を測る必要がないため高速に動作するという利点がある。

その他、形成されたクラスタの二次元座標へのプロットの方法なども解説してありましたが、今回は読み飛ばしました。


実際のWeb APIなどを利用しており、簡単なスクリプトの例によって説明しているためとても実用性の高い本だと思います。簡単なレコメンデーションシステムなら2章のコードをコピペしてしまうだけで作れてしまうでしょう。

今回は2章と3章を少し時間をかけて読み込みましたが、本書のイメージは掴めましたし、さすがに全部このペースで読んでレビューまでこなすのはヘビーなので、一度簡単に全体をポイントだけ理解しながら読みつつ、興味のある部分は改めて細かく見てみたいと思います。

で、僕から失われたWebサービス対する「勘」が多少なりとも戻ったかというと。「Amazonのこの部分の推薦はアイテムベースでを使っているだろう」とか、「この間話した携帯ゲーム会社の人が話していたHadoopのバッチ処理もこのアイテムベースの類似度データを作ってるんだな」、くらいのイメージは湧きます。でも何か応用できる分野が見つかるかと言われると、、、うーん、例えば広告のWebクリック率履歴を利用してユーザ毎にカスタマイズした広告を出すとか?いやー、そんなものGoogleとかで確実にもう実装されてるよな。もう少し訓練が必要ですね。

2011年9月12日月曜日

読書日記「Googleを支える技術」

ちょっと分散システムの仕組みについて復習してみたかったので、昔読んで面白かった本を引っ張り出してみました。Googleの大規模検索システムが、どのような仕組みで動いていいるのかを、検索エンジンのクローリングやインデクシングから分散システムのハード(データセンターなど)とソフト(データベースやデータ処理)、さらにおまけで開発手法まで説明した本です。Googleのオフィシャルな本ではないですが、Googleの大規模検索システムの概要をとても分かりやすく易しく説明しています。コンピュータサイエンスのバックグラウンドがあれば専門領域が違っても一日で理解できるくらいの内容です。




今回は分散処理の仕組みだけチェックしておきたかったので、3章の「分散ストレージ」と4章の「分散データ処理」の部分を中心に読みました。Googleのシステムはデータやその処理を複数のコンピューターに分散することによって高速化やデータの扱う大規模化を図っています。また、処理を分散させるためのデータのコピーや、ハードウェアが壊れた時のフェイルオーバー機能をもたせており、2章と3章ではそれら仕組みが説明されています。

3章の「分散ストレージ」ではGFS、Big TableとChunkという3つの分散ストレージを紹介し、データの分散方法や、多重化されたデータベースに対するアップデート、エラー時の対応などが説明されています。

GFS
ハードディスク上のデータの大容量化、分散化を可能にする技術です。チャンクと呼ばれる細かい単位に分けられ、マスタによって場所などが保持される。データの読み込みはマスタにデータの場所を問い合わせるのみで簡単に行うことができる。ただ、書き込み時にはロック機能がないため不整合が起こる可能性がある。その代わり、ファイル末尾にレコード追加するような機能を備えており、これだとアトミックな操作はできるが同じデータを重複して書きこむ可能性もある。読み込み、書き込みともにスケールアウトするが、書き込み時にはデータ多重化のためにチャンクのコピーを伴うため読み込みより時間がかかる。

Big Table
ある程度構造化された大規模データを扱うためのテーブル。他のテーブルとのリレーションは持たないが、フィールドにはどんなデータでも格納できるというデータ構造。行キーのカラムキーとタイムスタンプの3つによってデータを特定することができる。ロックは行単位でのみ可能。データはタブレットと呼ばれる単位で分散して格納され、マスタによって管理される。タブレットへの書き込み操作はmemorableというログにジャーナルされ、それがある程度のサイズになったところで新しいタブレットが作られて、タブレットの分割や結合が起こる。

Chunk
ロックとイベント通知の機能を備えた小規模データ向けのストレージ。GSFやBig Tableなどの外部リソースのロック制御や、DNSとして使われている。レプリカと呼ばれるマシンで5重に多重化されており、その一つがマスタとして働く。

4章の「分散データ処理」ではMapReduceによる分散処理の仕組みの説明や、Sanzallという簡単にMapReduceの仕組みを使うためのスクリプト言語について説明しています。ほぼマシン台数に応じて比例してスケールするというかなり優秀な結果がでているそうです(サーバを50台から600台に増やしても1.3倍程度しかトランザクションが増加しないらしい)。

MapReduce
言わずと知れた分散データ処理技術です。データはKeyとValueのセットで扱われ、Map、シャッフル、Reduceという3つのステップにより行われます。Mapが個々のデータに対して分散して処理を行い、シャッフルが処理を終えたデータからKeyに応じてデータの並び替えを行い、ReduceがKeyごとにデータを集約し書きだすという仕組みのようです。

Sanzall
MapReduceの仕組みを使うためのとても簡単なスクリプト言語です。Map処理をスクリプト内に書き、Reduce処理はアグリゲータと呼ばれるパラメータ(Sum, Maxなど)を指定すると自動的に行われるようです。インプットとアウトプットのレコードを実行時に引数で指定すると自動的にGFS(BIG Table)からデータを読み込み、指定したMapReduceの処理を分散して行い、GFSへ結果を書き込みます。本書にいくつかプログラムの例があるのですが、使い方はとても簡単で、分散処理どころかプログラミングの経験すらない人でも簡単にデータ処理ができてしまうと思います。

MapReduceの分散処理のアイデア自体はとても単純なものだけれども、しっかりスケールアウトさせるためにどうデータやトランザクションを効率的に分散させるかであったり、エラー時や機器の故障時にも処理をとめることなくファイルオーバーさせる技術は、(本書ではコンセプトしか説明していませんが)とても複雑であることがよく分かります。その複雑な部分を隠蔽して、単純なスクリプトで扱えるようにしてしまう点には感心しますね。

本書はGoogleを支えているシステムの基本的な技術を知るにはとても良い本だと思います。完全に読み物的な本で、著者もGoogleのシステムに触れるわけではなく、コードの例が豊富にはなかったのでコードレベルでのイメージがしにくかったのがちょっと残念ですが、その辺りはHadoopをちょっと勉強してカバーしたほうがいいかもしれないですね。少なくともGFSやMapReduceに対応する仕組みがどのようなもので、どうやって使うかくらいは簡単に把握しておこうかな。