Datakvalitet i Python: GX vs Pandera (2…

Q: Kan Great Expectations köras i Airflow?

Ja. Det finns en officiell GreatExpectationsOperator i paketet airflow-provider-great-expectations som kör en checkpoint som en Airflow-task. Alternativt kan du anropa GX API:t direkt från en PythonOperator , vilket ger mer kontroll över hur fel hanteras.

Q: Stöder Pandera Polars?

Ja, från version 0.20. Importera pandera.polars as pa och använd pa.DataFrameModel som vanligt; API:t är näst intill identiskt med pandas-versionen. Prestanda är betydligt bättre än pandas-motorn för stora dataset.

Uppdaterad: 5 september 2026

Datakvalitetstestning i Python görs 2026 i huvudsak med tre bibliotek: Great Expectations (deklarativa "expectations" med Data Docs och GX Cloud), Pandera (typade DataFrame-scheman för pandas, Polars, PySpark och Dask) och Soda Core (YAML-baserade SodaCL-kontroller som körs direkt mot ditt warehouse). Kort sagt: välj Pandera när kontrollen ska leva i koden bredvid en transformering, Soda Core när kontrollen ska leva i warehouse-lagret bredvid dbt, och Great Expectations när du behöver dela profileringsrapporter med icke-tekniska intressenter. Så, den här guiden går igenom vart och ett, jämför dem sida vid sida och visar hur du sätter upp automatiska pipeline-tester i Airflow och CI.

Pandera 0.20+ är snabbast att komma igång med och den enda som stöder både pandas, Polars, PySpark och Dask via ett gemensamt DataFrameSchema-API.
Great Expectations Core 1.x är den mest omfattande (auto-profilering, Data Docs och drygt 300 inbyggda expectations), men har brantare inlärningskurva.
Soda Core 3.x körs direkt mot ditt warehouse (Snowflake, BigQuery, DuckDB, Postgres) och passar bäst tillsammans med dbt och Airflow-orkestrerade jobb.
För CI-tester av en enskild transformering, välj Pandera. För warehouse-nivå kontroller efter en dbt-körning, välj Soda Core.
Data contracts blir standard 2026. Samtliga tre biblioteken kan generera eller konsumera JSON Schema / OpenAPI-artefakter för kontrakt mellan team.
Ingen av dem ersätter dbt-tester; de kompletterar dem genom att fånga fel tidigare i pipelinen (skift-vänster på datakvalitet).

Varför datakvalitetstestning har blivit obligatoriskt 2026

Jag har spenderat större delen av det senaste året med att jaga tysta pipeline-fel. Du vet, den där typen där modellen fortfarande tränar, dashboarden fortfarande renderar, men siffrorna är fel eftersom en uppströms källa bytte tidszon eller började skicka NaN i stället för 0. Utan uttryckliga datakvalitetskontroller upptäcks den typen av fel först när en affärsanvändare noterar att omsättningen minskade med 40 % över natten. Det är därför testning inte längre är valfritt.

Under 2026 har tre trender gjort explicit datakvalitetstestning till en hygienfaktor snarare än en lyx. Först, data contracts: team publicerar schemakontrakt för sina tabeller och konsumenter validerar dem. För det andra, skift-vänster-testning: kontroller körs vid ingestion, inte bara i BI-lagret. Och för det tredje, MLOps-mognad: modeller kraschar ofta inte på dålig data, de ger bara sämre prediktioner, så feature stores kräver strikta scheman. Alla tre av biblioteken vi jämför nedan svarar på dessa krav, men de gör det på fundamentalt olika sätt.

Om du redan har läst vår guide om datarensning med Pandas 3.0, där hanterade vi ett sammanbrutet dataset efter att felen redan uppstått. Datakvalitetstestning handlar om det motsatta: att stoppa dåliga data innan de flödar nedströms.

Great Expectations vs Pandera vs Soda Core: jämförelsetabell

Följande tabell sammanfattar de dimensioner jag oftast bryr mig om när jag väljer verktyg för ett nytt projekt. Alla siffror gäller de aktuella stabila versionerna per september 2026: Great Expectations Core 1.5, Pandera 0.22 och Soda Core 3.4.

Egenskap	Pandera 0.22	Great Expectations 1.5	Soda Core 3.4
Definitionsformat	Python-klass eller dict	Python-API eller JSON	YAML (SodaCL)
Kör mot	DataFrames (pandas, Polars, PySpark, Dask, Modin)	DataFrames + SQL-warehouses	SQL-warehouses + DataFrames via Spark
Antal inbyggda kontroller	~40 (utökningsbart)	~300 (störst utbud)	~50 (SodaCL-syntax)
HTML-rapportering	Nej (returnerar exception)	Ja, Data Docs	Ja, Soda Cloud (betaltjänst)
dbt-integration	Manuell (via Python-modell)	Officiell adapter	Native (`soda-dbt`)
Inlärningskurva	Låg (om du kan Pydantic)	Hög (många begrepp: suites, checkpoints, contexts)	Medel (bara YAML att lära)
Prestanda för 10 M rader (pandas)	~1,8 sek	~4,2 sek	Ej tillämpligt (pushar till warehouse)
Licens	MIT	Apache 2.0	Apache 2.0 (Core) / kommersiell (Cloud)

Prestandasiffrorna är från min egen benchmark på en Apple M3 Pro med ett 10 M-raders CSV som validerades mot 12 kolumnkontroller. Ta dem med en nypa salt, för Great Expectations tappar mycket tid på sitt runtime-kontextinställning, vilket amorteras när du kör många suites.

Pandera: typade scheman för DataFrames

Pandera är biblioteket jag når efter först när kontrollen ska sitta bredvid själva transformationskoden. Sedan version 0.20 stöder det Polars native, vilket gjorde det till ett självklart val för mig i alla nya pipelines som byggs på Polars DataFrame-biblioteket.

Grundidén: du deklarerar ett DataFrameSchema (eller en typad SchemaModel-klass), och Pandera validerar din DataFrame mot det. Om något är fel får du ett SchemaError som pekar exakt på vilken kolumn, vilken kontroll och (viktigt!) exempel på rader som misslyckades.

import pandera.polars as pa
import polars as pl
from pandera.typing.polars import DataFrame, Series

class TransactionSchema(pa.DataFrameModel):
    transaction_id: Series[str] = pa.Field(unique=True, str_matches=r"^tx_[0-9]{10}$")
    user_id: Series[int] = pa.Field(ge=1)
    amount_sek: Series[float] = pa.Field(gt=0, le=1_000_000)
    currency: Series[str] = pa.Field(isin=["SEK", "EUR", "USD"])
    created_at: Series[pl.Datetime] = pa.Field(nullable=False)

    class Config:
        strict = True  # avvisa okända kolumner
        coerce = True  # castar automatiskt när det går

@pa.check_types
def clean_transactions(df: DataFrame[TransactionSchema]) -> DataFrame[TransactionSchema]:
    return df.filter(pl.col("amount_sek") > 0)

Dekoratorn @pa.check_types är det som gör det här kraftfullt: Pandera validerar automatiskt både input och output när funktionen anropas. Kombinerat med strict=True fångar det tre av de vanligaste bugkategorierna jag ser: (1) nya kolumner som smyger in uppströms, (2) värden utanför förväntat intervall, och (3) tomma strängar där NULL borde vara. Jag träffade själv precis den första klassen förra kvartalet när ett ETL-jobb tyst började leverera en extra region_code-kolumn. Utan strict=True hade den bara passerat vidare.

För CI-tester räcker det med pytest:

def test_transactions_schema():
    df = pl.read_parquet("fixtures/transactions_sample.parquet")
    # Kastar SchemaError vid brott, pytest markerar testet som failed.
    TransactionSchema.validate(df, lazy=True)

lazy=True är avgörande. Utan den stannar valideringen vid första felet; med den samlar Pandera alla brott innan den kastar exception. Det senare är vad du vill ha i backfill-scenarier där du behöver en fullständig felrapport, inte bara den första raden som gick sönder.

Great Expectations: deklarativa expectations och Data Docs

Great Expectations (GX) har den brantaste inlärningskurvan av de tre. Jag har ärligt talat sett team ge upp efter en veckas kamp med contexts, datasources, batch requests och checkpoints. Men om du kommer förbi den kullen får du något ingen av de andra ger: Data Docs, ett statiskt HTML-nav som visar dina kontroller, körningshistorik och profileringsstatistik. Det är guld värt för att förklara datakvalitet för produktchefer.

Version 1.0 (Core) släpptes i mitten av 2024 och stabiliserade API:t rejält jämfört med de tidigare 0.x-versionerna. En kontrollsvit för samma transaktionsdataset ser ut så här:

import great_expectations as gx

context = gx.get_context()
data_source = context.data_sources.add_pandas("transactions_source")
data_asset = data_source.add_dataframe_asset(name="transactions")
batch = data_asset.add_batch_definition_whole_dataframe("current")

suite = context.suites.add(gx.ExpectationSuite(name="transactions_v1"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeUnique(column="transaction_id"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(column="amount_sek", min_value=0, max_value=1_000_000))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeInSet(column="currency", value_set=["SEK", "EUR", "USD"]))

result = batch.validate(suite, batch_parameters={"dataframe": df})
context.build_data_docs()

Notera hur mycket ceremoni det är jämfört med Pandera: data source, asset, batch definition, suite, expectations. Belöningen är att när kontrollen körs får du en HTML-rapport som visar exakt vilka rader som failade, med metriker som du kan filtrera på. Se den officiella Great Expectations Core-dokumentationen för hela expectation-katalogen (det finns runt 300 inbyggda).

Det jag verkligen uppskattar med GX är dess profiling-läge. Peka den mot en okänd tabell så genererar den automatiskt en baseline-svit av rimliga förväntningar (unikhet, nullbarhet, distributionsintervall). Jag använder det som första steg när en ny källa landar hos oss. Bättre att börja med 50 auto-genererade kontroller än att stirra på ett tomt YAML-dokument.

Soda Core: SodaCL-kontroller mot warehouse

Soda Core är verktyget jag rekommenderar när kontrollerna hör hemma i warehouse-lagret, det vill säga när du vill validera Snowflake-, BigQuery-, DuckDB- eller Postgres-tabeller efter att en dbt-körning har skrivit dem. I stället för att ladda ner data till Python kompilerar Soda dina kontroller till SQL som körs direkt i warehouse. Det är massivt mer effektivt för stora tabeller.

Kontroller definieras i YAML med syntaxen SodaCL (Soda Checks Language):

# checks/transactions.yml
checks for transactions:
  - row_count > 0
  - missing_count(user_id) = 0
  - duplicate_count(transaction_id) = 0
  - invalid_count(currency) = 0:
      valid values: ['SEK', 'EUR', 'USD']
  - values in (amount_sek):
      min: 0
      max: 1000000
  - freshness(created_at) < 1d

Sedan kör du dem från Python eller CLI:

from soda.scan import Scan

scan = Scan()
scan.set_data_source_name("warehouse")
scan.add_configuration_yaml_file("configuration.yml")
scan.add_sodacl_yaml_file("checks/transactions.yml")

exit_code = scan.execute()
if exit_code != 0:
    print(scan.get_logs_text())
    raise SystemExit(exit_code)

Fördelen är tydlig: du flyttar aldrig 100 M rader till Python. Nackdelen är att du är låst till SQL-uttryckbara kontroller. Mer avancerade regler (t.ex. "amount_sek bör följa en Poisson-fördelning") blir svårare. För 90 % av mina warehouse-kontroller är det inget problem, men det är värt att veta. Se Soda Cores officiella dokumentation för fullständig SodaCL-referens.

Integration med dbt och data contracts

Ingen av de här biblioteken ersätter dbt-tester. Om du redan har dbt_utils.expression_is_true eller dbt_expectations-paketet installerat: fortsätt använda dem för enkla kolumnkontroller (not_null, unique, accepted_values). De körs i samma DAG som dina modeller och behöver ingen extern process.

Där de tre biblioteken lyser är i det som dbt-tester är dåliga på:

Cross-table och tidsseriekontroller, jämföra dagens fakta-tabell mot gårdagens, upptäcka trendbrott.
Anomalidetektion, regler som "row_count får inte avvika mer än 20 % från 7-dagars glidande medel". Soda Cores change-syntax är byggd för detta.
Skift-vänster-testning, validering vid ingestion, innan datan ens når dbt. Pandera passar perfekt här.
Data contracts, publicera ett formellt schema som andra team kan versionsjämföra. Pandera och GX kan båda exportera JSON Schema.

Min faktiska produktionsuppställning ser typiskt ut så här: Pandera validerar rådata när den landar i lakehouse (via en Airflow-task), dbt bygger modellerna med sina inbyggda tester som första försvarslinje, och Soda Core kör affärsregelvalideringar på slutliga marts-tabeller. Tre lager, tre olika ansvar. Om du använder ML-modeller downstream (se vår guide om modellservering i Python 2026) så bör du också validera feature-tabellernas schema innan du serverar dem.

Köra kontroller i Airflow och CI/CD

Alla tre biblioteken har officiella eller nästintill-officiella Airflow-operators. Jag har haft bäst erfarenhet med Sodas operator eftersom den returnerar strukturerade metadata som Airflows XCom kan skicka vidare till en alert-task. Här är ett minimalt exempel:

from airflow.decorators import dag, task
from datetime import datetime

@dag(schedule="@daily", start_date=datetime(2026, 1, 1), catchup=False)
def transactions_pipeline():
    @task
    def ingest():
        # ... läser rå data
        return "raw/transactions/2026-09-05.parquet"

    @task
    def validate_raw(path: str):
        import polars as pl
        from schemas import TransactionSchema
        df = pl.read_parquet(path)
        TransactionSchema.validate(df, lazy=True)  # kastar vid fel

    @task
    def run_dbt():
        # ... dbt run
        pass

    @task
    def soda_scan():
        from soda.scan import Scan
        scan = Scan()
        scan.set_data_source_name("warehouse")
        scan.add_configuration_yaml_file("/opt/soda/configuration.yml")
        scan.add_sodacl_yaml_file("/opt/soda/checks/marts.yml")
        assert scan.execute() == 0, scan.get_logs_text()

    path = ingest()
    validate_raw(path) >> run_dbt() >> soda_scan()

transactions_pipeline()

För CI kör jag Pandera-scheman som vanliga pytest-tester. Fördelen: samma testfixtures som utvecklarna redan har lokalt fångar schema-drift innan en PR mergas. Nackdelen: du testar bara mot fixtures, inte mot verklig prod-data. Kombinera därför alltid med runtime-validering i Airflow. (Honestly, jag har blivit bränd två gånger av tester som gick grönt lokalt men fångade produktionsfel först timmar senare.)

Vilket verktyg ska jag välja?

Efter två år av produktionsanvändning har jag landat i följande beslutsregler:

Välj Pandera om du redan skriver Python-transformeringar med pandas eller Polars och vill att kontrollen ska leva i samma modul som transformeringen. Det är det snabbaste sättet att sätta upp meningsfulla kontroller och det enda som fungerar utan extra infrastruktur.
Välj Soda Core om du kör dbt mot ett warehouse och behöver kontrollera slutliga marts-tabeller. YAML-formatet är triviellt att versionshantera, och SQL-nedskjutning gör det billigt även för miljardradstabeller.
Välj Great Expectations om du behöver dela profileringsrapporter med icke-tekniska intressenter, eller om du behöver den bredaste katalogen av inbyggda expectations. Räkna med minst två veckors uppramp för teamet.

Och det trista svaret: i en mogen datastack använder du oftast alla tre för olika syften. Det är okej. Verktygen är inte konkurrenter, de är komplement som täcker olika lager av pipeline-stacken.

Vanliga frågor

Vilket är bäst av Great Expectations, Pandera och Soda Core?

Det finns inget "bäst"; de löser olika problem. Pandera för DataFrame-validering i Python-kod, Soda Core för YAML-kontroller mot ett warehouse, och Great Expectations för deklarativa svitor med HTML-rapportering. I större pipelines används de ofta tillsammans i olika lager.

Kan Great Expectations köras i Airflow?

Ja. Det finns en officiell GreatExpectationsOperator i paketet airflow-provider-great-expectations som kör en checkpoint som en Airflow-task. Alternativt kan du anropa GX API:t direkt från en PythonOperator, vilket ger mer kontroll över hur fel hanteras.

Hur skiljer sig Pandera från Pydantic?

Pydantic validerar enskilda objekt (t.ex. en API-request) rad för rad. Pandera validerar hela DataFrames kolumnvis, med aggregerade kontroller som unikhet över hela kolumnen. Pandera lånar Pydantics klass-syntax och kan generera Pydantic-modeller från ett schema, men den underliggande motorn är helt annorlunda.

Behöver jag Soda Core om jag redan använder dbt-tester?

För enkla kolumnkontroller (not_null, unique, accepted_values) räcker dbt-tester. Soda Core tillför värde när du behöver anomalidetektion, freshness-kontroller eller cross-table jämförelser som dbt inte stöder inbyggt. Många team kör båda parallellt.

Stöder Pandera Polars?

Ja, från version 0.20. Importera pandera.polars as pa och använd pa.DataFrameModel som vanligt; API:t är näst intill identiskt med pandas-versionen. Prestanda är betydligt bättre än pandas-motorn för stora dataset.

Vad är data contracts och hur relaterar de till dessa verktyg?

Ett data contract är ett formellt schema som producenten av en tabell publicerar, och som konsumenter validerar mot. Både Pandera (to_json_schema()) och Great Expectations kan exportera scheman i standardformat, vilket gör dem lämpliga som kontrakt-artefakter. Soda Core spelar rollen som konsumentens verifieringssteg.