Pandera или Great Expectations: проверка данных — это выбор места для правил качества. Pandera встраивает схему в Python-функцию и проверяет DataFrame на входе. GX Core описывает партии данных, связывает их с набором ожиданий и запускает проверку через Checkpoint. Оба инструмента отвечают на один вопрос: соответствует ли таблица заданным правилам.
Что проверяет каждый инструмент и где граница данных
Документация Pandera описывает библиотеку как API для проверки данных на объектах, похожих на DataFrame. Схема задаётся один раз и применяется к pandas, polars, dask, modin, ibis и pyspark. Граница проверки здесь — dataframe-подобный объект, переданный валидатору; способ вычисления и хранения зависит от выбранного backend. Вы получаете таблицу, объявляете типы колонок и проверки, вызываете validate. Результат — либо прошедший проверку DataFrame, либо исключение с описанием нарушений.
GX Core работает на другом уровне. Документация проекта описывает Data Context как среду, в которой определяется и запускается рабочий процесс GX. Внутри контекста вы описываете источник данных, актив, определение партии, набор ожиданий и определение проверки. Граница данных здесь — партия записей, организованная по правилу из Data Asset. Проверка может относиться к партии из файла, SQL-таблицы или Spark DataFrame.
Разница проявляется в том, что именно вы проверяете. Pandera проверяет структуру и содержимое таблицы, которая уже находится в вашем коде. GX Core проверяет партию, которую система умеет собрать из источника по описанию. Первый инструмент живёт внутри функции обработки. Второй живёт рядом с конвейером и хранит историю проверок.
Практическое следствие: Pandera отвечает на вопрос «правильная ли эта таблица прямо сейчас». GX Core отвечает на вопрос «правильные ли данные приходят из этого источника на регулярной основе». Оба ответа полезны, и они не заменяют друг друга.
Один контракт и пять заполненных строк
Возьмём единый контракт, который можно выразить в обоих инструментах. Правила: quantity — целое число не меньше 1; price — число не меньше 0 и без пропусков; currency — одно из значений RUB или EUR. Это условный учебный вход. Измерения продукта для него не проводились.
Пять строк для проверки:
| Строка | quantity | price | currency | Ожидаемый результат |
|---|---|---|---|---|
| r1 | 2 | 10 | RUB | PASS |
| r2 | 0 | 10 | RUB | FAIL quantity |
| r3 | 1 | −1 | EUR | FAIL price |
| r4 | 1 | 10 | USD | FAIL currency |
| r5 | 1 | null | RUB | FAIL price |
Смысл правил одинаков для обоих инструментов. Различается путь: как определяется партия, как получается результат и какое действие следует дальше. Одни и те же пять строк дают один и тот же список дефектов. r2 нарушает нижнюю границу quantity, r3 нарушает нижнюю границу price, r4 выходит за допустимый набор валют, r5 содержит пропуск в обязательной числовой колонке.
Этот пример отделяет смысл контракта от API. Когда правила сформулированы на бумаге, перенос в любой инструмент становится механической работой. Ошибка возникает, когда контракт держат только в голове и проверяют его фрагментами в разных местах кода.
Как Pandera представляет схему и lazy validation
Документация Pandera отмечает, что версия v0.24.0 вводит модуль pandera.pandas, который стал рекомендуемым способом определения DataFrameSchema и DataFrameModel для pandas-структур. Схема описывает колонки, типы и проверки. Проверки задаются объектами Check, которые принимают функцию и возвращают булево значение или серию булевых значений.
По умолчанию проверка идёт в режиме eager: выполнение останавливается на первой найденной проблеме. Документация Pandera описывает альтернативу: при lazy=True ошибки агрегируются в отчёт. В отчёте группируются ошибки DATA и SCHEMA, что даёт обзор источников проблем внутри таблицы. При ленивой проверке возникает исключение SchemaErrors с краткой сводкой количества ошибок и случаев нарушения.
При eager проверка останавливается на первом обнаруженном нарушении; его порядок зависит от схемы и данных. Для нашего контракта ожидаются дефекты r2, r3, r4 и r5; lazy=True позволяет собрать нарушения в одном отчёте. Отчёт группирует ошибки по источникам, поэтому нарушения типов и нарушения значений не смешиваются в один список.
Практический порядок работы со схемой Pandera:
- Определите колонки, типы и проверки в одном объекте DataFrameSchema.
- Вызовите validate с lazy=True, чтобы собрать все нарушения за один проход.
- Перехватите SchemaErrors и извлеките failure_cases в таблицу для разбора.
- Исправьте данные или уточните правила, если проверка оказалась слишком строгой.
Шаг с извлечением failure_cases важен для отладки. Документация Pandera показывает, как получить из исключения структурированные сведения о нарушениях. Это позволяет построить отчёт по дефектам и передать его дальше по конвейеру.
Как GX Core связывает Batch Definition, Expectation Suite и Validation Definition
Документация GX Core описывает цепочку понятий. Data Context — среда, в которой определяется и запускается рабочий процесс. Batch Definition сообщает GX, как организовать записи внутри Data Asset. Expectation Suite — это коллекция ожиданий. Validation Definition явно связывает Batch Definition с Expectation Suite и определяет, какие данные проверяются против каких ожиданий.
Цепочка читается так: Data Source описывает подключение к хранилищу, Data Asset задаёт коллекцию записей внутри источника, Batch Definition организует записи в партии, а Validation Definition связывает партию с набором ожиданий. Когда все четыре части описаны, проверка становится воспроизводимой операцией. Вы можете запустить её снова на новой партии из того же источника.
Для нашего контракта это означает: правила quantity, price и currency становятся ожиданиями внутри набора. Определение партии описывает, откуда берутся строки. Определение проверки соединяет конкретную партию с набором правил. Результат связывается с проверенной партией и выбранным набором правил.
Такое разделение полезно, когда правила должны пережить смену кода. Набор ожиданий хранится отдельно от функции обработки. Новая версия конвейера использует тот же набор правил. Определение проверки можно переиспользовать для разных партий из одного источника.
Checkpoint, Actions и Data Docs как другой процесс работы
Документация GX Core описывает Checkpoint так: он выполняет одно или несколько Validation Definitions, а затем совершает набор Actions на основе результатов, которые вернуло каждое определение проверки. Здесь появляется слой, которого нет в Pandera: результат проверки запускает действие.
Actions — это реакция на результат. Проверка прошла — можно продолжить конвейер. Проверка нашла нарушения — можно остановить загрузку, отправить уведомление или записать отчёт. Документация GX Core описывает настройку severity и уведомлений внутри Checkpoint.
Data Docs — это локальная веб-страница с результатами проверки набора ожиданий против партии данных. Историческая статья Endjin описывает Data Doc как HTML-файл, который показывает результаты прогона. В текущем GX Core Data Docs остаются частью рабочего процесса: они дают читаемый отчёт по партии.
Порядок работы в GX Core выглядит иначе, чем в Pandera:
- Создайте Data Context как среду проекта.
- Опишите источник данных и актив.
- Задайте Batch Definition — правило организации записей.
- Соберите Expectation Suite с правилами контракта.
- Свяжите партию и набор через Validation Definition.
- Настройте Checkpoint с Actions и запустите проверку.
- Откройте Data Docs и разберите результаты партии.
Этот процесс тяжелее на старте. Он окупается, когда проверка должна работать регулярно и оставлять след. Закрытый GX Cloud в этом сравнении не участвует: речь идёт о GX Core и его документированных понятиях.
Матрица трёх сценариев выбора
| Сценарий | Инструмент | Почему |
|---|---|---|
| Python-функция принимает DataFrame и должна отдать проверенную таблицу | Pandera | Схема встраивается прямо в границу функции, проверка идёт на объекте в памяти |
| Регулярные партии из внешнего источника с отчётами и действиями | GX Core | Определение партии, набор ожиданий, Checkpoint и Actions описывают полный цикл |
| Оба этапа в одном проекте | Совместная работа | Pandera проверяет таблицу внутри функции, GX Core проверяет партии на входе конвейера |
Первый сценарий типичен для обработки, где данные уже загружены и должны быть проверены перед расчётом. Схема Pandera стоит на границе функции и отсекает неправильные таблицы до того, как они попадут в логику.
Второй сценарий типичен для конвейеров, где данные приходят партиями из внешней системы. Здесь важны история проверок, отчёт по каждой партии и автоматическое действие при нарушениях. GX Core даёт эти части как готовые понятия.
Третий сценарий встречается, когда проект растёт. GX Core проверяет партии на входе, а Pandera проверяет таблицы внутри отдельных функций обработки. Автоматического победителя в таком сравнении нет: инструменты занимают разные места в одном процессе.
Версия старого сравнения и текущий API
Историческая статья Endjin о Pandera и Great Expectations датируется 2023 годом и обновлялась в 2026 году. Она остаётся полезным первым сравнением: в ней описан сценарий с данными о продажах лодок, показана схема Pandera с проверками in_range и isin, разобраны выводы о кривой обучения и интеграции.
Команды из этой статьи относятся к прежнему API Great Expectations. Материал описывает Data Context, Expectation Suite, Checkpoint и SimpleCheckpoint в терминах того времени. Текущая документация GX Core описывает Validation Definition как отдельное понятие, связывающее Batch Definition и Expectation Suite. Checkpoint выполняет определения проверки и запускает Actions.
Практическое правило: сверяйте API по текущей документации проекта. Старое сравнение читайте ради аргументов о кривой обучения и интеграции. Команды из него переносите только после проверки в актуальной документации. Это относится и к CLI, и к настройке Checkpoint, и к способам редактирования набора ожиданий.
Частые вопросы
Pandera и Great Expectations — что выбрать для начала?
Для быстрого старта с таблицей в Python подходит Pandera: схема описывается в коде рядом с функцией обработки. GX Core требует описать контекст, источник, партию и набор ожиданий. Историческая статья Endjin отмечает, что кривая обучения у Pandera пологая, а GX Core вводит собственные понятия и термины.
Чем отличается lazy validation в Pandera от обычной проверки?
Обычная проверка останавливается на первой найденной проблеме. При lazy=True ошибки агрегируются в отчёт, где группируются ошибки DATA и SCHEMA. Для пяти учебных строк это означает, что вы увидите все четыре дефекта за один проход.
Как GX Core связывает партию данных и правила?
Batch Definition описывает, как организовать записи внутри актива. Expectation Suite содержит правила. Validation Definition явно связывает партию с набором ожиданий. Checkpoint выполняет определения проверки и запускает Actions по результатам.
Можно ли применять оба инструмента в одном проекте?
Да. GX Core проверяет партии на входе конвейера и хранит историю результатов. Pandera проверяет таблицы внутри отдельных функций обработки. Инструменты занимают разные места в процессе, поэтому совместное применение имеет смысл при росте проекта.
Почему старые команды Great Expectations не работают?
Историческая статья Endjin описывает API прежней версии. Текущая документация GX Core вводит Validation Definition как отдельное понятие и описывает Checkpoint через выполнения определений проверки и Actions. Сверяйте команды по актуальной документации проекта перед переносом.