Snowflake zaman yolculuğu ve klonlama: geçmişe dönmek, kopya almadan çoğaltmak

Time Travel ve klonlama ne işe yarar?

Veri ekiplerinin en sık yaşadığı kazalar basittir: yanlış koşulla çalıştırılan bir silme ya da güncelleme, yanlış ortama gönderilen bir dönüştürme, yanlışlıkla silinen bir tablo. Geleneksel yöntem yedekten geri yüklemektir; zaman alır ve yedeğin alındığı ana kadar geri dönebilirsiniz.

Snowflake'te Time Travel, verinin belirli bir saklama süresi içindeki geçmiş hâllerine erişmenizi sağlar. Geçmişte bir zamana ya da belirli bir sorgudan önceki ana dönerek tabloyu sorgulayabilir, o hâlden yeni bir tablo üretebilir ya da silinmiş bir nesneyi geri getirebilirsiniz. Böylece hata düzeltmek yedekten geri yükleme sürecine değil, bir sorguya dönüşür.

Zero-copy clone ise bir veritabanının, şemanın ya da tablonun anında kopyasını, veriyi fiziksel olarak çoğaltmadan oluşturur. Test ve geliştirme ortamı kurmak, bir değişikliği denemeden önce üretim verisinin kopyasında prova yapmak için idealdir. İki özellik birlikte kullanıldığında güçlüdür: geçmişteki bir ana ait klon oluşturabilirsiniz.

Geçmiş veriyi sorgulamak: AT ve BEFORE

Time Travel sorgularında iki ifade kullanılır. AT, belirttiğiniz ana ait durumu verir. BEFORE, belirttiğiniz sorgudan hemen önceki durumu verir. Zamanı bir zaman damgasıyla, bir kaydırmayla ya da bir sorgu kimliğiyle belirtebilirsiniz.

Bir zaman damgasına göre:

SELECT * FROM siparisler AT(TIMESTAMP => '<zaman damgası>');

Bir hatalı sorgudan önceki duruma göre:

SELECT * FROM siparisler BEFORE(STATEMENT => '<sorgu kimliği>');

İkinci biçim, kazayı geri almak için en kullanışlısıdır: yanlış UPDATE'in sorgu kimliğini sorgu geçmişinden bulur ve o sorgudan hemen önceki hâle bakarsınız. Doğru veriyi gördükten sonra onu yeni bir tabloya kopyalayıp asıl tabloyu yenileyebilir ya da yalnızca etkilenen satırları geri yazabilirsiniz.

Önemli sınır: yalnızca saklama süresi içindeki geçmişe erişebilirsiniz. Bu süre tablo, şema ya da veritabanı düzeyinde ayarlanır ve en yüksek değeri Snowflake sürümüne göre değişir. Güncel değerleri resmî belgeden kontrol edin.

Silinen nesneyi geri getirmek: UNDROP

Yanlışlıkla silinen bir tablo, şema ya da veritabanı için UNDROP komutu vardır:

UNDROP TABLE siparisler;

Komut, nesneyi saklama süresi içinde geri getirir. Aynı adla yeni bir nesne oluşturulmuşsa önce o nesnenin yeniden adlandırılması gerekir, çünkü ad çakışması geri getirmeyi engeller.

Bu yetenek, süreçler için bir güvenlik ağıdır ama bunu yedekleme stratejisinin yerine koymayın. Saklama süresi dolduktan sonra Snowflake'in ayrıca sunduğu bir kurtarma katmanı (Fail-safe) vardır; bu katman kullanıcıların kendi başına eriştiği bir özellik değil, yalnızca Snowflake desteği aracılığıyla kullanılan son çaredir. Planlamanızı buna dayandırmamak gerekir.

Temel bir prensip: kritik tablolarda saklama süresini iş gereksinimine göre bilinçli ayarlayın. Her tabloda en uzun süreyi tanımlamak, depolama maliyetini artırır; çünkü geçmiş hâller de depolanır. Sık değişen büyük tablolar bu açıdan daha pahalıdır, geçici ve türetilmiş tablolar için ise kısa süre ya da geçici tablo türü tercih edilebilir.

Zero-copy clone: sıfır kopyayla hızlı çoğaltma

Klon oluşturmak tek bir komuttur:

CREATE TABLE siparisler_test CLONE siparisler;

Aynı sözdizimi şema ve veritabanı için de geçerlidir. Veritabanı klonlamak, içindeki tüm şemaları ve tabloları birlikte klonlar.

Klon neden 'sıfır kopya'? Snowflake verileri değişmez mikro bölümler hâlinde saklar. Klon oluşturulduğunda, yeni nesne mevcut mikro bölümlere işaret eden bir metadata kaydıdır; veri fiziksel olarak kopyalanmaz. Bu yüzden klonlama saniyeler içinde biter ve ilk anda ek depolama kullanmaz. Klon ya da kaynak üzerinde değişiklik yapıldıkça, değişen bölümler için yeni mikro bölümler oluşur ve bu tarafın depolaması bağımsız biçimde büyür. Kaynak ile klon, o noktadan sonra birbirinden bağımsız ilerler.

Bu mimari, test ortamı için çok değerlidir. Üretim verisinin tam bir kopyasında yeni bir dönüştürme mantığını deneyebilir, hatalıysa klonu silebilirsiniz. Kaynak etkilenmez. Yük testleri, veri kalitesi kontrolleri ve şema değişikliği provaları aynı yöntemle yapılır.

Bilinmesi gereken bir nokta, klonlanan nesnenin yetkilerinin ve bazı bağımlı nesnelerin davranışıdır; klonlama kuralları nesne türüne göre değişir ve resmî belgede ayrıntılıdır.

Time Travel ve klonu birleştirmek

Klon ile geçmiş zaman birlikte kullanılabilir:

CREATE TABLE siparisler_kurtarma CLONE siparisler AT(TIMESTAMP => '<zaman damgası>');

Bu komut, tablonun belirtilen andaki hâlinin klonunu çıkarır. Bir kazadan sonra veriyi geri yüklemenin en temiz yoludur: asıl tabloya dokunmadan, hatadan önceki hâli yeni bir tabloda oluşturur, doğrulama yapar, sonra isterseniz asıl tabloyla değiş tokuş edersiniz.

Örnek senaryo: bir veri mühendisi, gece çalışan bir dönüştürme işinin bir tabloyu yanlış değerle güncellediğini sabah fark ediyor. Sorgu geçmişinden o işin sorgu kimliğini bulur. BEFORE ifadesiyle tablonun öncesini sorgulayıp farkı doğrular. Ardından o ana ait bir klon oluşturup doğru veriyi yeniden yükler. Bu süreç, yedek dosyası aramaktan çok daha kısadır ve işlem boyunca asıl tablo kullanılabilir kalır.

Geliştirme akışında da kalıp işe yarar: her sprint başında üretim şemasının klonunu geliştirme ortamına almak, test verisini güncel tutar. Eski klonları temizlemeyi unutmamak gerekir, çünkü değişen ve artık kullanılmayan klonlar depolamada yer tutar.

Maliyet ve sınırlar

Bu iki özellik depolama maliyetini doğrudan etkiler. Time Travel için geçmiş hâller saklama süresince depoda kalır; sık güncellenen büyük tablolarda bu ek depolama anlamlı olabilir. Klonlarda ise kaynaktan ayrışan veri kadar ek depolama oluşur; sürekli değiştirilen büyük bir klon zamanla kaynak kadar yer kaplayabilir.

Sınırları şöyle özetleyebiliriz: • Time Travel yalnızca saklama süresi içinde çalışır; sonrası için bu özelliğe güvenilemez. • Saklama süresi, Snowflake sürümüne ve nesne türüne göre farklılık gösterir; geçici ve geçici olmayan nesneler arasında fark vardır. • Klon, kaynak verinin tutarlı bir anlık görüntüsünü alır; çok büyük nesnelerde bile hızlıdır ama depolama farkı sonradan oluşur. • Dış tablolar gibi bazı nesne türleri klonlanamaz ya da farklı davranır; resmî belgedeki tabloya bakın.

Maliyeti yönetmek için depolama kullanım görünümlerini izleyin: hangi tabloların Time Travel için, hangilerinin klon nedeniyle yer tuttuğu raporlanabilir. Düzenli temizlik ve doğru saklama süresi seçimi, bu özelliklerden yararlanırken depolama faturasını kontrol altında tutar.

Sık hatalar ve kontrol listesi

• Time Travel'ı yedek sanmak: saklama süresi dolunca geri dönüş yoktur. Kritik veriler için ayrıca yedekleme ve olağanüstü durum planı gerekir.
• Yanlışlıkla CREATE OR REPLACE ile tabloyu ezmek: bu komut eski tabloyu geçmişe taşır ama kolay fark edilmez; sorgu geçmişinden kontrol edin.
• Klonları silmeyi unutmak: bağımsız büyüyen eski klonlar depolama yer.
• Saklama süresini hiç ayarlamamak: varsayılan değerin ihtiyaca uygun olup olmadığını kontrol edin.
• Üretim verisini içeren klonu geniş yetkiyle paylaşmak: klon, kaynağın hassas verisini taşır. Maskeleme ve yetki kurallarını klon için de gözden geçirin.

Kontrol listesi: kritik tablolarda saklama süresi belgelenmiş mi, kaza kurtarma prosedürü yazılı ve denenmiş mi, geliştirme klonlarının sahibi ve silinme tarihi belli mi? Prosedürü bir kez gerçek bir klon üzerinde prova etmek, gerçek kazada dakikalar kazandırır.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Zaman yolculuğu ve klonlama, Snowflake İleri Seviye: Performans ve Maliyet Optimizasyonu eğitiminin 'Veri Yükleme, Paylaşım ve Zaman Yolculuğu' modülünde işlenir; Snowflake ile Veri Sorgulama eğitimi ise platformun mimari temelini ve SQL tarafını verir. Veri mühendisleri, analitik mühendisler ve veri platformu yöneticileri için uygundur.

Kurumsal ekiplerde üretim verisini güvenle test etmek isteyen, kaza sonrası geri dönüş sürecini belgelemek isteyen veri ekipleri için pratik bir temel sağlar.