DBT kullanarak Redshift'e veri yükleme

• Yelp, son dönemde tüketici verilerine yönelik talep arttıkça verileri Redshift'e daha verimli yükleme yöntemlerini yeniden değerlendirdi
• Bu yazı, DBT'nin Redshift Spectrum ile sorunsuz biçimde kullanılarak verilerin Data Lake'ten Redshift'e alınmasını, çalışma süresinin büyük ölçüde azaltılmasını, veri kalitesi sorunlarının çözülmesini ve geliştirici üretkenliğinin artırılmasını nasıl sağladığını inceliyor

Başlangıç noktası

• Batch veriyi Redshift'e yükleme yöntemi yıllardır etkiliydi, ancak ekip sürekli iyileştirme alanları arıyordu
• Ağırlıklı olarak Spark işleri kullanılarak S3 verisi okunuyor ve şirket içi Kafka tabanlı veri hattına yayımlanarak veriler hem Data Lake'e hem de Redshift'e alınıyordu
• Ancak zamanla bazı sorunlarla karşılaşılmaya başlandı:
  • Performans: Büyük veri kümeleri (günlük 1 milyondan fazla satır) gecikmeye başladı. Bunun başlıca nedeni, upsert sırasında birincil anahtarların yinelenmemesini sağlamak için yapılan tablo taramalarıydı
  • Şema değişiklikleri: Tabloların çoğu Avro şemalarıyla tanımlanmıştı. Şema değişiklikleri zaman zaman karmaşık hale geliyordu, çünkü yeni bir Avro şeması oluşturup kaydetmeyi gerektiren çok adımlı bir süreç vardı
  • Backfill: Veri düzeltmeleri için backfill desteği zayıftı, çünkü satırları in-place güncellemenin kolay bir yolu yoktu. Düzeltilmiş veriler tüm partisyon için yeniden yazılmadan önce veriler çoğu zaman elle siliniyordu
  • Veri kalitesi: Data Lake ve Redshift'e paralel yazmak, iki veri deposu arasındaki veri tipi farkları gibi tutarsızlık riskleri yaratıyordu

DBT ile Redshift yüklemelerini iyileştirmek

• Veriyi daha verimli taşımanın yolları değerlendirilirken, Data Lake verisini Redshift'ten sorgulamak için özel olarak tasarlanmış bir araç olan AWS Redshift Spectrum'dan yararlanma kararı alındı
• Data Lake tabloları genellikle en güncel şemaya sahip olduğundan, Redshift batch işlemleri için veri kaynağı olarak S3 yerine Data Lake kullanılmasına karar verildi. Bu yalnızca veri farklarını azaltmaya yardımcı olmadı, aynı zamanda Data Lake'i tek doğruluk kaynağı olarak ele alma yönündeki en iyi uygulamayla da uyum sağladı
• Uygulama tarafında Spectrum, tanımlı bir şema gerektiriyor; bu da Data Lake tabloları için Glue üzerinde zaten mevcuttu. Gerekli tek ek kurulum, Data Lake tablolarını external table olarak ekleyip bunlara Redshift'ten basit SQL sorgularıyla erişilebilir hale getirmekti
• Ekip zaten başka veri kümelerinde DBT'yi kullanmaya başlamıştı ve bunun, veri hattındaki Redshift Spectrum sorgularını kapsamak için de mükemmel bir aday olduğu görüldü. DBT, veri dönüşümünde çok güçlü ve modüler, sürüm kontrollü SQL yazımını teşvik ediyor
• Spark işleri S3'ten Redshift'e okumak yerine, DBT kullanılarak veri doğrudan Data Lake'ten Redshift'e kopyalandı. DBT, yeniden üretilebilirlik, esneklik ve veri soy ağacı gibi karakteristik avantajlar sunmakla kalmadı, aynı zamanda yukarıda belirtilen bazı sorunların çözülmesine de yardımcı oldu

Basitleştirilmiş şema değişiklikleri

• Şema değişikliklerini basitleştirmek için DBT'nin on_schema_change yapılandırma argümanından yararlanıldı. Bu ayar append_new_columns olarak belirlenerek, gelen veride sütun bulunmasa bile bunların silinmemesi garanti altına alındı
• Ayrıca DBT contract'ları ikinci bir koruma katmanı olarak kullanılarak yazılan verinin model yapılandırmasıyla uyumlu olduğu doğrulandı

Daha az manuel backfill

• DBT sayesinde backfill de çok daha kolay hale geldi. pre_hook yapılandırma argümanı kullanılarak modelden hemen önce çalıştırılacak sorgular belirtilebiliyor
• Bu sayede yazılacak partisyonlara ait veriler daha otomatik biçimde silinebiliyor
• Artık idempotency garanti altına alınabildiğinden, eski verilerin kaldırılmaması konusunda endişe etmeden backfill yapılabiliyor

Veri tekilleştirme

• Yinelenen satırları çözmek için SQL'e bir tekilleştirme katmanı eklendi ve bu yapı DBT testleriyle doğrulandı
• DBT'de yerleşik bir unique sütun testi bulunsa da bu test tüm tabloyu taramayı gerektirdiği için büyük tablolar için uygulanabilir değildi
• Bunun yerine dbt_expectations paketindeki expect_column_values_to_be_unique fonksiyonu kullanıldı. Bu sayede yalnızca yakın zamanda yazılmış satırları tarayan satır koşulları tanımlanabildi

Performans kazanımları

• En dikkat çekici sonuç, özellikle en sorunlu Redshift veri kümelerindeki performans artışı oldu:
  • Yazma işlemleri yaklaşık 2 saat sürerken artık genellikle yalnızca 10 dakikada tamamlanıyor
  • Daha önce ayda toplam 6 saate kadar gecikme yaşanırken artık gecikme görülmüyor. Bu da on-call olay müdahale yükünü önemli ölçüde azalttı
  • Şema yükseltmeleri eskiden daha uzun ve çok adımlı bir süreçti. Şimdi ise yalnızca birkaç saat süren 3 adımlı bir sürece indirildi

Daha iyi veri tutarlılığı

• Veri akışındaki çatallanma ortadan kaldırılarak farklı veri depoları arasında veri farklılığı oluşmayacağına dair güven artırıldı
• Redshift'e giren tüm verilerin önce Data Lake'ten geçmesi gerektiğinden, Data Lake'in tek doğruluk kaynağı olarak kalması daha güçlü biçimde güvence altına alındı

Sonuç

• Geçişin başarısının ardından bu değişiklikler yaklaşık 12 farklı veri kümesine daha uygulandı ve genel olarak benzer faydalar gözlemlendi
• AWS Redshift Spectrum ve DBT gibi araçlardan yararlanılarak altyapı, değişen veri ihtiyaçlarına uyum sağlayacak şekilde geliştirildi ve böylece kullanıcılara ve paydaşlara daha fazla değer sunuldu