リアルタイムモード: 2つ目のエンジンを必要とせず、Spark APIで超低レイテンシのストリーミングを実現

Apache Spark構造化ストリーミングは、ストリーミングETLからアナリティクス、機械学習に至るまで、ミッションクリティカルなデータパイプラインを大規模に長年支えてきました。しかし、運用上のユースケースが進化するにつれ、チームは不正検知、パーソナライゼーション、異常検知、リアルタイムのアラート、レポート作成などのアプリケーションで、1秒未満のレイテンシといった、より高度な要求をするようになりました。

これまで、これらの超低レイテンシ要件を満たすには、Sparkと並行して専門的なシステムを導入する必要がありました。Spark Structured Streamingにリアルタイムモードが導入されたことで、そのトレードオフはもはや不要になりました。このブログでは、Sparkが特徴量エンジニアリングなどの一般的なユースケースにおいて、リアルタイムストリーミングアーキテクチャをどのように簡素化し、長年にわたる運用上の複雑さを排除し、業界をリードするパフォーマンスを実現するかについて探ります。

リアルタイムストリーミングでは、複数の異種のシステムを運用する必要がなくなりました

リアルタイムでデータを処理し、それに基づいて行動する能力は、今や中核的な要件となっています。最新のアプリケーション、特にAIエージェントは、機能するために最新のコンテキストからなる継続的なストリームに依存しています。基盤となるデータが不完全であったり、遅延したりすると、ユーザーエクスペリエンスが損なわれます。リアルタイムのパフォーマンスは、不正検知などの従来のユースケースだけでなく、ユーザーが正確で最新の応答を期待するあらゆる一般的なインタラクションにおいても必要とされます。このような環境では、レイテンシは収益、顧客の信頼、競争上の優位性に直接影響します。

リアルタイムストリーミングアプリケーションを構築するデータチームは、これまで、大規模アナリティクス向けのApache Spark™と、1秒未満のレイテンシに敏感なアプリケーション向けのApache Flink®やKafka Streamsなどの特殊なシステムという、2つの異なるデータ処理スタックを管理する必要がありました。この断片化により、チームは重複したコードベースを維持し、別々のガバナンスモデルを管理し、エンジン固有のインフラストラクチャを調整・維持するために専門的な人材を雇う必要がありました。

2025年8月にパブリックプレビューとしてリリースされたApache Spark Structured Streamingのリアルタイムモード（RTM）は、このような摩擦を解消するために設計されています。Spark 実行エンジンを根本的に進化させることで、2 つ目のシステムは不要になりました。この移行により、エンジニアは、高スループットのETLから低レイテンシのリアルタイムアプリまで、あらゆるユースケースに、すでに使い慣れた同じSpark APIで対応できるようになります。これにより、インフラストラクチャの管理時間が短縮され、ビジネスのユースケースにより多くの時間を集中させることができます。

Spark は、ミリ秒単位でイベントを処理できるようになりました。これは Flink よりも最大 92% 高速です。

リアルタイムモード（RTM）では、Sparkが一貫して1秒未満のレイテンシを実現できるようにする、新しい最適化された実行エンジンが導入されました。パフォーマンスを評価するために、Spark RTMとApache Flinkの横並び比較を実施しました。このテストは、本番運用で一般的に見られるリアルタイムの特徴量計算ワークロードに基づいています。これらの特徴量計算パターンは、不正検知、パーソナライゼーション、オペレーショナルアナリティクスなど、ほとんどの低レイテンシETLユースケースの代表例です。

3つの一般的なフィーチャーパターンを評価しました。

• 特徴量エンコーディング (ステートレス変換): 入力行の切り捨てと エンコーディング
• フィーチャーエンリッチメント（結合による）: ストリームと静的テーブルの結合
• 特徴量計算（集計経由）: GroupBy + Count集計

この結果は、Sparkの進化したアーキテクチャが、特殊なストリーミングフレームワークに匹敵するレイテンシプロファイルを提供することを示しています。

このパフォーマンスは、RTMにおける3つの主要な技術革新によって実現されています。

• 継続的なデータフロー: データは、不連続な定期的チャンクとしてではなく、到着と同時に処理されます。
• パイプライン スケジューリング: 各ステージがブロックすることなく同時に実行されるため、下流タスクは上流ステージの完了を待たずに、すぐにデータを処理できます。
• ストリーミングシャッフル: データはタスク間ですぐに渡され、従来のディスクベースのシャッフルによるレイテンシのボトルネックを回避します。

これらが一体となり、Sparkは最も要求の厳しい運用ユースケースを処理できる、高性能かつ低レイテンシのエンジンへと変貌します。

チームはより少ないインフラストラクチャで運用し、Spark を使用してより迅速に開発を進めることができます。

生の速度は不可欠ですが、リアルタイムモードの真の価値は、超低レイテンシパイプラインの構築を通常妨げる運用上の複雑さを排除できる能力にあります。Spark RTMは、3つの主要な利点を通じて、アーキテクチャを大幅に簡素化します。これを具体的にするために、リアルタイムのmachine learningアプリケーションのコンテキストでこれらを説明します。

トレーニングと推論間の「ロジックドリフト」を最小化: 不正検知などのリアルタイム機械学習には、高スループットのバッチ処理（モデルトレーニング用）と低レイテンシのストリーミング（ライブ推論用）の間のシームレスなハンドオフが必要です。Sparkはモデルトレーニングにおいてデータサイエンティストに好まれる選択肢であり、推論のためにSparkからFlinkへの切り替えを強制すると、ビジネスロジックにギャップが生じます。結局、トレーニング用にはSparkのロジックの1つのバージョンを、本番運用にはFlinkの全く異なるコードベースを使用することになります。このビジネスロジックの複製はエラーが発生しやすく、モデルがある現実でトレーニングされ、別の現実でスコアリングされるというロジックドリフトにつながります。Spark RTMを使用すると、変換コードは同一のままとなり、より迅速かつ高い精度で特徴量を本番環境に導入できます。

1行のコード変更でオンデマンドの鮮度を実現: ビジネス要件が静的であることはほとんどありません。モデルの鮮度に対するニーズが進化するにつれて、今日は1分間のSLAで始まる特徴量パイプラインが、明日には1秒未満のレイテンシを必要とするようになるかもしれません。逆に、多くのユースケースでは、即時の鮮度が要求されない場合、「より遅くする」（例：日次または時間単位のバッチ）ことが大幅にコスト効率が良くなります。Sparkは、製品と共に成長し、規模を拡大する余地を提供します。これにより、1行のコードを変更するだけで、特徴量エンジニアリング戦略を簡単に転換できます。例えば、triggerを AvailableNow に設定して、パイプラインを毎日または毎時のスケジュールで実行できます。ビジネスニーズが変化した場合は、リアルタイムモードに切り替えるだけで、継続的な超低レイテンシのストリーミングに移行できます: .trigger(RealTimeTrigger.apply())。対照的に、Flinkでこれを実現するのは手動のプロセスです。新しい処理頻度に対応するためだけに、並列処理を調整し、コンピュートリソースのシャットダウンと再起動を調整する必要がしばしばあります。

開発の迅速化: RTMは、チームがすでに使い慣れているのと同じSpark API上に構築されています。これにより、複数のシステムを維持する手間が省け、単一の一貫した環境内でリアルタイムアプリケーションを構築・スケーリングすることで、より迅速に作業を進めることができます。

顧客はSpark上でいくつかのリアルタイムアプリケーションを実行しています

早期導入者は、業界を問わず、RTM を使用してさまざまな低レイテンシ アプリケーションを強化しています。

不正検知: ある主要なデジタル資産プラットフォームは、Kafkaストリームから速度チェックや集計支出パターンなどの動的なリスク特徴量をコンピュートし、オンラインのFeature Storeを200ミリ秒未満で更新して、販売時点で不正な取引をブロックします。

パーソナライズされたエクスペリエンス: eコマースプラットフォームは、ユーザーの現在のセッションに基づいてリアルタイムの意図に関する特徴量を計算し、ユーザーが製品を操作した瞬間にモデルが推奨を更新できるようにします。

IoTモニタリング: ある運輸・物流会社は、ライブテレメトリを取り込んで異常検知を行い、ミリ秒単位で事後対応的な意思決定から事前対応的な意思決定へと移行しています。

北米最大級のスポーツブックおよびファンタジースポーツサービスの1つであるDraftKingsは、不正検知モデル向けの特徴量計算を強化するためにRTMを使用しています。

「ライブスポーツベッティングでは、不正検知に極めて高い速度が要求されます。Spark Structured StreamingにtransformWithState APIとともにリアルタイムモードが導入されたことは、私たちにとって画期的なことでした。レイテンシとパイプライン設計の両方で大幅な改善を達成し、初めて機械学習トレーニングとオンライン推論のための統合された特徴量パイプラインを構築し、以前は不可能だった超低レイテンシを実現しました。」—マリア・マリノワ、DraftKings、シニアリードソフトウェアエンジニア

Sparkリアルタイムモードで構築を始めましょう

「簡単」と「高速」のどちらかを選ぶ時代は終わりました。1つのエンジンがすべてをこなすようになった今、なぜ2つのエンジン、2つのセキュリティモデル、2セットの専門スキルを管理する必要があるのでしょうか？RTMは、リアルタイムアプリケーションが要求する1秒未満の速度と、チームにふさわしいアーキテクチャのシンプルさを提供します。「運用税」を取り除くことで、インフラストラクチャの管理ではなく、価値の構築にようやく集中できるようになります。

リアルタイムスタックの複雑さを解消する準備はできていますか？

• 詳細を確認する: RTMドキュメントで、完全な技術仕様、サポートされているソースとシンク、クエリの例をご確認ください。新しいトリガーを有効にし、ストリーミングワークロードを構成するために必要なものがすべて見つかります。
• 実際の動作を見る: RTMの背後にあるエンジニアリングをより深く知るには、設計と実装を解説するこの技術詳細セッションをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事