Agile Cat — in the cloud

Hadoop 2 がリリースされた : MapReduce から YARN へ移行

Posted in .Selected, Apache, Big Data, Google, Hadoop, MapReduce by Agile Cat on October 17, 2013

Apache Software Foundation unveils Hadoop 2, replacing MapReduce with YARN

Loek Essers, IDG News Service @loekessers – Oct 16, 2013


The Apache Software Foundation unveiled its latest release of its open source data processing program, Hadoop 2. It runs multiple applications simultaneously to enable users to quickly and efficiently leverage data in multiple ways at supercomputing speed, Apache said Wednesday.

Apache Software Foundation が、そのオープンソース・データ処理プログラムである、Hadoop 2 の最新リリースを発表した。水曜日の Apache の説明によると、マルチ・アプリケーションの同時実行が達成されることで、ユーザーは各種の方式を用いて、しかもスーパー・コンピューターの速度で、そのデータを迅速かつ効率よく活用できるようになる。

Apache Hadoop is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It enables organizations to more efficiently and cost-effectively store, process, manage and analyze the growing volumes of data being created and collected every day.

Apache Hadoop は、シンプルなプログラミング·モデルを用いて、しかもコンピュータやクラスタを横断するかたちで、大規模データの分散処理を実現するフレームワークである。それにより、毎日のようにデータを収集/作成していく組織は、増え続ける情報の保存/処理/管理/分析を、効率よく低コストで達成していける。

Hadoop is deployed at enterprise organizations around the globe, including Amazon Web Services, AOL, Apple, eBay, Facebook, Netflix and Hewlett-Packard.

現時点において Hadoop は、Amazon Web Services/AOL/Apple/eBay/Facebook/Netflix/Hewlett-Packard といった、世界中のエンタープライズに展開されている。

The latest version of the platform, released Wednesday, has been more than four years in the making and has a number of new components. Most notable is the addition of YARN, (Yet Another Resource Negotiator), which is a successor to Hadoop’s MapReduce. The new version splits major functions into two separate daemons, with resource management in one, and job scheduling and monitoring in the other.

水曜日にリリースされた、このプラットフォームの最新バージョンは、その製作に 4年以上の歳月をかけ、また、いくつかの新しいコンポーネントを取り込むものとなる。その中でも、最も注目すべきは、Hadoop における MapReduce の後継者となる YARN(Yet Another Resource Negotiator)である。この新バージョンでは、主要な機能を、2つの Deamon に分割している。その 1つは、Resource Management であり、もう 1つは Job Scheduling and Monitoring となる。

Apache Software Foundation

YARN sits on top of the HDFS (Hadoop Distributed File System) and serves as a large-scale, distributed operating system for big data applications, enabling multiple applications to run simultaneously for more efficient support of data throughout its entire lifecycle, Apache said in a news release. Hadoop 2 and YARN gives users the ability to mix batch, interactive and real-time workloads within a stable foundational part of the Hadoop ecosystem, it said.

YARN は HDFS(Hadoop Distributed File System)の上に配置され、Big Data アプリケーションのための、大規模/分散オペレーティング・システムとして機能する。 それにより、ライフサイクル全体を通して、データを効率よくサポートとしていく、マルチ・アプリケーションの同時実行が可能となると、Apache はニュース・リリースで述べている。 そして、Hadoop 2 と YARN がユーザーに提供するものとして、バッチ/インタラクティブ/リアルタイムのワークロードなどを混在させる能力を、Hadoop エコシステムの安定した基盤を用いて実現することを挙げている。

Apache also refers to YARN as MapReduce Version 2. It retains API compatibility with the previous version, and applications written for MapReduce will run on YARN if recompiled, the foundation said.

また、Apache は YARN について、MapReduce の Version 2 だとしている。 つまり、これまでのバージョンとの API 互換を保持し、再コンパイルさえすれば、MapReduce 用のアプリケーションを YARN 上で実行できると、同ファンデーションは述べている。

More than a dozen Apache projects integrate with Hadoop, and ten more are about to follow, Apache said.

1ダース以上の Apache プロジェクトが Hadoop と統合されているが、その大半が、新たなプラットフォームに移行すると、Apache は述べている。

The General Availability (GA) release of Hadoop 2 follows a preview distribution that was released in June, that also included YARN. Apache Hadoop 2 will be released under the Apache License v2.0.

Hadoop 2 の General Availability (GA) リリースは、6月にリリースされたプレビューに、つまり YARN が含まれていたディストリビューションに従うものとなる。なお、Apache Hadoop 2 は、Apache License v2.0 の下でリリースされる。


image Hadoop に関するポストというと、かなり久々のことなのですが、当然のものとして、広く浸透していることの、証明なのかもしれません。 昨年の、Apple Maps 騒動のときに、Wired が 面白い記事をポストしていました。 そこには ーーー このバトルの背景は、たった 2つの言葉で説明できる。 つまり、Google は Big Data を使いこなし、その一方で Apple は、Big Data を急いで準備している段階にある。ーーー という、とても分かりやすい一文が記されていました。そして、Hadoop も、ついに新世代なのですね。 ほんと、期待大です!image



IDC:データ分析市場は、2016年までに $51 B ビジネスに成長する
Facebook と Hadoop : どのように 100 Peta Byte ハンドリングするのか?
Facebook にストアされた 100 PB イメージ・データは、写真にすると 6,660 億枚になる!
ついに、Hadoop for Windows がデビューするらしい
Hadoop 王国は、戦国時代へと 突入する?


Google Maps は Big Data を使いこなすが、Apple Maps には それが出来ない

Posted in .Selected, Apple, Big Data, Google, Hadoop, MapReduce by Agile Cat on October 23, 2012

Apple’s ‘Mapocalypse’ Highlights Big Data Battle
October 3, 2012 –
Mike Barton


The new Maps feature in Apple’s iOS 6 (launched with iPhone 5) has caused Apple a headache, and even led to its CEO apologizing. But more important than Apple’s ego is what the “mapocalypse” means in its bigger battle with Google and its Android platform. Forbes’ Dave Einstein writes in “Google vs. Apple Maps: Big-Data Battle, Cloudy Clash”:

Apple の iOS 6 における、新しい Maps 機能(iPhone 5で導入された)は同社にとって頭痛のタネとなり、また、CEO が謝罪するという事態をもたらした。 しかし Apple にとって、自身のエゴよりも重要なことは、この Mapocalypse が意味するものが、Google および Android プラットフォームとのバトルだという点だ。Forbes の Dave Einstein は、“Google vs. Apple Maps: Big-Data Battle, Cloudy Clash” で、以下のように書いている:

The battleground can be described in just two words: Big Data. Google has it; Apple is scrambling to catch up.

このバトルの背景は、たった 2つの言葉で説明できる。 つまり、Google は Big Data を使いこなし、その一方で Apple は、Big Data を急いで準備している段階にある。

G’day, North America! One example of the iOS 6 “mapocalypse.” Source:

And it’s not just Maps, Einstein writes:

Einstein は、マップ以外についても、以下のように記述している:

Apple would seem to have the edge, but the more consumers use Siri, the more they may realize it’s a work in progress. Like Maps, it’s even being made fun of on TV. Android, meanwhile, has proven remarkably accurate at recognizing human speech and returning accurate answers.

Again, it’s all about Big Data. Speech recognition used to be a novelty for consumers, something to be used if you had Carpal Tunnel or another ailment that made it hard to use a computer.

…Google’s game changer used massive databases to store everything users said while voice-searching on their Android phones. Suddenly speech recognition became a data-driven, cloud service that trained itself. It compared the speech patterns of millions of users, correlated with the content and context of search queries.

Apple は、競争力を持っているように思われるだろうが、そして、多くのユーザーが Siri を使っているだろうが、それが開発途上にあることを知っているのかもしれない。 Maps と同様に、テレビでからかわれさえしている。 その一方で Android は、人間のj話し言葉を認識して、答えを返すことにおいて、驚くほど正確であると証明されている。

繰り返すが、それらすべてが、Big Data に関連する。 これまでの音声認識は、消費者に対するノベルティの類のものであり、もし Carpal Tunnel(手根管症候群)などの病気で、コンピュータを使うことが困難になったときに、使われる何かであった。

しかし、ゲーム・チェンジャーである Google は、Android Phone を使った音声検索の間に、ユザーが発するすべての言葉を、大規模なデータベースにストアするという手法を用いている。 突然に、音声認識がデータ駆動型になり、そのクラウド・サービスは、自身を洗練させ続ける。そこでは、何百万人というユーザのスピーチ・パターンが比較され、サーチ・クエリーの内容と脈略に関連づけられる。

Einstein writes: “Google’s advantage over Apple could easily continue to grow, because much of its product development ties right back into geo-location. From self-driving cars that know where they are to ‘augmented reality’ glasses right out of Philip K. Dick, the company is developing services based on location to help them improve things like Google Maps and Voice Search.”

さらに Einstein は、『 Apple に対する Google のアドバンテージは、そのプロダクト開発の大半が、ゲオ・ロケーションと緊密に結び付けられるため、容易に拡張し続けることが可能だ。 Philip K. Dick の小説にあるように、自身の位置を確認しながら自動操縦するクルマから、「複合現実感」のメガネにいたるまで、Google が開発するサービスは、自らを洗練させるためにロケーションをベースにする。そして、それは、Google Maps も、Voice Search も、同じことなのだ 』と記している

Google’s Android is the most popular mobile OS and growing like crazy, and you know the story online (read: big data collection in overdrive). This gives the company a growing jump on Apple.

Google の Android は、最も人気の高いモバイル OS であり、また、猛烈な勢いで成長している。そして、あなたはオンラインで、そのストーリーを探せる( 加速している Big Data での記事を読んでほしい)。 それにより、Google は Apple を飛び越せる。

Weigh in: Is Google’s cloud advantage playing out now with Maps and speech recognition? Is this jump on Big Data something Apple and others can ever match? Will Apple and others be forced to accept Google’s Big Data advantage and use Google tools such as Maps?

Weigh in:  Google Cloud のアドバンテージは、いまのところ、Maps と音声認識で展開しているのか? この、Big Data(のようなもの)へのジャンプにおいて、Apple などは、そもそも対抗できるのか? Apple などは、Google における Big Data のアドバンテージを受け入れ、また、Maps のような Google ツールを使うことを強いられるのか?


imageいまの IT 業界に、イノベーション Big Four を見出すとしたら、Amazon/Apple/Facebook/Google なのだろうと思います。 そして、いわゆる Big Data で遅れを取っているのが Apple であり、それが Apple Maps で問題を起こしているというのは、とても興味深く、また、納得しやすい論点ですね。 image



IDC:データ分析市場は、2016年までに $51 B ビジネスに成長する
Hadoop 王国は、戦国時代へと 突入する?
Facebook と Hadoop : どのように 100 Peta Byte ハンドリングするのか?
Twitter が提供する、MySQL 関連のオープンソースとは
Microsoft が発表した、OSS ベースのクラウド・サービスとは?

Big Data を 美味しくいただくための、クッキング・ブックを作ろう

Posted in Big Data, Hadoop, MapReduce, NoSQL by Agile Cat on March 9, 2011

The Big Data Cookbook
Posted in
Main on March 8th, 2011
by Pingdom 

_ pingdom

Big data has become one the new buzzwords on the Internet. It refers to the massive amounts of data that many modern web services deal with. This post will list some of the more useful software available to web developers for working with big data.

Big data は、インターネット上の新しいバズワードになっている。 この用語は、数多くのモダンな Web サービスが取り扱う、大規模なデータのことを指す。 そして、このポストでは、ビッグ・データの分野で働くWeb デベロッパーにとって有益な、いくつかのソフトウェアをリストアップしていく。


You don’t have to operate at the scale of Google or Facebook to enter into big data territory. Web analytics services, monitoring services (like our very own Pingdom), search engines, etc., all process and store massive amounts of data.

ただし、この領域に参加するからといって、Google や Facebook のスケールを考える必要はない。 そこまでいかなくても、Web 分析サービスおよび、モニタリング・サービス(Pingdom など)、サーチ・エンジンなどの全てが、大量データの処理と保存に対応している。

To quote Wikipedia (Wikipedia からの引用):

Big data are datasets that grow so large that they become awkward to work with using on-hand database management tools. […] Though a moving target, current limits are on the order of terabytes, exabytes and zettabytes of data.

Big data ビッグ・データは、成長が著しいデータセットであるため、手製のデータベース・マネージメント・ツールを用いた作業は厄介になってしまう。 [中略]その上限が定まっているわけではないが、現時点におけるデータの限度は、テラバイト/エクサバイト/ゼッタバイトの並びの上にある(つまり、ペタということ?)。

At this scale, many traditional approaches for handling and processing data are either impractical or break down completely.


That’s why the web development community has been turning to alternative ways to handle all this data, developing new software that scales to these extremes. You may have heard about NoSQL databases, but that’s just a small piece of the puzzle.

そこに、Web 開発のコミュニティが、それら全てのデータを取り扱うための、代替案を探し求めてきた理由がある。つまり、それらを大幅にスケールするソフトウェアの開発である。 NoSQL データベースの情報を持っていると思うが、それはパズルにおける小さい小片である。

So what are the various ingredients available for handling big data? We’ve divided them into four categories:

そして、このビッグデータを取り扱うために利用できる、各種の構成要素とは、何なのだろう?私たちは、それを を4つのカテゴリに分けてみた:

  • Storage and file systems
  • Databases
  • Querying and data analysis
  • Streaming and event processing

We figured this could be a good starting point, and we’re hoping that you’ll help us add to the list in this post by making your own suggestions in the comments. In other words, read the list, and help us add more useful ingredients!


ーーーーー とりあえず、訳はココまで ーーーーー

Here we go…

Storage and file systems

When you need to store massive amounts of data, you’ll want a storage solution designed to scale out on multiple servers.

  • HDFS (Hadoop Distributed File System) – Part of the open source Hadoop framework, HDFS is a distributed, scalable file system inspired by the Google File System. It runs on top of the file system of the underlying OSs and is designed to scale to petabytes of storage. The Hadoop project (you’ll see several of the other components further down) has several high-profile contributors, the main one being Yahoo. Hadoop is used by Yahoo, AOL, eBay, Facebook, IBM, Meebo, Twitter and a large number of other companies and services.
  • CloudStore (KFS) – An open source implementation of the Google File System from Kosmix. It can be used together with Hadoop and Hypertable. A well-known CloudStore user and contributor is Quantcast.
  • GlusterFS – A free, scalable, distributed file system developed by Gluster

While classics like MySQL are still widely used, there are other options out there that have been designed with “web scalability” in mind, many of them so-called NoSQL databases (speaking of buzzwords…).

  • HBase – A distributed, fault-tolerant database modeled after Google’s BigTable. It’s part of the Apache Hadoop project, and runs on top of HDFS.
  • Hypertable – An open source database inspired by Google’s BigTable. A notable Hypertable user is Baidu.
  • Cassandra – A distributed key-value database originally developed by Facebook, released as open source, and now run under the Apache umbrella. Cassandra is used by Facebook, Digg, Reddit, Twitter and Rackspace, to name a few.
  • MongoDB – An open source, scalable, high-performance, document-oriented database. It’s used by, among others, Foursquare,, Shutterfly, Etsy and Chartbeat.
  • Membase – An open source, distributed, key-value database optimized for interactive web applications, developed by several team members from the famous Memcached project. Users include Zynga and Heroku. A month ago, the Membase project merged with CouchDB, creating a new project called Couchbase.
Querying and data analysis

All that data is of no use without the ability to access, process and analyze it.

  • Hadoop MapReduce – Open source version of Google’s MapReduce framework for distributed processing of large datasets.
  • Hive – An open source data warehouse infrastructure with tools for querying and analyzing large datasets in Hadoop. Supports an SQL-like query language called Hive QL.
  • Pig – A high-level language used for processing data with Hadoop. Funny aside: the language is sometimes referred to as Pig Latin.
Streaming and event processing

When you have massive amounts of data flowing into your system, you will often want to process and react on this data in real time.

  • S4 – A general-purpose, distributed, scalable platform for processing continuous streams of data. Developed by Yahoo and released as open source in 2010. It’s apparently not quite ready for prime time yet, although Yahoo is using a version of it internally.
  • Esper – An event-processing platform from EsperTech for handling continuous streams of incoming data.
  • StreamInsight – Microsoft’s entry in the EST/CEP field, included with SQL Server.

A small aside when speaking of streaming and event processing, you’ll hear two industry terms repeated over and over again: EST, Event Stream Processing, and CEP, Complex Event Processing. Just in case you were wondering what that actually stood for.

The Google legacy

It’s interesting how influential Google has been in the big data field in spite of having released very little actual software to the public.

Much of the open source big data movement is centered around Apache’s Hadoop project, which essentially has tried to replicate Google’s internal software based on the various whitepapers Google has made available. (More specifically, Hadoop has replicated GFS, BigTable and Mapreduce.)

Here is a list of some of Google’s proprietary software relating to big data:

  • GFS (Google File System) – Google’s scalable, fault-tolerant, distributed file system. Designed from scratch for use with data-intensive applications.
  • BigTable – A distributed, high-performance database system built on top of GFS.
  • Mapreduce – A framework for distributed processing of very large data sets.
  • Pregel – A framework for analyzing large-scale graphs with billions of nodes.
  • Dremel – Meant as a faster complement to Mapreduce, Dremel is a scalable, interactive, ad-hoc query system for large data sets. According to Google, it’s capable of running aggregation queries over trillion-row tables in seconds and scales to thousands of CPUs.

If we may be so bold as to bring out our crystal ball, there will most likely be several open source implementations of Pregel and Dremel available soon. For example, there’s already an OpenDremel project in the works.

Help us add more ingredients!

What excellent big data software did we leave out? Let’s make this post a true resource, so please give us a hand in the comments.


なかなか面白い試みで、さすがは Pingdom です。 それと、Google legacy というカテゴリがユニークですが、さまざまな基盤を提供してくれて有難うと、言いたくなる実績ですね! では コメント欄から、ご意見など、ぜひ ど~ぞ! ーーー __AC Stamp 2


Mollom アーキテクチャは、毎秒 100回のリクエストを発行し、3億 7300万のスパムを退治する
プロジェクト Piccolo は、スピードで Hadoop を凌駕する
Real World NoSQL シリーズ – Netflix における Amazon SimpleDB
Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase
Google の発想 – リクエストとレスポンスを Tree で制御する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!

Google – Cluster Computing and MapReduce Lecture 1-5

Posted in Big Data, Google, MapReduce by Agile Cat on November 5, 2010

いまさらながら、2007年のビデオですが ・・・

以前に見つけていた Youtube なのですが、ようやく全巻の所在をつかみましたので、まとめてポストします。 講師を務める Aaron Kimball さんは、たしか昨年に Cloudera へ移籍していましたね。 このレクチャーは、全部で 4時間くらいあり、その内容については、とてもではありませんが、Agile_Cat ごときが説明できるものではありませんので、チャレンジ精神の旺盛な方に、ぜひともトライしていただきたいと思っています。






Sawzall もオープン化されたことですし、この週末にお勉強をという方に、お勧めいたします。 ーーー A.C.


実行中にノードを追加できる、新しい Elastic MapReduce とは?
MapReduce と Hadoop の将来について
Google Instant では、リアルタイム検索のために MapReduce を排除!

実行中にノードを追加できる、新しい Elastic MapReduce とは?

Posted in Amazon, Big Data, Hadoop, MapReduce by Agile Cat on October 26, 2010

Amazon Elastic MapReduce – Now Even Stretchier!


Our customers have used Amazon Elastic MapReduce to process very large-scale data sets using an array of Amazon EC2 instances. One such customer, Seattle’s Razorfish, was able to side-step the need for a capital investment of over $500K while also speeding up their daily processing cycle (read more in our Razorfish case study).

私たちのカスタマーは、大量の Amazon EC2 インスタンスを用いた、大規模スケールのデータセットを処理するために、Amazon Elastic MapReduce を活用している。 そのようなカスタマーである Seattle の Razorfish は、日々の処理サイクルをスピードアップする一方で、必要とされる $500 K 以上の資本投資を回避した(詳細については Razorfish のケーススタディを参照)。


Our implementation makes it easy for you to create and run a complex multi-stage job flow composed of multiple job steps. Until now, the same number of EC2 instances (known as slave nodes in Hadoop terminology) would be used for each step in the flow. Going forward, you now have more control over the number of instances in the job flow:

これらの、私たちが実装した環境では、マルチ・ジョブ・ステップで構成された、複雑なマルチ・ジョブ・フローの生成/実行が容易になる。これまで、同量の EC2 インスタンスが(Hadoop 用語で Slave Nodes)、対象となるフローにおける個々のステップのために使われていたはずだ。それをさらに推し進めて、ジョブ・フローにおけるインスタンス数に対して、より以上の管理機能を提供するようになった:

  • You can add nodes to a running job flow to speed it up. This is similar to throwing more logs on a fire or calling down to the engine room with a request for "more power!" Of course, you can also remove nodes from a running job.
  • A special "resize" step can be used to change the number of nodes between steps in a flow. This allows you to tune your overall job to make sure that it runs as quickly and as cost-efficiently as possible.
  • As a really nice side effect of being able to add nodes to a running job, Elastic MapReduce will now automatically provision new slave nodes in the event that an existing one fails.
  • 処理速度を向上させるために、実行中のジョブ・フローにノードを追加できる。つまり、暖炉の火に薪を投げ込んだり、エンジン・ルームへ向けて 『 More Power! 』と叫ぶようなものだ。 もちろん、実行中のジョブから、ノードを取り除くことも可能だ。
  • スペシャルな 『 Resize 』 ステップを、フローにおけるノード数の変更のために使用できる。 それにより、ユーザーの全体的な作業を、可能な限り高速/低コストで実行するための、チューニングが実現される。
  • 実行中のジョブにノードを加えることで、きわめて有益な副作用が生じる。 つまり、何らかのジョブが失敗する場合に、 Elastic MapReduce により自動的に、新しいスレーブ・ノードに供給されることになる。

You can initiate these changes using the Elastic MapReduce APIs, the command line tools, or the AWS SDK for Java. You can also monitor the overall size and status of each job from the AWS Management Console.

なお、Elastic MapReduce API API および、コマンドライン・ツール、AWS SDK for Java を用いて、これらの変更に取り掛かれる。 さらに、AWS Management Console を介して、それぞれのジョブのに関する全体的なサイズとステータスをモニターできる。

We’ve got a number of other enhancements to Elastic MapReduce in the works, so stay tuned to this blog.

私たちは他にも、多数の機能拡張を Elastic MapReduce に対して実施している途上にあるため、新しい情報が入り次第、このブログでお伝えしていく。


PS – Open positions on the Elastic MapReduce team: Software Development Engineer and Senior Product Manager.


最初は、なんで暖炉の写真なのだろうと思いましたが、ちゃんと本文に関連するのですね。  Google Instant が MapReduce から離れると、Amazon がさらに柔軟な Hadoop を提供し始めるというふうに、この世界にも興味深い出来事が続きますね。 EC2 上にハードウエア資産を持たない PaaS プロバイダーが登場すると、佐藤一郎先生が以前におっしゃっていましたが、同じく資産を持たないデータ・ウェアハウスも可能なのではと、想像を膨らましてしまいますね。 ーーー A.C.


MapReduce と Hadoop の将来について
Google Instant では、リアルタイム検索のために MapReduce を排除!
Hadoop World: Cloudera は Big Data Friends を得たが ・・・
HW2010 玉石混合ダダ漏れ Twitter もちろん英語
Hadoop World 2010 のアジェンダが発表 – Tim O’Reilly もキーノートに!
Hadoop ベンダーたちは、データに苦しむ銀行から利益を得られるのか?

MapReduce と Hadoop の将来について

Posted in Big Data, Hadoop, MapReduce by Agile Cat on October 10, 2010

MapReduce and Hadoop Future
by Alex Popescu
Oct 7th, 2010 3:16


In the light of ☞ Google Caffeine announcement — a summary of a summary would be that Google replaced MapReduce-based index updates with a new engine that would provide more timely updates — ☞ Tony Bain is wondering if Michael Stonebraker and DeWitt’ paper ☞ MapReduce: a major step backwards hasn’t thus been proved to be correct:

Google Caffeine のアナウンスメントを考慮に入れて(MapReduce ベースのインデックス更新を、よりタイムリーな更新を提供する新しいエンジンを、Google が置き換えたという一連の要約のこと)、Michael StonebrakerとDeWitt’の論文、”MapReduce:大きな後退”は従って正しいと証明されたことになっていないのかと、Tony Bainは考えている。

Firstly, was Stonebraker and Dewitt right? It is red faced time for those who came out and aggressively defended the Map/Reduce architecture?

第一に、 Stonebraker と Dewitt は正しかったのか? MapReduce アーキテクチャを広めて擁護した人たちが、恥じをかくときがきたのか?

And secondly what impact does this have on the future of Map/Reduce now those responsible for its popularity seem to have migrated their key use case? Is the proposition for Map/Reduce today still just as good now the Google don’t do it? (Yes I am sure Google still use Map/Reduce extensively and this is a bit tongue in cheek. But the primary quoted example relates to building the search index which is what, reportedly, has been moved away from MR).

第二に、このことが、MapReduceの将来にどのような影響を与えるのか? MapReduce が人気を博してきたことに、責任をもつべき人々が、そのキーとなるユースケースから移行してしまったかのように見える(つまり、Googleが検索インデックスから?この Map/Reduce に関する提言は、Google が使わない今でも、これまでと同様に有効なのだろうか? (Google は広範囲において、皮肉を込めて言えば、まだ MapReduce を使っていると確信している。 しかし、伝えられるところによれば、 主として引用されたサンプルは、MR から切り離されている検索インデックスの構築に関連する)。

While all these questions seem to be appropriate, I think some details could help with finding the correct answers.


Firstly, I think Google’s decission to “drop” MapReduce-based index updates was determined by their particular implementation and their storage strategy. Simply put, Google’s MapReduce-based index updates required reprocessing of data, so providing timely updates was more or less impossible. But as proved by CouchDB mapreduce implementation this approach is not the only one possible. CouchDB views are built as a result of running a pair of map and reduce functions and storing it in btrees. As for updates, CouchDB doesn’t need to reprocess all initial data and rebuild the index from scratch, but only apply changes from the updates. In this regard, Stonebraker seem to have been right when saying that it is “a sub-optimal implementation, in that it uses brute force instead of indexing”.

第一に、MapReduce ベースのインデックス更新を 『やめる』という Google の決定は、その実装とストレージ戦略に起因するものだと考える。シンプルに言えば、Google における MapReduce ベースのインデックス更新は、データの再処理を必要とする。 そのため、タイムリー( Instant)な更新を提供するが、いずれにせよ不可能だった。 しかし、CouchDB の Mapreduce 実装が証明するように、Google のアプローチだけが、唯一可能性を示すというものではない。CouchDB のビューは、Map と Reduce をペアとして実行した結果として、また BTree 内にストアするものとして構築される。CouchDB における更新は、すべてのイニシャル・データの再処理と、インデックスのゼロからの再構築を必要とせず、更新に基づいた変更だけを適用する。 この点に関して、『 インデックス処理に換えて、ちから技を用いるという点で、次善の実装である 』という、Stonebraker の発言は正しかったと思われる。

While Hadoop, the most well know mapreduce implementation, is following closely Google’s design, that doesn’t mean that there isn’t work done to improve its behavior for special scenarios like real-time stream processing, cascading, etc.

MapReduceの実装として最も広く認識されている Hadoop は、Googleの設計に良く従っている。しかし、たとえばリアルタイムにおけるストリーム・プロセッシングやカスケーディングなどの特別のシナリオのために、すでに Hadoop を改良する余地はないという意味ではない。

As regards the questions related to the impact of Google’s announcement on MapReduce adoption, I’d say that taking a look at the reports from the Hadoop Summit we all would agree that for quite some time the biggest proponents of MapReduce (in its Hadoop incarnation) have been Yahoo!, Facebook, Twitter, and other such companies. And, as I said it before, it sounds like Hadoop is actually processing more data than Google’s MapReduce .

Google による MapReduce の肯定的な容認の、影響をうけた論点として、この Hadoop Summit のレポート参照したい。それは、ずいぶんと以前から、MapReduce(化身としての Hadoop)における最大の提案者が、Yahoo! および、Facebook、Twitter などであると、私たち全てが同意していることである。 そして、以前から発言しているように、Google の MapReduce よりも Hadoop の方が、大量のデータを処理している印象がある。

Last, but not least, as with any NoSQL technology all these do not mean that MapReduce or Hadoop will fit all scenarios.

最後になるが、いかなる NoSQL テクノロジーの存在を考慮しても、その全てが意味していることがる。 つまり、MapReduce であっても、Hadoop であっても、すべてのシナリオにもフィットするわけではない

Original title and link: MapReduce Future (NoSQL databases © myNoSQL)

Reading List:

Google BigQuery SQL-like API
Howl: Unifying Metadata Layer for Hive and Pig
Pig: Making Hadoop Easy
Hadoop Tutorial Part 2: Getting Started with Partitioning
Hadoop: The Problem of Many Small Files
Hadoop and HBase Status Updates after Hadoop Summit
NoSQL Databases and The Unix Philosophy


Map/Reduce は、すでに Google のものというより Hadoop のものである。 それにより、これまで以上に広い範囲で、数多くのシステムに適用される ・・・ という論点なのだと思います。 大賛成! ーーー A.C.


Google Instant では、リアルタイム検索のために MapReduce を排除!
Big Data と LAMP Stack
Teradata と Cloudera が Hadoop で提携!
Cloudera と Netezza による、Hadoop の商用アプライアンスとは?
Microsoft readying Hadoop for Windows Azure の対訳
Hadoop World NYC – Oct 12 2010 – 今年の目玉は Twitter、Bank of America、AOL?

Google Instant では、リアルタイム検索のために MapReduce を排除!

Posted in .Selected, Big Data, Google, MapReduce by Agile Cat on September 13, 2010

Google’s Colossus Makes Search Real-time by Dumping MapReduce
Saturday, September 11, 2010 at 5:50AM


As the Kings of scaling, when Google changes its search infrastructure over to do something completely different, it’s news. In Google search index splits with MapReduce, an exclusive interview by Cade Metz with Eisar Lipkovitz, a senior director of engineering at Google, we learn a bit more of the secret scaling sauce behind Google Instant, Google’s new faster, real-time search system.

King of Scaling としての Google が、これまでとは全く異なることを行うために検索インフラストラクチャを変更すれば、それはニュースになる。 Google 検索インデックスは MapReduce により分散されるという、Google  エンジニアリング部門のシニア・ディレクタである Eisar Lipkovitz に対する、Cade Metz による独占インタビュー を読み解いていく。 そして、Google が提供する最速リアルタイム検索システムである、Google Instant の背景となる秘密のスケーリングについて、もう少し学んでいく。


The challenge for Google has been how to support a real-time world when the core of their search technology, the famous MapReduce, is batch oriented. Simple, they got rid of MapReduce. At least they got rid of MapReduce as the backbone for calculating search indexes. MapReduce still excels as a general query mechanism against masses of data, but real-time search requires a very specialized tool, and Google built one. Internally the successor to Google’s famed Google File System, was code named Colossus.

これまでの Google におけるチャレンジとは、コアとなる検索テクノロジーが、バッチ指向として有名な MapReduce であるのに、どのようにしてリアルタイムな世界をサポートすべきかという点にあった。 そしてシンプルに、Google は MapReduce を取り除いた。 少なくとも、検索インデックス計算というバックボーンとして  の MapReduce を取り除かれている。依然として、MapReduce は大量データに対する汎用クエリー・メカニズムとしては卓越した存在であるが、リアルタイム検索には完全に特化されたツールが必要であり、それを Google は構築した。その、有名な Google File System の後継者には、内部的に Colossus(巨像)というコードネームが付けられている。


Details are slowly coming out about their new goals and approach:


  • Goal is to update the search index continuously, within seconds of content changing, without rebuilding the entire index from scratch using MapReduce.
  • The new system is a “database-driven, Big Table–variety indexing system.”
  • When a page is crawled, changes are made incrementally to the web map stored in BigTable, using something like database triggers.
  • A compute framework executes code on top of BigTable.


  • そのゴールは、コンテントが更新される数秒の間に、連続的に検索インデックスをアップデートすることだが、MapReduce でスクラッチからインデック化することではない。
  • この新しいシステムは、”database-driven, Big Table–variety indexing system” である。
  • 何らかのページがクロールされるとき、データベース・トリガーのようなものを用いて、BigTable にストされた Web マップに対して、そこでの変更がインクリメントされる。
  • 計算のためのフレームワークは、BigTable のトップで’実行される。

The use of triggers is interesting because triggers are largely ignored in production systems. In a relational database triggers are integrity checks that are executed on a record every time a record is written. The idea is that if the data is checked for problems before it is written into the database, then your data will always be correct and the database can be a pure source of validated facts. For example, an account balance could be checked for a negative number. If the balance was negative then the write would fail, the transaction aborted, and the database would maintain a correct state.

トリガーを用いるという考え方が興味深いのは、大半のプロダクション・システムにおいて、それは無視される存在だからである。 リレーショナル・データベースにおけるトリガーとは、レコードが Write されるごとに、レコード上で実行される完全のチェックのことである。 この考え方とは、データベースへの書き込みの前に、データにおける問題がチェックされるなら、そのデータは常に正しくなり、また、そのデータベースは妥当性を検査された事実の、純粋なソースになり得るというものだ。 たとえば、アカウントのバランスにおいて、負数の存在をチェックできる。 もし、そのバランスが負であれば、書き込みは失敗し、トランザクションは中断され、データベースは正しい状態を維持するだろう。

In practice there are many problems with triggers:


  • Destroys performance. Since triggers happen on every write they slow down the write path to the extent that database performance is often killed. Triggers also take record locks which makes contention even worse.
  • Checking is distributed. Not all integrity checks can be made from data inside the database so checks that are database oriented are put in the triggers and checks, that say access a 3rd party system, are kept in application code. So now we have checks in multiple places, which leads to the update anomalies in code that ironically, relational databases are meant to prevent in data.
  • Checking logic is duplicated. Checking in the database is often too late. A user needs to know immediately when they are doing something wrong, they can’t wait until a transaction is committed to the database. So what ends up happening is checking code is duplicated, which again leads to update anomalies.
  • Not scalable. The database CPU becomes dedicated to running triggers instead of “real” database operations, which slows down the entire database.
  • Application logic moves into triggers. Application code tends to move into triggers over time since triggers happen on writes (changes), in a single common place, they are a very natural place to do all the things that need to be done to data. For example, it’s common to emit events about data changes and perform other change sensitive operations. It’s easy to imagine building secondary indexes from triggers and synchronizing to backup systems and other 3rd party systems. This makes the performance problems even worse. Instead of application code being executed in parallel on horizontally scalable nodes, it’s all centralized on the database server and the database becomes the bottleneck.


  • Destroys performance.トリガーはすべての書き込みおいて発生するため、データベース性能が頻繁に損なわれるという範囲において、その書き込み経路の速度を遅くする。 さらに、トリガーはレコードをロックするため、この論点を更に悪化させる。
  • Checking is distributed. すべての完全性に関するチェックが、データベース内のデータに基づいて、実現されるわけではない。したがって、データベース指向のチェックはトリガー内に取り込まれてチャックされるが、アプリケーション・コード内に保持されるサード・パーティ・システムにアクセスすることになる。そのため、多数の場所にチェックを持ることになるが、それは皮肉にも、リレーショナル・データベースが意図的に許可していない、コードにおけるアップデートの不整合へと導くことになる。
  • Checking logic is duplicated. 大半のケースにおいて、データベース内でのチェックは遅すぎる。それらが、問題を引き起こす何かを行っているとき、ユーザーは直ちに把握する必要がある。こうした問題は、トランザクションがデータベースにコミットされるのを、待つことができない。 したがって、複写されたコードを調べることになるが、前述のとおり、アップデートの不整合へと導いてしまう。
  • Not scalable. データベース CPU は、「本来」データベース操作ではなく、トリガーに占有されるため、データベース全体の速度が劣化する。
  • Application logic moves into triggers. 紆余曲折の後にアプリケーション・コードが、トリガー内部の共通の位置に取り込まれる傾向にあるのは、そこがデータに対して施すべき処理を、トリガーから実行もしくは記述(変更)するのに都合の良い場所だからだ。 たとえば、データの変更に関するイベントを発行し、それらの変更に対応するオペレーションを実行することなどが、一般的な用法である。トリガーに基づいて 2番目のインデックスを構築し、バックアップ・システムとサードパーティ・システムを同期指せる方式などが、容易に思いつくはずだ。それにより、パーフォーマンス的な問題が、さらに悪化していく。 ホリゾンタルにスケーリングされたノード上で、アプリケーションコードを並列に実行させる代わりに、データベース・サーバー上にセンタライズされる方式であるため、そのデータベースがボトルネックになる。

So, triggers tend not to be used in OLTP scenarios. Applications contain the same logic and it’s up to release policies and testing to make sure nothing falls through the cracks.

したがって、OLTP のシナリオでは、トリガーは使用されない傾向にある。 複数のアプリケーションが同じロジックを含むが、それらはリリース・ポリシーに依存するものになる。また、想定外の問題を起こさないようにするための、厄介なテストも必要になる。

This isn’t to say you don’t want to put logic in triggers, you do. Triggers are ideal in an event oriented world because the database is the one central place where changes are recorded. The key is to make triggers efficient.

これでは、トリガーにロジックを取り込まないと思うはずだし、現実に誰もが、それを行わない。 つまり、トリガーがイベント指向の世界で理想的になるのは、データベースが変更が記録される、センタライズされた場所にデータベースが置かれる場合となる。 そこでは、キーによりトリガーが効率化される。

It sounds like Google may have made a specialized database where triggers are efficient by design. We know hundreds of thousands of pages are being crawled simultaneously. When the pages are written to the database that’s the perfect opportunity perform calculations and updates. The compute framework would make it efficient to perform operations in parallel on pages as they come in so that processing isn’t completely centralized on each node.

そのためか、効果的なトリガーのためにデザインされた特別なデータベースを、Google が開発したのかとも思える。 私たちが知っているのは、何 10万ページものデータが、同時にクローリングされていることである。 ページがデータベースに書き込まれるときが、計算と更新を実行する完ぺきなタイミングとなる。 このコンピューティング・フレームワークでは、それらのページが取る込まれるときにページ上での並列処理を効率よく実現し、それぞれのノード上に処理がセンタライズされないようにするのだろう。

One can imagine that the in-memory data structures that existed on the MapReduce nodes have been extracted in some form and reified within BigTable. What we have is a sort of Internet DOM, analogous to the browser DOMs that have made it possible to have such incredibly powerful browser UIs, but for the web. I imagine programming the web for Google has become something like programming a browser DOM. I could be completely wrong of course, but I explored this idea a while ago in All the world is a DOM.

MapReduce ノード上に存在するインメモリ・データ構造が、いくつかの形式で抽出され、また、BigTable 内で具体化されると、想像する人もいるだろう。 私たち、ブラウザの DOM に類似した、ある種の Internet DOM を持っている。つまり、ブラウザ DOM は、信じられないほどにパワフルな ブラウザ UI を持っているが、それは Web ではない。 私は、 Google における Web プログラムが、ブラウザ DOM をプログラムに似たものになっていると想像する。もちろん、それはまったくの見当違いかも知れないが、この考え方については All the world is a DOM において、以前に探求している。

There’s an interesting quote at the end of the article: “We’re in business of making searches useful, we’re not in the business of selling infrastructure.”

この記事の最後には、『 私たちのビジネスは検索を有益なものにすることであり、そのインフラストラクチャを販売することではない 』という、興味深い引用が記されている。

These could actually be the same goal. It’s a bit silly to have everyone in the world crawl the same pages and build up yet another representation of the Web. Imagine if the Web was represented by an Internet DOM that you could program, that you could write to, and that you could add code to just like Javascript is added to the browser DOM. Insert a node into the Internet DOM, like a div in an HTML page, and it would just show up on the Web.

しかし、現実においては、それらのゴールが同じものにもなり得る。 世界中の誰もが、同じページをクローリングして、Web に別の表現を展開することは、少し愚かなことである。あなたがプログラムできる Internet DOM により、Web が表現されると想像して欲しい。 もちろん、そこでは書き込みも可能であり、Browser DOM と同様に、Javascript などのコードも加えられる。 HTML ページの div のように、Internet DOM にノードをインサートすれば、それが Web 上に、ただちに表示されるだろう。

This Internet DOM could be shared and all that backbone bandwidth and web site CPU reclaimed for something more useful. Google is pretty open, but they may not be that open.

この Internet DOM を共有することは可能であり、バックボーンの帯域幅と Web サイトの CPU は、より有益なものとして再構成される。 Google は、かなりオープンであるが、オープンではないのかもしれない。


ひさびさに、Google の底力を見せつけられました。 これだけのものを、ポンと実装から提供してしまうのって、やはりスゴイことですよね。 特許でも何でも取ってしまって構いませんので、Apache だけには、優しくしてほしいです。 ーーー A.C.


Google は 1000万台のサーバーを目指す? (Spaneer 関連)
年間で 30億円以上になる Google サーチの電気料金は、Instant の登場で跳ね上がるのか?
新検索エンジン「Google Instant」、入力中に検索結果を逐次表示
Google Instant, YouTube Instant, そして今度はGoogle Maps Instantだっ!
Google Instant:「真の可能性」と他への影響
グーグル、「Google Instant」検索をローンチ
Google、入力予測で検索結果を表示する「Google Instant」を発表

Hadoop で スマートグリッドを、図とデータで見る!

Posted in Hadoop, MapReduce by Agile Cat on June 18, 2010

GPA の OpenPDC とは、いったい何ものなのか?

先月(5月)にテネシーへ出張してきましたが、そのメインの目的は、Hadoop でスマート・グリッドに取り組んでいる GPA 社とのミーティングでした。日本へ帰ってきて、少しずつ情報を整理していますが、その概要がまとまりましたので、以下に ご紹介します。 ーーー A.C.

まず、この領域における Google の動向ですが ・・・   Ggoogle の子会社として設立され、電力の卸売を行う Google Energy については、さまざまな憶測があります。 その中で一番に挙げられるのは、再生可能エネルギーへのアクセスを実現することで、Google の大規模データセンターを支援していくという可能性でしょう。


つまり、Google Energy の電力売買権を用いれば、たとえば風力発電会社から一度買い取ってから、Google に転売することができます。 そして、もし、Google が独自の更新可能エネルギーを保有するなら、その風力発電会社からの電力は、契約が切れたあとでもオープンなマーケットに提供されることになります。

それに加えて、2000社以上にのぼると言われる、大手や中小で構成されるアメリカの電力卸売業界を、その資本力を用いて再編していくことも予測されます。その意味で、Google は IT の世界から、スマートグリッドの世界に向けてアプローチを開始していて、その尖兵となるのが Google Energy であると捉えることができます。

そして OpenPDC ですが ・・・  その一方で、 NERC(North American Electric Reliability Corporation)、TVA(Tennessee Valley Authority)、GPA(Grid Protection Alliance)が共同で推進しているスマート・グリッド・プロジェクトは、PMU(phasor measurement unit) データを収集し、保存し、処理するための、OpenPDCと呼ばれるものです。 このプロジェクトは、アメリカの電力業界の中から生じているものであり、Google とは反対に、電力の世界からスマート・グリッド(IT)の世界にアプローチするものです。


以前にもご紹介しましたが、OpenPCD は。実時間情報を持った一連のストリーミング・データを処理するための、アプリケーション・セットです。複数の入力ソースから得られる GPS タイム・スタンプ付きの測定データをソートし、ユーザー定義されたアクションに対して提供し、カスタムな出力ディスティネーションへ向けて分散させていきます。

そして、それらのデータが測定されるとき、GPS から取得されたタイムスタンプにしたがって、それらの測定されたデータは OpenPDC へとストリーミングされていきます。 この時に用いられるデバイスは、Phasor Measurement Unit(PMU)と呼ばれるものであり、1秒間に 30回のレートでデータのサンプリングを行います。一般には、point/ signal/ events/ time-series value や measurement、そして、 temperature/ voltage/ vibration/ location/ phasor といったものが含まれるとのことです。

そこでは、高速でのデータ転送を実現するために、プロセス・コンプレックス・イベントへの対処と、動的な変化への対応が要求されれます。 つまり、PMUに添付されたタイム・スタンプに応じてイベントを処理した後に、データをタイム・スライスすることで分析が行われていきます。


アメリカの送電網は、複数の電力会社により構成されるため、円滑な電力供給を実現するためには、それらの協調が必要になります。そして、そこで取り扱われるデータは膨大なものとなるため、PMU データ・リポジトリのためのアーキテクチャとして、Hadoop が採用されています。

このプロジェクトにおける Hadoop の採用理由は、高価なマシンが不要であること、そして、分散ファイルシステムであるHDFS が使える点にあります。 つまり、送電網から取得される膨大なデータを、MapReduce を用いて分散処理するために Hadoop が用いられています。



このサンプリング・データのサイズが 128 Bytes だとすると・・・・

3.84k Bytes /sec 
230K Bytes /minute 
14M Bytes /hour 
330M Bytes /day 
1G Bytes /month

そして、送電網に配置される PMU が 1000 ヶ所だとすると・・・

1T Bytes/month     365T Bytes/year

さらに、10000 ヶ所だとすると・・・

10T Bytes/month   3.65P Bytes/year

・・・ となります。


これだけのデータを処理するには Hadoop が必須だということが、お解りいただけると思います。スマート・グリッドと Hadoop の組み合わせというと、とてもリッチなトレンド・マッシュアップのように聞こえますが、そこには、それなりの必然性があるのだと思います。ーーー A.C.


Google は電力事業にも参入するのか?
スマートグリッドを Hadoop で (US 出張編_2)
スマートグリッドを Hadoop と OpenPDC で(US出張編_3)

Tagged with: , , , , ,
%d bloggers like this: