Məlumat anbarının ETL komponenti tez-tez anbarın özü tərəfindən kölgədə qalır və əsas verilənlər bazası və ya ön hissə komponenti, BI və hesabatdan daha az diqqət çəkir. Eyni zamanda, anbarın verilənlərlə doldurulması mexanikası nöqteyi-nəzərindən ETL əsas rol oynayır və idarəçilərdən digər komponentlərdən heç də az diqqət tələb etmir. Mənim adım Alexander, mən indi Rostelecom-da ETL-ni idarə edirəm və bu məqalədə Rostelecom-da böyük bir məlumat anbarında ən məşhur ETL sistemlərindən birinin administratorunun nə ilə məşğul olması barədə bir az paylaşmağa çalışacağam.
Əgər hörmətli oxucular bizim məlumat anbarı layihəmiz və Informatica PowerCenter məhsulu ilə artıq tanışdırsa, onda siz dərhal növbəti bölməyə keçə bilərsiniz.
Bir neçə il əvvəl vahid korporativ məlumat anbarı ideyası yetişdi və Rostelecom-da həyata keçirilməyə başladı. Artıq fərdi problemləri həll edən bir sıra depolar yaradılmışdı, lakin ssenarilərin sayı artdı, dəstək xərcləri də artdı və gələcəyin mərkəzləşmədə olduğu aydın oldu. Arxitektura baxımından bu, Hadoop və GreenPlum, köməkçi verilənlər bazaları, ETL mexanizmləri və BI-də həyata keçirilən bir neçə təbəqədən ibarət saxlama özüdür.
Eyni zamanda, çoxlu sayda coğrafi cəhətdən paylanmış, heterojen məlumat mənbələri sayəsində işinə Informatica tərəfindən nəzarət edilən xüsusi məlumat yükləmə mexanizmi yaradılmışdır. Nəticədə, məlumat paketləri Hadoop interfeys sahəsinə daxil olur, bundan sonra saxlama təbəqələri, Hadoop və GreenPlum vasitəsilə məlumatların yüklənməsi prosesləri başlayır və onlar Informatica-da həyata keçirilən ETL adlanan idarəetmə mexanizmi ilə idarə olunur. Beləliklə, Informatica sistemi anbarın fəaliyyətini təmin edən əsas elementlərdən biridir.
Yaddaşımız aşağıdakı yazılardan birində daha ətraflı təsvir olunacaq.
Informatica PowerCenter/Big Data Management hazırda verilənlərin inteqrasiyası alətləri sahəsində aparıcı proqram təminatı hesab olunur. Bu, ETL (Extract Transform Load), məlumatların keyfiyyətinin idarə edilməsi, MDM (Master Data Management), ILM (Information Lifecycle Management) və digər sahələrdə ən güclü oyunçulardan biri olan Amerikanın Informatica şirkətinin məhsuludur.
İstifadə etdiyimiz PowerCenter inteqrasiya olunmuş Tomcat proqram serveridir, burada Informatica proqramları öz xidmətlərini həyata keçirir:
Domain, əslində, bu, hər şey üçün əsasdır; xidmətlər, istifadəçilər və GRID komponentləri domen daxilində fəaliyyət göstərir.
Administrator Konsolu, məhsulla qarşılıqlı əlaqə üçün əsas vasitə olan Informatica Developer müştərisinə əlavə olaraq veb əsaslı idarəetmə və monitorinq aləti
MRS, Model Repository Service, metadata repozitoriyası, metadataların fiziki olaraq saxlandığı verilənlər bazası ilə inkişafın baş verdiyi Informatica Developer müştərisi arasındakı təbəqədir. Repozitoriyalar məlumatların təsvirlərini və digər məlumatları, o cümlədən bir sıra digər Infromatica xidmətləri üçün, məsələn, yerinə yetirilən tapşırıqlar üçün cədvəllər (Cədvəllər) və ya monitorinq məlumatlarını, həmçinin tətbiq parametrlərini, xüsusən də eyni proqramla işləmək üçün istifadə etməyə imkan verir. müxtəlif məlumat mənbələri və qəbulediciləri.
DIS, Məlumat İnteqrasiya Xidməti, bu, əsas funksional proseslərin baş verdiyi, tətbiqlərin orada işlədiyi və İş Akışlarının (xəritələmə ardıcıllığının və onların qarşılıqlı əlaqəsinin təsviri) və Xəritəçəkmələrin (çevirmələr, transformasiyaların özünün baş verdiyi bloklar, məlumatların işlənməsi) faktiki işə salındığı bir xidmətdir. ) baş verir.
GRID konfiqurasiyası – mahiyyətcə, DIS tərəfindən işə salınan yük qovşaqlar (yəni domenin bir hissəsi olan serverlər) arasında paylandıqda bir neçə serverdən istifadə edərək kompleks qurmaq üçün bir seçimdir. Bu seçim vəziyyətində, DIS-də yükü bir neçə qovşağı birləşdirən əlavə GRID abstraksiya təbəqəsi vasitəsilə paylamaqdan əlavə, DIS-in konkret bir node üzərində işləmək əvəzinə işlədiyi əlavə ehtiyat MRS nümunələri də yaradıla bilər. Siz hətta yüksək əlçatanlığı həyata keçirə bilərsiniz, burada əsas zəng uğursuz olarsa, ehtiyat qovşaqlar vasitəsilə xarici zənglər edilə bilər. Biz hələlik bu tikinti variantından imtina etmişik.
Informatica PowerCenter, sxematik
Məlumat təchizatı zəncirinin bir hissəsi kimi işin ilk mərhələlərində problemlər müntəzəm olaraq yaranırdı, bəziləri o dövrdə Informatica-nın qeyri-sabit işləməsi ilə əlaqədardır. Mən bu dastanın yaddaqalan məqamlarından bəzilərini - Informatica 10-u mənimsəməyi bölüşəcəyəm.
Keçmiş Informatica loqosu
Bizim məsuliyyət sahəmizə digər Informatica mühitləri də daxildir, onların fərqli yükə görə öz xüsusiyyətləri var, lakin indiyə qədər Informatica-nın məlumat anbarının özünün ETL komponenti kimi necə inkişaf etdiyini dəqiq xatırlayacağam.
Bu necə oldu
2016-cı ildə, Informatica-nın işinə cavabdeh olduğumuz zaman, o, artıq 10.0 versiyasına çatmışdı və ciddi bir həlldə kiçik versiya .0 olan bir məhsuldan istifadə etməyə qərar verən optimist həmkarlar üçün hər şey aydın görünürdü - istifadə etməliyik. yeni versiya! Aparat resursları baxımından o vaxt hər şey qaydasında idi.
2016-cı ilin yazından etibarən bir podratçı Informatica-nın işinə cavabdehdir və sistemin bir neçə istifadəçisinə görə, "həftədə bir neçə dəfə işləyirdi." Burada, anbarın PoC mərhələsində de-fakto olduğunu, komandada heç bir idarəçi olmadığını və sistem müxtəlif səbəblərdən daim qəzaya uğradığını, bundan sonra podratçının mühəndisi onu yenidən götürdüyünü aydınlaşdırmaq lazımdır.
Payızda məsuliyyət sahələrini öz aralarında bölüşdürərək komandaya üç administrator qoşuldu və layihədəki sistemlərin, o cümlədən Informatica-nın işini təşkil etmək üçün normal iş başladı. Ayrı-ayrılıqda, bu məhsulun geniş yayılmadığını və hər hansı bir suala cavab tapa biləcəyiniz və hər hansı bir problemi həll edə biləcəyiniz böyük bir cəmiyyətə sahib olduğunu söyləmək lazımdır. Buna görə də, rus tərəfdaşı Informatica-dan tam texniki dəstək çox vacib idi, onun köməyi ilə o vaxtkı gənc Informatica 10-un bütün səhvləri və səhvləri düzəldildi.
Komandamızın tərtibatçıları və podratçı üçün etməli olduğumuz ilk şey Informatica-nın özünün işini sabitləşdirmək, veb idarəetmə konsolunun (Informatica Administrator) funksionallığını təmin etmək idi.
Informatica tərtibatçıları ilə tez-tez belə görüşürük
Səbəblərin müəyyən edilməsi prosesini bir kənara qoysaq, qəzaların əsas səbəbi şəbəkə mənzərəsi nöqteyi-nəzərindən “Informatica” proqram təminatının nisbətən uzaq serverdə yerləşən repozitor bazası ilə qarşılıqlı əlaqə sxemi olub. Bu, gecikmələrə səbəb oldu və Informatica domeninin vəziyyətinə nəzarət edən mexanizmləri pozdu. Verilənlər bazasının bir qədər sazlanmasından, onu verilənlər bazası gecikmələrinə daha dözümlü edən Informatica-nın parametrlərinin dəyişdirilməsindən və sonda Informatica versiyasının 10.1-ə yenilənməsindən və verilənlər bazası əvvəlki serverdən Informatica-ya yaxın olan serverə köçürüldükdən sonra problem öz yerini itirdi. aktualdır və o vaxtdan bəri biz müşahidə etmədiyimiz bu cür qəzalar olub.
Informatica Monitoru işə salmaq cəhdlərindən biri
İdarəetmə konsolu ilə bağlı vəziyyət də kritik idi. Nisbətən məhsuldar mühitdə fəal inkişaf birbaşa aparıldığı üçün həmkarlar daim xəritələrin işini və “yolda” iş axını təhlil etməli idilər. Yeni Informatica-da Məlumatların İnteqrasiya Xidmətinin bu cür monitorinq üçün ayrıca aləti yoxdur, lakin idarəetmə veb konsolunda (Informatica Administrator Monitor) monitorinq bölməsi peyda olub, burada tətbiqlərin, iş axınının və xəritələrin işinə nəzarət edə bilərsiniz. işə salır, qeyd edir. Periyodik olaraq, konsol tamamilə əlçatmaz oldu və ya DIS-də cari proseslər haqqında məlumat yenilənməyi dayandırdı və ya səhifələri yükləyərkən xətalar baş verdi.
Performansı sabitləşdirmək üçün java parametrlərinin seçilməsi
Problem bir çox cəhətdən düzəldildi, parametrləri dəyişdirmək üçün eksperimentlər aparıldı, loglar və jstack toplandı, dəstəyə göndərildi, eyni zamanda aktiv googling və sadəcə müşahidə edildi.
Əvvəla, monitorinq üçün ayrıca MRS yaradıldı, sonradan məlum oldu ki, bu, bizim mühitlərdə resursların əsas istehlakçılarından biridir, çünki xəritələr çox intensiv şəkildə işə salınır. Java yığını və bir sıra digərləri ilə bağlı parametrlər dəyişdirildi.
Nəticədə, Informatica 10.1.1-in növbəti yeniləməsi ilə konsolun və monitorun işi sabitləşdi, tərtibatçılar daha səmərəli işləməyə başladılar və müntəzəm proseslər getdikcə daha müntəzəm oldu.
İnkişaf və idarəetmə arasında qarşılıqlı əlaqə təcrübəsi maraqlı ola bilər. Mürəkkəb sistemlərdən istifadə zamanı işlərin necə işlədiyi, nəyin edilə və nəyin edilə bilməyəcəyi haqqında ümumi anlayış məsələsi həmişə vacibdir. Buna görə də, təhlükəsiz olaraq tövsiyə edə bilərik ki, əvvəlcə inzibati komandaya proqram təminatının necə idarə olunacağı, inkişaf komandasına isə kod yazılması və sistemdə proseslərin necə çəkiləcəyi ilə bağlı təlim keçin və yalnız bundan sonra nəticə üzərində işləmək üçün birinci və ikincini göndərin. Zaman sonsuz resurs olmadığı zaman bu, həqiqətən vacibdir. Bir çox problem hətta seçimlərin təsadüfi axtarışı ilə həll edilə bilər, lakin bəzən bəziləri aprior bilik tələb edir - bizim işimiz bu aksiomanı başa düşməyin vacibliyini təsdiqləyir.
Məsələn, MRS-də versiyanı aktivləşdirməyə çalışdığımız zaman (sonda məlum oldu ki, SVN-nin fərqli versiyası lazım idi), bir müddət sonra sistemin yenidən başlama vaxtının bir neçə on dəqiqəyə qədər artdığını aşkar etdikdən sonra həyəcanlandıq. Başlanğıcda gecikmənin səbəbini tapdıqdan və versiyanı söndürdükdən sonra yenidən yaxşı iş gördük.
Informatica ilə əlaqəli diqqətəlayiq maneələrə artan java mövzuları ilə epik döyüş daxildir. Müəyyən bir nöqtədə replikasiyanın, yəni qurulmuş proseslərin çoxlu sayda mənbə sistemlərinə yayılmasının vaxtı gəldi. Məlum oldu ki, 10.1.1-dəki proseslərin heç də hamısı yaxşı işləməyib və bir müddət sonra DIS işləmir. Tətbiqin yerləşdirilməsi proseduru zamanı onların sayı xüsusilə nəzərəçarpacaq dərəcədə artan on minlərlə mövzu aşkar edildi. Bəzən funksionallığı bərpa etmək üçün gündə bir neçə dəfə yenidən başlamalı olurdum.
Burada dəstəyə təşəkkür etmək lazımdır; problemlər EBF (Emergency Bug Fix) istifadə edərək nisbətən tez lokallaşdırıldı və həll edildi - bundan sonra hər kəs alətin həqiqətən işlədiyini hiss etdi.
Hələ də işləyir!
Hədəf rejimində işə başlayanda Informatica belə görünürdü. Informatica 10.1.1HF1 versiyası (HF1 HotFix1-dir, EBF kompleksindən olan təchizatçı yığımıdır) GRID-in bir hissəsi olan üç serverdən birində 20 x86_64 nüvəsi olan miqyaslaşdırma və bəzi digər problemlərimizi düzəldən əlavə quraşdırılmış EBF ilə və saxlama, çox yavaş yerli disklər massivində - bu, Hadoop klasteri üçün server konfiqurasiyasıdır. Başqa bir oxşar serverdə - həm Informatica domeni, həm də ETL idarəetmə mexanizmi işlədiyi Oracle DBMS. Bütün bunlar komandada istifadə olunan standart monitorinq alətləri (Zabbix + Grafana) tərəfindən hər iki tərəfdən - Informatica-nın özü xidmətləri ilə və ona daxil olan yükləmə prosesləri ilə izlənilir. İndi həm performans, həm də sabitlik, xarici amilləri nəzərə almadan, indi yükü məhdudlaşdıran parametrlərdən asılıdır.
GRID haqqında ayrıca deyə bilərik. Ətraf yük balansı imkanı ilə üç qovşaq üzərində qurulmuşdur. Bununla belə, sınaq zamanı məlum oldu ki, tətbiqlərimizin işləyən instansiyaları arasında qarşılıqlı əlaqə problemlərinə görə bu konfiqurasiya gözlənildiyi kimi işləmədi və onlar üç qovşaqdan ikisini domendən çıxararaq müvəqqəti olaraq bu tikinti sxemindən imtina etməyə qərar verdilər. Eyni zamanda, sxemin özü eyni qaldı və indi bu, dəqiq bir GRID xidmətidir, lakin bir node üçün degenerasiya olunur.
Hal-hazırda çətinlik monitor dövrəsini mütəmadi olaraq təmizləyərkən performansın azalması ilə bağlı olaraq qalır - CNN-də eyni vaxtda proseslər və işləyən təmizləmə ilə, ETL idarəetmə mexanizminin işində nasazlıqlar baş verə bilər. Hal-hazırda bu, bütün əvvəlki məlumatların itirilməsi ilə monitor dövrəsini əl ilə təmizləmək yolu ilə "köpək kimi" həll olunur. Bu, adi rutin əməliyyat zamanı məhsuldarlıq üçün çox da kritik deyil, lakin hazırda normal həll yolunun axtarışı davam edir.
Eyni vəziyyətdən başqa bir problem yaranır - bəzən bizim idarəetmə mexanizmimizin bir neçə dəfə işə salınması baş verir.
Mexanizmin uğursuzluğuna səbəb olan çoxsaylı proqram işə salınır
Cədvəllə işləyərkən, sistemə ağır yük düşdüyü vaxtlarda bəzən mexanizmin xarab olmasına səbəb olan hallar baş verir. Problem hələ də əl ilə həll edilir və daimi həll yolu axtarılır.
Ümumiyyətlə, ümumiləşdirə bilərik ki, ağır yük olduqda, ona adekvat resursları təmin etmək çox vacibdir, bu, Informatica-nın özü üçün də aparat resurslarına aiddir, eyni zamanda verilənlər bazası repozitoriyası üçün də, həmçinin optimal parametrləri təmin etmək üçün. onlar üçün. Bundan əlavə, hansı verilənlər bazası yerləşdirmə sxeminin daha yaxşı olması sualı açıq qalır - ayrı bir hostda və ya Informatica proqramının işlədiyi eyni. Bir tərəfdən, bir serverdə daha ucuz olacaq və birləşdirildikdə, şəbəkə qarşılıqlı əlaqəsi ilə bağlı mümkün problem praktiki olaraq aradan qaldırılır; digər tərəfdən, verilənlər bazasından hosta yük Informatica-dan yüklə tamamlanır.
İstənilən ciddi məhsulda olduğu kimi, Informatica-da da gülməli məqamlar var.
Bir dəfə, bir növ qəzanı sıralayarkən, MRS jurnallarının hadisələrin vaxtını qəribə şəkildə göstərdiyini gördüm.
MRS-də müvəqqəti dualizm "dizayn üzrə"
Məlum olub ki, vaxt ştampları AM/PM göstərilmədən, yəni günortadan əvvəl və ya sonra 12 saatlıq formatda yazılır. Hətta bu məsələ ilə bağlı ərizə də açılıb və rəsmi cavab da alınıb - belə nəzərdə tutulub, MRS jurnalında məhz bu formatda işarələr yazılıb. Yəni bəzən hansısa XƏTNİN baş vermə vaxtı ilə bağlı bəzi intriqalar qalır...
Ən yaxşısı üçün səy göstərin
Bu gün Informatica kifayət qədər sabit bir vasitədir, idarəçilər və istifadəçilər üçün əlverişlidir, mövcud imkanları və potensialı baxımından son dərəcə güclüdür. O, funksional ehtiyaclarımızı dəfələrlə üstələyir və indi layihədə ən tipik və tipik olmayan şəkildə de-fakto istifadə olunur. Çətinliklər qismən mexanizmlərin işləməsi ilə bağlıdır - spesifik məsələ odur ki, qısa müddət ərzində parametrləri intensiv şəkildə yeniləyən və repozitor bazası ilə işləyən çoxlu sayda iplər işə salınır, eyni zamanda server aparat resursları demək olar ki, tamamilə istifadə olunur. CPU tərəfindən.
İndi biz Informatica 10.2.1 və ya 10.2.2-yə keçməyə yaxınıq, hansı ki, bəzi daxili mexanizmləri yenidən işləyib və hazırda malik olduğumuz bəzi performans və funksionallıq problemlərini aradan qaldırmaq üçün dəstək vəd edir. Və hardware baxımından, yaddaşın böyüməsi və inkişafı ilə əlaqədar yaxın gələcək üçün ehtiyatı nəzərə alaraq, bizim üçün optimal konfiqurasiyaya malik serverləri gözləyirik.
Əlbəttə ki, HA GRID hissəsində sınaq, uyğunluq yoxlanışı və bəlkə də memarlıq dəyişiklikləri olacaq. Informatica daxilində inkişaf davam edəcək, çünki qısa müddətdə sistemi əvəz edəcək heç bir şey təmin edə bilmərik.
Gələcəkdə bu sistemə cavabdeh olacaq şəxslər isə onu müştərilər tərəfindən irəli sürülən tələb olunan etibarlılıq və performans göstəricilərinə mütləq çatdıra biləcəklər.
Məqalə Rostelecom-un məlumatların idarə edilməsi qrupu tərəfindən hazırlanmışdır
Cari Informatica loqosu
Mənbə: www.habr.com