データの鮮度とは。バッチ処理の限界とリアルタイム分析

本記事のポイント

    1. データの処理方式は、バッチとストリーミングとオンデマンドの3つ
    2. 必要な鮮度は用途ごとに違い、月次レポートなら締めの日までに整えばよい
    3. リアルタイムで処理するのは一部の用途だけで、まずはバッチで足りる

月曜日の朝、経営ダッシュボードを開きます。表示されているのは金曜日までの数字です。週末に起きた変化は、火曜日のバッチ処理が終わるまで画面に出てきません。多くの企業が、この翌日バッチのレポートで意思決定をしています。現場の営業担当者は今日の顧客の反応をその場で受け取り、工場の担当者は今この瞬間の稼働状況を見ています。判断の根拠になるデータだけが遅れています。この1日の差が、データにもとづいて決めることを難しくしています。データの鮮度とは、業務でその事象が起きてから、分析に使える形で画面に出るまでの時間です。必要な鮮度は用途ごとに違います。

DBリプレイスから始める AI時代のデータ基盤設計（構想）DBリプレイスから始める AI時代のデータ基盤設計
無料の資料を読む▶

 


 

1. データパイプラインの3つの方式

データが生成されてから分析に使える状態になるまでの処理の流れを、データパイプラインと呼びます。処理の方式は大きく3つに分かれます。

バッチ処理

スケジューラーで定期的にデータを一括処理する方式です。日次で実行する構成が多く見られます。処理のしくみが単純なため、開発者が組みやすく、動かす費用も抑えられます。多くの企業では、いまもデータ処理の大半をこの方式で行っています。

ストリーミング処理

データが生成された時点で処理する方式です。イベントを受け取って、取り込み、変換、配信を続けます。遅れは、構成と処理の内容によりますが、秒単位まで抑えられます。引き換えに、開発者が組む手間も、運用の担当者が監視する手間も、動かす費用も大きく増えます。

オンデマンド処理

APIの呼び出しやファイルの受け取りなど、特定のきっかけで起動する方式です。常に動かしておく必要がないため、業務の流れの中に組み込んで使われます。

この3つは、どれか1つを選ぶという関係ではありません。バッチとストリーミングは処理の方式、オンデマンドは起動のしかたを指すため、重なる部分があります。ストリーミングも、常時稼働させる構成と、定期的に起動して停止する構成の両方が取れます。

3つの方式と遅れの大きさ

💡STech I ワンポイントアドバイス

必要な鮮度は、技術ではなく判断の周期から決まります。その数字を見て何かを決める人が、どのくらいの間隔で決めているかを聞いてください。月次の予算会議で使う数字なら、締めの日までに整っていれば足ります。営業担当者がその日の訪問先を決めるために使うなら、出社の時点で必要な範囲が入っていれば足ります。決める間隔より短い周期で更新しても、判断の内容は変わりません。ただし、判断の周期の途中で急な対応が必要になる業務では、この目安は当てはまりません。

 

2. バッチでは間に合わない場面

すべてのデータ処理に即時性が求められるわけではありません。一方で、1日1回という頻度では対応できない場面があります。

不正検知

クレジットカードの不正利用を1日1回の処理で検知すると、判明するのは翌日です。その間の利用は止められません。不正が発生した時点で検知し、その場で取引を止めるしくみが必要です。

在庫の可視化

ECサイトで在庫ありと表示されていた商品が、注文の処理段階で品切れになっていることがあります。原因は、在庫の引き当ての方式や、複数の販売経路の間の同期など複数ありますが、在庫数の更新がバッチのタイミングまで画面に反映されないことも、そのひとつです。

需要予測

天候、SNS上の話題、競合の動きといった外部の情報を直近まで取り込めば、予測に反映できる材料が増えます。変化の速い商材では、予測の精度が大きく上がることがあります。精度が上がるかどうかは、モデルと対象によって変わります。

顧客の行動に基づく出し分け

Webサイトやアプリでの行動を見て、その場で表示する内容を変える使い方です。ECや会員向けサービスでは、この使い方が広がっています。行動から表示までの間にバッチの待ち時間が入ると、利用者はすでに別のページに移っています。

引き換えになるもの

ストリーミング処理には、構築と運用の費用がかかります。保守の難度も上がります。常時動かす構成では監視の体制が必要となり、障害が起きたときの影響範囲もバッチより広くなります。すべてをリアルタイムにするのではなく、その数字で判断する部門と基盤の設計者が、用途ごとに必要な鮮度を決めます。

 

💡STech I ワンポイントアドバイス

データが遅れている場合、原因が1か所とは限りません。業務システムへの記録、そこからの取り出し、変換、書き込み、画面の更新と、工程ごとに待ち時間があります。それぞれの工程で実際にどれだけかかっているかを測ってから、手を入れる工程を決めてください。取り出しだけを速くしても、業務システムへの記録が1日1回のままなら、全体の遅れは変わりません。

DBリプレイスから始める AI時代のデータ基盤設計（構想）DBリプレイスから始める AI時代のデータ基盤設計
無料の資料を読む▶

 

3. バッチとストリーミングを1つの基盤で扱う

以前は、バッチ処理とストリーミング処理を別々の技術で組む必要がありました。しかし現在のデータ基盤では、両方を同じしくみの上で扱えます。例として Databricks を取り上げます。

差分だけを処理する

Databricks には、追加されたデータだけを取り込んで処理するストリーミングテーブルというしくみがあります。全データを毎回読み直すバッチと比べて、読み込む量が大きく減り、処理の時間と費用も下がります。ただし集計の内容によっては過去の状態も参照するため、削減の幅は用途によって変わります。また、このしくみはデータが追加されていく形式を前提にしています。既存の行が更新されたり削除されたりする場合は、別の設計が必要です。

ファイルの到着を検知して取り込む

Databricks の Auto Loader は、クラウドのオブジェクトストレージ上に置かれたファイルを検知して取り込みます。個々のファイルを指定して取り込み処理を組む必要がなくなります。実際に処理が始まる時点は、ストリームが動いているかどうかと、ジョブの実行間隔で決まります。停止中に置かれたファイルは、次に起動したときに処理されます。ジョブの設定、実行のスケジュール、監視は引き続き必要です。Kafka などのメッセージキューからの取り込みは、Auto Loader ではなく別のコネクタを使います。

同じ処理をバッチとストリーミングで切り替える

Structured Streaming で書いた処理は、実行時のトリガー設定によって動きが変わります。開発者が Trigger.AvailableNow を指定すると、処理は起動した時点までに到着した未処理のデータを、1つ以上のまとまりに分けて処理し、停止します。processingTime を指定すると、指定した間隔ごとに処理を起動します。前の回が終わっていなければ、次の回はその終了を待ちます。なお Databricks のサーバーレスコンピュートでは processingTime を指定できません。通常のバッチ処理として書いたコードは、この切り替えの対象ではありません。

切り替えるときは、処理の状態を記録するチェックポイントの保存先を決めます。チェックポイントには、読み込み済みの位置、書き込み先へ確定した処理の記録、集計の途中経過が保存されます。書き込み先のデータそのものは管理しません。foreachBatch のように、同じデータが二度書き込まれる可能性のある方式を使う場合は、二度書き込んでも結果が変わらない書き方を別に設計します。

計算資源の確保

サーバーレスの構成を使うと、処理のたびに計算資源を用意する手間が減ります。利用には Unity Catalog の有効化などの条件があり、使える言語や機能にも制限があります。使った分だけの費用になるため、実行の頻度を変えたときに費用がどう動くかを見ながら調整できます。ただし、どの方式でどの頻度で動かすかは、計算資源の選び方とは別に設計します。

 

💡STech I ワンポイントアドバイス

最初からストリーミングで作る必要はありません。Structured Streaming として書いておけば、バッチで始めて、鮮度が問題になった用途から切り替えられます。トリガーの設定だけを変える場合は、同じチェックポイントから再開できます。入力元、出力先、集計の内容を変える場合は、新しいチェックポイントが必要になります。切り替える可能性のある処理だけを Structured Streaming で書き、残りは通常のバッチで書くのが現実的です。すべてを切り替え可能にすると、書き方の制約が全体に及びます。

 

4. よくある質問

Q.　自社のデータの鮮度が足りているかを、どう判断しますか。
その数字を見て決めている人に、決める間隔を聞くところからです。決める間隔よりデータの更新間隔が長ければ、鮮度が足りていません。全社を一度に調べる必要はなく、経営会議で使う数字と、日中に判断が動く業務の数字から確かめるのがよいでしょう。

Q.　リアルタイム化は、どの用途から始めますか。
投資の説明がつきやすいのは、遅れによって金額が動く用途です。不正検知のように、遅れた分だけ損失が出る用途は、金額で効果を示せます。在庫の引き当ては、遅れ以外の原因も絡むため、切り分けたうえで示します。レポートの表示を速くする用途は効果を金額で示しにくいため、社内の合意が得られる場合を除き、後の順番になります。

Q.　バッチのままで運用を続けると、何が起きますか。
用途によります。月次や週次で判断していて、締めの日までにデータが整う範囲であれば、支障は出ません。日中に何度も判断が動く業務では、判断の根拠が前日のままになり、担当者は自分の見立てで補うことになります。この状態が続くと、担当者はデータを開く前に自分の見立てで動くようになります。

 

5. まとめ

取引を止める判断のように、その場での即時性が求められるもの。在庫の引き当てのように、注文の受付間隔に間に合えばよいもの。月次レポートのように、締めの日までに整えばよいもの。それぞれに必要な鮮度を決め、その鮮度に合う処理方式を選びます。決めるのは基盤の設計者だけではなく、その数字で判断する部門も加わります。リアルタイムで処理するのは、このうち一部の用途だけです。

翌日のレポートで意思決定をしている現状に違和感があるなら、まず自社のデータパイプラインを棚卸しし、用途ごとに必要な鮮度を書き出してみてください。同じ処理をバッチとストリーミングで切り替えられる基盤を使えば、段階的に進めることができます。

DBリプレイスから始める AI時代のデータ基盤設計（構想）DBリプレイスから始める AI時代のデータ基盤設計
無料の資料を読む▶

 

6. 出典

  • Auto Loader が取り込むのは、クラウドのオブジェクトストレージ上のファイル。
  • 出典： Databricks の公式ドキュメント「Auto Loader」。
  • Trigger.AvailableNow は、起動した時点までに到着した未処理データを処理して停止する。
  • processingTime は、一定の間隔で処理を続ける。
  • 出典： Databricks の公式ドキュメント「Structured Streaming のトリガー間隔の設定」。
  • 処理の再開位置はチェックポイントが管理する。
  • 出典： Databricks の公式ドキュメント「Structured Streaming の本番環境に関する考慮事項」。
  • サーバーレスコンピュートで使えるトリガーは AvailableNow と Once のみ。
  • 出典： Databricks の公式ドキュメント「Structured Streaming のトリガー間隔の設定」。
  • foreachBatch の書き込み保証は at-least-once で、同じデータが二度書き込まれることがある。
  • 出典： Databricks の公式ドキュメント「foreachBatch を使用した任意のデータシンクへの書き込み」。

関連記事

この記事を書いた人

伊丹 優花
インフラ、Data＆AIのマーケティング担当