Guides
Great Expectations

Great Expectations: первый checkpoint за 15 минут

Быстрый старт с Great Expectations: data context, expectation suite, checkpoint. Запуск через CLI vs Python API. Куда со

Всем привет. Если вы устали от ручных проверок данных и хотите наконец-то автоматизировать валидацию пайплайнов, но боитесь, что внедрение займёт недели — этот гайд для вас. Great Expectations (GX) — это не монстр, а инструмент, который можно завести за 15 минут и сразу получить работающий checkpoint. Я покажу самый короткий путь от нуля до первого отчёта, минуя слои абстракции, которые часто сбивают с толку.

Установка и инициализация контекста

Начнём с чистого виртуального окружения. Установите пакет и создайте Data Context — центральный хаб для управления всеми компонентами GX.

pip install great_expectations

Теперь инициализируем проект. Это создаст директорию great_expectations со всей необходимой структурой.

great_expectations init

Создаём Expectation Suite

Expectation Suite — это набор правил (assert-ов) для ваших данных. Мы создадим простой набор через CLI, используя встроенный помощник (профилер). Для примера будем проверять CSV-файл.

great_expectations suite new

Выберите опцию “Create a new Expectation Suite manually”. Назовите suite, например, my_data_suite. Далее вам предложат добавить Expectations. Нажмём “Yes” и выберем “Pandas” в качестве обработчика. Укажите путь к вашему тестовому CSV-файлу. После загрузки данных откроется Jupyter ноутбук. В нём можно интерактивно исследовать данные и добавлять правила. Для быстрого старта просто выполните все ячейки по порядку и сохраните suite. Профилер предложит базовые правила на основе статистики вашего файла.

Настраиваем Checkpoint

Checkpoint — это исполняемый объект, который связывает данные, набор правил (suite) и действие (например, генерацию отчёта). Создадим его через CLI:

great_expectations checkpoint new my_first_checkpoint

В открывшемся ноутбуке сконфигурируем checkpoint. Ключевой блок — config:

yaml_config = f"""
name: my_first_checkpoint
config_version: 1.0
class_name: SimpleCheckpoint
validations:
  - batch_request:
      datasource_name: my_datasource
      data_connector_name: default_inferred_data_connector_name
      data_asset_name: your_data_file.csv
      data_connector_query:
        index: -1
    expectation_suite_name: my_data_suite
"""

Запустите все ячейки ноутбука, чтобы checkpoint зарегистрировался в контексте.

Запуск: CLI против Python API

Теперь checkpoint можно запустить двумя способами. Через CLI — это удобно для ad-hoc проверок или шедулеров вроде cron/Airflow:

great_expectations checkpoint run my_first_checkpoint

Через Python API — это идеально для встраивания в ваши пайплайны (например, внутри Spark- или Airflow-DAG):

import great_expectations as gx

context = gx.get_context()
checkpoint = context.checkpoints.get("my_first_checkpoint")
results = checkpoint.run()
# Дальше ваша логика, например, если not results["success"]: raise ...

Разница в подходе: CLI команды используют конфигурацию из вашей директории great_expectations/, а при работе через API вы можете динамически создавать batch_request и передавать параметры.

Куда всё сохраняется и как смотреть Data Docs

Все результаты прогона (Validation Results) сохраняются в сторе по умолчанию — локально в great_expectations/uncommitted/validations/. Это JSON-файлы с детальной информацией по каждому правилу.

Самая мощная фича GX — автоматически генерируемые Data Docs. Это статический сайт с отчётами. После каждого запуска checkpoint обновите docs:

great_expectations docs build

Запустите локальный веб-сервер для просмотра:

great_expectations docs view

Откроется браузер с интерактивным обзором всех проверок: что прошло, что упало, какие были значения. Это ваш единый источник правды о качестве данных.

Типичные грабли

  1. Пути к данным. При использовании относительных путей в batch_request убедитесь, что рабочий директорий при запуске — правильный. Лучше сразу настраивать data connector на абсолютные пути или переменные окружения.
  2. Версионность данных. GX по умолчанию не версионирует сами данные, только результаты проверок и конфиги. Интегрируйте его в пайплайн после шага фиксации данных (например, после записи в S3-бакет с версиями).
  3. Первый запуск Data Docs может не показать свежий результат, если не выполнить docs build. Запомните: checkpoint -> validation, docs build -> генерация HTML, docs view -> просмотр.

Всё готово. Вы потратили 15 минут, чтобы получить автоматическую валидацию данных с веб-интерфейсом. Дальше можно углубляться: подключать разные datasource (Snowflake, BigQuery), писать кастомные expectations и настраивать оповещения в Slack. Но первый и самый важный шаг уже сделан.