Agile Cat — in the cloud

Microsoft と Intel には、並列/分散の隠し技があるのか

Posted in Big Data, Microsoft, MS-MapReduce, Parallel by Agile Cat on September 4, 2010

Microsoft, Intel deliver new distributed/parallel tools
By Mary Jo Foley
September 3, 2010, 8:04am PDT
http://www.zdnet.com/blog/microsoft/microsoft-intel-deliver-new-distributedparallel-tools/7300

All About Microsoft

Microsoft execs haven’t been beating the parallel-computing drum as loudly as they were a year or two ago, but that doesn’t mean nothing is happening in this space.

Microsoft の首脳陣たちは、この1~2年間と同じように、パラレル・コンピューティングについて押し黙っている。だからといって、この領域で何も起きていない訳ではない。

Late last month, Microsoft made available for download a new version of the HPC (High Performance Computing) Toolpack, which is a collection of utilities that can be used on Windows Server 2008 R2-based clusters. The latest tool pack includes two tools, one known as “Lizard,” and the other as “ClusterCopy.” Lizard, the Linpack Performance Wizard, calculates peak performance of HPC clusters in billions of floating-point operations per second (GFLOPS) and allows users to save those results and the parameters that helped achieved them. ClusterCopy is a tool for distributing files around a cluster using a tree-based copy system.

先月(8月)のおわりに Microsoft は、Windows Server 2008 R2 ベース・クラスタで利用するユーティリティー・コレクションとして、HPC(High Performance Computing)Toolpack の、新バージョンのダウンロードを開始した。 この最新のツール・パックには、“Lizard” と “ClusterCopy” という 2つのツールがを取り込まれている。Linpack Performance Wizard である Lizard は、HPC クラスタのピークのパフォーマンスを、1秒あたり10億桁の浮動小数点オペレーション(GFLOPS)で 計算する。そして、ユーザーの目的を達成するために、それらの結果やパタメータの保存も実現する。 また、ClusterCopy は、ツリーベースのコピーシステムを用いて、クラスタの周辺にファイルを配置していくためのツールである。

image

As I noted in a previous blog post, Microsoft is gearing up to make some more noise in the HPC space this fall, when the company is expected to release a first Community Technology Preview (CTP) of its Dryad parallel/distributed computing infrastructure technology. A final commercial version of Dryad is due out some time in 2011. Dryad has been a Microsoft Research project, but is in the process of being commercialized, according to a Microsoft presentation I saw.

前回のブログ・ポストで指摘したように、Microsoft は、並列/分散コンピューティングのインフラストラクチャ・テクノロジーである、Dryad の CTP (Community Technology Preview) のリリースに合わせて、HPC 領域に関する話題を、この秋に盛り上げようとしている。 最終的な Dryad の商用バージョンは、2011年のいずれかで登場する。 ただし、私が Microsoft のプレゼンテーションで見た限りでは、Dryad は依然として Microsoft Research のプロジェクトであり、商用化へ向けたプロセスの途上にある。

“Lizard and ClusterCopy have no direct relationship to Dryad today,” a Microsoft spokesperson said when I asked if there was any connection between the products. “Microsoft periodically releases additional tools for HPC that they developed out of band (between formal releases/updates) of the product.  These provide additional value to our customers, at no additional cost, through online tool packs.”

『 現時点において、Lizard と ClusterCopy は Dryad とのダイレクトな関係を持っていない 』と、私の質問に対して、Microsoft のスポークスマンは答えている。 『 Microsoft は、プロダクトとは関係しない領域(正式なリリースやアップデートの間で)で開発され、HPC に追加されていくツールを、周期的にリリースしている。 それらがもたらす価値は、オンライン・ツールパックを介して、また、追加の費用を求めることもなく、顧客に対して提供されていく 』

In other parallel/distributed computing news this week, Intel rolled out an updated version of its Parallel Studio tool suite for Windows developers. The new Intel Parallel Studio 2011 is designed to help developers increase the performance and reliability of both serial and parallel applications running on multicore processors. The new Studio 2011 adds a set of parallel models, known as Parallel Building Blocks, as well as a new threading assistant, known as Parallel Advisor. The new Intel suite supports Visual Studio 2010.

今週の、その他の並列/分散コンピューティングに関するニュースとして、Intel が Windows デベロッパーに対して、Parallel Studio ツール・スイートの、アップデート・バージョンを提供したことが挙げられる。 新しい Intel Parallel Studio 2011 は、マルチコア・プロセッサ上で実行されるシリアル/パラレルのアプリケーションに関して、デベロッパーがパフォーマンスと信頼性を、高めていくためにデザインされている。 この、新しい Studio 2011 では、Parallel Building Blocks というパラレルモデルのセットに加えて、Parallel Advisor という新規のスレッディング・アシスタントも追加される。 そして、この Intel スイートは、Visual Studio 2010 をサポートする。

Intel has been working with Microsoft on adding and improving support for parallel/multicore systems.

Intel は、パラレル/マルチコア システムを追加し、そのサポートを改善するために、Microsoft と協調している。

Microsoft’s recently formed Technical Computing Group is the part of the company that has the charter these days for parallel, technical and high-performance computing.

最近になって、Microsoft で組織された Technical Computing Group とは、パラレル・テクノロジーでハイパフォーマンス・コンピューティングを実現する役割を与えられた、同社の一部門である。

ーーーーー

Mary Jo Foley さんが、冒頭で『 この領域 』と言っていますが、まさにココが、Microsoft のチョイ情けないところなのです。 いいじゃぁないですか、たとえ Bing が 何らかの Map/Reduce を使っていたとしても。。。 また、Map/Reduce でなくても構いませんので、いまはこうだけど、次は Dryad でこうなるとか、将来の展望を説明してみれば良いではないですか。 そうすることで、『 この領域 』 での信頼を勝ち得ていくのです。 今回の Mary さんのブログポストは、『 頑張れ Mictosoft 』の応援団ですよ。 ーーー A.C.

ーーーーー

<関連>
Dryad が DAG をつかう理由 – Dryad & DryadLINQ Team Blog
MapReduce in DryadLINQ
Apache ZooKeeper による分散並列キューの構築
Observers と ZooKeeper

Dryad が DAG をつかう理由 – Dryad & DryadLINQ Team Blog

Posted in Hadoop, MS-MapReduce by Agile Cat on August 24, 2010

Why does Dryad use a DAG? – Dryad & DryadLINQ Team Blog
http://blogs.msdn.com/b/dryad/archive/2010/07/23/why-does-dryad-use-a-dag.aspx

image

The basic computational model we decided to adopt for Dryad is the directed-acyclic graph (DAG). Each node in the graph is a computation, and each edge in the graph is a stream of data traveling in the direction of the edge. The amount of data on any given edge is assumed to be finite, the computations are assumed to be deterministic, and the inputs are assumed to be immutable. This isn’t by any means a new way of structuring a distributed computation (for example Condor had DAGMan long before Dryad came along), but it seemed like a sweet spot in the design space given our other constraints.

私たちが Dryad に適用することに決めた基本的な計算モデルは、DAG(directed-acyclic graph:有向非巡回グラフ)である。 このグラフにおける個々のノードで計算が行われ、また、グラフにおける個々のエッジが、その方向をデータを送り出すストリームとなる。 あらゆるエッジ上のデータ量は有限と想定され、また、その計算は決定論的なものと想定され、入力は不変であると想定されるべきである。 それは、分散された計算を構成するための新しい方法ではないが(たとえば Dryad が登場するずっと以前に、CondorDAGMan を有している)、他の制約を持つデザイン・スペースにおけるスイート・スポットだと想定される。

So, why is this a sweet spot? A DAG is very convenient because it induces an ordering on the nodes in the graph. That makes it easy to design scheduling policies, since you can define a node to be ready when its inputs are available, and at any time you can choose to schedule as many ready nodes as you like in whatever order you like, and as long as you always have at least one scheduled you will continue to make progress and never deadlock. It also makes fault-tolerance easy, since given our determinism and immutability assumptions you can backtrack as far as you want in the DAG and re-execute as many nodes as you like to regenerate intermediate data that has been lost or is unavailable due to cluster failures.

それは、なぜ、スイート・スポットになるのだろうか? DAG の利便性の高さは、グラフ内にノードの順序を取り込んでいる点にある。 そのため、入力に際してノードが行うべきことを定義できるようになるため、スケジューリング・ポリシーのデザインが容易になる。そして、準備が済んでいる大量のノードを、どんな時にでも希望する順序のとおりに選択して、スケジューリングすることが可能となる。さらに、少なくとも 1つのスケジュールされたノードがある限り、その処理は継続され、また、デッドロックが起こることはないだろう。また、私たちの決定性と普遍性の仮説を前提として、DAG  内の任意の場所をバックトラックできるため、フォールト・トレランスも容易になる。なお、クラスタの失敗などにより、消失あるいは利用不能になってしまった中間データを再生したいする場合には、それに見合うだけのノードを再実行できる。

image

クリックで拡大 ⇒
https://nosqleast.com/2009/slides/yu-dryad.pdf より

The obvious way to generalize the DAG model would be to allow cycles in the graph, but that makes both scheduling and fault-tolerance more complicated. They are still possible, but we decided to go with the simpler approach and see what we ended up being able to do with it; and leave as a research question the extent to which adding cycles would be useful.

DAG モデルを普及させるには、そのグラフでの巡回を許す方式が明らかに有効だろうが、ケジューリングとフォールト・トレランスがさらに複雑になってしまう。それを実現する可能性も残されているが、私たちの決定においては、より単純なアプローチを選択し、その結果を見届けることになった。つまり、巡回を追加する有用性については、研究課題として残すことに決定した。

On the other hand, there’s no obvious way to restrict the DAG model that makes the underlying system any simpler. Although MapReduce is I think a simpler programming model than Dryad, arguably the system itself is, at least conceptually, more complicated, since the Map nodes and the Reduce nodes have different scheduling and fault-tolerance properties and implementations. In addition when the system wants to optimize some data transfer, e.g. building an aggregation tree or sampling a dataset to find a balanced range partition, the optimization can usually be expressed as a subgraph of a DAG, and doesn’t need to be “hand-rolled” the way it would if you wanted to add it to a system like Hadoop. So the big advantage of adopting a general DAG as the low-level computational abstraction is that there’s just one state machine that handles all computation nodes. Of course, any real implementation of MapReduce or a DAG-driven system like Dryad can get complicated, but the topology of the data flow is not in itself a source of complexity in Dryad.

その一方で、基本的なシステムをシンプルにするために、DAG モデルを制約していく明白な方法は存在しない。 おそらく、MapReduce は Dryad よりも単純なプログラミング・モデルだと思われるが異なるスケジューリングとフォールト・トレランスのプロパティおよび実装を、Map ノードと Reduce ノードが有するため、少なくともシステム自身は、概念的に複雑なものとなる。 それに加えて、たとえば、アグリゲーション・ツリーの構築や、バランスのとれたレンジのパーティションを見つけるためのデータセットのサンプリングといった、データ転送に関する最適化をシステムが要求することがある、そのときに、この最適化は DAG のサブ・グラフとして表現できるが、たとえば Hadoop のようなシステムに加えようとするなら、そこで望まれる “hand-rolled”  の方式を取り入れる必要がなくなってしまう。したがって、一般的な DAG を低レベルの計算抽象概念として採用する大きいアドバンテージは、すべての計算ノードを取り扱う 1つのステート・マシンが、そこに存在するという点に集約される。 もちろん、 現実に実装するとき、MapReduce や、Dryad などの DAG 駆動システムは、複雑なものになり得る。 しかし、データフロー・トポロジーが、Dryad の複雑さ自身の根本に含まれることはない。

One thing we learned fairly early in the Dryad project was that people don’t want to build DAGs by hand: it’s too low-level, and people don’t want to have to learn to think about how to think about their algorithms in terms of dataflow graphs. So this seems like it might be a disadvantage of something like Dryad compared with MapReduce, whose simple programming model is often touted as its big advantage. But with a couple of years of experience, and having talked to a lot of people in academia and industry who have been using Hadoop, I’m not sure that’s really true. In practice, once you get beyond a coursework assignment, most interesting computations cannot be expressed purely as a single Map followed by a single Reduce. Instead, it turns out, you typically need to take the output of the first Reduce and do another round of Map and another round of Reduce, and so on. Often you are trying to write an iterative algorithm (e.g. something like k-means) or very commonly you need to do something like a Join that combines information from two input sets. Join is the basic construct that is used for most graph traversal algorithms (you are combining data at the nodes with an edge map), and it is also used all over the place when there are common subexpressions in a computation: the common result is computed once and then “joined” with other data several times as necessary.

Dryad プロジェクトの早期において、私たちが正しく学んだ 1つに、人々が手作業で DAG を構築したがらないという事があった。 つまり、あまりにも低レベル過ぎるという事であり、データフロー・グラフの観点で、そのアルゴリズムについて学習しようと望まないことであった。 その単純なプログラミング・モデルが、大半のケースでアドバンテージとして推奨される MapReduce との比較において、そのことが Dryad のようなテクノロジーの、ディスアドバンテージになっているのかも知れない。 ただし、この 2年間のエクスペリエンスにおいて、そして Hadoop を使用している学界と業界とのディスカッションにおいて、それが本当に本当であるとは確信していない。 実際のところ、教科書的なレベルを超えると、大半の興味深い処理が、単一の Map と Reduce の組み合わせでは、表現できなくなるだろう。 それに換えて、最初の Reduce の出力を取得し、別の Map と Reduce へと展開していく必要性が導かれる。 大半のケースにおいて、反復性のアルゴリズム(たとえば k-means など)の記述や、きわめて一般的な Join  のようなものを用いた、2つの入力セットに基づく情報の結合などが必要となる。 Join は、大半のグラフ横断型アルゴリズム(データ・ノードにおいてデータとエッジ・マップを結合)において用いられる、基本的な概念である。 そして、計算における共通の副次式が存在する場合にも、園周辺で使用される。つまり、共通の結果は一度だけ計算された後に、必要に応じて何度でも、他のデータと " Join " される。

In other words, MapReduce is really too low level for most programming tasks as well; programmers don’t want to have to break up a complicated algorithm into a set of Maps and Reductions, and manually manage all the types and manually write a script to sequentially execute a series of MapReduce jobs. Good evidence for this comes from the proliferation of higher-level language layers that have been built on MapReduce and Hadoop, including Sawzall, PigLatin, HIVE, Cloudbase, and Yahoo!’s Hadoop SQL.

言い換えれば、大半のプログラミング・タスクに対して、MapReduce はあまりにも低レベルすぎる。つまり、プログラマー Map と Reduuce のセットの中に、複雑なアルゴリズムを分解し、また、それらすべての手作業で管理し、一連の MapReduce ジョブを連続して実行するスクリプトを、手作業を書こうとは思わない。その良い証拠が、MapReduce と Hadoop の上に構築された Sawzall/PigLatin/HIVE/Cloudbase/Yahoo! Hadoop SQL などを含む、高レベルい言語レイヤへの拡散である。

So: if programmers aren’t actually directly writing Map and Reduce functions but instead using a higher-level language; and the MapReduce system isn’t easier to implement than a general DAG model (especially once you have added optimizations for things like sorting and hierarchical aggregation and distribution); and the high-level language you write can generate better-performing execution plans when it has access to a general DAG rather than a limited set of constructs such as Map and Reduce, then why would you choose to implement MapReduce over something like Dryad? We don’t think you would, but then we are biased :)

そうだとすると、もしもプログラマーがMapReduce を書きたがらず代わりに高レベルの言語を使うのであれば、また、MapReduceがDAGモデルよりも簡単に書けるのではなければ(とくにひとたびソートや階層的な集約・分散に関しての最適化を加えてしまったりしたときに)、さらには汎用のDAGにアクセスできる高レベルの言語がMapReduceのような限定された構造よりよい性能の実行プランを作れるのであれば、Dryadのようなものの上にMapReduceを実装しようとするだろうか?そうは思えないが考え方が偏っているのかもしれない。 :)

Michael Isard

ーーーーー

コメント欄にあるように、最後の段落ですが、上田さんに校正していただきました訳文に、差し替えました。 おかげさまで、とても読みやすくなりました。 有難うございます。 ーーー A.C.

ーーーーー

これがウワサの、DAG(directed-acyclic graph)ですね。 日本語にすると、有向非巡回グラフ となるのでしょうか? たしかに、たとえば Hadoop などを活用していくと、その Map/Reduce が多段化してくることになり、そのフローを簡潔かつ確実に制御するための仕組みが必要になると思われます。

そのため、Apache は Zookeeper などに取り組むという構図になっているのでしょうが、あくまでも Hadoop の利用を前提としています。 その点、この記事でいうノードの中身なのですが、そこが、どのように考えられているのか、とても興味がありますね。

それと、訳に自身のないところが多々ありで、なにか変なところなど見つかりましたら、ぜひ、お知らせくださ~~~い!ーーー A.C.

ーーーーー

<関連>
MapReduce in DryadLINQ
Windows Azure MapReduce Demo
Hadoop が Microsoft の教材に?
教育機関への Dryad 提供が始まる
Apache ZooKeeper による分散並列キューの構築
Observers と ZooKeeper
Hadoop による Web 広告システムの構築と運用 :ヨーロッパでの事例
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート
Microsoft readying Hadoop for Windows Azure の対訳

Windows Azure チームが、アイデアを募集!

Posted in Microsoft, MS-MapReduce by Agile Cat on January 26, 2010

サゼッションがあったら ヨロシク !!! 

Windows Azure

・・・ というわけで、みなさんのアイデアを募集中とのことです。 要望を、ドンドン 送りましょう!

Do You Have A Great Windows Azure Idea?

http://blogs.msdn.com/windowsazure/archive/2010/01/25/do-you-have-a-great-windows-azure-idea.aspx

Do you have a suggestion or idea for a new feature for Windows Azure?  We’d love to hear about it so we’ve created a forum for you to weigh on which new features we should consider adding to Windows Azure and to hear about what you need or want in the product moving forward. 

Go here: http://www.mygreatwindowsazureidea.com/ to post requests and vote on other people’s ideas.   We’ll be monitoring the posts and incorporating this input into our plans for the product moving forward. It’s that simple so start sharing your ideas today!

Published Monday, January 25, 2010 4:48 PM by WindowsAzure

ーーーーーーーー

この、上記のポスト自体、つい先程のことのようですが、
もうすでに、たくさんの要望が集まっているようです。

Azure Vote_1

Agile_Cat 的には、ココに ↓ に参戦したいですね。

Azure Vote_2

とても、良い傾向ですよねーーー A.C.

ーーーーー

<参考>
Gartner : Ray Ozzie – Interview 0

Tagged with: , ,

Intel 48 Cores + Hadoop

Posted in Hadoop, MS-MapReduce, Parallel, Virtualization by Agile Cat on December 4, 2009

Futuristic Intel Chip Could Reshape How Computers are Built, Consumers Interact with Their PCs and Personal Devices

Intel 48 cores

SANTA CLARA, Calif., Dec. 2, 2009 – Intel Labs 研究者がデモンストレーションしたのは、48-core Intel プロセッサであり、つまりは、シングルチッ・プクラウド・コンピュータであり、ラップトップや、PC、サーバーなどのデザインで用いられている、現在における数多くのアプローチを再考させるものである。 この未来のチップは、現時点で広く利用されているIntel Core ブランド・プロセッサと比較して、10~20倍の能力のある処理エンジンを内部に持つ。

この研究における長期的なゴールは、まったく新しいソフトウェア・アプリケーションと、コンピュータのマンマシン・インターフェイスをドライブするための、途方も無いスケールを加えていくことである。Intel が来年に計画しているのは、新しいソフトウェア・アプリケーションとプログラミング・モデルの具体的な研究のために、100 個以上の実験用チップを、産業界と教育機関で共有していくことだ。

Intel は、2010 年の前半には、Core ブランド・チップの新しいラインに主要な特徴を統合し、後半には 6-core と 8-core のプロセッサに、それらを導入する。その一方で、このプロトタイプを用いて、1つのシリコン・チップ上に、プログラムを処理できる48個の Intel プロセッシング・コアを取り込んでいく。さらに、 情報共有のための、高速のオン・チップ・ネットワークと、新たに開発されたパワー・マネジメント技術も取り込む。それにより、わずか25ワットから、最大性能時における 125ワットまでの間で、48コアにおける全てをエネルギーを、きわめて効率的に操作できる(今日の Intel プロセッサの消費電力は、標準的な家庭用電球2個分ほど)。

<中略>

マルチ・コア・プロセッサのプログラミングは、シングル・シリコン・チップ上の Many Core へ向かう、コンピュータとソフトウェアのメーカーにとって、重要なチャレンジとして認識されている。 このプロトタイプが実現するのは、一般的で効果的な並列プログラミングのアプローチであり、クラウド・データセンターのソフトウェアで用いられ、このチップに適用されるものとなる。

Intel 48 cores Hadoop

こんな画面も、Youtube の動画でチラッ見られますよ~~~

Intel/HP/Yahoo の Open Cirrus コラボレーションからの研究者により、この 48 IA コアチップへのクラウド・アプリケーションのポートが始まっている。それは、Java framework を用いる Hadoop であり、Rattner が証明しているような、データ・セントリッな分散アプリケーションをサポートしている。 

詳しくは、↓ こちらで ど~ぞ。
http://www.intel.com/pressroom/archive/releases/2009/20091202comp_sm.htm

この実験に Hadoop が使われることが、とても自然に思えます。 Many Core の活躍の場を、Hadoop が作っていくと言っても過言ではないでしょう。 --- A.C. 

<関連>
Nehalem と仮想化

MapReduce in DryadLINQ

Posted in MS-MapReduce by Agile Cat on November 21, 2009

Data-Intensive Computing on Windows HPC Server
with the DryadLINQ Framework

John Vert in 408A on Tuesday at 3:00 PM

Come get an overview of the DryadLINQ features and runtime environment, and walk through some real-world examples of DryadLINQ programs based on the familiar declarative syntax of LINQ combined with the fault-tolerant distributed graph scheduling of the Dryad runtime. Hear how DryadLINQ provides a programming model and runtime for data-parallel programs running across large clusters and partitioned data sets.

http://microsoftpdc.com/Sessions/SVR17

PDC Dryad LINK 1

PDC Dryad LINK 2

PDC Dryad LINK 3

PDC Dryad LINK 4

PDC Dryad LINK 5

PDC Dryad LINK 6

Thanks to  http://twitter.com/nsharp_2ch

— A.C.

Windows Azure MapReduce Demo

Posted in MS-MapReduce by Agile Cat on October 27, 2009

リアルタイム系に MapReduce の概念を?

以前に紹介した、Simon Guest さんの TechED コンテンツですが、自身のブログで Web キャスト化してくれました。 以下の各図は単なるスクリーンキャプチャですが、彼の Screencasts from “Patterns for Cloud Computing” Presentation における ③ は、MapReduce running on Windows Azure という内容であり、その概念がが丁寧に解説されています。

① Windows Azure MapReduce Demo という、きわめて刺激的なタイトル。

SG B_1

② 以前にも紹介した、複数の Worker RoleにMap するというイメージ。

SG B_2

③ こちらは Map のイメージ。

SG B_3

④ つまり、Queue からWorker Role に分散され(Map)、それぞれの出力結果が Table 上に集約(Reduce)される。

SG B_4

⑤ そして DEMO です。。。

SG B_5

⑥ VS 上に作成された、Azure MapReduce Project。

SG B_6

⑦ディプロイされた 5つのノード(Worker Role)。

SG B_7

⑧ 何をしていたかというと、1~500 の間の素数の抽出。 それを、5パラの Worker Role で ・・・

SG B_8

MapReduce という概念は同じでも、Hadoop などとは異なる、リアルタイム系での分散処理なのでしょうね。

1~100 の間の素数、そして、101~200 の間の素数という感じで、処理を分散しているのだと思いますが、たとえば、ログの解析などで、あまり溜め込まずに、逐次的に処理をしていくようなシナリオに当てはまりそうですね。

Hadoop が Microsoft の教材に?

Posted in Hadoop, MS-MapReduce by Agile Cat on September 5, 2009
    MapReduce を認め、Hadoop を学習し、Dryad へ向かっていこう!

    Simon Guest さんが TechED(US)で使った Windows Azure スライドに、とても興味深い一節がありましたので、簡単に紹介しますね。これまで、Microsoft が避けてきた MapReduce に対する評価に、正面から取り組んでいるのです。 私としては、一番 聴きたかったところです。

    すべての基軸が Microsoft の中だけに存在していた時代から、新しい枠組みへと IT の世界は移行しているのですが、それは認め難いという雰囲気でしたよね、これまで。。。 その一方で、外側にできてしまった MapReduce という強固な基軸を無視し続けることが、もう出来なくなっているのも事実だと思います。

    最も合理的な方法は、それを物差しとして利用し、その目盛りのどの位置に、どのようなカウンターをぶつけていくのか、その点を Microsoft が説明していくことです。 それが、情報の発信側と受け手の間で、ショートカットとして機能し、しかも、齟齬を減らしていくのです。

    その Simon さんの一節の出だしが、以下のスライドです。”MapReduce により IT がさらに広がった” とでも解釈すべきなのでしょうかね? (↓)

    MapReduce 1

    以下は、Map に関する説明です。 こんなに解りやすい Map の資料は今までに無かったと思います。(↓)

    MapReduce 2

    同様に、Reduce の説明です。 これまた、解りやすい!(↓)

    MapReduce 3

    ここで、Google、Yahoo、Facebook が、どれだけのデータを MapReduce を用いて日々分析しているのか、その値を示しています。(↓)

    MapReduce 4

    MapReduce のオープンソース版である、Hadoop に関する説明です。(↓)

    MapReduce 5

    "Jim は、今日のオンプレミスで、この問題を、どのように解決するのだろうか?" (Jim というのは、このスライドに出てくるアバターのことです)(↓)

    MapReduce 6

    これが、Azure におけるソリューションです! (推測ですが、Queue と Table があるので、おそらく、そうなんでしょう)(↓)

    MapReduce 7

    1:MapReduce は実績があるが、最初は把握しにくい。

    2:既存のフレームワークを勉強しよう。とりわけ Apatch Hadoop がお勧め。

    3:将来へ向けて、Dryad(DryadLINQ)と調べよう。(↓)

    MapReduce 8

    どんなデモが行われたのでしょうね? ”Inspired by MapReduce” とハッキリ書いてあるところに好感が持てます。(↓)

    MapReduce 9

    ・・・というわけで、Agile Cat でもお勧めの、、、"Hadoop” と "Cosmos + Scope" も ど~ぞ!

    それと、Data Consistency の違いによる住み分けにも、興味がありますね。。。

教育機関への Dryad 提供が始まる

Posted in MS-MapReduce by Agile Cat on July 22, 2009

Microsoft releases Dryad concurrent-programming code to academics
All About Microsoft
Posted by Mary Jo Foley
7:09 am
July 17th, 2009
http://blogs.zdnet.com/microsoft/?p=3385

Google の MapReduce と Apache の Hadoop への対抗策として位置づけられる、コンカレント・プログラミング・テクノロジーである Microsoft の Drayed について、Bill Gates が言及してから 2年の歳月がたつ。今週になって、その Dryad のコードが教育機関と研究機関に提供されたことにより、我々の視界に再び捉えられるようになってきた。

dryad-1

この Dryad のゴールは、Windows コンピュータによるクラスタ上で実行するアプリケーションの、プログラマたちによる開発を実現することにある。つまり Dryad は、マルチ・マシンをまたがる複雑なアプリケーションの、低レベルにおける自動的なパラレル化を実現する、システムのためにデザインされている。コンピューティング集約型にフォーカスする、既存のハイ・パフォーマンス・グリッド・プラットフォームとは異なり、Drayed が取り組むのは、最も重要なスケールとフォールト・トレランスが欠かせない、データ集約型のコンピューティング・シナリオである。

Microsoft と厳選されたパートナーたちは、バイオ情報科学から天体観測にいたるすべての領域において、多様なサンプルと現実世界のアプリケーションを、Dryad コードを用いて開発している。

Microsoft が今週に開催した Faculty Summit 2009 conference において、Dryad と DryadLINQ プログラミング・ツールが利用可能になったと、同社から正式なアナウンスがあった(Dryad バイナリー・コードとDryadLINQ ソース・コード)。C# プログラミング言語に対するQuery (LINQ) 拡張の統合を DryadLinq が実現することで、.NET プログラマによる Drayed アプリケーションの記述が可能となる。教育機関と研究機関は、 Microsoft の MS-Research ライセンス契約にサインした後に、Dryad と DryadLINQ のダウンロード が可能となる。

このカンファレンスで Microsoft の重役たちは、同社のクラウド・コンピューティング・プラットフォームである Azure 上で、この Drayed が動作しないことを認めているが、それを実現するためのプランも進められているという。ただし、Azure への移行に関するタイム・テーブルは、Factulty Summit の参加者たちにオフィシャルには提供されていない。

(Microsoft Researcher である Mihai Budiu が 2009年 3月に 行った、Dryad プレゼンテーションから取得した 以下のスライドを参照してほしい。Azure の部分はハッキリとは表示されていないが、Dryad と Azure の組み合わせについて、Microsoft が思い描いている様子がわかる)

dryad-2

現時点において、Dryad は他と比べて研究段階にある。すべての Microsoft Research プロジェクトと同様に、その商用化については、実現性も時期も約束されていない。

しかし 2008年には、Microsoft Research Silicon Valley の Senior Researcher である Michael Isard が、短期間のニーズのためではあるが、プロダクト・グループを支援するために、Dryad の一部が構築されたと言及している。つまり、そこではデータ分析が必要だったわけであり、分散環境における別の局面において、研究の推進を実現するためのプラットフォームであると期待されているのである。

Microsoft は、多様な並列/分散コンピューティング・プロジェクトを走らせている。同社が開発している、次世代オペレーティング・システムの Midori も、そのひとつである。

こちらも ど~ぞ : カテゴリ Cosmos + Scope

http://agilecat.wordpress.com/category/cosmos-scope/

 

%d bloggers like this: