Big Data Topics

 

5038714561_34183a0639_m

January 3, 2011
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
このポストは、文中にリンクのある 『 A Snapshot of Facebook in 2010 』 のデータを元にしているようです。 そちらを見ると 『 Most Liked Celebrities 』というのもあり、『 Lady Gaga : 24,712,169 people like 』 などのデータも参照できます。


December 24, 2010
Hadoop に似た Dryad は、Microsoft の Big Data スターになれるのか
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)に対応しているように見える。


Amazon

December 22, 2010
GPGPU を用いたソートについて考える – James Hamilton
何年か前のことだが、特殊な目的のハードウェアは好ましくないという、間違った考え方を持っていた。 何が良くないかといえば、コストのかかるチャネルを介して販売される、特別な用途のための、少量生産の高額なデバイスである。 効率のよいハードウェア実装とは、コストとロットをベースに測定するときに、最も大きな価値をもたらすのが一般である。 Broadcom/Fulcrum/Dune(現在は Broadcom)などから提供される、一般的なネットワーク・パーツといった系譜は、Application Specific Integrated Circuits(ASIC)の美しい事例であり、きわめてホットで変化しにくいコードをカーネルとする際の、正しい回答である。


image

December 17, 2010
Big Data – だれが、どこで、使うのか?
Big Data あるいは膨大なデータセットを分析する能力が、科学/社会/経済の理解において強烈なブレークスルーをもたらす臨界点へと向けて、私たちを効果的に導いている。  Aster Data が後援する、直近の Bid Data カンファレンスでは、どのようなタイプの Big Data を想定して、計画を立てるべきかという質問が相次いだ。


December 12, 2010
Amazon S3 – 5 TB のシングル・オブジェクトは お好き?
私たちの多くの顧客は、科学や医療のデータ、高解像度のビデオ・コンテント、バックアップ・ファイルなどの、きわめて大容量のファイルを、Amazon S3 にストアしたがっている。 これまで、彼らは、それらの大容量ファイルを 5 GB 以下のチャンクに分割してストアし、参照しなければならなかった。 したがって、大容量ファイルへのアクセスや、他者との共有を望むとき、Amazon S3 におけるいくつかの URI を用いるか、な媒介となるサーバーもしくはアプリケーションを用いて、ファイルをヒモ付けせざるを得なかっただろう。もう、そうんな面倒はいらない。


image

December 6, 2010
スループット指向のアーキテクチャ- Amazon EC2 で GPU を正しく使うために
ドアを開けてリビング・ルームに入り、緑色の古臭いシャギー・カーペットを眺め、その家が改築されていないと理解したとき、私たちの大半がいまだに住んでいる元々の Amazon クラウドは、いろいろな意味において寒々としている。 そのネットワークは少し遅くて、プロセッサも時代遅れであり、仮想化が家を狭く感じがさせた。 そのクラウドでは、広帯域および低レイテンシーのワークロードを動かすことが難しい。そこらじゅうに、ボトルネックがある。 大半のアプリケーションとっては重要な事柄ではないが、それは HPC(high performance applications )を殺してしまうものだった。


image

December 4, 2010
ついに Apple も、Hadoop ユーザーになるようだ!
Steve Jobs のオープンソース定義に、Hadoop が入る入らないは別にして、 データ・インテンシブな分散アプリケーションをサポートするために構築され、ますます注目度を高めているこのフレームワークを、Apple は受け入れるようだ。


e468f100-b468-4cfe-91da-bbb1f19bbd46[4]

November 28, 2010
Facebook における 1300万/秒 クエリーの秘密
Facebook は MySQL Tech Talk において、同社におけるMySQL への取り組みを詳述したが、その中でも微妙で興味深いポイントは、リクエスト・レスポンス・タイムのバラつきを制御することへの注力であり、毎秒のクエリー数を最大にすることが関心事ではないことだった。しかし、最初に言っておくが、そのスケーラビリティは普通ではない。 Facebook における OLTP のパフォーマンス値は、いつものとおり、きわめてドラマチックである:


e468f100-b468-4cfe-91da-bbb1f19bbd46[4]

November 18, 2010
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook が導入する新しい Social Inbox が、電子メールおよび、IM、SMS、テキスト・メッセージ、Facebook オン・サイト・メッセージを統合するという記事を、どこかのメディアで読んでいると思う。 全般的に見て、Facebook は 1カ月に、1350億以上のメッセージをストアする必要がある。それら全てを、何処にストアするのであろうか? Facebook の Kannan Muthukkaruppan は、The Underlying Technology of Messages で HBase だと答えて、多くの人々を驚かせた。 つまり、HBase は、MySQL や、Cassandra などを打ち負かしたことになる。


image

October 28, 2010
Cassandra – 永続性とは? そして何故に?
永続性の意味を理解することは、各種のデータ・ストア・システムを評価するうえで重要である。 大半の先進的なアプリケーションにおいては、データストアの重要性という条件のもとで、不完全に理解に基づいた選択をすることが、深刻なダウンタイムやデータ・ロスを意味することになる。 このポストにおいて、私たちは永続性とデータ・ストア・デザインのアプローチを論じた後に、Cassandra のコンテキストにおける、それらの背景を提供していく。


image

October 26, 2010
実行中にノードを追加できる、新しい Elastic MapReduce とは?
私たちのカスタマーは、大量の Amazon EC2 インスタンスを用いた、大規模スケールのデータセットを処理するために、Amazon Elastic MapReduce を活用している。 そのようなカスタマーである Seattle の Razorfish は、日々の処理サイクルをスピードアップする一方で、必要とされる $500 K 以上の資本投資を回避した。


image

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


hadoop ws

October 5, 2010
Hadoop ベンダーたちは、データに苦しむ銀行から利益を得られるのか?
先週のことだが、分析フィールドにおける M&A のあらしについて書いたが、企業買収だけを掘り下げても、この領域がホットであるという、全体的なストーリーを伝えられない。 今週に公表された2つの調査結果が、それらの詳細を埋めるうえで役立つ。 とりわけ、各種ベンダーが分析マーケットで、足場を確保するために対価を積み上げている理由が分かる。 GigaOM Pro の Weekly コラムで説明しているように、Hadoop ベースのプロダクトを販売しているベンダーにとって、こうした裏付けはとても甘美なことなのだろう。


Google_logo2

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


Cassandra

September 10, 2010
Digg は Cassandra を、あきらめていないようだが・・・
Cassandra は、ギリシャの神話で悲劇の主人公である。彼女は、予知能力を持ち、次に来るものを(通常は死と破壊)を予言できた。 したがって、彼女が誰にも好まれなかったとこは、驚きではない。 同じ名前のオープンソース NoSQL ソフトウェアが、それ自身をめぐる論争の中に、しばしば見出されるのは皮肉である。 現時点において、Digg での Cassandra はスケール(と可用性)の問題を追求されている。それは、Digg で Cassandra を推進していた、VP of Engineering である John Quinn の、離脱をも導くのかも知れない。


GIGAOM Big Data LAMP

August 9, 2010
Big Data と LAMP Stack
数多くのFortune 500 と中型のエンタープライズが、Big Data を分析するための、Hadoop Test/Dev プロジェクトに資金を投じているが、その標準的なエンタープライズ・アーキテクチャの中に Hadoop を統合する方式には疑問が残る。 たとえば、クレジット・カード大手の Visa で、Technology Strategy and Innovation 部門を統率する Joe Cunningham は、昨年の Hadoop World で以下のように説明している。それは、トランザクション分析の Alpha/Beta のレベルから主として利用される環境へと、Hadoop が発展していくことを望むが、インテグレーションとオペレーションマネージメントについて心配というものだ。


facebook_logo

July 3, 2010
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook の運用スケールにおいて、 Web コンテントをサービスするための、数多くの伝統的なアプローチは失敗し、また、現実的ではなくなっている。 Facebook のエンジニアによるチャレンジは、5億人に近いアクティブ・ユーザーをハンドリングしながら、このサイトを維持して、順調に走らせることにある。 この記事では、その目標を達成するために、Facebook が要しているソフトウェアとテクニックを見ていく。


alt

June 9, 2010
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
Twitter は 2013年までに10億人のユーザーに到達するという、身の毛もよだつ大胆な目標を持っている。 そして Twitter は、3つの圧力に立ち向かう。 まず、世界は 2012年に終わってしまうらしいが、私たちは楽天的になれると想定しよう。 次に Facebook の存在だ。 Facebook は現時点において 4億人以上のユーザーを持ち、また、この指標におけるリーダーとなっている。 Facebook は行き詰まるだろうか? それとも、Twitter より早く 10億人のユーザーに至るだろうか?

Comments are closed.
%d bloggers like this: