Veri mühendisliği endüstrisindeki en son yenilikler, farklı veri platformlarının depolama ve işlemi birbirinden ayırma veya birleştirme şeklindeki yaklaşımlar etrafında dönüyor. Ancak, bu yaklaşımlar fazla mı ileri gidiyor?
2014 yılında, Gwyneth Paltrow ve Chris Martin gibi, bilgisayar mühendisleri de bilinçli bir şekilde depolama ve Compute ayırmaya başlama trendini keşfettiler. Bu yaklaşım, maliyet ve ölçeklenme açısından on-premises veritabanlarına kıyasla büyük avantajlar sağlıyordu. Fortune 500 şirketindeki bir veri mühendisliği yöneticisi, on-premises kısıtlamalarının yarattığı sıkıntıyı şu şekilde ifade etti:
“Analistlerimiz istedikleri sorguları istedikleri zaman çalıştıramıyorlardı. Veri ambarımız, veri dönüşümleri ve yüklemeleri için düzenli olarak çevrimdışı alınması gerektiğinden günde 12 saat boyunca çalışmıyordu… Bu süreci tanımlamak için kullanabileceğim tek kelime acı verici.”
Günümüzde, veri yönetimi endüstrisinde önemli bir yenilik dalgası, farklı veri platformlarının depolama ve işlemi birbirinden ayırma veya birleştirme şeklindeki yaklaşımları etrafında dönüyor. Bu bağlamda, veri alımı ve dönüşümden veri yönetimi ve izlemeye kadar olan ilişkili veri hizmetlerinin nasıl bir araya getirildiği veya ayrıldığı da dikkat çekiyor.
Bağlantı ve Entegrasyon
Bu hizmetleri birbirine bağlayan genellikle tablo formatlarının (depolama) ve sorgu/işlem günlüklerinin (işlem) meta verilerinde bulunuyor. Bu unsurların veri platformunuz içinde nasıl yönetildiği, performansı, maliyeti, kullanım kolaylığını, ortak ekosistemi ve gelecekteki sürdürülebilirliği büyük ölçüde etkileyecektir.
Doğru veri platformu türü ve hangi düzeyde ayırmanın doğru olduğunu sormak, SQL kodunuzu nasıl biçimlendirmeniz gerektiğini sormak gibidir: Büyük ölçüde kişisel tercihlere ve mesleki gereksinimlere bağlı olacaktır; ancak çoğu ihtiyacı karşılayan birkaç olasılık aralığı bulunmaktadır.
Mevcut Durum ve Gelişmeler
Veri platformları spektrumu, depolama ve işlemi birbirinden ayırma konusunda geniş bir yelpazeye sahiptir. Bazıları “bulut pahalı, eski sunucu rafına geri dönelim” yaklaşımını benimsemiş olsa da, bu yaklaşım giderek azalan bir azınlığa aittir.
Geçtiğimiz haftalarda, Pragmatic Engineer, Twitter’ın makine öğrenme modellerini GCP’den çıkararak sadece üç veri merkezine güvenmeye başlamasının ardından ortaya çıkan hız sınırlamalarını ve kullanıcı deneyimi sorunlarını vurguladı.
Depolama ve işlemi bağımsız olarak ölçeklendirme yeteneği hem daha maliyet etkin hem de performanslıdır, ancak bu ayrı işlevlerin aynı veri platformu içinde olması da avantajlara sahiptir.
Çoğu veri analitik talepleri içeren optimize edilmemiş bir SQL sorgusu, genellikle kutusundan iyi çalışmak üzere ayarlanmış bu platformlarda çok daha hızlı çalışır. Depolama ve işlemi platform düzeyinde ayıran daha ayrı bir mimari, ağır iş yüklerini çalıştırmak için çok maliyet etkin olabilir, ancak bunlar üzerinde zaman harcayan yüksek eğitimli bir ekip olduğunu varsayar.
Kombine ama ayrı depolama ve işlem sunan veri platformları, aynı zamanda birkaç önemli DataOps görevi için daha sağlam ve entegre bir kullanıcı deneyimi sunar. Örneğin, veri yönetimi konusunda. Bu platformlar, merkezi bir mekanizma sağlayarak erişim kontrolü yapılmasını sağlar, oysa ayrılmış mimariler birden fazla sorgu motoru arasında rolleri birleştirmeyi gerektirir bu zor bir görevdir.
Ayrı ama birleşik yaklaşım, Snowflake’in en yaygın yorumlarından birini oluşturan “Her şey sadece çalışıyor” yorumunu doğuran yaklaşımdır.
Databricks, Spark işlemlere odaklanarak büyük bir büyüme gördü, ancak Delta tabloları içindeki meta veri ve ACID benzeri işlemleri Unity Catalog içindeki yönetim özellikleri ekledikten sonra yeni bir büyüme seviyesi elde etti. Ayrıca, Delta tablosuna yazdığınızda (depolama) o tablo içindeki meta verilerinin Delta, Apache ve Hudi tarafından okunabilen formatlarda yazılmasını sağladılar.
Meydan Okuyan Platformlar
Bu nedenle, en son gelişen veri mühendisliği teknolojilerinin birçoğunun depolama ve işlemi sağlayıcı düzeyinde ayırmaya başlaması ilginçtir. Örneğin, Tabular, kendisini “başsız bir veri ambarı” veya “işlem hariç her şeyi içeren bir veri ambarı” olarak tanımlar.
Bir adım daha ileri giden bazı kuruluşlar, “kendi kendine yap” şeklinde backend altyapı yönetimini ve Trino gibi ayrı bir sorgu motorunu kullanarak bir veri gölü içindeki Apache Iceberg tablolarına geçiş yapıyorlar. Bu genellikle yüksek performanslı ve maliyet etkin, etkileşimli sorgular gerektiren müşteri odaklı kullanım durumlarından kaynaklanmaktadır.
DuckDB, depolama ve işlemi birleştirir, ancak modern veri yığınının neredeyse sonsuz işlem kapasitesini feda ederken, geliştirici basitliği ve düşük maliyeti tercih eder.
Bu nedenle, bu yeniliklerin mevcut bulunan bulut tabanlı veri platformlarını mı değiştireceği sorusu ortaya çıkar.
Tekrar belirtmek gerekirse, bu sorunun cevabı kim olduğunuza bağlı olacaktır. DuckDB, birçok veri analisti tarafından sevilen son derece popüler bir araç olsa da, muhtemelen veri platformunuzu inşa ettiğiniz temel olmayacaktır.
Kullanım kolaylığı ve performans arasında denge sağlanması gereken ilişkili değişkenlerdir, ancak çoğu veri yöneticisi, karmaşıklık maliyetlerinin göreceli olarak gizli olduğu için kullanım kolaylığına bir önyargı taşımak isteyecektir. Rekabet avantajınız genellikle karmaşık altyapıyı sürdürmekten daha çok, birinci taraf verileri zenginleştirmekte ve uygulamaktadır.
Modern Veri Yığını
Modern veri yığınına eleştiri yapmak (ve belki de ihtiyacınız yoktur) modadır, ancak tüm kusurlarına rağmen, çoğu veri ekibi için en iyi seçenek olacaktır. Bu yaklaşım, hızlı değer üretme ile uzun vadeli bir yatırımı geleceğe taşıma arasında ideal bir denge sunar.
Birçok yeni teknoloji daralan bir kullanım alanına sahip olsa da, önemli değer taşır. Bu teknolojilerin nasıl evrileceğini ve veri mühendisliği pratiğini nasıl şekillendireceğini görmek heyecan verici olacaktır.
Sonuç olarak, depolama ve Compute ayrı olarak ölçeklendirmenin gerekliliği yanı sıra, bu hizmetlerin ve ilgili meta verilerin aynı platform içinde bulunması, göz ardı edilemeyecek kadar güçlü ve birçok avantaja sahiptir.
Kaynak: dzone.com