Veri Kaynaklarını ve Sizin İçin Neyi Kastettiğini Birleştiren 4 Yaklaşım

Veri Kaynaklarını ve Sizin İçin Neyi Kastettiğini Birleştiren 4 Yaklaşım

Veri analistleri ve veri mühendislerinin genellikle bir iş zekası (BI) raporlama aracında aradıkları ortak bir özellik, farklı veritabanlarından gelen verileri, özellikle de PostgreSQL, MySQL, SQL sunucusu gibi iki veya daha fazla veritabanı tedarikçisine yayılan verileri birleştirmektir; vb.

Bu makale, BI sağlayıcıları tarafından benimsenen farklı felsefelerin artılarını ve eksilerini araştırıyor, bunun anlamı sizin için.

Bir örnekle başlayayım

Şirketiniz e-ticaret alanında bir başlangıç ​​ve siz verileri bir SQL sunucusunda depolayan bir sipariş ve dağıtım yönetimi sistemi uyguladınız. Buna ek olarak, web sitesi trafiğini toplamak ve ilgili bilgileri ziyaret etmek ve ayrı bir PostgreSQL veritabanında saklamak.

Pazarlama ekibiniz ve kurucular, bir satın alma ile sonuçlanan en iyi kanalları anlamak istiyorlar. Böylece, raporlama çözümünüzün her iki veritabanındaki verileri bir araya getirmesi ve inşa etmeyi düşündüğünüz görselleştirmelerde hızlı incelemeler ve filtreleme sağlamak için yeterince hızlı çalışması gerekir.

Genel bir çözüm

Bazı BI raporlama araçları, bir özelliği kullanmanıza, hatta bir sorguda her iki veri kaynağındaki tabloları birleştiren bir SQL yazmanıza izin verir.

Böyle bir çözümün genel tasarımının yüksek seviyede nasıl işleyeceğine bir göz atalım:

  1. Verileri tek bir kaynaktan -özellikle daha az satır olanı (bu PostgreSQL diyelim) “geçici” bir yere taşıyın.
  2. Sorguyu çalıştırın ve daha hacimli veri kümesindeki sonuçları alın (SQL Server).
  3. Geçici konumdaki iki veri kümesini birleştirin ve nihai sonucu verin.

Not: Bazı BI ürünleri, diğerlerinden daha iyi bir veya daha fazla basamağa sahip olabilir, ancak iki veri kümesini sorgulayıp birleştirerek getirilen kısıtlamalar aynıdır.

4 muhtemel yaklaşım

Aradaki fark “geçici” konumun bulunduğu yerdedir ve dört muhtemel yaklaşıma yol açar:

  1. Veriler herhangi bir yerde saklanmaz ve çalışma zamanında birlikte dikilir.
  2. Veriler hafızada işlenir (sebat olmaz).
  3. Veriler, genellikle BI aracı satıcısı tarafından sağlanan bir önbellek veritabanında işlenir (kalıcılık ile).
  4. Veriler ortak bir veritabanına kopyalanır ve tüm raporlar bu ortak veritabanına karşı geçer (geçici değil).

1. Veriler herhangi bir yerde saklanmaz ve çalışma zamanında birbirine dikilir

İlk yaklaşım, genellikle bir sunucuda çalışan ve iki veri kümesini birleştirmek için sunucunun bellek, bant genişliği ve bilgi işlem kaynakları kullanan bir ürüne sahip olan BI sağlayıcıları tarafından sağlanmaktadır. Bunun en iyi örneği IBM Cognos BI’dir.

Dezavantaj, elbette performans. Sorguları yürütmeyi, sonuçların bir veri aktarım protokolü aracılığıyla alınmasını ve sunucudaki veri kümelerini birbirine dikmeyi gerektirdiği için, iki kaynaktan alınan verileri birleştirmek zaman alır. Özellikle bir veya daha fazla veri kaynağının sorgu sonuçlarını döndürmesi yavaşsa, bu adımlardan herhangi birinde gecikmeler olabilir.

 Birçok başarısızlık noktası olduğu için bu yaklaşımı ölçeklendirmek zordur . İlk raporlama çözümünüz kabul edilebilir bir performans sergilese bile, verileriniz büyüdükçe mücadele edecektir. Ayrıca, raporu kapatma ve daha sonra tekrar açma gibi basit bir işlem bile tüm süreci sıfırdan tekrar çalıştırarak kullanıcı deneyimini yavaşlatabilir.

2. Veriler bellekte işlenir (kalıcılık olmaz)

Bellek içi işleme, yerel (masaüstü / dizüstü) veya paylaşılabilir (sunucu) olabilir. BI aracı, her iki kaynaktan veri getirip sorgularınız ve analizleriniz için onu en iyi duruma getirdiğinde, bu hızlı olabilir. Dolayısıyla, gösterge paneli veya raporlama çözümü erişildiğinde, BI aracı, veri kümesini birleştirmek için birkaç saniye veya dakika alır (oturum başına bir kez yapılır) ve daha sonra yapılan incelemeler ve filtreleme gibi daha sonra yapılan işlemler iyi performans gösterir.

Tableau gibi dizüstü bilgisayarınızda veya masaüstünüzde çalışan yazılımlar, küçük veri setleri için gerçekten iyi çalışıyor. Bellek bir sunucuda kullanıldığında, bellek içi veri kümesi bir grup insan tarafından da kullanılabilir.

“Sesler harika! Yapalım, “dediğini duyuyorsun. Ancak, veriler arttıkça performans yavaşlar ya da kullanıcılarınızın sorduğu sorular anında daha fazla veri noktasına ihtiyaç duyar. Aşağıda kullanıcı ve veri (boyut ve karmaşıklık) olmak üzere iki önemli boyut kullanan bellek içi işleme olanaklarını tasvir ettim:

Bellek içi teknoloji bugünün gereksinimlerini karşılayabilir, ancak müşterilerinizin ihtiyaçlarının nereye yöneldiğini düşünmeni isteyeceğim. Şansınız verileriniz ve / veya kullanım kalıpları çeşitlenecek olmasıdır.

3. Veri önbellek veritabanında işlenir (kalıcılık ile)

Her iki kaynaktan gelen verileri bir önbellek veritabanında saklama, raporlarınızın veya gösterge tablolarınızın hızlı bir şekilde çalışmasını sağlar. Raporlama gereksinimleri değiştiğinde bile önbellek, sahnelerin arkasında yeniden oluşturulur, böylece kullanıcı deneyiminizin zarar görmemesi sağlanır. Bununla birlikte, risk, iş liderlerinin kararlar aldığı önbelleklerin bayat hale gelebilmesi ve operasyonel görünümle senkronize edilmemesidir.

Sorun genellikle bazı satıcıların sağladığı otomatik yenileme seçeneğiyle çözülürken, raporlama özellikleri için maliyetlerin yanı sıra veri barındırma hizmeti için bant genişliği, depolama ve işleme ücreti ödeyeceksiniz.

Belki de en büyük endişe veri güvenliği konularından biridir: şirketinizin verileri artık bir üçüncü taraf tarafından barındırılan bir kümede bulunur. Finansal hizmetler gibi bazı sektörlerde, bu düzenlemeler tarafından yasaklanmıştır. BI verilerini müşteri verilerinde kullanmayı düşünen diğer kullanıcılar için, müşteri tanımlayıcı bilgileri harici sunuculara yerleştirmek büyük önem arz edebilir.

4. Veriler ortak bir veritabanına kopyalanır (geçici değil)

Bu, klasik bir veri ambarı çözümüdür-ortak bir raporlama platformuna kaynak verileri, güncellemeleri toplu olarak planlar ve ticari kullanıcılar, veri analistleri ve veri bilimcileri için kaldırabilecek bir veritabanı bulunduğundan emin olunur.

Veritabanı yöneticileri güvenlik standartlarını uygulamakta ve istikrarı sağlamak ve çökme riskini azaltmak için yönetişim politikaları oluşturmayı seçebilirler. Açıkça görülen dezavantaj, işletme verilerinizin iki kopyasını oluşturmanız ve daha önce bahsedilen senkronize edilememe riskiyle yüzleşmenizdir. Ayrıca, çoğaltma nedeniyle depolama maliyetleri potansiyel olarak iki katına çıkabilir.

Ayrıca, birkaç yıl öncesine kadar, toplu güncelleme zamanlamaları, neredeyse gerçek zamanlı olarak veri almak için iş gereksinimlerini karşılayamadı. Veri akışı teknolojisindeki yeni araçlar, bu sorunun üstesinden gelmeyi ve gerçek zamanlı yazma yeteneklerini veritabanınıza hemen kazandırmayı mümkün kılmaktadır.

Veri sanallaştırma

Veri sanallaştırma ürünleri, yukarıdaki yaklaşımların birkaçı boyunca yayılmıştır. Veri kaynaklarına ilişkin tabloların soyut bir görünümünü sağlarlar ve bir veri analistinin, tablolar arasındaki ilişkileri sanki aynı veritabanında fiziksel olarak varolduklarını modellemelerine olanak tanır. Modellenen ve yayınlandıktan sonra bu ürünler, iki veri kümesini birleştirmenin en uygun yolunu tanımlayan bir sorgu yürütme yolu oluşturur. Daha sonra, bu modeller bellekte, bir veritabanında önbellekte saklanabilir veya isteğe bağlı olarak çalıştırılabilir.

Büyük işletmeler, teknoloji parçalanma problemini çözmenin bir yolu olarak veri sanallaştırma çözümlerini benimsiyor. Veri sanallaştırma çözümleri ile geçici bir yer seçerken aldığınız yaklaşımın sizi, yukarıda tartışılan yaklaşımların birleşik dezavantajlarına ve faydalarına getireceğini unutmayın.

İşinizde nelerin değişeceğine dayanan farklı yaklaşımları özetlemek gerekirse – veri hacmi ve çeşitliliği, kullanıcı sayısı ve raporlama gereksinimleri – aşağıdaki tabloyu bir araya getirdim:

Bütün bunlar senin için ne anlam ifade ediyor

Bir BI çözümü, yukarıdaki üç açıklamadan en fazla iki olabilir, bu da tek bir parametreden ödün vermenize neden olur. İyi kelimesi bazılarına güvenli, diğerleri için ölçeklenebilir ve arasında birçok şey anlamına gelebilir.

Farklı veritabanlarından gelen verileri bir araya getirmek için bir çözüm seçmeden önce en azından önümüzdeki 18 ay içinde, veri toplamanızın, kullanıcı büyümenizin ve mevcut kullanıcı davranışınızın nereye yöneldiğini düşünmeye davet ediyorum.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir