⚡️Если вам нужно быстро создавать новые колонки из выражений и ускорить вычисления, попробуте eval():

df.eval('C = A + B', inplace=True)

# где: 
## A и B - уже существующие колонки, 
## C - новая (будет создана в df)  

Так Pandas «под капотом» обрабатывает выражение чуть эффективнее, а код получается более «чистым». Сложные операции из нескольких столбцов можно оформлять в одной строке, что удобно и наглядно.

🏎 Arrow-строки в Pandas: меньше памяти, больше скорости

Arrow-backend — это способ хранить текстовые столбцы (dtype="string[pyarrow]") не как массивы Python-объектов, а как колонки формата Apache Arrow. Физически данные лежат в двух компактных C-буферах (offset + values).

Почему стоит попробовать?
✔️ Ускорение кода
Типичная выгода — в 3–6 раз быстрее str.contains, str.len, groupby по строкам.

✔️ Уменьшение RAM
1 млн строк ≈ 35 МБ вместо 120 МБ — пригодится и в ноутбуке, и в продакшене 🔥

✔️ Безболезненный переход на pandas 3.x
С версии 3.0 Arrow-строки становятся дефолтом и PyArrow — обязательной зависимостью. Включив backend в 2.2, вы опередите миграцию.

✔️ Эффект сети
Чем больше инструментов вокруг (DuckDB, Polars, Spark) тоже живут на Arrow, тем дешевле становится сквозная обработка данных

Как попробовать (pandas 2.2)

import pandas as pd
pd.options.mode.string_storage = "pyarrow"   # глобально
df = pd.read_csv("sales.csv",
                 dtype_backend="pyarrow")    # или явно при чтении

Любое вновь созданное строковое поле сразу получит Arrow-dtype; существующее можно перевести через

df = df.convert_dtypes(dtype_backend="pyarrow")

Arrow-backend превращает строковые данные из «узкого места» в источник прироста производительности и совместимости. Если ваш пайплайн упирается в память, медленные str.* операции или сложную интеграцию с другими инструментами аналитики, попробуйте переключить хранение строк на Arrow — и скорее всего, назад возвращаться уже не захочется 🙂

🚩 Проверяйте джоины до того, как считать агрегаты

В аналитике обычно всё «ломается» не на groupby, а на этапе объединения данных. Если в джоине затерялись или продублировались строки, итоговые суммы и метрики окажутся недостоверными, а вы потратите часы на «дебаг → созвон → почта → hot‑fix». Один из классных способов проверять джоины - использовать параметр validate= в merge

out = orders.merge(users,
                   on="user_id",
                   how="left",
                   validate="one_to_one")   # «один‑к‑одному»

Если в orders внезапно окажется два заказа с одинаковым user_id, код упадёт здесь, а для вас это сразу сигнал, что объединение прошло не так как вы ожидали и надо перепроверить.

✨ Какие опасные ситуации поможет избежать:
1) Дубли в обеих таблицах
Симптомы: sum() или count() завышены в n раз.
Итог: ложные «росты» или «падения».

2) Потеря строк (left join)
Симптомы: метрики падают - DAU, выручка, ретеншн
Итог: закроете фичу, которая реально работает.

3) Лишние строки (outer)
Симптомы: объём данных растёт, процессы тормозят.
Итог: бюджет на вычисления взлетает.

Всегда задавайте validate= при merge. Ответственный джоин = достоверные результаты 👍