Databricks、Spark Structured Streaming向けにオンデマンドの状態再パーティション機能を追加
Databricksは、Structured Streamingクエリがチェックポイントを再構築せずにパーティション数を変更できるパブリックプレビュー機能を発表した。
ひとことで言うと
DatabricksはApache Spark Structured Streamingの状態管理について何を発表したのか。
Databricksはオンデマンドの状態再パーティション機能を発表した。これはDatabricks Runtime 18以上で利用できるパブリックプレビュー機能で、ステートフルなStructured Streamingクエリが新しい設定で再起動することでパーティション数を変更でき、チェックポイントの状態を失ったり再構築したりする必要がない。
要点
- Databricksは、Apache Spark Structured Streaming向けのオンデマンドの状態再パーティション機能を発表した。現在Databricks Runtime 18以上でパブリックプレビュー中である。
- この機能により、ユーザーは新設定のspark.sql.streaming.stateStore.partitionsを通じてステートフルなストリーミングクエリのパーティション数を変更できる。この設定は、ステートフルなクエリにおいてspark.sql.shuffle.partitionsより優先される。
- 従来、パーティション数はチェックポイント作成時点で固定されており、spark.sql.shuffle.partitionsを変更してもチェックポイントを破棄して蓄積された状態を失わない限り効果がなかった。
- Databricksによると、要件はDatabricks Runtime 18以上とRocksDBステートストアプロバイダーであり、後者はDBR 17.3以上ではデフォルトとなっている。
- Databricksによると、早期導入企業のCoveoはこの機能を利用した後、関連するAmazon S3 APIコストを40%削減した。これは発表に含まれたCoveoのアレクシス・シコワン氏の発言による。
Databricksは、Apache Spark Structured Streaming向けにオンデマンドの状態再パーティション機能を発表した。これはパブリックプレビュー機能で、エンジニアがチェックポイントを再構築したり蓄積された状態を失ったりすることなく、ステートフルなストリーミングクエリのパーティション数を変更できるようにするものだ。この機能はDatabricks Runtime 18以上で利用できる。
何が変わったのか
Databricksによると、ステートフルなストリーミングクエリは従来、チェックポイントが作成された時点でパーティション数が固定されていた。標準のspark.sql.shuffle.partitions設定を変更してクエリを再起動しても、パーティションのレイアウトはチェックポイントに組み込まれているため効果がなかった。Databricksによれば、これまで唯一の選択肢はチェックポイントを破棄して新たに作り直すことだったが、これは何百万ものアカウントにまたがる不正検知データや複数日にわたるセッションウィンドウなど、クエリが蓄積してきた状態をすべて失うことを意味していた。
Databricksは、オンデマンドの状態再パーティション機能によってこの制約がなくなると説明する。この機能は、集計、ストリーム間結合、重複排除、セッション化、transformWithStateのワークロードなど、あらゆるステートフルなストリーミングクエリに適用できる。
仕組み
Databricksによると、ユーザーは専用の設定であるspark.sql.streaming.stateStore.partitionsを設定し、クエリを再起動する。この設定は、ステートフルなクエリにおいてspark.sql.shuffle.partitionsより優先される。再起動時、クエリはまず保留中のマイクロバッチを完了させ、その後、状態データを新しいパーティション数に物理的に再配置し、キーを正しい場所に再ハッシュする1回限りの再パーティション処理を実行する。この処理が完了すると、クエリは新しいパーティション数のもとで処理を再開する。
Databricksによると、この機能を利用するための要件はDatabricks Runtime 18以上と、RocksDBステートストアプロバイダーであり、後者はDBR 17.3以上で新規作成されるクエリのデフォルトとなっている。
モニタリング
Databricksによると、再パーティション処理の所要時間は標準のStreamingQueryProgressイベントに表示され、具体的にはcontrolBatch.REPARTITIONというフィールド配下のdurationMsメトリクスに記録される。同社は、再パーティションにかかる時間は関連する状態量に比例するとしつつ、ほとんどのワークロードでは数秒程度で済むと見込んでいる。
挙げられた利用シナリオ
Databricksはこの機能について3つのシナリオを挙げている。1つ目はローンチ後のクエリのサイズ最適化で、小規模な試験導入向けに設定した初期パーティション数が、例えば不正スコアリングのストリームが1地域から多地域に拡大するといった成長にもはや対応しきれなくなった場合だ。2つ目は変化するワークロードへの調整で、例えば広告入札パイプラインが日中のトラフィック増加に合わせてパーティションを増やし、夜間には減らすといったケースだ。3つ目は過去データのバックフィルで、過去データの再処理を高速化するために一時的にパーティション数を増やし、定常トラフィックに戻ったら縮小するという使い方だ。
顧客事例
Databricksは、この機能の早期導入企業であるCoveoのシニアソフトウェア開発者、アレクシス・シコワン氏の発言を引用している。Coveoは変動の大きいデータ量を扱う大規模なステートフルストリーミングパイプラインを運用しており、この機能を利用することで関連するAmazon S3 APIコストを40%削減できたという。シコワン氏は、以前は過剰なプロビジョニングか新規チェックポイントからの再構築かの二択を迫られ、ストレージAPIコストが計算コストに近い水準まで膨らんでいたが、今では既存の状態を損なったりチェックポイントの移行を発生させたりすることなくスケールできるようになったと述べている。
出典:Databricksブログ「Announcing On-Demand State Repartitioning for Apache Spark™ Structured Streaming on Databricks」、2026年9月14日公開。
よくある質問
- オンデマンドの状態再パーティションとは何か。
- これはDatabricksが提供するパブリックプレビュー機能で、ステートフルなApache Spark Structured Streamingクエリがクエリを停止・再起動することでステートのパーティション数を変更できるようにするものであり、その際も既存のチェックポイントの状態はそのまま維持される。
- 利用するには何が必要か。
- Databricksによると、Databricks Runtime 18以上とRocksDBステートストアプロバイダーが必要であり、後者はDBR 17.3以上で新規作成されるクエリではすでにデフォルトとなっている。
- パーティション数はどのように変更するのか。
- Databricksによると、クエリを停止し、spark.sql.streaming.stateStore.partitions設定を新しい値に設定した上で、同じチェックポイントを使ってクエリを再起動する。その後、クエリは処理を再開する前に新しいパーティション数に合わせて状態を再配置する。
- 再パーティション処理はどのように監視できるのか。
- Databricksによると、StreamingQueryProgressイベントは、controlBatch.REPARTITIONフィールド配下のdurationMsメトリクスに処理の所要時間を報告する。