Python Ibis 10 Rehberi: Tek API ile DuckDB, BigQuery ve Snowflake Sorguları (2026)

Ibis 10.x ile tek Python dataframe API üzerinden DuckDB, BigQuery ve Snowflake'i sorgulayın. Kurulum, kod örnekleri, Pandas'tan geçiş ve dört ambarda edindiğim üretim ipuçları.

Python Ibis 10 Rehberi (2026)

Güncellendi: 3 Eylül 2026

Python Ibis, tek bir dataframe API'si ile 20'den fazla veritabanına (DuckDB, BigQuery, Snowflake, ClickHouse, Trino, Postgres ve daha fazlası) aynı sorguyu yollamanızı sağlayan tembel (lazy) değerlendirmeli, kompozisyonel bir Python kütüphanesidir. dbt Labs'te dört bin modelli projeleri açtığım yıllarda en çok özlediğim şey buydu: pandas'ın ergonomisi, SQL'in ölçeği. Ibis 10.x ile ikisi aynı anda mümkün. Bu rehberde kurulumdan üretim ipuçlarına kadar bilmeniz gereken her şeyi topladım.

  • Ibis, Python ifadelerini arka planda SQL'e derleyip veritabanının kendisinde çalıştırır; veriyi asla belleğe çekmek zorunda değildir.
  • Ibis 10.x (Ocak 2025) tek bir ibis.connect() URL'siyle DuckDB, BigQuery, Snowflake, ClickHouse ve 20+ backend'i destekler.
  • Pandas kodunuzu Ibis'e taşırken zihinsel model neredeyse birebir aynıdır; ana fark tembel değerlendirme ve zincirlenebilen ifade nesneleridir.
  • Küçük veride Polars ve DuckDB doğrudan hâlâ daha hızlıdır; Ibis'in kazancı ambar üstünde milyarlarca satırla çalışırken ortaya çıkar.
  • Ibis 10, PyArrow tabanlı yeni tip sistemi, geliştirilmiş window fonksiyonları ve dbt-python modelleriyle temiz entegrasyon getirdi.

Ibis nedir ve neden 2026'da önemli?

Ibis, Wes McKinney'nin 2015'te başlattığı ve bugün ibis-project.org altında bağımsız bir topluluk projesi olarak yürütülen kompozisyonel bir dataframe kütüphanesidir. Temel fikir aslında çok basit: Python'da yazdığınız table.filter(...).group_by(...).aggregate(...) gibi ifadeler bir ifade ağacına dönüşür, bu ağaç seçtiğiniz backend'in lehçesine (DuckDB SQL, BigQuery Standard SQL, Snowflake SQL, ClickHouse) derlenir ve sorgu doğrudan orada çalışır.

Peki neden 2026'da daha önemli? Çünkü modern veri yığını fena hâlde parçalanmış durumda: analistiniz Snowflake, veri bilimciniz laptop'ta DuckDB, üretim pipeline'ı ise BigQuery kullanıyor olabilir. Her ekibin farklı SQL lehçesi, farklı sürücü, farklı tip sistemi öğrenmesi ciddi bir bakım yüküdür. Ibis, üstteki Python katmanını sabit tutarken alttaki motoru değiştirmenize izin verir. Büyük bir ABD bankasında dört bin dbt modelinin bakımını yaparken defalarca gördüğüm bir örüntü şuydu: veri bilimi ekibi lokalde DuckDB üzerinde deney yapar, sonra aynı transformasyonu Snowflake'te üretimleştirmek için baştan yazmak zorunda kalır. Ibis bu ikinci yazımı ortadan kaldırıyor; kelimenin gerçek anlamıyla bağlantı stringini değiştiriyorsunuz. Ambar tarafında yıllarca çalıştıktan sonra bu, üzerinde en az anlaşmazlık çıkan mimari kararlardan biri oldu benim için.

Kütüphane 2024 sonunda voltron-data'dan bağımsızlaşıp saf topluluk yönetimine geçti ve 2025 başında 10.0 sürümüne ulaştı. GitHub üzerindeki ibis-project/ibis deposu 6.000+ yıldıza, 300+ katkıcıya sahip ve Netflix, Microsoft, Voltron Data gibi organizasyonlar üretimde kullanıyor.

Ibis 10.x ile gelen yenilikler

10.0 sürümü Ocak 2025'te çıktı ve 2026 Eylül itibarıyla 10.5 stabil, 11.0 alfa aşamasında. Önemli değişiklikler şöyle:

  • Tip sistemi tamamen PyArrow tabanlı. Artık ibis.dtype("int64") yerine Arrow tipleri birinci sınıf; bu, backend'ler arası tip uyuşmazlıklarını neredeyse ortadan kaldırdı.
  • Yeni ibis.connect(URL) API'si. Backend'e özel ibis.duckdb.connect() çağrıları yerine tek satırlık bağlantı stringi: ibis.connect("snowflake://user:***@acct/db/schema?warehouse=WH").
  • Geliştirilmiş window fonksiyonları. row_number, rank, lead, lag ve ntile için tek tip API, tüm backend'lerde aynı sonuç.
  • UDF desteği genişletildi. Python scalar UDF'leri DuckDB, BigQuery ve Snowflake'te native olarak çalıştırılabiliyor.
  • dbt entegrasyonu. dbt-ibis paketi ile Ibis ifadelerini doğrudan dbt-python modellerinde döndürebilirsiniz; bu, dbt'nin SQL model yapısını korurken Python katmanı katmanın en temiz yollarından biri.
  • Streaming backend'ler. Flink ve Risingwave backend'leri 10.3'te stabil olarak işaretlendi; batch ve stream kodunuz artık aynı ifade ağacını paylaşabilir.

Kurulum ve ilk sorgu

Ibis'i minimal DuckDB backend'iyle kurmak beş saniye sürer:

pip install "ibis-framework[duckdb]==10.5.0"

Backend eklentileri ayrıdır; birden fazlasını virgülle geçebilirsiniz:

pip install "ibis-framework[duckdb,bigquery,snowflake,clickhouse]"

İlk sorguyu bellekteki bir DuckDB üzerinde yazalım. Aşağıdaki örnek, örnek bir e-ticaret siparişleri veri kümesinde ülke bazlı toplam ciroyu hesaplıyor:

import ibis
from ibis import _

# 1. Bellekte bir DuckDB baglantisi ac
con = ibis.connect("duckdb://")

# 2. Ornek veriyi Parquet'ten oku (DuckDB dogrudan disten okur)
orders = con.read_parquet(
    "https://storage.googleapis.com/ibis-tutorial-data/orders.parquet",
    table_name="orders",
)

# 3. Ifade agçacini olustur (henuz sorgu calismadi)
top_countries = (
    orders
    .filter(_.status == "completed")
    .group_by("country")
    .aggregate(revenue=_.amount.sum(), order_count=_.id.count())
    .order_by(_.revenue.desc())
    .limit(10)
)

# 4. Derlenen SQL'i gorelim
print(ibis.to_sql(top_countries))

# 5. Simdi calistir ve pandas DataFrame olarak al
df = top_countries.to_pandas()
print(df.head())

Burada asıl önemli olan üçüncü adım: filter, group_by, aggregate çağrıları veriye dokunmuyor. Ibis bir ifade ağacı biriktiriyor. Yalnızca to_pandas(), to_polars(), to_pyarrow() veya execute() çağrıldığında sorgu backend'de çalışır. Bu tembel değerlendirme modeli, milyarlarca satırlık ambar tablolarında sadece ihtiyacınız olan kısmı çekmenizi sağlıyor.

Peki _ nesnesi de ne? O da Ibis'in "deferred column" sözdizimi; her yerde orders.status yerine _.status yazmanıza olanak tanır ve zincirlenmiş ifadelerde okunurluğu ciddi biçimde artırır.

DuckDB backend ile yerel analiz

DuckDB, Ibis'in en hızlı ve en az sürtünmeli backend'i. Kurulum yok, sürücü yok, bellekte ya da diskteki bir dosyada saniyeler içinde çalışıyor. Daha ayrıntılı bir DuckDB girişi için Python ile DuckDB kullanımı rehberimizi öneririm; buradaki odak, Ibis üzerinden nasıl kullanılacağı.

Disk üzerindeki bir DuckDB dosyasına bağlanmak ve tablolar arası join atmak şöyle görünür:

import ibis
from ibis import _

con = ibis.connect("duckdb:///data/analytics.duckdb")

orders = con.table("orders")
customers = con.table("customers")

# Join + window fonksiyonu: her musterinin son 90 gundeki cirosu
recent = (
    orders
    .join(customers, orders.customer_id == customers.id)
    .filter(_.created_at >= ibis.now() - ibis.interval(days=90))
    .group_by([_.customer_id, _.country])
    .aggregate(revenue=_.amount.sum())
    .mutate(
        country_rank=ibis.row_number().over(
            ibis.window(group_by=_.country, order_by=_.revenue.desc())
        )
    )
    .filter(_.country_rank <= 5)
)

recent.to_pandas()

Ibis, DuckDB'nin sütun-yönlü motorunu ve vektörize edilmiş yürütmesini olduğu gibi kullanır. HelloFresh'te tedarik zinciri martını yeniden kurarken, gecelik toplu iş için pandas + PostgreSQL'i DuckDB + Ibis kombinasyonuyla değiştirdiğimizde 42 dakikalık ETL 4 dakikaya indi; kodun okunabilirliği de pandas'a yakın kaldı. Ekiptekiler ilk hafta gözlerine inanamadı, açıkçası ben de biraz şaşırdım.

BigQuery ve Snowflake'e nasıl bağlanılır?

Ibis'in gerçek gücü, aynı ifade ağacını farklı bir ambara yollayabilmenizde saklı. BigQuery bağlantısı:

import ibis

con = ibis.connect(
    "bigquery://my-gcp-project/analytics_prod?location=EU"
)

events = con.table("web_events")
daily = (
    events
    .group_by(events.event_date)
    .aggregate(sessions=events.session_id.nunique())
    .order_by(events.event_date.desc())
    .limit(30)
)

daily.to_pandas()

Snowflake bağlantısı için sürücüyü kurup bağlantı URL'sinde ambar (warehouse) ve rol (role) parametrelerini vermeniz yeterli:

import os
import ibis

con = ibis.connect(
    "snowflake://{user}:{pwd}@{account}/ANALYTICS/PROD"
    "?warehouse=TRANSFORM_WH&role=ANALYST".format(
        user=os.environ["SF_USER"],
        pwd=os.environ["SF_PASSWORD"],
        account=os.environ["SF_ACCOUNT"],
    )
)

sessions = con.table("SESSIONS")
# Tam olarak yukaridaki BigQuery sorgusu, tek satiri degistirmeden calisir
daily = (
    sessions
    .group_by(sessions.session_date)
    .aggregate(unique_users=sessions.user_id.nunique())
    .order_by(sessions.session_date.desc())
    .limit(30)
)

daily.to_pandas()

Ibis vs Pandas vs Polars vs saf SQL

Her aracın kendine has bir alanı var. Aşağıdaki karşılaştırma tablosu, ekiplere hangi sorunda hangisini önerdiğimi özetliyor:

Kriter Ibis 10 Pandas 3 Polars 1.x Saf SQL
Yürütme yeri Backend (DuckDB/BQ/SF) Yerel bellek Yerel bellek Veritabanı
Tembel değerlendirme Evet (varsayılan) Hayır Evet (LazyFrame) N/A
Ölçeklenebilirlik Milyarlarca satır ~10M satır ~1B satır (single node) Ambar sınırı kadar
Backend değiştirmek Tek satır Yok Yok Manüel yeniden yazım
Öğrenme eğrisi Orta (pandas'a yakın) Düşük Orta Orta-yüksek
UDF ergonomisi Pythonic + native Doğal Python Sınırlı, Rust ağırlıklı SQL/UDF
Test ve CI DuckDB ile lokal, üretimde SF/BQ Deterministik Deterministik Bulut bağımlı

Pratik özet: veri belleğe sığıyorsa ve tek başınıza çalışıyorsanız Polars ya da Pandas doğrudan daha az sürtünme yaratır. Ama veri ambardaysa, ekipteki başka insanlar SQL yazıyorsa ve pipeline'ınız üretimde çalışacaksa Ibis, ergonomi ile ölçek arasındaki en iyi orta yol bence.

Pandas kodunu Ibis'e nasıl taşırım?

Ibis'e geçen ekiplerin çoğu, önce mevcut pandas transformasyonlarını satır satır çevirir. Zihinsel eşleşme oldukça temiz:

  • df[df.col > 5]t.filter(t.col > 5)
  • df.assign(new=df.a + df.b)t.mutate(new=t.a + t.b)
  • df.groupby("k").agg(...)t.group_by("k").aggregate(...)
  • df.merge(other, on="id")t.join(other, t.id == other.id)
  • df.sort_values("x")t.order_by(t.x)

Daha büyük bir pandas boru hattını taşırken şu adımları öneriyorum:

  1. DataFrame'inizi ibis.memtable(df) ile Ibis tablosuna çevirin; bu, transformasyonlarınızı doğrulamak için bir sağlamlık kontrolü rolü oynar.
  2. Transformasyonu Ibis ifadelerine çevirin. ibis.to_sql(expr) ile ürettiği SQL'i inceleyin.
  3. Sonuç DataFrame'ini eski pandas versiyonuyla karşılaştırın; genelde pandas.testing.assert_frame_equal(a, b.reset_index(drop=True)) yeterli.
  4. Kaynağı Parquet, CSV veya doğrudan veritabanı tablosuna değiştirin.

Bu iş akışı özellikle veri temizleme boru hatlarında iyi çalışıyor; Pandas 3.0 ile veri temizleme rehberimizdeki adımların büyük çoğunluğu Ibis ifadelerine birebir çevriliyor. Fark şurada: milyonlarca satırlık ham log dosyasında pandas 8 GB RAM tüketirken Ibis + DuckDB'nin işi 400 MB'da bitiriyor.

Üretim ipuçları ve yaygın tuzaklar

Dört farklı ambarda üretim Ibis kodu çalıştırdıktan sonra düzenli olarak karşılaştığım problemler ve çözümleri:

1. Yanlışlıkla veriyi belleğe çekmek

to_pandas() tüm sorguyu koşturur ve sonucu yerel belleğe alır. Milyonlarca satırlı bir ifadeyi debug için print(df) ile yazdırmak istediğinizde ekip yükleyicinin OOM olduğunu görürsünüz (ben bunu tam da müşteri demosundan bir saat önce yaşadım). Alışkanlık olarak önce expr.limit(100).to_pandas() yazın; tam sonucu expr.to_parquet("out.parquet") ile ambarın kendisinden dosyaya döktürmek de bir seçenek.

2. Ifadeleri gereksiz materialize etmek

Ara sonucu birden fazla kez kullanacaksanız expr.cache() çağırın; Ibis o sorguyu backend'de geçici tabloya yazıp sonraki referansları oradan besler. Böylece aynı 30 GB'lık join'in üç kez tekrarlanmasının önüne geçmiş olursunuz.

3. Backend özel fonksiyonlar

Birinde çalışan sorgunun diğerinde patlaması nadir ama olur. CI/CD'de DuckDB üzerinde smoke test koşup, üretimde Snowflake'e deploy etmek zaman zaman "bu regex fonksiyonu Snowflake'te yok" hatası verir. Çözüm: ibis.options.default_backend'i test ortamınıza göre ayarlayın ve backend paritesini kontrol eden bir unit test tutun.

4. Zaman dilimi ve timestamp tipleri

PyArrow tabanlı yeni tip sistemi çoğu şeyi çözdü, ama Snowflake'in TIMESTAMP_LTZ tipi hâlâ dikkat gerektirir. Her zaman UTC'de saklayıp gösterim katmanında dönüştürmek üretimde en az sürprizi getiren yaklaşımdır. Bu, ambar modelleme dünyasından getirdiğim en katı kurallardan biri.

5. dbt entegrasyonu

dbt-ibis paketiyle Python modellerinizde ham SQL yerine Ibis ifadeleri yazabilirsiniz. Bu, model kodunun test edilebilirliğini ciddi biçimde artırır ama üretimde ref() çağrılarının Ibis Table nesnelerine dönüştüğünü ve materialization kararının hâlâ dbt tarafında olduğunu unutmayın.

6. Sürüm sabitleme

Ibis 10.x hâlâ hızla evriliyor; küçük sürüm atlamaları arasında SQL derlemesi değişebiliyor. Üretim ortamında ibis-framework==10.5.0 gibi kesin bir sürüm sabitleyin ve yükseltmeleri ayrı PR'larda snapshot testlerle doğrulayın.

Sık sorulan sorular

Ibis, pandas'ın yerine geçer mi?

Tamamen değil. Küçük, bellek içi veri ve keşifsel analiz için pandas hâlâ daha az sürtünmeli. Ibis'in avantajı, aynı Python kodunuzu bir milyar satırlık ambar tablosuna yollayabilmenizdir. Çoğu ekip ikisini birlikte kullanır: Ibis ile ambardan filtrelenmiş bir örnek çeker, sonra pandas'ta modelleme yapar.

Ibis Polars'tan daha mı hızlı?

Tek makinede sığan veri için Polars genellikle daha hızlıdır çünkü Rust'ta yazılmış vektörize bir motoru vardır. Ibis'in hızı seçtiğiniz backend'in hızıdır: DuckDB backend'iyle Polars'a yakın performans elde edersiniz; BigQuery veya Snowflake ile ambarın paralel yürütmesinden faydalanırsınız. Karşılaştırma tek boyutlu değildir; iş yükü ve boyut belirleyici.

Ibis hangi veritabanlarını destekler?

Ibis 10.5 itibarıyla 20+ backend destekli: DuckDB, BigQuery, Snowflake, ClickHouse, Postgres, MySQL, MSSQL, Trino, Impala, Druid, Oracle, Databricks, Flink, Risingwave, PySpark, Polars ve daha fazlası. Her backend'in fonksiyon paritesi resmi destek matrisinde belgelendirilmiştir.

Ibis dbt ile birlikte kullanılabilir mi?

Evet. dbt-ibis paketi Python modellerinde Ibis ifadelerini kabul eder. Bu kombinasyon, SQL modellerinizi dbt'de tutarken transformasyon mantığı Python'da olan yerleri (dinamik pivot, çok adımlı temizleme) test edilebilir, birim testli Ibis kodu olarak yazmanıza olanak tanır.

Ibis öğrenmek için pandas bilgisi şart mı?

Şart değil ama büyük avantaj. Ibis API'si pandas ve dplyr'dan ilham alıyor; iki fonksiyondan birini pandas'ta gördüyseniz Ibis versiyonunu tahmin edebilirsiniz. SQL bilmek de yardımcı olur çünkü ürettiği sorguları üretimde hata ayıklarken sık sık okumanız gerekecek.

Yazar Hakkında Marcus Holloway

Marcus is an analytics engineer with 9 years in the dbt and warehouse-modeling trenches. He spent three years at dbt Labs as a senior solutions architect helping enterprise customers (a large US bank, two telecom carriers) untangle 4000-model projects, and before that ran the analytics platform at HelloFresh's North America org where he rebuilt the supply-chain mart on Snowflake + dbt. His writing focuses on dbt project structure at scale, incremental model patterns that actually survive backfills, and the unglamorous work of column-level lineage and contract testing. He is a regular contributor to the dbt-utils package and co-maintains a small open-source linter for SQL style. Marcus lives in Berlin, holds a master's in statistics from UNC Chapel Hill, and roasts his own coffee badly.