5 проверок данных перед анализом: что исследователю стоит позаимствовать у дата-инженера?

Дата-инженер (DE) по умолчанию не доверяет данным: источник изучают в начале работы с ним, а таблица попадает в отчёт только после тестов. У исследователя данные приходят от прибора, анкет, соавтора или репозитория, и многие проблемы качества повторяются. Пять проверок до детального анализа:
1. типы данных
2. количество строк
3. ключи и дубли
4. пропуски
5. допустимые значения и распределения

🔸 1. типы: данные прочитались так же, как лежат в источнике

Excel, pandas и R при чтении файла угадывают тип каждой колонки, и не всегда удачно. Известный случай из биоинформатики: Excel превращает название гена SEPT2 в дату 2-Sep. Ошибка встречалась так часто, что HGNC переименовал 27 генов человека, чтобы их названия не совпадали с датами.

Что делать:
• при чтении указывайте типы: dtype в pandas, col_types в readr
• ID и коды читайте как строки, иначе пропадут ведущие нули (007 → 7)
• проверьте десятичный разделитель и формат дат: 03.04 это 3 апреля или 4 марта?

🔸 2. объём: сколько строк пришло и сколько осталось

В пайплайнах считают количество строк на входе и выходе каждого шага и сверяют с источником. Так, из-за лимита в 65 536 строк в старом формате .xls часть тестов на COVID однажды молча отрезалась при выгрузке, и тысячи случаев не передали контактным трекерам вовремя.

Что делать:
• выпишите из протокола, сколько должно быть участников, образцов, измерений
• сверяйте это число после загрузки, каждого фильтра и каждого merge
• записывайте, сколько строк отброшено на каждом шаге и почему

🔸 3. ключи: одна строка, один участник

Перед работой с таблицей стоит понять её гранулярность: что описывает одна строка, участника, визит или замер. От этого зависит ключ уникальности строки и то, как таблицы соединяются между собой.

DE после каждого джоина проверяют количество строк и заполненность по ключевым полям, иначе можно наплодить дублей: у части людей несколько замеров, строк после соединения станет больше, чем участников, и расчёт по участникам даёт больший вес тем, у кого замеров больше.

Что делать:
• проверьте до merge, что ID уникален в каждой таблице
• укажите ожидаемую связь прямо в merge: validate="one_to_one" в pandas, relationship = "one-to-one" в dplyr
• ищите и полные, и неполные дубли, где совпадает только ключ

🔸 4. пропуски: NA бывает в десятке обличий

Классика у DE: select distinct по новому полю показывает '123', '456', 'None', '789'. Числа хранятся как текст, а вместо null строка None. В исследовательских данных вариантов больше: пустая строка, n/a, дефис, #N/A из Excel и коды-заглушки вроде 99 или -999.

Текстовые заглушки обычно ломают расчёт сразу. Числовые опаснее: 999 в шкале от 0 до 100 спокойно участвует в среднем и в регрессии, и даже указанный в описании датасета код пропуска большинство пропускает.

Что делать:
• замените все коды пропусков на NA до любых расчётов
• посчитайте долю пропусков по каждой колонке и отдельно по группам
• найдите колонки, заполненные только пропусками

🔸 5. значения и распределения: проверка здравого смысла

Финальный шаг в DE, sanity check: посчитать основные агрегаты и убедиться, что данные похожи на реальные. Пример: в исследовании о честности на данных страховой компании, где клиенты сами сообщали пробег автомобиля, пробег оказался распределён почти равномерно, без единого значения выше 50 000 миль. Данные признали сфабрикованными, статью отозвали.

Что делать:
• сравните min и max с физически возможными значениями: возраст, проценты, концентрации, даты из далёкого будущего или прошлого
• постройте гистограмму каждой ключевой переменной
• схлопывайте в одно значение одинаковые по смыслу категории: Male, male и M в male
• после перекодировки постройте кросс-таблицу старой и новой переменной

Все эти проверки можно оформить кодом: в Python есть pandera и pointblank, в R пакеты validate и pointblank.

Больше про инжиниринг данных в канале @rzv_de