Polars 2.0 预发布

今天，我们发布了 Polars 2.0 的第一个候选版本。确切的 2.0 版本将在接下来的几周内发布。我们的目标不是发布 Polars 2.0 的重大功能。事实上，我们希望这对您来说是一次无聊的经历。我们推出这个主要版本的原因是，我们可以摆脱过去做出的目前阻碍我们的设计决策，然后我们希望将默认值更改为更合理的设置，这将有利于更多的受众。最大的默认更改是所有 LazyFrame 查询现在都将在流引擎上运行。因此，Polars 休闲用户可以期待内存使用和性能方面的巨大改进。总的来说，我们预计流引擎的速度将轻松提高 5 倍。为了帮助用户过渡到 2.0，我们发布了完整的迁移指南。这篇文章将介绍一些亮点。默认流媒体引擎这是2.0影响最大的变化。现在，在 LazyFrame 上调用收集将默认使用流引擎，从而为用户的大多数查询带来大量内存和性能改进。这需要主要版本提升的原因是流引擎默认情况下不保证某些操作（ join 、 group_by 、 unpivot 等）的行顺序。如果您在这些操作中需要可观察的行顺序，则可以通过设置 Maintenance_order=True 来选择。对于想要继续默认使用“内存”引擎的用户，可以通过设置引擎亲和性来实现。 lf = pl 。 LazyFrame ({ "k" : [ 2 , 1 , 0 ], "v" : [ "a" , "b" , "c" ]}) other = pl 。 LazyFrame ({ "k" : [ 0 , 1 , 2 ], "r" : [ "x" , "y" , "z" ]}) # 2.0: engine="auto" 现在解析为流引擎。 # 不再保证 join、group_by、unpivot、... ( lf . join (other, on = "k" , how = "left" ) .collect () ) # ┌──────┬──────┬──────┐ # │ k ┆ v ┆ r │ <- 顺序可能与 `lf` 的原始行顺序不匹配 # └──────┴──────┴──────┘ # 选择此查询的可观察顺序: ( lf . join (other, on = "k" , how = "left" , Maintenance_order = "left" ) .collect () ) # 或者保留旧的内存引擎作为默认值，进程范围: pl .配置。 set_engine_affinity ( "in-memory" ) # ...或每个查询： ( lf . join (other, on = "k" , how = "left" ) .collect (engine = "in-memory" ) ) 更严格的 Polars Polars 的目标是严格并快速失败。理想情况下，错误应该提前出现，而不是在管道中出现 20 分钟后出现。数据不匹配的隐式行为应该是选择加入的，而不是默认的，因为这些不匹配可以隐藏错误。随着人工智能驱动开发的兴起，这种严格性变得更加有价值。代理可以通过调用collect_schema()来尽早验证查询的结构，它可以解析类型并捕获模式级不匹配，而无需具体化任何数据。这确保了代理的快速反馈，这意味着他们可以更快地迭代。并非所有错误都可以在查询计划编译期间捕获，有些错误取决于数据。在这些情况下，Polars 默认采取更严格的行为，以确保发现不一致之处，而不是默默地产生不同的结果。下面是 Polars 变得更加严格的几个示例： is_in 无损类型强制 如果您在不同的数据类型上运行 is_in 表达式，Polars 就会将两种类型转换为其共同的超类型，即使这种转换是有损的。 下面是一个用户 ID 的示例，该用户 ID 可能会因静默数据类型不匹配而出错。 # 检查用户 ID 是否与“标记”帐户 ID 列表匹配 # （从 JSON 导出加载的 flagged_ids，其中大 ID 变成浮点数） flagged_ids = pl .系列 ([ 9007199254740992.0 ]) user_id = pl 。 Series ([ 9007199254740993 ]) # Int64 -> 不同的 ID，减少 1 user_id 。 is_in (flaged_ids) 在 2.0 之前， user_id 被强制为 Float64 以匹配 flagged_ids 。但是 9007199254740993 位于 2^53 (9007199254740992) 之上，这是 float64 可以精确表示的最大整数，因此它会默默地向下舍入到 9007199254740992.0，从而给出误报。在 2.0 中，这会引发： InvalidOperationError: 'is_in' 无法检查 List(Float64) 数据中的 Int64 值。 ，用户应该显式强制转换来处理有损类型转换。严格串联 水平串联现在将检查长度，而不是默默地填充 null 。 # 将每日交易计数与每日欺诈标记计数连接起来，交易 = pl 。 DataFrame ({ "day" : [ 1 , 2 , 3 , 4 , 5 ], "count" : [ 120 , 98 , 143 , 87 , 156 ]}) # 第 5 天的上游作业静默失败frags = pl . DataFrame ({ "flaged" : [ 2 , 0 , 5 , 1 ]}) # 只有 4 行 pl . concat ([transactions,fragus_flags], how = "horizontal") 形状：(5, 2) ┌──────┬────────┬──────────┐ │ 天 ┆ 计数 ┆ 标记 │ │ 1 ┆ 120 ┆ 2 │ │ 2 ┆ 98 ┆ 0 │ │ 3 ┆ 143 ┆ 5 │ │ 4 ┆ 87 ┆ 1 │ │ 5 ┆ 156 ┆ null │ <- 第 5 天默默地没有标志计数 └──────┴────────┴──────────┘ 在 2.0 中，这将引发： ShapeError: 无法在 'strict' 中连接具有不同高度的数据帧如果填充是您想要的，则必须使用 how="horizontal_extend" 显式选择加入。向对方明确表达这一意图