ビッグデータに関する神話と伝説



パイロットタスク用のクラスターの1つ(データノード:18サーバー/ 2 CPU、12コア、64GB RAM /、12ディスク、3 TB、SATA-HP DL380g)



-ビッグデータ全般とは何ですか?

誰もがこれが膨大な量のデータを処理していることを知っています。 しかし、たとえば、20ギガバイトまたは4ペタバイトのOracleデータベースで作業することは、まだビッグデータではなく、単なる高負荷データベースです。



-それでは、ビッグデータと「通常の」高負荷システムの主な違いは何ですか?

柔軟なクエリを構築する機能。 リレーショナルデータベースは、そのアーキテクチャにより、同じストリームを流れる短い高速クエリ向けに設計されています。 突然そのようなクエリを超えて新しい複雑なクエリを作成することにした場合、ベースを書き直す必要があります。そうしないと、負荷がかかって死んでしまいます。



-この新しいロードはどこから来たのですか?

アーキテクチャをもう少し詳しく見てみると、従来のデータベースは情報を非常に分散して保存していることがわかります。 たとえば、サブスクライバー番号は1つのテーブルの1つのサーバーにあり、彼の残高は別のテーブルにあることができます。 パフォーマンスには、最大のデータ分割が必要です。 複雑な結合を開始するとすぐに、パフォーマンスが急激に低下します。



-そのようなタスクの例はありますか?

次に例を示します。人々がブリックダイヤラーを備えた最新のスマートフォンに切り替えると、私たちにとって興味深いものになりました。 かなり明確なしきい値があることが判明しました。たとえば、モスクワの居住者にとって、2007年の古い電話と多数のサービスの使用と高いトラフィック消費の組み合わせは、スマートフォンへの切り替えを望むことを意味する場合があります。 したがって、そのような境界を見て、どのモデルに切り替えるかを検討しました。 そして私たちはさらに進んだ-私たちは今日そのような電話を購入する準備ができている人を見つけることにしました。 そして、技術的な質問です。 モスクワには約250の営業所があります。 データに従って、1週間以内にスマートフォンに切り替えることにした人のグループを選び出します。 そのうちの1人がサロンに50メートル近づくと監視します。 そして、このサロンにスマートフォンがあり、デモンストレーションの準備ができているかどうかを「見るのをやめて」というメッセージをSMSに送信します。 このようなタスクは、従来のシステムを単純に爆発させます。



「そして、これはどのように解決されますか?」

別のデータベースアーキテクチャが必要です。 柔軟なクエリが必要な場合、データを保存する最も簡単な方法は構造化されていません。新しいクエリごとに、新しい最適な構造を別々に構築する必要があるためです。 従来のデータベースは、限られたコンピューティングリソース内でパフォーマンスを最大化することを目的としています。



-では、それらをスケーリングしましょう-問題は解決しますか?

一般に、スケーリングすることが多くある場合、はい、これは出口です。 同意します。データベース構造全体を書き換えるよりも、いくつかのサーバーまたはストレージシステムを購入する方が簡単です。 ただし、大きなデータの場合、これはそれほど単純ではありません。 リレーショナルデータベースは、通常、単一のストレージシステムのボトルネックにまで拡張することは非常に困難です。 スケーリングには水平方向のしきい値があります。その後、非常に複雑なハードウェアシステムを導入するよりも、新しい構造を記述する方が簡単になります。



-それで、結果は何ですか?

その結果、簡単に分析できる生データの特定のセットがあります。 Javaコードで実行されているロボットが実行されます。 鉄には特定のハードウェア要件がないため、これらは完全に並行しています。 コンピューティングパワーを追加する必要がある場合は、仮想環境にもう少しリソースを提供するか、提供します。 戦闘リレーショナルデータベースでは、これは当てはまりません。



「しかし、それはとてつもなく遅いですよね?」

常にではありません。 比較することが理にかなっている状況は2つあります。

  1. 結合が少ない短いクエリ。 ここで、データベースアーキテクチャは時間の増加をもたらすことがよくありますが、選択したアーキテクチャに最適ではないクエリの負荷が急激に増加するため、代償を払います。
  2. 単一タイプの複雑なクエリ。 ビッグデータ用のJavaロボットを4時間作成して5分間の応答を待つよりも、リレーショナルデータベースのクエリを10分でコンパイルしてソリューションを2時間待つ方が簡単な場合があります。 タスクに依存します。


そのため、原則として、ビッグデータは非常に頻繁に繰り返されることのないタスクに使用されます。 ビッグデータタスクの1つを永続的にすることを突然決定し、リレーショナルデータベースで解決できる場合、アーキテクチャを固定した通常のデータベースに「ハードコード」するだけです。



-ビッグデータを使用する有名な例は何ですか?

遅かれ早かれ、ビッグデータを扱うほとんどすべての人が、ほぼ同様のアプローチを採用します。高速クエリ用の有能なアーキテクチャを備えた構造化され、壊れたデータベース、複雑な1回限りの非構造化生データです。 Habréには、アーキテクチャに対するTwitterのアプローチに関する言及がありました。そこでは、同様のものが使用されています。



-では、会議の全員がビッグデータについて話すのはなぜですか?

トレンドが流行しているため、ジャーナリストという言葉は大好きです。 5万件のオンラインストアのレコードを処理してビッグデータと呼んだとしても、プレスリリースを書くのに十分な哀れみになります。



-ビッグデータの目標の1つは、長いプロジェクトサイクルから逃れることです。

はい、そして松葉杖の塊から従来のデータベースまで。 Javaの方法論は古くから知られていますが、分析では比較的最近使用されています。 従来の方法でいくつかの分析問題を解決する場合、何が間違っているのかを事前に言うことはできません。 リレーショナルデータベースを使用して発生した不快な状況を分析するには、数か月かかる場合があります。 ビッグデータのアプローチは完全に異なります。データはリアルタイムで収集され、処理されずに保存され、その後処理され、絶えず変化する可能性がある現在のタスクに基づいて必要に応じて処理されるためです。



-すでに解決された問題の例がありますが、どこで見られましたか?

はい ヨーロッパのパートナーは、LTEのカバレッジエリアでデバイスを監視していましたが、実際にはLTEが接続されていませんでした。 たとえば、古いSIMを搭載したiPhoneの所有者、LTEなどがあることを知らずに中国の携帯電話の所有者。 このプログラムはパートナーに6か月かかりました。 私たちと一緒に、このプロジェクトは3週間でプラットフォームのパイロットの一部として実装されました。 私たちの実装では、この機能を使用していないLTE対応デバイスを持っている多くの人々を見つけることができました。 または、別の例を示します。 VimpelComには、加入者が使用するデバイスを分析するユニットがあります。 これは、サービス配信を最適化するために行われます。 たとえば、1つのモデルのデバイスの数が500を超えると、そのようなデバイスのサポートを開始します。特に、可能な顧客の質問に答えられるように、メーカーに情報を要求します。 ツールキットを使用すると、ネットワーク内のデバイスの使用に関するこのような1回限りのレポートをすばやく作成できます。



-プラットフォームの構造は何ですか?

  1. データソース。 データが必要かどうかを考えることなく、すべてのデータを1か所に集めます。生の配列を収集するだけです。 たとえば、これらはイベント(通話、休憩など)、位置情報、CRMデータ、請求データ、アカウント補充データなどです。
  2. アイデアの工場があります-これらは、開発者とコンピューティングパワーに時間を割くと実現できる商業的なアイデアです。
  3. パイロットプロジェクトのゾーンがあります-これらは、サブスクライバーの小さなサンプルに実装されるデモバージョンです。 そして生産性があります(それについては以下)。
  4. プラットフォーム。 VimpelComは、すでにかなりの数のいわゆる「ノード」を、ほぼリアルタイムでデータを収集および分析するマシンであるビッグデータを操作するシステムに統合しています。 このネットワークを構築していきます。 たとえば、Verizonには同様のシステムに関与する約500のノードが既にあります。 当社のプラットフォームは、パイロット用のクラスター(サンドボックス)と製品用のクラスターに分かれています。 基本的に、それらは力とサポートを除いてほとんど違いはありません。 製品クラスターはより強力であり、実験の場所ではなく、集中力とデータ処理の「工場」です。 そして、サンドボックスでは、新しいアイデアが練り上げられており、すべてのデータソースがそれに接続され、製品のクラスターにも接続されています。




-そのような計画の予後のタスクの例はありますか?

はい、人がいつ他の国に旅行するかを知りたいです。 たとえば、「カザカスタンへようこそ」とその場で彼に知らせるのではなく、旅行の開始前であっても、関税オプションを提供し、その場で価格について知らせてください。 プロジェクトの1つは、空港での顧客の流れの分析です。 帰国者(簡単)、空港職員とタクシー運転手(以前の訪問による)を遮断し、1、2時間で飛行機に乗る人を選択する必要があります。 そのため、飛行機を待っている間に-オファーのあるSMSを受け取ります:特定の地域または国(端末がこの方向でのみ機能する場合)の場合、一般的な(情報を表示する場所と方法)、場合によっては。



-ビーラインで誰がこれをしますか?

だから私はこれと同僚のヴィクトル・ブルガコフをやっている。 オランダでテレコムを始めました。そこでは、リアルタイム請求とMNPのアーキテクトでした。 その後、HP KPNは、アディダスのビジネスインテリジェンスとデータマイニングの実装を担当しました。現在はビーラインです。 そしてビクターはInkombankでERPと共に働いていました。 その後、1999年以来、私たちはビジネス分析に取り組んでおり(実際、私はすべてを最初からやりました)、今ではビッグデータがそれに近づいています。



低レベルでデータを処理する方法について学習したり、ハードウェアについて聞きたいと思うかもしれません。 トピックが興味深い場合-書いてください。



All Articles