Veri ambarının ETL bileşeni genellikle ambarın gölgesinde kalır ve ana veritabanı veya ön uç bileşeni, iş zekası ve raporlamaya göre daha az dikkat çeker. Aynı zamanda depoyu verilerle doldurma mekaniği açısından ETL önemli bir rol oynar ve yöneticilerin diğer bileşenlerden daha az dikkat etmesini gerektirmez. Adım Alexander, şu anda Rostelecom'da ETL'yi yönetiyorum ve bu makalede, Rostelecom'daki büyük bir veri ambarındaki en ünlü ETL sistemlerinden birinin yöneticisinin uğraşmak zorunda olduğu şeylerin bir kısmını paylaşmaya çalışacağım.
Sevgili okuyucular, genel olarak veri ambarı projemize ve Informatica PowerCenter ürününe zaten aşina iseniz, hemen bir sonraki bölüme geçebilirsiniz.
Birkaç yıl önce tek bir kurumsal veri ambarı fikri olgunlaştı ve Rostelecom'da uygulanmaya başlandı. Bireysel sorunları çözen bir dizi depo zaten oluşturulmuştu, ancak senaryoların sayısı arttı, destek maliyetleri de arttı ve geleceğin merkezileştirmede yattığı ortaya çıktı. Mimari olarak bu, Hadoop ve GreenPlum, yardımcı veritabanları, ETL mekanizmaları ve BI üzerinde uygulanan birkaç katmandan oluşan depolamanın kendisidir.
Aynı zamanda, çok sayıda coğrafi olarak dağılmış, heterojen veri kaynağı nedeniyle, çalışması Informatica tarafından kontrol edilen özel bir veri yükleme mekanizması oluşturuldu. Bunun sonucunda veri paketleri Hadoop arayüz alanına ulaşır ve ardından depolama katmanları, Hadoop ve GreenPlum üzerinden veri yükleme işlemleri başlar ve Informatica'da uygulanan ETL kontrol mekanizması olarak adlandırılan mekanizma tarafından yönetilirler. Dolayısıyla Informatica sistemi deponun işleyişini sağlayan temel unsurlardan biridir.
Depolamamız aşağıdaki gönderilerden birinde daha ayrıntılı olarak açıklanacaktır.
Informatica PowerCenter/Büyük Veri Yönetimi şu anda veri entegrasyon araçları alanında lider yazılım olarak kabul edilmektedir. Bu, ETL (Dönüştürme Yükünü Çıkarma), veri kalitesi yönetimi, MDM (Ana Veri Yönetimi), ILM (Bilgi Yaşam Döngüsü Yönetimi) ve daha birçok alandaki en güçlü oyunculardan biri olan Amerikan şirketi Informatica'nın bir ürünüdür.
Kullandığımız PowerCenter, Informatica uygulamalarının kendi hizmetlerini çalıştırdığı entegre bir Tomcat uygulama sunucusudur:
domainAslında bu diğer her şeyin temelidir; hizmetler, kullanıcılar ve GRID bileşenleri etki alanı içinde çalışır.
Yönetici KonsoluÜrünle etkileşim için ana araç olan Informatica Developer istemcisine ek olarak web tabanlı bir yönetim ve izleme aracı olan
MRS, Model Depo HizmetiBir meta veri deposu olan , meta verilerin fiziksel olarak depolandığı veritabanı ile geliştirmenin gerçekleştiği Informatica Developer istemcisi arasındaki bir katmandır. Depolar, bir dizi diğer Infromatica hizmetine ilişkin veri açıklamalarını ve diğer bilgileri, örneğin görevlerin yürütülmesine (Programlar) veya verilerin izlenmesine yönelik programların yanı sıra, özellikle aynı uygulamanın birlikte çalışmak için kullanılmasına izin veren uygulama parametrelerini saklar. çeşitli veri kaynakları ve alıcıları.
DIS, Veri Entegrasyon Hizmeti, bu, ana işlevsel süreçlerin gerçekleştiği, içinde uygulamaların çalıştığı ve İş Akışlarının (eşleme sırasının ve bunların etkileşimlerinin açıklamaları) ve Eşlemelerin (dönüşümler, dönüşümlerin kendilerinin gerçekleştiği bloklar, veri işleme) fiili başlatıldığı bir hizmettir. ) yer almak.
GRID yapılandırması – esasen, DIS tarafından başlatılan yükün düğümler (yani etki alanının parçası olan sunucular) arasında dağıtıldığı durumlarda, birden fazla sunucuyu kullanarak bir kompleks oluşturma seçeneği. Bu seçenek durumunda, DIS'teki yükün, belirli bir tek düğüm üzerinde çalışmak yerine üzerinde çalıştığı birkaç düğümü birleştiren ek bir GRID soyutlama katmanı yoluyla dağıtılmasına ek olarak, ek yedek MRS örnekleri de oluşturulabilir. Ana düğümün arızalanması durumunda harici çağrıların yedek düğümler aracılığıyla yapılabileceği yüksek kullanılabilirliği bile uygulayabilirsiniz. Şimdilik bu inşaat seçeneğinden vazgeçtik.
Informatica PowerCenter, şematik
Veri tedarik zincirinin bir parçası olarak çalışmanın ilk aşamalarında, bazıları Informatica'nın o dönemdeki istikrarsız işleyişinden kaynaklanan düzenli olarak sorunlar ortaya çıktı. Bu destanın unutulmaz anlarından bazılarını paylaşacağım: Informatica 10'da uzmanlaşmak.
Eski Informatica logosu
Sorumluluk alanımız diğer Informatica ortamlarını da içeriyor, farklı yük nedeniyle kendilerine has özellikleri var ama şimdilik Informatica'nın veri ambarının bir ETL bileşeni olarak nasıl geliştiğini tam olarak hatırlayacağım.
Nasıl oldu
2016 yılında Informatica'nın çalışmalarından sorumlu olduğumuzda, sürüm 10.0'a ulaşmıştı ve ciddi bir çözümde küçük sürüm .0'a sahip bir ürünü kullanmaya karar veren iyimser meslektaşlarımız için her şey açık görünüyordu - kullanmamız gerekiyor yeni versiyon! Donanım kaynakları açısından o zamanlar her şey yolundaydı.
2016 baharından beri Informatica'nın işlerinden bir yüklenici sorumluydu ve sistemin az sayıdaki kullanıcısına göre "haftada birkaç kez çalışıyordu." Burada havuzun fiili olarak PoC aşamasında olduğunu, ekipte hiçbir yöneticinin bulunmadığını ve sistemin çeşitli nedenlerle sürekli çöktüğünü, ardından yüklenicinin mühendisinin onu tekrar aldığını açıklığa kavuşturmak gerekir.
Sonbaharda ekibe üç yönetici katılarak sorumluluk alanlarını kendi aralarında paylaştırdılar ve Informatica dahil projedeki sistemlerin işleyişini organize etmek için normal çalışma başladı. Ayrıca bu ürünün yaygın olmadığını ve her türlü soruya cevap bulabileceğiniz, her sorunu çözebileceğiniz geniş bir topluluğa sahip olduğunu da söylemek gerekir. Bu nedenle Rus ortağımız Informatica'nın tam teknik desteği çok önemliydi ve bu sayede o zamanlar genç olan Informatica 10'daki tüm hatalarımız ve hatalarımız düzeltildi.
Ekibimizin geliştiricileri ve yüklenici için yapmamız gereken ilk şey, Informatica'nın çalışmasını stabilize etmek, web yönetim konsolunun (Informatica Yöneticisi) işlevselliğini sağlamaktı.
Informatica geliştiricileriyle sık sık bu şekilde tanıştık
Sebeplerini bulma sürecini bir kenara bırakırsak, çökmelerin ana nedeni Informatica yazılımının, ağ ortamı açısından nispeten uzak bir sunucuda bulunan veri havuzu ile etkileşim modeliydi. Bu durum gecikmelere neden oldu ve Informatica alanının durumunu izleyen mekanizmaların aksamasına neden oldu. Veritabanında bir miktar ayarlama yapıldıktan, Informatica'nın parametreleri değiştirilerek veritabanı gecikmelerine karşı daha toleranslı hale getirildikten ve sonunda Informatica sürümünün 10.1'e güncellenmesinden ve veritabanının önceki sunucudan Informatica'ya daha yakın bulunan bir sunucuya aktarılmasından sonra sorun ortadan kalktı. ve o zamandan bu yana gözlemlediğimiz bu türden çökmeler yaşandı.
Informatica Monitor'ü çalıştırma girişimlerinden biri
Yönetim konsolunun durumu da kritikti. Aktif geliştirme doğrudan nispeten üretken bir ortamda devam ettiğinden, meslektaşların sürekli olarak eşleme ve iş akışı çalışmalarını "hareket halindeyken" analiz etmeleri gerekiyordu. Yeni Informatica'da Veri Entegrasyon Hizmetinin bu tür izleme için ayrı bir aracı yoktur, ancak yönetim web konsolunda (Informatica Yönetici Monitörü) uygulamaların çalışmasını, iş akışını ve eşlemeleri izleyebileceğiniz bir izleme bölümü ortaya çıkmıştır, başlatır, günlükler. Periyodik olarak konsol tamamen kullanılamaz hale geldi veya DIS'teki mevcut işlemlerle ilgili bilgilerin güncellenmesi durduruldu veya sayfalar yüklenirken hatalar oluştu.
İşlemi stabilize etmek için Java parametrelerinin seçimi
Sorun birçok yönden düzeltildi, parametreleri değiştirmek için deneyler yapıldı, günlükler ve jstack toplandı, desteğe gönderildi, aynı zamanda aktif Google araması ve basit gözlem vardı.
Her şeyden önce, izleme için ayrı bir MRS oluşturuldu, daha sonra ortaya çıktığı gibi, haritalamalar çok yoğun bir şekilde başlatıldığı için bu, ortamlarımızdaki ana kaynak tüketicilerinden biridir. Java heap ve diğer bazı parametrelerle ilgili parametreler değiştirildi.
Sonuç olarak, Informatica 10.1.1'in bir sonraki güncellemesiyle konsolun ve monitörün çalışması stabilize edildi, geliştiriciler daha verimli çalışmaya başladı ve düzenli süreçler giderek daha düzenli hale geldi.
Geliştirme ve yönetim arasındaki etkileşim deneyimi ilginç olabilir. İşlerin nasıl yürüdüğüne, neyin yapılabileceğine ve neyin yapılamayacağına dair genel bir anlayış meselesi, karmaşık sistemleri kullanırken her zaman önemlidir. Bu nedenle, öncelikle yönetim ekibine yazılımın nasıl yönetileceği konusunda, geliştirme ekibine ise sistemde kod yazma ve çizim süreçlerinin nasıl yazılacağı konusunda eğitim vermenizi ve daha sonra birinci ve ikinci ekibi sonuç üzerinde çalışmaya göndermenizi rahatlıkla tavsiye edebiliriz. Zamanın sonsuz bir kaynak olmadığı durumlarda bu gerçekten önemlidir. Pek çok sorun, seçeneklerin rastgele araştırılmasıyla bile çözülebilir, ancak bazen bazıları ön bilgi gerektirir; bizim durumumuz bu aksiyomu anlamanın önemini doğrulamaktadır.
Örneğin, MRS'de sürüm oluşturmayı etkinleştirmeye çalıştığımızda (sonunda farklı bir SVN sürümüne ihtiyaç duyulduğu ortaya çıktı), bir süre sonra sistemin yeniden başlama süresinin birkaç on dakikaya çıktığını fark ettiğimizde alarma geçtik. Başlangıçtaki gecikmenin nedenini bulduktan ve sürüm oluşturmayı devre dışı bıraktıktan sonra yine iyi iş çıkardık.
Informatica ile ilgili dikkate değer engeller arasında büyüyen java parçacıklarıyla yapılan destansı savaş yer alıyor. Bir noktada çoğaltmanın, yani yerleşik süreçleri çok sayıda kaynak sisteme genişletmenin zamanı geldi. 10.1.1'deki tüm süreçlerin iyi çalışmadığı ve bir süre sonra DIS'in çalışamaz hale geldiği ortaya çıktı. On binlerce iş parçacığı tespit edildi ve bunların sayısı özellikle uygulama dağıtım prosedürü sırasında gözle görülür şekilde arttı. Bazen işlevselliği geri yüklemek için günde birkaç kez yeniden başlatmam gerekiyordu.
Burada desteğe teşekkür etmemiz gerekiyor; sorunlar EBF (Acil Durum Hata Düzeltmesi) kullanılarak nispeten hızlı bir şekilde yerelleştirildi ve düzeltildi - bundan sonra herkes aracın gerçekten işe yaradığı hissine kapıldı.
Hala çalışıyor!
Hedef modunda çalışmaya başladığımızda Informatica böyle görünüyordu. Informatica 10.1.1HF1 sürümü (HF1, bir EBF kompleksinden bir satıcı derlemesi olan HotFix1'dir) ek olarak yüklenmiş EBF'ye sahip, ölçeklendirme ve diğer bazı sorunlarımızı düzeltir, GRID'nin parçası olan üç sunucudan birinde, 20 x86_64 çekirdek ve depolama, çok yavaş bir yerel disk dizisinde - bu, bir Hadoop kümesinin sunucu yapılandırmasıdır. Başka bir benzer sunucuda - hem Informatica etki alanının hem de ETL kontrol mekanizmasının çalıştığı Oracle DBMS. Tüm bunlar, her iki tarafta da ekipte kullanılan standart izleme araçları (Zabbix + Grafana) - Informatica'nın kendisi, hizmetleri ve buna giren yükleme süreçleri tarafından izlenir. Artık hem performans hem de stabilite, dış faktörleri hesaba katmadan, artık yükü sınırlayan ayarlara bağlı.
Ayrı olarak GRID hakkında da söyleyebiliriz. Ortam, yük dengeleme olanağına sahip üç düğüm üzerine inşa edildi. Ancak test sırasında, uygulamalarımızın çalışan örnekleri arasındaki etkileşim sorunları nedeniyle bu yapılandırmanın beklendiği gibi çalışmadığı keşfedildi ve üç düğümden ikisini etki alanından kaldırarak bu yapı şemasından geçici olarak vazgeçmeye karar verdiler. Aynı zamanda, şemanın kendisi aynı kaldı ve şimdi tam olarak bir GRID hizmetidir, ancak tek bir düğüme dejenere olmuştur.
Şu anda, monitör devresini düzenli olarak temizlerken performanstaki düşüşle ilgili zorluk devam ediyor - CNN'deki eşzamanlı işlemler ve temizlemenin yürütülmesiyle, ETL kontrol mekanizmasının çalışmasında arızalar meydana gelebilir. Bu şu anda "koltuk değneği gibi" çözülüyor - önceki tüm verilerin kaybıyla birlikte monitör devresini manuel olarak temizleyerek. Bu, normal rutin çalışma sırasında üretkenlik açısından çok kritik değildir, ancak şimdilik normal bir çözüm arayışı devam etmektedir.
Aynı durumdan başka bir sorun daha ortaya çıkıyor - bazen kontrol mekanizmamızın birden fazla başlatılması meydana geliyor.
Mekanizma arızasına yol açan birden fazla uygulamanın başlatılması
Bir programa göre çalışırken, sistemin ağır yüklendiği anlarda, bazen mekanizmanın bozulmasına yol açacak durumlar meydana gelir. Sorun manuel olarak giderilmeye devam ediliyor ve kalıcı bir çözüm aranıyor.
Genel olarak özetleyebiliriz ki, yoğun bir yük söz konusu olduğunda buna yeterli kaynak sağlamak çok önemlidir, bu Informatica'nın kendisi için donanım kaynakları için de geçerlidir, aynı şekilde veritabanı deposu için de geçerlidir ve optimum ayarların sağlanması için de geçerlidir. onlar için. Ek olarak, hangi veritabanı yerleştirme şemasının daha iyi olduğu sorusu açık kalıyor - ayrı bir ana bilgisayarda mı yoksa Informatica yazılımının çalıştığı aynı yerde mi? Bir yandan tek sunucuda daha ucuz olacak ve birleştirildiğinde ağ etkileşimindeki olası sorun pratik olarak ortadan kaldırılacak, diğer yandan ana bilgisayardaki veritabanından gelen yük, Informatica'dan gelen yük ile desteklenecek.
Her ciddi üründe olduğu gibi Informatica'nın da komik anları var.
Bir keresinde bir tür kazayı çözerken, MRS kayıtlarının garip bir şekilde olayların zamanını gösterdiğini fark ettim.
MRS günlüklerindeki zamansal dualizm “tasarım gereği”
Zaman damgalarının 12 saat formatında, AM/PM belirtilmeden, yani öğleden önce veya sonra yazıldığı ortaya çıktı. Hatta bu konuyla ilgili bir başvuru açıldı ve resmi bir yanıt alındı - amaçlanan buydu, MRS günlüğüne işaretler tam olarak bu formatta yazılıyor. Yani, bazen bir HATA'nın ortaya çıkma zamanıyla ilgili bazı entrikalar kalır...
En iyisi için çabalayın
Bugün Informatica oldukça istikrarlı, yöneticilere ve kullanıcılara uygun, mevcut yetenekleri ve potansiyeli açısından son derece güçlü bir araçtır. İşlevsel ihtiyaçlarımızı defalarca aşıyor ve artık projede pek tipik ve tipik olmayan bir şekilde fiilen kullanılıyor. Zorluklar kısmen mekanizmaların çalışma şekliyle ilgilidir - spesifik olan şey, kısa bir süre içinde parametreleri yoğun bir şekilde güncelleyen ve depo veritabanıyla çalışan çok sayıda iş parçacığının başlatılması ve sunucu donanım kaynaklarının neredeyse tamamen kullanılmasıdır. CPU tarafından.
Artık Informatica 10.2.1 veya 10.2.2'ye geçmeye çok yaklaştık; bu sürüm, şu anda sahip olduğumuz performans ve işlevsellik sorunlarından bazılarını ortadan kaldırmaya yönelik bazı dahili mekanizmaları ve destek vaatlerini yeniden işledi. Donanım açısından bakıldığında, depolamanın büyümesi ve gelişmesi nedeniyle yakın geleceğe yönelik rezervi de hesaba katarak bizim için en uygun konfigürasyona sahip sunucular bekliyoruz.
Elbette HA GRID kısmında testler, uyumluluk kontrolleri ve muhtemelen mimari değişiklikler olacak. Kısa vadede sistemin yerini alacak herhangi bir şey sağlayamayacağımız için Informatica'daki geliştirmeler devam edecek.
Ve gelecekte bu sistemden sorumlu olacaklar, onu kesinlikle müşterilerin ortaya koyduğu gerekli güvenilirlik ve performans göstergelerine getirebilecekler.
Makale Rostelecom veri yönetimi ekibi tarafından hazırlandı.
Güncel Informatica logosu
Kaynak: habr.com