Veri mühendisliği araçları konuşması güvenilir bir döngü izliyor. Gerçek bir problemi gerçekten daha iyi şekilde çözen yeni bir araç çıkıyor. Erken benimseyenler başarılı oluyor. Vaka çalışmaları yazılıyor. Konferans konuşmaları yapılıyor. Araç uzlaşı seçimi haline geliyor. Organizasyonlar benimsiyor — kimileri problemlerini çözdüğü için, çoğu iş ilanlarının gerektirdiği ve danışmanların önerdiği şey olduğu için.
Sonra bir sonraki döngü başlıyor.
Bunu veri ambarı platformları, ETL araçları, orkestrasyon çerçeveleri ve şimdi modern veri yığını ile yaşandığını gözlemledim. Her seferinde en iyi durumda olan organizasyonlar en erken ya da en geç benimsetenler değil. Araca değil, soruna odaklı kalmaya devam edenler.
Her Araç Gerçekte Neye İyi Geliyor
Tartışma çoğunlukla çok yüksek bir soyutlama düzeyinde yürütüldüğünden somut olmak istiyorum.
Oracle ortamlarında PL/SQL olgun, veritabanı motoruyla derin entegre ve işlemsel finansal veri işleme için son derece uygun. Oracle'ın baskın veritabanı platformu olduğu Türk düzenlenmiş finansal hizmetlerinde PL/SQL pipeline'ları onlarca yıllık optimizasyondan, derin bir yetenek havuzundan ve uyum açısından önemli veritabanı özelliklerinden doğrudan entegrasyondan yararlanıyor: bölümleme, satır düzeyinde güvenlik, denetim tetikleyicileri ve ayrıntılı erişim kontrolü. PL/SQL'e karşı argüman nadiren teknik. Genellikle "eski" olduğu ve işe almanın zor olduğu. Her ikisi de doğru yaklaşımla yönetilebilir.
dbt belirli bir sorunu çok iyi çözüyor: modern bulut veri ambarında halihazırda bulunan veriyi sürüm kontrollü, test edilebilir SQL kullanarak dönüştürmek. Dokümantasyon, lineage ve test yetenekleri çoğu ekibin elle inşa ettiğinden gerçekten üstün. dbt'nin yetersiz kaldığı yer: verinin Snowflake/BigQuery/Redshift şekilli ambar olmadığı ortamlar, dönüşümlerin SQL'in düzgün ifade edemediği prosedürel mantık gerektirdiği durumlar ve modern veri yığınının operasyonel yükünün sorunun ölçeği veya karmaşıklığıyla haklılaştırılmadığı durumlar.
Spark gerçek bir sorunu ele alıyor: tek düğümlü bir veritabanının üstesinden gelemeyeceği veri hacimleri veya dağıtık hesaplamadan yararlanan işleme örüntüleri. Türk finansal hizmet ortamlarının çoğunda bu sorun Spark'ın karmaşıklığını gerektiren ölçekte mevcut değil. İyi ayarlanmış bir Oracle sorgusunun daha hızlı, daha basit ve operasyonel olarak daha ucuz olacağı ortamlarda Spark'ın benimsendiğini gördüm. Bedeli, anlamlı bir performans kazancı olmaksızın iki yıl karmaşıklık oldu.
Kimsenin Sormadığı Soru
Araçları değerlendirmeden önce önce gelmesi gereken soru: Gerçek kısıt nedir?
Kısıt veri hacmiyse, yatay ölçeklenen araçlar önemli. Kısıt dönüşüm karmaşıklığıysa, etkileyici mantığa sahip araçlar önemli. Kısıt denetlenebilirlik ve lineage ise yerel dokümantasyona sahip araçlar önemli. Kısıt operasyonel maliyetse, ekibinizin zaten bildiği araçlar en çok önemli.
Düzenlenmiş finansal hizmetlerde en sık karşılaştığım kısıtlar: denetlenebilirlik, düzenleyici baskı altında değişim yönetimi ve organizasyonel bilgi konsantrasyonu. Bunların hiçbiri öncelikle araç sorunu değil. Hangi aracı kullandığınızdan bağımsız var olan mimari ve süreç sorunları.
Kimsenin Bütçelemediği Migrasyon Maliyeti
Her araç migrasyonunun iş vakasında nadiren görünen gizli bir maliyeti var: gömülü iş mantığının kaybı.
Sekiz yıldır üretim uyum raporlaması çalıştıran PL/SQL paketi iş kuralları içeriyor. Bir kısmı belgelenmiş. Çoğu değil — mantığın kendisinde kodlanmış, onu koruyan ekip üyeleri tarafından örtük olarak anlaşılıyor. dbt'ye geçtiğinizde yalnızca SQL'i taşımıyorsunuz. Her iş kuralını, kimsenin yazmadığı kurallar dahil, anlayıp yeniden uygulamak zorunda kalıyorsunuz.
Bu çalışma pahalı. Mevcut sistemi bilenlerden aylarca yeni çalışma yerine migrasyona zaman harcamalarını gerektiriyor. Yeniden uygulama riski getiriyor — aynı testlerden geçen ama bir kenar durumu farklı ele alan yeni sistem.
Organizasyonların bir migrasyonun altyapı maliyetini bütçeleyip bilgi transferi maliyetini görmezden geldiğini gördüm. Sonuç, planlanandan üç kat uzun süren ve teknik olarak modern, davranışsal olarak belirsiz sistemler üreten migrasyonlar.
Gerçekte Önemli Olan
Herhangi bir araç kararından önce yanıtlanacak soru: Mevcut araçlarım yapmam gereken bir şeyi yapmamı engelliyor mu? "Diğer organizasyonların kullandığı daha yeni bir araç var mı?" değil.
Cevap evetse — mevcut araçlar gerçekten işi engelliyorsa — alternatifleri değerlendirin. Ortamınızı yansıtmayan teorik ölçek veya sektör kıyaslamalarına değil, kendi özel kısıtlarınıza göre değerlendirin.
Cevap hayırsa — mevcut araçlar çalışıyor, anlaşılıyor ve bakımı yapılabiliyorsa — migrasyon gerekçesinin trend benimsemesine değil, çözdüğü belirli bir soruna dayanması gerekiyor.
Aldığım en iyi veri araçları kararı en modern yığını seçmekle ilgili değildi. O yıl ne popülerse bağımsız olarak, eldeki sorun için hangi aracın doğru olduğunu bilmekle ilgiliydi. Bu yargı teknik beceriden daha nadir ve daha değerli.