Great Expectations у 2026: Валідація Якості Даних та Питання на Співбесідах

Great Expectations (GX) є провідним open-source фреймворком для валідації якості даних у пайплайнах на Python. Версія 1.22, випущена у серпні 2026 року, закріплює зміни API, представлені в GX 1.0, та додає експериментальну підтримку Python 3.14, роблячи його критично важливим інструментом для дата-інженерів, які будують production-пайплайни.

Які Проблеми Вирішує Great Expectations у Пайплайнах Даних

Пайплайни даних виходять з ладу непомітно. Зміна схеми на стороні джерела, значення null там де його не повинно бути, формат дати що змінюється з ISO на Unix timestamp — ці проблеми часто потрапляють до дашбордів або ML-моделей до того як хтось їх помітить. Great Expectations ставиться до даних як до коду, застосовуючи твердження (що називаються Expectations), які автоматично запускаються в контрольних точках пайплайну.

Фреймворк інтегрується з Apache Airflow, Databricks, Snowflake та хмарними сервісами зберігання такими як AWS S3 та Azure Blob Storage. Кожна валідація генерує Data Docs — HTML-звіти, які можуть читати нетехнічні stakeholders.

Основні Концепції: Data Context, Data Sources та Expectations

GX 1.22 організовує валідацію навколо чотирьох компонентів: Data Context, Data Sources, Data Assets та Expectation Suites.

Data Context — це центральний об'єкт конфігурації. Він зберігає метадані для Data Sources, Expectation Suites, Checkpoints та історичних результатів валідації. У більшості проєктів єдина директорія gx/ містить YAML-файли конфігурації та згенеровані Data Docs.

Data Source представляє з'єднання з базою даних, сховищем даних або файловою системою. Data Asset — це логічна колекція записів у межах цього джерела, подібна до таблиці або набору результатів запиту.

# gx_setup.py
import great_expectations as gx

# Initialize or load an existing Data Context
context = gx.get_context()

# Add a Pandas Data Source for local files
data_source = context.data_sources.add_pandas("local_files")

# Define a Data Asset pointing to a specific CSV pattern
data_asset = data_source.add_csv_asset(
    name="user_events",
    filepath_or_buffer="data/user_events_*.csv"  # Glob pattern
)

Це налаштування дозволяє GX валідувати будь-який CSV-файл, що відповідає патерну user_events_*.csv у директорії data/.

Створення Expectation Suite для Валідації Колонок

Expectation Suite — це колекція тверджень щодо Data Asset. Кожна Expectation оголошує умову, яка повинна виконуватися для даних, наприклад "колонка user_id ніколи не повинна бути null" або "колонка age повинна містити значення від 0 до 120."

# build_suite.py
import great_expectations as gx

context = gx.get_context()

# Create or retrieve an Expectation Suite
suite = context.suites.add(
    gx.ExpectationSuite(name="user_events_suite")
)

# Add Expectations to the suite
suite.add_expectation(
    gx.expectations.ExpectColumnToExist(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="age",
        min_value=0,
        max_value=120
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToMatchRegex(
        column="email",
        regex=r"^[\w.-]+@[\w.-]+\.\w+$"
    )
)

# Save the suite to the Data Context
context.suites.save(suite)

GX 1.0+ використовує API на основі класів для Expectations. Старіший синтаксис на основі словників (expect_column_to_exist) залишається доступним, але підхід на основі класів забезпечує краще автодоповнення в IDE та типобезпеку.

Запуск Валідацій за Допомогою Checkpoints

Checkpoint об'єднує Data Asset, Expectation Suite та опціональні Actions, що запускаються коли валідація проходить або провалюється. Checkpoints є головною точкою входу для автоматичної валідації в production.

# run_checkpoint.py
import great_expectations as gx

context = gx.get_context()

# Create a Checkpoint
checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="user_events_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="validate_user_events",
                data=context.data_sources.get("local_files")
                    .get_asset("user_events")
                    .build_batch_request(),
                suite=context.suites.get("user_events_suite")
            )
        ],
        actions=[
            gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
        ]
    )
)

# Run the Checkpoint
result = checkpoint.run()

# Check overall success
if result.success:
    print("All validations passed")
else:
    print("Validation failures detected")
    for validation_result in result.run_results.values():
        for expectation_result in validation_result.results:
            if not expectation_result.success:
                print(f"  Failed: {expectation_result.expectation_config}")

Коли Checkpoint запускається, GX завантажує batch, застосовує кожну Expectation та оновлює Data Docs. Невдалі валідації можуть викликати Slack-сповіщення, PagerDuty-алерти або зупинку пайплайну залежно від налаштованих Actions.

Інтеграція GX з Apache Airflow DAGs

Більшість production-пайплайнів використовують оркестратор такий як Apache Airflow. GX надає офіційну інтеграцію з Airflow, яка обгортає виконання Checkpoint в оператор.

# dags/user_events_pipeline.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import great_expectations as gx

def validate_user_events():
    """Run GX Checkpoint for user events data."""
    context = gx.get_context(context_root_dir="/opt/airflow/gx")
    checkpoint = context.checkpoints.get("user_events_checkpoint")
    result = checkpoint.run()
    
    if not result.success:
        # Raise exception to fail the Airflow task
        raise ValueError("Data validation failed. Check Data Docs for details.")

with DAG(
    dag_id="user_events_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    
    validate_task = PythonOperator(
        task_id="validate_user_events",
        python_callable=validate_user_events
    )
    
    # Downstream tasks depend on validation passing
    # transform_task >> load_task

Розміщення валідації перед завданнями трансформації запобігає поширенню поганих даних downstream. Цей патерн, який іноді називають "shift-left testing", виявляє проблеми на етапі ingestion замість того щоб чекати завершення дорогих обчислювальних завдань.

Типові Питання на Співбесідах про Great Expectations

Співбесіди для дата-інженерів у 2026 році часто включають питання про інструменти якості даних. Нижче наведено питання, що з'являються на технічних співбесідах, разом з відповідями, які відрізняють досвідчених кандидатів від джуніорів.

"Як би ви реалізували перевірки якості даних у production-пайплайні?"

Сильні відповіді згадують вбудовування валідації як етапу пайплайну, а не як окремого дашборду. Конкретно:

• Валідація схеми на етапі ingestion виявляє структурні проблеми негайно, наприклад рядок там де очікувався integer
• Валідація бізнес-логіки перевіряє доменні обмеження такі як позитивні ціни та діапазони дат
• Автоматичні алерти повідомляють чергових інженерів коли валідація провалюється, запобігаючи тихому пошкодженню даних
• Тести dbt обробляють перевірки рівня трансформації тоді як GX обробляє валідацію ingestion та output

"Яка різниця між Expectation Suite та Checkpoint?"

Expectation Suite містить самі твердження: які колонки повинні існувати, які діапазони значень є прийнятними, які regex-патерни повинні збігатися. Він визначає що перевіряти.

Checkpoint визначає коли та як запускати ці перевірки. Він з'єднує конкретний Data Asset (дані для валідації), Expectation Suite (правила для застосування) та Actions (що відбувається після валідації).

"Як обробляти Expectations що різняться залежно від середовища?"

Production-дані часто мають інші характеристики ніж staging-дані. Два підходи:

1. Параметризовані Expectations: Використання змінних середовища або runtime-параметрів для налаштування порогів. Наприклад min_value=int(os.getenv("AGE_MIN", 0)).

2. Кілька Suites: Підтримка окремих suites для staging та production. Staging може дозволяти null в опціональних полях для тестування неповних потоків даних.

"Що відбувається коли Checkpoint провалюється в запланованому пайплайні?"

Checkpoint повертає CheckpointResult з success=False. Поведінка пайплайну залежить від того як оркестратор обробляє помилку:

• В Airflow кидання exception позначає завдання як невдале, блокуючи downstream-завдання
• В Databricks notebook може завершитись зі статусом помилки
• Actions приєднані до Checkpoint можуть надсилати Slack-повідомлення, створювати Jira-тікети або запускати процедури rollback

Власні Expectations для Доменно-Специфічної Валідації

GX включає понад 300 вбудованих Expectations, але доменно-специфічні правила часто вимагають власних реалізацій. Власна Expectation розширює базовий клас та реалізує логіку валідації.

# custom_expectations/expect_valid_iso_country_code.py
from great_expectations.expectations import Expectation
from great_expectations.core import ExpectationConfiguration
import pycountry

class ExpectValidIsoCountryCode(Expectation):
    """Expect column values to be valid ISO 3166-1 alpha-2 country codes."""
    
    column: str
    
    @classmethod
    def _prescriptive_template(cls) -> str:
        return "Column {column} values must be valid ISO country codes"
    
    def _validate(self, metrics, runtime_configuration=None, execution_engine=None):
        column_values = metrics.get("column_values")
        valid_codes = {c.alpha_2 for c in pycountry.countries}
        
        invalid_values = [
            v for v in column_values 
            if v is not None and v not in valid_codes
        ]
        
        return {
            "success": len(invalid_values) == 0,
            "result": {
                "observed_value": len(invalid_values),
                "unexpected_list": invalid_values[:10]  # Sample
            }
        }

Власні Expectations реєструються шляхом розміщення їх у директорії great_expectations/plugins/ або додавання модуля до plugins_directory в great_expectations.yml.

Data Docs: Комунікація Якості Stakeholders

Data Docs — це статичні HTML-сайти, згенеровані з результатів валідації. Кожен запуск створює сторінку, що показує які Expectations пройшли або провалились, з деталями drill-down щодо неочікуваних значень.

# Generate and open Data Docs
context = gx.get_context()
context.build_data_docs()
context.open_data_docs()  # Opens browser

Для production-систем Data Docs можуть хоститись на S3, GCS або Azure Blob Storage з відповідними контролями доступу. Платформа GX Cloud пропонує hosted Data Docs з функціями командної співпраці.

Міграція на GX 1.0: Ламаючі Зміни з 0.x

Команди що оновлюються з GX 0.x стикаються зі змінами API. Основні відмінності:

Офіційний посібник з міграції охоплює кожну зміну. Для великих кодових баз поступова міграція з використанням shims сумісності зменшує ризик.

Ключові Висновки для Якості Даних з GX 1.22

• Great Expectations 1.22 (серпень 2026) підтримує Python 3.10 до 3.13, з експериментальною підтримкою 3.14 через змінну середовища GX_PYTHON_EXPERIMENTAL
• Expectation Suites визначають що валідувати, Checkpoints визначають коли та як
• Вбудовування Checkpoints як етапів пайплайну в Airflow DAGs або Databricks notebooks дозволяє виявляти погані дані на етапі ingestion
• Власні Expectations обробляють доменно-специфічні правила які вбудовані Expectations не можуть охопити
• Data Docs надають зрозумілі для stakeholders HTML-звіти; їх слід хостити в хмарному сховищі для production-доступу
• Відповіді на співбесідах повинні наголошувати на якості даних як вбудованому етапі пайплайну, а не додатковому дашборді