🐍 Python для анализа данных

Короткий ответ Выбор между глобальным средним/медианой, групповым средним (например, по сегменту) и модельной импутацией зависит от того, насколько пропуск связан с другими признаками: более сложные методы точнее, но требуют больше данных и прозрачности для интерпретации. Как это работает подробнее глобальное среднее/медиана заполняет все пропуски одним и тем же значением, игнорируя контекст; групповое среднее (df.groupby('segment')['x'].transform('mean')) учитывает, что разные сегменты могут иметь разный типичный уровень метрики; модельная импутация (например, регрессия по другим признакам) пытается предсказать пропущенное значение на основе взаимосвязей в данных. Пример кода Что использовать на практике Практика. групповое среднее — хороший баланс между простотой и точностью, когда есть явный сегмент, объясняющий часть вариации; модельная импутация оправдана при значимой доле пропусков и достаточном объёме данных для обучения, но добавляет сложность и риск переобучения или скрытой утечки целевой переменной.

Читать полностьюdata-quality

Короткий ответ IQR и перцентильные границы устойчивы к асимметричным распределениям и не требуют предположения о нормальности, а z-score основан на среднем и стандартном отклонении и чувствителен к самим выбросам, которые искажают эти оценки. Как это работает подробнее IQR-метод использует Q1/Q3 и не зависит от формы распределения; перцентильный метод (например, отрезать значения ниже 1-го и выше 99-го перцентиля) задаёт фиксированную долю "крайних" значений независимо от их абсолютной величины; z-score = (x − mean) / std, и чем больше |z|, тем дальше значение от среднего в единицах стандартного отклонения, но сам std может быть "раздут" выбросами. Пример кода Что использовать на практике Практика. для сильно скошенных метрик (выручка, время на сайте) предпочтительнее IQR или перцентили, так как z-score на таких распределениях будет либо пропускать реальные выбросы, либо помечать нормальные большие значения как аномалии; выбор метода и порогов — это допущение, которое всегда стоит явно проговаривать, а не счи

Читать полностьюiqr

Короткий ответ Типичные приёмы — предварительно отсортировать или проиндексировать данные по ключу объединения/группировки, уменьшить типы данных (category, меньшая разрядность чисел), отфильтровать и выбрать только нужные столбцы до тяжёлой операции, и избегать повторных merge/groupby там, где можно объединить логику в один проход. Как это работает подробнее merge и groupby внутри используют хеширование или сортировку по ключу; если ключ имеет тип object (строка) вместо category или числового типа, сравнение и хеширование происходит медленнее; выбор только нужных столбцов (usecols при чтении, или df[['a','b']] до операции) снижает объём данных, которые нужно переставлять в памяти. Пример кода Что использовать на практике На практике. перед тяжёлым merge полезно сначала отфильтровать обе таблицы до нужного подмножества строк (например, только за нужный период), а не объединять всё и фильтровать потом; для повторяющихся по одному и тому же ключу группировок стоит задуматься об установке ключа как индекса (set_

Читать полностьюgroupby

Короткий ответ float64 хранит числа в двоичном формате с конечной точностью, поэтому суммирование большого количества денежных значений может давать крошечные расхождения (например, 0.1 + 0.2 ≠ 0.3 точно), которые накапливаются при множестве операций и могут привести к заметным отклонениям в финансовой отчётности. Как это работает подробнее десятичные дробные числа вроде 0.1 не имеют точного представления в двоичной системе, поэтому при хранении в float64 они округляются до ближайшего представимого значения; при суммировании миллионов таких значений ошибки округления накапливаются, и итоговая сумма может немного отличаться от "точной" математической суммы. Пример кода Что использовать на практике На практике. для большинства аналитических отчётов такая погрешность пренебрежимо мала и не влияет на выводы, но для финансовой отчётности, где суммы должны сверяться до копейки с бухгалтерскими системами, стоит либо работать в минимальных неделимых единицах (копейки/центы как целые числа), либо использовать Decimal

Читать полностьюaggregation

Короткий ответ dropna() уместен, когда пропусков мало и они распределены случайно относительно анализа; если пропусков много или они связаны с конкретным сегментом, удаление строк может сильно искажать выборку. Как это работает подробнее dropna() по умолчанию удаляет строку, если хотя бы в одном столбце есть NaN (how='any'); параметр subset ограничивает проверку конкретными столбцами, а how='all' удаляет строку только если все значения пропущены. Пример кода Что использовать на практике На практике: перед удалением стоит посчитать, какую долю строк это затронет, и проверить, не концентрируются ли пропуски в конкретном сегменте (например, в одной стране или у новых пользователей) — тогда удаление введёт систематическое смещение, а не просто уменьшит шум. Проверка: до удаления 4 строки, после — 2; если удалённые строки относятся к конкретному сегменту (например, все без страны оказались новыми пользователями), стоит явно отметить это ограничение в выводах. Подводные камни Частые ошибки: удаляют все строки с про

Читать полностьюdropna

Короткий ответ Нужно построить ежедневный ряд метрики вместе со вспомогательными показателями (например, долей пропусков, количеством событий по источнику) вокруг подозрительной даты и проверить, совпадает ли разрыв с резким изменением структуры данных, а не только самого значения метрики. Как это работает подробнее строят df.set_index('date').resample('D').agg(...) для получения дневного ряда метрики и сопутствующих характеристик (доля пропусков в ключевых полях, число записей по платформе/источнику); резкий "излом" ровно в день релиза или смены трекинга — сильный сигнал технической причины, а не органического изменения поведения пользователей. Пример кода Что использовать на практике Практика. полезно сравнить структуру данных до и после даты излома — распределение по платформам, появление новых значений категориальных полей, изменение доли NaN в конкретном столбце; если на эту же дату приходится релиз приложения или смена версии API, это веский довод в пользу технической причины. Проверка. резкий рост even

Читать полностьюchange-point

Короткий ответ Если случайность используется в нескольких местах (разбиение на train/test, df.sample, перемешивание, инициализация модели), а зафиксирован seed только в одном из них, итоговый результат всё равно останется невоспроизводимым, потому что остальные источники случайности будут меняться от запуска к запуску. Как это работает подробнее каждый генератор случайных чисел (встроенный random, numpy.random, random_state внутри функций pandas/sklearn) может иметь собственное внутреннее состояние; фиксация seed в одном месте не влияет на остальные, если они не связаны общим источником случайности или не получили свой собственный seed. Пример кода Что использовать на практике На практике. для надёжной воспроизводимости всего пайплайна стоит зафиксировать seed в самом начале скрипта для всех используемых библиотек случайности и передавать random_state явно в каждую функцию, где он поддерживается (train_test_split, sample, shuffle), а не полагаться на глобальный seed, который может быть "израсходован" предыдущ

Читать полностьюnumpy

Короткий ответ Полное совпадение всех столбцов строки — более строгое условие, чем совпадение бизнес-ключа (например, order_id); если в таблице несколько версий одного заказа с разными статусами, проверка полных дубликатов их не найдёт, и в итоге дашборд, считающий по order_id, и источник, считающий по строкам, дадут разные числа. Как это работает подробнее df.duplicated() без параметров сравнивает все столбцы, а df.duplicated(subset=['order_id']) — только указанный ключ; если каждая версия заказа отличается хотя бы одним полем (например, временной меткой обновления), полные дубликаты не обнаруживаются, хотя по бизнес-смыслу должна быть одна запись на заказ. Пример кода Что использовать на практике Практика. при расхождении дашборда и источника стоит первым шагом сравнить df['order_id'].nunique() с len(df) — если они не равны, источник содержит несколько строк на один бизнес-объект, и нужно явно решить, какую версию считать "актуальной" (например, keep='last' по дате обновления) до агрегации. Проверка. len(df

Читать полностьюbusiness-key

Короткий ответ apply вызывает функцию отдельно для каждого элемента или строки через интерпретатор Python, тогда как векторизованные операции (например, встроенная арифметика pandas/NumPy) выполняются скомпилированным кодом сразу над всем массивом, что обычно намного быстрее на больших данных. Как это работает подробнее векторизованные операции (df['a'] + df['b'], str.contains, np.where) написаны на C и обрабатывают весь столбец за один проход без накладных расходов на вызов функции Python для каждой строки; apply(lambda row: ..., axis=1) для каждой строки создаёт отдельный объект Series и вызывает Python-функцию, что существенно медленнее на больших таблицах. Пример кода Что использовать на практике Практика. apply оправдан, когда логику действительно нельзя выразить встроенными операциями — например, сложная условная логика, зависящая от нескольких столбцов одновременно нестандартным образом, или вызов внешней функции/API; для простых случаев обычно есть векторизованная альтернатива (np.where, np.select, st

Читать полностьюapply