Bir süredir endüstri olarak kare veri ambarı araçlarını yuvarlak, veriye dayalı uygulama deliklerine sokmaya çalıştığımız aşikar. Ancak Decodeable CEO’su Eric Sammer’in mükemmel yazısını okuyana kadar değildi.Veri Ambarı’nı Kötüye Kullanıyoruz: RETL, ELT ve Diğer Garip ŞeylerBu süreçte neden ve ne gibi zararlar verdiğimizi anladım. Sammer’in yazdığı gibi, “Yüksek fiyatlı analitik veritabanı sistemlerini sıcak yola sokmak, desteklenebilirlik ve operasyonlar için pantolon-on-head anti-desenleri getiriyor.”
Merak ediyorsanız, “pantolon anti-desenleri” bir iltifat değildir. Bu, “biri lütfen bu deliliği durdursun!” diye ıstıraplı bir çığlıktır.
Veri sorununun birleştirilmesi
İşletmelere veri ambarları hakkında ne hissettiklerini sorun ve yüksek bir yüzde (bu ankette %83) memnuniyetsizliği ifade eder. Veri yüklemek için mücadele ediyorlar. Yapılandırılmamış verileri var ama veri ambarı bunu kaldıramıyor, vb. Ancak bunlar mutlaka veri ambarıyla ilgili sorunlar değildir. Genellikle, memnuniyetsizliğin veri ambarını (veya isterseniz analitik veritabanını) uygun olmayan bir şey yapmaya zorlamaktan kaynaklandığını tahmin ediyorum.
Sammer’e göre hatanın başlamasının bir yolu:
Şimdiye kadar herkes rETL (ters ETL) eğilimini gördü: Uygulama 2’deki (örneğin Marketo) verileri zenginleştirmek için 1 numaralı uygulamadan (örneğin Salesforce) gelen verileri kullanmak istiyorsunuz. Çoğu mağaza, Fivetran gibi bir ELT aracıyla veri ambarına 1 numaralı uygulamadan veri gönderdiğinden, birçok kişi kısayol olduğunu düşündükleri şeyi aldı, veri ambarında dönüştürme yaptı ve ardından verileri dışarı taşımak için bir rETL aracı kullandı. deponun ve uygulama # 2’ye.
Yüksek fiyatlı veri ambarları ve veri gölleri, ELT ve rETL şirketleri, ciddi maliyet ve karmaşıklıkta bile, kullanıcıların uygulamaları bir araya getirmenin pragmatik bir yolunu kullanmalarına yardımcı olmaktan mutlu oldular.
Ve neden olmasınlar? Sammer, “Bulut veri ambarı, muhtemelen mevcut en pahalı CPU döngüsüdür” diyor. Veri ambarı topolojisi, verileri çoğaltarak sona erer (diğer sorunların yanı sıra yönetişim sorunları yaratır), ancak kullanışlı olma avantajına sahiptir. Veri ambarları, iyi anlaşıldıkları için uygundur. Pek çok insan onları kullanmak için eğitildi ve zaten kullanılıyorlar.
Doğru sorun, yanlış çözüm
Sammer, veriye dayalı uygulamalar oluşturmanın tamamen yanlış ve en maliyetli yolu olduklarına dair ikna edici bir “kafada pantolon” vurgusu yapıyor. Niye ya? Çünkü “iki Katman 1 uygulaması arasına bir veri ambarı koymak, [bad] fikir.” Şirketler, analitik sistemlerini “Tier 1, iş açısından kritik bileşenler gibi” ele almama eğilimindedir. Bu nedenle, “şirketler, kullanılabilirlik bölgelerinde yüksek kullanılabilirlik için analitik araçları ve verileri çoğaltmazlar; (genellikle) çağrı cihazı taşımazlar; süreçleri kopyalamazlar.” Sonuç “muazzam maliyet ve risk”tir. Veya, “Müşteri deneyimimizi kazara yavaş toplu ELT süreçlerine dayanacak şekilde tasarladık” sonucuna varıyor.
Peki alternatif nedir?
Sammer için her şey ELT (veya reETL) değil, veri akışı ile ilgilidir. Kappa mimarisine dayalı gerçek zamanlı veri boru hatlarıyla ilgilidir. Kappa mimarisi, “yalnızca eklenen değişmez bir günlüğünüz” olduğu anlamına gelir. Günlükten, veriler bir hesaplama sistemi aracılığıyla aktarılır ve hizmet için yardımcı mağazalara beslenir.” Milinda Pathirage’ı açıklıyor, KPMG’de büyük veri mühendisliği uzmanı. Veya Confluent CEO’su olarak Jay Kreps 2014’te yazdı LinkedIn’de mühendislik lideriyken, Sammers’in reddettiği bir tür “bantlı” Lambda mimarisi yaklaşımına karşı çıkarak, “neden akış işleme sistemi hedef etki alanında belirlenen tüm sorunu ele almak için geliştirilemiyor? ”
Yani akışı veri evreninin merkezi yapın.
Sammers, faydaların birkaç olduğunu öne sürüyor: “Maliyeti çok daha düşük, verileri çoğaltma maliyeti olmadan Katman 1 kalitesinde SLA’lar sağlıyor, toplam hatalar yerine kısmi hatalara izin veriyor ve veri ambarınızı kritik yoldan çıkarıyor. Basitçe ifade etmek gerekirse, Kappa, veriyi oluştuğu anda 1 numaralı uygulamadan çekmek, veri ağ geçidine küçük parçalar halinde göndermek, gerektiği şekilde dönüştürmek/zenginleştirmek ve ardından ihtiyaç duyulan tüm yerlere paralel olarak teslim etmek anlamına gelir.”
Akışın veritabanının yerini aldığını düşünmeseniz bile (kişisel olarak sanmıyorum), veri boru hatlarının/akışlarının, verileri analitik veritabanları arasında ileri geri taşımaya çalışmaktan daha fazla geleceği olduğu fikrine katılmak kolaydır. Kappa ve benzeri yaklaşımlar gerçek zamanlı veriler sunsa da, aslında bununla ilgili değil. Sammer’e göre bu, “rETL’nin biriktirdiği devasa teknoloji borcu yığınını sona erdirmekle ilgili. Bu, analitik araçlara yönelik kritik bağımlılık yuvasını çözmek ve desteği sürdürülebilir kılmakla ilgili.”
Bir dahaki sefere bir lider panosu olan veya verilerle bilgilendirilmesi gereken bir uygulama oluşturduğunuzda (ve bu, uygulamaların şişme yüzdesidir), kendinize varsayılan veri varsayımınızın neden durağan olduğunu sorun: depolamada duran ve daha sonra itmeniz gereken veriler uygulamadan uygulamaya, sistemden sisteme. Artık parti odaklı dünyada yaşamıyoruz. Sammers doğru görünüyor: Akışlar bir istisna değil, varsayılan olmalıdır.
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3660074/doing-data-warehousing-the-wrong-way.html#tk.rss_all