YahooがTensorFlowをApache Sparkで高度なスケーラビリティへアップ

Servers in Data Center

Apache Sparkの模範市民Yahooはかつて、CaffeによるディープラーニングモデルのスケーラビリティをSparkの並列処理で高めるフレームワーク、CaffeOnSparkを開発した。そしてそのYahooが今回は、TensorFlowOnSparkと呼ばれるプロジェクトをオープンソースで公開した。今度のそれは、SparkとTensorFlowを組み合わせることによって、大規模なクラスターで動くディープラーニングモデルを作るデベロッパーにとってTensorFlowフレームワークを、より魅力的にするものだ〔==TensorFlowのスケーラビリティを高める〕。

ビッグデータ時代の人気者になったApache Sparkは、効率の高い並列処理を可能にするオープンソースのフレームワークだ。Hadoopのようなシステムを追う形で出てきたSparkは、たとえばNetflixのような企業における大量のユーザーデータの処理を支え、リコメンデーションのスケールアップを可能にしている。

GoogleのTensorFlowやCaffeのような機械学習のフレームワークの登場によって、機械学習の専門知識のない者でもディープラーニングのモデルを作れるようになった。抽象度の高いライブラリがオープンソースで存在するからデベロッパーは、車輪を再発明する苦労から解放されて、いきなりモデルそのものを作ることができる。

ビッグデータの処理を高効率なクラスタリング並列処理で支えるSparkは、機械学習、中でもディープラーニングが必要とする膨大な量の、そして高速であることを要する、データ処理にも向いている。Yahooは自社で利用するためにCaffeOnSparkを作ったが、Caffe用のツールは機械学習のコミュニティのごく一部にとってしか恩恵がない。それに対して、人気がすごく高いフレームワークがTensorFlowだ(下図)。そこでYahooは、ディープラーニングのための大量高速データ処理をSparkにやらせるその処理枠組みを、TensorFlowに移植し、コミュニティの尊敬をかちとることを目指した。

YahooはTensorFlowとSparkのあいだに橋をかけるために、既存のツールSparkNetやTensorFrameを参考にしたが、最終的には一から自分で作る方が良い、と結論した。その結果デベロッパーは、自分の既存のTensorFlowプログラムを比較的簡単に、TensorFlowOnSparkを使うよう改造できる。

ディープラーニングのフレームワークは、デベロッパーたちが特定の“部族”に凝り固まる傾向がある。たとえばJavaで書かれたSkymindのDeeplearning4jは、最初からSparkを統合しているオープンソースのフレームワークだが、このライブラリの人気は6位と低い。そして他方には、複数種類のGPUにまたがるスケーラビリティを誇るMXNetがある。その特長がAmazonの関心をとらえ、AWSの努力によりMxNetはApacheのインキュベータに加入した

TensorFlowOnSparkはオープンソースだが、Yahoo自身による改良努力は今後も続く。入手は、YahooのGitHubから可能だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSのディープラーニングフレームワークMXNetがApacheソフトウェアの一員になる、対TensorFlow戦略の一環

Connecting lines, computer illustration.

Amazon Web Servicesの推奨ディープラーニングフレームワークMXNetが今日(米国時間1/30)、Apache Incubatorに加わった。このインキュベータに受け入れらることは、オープンソースのプロジェクトがApache Software Foundationの一員になるための第一歩だ。

Apache Software Foundationは、何千人ものデベロッパーによる、世界中のさまざまなオープンソースプロジェクトのメンテナンス努力を支えている。今後はMXNetも、Apche流儀の実績豊富なオープンソース方式を採用し、またApacheのコミュニティにアクセスできる利点も享受していく。

MXNetは、デベロッパーによるディープラーニングモデルの構築を助ける、今や数多いフレームワークの一つで、それらを使えることによってデベロッパーは、ユースケースごとに‘車輪を再発明’することを避けられる。さまざまな機械学習方式の中でもディープラーニングはとくに、大きなデータ集合からパターンを掘り出す処理に向いている。

それらの中でMXNetの差別化要因は、多様な言語に対応していることだ。デベロッパーはC++とPythonという主軸言語のほかに、R, Scala, MATLAB, JavaScriptなども使える。

MXNetのもうひとつの特長が、スケーラビリティだ。昨年Amazonがこのフレームワークの内部的利用と対外的推奨をを決めたとき、画像認識アルゴリズムを動かすGPUの数が多くなると、ほかのフレームワークに比べてスループットが良い(速い)、と言っていた。ただ速いだけでなく、MXNetは‘拡張効率’が良くて、GPUの台数増加率の85%の高いスループット向上が得られる、という。〔例: GPUの台数を2倍(200%)にすると、スループットは1.85倍に向上する。〕

しかしディープラーニングのフレームワークの中でMXNetは、ユーザー数の多さではGoogleのTensorFlowなどの後塵を拝している。AmazonがMXNetを推奨フレームワークにすることを決めたのは、デベロッパーたちの関心を高める意味もある。AWSはMXNetを機械学習コミュニティの人気者に育てるべく、コードとドキュメンテーションで尽力している。今回Apache Software Foundationの一員になったことも、この目標の実現に貢献するだろう。

Blue - TensorFlow, Yellow - Theano, Red - MXNet, Green - DL4J

青: TensorFlow, 黄色: Theano, 赤: MXNet, 緑: DL4J

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

IBMのDataWorksはApache Sparkによるビッグデータ分析に人工知能Watsonが企業向け利用インタフェイスをまとわせる

screen-shot-2016-09-27-at-10-53-02-am

マシンインテリジェンスの分野は、研究開発が盛んであるだけでなく、より影響力の強い応用現場でも新しいトレンドが生まれつつある。それを好機としてApache Sparkのようなオープンソースのフレームワークは、データサイエンティストのニーズに応えるだけでなく、企業の事業開発にもデータ分析を持ち込もうとしている。

IBMがこのほど立ち上げたProject DataWorksは、SparkとIBM Watsonを組み合わせて、分析の堅実性を維持しつつそのスピードと使い勝手を向上しようとする。わかりやすく言えばDataWorksは、データ分析のためのGoogle Docsだ。今多くの企業は大量のデータを、いろんなところにばらばらに保存している。IBMのこの新製品は企業のすべてのデータを食べて、それを一箇所のアクセスしやすい場所に置く。

management-console

データに、それを必要とする者が迅速簡単にアクセスできるために、IBMはダッシュボードを提供し、そこにデータのアクセス状態や、利用しているユーザー、カテゴリー関連の各種測度などを収めて表示する。IBMはその技術を、データをカタログに仕分け分類すること、と呼ぶ。検索は自然言語で行い、ユーザーはカタログに整理された情報を、これまでよりもずっと素早く取り出すことができる。また、データの取り入れ速度は、IBMによると、50〜100Gbpsである。

データの視覚化は、PixiedustやBrunelなどのコードを使って、わずか1行のコードで作り出される。視覚化によりもちろん、データ間の関連性や分類がよりわかりやすくなり、ふつうの社員でも、ひと目でインサイトを得ることができる。

大企業も中小企業も、IBMのクラウドプラットホームBluemixからDataWorksツールにアクセスできる。近く料金体系が確立すれば、ユーザー企業はこのシステムを数時間〜数日〜数か月と、長期間(または常時的に)稼働させられる。またIBMの構想では、データ分析を携帯キャリアのデータプランからも提供し、それを定額の月額制にすることもできる。

IBMのデータ分析担当VP Rob Thomasによると、企業はこのツールを活用することによって、人件費を大幅に節約できる。またデータ分析に関して、企業の特定部門の人間を教育訓練する苦労もなくなる。さしあたり、リテールや金融、通信などの分野が主な顧客層になるが、しかしThomasによると、中小企業のうち‘中’の方の企業も今すでにこのシステムに関心を示している。

DataWorksの動力となっているIBM Watsonは、これまでも同社の成長と売上を支えてきた。このたび新しいユースケースが増えることによって、Watsonはますます自分を改良していくだろう。そしてDataWorksの主要部分は、IBMが今年初めに買収したThe Weather Companyの技術を利用している。その買収の目的は不定形データの分析にあったが、今ではお天気情報ばかりでなく、Watsonの助力も得て、企業のデータ分析方面に新たな市場を開拓しつつある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSのElastic MapReduce 5.0.0は16種のHadoop関連プロジェクトをサポートしてビッグデータ処理の実用性を増強

15558382212_a81f9f4a3a_k

Amazon Web Services(AWS)が今日(米国時間8/2)リリースを発表したElastic MapReduce(EMR) 5.0.0は、16種のHadoop関連プロジェクト(派生プロジェクト)をサポートする。

AWSはつねに、顧客がクラウド上の多様なエンタープライズ機能を管理するための、さまざまなツールのアップグレードに努めているが、今回のものは、Hadoopでビッグデータプロジェクトを管理しているデータサイエンティストやその関連部署に向けられている。

この分野に強いForresterのアナリストMike Gualtieriの言葉を借りると、Hadoopとは基本的に、“大きなデータ集合を保存し処理するためのインフラストラクチャ的ソフトウェア”だ。

従来のデータ処理ソフトウェアと違ってHadoopは、データの保存と処理を複数のノード(数千に及ぶこともある)に分散して行い、それにより大量のデータ処理を効率化する。

しかもそれは、Apacheのオープンソースプロジェクトとして、きわめて人気が高い。かわいいマスコットまである(上図)。Hadoopを軸に大きなエコシステムができていて、プロジェクトの改良充実にたえず貢献している。また、そこから生まれる派生プロジェクト(“Hadoop関連プロジェクト”)も多い。

今のHadoopはそれらの派生プロジェクトを積極的に取り入れて、ユーザーによる大量のデータ集合の管理を助けている。たとえばHiveはHadoopのためのデータウェアハウスであり、HBaseはスケーラビリティの高い分散データベースだ。AWSは、どちらもサポートしている。

Hadoopによるシステムの実装やデータ処理を助ける企業も続々生まれていて、有名なところとしてはCloudera, Hortonworks, MapRなどが、Hadoopの独自の商用化バージョンを提供している。

AWSは昨年の7月以来、AWS本体ツールの継続的アップデートとともにHadoop関連プロジェクトのサポートのピッチを上げ、顧客の選択の幅を広げようとしている(下図)。

[EMRの更新履歴(4.7.0まで)とHadoop関連プロジェクトのサポート]

Chart showing updates to EMR tool since January, 2016.

図表提供: AWS.

AWSは、もうひとつのApacheオープンソースプロジェクトBigtopも使ってきた。これは、プロジェクトのページによると、“Hadoopのビッグデータコンポーネントの、インフラストラクチャのエンジニアやデータサイエンティストによるパッケージングとテストと構成を助ける”、という。AWSのブログ記事によると、AmazonはBigtopの開発のペースアップに協力し尽力してきた。

以上は、データサイエンティストと、クラウド上の大型データ集合を扱う社員たちにとって、良いニュースだ。今回のリリースではオプションの数がぐっと増え、AWS上で有用なHadoop関連プロジェクトを、より見つけやすくなったと言えるだろう。

ビッグデータは今やAWS上の重要なユースケースだから、Hadoop本体はもちろんのこと、ストレージやコンピューティングを効率化するためのさまざまなツールを必要とする。〔そしてそのニーズの多くをさまざまなHadoop関連プロジェクトがサポートする〕。ユーザーから見ると、AWSのようなクラウドベースのインフラストラクチャは文字通りエラスティック(elastic, 伸縮自在)であり、オンプレミスの場合のように、扱いデータの増加とともに新たなリソースの手配をいちいち心配する必要がない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Microsoftはビッグデータ分析とその応用プロダクトでApache Sparkに総賭けの姿勢

microsoft_cloud_logo

Microsoftが今日(米国時間6/6)、オープンソースのクラスターコンピューティングフレームワークApache Sparkに、本格的にコミットしていく、と発表した

昨年、Sparkのエコシステムの浅瀬でちょっと足を濡らしてみたMicrosoftは、本日、いくつかのSpark関連サービスのプレビューを終えてそれらを公式ローンチし、またR Server for Hadoopのオンプレミスバージョンが今後はSparkベースになる、と発表した。R Serverの‘R’は、今人気がますます盛り上がっている、ビッグデータ分析とモデリングのためのオープンソースの言語Rを指す。

spark-logo-trademark

さらにMicrosoftは、R ServerのAzureクラウドバージョンR Server for HDInsightがこの夏の終わりごろプレビューを終えて一般公開される、と発表した。なおSpark for Azure HDInsightは今すでに一般公開されていて、Hortonworksによる管理を伴うSparkサービスがサポートされる。MicrosoftのビジネスインテリジェンスツールPower BIも、今ではSpark Streamingをサポートし、ユーザーはリアルタイムデータをSparkから直接Power BIへプッシュできる。

これらの発表はすべて、Microsoftが“Sparkへの幅広いコミットによってMicrosoftのビッグデータ分析プロダクトを強化する”、と述べる方針の実現(の一環)だ。プロダクトはPower BIやR ServerだけでなくCortana Intelligence Suiteも含まれる。こちらはMicrosoftの複数のビッグデータ分析サービスを併用し、いくつかの機械学習ツールも利用するシステムだ。〔Cortana参考サイト

今週サンフランシスコで行われるSpark SummitでMicrosoftは、Google, Baidu, Amazon, Databricksなどなどと共にスポットライトを浴びる気でいる。その席でMicrosoftは、同社がSparkに今どれだけ入れ込んでいるか、その情報をシェアする、と約束している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Crayの最新のスーパーコンピューターはOpenStackを搭載してオープンソースのビッグデータツールを動かす

ms_front-right-angle_0293_high-res

Crayといえば、スピードとパワーをつねに連想するが、同社の最新の計算怪物Cray Urika-GX systemは、ビッグデータのワークロード専用に設計されている。

しかも、そのベースシステムはオープンソースのクラウドプラットホームOpenStackで、その上でビッグデータを処理するHadoopやSparkなどのツールが仕事をする。

Seymour CrayがCray社を立ち上げたのは70年代の初頭だが、その後のコンピューティングの進化を同社はよく認識している。作っているのは相変わらずハイパワーのコンピューターだが、今ではクラウドコンピューティングという強敵がいる。人びとはコンピューターを買わずに、その都度必要なぶんだけ利用して、料金を払う。

そんな強敵と戦うためにUrkia-GXは2ソケットのIntel® Xeon® v4(Broadwell)を16〜48ノード搭載し、そのコア数は最大で1728、DRAMは最大で22TBを持つ。ストレージは35TB PCIe SSDと192TBのハードディスクを、ローカルストレージとして持つ。

しかも同機はCray特有の高速マシンであるだけでなく、差別化要因として、顧客企業が求めるビッグデータ処理ソフトウェアの完全セットアップサービスがつく。HadoopやSparkだけでなく、顧客が求めるものは何でもインストールし、構成し、実働状態にしてから納品する。

また、同社独自のグラフデータベースCray Graph Engineを標準で搭載する。それは複雑なビッグデータ分析において、既存のグラフソリューションの10倍から100倍は速いそうだ。グラフというデータ構造はいろんなものを複雑に結びつけたり比較する処理に適していて、たとえばeコマースのサイトでは顧客が買った物と似たものを見つけたり、逆にそんな物が好きな友だちをソーシャルネットワーク上に見つけたりという、複雑な関係操作が得意だ。

今クラウドに人気があるのは、ITの面倒な部分をすべてクラウドベンダが肩代わりしてくれるからだ。そのことを認識しているCrayは、クラウド上のSaaSではなく、オンプレミスのSaaS、ソフトウェアのインストールから構成〜実働までのすべての面倒を見るサービスに徹しようとしている。それは、Urika-GXとビッグデータ分析に関して、上で述べたとおりだ。しかもソフトウェアのアップデートも、半年ごとにCrayがすべてやってくれる。

顧客が日常使うのはシステムの最上層のアプリケーションだが、その下の部分は顧客企業のIT部門を手伝いながら主にCrayが担当する。ソフトウェアのメンテナンスのお世話をする、という言葉は単純だが、顧客が上の方の、Crayがせっかくインストールしたソフトウェアの上で黙って勝手なことをして、おかしなことになっても、その修復がCrayの仕事になるから、たいへんだ。

でもCrayのプロダクト担当SVP Ryan Waiteによると、同社は顧客と一緒に仕事をしていく歴史が長いから、どんなにわかりにくい問題が生じても十分対応できるそうだ。

費用についてWaiteは、そのほかのビッグデータ処理ソリューションとそれほど変わらない、と言う。みんなが考えるほど、高くはない、と。ということは、Crayコンピューターの数百万ドルというプライスタグは、すでに過去のものか。彼によると、価格はハードウェアとソフトウェアの組み合わせ次第で変動幅が大きい、という。言い換えると、顧客のニーズ次第、ということだ。

というわけで、まだ表面的なことしか分からないが、Crayが今でも強力なコンピューターのプロバイダであることは確実だ。かつてのギークたちの夢は、どっこい、まだ生きていた。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Strata + Hadoop World 2016に見るビッグデータの最新トレンド、「インメモリ」で「リアルタイム」へ

15366067990_febad7909e_k

[筆者: Josh Klahr](Atscaleのプロダクト担当VP)

今年もまたStrata + Hadoop Worldが始まる。それはいつも、一歩引いてセッションの内容を一望し、ビッグデータの最新の動向を理解するための、良い機会だ。

これまで毎年のようにこのカンファレンス参加してきた人は、このイベントがオープンソースの技術を実験するソフトウェアデベロッパーのための催しから、重要なエンタープライズソフトウェアの大会に変わってきたことを、目撃されただろう。今ではデベロッパーだけでなく、企業の役員たちや、ベンダー、プロフェッショナルなサービスのプロバイダーたちが一堂に会して、この分野の最新の開発について共有し、学習している。

サンノゼで行われる今年の大会の、もっともホットな話題を知るために、この週全体にわたるコンテンツ(教育訓練クラス、キーノート、プレゼンテーションなど)のタイトルに登場する言葉の頻度を数えてみた。当たり前のような言葉(Hadoop, data, analytics, Apacheなど)を取り除いて集計すると、上位の語彙は下図のようになる:

pasted image 0 (10)

このデータをじっくり見ると、ビッグデータ界隈における、いくつかの重要なトレンドが浮かび上がってくるのではないだろうか。

Sparkの採用と関心が成長を続けている: 採用の絶対数では依然としてHadoopがトップだが、このところ、ビッグデータのエコシステムにおけるSparkの成長が著しい。HadoopとSparkは二頭の王座、と言えるかもしれない。とりわけSparkはユースケースの幅が広くて、データのパイプライン処理や、データサイエンスワークロードの並列処理といった分野でも利用されている。

ストリーミングとリアルタイムが“次の大物”: 上図では、“streaming”や“real-time”と並んで、“kafka”、そしてKafkaの商用ディストリビューションである“confluent”が上位に来ている。今企業は、Hadoopのクラスタにデータをバッチでロードし処理することには成功し、次の段階として、リアルタイムのデータ取り入れ、処理、そして分析へと関心を移しつつある。

視覚化は依然として重要: AtScaleのHadoop Maturity Surveyによると、最近の企業はますます、Hadoop上のビジネスインテリジェンスユースケースの展開に力を入れつつある。その関心は、データサイエンスへの投資を上回っている(メディアは今でもデータサイエンスを“セクシー(ナウい!)と持ち上げているけど)。データの視覚化とセルフサービスは、Hadoopの世界においても、今後も重要な投資対象であり続ける。

SQL-on-Hadoopが脇役から主役に昇進: 上図のHadoop World上位語彙のリストにはSQL-on-Hadoopが見当たらない。前年までは、Hiveに始まりImpalaやSparkSQL(そしてそのほかの商用SQL-on-Hadoop製品の数々)に至るまで、これらの技術に対する熱い関心があった。しかしSQL-on-Hadoopは勢いが衰えたのではなくて、Hadoopツールキットにおける“必須品目(must have)”になり、メインストリームの一員になったのだ。Hadoop上のビジネスインテリジェンスに関する最近のベンチマークが示しているように、今ではこれらのSQLエンジンが大規模で分析的なSQLワークロードをサポートしている。

インメモリサブストレート…それは次の最適化か?: 語彙リストの上位に登場している“alluxio”とは、なんだろうか? Alluxioは、最近Tachyonから改名された仮想分散ストレージシステムだ。それはメモリ基板(サブストレート)を利用するストレージなので、クラスタ間のデータ共有がメモリのスピードで行われる。SQL-on-Hadoopエンジンの場合ならそれによってクェリの時間が速くなりパフォーマンスが上がる。Alluxioを採用したBaiduの経験でも、確かに彼らの分析的データ処理がスピードアップしている。

Hadoopの採用が最大の関心: “adoption”と“production”がリストの上位: 今では多くのIT組織が、次世代のデータプラットホームとしてHadoopに大きな期待を寄せ、ワークロードをTeradataのようなレガシーシステムから、もっとローコストでスケーラブルな環境へ移行させつつある。これらの組織にとって重要なのは、彼らのHadoopへの投資が、ビジネスインテリジェンスなどの中核的なビジネス機能によってプロダクションクラスタ(実用・現用システムで使われるクラスタ)の形で採用され、現実にコスト低減に貢献している、と実証することだ。“production”へのこだわりは、試用やパイロットの段階を超えた実践実用レベルへの関心の強さを表している。

クラウド上のビッグデータを忘れるな: AmazonとMicrosoftの二社がリストに登場している。Hadoopへの取り組みが遅かったMicrosoftも、今ではビッグデータの分野で大きな成功を収め、HDInsightのようなサービスを提供している(WindowsではなくLinux上で動く!)。そしてAmazonは前から一貫して、ビッグデータの分野に大きな貢献を果たしている。中でもとくにRedshiftは、S3やEMR(Elastic MapReduce)などの人気サービスを補完するサービスとして、採用が引き続き増加している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

ビッグデータ技術者のいない中小企業のためにHadoopクラスターを5分で立ち上げるGalactic Exchangeがオープンソースでスタート

shutterstock_230176666

Galactic Exchangeというクールな名前の企業が今日(米国時間3/24)ステルス状態を脱(ぬ)けて、そのすばらしいアイデアを披露した。同社の主張によると、同社はHadoopのクラスターを5分でセットアップし、即、動かせるようにする。複雑で面倒で難しいと言われていたHadoopが、誰にも簡単に使えるようになるのなら、それはすごいことだ。

同社のプロダクトClusterGXは、今週サンノゼで行われたStrata+HadoopWorldでベータでリリースされた。クラスターの上で動くアプリケーションとそのためのデータは、ユーザーが自分で用意しなければならない。

このプロダクトは、Hadoopのクラスターを短時間で立ち上げられるだけではなくて、オープンソースだから今後ユーザーの寄与貢献で改良していけるし、しかも無料で使える。ただしビッグデータを扱うHadoopはデータ用に大量のストレージを必要とするから、そのためのクラウドインフラにはお金がかかる。

Galactic Exchange自身も慈善事業ではないから、今後はセキュリティ機能やビジネス関連の機能を完備したエンタプライズバージョンを、収益源にしていくつもりだ。そのためにはもちろん、最初の無料のオープンソースバージョンが、企業ユーザーにとって魅力的でなければならない。

同社のプロダクトは、Hadoopとビッグデータ分析を導入したいが技術者がいない、という典型的な中小企業が主なターゲットだ。CEOのRob Mustardeは、そう説明する。

どれぐらい、簡単なのか? Mustardeによると、スマートフォンにアプリをインストールするぐらい簡単だそうだ。インストール先は、WindowsでもLinuxでもOS Xでもよい。あるいはベアメタル(つまり専用クラウドサーバー)でもよい。

同社は長期的には、HadoopやSparkに限定されない幅広いサービスを提供していきたい、と考えている。Mustarde曰く、“長期的なプランは、ユーザーのアプリケーションとコンピューティングと仮想ストレージが完全に一体化した環境を提供していくことだ”。

今に関して言えば、オープンソースのプロダクトで立ち上がるのは賢明なやり方だと思える。Enterprise Strategy GroupのアナリストNik Roudaのところには、そんなやり方を肯定するデータがある。それによると、“われわれの調査では、企業でビッグデータ戦略を任されている人たちの90%以上が、ベンダがオープンソースで積極的な活動をしていることを、高く評価している。そして24%が、Hadoopの環境は純粋にオープンソースのディストリビューションで構成したい、と言っている”。

今週スタートした同社にとっても、これはまさに吉報だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

データを発見しそれらの起源・出自を調べるLinkedInの社内ツールWhereHowsがオープンソース化

linkedin-chocs

LinkedInが今日(米国時間3/3)、WhereHowsをオープンソース化した。WhereHowsは主に同社の社員が、同社が生成するデータを見つけ、また同社のさまざまな内部的ツールやサービスで使われているデータ集合の出自を調べるために使っている、メタデータツールだ。

今では多くの企業が毎日のように大量のデータを作り出しているから、それらの情報のフローを全社的に管理することがほとんど不可能になっている。データウエアハウスに保存するのはいいけれども、結局のところ、同じようなデータ集合が大量に集積したり、元のデータ集合のいろんなバージョンが散乱したり、いろんなツールで使うためにデータ集合がさまざまに変形されていたりする。まったく同じデータが、名前やバージョンを変えて複数のシステムにあることもある。だからたとえば新製品開発をこれから始める、というとき、あるいは単純に役員が見るためのレポートを作ろうとするとき、どのデータ集合を使えばよいのか、よく分からないことが多い。

2016-03-03_0839

LinkedInのShirshanka DasとEric Sunによると、同社もまさしく、この問題に直面していた。そこで彼らは、WhereHowsを開発した。それは、LinkedInのような大きな企業で、データに何が起こっているかを常時追跡するための、中央的リポジトリ兼Webベースのポータルだ。今では中小企業ですら、大量かつ雑多なデータの整理や管理に悩まされているだろう。LinkedInでは、WhereHowsが現在、約5万のデータ集合と14000のコメントと3500万のジョブ実行の、ステータスに関するデータを保存している。それらのステータスデータは、約15ペタバイトもの情報に対応している。

LinkedInはHadoopの大ユーザーだが、このツールはほかのシステムのデータも追跡できる(Oracleデータベース、Informatica、などなど)。

WhereHowsはAPIとWebの両方でアクセスできるから、社員たちはデータ集合の出自や由来を視覚化したり、注釈を加えたり、いろんなことができる。

DasとSunによると、LinkedInは、そのサービス本体に属していないプロダクトをこれまでも長年、オープンソース化してきた。その基本的なねらいは、会話を喚起することだ。ビッグデータの大きなエコシステムがあれこれのツールを採用すると、同社もそのことで結果的に得をする。これまでぼくが取材してきた多くの企業と同様に、LinkedInでも、オープンソースが同社の技術のブランドイメージを高め、すぐれた人材の獲得を容易にするのだ。

2016-03-03_0844

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Hadoopベンダとして5年を超える古参MapRがビッグデータストリーミングで新境地を開拓

shutterstock_272856935

MapR(MapR Technologies)は、オープンソースのHadoopプラットホームを提供する企業のひとつだが、今そんな企業は多いから競争も激しい。今日(米国時間12/8)同社は、資金潤沢なライバルたちに対する差別化努力として*、MapR Streamsという新製品を発表した。〔*: CEOはこの説を否定(後述)。〕

この新しいプロダクトは、その名のとおり、コンスタントなデータストリームを顧客に供給する。それが消費者データのフィードなら、アドバタイザーは広告の個人化に利用するだろう。保健医療に関するデータなら、それをもとに医師や保健医療機関が処方や処理の適正化を図るだろう。いずれの場合も、ほとんどリアルタイムで。

同社が提供するデータストリームは通常、個別企業等のオーダーメイドではなく、クラウド上で複数の顧客(人間または機械)が会員/会費制で利用する。たとえば顧客が使っているメンテナンスプログラムは、売り場やメーカーからのデータを見て、自分が納めたシステムの使われ方やボトルネック、損耗の状況などを知るだろう。あるいはIT部門はログ情報のストリームを見て、メンテナンスを必要とする異状や、セキュリティの侵犯などを知る。

またMapRが提供するストリームは、上記のようなリアルタイムに近い利用のほかに、記録システムとしての用途もある。それは、過去のどの時点へも巻き戻せるから、不具合の分析などに役に立つ。つまりそれは、完全な監査対象データであり、いろんな規制の多い業種業界では、すべてのトランザクションを記録できることが重宝するだろう。

これと同時に同社は、データを総合化するためのプラットホームも発表した。それは、ファイルやデータベース、アナリティクスなどのデータを単一のプラットホーム上で総合化し、分析できるシステムだ。その場合データソースはHadoopだけでなく、Apache Sparkも使える。それは、2010年にカリフォルニア大学バークリー校で開発された、オープンソースのビッグデータ高速分析プラットホームだ。

CEOのJohn Schroederは、今回の新製品発表について、そろそろHadoopオンリーから脱したいので、と言う。“このプロダクトはエンタプライズ級のHadoopとしてプレゼンしたし、それは今でもうちにとって、さしあたり重要なことだが、実際にはそれ以上のものでもある”。

前向きの脱Hadoopは、Hadoop市場があまりにも混み合っているせいでもある。

たとえば、MapRと同期のHadoopベンダHortonworksは、昨年上場した。また、昨年は10億ドル近い資金を調達した大物のClouderaは、評価額が40億ドルに達している。コンペティタたちにのしかかるプレッシャーは、ますます強まる。ClouderaのCEO Tom Reillyは、どこのベンダもHadoopだけをサポートしているわけではないから、ベンダ全員が健全なエコシステムの恩恵を被っている、と言うのだが(Intel Capitalの今年のGlobal Summitでインタビューしたとき、そう語った)。

それでもしかしSchroederは、今回のアップデートを競合戦略だとは言わない。むしろ、顧客の要望への対応だ、と述べる。“顧客のニーズに基づいて会社を経営している。コンペティタが何をやってるかは、経営の指標にはなりえない”、と彼は語る。

MapRの創業は2009年だ。同社は独自のHadoopビッグデータプラットホームを作り、それを無料でオープンソースのプロダクトとして提供している。そして企業顧客のための関連製品やサービスが、有料だ。同社はこれまでに、1億7400万ドルを調達した。いちばん最近は、2004年6月の、プライベートエクイティによる8000万ドルだ。

参考日本語ページ(1)(2)CrunchBaseページ。〕

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

SparkとHadoopは友だちである、敵ではない

hadoop-spark

[筆者: Raymie Stata](AltiscaleのCEO)
今年の6月はApache Sparkにとってエキサイティングな月だった。San Joseで行われたHadoop Summitで頻繁に話題になっただけでなく、Spark関連のプレゼンテーションも多かった。6月15日にIBMは、Sparkの関連技術に大量の投資をすると発表した。

この発表がSan Franciscoで行われたSpark Summitに火をつけ、来場者は昨年に比べて急増した。Sparkを試してみたい、という企業の数も増えた。

こうしてSparkへの投資と採用の好循環が回りだしたため、この重要な技術の成熟度と能力も急速に高まり、ビッグデータコミュニティの全体がその利益を享受した。しかし、Sparkへの関心が高まるにつれて、奇妙で偏狭な誤解も生まれてきた。それは、SparkはHadoopに取って代わるものであり、後者を補完するものではない、という誤解だ。たとえば次のような見出しは、この誤解の産物だ: “新しいソフトウェアがHadoopを蹴散らす”とか、 “企業はビッグデータでHadoopの次の技術へ”

ぼくはビッグデータとの付き合いの長い人間で、初期のHadoopに対するYahoo!の投資も擁護し、今では企業にビッグデータのSaaSを提供している会社のCEOだ。だからこの誤解を解きほぐす役割として、適任かもしれない。

SparkとHadoopは、一緒に使うものであります。

Hadoopは今やますます、ビッグデータ分析をやろうとする企業にとって、定番のようなプラットホームになりつつある。SparkはそのHadoopをより高速に動かすための、インメモリ技術だ。eBayやYahoo!などの、Hadoopの大型ユーザは、Hadoopのクラスタの中でSparkを使っている。ClouderaやHortonworksのような‘Hadoopベンダ’からHadoopのディストリビューションを導入すると、すでにSparkが同梱されている。弊社Altiscaleの顧客も、最初からHadoop上でSparkを使っている。

SparkをHadoopの対抗馬のように言うことは、車をガソリン車から電気カーに変えてとても快調なので、もうこれ以上電気は要らないと錯覚するのと同じだ。むしろ、電気で走るようになった車は、さらに快調に走るためには、さらに多くの電気を必要とするのであります。

なぜ、こんな混乱が生じるのだろう? 今のHadoopには主要部位が二つある。ひとつは、Hadoop Distributed File System(HDFS)と呼ばれる大規模なストレージシステムで、大量のデータをローコストで、しかも多様なデータを高速に処理できるよう最適化した形で保存する。第二の部位はYARNと呼ばれる計算処理の部位で、HDFSに保存されているデータを大規模な並列処理により高速に処理していく。

YARNはその処理方式としてさまざまなプログラミングフレームワークをホストできる。最初に使われたのがMapReduceで、これはGoogleが大規模なWebクロール(crawl)を処理するために発明したフレームワークだ。Sparkもそういうフレームワークの一つであり、最近ではTezというフレームワークも登場した。記事の見出しなどが“SparkがHadoopを蹴散らす”、と言っているときは、実は、今ではMapReduceよりもSparkを好むプログラマが多い、という意味なのだ。

言い換えると、MapReduceとHadoopを同格に扱うことはできない。MapReduceは、Hadoopのクラスタでデータを処理するときの、さまざまな処理方式の一つにすぎない。Sparkは、Haoopに取って代わることはできないが、MapReduceに取って代わることはできる。もっと広い視野で見ると、アプリケーションのレベル、たとえばビッグデータ分析の重要なアプリケーションのひとつであるビジネスアナリシスでは、多くの場合、ユーザのレベルでMap…やSpa…の顔を直接見ることはなく、もっぱら、彼らがいちばん使い慣れているデータクェリ言語SQLが、見かけ上の処理方式だ。

最近の4年ぐらいで、Hadoopを使うビッグデータ技術に大きなイノベーションが訪れている。まず、SQLがバッチではなくリアルタイムの対話型になった。そしてフレームワークは、MapReduce一本槍から、MapReduceもSparkも、そしてそのほかにも、いろいろあります、というご時勢になっている。

HDFSは、パフォーマンスとセキュリティが大幅に改良された。またビッグデータ分析のユーザビリティを良くするためのさまざまなツール…DatameerH20Tableauなどなど…が続々登場している。そしてこれらにより、より多くのデータサイエンティストやビジネスユーザにとってビッグデータ分析が、アクセスしやすいものになっている。

Sparkは、Hadoopをリプレースする挑戦者ではない。むしろHadoopは、Sparkがその上で活躍できるための基盤だ。企業が、そのデータ資産をアクションに結びつくビジネスインサイトに換えようとするとき、この両者をベースとする強力でロバストなプラットホームが、ますます多く採用されていくだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ビッグデータ産業の今後の成長のためにはHadoopの標準化が不可欠だ

industrialinternet

[筆者: Stefan Groschupf ](ビッグデータ分析のDatameerのCEO)
 
至るところでデータが増大し、それとともに、誰もが選ぶビッグデータプラットホームとしてHadoopの評価が定着しつつある。Allied Market Researchによると、Hadoopの市場はほぼ30億ドルに相当し、2020年には500億ドルを超える、と推計されている。しかし、今後の長期的な成功は、標準化の実装と、もっと構造性のある(手当たりばったりでない)イノベーションの過程にかかっている。

採用者がもっとも多いビッグデータ技術なのだから、どこが作ったどんなソフトウェアでも、Hadoopのあるところなら必ず動く、何年後でも完全に動く、という状態を確立すべきであり、そのためには全面的な標準化が必要だ。各ベンダには、他社と差別化するという商業的なプレッシャーはあるが、それらの差別化要因によって、どこで動く・動かないの非互換性が生ずるのなら、そもそも差別化の意味がない。これまで、ばらばらの非互換性が多く生じているのも、標準仕様と標準APIの欠如にその原因がある。

このような非互換性は、このプラットホーム上のアプリケーション層の、イノベーションを窒息させる。標準性の欠如によりインフラストラクチャもますます分断化し、それがイノベーションをさらに遅滞させる。誰もが知ってるJavaの成功とUNIXの逝去を比べてみれば、分断化がその技術の死の病であることが分かる。全員が元気で生きて前進するためには、早期の標準化努力が必須だ。

Hadoopのコミュニティが成長すればするほど、標準化の欠如に起因するさまざまな問題点が、ますます受け入れがたいものになっていく。

業界の総意に基づく標準化の過程があれば、ベンダはその過程の中に、自らのAPIアイデアや性能アップのアイデアなどを投じていけるから、非互換性をもたらす分断化のおそれはなくなる。一貫性(無矛盾性)があってデベロッパとベンダにとって扱いやすい標準仕様があれば、Hadoopベースの技術はさらに広く採用されるようになり、究極的には、大小すべての選手が互角な条件で競争に参加でき、その正体が非互換性であるような差別化で頓挫するところは、なくなる。

今のHadoop市場は規格の統一に失敗している

現状では、標準化の過程がない。それがまだ存在しないのは、Apache Community Foundationがもともと、標準化にあまり関心も熱意もない団体だからだ。Apacheはオープンソースへの共同的コントリビューションでは偉大なモデルだから、企業も団体も協力できる。しかしプロダクトの標準化やフォーマルな仕様の開発に関しては、それと類似の組織がない。

今は、Hadoopのニューバージョンが出ると、ベンダがその動作の一部を勝手に変えても、それを止める者がいない。ある顧客のための、何かの問題の修復のためにリリースの一部を書き換えると、その後、その顧客自身ですら、そのほかのアプリケーションが動かなくなり、デベロッパとベンダは新たに生じた問題を直すために時間とリソースを費やすことになる。

今日ではニューバージョンのリリースのたびに、ベンダとデベロッパは、アプリケーションを修復してそれらがHadoopのすべてのバージョンで無事動くことを検証する作業に忙殺され、カスタム化したアプリケーションのHadoopのニューバージョンへのマイグレーションも、なかなか捗(はかど)らない。このような複雑な課題を抱えているので、ベンダ各社のプラットホームサポートはスイスチーズ状(穴だらけ)のマトリクスになり、さまざまなバグや制限のあるツールの中から、無理やりどれかを選ばざるをえなくなる。

目標は、Hadoopベースのツールをできるかぎり使いやすくすることだが、でも現状は、それぞれカスタム化したプラットホーム同士の内戦が、さらに一層カオス的な市場を作り出している。標準化は、スタックの上の方にいる顧客やISV(Independent Software Vendors, 独立ソフトウェアベンダ)にとって良いだけでなく、究極的には関係者全体にとって良いのだ。

標準規格の実装系はリスクを排除する

ではHadoopはどうやってガバナンスを実装するのか? Java Enterprise Edition(JEE)とその標準化のためのコミュニティプロセス(Java Community Process, JCP)は、Hadoopを成功裡に標準化するための優れたお手本だ。ベンダはJava Specification Request(JSR)というものを提出でき、それを優秀なリーダーたちの委員会が検討して採否を決める。

そしてワーキンググループ(作業部会)がその標準規格の参照実装を作り、実際に作るとどうなるかという例を示し、その標準規格の正しい使い方や、できることとできないこと、ISVによるプロダクトの作り方、などをデモする。そうすることによって、Java技術への企業の投資を守り、さらなる採用の拡大に誘う。

‘Java業界’ではさまざまなミドルウェアやアプリケーションのインフラストラクチャが市場に登場しているが、それらのプロダクトもすべてが、この標準規格を実装したものとなる。これらすべての製品がJEEを基盤として構築され、その標準規格(スタンダード)に準拠することを要請される。

Javaのコミュニティはそのようにして信頼性の高いスタンダードを作り、ソフトウェアを前進させ、アプリケーションのエコシステムのための安定的な基盤を提供することによって、需要を増大させていった。対照的にUNIXは、1970年代と80年代に標準化に失敗し、最後にはマーケットシェアをLinuxに奪われた。

さまざまな業界で、Hadoopを使ったアプリケーションの構築が増えている。この怒涛のような動きも、標準化を要請する大きな力だ。これからますますHadoopネイティブのアプリケーションが構想され作られていくし、そんなアプリケーションを作る企業も今後続々登場して、投資家の関心を喚(よ)んでいく。

Hadoopのコミュニティが成長すればするほど、標準化の欠如に起因する困難な問題が、ますます受け入れがたいものになっていく。

〔参考記事: Amazon EMRがSparkを全面導入Sparkの対抗馬Apache FlinkビッグデータとHadoopの9つの神話を暴く。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ビッグデータ対応を軸にITとデータセンターの運用/管理環境を一新するRocanaが$15Mを調達

424442436_fcd1fc9241_o

Rocana(元ScalingData)が、Google Venturesがリードし、General Catalyst PartnersとToba CapitalおよびPaul Sagan(元Akamaiの会長で現在はGeneral Catalystの常勤役員)が参加したシリーズBのラウンドで、1500万ドルを調達したことを発表した。

これで、同社の総調達額は1940万ドルになる。

Rocanaは大型データセンターの問題発見と修復を単純化し迅速化する。各企業のサービスのモバイル化とクラウド化の進展により、それら混成環境における問題発見がますます難しくなっている、とRocanaの協同ファウンダでCEOのOmer Trajmanは説明する。

Rocanaが得意とするのは、問題が起きたときにシステムをずっと低レベルまで下(お)りていって調べる”root cause analysis”(根本原因の分析)と呼ばれる手法だ。

企業はそれまで、理解も制御も容易な、比較的シンプルなシステムを利用していたが、しかし今日では、OpenStack、Hadoop、Dockerなどなど、多様な技術を使いこなさなければならない。これらのツールは一部の困難な問題を解決してくれるが、同時にユーザのシステムの複雑さを増大させる。

General CatalystのパートナーDonald FischerはRocanaに惹かれた理由を、企業ITのこのような環境変化に取り組むための新しい方式を開拓しているからだ、と言う。“私の眼下に広がる視野の中では、いろんなものが複雑性を増し、とくにデータセンターでデプロイされるものが、(単一ベンダのストレートなソリューションではなく)ますます異種混成的になりつつある”、と彼は述べた。

しかも彼の耳に入ってくるのは、シンプルなデータセンターのために設計された従来型のツールが、時代遅れで使い物にならない、という声だ。“ITの運用をを管理するためのツールを見渡すと、どれも老馬だ。IBMやHP、BMCなどのツールさ。どれも、DockerやOpenStack、Mesosphereなど以前の製品だ。それらのツールが、もはや役に立たない、という声が沸き起こっている”、と彼は語る。

そこで、Rocanaのようなスタートアップに機会が開ける。ファウンダたちは、データセンターの問題の根幹にあるのがビッグデータの問題だ、と見ている。日に日に複雑性を増しているシステムの、いろんなところから、雑多な、統一性のないデータが大量に入ってくる。それらに対応するためにRocanaは、Hadoopと、その関連技術Apache Spark(分散クラスタ、インメモリ処理)とApache Solr(検索エンジン)を選んだ。

アプリケーションのパフォーマンス管理というとNew RelicやAppDyamicsなどのサービスがすでにあるが、Trajmanによると、彼らはどちらかというとRocanaがやってることを補完するものだ。

“New Relicはアプリケーションのレベルでパフォーマンスやその問題を理解させるが、うちのようにインフラまで下(お)りて行くと、まったく違う光景が見えるのだ”。

つまり彼によるとNew Relicは、アプリケーションのどこで何がおかしくなっているか、を教えてくれるが、Rocanaはインフラストラクチャのレベルでユーザが問題を詳細に理解し、それらを修復する方法を提供する。

ITの運用スタッフに詳細なインフラストラクチャとソフトウェアの分析を提供する、という点ではむしろ、DataDogがコンペティタかもしれない。

いずれにしても、市場の特定の部分だけを対象に頑張っているスタートアップは、それほど多くはない。Rocanaは、20名の社員がボストンとサンフランシスコにいる。Trajmanは、今回得られた資金で社員数を2〜3倍に増やしたい、と言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Hadoopのクラスタの最適化管理を行うPepperdataが$15Mを調達

15558382212_a81f9f4a3a_k

HadoopのクラスタのパフォーマンスをチューニングするサービスPepperdataが、新たな投資家Wing Venture PartnersとCiti VenturesおよびSilicon Valley Data Capitalが率いるシリーズBのラウンドにより、1500万ドルの資金を調達した。これまでの投資家Signia VenturesとYahooの会長Maynard Webbも、このラウンドに参加した。これで同社の資金調達総額は2000万ドルになる。

Hadoopはビッグデータを処理/操作するための、定番的な、オープンソースのソフトウェア集合だ。Pepperdataは協同ファウンダのSean SuchterがかつてYahooの検索技術のチームリーダーで、そのときにHadoopを利用する初の商用システムを組み上げた(と同社の紹介ではなっている)。

そういった経験に基づいてPepperdataは、Hadoopのクラスタのパフォーマンスを最適化する。もう一人の協同ファウンダChad Carsonに言わせると、要するにHadoopは無脳なスケジューラだ。ジョブを順次動かすことはできるが、ユーザ企業のニーズやステータスに応じて適切なプライオリティを決める能力はない。

Pepperdataは、そのスケジューラを細かく調整し、Hadoopのジョブのプライオリティを決めて、リソースの割り当てを最適化し、ユーザ企業のサービスレベルの低下を防ぎ、その向上を導く。

社内の特定の部署が高いプライオリティを必要としているときでも、そのままでは低いプライオリティのジョブが実行されてしまうときがある。

“うちのシステムは低いプライオリティのジョブがCPUやネットワークやディスクの利用を占領しているのを見つけて介入し、高いプライオリティのジョブにそれらのリソースを回す”、とSuchterは説明する。

彼によると、それは力づくの処理ではなく、繊細な介入だ。低いプライオリティのジョブからリソースを完全に奪うのではなく、必要なぶんだけをプライオリティの高い方へ回す。

Carsonによると、同社のシステムはプライオリティの調整以外に、クラスタ全体の有効利用も図る。たとえば、メモリは2.5GBあれば十分なジョブが、4GBも割り当てられていたりする。Pepperdataはユーザのシステム全体のリソース利用状況を調べ、無意味に確保されているリソースを見つけたらそれらを可利用プールへ戻す。そうすることによって、システムの稼働効率を上げるのだ。

Pepperdataのインストールには15〜30分かかるが、ユーザはインストールした直後から30から50%のスループットの向上を体験する。それはPepperdataがリソースの割り当てを最適化した結果だ。

Pepperdataが新たな顧客のシステムにインストールされたら、同社はほぼ一週間、状況をモニタする。そして、モニタした結果に基づき、また顧客企業のジョブプライオリティに基づいて、システムのリソース利用のさらに細かい微修正〜最適化を図る。

これまでPepperdataの主な顧客はPepperdataの効用をすぐに理解できるHadoopの初期からのユーザだったが、最近では銀行やヘルスケアや通信など、特定の分野への売り込みに力を入れている。

2012年にSunnyvaleで創業したPepperdataは、最近ニューヨークにもオフィスを開いた。社員は約30名だが、技術と営業の両部門とも増員し、年内には50名程度となる予定だ。

同社は売上をクラスタのノード数で表しているが、これまで同社のライセンスを売ったノードは約1万に上(のぼ)る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Hadoopの利用を使いやすいSaaSで提供するAltiscaleが$30Mを調達

【抄訳】

Hadoopといえば、企業のデータセンターの複雑なオンプレミスのセットアップを連想しがちだが、Altiscaleはそういう複雑な部分をすべてクラウド上で面倒見て、かんじんのHadoopの利用インタフェイスだけをSaaSとして提供する。同社は、その使命の継続のために今日(米国時間12/9)、シリーズBで3000万ドルの資金を調達した。

このラウンドを仕切ったのはNorthgate、これに前からの投資家Sequoia CapitalとGeneral Catalyst Partnersが参加した。これでAltiscaleの資金調達総額は4200万ドルになる。

Hadoopは、ビッグデータを処理するためのオープンソースのプロジェクトだ。

【中略】

AltiscaleがHadoopのベンダとして特異なのは、最初から、企業が抱えるHadoopのワークロードをクラウドで処理するという、根っからのクラウド企業としてスタートしたことだ。ファウンダでCEOのRaymie Stataは曰く、Hadoopは簡単に使えるものではないし、仕上げの粗い部分もある。彼が前にいたYahoo!では、社内に大きな組織を作ってHadoopに取り組んでいたが、ふつうの会社にはそんな贅沢はできない。

それが、彼がAltiscaleを作った主な理由だ。サービスがクラウドにあれば、大から小までもっといろんな企業がHadoopを利用できるし、またビッグデータの処理についても相談に乗ってあげられる。処理の根幹だけでなく、ちょっとしたヘルプの相談もある。企業はそういう問題を自分で抱え込んで悩むのではなく、解決をAltiscaleに求めればよい。

そして彼によれば、Altiscale自身はHadoopのエキスパートだから、企業が解決に数日を要していたような問題も、数時間で解決してあげられる。それでなくとも企業のIT部門は、いろんな問題を常時、山のように抱えているのだから。

Hadoopのサードパーティベンダは数が多く競争も激しい。それらの中でHortworksは最近、IPOにこぎつけた。この前の3月にはClouderaが、シリーズFの資金調達に際して40億ドルを超える評価額を達成した。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google Cloud Platform–Cloud Storage上でHadoopを簡単に使えるためのコネクタを提供開始

かねてからGoogle Cloud StorageはHadoopに対応しており、デベロッパはデータをここに置くことによって、分散コンピューティングによる高度なデータ分析ができる。そして今日(米国時間1/14)Googleは、新たなコネクタをリリースして、Google Cloud Platform上でのHadoopの利用が、より容易にできるようにした。

クラスタやファシステムの管理をそのGoogle Cloud Storage connector for Hadoop(HadoopのためのGoogle Cloud Storageコネクタ)がデベロッパに代わって行うので、デベロッパは物理レベルの面倒な管理業務から解放され、データの処理に専念できる。

Googleが2003年に開発したGoogle File Systemは、今ではHadoopの土台だ。HadoopはApache Software Foundation(通称Apache)が管理するオープンソースの分散コンピューティング環境で、データをサーバのクラスタ上に分割分散して分散処理によるデータ分析を行う。今ではHadoopのまわりに、多様なソフトウェアやサービスから成るエコシステムが形成され、ClouderaやHortonworksなど多くの企業がそれを支えている。

Google Connector for Hadoopは、Googleの最新のクラウドストレージシステムColossusを使用する。また、シンプルなコネクタライブラリを使用して、Hadoopに直接Google Cloud Storageへアクセスさせ、データ処理を行わせる。

Googleは、このコネクタの利点をいくつか挙げている。HadoopのクラスタをGoogle Cloud Storageが一か所で管理するので、デベロッパはHadoopの使用をすぐに開始できる。Google本体のスケーラビリティを利用するので、可利用性がつねに高い。データのコピーを持つ必要がないので経費節約になる…つまり、バックアップ用にコピーを作るなどは、Google Cloud Storage自身が勝手にやってくれる。

今やHadoopは、ビッグデータ分析の分野における主流派だ。先月の記事でも書いたように、Hadoopは、Twitterなど、毎日ペタバイトのオーダーでデータを処理するインターネット企業にとって欠かせない技術だ。また一般企業でも、処理する情報量の爆発的な増大とともに、やはりHadoopを利用せざるをえなくなっている。

しかしHadoopを本格的かつ有効に利用するためには複雑な技術課題が多く、高度な経験知識をもった技術者を何人も必要とする。そこで今回のGoogle Cloud Storage Connector for Hadoop(Hadoop用のGoogle Cloud Storageのコネクタ)のようないわば‘仮想技術者’がいろいろ登場することによって、Hadoopを誰もが気軽に使えるものに、していく必要があるのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AWSがHadoopビッグデータのクェリツールImpalaをサポート

Amazon Web ServicesにImpalaのサポートが加わった。これはClouderaがGoogleに倣って開発したクェリツールで、大量のデータを並列処理によりリアルタイムで処理する。Impalaでは、デベロッパがAWSのElastic MapReduceの上で、SQLふうの言語を使ってクェリを行える。それは高速でアクセス性も良く、オープンソースの分散コンピューティングシステムHadoopでSQLの利用が増えていることを示す一つの例でもある。またImpalaは、より広い視野で見ると、この市場ではGoogleの影響がとても大きいことを示す例の一つでもあり、新しいデータプラットホームや従来よりもリッチなアプリケーションエコシステムを作ろうとする人たちの多くが、Googleの先行製品を参考にしている。

昨年世に出たImpalaの場合は、GoogleのDremelがベースだ。これはビッグデータ分析におけるGoogleの先駆的製品、広大なクラウド宇宙の全域にわたって保存されているデータをクェリするMapReduceの後継製品で、GoogleのPM William Vambenepeによれば、DremelはGoogleのデータ分析プラットホームBig Queryのベースでもある。Hortonworksが発表したTezは、同社のStingerプロジェクトの一環で、HadoopをクェリするデータベースHiveを使用する。Hortonworksによると、Stingerは通常のSQL文によるクェリをペタバイトクラスの大規模データに対し、従来の100倍のスピードで実行する。

Citus Dataの分析データベースも、やはりGoogle Dremelがベースだ。これはPostgreSQLデータベースに対する並列処理で高速なクェリを行う。またMapRはApache Drillを使って大量データに対する高速クェリを提供する。そしてHadoopをベースとする分析データベースJethroDataも、Google Dremelのやり方に倣っている。

“Adaptive Analytical Platform”でこれらすべての企業/製品に先行するHadaptは、オープンソースのApache HadoopにSQLのネイティブ実装を持ち込んでいる。

Dremelの大きな影響力の理由

Hadoopは、ペタバイトのオーダーでデータを処理するTwitterのようなインターネット企業にとって重要な技術だ。また既存の企業にとっても、昨今はデータの量がこれまでになく増加しているので、Hadoopのありがたみが増している。Impalaは、こういった新世代のデータユーザに、利便を提供する。Impalaを使えば、高度な専門技術がなくても、データをクェリできるのだ。

これまでのHadoopは、高度な知識能力を持つ専門技術者でないと扱えないしろものだった。そういう人たちは初期のデータサイエンティストと呼ばれ、プログラミングの能力とクラスタの管理能力、そしてデータ分析の技術を持っていた。そういうビッグデータ技術者たちは、大量のデータをそれぞれ独自のやり方で処理し分析していたインターネット企業から巣立ってきた。たとえばJeff Hammerbacherは、Facebookを辞めてClouderaの協同ファウンダになった。Yahoo!でApache Luceneを使ってオープンソースの検索エンジンを作っていたDoug Cuttingは、そのプロジェクトのためにHadoopを作って利用した。Luceneも、その初期の作者がCuttingだ。そのCuttingも、今ではClouderaで仕事をしている。

Googleは、MapReduceで先陣を切った。それは、ノードの集合を、データを並列処理するためのクラスタとして扱った。複数のクラスタに亙ってデータをマップし、それを縮小(reduce)して答えを得た。

そしてそのMapReduceを超える技術であるGoogle Dremelは、次世代のHadoop技術の柱となる製品だ。それは、そのほかの、HivePigといったオープンソースのプロジェクトとともに、成長し続けるエコシステムを形成し、それらが一体となって、より高級な言語でMapReduceの複雑さ~難解さを抽象化する。

Dremelの強みは、データ分析がバッチでなくリアルタイムの瞬時であることだ。しかしそれは最初、Googleの…主にオンライン広告のための…大規模な関係データベースGoogle F1をクェリすることを、目的として開発された。

ImpalaもDremel同様、その分析能力が売りだ。したがってそれは、ビジネスインテリジェンス(BI)のための視覚化技術Tableauなどの、補完製品とみなされることが多い。Impalaでデータを迅速にクェリし、その結果をBIツールが利用するのだ。

Hadoopそのものは、アプリケーション開発のためのプラットホームではない。しかしImpalaのようなアプリケーションに奉仕するツールの普及および多様化に伴って、Hadoopがアプリケーションのベースとなる機会が今後ますます増えるだろう。たとえば今年の初めに発表されたHadoopの最新バージョンでは、MapReduceを抽象化してスケジューラやリソースマネージャとして使うYarnの新バージョンが同梱された。これによって、それまでのHadoopでは難しかったスケーリングが可能になる。

Hadoopから生まれるアプリケーションのエコシステムは、すでにImpalaやYarnにその兆しがある。どちらのツールもHadoopの外見を単純化し、エンドユーザ(アプリケーションデベロッパ~BIユーザ)の能力を深化する。またConcurrentが商用化したHadoopのためのアプリケーションフレームワークCascadingがある。TwitterEtsyAirbnbなどが、その顧客として名を連ねている。

この市場(ビッグデータアプリケーション市場)は、長年Googleが先頭を走ってきた。しかしHadoopとプラットホームレイヤのイノベーションにより、Googleと後発グループとの差は縮まりつつある。

画像提供: Electric Sheep, Creative Commonsによる)

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


AWSがHadoopとそのエコシステムをアップデートしてビッグデータ分析プラットホームのサポートを一新

Amazon Web Services(AWS)がそのElastic Map ReduceプラットホームをアップデートしてHadoopの新バージョンを導入するとともに、同社のデータ分析エコシステムのサポートをアップデートした。

Elastic Map Reduceは、大量のデータを処理するためのAWSのプラットホームだが、ほかのベンダと違ってAWS自身がホストするサービスであるため、Hadoopとその周辺のエコシステムを、それらオープンソースのプラットホームの更新とペースを合わせてアップデートすることが重要な課題となる。

今回の最新アップデートではHadoopを2.2にアップデートし、またHivePigHBaseMahoutなどHadoopの同伴技術もバージョンを新たにした。AWSのブログ記事によると、それによりクラスタの始動時間が短縮され、データの拡大能力が強化され、マッパーM7がサポートされるようになった。MapR M7は、Hadoop用のNoSQLデータベースHBaseの有料サービスだ。

Elastic Map Reduceの今回のアップデートには、 Hadoop MapReduceの次世代アーキテクチャYARNのサポートも含まれる。

これはAWSの大型アップデートであり、Hadoopだけでなく、ここ数年で築かれたエコシステム全体をカバーする。Hadoopはファイルベースのシステムであり、データベースとしてはHBaseを必要とする。Pigは分析プラットホームであり、多くの場合ETL(Extract/Transform /Load)処理で使われ、そしてMahoutは機械学習ライブラリだ。

AWSはこのところ、データ分析技術のサポートにますます力を入れている。先週BI(ビジネスインテリジェンス)プロバイダのJaspersoftがElastic Map Reduceをサポートするようになったのも、そのことの成果だ。JasperはAWSとの付き合いが長く、AWS Marketplaceで入手できるそのサービスには、すでに500社の顧客企業がいる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


データサイエンティストのいない企業でもHadoopを有効利用できるビッグデータ分析サービスDatameer

最近は、データサイエンティストでないふつうの人にデータ(とくにビッグデータ)分析を提供するプラットホームが増えているが、Datameeerもその一つだ。コンピュータといえば仕事でスプレッドシートを使うぐらい、という圧倒的多数のコンピュータユーザが、こうやって徐々に本格的なデータ分析に接近しつつある。

Datameer 3.0には、“Smart Analytics”(スマートアナリティクス)と呼ばれる機能があり、それによって、データサイエンティストたちがつねに自分でゼロから計算するようなワークを、あらかじめ組み込んでいる。そろそろ、こういう抽象化〜ラッパー化があってもよい頃合いだ。Hadoopの普及率は今ではとても高いから、今度はそうやってそのアクセス性が向上すべきだ。

そのための重要な課題が、雑多なデータの統合化だ。すべてのデータを集めて、それらを分析可能に整理すること。また物理面では、サーバクラスタのセットアップ、という課題もある。さらに、技術者でない者にも理解できるユーザインタフェイスも必要だ。そしてもちろん、分析結果がユーザの仕事に活をいれる、有益なものでなければならない。

Datameer 3.0のSmart Analyticsは、以下の4つの方法でデータ分析を単純化する:

  1. レコードをクラスタ化してデータ集合中に有意なグループが見られるようにする。データは、位置データ、写真、顧客のオペレーティングシステムなどさまざまだ。このクラスタ化により、ユーザはたとえば顧客リスト中の顧客データを有意義に分類できる。
  2. デシジョンツリーが目的とする結果を表示し、その中の多様な要因を分析して、デシジョン(意思決定)に導く過程を一望する。
  3. カラムディペンデンシー(column dependencies, カラム間依存関係)により異なるカラム間の関係を表示し、データ間の、それまで自明的ではなかった結びつきを明らかにする。たとえば、位置と疾病タイプの関係や、職階とクレジットスコアの関係が分かったりするだろう。
  4. ユーザの履歴データに基づいて、次はどんなものに関心を持つかを予測し、個人化されたリコメンデーションを生成するような、リコメンデーションエンジンを提供する。この機能により企業ユーザはユーザに対し、より関係性のあるより有意義なリコメンデーションができるようになる。社内にデータサイエンティストがいなくても。

CEOのStefan Groschupfが今日(米国時間6/24)のブログ記事で、市場の現状について述べている。Hadoopはそのほかの技術と同様に進化してきているので、今や何かをスクラッチで(==ゼロから)作る必要はない。Hadoopベースのサービスの中には、カスタム化ができず、長期的なメンテナンスが困難なものもある。しかし今では、Hadoopを企業がより現実的に活用できるためのサービスもあるのだ、と。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


56台のRaspberry PiをLEGOの棚に収めたPiCloud, クラウド環境を目の前の実物で学習

Raspberry Piにはできないことって、あるだろうか? ここにもまた、この35ドルのマイクロコンピュータの…それを56個重ねた…おもしろい実装がある。PiCloudと呼ばれるこの作品は、Pi用のおあつらえ向きの棚としてLEGOブロックを使っている。(PiとLEGOを組み合わせた作品は、ほかにもあった。)

この作品はグラスゴー大学のコンピュータ科学専科大学院(School of Computing Science)で教材として作られ、学生たちはこれをハックしながら、AmazonのAWSなどで使われているクラウドプラットホームのインフラストラクチャと、その技術(仮想化など)について勉強する。

PiCloudの56のRaspberry Piは、LEGOで作った4段の棚に収められ、16のEthernetラインで接続されている。内14がPiのネットワーク用、2つがスイッチ用だ。各PiボードがRaspbian Linuxを動かし、さらに3つのLXC仮想化コンテナがLinuxのインスタンスを動かす。

PiCloudが動かしているソフトウェアは、“シンプルなワークロード”と呼ばれるlighttpdなどと、実験用の“人工的なワークロード”と呼ばれるlookbusyなどだ。PiCloud上のそのほかの実験的なハッキングとして、libvirtdockerなどもある。Hadoopも動かしているが、これは目下ネイティブのLinuxインスタンス上のみで、LXCのインスタンスではない。

学生の一人が、PiCloudのAWSふうWebコンソールインタフェイスを作った(下図):

PiCloudの作者たちは、これは“永遠に未完の作品だ”と言う。教材としてはたとえば、“libvirtが使えるようになったら”ovirtなどの標準ツールも導入したい。やりたいことが、まだまだある。また教材以外に、これは研究材料でもあり、コラボレーションの素材でもある。詳しくは、プロジェクトのホームページを見てみよう。

PiCloudは、Piが利用者のさまざまな目的やミッションに奉仕することの好例であるとともに、いわゆる“メーカー”たち(参考記事)の人気者であることも示している。Raspberry Pi Foundationは元々、イギリスでもっと多くの子どもたちがプログラミングを学べるために、この低価格の超小型コンピュータを作った。PiCloudも今まさに、そのために役立っているのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))