Hadoopって何?しおやHadoopとは何ぞやということなんですけれども、MapReduceという並列処理用の計算フレームワークと分散ファイルシステムのオープンソース版の実装です。Cutting)さんという人で、検索エンジンLuceneの作者として有名な人なんですけれども、この人が元々はNutchというLuceneを使ったウェブ検索システムを開発してたんですね。その分散システムをやっていた頃、Googleの方でMapReduceを作りました、クラウド向けのファイルシステムを作りましたみたいな発表があったんで、そのアイデアを取り込んでできたのがHadoopの原型です。その他いくつかのプロジェクトを取り込んで、今はApacheのトップレベルプロジェクトとして名を馳せています。Hadoopという名前なんですけど、これは息子さんが持っているぞうさんのぬいぐるみの名前がHadoopなんだそうです。意味がある単語ではない。Hadoopのコア部分の構成なんですけれども、特に有名なコンポーネントは3つあります。一つ目がMapReduceという並列処理を行うところです。(HDFS)というファイルシステム。ここにデータをため込んで、それをMapReduceで計算して、また計算結果を格納するシステムになっています。この2つが本当に中核的なコアの部分。これともう1つHBaseという超巨大なテーブル、縦が数十億行のオーダー、横は数百万カラムという大きいテーブルを実現している、この3つがHadoopの最初の頃からある大きな機能です。(図のMapReduce・HDFSとHBaseの境界を指しつつ)ちょっとここは分かれているんですけど、MapReduceとHDFSがとにかく中心になっている。HBaseはHDFSの一アプリケーションという位置づけになっているようです。MapReduceはどんな処理をやっているかしおやで、そのMapReduceなんですけれども、これはどういうものかと言いますと、グーグルが発表した大量データ用の分散処理フレームワークです。基本になるファイルシステムにデータが乗っていて、まずそこのファイルシステムからデータをMapするという形で、情報をまず取り出す。取り出した情報をReduceというフェーズで計算していって、その結果をまたファイルシステムに戻す。いうように、MapとReduceの2段階に分けて計算をするので、MapReduceと言います。具体的にはどんなことをやるのかと言いますと、これはMapReduceのチュートリアルに出てくるんですけれども、単語を数える処理というのを例にとって説明してみたいと思います。Worldという4単語の文章があって、この単語の出現頻度を数えていきます、というような処理をやってみようということを考える。普通のプログラムだと一単語読んでHelloが1件、次Worldを読んでWorldが1件、Byを読んでByが1件、でもう1回Worldを読んで2件、で1234と数えるんですけれども、MapReduceではどうやるかと言うと、まずHadoopが「このテキストを処理してください」というのをマップタスクに渡します。マップタスクはプログラマが書きます。マップタスクの方ではこの文をスペースで分割してHelloが1件ありました、Worldが1件ありました、Byが1件ありました、Worldが1件ありました、というように(キューに)投入します。キーとバリューのペアとして投入するというのがここの処理のミソです。この例だと、テキスト1行しかないから何でもないんですけど、例えばこのテキストが100行とか10,000行とかあった場合には、それを計算ノードで分割して、あっちのノードではこの100行、こっちのノードでは次の100行っていうように分担して処理ができます。この“分割して投入する”というところで並列化ができるということになります。データが投入されてくると、Hadoopはそのデータをキーによって並べ替えていきます。ここではアルファベット順に並べています。Worldという順番にならべて、ByとHelloは1個しかないですけれども、Worldの場合は2つあるので1個のデータが2つというリストができあがってきます。MapReduceを実行すると、まず投入されたデータでここまでのデータの計算を全部やっていく。Mapしたデータが全部揃ってきれいにソートされた時点で、それをいくつかのノードにまた分担して、各々にReduceタスクとして配っていく。ここでちゃんとソートして配っていくので、うまく分業してできるようになっている、という仕組みです。Reduce側ではキーワードとバリューのリストをもらうので、それについて計算をしていく。今回は出現頻度なので、ここの数字を足し合わせていく。Byは1件、Helloは1件なんですけどWorldっていう単語の場合は1件が2回なので1+1で2件出てきましたというような計算をするということです。(コード例を指して)ここの青で染まっているところがプログラマが書く仕事です。最初に入力されたデータを分割するところと、Mapされたデータをソートしてキーごとに整理するというところをHadoopがバックエンドでやってくれるという役割分担になっています。これがMapReduceの処理ですね。(HDFS)のしくみしおやこうやって処理されたデータあるいはこれから処理したいデータはHDFSに保管されます。これは、Googleが作ったGoogleFileSystemにインスパイアを受けたファイルシステムということになっています。いうシステムかというと、メタ情報を管理するネームノードというのが1つありまして、それの配下にデータノードというのがいっぱいあると。データを一つ保管するときに、必ずこのデータノードのどれかに適当にコピーを置きながら管理をしていく。すると、例えばこのノードがいきなり壊れても、どこかこっちはこっちにレプリカがあるからデータとしては大丈夫というような分散ファイルシステムになっています。今は結構賢い実装になっていて、今データを3つ分散しますって言いましたけれども、例えば、メインで計算しているノードはこっち側のラックにあるので、ここに2つくらい置いておこうと。するとこのラックが死んだときに怖いから、ちょっと遠くにあるラックにもう1つ最後の1個は分散しておこう、というようにラック同士っていうのもある程度意識してデータの配置をしてくれる賢い分散ファイルシステムです。いうのはだいたい絶対安全なように作るんですけれども、説明資料によると、今このネームノードっていうメタ情報を管理するところが単一障害点になっていて、これが落ちるとデータにアクセスできなくなっちゃうというのが問題点のようです。HBaseはあんまり話す内容がないので割愛したいと思います。MapReduceと分散ファイルシステムHDFSの説明は以上です。Hadoopをちょっと使ってみるしおやちょっとここで、じゃぁ具体的に使うとどんな感じなのっていうのに移りたいと思います。Hadoop自体はJavaで書かれていまして、彼らのプロジェクトのサイトによるとWindowsかLinuxで動かすというような説明になっております。OpenSolarisでもちょこっと動いたんですけども、本格的な分散構成まで試してないので、実際に動くかどうかはわからないです。今日はHadoopの作者が勤めている会社から配布されているVMware用のイメージというのがありまして、それをセットアップして環境を構築してみます。構築と言っても本当に起動するだけの超お手軽環境なんですけれども。...なので、もうVMwareを立ち上げるとこういう風にHadoopの0.13、結構古いバージョンですけれども、が入っていて、すぐ使えるようになっています。Hadoopのおもしろいところというか、ちょっとあれだなというところは、Hadoopそのものはbinフォルダの下にHadoopコマンドというのがありまして、Javaで実装されたコマンドが置いてあります。このHadoopコマンドを使ってプログラムを実行したり、さっきのHDFSにデータを出したり入れたりします。このコマンドを通さないと使えないのがちょっと不便と言えば不便なんですけれども、まぁそれはそれということで。使ってみようかなという分にはこんな感じで簡単にセットアップされているバーチャルマシンもありますし、自分でインストールするときもApacheのサイトからダウンロードできるディストリビューションを展開するともうほとんどこういう風に(同じディレクトリ構成に)なっている。スタンドアローンモードだともうそのまま使えます。さっきのワードカウントプログラムをちょっと動かしてみたいと思います。Hadoopコマンドでファイルの操作を指定するというコマンドを出して、今Hadoopのファイルシステムにどういうファイルがあるかなというのはこういう感じで、ls(LS)コマンドのように使います。中身はこんな感じで入っています。プログラム自体はjarファイルをあらかじめ用意しておくと。このjarファイルを指定して実行する。jarを指定して、このjarの中にあるwordcountというプログラムを実行してくださいというような指定の仕方をします。こんな感じでjarファイルとプログラム名を指定してやるとプログラムが実行されていきます。今Mapが、ちょっと速いんですけれど、最初スタートしてマップが50%、マップが100%終わって、データを今ソートして、次にReduceをやる。4単語しかないからあっという間に終わっちゃうんですけれども、これでデータが終了しましたと。説明が抜けてましたけど、こっちが入力ファイルでこっちが出力ファイルなんですけれども。もじ今はローカルのファイルシステムにファイルがあるわけではなくてHDFSの方に入っている?しおやはい。かさいそれはそのVMwareのイメージの中にHDFSも入っている?しおや入っています。もじ仮想ファイルシステムっていうような感じなんですかね?ローカルな環境から見ると。今プログラムは終わっているんですけれども、Hadoopっていう名前でgrepすると、バックではいろんなデーモンが実は動いている、と。肝心な処理結果は...確かこんな感じで。この(配布されている)VMはバージョンが古いんだか何だか知らないんですけど、実はマニュアルと少しコマンドの体系が違うんですよ。(Hadoopでcatコマンドを操作)catで出力するとさっきお話した内容の処理ができていると。これはまだHadoopのファイルシステム上に乗っているので、このデータが欲しいなぁというときには、やっぱり面倒くさいんですけれども、(Hadoopの)getコマンドで、ローカルファイルに降ろしてくるという感じで操作します。Hadoopコマンドを使いながらプログラムの操作ですとかファイルの管理をするっていうのが、Hadoopプログラミングをするとちょっとまどろっこしいなぁと思います。具体的なプログラムの解説は今日は細かくやらないですけれども、ソースはチュートリアルにあるソースをそのまま使っております。ソースは全体で60行くらい。プログラムはMapReduceのクラスを継承しておいてMapのメソッドとReduceのメソッドを実装します。MapするためのクラスとReduceをするためのクラスと2つ定義してあって、Mapメソッドの中ではtokenizerっていうJavaのユーティリティクラスがあるんですけれども、それを使って単語を切り取ってアウトプットというところに投げ入れる。さっき話した2番のところ(=プログラマが書くべきMap処理)。Reduceする側はテキストでキーとそのキーに対応する値のリスト、ここではiteratorという定義になってますけれども、のペアが上から降ってくるので、それを使って単純に合計して結果を出力する。いうような、この2つの処理を考えて、プログラムを書きます。こっちの下のところが実際にプログラムを実行するところです。どんなことが書いてあるかというと、おなじみのmainの引数のところと、それからJobConfっていうのがありまして、このタスクにどうやってデータを渡してやるかというのを指定してやる。さっきのワードカウントの例ですと、テキストファイルを読み込んで一行ずつ渡すっていうようなことが、この辺につらつらと書いてあります。テキストを一行ずつここで定義したクラスに渡してくださいというようなことが書いてある。本当は中にいろいろ機能があって、この後の方にもでてくるんですけれども、今日はここまでということで。Hadoopの基本部分はこんな感じです。Q&Aかわの前回までの話でHadoop、いわゆるクラウドコンピューティングをやりたい人が、リソースとしてクラウドを使うときに結局実際にはHadoopのMapReduceのAPIを叩いて使うというような理解で、実際に自分がやりたい処理はどんな人も持っていると思うんですけど、MapとReduceをどういう風に分けているのかっていうか、構文解析みたいな今の例だとわかるんですけど、そもそもMapとReduceをどういう風に処理を分けるのかという基本的なところがよくわからない。しおやそれはアルゴリズムによりけりでケースバイケースかなとは思うんですけれど、その辺はやっぱりMapReduceってデータもこう、インタフェースが決まっているんですけれど、キーとバリューしか使えないし、そもそもこの処理がやりたいんだけど、どうMapしてどうReduceすればいいのかという、結構判断が難しい。今Hadoopのプロジェクトを見るとですね、それが今日の後半の話のメインなんですけど、知らないプロジェクトがいっぱい並んでいるんですよ、これが。去年くらいまでのHadoopの記事を読むと、最初のMapReduceとファイルシステムとHBaseの3つぐらいで紹介している記事が多いんですよ。最初は実際そうだったんですけど、今はHadoopのサイトを見に行くと、サブプロジェクトがこ〜んなにいっぱい並んでいるんですよ。これは一体なんだろうというのが今回の後半です。MapReduceのプログラムはやっぱり難しいということで、もっと身近な形でデータを扱えるようにしようというのがこの辺のプロジェクトなんですね。昔からHBaseという超巨大テーブルというのはあるんですけれども、それだけではやっぱりいろいろ厳しいので、いろいろなものが出てきている。今回、全部翻訳するのかどこまで翻訳するのか、これからいろいろと検討されることになると思うんですけれど、今日はその入り口というところで(簡単に紹介していきます)。Worldのサンプルというのは、なぜ分散する必要があるのかわからないんですけど。単語はさっきの話だとHadoopの中ですでに計算されていますよね。これはなぜ分散させる必要があるのか。penであったときに、これを例えばノードAがやっているとすると、こっちの行はノードBがやりますよ、こっちの行はノードCがやりますよ、っていうように大量のテキストを(行単位のまとまりで)分割して実行できるようにする。いぬいテキストが長い場合の分割ということですか?しおやそうです。チュートリアルの例がこうだからこうなっているんですけれども、実際の実用的なMapReduceの例だと、ここのブロックはもっと大きい単位のデータ。ページ丸々1つとか、何M分の、何十ページ分とか。MapReduceする必要はなくて、それではノードAに与えられてその中だけで計算されますよね。この分割してというところはもうシリアルに、今まで通りに書くしかない。Worldっていうひとつの単位がMapプロセスに渡されていると言うことですよね?それの処理結果がビッグテーブルに渡されるとするじゃないですか。それを回収するのは誰が回収するんですか?Reduceの中で回収されるんですか?しおやこの出力されたデータを回収するのはHadoopの役目になります。1件>というキーとバリューのペアを置いておく。これをHadoopが中でいったん並べ替えていくわけですね。ここはもうフレームワークの中でこっそりとやられてきます。全部入力したデータが処理しおわって、いったん一時ファイルのような形で展開された後、Reduce側のノードの空き状況とか、これとこれはこっちのノード1でやってくださいとか、これとこれはノード2でやってください、と。まとめて渡っているように見えますけど、正確には2つのタスクとして。いぬいこれだと2段階になっているということですか?しおやそうです。2段階になっています。いぬいReduceのプログラムには2種類あると言うことですか?この場合。ワードをカウントするのがMapReduceのプログラム(のReduceタスク)と言うことですよね。それを、その1つのノードが計算していたところの全体をまとめていくプロセスっていうのは別のリデュースですか?しおやはい、それはまた別にあります。この下りは多少説明者に混乱があって、Partioner(Mapの処理結果をどうReduceに割り当てるかを制御するクラス)やOutputCollector(Reduceタスクの処理結果を回収するクラス)について未消化のまま話している。MapReduceの処理は基本的には、Map->(Sort)->Reduceという流れであって、ここの例ではMapタスクが単語を投入、Reduceタスクが出現頻度をカウントして、その結果がHDFSに保存される)いぬいそれはそれぞれのReduceが分散していて、それぞれが勝手に足し算していって、それが1つに勝手にまとめられるということですよね?そういう意味では2段階はなくて、1段階のReduceの方でワードをカウントして、その結果をそれぞれ入れていって、それがテーブルに収まっていって、最終的にはそのテーブルを何らかの方法で取り出せばいいということですか?しおやそうです。さっきの例の出力の場合だと、ああいう形でファイルにどんどん入っていく形になります。Javaで理解する」http://www.atmarkit.co.jp/fjava/special/distributed01/distributed01_1.html)では単語ではなくてAとかBとかの文字をカウントする例があって。MapReduceは何に使える?ともじしおやさんだと身近な業務の中で「あっ、これにMapReduce使えるな」みたいなのってあったりします?しおやうちの製品の場合、LogStorageというログを管理するシステムがあるんですけど、それの解析ステージ、ログって1行1行ばらばらですから、並列で処理する方がやっぱり賢いので、それのインデックス付けにはもってこいかなと。もじイメージとして生(なま)のログをまずマップして、何らかのキーバリューフェアの集合体にして、そこまでがマップ。それに対してどういう集計結果がほしいかというのをプログラムするところからリデュースになる...いぬい分散する処理は人が考えないといけないので、そこは難しいですよね?そこがポイントですよね。人間が分散できると思えない処理は処理できないということですね。もじ本当にむちゃくちゃ大量なデータで普通にシリアルにやっていたらきりがないし、分散してやっていかないともしかして何ヶ月何年もかかるような計算量のものがもしあれば、こういうものを使うと。いぬいゲノムの解析とかはこういうのが便利でしょう。みやプログラムの話は全然わからないんですけど、一般的な業務システム、社内の人事とか財務とかトランザクション処理とか、そういうのではMapReduceってあんまり効果ないって考えた方がいいのかな?しおやみなさん、そう思われるらしくて、Apacheのプロジェクトの方々はそこでどうしたかと言うと、「わかった、もうMapReduceなんか使わなくていい。みんながよくわかっているSQLを使えるようにしてやろうじゃないか」というのがApacheのサブプロジェクトになりました。データを計算するだけなのにアルゴリズムを適応させるのは面倒くさいので、HiveというSQLっぽい言語で書けるようにしました。すると、SQLからMapReduce処理っていうところは全部Hiveでやってくれるので、プログラマ側は「この処理は早くなるんだろうか、ならないんだろうか」とか心配しないでMapReduceの計算力を使えるようになったんですね。もじ例えば業務アプリケーションの中でSQLライブラリを叩きたいところがあったとしても、データが巨大にない限りは意味ないわけですよね?1台のPCとか1台のサーバとかで処理できる範囲のデータしかないんなら、普通に素直にSQL組めばいいということですね。いぬいこれは人間が分散できないといけないわけですよね?SQLにしても。しおやSQLの場合は、十万行のSELECTをやりたいというときに1万行ずつに分けて、というところはフレームワーク側が面倒みてくれる。人間側としては、なんかよくわからないけどSQLを書けば結果は返ってきますよ、と。いぬい例えば暗号の解析とかに使えると思うんですよね。暗号の解析は、暗号化された結果がありますよね。結果が無作為な文字列、人間が見たらよくわからないキーになってるじゃないですか。それは暗号化のアルゴリズムで戻せないアルゴリズムで暗号化しているわけですよ。それを総当たりで計算していくときに、総当たりするとひとつのパソコンでやるとめちゃめちゃ時間がかかるわけですよ。いう並列計算をすると、ABとかACとか順番に、自転車のダイヤルロックでひとつずつやっていくようなものですよね、あれを分散してできるので、一瞬にしてできるという。みやプログラムに詳しくない人の見方なんだけど、クラウドがいろんなものを解決しますという世の中いろいろ言われているけど、これで本当にどこまでの業務システムがここに乗っけることによって幸せにハッピーになれるのかというところが僕の最終的に知りたいところでもあって...適材適所なのか何でもできちゃうのか。しおやできるかできなかと言えば、しょせんコンピュータが計算することですから基本的には今までと変わらないんですけれど、Hadoop内、クラウドの環境に乗せておくと何がうれしいかというと、スケーラビリティが取りやすい。今まで100人ぐらいの規模の会社のシステムだったのが10,000人になりましたとかっていうときに。100台コンピュータ増やしましょうっていう風にはなかなかすぐにいかない。かさい今あるコンピュータ資産、計算機資源のまんまで処理能力が上がるみたいなスケーラビリティが確保される。いぬい僕、今回Hadoop結構勉強してきたんですけど(笑)、Hadoopのフレームワーク自体が勝手にコンピュータをどんどん追加していったり削除したり、そういうことが柔軟にできるというところも一つの特徴ですよね。かわのそれがよくわからなかったんですけど、リソースが追加されるのを気にしなくていいんですか?クラウドのリソースがどんどん追加されて処理能力が上がるか上がらないとか、そういうことは処理を頼む方は気にしなくていいんですか?いぬい処理を頼む方は気にしなくていいですね。そのリソースをどれだけコンピュータが追加していくなら追加していく方で、そういう手順があるわけですよ。並列計算で例えば暗号化の計算って無限に分割できるわけじゃないですか。あなたは4桁を総当たりしなさい、あなたは5桁を総当たりしなさい、あなたは6桁を総当たりしなさい、というのがあるわけですよね。あなたは数字の4桁を総当たりしなさい、あなたはアルファベットの4桁を総当たりしなさいと、それはかなりの数があるわけですよ。それを分割できるわけですよね。それをコンピュータが増えれば勝手にHadoop自体が分散化してくれる。コンピュータをどんどん追加していけば、どんどん計算の時間が短くてすむ。かわのじゃぁ、人間がやるのは、キーバリューに直すような処理のところは書く?いぬい例えばキーバリュー分散するときに10にしか分散できないとするじゃないですか。文字列はさっきのしおやさんの説明で長い文章を10個に分割したとするじゃないですか。10個に分割したら最大10人しか作業できないわけですよ。それをマシンを11台にしても12台にしても100台にしても10000台にしても時間は変わらないじゃないですか。それがものすごく長い文章で、例えば10000万個に分割できる文章があったとするじゃないですか。それは10台のコンピュータでも計算できますけど、10台だと10000÷10で1000回、1つのコンピュータが1000回やるわけですよね。10000台あったらそれは1回で済む、それぞれ1回で済むわけですよ。それがHadoopのいいところだと私は思いましたけど。かわのじゃぁ、スケーラビリディのことはHadoopに任せてHadoopに合わせたプログラムさえ書けばリソースのスケーラビリディが自由に使えるってことなんだ。いぬいそうです、そうです。Worldで例えば10行あったやつをマッププログラムで1個にしかまとめなかったら、それは一人が計算するしかないので、それは10万台パソコンがあっても全然時間は変わらないと思う。1万行あるやつを1行ずつに分割していくようなマッププログラムを書けば、1万個の作業に分割できているわけですよ。すると1万台あったら1回の処理で終わると。それが1000台だと10回。かわの多分、だからMapReduceがふさわしい、MapReduceが機能を発揮できるような仕事を今やるのかどうかという判断はしないといけないけど、判断がつけばMapReduceのプログラムを書ける人に頼めば、そういう有効に生かしてもらう処理を書いてもらえるってことですよね。もじ多分、MapReduceがでる前はそういった分散処理的なことをやろうと思ったら、その分散処理のインフラのところから全部自分で組まなくてはいけなかったということですよね。しおや前回Eucalyptusの話だったんですけれど、あれでマシンが10台ほしい、今月だけはマシンが10台ほしいねっていうときに、じゃぁアマゾンから10台借りれますっていう状況になったんですけれど、じゃぁ、プログラムの方が10台分担して10分の1のスピードで仕事ができるかっていうと、それはプログラムをそういう風に書いておかないといけない。MapReduceであらかじめ書いておけば、普段は1台で処理してもいいし、今月は増えるんで100台でガッと処理したいってときでも全然やることは変わらないっていうのが便利。かわのリソースを増やす側っていうか、処理が負荷が重くなってきたからバーチャルマシンを増やしていって、それをMapReduceにどうやって教えてあげるんですか?しおやそれはですね、Hadoopの中にHadoopオンデマンドっていう機能がありまして、ノードを増やしたいです、1000台ぐらいノードを増やして計算してくださいっていうコマンドを入れてやると増やせる。かわのじゃあ、それはリソースの管理者というかアドミニストレータが別にいてHadoopにリソースを追加して送ってやったりして、リソースマネージャみたいな人がいるわけだ。Hadoopの実用化の状況は?みや実際にHadoopはどれだけの規模のシステムの実績があるんですか?しおや実績は今回きちんとまとめてこなかったんですけど...かさい東大で研究しているところが会社を作ったみたいで、Hadoopを使ったシステム構築をやっていますみたいなことがちょっと検索したら出てきて、そこでなんか今お宅にある計算機資源でHadoopを使うとこれだけのことができますよ、みたいなのが出てきて、私ノートPC持っていないんでここですぐ出てこないんですけど(笑)みやグーグルで検索したら広告出てきましたよ。しおやあと、Hadoop関連のプロジェクトの論文を見ると、Yahoo(米Yahoo)の中で使っているんだけどね、みたいな説明がごろごろ。いぬいこれ、まさにグーグルが一番分散化している。MapReduce自体グーグルのインデックスを作るための仕組みなので。いぬいグーグルの何万台あるとか世界の何万台あると言われている中で実際使われているんじゃないですか?みや今これを枯れ具合というか熟成度というか実際にそのやってみようレベルから本当に使ってみようレベル、どのぐらいまで行っているのかなというのが気にはなっていて、そういう取り組みをやっている最中なのか、もう本当に性能を発揮できていて「こりゃ、すごい」という状態なのか。それともHadoop?みやHadoop。いぬいHadoopはどうなんでしょうね。しおや使っているんじゃないかなという気がするんですけどね。こっちの中の別プロジェクトにChukwaっていうログ収集システムがあるんですけれども、これはちょっと真面目に読んだんですけれども2000台ぐらいのノードがあって、そこでもうがんがんMapReduceの計算をやっていると。そこから大量に流れてくるログを見て処理をしてますっていうようなことはやっているので、まさか実験だけでただ単に2000台のノードを構築するっていうのはちょっと考えにくいんで。みや計算機センターを作ってグーグルと同じことをやりましょうと言ったらできちゃう?しおやできちゃう。いぬいいや、これに関してはできると思いますけど、できるかもしれないですけど、グーグルはもっとすごい、アルゴリズム的にもっとすごいわけじゃないですか。あっ、いやいやすみません、グーグルが回っている検索エンジンという意味では当然その検索アルゴリズムは別ですよね。みや例えばグーグルがやっているクラウドのサービスを、そのただお金集めてマシンを何万台並べてあとはEucalyptusとHadoopで「以上!」で展開みんな誰でもお金さえあればできちゃうのかな?しおや実際にはそこでノウハウっていうのはものすごくいろいろ出てくると思うんですけれども、実質的にはそろっている。ちなみに、リソース管理は前回Eucalyptusが出ましたけれども、彼らはまた別のTORQUEっていう、オープンなんだけど商用のリソース管理システムを使っているんだそうです。結局、クラウドって一口に言ってもハードウェアレベルでラックをどう組む、組んだハードウェアをどう管理する、管理したハードウェア上でどういう風にバーチャルマシンのOSを動かす、その辺をどうやってうまく動かせる?みたいな、すっごい一杯の要素が組み合わさって、それを全部把握して運用するっていうのは相当な力業じゃないかなと思います。もじちなみに今、アマゾンのMapReduceのオンデマンドサービス、MapReduceのフレームワークを間貸ししてくれるみたいなのをやっている。もじとりあえずMapReduce使いたいと思ったらアマゾンのEC2みたいなので、従量課金制で。大量の、MapReduceで大量のデータを解析したいとき、でも、それが恒常的にあるんであれば自社でHadoop組めばいいんだろうと思うんですよ。今月とりあえず、ないしは今この大量のデータ1回こっきりこれを解析したいんだっていうときに、MapReduceを使えば、アマゾンのMapReduceを例えば3日間だけ借りるってできるんですよ。一応、そういうインフラも最近できて来てて。いぬいアマゾンとかだと昼間は使うけど夜使わないとか、そういうのはお得かもしれないですよね。24時間本当にフル稼働しているんだったらあんまり変わらないかもしれないですけど。かわのAPIが同じっていうことですか?ともじHadoopと互換ということはあり得ないと思うんですけどね。HadoopはあくまでもMapReduceの一実装じゃないですか。グーグルはグーグルでMapReduceの実装を持っていて、アマゾンはまた別の実装でやっていると思うんで。かわのじゃぁ、アマゾンを使いたい場合は実装のインタフェースが公開されているわけですね。みやEC2のマシンの中にHadoopを入れておけば、ともじまぁ、同じこともできますね。すれば使える?いぬい話は弾みますけど、分散OSをよく知る者としては(笑)分散OSとかと比べると汎用性は低いわけですよ、やっぱり。汎用性は低いけど、こういう風なものがハマるのはめちゃめちゃ効率はいいですよね。その何も考えずに作ったものを分散化させるというのでは、分散OSですとかコンパイラとかそういう世界なんですけど、これはあくまで分散できることをやる人がわかった上で分散するという、その違いです。もじキーバリューの形に落とし込めるんだったら優先的に使えばよい?キーバリューの形に落とし込めないんだったらば別の分散のやり方を考えないといけない?いぬいそうですそうですかわのキーバリューに落とし込むっていうとことろが今ひとつよくわからないんですけど、どういう状態が落とし込めた状態なんですか?いぬいキーバリューが平行に分割できるかっていうことですよ。同じ作業に分割できるかっていうことです。暗号化みたいに単純な同じ作業を複数に分けられるかという。もじCouchDBなんかもキーとバリューしかないわけですよ。かわのすごいシンプルなインタフェースですよね、キーとバリューだけって。もじCouchDBなんかの場合だと確かにキーとバリューの中に、そのバリューがいわゆるハッシュなわけですよね、キーだってバリューだって。そのバリュー側がまたハッシュになってて、いわゆるハッシュの入れ子ができる。かわのじゃぁ、複雑なものも、そうやって入れ子にすることによって。もじただ、その形にできないとどうしようもない。いぬいその形にできるものが世の中にどれくらいあるかという。もじ例えばCouchDBについて調べていたのが、CouchDBっていうのはJSONっていうファイル形式、いわゆるそのハッシュをテキストで表現するっていう形式だと思うんですけど、XMLのデータ構造を入れ子にはなるんですけど、ハッシュの形にできればDITAのファイルとか、ハッシュの入れ子の形にはなるわけじゃないですか。XMLのドキュメント構造をハッシュの入れ子構造にマッピングできれば、そのまま勝手に。かわのそれって自動的にやる処理を書けるんですかね?ともじ結構あるんですよ、完成度はどれも高くないんですけど。すると、そのDITAのファイルとかXMLのドキュメントをいったんJSONに変換してCouchDBに入れて、そこでMapReduceして、まぁ、何をMapReduceするか僕もよくわからないんですけど(笑)。いぬいXMLのノードの計算というか、ノードがいくつあるかの計算のときに、それはまさにしおやさんがおっしゃったことと同じですけど、その全体構造をいくつかに分割してそれぞれに渡すっていうような形。しおや逆に言うと、依存関係があるとできないんですよ。この文章を読んだ後に、これを踏まえてこの文章を読まないといけないといったタスクはもう、まずこれ読んで次にこれ読んで、ってシリアルにやるしかないですから。僕は今この行、あなたはこの行やりますってバラバラにやっていいんだったらどんどん分割しちゃって構わない。ともじどうしても翻訳の方で頭考えちゃっているんですけど(笑)、翻訳メモリって結局そのファジーマッチのインデックス作るときって、結局は一旦トークナイズして、それからその文章の中にどんな単語があるかっていう、結局最終的にはキーバリューの形に落とし込めるんだろうと思うんですよ。翻訳メモリのインデックスを作る大量のドキュメントのファジーマッチを作るんだったら、これを使うとおもしろいのかなってちょっと感じましたね。かさいかわのさんみたいにひと月に一人で40万50万ワードの翻訳をやりなさいという仕事が上からドカーンと来たときに、Hadoopでばーっと分けて機械でやらせて。もじかわのさんがエクストランスでHadoopやっていたわけですよね。かわのディスパッチャでしょ?(笑)いぬいいや、でもまさにそれですよ。翻訳ソフトって、例えば大量のものすごいデータを渡したらそれなりに翻訳するの時間かかるじゃないですか。それこそまさに分割できるところですよね。翻訳ソフトってコンテキストがあんまり考えてないですよね。前の文章ってあんまり考えてないので、そういうのはこういうのに向いているんでしょうね。かわの前やっていた仕事で流体力学の数値解析、要するに数値流体力学っていうのがあって、大量の計算をNavier-Stokesの方程式っていうので力業で解いていくような分野があったんですけど、そういう数値解析にもこれ使えるんですかね。しおや使えると思います。かわの使えますよね、きっと。いぬいその力業とかいうところがキーワードだと思いますよ。力業を、頭を使わなくて単純なことをやるっていうことに適しているわけですよ。かわの結構、工学でそういうことを強いられている人っていうか、あったら便利な人って大勢いるんじゃないかなぁ。いぬいまぁ、その例がまあちょっと今はあれですよね、翻訳のことは思いつきましたし、暗号解析は思いつきましたけど、他に何があったかなというのはちょっと。データベースを分割、カウントしていくっていうのぐらいはありましたけど。もじアマゾンのMapReduceのレンタルだと、やっぱり研究機関なんかが一時的に使ったりっていうのはありますね。いぬい研究機関は数値解析を分散化してやっていますから、そういうのにはすごく向いているんでしょうね。かさいどこかの新聞社が過去の自分の新聞をスキャナで取り込んで、それをPDFに直すのにHadoopをつかったら、たったの6時間で終わったって書いてました。しおやで、計算機のコストが140ドルくらいで終わっちゃった。もじ業務アプリなんかでもし使うとしたら、例えば月次とか年次とかのバッチ処理なんかで使うっていうイメージ。しおやMapReduceってあんまりレスポンスはよくないので、まぁ、基本的にはバッチ処理に使ってくださいっていうようなスタンスですね、やっぱり。もじトランザクションが求められるようなところにはあまり使わない。しおやこのChukwaっていうログ管理システムがありまして、これはまさに大量のデータを集めてくるぞっていうものなんですけれど、これはさっきログの解析に使いたいですねっていう話をしたんですけれど、彼らはまさにやっているんですよ。MapReduce自体は今言ったようにバッチ処理が基本なので、彼らはそのバッチ処理で分析したデータをMySQLデータベースに入れてリアルタイムな分析とかはそっちでやってねっていう、そういうスタンスでやっている。確かに万能ではないんですけれど、基本的には大量のデータをバッチでやるような用途にまず使うと。それ以外のところはうまく他のプロジェクトと組み合わせて使ってくださいという感じ。ながえ具体的にはどんなケースがあるんでしょうか。しおやまぁ、今言ったような、大ざっぱなインデックス付けはMapReduceでやっておいて、それを細かく、例えば先月の分だけを抜き取って集計するみたいなのはSQLでちょこちょこっとやっちゃった方がいいとか。あとはウェブのフレームワークとかも大体は今データベースで使うように作ってありますから、そいうのと連携するときは何かとデータベースみたいになった方がいいとか。あと他にいくつか特徴があるんですけれど、例えば(HDFSには)トランザクションがないんですよ。MapReduceもそうだしHDFSもそうなんですけど、データの置き方がシンプルなんです。テーブルみたいな形で見たいよっていうときはHBaseっていうプロジェクトがありますし、他にはZooKeeperっていうプロジェクトがあって、これは設定情報の管理に使うんですけれども、設定情報だとただ単にデータがわーっと管理できれば、例えば設定項目が一千万の項目が管理できますとかってあってもあんまりうれしくなくて、一千万のノードがあったとして、それに全部確実に設定情報の何が、パラメータが10から20になりましたって通知しないといけない。10から20になったんだけれども、管理者がもっと今度20を30に上げよう、でも、また他のノードにはどこまでどう情報が行き渡ったかわかんないとか、そういうようなことを管理するのがやっぱり(HDFSは)全然向いていないので、ZooKeeperっていうサブプロジェクトがあって、それを支援するようになっています。それから、データの形のキーバリューっていうことで済んだんですけれど、じゃぁファイルに保存するときはどうするのっていう問題がどうしても出てくるので、Avroっていうプロジェクトがあって、これはデータのアプリ固有のフォーマットを定義してやると、そのデータスキーマごとファイルシステムに保存してくれるという、そういうライブラリです。もじ例えば、このキーバリューをJSONにしたかったりXMLにしたかったり...しおやグーグルでプロトコルバッファっていう似たようなプロジェクトがあって、あのアプリ用のフォーマット、このアプリ用のフォーマットと書けるんですけれども、Hadoopはおもしろいのはダイナミックになっていまして、グーグルのプロジェクトだとまずデータ定義を書くと、で、それをコンパイラみたいなのに落とすと。アプリケーション固有のデータを扱うプログラムの元ネタみたいなものが出てくるんですね。いう風に、1回データを定義して変換してJavaのソースが手に入るんで、それをコンパイルするみたいな形なんですけれども、このHadoopのAvroはおもしろくて、ダイナミックなんですね。コンパイルとかはいらなくて、いらなくてって言うのは、データのスキーマとデータが一緒に保存されているので、それをAvroのライブラリに渡してやればその辺の処理をやってくれるという、非常に柔軟性のあるシステムです。いぬいこれとかあれですね、並列コンパイラでもいいですね。makeあるじゃないですか。makeで、あっ、並列コンパイラご存知ですか、GNUの?しおやあの、各モジュールをバラバラにしてコンパイルしていってっていう。GNUのコンパイラというかmakeファイルが分散してくれるんですよ。コアが、今のパソコンでもコアがいくつもあると分散してくれて、それぞれのコンパイラが動くんですね。いうのに、多分こういう実装されていないと思いますけど、そういうことができると、例えばものすごく大規模なシステム、Cソースファイルをいっぱいコンパイルしていって最終的にひとつのモジュールを作るわけですよ。それを分散処理で僕が作っているフィルタではコンピュータで分散するところをGNUが出してるんですね。それをこういう広域でもって分散してやると、何十万個あるソースコードが、例えば5秒でコンパイルできるとか、まぁ最初はちょっとリンクするところは1つじゃないとダメと思いますけど、そういうことができるんでしょうね。Engineは使えるんですよね。したら、すごい処理ができちゃう。EngineではBigTableがまず公開されて、いわゆるキーバリューしか格納できないデータベース、たぶんCouchDBみたいなデータベースがまず使えて、それはSQLじゃなくて確かGQL。SQLっぽい、いわゆるSQLでやるようなテーブルとテーブルのリレーション組んだりっていうのは確かできないですよ。Engineの中では使えると。その中で多分、MapReduce的なことをやりたければAPIはあるとは思うんですけどね。しおや大枠は同じなんですけど細かいところのコントロールですとかはやっぱり微妙に作法が違うらしくて、一口にMapReduceと言っても、やっぱりHadoopのMapReduce、グーグルのMapReduce、どこそこのって、微妙に違いはあるみたいです。いぬいかわのさん、これ翻訳パラダイスに使えるんですよね。いうところで使えるかというと、翻訳パラダイスって今三千何百人の翻訳者がそれぞれの翻訳できる言語を登録しているんですね。その言語がかなりたくさんあって、アラビア語とかイタリア語とか、そういういのが多分数十個あるんですけど、僕自身も覚えていないんですけど、で、今、翻訳者に登録するじゃないですか、で今それの集計を出すリンクがあるんですよ。集計というのは英語できる人が何人、フランス語できる人が何人という、その集計を言語に対して出すんですね。ところが、その計算ってすごい時間がかかるんですよ。今翻訳パラダイスのリンクを押してもらったら3分くらいかかるんですよ、申し訳ないんですけど。3分ってなかなかウェブに表示するのに3分待てないですよね。僕はちょっと非力なマシンを使っていて1GHzくらいのマシンを自宅に置いているので3分くらいかかるんですけど、その作業をこれで分割すれば、要は英語っていうキーワードを入れた人だけの集計をしなさい、イタリア語の集計をしなさいという、それぞれの言語を少なくとも言語単位で20個ぐらいに分割できたら、それは恐らく一瞬で返ってきて一瞬で表示できるわけですよ。いうことには向いているんですね。かわのじゃぁ、そんなに大規模な仕組み、システムばかりっていうイメージじゃなくて、分業できるものがあったら適している。しおやアマゾンついでに出てきましたけど、結構アマゾンは昔から使えるようになっていてアマゾンのS3ストレージサービスとMapReduceを組み合わせてっていうのもできるんです。基本的には、彼らはHadoopはやっぱりHDFSと使ってねっていうことになっていて、それは何でかっていうと、このデータはここのノードにあるよという情報を、やっぱり計算するときも生かして計算したい。ローカルの計算はローカルでやってから隣のラックと組み合わせましょうみたないことをしたいので、できればHDFSとMapReduceはセットで使ってくださいと。自由に増やせると言っても、そういうところでハードウェアの制約っていうのはどっかで効いてくるんですね。アマゾンだと、これが隠れちゃってひとつのでかいディスクみたいに見えるから、実際にはアメリカとヨーロッパのデータを混ぜて計算してます、みたいなバカなことをやっているみたいなことも起こりうるのですけど、Hadoopで同じプロジェクト内のものを使うっていうのはそれなりにメリットがあるのかなと。いぬいグーグルのクローラーもこういうのを使っているんじゃないですかね。中でどう組み合わせているかはよくわからないんですよ。さっきから何回か話に出てくるグーグルのビッグテーブルっていうのはHBaseっていうのが対応しているんですけれども、これ自体はHDFSに依存しているんですけれども、MapReduceは使っても使わなくてもいいよねっていう。入れたければここに百万件くらいデータを蓄えておいて上から順番に読んでくみたいなプログラムも書けるんですよ。いう要素技術はいろいろ出ているんですけど、あとはどう組み合わせて何をやるかっていうところでいろいろと頭をひねらないといけない。Hadoopを必要とするユーザはどこにいるかともじHadoopとかこの種のクラウド関係を見ていて思うのは、例えばApacheとかTomcatって基本的にクライアントサーバだから自分ひとりで何かやってもしょうがないんだれど、自分ひとりでサーバ立てるとか何かこう使い道があるんだけれども、ここまで行っちゃうと、自分ひとりでHDFSとか組んで自分ひとりで何かいいことがあるかというと、そういうことはあんまり...しおやないですね。World、あっ、動いた動いたで終わっちゃう。しおや彼ら運用している側も、こんな二千台も三千台もノードがあるところで、このタスクはどこで誰がどう処理しているかわからないんで、もうそのためにはログ管理システムとかデータ収集システムみたいなものを作らないと、自分自身もどこで何が起こっているかまったくわかんないっていう、中もクラウドになっちゃっているっていう(笑)。もじ特にHadoopって、Hadoopを本来的な目的で使うユーザっていうのは世界でもすごい限られる。何百か何千かわからないですけど。Tomcatのインストールベースとか、そこまではいかない。いぬい僕が思うには、世の中もっと進めば、こういうのが個人で使う時代になると思いますよ。何かっていうと、ファイルシステムとかネットーワーク上に分散していていいわけですよ。分散していてよくて計算も別にこのコンピュータで計算する必要なくて、これは単なるThinクライアントであって、これは単に画面が見えていて文字が見ているだけなんですよ。本当に計算とか何かやっているのはバックエンドにいたらいいわけですよね。僕が昔作っていたのは、分散OSを作ったわけですけど、これはあくまで端末なんですよ。lsってやったらずらっとリストが出てきますけど、それはここまでのリストは単に日本国内にある個々のファイルの中にあるわけで、ここの部分は別のところにあっていいわけですよね。その計算自体も分散化されるような、そういう時代は究極的には来ると思いますけどね。もじそれはHadoop内でひとつのHDFSがあればいいっていう感じになるんですかね。しおや昔はよく、水道をひねると水が出てくるようにコンピュータが使えるようになるって言われましたけど、本当にそうなっちゃうと、みんな水道は使うけど、水道屋さんは2つとか3つとか地域に1つとか。かさいさんの(訳した)本のテレコズムには書かれているんですけど、ネットワークの速度がありますから、ネットワークの速度は光の速度を超えられないっていうのをテレコズムで言っていますよね。それは究極だと思うんですよね。光の速度を超えられないので、やっぱり距離があると遅いわけですよ。アメリカに行って返ってくるまでには時間があるので、そこはちょっと問題があるので、ある程度はどんな時代になっても距離っていうのはあるはずなんですよね。僕がやっていた仕事の一部は、プロセスマイグレーションってご存知ですかね、この計算機でおこなわれているプロセスごとにあちこちに自動的に振るわけです。話が脱線してきましたけど、今ってデュアルコアなんですよ。デュアルコアとかクワッドコアとかありますよね、コアがいくつかあって、今デュアルコアを使っているのでいろんな処理が並列に動いているじゃないですか。それを更に別のコンピュータに処理を振って、ここに計算が返ってくるような、そういうプロセスマイグレーションをおこなうんですよね。究極はなんかそういう世界が来ると信じて1980年代からプロセスマイグレーションがおこなわれるんですけど、未だに実用には至っていないという(笑)。もじ究極的に例えばそのアマゾンのインフラとかグーグルとかのインフラがいわゆるPCのバックエンドの巨大なコンピューティングリソースになってそれをグーグルやアマゾンが間貸ししていくみたいな世界に...いぬいそうだと思いますよ。computerっていうのは、僕はその頃は80年代にサンを使っていたときはどういう意味か、文書の意味はわかりますけど、本質はわからなかったですけど、サンっていうのはすごく前を見つめているな、ほんとネットワークっていうのはコンピュータなんですよね。ネットワーキングですべてが解決する時代はいつかは来ると思いますね。しおやそうなったら今度はきっと、このプログラムを走らせると今計算料金はコレコレで、アメリカではコレコレになっているから、仕事の30%はグーグルにやらせて、20%はアマゾンにやらせて、10%はローカルでやろうみたいなライブラリもそのうち出てくるかもしれない。もじある意味、何かこうわかんないですけど先祖返りっていうか、昔はメインフレームがあって、その時間課金がされていたわけですよね。それでアカウントっていう呼び方もそこで生まれたわけですよね。考えるとメインフレーム、世界のメインフレームをグーグルなりアマゾンなりが用意していて、それを世界中が昔のメインフレームかのように時間で使っているという。いぬい私の個人的なことを言うと、こういう分散機能ですね、MapReduceもそうですけど、これは多分、分散屋さんからいくと負けなんですよ。いうと、本当はユーザがまったく意識せずに処理を分散させることができることが究極に目指していた方向だと私は思うんですけど、やっぱりそれは1980年代から、もっと前から、私はもっと前は知らないですけど、ずっと研究されてきたけどなかなか難しいんですよね。何かって言うと、プロセスマイグレーションっていうのはここでコンピュータが動いている処理を、こっちに自動的に移したとしても、ここのデバイスとかを扱わないといけないとか、それって結構難しいんですよね。いう自動的な分散っていうのを目指してたけど自動的に分散するのはやっぱりそこそこ難しいよねというのがわかってきて、じゃぁ、でも分散はしたいからこういう風に人間が分散っていうのを考えて、分散できる範囲で分散しましょうかっていうようなことに来たような気が僕はしているんですよね。もじ例えばMapReduceだと、Reduceのところはキーバリューペアになっちゃったらもう自明だと思うので、昔、人間がMapしなくてもよかったと、機械が勝手にこう...いぬい機械がやるやつは今でもあるんですよ。分散コンパイラというのがありまして、処理をスレッド化できるんですよ。スレッドに分けるとコアに分散できるので、デュアルコアとかそうですけど、そういう機能はあるんですけど、ただこれ問題がいろいろあって、C言語とかっていう言語があるんですけど、ポインタを扱うとか、こうグチャグチャなやつっていうのは分散できない、非常に分散しづらいんですよね。FORTRANとかそういう言語は分散しやすいって言われているんですけど、まぁ、C言語では分散できないと、そういう問題もあって。アセンブラとかはまさに全然分散できないわけですよ。いう、あえて分散を自分で考えましょうという方向の方が正しいというか、主流なのかなという気がします。しおや最初に、今日話し始めてすぐにかわのさんが、どういう作業ならMapReduceできるかわからないっておっしゃいましたけど、まさにそこが一番難しいところなんですよね。もじあと、もう一つ、今日話を聞けて思ったのが、グーグルにしてもアマゾンにしても、データベースの間貸し、レンタルっていうか時間貸しって、どれも基本的にキーバリューっていうか、この構造なんですよね。SQLとか、いわゆるSQLリレーショナルデータベースの時間貸ししか基本的にまだやっていなくて、それって例えばオラクルでクラスリンクができるんだろうと思うんですけど、アマゾンならアマゾンで一つのデータベースリンクだ、グーグルならグーグルに一つのデータベースリンクだっていう形にしないとメンテナンスが大変になると思うので、その形でユーザに無数の何万人何十万人っていうユーザにデータベースリンクを提供しようと思ったら、多分このやり方しかないということなのかなぁっていう。Hadoopに先に何があるのかみやちなみにこの先を行くプロジェクトっていうのは、ちょっと先走りますけど、もっと先の理想っていうのは何かあるんでしょうか。しおやどうなんでしょう。MapReduceよりもっと高級なレベル、今日も何回か話に出ましたけど、SQLを使えるようにしようとか、スクリプト言語みたいなのでラップするっていうのが出てきています。もじ例えば、もうMapReduceはもう時代遅れだと。MapReduceはもう古い考え方で次はこれだみたいなのがあったりするんですか?みや多分、そういう時期は来ると思うんだよね。しおや今日の話とは直接関係ないし必ずしも今言った話とはリンクしていないんですけれども、クラウドが、まぁ特に企業系システムでクラウドクラウドってみんな言っている一方で、個人用のコンピュータはGPUで並列計算がいっぱいできるとか、3Dをやるとか、この間アップルがGCDっていう技術を出しましたけど、あれはコンパイラにある程度、この辺とこの辺並列化よろしくってやっておくとGPUがやってくれる。GPUがやってるってことは...いぬい私の知り合いの会社でGPUでやっている人がいますけど、結構難しいみたいですね。しおや単純な計算を分担してやるっていうのはGPUは得意なんですけど、それに合わせてプログラムを書くのが難しい。いぬいGPU、めちゃめちゃ早いんですよ。あれは恐るべしですよね。計算をGPUに任せるとめちゃ早いです。しおやだから、その辺とか結びつくとまた違う進展とかあるのかなとかちょっと妄想したりしましたけど。もじ昔の、昔って今もあるんでしょうけど、宇宙からの電波かなんかを...かわのSETI。あれもやっぱり分散コンピューティングなんですか?いぬい並列計算できるんじゃないんですかね。昔から並列計算というのはやられてて、いっぱいやられていたと思いますよ。いう風にきっちりこういうフレームワークっていうかMapReduceみたいな仕組みで、こういうインタフェースでできますって提起したところが新しいんじゃないですかね。もじMapReduceっていうのは分散コンピューティングの一形態で、その中の一実装がHadoop?しおやそうですね。いぬい究極の分散コンピューティングは人体のDNAコンピューティングだと思いますけどね。かわのDNAコンピューティングって何ですか?いぬいDNAコンピューティングっていうのは究極の今研究されているコンピューティングですけど、計算機っていうのはこの値とこの値を与えたときに結果がこうなるっていう風に予測できると、それはすべて計算機として使えるわけですよ。何かっていうと1+1が、1と1を足したら3でもいいわけですよ。それは3ということが予測できていればコンピュータとして使えるんですね。人間のDNAが何がすごいかっていうと、このタンパク質とこのタンパク質の組成を与えるとこういうものが合成されるとかいうことが計算できているわけです。計算というか予測できているわけです。それを計算機で使うっていうのがDNAコンピューティング。DNAコンピューティングっていうのはタンパク質とタンパク質を加えてどう反応するか、人体がどういう風に反応させるか、っていうことをやっている。これは今で言うと計算機科学、コンピュータサイエンスをやっている人たちと、ある意味、医療をやっている人たちがジョイントして研究している分野なんですよ。もじソースコード、例えば普通にJavaかなんかのコンパイラがタンパク質を合成したりとか、そういうイメージなんですか?いぬいコンパイラとかじゃなくて、もっと下のレベルですね。下のレベルの、CPUのレベルですよ。CPUっていうのは最近は何mipsとか言わないかもしれないですけど、計算能力を、最近だと3GHzのCore2Duoだとこれぐらいの処理能力っていうのがあるじゃないですか、人間のDNAっていうのはあれをはるかに超えているらしいんですね。私もどれくらい超えているかは忘れましたけど。要はそういうところに計算させましょうと。計算機能力はあるんですよ。今難しいのは、どういう組成のタンパク質とどういう組成のタンパク質を与えられるかっていうところまではわかるんですけど、その結果を取り出して数値化するのが難しいっていう風に聞きましたけど。それができてくると、本当に究極の並列計算ができるわけです。みやたぶんHadoopもクラウドも、いずれは「あのとき、2009年頃は結構みんな勉強していたよね」という時期が必ず来ると思うんですけどね、それを思い浮かべたときに何があるんだろうかというのがまたおもしろそうですね。どっかにもしかしたら芽が生えているかも。それを見つけるっていうのがまた、「あしたの研」としてやろうかなと。しおや人間の中身って結構やっていることはものすごくシンプル、ドグラマグラにもそういう話は出てきますけど、細胞レベルで見ると、隣の細胞に信号が来たんで次の信号よろしくって旗上げて下げてぐらいのことしかやっていない、超分散処理なわけですよ、我々の脳って何十億っていう細胞があって。こんな高度な、いろいろな精神活動ができる。クラウドもそういう意味では超分散システムなので次に進歩するともうきっとクラウドの中に...いぬいそうですよね。これ脳になるかもしれない。人工脳になるかもしれないですね。しおやでも、そうすると人造人格ができちゃったりして。かわのそれスカイネットじゃない?いぬいDr.ミンスキーっていう方が書いた『心の社会』ってご存知ですか?そういう有名な本があって、それは脳の中がどういう風な構造で動いているか、それが恋愛とか怒りとか恐れとか、いろいろあるじゃないですか、それをすべて解析、本にまとめているんですよ。それを読むと「あっ、これってコンピュータで実現できるじゃない」って思えてくるんですよね。その後ちょっといろいろ批判があって、矛盾してるかとか学者から批判されているところもあるんですけど、まさにこういう並列計算、人間のシナプスの世界なんで、それが、もしかしたら世の中の何百万台か何千万台かの計算機能力で人間の感情と同じようなものが将来できるかもしれないですね。人間と同じように考える脳っていうのができるかもしれないですね。しおやそうなると本当にこんな仕組みなんか誰も勉強しなくなって、「グーグルさんグーグルさん、今日のデータの計算結果を教えてください」っていう。いぬい2001年宇宙の旅のHAL9000みたいに、質問したら的確な答えを出してくれるっていうのは、こういうのがもしかしたらベースなのかもしれないですね。もじスカイネットの話がでたので...ターミネーター4でしたっけ、最初のターミネーターで、その前かな、ちょっと覚えていないけど、結局スカイネットは潰せないと、スカイネットは分散しちゃっているから、どっかのノード1個叩いたところでスカイネット自体は死なないみたいな、そう言った意味ではスカイネットが分散をべースにしているというストーリーかなと。いぬいスカイネットはよく知らないですけど、SFの映画とかでコンピュータに支配されるみたいなのがあるじゃないですか。いうの本当に、まさにそういう時代を予感させるのかなぁと。並列計算で、さっきの脳の話で、人工脳になってしまったらコンピュータが自分で考えて自分でいろんなことをやるわけですよね。機械の世界でターミネーターも攻撃されるみたいな、そんなのも全然ウソじゃないだろうなという感じはしますね。ベンチャー企業の活路とはしおや今回調べものをして思ったのは、本当にさっきの話ではないですけど、現実的なところに目を向けると、ハードを組み合わせてソフトの設定をしてあのソフトにこのソフトにそのソフトを組み合わせてっていうのは考えただけでもぞっとするような仕事で、そこをうまくまとめるのが次のブレークポイントというか山なのかもしれないですね。もじ同時にこういったHadoopのインフラを必要とする、ないしは用意する企業、できる企業っていうのは本当に世界に一握りになっちゃうのかなぁという印象をすごく受けますね。いぬいそのハードを用意できる企業は資本力がある企業じゃないですか。僕らみたいなベンチャーの視点から言うと、これを使いこなせる仕組みっていうかソフトウェアっていうかをうまく作れれば一応ビジネスになるだろうなとかって思いますけどね。インフラはお金がないと用意できないのは当然なので、それはアマゾン利用するとか、それはそういう既存のインフラにお金払えばいいと思うんですけど、まさに何が分割できるかを考えるわけですよ。さっきの翻訳の話じゃないですけど、翻訳の言語ごとにまとめるとかっていう話は翻訳に関わっている人じゃないとなかなか思いつかないですよね。いう、ここで何ができるかをいかに思いつくかっていうのはビジネスになるんだと思うんですけどね。かわの多分、誰でも使えるようなインフラになったら、別にインフラ自体はおもしろいものでも何でもなくて、壊れたらみんな怒るけど使えてて当たり前のものですよね。電気も水道も電話も、動いていると何も感じないというものになって。アマゾンもグーグルも、今も半分そうだけど動いてて当たり前で止まったら「何だこれは」みたいに言われる世界になって、辛い仕事ですよね、ある意味。その上でいろんなものを展開するのがおもしろくなってくるんじゃないですか。Corporation.当サイトはリンクフリーです。reactive-web。