Pandera 2026: Validasi Pandas & Polars

Q: Apa perbedaan Pandera dan Pydantic?

Pydantic memvalidasi objek Python biasa (dict, class) satu per satu. Pandera memvalidasi DataFrame yang berisi jutaan baris secara vectorized. Untuk API request body, pakai Pydantic; untuk DataFrame ETL, pakai Pandera. Pandera 0.22 menyediakan integrasi Pydantic v2 sehingga DataFrameModel bisa di-serialize ke BaseModel .

Q: Apakah Pandera mendukung Polars LazyFrame secara native?

Ya, sejak Pandera 0.19 dan diperluas di 0.22. Import dari pandera.polars , gunakan Series dari pandera.typing.polars , dan panggil Schema.validate(lazyframe, lazy=True) . Validasi di-push ke query plan Polars sehingga bisa jalan streaming untuk file Parquet besar.

Q: Bagaimana cara membuat Pandera mengumpulkan semua error, bukan berhenti di error pertama?

Tambahkan argumen lazy=True pada pemanggilan Schema.validate(df, lazy=True) . Pandera akan menjalankan semua Check dan raise satu SchemaErrors (jamak) yang berisi DataFrame failure_cases dengan kolom, index, dan nilai yang gagal, sehingga mudah ditulis ke tabel audit untuk investigasi.

Q: Berapa overhead performa Pandera di pipeline produksi?

Untuk schema tipikal (10–20 kolom, 5–10 Check per kolom), overhead sekitar 2–5% dari total waktu pipeline pada DataFrame 1–10 juta baris. Check bawaan sangat vectorized. Custom Check yang element-wise bisa 40x lebih lambat, jadi selalu tulis Check di level Series/DataFrame, bukan element.

Q: Apakah Pandera bisa digunakan di dbt?

Bisa, di dbt Python model (dbt 1.5+ di Snowpark, BigQuery Python, atau Databricks). Panggil Schema.validate(df, lazy=True) di function model() sebelum return DataFrame. Kalau validasi gagal, run dbt gagal, jadi data buruk tidak pernah masuk warehouse. Untuk SQL model biasa, tetap pakai dbt test generic dan singular.

Q: Pandera atau Great Expectations untuk project baru di 2026?

Untuk tim engineering-first yang menulis schema di kode dan menjalankannya di CI/pytest, pilih Pandera. Untuk tim data quality yang butuh data docs UI, auto-profiling, dan validasi post-load di warehouse untuk stakeholder non-teknis, pilih Great Expectations. Keduanya bisa hidup berdampingan di stack yang sama.

Diperbarui: 10 Juli 2026

Pandera adalah library Python untuk validasi statistik dan schema DataFrame Pandas, Polars, PySpark, dan Modin yang memungkinkan tim data engineering mendeklarasikan kontrak data eksplisit, menjalankan pemeriksaan tipe, nilai, dan nullability, lalu menghentikan pipeline sebelum baris rusak menyebar ke tabel downstream. Di rilis 0.22, Pandera menambah dukungan Polars LazyFrame native, integrasi Pydantic v2, dan API DataFrameModel berbasis class yang membuat schema terasa seperti kode aplikasi biasa (bukan konfigurasi YAML terpisah).

Pandera 0.22+ mendukung Pandas 2.x, Polars 1.x (eager & lazy), PySpark, dan Modin dengan API yang seragam.
DataFrameModel berbasis class Python type-hint lebih maintainable dibanding dict schema, bisa di-subclass, diinherit, dan diedit di IDE.
lazy=True mengumpulkan seluruh error validasi ke satu SchemaErrors. Ini wajib untuk pipeline batch supaya semua kolom bermasalah dilaporkan sekaligus, bukan gagal di kolom pertama.
Integrasi pytest + hypothesis membuat data contract jadi bagian dari CI: schema drift ketahuan di PR, bukan jam 3 pagi saat backfill.
Di dbt Python model, Airflow task, dan endpoint FastAPI, Pandera bertindak sebagai gate. Data yang tidak lolos tidak pernah masuk warehouse atau response body.
Untuk validasi kompleks lintas tabel, Pandera lebih ringan dan Pythonic dibanding Great Expectations, tapi GE unggul untuk profiling otomatis dan data docs UI.

Apa itu Pandera dan kenapa data engineer memakainya

Pandera adalah framework validasi DataFrame open-source yang dikembangkan di bawah organisasi Union.ai. Fungsinya sederhana. Anda mendeklarasikan bentuk data yang seharusnya (kolom apa, tipe apa, batas nilai apa, boleh null atau tidak), lalu Pandera memeriksa DataFrame terhadap kontrak tersebut sebelum kode downstream menyentuhnya. Yang membedakan Pandera dari sekadar assert df.dtypes manual adalah kemampuannya menggabungkan pemeriksaan tipe, pemeriksaan statistik (rata-rata dalam rentang, distribusi nilai kategori), dan pemeriksaan lintas kolom (kolom end_date harus lebih besar dari start_date) di satu tempat yang bisa dites, di-version-control-kan, dan diinheritkan.

Jujur saja, saya bekerja sebagai data engineer, dan hampir setiap incident pipeline yang saya audit ulang tahun lalu berakhir di kesimpulan yang sama. Skema data berubah tanpa pemberitahuan (kolom hilang, tipe berubah dari int64 ke string, atau kolom kategori tiba-tiba berisi enum baru), dan model downstream diam-diam menghasilkan output rusak selama berhari-hari. Pandera menghentikan skenario itu di titik masuk. Kalau kontrak dilanggar, task Airflow gagal keras, alert menyala, dan tim upstream tahu mereka yang menyebabkan masalah, bukan tim analytics yang dituduh karena angka aneh di dashboard esok pagi.

Jangan salah paham. Pandera bukan pengganti test unit atau dbt test. Dia melengkapi keduanya. dbt test bagus untuk aturan SQL-first (unique, not null, accepted_values) yang jalan setelah transformasi di warehouse. Pandera bagus untuk aturan Python-first yang jalan di dalam pipeline: di batas antara sistem, di dalam job feature engineering, atau di boundary API sebelum data dikirim ke user. Kombinasi keduanya, plus feature engineering yang di-pipeline dengan scikit-learn, memberi Anda tiga lapis pertahanan yang saling menguatkan.

Instalasi Pandera 0.22 dan kompatibilitas versi

Pandera 0.22 (rilis Q2 2026) mendukung Python 3.9–3.13, Pandas 1.5–2.2, Polars 0.20–1.6, PySpark 3.4+, dan Pydantic 2.6+. Instalasi minimal cukup pip install pandera, tapi di praktik, Anda hampir selalu ingin extras untuk engine yang dipakai. Extras dipisah supaya build image Docker tidak menyeret dependensi PySpark atau Modin kalau Anda cuma butuh Pandas.

# Untuk pipeline Pandas standar
pip install "pandera[pandas]==0.22.*"

# Menambah dukungan Polars (eager + lazy)
pip install "pandera[polars]==0.22.*"

# Kombinasi Pandas + Polars + hypothesis untuk unit test
pip install "pandera[pandas,polars,hypotheses]==0.22.*"

# Integrasi Pydantic v2 (schema -> BaseModel)
pip install "pandera[pandas,io]==0.22.*" "pydantic>=2.6"

Cek versi setelah install:

import pandera as pa
import pandera.pandas as papd  # namespace baru sejak 0.20

print(pa.__version__)  # 0.22.x
print(papd.DataFrameSchema.__module__)

DataFrameSchema vs DataFrameModel: mana yang dipilih

Pandera memberi dua API untuk mendefinisikan schema. DataFrameSchema adalah bentuk imperatif. Anda membangun objek schema dari dict kolom, mirip konfigurasi. DataFrameModel adalah bentuk deklaratif berbasis class dengan type hint, mirip Pydantic BaseModel. Untuk pipeline produksi 2026, saya hampir selalu memakai DataFrameModel. Alasannya sederhana: schema jadi bisa di-refactor di IDE, bisa di-inherit untuk membuat varian (silver → gold), dan lebih ramah code review karena diff-nya berupa perubahan class, bukan dict yang panjang.

Contoh DataFrameSchema imperatif untuk tabel transaksi mentah:

import pandera.pandas as pa
from pandera import Column, Check, DataFrameSchema

transactions_schema = DataFrameSchema(
    columns={
        "transaction_id": Column(str, unique=True, nullable=False),
        "user_id": Column(int, Check.ge(1), nullable=False),
        "amount_idr": Column(float, Check.in_range(0, 1_000_000_000), nullable=False),
        "currency": Column(str, Check.isin(["IDR", "USD", "SGD"]), nullable=False),
        "created_at": Column("datetime64[ns, UTC]", nullable=False),
    },
    strict=True,   # tolak kolom di luar daftar
    coerce=True,   # coba cast tipe otomatis
)

Versi DataFrameModel yang setara, lebih pendek dan bisa di-subclass:

import pandera.pandas as pa
from pandera.typing import Series
from datetime import datetime

class TransactionsSchema(pa.DataFrameModel):
    transaction_id: Series[str] = pa.Field(unique=True)
    user_id: Series[int] = pa.Field(ge=1)
    amount_idr: Series[float] = pa.Field(in_range={"min_value": 0, "max_value": 1_000_000_000})
    currency: Series[str] = pa.Field(isin=["IDR", "USD", "SGD"])
    created_at: Series[pa.DateTime] = pa.Field()

    class Config:
        strict = True
        coerce = True

# Schema turunan untuk layer gold (menambah kolom hasil enrichment)
class TransactionsGoldSchema(TransactionsSchema):
    user_country: Series[str] = pa.Field(isin=["ID", "SG", "MY"])
    fx_rate_to_usd: Series[float] = pa.Field(gt=0)

Perhatikan bagaimana TransactionsGoldSchema mewarisi seluruh aturan TransactionsSchema tanpa duplikasi. Kalau di kemudian hari kolom currency diperbanyak enum-nya, Anda ubah di parent, dan kedua layer otomatis update. Pola inheritance seperti ini yang saya cari, dan itu tidak ada di YAML-based validator.

Check bawaan dan custom Check untuk aturan bisnis

Pandera menyediakan lebih dari 20 Check bawaan. Cukup untuk 80% kasus. Yang paling sering dipakai: Check.ge/le/gt/lt untuk batas numerik, Check.in_range untuk interval tertutup, Check.isin/notin untuk enum, Check.str_matches untuk regex, Check.str_length untuk panjang string, dan Check.unique_values_eq untuk memaksa satu kolom kategori berisi persis set nilai tertentu (bukan hanya subset).

Untuk aturan bisnis yang tidak masuk ke Check bawaan, tulis Check kustom dengan @pa.check. Check kustom bisa beroperasi di level element (satu nilai) atau level kolom (seluruh Series). Level kolom hampir selalu lebih cepat karena vectorized.

import pandera.pandas as pa
from pandera.typing import Series

class OrdersSchema(pa.DataFrameModel):
    order_id: Series[str] = pa.Field(unique=True)
    subtotal_idr: Series[float] = pa.Field(ge=0)
    discount_idr: Series[float] = pa.Field(ge=0)
    total_idr: Series[float] = pa.Field(ge=0)

    @pa.dataframe_check
    def total_equals_subtotal_minus_discount(cls, df):
        # Toleransi 1 rupiah untuk floating point
        diff = (df["total_idr"] - (df["subtotal_idr"] - df["discount_idr"])).abs()
        return (diff < 1).all()

    @pa.check("discount_idr", name="discount_not_greater_than_subtotal")
    def discount_bounded(cls, discount: Series[float]) -> Series[bool]:
        # Series check: benchmark ~40x lebih cepat dari element-wise di 1M row
        return discount <= discount.index.map(lambda i: 1e12)  # placeholder

Cara validasi Polars LazyFrame dengan Pandera

Sejak versi 0.19, Pandera mendukung Polars sebagai first-class backend. Di 0.22, dukungan LazyFrame lengkap. Validasi digabung ke query plan sehingga bisa berjalan streaming untuk file Parquet berukuran besar tanpa memuat semuanya ke memori. Ini penting kalau Anda sudah bermigrasi dari Pandas ke Polars untuk pipeline yang menangani puluhan juta baris.

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

class EventsSchema(pa.DataFrameModel):
    event_id: Series[str] = pa.Field(unique=True)
    user_id: Series[int] = pa.Field(ge=1)
    event_type: Series[str] = pa.Field(isin=["click", "view", "purchase"])
    ts: Series[pl.Datetime] = pa.Field()

    class Config:
        strict = True

# Validasi LazyFrame: plan validation di-push down ke Polars
lf = pl.scan_parquet("s3://bucket/events/*.parquet")
validated_lf = EventsSchema.validate(lf, lazy=True)
df = validated_lf.collect(streaming=True)

Perbedaan penting dengan backend Pandas: di Polars, Series di-import dari pandera.typing.polars, dan tipe kolom mengikuti dtypes Polars (pl.Datetime, pl.Utf8, pl.Int64, dst.). Sisanya identik. API yang sama, kontrak yang sama, sehingga Anda bisa punya dua versi pipeline yang share schema definition dan hanya beda backend.

Lazy validation: kumpulkan semua error dalam satu run

Default Pandera adalah eager. Begitu satu Check gagal, dia langsung raise SchemaError. Untuk debugging interaktif itu berguna, tapi untuk pipeline batch itu bikin frustrasi. Anda perbaiki kolom pertama, jalankan ulang, ketemu error kolom kedua, perbaiki, jalankan lagi, dan seterusnya. Solusinya adalah lazy=True. Pandera menjalankan semua Check, mengumpulkan semua kegagalan, lalu raise satu SchemaErrors (jamak) dengan laporan lengkap.

import pandera.pandas as pa

try:
    TransactionsSchema.validate(df, lazy=True)
except pa.errors.SchemaErrors as exc:
    # exc.failure_cases: DataFrame berisi kolom, check, index, dan nilai yang gagal
    failures = exc.failure_cases
    print(f"Total failure: {len(failures)}")
    print(failures.head(20))

    # Simpan ke tabel audit untuk investigasi upstream
    failures.to_parquet("s3://bucket/audit/schema_failures/2026-07-10.parquet")

    raise  # tetap fail task

Di pipeline dbt/Airflow saya, saya selalu menulis failure_cases ke tabel audit sebelum re-raise. Alasannya, alert Slack yang muncul di on-call bilang "20.000 baris gagal Check currency_isin" jauh lebih actionable dibanding "SchemaError at column 5". Data engineer on-call bisa langsung query tabel audit dan tahu upstream mana yang mengirim currency baru yang belum kita whitelist.

Integrasi pytest, hypothesis, dan CI

Schema Pandera adalah artefak testable. Anda bisa menulis unit test yang memuat fixture kecil, memvalidasinya, dan memastikan aturan bekerja seperti yang diharapkan. Ini yang saya sebut schema regression test: setiap kali seseorang mengubah schema, test yang relevan gagal supaya reviewer sadar dampak downstream.

# tests/test_transactions_schema.py
import pandas as pd
import pytest
import pandera.pandas as pa
from myproject.schemas import TransactionsSchema

def test_valid_transactions_pass():
    df = pd.DataFrame({
        "transaction_id": ["a", "b"],
        "user_id": [1, 2],
        "amount_idr": [1000.0, 2000.0],
        "currency": ["IDR", "IDR"],
        "created_at": pd.to_datetime(["2026-07-01", "2026-07-02"], utc=True),
    })
    validated = TransactionsSchema.validate(df)
    assert len(validated) == 2

def test_reject_unknown_currency():
    df = pd.DataFrame({
        "transaction_id": ["a"],
        "user_id": [1],
        "amount_idr": [1000.0],
        "currency": ["JPY"],  # tidak dalam whitelist
        "created_at": pd.to_datetime(["2026-07-01"], utc=True),
    })
    with pytest.raises(pa.errors.SchemaError):
        TransactionsSchema.validate(df)

Untuk fuzz testing, Pandera bisa membangkitkan DataFrame contoh dari schema lewat hypothesis. Ini pola yang jarang dipakai orang tapi sangat kuat. Kalau schema bisa membangkitkan data valid, Anda bisa memberi fixture itu ke fungsi transformasi Anda dan memastikan tidak ada exception untuk seluruh domain input.

from hypothesis import given
from myproject.schemas import TransactionsSchema
from myproject.transforms import compute_daily_totals

@given(TransactionsSchema.strategy(size=100))
def test_compute_daily_totals_never_crashes(df):
    result = compute_daily_totals(df)
    assert result["total_amount"].ge(0).all()

Integrasi Pandera dengan dbt, Airflow, dan FastAPI

Sekarang bagian yang paling relevan untuk workflow data engineering harian. Berikut tiga pola integrasi yang saya pakai di production.

1. dbt Python model dengan Pandera

dbt 1.5+ mendukung Python model di Snowpark, BigQuery, dan Databricks. Di dalam function model(), Anda bisa memvalidasi output DataFrame sebelum di-return ke warehouse. Kalau validasi gagal, run dbt gagal, dan itulah yang kita inginkan.

# models/silver/silver_transactions.py
import pandera.pandas as pa
from myproject.schemas import TransactionsSchema

def model(dbt, session):
    dbt.config(materialized="incremental", unique_key="transaction_id")

    raw = dbt.ref("raw_transactions").to_pandas()

    # Transform
    raw["amount_idr"] = raw["amount"].astype(float)
    raw["currency"] = raw["currency"].str.upper()

    # Validate SEBELUM return: hentikan garbage sebelum masuk warehouse
    validated = TransactionsSchema.validate(raw, lazy=True)
    return validated

2. Airflow task dengan schema gate

Untuk pipeline Airflow, saya membungkus validasi di PythonOperator yang berjalan sebelum task ekstraksi ke warehouse. Kalau validasi gagal, task fail, downstream task tidak jalan, dan Slack alert menyebutkan tabel audit yang bisa di-query.

from airflow.decorators import task
import pandera.pandas as pa
from myproject.schemas import TransactionsSchema

@task
def validate_and_load(df_path: str) -> str:
    import pandas as pd
    df = pd.read_parquet(df_path)
    try:
        TransactionsSchema.validate(df, lazy=True)
    except pa.errors.SchemaErrors as e:
        e.failure_cases.to_parquet(f"{df_path}.audit.parquet")
        raise
    return df_path

3. FastAPI endpoint yang memvalidasi request body DataFrame

Kalau Anda menyajikan model ML lewat API, request bisa berisi batch prediksi. Sebelum masuk ke pipeline scikit-learn, validasi bentuknya. Pola ini saya bahas lebih dalam di panduan FastAPI serving scikit-learn di produksi.

from fastapi import FastAPI, HTTPException
import pandas as pd
import pandera.pandas as pa
from myproject.schemas import InferenceRequestSchema

app = FastAPI()

@app.post("/predict")
def predict(payload: dict):
    df = pd.DataFrame(payload["rows"])
    try:
        df = InferenceRequestSchema.validate(df, lazy=True)
    except pa.errors.SchemaErrors as e:
        raise HTTPException(status_code=422, detail=e.failure_cases.to_dict())
    # ...panggil model...
    return {"predictions": [...]}

Pandera vs Great Expectations: perbandingan objektif

Kedua library punya niche masing-masing. Berikut perbandingan yang saya pakai untuk memutuskan mana yang cocok di project baru.

Aspek	Pandera 0.22	Great Expectations 1.0
API utama	Class-based (DataFrameModel) mirip Pydantic	Expectation Suite berbasis config JSON/YAML
Kurva belajar	Rendah (Python developer bisa langsung jalan)	Menengah (perlu paham Datasource, Suite, Checkpoint)
Support DataFrame	Pandas, Polars, PySpark, Modin, Dask	Pandas, Spark, SQL (via SQLAlchemy)
Auto-profiling	Terbatas (schema inference sederhana)	Kuat (data assistant + profiler bawaan)
Data docs UI	Tidak ada (harus dibangun manual)	Ada (HTML docs generation)
Integrasi pytest	Native, sangat cocok untuk CI	Perlu wrapper Checkpoint
Overhead runtime	Rendah (~2–5% pipeline time)	Sedang (setup context per run)
Storage backend	Tidak diperlukan	Perlu (file store atau cloud store)

Ringkasan pilihan. Pakai Pandera kalau tim Anda Python-first, ingin schema di-versioned bersama kode, dan validasi jadi bagian dari test suite. Pakai Great Expectations kalau Anda butuh data docs untuk stakeholder non-teknis, ingin auto-profiling untuk tabel baru, atau tim data quality Anda terpisah dari tim engineering dan lebih nyaman edit config daripada Python. Kedua tools bisa hidup berdampingan. Banyak tim yang saya kenal pakai Pandera di pipeline dan GE untuk validasi post-load di warehouse.

Pola produksi: schema versioning, deprecation, dan backfill

Bagian ini adalah pelajaran dari incident nyata. Schema data akan berubah, entah karena kolom baru ditambah, tipe di-tighten, atau enum di-expand. Kalau Anda naif dan langsung update schema di main branch, semua backfill historis akan gagal karena data lama tidak memenuhi kontrak baru. Berikut tiga pola yang saya wajibkan di tim.

Versi schema per tanggal

Simpan schema di modul yang di-versioned: schemas/v1/transactions.py, schemas/v2/transactions.py. Setiap pipeline job menyebutkan versi schema yang dipakai. Backfill job untuk periode lama menunjuk ke schema versi lama; job harian pakai versi terbaru. Ini kelihatan berat, tapi menyelamatkan banyak jam saat backfill 3 tahun data.

Deprecation window untuk perubahan breaking

Kalau menambah aturan baru (misalnya currency harus isin=["IDR","USD","SGD","MYR"]), jalankan dulu dalam mode warning-only selama 2 minggu. Log baris yang gagal ke tabel audit tanpa fail-hard. Setelah upstream memperbaiki datanya, baru switch ke fail-hard. Pandera tidak punya mode warning bawaan. Trik saya adalah wrap validasi dengan try/except dan log ke tabel audit, lalu conditional raise berdasarkan feature flag.

Backfill-aware validation

Untuk data historis, sering ada baris legit yang melanggar aturan baru (mis. currency JPY pernah dipakai di 2023 sebelum tim JP di-offboard). Tulis schema turunan TransactionsHistoricalSchema(TransactionsSchema) yang meng-override aturan tertentu. Panggil schema historis untuk partisi < tanggal cutoff, schema baru untuk partisi ≥ cutoff. Referensi lengkap ada di dokumentasi resmi DataFrameModel Pandera, dan detail changelog tiap release ada di halaman rilis GitHub Pandera.

Frequently Asked Questions

Apa perbedaan Pandera dan Pydantic?

Pydantic memvalidasi objek Python biasa (dict, class) satu per satu. Pandera memvalidasi DataFrame yang berisi jutaan baris secara vectorized. Untuk API request body, pakai Pydantic; untuk DataFrame ETL, pakai Pandera. Pandera 0.22 menyediakan integrasi Pydantic v2 sehingga DataFrameModel bisa di-serialize ke BaseModel.

Apakah Pandera mendukung Polars LazyFrame secara native?

Ya, sejak Pandera 0.19 dan diperluas di 0.22. Import dari pandera.polars, gunakan Series dari pandera.typing.polars, dan panggil Schema.validate(lazyframe, lazy=True). Validasi di-push ke query plan Polars sehingga bisa jalan streaming untuk file Parquet besar.

Bagaimana cara membuat Pandera mengumpulkan semua error, bukan berhenti di error pertama?

Tambahkan argumen lazy=True pada pemanggilan Schema.validate(df, lazy=True). Pandera akan menjalankan semua Check dan raise satu SchemaErrors (jamak) yang berisi DataFrame failure_cases dengan kolom, index, dan nilai yang gagal, sehingga mudah ditulis ke tabel audit untuk investigasi.

Berapa overhead performa Pandera di pipeline produksi?