Databricks 宣布为 Apache Spark™ Structured Streaming 推出按需状态重分区功能
内容提要
Databricks Runtime 18 推出按需状态重分区功能，允许有状态流查询在不丢失检查点状态的情况下调整分区数。此前分区数在创建检查点时固定，修改无效，只能重建状态。新功能通过停止、设置 spark.sql.streaming.stateStore.partitions 并重启，安全地重新分配状态，适用于聚合、连接、去重等场景，Coveo 借此将 S3 API 成本降低 40%。
延伸解读
为什么分区数曾经无法更改
有状态流查询的状态存储在检查点中，每个键通过哈希映射到特定分区，分区数决定了整个状态存储的磁盘布局。如果直接修改分区数，键的哈希位置会改变，但累积状态仍留在原分区文件中，导致查询丢失状态。因此，Structured Streaming 将分区数锁定在检查点创建时，并忽略后续对 spark.sql.shuffle.partitions 的修改，以避免静默损坏。
新机制如何安全迁移状态
按需状态重分区通过物理重新分配状态来匹配新分区数。操作时需停止查询，设置 spark.sql.streaming.stateStore.partitions，然后使用相同检查点重启。重启后，查询先完成最后一个待处理的微批次，然后执行一次性重分区，将状态数据重新哈希到正确的新分区，完成后恢复处理。该配置优先于 spark.sql.shuffle.partitions，确保更改生效。
适用场景与操作建议
该功能适用于聚合、流-流连接、去重、会话化或 transformWithState 等有状态查询，以及欺诈检测、实时监控等工作负载。由于每次调整都需要停止和重启，并伴随一次性重分区暂停，应将其视为计划内的维护操作，在可接受短暂处理暂停的窗口执行。可通过 StreamingQueryProgress 中的 controlBatch.REPARTITION 指标查看重分区耗时，大多数工作负载预计只需几秒。
实际收益与限制
早期采用者 Coveo 利用该功能将相关 Amazon S3 API 成本降低了 40%，此前他们不得不在过度配置和重建检查点之间权衡。该功能在 Databricks Runtime 18 及以上版本中提供公共预览，要求使用 RocksDB 状态存储提供程序。它解决了长期运行流查询无法动态调整分区数的痛点，但并非例行操作，需权衡暂停成本。
Q&A
Databricks 的按需状态重分区功能是什么？
按需状态重分区是 Databricks Runtime 18 及以上版本提供的一项功能，允许有状态流查询在不丢失检查点状态的情况下调整分区数。它通过停止查询、设置 spark.sql.streaming.stateStore.partitions 并重启，安全地重新分配状态，适用于聚合、连接、去重等场景。
为什么有状态流查询的分区数在创建检查点后无法更改？
因为状态存储是物理分区的，每个键通过哈希映射到特定分区，数据存储在检查点内独立的 RocksDB 实例中。分区数定义了状态存储的磁盘布局。如果更改分区数，哈希映射会错位，导致键的累积状态留在原分区，查询会丢失状态，造成静默损坏。因此，Structured Streaming 在创建检查点时锁定分区数，并忽略后续对 spark.sql.shuffle.partitions 的更改。
如何使用按需状态重分区功能？
使用步骤：停止查询，设置 spark.sql.streaming.stateStore.partitions 为所需分区数，然后使用相同的检查点重启查询。重启后，查询会完成最后一个微批处理，执行一次性的状态重分区操作，将状态数据重新分布到新分区数，然后继续处理。注意：对于有状态查询，spark.sql.streaming.stateStore.partitions 优先于 spark.sql.shuffle.partitions。
按需状态重分区功能有哪些使用限制或注意事项？
该功能需要 Databricks Runtime 18 及以上版本，并使用 RocksDB 状态存储提供程序。重分区操作需要停止和重启查询，并有一次性的重分区暂停，其持续时间与状态大小成正比。因此，它应被视为一种有意的维护操作，建议在可接受短暂处理暂停的时间窗口内进行。
按需状态重分区功能适用于哪些场景？
适用于任何有状态流查询，包括聚合、流-流连接、去重、会话化或 transformWithState，以及任何工作负载，如欺诈检测、实时监控等。特别适用于需要调整分区数以适应数据量变化、优化资源使用的场景。
Coveo 使用按需状态重分区功能取得了什么效果？
Coveo 通过该功能将其相关的 Amazon S3 API 成本降低了 40%。他们运行大规模有状态流管道，数据量波动大。以前，每次扩展决策都面临权衡：要么过度配置，要么从新检查点重建，导致存储 API 成本几乎与计算成本相当。现在，他们可以随着需求变化自由扩展，而不会中断现有状态或触发昂贵的检查点迁移。
