Google Apps 対 Office Web Apps

ZDNet の特集

Google Apps vs. Office Web Apps
Can Microsoft compete in the cloud?
September 22nd, 2009

http://blogs.zdnet.com/BTL/?p=24614&tag=nl.e539

先ほど入ってきた ZDNet のメルマガで、面白そうな記事が紹介されていました。Google Apps vs. Office Web Apps というタイトルで、あくまでも現時点での、、、という前提で、両者を比較しています。

2ページ目には、上記のような比較表もあります。ZDNet のページにいくと、もっとたくさんの項目を見ることが可能です。 それと、文中の Gallery というリンクからは、以下のようなページにもいけます。

 http://content.zdnet.com/2346-12355_22-344688.html

双方の、特徴的な画面イメージが参照できますよ。

PHP のクラウド API とオープンソース

Information Week、All About Microsoft、eWeek でのとりあつかい

PHP スクリプティング言語サプライヤーである Zend が提示した、Simple API に関するオープンソース･プロジェクトに、IBM と Microsoft、Nirvanix、Rackspace、GoGrid がサインしたとのことです。 ただし、Amazon と Google のサインはマダとのことです。Open Cloud マニフェストのときのようにならないと良いですね。以下に、3誌でのとりあつかいをコピーしておきますが、それぞれ出だしの部分だけなので、詳しくは本文を参照してください。 －－－ A.C.

http://www.simplecloud.org/

Information Week : IBM, Microsoft Back Zend Open Cloud API

Posted by Charles Babcock @ 01:15 EDT | Sep 22, 2009

Zend Technologies’ Simple API project provides a common API set from which developers may call application services.

A group of prominent cloud vendors has banded together behind an open source project that promises to make application services available across clouds. Zend Technologies, the supplier of the PHP scripting language, launched the Simple API project Tuesday, and IBM and Microsoft were among the first vendors to sign on.

"We’re very excited to participate. This is a very important effort," said Vijay Rajagopalan, principal architect for Microsoft’s interoperability strategy team, in an interview. Microsoft will supply the project with a PHP software development kit for its Azure cloud, which is due to become operative in the second half of November.

Simple API will seek to counteract the tendency of each cloud to have some proprietary parts, making it difficult for an application to work with services in more than one cloud at a time.

From <http://www.informationweek.com/cloud-computing/article/showArticle.jhtml;jsessionid=H3FSO4DG5VQLXQE1GHPCKHWATMY32JVN?articleID=220100547>

All About Microsoft : Zend, Microsoft, IBM join forces to simplify cloud-app devlopment for PHP coders

September 22nd, 2009

Posted by Mary Jo Foley @ 11:54 am

Zend Technologies and a number of its partners — including Microsoft — unveiled on September 22 another cloud-interop intiative. This one is aimed at developers who are writing new cloud-centric apps in PHP.

All the right buzzwords are part of the newly unveiled Simple API for Cloud Application Services. It’s an open-source initiative that currently includes Zend, Microsoft, IBM, Nirvanix, Rackspace and GoGrid as the founding members. (No Google and no Amazon, however.) It’s all about interoperability and community and dialogue.

From <http://blogs.zdnet.com/microsoft/?p=4031>

eWeek：Zend Teams With Microsoft and IBM on Open Source Cloud Project

By: Darryl K. Taft

2009-09-22

Zend Technologies, in association with IBM, Microsoft and others, has launched the Simple API for Cloud Application Services project, a new open source initiative that enables developers to use common application services in the cloud, while enabling them to unlock value-added features available from individual providers.

Zend officials said the Simple Cloud API project aims to facilitate the development of cloud applications that can access services on all major cloud platforms. Zend, IBM, Microsoft, Nirvanix, Rackspace and GoGrid are co-founding contributors to this community project. However, cloud giants such as Amazon and Google are not.

The Simple Cloud API project empowers developers to use one interface to interact with a variety of cloud application services, enabling them to more easily access new technologies from cloud vendors, said Dirk Nicol, director of emerging technology in IBM’s Software Group.

From <http://www.eweek.com/c/a/Cloud-Computing/Zend-Teams-With-Microsoft-and-IBM-on-Open-Source-Cloud-Project-693753/>

 

The Anatomy of Hadoop I/O Pipeline _3

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

Optimizing Input Pipeline

Adding everything up, including a "copy" for decompressing bytes, the whole read pipeline involves seven buffer-copies to deliver a record to MapTask’s map() function since data are received in the process’s kernel buffer. There are a couple of things that could be improved in the above process:

バイト列を解凍するための ”Copy” も含めて、すべてを合算すると、データがプロセスのカーネル･バッファに受信されてから、MapTask の map () 関数にレコードを受け渡すまでに、Read パイプラインの全体で７つのバッファ･コピーを伴うことになる。 上記のプロセスにおいて、改善が可能な２つのものがある：

• Many buffer-copies are needed simply to convert between direct buffer and byte[] buffer.
• Checksum calculation can be done in bulk instead of one chunk at a time.

大量のバッファ･コピーが、ダイレクト･バッファと byte[] バッファ間での、シンプルな変換を必要とする。

チェックサムの計算は、チャンクごとではなく、バルクでの一括処理が可能である。

Figure 2: Optimizing input pipeline.

Figure 2 shows the post-optimization view where the total number of buffer copies is reduced from seven to three:

Figure 2 が示すのは、バッファ･コピーの回数を 7回から 3回に減らす場合の、ポスト・オプティマイゼーションの様子である：

1. An input packet is decomposed into the checksum part and the data part, which are scattered into two direct buffers: an internal one for checksum bytes, and the direct buffer owned by the decompression layer to hold compressed bytes. The FSInputChecker accesses both buffers directly.
2. The decompression layer deflates the uncompressed bytes to a direct buffer owned by the LineReader.
3. LineReader scans the bytes in the direct buffer, finds the line separators from the buffer, and constructs Text objects.

1: 入力パケットは、チェックサム･バイトのためのインターなものと、圧縮されたバイト列を保持する解凍レイヤが管理するダイレクト･バッファで構成される、2つのダイレクト･バッファの中で、チェックサム部分とデータ部分に分解される。 FSInputChecker は、双方のバッファに対して、ダイレクトにアクセスする。

2: この解凍レイヤは、LineReader が管理するダイレクト･バッファへ向けて、圧縮されていないバイト列を収縮させる。

3: LineReader は、ダイレクト･バッファ内のバイト列をスキャンし、バッファからライン･セパレータを探し出し、Text オブジェクトを構成する。

 

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

司馬遼太郎的クラウド観_1

クラウドは文化ではなく文明である

司馬遼太郎の作品の中に、アメリカ素描というエッセイがあります。日本や中国、そしてモンゴルについて書かれた作品は多々ありますが、おそらく、アメリカを書いたものとしては、唯一のものではないかと思います。

この本で司馬は、風習や集落の以前に、法から始まった唯一の国家が、アメリカであると定義しています。つまり、文化ではなく、文明からスタートしている実験国家が、アメリカであると言っているのです。

なにやら、オンプレミスとクラウドの対比に似ていると思い出し、以前に読んだ本を引っ張り出し、再読している最中なのですが、そこから以下のくだりをご紹介したいと思います。

ここで定義を設けておきたい。文明は「誰もが参加できる普遍的なもの、合理的なもの、機能的なもの」をさすのに対し、文化はむしろ不合理なものであり、特定の集団（たとえば民族）においてのみ通用する特殊なもので、他に及ぼしがたい。つまりは普遍的でない。

たとえば、青信号で人や車は進み、赤信号で停止する、この取り決めは世界に及ぼしうるし、げんに及んでいる。普遍的という意味で交通信号は文明である。逆に文化とは、日本で言うと、婦人がふすまをあけるとき、両ひざをつき、両手であけるようなものである。立ってあけてもいい、という合理主義はここでは、成立しえない。不合理さこそ文化の発光物質なのである。同時に文化であるために美しく感じられ、その美しさが来客に秩序についての安堵感をあたえ、自分自身にも、魚巣に住む魚のような安堵感をもたらす。ただし、スリランカの住宅にもちこむわけにはいかない。だからこそ文化であるといえる。

ーーー アメリカ素描：司馬遼太郎(著)：新潮文庫

なにやら、霞ヶ関クラウドというものが、どのようなものになるのかと、とても気になってしまう論旨です。やはり、黒船が着てくれないと、日本のクラウドは始まらないのでしょうか？

司馬遼太郎的クラウド観_1
司馬遼太郎的クラウド観_2
司馬遼太郎的クラウド観_3
司馬遼太郎的クラウド観_4

＜関連＞
個人情報と日米欧
海外 Internet 速度テスト

The Anatomy of Hadoop I/O Pipeline _4

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

Writing Outputs

Now let’s shift gears and look at the write-side of the story. Figure 3 illustrates the I/O pipeline when a ReduceTask writes line records into a gzipped text file using TextOutputFormat. Similar to Figure 1, each data transfer is tagged with the numeric step where the transfer occurs:

ここで視点を変えて、Write 側からのストーリーを追いかけていく。 Figure 3 が示すのは、ReduceTask が TextOutputFormat を用いて、gzip されたテキスト･ファイルにライン･レコードを書き込む様子である。 Figure 1 のように、それぞれのデータ転送について、そのステップ順を示すタグを付けている：

 Figure 3: Writing line records into gzipped text files.

1. TextOutputFormat’s RecordWriter is unbuffered. When a user emits a line record, the bytes of the Text object are copied straight into a 64KB direct buffer owned by the compression layer. For a very long line, it will be copied to this buffer 64KB at a time for multiple times.
2. Every time the compression layer receives a line (or part of a very long line), the native compression code is called, and compressed bytes are stored into another 64KB direct buffer. Data are then copied from that direct buffer to an internal byte[] buffer owned by the compression layer before pushing down to the DFSClient layer because the DFSClient layer only accepts byte[] buffer as input. The size of this buffer is again controlled by configuration property "io.file.buffer.size". This step involves two buffer-copies.
3. FSOutputSummer calculates the CRC32 checksum from the byte[] buffer from the compression layer, and deposits both data bytes and checksum bytes into a byte[] buffer in a Packet object. Again, checksum calculation must be done on whole 512B chunks, and an internal 512B byte[] buffer is used to hold partial chunks that may result from compressed data not aligned with chunk boundaries. Checksums are first calculated and stored in a 4B byte[] buffer before being copied to the packet. This step involves one buffer-copy.
4. When a packet is full, the packet is pushed to a queue whose length is limited to 80. The size of the packet is controlled by configuration property "dfs.write.packet.size" and is default to 64KB. This step involves no buffer-copy.
5. A DataStreamer thread waits on the queue and sends the packet to the socket whenever it receives one. The socket is wrapped with a BufferedOutputStream. But the byte[] buffer is very small (no more than 512B) and it is usually bypassed. The data, however, still needs to be copied to a temporary direct buffer owned by JDK code. This step requires two data copies.
6. Data are sent from the ReduceTask’s kernel buffer to the DataNode’s kernel buffer. Before the data are stored in Block files and checksum files, there are a few buffer-copies in DataNode side. Unlike the case of DFS read, both file data and checksum data will traverse out of kernel, and into JVM land. The details of this process are beyond the discussion here and are not shown in the figure.

1: TextOutputFormat の RecordWriter はバッファリングされていない。 ユーザーがライン･レコードを発行するとき、Text オブジェクトのバイト列は、圧縮レイヤが管理する 64KB ダイレクト･バッファ内に、そのままコピーされる。きわめて長いラインの場合には、何回かに分けて、64KB ずつバッファにコピーされるだろう。

2: 圧縮レイヤがライン（あるいは長いラインの一部）を受信するときには必ず、ネイティブの圧縮コードがコールされ、そして、圧縮されたバイト列は別の 64KB ダイレクト･バッファにストアされる。 DFSClient レイヤは、byte [] バッファを単なる入力として受け入れるため、データが DFSClient レイヤにプッシュされる前に、圧縮レイヤが管理する内部の byte [] バッファへ向けたコピーが実行される。 このバッファのサイズは、コンフィグレーション･プロパティである "io.file.buffer.size" により制御される。このステップは、２つのバッファコピーを伴う。

3: FSOutputSummer は、圧縮レイヤから得られる byte [] バッファに基づいてCRC32 チェックサムを計算し、また、チェックサム･バイトとデータ･バイトの双方を Packet オブジェクト内の byte [] バッファに蓄積する。 チェックサム計算を、512B チャンク全体に対して再実施しななくてはならない。そして、チャンクの境界線が不揃いな圧縮データに起因するかもしれない、部分的なチャンクを保持するために、内部の 512B byte [] バッファが使用される。 チェックサムが最初に計算され、パケットにコピーされる前に、4B byte [] バッファにストアされる。 このステップで、１つのバッファ･コピーが生じる。

4: パケットがあふれるときには、長さが 80 に制限されたキューに、パケット自体がプッシュされる。 パケット･サイズはコンフィグレーション･プロパティ "dfs.write.packet.size” により制御されるが、そのデフォルトは 64KB となる。このステップは、バッファコピーを伴わない。

5: DataStreamer スレッドは対象となるキューの支配下にあり、何らかのデータを受信するときには必ず、ソケットへ向けてパケットを送信する。 このソケットは、BufferedOutputStream に取り込まれている。しかし、byte [] バッファはきわめて小さいため（512B 以上にはならない）、通常ではバイパスされる。 ただ、JDK コードによるい管理されるテンポラリなダイレクト･バッファに、データをコピーする必要が依然として残っている。 このステップでは、２つのデータ･コピーが必要となる。

6: ReduceTask のカーネル･バッファから DataNode のカーネル･バッファまで、データは送信される。 データが Block ファイルとチェックサム･ファイルにストアされる前に、 DataNode サイドで何回かのバッファ･コピーが行われる。 DFS Read のケースとは異なり、ファイル･データとチェックサム･データの双方が、カーネルを横断してJVM にたどり着く。 そのプロセスの詳細については、この図に示していない。

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