迪卡侬采用 Polars 优化数据管道与算力成本

迪卡侬（Decathlon）作为全球领先的体育用品零售商之一，近期分享了其采用开源库 Polars 来优化数据流水线的原因。迪卡侬数字团队发现，在处理小规模输入数据集时，从 Apache Spark 迁移到 Polars 能够带来显著的性能提升和成本节约。

迪卡侬的数据平台在云端集群上运行 PySpark 工作流，每个集群由 6 个 worker 组成，总计约 180 GiB 内存和 24 个 CPU 核心。数据以 Delta 表的形式存储在 AWS S3 数据湖中，并由 AWS Glue 作为技术元数据仓库。

该方案针对大规模数据任务进行了优化，但对于规模较小的数据集（GB 甚至 MB 级）而言并不理想。迪卡侬数据工程技术负责人 Arnaud Vennin 写道：

对于数据部门的数据工程师来说，主要工具是 Apache Spark，它非常擅长处理 TB 级别的数据。然而，事实证明，并不是每一个工作流的输入数据都有 TB 级，有些只有 GB，甚至只有 MB。

该平台采用奖牌式（Medallion）架构（青铜、白银、黄金、洞察层），用于对数据进行逐层加工和组织，以满足数据质量与治理要求。工作流通过 AWS 上的托管 Apache Airflow 服务 MWAA 进行编排，CI/CD 则通过 GitHub Actions 实现，用于代码测试和部署。

数据团队开始在轻量或中等规模的工作负载中尝试使用 Polars，最初是为了替代在扩展性方面遇到瓶颈的 pandas 等工具。Polars 是一个用于数据处理的开源库，核心是用 Rust 实现的 OLAP 查询引擎，并以 Apache Arrow 列式格式作为内存模型。

迪卡侬在 Polars 上运行的数据平台架构。图源：迪卡侬数字博文

由于 Polars 的语法与 Spark 相近，团队决定将一个 Spark 作业迁移到 Polars，起点是一个约 50 GiB 的 Parquet 表，相当于至少 100 GiB 的 CSV 数据。将作业从云端 Spark 集群迁移到单节点的 Kubernetes Pod 后，计算资源的启动时间从 8 分钟缩短到了 2 分钟。

在启用 Polars 新推出的流式执行引擎后，效果更加明显。该引擎允许处理规模超过可用内存的数据集。迪卡侬表示，在单个 Kubernetes Pod 上，过去需要大型集群才能完成的作业，现在只需较少的 CPU 和内存即可高效运行，而且往往在完整 Spark 集群完成冷启动之前就已经执行完毕。

图源：迪卡侬博客

施耐德电气（Schneider Electric）首席架构师 Eric Cheminot 对此提出质疑：

这更像是一个信号，说明把这些作业部署在 Spark 集群上本身就不是一个好的选择。不过……我们看到这种情况出现得太频繁了，已经具有代表性。

基于这些实验结果，团队决定在满足以下条件的新流水线中统一使用 Polars：输入表小于 50 GiB、数据规模随时间变化稳定，且不涉及多表连接、大量聚合或复杂函数。Vennin 也同时提醒了一些需要注意的问题：

在 Kubernetes 上运行 Polars 也带来了一些挑战。它为技术栈引入了新的工具，团队需要学习如何运行容器化服务；这也可能放慢不同团队之间的数据流水线协作。此外，Kubernetes 需要由 Data Ops 团队进行管理，并且涉及特定的安全策略，这些因素都会影响 Polars 在迪卡侬内部的推广方式。

Michel Hua 也表示认同：

Polars 采用了与 Spark 兼容的语法，这让代码迁移变得更容易。真正的痛点主要在于管理 RDD 和集群本身。

针对外界对“为什么不将 Polars 扩展到更多作业”的疑问，Vennin 指出其目前还存在的一些额外限制，例如 Polars 无法读取使用 Liquid Clustering 或 Column Mapping 特性写入的数据集。

原文链接：

https://www.infoq.com/news/2025/12/decathlon-spark-polars/