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, 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:
İ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:
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ı:
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:
Daha büyük bir pandas boru hattını taşırken şu adımları öneriyorum:
DataFrame'inizi ibis.memtable(df) ile Ibis tablosuna çevirin; bu, transformasyonlarınızı doğrulamak için bir sağlamlık kontrolü rolü oynar.
Transformasyonu Ibis ifadelerine çevirin. ibis.to_sql(expr) ile ürettiği SQL'i inceleyin.
Sonuç DataFrame'ini eski pandas versiyonuyla karşılaştırın; genelde pandas.testing.assert_frame_equal(a, b.reset_index(drop=True)) yeterli.
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.
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.
Marimo, Python notebook'larını reaktif bir hesaplama grafına dönüştürür: gizli hücre durumu yok, saf .py dosyaları, tek komutla web uygulaması. FastAPI arka planından gelen bir bakışla Marimo 0.10'un veri bilimi iş akışlarınızı nasıl sadeleştirdiğini gösteriyorum.
Great Expectations 1.x ile Python veri boru hatlarınızı pandas ve Airflow üzerinden otomatik test edin. Fluent API, Checkpoint kurulumu ve Data Docs paylaşımı için üretim odaklı örnekler.
ONNX Runtime ile PyTorch ve scikit-learn modellerini üretimde 2-5x hızlı, %85 daha az bellekle sunun. INT8 kuantalama, execution provider seçimi ve FastAPI servisi gerçek benchmark rakamlarıyla.