コンテンツ
出典：Jakub Jirsak / Dreamstime.com
取り除く：
ホストのエリック・カバナは、業界の専門家とビッグデータ分析について議論します。
エリック：ご列席の皆様、それは2014年の終わりです-少なくとも、ほとんど。今年最後のウェブキャストです、皆さん！ TechWiseへようこそ！はい、確かに！私の名前はエリック・カバナです。すばらしいウェブキャストの司会者になります。私は本当に興奮しています。オンラインには2人の素晴らしいアナリストがおり、このビッグデータエコシステム全体の真の革新者である2つの優れた企業がいます。そして、ビッグデータ分析の鍵は違いを理解することです。それでは、先に進みましょう。
プレゼンターが数人います。あなたが見ることができるように、あなたの上に本当にあります。マイク・ファーガソンは、英国から電話をかけています。英国では、オフィスビルに滞在するために特別な特権を取得する必要がありました。それは彼にとって遅すぎます。 Bloor Groupの私たち自身のチーフアナリストであるRobin Bloor博士がいます。そして、RedPoint GlobalのCEO兼共同設立者であるGeorge Corugedoと、SAS InstituteのシニアソリューションアーキテクトであるKeith Renisonがいます。これらは素晴らしい会社です。これらは本当に革新的な企業です。そして、ビッグデータの世界全体で今起こっていることの良い部分を掘り下げていきます。直面してみましょう、小さなデータは消えていません。それに、ここで私のエグゼクティブサマリーをお聞かせください。
そのため、古いフランス語の表現があります：「より多くのものが変化するほど、それらは同じままです。」ここでいくつかの事実に直面しましょう。ビッグデータは小さなデータの問題を解決するものではありません。企業の小さなデータはまだそこにあります。まだどこにでもあります。これは、今日の情報経済の運用の燃料です。ビッグデータは、これらのいわゆる小規模企業データを補完しますが、小規模データに取って代わるものではありません。まだまだあります。私はビッグデータ、特に機械生成データのようなものについて多くのことが好きです。
今日は、おそらくソーシャルメディアデータについても少しお話します。これも非常に強力なものです。そして、例えば、ソーシャルがビジネスをどのように変えたかについて考えるなら、ここの3つの簡単なウェブサイトを考えてみてください：、LinkedInおよび。 5年前、誰もそのようなことをしていないという事実を考えてください。最近の絶対的なジャガーノートです。 、もちろん、巨大です。それは巨大です。そして、LinkedInは企業のネットワーキングとコミュニケーションの事実上の標準です。これらのサイトは膨大で、その中にあるデータを活用できるようにするために、ゲームを変えるいくつかの機能を復活させます。多くの組織にとって、少なくともそれを利用する組織にとっては、本当に多くの利益をもたらすでしょう。
バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド
誰もソフトウェアの品質を気にしない場合、プログラミングスキルを向上させることはできません。
したがって、ガバナンス—ガバナンスは依然として重要です。繰り返しますが、ビッグデータはガバナンスの必要性を無効にするものではありません。率直に言って、ビッグデータの世界をどのように管理するかに焦点を合わせる必要がまったくありません。手順とポリシーが整っていることをどのように確認しますか。適切な人が適切なデータにアクセスしていること。あなたは連絡先を持っていること、あなたはここに関係しているのですか？実際に、データがどこから来たのか、何が起こったのかを知っています。そして、それはすべて変化しています。
Hadoopエコシステムを活用しているこのまったく新しい世界で私が目にしたもののいくつかに、私は率直に感銘を受けました。もちろん、機能の観点からはストレージ以上のものです。 Hadoopも計算エンジンです。そして同社は、その計算能力、その並列処理能力をどのように活用するかを理解する必要があります。彼らは本当に、本当にクールなことをするつもりです。今日はそれについて学びます。
言及すべきもう一つのことは、これは最近ブロア博士が話したことですが、イノベーションの波はまだ終わっていないということです。そのため、もちろん、Hadoopに関して多くの注目を集めています。 ClouderaやHortonworksなどの企業は、実際にいくつかの波を作っています。そして、彼らは今日、非常に率直に言って、呼び出し中の企業とのパートナーシップを開発しています。そして、彼らは多くの人々とパートナーシップを築いています。しかし、イノベーションの波はまだ終わっていません。 Apache Foundationからスピンアウトするプロジェクトがさらにあり、エンドポイントだけでなく、人々が使用するアプリケーションだけでなく、インフラストラクチャ自体も変更しています。
したがって、YARNのこの開発全体（さらに別のリソースネゴシエーター）は、ビッグデータのオペレーティングシステムのようなものです。それは大したことですそれで、それが物事をどのように変えるかを学びます。したがって、ここでのほんの数ビットの明らかなアドバイスは、今後の長期契約に注意してください、5年、10年契約は波になりそうです。どうしてもロックインを避けたいと思うでしょう。今日はそのすべてについて学びます。
それで、今日話す最初のアナリスト—プログラム全体の最初のスピーカーはマイク・ファーガソンで、英国から電話をかけます。それで、私はあなたに鍵を渡します、マイク、それを取り去らせます。マイク・ファーガソン、床はあなたのものです。
マイク、そこにいるの？ミュートになっている可能性があります。彼の声は聞こえません。彼に電話し直さなければならないかもしれません。そして、Robin Bloorのスライドにジャンプします。ロビン、私はここで貧しいマイク・ファーガソンのランクを引き上げるつもりです。ちょっと行きます。
マイクですか？聞こえますか？いや先にロビンと一緒に行かなければならないと思います。だから、ちょっと待って、みんな。ここ数分で、スライドへのリンクもいくつか表示します。それで、Robin Bloorに鍵を渡します。ロビン、マイクの代わりに先に行くことができます。すぐにマイクに電話します。
ロビン：わかりました。
エリック：ちょっと待って、ロブ。ロブ、スライドをここに上げましょう。少し時間がかかります。
ロビン：わかりました。
エリック：うん。ただし、ここではガバナンスの観点から、私たちが何を扱っているかについてお話しいただけます。ガバナンスについてお話しします。これは通常、小さな企業データの詐欺で考えられています。さて、スライドを上げました、ロビン。何も動かさないでください。そしてここに行きます。床はあなたのものです。奪って
ロビン：わかりました。うん。つまり、マイクは分析的な側面について話し、ガバナンスの側面について話します。ある程度まで、ガバナンスはアナリティクスに従いますが、それはビッグデータを扱う理由であり、アナリティクスを行うためにすべてのソフトウェアをアセンブルする理由は、そこに価値があるという意味です。
問題があります。そして問題は、あなたが知っているように、データを混乱させる必要があるということです。データをマーシャリングする必要があります。データは、分析が完全な自信を持って行われることを可能にする方法でまとめられ、管理される必要があります。ですから、私が話したいのは、方程式のガバナンスの側面だと思いました。本当に言うべきことは、ガバナンスがすでに問題になっているということです。ガバナンスはすでに問題であり、データウェアハウスゲーム全体で問題になり始めています。
実際に起こったことは、それがより大きな問題に変わったことです。そして、それがより多くのデータと同様にはるかに大きな問題に変わった理由ですが、私は、本当に、これらの理由です。データソースの数は劇的に拡大しました。以前は、データウェアハウスに供給されたものによって、全体的に定義されていたデータソースが定義されていました。通常、データウェアハウスにはRTPシステムからデータが供給されます。わずかな外部データが可能ですが、それほど多くはありません。
今、私たちはあなたが知っているように、データ市場が現在存在している世界に行きました。したがって、データの取引があります。組織に実際に持ち込むことができるさまざまなデータのストリーミングソースの負荷と負荷を既に持っています。ソーシャルメディアデータがあります。これは、いわば、独自のアカウントで削除されたものです。つまり、ソーシャルメディアサイトの価値は、実はそれらが集約する情報であり、したがって人々が利用できるようにすることができるということです。
また、すでに存在しているような発見もあります。 Splunkの登場により、既にこれらのログファイルがありました。そしてすぐに、ログファイルに価値があることが明らかになりました。そのため、組織内には、外部データソースと同様に新しいデータソースと呼ばれるデータがありました。だから、それは一つのことです。そして、それは本当に、以前のデータ管理のルールが何であれ、何らかの形で拡張する必要があり、実際に管理するために拡張する必要があることを意味しますデータ。しかし、私たちは今、何らかの形で組み立て始めています。
このリストを下に行くと、ストリーミングとデータの到着速度があります。 Hadoopが人気を博した理由の1つは、Hadoopを使用して多くのデータをキャッチできることです。また、データ速度を取り込むことができるため、実際にすぐに使用する必要がない場合は、優れた並列、巨大な並列環境になります。しかし、あなたは現在かなりの量のストリーミング分析が行われているという事実も持っています。かつてはストリーミングアプリケーションに関心を寄せていた銀行セクターでしたが、現在はグローバルになりました。そして、誰もが何らかの方法でストリーミングアプリケーションを見ています。これは、データから価値を引き出し、組織の分析を行う潜在的な手段です。
非構造化データがあります。通常、世界のデータのわずか10％の一部である統計は、リレーショナルデータベースにありました。さて、その主な理由の1つは、ほとんどが実際に構造化されていないことでした。そのデータは分析可能でも使用可能であることが証明されています。そして、シマンテックの技術の出現により、徐々に状況に忍び込み、ますますそうなりつつあります。そのため、非構造化データを実際に収集して管理する必要があります。これは、以前よりもはるかに大きいことを意味します。既に述べたソーシャルデータはありますが、それについてのポイント、それに関する主なポイントは、おそらくクリーニングが必要だということです。
モノのインターネットのデータがあります。それはある種の異なる状況です。多くの可能性がありますが、その多くは、それが運営されている場所の近くのどこかに分散している必要があります。しかし、何らかの方法でそれを引き出して、組織内でデータを分析することもできます。それで、さらに別の要因が追加されました。そして、そのデータはおそらく別の方法で構造化されます。おそらく、JSONまたはXMLでフォーマットされ、それ自体を宣言するからです。そして、何らかの方法で、実際にデータを取り込み、その特定のデータの読み取り時に一種のスキーマを実行できることだけではありません。
起源の問題があり、これは分析の問題です。あなたがデータを行っている分析の結果は、データの出所がわからない限り、実際に承認することはできません。つまり、それはデータサイエンティストの活動という点での単なるプロフェッショナリズムです。しかし、データの出所を確認するには、実際にデータを管理し、その系統に注意を払わなければならないことを知っています。
コンピューターの処理能力と並列性の問題があり、それはすべてを高速化することです。問題は、明らかに、私たちが導入した特定のプロセスは他のすべてにとって遅すぎるかもしれないということです。そのため、速度の点で不一致が生じる可能性があります。
機械学習の登場です。機械学習には、実際、分析を以前とは異なるゲームにする効果があります。しかし、実際に使用できるのは、パワーを持っている場合のみです。
新しい分析ワークロードの事実がわかりました。並列の世界があり、最大の効果を得るにはいくつかの分析アルゴリズムを並列に実行する必要があります。したがって、問題は実際に、何らかの方法で実際にデータをプッシュし、利用可能な場合はデータを作成する方法を管理することです。また、データベース内で実際に分析ワークロードを実行している可能性があるため、実際に分析ワークロードを実行します。したがって、分析アプリケーション内でそれを行っている可能性があります。
そのため、一連のガバナンスの課題があります。今年私たちがしたこと—今年私たちが行った研究は、ビッグデータアーキテクチャに関するものでした。そして、実際にそれを一般化しようとすると、私たちが思いついた結論-私たちが思いついた図は、このように見えました。
特に、Mikeが分析用のデータアーキテクチャについてかなりの量を行うので、これについては説明しません。しかし、私が実際に人々が注目するのが好きなのは、私たちが何らかの形でデータを集めているこの底部の領域です。私が参照したいのは、データ精製所またはデータ処理ハブです。そしてそこでガバナンスが行われます。ですから、私たちが何らかの焦点を当てると、そのように見えます。ご存知のように、内部および外部ソースからのデータが供給されています。理論的には、ハブは生成されるすべてのデータを取得する必要があります。分析とデータのストリーミングが必要な場合は、ストリーミングされたとおりにストリーミングおよび管理され、ハブに渡される必要があります。または、すべてがハブに入ります。そして、進行中の多くのことがあります-それはハブで起こっています。また、ハブで一定量の分析とSQLを実行することはできません。ただし、データを他の領域にプッシュするには、各セルでデータを仮想化する必要もあります。しかし、そのいずれかが起こる前に、実際には何らかの方法で、データの準備を改善する必要があります。データ準備と呼ぶことができます。それよりもずっと大きいです。これらは私がそれが含むと思うものです。
ある意味で、これがデータレイヤーの主要な部分であるという意味で、システム管理とサービス管理があり、実際に、ほとんどすべての運用システムにこれまで行ってきた運用システム管理努力を管理するすべてのシステムを適用する必要があります。しかし、何らかの方法で、これらのさまざまなサービスレベルが満たされていることを確認するために、他のことを監視する必要もあります。これは、定義されたサービスレベルまたはアクションとしてのあらゆる種類の分析、またはBIデータがバインドされているためです行動されている。
パフォーマンスの監視と管理が必要です。それ以外の場合は、さまざまな時点でさらにどのコンピューターリソースを割り当てる必要があるかを知るために必要です。しかし、実際には非常に多くのワークロードが実際に存在し、かなり複雑で、リソースをめぐって互いに競合しています。その分野で行う必要がある非常に洗練されたものがあります。
これまでにない方法でデータのライフサイクルが得られました。ここでの取り決めは、データの収集と破棄を行わなかったという点で、他の何よりも優れています。必要なデータを収集する傾向があり、おそらくそれを保持してから、アーカイブしました。しかし、これからやるのは、データの探索です。また、データが必要ない場合は、埋めてみましょう。そのため、データのライフサイクルは状況に応じて異なりますが、非常に多くのデータが集約されます。したがって、あなたは、集約がどこから来たのか、集約のソースが何であるのかなどを知ることができます。それはすべて必要です。
データ系統は自然に役立ちます。それなしでは、問題を知る必要があるので、データは...データが有効であるが、実際にどれだけ信頼できるかを知る必要があります。
データマッピングもあります。これは、実際には多くのデータが何らかの形で実際に使用されるためです。必要に応じて、これはMDMのある程度の範囲に関連しています。 JSONによって定義された、または読み取り時のXMLスキーマに基づいて非常に多くのデータを取得した場合、何らかの方法で非常にアクティブにする必要があるためです。進行中のデータマッピングアクティビティ。
MDM以外のメタデータ管理状況があります。何らかの方法で、今私が考えたいものを、あなたが興味を持っているすべてのものの一種のメタデータウェアハウスとして構築する必要があるからです。メタデータがありますデータの一部は必ずしもメタデータが宣言されているとは限らないため、すぐに使用したいためです。そして、データのクレンジングがあります。これは、そこで行うことができる一連のこととして大きなことです。また、データのセキュリティもあります。このデータはすべて、許容可能なレベルに保護する必要があります。これは、特定のインスタンス（たとえば、多くの値を暗号化する場合）でさえ意味する場合があります。
したがって、このワークロードはすべてガバナンスの帝国です。このすべては、何らかの形で、すべての分析活動と同時に、またはその前に行わなければなりません。これは多数の調整されたアプリケーションです。それ自体がシステムです。そして、さまざまな時点でそれをしない人は、進むにつれてそれが不足することに苦しむでしょう。これらのことの多くは本当にオプションではないからです。エントロピーを行わないと、エントロピーが増加してしまいます。
したがって、データ分析とガバナンスの観点から言えば、私が言いたいのは、実際には片方がもう片方を洗うということです。ガバナンスがなければ、アナリティクスとBIが時間を無駄にすることはありません。そして、分析とBIがなければ、とにかくデータを管理する必要はほとんどないでしょう。したがって、2つのことは本当に密接に関連しています。彼らが中東で言うように、「片手はもう片方を洗う」。そして、実際に私が言いたいことはこれだけです。願っています—うまくいけば、マイクが戻ってきました。
エリック：やる。マイク、私はあなたがそこにいると思います。スライドを押し上げます。
マイク：私は。さて、聞こえますか？
エリック：うん、聞こえるよ。すばらしいですね。それでは、私に紹介させてください...どうぞ。そして、あなたは現在プレゼンターです。奪って
マイク：わかった、ありがとう！おはようございます、こんにちは、こんばんは。最初にしゃっくりを許してください。なんらかの理由で、私は自分自身を黙らせ、全員を見ることができましたが、彼らは私を聞くことができませんでした。
わかった。ですから、私がすぐにやりたいのは、ビッグデータ分析エコシステムについてです。私に質問したい場合は、このセッション以降で、連絡先の詳細をこちらから入手できます。私が言ったように、ここイギリスの深夜。
さて、私が話したいことを話しましょう。明らかに、ここ数年にわたって、クリックストリームデータからオンライン行動の理解、エリックが話していたソーシャルメディアデータまで、ビジネスが現在分析したいあらゆる種類の新しい種類のデータが出現しています。ここからプログラムの始まり。ロビンはJSON、BSON、XMLに言及したと思います。つまり、自己記述的な半構造化データです。もちろん、構造化されていないデータ、ITインフラストラクチャのログ、センサーデータなど、他にもたくさんのものがあります。比較的新しいデータソースのすべてには、企業が現在興味を持っているものがあります。これは、私たちの知識を深める可能性のある貴重な洞察を含んでいるからです。
つまり、基本的には、分析環境が従来のデータウェアハウジングを超えて移動したことを意味します。構造化データとマルチ構造化データの組み合わせの世界にデータを構築しますが、多くの場合、マルチ構造化データは企業の内部または外部から取得できます。そして、これらの新しいデータタイプと分析する新しいニーズの結果として、新しい分析ワークロードの出現が見られました。動きのあるデータの分析から、従来のデータウェアハウジングアーキテクチャを多少なりとも変えるものまで、従来のサークルでは、データの統合、クリーニング、変換、保存、分析を行いました。しかし、移動中のデータを分析する場合、データをキャプチャし、統合し、分析してデータを準備してから保存します。したがって、データはどこにでも保存される前に分析されます。
モデル開発、統計的および予測的モデル開発のために、構造化データの分析を複雑にします。これは、従来のデータウェアハウジングの分野の一部の人々にとって新しいことではありません。モデル上のデータの探索的分析を行いました。それがそこにある構造化データの量です。グラフ分析の形で新しいワークロードがあります。これには、金融サービスのクライアントには詐欺などが含まれます。サイバーセキュリティも含まれます。もちろん、ソーシャルネットワーク、インフルエンサーなどの理解も含まれます。私もそれを管理で習得し、数年のグラフ分析を行いました。
データウェアハウスの最適化またはETL処理のオフロードがあります。これは一種のITユースケースであり、CIOが資金を提供する可能性があります。さらに、データやデータウェアハウスをアーカイブして、Hadoopなどでオンラインに保ちます。そのため、これらの新しい分析ワークロードはすべて、分析プラットフォームに新しいプラットフォーム、新しいストレージプラットフォームを追加しました。そのため、従来のデータウェアハウス、データマートを使用するのではなく、Hadoopを使用することになりました。分析ワークロードによく使用されるグラフデータベースなどのNoSQLデータベースがあります。もちろん、Hadoop自体とNoSQLグラフDBMSでグラフ分析を行うことができます。ロビンが言及したストリーミング分析があります。また、必要に応じて、おそらく分析データウェアハウスアプライアンス上にモデルを構築しています。しかし、これらはすべて分析の状況を複雑にしており、複数のプラットフォームが必要になっています。そして、フロントオフィスやバックオフィス、または財務、調達、人事などのあらゆるビジネスの課題は、どの分析プロジェクトが従来のデータウェアハウジングシーンに関連しているかを把握することだと思います。そして、分析プロジェクトがこれらの新しいビッグデータプラットフォームに関連付けられ、どこで実行されるかがわかれば、どの分析ワークロードがわかるのかがわかりますが、ビジネスという意味でビジネスを見失うことはありません。データ分析プロジェクトと従来のビッグデータウェアハウジングプロジェクトは、顧客や業務、リスク、財務、持続可能性などの内部を強化するために一緒に必要です。したがって、これらすべてを戦略的ビジネスの優先事項と整合させ、ビジネスのパフォーマンスを向上させ、コストを削減するために、プッシュする必要のある針を軌道に乗せるようにします。当社全体のリスクなどを軽減するために。したがって、ここで一方が他方をビッグデータで従来のものに置き換えるわけではありません。両方一緒に使用されています。そして、それはアーキテクチャを劇的に変えます。
ですから、私がここで持っているのは、クライアントで使用する比較的新しいアーキテクチャです。そのため、下の方にあるように、構造化されただけでなく、さまざまなデータソースがあります。それらの一部は、センサーのようなライブデータ、市場データのようなライブデータをストリーミングしています。ライブクリックストリームデータである場合もあります。ライブビデオストリーミングデータである可能性があります。そのため、構造化する必要はありませんでした。そのため、そのデータに対してストリーム処理を実行して、リアルタイムで自動アクションを実行できます。また、関心のあるデータをフィルター処理し、分析データストアに入力するために使用できるエンタープライズ情報管理ツールに渡すことができます。ここでのミックスを見ることができない限り、従来のデータウェアハウジング、Hadoop、NoSQLデータベースがあります。ミックスにもマスターデータ管理があります。そして、これらのデータストアにデータを追加するだけでなく、データストア間でデータを移動するために、データ管理ツールスイート全体により大きなプレッシャーがかかります。
さらに、アクセスツールを簡素化する必要があります。ユーザーに向かって「これらすべてのデータストアを取得し、これらのAPIを保持してください-あなたの問題」と言うことはできません。あなたがしなければならないことは、アクセスを簡単にすることです。そのため、点線で示すように、データの仮想化と最適化は、複数のデータストレージの複雑さを隠しているように見え、エンドユーザーがこれに簡単にアクセスできるようにします。もちろん、上部にはさまざまなツールがあります。データウェアハウジングの上部から始めた従来のBIツールから、グラフの左側に徐々に移動してHadoopに接続するものまで、すべてが揃っています。そして、世界のNoSQLデータベース。
検索は、特にHadoopに保存されることが多い身体構造化された、構造化されていないデータを中心に、生命の新たなリースを獲得しました。 MapReduceを使用してHadoopプラットフォームでカスタム分析アプリケーションを実行できるようにしました。たとえば、Sparkフレームワークです。ご存知のように、グラフ分析ツールを使用して、非常に具体的なワークロードに集中できます。そのため、さまざまなツールとデータフローもより複雑になります。データウェアハウスの一方通行ではありません。もちろん、現在はマスターデータです。
新しいデータソースが追加されました。NoSQLでキャプチャされるか、MongoDBのようなデータストア、Cassandraのような、HBaseのようなデータストアがあります。分析とデータ準備のためにデータをHadoopに直接持ち込んでいます。 Hadoopとデータウェアハウスから新たな洞察が生まれています。データウェアハウスからHadoopにアーカイブが追加されました。これで、すべてのNoSQLデータベースとデータマートにもデータフィードが送られました。ですから、ここで見ることができるのは、データ管理においてはるかに多くの活動が行われているということです。そして、それはデータ管理ソフトウェアにかなりのプレッシャーをかけていることを意味します。もはや一方通行ではありません。これは双方向のデータ移動です。さらに多くの活動が行われているため、データ管理ツールの面でもデータソースでもスケーラビリティが重要です。
したがって、このチャートは、先ほど触れたそのアーキテクチャに戻ります。このアーキテクチャのさまざまな部分で実行されているさまざまな分析ワークロードを示しています。左下の並べ替えでは、リアルタイムストリーミング、あらゆる種類のライブデータストアからのデータのストリーム処理を行っています。 NoSQLグラフデータベースでクラス分析が行われています。 Hadoopでも発生する可能性があります。たとえば、SparkフレームワークとそこにあるGraphXを使用して、RobinがHadoopでの出来事について話していた調査分析とデータ精製を行いました。従来のワークロードがまだ進行中で、データウェアハウジングは、おそらくデータウェアハウスアプライアンス上で統計モデルと予測モデルを構築するパワーユーザーです。そして、エンドユーザーが簡単にアクセスできるように、これらすべてへのアクセスを簡素化しようとしています。
したがって、このセットアップ全体での成功は、単なる分析的な側面以上のものです。分析プラットフォームを適切に配置することはできますが、大規模で高速かつ大量のデータをキャプチャして取り込むことができない場合、あまり意味がありません。分析するものは何もありません。したがって、ビッグデータ分析の成功には、運用システムのスケールアップが必要です。つまり、新しいトランザクションをサポートできるようにするには、ピーク時です。そこにキャプチャされている非トランザクションデータは、センサーや取り込みなどの高速データの非常に高い到着率である可能性があります。このすべてに対応できるようにする必要があります。この種のデータをキャプチャし、分析のために取り込むことができます。また、分析自体をスケーリングし、既に述べたデータへのアクセスを簡素化する必要があります。そして、それを結びます。ご存知のように、クローズドループを提供するには、これらの運用システムに戻って改良できる必要があります。
そのため、家の運用面をスケーリングしてデータをキャプチャすることは、ご存知のように、NoSQLデータベースの世界に入り込みます。つまり、ここには5つのカテゴリのNoSQLデータベースがあります。このカテゴリは、上記の他の4つの組み合わせのみでモデル化されます。一般的に、キー値、保存されたドキュメント、および最初の3つの列ファミリーデータベースは、より多くの種類のトランザクションデータおよび非トランザクションデータに使用されます。
プロパティとしてサポートするデータベースの一部。それらのいくつかはそうではありません。しかし、それでも、これらの種類のアプリケーションをスケーリングするために、それらの導入を見ています。そのため、たとえば、キーボードで取引を入力する従業員だけから離れて、現在の顧客や、新しいデバイスを使用して大衆がそれを行えるようになりました。企業に入力されるトランザクションの数が大幅に増加しました。そのため、トランザクションアプリケーションをスケーリングする必要があります。
今、一般的に言えば、それはここに示すNuoDBやVoltDBのようなリレーショナルデータベースとしてNewSQLデータベースで実行できます。または、トランザクション処理を保証できるACIDプロパティをおそらくサポートする一部のNoSQLデータベースが動作している可能性があります。これは、トランザクション前のショッピングカートデータなどの非トランザクションデータにも当てはまります。何億ものセンサー読み取り値の中でセンサー読み取り値が失われるので、人々が商品やセンサーデータを購入する前に知っています。それは大したことありません。クリックストリームの世界でのクリック-ご存知のとおり、クリックを使用しても大したことはありません。ACIDプロパティは必ずしも必要ではありません。NoSQLデータベースが役に立つのはそのためです。非常に高度で適切な処理を行い、これらの新しい種類のデータをキャプチャする機能があります。
同時に、分析の規模を拡大したいと考えています。したがって、データが大きすぎるため、データをデータストアから分析プラットフォームにプルしても、ハッキングされなくなります。私たちが本当に望んでいるのは、分析をデータにプッシュできるように、分析を別の方法でエンタープライズデータウェアハウス、Hadoop、ストリーム処理にプッシュすることです。ただし、データベース分析またはHadoop分析であると誰かが言ったからといって、必ずしも分析が並行して実行されるとは限りません。率直に言って、データウェアハウスアプライアンスやクラスターストリーム処理エンジンなど、Hadoopのようなこれらの新しい超並列スケーラブルテクノロジーに投資する場合、並列で実行する分析が必要です。
だから、それはチェックアウトだけです。ご存知のように、顧客、運用、リスクなどを予測するのに役立つ分析がある場合、プラットフォームで実行するだけでなく、並行して実行する必要があります。両方欲しい。それは、テクノロジーもSASなどの新しい視覚的発見ツールのようなものだからです。それは実際ここのスポンサーの1つです。
人々が望んでいることの1つは、少なくともHadoopでデータベース分析を活用することです。そして、このような大量のデータに必要なパフォーマンスを提供できるように、これらを並列に実行する必要があります。同時に、これらすべてへのアクセスを簡素化しようとしています。そのため、SQLが再び議題に戻りました。ご存知のように、SQLはそうです— Hadoop上のSQLは現在ホットです。現在、19のSQLおよびHadoopイニシアチブで追跡しています。さらに、Hadoop自体のSQLに直接アクセスして、SQLを検索インデックスに移動できるように、さまざまな方法でこのデータを取得できることがわかります。そのような方法で、その分野の一部の検索ベンダーは、HadoopへのExcelテーブルを持つ分析リレーショナルデータベースにSQLアクセスできます。
これで、データ仮想化サーバーへのSQLアクセスが可能になり、サーバー自体をHadoopのデータウェアハウスに接続できます。ライブストリーミングデータへのSQLアクセスの出現を今でも見始めています。そのため、これらすべてへのSQLアクセスは急速に増加しています。課題の一部は、SQLアクセスが市場に出回っているという理由だけです。問題は、SQLが複雑なデータを処理できるかどうかです。それは必ずしも簡単ではありません。ここには、JSONデータをネストできるという事実を含む、あらゆる種類の複雑さがあります。スキーマバリアントレコードを持つことができます。したがって、最初のレコードには1つのスキーマがあります。 2番目のレコードには異なるスキーマがあります。これらのことは、リレーショナルの世界で起こることとは大きく異なります。
そのため、分析しようとしているのはどのようなデータで、どのような分析特性であるかについて質問する必要があります。あなたがしたいのはパネルですか？機械学習ですか？グラフ分析ですか？ SQLからできますか？ご存知のとおり、これはSQLから呼び出すことができますか？これを行う同時ユーザー数は？数百人の同時ユーザーがいます。複雑なデータでも可能ですか？これらすべてが重要な質問です。それで、私はあなたが考慮すべきだと思うここでいくつかのリストを作りました。どんなファイル形式ですか？どんな種類のデータについて話しているのでしょうか？複雑なデータを取得するために、SQLからどのような分析関数を呼び出すことができますか？そして、一種の機能が並行して実行されます。つまり、これをスケーリングできるようにするには、それらを並行して実行する必要があります。また、Hadoop以外のデータを今日、Hadoopに追加することはできますか？そして、これらすべての種類のクエリワークロードで何をしますか？
そして、ご覧のとおり、SQLとHadoopのディストリビューションには多くの違いがあります。これらはすべて私が追跡しているものです。ところで、それはHadoopの純粋なSQLです。この時点では、データ仮想化は含まれていません。それで、そこにはたくさんの統合の余地があり、それは来年、18ヶ月くらいで起こると思います。しかし、それは別のことも可能にします。Hadoopの同じデータに複数のSQLエンジンを潜在的に持つことができるということです。そして、それはリレーショナルではできなかったことです。
もちろん、それはつまり、実行しているクエリワークロードの種類を知る必要があるということです。 Hadoopイニシアチブの特定のSQLでバッチで実行する必要がありますか？ Hadoopイニシアチブなどの別のSQLを介して対話型のクエリワークロードを実行して、接続先を確認する必要がありますか？理想的には、もちろん、そうすべきではありません。ご質問があるだけです。ご存知のように、オプティマイザーの中には最適な方法を見つけ出すものがあります。しかし、私の意見では、まだ完全にはありません。
しかし、それでも、前述のデータ仮想化は、複数のデータストアへのアクセスを簡素化するために非常に重要な役割を果たします。また、Hadoopで新しい洞察を作成する場合、たとえばデータを必ずしもHadoopから従来のデータウェアハウスに移動せずに、データ仮想化を介してそのデータからデータおよび従来のデータウェアハウスに参加することは確かにもっともらしいです。もちろん、それもできます。また、従来のデータウェアハウスからHadoopにデータをアーカイブすることも妥当です。私はまだそれを取得し、データウェアハウスからデータ仮想化にあるものに戻すことができます。ですから、私にとっては、この仮想化アーキテクチャはこの全体的なアーキテクチャに大きな未来をもたらし、これらすべてのデータストアへのアクセスを簡素化したと思います。
リレーショナルシステムであろうとNoSQLシステムであろうと、これらの新しい洞察を作成するとき、私たちが見つけたものの価値を最大化できるように、それらの洞察を運用に戻すことを引き続き忘れないことを忘れないでくださいそれを活用して、その環境でより効果的でタイムリーな意思決定を行い、ビジネスを最適化します。
それで、最後に、私が見ているのは、新しいデータソースが出現していることです。必要に応じて、より複雑なアーキテクチャ上に新しいプラットフォームを用意しています。そして、Hadoopは非常に重要になり、リキッドサンドボックスのデータ準備、アーカイブクエリ、データウェアハウスからのアーカイブ、データウェアハウスを超えてこれらすべてのプラットフォームのデータ管理にまで及ぶデータ管理、そしてこれらの環境でデータを分析およびアクセスし、データをより適切に取り込むためのスケーラブルなテクノロジーを使用できるようにし、プラットフォームにデータをプッシュダウンして並列化することで分析をスケーリングします。そして、願わくば、トップに登場する緊急SQLを介してすべてへのアクセスを簡素化することも願っています。それで、私たちがどこに向かっているのかを知ることができます。だから、それで、私はエリックに戻ります、今はエリックですか？
エリック：それは素晴らしい。そして、皆さん、ロビンとマイクから得たものの間では、おそらく、あなたがどこを探しても、景色全体の概観が包括的かつ簡潔であると言わざるを得ません。先に進みましょう。まず、ジョージコルジェドを待ち行列に入れます。そしてそこにあります。これをちょっと見てみましょう。さて、ジョージ、私はあなたに鍵を渡し、それを取り去ろうとしています。床はあなたのものです。
ジョージ：すばらしい！エリック、ありがとう、ロブとマイク。それは私たちが同意する素晴らしい情報とたくさんでした。ロビンの議論に戻ってください。RedPointがここにあり、SASがここにいるのは偶然ではないからです。 RedPointのおかげで、私たちは本当にガバナンスのデータ側、データの処理、分析で使用する準備に焦点を当てています。それでは、これら2つのスライドを割ってください。そして、MDMについてのRobinのポイントと、それがどれほど重要であり、HadoopがMDMとデータ品質の世界でどれほど有用であるかについて、実際に話し、取り上げます。
ロビンは、これがエンタープライズデータウェアハウスの世界とどのように関連しているかについて少し話していました。私は来ます。私は、アクセンチュアで長年を過ごしてきました。興味深いのは、会社に行って、基本的に放棄されていたデータウェアハウスをどうするかを考えなければならなかったことです。データウェアハウスチームがビジネスユーザーまたはデータの消費者に合わせてビルドを実際に調整しなかったため、多くのことが起こりました。または、非常に長い時間がかかったので、彼らがモノを構築する頃には、ビジネスの用途またはビジネスの理論的根拠が進化していました。
私が思うに、マスターデータ管理、データ品質、およびデータ準備にHadoopを使用するというアイデアは、常にアトミックデータに戻ることができるという事実にとても興奮しています。 Hadoopデータレイクまたはデータリザーバ、またはデータリポジトリ、またはハブ、または使用したいバズフォーム。しかし、常にそのアトミックデータを保持しているため、ビジネスユーザーと再調整する機会が常にあります。なぜなら、アナリストとして-私は実際に統計学者としてのキャリアを始めたので-エンタープライズデータウェアハウスはレポートを駆動するのに素晴らしいことですが、本当に予測的な分析を行いたいなら、本当に必要なのは、データウェアハウスで何らかの形で要約および集計された詳細な動作データであるためです。ですから、これは本当に重要な機能であり、Robinに反対する可能性があると思うことの1つは、個人的にデータレイクまたはデータハブにデータをできるだけ長く残すことです。データはそこにあり、きれいです。ある方向、別の方向からそれを見ることができます。他のデータとマージできます。あなたはいつもそれに戻って再構築する機会があり、それからビジネスユニットとこのユニットが持つかもしれない必要性と自分自身を再調整します。
これに関する他の興味深い点の1つは、これが非常に強力な計算プラットフォームであり、私たちがこれまで話してきた多くのワークロードであるため、すべてがHadoopに直接入ってくることです。マイクは世界のさまざまなテクノロジーについて話していましたが、このタイプのビッグデータエコシステムでは、Hadoopが本当に計算集約的な処理で大規模な処理を行うための主力製品であると思いますマスターデータとデータ品質が必要です。高価なデータベースから経済的なデータベースにデータを移動することで得られる経済性だけで、大企業での取り込みが非常に進んでいるので、そこでできるなら。
今、もちろん、いくつかの課題がありますよね？テクノロジーには課題があります。それらの多くは非常に未熟です。いくつあるかわかりませんが、マイクが言及したテクノロジーの多くは、まだゼロポイントのリリースになっていますよね？したがって、これらの技術は非常に若く、非常に未熟であり、まだコードベースです。そして、それは本当に企業にとっての課題です。そして、私たちは本当にエンタープライズレベルの問題を解決することに焦点を当てています。それで、私たちは別の方法が必要だと思います、そしてそれが私たちが提案するのは、これらの非常に初期の技術のいくつかを使用することでいくつかのものを進める別の方法です。
そして、ここで他の興味深い問題は、前述のとおり、どのタイプのHadoop環境でキャプチャしているデータがある場合、それは通常、書き込み時のスキーマではなく読み取り時のスキーマですいくつかの例外を除きます。そして、その読書、その多くは統計学者によって行われています。そのため、統計学者は、分析の目的でデータを適切に構造化できるツールを持っている必要があります。なぜなら、一日の終わりには、データを有用にするために、何らかの形で構造化して質問を表示したり、質問に答えたり、ビジネス、ある種のビジネスはビジネス価値を生み出します。
ですから、私たちがやってくるのは、非常に広範囲で成熟したEPL、ELTデータ品質マスターキー、および管理アプリケーションがあるということです。それは何年も前から市場に出回っています。そして、Robinがその円形グラフにリストしたすべての機能または多くの機能を備えています。純粋な生データをさまざまな形式やXML構造やその他でキャプチャし、すべてのクレンジングを実行する機能まで、データの完成、データの修正、データの地理空間コアビット。それは最近、モノのインターネットでますます重要になっているものです。ご存知のように、私たちが行っていることの多くやそのデータの多くに関連する地理学があります。そのため、すべての解析、トークン化、クレンジング、修正、フォーマット、構造化など、すべてがプラットフォームで実行されます。
そして、おそらく、おそらく最も重要なのは、重複排除のアイデアです。コアでは、マスターデータ管理の定義を見ると、重複排除が中核であることがわかります。さまざまなデータソースにわたってエンティティを識別し、そのエンティティのマスターレコードを作成できます。そして、そのエンティティは人かもしれません。エンティティは、たとえば飛行機の一部である可能性があります。エンティティは、ヘルスクラブのクライアントの1人に対して行ったような食品である可能性があります。彼らのためにマスターフードデータベースを作成しました。ですから、私たちが取り組んでいるエンティティが何であれ、そしてもちろん、ますます、ソーシャルハンドルやアカウントのようなもの、人に関連付けられたデバイス、車や電話、およびあなたが想像するかもしれない他のもの。
ご存知のように、あらゆる種類のセンサーをスポーツウェアに搭載しているクライアントと協力しています。したがって、データはあらゆる方向から来ています。そして、何らかの形で、それはコアエンティティの反映または表現です。そしてますます、それは人々であり、これらすべてのデータソース間の関係とそれらがそのコアエンティティにどのように関係するかを識別し、そのコアエンティティを経時的に追跡できるため、そのエンティティ間の変化を分析および理解できるようになりますそして、そのエンティティのその表現に含まれる他のすべての要素。たとえば、人々の長期的かつ長期的な分析にとって非常に重要です。そして、それは本当に大きな重要な利点の1つであり、ビッグデータが私たちにもたらすことは、人々のより良い理解であり、長期的には、どのデバイスなどで行動しているときに詐欺と人々の行動を理解することです。
それでは、ここをすばやく移動してみましょう。エリックはヤーンに言及しました。 YARN-人々はYARNについて話すので、私はほんの少しだけこれを投げます。ヤーンについてはまだ多くの無知があります。本当に多くの人はいません-YARNについてはまだ多くの誤解があります。実際、アプリケーションが正しい方法で設計されており、アプリケーションアーキテクチャに適切なレベルまたは並列化がある場合、YARNを利用してスケーリングプラットフォームとしてHadoopを使用できます。それがまさに私たちがやったことです。
YARNの定義の一部を指摘するだけです。私たちにとって、実際にYARNとは、私たち自身や他の組織がMapReduceやSpark、そしてそこにある他のすべてのツールの仲間になることを可能にしました。しかし、実際には、アプリケーションは最適化されたコードを直接YARNからHadoopに送ります。マイクが言及した非常に興味深いコメントがあります。それは、アナリティクスとアナリティクスについての質問は、クラスター内にあるというだけで、本当に並行して実行されているからですか？そこにある多くのデータ品質ツールについて同じ質問をすることができます。
ほとんどの場合、そこにある品質ツールはデータを取り出すか、コードをプッシュする必要があります。そして、多くの場合、それはあなたがしなければならない方法のために処理されるデータの単一ストリームです場合によってはデータ品質のアクティビティのレコードを比較します。事実、YARNを利用しているため、並列化を実際に活用することができました。
また、簡単に概要を説明するために、従来のデータベースや新しいデータベースなどを拡張できることの重要性について別のコメントが出されているため、クラスターの外部に実装またはインストールします。そして、バイナリをリソースマネージャーYARNに直接プッシュします。そしてそれから、YARNはクラスター内のノード全体にそれを配布します。そして、それはYARNです。YARNは、YARNがジョブを管理および実行できるようにします。つまり、データがどこにあるのかを把握し、データを処理し、データをコードに変換します。データ品質ツールを聞いて、ベストプラクティスはデータをHadoopから移動して、あなたの人生のために走らせることだと言っているとき、それはそうではないからです。データを処理したいと考えています。それがYARNが最初にすることです。データが存在するノードにバイナリを取り出します。
また、クラスタの外にいるため、従来のデータベースとリレーショナルデータベースのすべてにアクセスできるため、従来のデータベースの100％クライアントサーバーであるジョブ、100％Hadoop、またはHadoopクライアントサーバーを経由するハイブリッドジョブを持つことができます、Oracle、Teradata-必要なものはすべて同じジョブで提供されます。これは、1つの実装が世界の両側にアクセスできるためです。
そして、ツールの鋭敏さについての全体的な考えに戻ると、ここにあるように、これは単なる表現です。そして私たちがやろうとしているのは、世界を単純化することです。そして、それを実現する方法は、HDFSに非常に幅広い機能をもたらし、それを実現することです...そして、それは、すべての革新的なテクノロジーを排除しようとしているからではありません。企業は安定性を必要としているだけであり、コードベースのソリューションは好きではありません。そのため、私たちがやろうとしていることは、非常に予測可能な方法でデータを構築および処理できるようにする、使い慣れた、再現性のある一貫したアプリケーション環境を企業に提供することです。
すぐに、これはアプリケーションで得られる一種の影響です。 MapReduce対Pig対RedPointが表示されます。RedPointにはコード行はありません。 MapReduceでの6時間の開発、Pigでの3時間の開発、およびRedPointでの15分の開発。そして、そこが本当に大きな影響を与えます。処理時間も高速になりますが、人の時間、つまり生産性の時間は大幅に増加します。
最後のスライドは、この考えに戻りたいと思います。これは、データレイクまたはデータハブ、またはデータ精製所を取り込みの中心点として使用するための私たちの考え方だからです。その考えにこれ以上同意できませんでした。また、現在、世界の主要銀行の多くの最高データ責任者と議論を行っています。これが最適なアーキテクチャです。すべてのソースからのデータ取り込みにより、データレイク内でデータ品質処理とマスターデータ管理が行われ、その後、アプリケーションをサポートするため、BIをサポートするために必要なデータをプッシュします。そして、BIに分析がある場合、すぐに開始できるデータレイク内で直接実行できます。しかし、このアイデアは非常に重要です。このトポロジは、1つです。つまり、市場から多くの注目を集めています。以上です。
エリック：わかりました。ここに沿って移動しましょう。先に進み、キースに引き渡します。そして、キース、あなたはここで家を揺するために約10、12分を得ました。私たちはこれらのショーで少し長い時間をかけました。そして、私たちはこれのために70分を宣伝しました。だから、先に進んでそのスライドのどこかをクリックし、下矢印を使ってそれを取り去ってください。
キース：もちろん。エリック、問題ない。それは有り難いです。 SASについていくつか説明してから、SASがビッグデータの世界と交差するテクノロジーアーキテクチャについて説明します。これらすべてについて説明することがたくさんあります。 SASが分析、データ管理、およびビジネスインテリジェンステクノロジーをこのビッグデータの世界に導入した場所を簡単に理解するだけで、10分という非常に詳細な時間を費やすことができます。
まず、SASについて少しだけ説明します。この組織に慣れていない場合は、過去38年間、ビッグデータだけでなく小さなデータと豊富なデータを使用して高度な分析、ビジネスインテリジェンス、データ管理を行ってきました。私たちは、世界中に約75,000のサイトを持つ巨大な既存の顧客基盤を持ち、世界のトップ組織のいくつかと協力しています。私たちは約13,000人の従業員と30億ドルの収益を持つ民間組織です。そして本当に重要なことは、重要な部分は、私たちの研究開発組織にかなりの量の収益を再投資してきた長い歴史があるということです。今日見に行きます。
だから、私はこれらの本当に怖いアーキテクチャ図に飛び込みます。スライドで左から右に作業します。そのため、このプラットフォーム内で見慣れたものがあります。左側では、これらのビッグデータプラットフォームへの取り込みについて話しているすべてのデータソース。そして、あなたはこのビッグデータプラットフォームを手に入れました。
最終的に、今日提供する例は、これらのビッグデータプラットフォームと交差するすべてのテクノロジーに関するものであるため、Hadoopという言葉を先頭に置いただけではありません。 Hadoopはたまたま、最も堅牢な展開オプションを備えたものの1つですが、Teradataなどの他のエンタープライズデータウェアハウスパートナーとしばらくの間、これらの技術をかなり頻繁に開発し、開発してきました。 Oracle、Pivotalなど。したがって、どのプラットフォームですべての異なるテクノロジーがサポートされているかについて詳しく説明することはできませんが、今日説明するものはほとんどすべてHadoopであり、それらの大部分は他のテクノロジーパートナーと交差していることを安心してください我々は持っています。そのため、そこにそのプラットフォームがあります。
次の右側には、SAS LASR Analytic Serverがあります。今、それは本質的に、メモリ分析アプリケーションサーバーの大規模並列です。インメモリデータベースではないことは明らかです。本当に最初から設計されています。クエリエンジンではありませんが、分析リクエストを大規模に並行して処理するように設計されています。それが、右側にあるサービスキーアプリケーションです。
人々がこれらの物をどのように展開するかについて、もう少し詳しく説明します。しかし、本質的に、最初のアプリケーションは、SASの高性能分析です。私は、Enterprise MinerやSASなどの既存のテクノロジーとプラットフォームを多く使用しています。これらのツールに組み込まれているアルゴリズムの一部でマルチスレッドを実行するだけではありません年だけでなく、それらを大規模に並列します。そのため、ビッグデータプラットフォームからLASR Analytic Serverのメモリスペースにデータを移動し、分析アルゴリズムを実行できるようにします。多くの新しい機械学習、ニューラルネット、ランダムフォレスト回帰、これらの種類の物事-再び、メモリに座っているデータ。そのため、それらのプラットフォームにファイルされる特定のMapReduceパラダイムボトルネックを取り除くことは、分析作業を行う方法ではありません。そのため、データを一度メモリスペースに格納し、それを繰り返し処理できるようにしたいことがあります。そのため、それが高性能のAnalytic LASR Serverを使用するというコンセプトです。
また、その下にある他のアプリケーションである視覚分析により、そのデータをメモリに保持し、同じデータでより多くの人口に対応することができます。そのため、人々がビッグデータの調査を行えるようにします。そのため、モデル開発作業を行う前に、データを調査し、理解し、相関を実行し、予測ツリーや予測ツリーのトレンド分析（これらの種類）を行いますが、メモリに保存されているデータに対して非常に視覚的でインタラクティブな方法でプラットフォーム。また、プラットフォームにアクセスして、標準的な種類の記録を行うことができる非常に幅広いユーザー層を持つ限り、BIコミュニティにサービスを提供します。
次のステップでは、サービスを開始します。そして、統計学者と分析担当者が、視覚分析から削除されたデータをメモリに保存し、視覚統計アプリケーションへの探索を行うことで、そのようなアドホックモデリングを行えるようにします。これは、繰り返し処理を行うために使用されるバッチで統計を実行せず、モデルを実行し、結果を確認するための機会です。そのため、モデルを実行でき、結果を確認できます。これは、インタラクティブな統計モデリングに視覚的にドラッグアンドドロップすることです。そのため、これは私たちの統計学者とデータサイエンティストにサービスを提供し、初期の探索的視覚統計作業の多くを行います。
そして、私たちはコーダーを忘れていません-本当にやりたい人、反対のインターフェイスの層を剥がすことができる人は、アプリケーションを書き、SASで独自のコードベースを書くことです。これが、Hadoopのメモリ内統計です。そしてそれが、基本的に、Analytic LASRサーバーと対話してコマンドを直接発行し、リクエストに基づいてそれらのアプリケーションをカスタマイズできるようにするコードレイヤーです。それが分析の一部です。
これらがどのように設定されるのか…おっと、ごめんなさい。いくよ
ですから、これを行うには本当にいくつかの方法があります。 1つは、ビッグデータで（この場合はHadoopで）行うことです。そして、そこに、SAS LASR Analytic Serverがハードコア分析用に最適化された別のマシンのクラスターで実行されています。これは適切に配置され、ビッグデータプラットフォームに近いため、ビッグデータプラットフォームとは別にスケーリングできます。ですから、私が吸血鬼のソフトウェアのように特徴づけているようなものを、Hadoopクラスターの各ノードで食い尽くしたくないときに、これを行う人がいます。また、メモリを大量に使用する分析に適したビッグデータプラットフォームを必ずしも拡張する必要はありません。したがって、Hadoopクラスターのノードは120個ですが、そのような作業を行うように設計された分析サーバーのノードが16個ある場合があります。
ビッグデータプラットフォームからの並列性を維持して、データをメモリにプルすることは引き続き許可されています。したがって、実際にはSASをHadoopプラットフォームで使用しています。別の予約モデルでは、そのコモディティプラットフォームも使用してプッシュすることができます。つまり、Hadoopプラットフォーム上で基本的にAnalytic LASR Serverを実行します。だから、私たちがいるのは...ビッグデータプラットフォーム内で操作しているということです。これは、他のアプライアンスベンダーの一部でもあります。そのため、基本的にその商品プラットフォームを使用してその作業を行うことができました。
頻繁に使用されるのは、単一のサービスまたは単一の種類の分析実行である高性能分析、より多くの種類のバッチ指向であるということです。Hadoopでメモリスペースを必ずしも消費する必要はありません。プラットフォーム。この種の展開モデルには非常に柔軟性があり、YARNと協力してこれらの多くのケースで間違いなく優れたクラスターを再生できるようにしています。
さて、これが分析の世界です。分析アプリケーションで明確にするだけです。しかし、SASは最初からデータ管理プラットフォームでもあると述べました。また、必要に応じて、そのプラットフォームにロジックをプッシュするのに適切なものがあります。したがって、それを行うにはいくつかの方法があります。 1つはデータ統合の世界です。データのデータ変換作業を行うことは、以前に聞いたようにデータを撤回する意味がなく、大きなデータ品質ルーチンを実行することです。データ品質ルーチンのようなものをそのプラットフォームに確実に押し下げたいと考えています。そして、モデルのスコアリングなど。それで、モデルを開発しました。 MapReduceでそのことを書き直したり、ネイティブデータベースプラットフォームにその作業をやり直したりするのが難しくて時間がかかりたくありません。
たとえば、Hadoopのスコアアクセラレータを見ると、基本的にモデルを取得し、SAS数学ロジックをそのHadoopプラットフォームにプッシュダウンし、そのビッグデータプラットフォーム内の並列処理を使用してそこで実行できます。次に、Hadoopを含むさまざまなプラットフォーム用のコードアクセラレータを使用します。これにより、プラットフォーム内で基本的にSASデータステップコードを超並列的に実行できます。そのため、プラットフォームでデータ変換のような作業を行います。そして、SASデータ品質アクセラレーターにより、性別のマッチング、標準化のマッチコードなど、今日聞いたことのあるさまざまなデータ品質のすべてを行うことができる品質知識ベースをそこに置くことができます。
最後に、データローダーがあります。私たちは、ビジネスユーザーがコードを記述する必要がなく、これらのビッグデータプラットフォームでデータ変換が機能する必要があることを知っています。データローダーは、WYSIWYGの優れたGUIであり、他のテクノロジーをまとめてまとめることができます。たとえば、Hiveクエリを実行したり、データ品質ルーチンを実行したりする場合のウォークスルーウィザードのようなもので、その場合はコードを記述する必要がありません。
最後に言及するのは、この前の部分です。前にも言ったように、私たちは世界に巨大なSASの足跡を残しています。そして、これは、このスペースに存在するすべてのプラットフォームをすぐに実行できるとは限りません。そのため、Teradataからデータを取得してHadoopに戻す、またはその逆など、ビッグデータプラットフォームにデータを保存する必要がある既存のユーザーが確実に存在します。モデルの実行SASサーバーでの実行方法は既に知っていますが、現在Hadoopプラットフォームに配置されているデータを取得する必要があります。そのため、「from」と呼ばれる他の小さなアイコンがあり、SASアクセスエンジンを使用して接続できます。アクセスエンジンは、Hadoop、PolaのCloudera、Teradata、Greenplumに接続します。これにより、既存の成熟したSASプラットフォームを使用して、これらのプラットフォームからデータを取得し、必要な作業を行い、結果をこれらの領域に戻すことができます。
最後に言及することは、これらのテクノロジーはすべて、同じ標準の共通メタデータによって管理されているということです。そのため、変換作業、データ品質ルールの実行、それをメモリに移動して分析、スコアリングでのモデル開発を行えるようにすることについて説明します。分析ライフスタイル全体があり、ライフサイクルは共通のメタデータ、ガバナンス、セキュリティ、今日説明したすべてのことによって管理されています。
要約すると、そこには3つの大きなものがあります。 1つは、データプラットフォームを他のデータソースと同様に扱い、適切で便利なときにデータプラットフォームから引き出してプッシュできることです。これらのビッグデータプラットフォームを使用して、専用の高度な分析インメモリプラットフォームにデータを一覧表示できます。つまり、これがLASRサーバーです。
そして最後に、これらのビッグデータプラットフォームで直接作業し、データを移動させずに分散処理機能を活用できます。
エリック：まあ、それは素晴らしいことです、皆さん。ええ、これは素晴らしいです！それでは、いくつかの質問に飛び込みましょう。通常、これらのイベントには約70分または少し長くかかります。ですから、私たちにはまだ素晴らしい観客が座っていると思います。ジョージ、最初の質問を投げかけます。バイナリサウンドをHadoopにプッシュすることについて話す場合、計算ワークフローを本当に最適化したように思えます。そして、これらの種類のリアルタイムデータガバナンス、データ品質スタイルの成果を実現するための鍵は、それがあなたが得たい価値だからです。 MDMの旧世界に戻りたくない場合は、非常に面倒で時間がかかり、ほとんどの場合機能しない、特定の方法で人々に行動を強いる必要があります。それで、あなたがやったことは、あなたがあったもののサイクルを凝縮したということです。それを数日、数週間、時には数か月から数秒にまで減らしましょう。それは何が起こっているのですか？
ジョージ：まさにそのとおりです。クラスターから得られるスケールとパフォーマンスは、ベンチマークに関して非常に驚異的です。しかし、桁違いに、10億件、12億件のレコードを実行し、完全なアドレス標準化を行う場合（ミッドレンジHPマシンと言います）、8つのプロセッサマシンが必要です。 、コアあたり2ギガバイトのRAM、実行するには20時間かかります。 12ノードのクラスターで、約8分でこれを実行できます。そのため、現在実行できる処理の規模は劇的に異なるため、すべてのデータを自由に使用できるという考えとうまく調和しています。したがって、処理を行うことはそれほど危険ではありません。間違えた場合は、やり直すことができます。時間がありますよねMDMソリューションを運用しようとしていた人々にとって、この種のリスクは本当にビジネス上の問題になりました。オフショアに30人の従業員がデータガバナンスなどを行う必要があります。そのため、あなたはまだその一部を持っている必要がありますが、現在それを処理できる速度とスケールは、本当にあなたにより多くの呼吸の部屋を与えます。
エリック：ええ、それは本当に良い点です。私はそのコメントが大好きです。そのため、もう一度やり直す時間があります。素晴らしいです
ジョージ：ええ。
エリック：ダイナミクスを変えますよね？それはあなたがしようとしていることについてのあなたの考え方を変えます。私は、18年前に特殊効果を行う業界でこのことを思い出しました。なぜなら、私はそのスペースにクライアントがいたからです。そして、ボタンを押してレンダリングし、家に帰ります。そして、土曜日の午後に戻って、どうなっていたかを確認します。しかし、それを間違えた場合、それは非常に、非常に、非常に苦痛でした。そして今、それはほとんどない-それはあなたがより多くのものを試す機会を持っているので、それほど苦痛であることに近くありません。私は言わなければならない、それは本当に、本当に良い点だと思う。
ジョージ：そのとおりです。ええ、あなたは余分な足を吹きます。昔は仕事の途中で、失敗し、SOSが吹き飛ばされました。それでおしまい。
エリック：そう。そして、あなたは大きな問題に直面しています、ええ。そのとおり。
ジョージ：そうです。そのとおり。
エリック：キース、お前に投げ捨てさせてくれ。あなたのCILであるキース・コリンズとインタビューをしたことを覚えています。2011年に戻ったと思います。そして彼は、SASから派生した分析を運用システムに組み込むために顧客と協力することに関して、SASが特に取っている方向について多くのことを話しました。そしてもちろん、私たちはマイク・ファーガソンが思い出すことの重要性について話しているのを聞いた。ここでの全体的な考えは、このようなものを自分の業務に結び付けたいということです。企業から切り離された分析を真空で行いたくない。それは何の価値もありません。
運用に直接影響を与え、最適化できる分析が必要な場合。振り返ってみると、言わなければならないのですが、当時は良いアイデアだと思いましたが、それは振り返ってみると、本当に、本当にスマートなアイデアのようです。そして、それはあなたたちが持っている本当の利点だと思います。そしてもちろん、この偉大な遺産、この巨大なインストールベース、そしてこれらの分析を運用システムに組み込むことに注力しているという事実、つまり今は、そして確かに、ある程度の作業が必要になることを意味します。かなり一生懸命取り組んでいます。しかし、今では、これらすべての新しい技術革新を活用することができ、顧客と一緒にそれらすべてを運用できるという点で本当にあります。それは公正な評価ですか？
キース：ええ、絶対です。コンセプトは、意思決定のデザインや意思決定科学のアイデアを得るということです。これは、ある程度、科学的なものです。プロセスのエンジニアリングを実際に行うことができない限り...車の開発を考えているなら、この美しい車を作るデザイナーがいますが、エンジニアがその計画を実行して実際の実行可能な製品を作るまではそうではありません実際に物事を配置することができ、それは基本的にSASが行ったことです。意思決定-意思決定設計プロセスと意思決定エンジニアリングプロセスを統合しているので、アクセラレータ、特にスコアリングアクセラレータについて説明するときは、開発したモデルを使用してそれをプッシュすることができます。モデル開発、モデル展開のためのダウンタイムなしで、Teradataに、またはOracleまたはHadoopにプッシュします。モデルは時間とともに劣化するため、これらのモデルの精度は重要です。そのため、それを取得して本番環境に投入するのに時間がかかるほど、モデルの精度が低下します。
そして、もう1つは、そのプロセスを長期にわたって監視および管理できるようにすることです。モデルが古くて不正確になった場合、モデルを非推奨にします。あなたはそれを見て、時間の経過とともにそれらの精度をチェックし、それらを再構築したいのです。そのため、その上にあるモデル管理ツールもあり、モデル化されたプロセスに関するメタデータを実際に追跡します。そして、人々は、そのような概念はモデルファクトリー、またはあなたがそれを呼び出したいもののようなものであるということを知っています。重要なのは、メタデータと管理を導入することです。そこで私たちがヒットする3つの大きなことは、人々がお金を稼ぎ、お金を節約し、刑務所に入れないようにすることです。
エリック：最後のものもかなり大きいです。私はそれをすべて避けたいと思っています。それでは、…最後に1つ質問します。多分、あなたはそれぞれこの点で両方の種類のジャンプをすることができます。私たちの世界の不均一性は増加するだけだと思われます。ハイブリッドクラウド環境で何らかの結晶化が確実に見られると思います。しかし、それでも、多くの主要なプレーヤーがくっついているのを見るでしょう。 IBMはどこにも行きません。 Oracleはどこにも行きません。 SAPはどこにも行きません。そして、このゲームに関与している他の多くのベンダーがあります。
また、運用面では、文字通り何千ものさまざまな種類のアプリケーションがあります。そして、私は聞いた-あなたのほとんどはこれについて話していますが、私はあなたの両方が私が言ってきたことに同意すると思います。この傾向は、分析エンジンの単なる計算能力、アーキテクチャの観点から見てきました。企業はここ数年、他のエンジンを活用して、ある種のオーケストレーションポイントにサービスを提供することについて話してきました。そして、ジョージ、私はあなたにそれを最初に投げるでしょう。私にはそれは変わらないように思えます。このような異機種混在環境を実現する予定です。つまり、リアルタイムCRMやデータ品質、データガバナンスなどがあります。ベンダーとして、これらすべてのさまざまなツールとのインターフェースが必要になります。そして、それは顧客が望んでいることです。彼らは、これらのツールで大丈夫なものを望んでいませんし、これらのツールではそれほど大丈夫ではありません。彼らはスイスのMDMとCRMを望んでいますよね？
ジョージ：そうです。そして、私たちは非常にそれを受け入れてきたので、興味深いです。その一部は、私たちがその空間で持っていた歴史です。そして、明らかに、私たちはすでに他のすべてのデータベース、Teradata、および世界の各部分に取り組んでいました。そして、実装プロセスで、具体的には私たちが行った方法で、そうすることで、これらのさまざまなデータベースのすべてにまたがります。私がおもしろいと思うことの1つは、すべてのリレーショナルデータベースを削除しようとするクライアントがいるということです。そしてそれは興味深いです。いいですか、それでいいです。それは面白いです。しかし、大規模な企業規模で実際に起こっているとは思えません。長い間起きていませんだから、私はハイブリッドが長い間ここにあり、キャンペーン管理プラットフォームにメッセージングプラットフォームがあるアプリケーションの反対側にいると思います。実際に特別に設計しました。これで、ハイブリッドデータ環境に接続し、Hadoopを照会したり、任意のデータベース、任意の分析データベースを照会したりできるバージョンをリリースしました。ですから、それは単なる未来の波だと思います。そして、これで仮想化が確かに大きな役割を果たすことに同意しますが、私たちはただです-私たちはすべてのアプリケーションのデータにすぐに出かけます。
エリック：わかりました。そして、キース、私はあなたにそれを投げます。足を踏み入れることで私たちが直面している異質な世界についてどう思いますか？
キース：ええ、本当に魅力的です。私たちがもっと見つけているのは、物事のデータ管理の側面だけでなく、現時点で本当に魅力的なのは、分析ベースのオープンソースの性質です。そのため、Sparkのような組織やSparkのような技術が登場し、PythonやRなどのオープンソース技術を使用している人々がいます。ある程度の対立や脅威として解釈できると思います。しかし、現実には、これらすべてのオープンソーステクノロジーには本当に素晴らしい賛辞があります。つまり、私たちは、神のためにオープンソースプラットフォーム上で活動しています。
しかし、たとえば、RモデルをSASパラダイムに統合できるようにすると、両方の長所を活用できますよね？同様に、学界での実験的なことやモデル開発作業のいくつかは、モデル開発プロセスにおいて非常に有用であることがわかっています。しかし、それをプロダクションクラスのツールと組み合わせることができれば、多くのクレンジングと品質を実行し、モデルに渡されるデータがチェックされていることを確認し、失敗しないように適切に準備されています実行中。そして、チャンピオンチャレンジャーモデルのようなことをオープンソースモデルで行うことができます。これらは、私たちが実現しようとしているものであり、これらすべてのテクノロジーのこの非常に異質なエコシステムの一部です。ええ、それだけではありません。私たちにとっては、それらのテクノロジーを採用し、賛辞を探すことです。
エリック：まあ、これは素晴らしいものです。ここで少し長くなりましたが、できるだけ多くの質問に答えたいと思います。本日のプレゼンターにQ＆Aファイルを転送します。したがって、あなたが尋ねた質問のいずれかが回答されなかった場合、回答が得られるようにします。皆さん、これで2014年の終わりです。明日と来週、DM Radioで本当にあなたの皆さん、そしてそれはすべて完了し、休日の休暇です。
これらすべてのすばらしいWebキャストをご覧いただき、時間と注意をありがとうございました。 2015年に向けて素晴らしい年を迎えました。そして、皆さん、すぐにお話しします。再度、感謝します。気をつけますバイバイ。