OLAPとは何ですか？ストリーム処理とは何ですか？それらはどのように異なるのでしょうか？このブログでは、OLAPとストリーム処理を包括的に比較することによって、これらの質問に答えます。
OLAPとは？
オンライン分析処理（OLAP）は、データベースに対する分析的なクエリに迅速に回答するために設計されたシステムの概要です。伝統的には、このようなシステムはデータウェアハウスとして知られており、分析用に履歴データを格納する中央集約型のリポジトリです。
OLAPシステムを展開するための典型的なアーキテクチャは、下記の図に示されています。OLAPシステムは通常、データライフサイクルの終わりに配置されます。データがETLプロセスを経てデータソースから変換され、クリーンなデータがOLAPシステムに取り込まれます。その後、OLAPシステムはユーザーのアドホックなクエリに直接回答し、累積されたデータに対する分析結果をリアルタイムで提供します。
リアルタイムクエリ応答をサポートするための技術的な課題は、複雑なアドホッククエリに対するクエリ遅延を減少させることです。歴史的には、OLAPシステムはデータを多次元配列に整理するデータキューブを使用し、アドホッククエリに答えるために事前集計統計を広範に使用していました。現代では、ハードウェアとクラウドコンピューティングの発展により、技術的な傾向はデータキューブからモダンデータウェアハウスにシフトしました。これらのシステムは、分離されたストレージレイヤー、カラム型ストレージ形式、ベクトル化されたクエリ実行、大規模並列処理などの技術を採用しています。モダンデータウェアハウスの設計原則は、ストレージレイヤーからのデータ読み込みオーバーヘッドを減少させ、クラウド上の計算リソースを並列化によって最大限に活用し、異なるサービスを分離してリソースの無駄を避けることです。
OLAPシステムは、データ分析とビジネスインテリジェンスをサポートするために広く展開されています。データサイエンティストや意思決定者は、中央集約型データリポジトリに対して直接複雑で深い分析的なクエリを発行し、OLAPシステムはデータから洞察を得て、情報に基づいたビジネス意思決定を行うためのレポートを生成します。
ストリーム処理とは？
ストリーム処理は、システムがデータを受信した後、継続的なデータストリームを直接処理するプログラミングのパラダイムです。通常、ストリーム処理システムは結果を保存しません。あらかじめ定義されたクエリに基づいて、ストリーム処理システムはストリーミングパイプラインを構築し、到着するデータストリームを受け取り、そのストリームを処理し、出力ストリームを下流のシステムに送ります。
下の図に示されているように、ストリーミングデータアーキテクチャは複数のコンポーネントで構成されています。まず、ストリームソースがデータプロデューサーからデータを取得します。データプロデューサーにはセンサー、トランザクションデータベース、その他の多くのデータソースが含まれます。ストリーム処理システムは、これらのプロデューサーによって生成されたデータストリームを受け取り、それらを変換し、出力ストリームを下流システムに送ります。これにより、下流システムはクリーンで整然としたデータを操作することができます。
ストリーム処理システムは、事前定義されたクエリに対して迅速な更新を提供するように設計されています。これを実現するために、インクリメンタル計算はストリーム処理の設計原則の中心にあります。データリポジトリ全体を再スキャンするのではなく、ストリーム処理システムは中間結果を保持し、新しいデータに基づいてのみ更新を計算します。このような中間結果は、システム内で「状態」と呼ばれます。ほとんどの場合、状態はメモリ内に保存され、状態フルな計算の低遅延を保証します。この設計は、ストリーム処理システムを障害に対して脆弱にします。任意のノードの状態が失われると、ストリーム処理パイプライン全体が崩壊します。そのため、ストリーム処理システムは、外部の耐久性のあるストレージシステムにグローバル状態の一貫性のあるスナップショットを定期的にバックアップするチェックポイント機構を使用します。システムが障害を起こした場合、最後のチェックポイントにロールバックし、耐久性のあるストレージシステムから状態を回復することができます。
ストリーム処理は、即座にデータを処理し、即座に意思決定を行う必要があるタスクに最適です。例えば、不正なアカウントはシステムに受信された時点で即座に検出する必要があります。汚れたレコードはデータウェアハウスを汚染する前に排除しなければなりません。また、メトリックが閾値を超えた場合、すぐにアラートを発信する必要があります。ユーザーがクエリを事前に定義すれば、ストリーム処理システムは新たに受信したデータからインクリメンタルにクエリ結果を更新することができます。
どのように異なるのか？
OLAPとストリーム処理はどちらも即時に分析結果を提供することを約束しますが、いくつかの点で異なります。
データソース
OLAPシステムは、他のシステムによってクリーンアップされた構造化データを取り込みます。構造化データとクリーンデータは、バルクでOLAPシステムにロードされます。
ストリーム処理システムは、生データまたはクリーンデータのデータストリームを受け取ります。これらのデータストリームは、AWS KinesisやRedisなどのメッセージブローカーから生成されます。データストリームは、メッセージブローカーが記録したイベントで構成され、それらは継続的にストリーム処理システムに送られます。データストリームは複数の異なるソースから来ており、継続的に収集されます。
出力
OLAPは、ユーザーの複雑なアドホックなクエリに応じてデータ分析結果を出力します。クエリはデータリポジトリ全体に対して発行され、通常、リポジトリのかなりの部分がクエリに関連しています。クエリ結果は通常小さく、ビジネスインテリジェンスでチャートやグラフとして表示されます。
ストリーム処理は、クエリされたデータストリームを出力し、それをデータシンクに保存して後でさらに分析できるようにします。クエリは通常、単純で事前定義されたもので、データストリームに対して継続的に実行され、サイクルごとの更新を提供します。ユースケースに応じて、出力ストリームは非常に小さいか、累積的に非常に大きくなることがあります。
ストレージ
OLAPシステムは、通常、読み取りに優れた形式でストレージを管理します。歴史的に、OLAPシステムのデータは多次元キューブに格納されており、データを事前に集計してクエリ結果を迅速に生成することができます。最近では、カラム型データベースに移行し、クエリ、ソート、インデックス作成のプロセスを加速し、データをより効率的に圧縮しています。注目すべきは、いくつかのOLAPシステムが自分のストレージシステムを管理せず、外部のストレージシステムからデータを読み込むことで、データは Apache Parquet や Apache Avro などのオープンフォーマットで保存されています。
従来、ストリーム処理システムにはクエリ可能な耐久性のあるストレージがありません。データの出力ストリームは後で別のシステムに保存されることがあります。その代わりに、ストリーム処理システムは状態を管理します。これは、過去のイベントが現在のイベントに影響を与える場合です。ストリーム処理システムは、ローカルメモリ、ローカルディスク、外部耐久性ストレージシステムなど、異なるレベルで状態を管理します。最近では、モダンなストリーム処理システムは、管理された状態に対して直接クエリを発行することも可能にしています。
堅牢性
OLAPシステムは、基盤となるデータベースに対する変更が少ないため、一般的に故障しません。もしクエリが失敗した場合、そのクエリを再実行することができます。データベースのバックアップ作成は依然として重要ですが、データの再ロードが回復方法の一つでもあるため、頻繁にバックアップを取る必要はありません。
一方、ストリーム処理システムは、継続的なクエリを実行しているため、故障が発生しやすいです。状態フルなストリーミングでは、現在のイベントが過去のイベントに依存しているため、ストリームの各失敗はグローバルな失敗につながる可能性があります。そのため、ストリーム処理システムは一貫性のあるチェックポイントを用いて耐障害性を確保します。これは、ストリーミングアプリケーションのメタデータが保存されることを意味します。ストリーム処理システムは常にデータを取り込み分析しているため、故障に遭遇する機会が多くなります。
データのスケール
OLAPシステムは、クエリのためにデータベース全体をスキャンする必要がある場合があります。これにより、PB（ペタバイト）レベルのデータを処理する可能性があります。
ストリーム処理システムは、データストリームを継続的に処理します。これらのシステムは、毎秒GBレベルのデータを処理できます。
特定のユースケース
OLAPは、ビジネスインテリジェンスに広く適用されています。例えば、財務報告、予算編成、マーケティングなどのケースで使用されます。もう一つの重要なユースケースは、データサイエンティストが機械学習モデルに投入するデータを準備することです。これらのケースでは、データが時間をかけて収集され、ビジネスに長期的な影響を与える意思決定を行うために、より深く複雑な分析が必要です。
ストリーム処理は、不正検出、センサーデータ、ライドシェアのマッチングなどに適しています。これらのケースはイベント駆動型であり、データがリアルタイムで到着し、即座に分析結果が求められます。
代表的なシステム
OLAP システムには、Apache Druid、Apache Pinot、ClickHouse、Amazon Redshift、Snowflake などがあります。
ストリーム処理システムには、Apache Flink、Apache Storm、RisingWave などがあります。
データライフサイクルにおける目的
OLAPシステムは、データがクリーンに整理され、関連性がフィルタリングされた後、データライフサイクルの終わりで使用されます。ユーザーは、データウェアハウスに保存されたデータに基づいて分析的な洞察を得るために、複雑なアドホッククエリをシステムに対して発行します。その後、分析結果を利用して、インパクトのあるビジネス意思決定を行います。
ストリーム処理システムは、データが生成された直後、つまりデータライフサイクルの始めに使用されます。事前定義されたクエリを使って、システムがデータをクリーンアップし、簡単な分析結果を提供します。出力ストリームは、後で異なるシステムで保存され、ユースケースに応じて分析されます。
| 機能 | OLAP | ストリーム処理 |
|---|---|---|
| データソース | 構造化され、クリーンにされたデータ（バルク） | 生データのデータストリーム |
| 出力 | データリポジトリ全体に対するアドホッククエリ結果 | 下流システムで処理されるデータストリーム |
| ストレージ | カラム型ストレージ、二次インデックス、データキューブ。管理された集中型ストレージまたは外部ストレージ | 状態フルなストリーム処理のための状態ストア。チェックポイントのための外部耐久性ストレージ |
| 堅牢性 | クエリの失敗は問題ではない | 障害に対して脆弱であり、一貫性のあるチェックポイントに依存 |
| データのスケール | PBレベルの累積データ | 毎秒GBレベル |
| ユースケース | ビジネスインテリジェンス、データサイエンス | 不正検出、センサーデータ、イベント駆動型アプリケーション |
| 代表的なシステム | Apache Druid、Apache Pinot、ClickHouse、Redshift、Snowflake | Apache Flink、Apache Storm、RisingWave |
| データライフサイクルにおける目的 | データウェアハウスから複雑な分析結果を出力してアドホッククエリに回答 | データが生成された直後に簡単な分析結果を提供するために使用 |
けつご
OLAPとストリーム処理は、異なるタスクに適した異なる技術群です。ストリーム処理システムは、リアルタイムでデータストリームに対して事前定義されたタスクを実行する一方で、OLAPシステムはデータセット全体に対してアドホッククエリを実行し、有益なユーザー洞察を提供します。
リアルタイムデータ分析が今日の多くの分野で推進力となっている中、私たちは複数のソリューションの中から最も適切なツールを選択すべきです。便利なことに、ストリーム処理とOLAPシステムを統合して、データ分析のプロセスをより効率的にするエンジンを作るという傾向があります。RisingWaveでは、この傾向を観察し、リアルタイムデータ処理をシンプルで手頃でアクセスしやすくするためにイノベーションを続けています。