Programlama

Kritik Toplayıcı

İş Liderlerinin genellikle tüm işletme genelindeki geniş bir faaliyet yelpazesinden etkilenen kararlar alması gerekir. Örneğin, satış marjlarını anlayan bir üretici, hammadde maliyeti, üretim tesislerinin işletme maliyetleri, satış seviyeleri ve fiyatlar hakkında bilgi gerektirebilir. Bölgeye, pazara veya tüm kuruluşa göre toplanan doğru bilgilerin anlaşılır bir biçimde mevcut olması gerekir.

Kritik Toplayıcı, bu bilgileri çıkarmak için hangi sistemleri “ziyaret edeceğini”, hangi dosyaları/tabloları/API’leri denetleyeceğini, farklı kaynaklardan gelen bilgileri nasıl ilişkilendireceğini ve bu verileri toplamak için gereken iş mantığını bilen bir yazılım bileşenidir. Bu bilgileri, basılı tablolar, çizelgeler ve tablolar içeren bir gösterge panosu veya tüketicilerin elektronik tablolarına giden bir veri akışı aracılığıyla iş liderlerine sağlar.

Doğaları gereği bu raporlar, örneğin finansal veriler, satış verileri, müşteri verileri vb. gibi bir işletmenin birçok farklı bölümünden veri çekmeyi içerir. Kapsülleme ve endişelerin ayrılması gibi iyi uygulamalar kullanılarak uygulandığında bu, belirli bir mimari zorluk yaratmaz. Ancak, bu gereksinim eski sistemlerin, özellikle de monolitik anabilgisayarların veya veri ambarlarının üzerine uygulandığında genellikle belirli sorunlarla karşılaşırız.

Miras içinde bu kalıbın uygulanması neredeyse her zaman işleme sırasında ihtiyaç duyduğu verileri getirmek için alt bileşenlere doğrudan erişebilme avantajından yararlanır. Bu, özellikle kötü bir bağlantı kurar, çünkü yukarı akış sistemleri, şimdiki zamanı bozma riski nedeniyle veri yapılarını geliştiremez. İstilacı Kritik Toplayıcı . Böyle bir başarısızlığın sonucu, işletmeyi ve liderlerini desteklemedeki kritik rolü nedeniyle özellikle yüksek ve görünürdür.

Şekil 1: Yaygın Toplayıcı kullanarak raporlama

Nasıl çalışır

İlk olarak, bir rapor gibi bir çıktı üretmek için hangi girdi verilerinin gerekli olduğunu tanımlarız. Genellikle kaynak veriler, genel mimarinin bileşenleri içinde zaten mevcuttur. Daha sonra kaynak verilere “yüklemek” için bir uygulama oluşturur ve çıktımızı oluşturmak için onu işleriz. Buradaki kilit nokta, kaynak verilerin yapısıyla sıkı bir bağlantı oluşturmadığımızdan veya ihtiyaç duyduğumuz verilere ulaşmak için mevcut bir bileşenin kapsüllenmesini kırmadığımızdan emin olmaktır. Veritabanı düzeyinde bu, ETL (Ayıkla, Dönüştür, Yükle) veya hizmet düzeyinde bir API aracılığıyla gerçekleştirilebilir. ETL yaklaşımlarının genellikle kaynak ya da hedef formata bağlı hale geldiğini belirtmekte fayda var; uzun vadede bu değişim için bir engel haline gelebilir.

İşleme kayıt bazında yapılabilir, ancak daha karmaşık senaryolar için ara duruma ihtiyaç duyulabilir ve bu ara veriler hazır olduğunda işlemedeki bir sonraki adım tetiklenir. Bu nedenle birçok uygulama, bir dizi işlem hattı olan bir Pipeline kullanır.
Borular ve Filtrelerbir adımın çıktısı bir sonraki adım için girdi haline gelir.

Verilerin güncelliği önemli bir husustur, kaynak verileri doğru zamanlarda, örneğin bir işlem gününün bitiminden sonra kullandığımızdan emin olmamız gerekir. Bu, toplayıcı ve kaynak sistemler arasında zamanlama bağımlılıkları yaratabilir.

Bir yaklaşım, belirli zamanlarda şeyleri tetiklemektir, ancak bu yaklaşım herhangi bir kaynak sistemindeki gecikmelere karşı savunmasızdır. örneğin toplayıcıyı saat 3’te çalıştırın, ancak herhangi bir kaynak sistemde bir gecikme olması durumunda, toplu sonuçlar eski veya bozuk verilere dayalı olabilir. Daha sağlam bir yaklaşım da, kaynak sistemlerin, tüm veriler kullanılabilir olduğunda toplayıcının tetiklenmesiyle, kaynak verileri hazır olduğunda göndermesini veya yayınlamasını sağlamaktır. Bu durumda, toplu sonuçlar ertelenir, ancak en azından geçerli girdi verilerine dayanmalıdır.

Kaynak verilerin zaman damgalı olmasını da sağlayabiliriz, ancak bu, kaynak sistemlerin halihazırda doğru zaman verilerine sahip olmasına veya değiştirilmesinin kolay olmasına bağlıdır; bu, eski sistemler için geçerli olmayabilir. Zaman damgalı veriler mevcutsa, tutarlı ve geçerli sonuçlar sağlamak için daha gelişmiş işleme uygulayabiliriz, örneğin:
Sürüm Değeri.

Ne Zaman Kullanılır

Bu model, bir işletme içindeki birçok farklı bölüm veya alan arasında genel bir görünüm elde etmeye gerçekten ihtiyaç duyduğumuzda, genellikle farklı alanlardan gelen verileri bir özet görünüm veya karar desteği için kullanılan bir dizi ölçümle ilişkilendirmemiz gerektiğinde kullanılır.

eski tezahür

Ağ bant genişliği ve G/Ç hızlarındaki geçmiş sınırlamalar göz önüne alındığında, veri işlemeyi veri depolama ile aynı makinede birlikte konumlandırmak genellikle mantıklıydı. Makul erişim sürelerine sahip yüksek hacimli veri depolama, genellikle özel donanım gerektirdi ve bu, merkezi veri depolama çözümlerine yol açtı. Bu iki güç, bu kalıbın birçok eski uygulamasını, veri güncelleme çizelgelerine ve zamanlamalarına bağlı olarak kaynak veri yapılarına sıkı sıkıya bağlı hale getirmek için bir araya geldi ve uygulamalar genellikle veri depolama ile aynı donanımda.

Sonuç İstilacı Kritik Toplayıcı köklerini genel sistemin birçok farklı bölümüne yerleştirir – bu nedenle çıkarılmasını çok zorlaştırır. Genel olarak konuşursak, yer değiştirmeye iki yaklaşım vardır. İlk yaklaşım, Critical Aggregator’ın yeni bir uygulamasını oluşturmaktır. Akışı Yönlendirgibi diğer desenlerle birlikte Kaynağa Dön. Alternatif, daha yaygın yaklaşım, toplayıcıyı yerinde bırakmak, ancak bu tür teknikleri kullanmaktır. Eski Taklit yer değiştirme boyunca gerekli verileri sağlamak. Eninde sonunda yeni bir uygulamaya ihtiyaç olduğu açıktır.

ile zorluklar İstilacı Kritik Toplayıcı

Kritik Toplayıcı’nın eski uygulamalarının çoğu, çeşitli kaynak veri biçimlerinin yapısına ve biçimine doğrudan bağlı olan herhangi bir işlemle, kaynak veriler etrafında kapsülleme eksikliği ile karakterize edilir. Ayrıca, İşleme ve Veri Erişim kodunun iç içe geçmesiyle ilgili endişelerin zayıf bir şekilde ayrılmasına sahiptirler. Çoğu uygulama, toplu veri işleme dillerinde yazılmıştır.

Anti-kalıp, özellikle uygulamalar herhangi bir kapsülleme olmadan doğrudan kaynak verilere ulaştığında, bir sistem içinde yüksek miktarda bağlantı ile karakterize edilir. Bu nedenle, kaynak veri yapısındaki herhangi bir değişiklik, işleme ve çıktıları hemen etkileyecektir. Bu soruna yaygın bir yaklaşım, kaynak veri formatlarını dondurmak veya tüm kaynak verilere bir değişiklik kontrol süreci eklemektir. Bu değişiklik kontrol süreci, özellikle büyük kaynak veri ve sistem hiyerarşileri mevcut olduğunda oldukça karmaşık hale gelebilir.

İstilacı Kritik Toplayıcı ayrıca veri hacmi büyüdükçe zayıf bir şekilde ölçeklenme eğilimi gösterir, çünkü kapsülleme eksikliği herhangi bir optimizasyon veya paralel işlemenin başlatılmasını sorunlu hale getirir, yürütme süresinin veri hacimleriyle birlikte artma eğiliminde olduğunu görüyoruz. İşleme ve veri erişim mekanizmaları birbirine bağlı olduğundan, bu, tüm sistemi dikey olarak ölçeklendirme ihtiyacına yol açabilir. Bu, daha iyi kapsüllenmiş bir sistemde herhangi bir veri deposundan ayrı olarak ticari donanım tarafından yapılabilecek işlemeyi ölçeklendirmenin çok pahalı bir yoludur.

İstilacı Kritik Toplayıcı zamanlama sorunlarına duyarlı olma eğilimindedir. Kaynak verilerin geç güncellenmesi, toplu raporların kritik doğası göz önüne alındığında, bir işletme için ciddi sorunlara neden olabileceğinden, toplamayı geciktirebilir veya eski veriler üzerinde çalışmasına neden olabilir. İşleme sırasında kaynak verilere doğrudan erişim, uygulamaların genellikle, kaynak verilerin sabit ve değişmez kalırken güncel olması gereken tanımlanmış bir “güvenli zaman penceresine” sahip olduğu anlamına gelir. Bu zaman pencereleri genellikle sistem(ler) tarafından uygulanmaz, bunun yerine genellikle başka bir yerde belgelenen bir kuraldır.

İşlem süresi arttıkça bu, kaynak verileri üreten sistemler için zamanlama kısıtlamaları oluşturabilir. Sabit bir zamanımız varsa, nihai çıktının hazır olması gerekir, o zaman işlem süresindeki herhangi bir artış, sırayla, herhangi bir kaynak verinin daha önce güncel ve kararlı olması gerektiği anlamına gelir. Bu çeşitli zamanlama kısıtlamaları, farklı zaman dilimlerinden gelen verilerin dahil edilmesini sorunlu hale getirir, çünkü herhangi bir gecelik “güvenli zaman penceresi” dünyanın başka yerlerindeki normal çalışma saatleriyle örtüşmeye başlayabilir. Zamanlama ve tetikleme sorunları, çok yaygın bir hata kaynağıdır ve bu modeldeki hatalardır, bunların teşhis edilmesi zor olabilir.

İşleme ve kaynak veri erişimi arasındaki endişelerin zayıf ayrımı nedeniyle, değişiklik ve test etme de zordur. Zamanla bu kod, hatalar için geçici çözümler, kaynak veri biçimi değişiklikleri ve tüm yeni özellikleri içerecek şekilde büyür. Tipik olarak, Kritik Toplayıcı’nın eski uygulamalarının çoğunun, bu zorluklar ve verilerin yanlış olma iş riskinin yanı sıra “donmuş” bir durumda olduğunu görüyoruz. Sıkı bağlantı nedeniyle, herhangi bir değişiklik donması kaynak verilere ve dolayısıyla ilgili kaynak sistemlere yayılma eğilimindedir.

Ayrıca, toplayıcı için ‘şişkin’ çıktılar görme eğilimindeyiz, çünkü yukarıdaki sorunlar göz önüne alındığında, yeni bir veri parçası eklemek için mevcut bir raporu genişletmek, yepyeni bir rapor oluşturmaktan genellikle daha kolaydır. Bu, uygulama boyutunu ve karmaşıklığının yanı sıra her raporun iş açısından kritik niteliğini artırır. Ayrıca, ihtiyaçları daha basit ve daha hedefli çıktılarla karşılanabilecek ayrı kullanıcı grupları olup olmadığını keşfetmek için ilk önce toplayıcının çıktılarının her kullanımını parçalamamız gerektiğinden, değiştirmeyi zorlaştırabilir.

COBOL ve assembler dillerinde bu (anti-) modelin uygulamalarını görmek yaygındır, bu hem değiştirmenin zorluğunu hem de çıktıların bir işletme için ne kadar kritik olabileceğini gösterir.

İlgili Makaleler

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.

Başa dön tuşu