ストリーミングデータは、数千ものデータソースによって継続的に生成されるデータです。通常は、小さなサイズ (キロバイト単位) で同時にデータレコードが送信されます。ストリーミングデータには、お客様のモバイルアプリケーションやウェブアプリケーションで顧客によって生成されるログファイル、e コマースでの購入内容、ゲーム内でのプレイヤーのアクティビティ、さらにはソーシャルネットワーク、証券取引所の立会場、または地理空間サービスからの情報、およびデータセンター内の接続されたデバイスや計器からのテレメトリなど、広範なデータがあります。
これらのデータは、レコード単位またはスライドした時間窓で連続的および増分的に処理する必要があり、相関分析、集計、フィルタリング、およびサンプリングなど、広範な分析に使用することができます。これらの分析から得られる情報により、企業では、顧客のサービス使用状況 (計測/請求用)、サーバー アクティビティ、ウェブサイトのクリック数、ならびにデバイス、ユーザー、物品の地理的場所など、自社ビジネスおよび顧客アクティビティの様々な側面を可視化し、新しい状況にすばやく対応できるようになります。例えば、ソーシャルメディアのストリームを継続的に分析することで、自社のブランドや製品への好感度の変化を追跡し、必要に応じてすばやく対応することができます。
ストリーミングデータの利点
新しい動的なデータが継続的に生成されるほとんどのシナリオで、ストリーミングデータ処理には利点があります。これは、ほとんどの業界およびビッグデータのユースケースに当てはまります。企業では一般に、システムログの収集や、ローリング最小値/最大値の計算などの基本的処理をはじめとする、シンプルなアプリケーションから始めます。その後、このようなアプリケーションはより洗練された、ほぼリアルタイムの処理に移行します。はじめに、アプリケーションではデータストリームを処理してシンプルなレポートを生成し、重要指標が特定のしきい値を超えたときにレスポンスとしてアラームを発するなどのシンプルなアクションを実行することができます。最終的には、そのようなアプリケーションでも、機械学習のアルゴリズムを適用するなど、洗練された形のデータ分析を行い、データから深いインサイトを抽出するようになります。やがて、現在最も人気のある動画を検出するための減衰時間枠などの複雑なストリームおよびイベント処理アルゴリズムが適用され、さらに充実したインサイトが得られるようになります。
ストリーミングデータの例
- 輸送車両、産業機器、および農業機械のセンサーが、ストリーミングアプリケーションにデータを送信します。アプリケーションは、パフォーマンスをモニタリングして事前に潜在的なエラーを検出し、交換部品を自動的に発注して機械のダウンタイムを防ぎます。
- ある金融機関では、株式市場の変化をリアルタイムで追跡して最大損失予想額を計算し、株価の変動に基づいて自動的にポートフォリオをリバランスしています。
- ある不動産会社のウェブサイトでは、コンシューマーのモバイルデバイスのデータサブセットを追跡し、コンシューマーの現在住所に基づいて訪れることのできる推薦物件をリアルタイムで紹介します。
- ある太陽光発電会社では、顧客に対する出力電力を維持できないと、違約金を支払う必要があります。その会社では、ストリーミングデータアプリケーションを実装して現場の全パネルをモニタリングし、リアルタイムで修理をスケジュールして、各パネルの低出力の時間とその間の違約金の支払いを最小限に抑えることができました。
- あるメディアでは、オンライン資産から数十億ものクリックストリームレコードをストリーミングし、ユーザーに関するデモグラフィック情報が含まれるデータを集計および拡充して、サイトへのコンテンツ配置を最適化し、高い関連性とより良いエクスペリエンスをユーザーに提供しています。
- あるオンラインゲーム会社では、プレイヤーとゲームのインタラクションに関するストリーミングデータを収集して、それをゲームプラットフォームに供給しています。さらに、そのデータをリアルタイムで分析することで、プレイヤーを囲い込むためのインセンティブとダイナミックなエクスペリエンスを提供しています。
バッチ処理とストリーム処理の比較
ストリーミングデータを扱う前に、ストリーム処理とバッチ処理を対比して整理することをお勧めします。バッチ処理は、様々なデータセットに対する無作為のクエリをコンピューティングするのに使用できます。バッチ処理では、通常、対象となるすべてのデータから得られた結果をコンピューティングし、ビッグデータセットを深く分析します。バッチジョブをサポートするプラットフォームの例には、Amazon EMR などの MapReduce ベースのシステムがあります。これに対し、ストリーム処理では、データのシーケンスを取り込んで、データレコードが供給されるたびに増分的にメトリクス、レポート、サマリー統計を更新する必要があります。ストリーム処理はリアルタイムモニタリングおよびレスポンス機能に適しています。
| バッチ処理 | ストリーム処理 | |
| データ範囲 | データセット内のデータの全部または大部分に対するクエリまたは処理。 | ローリング時間枠でのデータまたは直近のデータレコードのみに対するクエリまたは処理。 |
| データサイズ | 大きなデータバッチ。 | 少数のレコードから構成されるマイクロバッチまたは個々のレコード。 |
| パフォーマンス | 数分から数時間のレイテンシー。 | レイテンシーは数秒または数ミリ秒程度に抑える必要があります。 |
| 分析 | 複雑な解析。 | シンプルなレスポンス機能、集計、およびローリングメトリクス。 |
多くの組織では、これら 2 つのアプローチを組み合わせてハイブリッドモデルを構築しており、リアルタイムレイヤーとバッチレイヤーを管理しています。リアルタイムインサイトを抽出するため、データはまず Amazon Kinesis などのストリーミングデータプラットフォームによって処理されます。その後、S3 などのストアに永続化されます。S3 では、データは様々なバッチ処理のユースケースに合わせて変換およびロードされます。
ストリーミングデータ処理での課題
ストリーミングデータ処理には、ストレージレイヤーと処理レイヤーの 2 つのレイヤーが必要です。ストレージレイヤーでは、レコードの並べ替えをサポートするだけでなく、大きなデータストリームを低コストで高速に読み書きして再生できるようにする強力な整合性もサポートする必要があります。処理レイヤーでは、ストレージレイヤー内のデータを使用し、そのデータに対するコンピューティングを実行して、その実行後に不要になったデータを削除するようにストレージレイヤーに通知します。また、ストレージレイヤーと処理レイヤーの両方について、スケーラビリティ、データの耐久性、および耐障害性を考慮する必要もあります。このため、 Amazon Kinesis Data Streams、 Amazon Kinesis Data Firehose、 Amazon Managed Streaming for Apache Kafka (Amazon MSK)、Apache Flume、Apache Spark Streaming、および Apache Storm など、ストリーミングデータアプリケーションの構築に必要なインフラストラクチャを提供する多くのプラットフォームが登場しています。