Pandera passer bedst til Python-teams der arbejder i pandas eller Polars og vil have datavalidering som en let, kode-først kontrakt tæt på deres transformationer, mens Great Expectations bør vælges når du har multi-engine pipelines (pandas, Spark, SQL), skal dele forventningsuiter mellem hold og har brug for Data Docs og checkpoints med governance. I 2026 er begge biblioteker modne og produktionsklare. Valget handler ikke længere om "hvilket er bedst", men om hvor i din stak datakontrakten hører hjemme. Denne guide sammenligner dem side om side med kørbare eksempler, så du kan træffe beslutningen på 15 minutter i stedet for tre sprint-planlægninger.
Pandera 0.20+ er en letvægts, kode-først valideringsramme med backends til pandas, Polars, Dask, Modin og PySpark (samme skema, mange engines).
Great Expectations 1.x blev omskrevet i 2024–2025 og har nu et Fluent API, indbygget Data Docs og Checkpoints der kører på tværs af Spark, SQL og pandas.
Pandera integrerer med Pydantic v2, så du kan genbruge API-modeller (fx fra FastAPI) som DataFrame-skemaer uden dobbeltarbejde.
Great Expectations vinder når validering er en organisatorisk kontrakt mellem data-producenter og forbrugere, ikke bare en test i pipelinen.
Begge biblioteker er open source under MIT/Apache 2.0 og kan køres i CI, Airflow, Dagster og dbt-on-Python uden ekstra licensomkostninger.
Hvis du kun har brug for én ting fra denne artikel: kør validering før writes til dine warehouse-tabeller, aldrig kun efter. Backfills bliver dyre ellers.
Hvad er Pandera og Great Expectations?
Pandera er et Python-bibliotek til statistisk typet datavalidering af DataFrames. Du beskriver din tabel som et skema (kolonner, typer, tilladte værdier, nullability, unikke nøgler, rækkevidder), og Pandera afviser DataFrames der bryder kontrakten, enten som en Python-exception eller ved at markere dårlige rækker. Projektet startede i 2018 som et alternativ til at skrive ad-hoc assert-udsagn i notebooks og har siden fået en klasse-baseret API (DataFrameModel), Pydantic-interop og backends til Polars, Dask, Modin og PySpark. Vedligeholdes af Union.ai og et aktivt open source-fællesskab under Apache 2.0.
Great Expectations (ofte forkortet GE eller GX) tager en anden tilgang: validering som et delt sprog mellem hold. Du opretter en Data Context, tilslutter en eller flere Datasources (pandas, Spark, Snowflake, Postgres, BigQuery, DuckDB...), skriver Expectations (fx expect_column_values_to_be_unique) og pakker dem i Expectation Suites. Suites eksekveres af Checkpoints, og resultaterne renderes som statiske HTML Data Docs, læsbare for både data engineers, analytikere og forretningsinteressenter. GE 1.x, der landede sen 2024 og modnede gennem 2025, forenkler den tidligere tunge YAML-konfiguration med et nyt Fluent Python API.
Kort sagt: Pandera er et bibliotek. Great Expectations er et framework. Det er ikke en dom, men en beskrivelse af hvor meget struktur de påtvinger din kodebase, og det er den enkelt vigtigste dimension når du vælger.
Pandera vs Great Expectations: Sammenligning på 60 sekunder
Tabellen nedenfor opsummerer de dimensioner jeg oftest bliver spurgt om når teams står med valget. Tallene og feature-listen afspejler Pandera 0.20+ og Great Expectations 1.3+ pr. juli 2026.
Multi-engine data warehouses, cross-team governance
Licens
Apache 2.0
Apache 2.0
Hvis du læser tabellen og tænker "det ene lyder let, det andet lyder tungt", så har du fanget den vigtigste forskel. Pandera er bevidst let. GE er bevidst omfattende. Ingen af dem forsøger at være det andet, og det er faktisk en god ting.
Datavalidering med Pandera: Kørbart eksempel
Så lad os validere en salgstabel med Pandera. Installationen er én linje, og eksemplet nedenfor kører direkte i en Jupyter-notebook eller et Python-script. Jeg bruger den klasse-baserede API (DataFrameModel) fordi den giver bedre IDE-support og lettere genbrug, men den funktionelle DataFrameSchema API findes stadig og virker fint.
# pip install "pandera[pandas]==0.20.*"
import pandas as pd
import pandera.pandas as pa
from pandera.typing import Series
class SalgSkema(pa.DataFrameModel):
ordre_id: Series[int] = pa.Field(unique=True, ge=1)
kunde_id: Series[int] = pa.Field(ge=1)
beloeb_dkk: Series[float] = pa.Field(ge=0, le=1_000_000)
valuta: Series[str] = pa.Field(isin=["DKK", "EUR", "USD"])
oprettet: Series[pa.DateTime] = pa.Field(nullable=False)
class Config:
strict = True # afvis ukendte kolonner
coerce = True # forsoeg at caste typer foer validering
@pa.check("beloeb_dkk", name="ikke_negativt")
def positivt_beloeb(cls, s: Series[float]) -> Series[bool]:
return s >= 0
df = pd.DataFrame({
"ordre_id": [1, 2, 3],
"kunde_id": [101, 102, 103],
"beloeb_dkk": [499.0, 1250.5, 89.9],
"valuta": ["DKK", "EUR", "DKK"],
"oprettet": pd.to_datetime(["2026-07-01", "2026-07-02", "2026-07-03"]),
})
# Kaster pa.errors.SchemaError hvis DataFrame ikke overholder skemaet
gyldig_df = SalgSkema.validate(df, lazy=True)
print(gyldig_df.head())
Flaget lazy=True er nøglen i produktion: uden det stopper Pandera ved første fejl, med det samler den alle valideringsfejl først og rapporterer dem i én SchemaErrors-exception med en pænt formateret tabel. Ærligt talt, det er guld værd når du kører backfills og gerne vil se alle problemer på én gang i stedet for at fikse dem én ad gangen.
Bemærk coerce=True: Pandera vil forsøge at caste strengede tal til int, datoer i strengformat til datetime64 osv. før validering. Det gør bibliotekets kontrakt-agtige natur meget mere forsonlig med den rodede virkelighed hvor CSV-input altid ankommer som strings.
Datavalidering med Great Expectations: Kørbart eksempel
Great Expectations kræver mere setup, men til gengæld får du persisteret state, historik og et Data Docs-site du kan hoste for hele organisationen. Her er den korteste vej fra ingenting til en kørende valideringssuite med det nye Fluent API (GE 1.x):
# pip install "great_expectations==1.3.*" pandas
import great_expectations as gx
import pandas as pd
# 1) Opret (eller aabn) en Data Context, persisteret paa disk
context = gx.get_context(mode="file", project_root_dir="./gx")
# 2) Registrer en pandas datasource og et asset
datasource = context.data_sources.add_pandas(name="salg_ds")
asset = datasource.add_dataframe_asset(name="salg_asset")
# 3) Byg en Batch Definition
batch_def = asset.add_batch_definition_whole_dataframe("hele_salg")
df = pd.DataFrame({
"ordre_id": [1, 2, 3],
"kunde_id": [101, 102, 103],
"beloeb_dkk": [499.0, 1250.5, 89.9],
"valuta": ["DKK", "EUR", "DKK"],
})
# 4) Definer forventninger i en suite
suite = context.suites.add(gx.ExpectationSuite(name="salg_v1"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeUnique(column="ordre_id"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeInSet(
column="valuta", value_set=["DKK", "EUR", "USD"]))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(
column="beloeb_dkk", min_value=0, max_value=1_000_000))
# 5) Byg og koer et Validation Definition
validation = context.validation_definitions.add(gx.ValidationDefinition(
name="salg_daglig", data=batch_def, suite=suite))
result = validation.run(batch_parameters={"dataframe": df})
print("Success:", result.success)
context.build_data_docs() # genererer HTML-rapport i gx/uncommitted/data_docs/
Læg mærke til begreberne der er nye: Data Context, Data Source, Asset, Batch Definition, Suite, Validation Definition, Checkpoint. Det er ikke tilfældigt. GE modellerer datakvalitet som et system, ikke bare en funktion. Fordelen er at du kan versionere suites, distribuere dem via en delt Data Context og få HTML-rapporter automatisk. Ulempen er at "hej verden"-eksemplet fylder tre gange så meget som i Pandera. I mit team har vi typisk brugt en dag på at få den første GE-suite kørende i CI, så regn med at det er en investering, ikke en eftermiddagsopgave.
Hvornår skal du vælge Pandera?
Vælg Pandera hvis mindst to af disse punkter beskriver dit setup:
Din pipeline lever primært i pandas eller Polars. Pandera er født i den verden, og skemaerne læser næsten som pandas-kode. Skifter du mellem pandas og Polars, kan samme DataFrameModel validere begge, hvilket er meget nyttigt hvis du er ved at migrere. Se min tidligere sammenligning af Polars og pandas i 2026 for hvornår hvert bibliotek giver mening.
Du bygger ML-features og vil have kontrakter tæt på transformationerne. Kombiner Pandera med en scikit-learn Pipeline (se min guide til scikit-learn Pipeline og ColumnTransformer), og du får både preprocessing og validering ét sted i koden.
Du bruger allerede Pydantic (fx via FastAPI). Pandera kan læse dine Pydantic-modeller direkte og genbruge dem som DataFrame-skemaer. Ét sted sandhed, både for HTTP-payloads og batch-data.
Du vil have validering som en pytest-fikstur. Pandera skemaer er importerbare Python-objekter, nemme at teste, mockere og fixture. GE's suites lever i en Data Context og kræver mere ceremoniel infrastruktur i tests.
Konkret erfaring fra min egen backlog: da vi rev en gammel Airflow DAG ud og skrev den om til Dagster asset-graphs, tog vi Pandera med. Vi kunne dekorere hver @asset med @pa.check_io(input=SalgSkema, output=BeriketSkema) og fange schema drift på 12 sekunder i CI i stedet for at opdage det klokken 03:47 fra en on-call notifikation. Det er den slags timebesparelse der får folk til at holde af tooling.
Hvornår skal du vælge Great Expectations?
Great Expectations vinder når validering ikke længere er en teknisk detalje, men en organisatorisk kontrakt. Konkret betyder det:
Du kører multi-engine pipelines. Samme suite kan valideres mod en pandas DataFrame i CI, en Spark-tabel i EMR og et Snowflake-view i produktion. Pandera kan også, men GE's abstraktion er mere gennemarbejdet for warehouse-scenarier.
Ikke-programmører skal kunne læse resultaterne. Data Docs er statiske HTML-sites, hostbare på S3 eller GitHub Pages, og de viser hver validering med grønne/røde flueben, sample-rækker og historik. Ingen analytiker eller product owner vil læse en Python stack trace. De vil kigge på en side.
Du vil have et delt "sprog" mellem data-producenter og forbrugere. GE's Expectation Suites er versionerbare artefakter du kan distribuere gennem en pakke og genbruge på tværs af hold. Det er den samme idé som en dbt data test, bare uden at være bundet til SQL.
Governance og revision betyder noget. GE opsamler resultater i en Store som du kan holde i Postgres. Det giver dig historik og audit trail, hvilket er vigtigt hvis du er i et reguleret domæne (fintech, sundhed, forsikring).
Der er dog en pris. GE 1.x er lettere end 0.x, men det er stadig et framework med sin egen abstraktion. Regn med to til fire uger fra beslutning til første suite i produktion, når du inkluderer suite-design, review, CI-opsætning og Data Docs-hosting.
Integration i CI/CD, dbt og orkestrering
Begge biblioteker kan køres i pytest, GitHub Actions, Airflow, Dagster og Prefect. Det er ikke der forskellen ligger. Forskellen ligger i hvor valideringen konceptuelt hører hjemme i din stak.
Pandera hører hjemme i transformationen. Et typisk mønster: du dekorerer din transformation med @pa.check_io, som validerer input og output. Fejl fanges før dårlige data forlader funktionen. I dbt-on-Python (dbt 1.9+ med Python-modeller på Snowpark/Snowflake eller BigQuery) kan du bruge Pandera direkte i din model.py og kaste en fejl der får dbt til at markere modellen som failed. Det gør backfills forudsigelige. Du får aldrig delvist skrevne, halvt-korrupte tabeller.
Great Expectations hører hjemme mellem stages. Typisk kører du en Checkpoint efter en dbt run. GE kigger på det producerede warehouse-objekt, kører sin suite mod det, og genererer Data Docs. Fejl håndteres af din orkestrator (Airflow sensor, Dagster asset check, Prefect flow). For teams der har adopteret Data Mesh eller lignende decentraliserede modeller, er det den korrekte designmæssige placering: kontrakten sidder på grænsefladen mellem to produkter, ikke inde i én af dem.
Min anbefaling efter at have bygget begge dele: hvis du starter fra bunden, læg Pandera i selve transformationen (fast, billig kontrakt) og hold GE til de kritiske pipeline-grænseflader hvor du har brug for Data Docs eller cross-team governance. Det er ikke enten-eller. Det er lag.
Performance og backends: Polars, Dask og PySpark
Performance-samtalen bliver ofte reduceret til "hvor hurtigt validerer det 1 mio. rækker?", men det er den forkerte fremstilling. Den rigtige samtale er "kan valideringen køre der hvor mine data lever, uden at flytte dem?" For dataflytning er den dyre operation, ikke selve validation-checket.
Pandera 0.19+ har native Polars-backend. Du importerer pandera.polars as pa og definerer en DataFrameModel. Pandera udnytter Polars' lazy API under motorhjelmen, så filter- og projections-pushdown gør validering på flerhundrede millioner rækker overkommelig på én maskine. Backends for Dask, Modin og pyspark.pandas findes også. Se Pandera-dokumentationen for hvilke checks der er implementeret pr. backend (nogle avancerede statistiske checks er stadig pandas-only).
Great Expectations har historisk været stærkest på SQL-backends. GE oversætter en Expectation til SQL og lader warehouse-motoren gøre arbejdet, og det er derfor GE typisk vælges når "dataen" er en 400 mia. række Snowflake-tabel. Spark-backend'et er også modent. pandas fungerer, men bruges mest i test.
En simpel tommelfingerregel: hvis dine data er så store at du ikke vil læse dem ind i memory, brug GE med SQL-backend eller Pandera med Polars-lazy backend. Hvis de passer i memory og du allerede har dem indlæst i en pandas DataFrame, gør Pandera det på 10 linjer, og du kan gå videre. Læs også Great Expectations' officielle dokumentation for opdaterede performance-benchmarks. De opdateres oftere end sekundære blog posts.
Vil du kombinere validering med reproducerbare pandas-pipelines? Så tag et kig på min guide til datarensning med pandas 3.0 og pipe(). Pandera passer perfekt ind som første og sidste led i en .pipe()-kæde.
Ofte stillede spørgsmål
Hvad er forskellen på Pandera og Great Expectations?
Pandera er et letvægts Python-bibliotek der validerer DataFrames med en skemadefinition tæt på din kode. Great Expectations er et framework der modellerer datavalidering som et system med en Data Context, versionerede Expectation Suites og HTML Data Docs. Pandera egner sig bedst til in-code kontrakter i ML og feature engineering; Great Expectations egner sig bedst til cross-team governance i data warehouses.
Kan Pandera validere Polars DataFrames?
Ja. Fra Pandera 0.19 (og forbedret i 0.20) er der native Polars-backend. Installer med pip install "pandera[polars]", brug import pandera.polars as pa, og validér både polars.DataFrame og polars.LazyFrame. Pandera konverterer internt til LazyFrame for at udnytte Polars' query-optimering.
Er Great Expectations gratis at bruge?
Ja. Great Expectations er open source under Apache 2.0-licensen og gratis at bruge kommercielt. Firmaet bag (GX Cloud) tilbyder en betalt SaaS-version med hostede Data Docs og team-funktioner, men self-hosted open source-versionen dækker de fleste behov uden licensgebyr.
Kan jeg bruge Pandera og Great Expectations sammen?
Ja, og det er faktisk et almindeligt mønster. Brug Pandera inde i dine transformationer (fx som @pa.check_io-dekorator) til hurtige, kode-nære kontrakter, og brug Great Expectations mellem pipeline-stages hvor du har brug for Data Docs, governance eller cross-team synlighed. De to biblioteker konkurrerer ikke. De dækker forskellige lag af datakvalitet.
Hvordan validerer man data i en dbt-pipeline med Python?
I dbt Python-modeller (dbt 1.9+ på Snowpark, BigQuery eller Databricks) kan du bruge Pandera direkte i modellens Python-kode og kaste en SchemaError ved fejl, hvorefter dbt markerer modellen som failed. Til slutgyldige checks efter dbt-runs bruges typisk Great Expectations Checkpoints eller dbt's egne indbyggede data tests. Kombiner dem: dbt tests til SQL-baserede assertions, GE til komplekse tværgående forventninger.
Lær at visualisere data med matplotlib og seaborn i Python. Komplet dansk guide med pandas DataFrames, linjediagrammer, boxplots, heatmaps, pairplots og et færdigt salgsdashboard du kan bygge videre på.
Byg reproducerbare datarensningspipelines med pandas 3.0. Lær pipe(), pd.col(), Copy-on-Write-semantik og Pandera-validering med praktiske kodeeksempler du kan bruge med det samme.
