BigQuery’de Sorguların Çalışma Prensibi ve Performansın Önemi

Modern kurumlar her gün terabaytlarca, hatta petabaytlarca veri üretiyor. Bu ölçekteki veri kümeleri üzerinde analitik işlemler gerçekleştirmek artık yalnızca veriyi depolamaktan ibaret değil. Asıl mesele, karmaşık sorguları düşük gecikme süreleriyle ve maliyetleri kontrol altında tutarak verimli bir biçimde çalıştırabilmektir.

Geleneksel veri ambarları, depolama ve hesaplama kaynaklarını birbirine sıkı sıkıya bağlar. Veri büyüdükçe, yalnızca ek hesaplama gücüne ihtiyaç duyulsa bile kurumlar genellikle tüm altyapıyı ölçeklendirmek zorunda kalır. Büyük birleştirme (JOIN) işlemleri, toplulaştırmalar (aggregations) ve düzensiz veri dağılımları da sorgu yürütmeyi yavaşlatan ve kaynakları israf eden darboğazlar oluşturabilir.

BigQuery, depolamayı hesaplamadan ayıran, SQL yürütmeyi otomatik olarak paralelleştiren ve kaynakları iş yüküne göre dinamik olarak tahsis eden dağıtık bir yürütme motoru aracılığıyla bu zorlukların üstesinden gelir. Bu mimarinin nasıl çalıştığını anlamak; verimli veri modelleri tasarlamak, performanslı SQL yazmak ve yavaş ya da maliyetli sorgulardaki sorunları gidermek için kritik önem taşır.

Bu yazıda, BigQuery’nin arka planda sorguları nasıl çalıştırdığını, veri çarpıklığı (data skew) gibi sorunların performansı neden etkilediğini ve yürütme verimliliğini önemli ölçüde artırabilecek optimizasyon tekniklerini inceleyeceğiz.

BigQuery’nin Dağıtık Mimarisi

BigQuery’nin mimarisi temel olarak depolama ve hesaplama gücünün birbirinden ayrılmasına dayanır. Bu sayede her iki servisin birbirinden bağımsız olarak ölçeklenmesi ve kaynakların verimli bir şekilde tahsisi mümkün olur.

Bu mimari birçok avantaj sağlar:

• Depolama ve hesaplama bağımsız olarak ölçeklenebilir.
• Birden fazla kullanıcı aynı veri kümelerini eş zamanlı olarak sorgulayabilir.
• Hesaplama kaynakları yalnızca ihtiyaç duyulduğunda tahsis edilir.
• İş yükleri altyapı yönetimi gerektirmeden izole kalır.

Bir sorgu çalıştırdığınızda, BigQuery bunu yürütme aşamalarından oluşan ve kendi içinde özel görevler içeren bir işe dönüştürür. Hesaplama, slot adı verilen hesaplama birimlerinden oluşan bir küme üzerine dağıtılır. Yönetici düğüm (primary node), bu slotların durumunu yöneterek ve bunları her yürütme aşamasına dinamik olarak tahsis ederek orkestrasyonu gerçekleştirir.

Örneğin, standart bir toplulaştırma sorgusu birkaç aşamadan geçer:

Aşama 1 (Girdi ve Filtreleme)

İlk aşamada veriler dağıtık depolama katmanından okunur. Bu aşamada BigQuery, yürütme işlem hattına giren veri miktarını en aza indirmeye çalışır. Bunun için aşağıdaki optimizasyonları uygular:

• Bölümleme budamasını (partition pruning) uygulamak
• Kümeleme (clustering) meta verilerini kullanmak
• Filtreleri olabildiğince depolamaya yakın konuma itmek (pushdown)
• Yalnızca gerekli sütunları okumak

🌟 Bu aşamada taranan veri miktarını azaltmak, hem yürütme süresini hem de sorgu maliyetini doğrudan azaltır. İsteğe bağlı sorgularda fiyatlandırma işlenen bayt miktarına dayandığından, bu yaklaşım bütçe optimizasyonuna doğrudan katkı sağlar.

Aşama 2 (Toplulaştırma / Yeniden Dağıtma)

Yeniden dağıtma (shuffle) aşaması, en maliyetli analitik işlemlerin gerçekleştirildiği aşamadır. Sorgu aşağıdaki gibi işlemleri içerdiğinde:

• GROUP BY
• DISTINCT
• Büyük JOIN işlemleri
• Pencere (Window) fonksiyonları

🌟 BigQuery aynı anahtarı paylaşan satırların birlikte işlenmesi için verileri slotlar arasında yeniden dağıtmalıdır. Bu yeniden dağıtıma shuffle adı verilir. Gerekli olmasına rağmen, verilerin Google’ın dahili ağı üzerinden taşınmasını gerektirdiği için en çok kaynak tüketen aşamalardan biridir.

Aşama 3 (Çıktı)

Her bir slot kendisine atanan veriyi işledikten sonra, ara sonuçlar birleştirilerek kullanıcıya döndürülen nihai çıktı oluşturulur.

🌟 Tabloları birleştirirken BigQuery, BROADCAST join (verilerin tüm slotlara gönderildiği daha küçük veri kümeleri için kullanılır) ile SHUFFLE join (her iki tablonun da shuffle işleminden geçirildiği büyük veri kümeleri için kullanılır) arasında akıllıca bir seçim yapar.

Gizli Performans Darboğazı: Veri Çarpıklığı (Data Skew)

Sorgu performansının en büyük gizli düşmanlarından biri, toplulaştırma işlemlerini ciddi şekilde etkileyen düzensiz veri dağılımı, yani veri çarpıklığıdır.

Örnek:

country

US      350 million rows
UK      20 million rows
Germany 15 million rows
NULL    900 million rows

Shuffle aşamasında, aynı anahtara sahip her satır aynı slot tarafından işlenmelidir.

Bir anahtar yüz milyonlarca kayıt içerirken diğerleri yalnızca birkaç bin kayıt içeriyorsa, bir slot aşırı yüklenirken kalan slotlar işlerini hızlıca bitirip atıl durumda bekler. Paralel yürütme yerine, tüm sorgu aşırı yüklenmiş tek bir işlemci birimi (worker) beklemek zorunda kalır.

BigQuery Nasıl Yanıt Verir?

BigQuery, yürütme sırasında iş yükü dağılımını sürekli olarak izler. Bir slot aşırı yüklenirse, optimizasyon motoru işi ek slotlara yeniden dağıtmak için otomatik olarak bir yeniden bölümleme (repartition) aşaması ekleyebilir. Buna karşılık, çok sayıda slot yalnızca küçük miktarda veri aldığında, BigQuery işi birleştirmek ve verimliliği artırmak için bir birleştirme (coalesce) aşaması uygulayabilir.

Bu uyarlanabilir optimizasyonlar yürütmeyi iyileştirse de, yine de ek veri hareketine yol açar ve slot tüketimini artırır. Çarpıklığı önlemek, BigQuery’nin bunu yürütme sırasında düzeltmesine izin vermekten neredeyse her zaman daha verimlidir.

Yürütme Sırasında Veri Çarpıklığı Nasıl Tespit Edilir?

• Shuffle edilen bayt miktarının işlenen bayt miktarını aşması: Bu durum, slotların aşırı yüklendiğini ve BigQuery’nin okuduğu veriden daha fazlasını taşımak zorunda kaldığını gösterir.
• Ortalama ve maksimum süre arasındaki farkın yüksekliği: Slotlar arasındaki ortalama hesaplama süresi ile maksimum hesaplama süresi arasındaki belirgin fark, güçlü bir şekilde veri çarpıklığına işaret eder.
• Sorgunun aşırı slot süresi tüketmesi: Bu, yavaş yürütmeye işaret eder ve eş zamanlı çalışan sorguları olumsuz etkileyebilir.

Gelişmiş Optimizasyon Teknikleri

“Kaynak Aşıldı” (Resources Exceeded) hatalarından kaçınmak ve slot süresini en aza indirmek için faydalanabileceğiniz teknik optimizasyon stratejilerine göz atalım.

1. Şema ve Girdi Optimizasyonu

• Bölümleme (Partitioning) ve Kümeleme (Clustering): BigQuery’nin okuması gereken veri miktarını sınırlamak için her zaman bölümlemeden faydalanın. İyi bölümlenmiş bir tablo, erken bir filtre görevi görür ve maliyetli tam tablo taramalarını (full table scan) önler.
• İç İçe ve Tekrarlanan Alanlar (Nested and Repeated Fields): Maliyetli JOIN ve GROUP BY işlemleri gerektiren yüksek derecede ayrıntılı, benzersiz olmayan sütunlara güvenmek yerine, iç içe ve tekrarlanan alanları (ARRAY ve STRUCT gibi) kullanın. Bu, bire-çok ilişkileri bire-bir ilişkilere dönüştürerek shuffle edilen bayt miktarını ve tüketilen slot süresini ciddi ölçüde azaltır.
• Erken Filtreleyin ve SELECT * İfadesinden Kaçının: Veri alımını erkenden sınırlamak için WHERE yan tümcelerini kullanın. Verileri keşfetmek için SELECT * çalıştırmak yerine, yerel önizleme (Preview) sekmesini kullanın.

2. Sorgu Hesaplaması ve Toplulaştırma

• Toplulaştırmayı Geç ve Seyrek Yapın: Toplulaştırma işlemleri, verilerin slotlar arasında yeniden dağıtılmasını (shuffle) gerektirdiği için hesaplama açısından maliyetlidir. Bu nedenle mümkün olduğunca gereksiz ara toplulaştırmalardan kaçının ve toplulaştırma işlemlerini yalnızca en dış sorguda gerçekleştirerek slot tüketimini ve sorgu yürütme süresini azaltın.
• Yaklaşık Fonksiyonlar Kullanın: Kesin hassasiyet şart değilse, standart sayma fonksiyonlarını APPROX_* karşılıklarıyla (ör. APPROX_COUNT_DISTINCT) değiştirin. Bu fonksiyonlar genellikle kesin sayının %1’i dahilinde sonuç verir, ancak shuffle edilen bayt miktarını ve yürütme süresini önemli ölçüde azaltır.
• ORDER BY İfadesini Optimize Edin: LIMIT kullanmadan bir ORDER BY yan tümcesi yerleştirmek, çıktı aşamasındaki tek bir slotu nihai sıralamayı yapmaya zorlar ve muazzam bir hesaplama yükü yaratır. Bireysel slotların verileri son aşamaya aktarmadan önce ara sıralamalar yapabilmesi için ORDER BY ifadesini her zaman bir LIMIT ile eşleştirin.

3. SQL Fonksiyon Verimliliği

• Veri Tipleri Önemlidir: INT64 veya BOOL gibi sayısal/mantıksal veri tipleri üzerinde filtreleme yapmak, STRING veya BYTES üzerinde filtreleme yapmaktan belirgin şekilde daha hızlıdır.
• Özel UDF’ler Yerine Standart SQL: JavaScript UDF’leri yerine standart SQL fonksiyonlarını tercih edin. Ayrıca, daha basit bir fonksiyon yeterliyse aşırı karmaşık fonksiyonlardan kaçının. Örneğin, yalnızca basit joker karakter (wildcard) eşleştirmesine ihtiyacınız varsa LIKE kullanmak, REGEXP_CONTAINS kullanmaktan hesaplama açısından daha ucuz ve hızlıdır.
• Filtre Sıralaması: Bir WHERE yan tümcesi yazarken, maliyetli fonksiyonları değerlendirmeden önce ilgisiz satırları elemek için en seçici ifadeyi ilk sırada belirtin.

Sorgu Yürütmenin Ötesinde

BigQuery, geleneksel analitik veritabanlarının ötesine geçerek gelişmeye devam ediyor.

Sorgu optimizasyon motoru, gelecekteki sorgu planlarını otomatik olarak iyileştirmek için giderek daha fazla yürütme geçmişine ve tablo istatistiklerine dayanmaktadır. Aynı zamanda BigQuery ML, vektör araması, sürekli sorgular (continuous queries), Apache Iceberg desteği ve Gemini Enterprise Agent Platform ile yerel entegrasyon gibi yetenekler, kurumların makine öğrenmesi ve üretken yapay zeka iş akışlarını doğrudan verilerinin bulunduğu yerde oluşturmalarına olanak tanır.

BigQuery hakkındaki önceki blog yazılarımıza göz atın 👇

BigQuery’de Üretken Yapay Zeka ve Makine Öğrenmesi: Hangi Yenilikler Var?

BigQuery Studio ile Gelişmiş Veri Analitiği ve Yapay Zeka Süreçlerini Tek Platformda Yönetin

Sonuç ve Değerlendirme

BigQuery’nin dağıtık mimarisi, kurumların devasa veri kümelerini dikkate değer bir hızla analiz etmesine olanak tanır; ancak en iyi performansı elde etmek için arka planda neler olup bittiğini anlamak gerekir. Sorgu yürütmeden slot tahsisine, shuffle işlemlerinden veri çarpıklığına kadar bu kavramlar, daha verimli SQL iş yükleri tasarlamanıza ve hem performansı hem de maliyeti optimize etmenize yardımcı olabilir.

Veri platformunuzu modernize etmek, BigQuery performansını artırmak veya Google Cloud’un en yeni veri analitiği ve yapay zeka yeteneklerinden yararlanmak istiyorsanız, BigQuery ve Google Cloud’un veri ve yapay zeka yolculuğunuzu nasıl hızlandırabileceğini keşfetmek için bizimle iletişime geçin.