本「クラウドでのBigDataの使用。 Microsoft Azureのサンプルを使用したデータの処理と保存»

クラウドでのビッグデータ処理の実生活の秘密が実際の例で調べられる最初のロシア語の本がここにあります。



焦点は、Microsoft AzureおよびAWSソリューションにあります。 クラウドストレージ、クラウドデータ分析ツールを使用して、クラウドで処理するために準備されたデータを取得する作業のすべての段階が考慮されます。 SAASサービスには特に注意が払われており、専用サーバーまたは仮想マシンに展開されたソリューションと比較したクラウドテクノロジーの利点が実証されています。



この本は幅広い読者向けに設計されており、Azure、Docker、その他の不可欠なテクノロジーの開発のための優れたリソースとして役立ちます。



「ストリーミングデータの直接ダウンロード」の一節をお読みください。

10.1。 一般的なアーキテクチャ

前の章では、多くのクライアントアプリケーションが大量のメッセージを送信しなければならない状況を検討しました。これらのメッセージは、動的に処理され、リポジトリに置かれ、再び処理される必要があります。 同時に、クライアントコードを変更することなく、データ処理とストレージフローのロジックを変更できる必要があります。 そして最後に、セキュリティ上の理由から、クライアントは1つのことだけを行う権利を持っている必要があります-メッセージを送信または受信しますが、決してデータを読み取ったり、データベースを削除したりすることはありません。



このようなタスクは、インターネット接続を介して接続されたIoTデバイスで動作するシステムや、オンラインログ分析システムで非常に一般的です。 専用サービスの上記の要件に加えて、「モノのインターネット」の詳細に関連し、信頼性の高いメッセージ処理を確保するために、さらに2つの要件があります。 まず、クライアントとサービスレシーバー間の相互作用のプロトコルは、限られたコンピューティング機能と非常に限られたメモリ（たとえば、Arduino、Intel Edison、STM32 Discovery、およびその他の「不適切な」プラットフォームなどのデバイスに実装できるように、非常にシンプルでなければなりませんRaspberryPiの前のように）。 次の要件は、処理サービスの障害の可能性に関係なく、信頼できるメッセージ配信です。 これは、高い信頼性の要件よりも強い要件です。 実際、システム全体の全体的な信頼性を確保するには、そのすべてのコンポーネントの信頼性が十分に高く、新しいコンポーネントを追加しても障害の数が目立って増加しないことが必要です。 クラウドインフラストラクチャの障害に加えて、ユーザーが作成したサービスでエラーが発生する場合があります。 その場合でも、ユーザーサービスが復元されたらすぐにメッセージを処理する必要があります。 このため、メッセージフロー受信サービスは、メッセージが処理されるか、その有効期限が切れるまでメッセージを確実に保存する必要があります（これは、継続的なメッセージフロー中のメモリオーバーフローを防ぐために必要です）。 これらのプロパティを持つサービスは、イベントハブと呼ばれます。 IoTデバイスには、モノのインターネットデバイスと組み合わせて使用​​するのに非常に重要な他のプロパティが多数ある特殊なハブ（IoT Hub）があります（たとえば、1ポイントからの双方向通信、組み込みのメッセージルーティング、デバイスの「デジタル対応物」、その他）。 ただし、これらのサービスは依然として専門的であり、詳細に検討することはありません。



メッセージ集中の概念に移る前に、その根底にある考えに戻りましょう。



メッセージソース（たとえば、クライアントからの要求）とそれらを処理するサービスがあるとします。 単一の要求の処理には時間がかかり、計算リソース（CPU、メモリ、IOPS）が必要です。 さらに、1つの要求の処理中、残りの要求は処理できません。 サービスが無料のときにクライアントアプリケーションがフリーズするのを防ぐには、キュー内で処理を待機している間にメッセージを格納する追加のサービスを使用して、クライアントアプリケーションを分離する必要があります。 この分離は、システムの全体的な信頼性を高めるためにも必要です。 実際、クライアントはシステムにメッセージを送信しますが、処理サービスは「落ちる」可能性がありますが、メッセージは失われてはならず、処理サービスより信頼性の高いサービスに保存する必要があります。 このようなサービスの最も単純なバージョンはキューと呼ばれます（図10.1）。









キューサービスは次のように機能します。クライアントはキューのURLを認識し、アクセスキーを持っています。 キューのSDKまたはAPIを使用して、クライアントはJSON、XML、またはバイナリ形式のペイロードを持つメッセージのタイムスタンプ、識別子、および本文を含むメッセージをキューに入れます。



サービスのプログラムコードには、キューを「リッスン」するサイクルが含まれており、各ステップで次のメッセージを取得します。キューにメッセージがある場合は、抽出されて処理されます。 サービスがメッセージを正常に処理すると、キューから削除されます。 処理中にエラーが発生した場合、エラーは削除されず、修正されたコードでサービスの新しいバージョンが起動されたときに再度処理できます。 キューは、1つのクライアント（または同様のクライアントのグループ）と1つの処理サービス（後者はサーバークラスターまたはサーバーファームに配置できます）を同期するように設計されています。 クラウドキューサービスには、Azure Storage Queue、Azure Service Bus Queue、AWS SQSが含まれます。 仮想マシンでホストされるサービスには、RabbitMQ、ZeroMQ、MSMQ、IBM MQなどが含まれます。



異なるキューサービスは、異なるタイプのメッセージ配信を保証します。

• 少なくとも1回のメッセージ配信
• 厳密に1回限りの配信。
• 順序を維持したメッセージの配信。
• 順序を維持せずにメッセージを配信します。

キューは、1つのソースから1つの処理サービスへのメッセージの信頼できる配信、つまり1対1の対話を保証します。 しかし、複数のサービスにメッセージ配信を提供する必要がある場合はどうでしょうか？ この場合、「トピック」（トピック）（図10.2）と呼ばれるサービスを使用する必要があります。









このアーキテクチャの重要な要素は「サブスクリプション」です。 これは、セクションに登録されているパスです。 メッセージは、クライアントによってトピックで公開され、サブスクリプションの1つに転送されます。そこから、サービスの1つによって抽出され、処理されます。 トピックは、1対多のカスタマーサービスインタラクションアーキテクチャを提供します。 このようなサービスの例には、Azure Service BusトピックおよびAWS SNSが含まれます。



ここで、さまざまなサービスに多くのメッセージを送信する必要のある異種クライアントが多数存在すると仮定します。つまり、多対多の対話システムを構築する必要があります。 もちろん、このようなアーキテクチャは複数のセクションを使用して構築できますが、そのような構築はスケーラブルではなく、管理と監視に手間がかかります。 ただし、個別のサービス-メッセージコンセントレーターがあります（図10.3）。









ハブは多くの顧客からメッセージを受け取ります。 すべてのクライアントは、1つの共通サービスエンドポイントにメッセージを送信するか、特別なキーを介して異なるエンドポイントに個別に接続できます。 これらのキーを使用すると、クライアントを柔軟に管理できます。一部の接続を切断したり、新しいクライアントを接続したりできます。コンセントレータ内にはパーティションもあります。 ただし、この場合、生産性を高めるためにすべてのクライアントに配布するか（ラウンドロビン-「周期的追加」）、クライアントはセクションの1つでメッセージを発行できます。 一方、処理サービスは消費者グループにまとめられます。 1つまたは複数のサービスを1つのグループに接続できます。 したがって、メッセージコンセントレータは、キュー、セクションまたはキューのグループ、またはセクションのセットとして構成できる最も柔軟なサービスです。 一般に、メッセージコンセントレータは、クライアントとサービスの間に多対多の関係を提供します。 これらのハブには、Apache Kafka、Azure Event Hub、AWS Kinesis Streamが含まれます。



クラウドベースのPaaSサービスを見る前に、非常に強力で有名なサービスであるApache Kafkaを見てみましょう。 クラウド環境では、仮想マシンクラスターに直接展開されたディストリビューションとして、またはHDInsightサービスを使用してアクセスできます。 したがって、Apache Kafkaは次の機能を提供するサービスです。

• メッセージフローの投稿とサブスクライブ
• メッセージの信頼できる保存。
• サードパーティのストリーミングメッセージ処理サービスのアプリケーション。

物理的に、Kafkaは1つ以上のサーバーのクラスターで実行されます。 Kafkaは、外部クライアントと対話するためのAPIを提供します（図10.4）。









これらのAPIを順番に検討してください。

• ベンダーAPIを使用すると、クライアントアプリケーションは1つ以上のKafkaトピックでメッセージフローを公開できます。
• コンシューマAPIを使用すると、クライアントアプリケーションは1つ以上のトピックをサブスクライブし、トピックからクライアントに配信されるメッセージフローを処理できます。
• ストリーミングプロセッサAPIを使用すると、アプリケーションはストリーミングプロセッサとしてKafkaクラスタと対話できます。 1つのプロセッサのソースは、1つ以上のトピックです。 この場合、処理されたメッセージも1つ以上のトピックに配置されます。
• コネクタAPIは、外部データソース（たとえば、RDB）をメッセージソース（たとえば、データベース内のデータ変更イベントをインターセプトすることができます）および受信者として接続するのに役立ちます。

Kafkaでは、クライアントとクラスター間の相互作用はTCPプロトコルを使用して行われます。TCPプロトコルは、.Netを含むさまざまなプログラミング言語の既存のSDKによって促進されます。 しかし、基本的なSDK言語はJavaとScalaです。



クラスターでは、メッセージフロー（Kafkaの用語ではエントリとも呼ばれます）の格納は、トピックと呼ばれるオブジェクトで論理的に行われます（図10.5）。 各レコードは、キー、値、およびタイムスタンプで構成されます。 本質的に、トピックは、顧客によって公開された一連のレコード（メッセージ）です。 Kafkaトピックは、0から複数のサブスクライバーをサポートします。 各トピックは、パーティション化されたログとして物理的に表されます。 各セクションはレコードの順序付けられたシーケンスであり、Kafkaの入力に到着する新しいレコードは常に追加されます。









セクション内の各エントリは、シーケンス内の番号に対応します。これはオフセットとも呼ばれ、シーケンス内のこのメッセージを一意に識別します。 キューとは異なり、Kafkaはサービスの処理後ではなく、メッセージの有効期間後にメッセージを削除します。 これは非常に重要なプロパティであり、1つのトピックから異なる消費者に読む機能を提供します。 さらに、各消費者にはオフセットが関連付けられています（図10.6）。 そして、読書の各行為は、各クライアントの価値を個別に増加させるだけであり、クライアントによって正確に決定されます。









通常、トピックから1つのメッセージを正常に読み取った後、このオフセットは1増加します。 ただし、必要に応じて、クライアントはこのオフセットをシフトし、読み取り操作を繰り返すことができます。



セクションの概念の使用には、次の目的があります。



まず、セクションは、1つのトピックが同じノードに収まらない場合にトピックをスケーリングする機能を提供します。 同時に、各セクションには、1つの先行ノード（クラスター全体のヘッドノードと混同しないでください）およびゼロまたは複数のフォロワーノードがあります。 ヘッドノードは読み取り/書き込み操作の処理を担当し、フォロワーはパッシブコピーです。 マスターノードに障害が発生すると、後続ノードの1つが自動的にヘッドノードになります。 各クラスターノードは、一部のセクションのリードであり、他のセクションのフォロワーです。 第二に、このようなレプリケーションは、並列読み取り操作の可能性により読み取りパフォーマンスを向上させます。



プロデューサーは、メッセージを自分の選択した任意のトピックに明示的に配置することも、暗黙的にラウンドロビンモードで配置することもできます（つまり、均一に塗りつぶす）。 消費者はいわゆる消費者グループにまとめられ、トピックで公開された各メッセージは各消費者グループの1人の顧客に配信されます。 この場合のクライアントは、1つ以上のサーバー/仮想マシンで物理的にホストできます。 より詳細には、メッセージ配信は次のとおりです。 同じ消費者グループに属するすべての顧客に対して、負荷を最適化するために顧客間でメッセージを配信できます。 顧客が異なる消費者グループに属している場合、各メッセージは各グループに送信されます。 異なる消費者グループによるセクションからのメッセージの分離を図に示します。 10.7。



ここで、Kafkaが保証するメッセージ配信とストレージの主なパラメーターについて簡単に説明します。

• 製造元から特定のトピックに送信されたメッセージは、送信された順に厳密に追加されます。
• クライアントは、メッセージが保存されたときに受信したトピックのメッセージの順序を確認します。 その結果、メッセージはプロデューサーからコンシューマーに厳密に受信した順序で配信されます。
• N倍のトピックレプリケーションにより、パフォーマンスを損なうことなくトピックがN-1ノードの障害に耐えることが保証されます。

そのため、Apache Kafkaサービスは次のモードで使用できます。

• サービス-メッセージブローカー（キュー）またはパブリケーションサービス-メッセージサブスクリプション（トピック）。 実際、Kafkaは、サブスクライバーが1人いる場合にキューに変換できるトピックのグループに基づいています。 （覚えておく必要があります：キューの原則に基づいて構築されたメッセージブローカーの通常のサービスとは対照的に、Kafkaでは、メッセージはその有効期限が切れた後にのみ削除されますが、ブローカーはPeek-Delete原則、つまり正常な処理後に取得と削除を実装します。 ）消費者グループの原則はこれらの2つの概念を要約し、ラウンドロビンの配布によりすべてのトピックでメッセージを公開する機能により、Kafkaはユニバーサルマルチモードメッセージブローカーになります。
• メッセージストリーミングサービス。 これは、Kafkaに含まれるストリームプロセッサAPIのおかげで可能になります。これにより、イベントドリブンの原理で作成された複雑なシステムを構築できます。メッセージをフィルタリングまたは応答するサービスと、メッセージを集約するサービスがあります。

これらのすべてのプロパティにより、ストリーミングデータを処理し、複雑なメッセージ処理システムを構築するための優れた機能を備えたプラットフォームの主要コンポーネントとしてKafkaを使用することができます。 しかし同時に、Kafkaはいくつかのノードのクラスターをデプロイおよび構成するという点で非常に複雑であり、これには多大な管理作業が必要です。 ただし、一方で、Kafkaの基礎となるアイデアはシステムの構築、メッセージの受信および処理のストリーミングに非常に適しているため、クラウドプロバイダーはこれらのアイデアを実装し、Kafkaクラスターの構築と管理のすべての困難を隠すPaaSサービスを提供します。 ただし、これらのサービスには、サービスに割り当てられた制限を超えるカスタマイズと拡張に関して多くの制限があるため、クラウドプロバイダーは、仮想マシンクラスターでのKafkaの物理展開に特別なIaaS / PaaSサービスを提供します。 この場合、ユーザーは構成と拡張のほぼ完全な自由を持っています。 これらのサービスには、Azure HDInsightが含まれます。 すでに上で言及されています。 ユーザーにHadoopエコシステムからのサービスを外部ラッパーなしで独自に提供するため、また一方で、IaaSを直接インストール、管理、および構成する際に発生する問題を軽減するために作成されました。 Dockerホスティングは少し離れています。 これは非常に重要なトピックなので、検討しますが、最初にKafkaの基本概念を使用して実装されたPaaSサービスに精通します。

10.2。 Azureイベントハブ

Azure Event Hubメッセージハブサービスを検討してください。 これは、PaaSモデルに基づいて構築されたサービスです。 クライアントのさまざまなグループは、Azure Event Hubのメッセージソースとして機能できます（図10.8）。 まず、これは、イベントハブにメッセージを直接送信するように出力またはトリガーを構成できるクラウドサービスの非常に大きなグループです。 これらは、Stream Analyticsジョブ、イベントグリッド、イベントをリダイレクトする重要なサービスグル​​ープ-イベントハブ（主にAppServiceを使用して構築されたApiアプリ、Webアプリ、モバイルアプリ、機能アプリ）になります。









ハブに配信されたメッセージを直接キャプチャして、Blob StorageまたはData Lake Storeに保存できます。



ソースの次のグループは、Azure Event Hub SDKがなく、Azureサービスと直接統合できない外部ソフトウェアクライアントまたはデバイスです。 これらのクライアントには主にIoTデバイスが含まれます。 HTTPSまたはAMQPを介してイベントハブにメッセージを送信できます。 これらのデバイスの接続方法の検討は、本書の範囲外です。



最後に、Azure Event Hub SDKを使用してメッセージを生成し、イベントハブに送信するソフトウェアクライアント。 このグループには、Azure PowerShellとAzure CLIが含まれます。

イベントハブからのメッセージ（コンシューマ-「コンシューマ」）の受信者は、Stream Analyticsジョブまたは統合サービスイベントグリッドである場合があります。 また、Azure Event Hub SDKを使用して、ソフトウェアクライアントがメッセージを受信することもできます。 コンシューマは、AMQP 1.0プロトコルを使用してイベントハブに接続します。



Azure Event Hubの使用方法と構成方法を理解するために必要なAzure Event Hubの基本概念を検討してください。 ハブにメッセージを送信するソース（ドキュメントではパブリッシャーとも呼ばれます）は、HTTPSまたはAMQP 1.0を使用する必要があります。 プロトコルの選択は、クライアントのタイプ、通信ネットワーク、およびメッセージレートの要件によって決まります。 AMQPでは、2つの双方向TCPソケット間の永続的な接続が必要です。 TLSトランスポート層暗号化プロトコルまたはSSL / TLSを使用して保護されます。 これはすべて、特に、初期接続の確立にはAMQPプロトコルがHTTPSよりも長い時間を必要とすることを意味しますが、メッセージフローが一定の場合、最初のプロトコルの方がはるかに高いパフォーマンスを発揮します。 まれなメッセージの場合、HTTPSが優先されます。



ソースは、自身を識別するために、SAS（Shared Access Signature）トークンメカニズムに基づく識別メカニズムを使用できます。 最も単純なケースでは、すべてのパブリッシャーが1つの共通SASトークンをすべてに適用するか、異なるパブリッシャーの異なるSASトークンに柔軟な配布ポリシーを使用できます。 異なるSASトークンによるソースの分割に加えて、セクションキーによる分割が使用されます（これについては以下で詳しく説明します）。



各ソースは、256 KB以下のメッセージを送信できます。 つまり、長いメッセージを連続して送信される複数のメッセージに分割するか、バイナリ形式に切り替えてデータ圧縮を使用する必要があります。



次に、イベントハブでメッセージが直接処理される方法を見てみましょう。 前の章ですでに述べたように、メッセージコンセントレータの概念は、コンシューマサブスクライバが接続できるエントリポイントと複数の出力を持つトピックのグループに基づいています。 EventHubの場合、これらのトピックはパーティションと呼ばれます。 概念的には、EventHubセクションは、先入れ先出し（FIFO）キューの原則に従って編成されたメッセージの順序付きシーケンスです（図10.9）。









各セクションは、イベントハブ全体内の独立した一連のメッセージです。 1つのイベントハブには2〜32個のパーティションを含めることができ、この値はイベントハブの作成後に変更できません。 コンセントレータから同時に取得されるメッセージの数は、パーティションの数に等しいことを理解することが非常に重要です。



セクション（および実際にはキュー）のメッセージは、コンシューマーがそれを取得するまで（削除されず、アクセスできなくなる-以下を参照）、または特定の保持期間（これはチューンイン これを明確にする必要があります。 いずれにせよ、メッセージは保存期間が終了した後にのみ物理的に削除されます。 セクションからメッセージを読み取る機能を提供するために、Azure Event Hubはオフセットの概念を実装しています。 この場合のオフセットは、現在の読み取り位置を示すセクション内の位置、つまり実際には現在の読み取り位置の番号を持つカーソルです。 メッセージを正常に取得した後、コンシューマはカーソルを1ポジション移動します。 Azure Event Hub SDKでは、メッセージを読み取ることができる任意の位置を設定できますが、これは推奨されません。 同時に、クライアント消費者はバイアスを保存する責任があり、彼自身がこの値を保存および更新する必要があります。









したがって、消費者は同じメッセージを数回読むことができますが、このメッセージの位置に対応するオフセットを毎回示す場合のみです。 ただし、標準のAzure Event Hub SDKは、信頼性の高いストレージとオフセットの更新のためのメカニズムを提供するため、デフォルトではこの可能性を除外しています。 通常、オフセットの保存にはストレージアカウントが使用されます。 イベントメッセージリスナーであるAzureサービスは、メッセージの保存を担当します。



Event Hub内の各セクションには独自のパーティションキーがあり、特定のソースから特定のセクションにメッセージを送信できます。 このアクションの目的は、メッセージフローを整理することです。 たとえば、ハブにはさまざまなパフォーマンス（単位時間あたりのメッセージ数）の多くのセクションとソースが含まれており、メッセージの発行と読み取り用の専用チャネルを作成する必要があります。 ソースでセクションキーが明示的に指定されていない場合、セクションキーはセクション間で均等に分散されます（ラウンドロビン）。



次に、ハブからメッセージを取得する問題について考えてみましょう。 すべての消費者は、共同で管理されるグループに論理的に結合され、消費者グループと呼ばれます（図10.11）。 グループを使用すると、異なる消費者が同じセクションから独立した読書を整理できます。 同時に、各グループは各クライアントアプリケーションに独自のビュー（各セクションの現在のオフセットの値）を与える機会を与えるため、セクションから独立してデータを読み取ります。 消費者グループごとに、このような表現は完全に異なるため、複雑なデータ処理シナリオを実装できます。 消費者グループの最大数は20ですが、各グループには5人までの消費者を含めることができ、同時に、グループから1人の消費者のみがセクションからメッセージを読み取ることができます。



ハブを分割すると、複数のコンシューマーによるメッセージの並列読み取りが可能になります。 さらに、単位時間あたりの所定量の受信に関するハブのパフォーマンスを調整できます。 これを行うために、スループット単位と呼ばれるパラメーターがあります。 帯域幅の各単位には、次の値が含まれます。

• 入力ストリームの場合-1秒あたり1 MBまたは1秒あたり1000メッセージ（これらの制限のどちらに最初に到達するかに応じて）。
• 出力ストリームの場合-1秒あたり2 MB。

特定の量のスループットは、ハブごとに個別に構成されます。 ソースが許容スループットを超えると、例外がスローされます。 この場合、受信者は特定の値よりも速くメッセージを受信できません。 帯域幅の単位は、サービスの使用コストにも影響します。 注意してください！ Event Hubサービスの個々のインスタンスではなく、ネームスペースに帯域幅制限が割り当てられていることに注意してください。









メッセージコンセントレーターは、名前空間（名前空間）に論理的にグループ化されます（図10.12）。











»本の詳細については、出版社のウェブサイトをご覧ください

» コンテンツ

» 抜粋



ホーカーのクーポンが20％オフ-BigData