オーディオ ファイアホースの活用:ストリーミング分析からビジネス価値を得る:ウェビナーのトランスクリプト

ファイアホースの活用:ストリーミング分析からビジネス価値を得る:ウェビナーのトランスクリプト

Anonim

Techopediaスタッフ、2016年2月24日

まとめホストRebecca Jozwiakは、業界のトップエキスパートとストリーミング分析について議論します。

あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。

Rebecca Jozwiak:ご列席の皆様 、こんにちは。2016年のHot Technologiesへようこそ! 今日のタイトルは「Firehoseを利用する:ストリーミング分析からビジネス価値を得る」です。これはRebecca Jozwiakです。 私の親愛なるエリック・カバナがここにいられないときはいつでも、私はウェブキャストの司令官の二番目です。

このエピソードは、他のエピソードとは少し異なります。 暑いものについて話しましたが、もちろん今年は暑いです。 過去数年間は暑かった。 常に新しいものが出てきます。 今日は、ストリーミング分析について話します。 ストリーミング分析は新しいものです。 もちろん、ストリーミング、センターデータ、RFIDデータは、必ずしも新しいものではありません。 しかし、データアーキテクチャのコンテキストでは、数十年にわたって安静時のデータに焦点を当ててきました。 データベース、ファイルシステム、データリポジトリ-すべてが主にバッチ処理を目的としています。 しかし、今ではストリーミングデータ、データ感情から価値を生み出すシフトに伴い、一部はそれをリビングストリームと呼んでいますが、実際には、これまで使用してきたデータを保存するアーキテクチャではなく、ストリームベースのアーキテクチャが必要です。高速取り込み、リアルタイムまたはほぼリアルタイムの処理を処理します。 モノのインターネットだけでなく、すべてのインターネットに対応できる必要があります。

もちろん、理想的には、2つのアーキテクチャを並べて、片手でもう片方を洗うのはいいことです。 数日前のデータ、数週間前のデータ、数年前のデータにはもちろん価値、履歴分析、傾向分析がありますが、最近ではライブデータがライブインテリジェンスを推進しているため、ストリーミング分析が非常に重要になっています。

今日はそれについてもっと話しています。 データサイエンティストのDez Blanchfieldがオーストラリアから電話をかけています。 彼にとって今は早朝だ。 チーフアナリストであるロビンブロア博士がいます。 Impetus TechnologiesのStreamAnalytixのプロダクトヘッドであるAnand Venugopalが加わりました。 彼らはこの分野のストリーミング分析の側面に本当に焦点を当てています。

それで、私は先に行き、Dezにそれを渡すつもりです。

Dez Blanchfield:ありがとう。 ここで画面の制御を取得し、前に飛び出す必要があります。

Rebecca Jozwiak:どうぞ

Dez Blanchfield:スライドを掴んでいますが、コアトピックだけを取り上げます。

これをかなり高いレベルに保ち、約10分に保ちます。 これは非常に大きなトピックです。 私は、ストリーム処理とは何か、現在開発中のフレームワークの詳細、およびこれらの大容量ストリームで分析を行うことの意味について詳しく調べるために2〜3日間費やしたイベントに参加しました。

ストリーミング分析が意味することを明確にし、それが実際にビジネスが求めているものであるため、ビジネス価値を引き出すことができるかどうかを掘り下げます。 彼らは、人々に非常に迅速かつ簡潔に説明してもらいたいと考えています。ストリームデータに何らかの分析を適用することで、どこで価値を引き出すことができますか?

ストリーミング分析とは何ですか?

ストリーミング分析により、組織はさまざまな形態のビジネスを通じてビジネスから得られる大量かつ高速のデータから価値を引き出すことができます。 ここでの大きな違いは、メインフレームが発明されて以来、何十年も休みなく処理してきた分析とレンズとデータのビューを開発してきた長い歴史があることです。 「ウェブスケール」と呼ばれるこの3〜5年で見られた大規模なパラダイムシフトは、イベント相関を処理して検索するだけでなく、リアルタイムまたはほぼリアルタイムで着信するデータストリームを利用することです。イベントがトリガーされますが、これらのストリームに対して非常に詳細で詳細な分析を実行します。 データの収集、ある種のリポジトリへの格納、現在は従来の大きなデータベース、Hadoopプラットフォームなどの大きなビッグデータフレームワークへの配置、およびバッチモード処理の実行、何らかの洞察。

私たちはそれを非常に迅速に行い、大量の重い鉄を試してみましたが、まだデータをキャプチャし、保存してから見て、何らかの洞察や分析を得ています。 データのストリーミング中にこれらの分析を実行することへの移行は、ビッグデータの周辺で発生するさまざまな種類の非常に新しいエキサイティングな成長分野です。 分析をキャプチャ、保存、処理、実行するためのまったく異なるアプローチが必要です。

ストリームで分析を実行することへの移行と集中の主な要因の1つは、情報がビジネスで利用可能になっているため、データが届くと、これらの洞察をより速く、より簡単に取得することで、大きなビジネス価値を獲得できることです。 現在、一日の終わりの処理を行うという考えは、特定の業界ではもはや関係ありません。 その場で分析を行えるようにしたいと考えています。 一日の終わりには、一日の終わりに到達して24時間のバッチジョブを行い、それらの洞察を得るのではなく、何が起こったのかを既に知っています。

ストリーミング分析とは、そのストリームを直接タップすることです。一方、データストリームは、通常、非常に大量のデータの複数のストリームであり、データが非常に迅速に移動し、それらのストリームに関する洞察や分析を取得します安静時にそれを可能にし、それらに対して分析を実行します。

先ほど述べたように、バッチ分析と呼ばれるものを何十年も実行してきました。 ここに本当にクールな写真を載せました。 これは、一生前にRAND Corporationによって作成されたモックアップされたコンピューターの前に立っている紳士の写真で、これは彼らが家の中でコンピューターをどのように見えるかを見たものです。 興味深いのは、それでも、これらの小さなダイヤルすべての概念があり、これらのダイヤルが家から来てリアルタイムで処理され、何が起こっているかを伝える情報を表していることです。 簡単な例は、大気圧と温度のセットであり、リアルタイムで何が起きているかを見ることができます。 しかし、RAND Corporationがその小さなモックアップを組み立てたときでも、彼らは実際にデータを処理し、ストリーム形式で提供される分析を実行することを既に考えていたと思います。 なぜ彼らがコンピューターにハンドルを置くのかはよくわかりませんが、それはかなりクールです。

プリンタが発明されて以来、データをキャプチャしてバッチ分析を実行するという考え方がありました。 今大きなシフトで言ったように、私たちは皆知っているウェブスケールのプレイヤーのような人からこれを見てきました、彼らはすべて、Twitter、Facebook、LinkedInのような家庭用ブランドですプラットフォームは、バッチモードでキャプチャ、保存、および処理するだけでなく、実際に通過するデータのストリームからリアルタイムで分析をキャプチャおよび駆動します。 何かをツイートするときは、後で何かをキャプチャして保存し、実行する必要があるだけでなく、すぐにストリームに戻し、自分をフォローしている他の人と共有できるようにする必要もあります。 それがバッチ処理モデルです。

なぜこのルートを下るのでしょうか? なぜ組織は、ストリーム分析の道をたどるという挑戦を検討するのに時間、労力、お金を投資するのでしょうか? 組織には、現在の業界の競合他社よりもパフォーマンスを向上させたいという大きな要望があり、シンプルなストリーム分析を通じてパフォーマンスの向上を迅速に実装でき、すでにリアルタイムデータを追跡するだけで開始できますに精通。 Google Analyticsの小さなスクリーンショットがありました。 これはおそらく、実際に消費者レベルの分析を実際に手に入れた最初の1つです。 人々があなたのウェブサイトを訪れていて、あなたのウェブサイトに埋め込まれたHTMLの小さなJavaScriptがあなたのウェブサイトに埋め込まれているこれらのヒットカウントを取得しているとき、これらの小さなコードはGoogleにリアルタイムで作られていましたウェブサイトのすべてのページ、ウェブサイトのすべてのオブジェクトからリアルタイムで送られてくるデータのストリームに対して分析を実行し、リアルタイムのグラフ、キュートなヒストグラム、過去にページにアクセスしたX人のユーザーを示す折れ線グラフですが、現在の人数は次のとおりです。

そのスクリーンショットでわかるように、現在25と表示されています。 スクリーンショットがそのページにあった時点で、現在25人です。 これが、消費者レベルの分析ツールでプレイした最初の本当のチャンスです。 多くの人が本当にそれを手に入れたと思います。 彼らは、何が起こっていて、どのようにそれに対応できるのかを知る力を理解しました。 アビオニクス、飛行機の飛行の規模を考えると、米国だけでも1日あたり18, 700の国内便があります。 約6〜7年前に、古い航空機モデルで約200〜300メガバイトのデータがこれらの航空機で生成されていたという論文を少し前に読みました。 今日の航空機の設計では、これらの航空機はフライトごとに約500ギガバイトのデータまたは約半テラバイトのデータを生成しています。

頭のてっぺんからすぐに計算すると、米国領空だけで24時間ごとに18, 700の国内便があり、最新の航空機がすべて約0.5テラバイトを生成している場合、43から44ペタバイトのデータが通過し、飛行機が空中にいる間に起こっています。 彼らが着陸し、データダンプを行うときに発生します。 そのとき、彼らは店に入り、エンジニアリングチームから完全なデータダンプを取得して、ベアリング、ホイール、およびエンジン内部で何が起こっているのかを調べます。 そのデータの一部はリアルタイムで処理する必要があるため、飛行機が空中にあるか、地上にいる間に実際の問題があるかどうかを判断できます。 バッチモードでは実行できません。 金融、健康、製造、エンジニアリングの分野で私たちが目にする他の産業では、彼らはまた、リアルタイムで何が起こっているのかという新しい洞察をどのように得ることができるかを検討しています。期間。

また、多くのデータは時間の経過とともに価値を失うという、私が生鮮商品または生鮮商品と呼ぶものとしてデータを扱うというこの概念もあります。 これは、モバイルアプリやソーシャルメディアツールでますます多くの人が言っていることであり、現在のトレンドはあなたが応答したいものだからです。 私たちの生活の他の部分について、物流や食料の輸送について考えるとき、その意味で腐りやすい商品の概念を理解します。 しかし、組織を通過するデータとその価値について考えてください。 誰かが今あなたとビジネスをしていて、リアルタイムでやり取りできる場合は、1時間待ってデータをキャプチャしてHadoopなどのシステムに入れてからこのボタンを押すことはできません。すぐに対処できず、クライアントの要求に応じてすぐに対処できるようにしたいと考えています。 あなたがパーソナライズを提供できるこのリアルタイムのデータストリームを持っていることについて人々が話す今、あなたが頻繁に現れる用語があります、そしてあなたの個人的な経験にあなたが使用しているシステムでパーソナライズを調整します。 たとえば、Google検索ツールなどのツールを使用する場合、私がクエリを実行して同じクエリを実行すると、常に同じデータが取得されません。 基本的に、私がセレブ体験と呼んでいるものが得られます。 私は一度限りの扱いを受けています。 私が収集したプロファイルとデータに基づいて、これらのシステムで起こっていることの個人的なバージョンを取得し、ストリームでリアルタイムに分析を行うことができました。

データが腐りやすい商品であるというこの考えは今のところ現実のものであり、データの価値が時間とともに低下することは、今日対処しなければならないものです。 それは昨日のことではありません。 ストリーミングアナリティクスで見ているものを正確に描画するので、川から飛び出すサーモンをつかむクマのこの写真が大好きです。 大量のデータが私たちに届いており、必要に応じて消火ホースであり、クマは小川の真ん中に座っています。 周囲の状況をリアルタイムで分析し、空中の魚を捕獲する機能を実際に設計できるようにします。 それはただストリームに浸り、それをつかむようなものではありません。 このことは空中で跳んでおり、その魚を捕まえるために適切なタイミングで適切な場所にいる必要があります。 そうでなければ、彼は朝食も昼食も食べません。

組織は、データに対して同じことをしたいと考えています。 彼らは、現在大量の移動中のデータから価値を引き出したいと考えています。 彼らは、そのデータと高速データの分析を実行したいので、データの量だけでなく、データの速度も重要です。 たとえば、セキュリティでは、すべてのルーター、スイッチ、サーバー、ファイアウォール、およびそれらから発生するすべてのイベント、および数十万ではないにしても数万のデバイス、場合によっては腐りやすいデータです。 モノのインターネットや産業用インターネットで考えるとき、最終的には数十億のセンサーではなく数百万のセンサーについて話し、分析を実行するデータが通過するにつれて、複雑なイベント処理を行うことを検討しています今まで見たこともないほどの規模と速度で、今日これに対処する必要があります。 その周りにツールとシステムを構築する必要があります。 一方で、DIYを行う非常に大きなブランドがあり、そのための能力とスキルセットとエンジニアリングを持っているときに、自分で焼くことができます。 しかし、平均的な組織ではそうではありません。 彼らにはスキルセットがありません。 彼らはそれを理解するために投資する能力や時間、あるいはお金さえ持っていません。 彼らは皆、ほぼリアルタイムの意思決定というこの概念を目指しています。

私が出会ったユースケースは、あなたが想像できるあらゆるセクターのあらゆる広い範囲にわたっており、人々は座って注意を払い、ストリームデータにいくつかの分析をどのように適用しますか? Webスケールのオンラインサービスについて説明します。 従来のソーシャルメディアプラットフォーム、オンラインのe-tailingおよび小売り(アプリなど)があります。 彼らは皆、このリアルタイムのセレブ体験を私たちに提供しようとしています。 しかし、テクノロジースタックサービス、電話サービス、音声およびビデオの詳細に目を向けると、電話でFaceTimeを実行している人々が見かけます。 爆発しているだけです。 人々は自分の前で電話を持ち、それをもう耳に当てるのではなく、友人のビデオストリームと話しているのが私の心を揺さぶる。 しかし、彼らはそれができることを知っており、適応し、彼らはその経験が好きでした。 これらのアプリケーションとこれらを提供するプラットフォームの開発は、そのトラフィックとトラフィックのプロファイルでリアルタイム分析を実行する必要があるため、そのビデオを完全にルーティングして、あなたが得るビデオは、良い経験を得るのに十分です。 そのようなデータをバッチ処理することはできません。 リアルタイムビデオストリームを機能的なサービスにすることはできません。

金融取引にはガバナンスの課題があります。 一日の終わりにたどり着いて、あなたが個人データをその場所に移動させている法律に違反していることを知ることは大丈夫ではありません。 オーストラリアでは、プライバシーに関連するデータをオフショアに移動することを禁じる非常に興味深い課題があります。 私のPID、個人の個人識別データ、オフショアを取ることはできません。 オーストラリアにはそれを防ぐための法律があります。 確かに金融サービスのプロバイダー、特に政府のサービスや代理店は、彼らが私に提供しているものが海岸を離れないことを確認するために、彼らのデータと指示の流れについてリアルタイム分析を行わなければなりません。 すべてのものはローカルに留まる必要があります。 彼らはリアルタイムでそれをしなければなりません。 彼らは法律を破り、後で許しを求めることはできません。 詐欺の検出–クレジットカードのトランザクションで耳にすることは非常に明白です。 しかし、金融サービスで行っている取引の種類は非常に急速に変化しているため、PayPalがリアルタイムで不正を検出する際に最初に行っている種類のものがあります。システム間の金融取引。 Ebay入札プラットフォーム、詐欺の検出は、ストリーミングオフィスでリアルタイムに実行する必要があります。

現在、ストリーム内で抽出アクティビティを実行し、負荷アクティビティを変換する傾向にあるため、ストリームに送信されるものをキャプチャする必要はありません。 そんなことはできません。 すべてをキャプチャすると、データはすぐに壊れる可能性が高いことを人々は知っています。 ここでのコツは、これらのストリームで分析を実行してETLを実行し、必要なもの、メタデータをキャプチャしてから、予測分析を実行して、実際に何が起こるかを少し先に伝えます私たちが実行した分析に基づいてストリームで見たばかりです。

エネルギーおよび公益事業者は、需要価格を設定したいという消費者からのこの大きな要望を経験しています。 私は家にいるだけで、多くのデバイスを使用していないため、特定の時間帯にグリーン電力を購入したいと思うかもしれません。 しかし、ディナーパーティーを開催する場合は、すべてのデバイスをオンにし、安価な電力を購入して電力が供給されるのを待ちたくはありませんが、その電力を得るためにより多くの費用を支払うことを望みます。 特に電力会社やエネルギー分野でのこの需要価格設定はすでに行われています。 たとえば、Uberは毎日できることの典型的な例であり、それはすべて需要価格設定によって決まります。 大in日の需要が大きいため、オーストラリアの人々が10, 000ドルの運賃を受け取っている典型的な例がいくつかあります。 私は彼らがその問題に対処したと確信していますが、車の中でリアルタイムで実行されるストリーミング分析は、いくら支払うべきかをあなたに告げています。

モノのインターネットとセンサーストリーム–これについてはほんの一面をかき集めただけで、実際に基本的な会話が行われただけですが、テクノロジーの扱い方に興味深い変化が見られるでしょう。わずか数千または数万ですが、数十万、潜在的には数十億のデバイスがストリーミングされますが、現在私たちが持っている技術スタックはほとんどそれに対処するように設計されていません。

セキュリティやサイバーリスクのような場所については、いくつかの本当にホットなトピックがあります。 それらは私たちにとって非常に現実的な課題です。 WebにはNorthと呼ばれるすてきなツールがあり、そこに座ってリアルタイムで発生するさまざまなサイバー攻撃をWebページで見ることができます。 見てみると、「すてきなかわいいWebページだ」と思うかもしれませんが、約5分後には、システムが世界中のさまざまなデバイスのさまざまなストリームで分析を行っているデータ量に気付きます。それらに供給されています。 それは彼らがそのレコードの端でそれを実行している方法の本質を揺り動かし始め、それをリアルタイムで攻撃する対象または他の何かがどのような種類の攻撃であるかを示すシンプルな小さな画面を提供します。 しかし、このページを見て、ストリームを取得し、分析クエリを処理するだけのボリュームと挑戦の感覚を得るだけで、リアルタイムでストリーム分析があなたに潜在的にできることの良い味を得るための本当にすてきな小さな方法ですそれらをリアルタイムで表します。

セッションの残りの部分での会話は、私の視点から、これらのタイプのすべてを1つの興味深い視点で取り上げることになると思います。それがDIYの挑戦であり、自分で焼いて、これらの種類のものを構築する余裕がある古典的なユニコーン。 これらのエンジニアリングチームを構築し、データセンターを構築するのに数十億ドルを費やしています。 しかし、ストリーム分析のビジネスで価値を高めたいと考えている組織の99.9%には、既製のサービスを取得する必要があります。 すぐに製品を購入する必要があり、一般的に、実装に役立つコンサルティングサービスと専門サービスが必要です。ビジネスでその価値を取り戻し、実用的なソリューションとしてビジネスに販売します。

それで、私はあなた、レベッカに返事をするつもりです、それが私たちが今私たちが詳細にカバーしようとしていることだと思うからです。

Rebecca Jozwiak:すばらしい。 ありがとう、デズ。 それは素晴らしいプレゼンテーションです。

さて、ボールをロビンに渡します。 奪って

Robin Bloor:なるほど。 Dezはストリーム処理の要点に取り組んでいるので、もう一度説明するのは意味がありませんでした。 だから私は完全に戦略的な見方をするつもりです。 地獄が何をしているのかを非常に高いレベルから見下ろし、それを配置するのは、それが人々、特に私たちの前に非常に深いストリーム処理に収容されていない人々を助けるかもしれないからです。

ストリーム処理は長い間使用されてきました。 以前はCEPと呼んでいました。 それ以前にはリアルタイムシステムがありました。 元のプロセス制御システムは、実際には情報の流れを処理していました。もちろん、今日までは何も起こりませんでした。 ここのスライドに表示されるこのグラフィック。 実際には多くのことを指し示していますが、それは他の何よりも上を指し示しています。つまり、ここにさまざまな色で現れるさまざまなレイテンシがあるという事実です。 1960年ごろに到着したコンピューティングまたは商用コンピューティングの発明以来実際に起こったことは、すべてがますます高速になったことです。 波の中が好きな場合、これが実際に出てくる方法に依存することができました。 これは実際にそれに依存しています。 それはすべてムーアの法則に基づいており、ムーアの法則は約6年間で約10倍の速度をもたらすからです。 その後、実際に2013年頃に到達すると、すべてが壊れ、突然、今までにない速度で加速し始めましたが、これは前例のないことです。 速度の向上という点で約10倍になっていたため、約6年ごとに待ち時間が短縮されました。 2010年頃から6年間で、少なくとも1, 000の倍数がありました。 1桁ではなく3桁。

それが起こっていることであり、それが業界が何らかの形で素晴らしい速度で動いているように見える理由です。 この特定のグラフィックの意味だけを見てみると、応答時間は実際には垂直軸に沿ってアルゴリズム的に縮小されています。 リアルタイムとはコンピューターの速度であり、人間よりも高速です。 インタラクティブな時間はオレンジ色です。 あなたが本当にあなたが本当に10分の1から1秒のレイテンシーが欲しいのはあなたがコンピュータとやり取りしているときです。 上記では、コンピューターで何をしているのかを実際に考えるトランザクションがありますが、それが約15秒で消えると、耐えられなくなります。 人々は実際にはコンピューターを待つことはないでしょう。 すべてがバッチで行われました。 バッチで行われた多くのことが、トランザクション空間、インタラクティブ空間、さらにはリアルタイム空間にまで流れています。 以前は非常に少量のデータで波状でしたが、これのいくつかを行うことができましたが、非常にスケールアウトされた環境を使用して非常に大量のデータで行うことができます。

基本的に、これらはすべてトランザクションと対話型の人間の応答時間です。 現在ストリームで行われていることの非常に多くは、物事について人間に知らせることです。 それのいくつかはそれより速くなっています、そして、それはリアルタイムですので、それはものをよく知らせています。 それから、私たちはただの石のように落とすためのライセンスを取得し、インスタント分析を実行可能にし、偶然にかなり手頃な価格にします。 速度が下がっただけでなく、トップも崩壊しただけではありません。 おそらく、これらすべてのさまざまなアプリケーションの中で最も大きな影響を与えるのは、これらすべての予測分析を実行できることです。 理由をすぐに説明します。

これは単なるハードウェアストアです。 並列ソフトウェアを入手しました。 スケールアウトアーキテクチャ、マルチコアチップ、メモリの増加、構成可能なCPU。 SSDは、回転するディスクよりもはるかに高速になりました。 さようなら、ディスクを回転させることができます。 SSDも複数のコアに含まれているため、さらに高速になっています。 すぐに、HPからメモリスタを入手しました。 IntelとMicronから3D XPointを入手しました。 それらの約束は、それがすべてとにかく速くなるということです。 実際に2つの新しいメモリテクノロジーを考えている場合、どちらも基本的な小片の全体を作成し、個々の回路基板ははるかに高速になりますが、その終わりさえ見ていません。

本当に次のメッセージであるStreamsテクノロジーは今後も続くでしょう。 新しいアーキテクチャが必要になります。 私は、Dezがプレゼンテーションのいくつかのポイントでこれについて言及していることを意味します。 何十年もの間、私たちはアーキテクチャをデータヒープとデータパイプの組み合わせと考えていました。 ヒープを処理する傾向があり、ヒープ間でデータをパイプする傾向がありました。 現在、データフローの処理とデータヒープを組み合わせたLambdaデータアーキテクチャと呼ばれるものに根本的に移行しています。 履歴データに対してデータフローまたはデータヒープとして入ってくるイベントストリームを実際に処理しているとき、それがLambdaアーキテクチャの意味です。 これはまだ初期段階です。 それは絵の一部にすぎません。 Dezが言及しているInternet of Everythingのような複雑なものを考えると、あらゆる種類のデータの場所の問題、つまりストリームで何を処理するかについての決定があることを実感するでしょう。

ここで本当に言っているのは、バッチで処理しているとき、実際にストリームを処理しているということです。 一度に1つずつできませんでした。 大きなものが山になるまで待ってから、すべてを一度に処理します。 ストリーム内のコンテンツを実際に処理できる状況に移行しています。 ストリーム内のデータを処理できる場合、保持するデータヒープは、ストリーム内のデータを処理するために参照する必要がある静的データになります。

これは、この特定のことを示しています。 これについては、生物学的アナロジーを用いたプレゼンテーションで以前に言及しました。 私があなたに考えて欲しいのは、私たちが人間である瞬間です。 リアルタイム予測処理のための3つの異なるネットワークがあります。 それらは、体性、自律性および腸溶性と呼ばれます。 腸溶性はあなたの胃です。 自律神経系は戦いと飛行の面倒を見ます。 実際には、環境への素早い反応を考慮しています。 体の動きを管理する体。 これらはリアルタイムシステムです。 それについての興味深いこと-​​または私はちょっと面白いと思う-それの多くはあなたが想像するよりも予測的です。 それはまるであなたが実際にあなたの顔から約18インチの周りのスクリーンを見ているかのようです。 あなたがはっきりと見ることができるすべて、あなたの体がはっきりと見ることができるすべては、実際には8×10の長方形についてです。 それ以外のすべては実際にはあなたの体に関する限りぼやけていますが、あなたの心は実際に隙間を埋めてぼやけていないようにしています。 ぼかしはまったくありません。 はっきりと見えます。 あなたの心は、あなたがその明瞭さを見るために、データストリームの予測方法を実際にやっています。 それはちょっと奇妙なことですが、実際に神経系がどのように動作するか、そして私たちがうまくやっていく方法と、少なくとも私たちの何人かは合理的に健全で、常に物事にぶつからない方法を見ることができます。

これはすべて、この内部の一連のニューラル分析スケールによって実行されます。 起こることは、組織が同じ種類のものを持ち、同じ種類のものを構築し、それが組織の内部ストリームを含むストリームの処理であるということです。それ、それの外で起こること、実際になされなければならない即時の応答は、もちろん決定を下し、これらすべてを起こすために人間を養うことです。 私が見ることができる限り、それは我々が行くところです。

その結果の1つは、ストリーミングアプリケーションのレベルがうまくいっていることです。 私たちが今見ている以上に恐ろしいことがたくさんあります。 今、私たちは明白なことをすることの簡単な成果を選んでいます。

とにかく、これが結論です。 ストリーミング分析はかつてはニッチですが、それが主流になりつつあり、まもなく一般的に採用されます。

それで、私はそれをレベッカに返します。

Rebecca Jozwiak:ありがとう、ロビン。 いつものように素晴らしいプレゼンテーション。

アナンド、あなたは次です。 床はあなたのものです。

Anand Venugopal:素晴らしい。 ありがとうございました。

私の名前はアナンドヴェヌゴパルで、StreamAnalytixの製品責任者です。 カリフォルニア州ロスガトスにあるImpetus Technologiesが提供する製品です。

Impetusは、実際に大企業向けのビッグデータソリューションプロバイダーとして素晴らしい歴史を持っています。 そのため、実際にサービス会社として多くのストリーミング分析の実装を行い、多くの教訓を学びました。 また、ここ数年で製品会社およびソリューション主導型企業への転換を果たし、ストリーム分析はImpetusを主に製品主導型の企業に変身させる責任を担っています。 企業に対するエクスポージャーのおかげでImpetusがクリアした重要な非常に重要な資産がいくつかあり、StreamAnalytixもその1つです。

私たちは20年間ビジネスに携わっており、製品とサービスの素晴らしい組み合わせが私たちに大きな利点をもたらしています。 StreamAnalytixは、ストリーミングの最初の5つまたは6つの実装から学んだすべての教訓から生まれました。

いくつかの点に触れますが、アナリストのDezとRobinはスペース全体をカバーするのに素晴らしい仕事をしたので、重複する多くのコンテンツをスキップします。 おそらく早く行きます。 企業で文字通り非常に非常に重要なバッチプロセスが存在する、バッチアクセラレーションの多くを使用する真のストリーミングケースを確認します。 ご覧のように、大企業ではイベントを検知して分析し、それに対処するこのサイクル全体が実際に数週間かかる可能性があり、彼らはすべてそれを数分、時には秒とミリ秒に縮小しようとしています。 したがって、これらのすべてのバッチプロセスよりも高速なものはビジネス獲得の候補であり、データの価値はその年齢とともに劇的に減少するため、発生した数秒で最初の部分に多くの価値があります。 理想的には、何が起こるかを予測できた場合、それが最高値になりますが、それは精度に依存します。 次に高い値は、それが起こっているときにすぐそこにあるときであり、それを分析して応答することができます。 もちろん、その後、値は劇的に減少します。これは、私たちがいる主な制限付きBIです。

それは面白い。 ストリーミング分析の理由に対する劇的な科学的答えを期待するかもしれません。 多くの場合、私たちが見ているのは、それが可能になったからであり、誰もがバッチが古いことを知っているからです。バッチは退屈で、バッチはクールではありません。 ストリーミングが可能であり、誰もがHadoopを持っているという事実に関して、誰もが今持っている十分な教育があります。 現在、Hadoopディストリビューションには、ストームまたはスパークストリーミングであるかどうかにかかわらず、ストリーミング技術が組み込まれています。もちろん、Kafkaなどのメッセージキューもあります。

私たちが見ている企業はそれに飛び込んで、これらのケースで実験を始めており、私たちは2つの広いカテゴリーを見ています。 1つは、顧客分析と顧客エクスペリエンス、および2つ目の運用インテリジェンスと関係があります。 これについては、少し後で詳しく説明します。 Impetus StreamAnalytixのカスタマーサービスとカスタマーエクスペリエンス全体の角度は、さまざまな方法でこれを実現しています。消費者のマルチチャネルエンゲージメントをリアルタイムで正確にキャプチャし、非常にコンテキスト依存のエクスペリエンスを提供することです。今日では一般的ではありません。 Bank of AmericaのWebサイトでWebを閲覧していて、いくつかの製品を調査していて、コールセンターに電話するだけの場合。 「ねえ、ジョー、銀行の商品を研究しているのを知っているので、それを埋めてくれませんか?」と言うでしょうか?今日はそうは思わないでしょうが、それはストリーミング分析で本当に可能な経験です。 多くの場合、特に顧客があなたのウェブサイトで早期終了条項または早期終了の契約条件を調べてからあなたと契約から抜け出す方法を調査し始めてから電話をかければ、それは大きな違いになりますシステムはこの人が早期解約を検討していることを知っているので、間接的に何らかの最初のプロモーションについてオファーを提供し、その時点でそのオファーを行うと、その顧客を保護し、資産を保護することができます。

それは一例であり、多くの顧客サービスはすべて非常に良い例です。 私たちは今日、コールセンターのコストを削減するだけでなく、劇的な楽しい顧客体験を提供しています。 Dezは、ユースケースのいくつかを要約するのに素晴らしい仕事をしました。 このチャートを数分間見つめることができます。 私はそれを垂直、水平、コンボエリア、IoT、モバイルアプリ、コールセンターに分類しました。 それらはすべて垂直および水平です。 それはあなたの見方によって異なります。 結論として、業界の業種全体でかなり一般的な水平方向の使用がかなりあり、金融​​サービス、医療、通信、製造などを含む垂直的な特定の使用例があります。それは、「ああ、どんなユースケースがあるのか​​わかりません。 ストリーミングアナリティクスに、自分の会社にとって、あるいは私たちの企業にとって、本当にビジネス上の価値があるかどうかはわかりません。」と考え直してください。 今日、あなたの会社には関連性のあるユースケースがあるため、より多くの人々と話してください。 ビジネス価値がどの程度正確に導出されるかについて、ビジネス価値について説明します。

ここのピラミッドの下部には、予測保守、セキュリティ、解約保護などがあります。これらの種類のユースケースは、収益と資産の保護を構成します。 Targetが数時間および数週間にわたって発生したセキュリティ侵害を保護した場合、CIOは仕事を救うことができたでしょう。 数千または数億ドルの節約などが可能です。リアルタイムストリーミング分析は、これらの資産の保護と損失の保護に役立ちます。 それはすぐにビジネスに付加される価値です。

次のカテゴリは、収益性を高め、コストを削減し、現在の運用からより多くの収益を得ています。 それが現在の企業の効率です。 これらはすべて、ネットワークがどのように動作しているのか、顧客の動作がどのように動作しているのか、ビジネスプロセスがどのように動作しているかを詳細に把握しているリアルタイム運用インテリジェンスと呼ばれるユースケースのカテゴリですフィードバックを受け取ったり、アラートを受け取ったりするので、そのすべてがリアルタイムで行われます。 リアルタイムで逸脱、差異を取得し、範囲外のプロセスを迅速に行動および分離できます。

高価な資本のアップグレードや、ネットワークサービスを最適化した場合には必要ないかもしれないと思われるものでも、多額のお金を節約できる可能性があります。 大手の電話会社が現在のトラフィックを管理するのに十分な容量があることがわかったため、ネットワークインフラストラクチャで4, 000万ドルのアップグレードを延期したケースを耳にしました。これは、トラフィックなどのインテリジェントルーティングを最適化して改善することによって行われました。 これらはすべて、これらの洞察にリアルタイムで作用するいくつかのリアルタイム分析およびアクションメカニズムでのみ可能です。

次のレベルの付加価値はアップセル、クロスセルであり、現在の製品からより多くの収益と利益を得る機会があります。 これは私たちの多くが彼らが経験したことを知っている古典的な例です。あなたはあなたの人生で、あなたに提供されていない製品を実際に今日購入したいと考えています。 多くの場合、多くの場合、それは実際に起こります。 購入したいこと、購入したいことがわかっていること、ToDoリストなどを持っていること、妻から言われたこと、妻がいないが本当に購入したいことを心に留めているウェブサイトで買い物をするか、小売店でやり取りしている場合、店頭にはコンテキストがなく、必要な情報を計算するインテリジェンスもありません。 したがって、彼らは彼らのビジネスを安全にしません。 ストリーミング分析を展開して実際に正確な予測を行うことができ、この特定のコンテキストに最も適したもので実際に可能な場合、この顧客はこの場所でこの時点で多くのアップセルとクロスセルがあり、それは再びストリーミング分析–機会があれば、その瞬間にこの顧客が購入または対応する可能性の高い傾向を判断できます。 だから、その魚を食べようとしているクマとデズが見せた写真が大好きです。 それはほとんどそれです。

また、顧客の行動の観察に基づいて、すべて別の企業の行動の観察に基づいて、まったく新しい製品とサービスを提供するという企業の劇的な変革的変化という大きなカテゴリーがあると思います。 たとえば、通信会社やケーブル会社が、市場のどのセグメントで、どのプログラムをいつ視聴しているかなどの顧客の使用パターンを実際に観察している場合、実際には、ほとんど頼まれている製品やサービスを作成することになります何らかの方法で。 したがって、モバイルアプリでテレビやケーブルのコンテンツを見ることができるようになった現在、マルチスクリーン動作のコンセプト全体はほぼ当然のことと考えています。 これらの例の一部は、当社に提供されている新しい製品およびサービスからのものです。

「ストリーミング分析のアーキテクチャに関する考慮事項は何ですか?」に入ります。最終的には、私たちがやろうとしていることです。 これは、履歴データとリアルタイムのインサイトをブレンドして同時に表示するLambdaアーキテクチャです。 それがシグマが可能にするものです。 今日、私たちは皆、バッチアーキテクチャと企業像を持っています。 ある種のBIスタックと使用率スタックを収集し、Lambdaアーキテクチャを追加しました。 スピードレイヤーまたは必要性とラムダは、これら2つの洞察をマージし、両方の洞察を組み合わせた豊かな方法でそれらを組み合わせた方法で見ることです。

Kappaアーキテクチャと呼ばれるもう1つのパラダイムがあります。これは、速度層が長期的に持続する唯一の入力メカニズムであるという推測が提案されています。 すべてがこのスピードレイヤーを通過します。 オフラインのETLメカニズムもありません。 すべてのETLが発生します。 クレンジング、データクレンジング、高品質のETL –すべてのデータがリアルタイムで生成されることを念頭に置いて、すべてをワイヤで実行します。 ある時点で、それはリアルタイムでした。 私たちはこれを湖、川、海に置き、静的解析でそれを行うことに慣れてきたので、データがリアルタイムである時点で生まれたことを忘れていました。 すべてのデータは実際にその時点で発生したリアルタイムイベントとして生成され、今日の湖のほとんどのデータは後の分析のためにデータベースに置かれただけであり、実際のLambdaおよびKappaアーキテクチャでは利点がありますそれを見て、分析し、前処理し、到着したときに反応します。 それがこれらのテクノロジーによって可能になったものです。 全体像として見ると、中にHadoopがあり、MPPがあり、データウェアハウスが既にあるこのようなものに見えます。

島の新しい技術について話すだけではないことが重要だからです。 統合する必要があります。 彼らは現在の企業の文脈で意味をなさなければならず、企業にサービスを提供しているソリューションプロバイダーとして、私たちはこれに非常に敏感です。 企業が全体を統合するのを支援します。 左側にはデータソースがあり、Hadoopレイヤーとデータウェアハウスレイヤーの両方、および最上位のリアルタイムレイヤーの両方にデータが送られます。これらの各エンティティは、ご覧のとおりストックコンピューターであり、データ消費レイヤーは右側にあります側。 現在利用可能なコンプライアンス、ガバナンス、セキュリティ、ライフサイクル管理などの大部分をこの新しいテクノロジーにすべて集約しているため、絶え間ない努力が行われています。

ストリーム分析がやろうとしていることの1つは、今日の展望を見ると、ストリーミングテクノロジーの展望に多くのことが起こっていることであり、企業顧客の観点からは、理解すべきことがたくさんあります。 追いつくべきことがたくさんあります。 左側には、NiFi、Logstash、Flume、Sqoopのデータ収集メカニズムがあります。 明らかに、網羅的ではないという免責条項を付けました。 メッセージキューに入ってから、オープンソースのストリーミングエンジン(Storm、Spark Streaming、Samza、Flink、Apex、Heron)に入ります。 Heronはおそらくまだオープンソースではありません。 Twitterからのものかどうかはわかりません。 これらのストリーミングエンジンは、複雑なイベント処理、機械学習、予測分析、アラートモジュール、ストリーミングETL、エンリッチメント統計操作フィルターなどのセットアップ分析アプリケーションコンポーネントにつながるか、サポートします。 これらはすべて、私たちが現在演算子と呼んでいるものです。 これらの演算子のセットは、一緒にストリング化された場合、必要に応じて大体結論付けられたカスタムも潜在的にストリーミングエンジンで実行されるストリーミングアプリケーションになります。

コンポーネントのチェーンの一部として、データをお気に入りのデータベース、お気に入りのインデックスに格納してインデックスを作成する必要もあります。 また、キャッシュを配布する必要がある場合がありますが、これは上部の右側のデータ視覚化レイヤーにつながり、商用製品またはオープンソース製品につながりますが、最終的には、そのデータをリアルタイムで視覚化する何らかの種類の製品が必要です。 また、時には他のアプリケーションを考える必要があります。 私たちは皆、あなたが洞察に対して取るアクションによってのみ導き出される値を見ました。そのアクションは、分析スタックから別のアプリケーションスタックへのトリガーになり、IVR側の何かであるか、コールセンターをトリガーしますアウトバウンドコールなど。 これらのシステムと、ストリーミングクラスターがデータをダウンストリームに送信する他のアプリケーションをトリガーするためのメカニズムを統合する必要があります。

これが、左から右への全体的なスタックです。 次に、サービスレイヤー、中間監視、セキュリティ一般サービスレイヤーなどがあります。顧客が目にしているエンタープライズスペースにある製品は、私が言ったようにストリーミングがあり、コマーシャルまたはシングルがあります。 -明らかに競合他社にあるベンダーソリューション。 ランドスケープには、ここで言及しなかった可能性のあるものがさらに多くあります。

あなたがそこに見ているものは、エンタープライズユーザーが広く見ているものです。 ご覧のように、ストリーム処理のための複雑で急速に進化している技術ランドスケープ。 選択とユーザーエクスペリエンスを簡素化する必要がありました。 企業が本当に必要と考えるのは、すべての機能を抽象化して、ワンストップショップで使いやすいインターフェイスを構築することです。劣化の問題、パフォーマンスの問題、ライフサイクルのメンテナンスの問題が企業に与えられます。

機能の抽象化は1つです。 2番目の部分は、ストリーミングエンジンの抽象化です。 ストリーミングエンジンとオープンソースドメインは、3、4、6か月ごとに1回登場しています。 長い間ストームでした。 Samzaが登場し、今ではSpark Streamingです。 Flinkは注目を集め始めています。 Spark Streamingのロードマップでさえ、Sparkはバッチ用に設計されていることを認識しており、アーキテクチャのビジョンと異なる可能性があるためのロードマップを作成しているため、純粋なイベント処理に異なるエンジンを潜在的に使用する方法を作成していますSpark Streamingの現在のマイクロバッチパターンに加えて、ストリーム処理用のエンジン。

多くの進化があることを争う必要があるのは現実です。 あなたは本当にその技術の変化から身を守る必要があります。 デフォルトでは、1つを選択してからそれを使用する必要があるため、最適ではありません。 別の方法で見ている場合は、「ロックインがなく、オープンソースのレバレッジがなく、非常に高いコストと制限のあるプロプライエタリなプラットフォームを購入する必要があります。繰り返しますが、私が言ったように、それは多くのコストと市場投入までの遅れです。 StreamAnalytixは、エンタープライズクラス、信頼性の高い単一ベンダー、サポートされるプロフェッショナルサービスを統合する優れたプラットフォームの一例です。これらはすべて、企業として本当に必要であり、オープンソースエコシステムの柔軟性の力です。インジェスト、CEP、分析、視覚化など、単一のプラットフォームがそれらを統合します。

また、非常にユニークな機能も備えており、1つのユーザーエクスペリエンスの下にさまざまなテクノロジーエンジンが統合されています。 ユースケースが異なればストリーミングアーキテクチャも異なるため、将来は複数のストリーミングエンジンを使用できるようになると考えています。 ロビンが言ったように、レイテンシーの全範囲があります。 ミリ秒の遅延レベル、数十、または数百ミリ秒について本当に話している場合、数秒、3、3秒で、より緩やかなまたは寛大な時間枠と遅延のために、同様に成熟した別の製品が出るまで、現時点でStormが本当に必要です4、5秒、その範囲、Spark Streamingを使用できます。 潜在的に、両方を行うことができる他のエンジンがあります。 結論として、大企業では、あらゆる種類のユースケースがあります。 1つのユーザーエクスペリエンスで複数のエンジンを使用できるようにするために、アクセスと汎用性が本当に必要です。それがStreamAnalytixで構築しようとしていることです。

アーキテクチャの簡単な概要。 これを少し手直ししますが、基本的に、左側に複数のデータソースがあります。Kafka、RabbitMQ、Kinesis、ActiveMQ、これらすべてのデータソース、およびストリーム処理プラットフォームに着信するメッセージキューです。アプリを組み立てて、ETLなどの演算子からドラッグアンドドロップすることができます。 その下には、複数のエンジンがあります。 現在、ストームストリーミングとスパークストリーミングは、複数のエンジンをサポートする業界唯一の最初のエンタープライズクラスのストリーミングプラットフォームです。 これは、リアルタイムダッシュボードを持つ他のすべての柔軟性に加えて、私たちが提供している非常にユニークな柔軟性です。 埋め込まれたCETエンジン。 HadoopおよびNoSQLインデックス、SolrおよびApacheインデックスとシームレスに統合されています。 それが何であれ、お気に入りのデータベースにアクセスして、アプリケーションを本当に迅速に構築し、本当に迅速に市場に出て、将来の保証を守ることができます。 これがStreamAnalytixの私たちのマントラです。

これで、私は発言を終えると思います。 さらに質問がある場合は、お気軽にお問い合わせください。 Q&Aとパネルディスカッションのためにフロアをオープンにしたいと思います。

レベッカ、あなたに。

Rebecca Jozwiak:いいですね。 どうもありがとうございます。 デズとロビン、聴衆のQ&Aに引き渡す前に質問がありますか?

Robin Bloor:質問があります。 聞こえるようにヘッドフォンを付け直します。 おもしろいことの1つは、もしあなたが親切に私にこれを言うことができれば、私がオープンソース空間で見てきたものの多くは、私に未熟だと言うことのように見えます。 ある意味では、はい、あなたはさまざまなことをすることができます。 しかし、実際には最初または2番目のリリースでソフトウェアを検討しているように見えますが、組織としてのあなたの経験、Hadoop環境の未熟さをどれほど問題があると思いますか?問題が多すぎますか?

Anand Venugopal:それは現実です、ロビン。 あなたは絶対に正しいです。 未熟さは、必ずしも機能的な安定性と物事の領域にあるとは限りませんが、そのいくつかの場合もあります。 しかし、未熟なのは使用の準備が整っていることです。 オープンソース製品であり、Hadoopディストリビューションで提供されているものでさえ、それらはすべて多くの異なる有能な製品であり、コンポーネントは一緒に平手打ちされています。 これらはシームレスに連携せず、スムーズなシームレスなユーザーエクスペリエンスを実現するようには設計されていません。Bankof America、Verizon、AT&Tのように、数週間以内にストリーミング分析アプリケーションを展開します。 彼らはそのために確かに設計されていません。 それが私たちが入る理由です。私たちはそれをまとめ、理解、展開などを本当に簡単にします。

その機能的な成熟度は、大部分はあると思います。 今日、多くの大企業がStormなどを使用しています。 今日、多くの大企業がSpark Streamingで遊んでいます。 これらのエンジンにはそれぞれ実行できる機能に限界があるため、各エンジンで何ができるか、何ができないかを知ることが重要であり、壁に頭をぶつけて言って意味がないSpark Streamingを選択しましたが、この特定の業界では機能しません。」機能しません。 Sparkストリーミングが最適なオプションになるユースケースがあり、Sparkストリーミングがまったく機能しない場合があるユースケースがあります。 だからこそ、本当に複数のオプションが必要です。

Robin Bloor:それには、ほとんどの場合、専門家チームを乗せる必要があります。 私はこれからどこから始めてもわからないということです。 熟練した個人の賢明な共同行動。 エンゲージメントがどのように関与し、どのように発生するかに興味があります。 それは、特定の企業が特定のアプリケーションを求めているからなのか、それともプラットフォーム全体で多くのことをしたいのか、私が戦略的採用と呼ぶようなものを見ているからでしょうか。

Anand Venugopal:両方の例を見ています、Robin。 誰もが知っているトップ10ブランドのいくつかは、非常に戦略的な方法でそれについて進んでいます。 彼らは、さまざまなユースケースがあることを知っているので、そのニーズに合うプラットフォームを評価しています。これは、企業に展開されるマルチテナント方式のさまざまなユースケースです。 同様に開始されている単一のユースケースストーリーもあります。 私たちが取り組んでいる住宅ローン会社には特定のビジネスアクティビティ監視タイプのユースケースがあり、これは最初のユースケースとしては想像できないが、それは彼らが思いついたビジネスソリューションまたはユースケースであり、その後、ドットをストリーミングに接続しました。 私達は言いました これは、ストリーミング分析の優れた事例であり、これを実装する方法です。」 次に、そのプロセスで、彼らは教育を受けて、「ああ、これができて、これが一般的なプラットフォームなら、アプリケーションを分離し、プラットフォームにレイヤー化し、この上に多くの異なるアプリケーションを構築できます」と言います。プラットホーム。"

Robin Bloor:デズ、質問がありますか?

Anand Venugopal: Dezはおそらくミュート状態です。

Dez Blanchfield:謝罪、ミュート。 私は自分自身で良い会話をしました。 ロビンの最初の観察に続いて、あなたは絶対に正しいです。 今の課題は、企業がエコシステムと、フリーでオープンソースのソフトウェアが彼らに知られているものであり、ブラウザとしてFirefoxのようなツールを使用することができ、それがまともなものである文化的および行動的環境を持っていることだと思います安定して安全になるまでの寿命。 しかし、彼らが使用するこれらの非常に大きなプラットフォームの一部は、エンタープライズグレードのプロプライエタリプラットフォームです。 したがって、私がオープンソースプラットフォームと考えるものを採用することは、必ずしも文化的または感情的に理解しやすいとは限りません。 これは、ローカルプロジェクトである小さなプログラムを採用するだけで、ビッグデータと分析を基本的な概念として使用するだけで見ました。 重要な課題の1つは、あなたが組織全体でそれらを見たことがあると確信していることです。結果を得たいという願望であると同時に、それを購入できる古い缶に片足を刺すことです。 「大きなブランドを挿入する」Oracle、IBM、Microsoft。 これらの新しいブランドと既知のブランドは、Hadoopプラットフォームなどで実現しています。 ストリームのような最先端のテクノロジーを備えた、よりエキサイティングなブランドが登場しています。

そのようなやり取りをしたり、カットしたりした会話はどのようなものですか? 今朝は大勢の出席者がいることを知っていますが、誰もが心に留めておくべきことの1つは、「ボードから管理レベルに至るまで、この困難な層全体を切り抜けるにはどうすればいいのでしょうか? 「クライアントとの会話はどのように進み、StreamAnalytixのようなものを採用することを検討するために、こうした種類の恐怖を和らげるところまでどのように切り抜けますか?

Anand Venugopal:実際、顧客は優先オプションとしてオープンソースに移行しているため、実際に価値提案を販売することはかなり簡単です。 彼らは簡単にあきらめて「オーケー、オープンソースに行く」と言っているだけではありません。彼らは実際に主要製品の非常に献身的な評価を行っています。これらのベンダー関係。 彼らは私たちやその製品に対するオープンソースエンジンを扱わないでしょう。 彼らは6〜8〜12週間の評価を受けます。 彼らは、ここにある程度のパフォーマンスと安定性があることを確信し、「うわー、あなたは何を知っていますか、実際にこれを行うことができます」と言って決心します。

今日では、多くのスタック上で運用中にストリーム分析を実行している主要なティア1の電話会社があり、非常に大きな有名な別のベンダーに対してそれを評価しており、すべてを証明して初めて確信しましたパフォーマンス、安定性、およびこれらすべてのもの。 彼らはそれを当たり前だとは思わない。 彼らは評価を通じてオープンソースが有能であることを発見し、最悪の場合、「たぶん私にはできない2つのユースケースがあるかもしれませんが、今日のビジネス加速ユースケースのほとんどはオープンソースで非常に可能です」そして、その使用を有効にします。 それがまさにそこにある大きなスイートスポットです。 彼らはオープンソースを望んでいました。 彼らは、長年使用されてきたベンダーのロックイン状態から抜け出すことを本当に望んでいます。 それからここに来て、「あなたは何を知っている、私たちはあなたのためにオープンソースをはるかに、はるかに簡単で使いやすいものにするでしょう。」

Dez Blanchfield:企業が見つける他の課題は、彼らが伝統的な現職を持ち込むときであると思います。彼らはしばしばここで話しているエキサイティングなものの最先端のいくつかの背後にある世代であり、私はそれがわずかに負。 現実には、安定したプラットフォーム、古い学校の開発、UATNの統合サイクル、テストと文書化、マーケティングと販売を検討するために、世代と道程を経て、彼らが安定したプラットフォームと見なすものをリリースしているのです。 あなたがやっているタイプでは、私が考えているのは、昨夜あなたの最新リリースのいくつかを調べて、ある種の研究作業をしていることだと思います。先行コンサルティングの観点からのコンピテンシーと実装だけでなく、ロールインできるスタックも手に入れました。これは、現職者がしばらく苦労するところだと思います。 私は市場で見たようにそれらの多くを見てきました。 それらはしばしば私がキャッチアップノードと呼ぶものの中にありますが、あなたがそこにいて会話をしていて実装しているときにあなたが私たちに言っていることから。

あなたが採用しているいくつかの国境の例について教えてください。 たとえば、ロケットサイエンスや宇宙に衛星を配置し、火星からデータを収集するような、本当に素晴らしい環境があります。 地球上でそれをしている人はほんの一握りです。 しかし、例えば、航空学、海運とロジスティクス、製造とエンジニアリングなど、健康のような大きな垂直産業があります。採用?

Anand Venugopal: Telcoは大きな例です。

ここでスライドをすぐに修正します。 ここでスライドを見ることができますか?

これは、大規模な電話会社がセットトップボックスデータを取り込み、それを使用して複数の処理を行う場合です。 彼らは顧客が実際に何をしているのかをリアルタイムで見ています。 彼らは、セットトップボックスでリアルタイムにエラーが発生している場所を見ています。 彼らはコールセンターに通知しようとしています。この顧客がすぐに電話をかけた場合、この顧客のセットトップボックスからのコードリンク情報、メンテナンスチケット情報は、この特定の顧客のセットトップボックスに問題があるかどうかをすばやく関連付けます顧客は一言話す。 すべてのケーブル会社、すべての主要な電話会社がこれを試みています。 彼らはセットトップボックスデータを取り込み、リアルタイム分析を行い、広告を掲載できるようにキャンペーン分析を行います。 巨大なユースケースがあります。

先ほど言ったように、大規模なシステムがデータの処理に関与する一般的なパターンであるこの住宅ローン会社があります。 システムA、システムB、システムCを流れるデータは規制されたビジネスであり、すべてが一貫している必要があります。 多くの場合、システムは互いに同期しなくなり、1つのシステムは「合計金額1, 000万ドルで100件のローンを処理しています」と言っています。システムは、「いいえ、110件のローンを処理しています彼らは実際に同じデータを処理し、異なる解釈をしているため、彼らはそれを本当に迅速に解決しなければなりません。

クレジットカード、ローン処理、ビジネスプロセス、または住宅ローンのビジネスプロセスなどのいずれであっても、これらのビジネスプロセスの同期を維持するために、リアルタイムで相関と調整を行うのを支援しています。 それは別の興味深いユースケースです。 異常検出を行うためにDNSトラフィックを調べている主要な米国政府の請負業者がいます。 彼らが構築したオフライントレーニングモデルがあり、リアルタイムトラフィックでそのモデルに基づいてスコアリングを行っています。 これらの興味深いユースケースのいくつか。 セキュリティキューを見ている大手航空会社があり、彼らはあなたにその情報を提供しようとしています。「ねえ、それはあなたの飛行機の飛行機のゲートです。 今日のTSAキューは約45分であり、2時間ではなく他の何かです。」 彼らはまだそれに取り組んでいます。 興味深いIoTユースケースですが、カスタマーエクスペリエンスに向かうストリーミング分析の素晴らしいケースです。

Rebecca Jozwiak:これはRebeccaです。 ユースケースの主題については、「これらのケーススタディは、これらのイニシアチブが家の情報システム分析側から推進されているのか、それともそれ以上に推進されているのか」と疑問に思う聴衆から大きな質問があります。特定の質問やニーズを念頭に置いているビジネスですか?」

Anand Venugopal:約60パーセント、50パーセントから55パーセント、主に非常に積極的で熱心なテクノロジーイニシアチブがあり、たまたま特定のビジネス要件を知っており、特定のビジネス要件を理解していると思います。特定されましたが、これらはビジネスユースケースの猛攻撃に備えて準備を整えているテクノロジーチームであり、機能を構築すると、これを実行できることを知ってから、ビジネスに参入して積極的に販売します。 30%から40%のケースでは、ストリーミング分析機能を求めている特定のユースケースが既にビジネスにあることがわかります。

Rebecca Jozwiak:それは理にかなっています。 聴衆からもう少し技術的な質問があります。 彼は、これらのシステムがリアルタイムでのTwitterストリームの堆積物やFacebook投稿など、構造化データストリームと非構造化データストリームの両方をサポートするのか、それとも最初にフィルタリングする必要があるのか​​疑問に思っています。

Anand Venugopal:私たちが話している製品とテクノロジーは、構造化データと非構造化データの両方を非常に切迫してサポートしています。 それらは構成できます。 すべてのデータは、テキストであろうとXMLであろうと、なんであれ、何らかの構造を持っています。 タイムスタンプフィードがあるという点で、いくつかの構造があります。 データ構造を解析するために解析をストリームに挿入できるように、解析が必要な別のblobが存在する可能性があります。 構造化されている場合は、システムに「わかりました。カンマ区切りの値があり、最初の値が文字列で、2番目が日付の場合」です。したがって、その解析インテリジェンスをアップスクリーンレイヤーに注入し、構造化データと非構造化データの両方を簡単に処理します。

Rebecca Jozwiak:聴衆から別の質問があります。 私たちは1時間を少し過ぎて実行していることを知っています。 この参加者が知りたいのは、リアルタイムストリーミングアプリケーションが、トランザクションシステム、たとえば不正防止システムに統合する必要性と機会の両方を開発しているように思われることです。 その場合、トランザクションシステムをそれに合わせて調整する必要がありますか?

Anand Venugopal:それはマージですよね? トランザクションシステムの統合です。 それらは時々トランザクションをリアルタイムで分析するデータのソースになります。多くの場合、アプリケーションフローがあるとしましょう。ここでは、静的なデータルックアップサイトを表示しようとしています。で、HBaseやRDBMSなどの静的データベースを検索して、ストリーミングデータと静的データを一緒に充実させて、決定または分析的洞察を行います。

また、OLAPとOLTPの収束という業界の大きなトレンドも見られます。そのため、トランザクションと分析処理の両方を同時にサポートするKuduなどのデータベースとインメモリデータベースがあります。 ストリーム処理層は完全にメモリ内にあり、これらのトランザクションデータベースの一部を調べたり、これらのトランザクションデータベースとインターフェイスしたりします。

Rebecca Jozwiak:混合ワークロードは、ジャンプすべき最後のハードルの1つであると思います。 ロビン、デズ、もう2つ質問がありますか?

Dez Blanchfield:最後の質問に飛び込んで、もし気に入らなければそれをまとめます。 過去10年ほど私が取り組んできた組織がストリーム分析のこの刺激的な課題に導いた最初の課題は、この課題全体についての会話を始めたときに彼らがテーブルに戻す傾向がある最初のものですスキルを取得しますか? スキルセットをどのように再トレーニングし、その機能を内部でどのように取得しますか? Impetusが入って来て、私たちを旅に引き込み、それから素晴らしい最初のステップとして実装します。そうすることはとても理にかなっています。

しかし、中規模から大規模の組織の場合、現時点でこれを準備し、その機能を内部で構築し、その周辺の基本的な語彙から何を得るために、どのような種類のメッセージを表示できるのか、この種のフレームワークへの移行を取り巻く組織は、CEOからITの既存の技術スタッフを改造し、構築して実装した後に彼ら自身がこれを実行できるようにしますか? 簡単に言えば、どのような課題とそれらをどのように解決しているのか、あなたが対処している顧客、彼らが見つけた課題の種類と、そのための準備をするための経験と知識を再訓練して取り戻すためにどのように解決するか運用的に回ることができますか?

Anand Venugopal:多くの場合、外出してストリーミング分析プラットフォームを購入しようとする少数の人々は、Hadoopを認識し、Hadoop MapReduceスキルを既に獲得しており、Hadoopと密接に連携しているため、すでにかなり合理的です。流通ベンダー、彼らはどちらかおなじみです。 たとえば、すべてがKafkaを取得しています。 彼らはそれを使って何かをしていて、StormまたはSparkのストリーミングがオープンソースドメインにあります。 確かに、人々はそれに精通しているか、それを中心にスキルを構築しています。 しかし、それは、十分なスキルを持ち、十分に賢い少数の人々から始まります。 彼らは会議に参加しています。 彼らは学んでおり、ベンダーにインテリジェントな質問をし、場合によってはベンダーとともに学びます。 ベンダーは最初の会議に来て発表するので、彼らは何も知らないかもしれませんが、彼らは一緒に読んで、それから遊び始めます。

その小さな人々のグループが核となり、成長を始め、今では誰もが最初のビジネスユースケースが運用可能になっていることに気付きます。 波が始まり、先週のSparkサミットで、Capital Oneのような大企業が全力を尽くしていたのを見ました。 彼らはスパークを選んでいた。 彼らはそれについて話していました。 彼らは多くの場合、ユーザーとしてSparkにも貢献しているため、Sparkで多くの人々を教育しています。 多くの大企業でも同じことが言えます。 少数の非常に優秀な人々で始まり、その後、全体的な教育の波が始まります。上級VPまたは上級ディレクターが一同になり、このことに賭けたいと思っていることを知っています。それらはすべてこれらのスキルを習得し始めます。

Dez Blanchfield:それらのチャンピオンを作るのに素晴らしい時間があると確信しています。

Anand Venugopal:はい。 私たちは最初のチャンピオンと協力しながら多くの教育を行い、トレーニングコースを開催します。多くの大規模な顧客のために多くの人が戻ってきて、多くのユーザーを主流の使用段階に導くためのトレーニングの波と波がありましたHadoop MapReduceサイトで。 私たちの顧客である大規模なクレジットカード会社では、少なくとも5〜8種類のトレーニングプログラムを提供していることがわかりました。 また、当社の製品を含むこれらすべての製品の無料のコミュニティエディションもあります。

Dez Blanchfield:今朝はこれで全部です。 どうもありがとうございました。 今日のモデルの種類と使用事例を見るのは非常に興味深いと思います。 ありがとうございました。

Anand Venugopal:素晴らしい。 どうもありがとうございます。

Rebecca Jozwiak: Hot TechnologiesのWebキャストにご参加いただきありがとうございます。 Dez Blanchfield博士、Robin Bloor博士、およびImpetus TechnologiesのAnand Venugopal氏の話を聞くのは魅力的です。 プレゼンターに感謝します。 スピーカーに感謝し、聴衆に感謝します。 来月は別のHot Technologiesがあるので、それを探してください。 Insideanalysis.comでアーカイブされたコンテンツをいつでも見つけることができます。 また、SlideShareには多くのコンテンツを掲載し、YouTubeにもいくつかの興味深い情報を掲載しています。

それはすべての人々です。 再びありがとう、良い一日を。 バイバイ。

ファイアホースの活用:ストリーミング分析からビジネス価値を得る:ウェビナーのトランスクリプト