Arhitectură de date pentru companii

Un subiect important privind software-ul enterprise, arhitecturile de date reprezintă o nouă abordare a datelor, pe baza unei arhitecturi distribuite pentru managementul acestora. Ideea este de a oferi o accesibilitate și o disponibilitate mai mare datelor pentru utilizatorii business, prin conectarea directă a deținătorilor, producătorilor și consumatorilor de date. Arhitecturile de date au drept scop îmbunătățirea rezultatelor de afaceri, ale soluțiilor axate pe date și stimularea adoptării arhitecturilor de date moderne.

Din perspectiva companiilor, arhitectura de date introduce idei noi referitoare la „elaborarea produselor pentru date”. Cu alte cuvinte, gândiți-vă la date ca la un produs care „trebuie să efectueze o activitate”, de exemplu să îmbunătățească procesul de luare a deciziilor, să detecteze fraudele sau să avertizeze compania privind schimbările survenite în lanțul de aprovizionare. Pentru a crea produse de mare valoare pentru date, companiile trebuie să implementeze schimbări în cultură și mentalitate și să aibă o abordare interfuncțională a modelării domeniului de afaceri.

Din punct de vedere tehnologic, perspectiva Oracle asupra arhitecturilor de date implică trei noi domenii importante pentru acestea:

1. Instrumente care să ofere produse pentru date sub forma unor colecții, evenimente și analize de date
2. Arhitecturi de date distribuite, descentralizate, pentru a ajuta organizațiile care renunță la arhitecturile monolitice pentru a trece la calculul multicloud și hibrid, ori care trebuie să funcționeze în mod descentralizat, la nivel global
3. Date în mișcare pentru companiile care nu pot depinde doar de datele centralizate, statice, orientate pe loturi și care se orientează către registre de date bazate pe evenimente și procese axate pe streaming, pentru evenimente de date în timp real, care oferă analize mai precise

Alte aspecte importante, cum ar fi instrumentele cu autoservire pentru utilizatorii non-tehnici și modelele puternice de guvernanță distribuită a datelor, sunt la fel de importante pentru arhitectura rețelelor de date, precum și pentru metodologiile de management al datelor, mai centralizate și clasice.

O abordare a arhitecturilor de date este o schimbare de paradigmă în abordarea datelor ca produs. Arhitectura de date introduce schimbările organizaționale și operaționale pe care companiile vor trebui să le gestioneze ca pe un activ real al capitalului de afaceri. Perspectiva Oracle asupra arhitecturii de date necesită alinierea între domeniile datelor organizaționale și analitice.

O arhitectură de date trebuie să conecteze producătorii de date direct cu utilizatorii de afaceri și, pe cât posibil, să elimine intermediarul IT din proiectele și procesele care colectează, pregătesc și transformă resursele de date.

Oracle s-a axat pe arhitectura de date pentru a le oferi clienților o platformă care poate răspunde acestor cerințe tehnologice emergente. Aceasta include instrumente pentru produse de date; arhitecturi descentralizate, bazate pe evenimente și modele de streaming pentru date în mișcare. Pentru modelarea domeniului produselor de date și alte probleme sociotehnice, Oracle se aliniază cu activitatea liderului de opinie în domeniul arhitecturilor de date – Zhamak Dehghani.

Adevărul trist este că arhitecturile de date monolitice din trecut sunt greoaie, costisitoare și inflexibile. De-a lungul anilor, a devenit clar că cea mai mare parte a timpului și costurilor pentru platforma de business digitală, de la aplicații la analize, este sufocată de eforturile de integrare. Prin urmare, majoritatea inițiativelor privind platformele sunt destinate eșecurilor.

Deși arhitectura de date nu reprezintă soluția pentru cele centralizate și monolitice, principiile, practicile și tehnologiile strategiei privind arhitecturile de date sunt concepute pentru a rezolva unele dintre cele mai presante și evitate obiective de modernizare pentru inițiativele de afaceri bazate pe date.

Unele dintre tendințele tehnologice care au dus la apariția arhitecturii de date ca soluție includ:

Schimbarea mentalității este cel mai important prim pas către o arhitectură de date. Dorința de adoptare a practicilor învățate privind inovația este rampa de lansare către modernizarea cu succes a arhitecturii de date.

Aceste domenii învățate ale practicii includ:

• Strategia designului - o metodologie dovedită pentru rezolvarea „problemelor dificile”, aplicată domeniilor de date enterprise pentru crearea unor produse de date excelente
• Teoria activităților care trebuie efectuate – aplicarea unui proces inovator axat pe client și a unui proces revoluționar bazat pe rezultate care să ne asigure că produsele de date enterprise rezolvă probleme reale de afaceri

Metodologiile de elaborare a strategiei oferă tehnici dovedite pentru eliminarea silozurilor organizaționale care blochează frecvent inovația interfuncțională. Teoria activităților care trebuie efectuate reprezintă baza proiectării produselor de date care îndeplinesc anumite obiective ale consumatorului final – sau activități care trebuie efectuate – și definește scopul produsului.

Deși abordarea privind produsele de date a apărut inițial în cadrul comunității de știință a datelor, aceasta este acum aplicată în toate aspectele managementului de date. În loc să creeze arhitecturi tehnologice monolitice, arhitectura de date se axează pe consumatorii de date și pe rezultatele de afaceri.

Deși concepția privind produsele de date poate fi aplicată altor arhitecturi de date, aceasta este o parte esențială a unei arhitecturi de date. Pentru exemple practice de aplicare a strategiei pentru produsele de date, echipa Intuit a efectuat o analiză detaliată a experienței lor.

Produsele de orice fel – de la produsele brute la articolele din magazinul local – sunt produse ca active de valoare, destinate consumului și au un anumit rol de îndeplinit. Produsele pentru date pot lua diverse forme, în funcție de domeniul de activitate sau de problema care trebuie rezolvată și pot include:

• Analize – tablouri de bord și istorice/rapoarte în timp real
• Seturi de date – colecții de date în diferite configurații/formate
• Modele – obiecte din domeniu, modele de date, caracteristici de machine learning (ML)
• Algoritmi – modele ML, evaluare, reguli de business
• Servicii de date și interfețe API – documente, sarcini utile, subiecte, interfețe API REST și multe altele.

Un produs de date este creat pentru consum, fiind deținut, de regulă, în afara domeniului IT și necesită urmărirea unor atribute suplimentare, cum ar fi:

• Harta acționarilor – cine deține, creează și consumă acest produs?
• Ambalarea și documentația – cum se consumă? Cum este etichetat?
• Scopul și valoarea – care este valoarea implicită/explicită a produsului? Există depreciere în timp?
• Calitatea și consecvența – care sunt indicatorii KPI și acordurile SLA de utilizare? Este verificabil?
• Proveniența, ciclul de viață și guvernanța – datele sunt de încredere și fezabile?

Sistemele IT descentralizate sunt o realitate modernă, iar odată cu apariția aplicațiilor SaaS și a infrastructurii cloud publice (IaaS), descentralizarea aplicațiilor și a datelor este deja o certitudine. Arhitecturile software pentru aplicații trec de la monoliții centralizați din trecut la microservicii distribuite (o arhitectură de servicii). Arhitectura de date va urma aceeași tendință de descentralizare, datele devenind mai distribuite într-o varietate mai largă de locații fizice și în mai multe rețele. Aceasta este o arhitectură de date.

O arhitectură este o topologie de rețea care permite unui grup mare de noduri non-ierarhice să colaboreze împreună.

Unele exemple tehnologie includ:

• WiFiMesh – multe noduri care colaborează pentru o acoperire mai bună
• ZWave/Zigbee – rețele de dispozitive inteligente, cu consum redus de energie
• 5G Mesh – conexiuni celulare mai fiabile și mai rezistente
• Starlink – rețea în bandă largă prin satelit, la scară globală
• Arhitectura serviciilor – o modalitate de a oferi controale unificate asupra microserviciilor descentralizate (software de aplicații)

Arhitecturile de date respectă aceste concepte și oferă o modalitate descentralizată de distribuire a datelor în rețele virtuale/fizice și pe distanțe mari. Arhitecturile monolitice de integrare a datelor moștenite, precum instrumentele ETL și pentru federațiile de date – și chiar serviciile mai recente, în cloudurile publice, cum ar fi AWS Glue – necesită o infrastructură extrem de centralizată.

O soluție completă pentru arhitecturile de date ar trebui să poată funcționa într-o infrastructură multicloud, putând să se extindă de la sistemele locale, la mai multe medii cloud publice și chiar la rețelele periferice.

Într-o lume în care datele sunt distribuite și descentralizate, rolul securității informațiilor este esențial. Spre deosebire de monoliții extrem de centralizați, sistemele distribuite trebuie să delege activitățile necesare pentru autentificarea și autorizarea diferiților utilizatori cu diferite niveluri de acces. Delegarea sigură a încrederii între rețele este dificil de realizat în mod optim.

Unele considerente includ:

• Criptarea în repaus – sub formă de date/evenimente scrise în spațiul de stocare
• Autentificarea distribuită – pentru servicii și baze de date, cum ar fi mTLS, certificate, SSO, baze de date secrete și seifuri de date
• Criptare în mișcare – sub formă de date/evenimente care circulă în memorie
• Managementul identității – servicii de tip LDAP/IAM, între platforme
• Autorizări distribuite – pentru punctele finale ale serviciului de redactare a datelor.
  De exemplu: Open Policy Agent (OPA) pentru plasarea punctului de decizie al politicii (PDP) în containerul/clusterul K8S, unde se procesează punctul final pentru microserviciu. LDAP/IAM poate fi orice serviciu compatibil JWT.
• Mascare deterministă – pentru a analiza în mod fiabil și consecvent datele PII

Securitatea în cadrul oricărui sistem IT poate fi dificilă și este și mai dificil să se asigure o securitate sporită în cadrul sistemelor distribuite. Totuși, aceste probleme pot fi rezolvate.

Un principiu de bază al arhitecturilor de date este ideea de distribuție a proprietății și a responsabilității. Cea mai bună practică este de a transfera proprietatea produselor și domeniilor de date către persoanele din organizație care sunt cel mai aproape de date. În practică, astfel se poate efectua alinierea la datele sursă (de exemplu, la sursele de date brute, cum ar fi sistemele operaționale de înregistrare/ale aplicațiilor) sau la datele analitice (de exemplu, datele compozite sau centralizate formatate pentru a fi ușor de absorbit de către consumatorii de date). În ambele cazuri, producătorii și consumatorii de date sunt adesea aliniați mai degrabă unităților de afaceri decât organizațiilor IT.

Metodele vechi de organizare a domeniilor de date cad adesea în capcana alinierii cu soluțiile tehnologice, cum ar fi instrumentele ETL, depozitele de date, lacurile de date sau organizarea structurală a unei companii (resurse umane, marketing și alte domenii de afaceri). Cu toate acestea, pentru o anumită problemă de afaceri, domeniile de date sunt adesea cel mai bine aliniate la domeniul de aplicare al problemei care se rezolvă, la contextul unui anumit proces de afaceri sau la familia de aplicații dintr-un anumit domeniu de probleme. În cazul organizațiilor mari, aceste domenii de date se extind, de obicei, la nivelul organizațiilor interne și al amprentei tehnologice.

Defalcarea funcțională a domeniilor de date, în cadrul arhitecturii de date, devine din ce în ce mai importantă. Diversele metodologii de defalcare a datelor pentru modelarea domeniului pot fi adaptate la arhitectura rețelei de date, inclusiv pentru modelarea clasică a depozitului de date (cum ar fi Kimball și Inmon) sau la modelarea seifului de date, dar cea mai des întâlnită metodologie încercată în prezent în arhitectura de rețea de date este proiectarea bazată pe domeniu (DDD). Abordarea DDD a apărut din defalcarea funcțională a microserviciilor și este aplicată acum în contextul unei arhitecturi de date.

Un domeniu important în care Oracle a contribuit la dezbaterile privind arhitectura de date este acela de a mări importanța datelor în mișcare ca element cheie al unei rețele de date moderne. Datele în mișcare sunt esențiale pentru a scoate arhitectura de date din lumea tradițională a procesării monolitice, centralizate și pe loturi. Funcționalitățile pentru datele în mișcare răspund la mai multe întrebări importante privind arhitectura de date, cum ar fi:

• Cum putem accesa produsele pentru date aliniate la sursă în timp real?
• Ce instrumente pot oferi mijloacele de distribuire a tranzacțiilor de date de încredere, în cadrul unei arhitecturi de date descentralizată fizic?
• Ce instrumente pot folosi atunci când este necesar ca evenimentele de date să fie disponibile ca interfețe API pentru produsele de date?
• Pentru produsele de date analitice care trebuie să fie actualizate în permanență, cum aș putea să mă sincronizez cu domeniile de date și să asigur încrederea și validitatea?

Aceste întrebări nu sunt doar probleme privind „detaliile de implementare”, ci au o importanță majoră pentru arhitectura de date în sine. O proiectare axată pe domeniu pentru date statice va utiliza tehnici și instrumente diferite față de un proces dinamic, cu date în mișcare, al aceleiași proiectări. De exemplu, în arhitecturile de date dinamice, registrul de date este sursa centrală de informații reale pentru evenimentele de date.

Registrele sunt o componentă fundamentală pentru funcționarea unei arhitecturi distribuite de date. La fel ca în cazul unui registru contabil, un registru de date înregistrează tranzacțiile așa cum se desfășoară.

La distribuirea registrului, evenimentele de date devin „reproductibile” în orice loc. Unele registre sunt asemenea unei cutii negre ale unei aeronave, care este utilizată pentru disponibilitate ridicată și recuperare în caz de dezastru.

Spre deosebire de depozitele de date centralizate și monolitice, registrele distribuite sunt create special pentru a ține evidența evenimentelor atomice și/sau a tranzacțiilor care au loc în alte sisteme (externe).

O arhitectură de date nu este un singur tip de registru. În funcție de cazurile de utilizare și de cerințe, o arhitectură de date poate utiliza diferite tipuri de registre de date bazate pe evenimente, inclusiv următoarele:

• Registru de evenimente de uz general – cum ar fi Kafka sau Pulsar
• Registrul de evenimente de date - instrumente distribuite CDC/replicare
• Middleware pentru mesagerie – inclusiv ESB, MQ, JMS și AQ
• Registrul blockchain – pentru tranzacții securizate, imuabile, între mai multe părți

Împreună, aceste registre pot funcționa ca un jurnal de evenimente durabil pentru întreaga companie, furnizând o listă curentă a evenimentelor de date care au loc în sistemele de înregistrare și în sistemele de analiză.

Fluxurile de date Polyglot sunt mai răspândite ca niciodată. Acestea variază în funcție de tipurile de evenimente, de sarcinile utile și de diferitele semantici ale tranzacțiilor. O arhitectură de date trebuie să susțină tipurile de fluxuri necesare pentru o varietate de acțiuni cu datele companiei.

Desigur, există mai mult de trei atribute ale unei arhitecturi de date. Ne-am axat pe cele trei elemente de mai sus pentru a atrage atenția asupra atributelor pe care Oracle le consideră a fi unele dintre aspectele noi și unice ale abordării moderne emergente a unei arhitecturi de date.

Alte atribute importante ale unei arhitecturi de date includ:

• Instrumente cu autoservire – rețeaua de date adoptă tendința generală de administrare a datelor cu autoservire, dezvoltatorii vor trebui să provină din ce în ce mai mult din rândurile deținătorilor de date
• Guvernanța datelor – arhitectura de date a avut, de asemenea, tendința de lungă durată de a trece la un model de guvernanță federalizat mai oficial, așa cum este susținut de responsabilii, administratorii de date și furnizorii de cataloage de date, de mai mulți ani.
• Posibilitatea de utilizare a datelor – respectarea principiilor privind arhitecturilor de date. În plus, există destul de multe avantaje legate de utilizarea produselor de date. Principiile privind produsele de date se vor referi la date care sunt valoroase, utilizate și fezabile pentru partajare.

Privind dincolo de migrările de tip „lift and shift” a arhitecturilor de date monolitice în cloud, multe companii caută, de asemenea, să renunțe la aplicațiile centralizate din trecut și să se orienteze către o arhitectură de aplicații mai modernă, de tip microservicii.

Dar aplicațiile vechi, monolitice depind de obicei de baze de date mari, fapt care pune problema modului în care se poate etapiza planul de migrare, pentru a se reduce perturbările, riscurile și costurile. O arhitectură de date poate oferi o importantă funcționalitate operațională IT pentru clienții care trec treptat de la arhitectura monolitică la cea de rețea. De exemplu:

• Descărcarea subdomeniului pentru operațiunile din baza de date, cum ar fi filtrarea datelor în funcție de „contextul limitat”.
• Replicare bidirecțională a tranzacțiilor pentru migrări etapizate
• Sincronizare între platforme, cum ar fi cea dintre mainframe și DBaaS

În argoul arhitecților de microservicii, această abordare utilizează un outbox bidirecțional pentru tranzacții care activează schema de migrare a „smochinului parazit”, un context limitat la un moment dat.

Aplicațiile esențiale pentru companie necesită indicatori KPI și acorduri SLA cu reziliență și continuitate foarte ridicate. Indiferent dacă aceste aplicații sunt monolitice, de tip microservicii sau intermediare, acestea nu pot da eroare!

Pentru sistemele esențiale, de regulă, nu poate fi acceptat un model de date distribuit, cu o consecvență relativă. Totuși, aceste aplicații trebuie să funcționeze în mai multe centre de date. Astfel se naște întrebarea privind continuitatea afacerii: „Cum îmi pot rula aplicațiile în mai multe centre de date, asigurând în același timp corectitudinea și consecvența datelor?”.

Indiferent dacă arhitecturile monolitice utilizează seturi de date „partajate” sau microserviciile sunt configurate pentru disponibilitate ridicată între locații, arhitectura de date oferă date corecte, cu viteză mare, la orice distanță.

O arhitectură de date poate constitui fundația pentru datele descentralizate, dar corecte 100% pentru toate site-urile. De exemplu:

• Tranzacții logice cu latență foarte scăzută (între platforme)
• Funcționalitățile compatibile ACID garantează corectitudinea datelor
• Soluționare multiactivă și bidirecțională a conflictelor

O platformă modernă, de tip arhitectură, utilizează evenimente pentru schimbul de date. În loc să depindă de procesarea pe loturi la nivelul datelor, sarcinile utile de date circulă în permanență atunci când au loc evenimente în aplicație sau în depozitul de date.

În cazul anumitor arhitecturi, microserviciile trebuie să facă schimb de sarcini utile de date între ele. Alte modele necesită schimburi între aplicațiile monolitice sau depozitele de date. Astfel se naște întrebarea: „Cum pot transfera în mod fiabil sarcinile utile de date pentru microservicii între aplicațiile și depozitele mele de date?”

O arhitectură de date poate furniza tehnologia de bază pentru schimbul de date axat pe microservicii. De exemplu:

• De la microservicii la microservicii în cadrul contextului
• De la microservicii la microservicii de la un context la altul
• De la monoliți către microservicii, de la microservicii către monoliți

Modelele de microservicii, cum ar fi asigurarea evenimentelor, CQRS și outbox-ul pentru tranzacții, sunt soluții înțelese în mod obișnuit. O arhitectură de date oferă instrumentele și infrastructura necesară pentru ca aceste modele să fie repetabile și fiabile la scară largă.

În afara modelelor de proiectare a microserviciilor, necesitatea integrării la nivel enterprise se extinde și la alte sisteme IT, precum bazele de date, procesele de business și aplicațiile și dispozitivele fizice de toate tipurile. O arhitectură de date oferă baza pentru integrarea datelor în mișcare.

De obicei, datele în mișcare se bazează pe evenimente. O acțiune a utilizatorului, un eveniment al dispozitivului, o etapă a procesului sau o confirmare a depozitului de date pot iniția un eveniment cu o sarcină utilă de date. Aceste sarcini utile de date sunt esențiale pentru integrarea sistemelor Internet of Things (IoT), a proceselor de afaceri, a bazelor, depozitelor și lacurilor de date.

O arhitectură de date oferă tehnologia de bază pentru integrarea în timp real, în întreaga companie. De exemplu:

• Conectarea evenimentelor legate de dispozitivele reale la sistemele IT
• Integrarea proceselor de afaceri în sistemele ERP
• Alierea bazelor de date operaționale cu depozitele de date analitice

Organizațiile mari vor avea, în mod firesc, o combinație de sisteme vechi și noi, monoliți și microservicii, depozite de date operaționale și analitice. O arhitectură de date poate contribui la unificarea acestor resurse în domenii de afaceri și de date diferite.

Depozitele de date analitice pot include tehnologii pentru piețe, depozite de date, cuburi OLAP și locații/lacuri de date.

În general, există doar două modalități de a transfera date în aceste depozite de date analitice:

• Încărcare în loturi/micro-loturi cu un instrument de programare a timpului
• Colectarea streamingului – încărcare continuă a evenimentelor de date

O arhitectură de date oferă baza pentru o funcționalitate de colectare a datelor în streaming. De exemplu:

• Evenimentele de date din baze sau depozite de date
• Evenimentele de la dispozitive obținute din telemetria dispozitivelor fizice
• Jurnalizarea evenimentelor din aplicații sau tranzacții de afaceri

Colectarea evenimentelor din streaming poate reduce impactul asupra sistemelor sursă, îmbunătăți exactitatea datelor (important pentru știința datelor) și permite analize în timp real.

După colectarea în depozitele de date analitice, este nevoie, de obicei, de procese care să pregătească și să transforme datele în diverse etape sau domenii. Acest proces de rafinare a datelor este adesea necesar pentru produsele de date analitice din aval.

O arhitectură de date poate oferi un nivel de procese de date guvernat în mod independent, care funcționează cu depozitele de date analitice, asigurând următoarele servicii de bază:

• Descoperirea și pregătirea automată a datelor
• Organizarea resurselor de date din toate domeniile
• Pregătirea și transformarea datelor în formatele necesare pentru produsele date
• Verificarea datelor prin intermediul unei politici care asigură consecvența

Aceste procese de date trebuie să poată funcționa în diverse depozite de date fizice (cum ar fi piețe, depozite sau lacuri) sau ca un „flux de trimitere a datelor” în cadrul platformelor de date analitice care acceptă fluxuri de date, cum ar fi Apache Spark și alte tehnologii pentru locațiile de date.

Evenimentele au loc în permanență. Analiza evenimentelor în streaming poate fi decisivă pentru a înțelege ce se întâmplă de la un moment dat.

Acest tip de analize bazate pe serii cronologice ale fluxurilor de evenimente în timp real pot fi importante pentru datele dispozitivelor din lumea reală IoT și pentru a înțelege ce se întâmplă în centrele de date IT sau în cadrul tranzacțiilor financiare, cum ar fi monitorizarea fraudelor.

O arhitectură de date completă va include funcționalitățile de bază pentru analiza evenimente de toate tipurile, în diverse intervale de timp pentru evenimente. De exemplu:

• Analiză simplă a streamingului de evenimente (evenimente web)
• Monitorizarea activității de afaceri (evenimente SOAP/REST)
• Procesarea complexă a evenimentelor (corelare multi-flux)
• Analiza evenimentelor de date (în tranzacțiile DB/ACID)

La fel ca procesele de date, analizele streamingului trebuie să poată rula în cadrul unei infrastructuri stabilite de tip locații de date sau separat, ca servicii native în cloud.

Liderii din domeniul integrării datelor colectează datele operaționale și analitice în timp real dintr-o colecție diversă de depozite reziliente de date. Inovațiile au apărut rapid și continuu, pe măsură ce arhitectura de date a evoluat spre analiza în streaming. Disponibilitatea operațională ridicată a condus la analize în timp real, iar automatizarea ingineriei datelor a simplificat pregătirea datelor, oferind cercetătorilor și analiștilor de date instrumente cu autoservire.