Great Expectations w 2026: Walidacja Jakości Danych i Pytania Rekrutacyjne

Great Expectations (GX) stanowi wiodący framework open-source do walidacji jakości danych w potokach przetwarzania opartych na Pythonie. Wersja 1.22, wydana w sierpniu 2026, utrwala zmiany API wprowadzone w GX 1.0 i dodaje eksperymentalne wsparcie dla Pythona 3.14, czyniąc go kluczowym narzędziem dla inżynierów danych budujących produkcyjne potoki przetwarzania.

Jakie Problemy Rozwiązuje Great Expectations w Potokach Danych

Potoki danych zawodzą w sposób cichy. Zmiana schematu po stronie źródła, wartość null tam gdzie nie powinna istnieć, format daty który zmienia się z ISO na Unix timestamp — te problemy często docierają do dashboardów lub modeli ML zanim ktokolwiek je zauważy. Great Expectations traktuje dane jak kod, stosując asercje (zwane Expectations) które uruchamiają się automatycznie w punktach kontrolnych potoku.

Framework integruje się z Apache Airflow, Databricks, Snowflake oraz usługami przechowywania w chmurze takimi jak AWS S3 i Azure Blob Storage. Każda walidacja generuje Data Docs — raporty HTML które mogą czytać osoby nietechniczne.

Podstawowe Koncepcje: Data Context, Data Sources i Expectations

GX 1.22 organizuje walidację wokół czterech komponentów: Data Context, Data Sources, Data Assets i Expectation Suites.

Data Context to centralny obiekt konfiguracyjny. Przechowuje metadane dla Data Sources, Expectation Suites, Checkpointów i historycznych wyników walidacji. W większości projektów pojedynczy katalog gx/ zawiera pliki konfiguracyjne YAML i wygenerowane Data Docs.

Data Source reprezentuje połączenie z bazą danych, hurtownią danych lub systemem plików. Data Asset to logiczna kolekcja rekordów w ramach tego źródła, podobna do tabeli lub zestawu wyników zapytania.

# 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
)

Ta konfiguracja pozwala GX walidować dowolny plik CSV pasujący do wzorca user_events_*.csv w katalogu data/.

Budowanie Expectation Suite do Walidacji Kolumn

Expectation Suite to kolekcja asercji wobec Data Asset. Każda Expectation deklaruje warunek który powinien być spełniony dla danych, na przykład "kolumna user_id nigdy nie powinna być null" lub "kolumna age powinna zawierać wartości między 0 a 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+ używa API opartego na klasach dla Expectations. Starsza składnia oparta na słownikach (expect_column_to_exist) pozostaje dostępna, ale podejście klasowe zapewnia lepsze autouzupełnianie w IDE i bezpieczeństwo typów.

Uruchamianie Walidacji za pomocą Checkpointów

Checkpoint łączy Data Asset, Expectation Suite i opcjonalne Actions które uruchamiają się gdy walidacja przechodzi lub nie. Checkpointy są głównym punktem wejścia do automatycznej walidacji w produkcji.

# 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}")

Gdy Checkpoint się uruchamia, GX ładuje batch, stosuje każdą Expectation i aktualizuje Data Docs. Nieudane walidacje mogą wywołać powiadomienia Slack, alerty PagerDuty lub zatrzymanie potoku w zależności od skonfigurowanych Actions.

Integracja GX z DAG-ami Apache Airflow

Większość produkcyjnych potoków danych używa orkiestratora takiego jak Apache Airflow. GX dostarcza oficjalną integrację z Airflow która opakowuje wykonanie Checkpointu w operatorze.

# 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

Umieszczenie walidacji przed zadaniami transformacji zapobiega propagacji złych danych w dół potoku. Ten wzorzec, czasem nazywany "shift-left testing", wychwytuje problemy przy ingestion zamiast po zakończeniu kosztownych zadań obliczeniowych.

Typowe Pytania Rekrutacyjne o Great Expectations

Rozmowy kwalifikacyjne dla inżynierów danych w 2026 roku często zawierają pytania o narzędzia do jakości danych. Poniżej znajdują się pytania pojawiające się na rozmowach technicznych wraz z odpowiedziami które odróżniają doświadczonych kandydatów od juniorów.

"Jak zaimplementować kontrole jakości danych w produkcyjnym potoku?"

Mocne odpowiedzi wspominają o osadzeniu walidacji jako etapu potoku, a nie jako osobnego dashboardu. Konkretnie:

• Walidacja schematu przy ingestion wychwytuje problemy strukturalne natychmiast, na przykład string pojawiający się tam gdzie oczekiwano integer
• Walidacja logiki biznesowej sprawdza ograniczenia domenowe jak dodatnie ceny i zakresy dat
• Automatyczne alerty powiadamiają inżynierów dyżurnych gdy walidacja nie przechodzi, zapobiegając cichej korupcji danych
• Testy dbt obsługują kontrole warstwy transformacji podczas gdy GX obsługuje walidację ingestion i output

"Jaka jest różnica między Expectation Suite a Checkpoint?"

Expectation Suite zawiera same asercje: które kolumny powinny istnieć, jakie zakresy wartości są akceptowalne, które wzorce regex powinny pasować. Definiuje co sprawdzać.

Checkpoint definiuje kiedy i jak uruchamiać te kontrole. Łączy konkretny Data Asset (dane do walidacji), Expectation Suite (reguły do zastosowania) i Actions (co dzieje się po walidacji).

"Jak obsługiwać Expectations które różnią się w zależności od środowiska?"

Dane produkcyjne często mają inne charakterystyki niż dane staging. Dwa podejścia:

1. Sparametryzowane Expectations: Użycie zmiennych środowiskowych lub parametrów runtime do dostosowania progów. Na przykład min_value=int(os.getenv("AGE_MIN", 0)).

2. Wiele Suites: Utrzymywanie osobnych suites dla staging i produkcji. Staging może dopuszczać null w polach opcjonalnych do testowania niekompletnych przepływów danych.

"Co się dzieje gdy Checkpoint nie przechodzi w zaplanowanym potoku?"

Checkpoint zwraca CheckpointResult z success=False. Zachowanie potoku zależy od tego jak orkiestrator obsługuje błąd:

• W Airflow rzucenie wyjątku oznacza zadanie jako nieudane, blokując zadania downstream
• W Databricks notebook może zakończyć się ze statusem błędu
• Actions dołączone do Checkpointu mogą wysyłać wiadomości Slack, tworzyć tickety Jira lub uruchamiać procedury rollback

Własne Expectations dla Walidacji Specyficznej dla Domeny

GX zawiera ponad 300 wbudowanych Expectations, ale reguły specyficzne dla domeny często wymagają własnych implementacji. Własna Expectation rozszerza klasę bazową i implementuje logikę walidacji.

# 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
            }
        }

Własne Expectations rejestruje się poprzez umieszczenie ich w katalogu great_expectations/plugins/ lub dodanie modułu do plugins_directory w great_expectations.yml.

Data Docs: Komunikowanie Jakości Interesariuszom

Data Docs to statyczne strony HTML generowane z wyników walidacji. Każde uruchomienie tworzy stronę pokazującą które Expectations przeszły lub nie, z szczegółami drill-down dotyczącymi nieoczekiwanych wartości.

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

Dla systemów produkcyjnych Data Docs mogą być hostowane na S3, GCS lub Azure Blob Storage z odpowiednimi kontrolami dostępu. Platforma GX Cloud oferuje hostowane Data Docs z funkcjami współpracy zespołowej.

Migracja do GX 1.0: Przełomowe Zmiany z 0.x

Zespoły aktualizujące z GX 0.x napotykają zmiany API. Główne różnice:

Oficjalny przewodnik migracji opisuje każdą zmianę. Dla dużych baz kodu stopniowa migracja z użyciem shims kompatybilności zmniejsza ryzyko.

Kluczowe Wnioski dla Jakości Danych z GX 1.22

• Great Expectations 1.22 (sierpień 2026) wspiera Python 3.10 do 3.13, z eksperymentalnym wsparciem dla 3.14 poprzez zmienną środowiskową GX_PYTHON_EXPERIMENTAL
• Expectation Suites definiują co walidować, Checkpointy definiują kiedy i jak
• Osadzanie Checkpointów jako etapów potoku w DAG-ach Airflow lub notebookach Databricks pozwala wychwytywać złe dane przy ingestion
• Własne Expectations obsługują reguły specyficzne dla domeny których wbudowane Expectations nie mogą pokryć
• Data Docs zapewniają czytelne dla interesariuszy raporty HTML; należy je hostować na storage w chmurze dla dostępu produkcyjnego
• Odpowiedzi rekrutacyjne powinny podkreślać jakość danych jako osadzony etap potoku, a nie dodany dashboard