Snowflake'te kredi tüketimini ve sorgu süresini düşürmek
Snowflake'te maliyet ve performans iyileştirme: warehouse boyutlandırma, auto-suspend, mikro bölüm ve kümeleme, önbellek ve kaynak izleme yöntemleri.
Maliyet nereden oluşur? Önce ölçmek
Snowflake'te maliyetin ana kalemi hesaplama, yani sanal ambarların (virtual warehouse) çalıştığı süredir. Bunun yanında depolama ve bazı hizmetlerin ayrı kalemleri bulunur. Optimizasyon işi, önce bu kalemlerin hangisinin faturada ağır bastığını görmekle başlar. Hangi ambar, hangi kullanıcı ve hangi sorgu grubu ne kadar kredi tüketiyor sorusunun yanıtı olmadan yapılan iyileştirme tahmine dayanır.
Snowflake'in kendi dokümantasyonu da maliyet için şu yaklaşımı önerir: hesapta optimizasyon önerileri veren araçları kullanmak ve bulut hizmetleri kullanımını ayrıca ele almak. Sorgu geçmişi ve kullanım görünümleri üzerinden ambar bazlı bir tüketim tablosu çıkarmak, işe başlamanın en sağlam yoludur.
Önemli nokta, maliyetle performansın çoğu zaman aynı yöne çekmesidir. Sorgu daha kısa sürede biterse ambar daha kısa süre çalışır. Bu yüzden iyi bir optimizasyon, sorguyu hızlandıran çözümleri öncelikle arar.
Warehouse boyutlandırma: büyük her zaman hızlı değildir
Ambar boyutu, sorgu hızını belirleyen ana ayarlardan biridir ama her sorgu büyük ambardan fayda görmez. Dokümantasyon, boyutun sorgunun büyüklüğüne ve karmaşıklığına uydurulmasını, küçük ve basit sorguların büyük ambardan genellikle kazanç sağlamadığını belirtir. Faturalandırma saniye bazlı olduğu için farklı boyutları aynı sorgu kümesiyle denemek ve küçültmek mümkündür.
Pratik yöntem şudur: temsil edici sorguları farklı boyutlarda çalıştırıp süre ve kredi tüketimini kıyaslamak. Bir noktadan sonra boyut büyüdükçe süre aynı oranda kısalmaz; bu eşikten sonrası maliyeti artırır.
Boyutlandırma ile eşzamanlılığı karıştırmamak gerekir. Çok sayıda kullanıcı ya da sorgu aynı anda geldiğinde sorgular kuyrukta bekliyorsa, çözüm ambarı büyütmek değil, ek ambar ya da çok kümeli ambardır. Dokümantasyon, yeniden boyutlandırmanın eşzamanlılık sorunları için tasarlanmadığını açıkça söyler. Çok kümeli ambar, Enterprise ve üzeri sürüm gerektirir.
Auto-suspend ve boşta bekleme maliyeti
Çalışan ama iş yapmayan ambar, en kolay kaçınılan kayıptır. Auto-suspend ayarı, belirli bir boşta kalma süresinden sonra ambarı otomatik durdurur. Dokümantasyon, boşta bekleme ücretinden kaçınmak için düşük bir değer önerir.
Burada denge vardır. İş yükünüzde sorgular arasında kısa boşluklar varsa, ambar sürekli durup yeniden başlayabilir ve her başlatmanın minimum bir ücret süresi vardır. Ambar durunca önbelleği de düşer; yeniden başladığında sorgular önbellek yeniden ısınana kadar yavaş çalışabilir. Bu nedenle ayar, iş yükünün boşluk desenine göre seçilir: aralıklı ve düzensiz kullanımlarda kısa süre, yoğun ve sürekli iş yüklerinde daha uzun ya da kapatılmış bir süre değerlendirilir.
Ambarları iş yüküne göre ayırmak da yardımcıdır. Ayrı bir ambarda çalışan raporlama, veri yükleme ve keşif sorguları, farklı auto-suspend ve boyut ayarlarıyla yönetilebilir.
Mikro bölümler, budama ve kümeleme
Snowflake tablo verisini otomatik olarak mikro bölümlere ayırır. Her mikro bölüm, sütun değer aralığı gibi meta veri tutar. Sorgu çalışırken Snowflake bu bilgiyi kullanarak filtreye uymayan mikro bölümleri hiç okumaz; bu işleme budama denir. Ne kadar çok bölüm atlanırsa, o kadar az veri okunur ve sorgu o kadar kısa sürer.
Budamanın verimi, verinin filtre kolonlarına göre nasıl dizildiğine bağlıdır. Veri tarih gibi bir boyuta göre sıralıysa, o boyuta göre filtreleyen sorgular çok sayıda bölümü atlayabilir. Veri yükleme sırası bu sıralamayı belirler.
Kümeleme anahtarı (clustering key), büyük tablolarda bu sıralamayı bilinçli olarak korumak için kullanılır. Dokümantasyona göre kümeleme en çok, çok büyük ve filtre kolonlarına göre kısmen sıralı ya da hiç sıralı olmayan tablolarda fayda sağlar; sorgu performansının zamanla bozulması, anahtar gereğinin işaretidir. Kümeleme kendi başına ek işlem ve maliyet getirdiği için her tabloya uygulanmaz; önce sorgu profilinde budama oranına bakılır.
Sorgu yazımı ve önbellek katmanları
Sorgu profili, hangi adımın zaman harcadığını gösterir. Yaygın bulgular: gereksiz tüm sütunları okumak (SELECT *), filtreyi geç uygulamak, gereksiz veri döndüren birleştirmeler, sıralama ve toplama adımlarının dökülmesi (belleğe sığmayıp diske taşması) ve tekrar eden hesaplamalar. Çözüm sırası: yalnız gereken sütunları seçmek, filtreleri mümkün olduğunca erken ve kümeleme kolonlarıyla uyumlu yazmak, birleştirmeden önce veriyi küçültmek.
Önbellek farklı mekanizmalardan oluşur. Ambar önbelleği, çalışan ambarın okuduğu tablo verisini tutar; ambar durdurulunca düşer. Sorgu sonucu önbelleği ise aynı sorgu yeniden çalıştırıldığında, koşullar sağlanıyorsa sonucu yeniden kullanır. Dokümantasyona göre yeniden kullanım için sorgunun öncekiyle birebir aynı olması, temel verinin değişmemesi ve rolün gerekli yetkilere sahip olması gerekir; yazım farkları bile engelleyebilir. Rastgele değer üreten fonksiyon içeren sorgular uygun değildir.
Bu nedenle pano ve rapor sorgularını tutarlı yazmak, aynı sonucun tekrar tekrar hesaplanmasını azaltır.
Maliyet yönetişimi: sınır ve izleme
Teknik ayar yetmez; sınırlar ve sorumluluk da gerekir. Snowflake'te kaynak izleyici (resource monitor), ambarların kredi tüketimini bir kotaya karşı izler. Eşik aşıldığında yalnız bildirim gönderebilir ya da atanmış ambarları askıya alabilir. Dokümantasyon, kaynak izleyicilerin saatlik katı sınır ya da hassas kredi kontrolü için tasarlanmadığını ve yalnız ambarlar için geçerli olduğunu, sunucusuz özellikler için ise bütçelerin (budget) kullanıldığını belirtir.
Yönetişimin diğer unsurları: • Ambar ve kullanıcı bazında etiketleme ile maliyetin birimlere dağıtılması • Düzenli maliyet raporu ve anormal tüketim için uyarı • Yeni ambar açma ve boyut değiştirme için basit bir onay süreci • Uzun süren ve beklenmedik sorgular için zaman aşımı sınırları • Dönemsel gözden geçirme: kullanılmayan ambarlar ve tablolar temizlenir
Bu önlemlerin amacı tasarrufu tek seferlik bir operasyon olmaktan çıkarıp sürekli bir yönetim alışkanlığına dönüştürmektir.
Sık hatalar ve öğrenme yolu
Sık yapılan hatalar: yavaş sorguya refleksle büyük ambar vermek, eşzamanlılık sorununu boyutla çözmeye çalışmak, auto-suspend'i kapalı bırakmak, her tabloya kümeleme anahtarı eklemek, tek ambarda tüm iş yüklerini karıştırmak ve ölçmeden iyileştirme yapmak. Çoğunun ortak sebebi, sorunu ölçmeden ayar değiştirmektir.
Öğrenme yolu mimariyi anlamakla başlar: depolama ve hesaplamanın ayrılması, mikro bölümler, sorgu profili. Sonra ambar boyutlandırma ve eşzamanlılık, veri düzeni ve kümeleme, sorgu yazımı ve önbellek, son olarak maliyet yönetişimi uygulanır. Gerçek sorgularla önce-sonra ölçümü yapmak en öğretici çalışmadır.
Mindset'in Snowflake İleri Seviye: Performans ve Maliyet Optimizasyonu programı şu modül başlıklarını içerir: Mimari, Mikro Bölümler ve Sorgu Profili, Warehouse Boyutlandırma ve Eşzamanlılık, Veri Düzeni ve Kümeleme, Sorgu Yazımı ve Önbellek Katmanları, Veri Yükleme, Paylaşım ve Zaman Yolculuğu, Maliyet Yönetişimi ve Bitirme Çalışması.
İlgili Mindset programı
Snowflake İleri Seviye: Performans ve Maliyet Optimizasyonu
Sık sorulan sorular
Snowflake'te en hızlı tasarruf nereden sağlanır?
Çoğu zaman boşta çalışan ambarların auto-suspend ayarıyla kapatılması ve gereğinden büyük ambarların küçültülmesi hızlı sonuç verir. Bunun için önce ambar bazlı kredi tüketimi görülmeli, değişiklik sonrası da tüketim ve sorgu süreleri tekrar kıyaslanmalıdır.
Warehouse'u büyütmek sorguyu her zaman hızlandırır mı?
Hayır. Büyük ve karmaşık sorgular için boyut artırmak fayda sağlayabilir, ancak küçük ve basit sorgular genellikle kazanç görmez. Sorgular kuyrukta bekliyorsa sorun eşzamanlılıktır ve çözümü ek ambar ya da çok kümeli ambardır, boyut değildir.
Kümeleme anahtarı her tabloya eklenmeli mi?
Eklenmemeli. Kümeleme, özellikle çok büyük tablolarda, filtre kolonlarına göre sıralı olmayan veriyle çalışan sorgularda fayda sağlar ve kendi bakım maliyeti vardır. Önce sorgu profilinde bölüm budama oranına ve performansın zamanla bozulup bozulmadığına bakılmalıdır.
Kaynak izleyici (resource monitor) harcamayı kesin olarak sınırlar mı?
Tam olarak değil. Kaynak izleyici ambarların kredi tüketimini kotaya karşı izler ve eşikte bildirim ya da askıya alma yapabilir; ancak dokümantasyona göre katı saatlik sınır için tasarlanmamıştır ve sunucusuz özellikleri izlemez. Daha güvenli olması için eşikler kotanın altında tutulur.
Sorgu sonucu önbelleği her zaman devreye girer mi?
Girmez. Sorgunun öncekiyle birebir aynı olması, verinin değişmemesi ve rolün yetkili olması gibi koşullar aranır. Koşullar sağlansa bile yeniden kullanım kesin değildir. Bu yüzden önbelleğe bağımlı bir performans tasarlamak yerine sorguyu zaten verimli yazmak gerekir.
İlgili rehberler
Kategori: Veri Mühendisliği ve MLOps, DevOps ve Bulut Teknolojileri