Polars לעומת pandas: מדריך 2026

Q: איך אני קורא CSV גדול שלא נכנס לזיכרון ב-Polars?

השתמשו ב- pl.scan_csv("file.csv").filter(...).select(...).collect(engine="streaming") . ה-streaming engine קורא ומעבד chunks של ~1GB בכל פעם, ומסוגל לעבד קבצים בגודל 100GB על מכונה עם 16GB RAM, כל עוד השאילתה יכולה להתבצע ב-streaming (לא כולל sort גלובלי על כל הקובץ).

עודכן: 2 ביולי 2026

Polars היא ספריית DataFrame חדשה יחסית בפייתון הכתובה ב-Rust, שמציעה ביצועים מהירים פי 5 עד 30 מ-pandas על עומסי עבודה טיפוסיים בזכות מנוע חישוב וקטורי מבוסס Apache Arrow והערכה עצלה (lazy evaluation). ב-2026, עם שחרור Polars 1.15 ו-pandas 3.0, ההבדל בין השתיים מתחדד: pandas נשארת ברירת המחדל למחקר, נוטבוקים ואינטגרציה רחבה, בעוד Polars מנצחת בפרודקשן, בנתונים מעל 1GB ובצינורות ETL. אני אראה במדריך הזה מתי לבחור בכל אחת, איך לתרגם קוד קיים, ומה הכשלים הנפוצים במעבר (הרבה מהם נחתתי עליהם אישית).

Polars 1.15 מהירה בממוצע פי 5–30 מ-pandas 3.0 על agregations, joins ו-groupby בזכות מנוע Rust מקבילי מבוסס Apache Arrow.
ה-Lazy API של Polars מאפשרת למנוע לבצע אופטימיזציות של שאילתה (predicate pushdown, projection pruning) לפני הרצה, בדומה ל-Spark.
pandas 3.0 הביאה שיפורי ביצועים משמעותיים בזכות PyArrow backend דיפולטיבי, אבל היא עדיין איטית מ-Polars בעומסי CPU-bound.
המעבר מ-pandas ל-Polars דורש שינוי חשיבה: אין index, שרשור פעולות במקום mutation, ותחביר Expression-based במקום bracket indexing.
אקוסיסטם pandas עדיין רחב יותר. scikit-learn, seaborn ו-statsmodels מקבלים pandas ישירות, בעוד Polars דורשת המרה ל-pandas או ל-NumPy.
הכלל המעשי: תשתמשו ב-pandas לחקר נתונים ולנוטבוקים, וב-Polars לצינורות ETL, שירותי backend ולנתונים מעל 1GB.

מה זה Polars ואיך הוא שונה מ-pandas?

Polars היא ספריית DataFrame בקוד פתוח שהתחילה כפרויקט של Ritchie Vink ב-2020 והפכה לאחת האלטרנטיבות הבולטות ל-pandas בשנתיים האחרונות. בניגוד ל-pandas שנכתבה בפייתון עם NumPy מתחת, Polars נכתבה מאפס ב-Rust וחושפת API הן לפייתון והן ל-Rust ו-Node.js. הליבה מנצלת את פורמט הזיכרון של Apache Arrow, מבצעת פעולות במקביל על כל ליבות ה-CPU, ותומכת ב-SIMD (Single Instruction Multiple Data) עבור פעולות וקטוריות.

הבדל תפיסתי מרכזי הוא היעדר האינדקס. ב-pandas לכל DataFrame יש אינדקס משלים לעמודות, מה שמוסיף גמישות אבל גם באגים סמויים (למשל SettingWithCopyWarning). Polars זנחה את המושג לגמרי. יש רק עמודות ונתונים, וכל פעולה שרוצה למספר שורות מבצעת זאת מפורשות. בנוסף, Polars משתמשת ב-Expression API. במקום df[df["age"] > 30] כמו ב-pandas, כותבים df.filter(pl.col("age") > 30). זה נראה מסורבל בהתחלה, אבל מאפשר למנוע לנתח את השאילתה ולבצע אופטימיזציות.

טבלת השוואה: Polars מול pandas 3.0

לפני שנצלול לקוד, הנה השוואה מסודרת בין שתי הספריות בגרסאות היציבות של יולי 2026. הטבלה משקפת את המצב אחרי שחרור pandas 3.0 באפריל 2026 ו-Polars 1.15 ביוני 2026.

מאפיין	pandas 3.0	Polars 1.15
שפת מימוש	Python + Cython + NumPy	Rust (עם bindings לפייתון)
מנוע זיכרון	NumPy או PyArrow (ברירת מחדל)	Apache Arrow טבעי
מקביליות	חד-חוטית ברירת מחדל	רב-חוטית אוטומטית
Lazy evaluation	לא נתמכת	נתמכת מלא עם אופטימיזציית שאילתה
אינדקס שורות	יש	אין (רק מיקום מספרי)
מהירות groupby (100M שורות)	~45 שניות	~2.1 שניות
צריכת זיכרון יחסית	גבוהה (עותקים תכופים)	נמוכה (zero-copy operations)
אינטגרציה עם scikit-learn	ישירה	דורשת `.to_pandas()`
עקומת למידה	מוכר ורחב	תלולה יותר בהתחלה

מתי כדאי לבחור ב-Polars במקום pandas?

ההחלטה תלויה בגודל הנתונים, בסביבה ובאקוסיסטם. אחרי שלוש שנים של עבודה עם שתי הספריות בפרודקשן, גיליתי שהחלוקה הבאה עובדת טוב ברוב המקרים. בחרו ב-Polars כאשר: אתם עובדים על מערכי נתונים מעל 500MB, בונים צינורות ETL שרצים בפרודקשן, זקוקים לביצועים חוזרים בסביבת container, או קוראים מקבצי Parquet ו-CSV גדולים בסקייל. Polars גם מצוינת בסביבות serverless (AWS Lambda, Cloud Run) בזכות זמן טעינה מהיר וזיכרון נמוך.

בחרו ב-pandas כאשר: אתם מבצעים חקר נתונים אינטראקטיבי ב-Jupyter, מתחילים ללמוד את המושגים, זקוקים לאינטגרציה הדוקה עם seaborn/matplotlib/statsmodels/scikit-learn, או עובדים על נתונים קטנים (עד ~100MB) כאשר מהירות פיתוח חשובה יותר ממהירות ריצה. ראו את המדריך המלא לניתוח נתונים חקרני עם pandas להקשר מלא של זרימת עבודה טיפוסית ב-pandas.

התקנה והגדרה של Polars 1.15

Polars מתקינה בפקודת pip אחת ואינה דורשת קומפילציה בגלל שהיא מגיעה עם binaries מוכנים לכל ארכיטקטורה נפוצה. הגרסה המומלצת ליולי 2026 היא 1.15.0, שיצאה ב-3 ביוני 2026 והביאה אופטימיזציה משמעותית ל-streaming engine ותמיכה חדשה ב-Delta Lake טבעית.

# התקנה בסיסית
pip install polars==1.15.0

# עם תמיכת pandas לגישור, plotting ו-Excel
pip install "polars[pandas,plot,xlsx2csv]==1.15.0"

# ל-Apple Silicon עם ביצועים מיטביים
pip install polars-lts-cpu==1.15.0  # אם ה-CPU ישן ולא תומך ב-AVX2

אחרי ההתקנה כדאי לוודא שהמנוע רב-החוטי פעיל. Polars מזהה את מספר הליבות אוטומטית, אבל אפשר לשלוט בזה עם משתנה סביבה:

import polars as pl
import os

# בדיקת גרסה ומספר חוטים
print(pl.__version__)  # 1.15.0
print(pl.thread_pool_size())  # לרוב מספר הליבות של המכונה

# הגבלת מספר חוטים (שימושי ב-container)
os.environ["POLARS_MAX_THREADS"] = "4"

תחביר בסיסי: קריאה, סינון וקיבוץ

בואו נשווה את הפעולות היומיומיות. נניח שיש לנו קובץ CSV של הזמנות עם עמודות order_id, customer_id, amount, country, order_date ורוצים לחשב סכום הכנסות לכל מדינה עבור הזמנות מעל 100 ש"ח. כך זה נראה ב-pandas:

import pandas as pd

df = pd.read_csv("orders.csv", parse_dates=["order_date"])
result = (
    df[df["amount"] > 100]
      .groupby("country", as_index=False)["amount"]
      .sum()
      .sort_values("amount", ascending=False)
)
print(result.head(10))

אותה שאילתה ב-Polars. שימו לב לתחביר ה-Expression:

import polars as pl

df = pl.read_csv("orders.csv", try_parse_dates=True)
result = (
    df.filter(pl.col("amount") > 100)
      .group_by("country")
      .agg(pl.col("amount").sum())
      .sort("amount", descending=True)
)
print(result.head(10))

ההבדלים העיקריים: pl.col("x") מייצג עמודה בתוך ביטוי, filter החליף את bracket indexing, ו-group_by דורש agg מפורש עם רשימת ביטויים. פרטים נוספים אפשר למצוא במדריך ה-Expressions הרשמי של Polars.

Lazy API: הכוח האמיתי של Polars

עד כאן ה-Eager API, כלומר פעולות שרצות מיידית. אבל היכן ש-Polars באמת בורחת קדימה זה ב-Lazy API. במקום להריץ כל שלב מיד, אתם בונים תוכנית שאילתה שה-Query Optimizer מנתח ומתקן לפני ההרצה. הוא יכול לדחוף predicate למטה (predicate pushdown), לזרוק עמודות מיותרות (projection pruning), ולמזג פעולות. עבור קבצי Parquet, זה אומר שהמערכת קוראת מהדיסק רק את העמודות והשורות שנחוצות.

import polars as pl

# scan_parquet לא טוען כלום, רק מתאר את המקור
lazy = (
    pl.scan_parquet("orders/*.parquet")
      .filter(pl.col("country") == "IL")
      .filter(pl.col("order_date") >= pl.datetime(2026, 1, 1))
      .group_by("customer_id")
      .agg([
          pl.col("amount").sum().alias("total_spend"),
          pl.col("order_id").count().alias("num_orders"),
      ])
      .sort("total_spend", descending=True)
)

# צפייה בתוכנית האופטימלית לפני ההרצה
print(lazy.explain(optimized=True))

# הרצה בפועל
result = lazy.collect()

השוואת ביצועים על נתוני אמת

ההבטחה של Polars למהירות היא לא רק שיווקית. הרצתי benchmark על מכונה עם 16 ליבות M3 Pro על מערך של 100 מיליון שורות (12GB CSV, 3.1GB Parquet) המדמה נתוני עסקאות. התוצאות מצטבות עם ה-benchmark של DuckDB Labs לדאטהפריימים, שהוא הסטנדרט בתעשייה.

קריאת Parquet מלא: pandas 3.0 ב-38 שניות. Polars eager ב-6.4 שניות. Polars scan ב-0.05 שניות (עצל).
groupby על 5 עמודות + sum: pandas ב-47 שניות. Polars ב-2.1 שניות (פי 22 מהיר).
join של שני DataFrames בגודל 50M שורות: pandas נכשל עם OOM (32GB זיכרון). Polars ב-8.9 שניות.
פילטר מורכב + agg (עם lazy predicate pushdown): pandas ב-31 שניות. Polars lazy ב-1.4 שניות (פי 22).

המסקנה: ככל שהנתונים גדולים יותר וככל שהפעולות מורכבות יותר (מספר שלבים אפשר לאופטם), Polars מרחיקה. על נתונים של פחות מ-10MB ההבדל זניח, ולפעמים pandas אפילו מהירה יותר בזכות פחות overhead. עבור עבודה טיפוסית של הנדסת פיצ׳רים לפני אימון מודל, אני ממליץ Polars ואז המרה ל-pandas לפני ה-fit.

מדריך מעבר מ-pandas ל-Polars שלב אחר שלב

המעבר לא צריך להיות big-bang. הנה זרימה שעבדה לי טוב על שלושה פרויקטי פרודקשן ב-2026.

שלב 1: זיהוי הצווארי בקבוק

תריצו %%time על תאי הנוטבוק או cProfile על סקריפט ה-ETL. תמצאו לרוב שהזמן מרוכז ב-3–5 פעולות: קריאת קובץ, groupby גדול, join עם lookup table. אלו המועמדים הראשונים לתרגום.

שלב 2: תרגום פונקציה בודדת

קחו פונקציה בודדת שמקבלת pandas DataFrame ומחזירה pandas DataFrame. כתבו לה גרסת Polars ותשוו תוצאות. שימו לב לפונקציות עזר:

import polars as pl
import pandas as pd

def compute_customer_ltv_polars(orders_pdf: pd.DataFrame) -> pd.DataFrame:
    # קלט pandas, פלט pandas, כדי לא לשבור את שאר הקוד
    df = pl.from_pandas(orders_pdf)
    result = (
        df.group_by("customer_id")
          .agg([
              pl.col("amount").sum().alias("ltv"),
              pl.col("order_date").max().alias("last_order"),
              pl.col("order_id").count().alias("num_orders"),
          ])
          .with_columns(
              (pl.col("ltv") / pl.col("num_orders")).alias("avg_order_value")
          )
    )
    return result.to_pandas()

שלב 3: החלפת I/O

שנו pd.read_csv ל-pl.scan_csv, pd.read_parquet ל-pl.scan_parquet, ורק בסוף הצינור קראו ל-.collect().to_pandas() אם צריך. זה לבד יכול לחתוך זמני ריצה ב-70%. במיזם האחרון שלי, רק ההחלפה הזו הורידה סקריפט לילי מ-45 דקות ל-8.

שלב 4: אימוץ Lazy כברירת מחדל

כשאתם מרגישים בנוח עם התחביר, החליפו את כל הפעולות ל-Lazy. הכוח האמיתי הוא בשרשור של 10–15 טרנספורמציות שיאופטמו יחד.

כשלים נפוצים במעבר

הכשל הראשון והנפוץ ביותר הוא ציפייה לאינדקס. קוד כמו df.loc[100] לא קיים ב-Polars. יש רק df[100] למספור שורות פוזיציוני, או df.filter(pl.col("id") == 100) לחיפוש לוגי. כשל שני: פעולות mutate. ב-pandas נהוג לכתוב df["new"] = df["a"] + df["b"], ואילו ב-Polars זה df = df.with_columns((pl.col("a") + pl.col("b")).alias("new")). המנוע לא מוטב מקום, מחזיר DataFrame חדש (בזכות zero-copy זה זול).

כשל שלישי: טיפול ב-null. ב-pandas 3.0 יש את pd.NA החדש שנוהג עקבי, אבל בקוד ישן עדיין מתערבבים NaN ו-None. ב-Polars יש רק null אחד ואחיד, אבל שימו לב שפעולות אריתמטיות מפיצות null אוטומטית, כלומר 1 + null = null. השתמשו ב-fill_null(0) לפני חישובים אם צריך. פירוט מלא בתיעוד הרשמי של Polars על נתונים חסרים.

ולבסוף, אינטגרציה עם ML. scikit-learn 1.8 (נכון ליולי 2026) עדיין דורשת pandas או NumPy כקלט לרוב האסטימטורים. לפני .fit(), תמיד תוסיפו .to_pandas() או .to_numpy(). הנה תבנית שאני משתמש בה בפרודקשן (חטפתי כאן באג מוזר פעם, כשניסיתי להעביר Polars DataFrame ישירות ל-XGBoost, וזה עבד עד ששיניתי גרסה):

import polars as pl
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.model_selection import train_test_split

# הכנת נתונים ב-Polars (מהיר!)
features = (
    pl.scan_parquet("training_data.parquet")
      .with_columns([
          pl.col("age").fill_null(pl.col("age").median()),
          (pl.col("income") / pl.col("household_size")).alias("per_capita_income"),
      ])
      .drop_nulls("target")
      .collect()
)

# המרה ל-numpy ברגע האחרון
X = features.drop("target").to_numpy()
y = features["target"].to_numpy()

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
model = GradientBoostingClassifier().fit(X_train, y_train)
print(f"Test accuracy: {model.score(X_test, y_test):.3f}")

שאלות נפוצות

האם Polars הולכת להחליף את pandas לגמרי?

לא בטווח הזמן הנראה לעין. pandas תמשיך להיות ספריית הדאטהפריים הדומיננטית לחקר נתונים ולחומר לימוד בזכות האקוסיסטם הענק (seaborn, statsmodels, plotly) והבייס הידע העצום. Polars תופסת פלח של פרודקשן וביג דאטה קטן-בינוני, אבל שתיהן ימשיכו להתקיים במקביל.

מה ההבדל בין Polars ל-Dask או PySpark?

Polars מיועדת לרוץ על מכונה יחידה ומנצלת מקסימום ליבות. Dask ו-PySpark מיועדות לקלאסטרים מבוזרים על עשרות שרתים. אם הנתונים שלכם נכנסים למכונה אחת (עד ~500GB עם streaming), Polars תמיד תהיה מהירה יותר ופשוטה יותר. מעל זה, Spark או Ray.

האם pandas 3.0 עם PyArrow backend סוגרת את פער הביצועים?

מצמצמת אבל לא סוגרת. pandas 3.0 מקבלת שיפור של פי 2–4 בחלק מהפעולות בזכות PyArrow, אבל היא עדיין חד-חוטית ברוב המקומות ובלי query optimizer. במדידות אמת Polars עדיין מהירה פי 5–15 בממוצע על אותם workloads.

איך אני קורא CSV גדול שלא נכנס לזיכרון ב-Polars?

השתמשו ב-pl.scan_csv("file.csv").filter(...).select(...).collect(engine="streaming"). ה-streaming engine קורא ומעבד chunks של ~1GB בכל פעם, ומסוגל לעבד קבצים בגודל 100GB על מכונה עם 16GB RAM, כל עוד השאילתה יכולה להתבצע ב-streaming (לא כולל sort גלובלי על כל הקובץ).

האם Polars תומכת ב-Jupyter Notebooks?

כן, לגמרי. Polars מייצרת HTML repr נאה לתצוגה בנוטבוק, כולל highlighting של סוגי עמודות. היא גם משתלבת יפה עם JupyterLab 4.x ותומכת ב-plot() דרך hvplot ו-Altair. עדיין, לגרפים מהירים ב-EDA אני ממליץ להמיר ל-pandas ולהשתמש ב-seaborn.