Agile Cat — in the cloud

クラウドは、オープンソースと伴に遍在化していく

Posted in .Selected, Linux, Research by Agile Cat on November 23, 2011

The Cloud Will Be Open Source And Ubiquitous
November 18, 2011 – by
Dana Blankenhorn
http://seekingalpha.com/article/308970-the-cloud-will-be-open-source-and-ubiquitous

_ seeking alpha

Cloud is an architecture. When you architect servers with virtualization, distributed computing and the ability to handle big data, so a single Web site or job can take power of the whole system when needed, that’s a cloud.

クラウドはアーキテクチャである。 仮想化を用いて、そして、分散コンピューティングと、Big Data 処理能力を用いてサーバーを構築するとき、シングル Web サイトもしくは単一のジョブの中に、必要に応じてシステム全体のパワーを取り込むことができる。 それが、クラウドである。

Salesforce.com (CRM) (whatever you may think of it) is not a cloud. It is Software as a Service (SaaS), something that can result from a cloud architecture but does not require a cloud. The same can be said for Apple’s (AAPL) iCloud. It too is SaaS, which could come from a cloud or from a standard enterprise set-up.

imageSalesforce.com(CRM)は、(考える得る全てにおいて)クラウドではない。つまり、SaaS であり、クラウド・アーキテクチャから得られるものではあるが、絶対にクラウドを必要とするものではない。Apple (AAPL)の iCloud についても、同じことが言える。 それは、さらに SaaS 寄りのものであり、クラウドだけではなく標準的なエンタープライズ・システムでも構築できる。

What we have learned about the cloud in the last week is that it will, without doubt, be based on open source and open standards. We know this from two news stories:

私たちが先週に学んだ確かなことは、クラウドがオープン・ソースとオープン・スタンダードに基づくことである。そして、2つのニュース・ストーリーから、それを確認できる:

  • Microsoft (MSFT) has abandoned its high performance computing architecture, called Dryad, in favor of open source Hadoop. This followed similar decisions by EMC, Oracle and IBM.
  • Microsoft(MSFT)は、Dryad と呼ばれる HOC アーキテクチャを断念し、オープンソースである Hadoop に賛意を示した。 すでに EMC/Oracle/IBM も、同様の判断を示しており、それに従う形となった。
  • クラウド企業である Eucalyptus は、オープンソースの道筋から逸れたが、その世界で信頼されるコミュニティ・マネージャーを、 Red Hat(RHT)から採用することで、もとの道に戻った。

Open source has become a cloud requirement because clouds are complicated, requiring a lot of cooperation among vendors to develop, and because everyone who has been involved in enterprise computing is rushing to the architecture just as fast as they can. Time is of the essence, in other words, and proprietary advantage has to go out the window.

オープンソースであることが、クラウドの要件になった。なぜなら、クラウドは複雑であり、開発するためには、ベンダー間における幅広い協調が必要だからである。そして更に、エンタープライズ・コンピューティングに関わる誰もが、可能な限り迅速に、このアーキテクチャを取り入れたがっているからである。 言い換えれば、時間こそが本質であり、また、プロプライエタリによるメリットは、消えて無くならなければならない。

Over the next few years nearly all Web hosting, all online services and Software as a Service offerings will become cloud based. Even phone companies are moving to the cloud, or at least their suppliers are.

これからの数年において、ほとんど全ての Web ホスティングおよび、すべてのオンライン・サービスと SaaS は、クラウドをベースにしていくことになる。 電話会社さえ、そのクラウドに移行している。もしくは、そのサプライヤーは、少なくとも移行していると言えるだろう。

Which tells us something else important.

それらの事象から、別の重要な何かを学べる。

Cloud is going to quickly become a commodity, not a differentiator, practically a requirement. Customers will differentiate based on the quality of a cloud, or its software, or the people doing the hosting. Enormous price earning multiples based on having cloud, like those of Rackspace (RAX), VMWare (VMW) and Red Hat (VMW) are going to bleed away, replaced by lower and more nuanced valuations based on product and service leadership.

クラウドは、急速にコモディティ化しており、差別化の要因や、実質上の要件ではなくなる。 そしてクラウドの利用者が、ベースとなるクラウドやソフトウェアの品質により、あるいはホスティングの品質により、エンドユーザーに対して差別化の要因を示していくだろう。 Rackspace(RAX)や、VMWare(VMW)、Red Hat(VMW)といったクラウドに対して、何倍もの巨大な株式資本を有する企業は、レッド・オーシャンへと向かっていくだろう。つまり、プロダクトとサービスのリーダーシップに基づき、また、安価で算定しづらい価値を持つ、オープンソースにより置き換えられていくことになる。

This does not mean that cloud leaders will have PE multiples similar to every other company. It just means they’re going to have to earn that leadership in the market, through sales and earnings, rather than by hyping the cloud.

ただし、他の企業と比較して、クラウド・リーダーたちの株式資本が小さいと言いたいわけではない。それらの企業は、クラウドを誇大宣伝するのではなく、マーケットにおける販売と資金調達という両面において、リーダーシップを発揮していくべきだろう。

Disclosure: I have no positions in any stocks mentioned, and no plans to initiate any positions within the next 72 hours.

More articles by Dana Blankenhorn »

ーーーーー

TAG indexクラウド以前からの企業がクラウドに取り組む場合と、クラウド有りきで成長してきた企業の間には、その規模やメンタリティにおいて、大きな違いがあると思います。その違いが、あらゆる局面におけるスピードの違いとして、顕在化してくるのが 2012 年のような気がします。 なお、この Seeking Alpha は経済誌だと思うのですが、こうしてテクノロジー・ベースの分析も取り入れ、おもしろい記事を提供してくれます。ーーー __AC Stamp 2

ーーーーー

<関連>

この一年で、OSS への支出が 56% に跳ね上がった
OSS に対する企業意識の調査 – 予想以上の期待度にビックリ!
クラウドは 他の IT と比べて、4倍速で急成長していく – IDC
SaaS の広がりが、クラウド・ベンダーに急成長をもたらす
クラウドに潜む、見えないコストについて言及しておこう
クラウド・ベンダー・ロックインと闘うための 五箇条の御誓文

Hadoop に似た Dryad は、Microsoft の Big Data スターになれるのか

Posted in Big Data, Hadoop, Parallel by Agile Cat on December 24, 2010

Why Hadoop-like ‘Dryad’ Could Be Microsoft’s Big Data Star
By
Derrick Harris
Dec. 21, 2010, 11:09am PDT
http://gigaom.com/cloud/why-hadoop-like-dryad-could-be-microsofts-big-data-star/

_ Gigaom

Microsoft’s HPC division opened up the company’s Dryad parallel-processing technologies as a Community Technology Preview (CTP) last week, a first step toward giving Windows HPC Server users a production-ready Big Data tool designed specifically for them. The available components — Dryad, DSC and DryadLINQ – appear to be an almost part-for-part comparison with the base Hadoop components (Hadoop MapReduce, Hadoop Distributed File System and the SQL-like Hive programming language) and hint that Microsoft wants to offer Windows/.NET shops their own stack on which to write massively parallel applications. Dryad could be a rousing success, in part because Hadoop – which is written in Java – is not ideally suited to run atop Windows or support .NET applications.

Microsoft の HPC 部門は先週、主として Windows HPC Server ユーザーのために設計された、プロダクションに対応可能な Big Data ツールを提供する、Dryad 並列処理テクノロジーの Community Technology Preview(CTP)を、その第一歩として公開した。 そこで利用する Dryad/DSC/DryadLINQ といったコンポーネントは、大まかなところで Hadoop コンポーネント(Hadoop MapReduce/Hadoop Distributed File System/SQL-like Hive programming language)に対応しているように見える。そして、Windows および .NET の開発者に対して、大規模並列アプリケーションを記述するための、Microsoft プロダクト・スタックを積み上げるというヒントが隠されている。Hadoop は Java で記述されおり、Windows 上での実行や、.NET アプリケーションのサポートにおいて、理想的ではないため、その部分で Dryad は成功するだろう。

When Microsoft broke into the high-performance computing market in 2005 with its Windows Compute Cluster Server, it affirmed the idea that, indeed, HPC was taking place on non-Linux boxes. Certainly, given the prevalence of large data volumes across organizations of all types, there is equal, if not greater, demand for Hadoop-like analytical tools even in Windows environments. Presently, however, Apache only supports Linux as a production Hadoop environment; Windows is development-only.  There are various projects and tools floating around for running Hadoop on Windows, but they exist outside the scope of Apache community support.  A Stack Overflow contributor succinctly summed up the situation in response to a question about running Hadoop on Windows Server:

Windows Compute Cluster Server により Microsoft が 2005年に High-Performance コンピューティングの市場に参入したとき、非 Linux ボックス上の HPC が、本当に成立するという発想を確認した。 確かに、すべての組織のたるところで、大容量データがトレンドになることを前提にすると、Hadoop のような分析ツールへの需要は、Windows環境であっても、それと同じ程度を見込めるだろう。しかしながら、現時点において、Apache は Hadoop の運用環境として Linux だけをサポートしており、Windows は開発環境のみである。  Windows 上で Hadoop を実行させるための、多様なプロジェクトとツールが存在するが、それらは Apache コミュニティ・サポートのスコープから外れている。  Stack Overflow のコントリビュータが、Windows サーバー上で Hadoop を走らせるという質問への回答において、その状況を簡潔にまとめている:

From the Hadoop documentation:
‘Win32 is supported as a development platform. Distributed operation has not been well tested on Win32, so it is not supported as aproduction platform.’
Which I think translates to: ‘You’re on your own.’

Hadoop documentation より:
『 Win32 は、開発プラットフォームとしてサポートされる。 Win 32 上での分散処理は、適切にテストされていないため、運用プラットフォームとしてはサポートされない 』
私が考えだと、それは『 あなたは独り立ちしている 』と翻訳される。

Then there is the Windows Azure angle, where Microsoft appears determined to compete with Amazon Web Services. Not only has it integrated IaaS functionality in Windows Azure, but, seemingly in response to AWS courting the HPC community with Cluster Compute Instances, Microsoft also recently announced free access to Windows Azure for researchers running applications against the NCBI BLAST database, which currently is housed within Azure. Why not counter Elastic MapReduce – AWS’s Hadoop-on-EC2 service – with Dryad applications in Azure?

そして、Microsoft が Amazon Web Services との競合を決意した、Windows Azure の視点がある。それは単に、Windows Azure 内で IaaS 機能を統合するだけではなく、 Cluster Compute Instances を用いた HPC コミュニティ作りに熱心な、AWS への反応とも映る。最近のことだが、さらに Microsoft は、NCBI BLAST データベースに対抗して、研究者たちがアプリケーション実行するWindows Azure への、無料でのアクセスを発表した。 それらは、現時点において、Azure の中にホストされている。 AWS EC2 における Hadoopサービスである Elastic MapReduce に対して、Azure 上の Dryad アプリケーションで立ち向かったらどうだろう?

SD Times actually reported in May that Microsoft was experimenting with supporting Hadoop in Windows Azure, but that capability hasn’t arrived yet. Perhaps  that’s because Microsoft has fast-tracked Dryad for a slated production release in 2011. As the SD Times article explains, Hadoop is written in Java, and any support for Hadoop within Windows Azure likely would be restricted to Hadoop developers. That’s not particularly Microsoft-like, which certainly would prefer to give additional reasons to develop in .NET, not Java. Dryad would be such a reason.

この 5月のことだが、SD Times は Microsoft が Windows Azure 上で Hadoop をサポートするための実験を進めているが、その能力はまだ目標を達成していないとレポートした。 2011年に予定されていた Dryad の製品リリースを、Microsoft が前倒しにした理由は、おそらく、そこになあるのだろう。 SD Times の記事が述べたように、Hadoop は Java で記述されており、Windows Azure における あらゆる Hadoop サポートは、おそらく、Hadoop デベロッパーに対するものに限定されるだろう。 そして、Microsoft にとっては特別というわけではないが、Java ではなく .NET が優先されるという、別の理由もあるはずだ。 Dryad は、こうした背景を持つのだろう。

What might give the Microsoft developer community even more hope is the Dryad roadmap that Microsoft presented in August. ZDNet’s Mary Jo Foley noted a variety of Dryad subcomponentsthat will make Dryad even more complete, including a job scheduler codenamed “Quincy.”

その Microsoft デベロッパー・コミュニティに対して、さらなる希望を何が与えるかといえば、Microsoft が 8月に提供したDryad のロードマップである。 ZDNet の Mary Jo Foley は、Dryad の完成度を高めるサブ・コンポーネント群の存在に気づいた。 そして、「Quincy」というコードネームを付けらた、ジョブ・スケジューラーも含まれることを指摘した。

But there’s no guarantee that the production version of Dryad will resemble the current iteration too closely. As Microsoft notes in the blog post announcing the Dryad CTP, “The DryadLINQ, Dryad and DSC programming interfaces are all in the early phases of development and might change significantly before the final release based on your feedback.” A prime example of this is that Dryad has only been tested on 128 individual nodes. In the Hadoop world, Facebook is running a cluster that spans 3,000 nodes (sub req’d). Dryad has promise as Hadoop for the Microsoft universe, but, clearly, there’s work to be done.

しかし、Dryad のプロダクション・バージョンが、現時点におけるイテレーションと、きわめて類似するものになるという保証はない。 そして Microsoft は自身のブログ・ポストで、『 DryadLINQ/Dryad/DSC プログラミング・インターフェイスの全てが、現時点では初期の開発段階にあるため、最終的なリリースを迎える前に、フィードバックに基づた大幅な変更が加えられるかもしれない 』 と、アナウンスしている。その顕著な例として、Dryad がは 128 ノードだけしかテストされていないという点が挙げられる。 Hadoop 世界では、3,000 ノード(以下で参照)にまたがるクラスタが、Facebook により運用されている。 Dryad は、Microsoft の宇宙における Hadoop だと見込まれているが、完了すべき作業が、まだまだ残っている。

Related content from GigaOM Pro (sub req’d):

ーーーーー

う~ん! コメントしにくいので、何も言わない。 ーーー A.C.

ーーーーー

<関連>
Microsoft readying Hadoop for Windows Azure の対訳
Microsoft と Intel には、並列/分散の隠し技があるのか
Dryad が DAG をつかう理由 – Dryad & DryadLINQ Team Blog
Windows Azure チームは、どのような興味を Cassandra に持っているのか?
NoSQL は Microsoft にとって重要だから、Microsoft だけに任せておけない!
実行中にノードを追加できる、新しい Elastic MapReduce とは?
MapReduce と Hadoop の将来について
Facebook の HBase は、毎月 1350億 メッセージを処理する!

 

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 の対訳

Microsoft readying Hadoop for Windows Azure の対訳

Posted in Hadoop, Microsoft by Agile Cat on May 4, 2010

Microsoft readying Hadoop for Windows Azure
By David Worthington
5/3, 2010
http://www.sdtimes.com/content/article.aspx?ArticleID=34319&page=1

ーーーーー

日本時間の 5/4 の午後に飛び込んできたニュースです。 超大急ぎの、ウルトラ・ラフ対訳でポストした後に、実は玉川さんに 「ちょっとチェックを~~~」 と、お願いしてみたところ、すばらしい校正をしていただけました :)  ・・・ というわけで、玉川竜司バージョンを、是非、どうぞ。 ーーー A.C.

ーーーーー

image

Microsoft is preparing to provide Hadoop, a Java software framework for data-intensive distributed applications, for Windows Azure customers.

Microsoft は Windows Azure の顧客に対して、データ集約分散のためのアプリケーションのための、Java ソフトウェア・フレームワークである Hadoop を提供すべく準備を進めている。

Hadoop offers a massive data store upon which developers can run map/reduce jobs. It also manages clusters and distributed file systems. Microsoft will provide Hadoop within a "few months," said a Microsoft executive who wished to remain anonymous.

Hadoopは、デベロッパーが Map/Reduce を実行できる大規模なデータストアを提供する。クラスタと分散ファイル・システムもまた管理する。 Microsoft の首脳が、「数カ月」のうちに Hadoop を提供すると発言しているが、彼は匿名を望んでいる。

The technology makes it possible for applications to analyze petabytes of both structured and unstructured data. Data is stored in clusters, and applications work on it programmatically.

このテクノロジーにより、構造化されているか否かによらず、ペタ・バイト・オーダーのデータを分析するアプリケーションが実現される。 それらのデータはクラスタに格納され、アプリケーションはプログラムによってそれらのデータを処理する。

"They are probably seeing Hadoop adoption trending up, and possibly have some large customers demanding it," said Forrester principal analyst Jeffrey Hammond.

「おそらく、MIcrosoft は、Hadoop の適用がトレンドになっていることを確認しており、また、いくつかの大手顧客の要求もあったのかもしれない」と、Forrester の主席アナリストである Jeffrey Hammond は発言している。

"Microsoft is all about money first; PHP support with IIS and the Web PI initiative were all about numbers and creating platform demand. If Hadoop support helps creates platform demand for Azure, why not support it? Easiest way to lead a parade is to find one and get in front of it."

「Microsoft は常に金額を第一に考えます。 つまり、IISによるPHPのサポートや Web PIイニシアティブは、数字が重要であり、プラットフォームに対する需要を喚起するためのものでした。 もし、Hadoop のサポートが、Azure プラットフォームに対する需要の喚起に寄与するなら、それをサポートしない手はないでしょう? パレードを導く最も容易な方法は、それを探し出して、その先頭に立つことなのです」

Microsoft’s map/reduce solution, codenamed "Dryad," is still a reference architecture and not a production technology.

「Dryad」という コードネームを持つMicrosoftのMap/Reduceソリューションは、現時点では実用のテクノロジーではなく、リファレンス・アーキテクチャに過ぎない。

Further, AppFabric, a Windows Azure platform for developing composite applications, currently lacks support for data grids. Microsoft has experienced difficulty in porting Velocity, a distributed in-memory application cache platform, to Windows Azure, because Velocity requires administrative privileges to install, the anonymous executive told SD Times.

さらに、複合アプリケーションを開発するためのWindows AzureのプラットフォームAppFabricは、現時点ではデータ・グリッドに対するサポートが欠落している。 Microsoftは、分散型のインメモリ・アプリケーション・キャッシュ・プラットフォームであるVelocityのWindows Azureへの移植に際して困難を経験した。その理由は、インストールする際にアドミニストレータ特権が必要だったからだと、この匿名の首脳は SD Times に打ち明けている。

"Do they feel so ‘way behind’ that they are rolling out a Java-based product without a .NET-based ‘superior’ alternative ready to go?" asked Larry O’Brien, a private consultant and author of the "Windows & .NET Watch" column for SD Times. "Perhaps they feel that distributed map/reduce is not really all that important, that they can put Hadoop on the ‘check-off box’ and it won’t be embarrassing that it gives Java developers a capability that .NET developers don’t have?"

「.NET ベースの ”より優れた”代案を用意することなく、Java ベースのプロダクトを市場に送り出すほど、Microsoft が"立ち後れてしまった"と感じているのでしょうか?」と、プライベート・コンサルタントであり、SD Times の "Windows & .NET Watch" の著者である Larry O’Brien” は疑問を投げかける。 「おそらく、Microsoft は、Map/Reduce がそれほど重要だとは感じていないので、Hadoop には確認用のチェックボックスをつけておくことができれば、それがJava デベロッパーに対して、NET デベロッパーが持たない力を提供することは、べつに恥ずかしいことではないのでしょう」

The Azure platform is not restricted to .NET development. Microsoft partnered with Soyatec to produce the Azure SDK for Java. However, using Hadoop as a data grid solution is a departure from Microsoft’s approach to data access.

Azure プラットフォームは、.NET 開発に限定されているわけではない。 Microsoft は Soyatec と組んで、Azure SDK for Java を作った。 しかし、Hadoop をデータ・グリッド・ソリューションとして用いることは、Microsoft におけるデータ・アクセスのアプローチからの脱却を意味する。

.NET’s existing data access APIs, such as the ADO.NET Entity Framework, provide an object-relational mapping (ORM) framework that abstracts data from the application.

ADO.NET Entity Framework のような、.NETにおける既存のデータ・アクセスAPIは、アプリケーションからデータを抽象化するためのORM(object-relational mapping )フレームワークを提供する。

Microsoft’s Velocity caching technology resides in the business logic layer, in the sense that it is in-memory and object oriented, said William Bain, CEO of ScaleOut Software. Dryad emphasizes its parallel computation model, which can be integrated with file storage, he added.

MicrosoftのVelocityキャッシング・テクノロジーは、それがインメモリでありオブジェクト指向であるという意味において、ビジネス・ロジック・レイヤに配置される と、ScaleOut Software の CEO である William Bain は言う。 Dryadでは、ファイル・ストレージとの統合が可能なパラレル・コンピューティング・モデルが強調されている、と彼は付け加えている。

Hadoop integrates parallel data analysis with the data storage layer rather than solely residing in the business logic layer. Its use of its own distributed file system with data accessed from the file system "creates its storage integration and the associated complexity," Bain claimed

Hadoop は、ビジネス・ロジック・レイヤだけに存在するというより、パラレル・データ分析をデータ・ストレージ・レイヤと統合するものだ。 つまり、独自の分散ファイル・システムからアクセスされるデータと、そのファイルシステムの利用は「ストレージとのインテグレーションと、それに伴う複雑さを生み出す」と、Bain は主張する。

"Map/reduce is definitely lower-level than SQL," said O’Brien. "However, because it’s more like a powerful mathematical technique than a black box whose internal workings are unclear, it’s not necessarily ‘more complex’ to think through a tough data analysis problem in terms of map/reduce. Map: ‘Farm out all of this identical work to a whole bunch of different computers.’ Reduce: ‘Gather those results and combine duplicates.’ Feed the reduced dataset into another map/reduction process. Conceptually, that’s pretty easy to reason with!"

「たしかにMap Reduceは、SQLと比較して低レベルだ」と、O’Brienは言う。 「しかし、内部の処理が不明確なブラック・ボックスと比較すれば、よりパワフルで数学的なテクニックに近いので、Map/Reduceの観点からタフなデータ分析の問題について考えたとしても、必ずしも「より複雑」なわけではない。 Map:このすべての同一の処理を、様々なコンピュータの集合体に対して請け負わせる。Reduce:それらの結果を集め、複製分を集約する。Reduce されたデータセットを、別の Map/Reduction プロセスにフィードする。 概念的には、きわめて納得がいくことだ。

Microsoft can gain a data grid capability in Azure by acquiring a partner such as ScaleOut Software or Alachisoft, said Forrester senior analyst Mike Gualtieri. Microsoft is not far behind other platform players in providing distributed data grids on the cloud, he added.

Microsoft は、ScaleOut Software や Alachisoft といったパートナーを手にいれることで、Azure にデータ・グリッド機能を加えることができると、Forrester の senior analyst である Mike Gualtieri は発言している。Microsoft は、分散データ・グリッドのクラウドへの提供という点では、他のプラットフォーム・プレーヤーにそれほど後塵を拝してはいないと、彼は付け加えている。

ScaleOut Software uses a memory-based approach to map/reduce analysis. Its parallel method invocation integrates parallel query with map/reduce on object collections stored in the grid.

ScaleOut Software では、Map / Reduce 分析のために、メモリベースのアプローチを用いている。 その並列メソッド呼び出しは、グリッドにストアされたオブジェクトのコレクションに対するMap / Reduceと、パラレル・クエリーを統合する。

“In-memory, object-oriented map/reduce within the business logic layer offers important advantages in reducing development time and maximizing performance,” said Bain. “Over time, we are confident that this approach will efficiently handle petabyte data sets, which currently rely on file-based implementations.”

「インメモリでオブジェクト指向のmap/reduceをビジネス・ロジック・レイヤに置けば、開発時間の短縮とパフォーマンスの最大化という重要なアドバンテージが得られる」と、Bain は言う。 「現時点ではファイル・ベースの実装に依存しているペタバイトのデータセットをも、このアプローチなら効果的に処理できると確信するようになった」

Additionally, there are open-source map/reduce solutions for .NET. A project called hadoopdotnet ports Hadoop to the .NET platform. It is available under the Apache 2.0 open-source license. MySpace Qizmt, a map/reduce framework built using .NET, is another alternative. It is licensed under GNU General Public License v3.

加えて、.NET用のオープンソース Map / Reduceソリューションも存在する。 ”hadoopdotnet”と呼ばれるプロジェクトは、Hadoopを.NET プラットフォームに移植するものだ。これは、Apache 2.0オープンソース・ライセンスのもとで利用できる。.NETを用いて構築されたMap/ReduceフレームワークであるMySpace Qizmtは、もう 1つの選択肢だ。こちらは、GNU General Public License v3 のもとでライセンスされている。

ーーーーー

<関連>
Hadoop による Web 広告システムの構築と運用 :ヨーロッパでの事例
TechDays のキーノートは、ここに注目!
Windows Azure チームが、アイデアを募集!
Microsoft は オープンソースへ走ると、O’Reilly が予言!
Bing と Yahoo の関係

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

The Anatomy of Hadoop I/O Pipeline _1

Posted in Big Data, Hadoop I/O Pipeline by Agile Cat on September 25, 2009

 

YDN Hadoop and Distributed Computing at Yahoo!

Hadoop and Distributed Computing at Yahoo!

August 27, 2009

From <http://developer.yahoo.net/blogs/hadoop/>

今日から何回かに分けて、Hadoop I/O Pipeline に関する対訳を掲載していきます。この領域に関するドキュメントは初めてのものらしく、読んでいても解らないことばかりです。 訳について、問題などありましたら、また、こう読むべきみたいなアドバイスがありましたら、ぜひコメントをつけてください。 Windows Azure + Dryad につながる知識が共有できればと思います。 --- A.C.

Introduction

In a typical Hadoop MapReduce job, input files are read from HDFS. Data are usually compressed to reduce the file sizes. After decompression, serialized bytes are transformed into Java objects before being passed to a user-defined map() function. Conversely, output records are serialized, compressed, and eventually pushed back to HDFS. This seemingly simple, two-way process is in fact much more complicated due to a few reasons:

Hadoop MapReduce における一般的なジョブでは、入力ファイルは HDFS からが読み込まれる。 そのファイル・サイズを低減するために、通常ではデータの圧縮と解凍が行われた後に、シリアライズさたバイト列が Java オブジェクトに変換され、ユーザー定義された map () 関数に引き渡される。 その反対に、出力レコードにもシリアライズと圧縮が行われ、最終的に HDFS の中にプッシュバックされる。この双方向のプロセスはシンプルに見えるが、いくつかの理由により、実際には複雑なものとなる:

  • Compression and decompression are typically done through native library code.
  • End-to-end CRC32 checksum is always verified or calculated during reading or writing.
  • Buffer management is complicated due to various interface restrictions.

一般的には、ネイティブのライブラリ・コードを介して実行される圧縮と解凍

一般的には、Read/Write の際に常に検証/計算される End-to-End CRC32 チェックサム

多様な制約事項により、複雑化していくバッファ管理

In this blog post, I attempt to decompose and analyze the Hadoop I/O pipeline in detail, and explore possible optimizations. To keep the discussion concrete, I am going to use the ubiquitous example of reading and writing line records from/to gzip-compressed text files. I will not get into details on the DataNode side of the pipeline, and instead mainly focus on the client-side (the map/reduce task processes). Finally, all descriptions are based on Hadoop 0.21 trunk at the time of this writing, which means you may see things differently if you are using older or newer versions of Hadoop.

このブログ・ポストで試みるのは、Hadoop I/O パイプラインに関する詳細な分解と分析であり、また、実現可能な最適化の追求である。 その説明を具体的にしていくために、gzip 圧縮されたテキスト・ファイルを対象として、ライン・レコードを Read/Write するサンプルを、随所で利用していく。 また、パイプラインの DataNode 側の詳細には入らない代わりに、主としてクライアント側(map/reduce タスク・プロセス)に焦点を合わせる。この執筆は Hadoop 0.21 の主要部分に基づいているため、あなたの利用しているバージョンとの間で、若干の違いが生じるかもしれない。

The Anatomy of Hadoop I/O Pipeline _1
The Anatomy of Hadoop I/O Pipeline _2
The Anatomy of Hadoop I/O Pipeline _3
The Anatomy of Hadoop I/O Pipeline _4
The Anatomy of Hadoop I/O Pipeline _5

The Anatomy of Hadoop I/O Pipeline _2

Posted in Hadoop I/O Pipeline by Agile Cat on September 24, 2009

From <http://developer.yahoo.net/blogs/hadoop/>

Reading Inputs

Figure 1 illustrates the I/O pipeline when reading line records from a gzipped text file using TextInputFormat. The figure is divided in two sides separated by a thin gap. The left side shows the DataNode process, and the right side the application process (namely, the Map task). From bottom to top, there are three zones where buffers are allocated or manipulated: kernel space, native code space, and JVM space. For the application process, from left to right, there are the software layers that a data block needs to traverse through. Boxes with different colors are buffers of various sorts. An arrow between two boxes represents a data transfer or buffer-copy. The weight of an arrow indicates the amount of data being transferred. The label in each box shows the rough location of the buffer (either the variable that references to the buffer, or the module where the buffer is allocated). If available, the size of a buffer is described in square brackets. If the buffer size is configurable, then both the configuration property and the default size are shown. I tag each data transfer with the numeric step where the transfer happens:

Figure 1 が示すのは、gzip されたテキスト・ファイルから、TextInputFormat を使ってラインレコードを読み込むときの I/O パイプラインである。 この図は、左右の 2つのパートに分割されている。 左側は DataNode プロセスを示し、右側はアプリケーション・プロセス(すなわち Mapタスク)を示す。ボトムらトップへ向けて、Kernel/Native/JVM の 3つのゾーンがあり、それぞれにバッファが割り当てられ操作される。 アプリケーション・プロセスに関しては、左から右へ向けて、データ・ブロックが横断しなくてはならないソフトウェア・レイヤが存在する。それぞれのカラーで色づけされたボックスは、各種のソートに用いるバッファである。ボックス間を結ぶ矢印ラインは、データ転送あるいはバッファコピーを示す。矢印ラインの太さは、それぞれのデータ量を示す。それぞれのボックス内のラベルは、バッファの大まかなロケーション(バッファに参照する変数あるいは、バッファが割り当てられるモジュール)を示す。記載が可能な場合には、バッファ・サイズをカッコ内に記している。バッファ・サイズをコンフィグレーションできる場合には、そのプロパティとデフォルト・サイズの双方を示す。データが転送される際の、それぞれのステップに対して、以下のタグを付けている:

Hadoop IO_1


Figure 1: Reading line records from gzipped text files.

  1. Data transferred from DataNode to MapTask process. DBlk is the file data block; CBlk is the file checksum block. File data are transferred to the client through Java nio transferTo (aka UNIX sendfile syscall). Checksum data are first fetched to DataNode JVM buffer, and then pushed to the client (details are not shown). Both file data and checksum data are bundled in an HDFS packet (typically 64KB) in the format of: {packet header | checksum bytes | data bytes}.
  2. Data received from the socket are buffered in a BufferedInputStream, presumably for the purpose of reducing the number of syscalls to the kernel. This actually involves two buffer-copies: first, data are copied from kernel buffers into a temporary direct buffer in JDK code; second, data are copied from the temporary direct buffer to the byte[] buffer owned by the BufferedInputStream. The size of the byte[] in BufferedInputStream is controlled by configuration property "io.file.buffer.size", and is default to 4K. In our production environment, this parameter is customized to 128K.
  3. Through the BufferedInputStream, the checksum bytes are saved into an internal ByteBuffer (whose size is roughly (PacketSize / 512 * 4) or 512B), and file bytes (compressed data) are deposited into the byte[] buffer supplied by the decompression layer. Since the checksum calculation requires a full 512 byte chunk while a user’s request may not be aligned with a chunk boundary, a 512B byte[] buffer is used to align the input before copying partial chunks into user-supplied byte[] buffer. Also note that data are copied to the buffer in 512-byte pieces (as required by FSInputChecker API). Finally, all checksum bytes are copied to a 4-byte array for FSInputChecker to perform checksum verification. Overall, this step involves an extra buffer-copy.
  4. The decompression layer uses a byte[] buffer to receive data from the DFSClient layer. The DecompressorStream copies the data from the byte[] buffer to a 64K direct buffer, calls the native library code to decompress the data and stores the uncompressed bytes in another 64K direct buffer. This step involves two buffer-copies.
  5. LineReader maintains an internal buffer to absorb data from the downstream. From the buffer, line separators are discovered and line bytes are copied to form Text objects. This step requires two buffer-copies.

1: DataNode から MapTask プロセスへ向けた、データの転送。 DBlk はファイルのデータ・ブロックであり、CBlk はファイルのチェックサム・ブロックである。ファイル・データは、Java nio transferTo (UNIX sendfile syscall のこと)を介してクライアントに転送される。最初にチェックサム・データが DataNode JVM バッファにフェッチされ、続いてクライアント(細部は示していない)にプッシュされる。 ファイルとチェックサムのデータが {packet header | checksum bytes | data bytes} のフォーマットにより、HDFS パケット(一般は 64kb)にまとめられる。

2: ソケットから受信されたデータは、おそらく、カーネルに対する syscalls 数を減らすことを目的として、 BufferedInputStream 内のバッファに入れられる。 実際には、2つのバッファを用いたコピーが行われる。データは最初に、JDK コードによるカーネル・バッファから、テンポラリ・バッファへダイレクトにコピーされる。続いて、テンポラリ・バッファ内のデータは、BufferedInputStream が管理する byte [] バッファにコピーされる。 BufferedInputStream の byte [] のサイズは、コンフィグレーション・プロパティである "io.file.buffer.size" により制御されるが、デフォルトは 4K となっている。 私たちの実運用環境では、このパラメータを128K にカスタマイズした。

3: BufferedInputStream を介することで、チェックサム・バイトは(その大まかなサイズは(PacketSize / 512 * 4)あるいは 512 B )内部の ByteBuffer 内に保存される。そして、ファイル・バイト(圧縮されたデータ)は、解凍レイヤが提供する byte [] バッファ内に堆積していく。 ユーザー・リクエストはチャンクの境界線をそろえないかもしれないが、チェックサムの計算ではフルの 512 byte チャンクが必要とされるため、ユーザーが提供する byte [] バッファ内に、部分的なチャンクをコピーしてしまう前に、512 byte [] バッファが使用される。 さらに、(FSInputChecker API が必要とする場合には)512 byte 単位のバッファに、データがコピーされることに注意すべきだ。 最終的に、FSInputChecker によるチェックサム検査を実現するために、すべてのチェックサム・バイトは 4 byte 配列内にコピーされる。 全体的に、このステップでは、余分のバッファ・コピーが生じる。

4: 解凍レイヤでは、DFSClient レイヤからのデータを受信するために、byte [] バッファが使用される。 DecompressorStream では、byte [] バッファから 64K のダイレクト・バッファにデータをコピーし、データを解凍するためにネイティブ・ライブラリ・コードをコールし、解凍されたデータを別の 64K ダイレクト・バッファにストアする。 このステップでは、2つのバッファ・コピーが生じる。

5: LineReader はダウンストリームからのデータを取り入れるために、内部バッファを保持する。 バッファから、ライン・セパレータが発見され、ライン・バイトが Text オブジェクトを形成するためにコピーされる。このステップでは、2つのバッファ・コピーが必要となる。

The Anatomy of Hadoop I/O Pipeline _1
The Anatomy of Hadoop I/O Pipeline _2
The Anatomy of Hadoop I/O Pipeline _3
The Anatomy of Hadoop I/O Pipeline _4
The Anatomy of Hadoop I/O Pipeline _5

%d bloggers like this: