第一回のドローンカンファレンスInterDroneに見るドローン未来学とそのための課題

solo_social_3

小型のドローンが急速に進歩している。最初はやや高度なリモコン玩具にすぎず、‘ドローン’という呼び名にも批判があった。ドローンと言えば、少なくともある程度の自律性があって、たとえばテロリストの暗殺に使われたりする無人機を指すからだ(一般市民も巻き添えにするが)。しかし今では、技術が名前に追いつきつつある。ドローンはますます自律的になり、そのため、近未来のスタートアップのための多様なビジネス機会が開かれつつある。

先週(9/6-12)は、今年で第一回となるInterDroneカンファレンスがラスベガスで行われ、そのキーノートで3D RoboticsのCEO Chris Andersonが、今やドローンは“パイロットのいない航空機”から“プロペラのあるスマートフォン”に変わりつつある、と述べた。

そのときのインタビューでAndersonは、3DR社は今、自律飛行の研究開発に重点投資をしており、AIと機械学習のエキスパートたちを雇用して技術の改良を進めている、と語った。

初期のドローンの性能は、人間操縦者の技能に大きく依存した。今のドローンは一部の基本的な機能は自律的に行うが、障害物の回避などの能力はまだお粗末だ。GPSで目的地に向かうことはできるが、その航路の途中に壁があってもまっすぐ飛び続ける。木や壁を避(よ)ける機能は比較的容易に実装できるが、たとえば送電線のようなものを認識させるのは難しい。いずれにしても今のドローンの大きな技術的障害が、障害物の回避なのだ。

ドローンが本当に“プロペラのあるスマートフォン”になったら、それは物のインターネット(IoT)の一部になり、それだけでなく、インターネットに接続されたほかのもの(ドローンや航空機が多いだろう)と対話できる。これにスマートな(電脳の)障害物回避が加われば、ドローンの自律性がより本格的になり、さらに新しい用途が開ける。

そしてドローンの自律性が増せば、人間はその複雑な操作に悩まなくなり、ドローンが集めてくるデータに集中できるようになる。

InterDroneに集まったAndersonなどの業界人の多くが、ドローン産業の現状をWebの初期になぞらえている。ということは、これからはドローンという新しい技術と、さまざまな既存の技術との組み合わせを考えるべきなのだ。インターネットとWebの登場によって、その後、小売業も不動産業もレストランも、行政すらも、あらゆる業態がディスラプトされてきたように。それはたとえば、Web + レストラン = OpenTable、といった式で書き表せるだろう。

誰もが思いつくユースケースもある。精密農業や、測量、それにAmazonのおかげで荷物の配達も。最近では、ドローンが撮影している映像をリアルタイムで仮想カンファレンス(ビデオによるカンファレンス)にストリーミングする、という企業も現れている。

このような簡単な応用例はまだまだたくさんあるが、あまり人が考えつかないようなものにも、おもしろいアイデアがいろいろある。

ドローンをめぐる規制はまだ流動的だから、ドローンでできることとできないことの境界も曖昧だ。でもベンチャーキャピタリストたちは、YuneecへのIntelの投資やさまざまなドローン指向ファンドにも見られるように、早くも走りだしている。ファンドの多くはハードウェアへの投資をねらっているが、しかし今日では、ドローン関連のソフトウェア開発も大量に行われている。そしてそれらのすべてが、将来FAAと問題を起こさぬように、適正に調製されるべきだ。AirwareSkywardのような企業ユーザ向けドローンソフトウェアのメーカーは、とくにそれを願っている。

というか、今日の主導的な趨勢としては、多くの企業が明日のドローン+(drone+, ドローンプラス)の時代に備えてインフラの整備に励んでいる。

ドローンを飛ばせることだけでなく、ドローンが集めてくるデータの分析も重要だ。それは典型的なビッグデータ分析の課題だが、今後はドローン固有のビッグデータソリューションがいろいろ登場するだろう。たとえば農家には、ドローンが送ってくる映像を毎朝分析する能力がないから、農家にそのためのわかりやすいダッシュボードを提供するソフトウェア企業が必要とされる。それは、潅水の適期適量を知るといった精密農業のニーズだけでなく、害鳥や害獣を追い払うといった、ドローンの古典的な活躍分野もありえる。

自分の身の回りの環境を完全に認識できる、真の自律的ドローンが登場し、同時にセンサとデータ分析の技術がさらに進歩し、良質な規制が完備したら、ドローンのポテンシャルが完全に開花するだろう。

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

ビッグデータの誤解

smalldata

編集部記:Slater Victoroffは、Crunch Networkのコントリビューターである。 Slater Victoroffは、Indico Data SolutionsのCEOである。

私のカスタマーはいつも嘘をつく。何を購入できるかについては嘘を付かない。どの程度カスタマーサービスが必要かに関しても嘘を付かないし、どのくらいの期間で料金を支払えるかについても嘘をつかない。

彼らは、持っているデータ量に関して嘘を付くのだ。

最初、妙なクライアントが一人いるだけだと思った。そのクライアントは毎月十億単位のコールを処理し、「大量のデータストリーム」があると話した。そのような大量のデータを分析するには、高額な費用がかかると私が説明すると、本当のことを話し始めた。彼らは、次の数ヶ月で日に100万コールになるようにしたいと言った。そのような前向きの目標を達成できたとしても、最初に主張したデータ量の100分の1にも満たない。

このような主張をするのは、このクライアントだけではなかった。企業が実際に取り扱うデータ量は、彼らが主張するデータ量の100分の1程度であるという法則を私は見出した。

「ビッグデータ」は「ビッグ」ではない

企業は保有するデータセットの量を誇張する。釣り人が釣った魚の大きさを誇張するのと同じようなことだ。彼らは、止めどないテラバイト単位の情報があると主張する。そう主張する理由は明白だ。情報量が多ければ多いほど良いことだと考えているのだ。

マーケティング資料を見て、データ量が会社に千里眼を与えると思うのだ。従業員のパフォーマンスから自社のカスタマーベースの好みまで、ありとあらゆることに関する深い洞察が得られるという。データが多いほど、人がどのように意思決定をし、何を購入し、何に気持ちが動くかが分かるようになる。そうだろう?

しかし、マーケティング資料とは釣り人のように誇張しているのだ。多くの企業は主張するほどデータを保持していない。そして典型的に、彼らが所有するデータのほんの一部からしか深い洞察は得られないものだ。

「ビッグデータ」の大半は大して便利ではない

何故企業はデータ量を偽るのか?自社を大企業のように見せたいからだ。AmazonFacebookGoogleのような企業が大量のデータを収集して所有しているという話を聞いているのだろう。企業はそのような大量のデータを集めるリーチがないにも関わらず、更にはデータを購入する資金がある訳でもないが、そのトレンドに乗りたいと考えているし、他社にもそう思われたい。データアナリストのCathy O’Neilが最近投稿したブログ記事にはこう記されている。多くの人は「普通のテクノロジー企業にデータを振りかければ、次のGoogleになると考えている」と。

しかし大企業でも、大量に集めたデータのほんの一部しか利用していない

ビッグデータは「ビッグ」でもなく、良いデータは更に少ない。

Twitterは、 一日8テラバイトの情報を処理している。その数値は、ツイートから何か洞察を得ようとしている小さな企業を圧倒するだろう。しかし、ツイートの実際のコンテンツはどのくらいのデータ量だろうか?Twitterのユーザーは 毎日5億のツイートをしていて、ツイートの平均文字数は60文字だという。簡単な計算をすると、実際のテキストコンテンツはたった30ギガバイト分だ。8テラバイトの1%の更に半分にも満たない。

このパターンは他でも見られる。Wikipediaはインターネット上で最も多くのテキストデータを保持しているが、全てのテキストデータは一つのUSBに収まる程度だ。世界中にある全ての音楽も600ドル程度で購入できるディスクドライブに収めることができる。似たような例は他にもあるが、重要なことは、ビッグデータは「ビッグ」でもなく、良いデータは更に少ないということだ。

スモールデータを最大限に活かす

もし大量のデータセットが役に立たないのなら、何故それが話題になるのだろうか?何故なら、全ての人の役に立たないということではないからだ。ディープラーニングのモデルを使用することで、ノイズとサインを区別し、専門家が体系化するまで数ヶ月かかるようなパターンを見つけたりすることができる。しかし、一般的なディープラーニングモデルは、ラベルが付いた大量のデータが必要だ。そして、大量のデータセットにラベルを付けるには、何万ドルもの費用と何ヶ月もの期間を要する。その仕事はFacebookやGoogleといった大企業が行うべきだろう。多くの小さな企業はこのことに気づかず、購入しても使い道のない大量のデータ容量を取得するのだ。

このような企業には別の選択肢がある。既に保持しているデータから価値を見出すことができる。

確かに、ほとんどのディープラーニングのアルゴリズムは大量のデータセットを必要とする。しかし、私たちは人が推論するように、少量のデータからでも傾向を導きだすようにそれを設計することができる。転移学習を用いることで、大量のデータセットでアルゴリズムを精錬した後に少量のデータ分析を行うことができる。これで学習プロセスが100倍から1000倍も効果的になる。

ビジネス目的に転送学習を活用しているスタートアップをいくつか取り上げる。

  • DatoGraphLab Createというプラットフォームは、大量の画像を瞬時に認識して分類することができる。ユーザーは既に鍛えたディープラーニングモデルを使用して、既知の特徴を判断するのに応用することができる。あるいはImageNetなどのデータセットを活用して自分たちで新しいモデルを構築することもできる。
  • Clarifaiの画像認識APIは、画像に説明文をタグ付けすることができる。そうすることで写真アーカイブの検索が楽になるのだ。彼らのディープラーニング・アルゴリズムは、ストリーミング動画でも機能し、広告主がユーザーが視聴したばかりのコンテンツに関連する広告を配信することが可能となる。
  • MetaMindのAIプラットフォームは、個人が発信したブランドに対するツイートの内容がポジティブかネガティブなものかを判断する。また、そのツイートを囲むTwitterの話題の主要なテーマを特定することができる。カスタマーの意見から洞察を得たい企業は、何千のアカウントから集めた年齢、性別、位置情報のデータより便利なものとなるだろう。

これらのサービスを利用するのにプログラマーである必要もない。Blockspringでユーザーはコードを一行も書かずとも、ExcelのスプレッドシートだけでAPIを組み合わせることができる。

このような選択肢がある中、テラバイト級の大量のデータを購入する意味が薄れる。また、誇張する必要もまるでない。

データの未来は「ビッグ」ではなく「スモール」なことは明確だ。

[原文へ]

(翻訳:Nozomi Okuma /Website/ twitter

自動車のビッグデータ解析行うスマートドライブが産革から最大6.6億円の資金調達、アクサ損保と新商品の開発も

150805smartdeive

車速やエンジン回転数など150種類にも及ぶ情報を取得するために自動車に用意されている「OBD-IIコネクタ」。ここに専用のデバイスを接続してリアルタイムに運転情報を取得。この”自動車のビッグデータ”を解析し、保険や車輌動態管理、CRMツールなど、さまざまなサービスに利用できるテレマティクス(自動車や輸送車両などに対して、移動体通信を通じてサービスを提供すること)情報のプラットフォームを構築しようとしているのが、北川烈氏率いるスマートドライブだ。同社は8月5日、産業革新機構から最大6億6000万円の資金調達を実施することを明らかにした。

開発中のデバイス

開発中のデバイス

スマートドライブは2013年10月の設立、ベンチャーキャピタルのANRIからシードマネーを調達して自動車向けのデバイスや連携アプリなどを開発していた。2014年8月からは千葉県・柏の葉にて実証実験を実施していた。また総務省主催の新事業創出支援プログラム「I-Challenge!:ICTイノベーション創出チャレンジプログラム」の1号案件にも採択された。

またスマートドライブでは、アクサ損害保険との業務提携契約を締結。資本参加も決定しているという。両社は任意保険のアクサダイレクト向けに新商品および新サービスの開発を進めているという。

新商品・サービスの具体的な内容については明らかにされていないが、リアルタイムに取得する情報をもとに、ドライバーの運転特性に応じて保険料が割引される「テレマティクス保険」を提供することになるのだろう。

米国などではこの動きが先行しているが、国内でもすでにソニー損害保険の「やさしい運転キャッシュバック型」、あいおいニッセイ同和損害保険「つながる自動車保険」といったテレマティクス保険が今春以降登場している。

都市の大規模建設プロジェクトから発生頻度の高い問題やエラーをビッグデータ分析で事前に取り除くVernox Labs

scaffolding

都市における建設や土地開発は、スケーラビリティとは縁遠いビジネスの典型だ。

まず、設計はそのときかぎりで、再利用性がない。土地利用の政策は各地域や国によってまちまちで、標準性がない。現場のサイズも大小まちまち、使用する素材も建物ごとに違う。つまりそれは、スケールするビジネスではない。

予算オーバーが日常化し、それはまれな例外ではない。

そこで、このほどY Combinatorから孵化したVernox Labsは、過去のプロジェクトから得られる多様な非定型データを活用して、上記のような、いろんな面での予測不可能性をできるかぎり排除しようとする。そして、ゼネコンや設計家やプロジェクトマネージャが、よくあるエラーをなるべく犯さないようにする。

まず、住居系のプロジェクトや病院などプロジェクトのタイプ別に、ゼネコンと設計事務所とのあいだで交わされる大量のメールやWordの文書やExcelのファイルなどを人工知能が読んで分析する。

そしてそれらのデータから、予測可能事のチェックリストないし設計の事前リビューを自動生成し、プロジェクトマネージャはそれと、新しい企画の細部を照らし合わせる。またGoogleのような検索エンジンを使って、部位や素材に対して下請けや建設労働者が抱く疑問に、即座に答える。

協同ファウンダのVinayak Nagpalはこう語る: “建設プロジェクトは、ひとつひとつが閉鎖的な蛸壺(silo, サイロ)だ。新規のプロジェクトは、できたてほやほやのスタートアップに似ている。しかしそれでも、毎回々々、同じような問題があちこちに生じてしまうんだよ”。

Nagpalは、トラブル続きのNokiaを辞め、Michael Savaianoと共に、UC BerkeleyのCenter for Entrepreneurship & TechnologyでVernox Labsを立ち上げた。

Savaianoは言う、“いつも、同じようなことを見忘れている。なにか、カーテンウォールのようなものが、毎度々々、過去に何千回も作られている。だから、過去の状況が分かれば、そこから学べるはずなのだ”。

Savaianoの説明によると、デベロッパは完成物の具体的なイメージを持っている。それを設計家に持ち込むと、設計家は設計を作る。次に、ゼネコンが登場して、その設計をいじくり回す。そこから、設計者と建築者とのあいだの、ありとあらゆる行き違い、コミュニケーションのエラーが生じてくる。

“今のビルは、とても複雑だ。その設計は、なお一層複雑だ。素材も、いろいろありすぎて複雑だ。建築を進めるシステム全体が、ものすごく複雑だ”、と彼は語る。“しかしそれでも、これまではプロジェクトのデリバリを助けるものが何もなかった。その状況は、何百年も変わっていない。われわれは、そこに着目したのだ”。

かつて大企業相手の営業をやっていたSavaianoは、パイロット協力企業を二社確保した。そのデベロッパ二社の名前は、当面非公開だ。Vernox Labsのサービスは今は無料だが、いずれは有料になる。

“うちがやるのは、起きうる問題を事前にシミュレートし、求めに応じて予測を作り出すことだ”、とSavaianoは述べる。

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

ビッグデータ処理/分析をシンプルなDaaS(Data as a Service)として提供するCazenaが$20Mを調達

4746718211_b06e579af9_o

企業のデータ処理を助けるCazenaが今日(米国時間7/22)、Formation 8率いるシリーズBのラウンドにより2000万ドルを調達したことを発表した。参加した投資家はAndreessen HorowitzとNorth Bridge Venture Partnersで、両社は昨年10月の800万ドルのシリーズAにも参加している。

Cazenaを作ったのは主にNetezzaの元社員らで、CEOはNetezzaのデータコンプライアンス担当ゼネラルマネージャだったPrat Mogheだ。彼はNetezzaが2010年にIBMに買収されて以降、IBM傘下のNetezzaで、ストラテジとプロダクトとマーケティング担当のSVPを務めていた。

数年間IBMにいたMogheは、Netezzaが解決しようとしていた問題を新たな視点から見なおしてみたい、と思うようになった。“データ処理の次の10年はどうなるだろう、ということを考えた。とくに、企業はHadoopのような新しいビッグデータスタックと、どうやってうまく付き合っていくのか”、と彼は語る。“とくに中規模以上の企業では、クラウドを前向きにとらえて処理のアジリティを向上させようとしているが、既存のプラットホームの複雑さとセキュリティの問題を前にして、立ちすくんでしまう傾向もある”。

2015-07-22_1318

Cazenaは、企業のビッグデータ処理を大幅に単純化することをねらっている。基本的にCazenaでは、データ処理ジョブのセットアップがわずか3クリックですむ(とMogheは言うが、現実はもうちょっとややこしい)。同社のサービスのキモは、このデータの分析にはどんな技術を使うべきか、という判断を自動化して、人間ユーザが直面する複雑性を減らしていることだ。次にプロビジョニングも自動化し、ワークフローを顧客に合わせて最適化し、そして管理する。データ処理ジョブはHadoopでもSparkでもMPP SQL(AmazonのRedshiftなど)でも何でもよい。

顧客のワークロードのタイプや予算、求める処理速度などに応じてCazenaは正しいインフラストラクチャを用意し、データの処理を進める。“こういう、data as a service(DaaS)と呼べるようなサービスは、新しいカテゴリだと思う。これをキーワードとして、大企業のクラウド化を支援していきたい”、とMogheは述べる。

Cazenaがその新しいプロダクトについて対外的にも語れるようになるまで、ほぼ二年を要している。今少数の大企業の協力のもとにベータを動かしているが、サービスの一般公開はまだまだ先のようだ。

Mogheによると、一般公開の暁には、料金体系にもイノベーションをもたらしたい、という。それは、単一の料金で処理費用、クラウドの費用、サポートの費用、SLAなどをすべてカバーする、きわめて単純化された料金体系だ。今のクラウドサービスは、ギガバイトとかノードの数などの(技術用語的な)数量ベースで課金するから、かんじんのユーザが費用を予測することができない、と彼は、こんな部分でも単純化を売りにするつもりだ。

今回得られた資金は、同社の技術開発と、営業の強化、そしてパートナーシップの構築に充てられる。

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

不動産市場全体をリアルタイムビッグデータとして表現し操作したいVTSが$21Mを調達

vts

不動産売買のVTS(元View The Space)が、OpenView Venture Partners率いるシリーズBのラウンドにより2100万ドルの資金を調達した。これに参加した既存の投資家Trinity Partnersは、VTSの評価額をほぼ1億ドルとしている。今回の資金の用途は、不動産取引におけるデータの活用の拡大、だ。

OpenViewのAdam Marcusはこう言う、“不動産は市場がきわめて大きいし、資産分類の中でも世界最大だ。それなのに不動産を管理している人びとの仕事のやり方は原始的だ。いまだに、何もかもExcelだし、情報は紙でやりとりされている”。

不動産売買に関わる人たち(ブローカー、物件のオーナー、投融資者など)がVTSを利用すると、彼らは任意のデバイスからいつでもリアルタイムでコラボレーションでき、自分たちのポートフォリオを管理できる。今出ている物件とそれらの見込み客たちが、このプラットホームの上で出会い、各ユーザ(アクセス者)に提供されるダッシュボード上に、関連物件とその所有者、そしてそれらの市場動向などが、総覧される。〔余計な訳注: 日本の不動産サイトのかったるさ、徒労感、ありゃーヒドイわ!! 〕

VTS phone

不動産売買の市場規模は12兆ドルと言われる。その意思決定がデータドリブンになれば、費用効率の向上も膨大な額になるだろう。

たとえばニューヨークのビルのオーナーが、ブローカーたちから、新しいスペースを探しているテクノロジ企業が前年より2割以上増えている、という最新情報を入手したとしよう。オーナーは一部の壁を壊し、会議室をたくさん作り、スタートアップたちの入居にふさわしいビルにするだろう。そして、お客にテク企業が多いブローカーにこのビルを持ち込む。ビルの改造に投じた費用が、大きく生きることになるだろう。

VTSの協同ファウンダRyan MasielloとNick Romitoは、9年間、ニューヨークでブローカーをやっていた。だから彼らは、不動産取引の痛いところも痒いところも、すべてよく知っている。

VTSがそのプラットホーム上で扱っているオフィススペースの総量は、約15億平方フィートだ。ご参考までに、ニューヨーク、マンハッタンの全オフィススペース(2013年)が5億2000万平方フィートだ(これはもちろん物件として出回っている量の総量ではない)。今では同サービスを、BlackstoneやJLLのような大手ブローカーや大家(おおや)たちも利用している。

今回の資金は海外進出にも投じられ、年内にロンドンとシドニーにオフィスを開く。

Romitoは語る、“今の不動産業界のエコシステムの、一員だとも、一員になりたいとも、思ったことはない。われわれ自身が新しいエコシステムになって、すべての不動産売買がその上で行われるようにしたい。それにはあと2年か、あるいは5年はかかると思うけど、でも我が社の今の成長スピードは、予想の10倍はいってるね”。

[原文へ]
(翻訳: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

インターネット上の音楽をソフトウェアで自動的にマスタリングするLANDRが$6.2Mを調達

screen-shot-2015-07-07-at-10-47-18-am

自分の曲をSoundCloudにアップロードしたけど、音がいまいち、Timbalandがプロデュースしたような、パワフルな音にしたい、と思っているミュージシャンは多いはず。そんな彼らのためにビッグデータ分析を利用して音楽のマスタリングをするLANDRが、620万ドルの資金を調達した。

このシリーズAのラウンドをリードしたのはWarner Music Groupで、前からの投資家Real VenturesとYUL Venturesが参加した。ラッパーでレコードプロデューサーのNasや、DJのRichie HawtinとTigaとJohn AcquavivaとPete Tongが始めたファンドPlus Eight Private Equity、そしてHDGLも参加した。

マスタリングというのは、アルバム制作の最後の段階で、それまでに録音したすべての音を、ミックスして一つにまとめる仕事だ。レコードやCDの原盤(マスター)を作る、という意味でマスタリングと呼ぶ。

LANDRのCEO Pascal Pilonはこう説明する: “マスタリングは要するに音に臨場感を与える仕事で、まるでバンドが自分の目の前で演奏しているような音を作り出すんだ。ふつうはいろんな楽器やボーカルなどをばらばらに録音して、それらをミキシングするから、その段階ではナマの臨場感はまったくない”。

プロのレコーディングアーチストはマスタリングの技術者を起用して、各楽器の音量や、低音のレベル、曲の圧縮(無駄を削ぎ落とす)などをやってもらう。そのために、一曲あたり数千ドルかかることもある。

“ナマのステージでは、できるだけ良い音が出るように、セッティングに時間をかけることができる。でもインターネット上のストリーミングは、そこが弱いね”、DJでLANDRに投資もしているJohn Acquavivaはこう述べる。

LANDRはインターネット上の音楽をナマなみの迫力にするために、人工知能によるマスタリングエンジンを利用する。そのサービスの料金は、ユーザが求める音のクォリティによって、月額6ドルから39ドルまでだ。

Pilonは曰く、“これまでの50年ぶんぐらいの、何万ものファイルや曲を分析して、マスタリングの技術者たちが下(くだ)している意思決定のタイプを理解した。そしてそういう意思決定を、リアルタイムで再現できるようにした”。

マスタリングは、技術的なプロセスであると同時に、クリエイティブな仕事でもある。たとえばEDMの曲をアコースティックギターでカバーした場合、マスタリングは原曲とはまったく違ったものになる。

だからLANDRも、少なくとも今のところは、人間技術者を超えた、とは豪語しない。これまで同社はおよそ50名のオーディオやマスタリングの専門家たちによってその技術を磨いてきたが、現状では25万人のユーザの多くが、お金を払ってマスタリングの専門技術者を起用することのできない、アマチュアたちだ。

“ミュージシャンやプロデューサーの多くがGarageBandなどのソフトウェアを使って曲を作っているが、低予算のため、最後のマスタリングの工程を省くことが多い。だから、まとまりのない、未完成な曲が、そのままアップロードされるのだ”、とPilonは語る。

最近は、プロのアーチストがLANDRを使って、途中の段階の試作的なミキシングやマスタリングを素早く行う、という例が増えているそうだ。彼らは制作のいちばん最後に、金と時間をかけて、人間技術者を起用するのだ。

LANDRのマスタリングエンジンIonianは、今1.0だが、Pilonの究極の目標は、SpotifyやSoundcloudなどのストリーミングサービスが、そのすべてのオンラインオーディオに、マスタリングのいわばスタンダードとして、LANDRを使ってくれることだ。

“うちを使うと、どんなクリエイターの音でも良い音になるから、LANDRはインターネット音楽のための、誰もが使う標準技術になりたい。今後は、音楽だけでなく、ビデオの画質向上にも挑戦したい”、とPilonは語っている。

[原文へ]
(翻訳: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

IBMがApache Sparkプロジェクトに3500名を投入、未来に生きる道はオープンソースしかないと悟る

5439493601_dc049b0258_o

IBMが今日(米国時間6/15)、オープンソースのビッグデータプロジェクトApache Sparkに3500名の研究員を割り当てる、と申し出た。また併せて同社は、同社の機械学習ツールIBM SystemMLのオープンソース化を発表して、それをビッグデータと機械学習の最先端の地位に押し上げたいという意図を鮮明にした。

この二つの技術はIBMが最近志向している、クラウドとビッグデータとその分析技術、およびセキュリティを軸とする自己変革戦略の一環だ。今日の発表と並行してIBMは、Sparkを同社の分析プロダクトの核とすることと、企業等のSparkプロジェクトを支援する商用サービスDatabricksとも協働していくことを誓った。

Sparkは、ビッグデータを処理するエンジンとしては世界最速を自称している。

IBMアナリティクス部門の製品開発担当VP、Rob Thomasはこう言う: “Sparkはビッグデータ分析のオペレーティングシステムだ、と考えたい。将来的には、ビッグデータを利用するときには誰もがSparkを使うようになるだろう。Sparkを使うと、データへのユニバーサルなアクセスができるからだ”。

Thomasによると、Sparkはその成長のペースがオープンソースの歴史上最速にはやかったため、IBMも注目せざるをえなかった。これまでの数年間、Sparkを使ってきたが、昨年Apacheのプロジェクトになってから、一層、注目度が高まった。

DatabricksサービスとIBMとの仲は、まだほんの数か月だが、彼らは機械学習がこのApacheプロジェクトの弱点だと聞かされて以降、IBMの機械学習技術に深く関わるようになった。

こういう場合のIBMのやり方として、単に3500名の研究員を投入するだけでなく、もっと全面的な関わりになる。同社は、同社のPaaS Bluemixの顧客に、今ではアプリケーションの重要素材としてSparkを使わせている。

さらに同社の10あまりの研究部門がSpark関連のプロジェクトに取り組んでおり、近くサンフランシスコにSpark Technology Centerというものをオープンしてデータサイエンス振興のためのコミュニティの形成に取り組み、Sparkを利用する各種のアプリケーションを作っていくとともに、Spark本体の開発も加速する。

IBMのプロジェクトには教育の部分があるのがふつうだが、今回もその例外ではない。IBMの発表によれば、同社はAMPLabやDataCamp、MetiStream、Galvanize、MOOCのBig Data Universityなどと協働して、Sparkを使いこなせるデータサイエンティストを最終目標として100万名育成する。立派な目標だけど、今現在データサイエンティストは、世界中からかき集めても最大で25万人ぐらいしかいないという説もあるから、遠大な目標でもある。

IBMはこれら一連の活動を慈善事業として行うわけではなく、ビッグデータが今後の同社のビジネスの重要な核になる、と信じているからだ。それが全面的に活性化できるための、多様な要素からなる基盤を今から築いておきたい。しかもオープンソースのプロジェクトに本気でコミットすることで、オープンソースのツールを使ってビッグデータや機械学習に取り組んでいる多くの企業との良好な関係形成を図れる。それによりIBMには、コンサルティングなど、そのほかのビジネス機会も開ける。

IBMはお金持ちだから、SparkやOpenStackのようなオープンソースプロジェクトにそのリソースを投ずることによって、会社の体質そのものをリフレッシュし、未来の新しいビジネスに向かう道を築きたいのだ。

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

コンテナを利用してビッグデータ分析を誰もが使えるツールにしたPachydermがシード資金$2Mを調達

pachyderm

ビッグデータの分析や加工をDockerなどのコンテナを利用して行うオープンソースのプラットホームPachydermが、200万ドルのシード資金を獲得した。

このシードラウンドに参加した投資家は、Data Collective、Foundation Capital、Blumberg Capital、Susa Ventures、Crunchfund(TechCrunchのファウンダMichael Arringtonが創業したVC)、Caffeinated Capital、Soma Capital、およびAce & Company。またPaul Buchheit、Jonathan Abrams、Avichal Garg、Jay Jamisonらのエンジェル投資家たちも参加した。

同社の立ち上げは、本誌が1月に報じた。Pachydermはオープンソースのツールだが、プログラマがこれを利用して大量のデータ分析を行うときは、Javaのコードを1行も書く必要がなく、MapReduceの動作原理などを知らなくてもよい。そのため、過去の類似のツールに比べてビッグデータ分析の敷居が相当低くなり、多くのデベロッパにとって、自分にも利用できる技術になる。Pachydermのキャッチフレーズは、“MapReduceのパワー -(マイナス) Hadoopの難解さ”、だ。詳しい説明は、上記の記事にある。

Pachydermの協同ファウンダJoe DolinerとJoey Zwickerによると、資金は技術者の増員と、このところ増え続けているユーザからの要望に応じて、新しい機能を加えていくことに使われる。“うちのコンセプトへの関心がとても多いことに、正直びっくりしている。それには、コンテナのパワーも貢献しているだろう”、とDolinerは述べる。企業だけでなく、大学などからの関心も大きいそうだ。今後の数か月で、人びとがもっと容易にデータ分析ジョブを書けて共有できるためのWeb上のハブ、いわば‘ビッグデータ分析のためのGitHub’を作りたい、と彼らは言っている。

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

農家自身による情報ネットワークFarmers Business Networkが$15MをGoogle Venturesなどから調達

farms

[筆者: Christine Magee]
2050年には100億に達すると予想されている世界の人口を支えるためには、それまでの35年間に全世界の農業生産量を倍増する必要がある。Farmers Business Network(FBN)にとってソリューションは、ビッグデータをベースとするグローバルな農家間ネットワークだ。それを築くために同社は新たに、1500万ドルの資金を調達した。

Google Venturesがそのラウンドをリードし、これまでの投資家Kleiner Perkins Caufield & Byersとインパクト投資企業DBLが賛助した。FBNのこれまでのベンチャー資金調達総額は2800万ドル弱になる。

農家は種子や肥料などに年間数十億ドルを投じているが、今のところ彼らには、使うべき種子、栽培量、肥料や栄養分の地域によって異なる最適配分などについて知るための信頼できる情報源がない。

FBNの協同ファウンダCharles Baronはこう言う: “これまで農家は、大学が高度に制御された環境で行う実験からのデータや、種子企業からの情報に依存して種子や苗を選んでいた”。

しかしそれらの情報源は、営農の現実を正確に反映していない。

“種子企業にアドバイスを求めることは、Exxonにおすすめの車を聞くことに似ている。Exxonなら必ず、ガス食いのオフロードカーをすすめるだろう”、とBaronはジョークを言った。

昨年11月にローンチしたFBNは、17の州の計700万エーカーの農地からデータを集めたが、その後データ量は1ヶ月に30%のペースで増加している。同ネットワークは今では、16種類の作物の500種類の種子のパフォーマンスを評価できる。

しかし、大量のデータを集めることが、農業のイノベーションではない。現代の農業機械は技術的には非常に高度であり、播種の方法から土壌成分の変化まで、あらゆることを記録できる。

FBN Dashboard

FBNは、全国の農家から集めたデータを正規化し、その分析結果を見られるダッシュボードを提供している。そこでは、地域の気象や土壌データなど、外部情報も利用される。FBNのネットワークに参加している農家からの、それらの報告に基づいて農家は、高収量を望める作物とその生産方法について、情報に裏打ちされた意思決定ができる。

しかし、実は、農家も情報の過剰に悩まされている。

“最新式のトラクターの運転台に坐ると、目の前に6つのスクリーンがある。そのそれぞれが、異なるフォーマットでソフトウェアからのデータを表示している”、とBaronは言う。そこでFBNは、35種類の農業用ソフトウェアからのデータを、統合しようとしている。

insideatractor

“大農場が使っている精密な農業機械では、ソフトウェアがその農場のデータを分析するから、昨年の灌水や肥料の問題点を把握して修正できる”、FBNの取締役会に入ったGoogle VenturesのAndy Wheelerがそう言う。

“しかし複数の農家や農場のデータを分析したり比較したりできないから、あまり有効なデータ利用はできない。複数の農家がデータを共有してインサイトを得るようになれば、どんな土壌にはどの種子が合うか、どんなやり方が収量を上げるかなど、意思決定に役立つ有効な情報が得られるようになる”、とWheelerは述べる。

情報の得られ方や利用の仕方で、農家の費用や収入に大きな違いが生ずる。FBNに参加している農家が1年に購入する種子は数千ドルにも相当するが、その種子の5-10%ぐらいが地域や土壌などの条件に合ってないことが事前に分かれば、種子の価額だけでなく、その後の諸費用も含め、相当額の経費を節約できる。

“今、農作物の価格は安いし、しかも農業のための機械、燃料、肥料、種子等々の費用はものすごく高い。農家の利幅はカミソリの刃のように薄いから、まとまった利益を得ることはほとんど不可能だ”、とBaronは言う。

しかし利益はともかくとして、エーカー当たりの費用効率を上げ、収量を最大化できれば、世界的な食糧危機の到来を遅らせることはできるだろう。

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

国の研究所からスピンアウトしたスタートアップDescartes Labsは衛星画像の分析データを農業分野などに売る

descartes_headshots_proofs-56

【抄訳】
合衆国政府の研究機関で7年間仕事をした連中がこのほど、深層学習(deep-learning, ディープラーニング)による画像分析を行うスタートアップ(非公開企業)Descartes Labs(デカルトラブス)としてスピンオフし、330万ドルの資金を獲得した。

Descartes Labsが主に行うのは、衛星画像を分析してそこに写っているものを理解し、それらから有意なデータを取り出す仕事だ。Descartes LabsはLos Alamos National Lab(ロスアラモス国立研究所)から昨年8月に公式にスピンオフしたが、投資家が関心を持つようになった今は、活動を加速させようとしている。そのために、サンフランシスコとロスアラモスの両方で人を増やし、またコンピュータの能力もパワーアップしたい。

Descartes LabsのCEO Mark Johnsoはこう言う: “うちがやっているのは、ふつうの画像認識技術ではない。うちでは画像に対して物理学を適用し、犬やコーラの缶を探したりはしない。遠隔探査と天体物理学には共通の部分が多いことが、分かってきた。空でたくさんの写真を撮る場合は、センサが正しく調製されていなければならないし、それらの写真を正しく縫い合わせて、大量の分析をしなければならない[天体物理学]。そしてそのときの望遠鏡を地球方向に向けたら、(地球〜地表に対して)それとまったく同じ問題を抱えることになる[遠隔探査]”。

同社はこれから、地球全体の農業を調べ始める。合衆国などでは農業のデータが充実しているが、そういうところは全地表のごく一部にすぎない。だから、データを衛星の画像に頼ることになる。そしてそうなると、それはお役所の問題ではなくて、Descartes Labsが機械学習を駆使して取り組むビッグデータの問題になる。

衛星から来るデータは、可視スペクトルのものだけではない。たとえば赤外線領域のデータは、農作物を調べるためにとても役に立つ。

このような大規模な問題に取り組んでいるDescartes Labsのところには、相当強力なコンピュータがあるに違いない、かな? ところが、以前なら巨額な国の予算を使えるところにしかなかったような強大な処理能力が、今ではAmazonのAWSやGoogleのCloud Compute Engineなどから安価に得られるのだ。今や国の研究機関の一部ではなくなったDescartes Labsも、自前で巨大なスーパーコンピュータを作ったり買ったりする代わりに、それらのサービスを安く利用している。

同社の機械学習のコードの効率が良いから、それで十分だ、という面もある。彼のチームが優秀だということでもあるが、たとえばロスアラモスの科学者だったMike Warrenは、宇宙の素粒子1兆個の振る舞いを調べるシミュレーションを動かしたこともある。そのほかのスタッフも科学者や宇宙研究者で、画像認識や機械学習を支えるハードサイエンスに取り組んでいる。

ビジネスの展望はすでにはっきりとある。たとえば衛星画像から得られる農業に関するデータは、商品取引などの業界で珍重される。彼らはその限られたデータから、世界中の主要作物の作柄を予測したりするのだ。そういうデータの質を高めることの方が、各作物の栽培や輸出入に関する大雑把なデータよりも、同社のビジネスにとって価値がある。

2014-10-12-L8-044034_10N_008_066_543

衛星画像の応用分野はもっと多様だが、同社はとりあえず農業からスタートすることにしている。農業の分野も、同社がやってるような大きな視野のデータは、まだどこにもないからだ。Johnsonによると、330万ドルはプロダクトを世に出すためには十分な額であり、スタートアップにつきものの多少の失敗やその修正も許される、という。

投資家の一人Venky HarinarayanはKosmixのファウンダだった人物だが、その会社は買収されて今ではWalmart Labsになっている。

1972-09-18-LM1-047034_10N_008_066_321

その彼が曰く、“生まれたばかりのスタートアップの重要な課題の一つが、具体的な市場を見つけることだ。大きな市場ではなくて、今後急速に成長する市場が欲しい。大きな市場は、ほやほやのスタートアップにとって荷が重すぎる。大市場の攻略には、大きな資本が必要だ。スタートアップが対応しやすいのは、だから急速な成長が見込める市場の方だ”。

Descartes Labsはロスアラモス国立研究所で7年間育てられて、そのあとスピンアウトした。しかし、国のお金で動いている研究所からのスピンアウトは必ずしも簡単ではない。まず、交渉事項がうんざりするほど多い。また、これまで資金の心配をしたことのない人たちは、スタートアップを経営するノウハウを持っていない。そこで投資家たちは、Descartes LabsのCEOとして、Ziteの元CEOで、FlipboardのプロマネでもあったMark Johnson、すなわちスタートアップのベテランを持ってきたのだ。

【後略】

[原文へ]
(翻訳: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

自動化マーケティングの将来…データから顧客や市場の現実を知ることがベース

marketingfuture

[筆者: Vik Singh]
編集者注記: Vik SinghはInferの協同ファウンダでCEO。それまでの彼はSutter Hill Venturesの正社員起業家。彼は検索やソーシャルネットワークやコンテンツオプティマイゼーションの分野で13件の特許を持っている。

その業界に詳しいDavid Raabの説では、マーケターの三人に二人は既存のマーケティング自動化ソフトウェアに大なり小なり不満である。またBluewolfの調査報告書“State of Salesforce”は、マーケティングソフトへの投資のわずか7%しか、まともなROIを得られないという。この、企業や商店に大きな利益をもたらすはずの自動化マーケティングは今、標準性を欠く乱雑な多様化とユーザの不満が激化しているのだ。

Marketing Automation Market Share (Source: Datanyze)

マーケティング自動化サービスのマーケットシェア(出典: Datanyze)

自動化マーケティングがそうなってしまった原因は、そのルーツがメール爆弾であることにある。そういうシステムはユーザのターゲットページや入力フォームやWebのアクティビティデータやトリガや、などなどに長年勝手に貼り付いてきたから、だんだん、やることが多くなって肥大し、ユーザがうんざりするような、口数ばかり多い無能ソフト/アプリケーション/サービスへと頽落した。

たとえば下の図はEloquaのスクリーンショットだが、この積み木ゲーム(Jenga)のような画面を見ると、われわれ自動化マーケティングの連中が今マーケターたちに提供しているものが、どんだけややこしくて脆(もろ)いものであるか、が分かる。われわれ、と言ったのは、こんな面倒な推奨ワークフローをマーケターに提示しているのは、Eloquaだけではないからだ。

Infer TC Image

自動化マーケティングが自動化しない

最大の問題は、上図のようなワークフローが、良い見込み客を見つけるための画一的で普遍的な法則とされ、具体的なデータに基づく指針になっていないことだ。

たとえば、こんなワークフローだ: “ユーザがこのリンクをクリックして、そのあと、あのリンクを二度クリックしたら、二日後にこのメールを送りなさい…”。これが、絶対的なルールとして書かれている。ユーザがWebサイトのデザインを変えたら、この(多くの人が無視したであろう)ワークフローは、もう使えない。

こんな低レベルな構成では、多様な現実への対応がほとんどできない。こういうワークフローを作った者がいなくなったら、どうするのだ? ワークフロー地獄は深刻なパフォーマンスの問題ももたらす。

私が実際に見たある企業は、自動化マーケティングシステムのすべてのワークフローを8時間以上もかけて処理してから、やっと見込み客をCRMシステムに渡していた。ネットで見つけた見込み客に営業が接触するまで、8時間以上もかかるのだ。自動化マーケティング約束した、スピードと単純化と、そしてまさに自動化は、どこにあるのだ?

2018年にはどのマーケティングプラットホームが優勢か?

今は、自動化マーケティングを再発明すべき時だ。そのプラットホームは、スケーラブルで応答の速いデータベースと、データに連携したワークフローシステムを提供する必要がある。それは、見込み客や顧客に関するデータを調べることに最適化された、軽いシステムでなければならない。また、サードパーティが特殊な目的の応用システムを構築できるために、クリーンなAPIを提供すべきだ。

そんな方向に向かうための条件は、早くも整いつつある。まず、膨大な量の外部データ、先進的なデータサイエンスと、さまざまな特殊目的に対応するマーケティングアプリケーションの登場。3年後の2018年には、新世代の自動化マーケティングソフトウェアが出揃うだろう。そして2018年に優勢になっているマーケティングプラットホームは、予測能力があって、どんな見込み客に対しても適切なリコメンデーションを出力する、オープンなプラットホームだ。

最初に予測ありき

明日のプラットホームは、何もかも詰め込んだ一枚岩的な自動化マーケティングシステムではなく、インテリジェントで痩身で、多くの小さな専門的アプリケーションに接続できる基幹プラットホームだ。それは豊富なデータに基づいて、顧客とのさまざまなタッチポイント(接触点)に適切なリコメンデーションを配布する。

最新のデータサイエンスと、それに基づくビッグデータ分析や機械学習技術により、そこらにあるさまざまなデータから重要な信号を読み取ることが、できるようになっている(Netflixのムービーのリコメンデーションは一体どうやっているのか、考えてみよう)。またコンピューティングのインフラストラクチャが安価になったので、多様な顧客モデルの作成とそれらに基づく具体的な個人化を、個々の企業に合わせてできるようになった。今ではConversicaLyticsRelateIQ、そしてInferのような企業が予測分析を誰の手にも届くようにし、見込み客の育成やキャンペーンの最適化、見込み度の判定など、自動化マーケティングのこれまでの課題だった項目に対しても、より効率的で効果的なソリューションを提供している。

予測能力のある人工知能(predictive intelligence)は今、すべての企業がこぞって求めている。それがさまざまなニッチのアプリケーションと結びついたプロダクトやプラットホームは今後、誰にでも使えて、具体的なアクションに結びつくシステムとして普及するだろう。それは使いやすいだけでなく、企業の進化の方向性に即したものでなければならない。そんなシステムは、ワークフローの構成など面倒なタスクも自動化するので、ユーザはパフォーマンスのチューニングとか劣化などを心配する必要がない。こういう予測型のシステムは、一人々々の顧客のアクションについて自分で学び、適応し、そして自分を改良していく。

マーケティングとセールスを循環させるリコメンデーション

(フルサークル (full-circle)リコメンデーション)

一人の顧客や見込み客に、マーケティングとセールスが別々に対応すべきではない。未来のプラットホームは顧客データをめぐる派閥性を解消し、すべての、マーケティング/営業機能を一元化する。今すでにKnoweldgeTreeなどのサービスは、営業とマーケティングとのあいだの風通しを良くすることによって、それを実現しようとしている。次のベストアクションやベストコンテンツが、片方の独断で決まらないようになる。

顧客に関する予測も、営業とマーケティングが共有する。セールスデータの履歴をよく吟味して、良い見込み客とはどんなタイプか、を見つけ出す。そしてその情報を、営業とマーケティングの両方に浸透させる。さらに、その結果に対しても然りだから、この情報活動には循環性がある。そこで‘フルサークル’と呼ぶ。

良い見込み客を拾い上げるための予測モデルを、短期的なCR(コンバージョンレート)重視型から長期お買い上げ重視型に変えることができれば、カスタマーサクセスチームがそれを利用して顧客のロードバランスを図れる。

オープンなプラットホームを目指せ

次世代のマーケティングプラットホームは強力なAPIを提供する。Autopilotがその好例だが、でもどんな企業でも、焦点を絞った、インサイトに満ち満ちた、由緒正しいツールを作ることはできる。それらは今はびこっている、何でも屋のような、インテリジェンスのないプラットホームより10倍も優れている。

たとえば仕込みキャンペーンをやる場合は、予測インサイトと痩身的システムならではのスケーラビリティを利用して、それまで無視してきた仕込み用データベースから見込み客を見つけるだろう。そういうデータベースは、見込み客の見込み度の得点を、彼らのWebビヘイビアに応じて絶えず更新しているから、仕込み客を見つけるのにはうってつけだ。そしてそういう見込み度の高い見込み客に個人化されたメールを送ったり、そのリストをセールスに回すことによって、仕込みキャンペーンが回り出す。

今ではマーケティング関連のサービスが2000近くあると言われる。CRMのSaaS化や自動化マーケティングが流行(はや)ってきたためだが、SalesforceのAppExchangeの影響も大きい。でも自動化マーケティング関連のサービスは、まだ幼児期にあるため、充実したエコシステムやAPIがなく、したがって成功例に乏しい。

でも、個々のアプリケーションのレベルでは、優れたものが現れ始めている。そして今後のオープンなマーケティングプラットホームは、CRM型ではなくデータ型(データ分析型)になるだろう。そもそも、CRMにデータを提供したり、またCRMからデータを拾う側、すなわちデータサイドが、顧客情報を長期的に多く集積しており、それらが効果的に分析されれば、マーケティングに大きく貢献しうるのだ。

クラウドコンピューティングが伸びていくとき、“ソフトウェアの終焉”という言葉が言われたような意味で、予測型プラットホームは自動化マーケティングというカテゴリーに革命をもたらす。未来のマーケティングは、キャンペーンの管理や見込み客の行動調査などを超えたものになる。

新しいプラットホームは、ワークフローとプログラムとアクションの形を、今後ますます強力になる予測インサイトの枠組みの中で変えていく。それらのワークフロー等は、マーケティングとセールスのあいだのギャップを、予測を糊としてCRMと自動化マーケティングをくつける(一体化する)ことにより、橋渡しする。

身軽でスケーラビリティの大きいデータプラットホームというものがまずあり、そこに予測のレイヤを置く。そしてコンバージョンを高めセールスを成功に導く良質なアプリケーションが、予測を活用する。初めに予測ありきのソフトウェアが世界を食べている。今その歯は、マーケティングとセールスに食らいついたところだ。覚悟を決めよう。

〔訳注: 本稿の筆者は、機械学習による予測ソフトのベンダ。自分が前に買ったり調べたりしたものに基づいて、来る日も来る日も、同じようなものの広告ばっかし見せてくれるのは、そういう‘機械的’ソフトが猛威を揮っているから。マーケティングが、その企画者実行者の人間知と人間性と創造力に基づく、クリエイティブな営為、新しいものや新しい発想を作り出す仕事であることは、ここでは完全に無視されている。本当のヒット商品や人気店は、どうやって生まれているのか、考えてみよう。データの集積と分析は重要だが、それらの処理の形や方向性を決め、処理結果から何かに気づくのも、人間性の能力だ。〕

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

Amazon Web ServicesはデータウェアハウスサービスRedshiftの基盤としてデータ移行プラットホームAmiatoを買収していた

screen-shot-2015-04-20-at-16-29-50

Amazon Web Services(AWS)は、2012年にローンチしたRedshiftにより、サービスのリーチをデータウェアハウジングやビッグデータ分析の分野にも広げてきた。CTOのWerner Vogelsによると、それはAWSの中でも今いちばん急成長のプロダクトだ。このRedshiftには、AWS生え抜きの技術者たちだけでなく、買収によって獲得した人材も開発に関わっていたことが、このほど明らかになった。

実は昨年の5月にAmazonは、NoSQLデータベースから非定型データを取り出してRedshiftにポートするプラットホームAmiatoを秘かに買収していた。ポートされたそれらのデータは、Amiatoの技術やそのほかのBI(business intelligence)ツールで分析できる構造を持つ。

そういう買収があったらしい、ということは今月初めにBloombergが初めて報じた。本誌は、Amazonと、Amiatoの元協同ファウンダでCEOのMehul Shahらにコンタクトして、買収の確証を得た。

Amiatoに投資しているSignatures Capitalは、Amiatoの一件はうまくいったイグジット(出口, exit)だ、と言う。Amazonに買収されたのは2014年の5月だそうだ。

Screen Shot 2015-04-20 at 16.58.41

Amiatoの元社員(の一部)も、LinkedInなどで見ると、今はAWSにいる。

AmiatoのTwitterアカウントは2013年以降更新されていないが、サービスを停止したという告知はない。

Amiatoは、2012年にY Combinatorで孵化されているときはNou Dataという名前で、その後Bobby YazdaniやData Collective、Andreessen Horowitz、Ignition Partnersらから200万ドルを調達した

しかしながら、観測筋によれば、同社はローンチ前から問題を抱えていた。要するに同社は、Redshiftがもうすぐローンチするという時期に、Redshiftのデータウェアハウジングサービスと同じプロダクトを開発していた。Amiatoが2013年3月にステルスを脱したとき、同社は準定型データのためのビッグデータA/Bテストプラットホーム、を自称していた。

しかしその後同社は進化し、ホームページでは次のように述べた: “AmiatoのSchema-lift™技術はNoSQLデータベースからすべてのデータを取り出し、それらを自動的に変換し、Amazonのペタバイト級のデータベースRedshiftに連続的にロードする。それらを直ちにSQLでクエリしたり、TableauやExcelにコネクトしたり、あるいはLookeのようなBIディスカバリツールで分析できる”。

元CEOも社員の一部も今はAmazonにいるのだから、それは技術と人材獲得を目的とする買収だったようだ。

RedshiftのローンチやAmiatoの買収等で最新のデータ技術をサービスの基盤に据えたAWSは、最近では2lemetryを買収するなどにより、今度はIoT方面の地固めに着手している。AWSがこうして買収に走るのも、過去にはなかった傾向だ。

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

GoogleのビッグデータサービスCloud Dataflowが公開ベータで一般利用可に、BigQueryはヨーロッパゾーンに対応

cbf_008

Googleが今日(米国時間4/16)、ブラッセルで行われたHadoop Summitで、同社がクラウドから提供しているビッグデータプロダクトのアップデートを発表した。まず、公開ベータで立ち上がるCloud Dataflowは、大量のデータを処理するGoogleの新しいサービスだ。そしてビッグデータ(Googleが提供するビッグデータデータベース)へのクェリを提供するBigQueryが同社のヨーロッパデータセンターにも展開され、また行(row)レベルのパーミッションも導入される。

Cloud Dataflowがデビューしたのは昨年6月のGoogleのデベロッパカンファレンスだったが、これまではずっと非公開アルファで、一般に利用できるプロダクトではなかった。しかしこれからは、関心のあるデベロッパなら誰でもこのサービスをトライし、使用を開始できる。ただしまだベータだから、公式のSLAはない。

Googleのプロダクトマネージメント部門のディレクタTom Kershawによると、ビッグデータに対するGoogleの基本的なポリシーは、複雑性をできるかぎり取り除くことだ。これまで業界を苦しめてきたのは、ビッグデータの取り扱いがきわめて難しいことだった。企業は自分たちが毎日作り出しているデータに大きな価値があることをそろそろ理解してきたが、まだ多くのデベロッパがそれらのデータを扱うるツールの開発で難儀している。Kershawは曰く、“ビッグデータの利用は、もっと民主化される必要がある。Googleにはビッグデータ処理のためのソフトウェア資産が蓄積しているので、これからはそれらを、ものすごく使いやすい形で提供していきたい”。

Cloud Dataflowは、データをストリームとしても、あるいはバッチでも、処理できる。スケーリングは、ニーズに応じて自動的に行われる(ただしユーザが押しこむデータの量があまりにも膨大になったら、Googleからの“適正な”課金が行われる)。デベロッパはCloud Dataflowを利用するためのコードを一度だけ書き、そのあとはGoogleが彼らに代わってインフラストラクチャの設定や操作等をすべて行う。

Cloud Dataflowは一般ユーザ/デベロッパにとって新しいと言えるが、しかしBigQueryは2010年からある。しかし今日からは、ユーザは自分のデータをGoogleのヨーロッパデータセンターでホストできる。Kershawによると、これまでその要望がとても多かったそうだ。データに対するユーザの主権についてうるさいヨーロッパで、Googleがもっと早くそれをやらなかったのが、不思議なぐらいだ。

BigQueryのもうひとつのアップデートは、データベースが行(row)レベルのパーミッションをサポートすることだ。ささやかなアップデートのようだが、Kershawが言うように、実用レベルではとても重要な機能だ。

ひとつのビッグデータデータベースをいろんな部課が利用する、という企業が少なくない。でもたとえばマーケティング部門には、彼らが必要とするデータにはアクセスを許可しても、そのほかの機密性のあるデータにはアクセスさせたくない。ITはそのために、必要なデータのコピーを作って渡す、という方法を採ってきた。しかしそのコピーは通常、データベース本体のアップデートと同期しない。だからマーケティング部門は、正しくない古いデータを使うことになる。しかし行レベルのパーミッションがあれば、データベース本体に安全にアクセスさせられる。〔もちろん、列(column)レベルのパーミッションもある。〕

今回のアップデートにより、BigQueryはテーブル上の行を最大毎秒10万行読み込むことができる。ビッグデータ、たとえばログファイルの巨大な集まりなどを分析するときは、これぐらいのスピードが必要だ。実際、Kershawによると、BigQueryはその目的のためにも、よく使われているそうだ。

Googleのビッグデータツールは現在、BigQueryとCloud DataflowとメッセージングサービスCloud Pub/Subの三本柱だ。Google自身がかねてから、社内的にビッグデータのエキスパートだから、おそらく来月のGoogle I/Oではさらに新しいアップデートやビッグデータプロダクトが発表されるのではないかな。

[原文へ]
(翻訳: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

ビッグデータ分析/視覚化で異色の技術を築いたQuidが早くもシリーズDで$39Mを調達

独自の高度な形でデータの視覚化を行うQuidが、3900万ドルの資金調達を発表した。昨年秋に創業4年を経過した若い企業だが、今回の資金調達がすでにシリーズDである。

Quidは自分のことを、“各種の調査研究とそれらの結果からインサイトを得る過程を加速する人工知能企業で、とりわけ、世界でもっとも複雑な問題を扱う”、と説明している。具体的にはそれは、何百万ものドキュメントを処理して、その結果のヴィジュアルマップを作る、というサービスだ。たとえば企業のために、プロダクトのローンチに対するオンラインの反響を視覚化したりする。

同社のことをかつて本誌TechCrunchは、世界でいちばんうぬぼれのでっかいWebサイトと評したことがあるが、しかし今ではホームページのメインタイトルも、自分たちの技術のマーケティング的な売り込みコピーになっており(上図)、またHyundaiやMicrosoft、Boston Consulting Groupなどメジャー企業の顧客からの評価を引用している

本誌が2010年に同社を取り上げたときには、もっぱら最先端技術を追っていたが、今では対象がもっと広くなっているようだ。Quidによると、現在の顧客数は80で、プラットホームは昨年の初めに一新している。

今回の投資ラウンドを仕切ったのはLiberty Interactive Corporationで、これにARTIS VenturesとBuchanan Investments、Subtraction Capital、Tiger Partners、Thomas H. Lee Limited Family Partnership II、Quidの取締役Michael Patsalos-Fox、Quidの会長Charles Lhoなどが参加した。

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


今なぜApache Sparkが急成長しているのか…各種現場での実用速度を達成したビッグデータ分析

[筆者: Vaibhav Nivargi]

編集者注記: Vaibhav Nivargiはデータ分析サービスのプロバイダClearStory Dataのファウンダでチーフアーキテクト。

今週はApache Sparkの、今急速に大きくなりつつあるコミュニティがニューヨークに集まり、自分たちのコラボレーションによりSparkが今日のもっとも人気の高いオープンソースプロジェクトに育ったことを祝った。

U.C. BerkeleyのAMPLabで2009年にローンチしたApache Sparkは、最近の1年半で急激に人気を高めた。Sparkのコントリビュータは2014年で500名近くになり、Apache Software Foundationと世界中のオープンソースのビッグデータプロジェクトの中でもっともアクティブなプロジェクトになっている。

われわれも、かなり早い時期から、このクラスタコンピューティングのプラットホームに着目し、もはや自分のソフトウェアをすべてスクラッチで作る時代ではない、と感じていた。

それはインメモリの並列処理により、同じくインメモリのHadoop MapReduceの100倍速くプログラムを動かすことができ、ディスクを使った場合でも10倍は速い。これによって複数(〜数10件)のデータソースを瞬時にしてブレンドしたり、統一することができる。

Gartnerによると、2016年には全企業の73%がビッグデータに投資していると思われるが、しかしそれでも、大半の企業はビッグデータのメリットを十分に生かすことができない…彼らはビッグデータを十分に管理できないからだ。

Sparkは今多くの企業や団体が採用しており、2014年のGray Sort Benchmark、Daytona 100TBカテゴリーではソートの世界記録を樹立した。

ビッグデータを扱う場合Sparkには、Hadoopとの互換性という利点もあり、また、そのリッチなAPIにより、JavaやPython、Scala、それにSQLなど、人気の高い言語で、ソフトウェアのコードをよりシンプルに書ける。構造化データと非構造化データの両方を扱え、機械学習やデータマイニングもサポートしている。

Sparkを全面的に統合したアプリケーションは、さまざまな分野の企業の指導者たちに、反復的データ集合の巨大なワークロードを、これまでに彼らが想像したことがないほど高い効率性で処理して、そこから得られるインサイトを提供する。どんなに大きくて複雑なデータに対しても、われわれはSparkによって初めて、データを探究する自由を獲得する。企業内で日々、あちこちに数多くの‘データの孤島’が肥大していても、もはや臆する必要はない。

Sparkのアーリーアダプター

Sparkのアーリーアダプターは、一般消費財や保険、メディア、エンタテイメント、製薬、小売業、自動車などの業界に多い。おおむね、消費者対象の業種が多い、と言える。

一般的な消費財の企業では、顧客分析が日々のビッグデータワークのルーチンになるから、Sparkにいちばん飛びつきやすいユースケースだ。顧客のビヘイビアを分析してそのインサイトやモチベーションを得ることは、消費財企業の毎日の最優先事項だ。これまでこの業種では、製品や顧客に関する多様な、互いに無関係なデータから得た、複数の孤立的な視野しか持ち得なかった。しかし今では店内の製品配置に対する顧客の反応や、オンラインとオフラインのトレンドの違い、地域差などのデータを素早く獲得して、より深い顧客理解に、そして究極的には売上の増に、結びつけることができる。

速いサイクルのデータ分析から迅速にインサイトが得られることによって、サプライチェーンの全体にわたるリアルタイムに近いビューが得られ、地域別に売上の最大化を図れる。原始データは、ERPやサプライチェーン、Dun & Bradstreetのような外部データソースなど、ばらばらなデータとして入手される。そしてこれらをビッグデータ分析により統一混淆(blend)することによって、より深い顧客理解が得られる。この、多種類ばらばらのデータソースの統一〜混ぜあわせという、ビッグデータ分析の手法により、消費財企業のトップは日々の操業に関する全体的な視野を獲得し、それに基づいて、速くて各部門協力的/連携的な意思決定を行うことができる。

同様に、データドリブンなヘルスケアや製薬産業では、全体的な視野やインサイトがより速く入手できることにより、診断から治療へというサイクルを早めることができる。Apache Sparkを利用するとユーザは大量のデータを大きな遅れなく処理でき、結果を全体的なパターンと照合して患者の危機を早期に発見でき、介護等のスタッフに周知徹底できる。このような早期警戒システムは命を救うだけではなく、薬剤、検査、などの費用の削減にも貢献する。

今Sparkは多方面から注目されつつあるが、しかし忘れてならないのは、分散コンピューティングのフレームワークが依然として複雑な生き物であることだ。Sparkだけをベースとするシステムでも、特定の問題集合に対する完全なソリューションを作り出してメンテナンスするためには、いろんな領域にわたるスキルと、細部にわたる相当量の実地体験を必要とする。言い換えるとビッグデータ分析が真に有効であるためには、データサイエンティストの技能と知恵と視点に加えて、経験豊富で優秀なドメインエキスパートを必要とする。

Sparkのプロジェクトが今後健全に進化していくためには、エンタプライズデータインテリジェンスのこれからのイノベーションが、以下の問題に取り組む必要がある:

より有効なビッグデータ分析のために

いろんなソースからデータを持ち込むようになると、そういう多様な情報のとりあえずの置き場として、サイロがたくさんできてしまう。さらに、多くの企業に実際に見られる現象として“データの湖”(data lakes)ができ、互いに脈絡のないデータのごみの山がそこへ放り込まれていく。そういう、現実的にはすっきりと行かないデータの状況に対する、適切な管理が必要だ。

また、ビッグデータ分析を本格的に活用するためには、Spark以外のものも必要である。ドアを開いたのはSparkだが、実際にビッグデータの高速リアルタイム分析の利点を生かせるためには、バックエンドのSparkに、改良され最適化されたAPIや、柔軟なスケーリング、ジョブスケジューリング、ワークロード管理などなどを結びつけていくことが必要だ。

2016年ごろまでには、さまざまな業種の、これまでよりも多くの企業が、Sparkがもたらす価値を理解するようになるだろう。その、サイクルの速いデータ分析がデータドリブンなインサイトをもたらし、人への理解を深め、人間と企業と社会にさらにモアベターな変化を起こす。

Apache Sparkの上に構築されるデータインテリジェンスプラットホームによって可能になる、新しい機能や能力を企業や組織が自分のものにしていけば、タイムツーインサイト(time-to-insights, インサイトが得られるまでの時間)の短縮と高速化により、大きなアドバンテージが得られ、市場における競争力も強化されるのだ。

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