Când cineva spune "modelare de date", se gândește automat la baze de date relaționale și la procesul de normalizare a datelor, a treia formă normală, etc. . Acest mod de gândire demonstrează o practică bună, înseamnând că semestrele de baze de date din facultate au avut efect asupra operațiilor de gândire și de lucru cu datele. Însă, din facultate și până acum, lucrurile s-au schimbat pentru că nu mai auzim la fel de mult despre baze de date relaționale, deși acestea sunt folosite în continuare cu preponderență în aplicații. Acum "big data" este la modă, dar este și o situație pe care tot mai multe aplicații trebuie să o abordeze: volumul, viteza, varietatea și complexitatea datelor (conform definiției Gartner pentru big data).
În acest articol vom aborda dualitatea conceptelor de normalizare și denormalizare în contextul big data, din prisma experienței mele cu MarkLogic (o platformă pentru aplicații big data).
Normalizarea datelor face parte din procesul de modelare a datelor pentru crearea unei aplicații. De cele mai multe ori, normalizarea este o practică bună din cel puțin două motive: evită problemele de integritate în situații de alterare a datelor (inserare, actualizare, ștergere) și evită înclinația față de orice model de interogare. În articolul "Denormalizare pentru viteză și profit", apare o comparație foarte interesantă între modelarea datelor și filozofie: principiul lui Descartes vast acceptat (inițial) de separare a minții de trup seamănă foarte bine cu procesul de normalizare - separarea datelor; eroarea lui Descartes a fost să despartă (filozofic) două părți care mereu au fost împreună. În același mod, după normalizare, datele trebuie aduse înapoi împreună de dragul aplicației; datele, care au fost inițial împreună, au fost fragmentate, iar acum trebuie recuplate - pare cel puțin redundant, dar este abordarea cea mai folosită din ultimele decenii, mai ales când se lucrează cu baze de date relaționale. Mai mult, chiar și lexicul și etimologia susțin această practică: datele fragmentate sunt considerate "normale".
Când vine vorba de modelare a datelor în contextul big data (în mod special MarkLogic), nu mai există o formă universal recunoscută în care trebuie încadrate datele, dimpotrivă, conceptul de schemă nu se mai aplică. Totuși, suportul oferit de platformele big data pentru date nestructurate nu este echivalent cu omisiunea pasului de modelare. Datele brute trebuie analizate dintr-un punct de vedere diferit în acest context, mai exact, din punctul de vedere al necesitaților aplicației, făcând astfel baza de date folosită orientată spre aplicație. Dacă ar fi să observăm operația cea mai frecventă - citire - s-ar putea spune că orice aplicație este o aplicație de căutare; din acest motiv, procesul de modelare a datelor trebuie să aibă în vedere entitățile pe care le manevrează în mod logic (după care caută), cum ar fi: articole, informații despre utilizator, specificații pentru mașini, etc. .
În timp ce normalizarea ,,sparge" datele brute pentru a respecta protocolul, fără a lua în considerare nevoile funcționale, denormalizarea se face doar pentru a servi aplicația - bineînțeles, cu grijă- pentru că denormalizarea excesivă poate cauza mai multe probleme decât soluții. Ordinea pașilor în care se dezvoltă o aplicație bazată pe date normalizată pare că respectă metodologia cascadă: odată ce modelul de date s-a stabilit, se începe lucrul la modelele de interogare și indiferent de performanța obținută, ajustările se fac asupra interogării, poate asupra indecșilor din baza de date, dar nu asupra modelului. Având o bază de date denormalizată, relația dintre modelul de date și modelele de interogare descriu mai bine metodologia agilă: dacă cerințele funcționale și atributele de calitate nu sunt îndeplinite atunci modificările se pot efectua și pe date pentru a îmbunătăți interogările până când se obține rezultatul dorit.
Toate argumentele care au făcut normalizarea atât de celebră rămân valide, însă platformele big data au dezvoltat instrumente pentru a păstra integritatea datelor și pentru a depăși alte probleme. Sistemele pentru big data sunt mult mai ușor scalabile pentru volume mari de date (atât pe orizontală cât și pe verticală), ceea ce face ca problema excesului de volum generat de denormalizare să fie ignorată; în plus, volumul extra ajută la îmbunătățirea performanței căutărilor. Rezolvarea pentru problemele de integritate depinde de arhitectura aleasă a aplicației, dar și de "proprietarul" datelor.
În momentul în care se alege denormalizarea datelor este clar că se merge pe centru de date orientat spre aplicație, însă aceasta reprezintă doar sursa de date cu care aplicația comunică direct, nu sursa originală a datelor sau "proprietarul" datelor. Pentru sistemele de big data, sunt două opțiuni: fie datele trăiesc doar în baza de date big data, fie au ca sursă inițială o bază de date relațională și cu ajutorul unui instrument de extragere-transformare-încărcare (ETL) datele ajung în "depozitul" big data. Având aceste două opțiuni, posibilele probleme de integritate se tratează altfel.
În cazul în care datele există doar în sistemul big data, este necesar un instrument de sincronizare și integrare a datelor care au suferit alterări. Instrumentele care implementează map-reduce sunt cel mai des folosite deoarece sunt eficiente și rulează pe hardware de bază. Astfel de procese de sincronizare pot fi declanșate fie imediat după ce modificarea originală a fost executată - când modificările nu sunt foarte dese și nu există posibilitatea de a genera o interblocare (dead-lock); când modificările sunt efectuate mai des, este recomandat un job ce rulează periodic, la intervale de timp prestabilite.
Când datele originale sunt într-o bază de date relaționale, efortul de menținere a integrității datelor este susținut de sistemul original de stocare - care trebuie sa fie normalizat. În această situație trebuie investit mult și în ETL pentru a reface structura logica a datelor. Chiar dacă libertatea pe care o oferă acest instrument este foarte mare, aplicațiile trebuie să respecte un anumit standard de performanță și încredere, deci noile modificări trebuie să fie aplicate pe sistemul de big data cât mai repede posibil; există, așadar, riscul de a denormaliza excesiv, reducând foarte mult din efortul de calcul din sistemul de big data.
După toată pledoaria de mai sus pentru denormalizare, pare lipsit de sens să mai atingem subiectul "join"; denormalizarea este o soluție pentru a evita un join de dimensiuni mari - suntem în context big data, până la urmă. Însă atributele calității, sursele multiple de date și respectarea protocoalelor externe pot reduce radical opțiunile de modelare/denormalizare. Să luam un exemplu concret, modelul de business pentru abonamentele periodice la articolele din anumite ziare cărora adăugăm și dimensiunea modelului de lucru: 45 de milioane de articole și 9 miliarde de relații articol-utilizator. Fiecare utilizator își poate face abonamente la anumite ziare pe perioade limitate de timp (doar câteva ediții); așadar condițiile de join sunt derivate din "potrivirea" între identificatorul ziarului și titularul abonamentului, precum și perioada abonamentului care să includă articolele publicate în acest interval. De ce este nepotrivită denormalizarea în acest scenariu? Modelul pentru articol ar trebui să conțină denormalizate informațiile despre toți utilizatorii care au acces la el - aceasta ar însemna o poluare a entității, dar și efortul de calcul suplimentar pe partea de ETL sau map-reduce, ceea ce ar putea degrada valoarea aplicației. Pe de altă parte, modificările efectuate pe perioada de subscriere pentru un anume utilizator poate crea alterarea a milioane de articole, și aceasta ar genera un proces de reconstruire a consistenței situației abonamentelor... în cele din urma.
În contextul big data, cea mai bună opțiune de modelare de date rămâne denormalizarea - aplicațiile moderne au nevoie de viteză mare de răspuns, nu merită să pierdem timp (de execuție) să punem la loc, împreună, datele normalizate pentru a oferi utilizatorului entitățile logice. Bineînțeles, denormalizarea completă nu este cea mai bună opțiune pentru a încapsula o relație mare de join many-to-many, după cum am arătat în paragraful precedent. Și pentru a termina într-o nota veselă, conform titlului articolului: "normalization is for sissies" (normalizarea este pentru naivi), iar denormalizarea e soluția.
de Larisa Goța
de Alpar Torok
