📣 Copy-on-Write (CoW) – новая логика работы с данными, которая будет включена по умолчанию в Pandas 3.0.

Её идея:

Когда ты делаешь какую-то выборку (slice) из большого DataFrame, Pandas сначала создаёт не полную копию данных, а специальное представление (view), которое ссылается на исходные данные.

Но как только ты пытаешься изменить этот кусок, Pandas тут же создаёт копию автоматически, чтобы твои изменения не задели исходную таблицу.

Таким образом, Copy-on-Write позволяет:
- Избавиться от предупреждений SettingWithCopy.

- Избежать неожиданных ошибок, связанных с изменением данных.

- Экономить память и ускорять работу (копии данных создаются только тогда, когда реально нужно что-то поменять).

Пример работы с Copy-on-Write
Допустим, у нас есть DataFrame:

import pandas as pd
pd.options.mode.copy_on_write = True  # включаем CoW явно (в Pandas 3.0 это по умолчанию)

df = pd.DataFrame({"A": [1, 2, 3]})
df_slice = df[df["A"] > 1]  # это сейчас просто view (представление)

Если сейчас изменить df_slice:

df_slice.loc[:, "A"] = 999

то Pandas создаст копию автоматически. Исходный df не изменится, а предупреждения тоже не будет.

Что нужно запомнить?
- SettingWithCopy — предупреждение, что Pandas не уверен, копия у тебя или ссылка на оригинал.

- Copy-on-Write — автоматическое создание копий при изменении, которое решает эту проблему полностью.

В Pandas 3.0 Copy-on-Write становится стандартным поведением, избавляя тебя от головной боли с SettingWithCopy 🔥

⚡️Если вам нужно быстро создавать новые колонки из выражений и ускорить вычисления, попробуте 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. Ответственный джоин = достоверные результаты 👍