Baze de date: ETL - Ciclu, provocări, performanțe

Ciclul ETL din viața reală

Ciclul tipic ETL din viața reală constă din următorii pași de execuție:

Inițierea ciclului
Construirea de date de referință
Extragerea (din surse)
Validarea
Transformarea (curățirea, aplicarea regulilor de afaceri, verificarea integrității datelor, crearea de agregate sau dezagregate)
Scena (încărcare în mesele de montaj, dacă este folosit)
Rapoarte de audit (de exemplu, privind respectarea regulilor de afaceri. De asemenea, în caz de defecțiune, ajută la diagnosticare/reparare)
Publicarea (la tabelele vizate)
Arhivarea

Provocări

Procesele ETL pot implica o complexitate considerabilă și pot apărea probleme operaționale semnificative cu sistemele ETL proiectate necorespunzător.

Gama de valori ale datelor sau calitatea datelor dintr-un sistem operațional poate depăși așteptările proiectanților la momentul în care sunt specificate regulile de validare și transformare. Profilarea datelor unei surse în timpul analizei datelor poate identifica condițiile de date care trebuie gestionate prin specificațiile regulilor de transformare, ducând la o modificare a regulilor de validare implementate în mod explicit și implicit în procesul ETL.

Depozitele de date sunt de obicei asamblate dintr-o varietate de surse de date cu diferite formate și scopuri. Ca atare, ETL este un proces cheie pentru a reuni toate datele într-un mediu standard, omogen.

Analiștii de proiectare ar trebui să stabilească scalabilitatea unui sistem ETL pe întreaga durată de viață a utilizării acestuia – inclusiv înțelegerea volumelor de date care trebuie procesate în cadrul acordurilor de nivel de serviciu. Timpul disponibil pentru extragerea din sistemele sursă se poate modifica, ceea ce poate însemna că aceeași cantitate de date poate fi procesată în mai puțin timp. Unele sisteme ETL trebuie să fie scalate pentru a procesa terabiți de date pentru a actualiza depozitele de date cu zeci de terabiți de date. Creșterea volumelor de date poate necesita proiecte care se pot scala de la un lot zilnic la un microlot de mai multe zile până la integrarea cu cozile de mesaje sau capturarea datelor de schimbare în timp real pentru transformare și actualizare continuă.

Performanţă

Furnizorii de ETL își analizează sistemele de înregistrare la mai mulți TB (teraocteți) pe oră (sau ~1 GB pe secundă) folosind servere puternice cu mai multe procesoare, mai multe hard disk-uri, mai multe conexiuni de rețea gigabit și multă memorie. Cel mai rapid record ETL este deținut în prezent de Syncsort, Vertica și HP la 5,4 TB în mai puțin de o oră, ceea ce este de peste două ori mai rapid decât recordul anterior deținut de Microsoft și Unisys.

În viața reală, cea mai lentă parte a unui proces ETL are loc de obicei în faza de încărcare a bazei de date. Bazele de date pot funcționa lent, deoarece trebuie să aibă grijă de concurență, întreținerea integrității și indici. Astfel, pentru o performanță mai bună, ar putea avea sens să folosiți:

Metoda de extragere directă a căii sau descărcare în bloc ori de câte ori este posibil (în loc de a interoga baza de date) pentru a reduce încărcarea sistemului sursă în timp ce obțineți extragerea de mare viteză
Majoritatea procesării transformării în afara bazei de date
Operațiuni de încărcare în vrac ori de câte ori este posibil

Totuși, chiar și folosind operațiuni în vrac, accesul la baza de date este de obicei blocajul în procesul ETL. Câteva metode comune folosite pentru a crește performanța sunt:

Tabele de partiții (și indici): încercați să păstrați partițiile similare ca dimensiune (atenție la valorile nule care pot denatura partiționarea)
Efectuați toată validarea în nivelul ETL înainte de încărcare: dezactivați verificarea integrității (dezactivare constrângere…) în tabelele bazei de date țintă în timpul încărcării
Dezactivați declanșatoarele (dezactivarea declanșatorului …) în tabelele bazei de date țintă în timpul încărcării: simulați efectul lor ca pas separat
Generați ID-uri în nivelul ETL (nu în baza de date)
Renunțați la indicii (pe un tabel sau partiție) înainte de încărcare – și recreați-i după încărcare (SQL: drop index …; create index …)
Folosiți încărcare în vrac paralelă atunci când este posibil – funcționează bine când tabelul este partiționat sau nu există indici (Notă: încercarea de a efectua încărcări paralele în aceeași tabelă (partiție) de obicei cauzează blocări – dacă nu pe rândurile de date, atunci pe indici)

Dacă există o cerință de a face inserări, actualizări sau ștergeri, aflați ce rânduri trebuie procesate în ce fel în nivelul ETL, apoi procesați aceste trei operațiuni în baza de date separat; de multe ori puteți face încărcare în vrac pentru inserări, dar actualizările și ștergerile trec de obicei printr-un API (folosind SQL)

O sursă comună de probleme în ETL este un număr mare de dependențe între joburile ETL. De exemplu, jobul „B” nu poate începe în timp ce jobul „A” nu este terminat. De obicei, se poate obține o performanță mai bună vizualizând toate procesele pe un grafic și încercând să se reducă graficul utilizând la maximum paralelismul și făcând „lanțuri” de procesare consecutivă cât mai scurte posibil. Din nou, partiționarea tabelelor mari și a indicilor acestora poate ajuta cu adevărat.

O altă problemă comună apare atunci când datele sunt răspândite între mai multe baze de date, iar procesarea se face în acele baze de date secvenţial. Uneori, replicarea bazei de date poate fi implicată ca metodă de copiere a datelor între baze de date – poate încetini semnificativ întregul proces. Soluția obișnuită este reducerea graficului de procesare la doar trei straturi:

Surse
Stratul ETL central
Ținte

Această abordare permite procesării să profite la maximum de paralelism. De exemplu, dacă trebuie să încărcați date în două baze de date, puteți rula încărcările în paralel (în loc să le încărcați în prima – și apoi să le replicați în a doua).

Uneori procesarea trebuie să aibă loc secvenţial. De exemplu, datele dimensionale (de referință) sunt necesare înainte de a putea obține și valida rândurile pentru tabelele principale de „fapte”.