Kurumsal Veri Ağı

Kurumsal yazılımda sıcak bir konu olan veri ağı, veri yönetimi için dağıtılmış bir mimariye dayanan verileri düşünmeye yeni bir yaklaşımdır. Buradaki fikir; veri sahipleri, veri üreticileri ve veri tüketicileri arasında doğrudan bağlantı kurarak verileri daha erişilebilir hale getirmektir. Veri ağı, veri merkezli çözümlerin iş sonuçlarını iyileştirmenin yanı sıra modern veri mimarilerinin benimsenmesini de amaçlamaktadır.

İş açısından bakıldığında, veri ağı "veri ürünü düşüncesi" etrafında yeni fikirler ortaya koymaktadır. Başka bir deyişle, verileri, örneğin karar verme sürecini iyileştirmek, dolandırıcılığı tespit etmeye yardımcı olmak veya tedarik zinciri koşullarındaki değişiklikler konusunda işletmeyi uyarmak gibi "yapılması gereken bir işi" yerine getiren bir ürün olarak düşünmektir. Şirketler, yüksek değerli veri ürünleri yaratmak için kültür ve zihniyet vardiyalarını ele almalı ve iş alanı modellemesinde daha çok işlevli bir yaklaşım sergilemelidir.

Teknoloji tarafından, Oracle'ın veri ağı hakkındaki görüşü, veriye dayalı mimari için üç önemli yeni alan içerir:

1. Veri koleksiyonları, veri etkinlikleri ve veri analitiği olarak veri ürünleri sunan araçlar
2. Dağıtılmış, merkezi olmayan veri mimarileri monolitik mimarilerden, çoklu bulut ve hibrit bulut bilişime geçmeyi seçen ya da küresel olarak merkezi olmayan bir şekilde çalıştırılması gereken organizasyonlara yardımcı olur
3. Sadece merkezi, statik, toplu işlem tabanlı verilere bağımlı olmayan ve bunun yerine daha zamanında analitik sağlayan gerçek zamanlı veri olayları için olay temelli veri defterlerine ve akış merkezli ardışık düzenlere doğru hareket eden kurumlar için hareketli veri

Teknik olmayan kullanıcılar ve güçlü birleşik veri yönetişimi modelleri için self servis araçları gibi diğer önemli kaygılar, tıpkı diğer, daha merkezi ve klasik veri yönetimi metodolojileri gibi veri ağı mimarisi için de önemlidir.

Veri ağı yaklaşımı, verileri ürün olarak düşünmeye ilişkin paradigma dönüşümüdür. Veri ağı, şirketlerin veriyi işletmenin somut bir sermaye varlığı olarak yönetmek için ihtiyaç duyacağı organizasyonel ve süreçsel değişiklikleri beraberinde getirmektedir. Oracle'ın veri ağı mimarisine yönelik bakış açısı, organizasyonel ve analitik veri alanları arasında uyum sağlanmasını gerektirmektedir.

Bir veri ağı, veri üreticilerini doğrudan iş kullanıcılarına bağlamayı ve veri kaynaklarını alan, hazırlayan ve dönüştüren proje ve süreçlerden BT aracısını mümkün olduğunca kaldırmayı amaçlar.

Oracle'ın veri ağı konusundaki odak noktası, müşterilerimiz için bu yeni teknoloji gereksinimlerini karşılayabilecek bir platform sağlamak olmuştur. Veri ürünleri için araçlar; merkezi olmayan, etkinliğe dayalı mimariler ve veri akış düzenleri buna dahildir. Oracle, veri ürünü etki alanı modellemesi ve diğer sosyoteknik kaygılar için, veri ağı konusunda fikir lideri olan Zhamak Dehghani tarafından yapılan çalışmalarla uyum içindedir.

Gerçek şudur ki, geçmişin monolitik veri mimarileri hantal, pahalı ve esnek değildir. Yıllar geçtikçe, uygulamalardan analitiklere kadar dijital iş platformları için harcanan zaman ve maliyetin çoğunun entegrasyon çabalarına gittiği anlaşılmıştır. Sonuç olarak, çoğu platform girişimi başarısız olmaktadır.

Veri ağı, merkezi, monolitik veri mimarileri için sihirli bir değnek olmasa da, veri ağı stratejisinin ilkeleri, uygulamaları ve teknolojileri, veri odaklı iş girişimleri için en acil ve ele alınmamış modernizasyon hedeflerinden bazılarını çözmek için tasarlanmıştır.

Veri ağının bir çözüm olarak ortaya çıkmasına neden olan teknoloji trendlerinden bazıları şunlardır:

Zihniyet değişimi, veri ağına doğru atılacak en önemli ilk adımdır. İnovasyonun öğrenilmiş uygulamalarını benimseme isteği, veri mimarisinin başarılı bir şekilde modernleştirilmesine yönelik sıçrama tahtasıdır.

Bu öğrenilen uygulama alanları şunları içerir:

• Tasarım odaklı düşünme, mükemmel veri ürünleri oluşturmak için kurumsal veri alanlarına uygulanan "kötü problemleri" çözmeye yönelik kanıtlanmış bir metodolojidir
• Yapılacak işler teorisi, kurumsal veri ürünlerinin gerçek iş sorunlarını çözmesini sağlamak için müşteri odaklı bir inovasyon ve sonuç odaklı bir inovasyon süreci uygulamaktır

Tasarım odaklı düşünme metodolojileri, işlevler arası inovasyonu sıklıkla engelleyen kurumsal siloları yıkmaya yardımcı olan kanıtlanmış teknikler sunar. Yapılacak işler teorisi, belirli nihai tüketici hedeflerini (veya yapılacak işleri) yerine getiren veri ürünleri tasarlamak için kritik bir temeldir ve ürünün amacını tanımlar.

Veri ürünü yaklaşımı başlangıçta veri bilimi topluluğundan ortaya çıkmış olsa da, artık veri yönetiminin tüm yönlerine uygulanmaktadır. Veri ağı, monolitik teknoloji mimarileri oluşturmak yerine veri tüketicilerine ve iş sonuçlarına odaklanır.

Veri ürünü düşüncesi diğer veri mimarilerine uygulanabilse de, veri ağının önemli bir parçasıdır. Veri ürünü düşüncesinin nasıl uygulanacağına dair pragmatik örnekler için Intuit ekibi deneyimlerinin ayrıntılı bir analizini yazdı.

Ham ürünlerden yerel mağazanızdaki ürünlere kadar her türlü ürün, tüketilmesi amaçlanan değerli varlıklar olarak üretilir ve yapılması gereken belirli bir işi vardır. Veri ürünleri, iş alanına veya çözülmesi gereken soruna bağlı olarak çeşitli şekillerde olabilir ve şunları içerebilir:

• Analitik: geçmiş/gerçek zamanlı raporlar ve konsollar
• Veri kümeleri: farklı şekillerde/formatlarda veri koleksiyonları
• Modeller: etki alanı nesneleri, veri modelleri, makine öğrenimi (ML) özellikleri
• Algoritmalar: ML modelleri, puanlama, iş kuralları
• Veri hizmetleri ve API'ler-belgeler, yükler, konular, REST API'ler ve daha fazlası

Bir veri ürünü tüketim için oluşturulur, genellikle BT dışında sahiplenilir ve aşağıdaki gibi ek özelliklerin izlenmesini gerektirir:

• Paydaş haritası-Bu ürünü kimler yaratıyor ve tüketiyor?
• Paketleme ve belgelendirme-Nasıl tüketiliyor? Nasıl etiketleniyor?
• Amaç ve değer-Ürünün örtülü/açık değeri nedir? Zaman içinde amortisman var mı?
• Kalite ve tutarlılık-Kullanım KPI'ları ve SLA'ları nelerdir? Doğrulanabilir mi?
• Kanıtlanabilirlik, yaşam döngüsü ve yönetişim-Veriler güvenilir ve açıklanabilir mi?

Merkeziyetsiz BT sistemleri modern bir gerçekliktir ve SaaS uygulamalarının ve genel bulut altyapısının (IaaS) yükselişiyle birlikte, uygulamaların ve verilerin merkezi olmaması kalıcı hale gelmiştir. Uygulama yazılımı mimarileri geçmişin merkezi monolitlerinden uzaklaşarak dağıtık mikro hizmetlere (bir hizmet ağı) dönüşüyor. Veri mimarisi de merkezsizleşme yönünde aynı eğilimi izleyecek ve veriler daha geniş bir yelpazedeki fiziksel alanlara ve birçok ağa daha fazla dağıtılacaktır. Buna veri ağı diyoruz.

Ağ, hiyerarşik olmayan büyük bir düğüm grubunun birlikte çalışmasını sağlayan bir ağ topolojisidir.

Bazı yaygın teknoloji örnekleri şunlardır:

• WiFiMesh—daha iyi kapsama için birlikte çalışan birçok düğüm
• ZWave/Zigbee—düşük enerji̇li̇ akilli ev ci̇hazı ağları
• 5G ağ—daha güvenilir ve esnek hücre bağlantıları
• Starlink—küresel ölçekte uydu genişbant ağı
• Hizmet ağı—merkeziyetsiz mikro hizmetler (uygulama yazılımı) üzerinde birleşik kontroller sağlamanın bir yolu

Veri ağı, bu ağ kavramlarıyla uyumludur ve verilerin sanal/fiziksel ağlara ve geniş mesafelere dağıtılması için merkezi olmayan bir yol sağlar. ETL ve veri federasyon araçları gibi eski veri entegrasyonu monolitik mimarileri ve hatta son zamanlarda AWS Glue gibi genel bulut hizmetleri oldukça merkezi bir altyapı gerektirmektedir.

Eksiksiz bir veri ağı çözümü, potansiyel olarak şirket içi sistemlerden birden fazla genel buluta ve hatta uç ağlara kadar uzanan çoklu bulut çerçevesinde çalışabilmelidir.

Verilerin son derece dağıtık ve merkezsiz olduğu bir dünyada, bilgi güvenliğinin rolü son derece önemlidir. Yüksek düzeyde merkezi monolitlerin aksine, dağıtık sistemler çeşitli kullanıcıların kimliklerini doğrulamak ve farklı erişim seviyelerine yetkilendirmek için gerekli faaliyetleri devretmelidir. Ağlar arasında güvenli bir şekilde güven dağıtımı yapmak zordur.

Bazı hususlar şunlardır:

• Bekleme durumunda şifreleme: Depolamaya yazılan veri/etkinlikler olarak
• MTLS, sertifikalar, SSO, gizli depolar ve veri kasaları gibi hizmetler ve veri için dağıtılmış kimlik doğrulama
• Hareket halinde şifreleme: Bellek içinde akan veri/etkinlikler olarak
• Kimlik yönetimi: LDAP/IAM tipi hizmetler, çapraz platform
• Verileri yeniden düzenlemek için hizmet uç noktaları için dağıtılmış yetkilendirmeler
  Örneğin: Mikro hizmet uç noktasının işlendiği konteyner/K8S kümesine ilke karar noktası (PDP) yerleştirmek için Open Policy Agent (OPA) sidecar. LDAP/IAM, JWT özelliğine sahip tüm hizmetler olabilir.
• Deterministik maskeleme: Kişiyle ilişkilendirilebilir verileri güvenilir ve tutarlı bir şekilde gizlemek için

Herhangi bir BT sisteminde güvenlik zor olabilir ve dağıtık sistemlerde yüksek güvenlik sağlamak daha da zordur. Ancak bunlar çözülebilir sorunlardır.

Veri ağının temel ilkelerinden biri, sahiplik ve sorumluluğun dağıtılması kavramıdır. En iyi uygulama, veri ürünlerinin ve veri alanlarının sahipliğini bir kuruluşta verilere en yakın olan kişilerle birleştirmektir. Uygulamada bu, kaynak verilere (örneğin, operasyonel kayıt sistemleri / uygulamalar gibi ham veri kaynakları) veya analitik verilere (örneğin, veri tüketicileri tarafından kolay tüketim için biçimlendirilmiş tipik bileşik veya toplu veriler) hizalanabilir. Her iki durumda da, verilerin üreticileri ve tüketicileri genellikle BT organizasyonlarından ziyade iş birimleriyle uyumludur.

Veri alanlarını organize etmenin eski yolları genellikle ETL araçları, veri ambarları, veri gölleri veya bir şirketin yapısal organizasyonu (insan kaynakları, pazarlama ve diğer iş kolları) gibi teknoloji çözümleriyle uyum sağlama tuzağına düşer. Bununla birlikte, belirli bir iş problemi için veri alanları genellikle çözülmekte olan problemin kapsamına, belirli bir iş sürecinin bağlamına veya belirli bir problem alanındaki uygulamalar ailesine en iyi şekilde uyarlanır. Büyük kurumlarda bu veri alanları genellikle kurum içi organizasyonları ve teknoloji ayak izlerini keser.

Veri alanlarının işlevsel olarak ayrıştırılması, veri ağında yüksek, birinci sınıf bir önceliğe sahiptir. Etki alanı modellemesi için çeşitli veri ayrıştırma metodolojileri, klasik veri ambarı modellemesi (Kimball ve Inmon gibi) veya veri kasası modellemesi dahil olmak üzere veri ağı mimarisine uyarlanabilir, ancak şu anda veri ağı mimarisinde denenen en yaygın metodoloji etki alanı odaklı tasarımdır (DDD). DDD yaklaşımı, mikro hizmetlerin işlevsel ayrıştırılmasından ortaya çıkmıştır ve şimdi bir veri ağı bağlamında uygulanmaktadır.

Oracle'ın veri ağı tartışmasına eklediği önemli bir alan, modern bir veri ağının temel bileşeni olarak hareket halindeki verilerin önemini artırmaktır. Hareket halindeki veri, veri ağını monolitik, merkezi, toplu işlemenin eski dünyasından çıkarmak için temel bir gerekliliktir. Hareket halindeki verilerin yetenekleri, aşağıdaki gibi çeşitli temel veri ağı sorularına yanıt verir:

• Kaynakla uyumlu veri ürünlerine gerçek zamanlı olarak nasıl erişebiliriz?
• Güvenilir veri işlemlerini fiziksel olarak merkeziyetsiz bir veri ağı üzerinden dağıtmak için hangi araçlar sağlayabilir?
• Veri olaylarını, veri ürünü API'leri haline getirmek için ne kullanabilirim?
• Sürekli güncel olması gereken analitik veri ürünleri için veri alanlarına nasıl uyum sağlarım ve güven ve geçerliliği nasıl sağlarım?

Bu sorular sadece bir "uygulama detayı" meselesi değildir, veri mimarisinin kendisi için merkezi bir öneme sahiptir. Statik veriler için alan odaklı bir tasarım, aynı tasarımın dinamik, hareket halindeki veri sürecinden farklı teknikler ve araçlar kullanır. Örneğin, dinamik veri mimarilerinde veri defteri, veri olayları için merkezi doğruluk kaynağıdır.

Defterler, dağıtık bir veri mimarisinin işlemesini sağlayan temel bir bileşendir. Tıpkı bir muhasebe defterinde olduğu gibi, bir veri defteri de işlemleri gerçekleştikleri anda kaydeder.

Defteri dağıttığımızda, veri olayları herhangi bir yerde "yeniden oynatılabilir" hale gelir. Bazı defterler, yüksek kullanılabilirlik ve felaket kurtarma için kullanılan bir uçak uçuş kayıt cihazına benzer.

Merkezi ve monolitik veri depolarının aksine, dağıtık defterler diğer (harici) sistemlerde gerçekleşen atomik olayları ve/veya işlemleri takip etmek için özel olarak üretilmiştir.

Bir veri ağı sadece tek bir defter türü değildir. Kullanım durumlarına ve gereksinimlere bağlı olarak, bir veri ağı aşağıdakiler de dahil olmak üzere farklı olay odaklı veri defteri türlerinden yararlanabilir:

• Kafka veya Pulsar gibi — genel amaçlı olay defteri
• Veri olayı defteri — dağıtılmış CDC/çoğaltma araçları
• Mesajlaşma ara yazılımı—ESB, MQ, JMS ve AQ dahil
• Blok zinciri defteri—güvenli, değişmez, çok taraflı işlemler için

Bu defterler birlikte, tüm işletme için bir tür dayanıklı olay günlüğü görevi görebilir ve kayıt sistemleri ile analiz sistemlerinde meydana gelen veri olaylarının çalışan bir listesini sağlayabilir.

Çok dilli veri akışları her zamankinden daha yaygındır. Bunlar olay türlerine, yüklere ve farklı işlem semantiklerine göre değişir. Bir veri ağı, çeşitli kurumsal veri iş yükleri için gerekli akış türlerini desteklemelidir.

Elbette, bir veri ağının üç özelliğinden daha fazlası vardır. Oracle'ın gelişmekte olan modern veri ağı yaklaşımının yeni ve benzersiz yönlerinden bazıları olduğuna inandığı özelliklere dikkat çekmenin bir yolu olarak yukarıdaki üçüne odaklandık.

Diğer önemli veri ağı özellikleri şunlardır:

• Self servis araçlar: Veri ağı, self-servise yönelik genel veri yönetimi eğilimini benimsediğinden, Citizen geliştiricilerin giderek daha fazla veri sahiplerinin saflarından çıkması gerekecektir
• Veri yönetişimi— Veri ağı aynı zamanda baş veri sorumluları, veri sorumluları ve veri kataloğu satıcıları tarafından uzun yıllardır savunulan daha resmi bir federasyon yönetişim modeline yönelik uzun süredir devam eden eğilimi de benimsemiştir.
• Veri kullanılabilirliği Veri ağının ilkelerini inceler. Veri ürünlerinin yüksek düzeyde kullanılabilir olmasını sağlamak için oldukça fazla temel çalışma vardır. Veri ürünlerine yönelik ilkeler, değerli, kullanılabilir ve paylaşılması mümkün olan verilerle ilgili olacaktır.

Monolitik veri mimarilerinin buluta 'kaldır ve kaydır' geçişlerinin ötesine bakan birçok kuruluş, geçmişteki merkezi uygulamalarını emekliye ayırmayı ve daha modern bir mikro hizmet uygulama mimarisine geçmeyi de amaçlamaktadır.

Ancak eski uygulama monolitleri tipik olarak büyük veritabanlarına bağlıdır ve bu da kesinti, risk ve maliyetleri azaltmak için geçiş planının nasıl aşamalandırılacağı sorusunu gündeme getirir. Bir veri ağı, monolitlerden ağ mimarisine aşamalı geçişler yapan müşteriler için önemli bir operasyonel BT yeteneği sağlayabilir. Örneğin:

• Verilerin 'sınırlı bağlama' göre filtrelenmesi gibi veritabanı işlemlerinin alt alan boşaltımı
• Aşamalı geçişler için çift yönlü işlem replikasyonu
• Ana bilgisayardan DBaaS'a gibi platformlar arası senkronizasyon

Mikro hizmet mimarlarının dilinde bu yaklaşım, çift yönlü bir işlem çıkış kutusu kullanarak incir ağacı geçiş düzenini etkinleştirmek için her seferinde bir sınırlı bağlamdan yararlanır.

İş açısından kritik uygulamalar, esneklik ve süreklilik konusunda çok yüksek KPI'lar ve SLA'lar gerektirir. Bu uygulamaların monolitik, mikro hizmet veya ikisinin arasında bir şey olup olmadığına bakılmaksızın, yıkılamazlar!

Görev açısından kritik sistemler için, dağıtılmış bir nihai tutarlılık veri modeli genellikle kabul edilemez. Ancak bu uygulamaların birçok veri merkezinde çalışması gerekir. Bu da iş sürekliliği açısından şu soruyu akla getiriyor: "Uygulamalarımı birden fazla veri merkezinde çalıştırırken doğru ve tutarlı verileri nasıl garanti edebilirim?"

Monolitik mimarilerin 'parçalanmış veri kümeleri' kullanıp kullanmadığına veya mikro hizmetlerin siteler arası yüksek kullanılabilirlik için kurulup kurulmadığına bakılmaksızın, veri ağı herhangi bir mesafede doğru, yüksek hızlı veriler sunar.

Veri ağı, siteler arasında merkezi olmayan ancak %100 doğru veriler için temel sağlayabilir. Örneğin:

• Çok düşük gecikmeli mantıksal işlemler (platformlar arası)
• Doğru veri için ACID özellikli garantiler
• Çok aktif, çift yönlü ve çatışma çözümü

Modern, hizmet ağı tarzı bir platform, veri alışverişi için olayları kullanır. Veri katmanındaki toplu işlemeye bağlı olmak yerine, veri yükleri uygulamada veya veri deposunda olaylar gerçekleştiğinde sürekli olarak akar.

Bazı mimariler için mikro hizmetlerin birbirleriyle veri yükü alışverişi yapması gerekir. Diğer modeller monolitik uygulamalar veya veri depoları arasında değişim gerektirir. Bu da şu soruyu akla getiriyor: "Uygulamalarım ve veri depolarım arasında mikro hizmet veri yüklerini nasıl güvenilir bir şekilde taşıyabilirim?"

Bir veri ağı, mikro hizmet merkezli veri alışverişi için temel teknolojiyi sağlayabilir. Örneğin:

• Bağlam içinde mikro hizmetten mikro hizmete
• Bağlamlar arasında mikro hizmetten mikro hizmete
• Monolitten mikro hizmete/ mikro hizmetten monolite

Olay kaynağı, CQRS ve transaction outbox gibi mikro hizmet modelleri yaygın olarak anlaşılan çözümlerdir. Veri ağı, bu modelleri ölçekte tekrarlanabilir ve güvenilir hale getirmek için araçlar ve çerçeveler sağlar.

Mikro hizmet tasarım modellerinin ötesinde, kurumsal entegrasyon ihtiyacı veritabanları, iş süreçleri, uygulamalar ve her türden fiziksel cihaz gibi diğer BT sistemlerine kadar uzanmaktadır. Veri ağı, hareket halindeki verileri entegre etmek için temel sağlar.

Hareket halindeki veriler genellikle olay odaklıdır. Bir kullanıcı eylemi, bir cihaz olayı, bir işlem adımı veya bir veri deposu işleminin tümü veri yükü içeren bir olayı başlatabilir. Bu veri yükleri Nesnelerin İnterneti (IoT) sistemlerinin, iş süreçlerinin ve veritabanlarının, veri ambarlarının ve veri göllerinin entegrasyonu için çok önemlidir.

Bir veri ağı, kurum genelinde gerçek zamanlı entegrasyon için temel teknolojiyi sağlar. Örneğin:

• Gerçek dünyadaki cihaz olaylarını BT sistemlerine bağlama
• ERP sistemleri genelinde iş süreçlerinin entegrasyonu
• Operasyonel veritabanlarını analitik veri depolarıyla uyumlu hale getirme

Büyük kuruluşlar doğal olarak eski ve yeni sistemlerin, monolit ve mikro hizmetlerin, operasyonel ve analitik veri depolarının bir karışımına sahip olacaktır; bir veri ağı, bu kaynakları farklı iş ve veri alanları arasında birleştirmeye yardımcı olabilir.

Analitik veri depoları arasında veri haritaları, veri ambarları, OLAP küpleri, veri gölleri ve veri göl evi teknolojileri yer alabilir.

Genel olarak konuşmak gerekirse, verileri bu analitik veri depolarına getirmenin yalnızca iki yolu vardır:

• Bir zaman çizelgesinde toplu/mikro toplu yükleme
• Veri alma akışı - veri olaylarını sürekli yükleme

Bir veri ağı, akışlı veri alma özelliği için temel sağlar. Örneğin:

• Veritabanlarından veya veri depolarından gelen veri olayları
• Fiziksel cihaz telemetrisinden cihaz olayları
• Uygulama olay günlüğü veya ticari işlemler

Olayları akışa göre almak kaynak sistemler üzerindeki etkiyi azaltabilir, verilerin doğruluğunu artırabilir (veri bilimi için önemlidir) ve gerçek zamanlı analitiği mümkün kılabilir.

Analitik veri depolarına alındıktan sonra, verileri farklı veri aşamalarında veya veri bölgelerinde hazırlamak ve dönüştürmek için genellikle veri işlem hatlarına ihtiyaç duyulur. Bu veri iyileştirme süreci genellikle aşağı akış analitik veri ürünleri için gereklidir.

The data network can provide an independently managed data pipeline layer that works with analytical data stores and provides the following core services:

• Self servis veri keşfi ve veri hazırlama
• Alanlar arasında veri kaynaklarının yönetişimi
• Veri hazırlama ve gerekli veri ürünü formatlarına dönüştürme
• Tutarlılığı sağlayan politika ile veri doğrulama

Bu veri işlem hatları, farklı fiziksel veri depoları (haritalar, depolar veya göller gibi) arasında veya Apache Spark ve diğer veri gölü teknolojileri gibi veri akışını destekleyen analitik veri platformları içinde bir "itme veri akışı" olarak çalışabilmelidir.

Olaylar sürekli olarak gerçekleşmektedir. Bir akıştaki olayların analizi, an be an neler olup bittiğini anlamak için çok önemli olabilir.

Gerçek zamanlı olay akışlarının bu tür zaman serisi tabanlı analizi, gerçek dünyadaki IoT cihaz verileri için ve BT veri merkezlerinizde veya dolandırıcılık izleme gibi finansal işlemlerde neler olup bittiğini anlamak için önemli olabilir.

Tam özellikli bir veri ağı, birçok farklı türde olay zaman penceresi boyunca her türden olayı analiz etmek için temel yetenekleri içerecektir. Örneğin:

• Basit olay akışı analizi (web olayları)
• İş etkinliği izleme (SOAP/REST olayları)
• Karmaşık olay işleme (çoklu akış korelasyonu)
• Veri olay analizi (DB/ACID işlemleri üzerinde)

Veri ardışık düzenleri gibi, akış analitiği de yerleşik veri gölü altyapısı içinde veya ayrı olarak bulut yerel hizmetleri olarak çalışabilir.

Veri entegrasyonunda öncü konumda olanlar, çeşitli esnek veri depolarından gerçek zamanlı operasyonel ve analitik veri entegrasyonu arayışındadır. Veri mimarisi akış analitiğine doğru evrildikçe yenilikler de durmaksızın ve hızla devam ediyor. Operasyonel yüksek kullanılabilirlik gerçek zamanlı analitiğe yol açmıştır ve veri mühendisliği otomasyonu veri hazırlamayı basitleştirerek veri bilimcileri ve analistleri self servis araçlarla etkinleştirmektedir.