解决Spark中策略学习因数据量大导致的推理慢与分裂搜索不稳定问题。
Spark Policy Toolkit: Semantic Contracts and Scalable Execution for Policy Learning in Spark

- 用向量化执行和不收集数据的分裂搜索提升性能
- 在40节点集群上实现每秒723万行的处理速度
- 适合大规模机器学习系统开发者参考
Spark中自定义策略学习管道因两个耦合系统问题而失效:逐行执行Python导致推理不实用,驱动端候选集生成使分裂搜索在特征规模下变得脆弱。本文提出Spark Policy Toolkit,一个语义约束的系统工具包,支持在Spark中可扩展的策略学习。提供两个原生接口:通过mapInPandas和mapInArrow实现分区初始化的向量化推理,以及在计算节点上评分候选的无收集分裂搜索。两者均遵循统一的固定输入语义契约:相同行、特征顺序、处理词汇表、预处理清单和分裂边界必须保持每行得分向量、最优分裂决策及端到端学习策略输出一致。评估包含基线对比、后端一致性验证、分裂搜索扩展性测试、合成与Hillstrom数据集上的端到端策略保真度、缺失值压力测试、分区与顺序扰动实验、分位数边界敏感性分析及具体对抗性失败案例库。在40个worker的Databricks集群上,mapInArrow在1000万匹配行时达472万行/秒,5000万行时达723万行/秒;无收集分裂搜索在特征数F=10至F=1000间保持有效,支持12.4万候选行,驱动端收集方案被有意跳过。24种后端消融设置中,mapInArrow胜出18次,mapInPandas胜出6次,表明后端选择应依工作负载而定。一旦固定输入锁生效,六种重分区/合并/洗牌扰动均保持相同签名;未加锁时全部漂移。核心结论并非仅速度:吞吐量与无收集执行是让策略语义在Spark规模下依然成立的关键机制。
原文摘要 · Abstract (English)
Custom policy-learning pipelines in Spark fail for two coupled systems reasons: rowwise Python execution makes inference impractical, and driver-side candidate materialization makes split search fragile at feature scale. We present Spark Policy Toolkit, a semantics-governed systems toolkit for scalable policy learning in Spark. The toolkit provides two Spark-native primitives: partition-initialized vectorized inference through mapInPandas and mapInArrow, and collect-less split search that scores candidates on executors. Both primitives are governed by one fixed-input semantic contract: the same rows, feature order, treatment vocabulary, preprocessing manifest, and split boundaries must preserve per-row score vectors, best-split decisions, and end-to-end learned policy outputs. The evaluation combines practical baseline ladders, backend parity checks, measured split-search scale results, synthetic and Hillstrom end-to-end policy preservation, missingness stress, partition and order perturbation tests, quantile-boundary sensitivity, and a concrete adversarial failure catalog. On a 40-worker Databricks cluster, mapInArrow reaches 4.72M rows/s at 10M matched rows and 7.23M rows/s at 50M rows, while collect-less split search remains valid from F = 10 through F = 1000 with 124000 candidate rows, where the driver-collect baseline is intentionally skipped. Across 24 backend-ablation settings, mapInArrow wins 18 while mapInPandas wins 6, so the paper treats backend choice as workload-dependent rather than universal. Once the fixed-input lock is enforced, all six tested repartition/coalesce/shuffle perturbations preserve identical signatures; before lock, all six drift. The central result is not speed alone: throughput and collect-less execution are the mechanisms that let policy semantics survive at Spark scale.
Thank you to arXiv for use of its open access interoperability. PaperDance 不是 arXiv 官方产品;中文卡片由大模型生成,请以原文为准。