Processing」という講演をしていたので聞きに行ってきました。皆様を前にして講演できることを大変光栄に思っております。Hadoop」について皆様に伝えていきますが、これはまさにデータ処理の新たなるパラダイムを提供するものではないかと私は思っております。簡単に自己紹介をさせていただきましょう。私は25年に渡ってシリコンバレーで仕事を続けてまいりました。OSのSpotlightの中に搭載されているテキスト検索エンジンを作り、90年代に入るとExciteでウェブサーチを担当し、直近だとYahoo!に勤めていました。実際にどういった研究をしてきたのかという話もしていきましょう。この10年間は一連のオープンソースプロジェクトに関わって参りました。foundationから招致を受けました。foundationとはいくつかのプロジェクトで関わらせていただいております。Nutchというプロジェクトを立ち上げました。「オープンソース機能」、「ウェブ検索エンジン開発」ということでかなり野心的なプロジェクトだったと思います。GoogleやMicrosoftがやってきたことに匹敵するものをオープンソースのプロジェクトでなんとかしようという目的でこのプロジェクトは今も継続中です。2006年、Nutchの一部を新たなプロジェクトとして展開させ、「Hadoop」というものが誕生しました。これの詳細は後ほど説明していきます。現在はクラウデラでアーキテクトとして勤務しております。同時にボランティアベースでチェアマンとしてエイセフにも在籍しております。これから「Hadoop」の本題に移っていきますが、その前に簡単に「Hadoop」の可能性について語っていきたいと思います。データというものは、今まで以上にどんどん増えています。増えているのか?その一因は、どんどんデータを保存するコストが安くなってきたからです。ハードウェアコストもこの数十年間低下傾向にあり、今後もさらに安くなっていきます。CPUの値段も下がっています。コンシューマがどんどんPCを使うようになった結果、値段がどんどん下がってきました。一方で、従来型のデータベースの技術はどうでしょうか?この勢いについていっていないんです。従来型のデータベース用にハードウェアを購入するとしたらどうでしょうか?実はコモディティ化されたPCハードウェアよりも高くついてしまいます。演算能力も同じ、あるいはPCとしての能力も同じなのに高くなってしまう。エンタープライズのテクノロジーの拡張性が問題となっています。数千台のコンピューターへのスケーラビリティがなかなか厳しい。先見的で透過的なスケーラビリティが大型のデータセンターではなかなか難しいというのが現状です。本当は値段も安くすることが可能なはずなのに、実際のところ、従来型の提供しているものと乖離がある。この乖離にこそチャンスがあると私は思っています。チャンスですが、このチャンスを物にするのは中々難しいです。言うまでもなく、数千台ものコンピューターに信頼性を持ってスケーリングすることはなかなか大変なことですから。ここで想像してみてください。ペタバイト相当のデータストレージを数千あまりのドライブでやっていかなければいけない。そのドライブは平均すると一年に一回くらい故障するかもしれない。数千のドライブが年に一回故障するとしたら、毎日のように何かしらが壊れているという計算になります。毎日何かしらが壊れる。皆様が開発しているシステムというものはこういう故障を見越した上で円滑に運用を続けなければいけないというのが現状です。いうことはストレージシステムとしても効果的に耐えられるものが必要ということになります。迅速にFailureに対応し、プロセスを中断させることなく耐用できるもの、そしてもちろん高可用性が担保されていなければいけません。ハードウェアドライブが一部故障したとしてもHD(ハードディスク)は担保されなければなりません。同時にフォールトトレラント設計なコンピューティングのフレームワークが必要です。したがって、たとえどこかでハードウェアが故障したとしてもそういったFailureに影響を受けることなくフォールトトレラントの環境で十分円滑に業務を遂行していかなければなりません。実はもう一つ課題があります。クラスタが大きくなると転送のコストがかかってしまう。確かにネットワークはスピーディになってきました。ネットワークで敢えてデータ検査をやらない方がスピードは担保できるわけです。100テラバイトのデータセットのプロセスが必要だったと想定します。1000ノードのクラスタがある。ネットワークを介してデータセットの読み込みを各ノードから別のノードへやっていると想像してみてください。各ノードが同時進行で他のノードと100メガビットのスピードで通信できるとしましょう。するとどうでしょうか?165分間かけて全てのデータセットをネットワーク上で処理するということになります。一方で、データがローカルドライブに乗っかっていた場合はどうでしょうか?するとデータの読み込みがより迅速にできるわけです。現在のドライブであれば秒間200メガバイトぐらいのスピードが出ます。換算すると、全部のデータの読み込みに8分しかかからない、ということになります。したがって、ここでの理屈は、データを動かすよりも実はこの処理能力を逆に利用して同一のハードウェア上で処理を行った方がより担保できるということです。Hadoop」こそがまさにデータ解析における回答ではないかと思っております。何千ものコモディティ化されたコンピューターにスケールできますし、全部のハードウェアをきちんと制御できます。全てのコア、CPU、さらにはハードドライブ、スピンドルなどがきちんと稼動する。Read/Writeもきちんとやりながら、効果的に処理できることが保障されていきます。他のコンポーネントを待つことなく、絶えず継続的かつ効果的にコンピューティング能力を使うことができるわけです。こちらは、新しいソフトウェアスタックになります。いくつかの異なる原理原則に基づいて開発されました。実は多くの企業によって既に採択されており、アメリカのWeb2.0系の大手企業、たとえばFacebookやTwitter、AmazonやeBayといったところは既に「Hadoop」を採用しております。いったweb系の企業以外でも「Hadoop」を採用する割合はどんどん増えております。新しいプラットフォームだと申し上げましたので、敢えて5つに絞り込んで皆様にご紹介していきたいと思います。これこそが新しいパラダイムの特徴だと思っておりますから。「コモディティ化されたハードウェア」。これは後半で触れていきます。2つ目は「シーケンシャルファイルアクセス」、従来のランダムアクセスではなくシーケンシャルファイルアクセスです。「シャーディング(パートシニング)」、データコンピティションを大型のマシンに関わらず、自動的にパートシニングしていくということです。「信頼性を保証しながら自動化を推奨していく」ということ。ハードウェアは時として壊れるんだという前提で、ハードウェアの上のソフトウェアに信頼性を組み込んでいくということです。5つ目は「オープンソースである」ということ。これは新たなパラダイムの現象における共通ブームなのではないかと。オープンソースこそがいろいろな事象を誘発していると思っています。最初の「コモディティ化されたハードウェア」からいきます。この場合の「コモディティ」とは何なのか。CPUやハードドライブ、メモリなど、PCの中に搭載されているものは劇的にコストダウンし、性能はこの10年間で大幅にアップしました。コモディティハードウェアを使って「Hadoop」の環境で使う、あるいはデータセンターの中で使う時にはある特定の使い方をしています。簡単な図が出ていますが、大型のラックやノードを使いながら活用するというやり方もあります。1ノード、単位で1から4くらいのCPUがあって、メモリがある程度割り当てられていて、2、4、8ハードドライブが搭載されており、各ノード単位で2、4、8くらい割り当てられている。これをラックに搭載し、ラック単位で20とか40ノードくらいが収まるでしょうか。ラックごとにネットワークスイッチが搭載されていて、このラック上のノードがここで繋がっている。スイッチごとにそれぞれ、より高次のスイッチと繋がっている。これがさらにラック全部を繋げていく。非常に典型的なコンフィグだといっているわけです。従ってデータをあちらこちらに動かすこととなった場合にはノード上のローカルディスクからいとも簡単に、効果的に同じラック上のデータを移動することができ、読み込むことができる。他のラックからのデータの読み込みとなると若干遅延が発生するという構成です。このコストなんですけれど、これも重要なポイントです。非常に合理的な価格になっています。このストレージと処理能力に対してです。拡張性は何万のマシンまでにも対応できますし、性能も線型に上がっていきます。10ノード、100ノード、1000ノード以上という使い方もされるということです。一つの原則について話をしたいと思います。この新しいパラダイムでの次の要素は「シーケンシャルファイルアクセス」です。全文インデックスは80年代に取りかかった内容なんですが、教科書やテキスト文庫を見ながらインデックスの作り方を学び、ビーツリーについてもその時覚えました。これはイギリスのデータベースの基本的なテクノロジーになります。ログエンのアクセスをハードドライブに対し、「全てのアップデートについてする」、「ビーツリーに対してする」という原則に基づいています。これ、ディスクシークなんです。ランダムアクセスはハードドライブのシークになりますから。この2、30年の間、シークの時間は短縮していません。コンピューターのパフォーマンスの要素として、他には追進できていないのがこのシークタイムで、むしろこれは例外的に増えていると思ってください。この「シークタイム=無駄な時間」なんです。アップデートやアクセスが頻繁にあるという時は、このビーツリーが非常に時間がかかって遅いということです。これは1980年代、1990年代に私自身が気付いたことです。Exciteでweb検索の仕事をしていましたけれど、効果的にインデックスを構築する唯一の方法が、これではなくてパッチシステムを使うことでした。大規模なデータベースをソートし、そこに対してアップデートし、アップデートをソートして、さらにそのアップデートとデータベースをマージさせて新しいバージョンを作るというアプローチを取りました。このような形でソートしたマージをバッチプロセスとして扱っておりました。しますと、全てシーケンシャルになるんです。シーケンシャルアイオペレーションになっていきます。すると、この大型のインデックスオペレーションの場合は10倍、100倍と速くすることができるんです。luceneにも同じ原則を用いました。すると伝送の時間、データをRead/Writeしている時間が大部分を占めるようになります。シークタイムという無駄な時間を減らすことができました。それによって、現在用いることのできるハードウェアの恩恵を十分に受けることができるようになったということです。次の要素の話をしたいと思います。「オープンソース」という側面です。オープンソースは、この何十年かの間に多く見かけるようになりました。多くの企業がその仕組みについて理解してきています。最大のアドバンテージはコスト削減ではないでしょうか。ソフトウェアが無償であるということ、無償で提供されるということがまず一つのポイントです。それから開発コストも大幅に下げることができます。そのコストをコラボレーションしている複数の企業で負担することができるからです。テストやQEについても同様です。後は文書化してドキュメンテーションする際にも他の企業と一緒にコラボレーションしてやりますので負担を分割することができます。それから、オープンソースのほうがよりよいソフトができるということも言えるかもしれません。開発者が何かを書いている際に「他の多くの人が見るんだ」と意識することによって、より質の高い仕事をするということも往々にしてあります。自分自身、あるいは自分の会社だけが使うんじゃない、他の会社も使うんだと意識することによって、より一般性の高いものを作るようになります。短期的に、自分のニーズを満たすためだけでは十分ではないからです。そんなものは他が関心を寄せてくれません。ソフトウェアを変えるためのコンセンサスを得ることにしても、一般的に使えるようなものでなければそれはコンセンサスを得ることができません。ソフトウェアはより質の高いものになっていくのではないでしょうか。それからもう一つのオープンソースのアドバンテージとして、社員の満足度が上がるという点ではないかと思います。自分の同胞や同僚から敬意を表してもらえるのでモチベーションを感じるわけです。それがとても重要なんです。2名とか5名のデベロッパーが集まったチームで仕事をするのではなく、100人単位のデベロッパーと仕事をすることによってモチベーションを感じる。転職して次の職場に行ってもその人達との繋がりは消えない。生涯を通してその人達と仕事をするようになっていくかもしれません。いう人達から敬意を表してもらえ、一目置いてもらえるということがモチベーションとなり、仕事を楽しいと感じるようになります。私自身もそれを目の当たりにしてきました。いろいろな人がこういった理由からオープンソースプロジェクトで仕事をすることを好むのです。Foundationで10年以上仕事をしてきましたけれど、最後のポイントとしてここで言っておきたいのは、オープンソースというのは「ただ無償のソフトウェアを提供する、そしてソースコードも開示する」ということではないのです。コラボレーションのコミュニティを構築するという意味も持つんです。これらのコミュニティがきちんと回っていくように担保していかなければなりません。Apacheはそれを見届けています。コミュニティというものは多様性が必要であると思っているからです。1社が支配するようなプロジェクトでは困るのです。どんな開発者でも均等な機会を与えられ、政治的な側面がなくなってきて、純粋に技術的なプロジェクトになっていきます。Apacheという場は、デベロッパーがコントロールする任意の団体であって、決して一企業が組織を支配しているわけではありません。それでは、これ以外の要素についても申し上げていきます。「Hadoop」の歴史に関連する様々なものです。2002年に始まったのがNutchです。このNutchはwebページにおけるデータベースの構築に必要なものでしたので、URLでデータベースをシャーディングしています。パートシーニングしている、データベースを複数に分けていくということです。URLのハッシュコードに基づいてこれをやっていきます。データベースの一つ一つのセグメントをネットワークの異なるノードに乗せていくんです。それからバッチベースの処理をしていきます。これは、さきほどちらっと話したことです。新しいページがクロールされたとします。そのデータベースを新しいページのリンクをもってアップデートしたい、どのページに対するリンクなのかということも含めてアップデートしたいということであれば、その新しいURL、アップデートをURLのハッシュコードに基づいて切り分けて、このシャードあたりの一つのファイルに対して入れ、ノードをコピーして、そのシャードを持っているノードに対し、既存のデータベースとそれを統合していくということをするわけなんです。非常に拡張性のあるもので、大方のデータベースには対応できますし、効率もいいです。いったステップを踏む必要があるんですけれど、今までマニュアルでやってきました。拡張性のあるアルゴリズムはあったものの、かなり大変でした。ある担当者がそれを4つ、5つのノードで走らせるということはできても、それ以上にはなかなか対応できなかったんです。様々な故障がある、ハードドライブがいっぱいになってしまうといった課題も出ましたし、このデータをコピーするというマニュアルの作業がとにかく大変でした。いう中で2004年になり、Googleが何枚かペーパーを出しました。Googleが同じ問題に直面していて、どう解決しているのかということを書いたペーパーです。実はGoogleも似たようなアルゴリズムを使っていました。Googleは自動化していたんです。いうシステムを持っていました。System、そしてMapReduceのコンピューティングフレームワーク、こうしたことについて書いたさまざまなペーパーが出ましたけれど、この中で分散型のソートマージに関する自動化について書いたわけです。それからGoogleは信頼性のハンドリングについても自動化をしていきました。何か障害があったとき、自動的にそれに対応することができるというものです。「ディスクがいっぱいになってしまったら何か他のものに振り返る」というようなことを自動でやるようになりました。オープンソースもこうでなければいけないと考えたんです。当時はGoogleしかこういうツールをもっていませんでした。オープンソースでもこれが必要ではないかと考えまして、それを提供していこうという取り組みが始まったわけです。そこで私とマイク・カフェデラーという2名の人物が数年間に渡ってこういった作業を続けて参りました。これも我々の空いている時間で開発を続けてきたわけですけれども、恐らくこれが具現化する、つまりは何千台というコンピューターで信頼性を持って実施するには相当の時間がかかるだろうと予想しました。20台まではいきました。信頼性は担保できたわけです。冒頭でも申し上げたように信頼性の高い分散ソフトウェアを開発するというのはなかなか大変です。そこで2006年、私はYahoo!と対話を始め、Yahoo!は興味を示してくれました。いった課題があるよね、と。彼らは、我々がNutchで開発したソフトウェアをプラットフォームとして採択するということに興味を示してくれました。大掛かりなエンジニアチームをYahoo!は抱えていましたし、多くのエンジニアも興味を持ってくれましたので、2006年に私はYahoo!に入社しました。「Hadoop」というプロジェクトが誕生しました。System、それからMapReduceだけを引っ張ってきて、こういった新たなプロジェクトが誕生した次第です。ここで、HDFSとMapReduceについても簡単に紹介しておきましょう。System」の略称ですが、非常に拡張性はいいです。ファイルはコモディティハードウェアできちんと共有化、パーティシニングできますし、非常に効率も高い。Read/Writeも効果的で値段も安いです。ハードウェアコストもクラスタの運用も比較的低コストでできてしまいます。信頼性はどうでしょうか?信頼性に関してもほぼ全部自動化できている。各ブロック単位で3つのデータノードにそれぞれデュプリケーションされていますので、データを失ってしまうという確立も少ないわけです。クラスターも何年もの間、Yahoo!内でほとんどデータを失うことなく実装が続いています。自動的にデータのリバランスも行われます。1ドライブがいっぱいになってしまったり、ハードウェアが故障してしまうと、デュプリケーションが他のノードへ自動的に行われる。全て自動的に行うだけでなく、監視も自動的に行われています。ファイルシステム、シングルマスターがあります。このシングルマスターにはホットスペアがありますので、万が一これが故障、Failureした場合でも、可用性が影響を受けるということはほとんどないと言ってもいいかと思います。MapReduceについて簡単に説明しておきたいと思います。プログラムモデルとしては至ってシンプルで単純な内容になっていますけれども、コモンパターンのプログラムの汎用性ということで、大方のクラスターでも並列環境が組みやすいという特徴を持っております。インプットデータを取り込み、そしてこれを塊ごとに切り分けていく。ここでは参考までに3つに分けていますけれど、塊ごとにユーザ定義のマップ関数に引き継がれていきます。このマップ関数を使いながら各データ、アイテムごとに処理を行って、キー、バリューペアを生成していきます。マップ関数のアウトプットがソートされていきます。マップ関数のアウトプット単位でユーザ定義のレデュース関数の方にどんどん引き継がれていきます。マップ関数からA、B、Cというキーが生成された場合にはAに相当するものがこちら、Bに相当するものがこちらのレデュース関数の方に引き継がれていく。Aペアのものが全てここ、レデュース関数へいっぺんに引き継がれていく。これを反復的に引き継いで採取的なアウトプットへと到達していきます。プログラミングモデルとしては至って単純で、2名のユーザがアプリケーションコードをマップ関数、レデュース関数に挿入しておいて使うということもできます。実はこういうやり方を使えばありとあらゆる種類ができるということも証明済みです。大型のクラスタであったとしてもハードウェアを十分にきちんと活用するということが担保される。ソート、マージもできますし、これ以外のメタフォに変換された他のアルゴリズムについても対応できます。このMapReduceについてもう2、3点だけ触れておきたいと思います。MapReduceのコンピュートノードというのはHTFSストレージと同じです。同じクラスタ上で実装されていきます。従って、ローカルハードドライブから読み込んでローカルハードドライブに書き込んでいくということができます。そこからクラスタを通してデュプリケーションが可能です。IOはほとんどの場合ローカルで処理できてしまいます。CPUやハードドライブも稼働率を上げながらハードウェアに相当する分だけのスループットが保証されるわけです。数百のハードドライブがあれば、データのプロセス能力も、4000あれば4000分に相当するスピードだということで、かなり目を見張るものがあります。ほとんどのシーケンシャルファイルアクセスを使い、さらにソートマージを直接サポートしています。ソートマージ型のコンピテーションに対応していると。3つ目に記したように、期待通りの信頼性、スケーラビリティが自動化されていきます。MapReduce、HTFSについて簡単に紹介しましたけれど、カーネルだけが使われる場合はほとんどないと言っていいかもしれません。MapReduce、カーネルを中心にいろいろコミュニティが拡大しております。いろんなプロジェクトがあちらこちらの開発者の間で浮上しています。他のコンポーネントはどうなのかといったことを謳った書籍も発表されておりますし、有償でいくつかの企業がサポートを提供し始めています。この下の図のように補完的なツールがどんどんネットワーク的に拡充しています。読みづらいのを承知で紹介しておりますが、MapReduceがちょうどこの中心に来ております。これを取り囲むような形でのコンポーネント、そしてこの中心、要となるMapReduceとHDFSのお互いの依存関係が読み取れます。実はこの図、1年ほど前のものですので、1年たった今はさらに複雑化しています。管理は難しいかもしれません。このコミュニティの全てを取り込んでいくということは大変かもしれません。Suiteがあったりとか、まあ、Linuxのディストリビューションを構成するものがその周りを取り囲んでいくという発想と全く同じです。そこでクラウデラ、我々はこのような複雑なコミュニティを何とか簡素化しようとして全部のコンポーネントを皆様が自身で導入しなくてもいいようにパッケージ化して提供しています。クラウデラのディストリビューションということで、かなり使いやすいものを私どもは提案しております。クラウデラのディストリビューションに含まれているコンポーネントは全てオープンソースです。ディストリビューションそのものもオープンソースでフリーです。従って誰でもダウンロードできます。コンポーネントのコンパチブルな標準セットもありますので、クラウデラの新たなるディストリビューションが発表されたとしても、コンポーネントプロジェクトの最新バージョンを取り込んで、そして十分にコンパチブルであるかというテストがされた上で、パッケージ化されてディストリビューションが出来上がり、という経緯をきちんと辿っていますので、コミュニティに対して大きなサービスではないかと思っております。ユーザの皆様がコンポーネントをいちいちインストールするという時間を省くことが可能となっています。このエコシステム、クラウデラのディストリビューションの、これ以外のコンポーネントについてちょっと触れていきたいと思います。有名なところでPig、Hive。高次でのクエリ言語になりますけれど、MapReduceの生成を行います。Pigはインペラティブデータ言語であるということ、そしてほとんどの場合、ETLのタスク用に使われるので、データセットのトランスフォームに使われることが多いかと思います。一方でHive、こちらはSQLをクエリ言語として採用しています。大体はデータウェアハウス系のアプリケーションに使われているケースが多いかと。データをソートし、そしてHiveを使いながらクエリをかける、といったような使い方が一般的だと思います。続いて、有名コンポーネントとしてAvro。共通のデータフォーマット、コモンデータフォーマットを提唱しておりますので、いろんなコンポーネントがきちんとコンパチブルで、一つのコンポーネントと他のコンポーネントが違うコンポーネントだったとしてもきちんとお互い認識しあえるということ。スキーマ言語を使っておりますので、データ構造はスキーマ言語を使って表現されています。データ構造のエヴァリューションにも対応しておりますので、追加だったり、名義を変えたり消去したりとか、あるいは古いデータセットがそのまま新しいコードであったとしても読み込めるようにもなっておりますし、古いコードであったとしても新しいデータセットを読み込めます。上位、下位の互換性があるということです。それから非常に効率のいいバイナリーコーディングも含まれておりますので、ありとあらゆるデータセットがコンパクトに表現できます。従ってその結果、冗長性をある程度削減するということにも繋がっております。Avroのファイルフォーマットは自己記述型のファイルになっておりますので、Avroのデータファイルを他の第三者に引き継いだとしても、実際にデータ構造が何なのかということをレファレンスしなくてもきちんと把握できるという仕組みです。Avroはリモートプロシージャコール、あるいはRPCシステムにも対応しています。JAVA、C、C++、Python、それからRuby、PHP、C#といった言語にも対応しました。それからプリデュースと一緒に使えるということ。プリデュース系のプログラムを簡単に使いながらAvroデータフォーマットに置き換えていくということです。次のコンポーネントも面白いんですけれど、Mahoutです。このMahoutというのはライブラリ。マシンラーニングのアルゴリズムのライブラリで、例えばクラシフィケーション、クラスタリング、そしてレコメンデーションエンジン、そういったものをサポートします。レコメンデーションをしなくてはいけない、それを自動でしたいという場合にはいくつかレコメンデーションのアルゴリズムがあるのですが、どれが適切なのかということをMahoutからデータにあわせて選んで使えます。このアルゴリズムは大部分はMapReduceで作られています。非常に便利なライブラリです。それから今度はHBaseです。これはGoogleのビッグテーブルというプロジェクトからインスピレーションを得て始まったものです。リアルタイムのオンラインデータベースで、HTFSで全てのデータが格納されており、プライマリーキーでアクセスすることもできます。非常に効率的なスキャンをデータの範囲に対してかけることもできます。キーでデータはソートされていますので、その順番どおりのスキャンも可能です。それから、HBaseはパフォーマンスが高く、スケーラビリティもあります。そのノードに対する書き込みのスピードでインサートをすることができますし、スキャンも可能です。ハードドライブからの読み込みと同じスピードでソートをすることができます。パフォーマンスも高く、スケーラビリティもあるということです。MapReduceと一緒に使うことができます。HBaseテーブルをインプットとしてMapReduceのジョブに適応することができますし、MapReduceのアウトプットを逆にHBaseに対して書き込むということもできます。次のコンポーネント、これも面白いです。これはデータ収集のフレームワーク、データコレクションフレームワークです。信頼性と可用性に焦点を当てています。通常はログデータですし、他のリアルタイムイベントのデータでもいいんですけれど、データを生成するサーバにエージェントを格納してFlumeがそれを共通の箇所に対して伝送していきます。そこで処理をするわけです。あるのはHDFSに対してデータを伝送すること。そこからアーカイブのサーチをかけたりするのでPigとかHiveを使うんですが、そうでなければHBaseに伝送することもできます。すればオンラインでイベントにアクセスすることが可能になりますし、そうでなければなんらかの検索インデックス、サーチインデックスに送ったり、そこで最近のイベントのトラッキングをしておいて、検索インターフェースでブラウズするということもできます。これらに対し、とにかく一つに対して送ることもできれば、この図にあるように三つに対して送るということも可能になっています。それがFlumeです。この何年かで私が見てきた限り、「Hadoop」の採用においてパターンがあると思っています。典型的なパターンを言えば、まず「Hadoop」のクラスタをインストールするのは特定のアプリケーションでの話です。そのアプリケーションは他の形で対応できないデータセットが問題を抱えており、例えばデータセットに対してこういう解析をしたいんだけど、他のテクノロジーを使ってみたができなかった、というような場合です。少なくとも経済的にはできないというような場合で「Hadoop」をやってみると。小さなクラスタ、10から20のノードのものを採用してみて、結果として簡単にデータセットの処理ができる、アルゴリズムの実装ができるという発見をするんです。その一つのアプリケーションで使い始めます。すると、他のデータセットをクラスタに持つことは良いと、しかもこれが効率的にできるということに気付いてデータセットを増やしていくんです。最終的にはその会社のほとんどのデータをHDFSのファイルシステムに入れることになります。いろいろな解析をすることもできれば、これまでできなかったような実験的な処理もすることができるということを発見していきます。すると多くの社員がこれを使うようになります。データを縦割りで持っていると一部の社員しか見れないということが起きてしまいますが、そうではなくデータは一箇所にすべてを置いて、みんなが見られるようにするというアプローチです。「Hadoop」はセキュリティ性が高いですから、全てのデータに全ての人がアクセスする必要はないんですが、もしそうだとしても可能です。サポートしますし、切り分けてセキュリティをかけ、アクセスを限定することもできます。いう形で始めていきます。いろんなことを簡単に試せるようになるのです。いう一つ一つのアイディアを簡単に試し、うまくいけば本当に採用するということです。ここに、Facebookからの引用を載せています。ある人がこんなことを言いました。「たくさんデータがあるから『Hadoop」』使うんじゃない。『Hadoop』を使うからデータがたくさんあるんだ」と。さきほどパターンを説明しましたけれど、ある特定の問題を解決するために「Hadoop」を採用したら、他にもたくさんのデータをサポートすることができると気付いて、増えていくということなんです。たくさんのデータがあればあるほど有益な解析ができるということに気付いてデータが増えていく、こういうパターンを大抵の企業は辿っているはずです。少なくとも私はそれを見てきました。最後のまとめに入って行きたいと思います。この、パラダイムのアドバンテージについて申し上げておきます。コスト効率が高いということ。他のテクノロジーに比べて、「Hadoop」を使えば何オーダーでもデータの格納が安くなると思ってください。他の方法では大きなデータセットを格納できないような場合にも格納できますし、処理も効率的にできます。汎用性が高いということもアドバンテージです。非常にパワフルでプログラミングも簡単。特定のモデルとかデータに対する考え方に限定されることがないのでとても柔軟性があり、オプションもたくさんあります。処理のオプションが数多くあるのです。最後のアドバンテージとしては、入りやすい、始めやすいということです。データベースを最初に設計して、スキーマを作ってからでないとデータの収拾ができないということはありません。データをとにかく生の状態で集め、そしてそれを全部保存してください。それを変換していく必要があれば、後から変換するように薦めています。その場合はデータをいくつかの表現方法で持つ方が良いです。最初から時間をたくさん費やす必要はありません。それをやってしまうと後から使えないデータが大量に発生します。どのデータが使えるかどうかもわからない状態ですから、必要に応じて後でやればいいと考えています。それでは最後に、今後の話を少ししておきたいと思います。ストレージならびに演算のコストはこれからも下がり続けると思っています。何年も前からムーアの法則は正しいということを証明してきました。CPUに加えてハードウェアもメモリも大容量になってきていますし、しかも安くなっています。多くのデータを格納し、保存することが経済的にもできるようになって来ています。使い勝手のいいデータを収集することが可能です。モニタリングをして、例えばそのイベントのデータのみならず、イベントのコンテキストも含めて経済性のある形で格納しておくということが可能になっています。データが多くなるということはそれを回線に繋げていけるということなんです。仕事に関するデータの場合にはビジネスの状態をよりよく理解することが可能になります。Googleのピーター・ノーヴィックがこう言いました。Data」、データの非効率的な有効性とでもいいますか。ようするにたくさんのデータを持ち、シンプルなアルゴリズムにしておいたほうがいいと言うんです。データは、少なくて賢いアルゴリズムを持つよりも、たくさんのデータを持ってアルゴリズムはシンプルなほうがよっぽどいいと言っています。アルゴリズムの改善にさほど時間をかける必要はないと、それをやるんだったらよりデータを多く収集しましょうと。アルゴリズムについては、必要なデータが全部集まってからでいいじゃないか、それが一番効率的な解析やデータセットに対する対応の仕方だと彼は言っています。そのほうがより正確に事態の把握ができると。いったことを全てあわせて考えますと、企業やビジネスは、より多くのデータを集めて解析することによって、改善に繋げることができると思っています。新しい分散型データOSのカーネルとして「Hadoop」を使えばまさにこれを実現できるのです。本日はご静聴ありがとうございました。BANK」動作ムービーネタのタレコミその他のお問い合わせ広告掲載についてGIGAZINEについて。