Pandas и NumPy: основы

Векторизация: откуда берётся разрыв в тысячи раз

Миллион строк, две колонки, надо перемножить. Через df.apply(lambda row: row.a * row.b, axis=1) это 17.7 секунды. Через df.a * df.b - 0.005 секунды. Разница почти в четыре тысячи раз, и код при этом короче.

Причина не в магии. apply с axis=1 на каждой строке собирает отдельный объект Series, вызывает питоновскую функцию и интерпретирует её байткод - миллион раз подряд. Векторная операция уходит одним вызовом в скомпилированный код, который проходит по сплошному куску памяти и не отвлекается ни на что.

Отсюда простой детектор в чужом коде: ищи всё, что выполняется построчно. iterrows, itertuples, apply(axis=1), обычный for по индексу - это питон-цикл, как его ни назови. Заменяется арифметикой столбцов, np.where вместо if, масками вместо фильтрации в цикле, merge или map вместо поиска по словарю на каждой строке.

// Вторая быстрая победа - память. Колонка на миллион строк с тремя уникальными городами весит 77 мегабайт как строки и 1 мегабайт после astype('category'): вместо миллиона строковых объектов хранится словарь из трёх значений и миллион маленьких кодов. groupby по такой колонке тоже становится заметно быстрее.

векторизация

выразить вычисление как операцию над всем столбцом сразу, чтобы цикл выполнялся в скомпилированном коде, а не в питоне

loc, iloc и правка, которая исчезает

loc обращается по меткам индекса, iloc - по позициям. Различие, которое спрашивают почти всегда: срез loc включает правую границу, срез iloc - нет. loc['a':'c'] вернёт три элемента a, b и c, а iloc[0:3] вернёт элементы с номерами 0, 1 и 2. Смешивать метки и позиции в одном выражении нельзя.

Дальше - самая известная ловушка pandas. Код df[df.a > 1].b = 99 выглядит логично: отфильтровали строки, присвоили колонке значение. На деле df[df.a > 1] создаёт новый объект, присваивание правит его, объект тут же уничтожается, а исходный датафрейм остаётся нетронутым.

Раньше pandas хотя бы ругался предупреждением SettingWithCopyWarning. В свежих версиях с копированием при записи операция просто молча не делает ничего: ни исключения, ни предупреждения, данные не изменились. То есть баг стал тише, а не безопаснее.

// Правило гигиены закрывает вопрос навсегда: любая правка подмножества делается одним выражением через .loc - df.loc[df.a > 1, 'b'] = 99. Тогда вопрос «это была копия или окно в оригинал» тебя просто не касается.

цепочное индексирование

две операции подряд через квадратные скобки: сначала отфильтровали, потом присвоили. Между ними успевает родиться временный объект, в который и уходит правка

merge, groupby и заразный пропуск

merge - это SQL-джойн со всеми его ловушками, и главная называется размножением строк. Три строки слева, три справа, ключ повторяется в обеих таблицах - на выходе получается пять строк, а сумма колонки вырастает с 60 до 90. Ошибки нет, есть просто метрика, которая теперь врёт в полтора раза.

Страховка встроена в саму функцию: validate='m:1' роняет джойн с MergeError, если ключ справа не уникален. Уронить пайплайн на месте на порядок дешевле, чем через неделю выяснять, почему выручка в отчёте выше, чем в кассе.

У groupby три разных инструмента, и путать их дорого. agg даёт одно число на группу: из значений 1 и 3 в группе «a» и 10 в группе «b» получится [2, 10]. transform возвращает результат той же длины, что исходник: [2, 2, 10] - среднее группы, размноженное обратно в каждую её строку. Это готовая идиома для фичей вида «отклонение от среднего по категории». apply - последний резерв, он гибкий и медленный.

// NaN - это число с плавающей точкой, и он заразен: добавь один пропуск в колонку целых чисел, и вся колонка станет float. Плюс NaN не равен ничему, включая самого себя: сравнение df.col == np.nan всегда даёт False, пропуски ищут только через isna().

кардинальность джойна

сколько строк одной таблицы соответствует одной строке другой: один к одному, многие к одному, многие ко многим. Последнее и размножает строки

Как отвечать: «pandas-код тормозит на миллионах строк. Как ускоришь?»

Первым делом ищу скрытые питон-циклы: iterrows и apply с axis=1 - это цикл, как бы он ни выглядел. Переписываю на операции над столбцами, условную логику на np.where и маски, поиск по справочнику на merge. Обычно этого хватает: разрыв там в сотни и тысячи раз, а не в проценты. Дальше смотрю память - строковые колонки с малым числом уникальных значений перевожу в category, это кратно меньше памяти и быстрее groupby. Потом проверяю джойны на validate, потому что «медленно» часто означает «после merge данных стало в десять раз больше, чем должно быть». Если после всего этого всё ещё тесно, беру чанки или переезжаю на polars либо duckdb, но до этого доходит редко.

Порядок разбора: алгоритмическая причина, потом память, потом объём данных, и только последней - смена инструмента. Так рассуждает человек, который чинил чужие ноутбуки, а не читал бенчмарки.

На чём валят

• −iterrows и apply(axis=1) на миллионах строк - секунды превращаются в десятки минут на ровном месте.
• −Джойн с дублями в правом ключе: суммы «выросли», ошибки нет, validate поймал бы это сразу.
• −df[df.a > 0].b = 1 - правка временного объекта. В свежем pandas это происходит вообще без предупреждения.
• −df.col == np.nan всегда False: пропуски ищутся только через isna().
• −Забыть, что срез loc включает правую границу, и получить лишнюю строку в выборке.
• −Взять apply вместо transform и получить агрегат вместо колонки нужной длины.