PLANUL SECTORIAL DE CERCETARE-DEZVOLTARE AL MSI ...

PLANUL SECTORIAL DE CERCETARE-DEZVOLTARE AL MSI

2015-2017

PROGRAMUL “AGENDA DIGITALĂ PENTRU ROMÂNIA – SECŢIUNEA: SERVICII

ELECTRONICE”

NR. CONTRACT / DATA Act adiţional

143/ 10.07.2015

DENUMIRE PROIECT Utilizarea tehnologiilor Big Data în sistemele informaţionale guvernamentale

ETAPA DE ELABORARE 1: Studiu referitor la abordarea Big Data în sectorul public

NR. VOL. / VERSIUNE 1/ 1

TERMEN DE PREDARE 30 NOIEMBRIE 2015

AUTORITATE CONTRACTANTĂ

Ministerul Comunicaţiilor şi pentru Societatea Informaţională

CONDUCEREA UNITĂŢII ELABORATOARE

DIRECTOR GENERAL, prof. dr. ing. Doina Banciu

…………………………………………………………….

DIRECTOR ŞTIINŢIFIC, dr.ing. Neculai Andrei

…………………………………………………………….

RESPONSABIL PROIECT, prof. dr. ing. Adriana Alexandru

…………………………………………………………….

LOCALITATEA Bucureşti

LUNA NOIEMBRIE

ANUL 2015

© ICI Reproducerea sau utilizarea integrală sau parţială a prezentului document în orice publicaţii şi prin orice procedeu (electronic, mecanic, fotocopiere, multiplicare etc.) este interzisă dacă nu există acordul scris al ICI.

Documentaţia conţine un studiu/raport de cercetare pe suport hârtie având 103 pagini şi un CD conţinând respectivul studiu/raport de cercetare

ICI – CS 143 ”Utilizarea tehnologiilor Big Data în sistemele informaţionale guvernamentale”

Etapa I - Studiu referitor la abordarea Big Data în sectorul public 1

Plan sectorial: MSI

Proiect: Utilizarea tehnologiilor Big Data în sistemele informaţionale guvernamentale

Etapa I - noiembrie 2015

Denumire etapă: Studiu referitor la abordarea Big Data în sectorul public

Rezultat: Studiu asupra seturilor de Big Data dedicate sectorului public care fac obiectul

proiectului. Analiză privind criteriile de selecţie a celor mai reprezentative tehnologii, bune

practici şi soluţii de eGuvernare.

Activităţi:

A I.1 - Studiu asupra conceptelor legate de Big Data

Rezultat: Studiu asupra seturilor de Big Data dedicate sectorului public care fac

obiectul proiectului

A I.2 - Elaborarea unui studiu privind arhitecturi, tehnologii şi seturi Big Data în sisteme

informaţionale guvernamentale

Rezultat: Criteriile de selecţie a celor mai reprezentative arhitecturi, tehnologii şi

seturi Big Data

A I.3 - Fundamentarea criteriilor de selecţie a celor mai reprezentative tehnologii, bune

practici şi soluţii de sisteme informaţionale guvernamentale

Rezultat: Criteriile de selecţie a celor mai reprezentative bune practici şi soluţii de

eGuvernare

A I.4 - Managementul etapei

Rezultat: Raport de etapă. Documente de predare



Cuprins

1. INTRODUCERE....................................................................................................................... 6 1.1. SCOPUL PROIECTULUI ...................................................................................................... 8 1.2. OBIECTIVELE ŞI FAZELE PROIECTULUI ............................................................................... 8 1.3. OBIECTIVELE FAZEI ACTUALE .......................................................................................... 10 1.4. REZUMATUL FAZEI ACTUALE ........................................................................................... 10

2. CONCEPTE LEGATE DE SETURILE BIG DATA .......................................................... 11 2.1. DEFINIREA BIG DATA ..................................................................................................... 11 2.2. CONCEPTE CONEXE ........................................................................................................ 14

2.2.1. Specialistul în date ............................................................................................... 14 2.2.2. Analiza Big Data .................................................................................................. 15 2.2.3. Date ascunse (dark data) ...................................................................................... 16

2.3. PROBLEME SPECIFICE BIG DATA ..................................................................................... 17 2.4. PROVOCĂRI ALE BIG DATA .............................................................................................. 18

3. ARHITECTURI, TEHNOLOGII ŞI SETURI BIG DATA ÎN SISTEME INFORMAŢIONALE GUVERNAMENTALE .............................................................. 20

3.1 ARHITECTURI PENTRU SISTEMELE BIG DATA ..................................................................... 20 3.1.1 Framework-ul Hadoop .......................................................................................... 20 3.1.2. Integrare Big Data cu Hadoop ............................................................................. 33

3.1.2.1. Arhitectura unui ecosistem pentru integrarea Big Data pentru business ...... 35 3.1.2.2. Arhitectura client-server pentru Big Data ..................................................... 37 3.1.2.3. Arhitectura pentru analiză Big Data ............................................................. 40 3.1.2.4 Arhitectura multi-agent pentru procesarea în timp real a Big Data ............... 41 3.1.2.5. Analiza Arhitecturii Multi-Agent Big Data .................................................. 44

3.2. TEHNOLOGII PENTRU BIG DATA ...................................................................................... 47 3.2.1. Mecanisme de stocare pentru Big Data ............................................................... 47

3.2.1.1. Baze de date .................................................................................................. 48 3.2.1.2. Tehnologia NoSQL ....................................................................................... 50

3.3. SETURI BIG DATA ........................................................................................................... 54 3.3.1. Categorii de date .................................................................................................. 54 3.3.2. Procesul de achiziţie a datelor ............................................................................. 55

3.3.2.1. Colectarea datelor ......................................................................................... 55 3.3.2.2. Transferul datelor .......................................................................................... 56

3.3.2.3. Pre-procesarea datelor...................................................................................... 57 3.3.3. Sisteme distribuite pentru stocarea datelor .......................................................... 58 3.3.4. Domenii de aplicabilitate a Big Data ................................................................... 59

3.4. IMPACTUL BIG DATA ŞI ANALYTICS ASUPRA SISTEMULUI PUBLIC ....................................... 62 3.4.1. Evoluţii recente ale sistemului public ................................................................... 62 3.4.2. Oportunităţi specifice serviciilor publice ............................................................. 63 3.4.3. Provocări specifice sectorului public ................................................................... 64 3.4.4. Beneficii specifice sectorului public ..................................................................... 65

4. CRITERII DE SELECŢIE A CELOR MAI REPREZENTATIVE TEHNOLOGII, BUNE PRACTICI ŞI SOLUŢII DE SISTEME INFORMAŢIONALE GUVERNAMENTALE ..................................................................................................... 67

4.1. FUNDAMENTAREA NECESITĂŢII ABORDĂRII BIG DATA ÎN CADRUL SISTEMELOR INFORMAŢIONALE GUVERNAMENTALE ..................................................................................... 67 4.2. CRITERII DE EVALUARE A INFRASTRUCTURII HARD ............................................................ 71

4.2.1. Criterii de utilizare ale Cloud Computing pentru Big Data ................................. 71



4.2.2. Existenţa backbon-ului 5G pentru aplicaţii Big Data şi Internetul lucrurilor. .... 72 4.3. CRITERII DE EVALUARE A TEHNOLOGIILOR ŞI SOLUŢIILOR SOFTWARE ................................ 72

4.3.1. O clasificare a tehnologiilor Big Data ................................................................. 72 4.3.2. Criterii de selecţie a celor mai reprezentative servicii ......................................... 73 4.3.3. Stiva metodelor analitice predictive pentru Big Data în timp real ...................... 73 4.3.4. Criterii utilizate în alegerea modului de stocare şi procesare primară a datelor75 4.3.5. Criterii în alegerea metodelor de stocare a datelor în sistemele Big Data ......... 75 4.3.6. Comparaţii între conceptul de depozit de date (data warehouse) şi abordarea Big Data ................................................................................................................................ 76 4.3.7. Criterii de alegere a software-ului de stocare şi procesare pentru Big Data ...... 78

4.3.7.1 Criterii de selectare a modalităţilor de stocare a Big Data ............................. 80 4.3.7.2 Exemplu de platformă de stocare a datelor-Spectrum Scale de la IBM ........ 80

4.3.8. Criterii utilizate în alegerea metodelor şi modelelor analitice ....................... 81 4.3.9. Criterii de selecţie asociate cadrului general al metodelor analitice pentru Big Data în timp real............................................................................................................. 82

4.4. ROLUL SPECIALIŞTILOR ÎN DATE ŞI CRITERII DE ALEGERE A ACESTORA .............................. 85 4.4.1. Joburi specifice Big Data ..................................................................................... 85

4.5. BIG DATA ÎN GUVERNARE - GHID DE BUNE PRACTICI ...................................................... 85 4.6. UTILIZAREA BUNELOR PRACTICI ÎN DOMENIUL BIG DATA ................................................. 94

4.6.1. Aspecte generale teoretice legate de bunele practici ........................................... 94 4.6.2. Bune practici pentru managementul Big Data ..................................................... 94 4.6.3. Studiu de caz – Proiectul European Anticorupţie ................................................ 95

4. CONCLUZII ŞI PLANUL DE CONTINUARE .................................................................. 97

5. BIBLIOGRAFIE ..................................................................................................................... 99

6. ANEXA - GLOSAR DE TERMENI ................................................................................... 103



Figuri în cadrul raportului de cercetare

Figura 1. Arhitectura de nivel înalt de cluster Hadoop multi-nod ........................................... 22

Figura 2. Un cluster multi-nod Hadoop ................................................................................... 23

Figura 3. Ecosistemul Hadoop ................................................................................................. 25

Figura 4. Arhitectura HDFS de tip master / slave .................................................................... 26

Figura 5. Arhitectura HDFS pe două niveluri .......................................................................... 27

Figura 6. Model de procesare MapReduce .............................................................................. 28

Figura 7. Arhitectura sistem MapReduce şi HDFS pentru un cluster mare............................. 29

Figura 8. Arhitectura MapReduce............................................................................................ 30

Figura 9. Arhitectura Big Data................................................................................................. 33

Figura 10. Arhitectura unui ecosistem pentru integrarea Big Data ......................................... 36

Figura 11. Arhitectura client-server pentru Big Data .............................................................. 37

Figura 12. Arhitectura Cluster HBase/Hadoop pentru Big Data ............................................. 39

Figura 13. Arhitectura pentru Analize Big Data ...................................................................... 41

Figura 14. Arhitectura Lambda ................................................................................................ 41

Figura 15. Arhitectura Lambda integrată cu Hadoop .............................................................. 43

Figura 16. Arhitectura pentru prelucrarea Big Data folosind sisteme multi-agent .................. 45

Figura 17. Ciclul de execuţie pentru tehnologiile emergente .................................................. 67

Figura 18. Stiva metodelor analitice predictive pentru Big Data în timp real ......................... 74

Figura 19. Componentele majore puse împreună într-o soluţie Big Data completă ................ 79

Figura 20. Transformarea Big Data în valoare ........................................................................ 82

Figura 21. Algoritmi de învăţare maşină pentru analiza Big Data (după IBM, 2015) ............ 84

Figura 22. Carteluri – Unele firme licitează împreună cu un câştigător şi pierd periodic ....... 95

Tabele în cadrul raportului de cercetare

Tabelul 1. Task-urile MapReduce ........................................................................................... 29

Tabelul 2. Componentele Hadoop şi funcţionalităţile lor ....................................................... 32

Tabelul 3. Comparaţie a celor mai importante caracteristici ale bazelor de date SQL şi NoSQL ..................................................................................................................................... 76

Tabelul 4. Probleme guvernamentale de afaceri potrivite pentru o soluţie de Big Data ........ 88



1. Introducere

Pe parcursul ultimelor decenii, organizaţiile au început să acorde importanţă sporită datelor şi să investească mai mult în colectarea şi gestionarea lor. Managementul tradiţional al informaţiei şi procesele de analiză a datelor („analytics”) urmăresc în principal sprijinirea proceselor decizionale interne. Acestea operează cu date de tip structurat, existente preponderent în interiorul organizaţiei.

În comparaţie cu instrumentele analitice tradiţionale, conceptul Big Data introduce modificări în cadrul a trei dimensiuni: (1) tipuri de date, (2) viteza de acumulare a acestora şi (3) volumul lor. Odată cu lansarea mediului Web 2.0, în jurul anului 2005, o mare parte din datele de valoare pentru întreprinderi sunt generate în exteriorul organizaţiei, de către consumatori şi în general, utilizatori Web.

Pe parcursul evoluţiei IT, fiecare generaţie de procesare şi analiză a datelor organizaţionale a căpătat denumiri noi.

Unele tipuri de date precum text şi voce, există de mult timp, însă volumul acestora în mediul Internet şi în alte structuri digitale anunţă începutul unei noi ere, precum şi a unor noi tehnologii care permit analizarea acestor tipuri de date.

Dincolo de informaţiile colectate în interiorul organizaţiilor şi de volumul crescând de date pe care le generează calculatoarele în funcţionarea lor, cele obţinute din exteriorul organizaţiei, fie structurate sau nestructurate, au surse multiple care pot include de la informaţii postate pe reţele de socializare şi produse vizionate în magazine virtuale, la informaţii citite de către senzori, semnale GPS de pe dispozitivele mobile, adrese IP ale computerelor, cookie-uri, coduri de bare ş.a.m.d.

Multe dintre cele mai importante surse de date însă sunt relativ noi. Se argumentează că explozia volumului de date caracteristic fenomenului prezent, Big Data, provine din datele de natură nestructurată. În cadrul acestora, spre deosebire de datele generate de către utilizatori, care au la origine informaţii furnizate voluntar în diferite medii de diseminare Web, există şi datele interceptate. Acestea din urmă se referă la informaţii colectate în mod pasiv din comportamentul online al indivizilor, cum sunt, de pildă, termenii de căutare online sau localizarea indivizilor prin aplicaţiile prezente pe dispozitivele mobile.

În acest context, anumiţi cercetători exprimă faptul că fiecare persoană devine ”un generator ambulant de date”.

Contextul european

Crearea de date se desfăşoară într-un ritm record şi neaşteptat. Analiştii care desfăşoară studii de piaţă consideră că organizaţiile cele mai capabile să ia decizii de afaceri în timp real folosind soluţiile Big Data se vor dezvolta, în timp ce acelea incapabile să adopte şi să folosească această schimbare se vor găsi din ce în ce mai des în dezavantaj pe piaţă şi se vor confrunta cu un posibil eşec.



Big Data, un termen general pentru cantitatea masivă de date colectată din variate surse, este prea mare, neprocesată sau nestructurată pentru analiza prin tehnicile convenţionale ale bazelor de date.

Numeroase ghiduri, articole de presă şi rapoarte ale mediului de afaceri au propus mijloace prin care guvernele se pot folosi de Big Data pentru a le ajuta să servească cetăţenii şi să depăşească provocările pe plan naţional (cum ar fi creşterea costurilor pentru sănătate, creare de locuri de muncă, dezastre naţionale şi securitate naţională).

La nivel european, îmbunătăţirea analizei şi procesării datelor, în special a Big Data, va permite:

• transformarea serviciilor industriale ale Europei prin generarea multor produse şi servicii

• inovatoare bazate pe informaţie;

• creşterea productivităţii în toate sectoarele economiei prin îmbunătăţirea informaţiilor de afaceri;

• adresarea mai adecvată a multor provocări cu care se confruntă societatea noastră;

• îmbunătăţirea cercetării şi creşterea vitezei de inovare;

• dobândirea unor reduceri de costuri prin folosirea de servicii personalizate;

• creşterea eficienţei sectorului public

• primirea de informaţii despre datele ce pot preveni sau împiedica fraude şi abuzuri.

În prezent, Platforma Europeană pentru Tehnologia Software şi Servicii NESSI, împreună cu parteneri din proiectul FP7 Big, a realizat planul Agendei de Cercetare Strategică şi Inovare (ACSI) cu privire la Big Data Value în Europa. Obiectivul ACSI este de a descrie principalele provocări de cercetare şi nevoile cu privire la implementarea Big Data Value în Europa.

Contextul naţional

În România nu au fost realizate cercetări cu privire la tipul şi complexitatea datelor aflate în exploatare în diversele sisteme informatice de la nivelul Administraţiei Publice Centrale, iar cadrul legislativ şi organizatoric aferent implementării sistemelor de tip Big Data nu este încă elaborat. Cu toate acestea, este important să amintim câteva sisteme informatice implementate cu succes în anii precedenţi în România.

Datele stocate în aceste sisteme naţionale sunt exemple de categorii de date candidate pentru implementarea sistemelor de tip Big Data:

• SEAP – Sistemul Electronic de Achiziţii Publice

• DEDOC şi sistemul RAMP aflat în implementare la nivelul MFP



• Sistemul informatic integrat al ONRC

• ORIZONT - Sistem Integrat pentru Casa Naţională de Pensii Publice

• SIUI, Dosarul Electronic de Sănătate, e-Prescripţie – Sisteme aflate în exploatare la nivelul Casei Naţionale de Asigurări de Sănătate (CNAS)

• Sistemele informatice ce realizează legătura dintre entităţile Ministerului pentru Finanţele Publice

• eTerra – Sistemul integrat de Cadastru şi Publicitate Imobiliară.

1.1. Scopul proiectului

Cercetarea în domeniul Big Data poate conduce la dezvoltarea programelor de politici publice şi poate îmbunătăţi performanţa guvernului, atât în beneficiul agenţilor externi şi al cetăţenilor, cât şi în beneficiul propriilor agenţi guvernamentali.

Scopul proiectului constă în identificarea şi analiza unor sisteme şi tehnologii Big Data pentru creşterea eficienţei sistemului guvernamental, prin adaptarea şi îmbunătăţirea proceselor şi operaţiunilor existente şi prin implementarea unora complet noi.

Proiectul îşi propune analiza de modele, practici de gestionare şi soluţii de utilizare a tehnologiilor Big Data ca suport pentru dezvoltarea de servicii electronice fie în cadrul platformelor deja existente destinate furnizării de servicii publice on-line, fie în cadrul unor platforme nou create în jurul potenţialului dat de seturile de Big Data.

Furnizarea de instrumente uşor accesibile şi o analiză profundă la nivelul societăţii informaţionale poate permite organizaţiilor comerciale, societăţii civile şi persoanelor fizice să contribuie mult mai eficient la dezvoltarea sectorului public într-o diversitate de moduri.

1.2. Obiectivele şi fazele proiectului

Obiectivul principal al proiectului constă în identificarea şi analiza unor sisteme şi tehnologii Big Data pentru creşterea eficienţei sistemului guvernamental, prin adoptarea şi îmbunătăţirea proceselor şi operaţiunilor existente şi prin implementarea unora complet noi.

Obiectivele specifice ale proiectului sunt:

1. Analiza privind seturile de date care se încadrează în conceptul de Big Data;

2. Analiza provocărilor curente privind securitatea, confidenţialitatea datelor şi posibile vulnerabilităţi induse de sisteme Big Data;

3. Determinarea practicilor adecvate de gestionare şi procesare a datelor din diferite surse şi aflate în diverse formate;

4. Modalităţi de identificare a datelor şi a conţinutului adecvat organizaţiilor guvernamentale în vederea optimizării, reducerii costurilor şi creşterea valorii serviciilor;



5. Analiză privind depozitarea şi gestionarea Big Data în sisteme de Cloud Computing;

6. Analiză privind serviciile şi tehnologiile Big Data în sistemele informaţionale guvernamentale.

Obiectivele măsurabile. În urma derulării proiectului vor fi obţinute următoarele rezultate directe:

- Realizarea unui studiu privind metodele de definire a seturilor Big Data aplicabile sectorului guvernamental;

- Un studiu privind cerinţele de stocare şi tipurile de formate a datelor structurate şi nestructurate întâlnite frecvent în cadrul seturilor Big Data guvernamentale;

- Un studiu privind criteriile de selecţie a tehnologiilor Big Data reprezentative din sectorul de eGuvernare;

- Realizarea unui studiu privind soluţiile Big Data implementate în sisteme informaţionale guvernamentale;

- Un studiu privind depozitarea şi gestionarea Big Data utilizând Cloud Computing ca suport de stocare şi dezvoltare tehnologică pentru soluţii informatice;

- Un set de caracteristici reprezentative pentru dezvoltarea serviciilor bazate pe seturile Big Data;

- Un set de caracteristici din perspectiva utilizării impactului tehnologiilor Big Data pentru servicii informaţionale guvernamentale în România;

- Un set de recomandări în vederea implementării tehnologiilor Big Data pentru dezvoltarea serviciilor guvernamentale.

Obiectivele specifice ale proiectului de cercetare propus sunt conforme cu principalele activităţi definite prin Termenii de referinţă. Astfel, prin soluţiile şi rezultatele care urmează a fi obţinute se are în vedere realizarea obiectivelor şi priorităţilor programului în sensul contribuţiei la introducerea şi dezvoltarea tehnologiilor Big Data ca suport pentru dezvoltarea guvernării electronice prin aplicaţii informatice de interes public şi personal.

Fazele de realizare ale proiectului pe toată durata cercetării sunt următoarele:

Nr. crt. Anul Denumire fază Termen de predare

1

2015

Analiza seturilor Big Data dedicate sectorului public şi studierea practicilor de gestionare şi procesare a datelor din diferite surse aflate în diverse formate

Noiembrie 2015

2

2016

Analiza asupra tehnologiilor, bunelor practici şi a soluţiilor de eGuvernare care utilizează seturi Big Data, existente la nivel naţional, european şi internaţional

Noiembrie 2016



3

2017

Identificarea impactului produs de utilizarea seturilor Big Data pentru dezvoltarea sistemelor informaţionale guvernamentale în România. Elaborarea unui set de recomandări privind bunele practici studiate, referitoare la serviciile şi tehnologiile Big Data

Noiembrie 2017

1.3. Obiectivele fazei actuale

În cadrul acestei etape intitulată „Studiu referitor la abordarea Big Data în sectorul public”, principalele obiective constau în:

- Realizarea unui studiu asupra conceptelor legate de Big Data şi asupra seturile de

Big Data dedicate sectorului public care fac obiectul proiectului

- Elaborarea unui studiu privind arhitecturi, tehnologii şi seturi Big Data în sisteme

informaţionale guvernamentale.

- Fundamentarea unor criterii de selecţie a celor mai reprezentative arhitecturi,

tehnologii şi seturi Big Data

- Identificarea criteriilor de selecţie a celor mai reprezentative bune practici şi soluţii

de eGuvernare

1.4. Rezumatul fazei actuale

În cadrul primei faze a proiectului, colectivul de cercetare a elaborat raportul de cercetare aferent fazei conform cu Termenii de referinţă şi Planul de realizare al proiectului.

Raportul de cercetare elaborat în cadrul primei faze cuprinde 4 capitole principale, un capitol de concluzii, unul cu bibliografie şi o anexă.

Pentru atingerea obiectivelor fazei 1, în Capitolul 1 - Introducere sunt prezentate condiţiile în care a apărut fenomenul Big Data, scopul proiectului, obiectivele şi fazele proiectului.

În Capitolul 2 s-a realizat un studiu privind conceptul Big Data, concepte conexe (specialistul în date, analiza Big Data, date ascunse (dark data)), probleme specifice Big Data şi provocări ale Big Data.

Capitolul 3 prezintă diferite arhitecturi pentru sistemele cu Big Data (framework-ul Hadoop, integrarea Big Data cu Hadoop), tehnologii pentru Big Data (Tehnologia NoSQL), seturi Big Data precum şi impactul Big Data şi analiza datelor aferente sistemului public.

În Capitolul 4 sunt prezentate pe de o parte criteriile de selecţie a celor mai reprezentative tehnologii şi pe de altă parte bunele practici şi soluţiile pentru sistemele guvernamentale.



2. Concepte legate de seturile Big Data

Big Data reprezintă un concept care se referă la o iniţiativă informaţională care rezolvă problema procesării unei cantităţi crescute de date într-un interval limitat. Aproape 90% din datele existente în prezent la nivel mondial au fost generate în ultimii doi ani. Mai mult, aproximativ 90% din aceste date sunt nestructurate. Pe de altă parte, cantitatea copleşitoare de Big Data existentă pe web şi în Cloud oferă noi oportunităţi pentru descoperirea şi crearea de valoare, pentru creşterea inteligenţei în afaceri prin deciziile adoptate la nivel de organizaţii (Gang-Hoon, 2014).

Bazându-se pe câţiva ani de succes în diferite segmente de guvernare, în martie 2012, Administraţia de la Casa Albă a dezvoltat şi a anunţat lansarea "Iniţiativei de Cercetare şi Dezvoltare în Big Data". Această iniţiativă este destinată a "ajuta la rezolvarea unora dintre cele mai presante provocări ale naţiunii" prin încurajarea şi îmbunătăţirea capacităţii de a genera descoperiri prin colectarea şi analiza unor colecţii de date mari şi complexe (Obama, 2012).

În esenţă, acest anunţ a declanşat o creşterea curiozităţii şi interesului în tehnologiile şi mijloacele de analiză aferente Big Data din întregul spectru guvernamental.

Conceptul de Big Data este în prim-planul temelor actuale în cele mai multe cercuri de IT. Înţelegerea conceptului de Big Data, la fel ca orice altă tehnologie în curs de dezvoltare, necesită mai întâi ca acesta să fie definit.

2.1. Definirea Big Data În anul 2001, un analist al companiei de consultanţă META (în prezent Gartner) a

definit schimbările şi oportunităţile aduse de volumul mare de date printr-un model 3V: Volum, Viteză şi Varietate (Laney, 2001).

În 2011, un raport al International Data Corporation a definit Big Data ca fiind “o nouă generaţie de tehnologii şi arhitecturi, proiectate pentru a extrage valoare economică din volume foarte mari de date de o largă varietate, prin asigurarea unei viteze ridicate de captare, descoperire şi/sau analiză” (Gantz şi Reinsel, 2011). Cu această definiţie, caracteristicile Big Data pot fi sintetizate prin 4V, adică Volum, Viteză, Varietate şi Veridicitate. Această definiţie evidenţiază cea mai critică problemă în Big Data, aceea a descoperirii valorilor din seturile de date cu dimensiuni uriaşe, în condiţiile unei mari varietăţi de tipuri de date şi unei generări rapide a datelor.

National Institute of Standards and Technology a formulat la rândul său următoarea definiţie: “Big Data înseamnă datele al căror volum, viteză de achiziţie sau reprezentare limitează capacitatea folosirii metodelor relaţionale tradiţionale de a efectua o analiză eficientă, sau datele care pot fi procesate cu succes cu tehnologii de investigare pe orizontală”, care se concentrează pe aspectul tehnologic al Big Data. Aceasta indică necesitatea dezvoltării de metode şi tehnologii eficiente pentru analiza şi procesarea Big Data.



Alte definiţii au fost furnizate de:

- Un raport din 2011 al McKinsey Global Institute în care se afirmă: ”Big Data se referă la seturi de date a căror dimensiune depăşeşte capacitatea de captare, stocare, administrare şi analiză a instrumentelor software şi a bazelor de date uzuale”.

- Conform definiţiei propuse de EMC şi IDM, Big Data reprezintă o nouă generaţie de tehnologii şi arhitecturi destinate extragerii de valoare din cadrul volumelor foarte mari de date care au o mare varietate, permiţând prelucrarea şi analiza acestora în timp real.

- Wikipedia: „Big Data include în mod usual seturi de date de dimensiuni care depăşesc capacitatea instrumentelor utilizate curent pentru a le captura, administra, gestiona şi procesa într-un interval de timp admisibil”.

- Firma de consultanţă Gartner: „Big Data reprezintă informaţie de volum mare, de mare viteză de generare şi / sau varietate ridicată, care necesită noi forme de prelucrare pentru a permite luarea de decizii îmbunătăţite, descoperirea de aspecte ascunse şi optimizarea proceselor”.

Big Data reprezintă un concept care se referă la o iniţiativă informaţională care rezolvă problema procesării unei cantităţi crescute de date într-un interval limitat.

Termenul ”Big Data” se referă la instrumente, procese, şi proceduri care permit organizaţiilor să creeze, să manipuleze şi să administreze seturi mari de date precum şi facilităţi de stocare a acestora.

Big Data face referire la colecţia de seturi de date într-atât de mari şi complexe încât devin dificil de procesat folosind doar instrumentele de gestiune a bazei de date aflate la dispoziţie sau aplicaţiile tradiţionale de procesare a datelor.

Rezumând, conceptul ”Big Data” se referă la instrumente, procese, şi proceduri care permit organizaţiilor să creeze, să manipuleze şi să administreze seturi mari de date precum şi facilităţi de stocare a acestora. Aceste volume nu se pot evalua în TB (terabytes), PB (petabytes) sau dimensiuni mai mari.

În plus, Big Data reprezintă o nouă generaţie de tehnologii şi arhitecturi destinate extragerii de valoare din cadrul volumelor foarte mari de date care au o mare varietate, permiţând prelucrarea şi analiza acestora în timp real.

Tehnologiile Big Data reprezintă un domeniu aflat în continuă dezvoltare ce se ocupă cu analiza şi gestionarea volumelor mari de date. Această definiţie cuprinde atât echipamentele hardware, cât şi sistemele software care integrează, organizează, gestionează, analizează şi prezintă datele care se caracterizează prin cei "patru V".

Întrucât cei "patru V" sunt consideraţi definitorii pentru acest concept, este oportună o detaliere a semnificaţiei acestor caracteristici.

1. Volum: creşterea volumelor de date în sisteme de tip întreprindere este cauzată de volumul tranzacţiilor şi a altor tipuri de date tradiţionale, precum şi de noi tipuri de date. Un



volum prea mare de date reprezintă o problemă de stocare, dar prea multe date au în egală măsură şi un mare impact asupra complexităţii analizei datelor;

2. Viteză: se referă atât la rapiditatea cu care datele sunt produse, cât şi la rapiditatea cu care datele trebuie să fie prelucrate pentru a satisface cererea. Acest lucru implică fluxuri de date, crearea de înregistrări structurate, precum şi disponibilitatea pentru acces şi livrare. Viteza de generare, prelucrare şi analiză a datelor creşte continuu, în principal din următoarele motive: specificul de timp real al proceselor de generare, cererile care rezultă din combinarea fluxurilor de date cu procesele de afaceri, specificul proceselor de luare a deciziilor. Viteza de prelucrare a datelor trebuie să fie ridicată în timp ce capacitatea de prelucrare depinde preponderent de tipul de prelucrare al fluxurilor de date.

3. Varietate: liderii IT au avut întotdeauna o problemă cu transformarea volumelor mari de informaţii tranzacţionale în decizii deşi tipurile de date generate sau prelucrate erau puţin diversificate, mai simple şi majoritar structurate. În prezent există mai multe tipuri de informaţii pentru analiză generate de noile canale şi tehnologii apărute - în principal provenind din social media, Internetul lucrurilor, surse mobile (sensibile la context) şi publicitatea online – care generează date semistructurate sau nestructurate. Varietatea include date tabelare (baze de date), date ierarhice, documente, XML, e-mailuri, blog-uri, mesaje instant, click stream-uri, fişiere log, date de contorizare, imagini statice, audio, video, date despre cursul acţiunilor (stoc ticker), tranzacţii financiare etc.

4. Veridicitate: se referă la cât de încredere sau de îndoielnice sunt datele. Calitatea datelor Big Data este mai puţin controlabilă deoarece provine din diferite surse pentru care nu se poate garanta calitatea conţinutului şi forma lui de prezentare. Pentru analistul de date experimentat este esenţială capacitatea de a evalua conformitatea, acurateţea şi sinceritatea datelor supuse analizei. Aici discuţia se poartă în jurul responsabilităţii generatorului iniţial al datelor, scopului pentru care datele sunt emise şi reacţiilor receptorilor.

Nu există un prag predefinit al celor „patru V”, care să indice când o organizaţie a intrat în domeniul "Big Data". Pe măsură ce tehnologiile avansează, dimensiunile seturilor de date care pot fi caracterizate ca Big Data vor creşte permanent. Acest prag este relativ şi se bazează pe doi factori:

• un factor tactic: dacă infrastructura IT existentă nu poate face faţă în condiţii de eficienţă creşterii unuia dintre cei „patru V”, organizaţia are o posibilă problemă de tip Big Data (o problemă de scalare);

• un factor strategic: dacă compania nu îşi poate atinge obiectivele fără analiza unui volum mai mare de informaţii, iar această cerinţă complică soluţia existentă de management a datelor.

Există un consens larg în cadrul mediului comercial, dar şi academic şi de guvernare cu privire la potenţialul remarcabil al tehnologiilor Big Data în direcţiile inovării, susţinerii comerţului şi dezvoltarea serviciilor publice pentru cetăţeni.



În stadiul actual, Big Data reprezintă tranziţia de la simpla analiză statistică a datelor la o abordare mult mai complexă şi sistematică, care poate să impulsioneze dezvoltarea atât a serviciilor de guvernare, cât şi a companiilor private.

Diferite sisteme stochează datele în diferite formate, chiar şi în cadrul aceleiaşi companii, ceea ce face dificil agregarea datelor pentru analiză. Ca urmare, investiţiile unei organizaţii în date, unul dintre activele sale cele mai de valoarea, nu sunt utilizate în totalitate.

Creşterea gradului de conştientizare a valorii dobândite prin analiza datelor într-un context geografic duce la dorinţa de a descoperi tipare şi relaţii bazate pe locaţie în Big Data care permit luarea de decizii informate pentru rezultate mai bune în afaceri.

Folosirea “Big Data” poate ajuta doctorii în alegerea corectă şi mai rapidă al tratamentului, pe baza informaţiilor colectate de către un alt personal medical. Pacienţii pot beneficia de un tratament mai adecvat şi la timp urmând să fie mai bine informaţi cu privire la furnizorii de servicii medicale. O utilizare inteligentă a “Big Data” poate gestiona mai bine fluxurile de trafic, ceea ce face oraşele noastre mai inteligente. Cetăţenii şi companiile pot economisi timp prin utilizarea de sisteme de planificare traseu. Big Data permite livrarea la timp şi adecvată a produselor pentru consumatori şi procese mai eficiente cu economii de costuri pentru afaceri.

Big Data Analytics reprezintă procese de examinare a unor cantităţi uriaşe de date de tipuri diferite, pentru a descoperi şabloane ascunse, neidentificate şi alte informaţii utile. Aceste informaţii pot furniza avantaje în competiţia dintre organizaţii şi pot produce beneficii economice, precum eficientizarea activităţilor specifice.

Tehnologiile legate de Big Data Analytics includ Hadoop, MapReduce şi bazele de date NoSQL. Aceste tehnologii constituie partea centrală a unui framework software de tip open-source, care facilitează procesarea unor seturi uriaşe de date stocate în sisteme clusterizate.

Potenţialele probleme pe care diversele tipuri de organizaţii le pot avea în legătură cu analiza volumelor mari de date au la bază lipsa competenţelor în acest domeniu a personalului intern şi costurile mari a angajării profesioniştilor în acest domeniu. Prin urmare, s-a constatat necesitatea lărgirii bazei de specialişti în acest domeniu prin programe de studiu dedicate.

Analiza volumelor mari de date, structurate sau nestructurate, pe lângă aplicarea unor tehnici specifice, impune şi folosirea unui calcul performant bazat pe programare paralelă şi distribuită.

2.2. Concepte conexe

2.2.1. Specialistul în date Fenomenul Big Data este strâns legat de apariţia şi consacrarea ştiinţei datelor, o

disciplină care combină matematica, programarea şi instinctul ştiinţific.



A beneficia de Big Data înseamnă a investi în echipe care acoperă un set de competenţe şi care se pot baza în activitatea lor pe interesul organizaţiei respective de a înţelege şi utiliza în scop lucrativ aceste date. Conform Raportului "Building Data Science Teams,” (http://www.oreilly.com/data/free/files/building-data-science-teams.pdf) specialiştii în ştiinţa datelor trebuie să aibă următoarele calităţi:

- expertiză tehnică: cei mai buni specialişti în domeniu au de obicei o experienţă avansată într-o disciplină ştiinţifică;

- curiozitate: dorinţa de a descoperi şi rafina o problemă într-un set foarte clar de ipoteze care pot fi testate;

- talent narativ: abilitatea de utilizare a datelor pentru a compune o poveste şi pentru a o putea comunica eficient;

- creativitate: capacitatea de a aborda o problemă în diferite moduri creative.

Principalele competenţe ale unui asemenea specialist se referă la:

• colaborare şi muncă în echipă, în relaţia cu părţile interesate, pentru înţelegerea problemelor de afaceri;

• abilităţi de analiză şi de modelare a deciziilor pentru descoperirea relaţiilor dintre date şi detectarea modelelor;

• abilităţi de management al datelor pentru construirea seturilor de date relevante, folosite pentru analiză.

Tematica instruirilor pentru specialiştii în ştiinţa datelor include:

• identificarea unor surse bogate de date ;

• lucrul cu volume mari de date în orice condiţii hardware, software, comunicaţii;

• curăţarea datelor şi asigurarea consistenţei lor;

• mixarea seturilor de date;

• vizualizarea datelor;

• construirea de instrumente care permit folosirea eficientă a datelor de către terţi.

2.2.2. Analiza Big Data „Big Data Analytics” (BDA) se ocupă cu managementul şi analiza datelor

multistructurate provenind în general de la surse din domeniul economic sau social: conţinut email, video, mesaje twitter, postări facebook şi alte tipuri de conţinut web. Datele generate de la senzori şi alte dispozitive conectate reprezintă o altă sursă neexplorată şi cu potenţialul de a furniza introspecţii care să sprijine funcţionarea şi dezvoltarea organizaţiilor din domeniul public sau privat.

Abordarea BDA se adresează provocărilor generate de două tendinţe evidente în procesarea datelor: ponderea tot mai mare a datelor nestructurate şi multistructurate generate de surse de date foarte prolifice şi larg răspândite (ca de ex. reţelele sociale, reţele de

http://www.oreilly.com/data/free/files/building-data-science-teams.pdf



senzori, Internetul obiectelor) şi decalajul tot mai mare dintre cantitatea disponibilă de date importante şi capacitatea de a le procesa în timp pentru suportul decizional.

Conform (Gartner, 2014) informaţiile neanalizate reprezintă resurse neutilizate. Reciproc, analiza care nu se sprijină pe un fundament solid de date poate duce la decizii de slabă calitate. Domeniul BDA reprezintă deci aplicarea capacităţilor analitice (descriptive, de diagnosticare, predictive, prescriptive) pe seturi de date mari, care sunt variate şi/sau care se modifică rapid. Aplicarea capacităţilor analitice în contextul Big Data, în special în combinaţie cu seturi de date tradiţionale (depozite de date, procesare analitică online - OLAP), a crescut semnificativ varietatea suportului decizional.

2.2.3. Date ascunse (dark data) Conform (Dayley, 2013) „dark data” reprezintă „activele de informare colectate,

procesate şi stocate de organizaţii în timpul activităţilor de afaceri, dar care în general nu pot fi folosite în alte scopuri (de exemplu analize, relaţii de afaceri, valorificare directă)“. Sunt „datele plătite pentru stocare, protejare şi gestionare, care nu au fost utilizate eficient pentru a îmbunătăţi creşterea valorii afacerii şi care prin conţinutul lor pot pune afacerea în pericol“.

Câteva dintre modalităţile de „elucidare” a acestor date sunt următoarele (CommVault, 2014):

a) Controlul volumului datelor: are la bază constatarea că 69% dintre datele stocate de companii nu au valoare pentru organizaţie. Utilizarea politicilor bazate pe reţinerea conţinutului va permite organizaţiei să păstreze doar datele importante pentru afacere.

b) Captarea datelor: datele trebuie colectate oriunde sunt create. Ideea este că datele produse pe dispozitivele mobile de ultimă generaţie pot include conţinut de valoare excepţională, la fel de mult ca şi informaţia stocată pe serverele virtualizate, în cloud corporativ.

c) Furnizarea accesului la cerere: angajaţii din cadrul organizaţiei găsesc valoare în diferite tipuri de date. Vânzările pot avea nevoie de informaţii pentru stabilirea preţurilor semestriale, în timp ce conducerea operativă poate avea nevoie de date cu privire la utilizarea facilităţilor, iar Resursele Umane de detalii privind satisfacţia la locul de muncă. Toate aceste date se află în informaţii arhivate, dar nu sunt utile până când nu sunt căutate şi găsite. Este mai uşor de a da utilizatorilor accesul pentru căutarea şi accesarea datelor de care au nevoie, decât să fie înfiinţat un departament de data mining a datelor în interiorul organizaţiei.

d) Automatizarea ciclului de viaţă al datelor: cu atât de mult conţinut stocat care nu este valoros afacerii, se ia în considerare evaluarea întregului ciclu de viaţă al datelor, de la creare până la disponibilizare. Stabilirea politicilor de guvernare a datelor pentru ştergerea conţinutului poate fi o cheie importantă în reducerea datelor ascunse (dark data).

e) Asigurarea conformităţii şi descoperirii: auditurile de conformitate şi litigiile sunt evenimente cu care companiile nu doresc să se confrunte, dar pentru care trebuie să se pregătească. Reglementările de conformitate se regăsesc peste tot (în industrie, în administraţie) şi organizaţiile înţeleg pericolul acţiunilor juridice luate împotriva lor. Cea



mai bună cale de a minimiza costul acestor acţiuni este de a fi proactiv în asigurarea unor facilităţi avansate de căutare şi descoperire a datelor.

2.3. Probleme specifice Big Data Prin valoarea pe care o conţin, Big Data sunt considerate o adevărată ”mină de aur”

pentru organizaţiile care le deţin. Infrastructura tradiţională TIC şi metodele de gestiune şi analiză a datelor sunt în continuare neadaptate principalelor probleme specifice ale domeniului, prezentate în continuare.

Viteza: sistemele de gestiune a bazelor de date relaţionale (RDBMS) utilizează în general metode de prelucrare şi stocare centralizate, care pot satisface cerinţele sistemelor de gestiune tradiţionale. Când se confruntă cu un volum tot mai mare de date şi scenarii dinamice de utilizare a lor, abordarea centralizată devine o piedică, în special datorită timpului de răspuns.

Arhitectura şi tipul datelor: RDBMS au dezvoltat modele mature pentru stocarea, interogarea şi prelucrarea datelor. Datele sunt structurate şi au modele fixe. Odată cu dezvoltarea rapidă a Internetului obiectelor şi a reţelelor de comunicaţie mobile, formatele şi tipurile de date se diversifică în mod constant. De aceea este necesară şi diversificarea modalităţilor de prelucrare, stocare şi integrare a unor date ale căror tipuri, surse şi structuri sunt diferite. Modelul general de management al datelor necesită noi tipuri sisteme şi arhitecturi distribuite pentru baze de date NoSQL, capabile a se adapta la volume mari de date şi structuri în schimbare.

Volum şi flexibilitate: în ceea ce priveşte stocarea datelor, trebuiesc adoptate o arhitecturi distribuite şi scalabile, cum ar fi bine cunoscutele soluţii Hadoop (http://hadoop.apache.org/) şi HBase (http://hbase.apache.org/). Pentru prelucrarea datelor trebuie adoptată, de asemenea, o arhitectură distribuită, cu luarea în considerare a corelării nodurilor de stocare a datelor şi a nodurilor de calcul. Identificarea resurselor adecvate pentru prelucrarea distribuită a datelor este o problemă complexă datorită diversităţii cerinţelor de calitate a serviciilor (QoS) ale utilizatorilor şi schimbării stării resurselor.

Costuri: în cazul soluţiei centralizate de prelucrare şi stocare a datelor, abordarea de bază constă în utilizarea unor unităţi de prelucrare puternice şi a unor sisteme de stocare de înaltă fiabilitate. Costurile componentelor hard în astfel de abordări sunt mari în raport cu posibilităţile unei întreprinderi.

Pe de altă parte, în contextul dezvoltării Big Data, se apreciază că noile soluţii distribuite – HDFS, HBase, Cassandra (http://cassandra.apache.org/), MongoDB (http://www.mongodb.org/) – sunt superioare abordării centralizate, pentru că folosesc o arhitectură descentralizată şi prelucrarea paralelă masivă. Aceste noi soluţii sunt în continuă dezvoltare şi sofisticare funcţională, iar politica de promovare este bazată pe open source.

Explorarea valorii: din cauza volumelor uriaşe şi în continuă creştere, densitatea valorii pe unitatea de date scade în mod constant, în timp ce valoarea totală a Big Data este în creştere (Labrinidis şi Jagadish, 2012). Dacă se doreşte extragerea de patern-uri din volume mari de date, este nevoie de o explorare a datelor în profunzime, diferit faţă de modelele



tradiţionale în care volumul datelor este relativ mic, algoritmii utilizaţi sunt de mare complexitate, iar convergenţa este lentă. În cazul Big Data, volumele masive de date şi procedeele specifice de stocare, curăţire şi ETL (extragere, transformare, încărcare) sugerează necesitatea utilizării modelelor de prelucrare paralelă şi distribuită.

Câştigul real al explorării datelor trebuie atent evaluat în cazul Big Data, luând în considerare:

- nevoia de garantare a autenticităţii şi completitudinii datelor; - costurile reflectate în investiţiile în forţa de muncă şi în infrastructura hard şi soft; - lungimea ciclului de realizare al proiectului; - beneficiile rezultate prin aportul informaţiei extrase la calitatea deciziilor adoptate în

întreprindere.

Securitate şi confidenţialitate: prevenirea pierderii datelor necesită mecanisme adecvate de back-up şi redundanţă, cu luarea în considerare a volumului de date structurate şi nestructurate. Protecţia datelor faţă de accesul neautorizat se confruntă cu diversitatea mecanismelor de stocare şi de acces în cazul unor volume masive de date nestructurate, ceea ce face necesară elaborarea unui mecanism unificat de control al accesului pentru multe surse multiple şi tipuri multiple de date. Problemele de confidenţialitate pentru Big Data apar în cazul colecţiilor de date care includ informaţii confidenţiale (ca de exemplu cele referitoare le comportamentul online al clienţilor). Scurgerile de asemenea informaţii sau utilizarea lor abuzivă reprezintă încălcări directe ale dreptului la intimitate pentru utilizatorii respectivi.

Interoperabilitate şi schimb de date: dacă ne referim cu titlu de exemplu la un proiect de tip “Smart City”, obiectivele sale fundamentale includ asigurarea interoperabilităţii şi a partajării informaţiilor, pentru valorificarea interconexiunilor logice între componentele proiectului prin acces deschis la date şi creşterea inteligenţei sistemului realizat.

În epoca Big Data şi cloud computing, datele provenite din diverse surse pot fi stocate pe o singură platformă / centru de date, unde protejarea informaţiei senzitive devine o problemă majoră, care necesită implementarea de soluţii eficiente pentru controlul accesului neautorizat al administratorilor platformei respective sau al reprezentanţilor altor întreprinderi care deţin date pe platforma respectivă.

2.4. Provocări ale Big Data Fenomenul inundării cu date, care caracterizează perioada curentă de afirmare a Big

Data, generează provocări imense pentru procesele de achiziţie, stocare, management şi analiză a datelor. Sistemele tradiţionale de management şi analiză a datelor se bazează pe sisteme de baze de date relaţionale (RDBMS), care se aplică doar datelor structurate şi folosesc tot mai frecvent componente hardware scumpe.

Comunitatea de cercetare a propus unele soluţii din perspective diferite. De exemplu, tehnologia cloud computing este folosită pentru îndeplinirea cerinţelor unei infrastructuri de tip Big Data, în ceea ce priveşte eficienţa costurilor, elasticitate, adaptare continuă la cerinţe prin extensie / restrângere.



Pentru soluţii de stocare pe termen lung managementul seturilor de date neordonate sunt recomandate sistemele de fişiere distribuite (Howard et al., 1988) şi bazele de date NoSQL (Cattell, 2011).

În ceea ce priveşte dezvoltarea de aplicaţii pentru Big Data, acestea pot fi dezvoltate pe baza tehnologiilor inovative sau a platformelor de programare, deşi trebuie luate în considerare o serie de dificultăţi, prezentate în continuare.

- Reprezentarea datelor: multe seturi de date se caracterizează prin niveluri diverse de eterogenitate a tipului, structurii, semanticii, organizării, granularităţii şi accesibilităţii datelor. Având în vedere că reprezentarea datelor urmăreşte să le pregătească pentru operaţiile de analiză şi interpretare pe calculator, o reprezentare necorespunzătoare va reduce valoarea datelor originale şi poate împiedica analiza lor eficientă.

- Reducerea redundanţei şi compresia datelor: în general, există un nivel înalt de redundanţă în seturile de date. Reducerea redundanţei, filtrarea şi compresia datelor sunt folosite la reducerea indirectă a costului prelucrării datelor în ipoteza că valoarea potenţială a acestora nu este afectată.

- Managementul ciclului de viaţă al datelor: în comparaţie cu progresele relativ lente ale sistemelor de stocare, reţelele de senzori omniprezente şi infrastructurile distribuite de calcul generează date într-un ritm şi la o scară fără precedent. Se apreciază că ar trebui formulat un principiu al importanţei datelor, care să reflecte valoarea lor analitică şi care să permită selectarea datelor care merită să fie stocate.

- Extensibilitate şi scalabilitate: sistemul analitic al Big Data trebuie să facă faţă unor cerinţe curente şi viitoare. Algoritmii de analiză trebuie să fie capabili să se adapteze unor seturi de date cu volum şi complexitatea structurii în continuă creştere.

- Cooperarea: analiza datelor de tip Big Data este o cercetare interdisciplinară, bazată pe cooperarea experţilor din diferite domenii. Se formulează necesitatea unei arhitecturi de reţea globală de Big Data pentru a sprijini oamenii de ştiinţă şi specialiştii din diverse domenii să acceseze diverse tipuri de date, să-şi folosească expertiza şi să coopereze pentru îndeplinirea diverselor obiective analitice.

- Mecanism analitic: sistemul de analiză al Big Data trebuie să prelucreze volume mari de date eterogene într-un timp limitat. RDBMS tradiţionale, caracterizate prin lipsă de scalabilitate şi extensibilitate, nu sunt adecvate. Bazele de date non-relaţionale şi-au demonstrat avantajele unice în prelucrarea datelor nestructurate şi sunt recunoscute ca soluţie viabilă în analiza Big Data, deşi există şi aici unele probleme de performanţă în cazul unor aplicaţii specifice. Este necesară o soluţie de compromis între RDBMS şi bazele de date non-relaţionale.



3. Arhitecturi, tehnologii şi seturi Big Data în sisteme informaţionale guvernamentale

3.1 Arhitecturi pentru sistemele Big Data Din cauza complexităţii sistemelor ”Big Data”, a fost necesară dezvoltarea unei

arhitecturi specializate. BDAF (Big Data Arhitecture Framework) are ca scop implementarea unei colecţii specifice de elemente de design, de a asigura o abordarea unui design consistent, de a reduce complexitatea sistemului, maximizarea reutilizării, legăturilor slabe (loose-coupling), reducerea dependenţelor şi creşterea productivităţii.

Pentru Big Data, cea mai frecventă arhitectură utilizată este Hadoop. Această inovaţie a redefinit managementul datelor, deoarece prelucrează cantităţi mari de date, cu costuri reduse şi în timp util.

3.1.1. Framework-ul Hadoop În tehnologia informaţiei, „Big Data” este o colecţie de seturi de date atât de mare şi

de complexă, încât devine incomodă pentru utilizarea uneltelor manuale de gestionare a bazelor de date. Atunci când lucrăm cu volume mari de date avem nevoie de o soluţie care să ne permită atât stocarea la un cost cât mai mic, dar şi să asigure o performanţă bună la procesare. Un posibil răspuns la această provocare este platforma de aplicaţii Apache Hadoop.

Hadoop (Hadoop, 2009) este un proiect open-source dezvoltat de Apache care îşi propune realizarea de procesări distribuite a unor seturi de date de dimensiuni mari, rulând pe mai multe clustere, folosind modele de programare simple. Proiectarea acestui framework a fost realizată astfel încât să fie scalabilă chiar şi în situaţia în care sarcinile sunt rulate pe mii de calculatoare, fiecare dintre acestea punând la dispoziţie o anumită capacitate de procesare şi de stocare.

Începând cu anul 2010, Hadoop a fost adoptat pe scară largă de organizaţii atât în scopul de a stoca volume mari de date cât şi ca platformă de analiză a acestora. În prezent, Hadoop este folosit de numeroase companii pentru care volumul de date generat zilnic depăşeşte capacităţile de procesare şi stocare specifice sistemelor convenţionale: Adobe, AOL, Amazon.com, EBay, Facebook, Google, LinkedIn, Twitter, Yahoo.

Apache Hadoop este un ecosistem de unelte gândite pentru a funcţiona împreună ca o soluţie eficientă de stocare şi procesare a datelor. Aceste unelte sunt dezvoltate de către o comunitate diversificată de dezvoltatori într-un mod colaborativ sub umbrela Apache Software Foundation.

Nucleul Apache Hadoop este format din două componente: un sistem de fişiere distribuit (HDFS – Hadoop Distributed File System) şi un framework pentru procesare distribuită (MapReduce). Hadoop a fost gândit să funcţioneze într-o arhitectură de tip cluster construită pe echipamente server obişnuite.

Dat fiind faptul că datele sunt stocate distribuit, locaţia unde acestea pot să fie accesate nu este cunoscută aprioric, fiind determinată de Hadoop (HDFS). Fiecare bloc de



informaţie este copiat pe mai multe maşini fizice pentru a evita orice probleme cauzate de defecţiuni la nivel hardware.

Framework-ul Hadoop include mai multe module:

Hadoop Common: utilitare de bază care oferă funcţionalităţile pentru celelalte module;

Hadoop Distributed File System (HDFS): sistem de fişiere distribuite ce pune la dispoziţie un nivel de disponibilitate ridicat la datele utilizate de aplicaţii;

Hadoop YARN: modul pentru planificarea sarcinilor şi gestiunea resurselor din cadrul unui cluster;

Hadoop MapReduce: sistem bazat pe YARN pentru procesarea paralelă a unor seturi mari de date.

În plus, au fost dezvoltate mai multe produse open source care pot fi folosite împreună cu Hadoop / HDFS:

HBase: bază de date distribuită, scalabilă care suportă stocarea informaţiilor structurate pentru tabele de dimensiuni mari; implementată sub forma unor perechi cheie-valoare, foloseşte de obicei sistemul de fişiere distribuit HDFS deşi poate fi folosit şi împreună cu sistemul de fişiere local;

ZooKeeper: serviciu de coordonare performant pentru aplicaţii distribuite;

Oozie: modulul pentru gestiunea şi planificarea fluxurilor, coordonând fluxurile MapReduce;

Pig: limbaj de nivel înalt pentru procesarea fluxurilor de date şi mediu de execuţie pentru prelucrări paralele;

Hive: depozit de date cu interfaţă SQL care oferă sumarizarea datelor şi interogări ad-hoc.

Există mai mulţi producători care pun la dispoziţie distribuţii Hadoop, al căror scop este oferirea unei configuraţii care rezolvă incompatibilităţile dintre diferite produse, prin rularea unor teste de integrare între acestea.

Produsele Hadoop integrate în cele mai multe dintre distribuţii sunt HDFS, MapReduce, HBase, Hive, Mahout, Oozie, Pig, Sqoop, Whirr, ZooKeeper, Flume. De asemenea, proiectul BigTop (dezvoltat de Apache) are rolul de a rula teste de interoperabilitate între componentele Hadoop oferind pachete Linux (RPM şi pachete Debian) pentru o instalare mai facilă.

Distribuţiile sunt realizate în mai multe formate, suportă un set de sisteme de operare şi pot include scripturi suplimentare pentru rularea mediului de lucru.

Între distribuţiile mai cunoscute se numără Cloudera Distribution for Hadoop (CDH), MapR Distribution, Hortonworks Data Platform (HDP), Apache BigTop Distribution,



Greenplum HD Data Computing Appliance. Acestea dispun şi de propriile documentaţii (inclusiv wiki) şi oferă utilizatorilor maşini virtuale pe care sunt instalate distribuţiile în cauză.

Hadoop este folosit de aproximativ 63% de organizaţii pentru a gestiona un număr mare de înregistrări şi evenimente nestructurate. Hadoop poate procesa volume extrem de mari de date cu structuri diferite (sau nestructurate) (Khan, Yaqoob şi alţii, 2014).

Arhitectura Hadoop

Hadoop a fost gândit să funcţioneze într-o arhitectură de tip cluster (vezi Figura 1) construită pe echipamente server obişnuite. După instalare necesită foarte puţină muncă de management deoarece datele sunt migrate şi multiplicate automat. Dat fiind faptul că datele sunt stocate distribuit, locaţia unde acestea pot fi accesate nu este cunoscută aprioric, fiind determinată de Hadoop (HDFS). Fiecare bloc de informaţie este copiat pe mai multe maşini fizice pentru a evita orice probleme cauzate de defecţiuni la nivel hardware.

În continuare este prezentată o arhitectură de nivel înalt (vezi Figura 1) a clusterului Hadoop multi-nod (Sindol, 2014).

Figura 1. Arhitectura de nivel înalt de cluster Hadoop multi-nod

Principalele aspecte mai importante ale arhitecturii Hadoop sunt următoarele:

Hadoop are două componente de bază: HDFS şi MapReduce

HDFS (Hadoop Distributed File System) oferă o stocare extrem de fiabilă şi distribuită, prin replicarea datelor pe mai multe noduri. Spre deosebire de un sistem de fişiere obişnuit, atunci când datele sunt trimise la HDFS, acestea se vor împărţi în mod automat în mai multe blocuri (parametru configurabil) şi depozitează datele în diferite „DataNodes”. Acest lucru asigură disponibilitate ridicată şi toleranţă la erori.

MapReduce oferă un sistem de analiză care poate efectua calcule complexe, pe seturi de date de dimensiuni mari. Această componentă este responsabilă de efectuarea calculelor şi de împărţirea unui calcul de complexitate ridicată în mai multe task-uri,



atribuirea lor la nodurile individuale slave, precum şi coordonarea şi consolidarea rezultatelor.

Hadoop funcţionează într-o manieră master / slave (vezi Figura 2.)

Master-ul conţine componente NameNode şi JobTracker.

o NameNode deţine informaţii referitoare la toate celelalte noduri din Clusterul Hadoop, fişierele prezente în cluster, blocurile constitutive ale fişierelor şi locaţiile lor în cluster şi alte informaţii utile pentru funcţionarea Clusterului Hadoop.

o JobTracker ţine evidenţa task-urilor individuale / Job-urile alocate pentru fiecare dintre noduri şi coordonează schimbul de informaţii şi rezultate.

Fiecare Master / Slave conţine TaskTracker şi componente DataNode.

o TaskTracker este responsabil pentru rulare task / calcul atribuit.

o DataNode este responsabil de deţinerea datelor.

Calculatoarele prezente în cluster pot fi prezente în orice locaţie şi nu depind de locaţia serverului fizic.

Figura 2. Un cluster multi-nod Hadoop

Dacă analizăm arhitectura unui astfel de sistem este necesar să introducem în vocabularul nostru doi termeni: NameNode şi DataNode.

NameNode este master-ul sistemului de stocare. Acesta se ocupă de sistemul de stocarea a numelui fiecărui fişier şi ştie unde poate să fie găsit - maparea fişierelor. Acest sistem nu stochează datele din fişiere, el ocupându-se doar cu maparea fişierelor, ştiind în fiecare moment locaţie unde aceste sunt stocate. Odată ce numele a fost rezolvat de către NameNode, acesta va redirecta clienţii spre DataNode-uri.

DataNode reprezintă "slave-urile" care stochează conţinutul propriu zis al fişierului. Clienţii vor accesa DataNode pentru a putea accesa informaţia stocată - scriere şi citire a datelor.



Un cluster Hadoop de dimensiuni reduse va conţine un singur nod cu rol de comandă şi mai multe noduri subordonate. Nodul cu rol de comandă include JobTracker, TaskTracker, NameNode şi DataNode. Un nod subordonat sau cu rol de execuţie îndeplineşte funcţiile specifice atât pentru DataNode cât şi pentru TaskTracker. Există de asemenea posibilitatea de a dispune şi de noduri cu rol de execuţie specializate exclusiv pe stocarea informaţiilor sau pe realizarea de operaţii. Categoriile acestea de noduri sunt utilizate exclusiv în aplicaţii nestandardizate.

Într-un cluster mai mare, controlul asupra HDFS se execută printr-un server dedicat NameNode, care stochează indexul sistemului de fişiere şi printr-un NameNode secundar, care poate genera instantanee ale structurilor de memorie cu numele nodurilor, prevenind astfel coruperea sistemului de fişiere şi reducând pierderea informaţiilor. În mod similar, un server JobTracker independent poate executa controlul asupra planificării activităţilor.

Caracteristicile Hadoop

Principalele caracteristicile ale framework-ului Hadoop sunt:

• Hadoop oferă o stocare sigură comună (HDFS) şi un sistem de analiză (MapReduce).

• Hadoop este foarte scalabil şi, spre deosebire de bazele de date relaţionale, Hadoop este scalat linear. Datorită scalei lineare, Hadoop Cluster poate conţine zeci, sute, sau chiar mii de servere.

• Arhitectura Hadoop este foarte rentabilă, deoarece poate lucra cu hardware-ul de bază şi nu are nevoie de hardware scump.

• Hadoop este extrem de flexibil şi poate procesa atât date structurate, cât şi nestructurate.

• Hadoop este construit cu toleranţă la erori. Datele sunt replicate pe mai multe noduri (factorul de replicare este configurabil) şi, în cazul în care un nod se defectează, datele solicitate pot fi citite de la un alt nod care are o copie a datelor. De asemenea, se asigură faptul că factorul de replicare este menţinut, chiar dacă un nod se defectează, prin replicarea datelor altor noduri disponibile.

• Hadoop este optimizat pentru seturi mari şi foarte mari de date. De aceea, o cantitate mică de date, cum ar fi 10 MB, atunci când alimentează Hadoop, are nevoie de mai mult timp pentru a procesa decât sistemele tradiţionale.

Componentele HADOOP

Apache Hadoop este un ecosistem de unelte gândite pentru a funcţiona împreună ca o soluţie eficientă de stocare şi procesare a datelor.

Nucleul Apache Hadoop este format din două componente: un sistem de fişiere distribuit (HDFS – Hadoop Distributed File System) şi un framework pentru procesare distribuită (MapReduce).



Spre deosebire de sistemele tradiţionale, Apache Hadoop oferă un set limitat de funcţionalităţi pentru procesarea datelor (MapReduce), dar are proprietatea de a deveni din ce în ce mai performant şi poate să ofere o capacitate mai mare de stocare pe măsură ce este instalat pe mai multe maşini fizice.

O procesare de tip MapReduce presupune că problema care trebuie rezolvată poate să fie împărţită în probleme mai mici care pot să fie rezolvate independent (faza de map), într-o manieră “divide et impera”, fiecare fiind executată cât mai aproape de datele pe care trebuie să opereze urmând ca apoi rezultatele să fie reunite în funcţie de necesităţi (faza de reduce).

Figura 3 ilustrează ecosistemul Hadoop, precum şi relaţia dintre diferitele componente (Khan, Yaqoob şi alţii, 2014).

Figura 3. Ecosistemul Hadoop

Scurtă descriere a componentelor

• HDFS este un sistem de fişiere distribuit implementat în cadrul Hadoop, diferenţa faţă de alte sisteme de fişiere de acest tip constând în faptul că este proiectat să ruleze pe dispozitive mai puţin performante, fiind capabil să gestioneze în mod coerent erorile. Rulează fără probleme pe configuraţii normale, putând fi folosit împreună cu calculatoarele pe care le avem acasă sau la birou. De asemenea, oferă un nivel de accesibilitate ridicat la datele aplicaţiei, fiind adecvat pentru aplicaţii care utilizează un volum de date de dimensiuni foarte mari.

HDFS este mult mai complex decât alte sisteme de fişiere, având în vedere complexitatea şi incertitudinea reţelelor. Clusterul conţine două tipuri de noduri. Primul nod este un NameNode, care acţionează ca un nod principal. Al doilea tip de nod este un nod de date (DataNode) care se comportă ca nod secundar. Acest tip de nod vine în multipli. În afară de aceste două tipuri de noduri, HDFS poate avea şi NameNode secundar. HDFS stochează fişierele în blocuri, mărimea blocului implicit este de 64MB. Toate fişierele HDFS se repeta în multipli pentru a facilita procesarea în paralel a unor cantităţi mari de date.

Arhitectura HDFS (vezi Figura 4) este de tip master / slave şi conţine un nod de nume (eng. NameNode), server ce gestionează spaţiul de nume al sistemului de fişiere, reglementând accesul la fişiere şi mai multe noduri de date (eng. DataNode, de regulă unul pentru fiecare nod din cluster), client ce gestionează spaţiul de stocare ataşat



nodurilor pe care rulează. În plus faţă de acestea mai există şi un nod de nume secundar (eng. Secondary NameNode) care se ocupă mai ales cu întreţinerea sistemului distribuit de fişiere, astfel încât acest proces să nu fie realizat doar la nivelul nodului de nume. Acesta nu este utilizat pentru asigurarea unui nivel de disponibilitate ridicat şi nici nu funcţionează ca rezervă pentru nodul de nume. Deşi pentru utilizator spaţiul de nume este vizualizat unitar, permiţând operaţiile uzuale de încărcare şi descărcare de fişiere (ca pentru orice sistem de fişiere), implementarea HDFS presupune împărţirea acestora în blocuri care sunt stocate în mai multe noduri de date. Dacă nodul de nume se ocupă cu operaţii legate de spaţiul de nume al sistemului de fişiere (deschidere, închidere, redenumire fişiere şi directoare), determinând şi maparea blocurilor la nodurile de date, nodurile de date au rolul de a trata cererile de citire şi de scriere ce provin de la utilizatori, realizând şi crearea şi ştergerea de blocuri, respectiv replicarea, în funcţie de instrucţiunile ce provin de la nodul de nume.

Figura 4. Arhitectura HDFS de tip master / slave

Atât nodul de nume cât şi nodul de date sunt programe scrise în Java, astfel încât pot să ruleze pe cât mai multe platforme. Tipic, nodul de nume rulează pe un server dedicat, în timp ce toate celelalte maşini din cluster conţin o instanţă a nodului de date. Există şi posibilitatea ca pe o singură maşină să existe mai multe instanţe ale nodului de date, însă un astfel de caz este destul de rar. Situaţii de acest tip pot fi întâlnite în situaţia în care se doreşte separarea seturilor de date provenind de la aplicaţii diferite. Existenţa unui singur nod de nume într-un cluster simplifică foarte mult arhitectura sistemului, întrucât nodul de nume negociază utilizarea resurselor şi reţine toate metadatele cu privire la fişierele stocate. Toate datele provenite de la utilizator sunt prelucrate neapărat de nodul de date.

Aşadar, arhitectura HDFS este organizată pe două niveluri (vezi Figura 5):

1. spaţiul de nume, în care este reţinută structura logică a sistemului de fişiere, constând în directoare, fişiere şi blocuri;



2. serviciul de stocare a blocurilor, format la rândul său din 2 componente:

a. gestiunea blocurilor (implementată în nodul de nume) realizată prin stabilirea apartenenţei unui nod de date la cluster prin tratarea operaţiilor de înregistrare şi a mesajelor transmise periodic, procesarea rapoartelor cu privire la blocuri şi întreţinerea locaţiei la care sunt stocate acestea, implementarea operaţiilor legate de blocuri (creare, modificare, ştergere şi obţinerea locaţiei), gestiunea plasării replicilor (replicarea blocurilor pentru care nu este întrunit factorul de replicare şi ştergerea blocurilor pentru care este depăşit factorul de replicare);

b. stocarea – oferită de nodurile de date prin stocarea blocurilor în cadrul sistemului local de fişiere, permiţând accesul la operaţii de citire/scriere.

Figura 5. Arhitectura HDFS pe două niveluri

În mod tradiţional, HDFS implementează o organizare a fişierelor de tip ierarhic, astfel încât un utilizator sau o aplicaţie pot crea directoare, stocând fişiere în cadrul acestora. Operaţiile suportate sunt de creare şi ştergere fişiere, relocarea unui fişier dintr-un director într-altul precum şi redenumirea unui fişier. Nu sunt implementate cote pentru utilizatori şi permisiuni de acces, dar nici obiecte de tip legătură (hard sau soft). Întreţinerea spaţiului de nume pentru sistemul distribuit de fişiere este realizat de către nodul de nume astfel că acesta înregistrează orice schimbare operată asupra sa sau proprietăţilor sale.

HDFS este proiectat pentru a stoca fişiere de dimensiuni foarte mari distribuite pe maşini în cadrul unui cluster ce conţine numeroase maşini. Astfel, fiecare fişier este reţinut ca o secvenţă de blocuri, de dimensiuni egale, fiecare dintre acestea fiind replicate pentru asigurarea toleranţei în cazul producerii de erori.

Accesul la HDFS se poate face direct, prin intermediul unui client, disponibil inclusiv din browser, fie prin intermediul unor interfeţe de programare (Java, C++) care obţin metadatele de la nodul de nume (locaţia blocurilor), accesând apoi informaţiile din nodurile de date. Un astfel de model este utilizat inclusiv de MapReduce. Alternativ, comunicaţia dintre clienţi şi HDFS poate fi realizată printr-un server intermediar (eng. proxy), dintre cele care sunt livrate împreună cu Hadoop.

• MapReduce sistem bazat pe YARN pentru procesarea paralelă a unor seturi mari de date.



MapReduce reprezintă un model de programare destinat procesării de date pe un număr foarte mare de noduri, reprezentate de maşini disponibile în comerţ, fără performanţe deosebite (eng. commodity hardware). Este inspirat din programarea funcţională de unde sunt preluate funcţiile map şi reduce, putând fi implementat în limbaje de programare ca Java, C++, Python sau Ruby. Un astfel de model (vezi Figura 6) este util mai ales pentru prelucrarea unor seturi de date (semistructurate şi orientate pe înregistrări) de dimensiuni foarte mari utilizat în special pentru procesarea distribuită în cadrul unor clustere de calculatoare. Aplicaţia este împărţită în fragmente mici singura soluţie pentru obţinerea unor rezultate într-un interval de timp acceptabil, fiecare putând fi executat sau reexecutat pe orice nod din cluster.

Figura 6. Model de procesare MapReduce

MapReduce se bazează pe împărţirea procesării în 2 etape: map şi reduce, fiecare primind ca date de intrare o pereche cheie-valoare (al căror tipuri poate fi stabilită de programator) şi întorcând ca rezultat tot o pereche cheie-valoare.

Valorile care sunt procesate de programul MapReduce sunt partiţionate în funcţie de cheile care le caracterizează şi distribuite nodurilor care aplică funcţia de mapare, în urma căreia se generează o listă (intermediară) de valori, fiecare dintre ele având asociată şi o cheie. Acestea sunt sortate şi grupate în funcţie de cheie (toate valorile care au aceeaşi cheie sunt concatenate într-o singură listă), astfel încât funcţia de reducere primeşte mai puţine perechi cheie-valoare (pentru fiecare cheie unică există o listă de valori generate anterior) obţinându-se o listă de rezultate compusă din perechi chei-valoare.

În cazul implementării MapReduce “clasice” sunt implicate mai multe entităţi:

clientul, care transmite sarcina de tip MapReduce;

un proces pentru monitorizarea sarcinii (eng. Job Tracker) care coordonează rularea acesteia;

mai multe procese pentru monitorizarea părţilor în care a fost împărţită sarcina (eng. Task Tracker);

sistemul distribuit de fişiere (de obicei HDFS), utilizat pentru partajarea fişierelor între aceste entităţi.



Entităţile implicate la rularea unei aplicaţii de tip MapReduce folosind YARN sunt:

clientul, care transmite sarcina de tip MapReduce;

procesul pentru gestiunea resurselor (eng. Resource Manager) care coordonează alocarea resurselor de procesare pe cluster;

procesele pentru gestiunea nodurilor (eng. Node Manager) care lansează în execuţie şi monitorizează containerele în cadrul maşinilor din cluster;

procesul de gestiune a aplicaţiilor (eng. Application Master) care va coordona partiţiile sarcinilor.

Figura 7 prezintă arhitectura sistem MapReduce şi HDFS pentru un cluster mare. (Azzini, Ceravolo, 2013), (O’Driscoll, Daugelaite, Sleator, 2013).

Figura 7. Arhitectura sistem MapReduce şi HDFS pentru un cluster mare

MapReduce este componenta principală a arhitecturii Hadoop şi o paradigmă de programare care permite scalabilitatea peste numeroase servere într-un cluster Hadoop. Pentru a îmbunătăţi performanţa, MapReduce atribuie volumul de muncă la serverele în care sunt stocate datele prelucrate. Prelucrare datelor este programată pe baza nodurilor clusterului. Unui nod îi poate fi atribuit şi un task ce necesită date străine de acel nod.

Componentei MapReduce îi corespund două task-uri distincte efectuate de programele Hadoop. Primul task este legat de funcţia map şi implică obţinerea unui set de date şi transformarea într-un alt set de date. În aceste seturi de date, componentele individuale sunt împărţite în seturi de variabile (perechi de chei / valori). Task-ul de reducere primeşte ca intrări, ieşirile de la task-urile map şi apoi împarte aceste seturi de variabile în seturi mai mici. Prin urmare, task-ul de reducere este efectuat întotdeauna după task-ul de map. Tabelul 1 prezintă pas cu pas task-urile MapReduce.

Tabelul 1. Task-urile MapReduce

Paşi Task-uri (1) Intrare (i) Datele sunt încărcate în HDFS în blocuri şi distribuite la

DataNode (ii) Blocurile sunt replicate în caz de defecţiuni (iii) NameNode urmăreşte blocurile şi DataNode

(2) Job Trimite job-ul şi detaliile sale la JobTracker



(3) Iniţializare job (i) JobTracker-ul interacţionează cu TaskTracker-ul în fiecare nod (ii) Toate task-urile sunt programate

(4) Mapare (i) Task-ul de mapare prelucrează blocurile de date (ii) Sunt listate perechile de valorile cheie

(5) Sortare Task-ul de mapare sortează lista perechilor de valori-cheie (6) Amestecare (i) Ieşirea mapată este transferată la task-ul de reducere

(ii) Valorile sunt rearanjate într-un format sortat (7) Reducere Task-ul de reducere reuneşte lista de perechi de valori-

cheie pentru a genera rezultatul final (8) Rezultat (i) Valorile sunt stocate în HDFS

(ii) Rezultatele sunt replicate conform configuraţiei (iii) Clienţii citesc rezultatele din HDFS

Datele redundante sunt stocate în mai multe zone din cluster. Modelul de programare rezolvă automat disfuncţionalităţile prin rularea de porţiuni ale programului pe diverse servere din cluster. Datele pot fi distribuite de-a lungul unui cluster foarte mare de componente împreună cu programarea asociată, oferită de redundanţa datelor. Această redundanţă tolerează defecte şi permite clusterului Hadoop să se repare, în cazul în care componenta hardware eşuează, având în vedere cantitatea mare de date. Figura 8 prezintă arhitectura MapReduce.

Figura 8. Arhitectura MapReduce

HBase este o bază de date distribuită de tip NoSQL, orientată pe coloane având la baza modelul Google BigTable, care foloseşte ca şi mediu de stocare HDFS, fiind utilizată în cazul aplicaţiilor Hadoop care necesită operaţii de citire / scriere aleatoare în seturi de date foarte mari. Este scris în Java şi poate fi accesat atât prin intermediul unui client propriu cât şi prin intermediul unui API foarte simplu.

HBase a fost creat pentru a preîntâmpina problema scalabilităţii în situaţia creşterii dimensiunii informaţiilor care trebuie stocate prin adăugarea de noduri. Nefiind o bază de date relaţională şi nefiind bazată pe SQL, este capabilă să ofere găzduirea unor tabele de dimensiuni mari, populate în mod inegal, pe clustere formate din maşini larg disponibile în comerţ, fără performanţe deosebite.

HBase reprezintă însă o soluţie pentru seturi de informaţii de dimensiuni foarte mari (de ordinul milioanelor şi miliardelor de înregistrări) sau pentru aplicaţii ce utilizează date care sunt accesate de foarte mulţi clienţi (cererile şi răspunsurile generate ca urmare a acestei interacţiuni implică un volum de date foarte mare). Totodată, funcţionează optim



în cazul unor scheme variabile, unde structura înregistrărilor diferă (datorită unor atribute care pot să existe sau nu).

HBase are trei componente principale:

1. biblioteca clientului;

2. un server de tip master;

3. mai multe servere de regiune.

Dacă serverele de regiune pot fi adăugate sau şterse în timpul funcţionării sistemului de gestiune pentru baze de date distribuite în funcţie de încărcarea acestuia, serverul de tip master este responsabil pentru repartizarea regiunilor către serverele aferente, folosind în acest sens un produs denumit Apache ZooKeeper, un serviciu de coordonare sigur, persistent, care oferă tuturor utilizatorilor un nivel înalt de disponibilitate.

• Zookeeper este un serviciu de coordonare pentru aplicaţiile distribuite. Zookeeper menţine, configurează şi denumeşte cantităţi mari de date. De asemenea, furnizează servicii distribuite de sincronizare şi de grup. Singur, Zookeeper conţine noduri master şi slave şi stochează informaţii de configurare.

• HCatalog stochează metadate şi generează tabele pentru cantităţi mari de date. HCatalog simplifică comunicarea utilizator folosind datele HDFS şi este o sursă de partajare a datelor între instrumente şi platformele de execuţie.

• Hive este o platformă de depozitarea datelor (de tip data warehouse) care permite interogarea şi gestionarea seturilor de date de mari dimensiuni din depozite distribuite, stocate în HDFS. Hive este o sub-platformă în ecosistemul Hadoop şi foloseşte un limbaj de interogare de tipul SQL, care este numit HiveQL. Limbajul, de asemenea, permite programatorilor tradiţionali ai MapReduce să se conecteze la mediul lor specific de interogare şi de reducere atunci când este incomod sau ineficient. Astfel, acest limbaj permite şi funcţii definite de utilizator (UDF-uri - user-defined functions). Platforma Hive se bazează în principal pe trei structuri de date conexe: tabele, partiţii şi „buckets”. Tabelele corespund directoarelor HDFS şi pot fi distribuite în diferite partiţii şi eventual, buckets-uri.

• Pig este o platformă de nivel înalt folosită pentru analizarea unor seturi de date mari având un limbaj propriu, pentru descrierea programelor de analiză a datelor. Caracteristica principală a Pig este că prin natura programelor Pig, permite paralelizarea lor la momentul rulării. Compilatorul Pig produce joburi MapReduce. Arhitectura Pig generează un limbaj de scripting de nivel înalt (Pig Latin) şi operează pe o platformă în timp real, platformă care permite utilizatorilor să execute MapReduce pe Hadoop. Pig este mai flexibil decât Hive referitor la formatul datelor, furnizând propriul model de date. Pig are propriul tip de date, hartă, care reprezintă datele semistructurate, inclusiv JSON şi XML.

• Mahout este o bibliotecă pentru algoritmi de învăţare automată (machine-learning) şi ”data mining”, incluzând algoritmi de clasificare şi de clustering. Mulţi algoritmi sunt



scrişi pentru compatibilitate cu MapReduce, astfel încât ei sunt scalabili la seturi de date mari. Această componentă este împărţită în patru grupe principale: filtrare colectivă, clasificare, clustering şi extragere de modele paralele frecvente (mining of parallel frequent patterns). Biblioteca Mahout aparţine de subsetul care poate fi executat într-o mod distribuit şi de către MapReduce.

• Oozie este un instrument pentru managementul workflow-ului /coordonarea joburilor MapReduce. Apache Oozie permite combinarea mai multor elemente într-o unitate logică de lucru. Apache Oozie este o aplicaţie Java Web, care rulează într-un servlet Java Tomcat şi foloseşte o bază de date pentru a stoca:

o Definiţii ale fluxului de lucru o Execuţii curente ale fluxului de lucru

Oozie permite definirea folosind fişiere XML de fluxuri complexe în cadrul unui cluster Hadoop. Oozie este o colecţie de acţiuni, dispuse într-un control de dependenţă DAG (Direct Aciclic Graphic), specificând o secvenţă de acţiuni ce trebuie executate. Acest grafic (secvenţă de acţiuni) este specificat în limbajul hPDL (limbaj de tip XML). Nodurile de control definesc fluxul de execuţie şi sunt începutul şi sfârşitul unui flux de lucru şi mecanismele pentru a controla calea executării fluxului de lucru. Nodurile de acţiune sunt mecanismul prin care un flux de lucru declanşează executarea unei sarcini de calcul sau prelucrare.

• Avro. Avro serializează datele, conduce apelurile de proceduri la distanţă şi transferă datele de la un program sau limbaj la altul. În această arhitectură, datele se auto-descriu şi sunt întotdeauna stocate în funcţie de propria lor schemă, deoarece aceste calităţi sunt potrivite limbajelor de scripting, cum ar fi Pig.

• Chukwa este un tool pentru monitorizarea aplicaţiilor distribuite, bazându-se pe arhitectura HDFS şi MapReduce. Chukwa este o arhitectură pentru colectarea şi analiza datelor. Chukwa colectează şi prelucrează datele din sistemele distribuite şi le stochează în Hadoop.

• Flume este un serviciu distribuit care permite colectarea, agregarea şi mutarea unor volume mari de date tip log. Are o arhitectură bazată pe fluxuri de date şi care permite construirea de aplicaţii analitice. Componenta foloseşte două canale, şi anume, surse şi colectoare (sinks). Sursele includ date Avro, fişiere şi fişierele jurnal (log) de sistem, în timp ce sinks fac referire la HDFS şi HBase. Prin motorul său personal de prelucrare, interogare, Flume transformă fiecare nou batch de Big Data înainte de a fi transportaţi în sink.

În tabelul 2 sunt sintetizate funcţionalităţile diferitelor componente Hadoop discutate mai sus.

Tabelul 2. Componentele Hadoop şi funcţionalităţile lor

Componentă Hadoop Funcţii (1) HDFS Depozitare şi replicare (2) MapReduce Prelucrare distribuită şi toleranţă la erori



(3) HBASE Acces rapid la citire/scriere (4) HCatalog Metadate (5) Pig Scripting (6) Hive SQL (7) Oozie Flux de lucru şi planificare (8) ZooKeeper Coordonare (9) Kafka Mesagerie şi date de integrare (10) Mahout Machine-learning

Cu Hadoop, 94% din utilizatori pot analiza cantităţi mari de date. 88% dintre

utilizatori analizează datele în detaliu, iar 82% pot păstra mai multe date. Deşi Hadoop are diverse componente (vezi Tabelul 2), fiecare companie utilizează anumite componente ale Hadoop în funcţie de necesităţile lor.

3.1.2. Integrare Big Data cu Hadoop

Arhitectura de Big Data nu este una fixă, care să se potrivească în toate situaţiile. Fiecare strat de procesare în arhitectură are mai multe soluţii şi tehnici care pot fi implementate pentru a crea un mediu robust. Fiecare soluţie are propriile avantaje şi dezavantaje pentru un anumit volum de muncă.

În general orice arhitectură de date se compune din patru componente logice principale (Anuganti, 2012), aşa cum se poate observa şi în Figura 9:

Figura 9. Arhitectura Big Data

Aceste componente sunt:

http://cdn.venublog.com/wp-content/uploads/2012/11/bigdata-scalein-architecture.png

http://cdn.venublog.com/wp-content/uploads/2012/11/bigdata-scalein-architecture.png�



1. Sursele de date

Datele provin din surse de date eterogene. De obicei, acestea sunt depozite de date (SQL sau NoSQL), care oferă date structurate sau orice alte tipuri de date provenite prin intermediul API-urilor sau a altor mijloace (semi-structurate sau ne-structurate):

• Date din SQL, depozite NoSQL (MySQL, Oracle, PostgreSQL, MongoDB, etc. – sunt în cea mai mare parte structurate),

• Date (semi/ne)-structurate (CRM, comercializare, campanii, cheltuieli, venituri, conducere etc.),

• Jurnale web sau alte fişiere jurnal (blogurile, clicurile utilizatorilor, vizitele utilizatorilor, acţiuni etc.).

2. Transformarea datelor

Transformarea datelor dintr-o formă în alta, se realizează fie cu ETL (Extract, Transform and Load - Extracţie, Transformare şi Încărcare), fie cu instrumente şi/sau scripturi de import/export. În principal, această transformare este folosită pentru a încărca toate sursele de date în fluxul de prelucrare al datelor.

ETL este un proces în utilizarea bazei de date şi în special în depozite de date care implică:

- extragerea datelor din surse externe;

- transformarea lor pentru a se potrivi necesităţilor operaţionale;

- încărcarea datelor în obiectivul final (baze de date sau depozit de date).

Instrumente de management a înregistrărilor pot fi, de asemenea, considerate ca făcând parte din ETL, deoarece acestea generează evenimente utile din fişierele de jurnal şi prezintă tabloul de bord pe sistemul de alertare local sau pot fi încărcate direct în depozite de prelucrare a datelor.

• Instrumente ETL, ELTL (scripturi bash / python / perl / Java, obiecte de business, SSIS, Kettle etc.);

• SQOOP (Instrument de transformare a datelor sursă în date pentru Hadoop, compatibil JDBC);

• Instrumente de import / export (instrumente specifice furnizorilor SQL / NoSQL);

• Instrumente de management a înregistrărilor (log-urilor) (Splunk, Syslog, script-uri de filtrare jurnal personalizat etc.).

3. Prelucrarea datelor sau integrarea datelor

O altă sursă de date se obţine prin combinarea datelor structurate şi nestructurate într-un singur loc (fie în timp real, fie cu încărcare incrementală), în principal, pentru prelucrarea



datelor (Depozite de date sau Analiza datelor) şi pentru generarea datelor utilizabile (materializate sau agregate), care pot fi cerute de către componentele de cereri de date.

• Hadoop şi ecosistemul (Hadoop / HDFS, Map-reduce, HBase, Hive, Impala, Pig etc.) – foloseşte HDFS ca mediu iniţial de stocare;

• Depozite de date şi Analiza soluţiilor (MySQL, SQL Server, Vertica, Green Plum, Aster data, Exadata, SAP HANA, IBM Netezza, IBM Pure Data, Tera date etc.) –utilizează depozitarea specifică furnizorului, foloseşte opţional HDFS.

• Analiza în memorie (SAS, Kognitio, Druid etc.) - citesc direct de la HDFS.

4. Cereri de date

Componentele pentru cereri de date fie cer, fie expun datele într-o formă utilizabilă de către utilizatorii finali sau de către alte nivele interne (ad-hoc) sau externe (folosind API-uri).

• Raportare (tablouri de bord personalizate, micro strategie, obiective de business, tablou etc.);

• Platforma de căutare sau descoperire a datelor: Solr (server open-source de căutare rapidă), Elasticsearch (server de căutare full text), Tibco Spotfire (software de vizualizare şi analiză a datelor), Datameer (soluţii de analiză Big Data pentru afaceri sub Hadoop) etc.;

• Date ştiinţifice, mineritul şi analiza datelor (în special pentru analiza datelor interne pentru a anticipa sau estima performanţa generală folosind un set de algoritmi).

În afară de cele patru componente logice, monitorizarea joacă un rol crucial în detectarea oricărei defecţiuni în fluxul de date împreună cu modificările prag pentru a identifica orice blocaje în funcţie de performanţă, scalabilitate şi de transfer de ansamblu.

3.1.2.1. Arhitectura unui ecosistem pentru integrarea Big Data pentru business

Printre problemele legate de integrarea Big Data se numără varietatea surselor de date, calitatea datelor ce urmează a fi integrate şi vizualizarea datelor (Bodapati, 2013).



Figura 10. Arhitectura unui ecosistem pentru integrarea Big Data

Arhitectura unui ecosistem pentru integrarea Big Data (vezi Figura 10) include următoarele componente:

1. Sursele de date structurate şi nestructurate. Introducerea bazelor de date stocate în cloud şi a infrastructurii mobile, au dus la o creştere semnificativă a dimensiunii şi complexităţii seturilor de date, acestea devenind componenta principală a ecosistemelor de integrare a datelor. Astfel arhitectura de integrare a datelor trebuie să includă strategii multiple pentru accesarea şi stocarea unei cantităţi foarte mari şi diversificate de date.

2. Sisteme de stocare Big Data. În timp ce sistemele de stocare a datelor foarte mari precum Hadoop asigură mijloace de stocare şi organizare a unor volume mari de date, procesarea acestora pentru extragerea de informaţii utile rămâne în continuare o activitate dificilă. Arhitectura MapReduce a acestor sisteme dă posibilitatea de stocare rapidă a unor cantităţi foarte mari de date şi oferă suport pentru realizarea de analize pe baza acestor date. Platforma pentru integrarea datelor trebuie să construiască structura pentru stocarea datelor şi să realizeze conexiunile cu celelalte surse de date.

3. Platforma pentru descoperirea datelor. Platforma pentru descoperirea datelor reprezintă un set de instrumente şi tehnici pentru lucrul cu fişiere pentru „Big Data” pentru găsirea de modele şi răspunsuri la întrebări de business. În prezent aceasta este mai mult o activitate adhoc, iar organizaţiile întâmpină dificultăţi în dezvoltarea unor procese în jurul ei. În cadrul activităţii de descoperire a datelor, informaţiile obţinute pot deveni uneori neutilizabile după doar câteva ore. Arhitectura pentru integrarea datelor trebuie să ţină cont de aceste informaţii volatile pentru asigurarea calităţii datelor. Infrastructura pentru integrarea datelor trebuie să fie capabilă să răspundă rapid la cerinţele utilizatorilor.

4. Depozite de date tradiţionale. Depozitele de date tradiţionale oferă necesarul de informaţii de bază, dar trebuie să includă noi funcţionalităţi pentru o mai bună integrare a surselor de date nestructurate şi pentru a satisface nivelul de performanţe solicitat de platformele de analiză. Organizaţiile au început să dezvolte noi modalităţi de separare a analizelor operaţionale de analizele în profunzime pe baza istoricului



pentru deciziile strategice. Platforma pentru integrarea datelor trebuie să fie capabilă să separe informaţiile operaţionale, de sursele de date utilizate în elaborarea strategiilor pe termen lung. Totodată infrastructura de integrare a datelor trebuie să permită un acces rapid la datele cel mai des accesate.

5. Portofoliul pentru inteligenţa afacerii. Portofoliul pentru inteligenţa afacerii se concentrează pe rezultatele şi performanţele din trecut, chiar dacă va exista o creştere a cererii pentru rapoarte şi performanţe operaţionale. Evoluţia necesităţii de autoservire a inteligenţei afaceri şi inteligenţei afacerii pe dispozitive mobile va continua să genereze probleme arhitecturale platformelor de integrare a datelor. Un alt aspect foarte important îl reprezintă capacitatea portofoliului de inteligenţă a afacerii de integrare cu portofoliul de analiză. Aceasta poate conduce la o creştere a cererilor pentru integrarea informaţiilor.

6. Portofoliul de analiză a datelor. Activitatea de analiză din cadrul acestui portofoliu trebuie să gestioneze atât problemele legate de activitatea companiei cât şi cele legate de date. Platformele de integrare a datelor joacă două roluri în ceea ce priveşte asigurarea suportului necesar portofoliului de analiză. În primul rând, ecosistemul de integrare a datelor trebuie să asigure accesul la date structurate şi nestructurate pentru activitatea de analiză. În al doilea rând, trebuie să permită reutilizarea analizelor efectuate anterior, reducând astfel situaţiile care ar necesita repetarea unor paşi.

În viitor, ecosistemul de integrare a datelor va trebui să includă posibilitatea de procesare a unor volume foarte mari de date şi să facă faţă unor solicitări de a lucra cu o varietate mare de surse de date.

3.1.2.2. Arhitectura client-server pentru Big Data În cele ce urmează (Figura 11), este prezentată o arhitectură client-server pentru Big

Data (Chan, 2013).

Figura 11. Arhitectura client-server pentru Big Data

Arhitectura la nivel de client

Arhitectura la nivel de client este formată din baze de date NoSQL (Not Only SQL) (vezi detalii în Subcapitolul 3.2.1.2), sisteme de fişiere distribuite şi un cadru de procesare distribuită.



Un exemplu popular de baze de date NoSQL este Apache Hbase. În conformitate cu Apache (Apache, 2013b), Apache Hbase oferă acces de citire / scriere aleatoare în timp real pentru Big Data. Oracle (Apache, 2013b) a descris baza de date Oracle NoSQL ca fiind o bază de date distribuită concepută pentru a oferi stocarea datelor extrem de fiabile, scalabile şi disponibile într-un set configurabil de sisteme care funcţionează ca noduri de stocare.

Următoarele nivele se compun din sistemul de fişiere distribuit, care este scalabil şi poate gestiona un volum mare de date şi dintr-un cadru de prelucrare distribuită care repartizează calculele în clustere de servere de mari dimensiuni. Tantisiriroj, Patil şi Gibson (Tantisiriroj, Patil şi Gibson, 2008) au descris sistemele de fişiere servicii Internet pentru a include sistemul de fişiere Google, serviciul de stocare simplă Amazon şi sistemul de fişiere distribuite Hadoop, de tip Open Source. O platformă des întâlnită este Apache Hadoop.

În conformitate cu Apache (Apache, 2013a), Apache Hadoop este un cadru de prelucrare distribuită a seturilor mari de date în clustere de calculatoare şi este proiectat pentru a scala de la câteva servere până la mii de servere, fiecare oferind calcule şi spaţii de depozitare locale.

Cele două componente esenţiale pentru Hadoop sunt: HDFS şi MapReduce (Minelli şi alţii, 2013). HDFS este sistemul de stocare care distribuie fişierele de date pe clustere de servere şi oferă acces high-throughput pentru seturi mari de date. MapReduce este cadrul de procesare distribuită pentru procesarea paralelă a seturilor mari de date. O procesare de tip MapReduce presupune că problema care trebuie rezolvată poate fi împărţită în probleme mai mici care pot fi rezolvate independent (faza de map), urmând ca apoi rezultatele să fie reunite în funcţie de necesităţi (faza de reduce).

Arhitectura la nivel de server

Arhitectura la nivel de server pentru Big Data este formată din platforme de calcul paralel care pot gestiona volumul şi vitezele asociate. Minelli şi colaboratorii (Minelli şi alţii, 2013) au descris trei opţiuni importante de calcul paralel:

• clustere sau grid-uri, • procesare masiv paralelă (MPP), • supercomputere (HPC).

În conformitate cu Buyya, Yeo, Venugopal, Broberg şi Brandic (Buyya, Yeo, Venugopal, Broberg şi Brandic, 2009), clusterele sau grid-urile sunt tipuri de sisteme paralele şi distribuite, iar un cluster este format dintr-o colecţie de calculatoare independente interconectate, care lucrează împreună ca o singură resursă de calcul integrat, iar un grid permite schimbul, selecţia şi agregarea dinamică în timpul rulării, a resurselor autonome distribuite geografic.

O arhitectură frecvent utilizată pentru Hadoop este formată din maşini client şi clustere de servere slab cuplate care servesc ca HDFS - stocare date distribuite şi MapReduce - prelucrare date distribuite. Hedlund (Hedlund, 2011) a descris cele trei mari categorii de roluri întâlnite într-o implementare Hadoop care constau din:



• maşini client, • noduri Master şi • noduri Slave.

Rolul maşinii client este de a încărca datele în cluster, să trimită joburile la MapReduce şi să prelucreze rezultatele de la joburi, atunci când acesta s-au terminat (Hedlund, 2011). Există două tipuri de noduri Master, nodurile HDFS şi nodurile MapReduce. Nodurile HDFS constau din NameNodes, care păstrează directorul tuturor fişierelor în sistemul de fişiere HDFS. Aplicaţiile client trimit joburile la nodurile MapReduce, care constau din JobTrackers care atribuie task-uri la MapReduce pentru nodurile slave.

JobTracker se consultă cu NameNode pentru a determina locaţia la DataNode, locul unde se află datele şi atribuie task-ului TaskTracker care se află în acelaşi nod, pentru a executa task-ul. În timp ce HDFS este un sistem de fişiere distribuit, care este foarte potrivit pentru stocarea de fişiere mari, acesta nu oferă căutări individuale rapide de înregistrare, pe câtă vreme HBase, construit în partea de sus a HDFS oferă căutări rapide de înregistrare şi actualizări (Apache, 2013c). Apache HBase oferă acces de citire / scriere aleatoare în timp real pentru Big Data (Apache, 2013b). Figura 12 ilustrează arhitectura Hadoop folosind HBase, HDFS şi MapReduce.

Figura 12. Arhitectura Cluster HBase/Hadoop pentru Big Data

Kim, Raman, Liu, Lee şi August (Kim, Raman, Liu, Lee şi August, 2010) au subliniat faptul că în timp ce clusterele de servere sunt cea mai populară formă de computere paralele pe scară largă, ele ar putea să nu fie potrivite pentru programe de aplicaţii de uz general dependente de inter-noduri. O opţiune pentru platforma de calcul paralel este MPP (Massively Parallel Processing - procesare masiv paralelă). Minelli şi colaboratorii (Minelli şi



alţii, 2013) au descris MPP combinând procesul de stocare, memoria şi procesul de calcul pentru a crea o platformă. În timp ce nodurile dintr-o reţea cluster sunt independente, nodurile din MPP sunt strâns interconectate prin reţele dedicate de mare viteză, care să permită colaborarea de mare viteză între procesoare.

3.1.2.3. Arhitectura pentru analiză Big Data Chen, Chiang, şi Storey (Chen, Chiang, şi Storey, 2012) au furnizat o clasificare a

inteligenţei afacerilor şi analiza datelor (business intelligence and analytics - BI & A) în trei categorii:

− BI & A 1.0 este caracterizat de conţinut structurat şi bazat pe SGBD. Se utilizează instrumente de analiză tradiţionale prin intermediul depozitelor de date, ETL, OLAP şi data mining.

− BI & A 2.0 este caracterizat prin conţinut nestructurat, dar bazat pe Web. Se utilizează instrumente în regăsirea de informaţii, exploatarea opiniei (opinion mining), răspuns la întrebare, analize web, analize de media, analize de reţea socială şi analize spaţio-temporale.

− BI & A 3.0 se caracterizează prin conţinut mobil şi pe bază de senzor. Se utilizează instrumente în analiza sensibilizării locaţiei, analiza-centrată pe persoană, analiza de context relevant precum şi vizualizarea mobilă şi HCI.

− BI & A 2.0 şi 3.0 necesită o platformă care să poată gestiona volumul, viteza şi varietatea mare de date. Arhitectura analizelor Big Data descrise mai jos utilizează cadrul de procesare şi depozitare, distribuit şi masiv paralel, furnizat de Hadoop HDFS şi MapReduce.

Data warehousing rămâne o tehnologie viabilă pentru analizele Big Date de volum imens de date structurate. În plus, există o sinergie între data warehousing şi tipul de Hadoop - arhitectura Big Data. Date nestructurate de la senzori, dispozitive M2M, social media şi aplicaţii Web pot fi stocate în Hadoop şi pot fi mai târziu introduse în MapReduce pentru o înţelegere semnificativă (Sathi, 2012). Datele din MapReduce pot fi integrate cu datele warehousing pentru o prelucrare analitică detaliată. Pe de altă parte, datele warehouse pot fi o sursă de date pentru Joburi complexe Hadoop, valorificând simultan capabilităţile a două sisteme (Awadallah şi Graham, 2011). Datele de localizare în timp real de la GPS sau smartphone-uri pot fi combinate cu datele istorice de la date warehouse pentru a oferi în timp real persoanelor din marketing capabilitatea să promoveze produsele specifice pentru clienţi individuali pe baza datele de localizare în timp real şi a profilului client. Figura 13 ilustrează o arhitectură pentru analiză Big Data.

Datele structurate sunt capturate prin diverse surse de date, inclusiv sisteme OLTP, sisteme moştenite şi sisteme externe. Prin procesul ETL, acestea se duc din sistemele sursă la data warehouse ţintă. Instrumentele de prelucrare analitică, cum ar fi procesarea online analitică (OLAP), data mining, şi interogare şi raportare, pot fi folosite pentru a crea inteligenţa de afaceri pentru a îmbunătăţi operaţiunile de afaceri şi procesele decizionale. Există o mare varietate de surse de date nestructurate şi semi-structurate. Acestea pot include date din clickstream-uri, social media, M2M, dispozitive mobile, senzori, documente şi rapoarte, log-uri web, înregistrări de apel, rezultate de cercetare ştiinţifică, sateliţi şi dispozitive geospaţiale. Ele sunt încărcate în clusterul HDFS. Hadoop MapReduce oferă cadrul de procesare tolerant la defecte distribuit în clusterul Hadoop.



În timp ce Hadoop este foarte scalabil şi poate efectua calcule masiv paralele pentru Big Data, acesta este un sistem de batch cu latenţă mare şi nu ar fi potrivit pentru prelucrarea evenimentelor în timp real. Minelli şi colaboratorii (Minelli şi alţii, 2013) au descris inteligenţa geospaţială folosind date despre spaţiu şi timp pentru a îmbunătăţi calitatea analizei predictive.

Figura 13. Arhitectura pentru Analize Big Data

3.1.2.4. Arhitectura multi-agent pentru procesarea în timp real a Big Data O paradigmă importantă, care este tot mai prezentă în analiza Big Data, este conceptul

de agenţi autonomi, inteligenţi şi proactivi (Cao, Weiss şi Yu, 2012). Noţiunea de agent de exploatare (agent mining) combină metodologii, tehnologii, instrumente şi sisteme din domeniul tehnologiei multi-agent, data mining şi knowledge discovery, machine learning, statistici şi web semantic, cu scopul de a accesa probleme care nu pot fi abordate doar printr-o singură tehnică cu aceeaşi performanţă şi calitate.

Una dintre principalele provocări, în ceea ce priveşte prelucrarea de seturi foarte mari de date, este manipularea fluxurilor de date în timp real. În timp ce ambele tipuri de date, offline şi online, pot fi în mod independent prelucrate, adesea este nevoie să furnizăm răspunsuri la întrebările cu privire la evenimente online bazate pe trecut. Arhitectura Lambda vine ca un răspuns la aceste provocări (Twardowski, Ryzko, 2014).

Figura 14. Arhitectura Lambda



Arhitectura Lambda

Arhitectura Lambda (vezi Figura 14) a fost propusă de Nathan Marz (Marz şi Warren, 2014). Ea se bazează pe câteva ipoteze cum ar fi:

• toleranţa la eroare, • suport de interogări ad-hoc, • scalabilitate, • extensibilitate.

Arhitectura, aşa cum este prezentată în Figura 14, este alcătuită din următoarele componente:

• Stratul de loturi (Batch Layer) - responsabil pentru gestionarea setului de date master şi de precalcularea vizualizărilor batch;

• Stratul de servire (Serving Layer) - indexează vizualizările batch pentru interogări ad-hoc;

• Stratul de vitază (Speed Layer) - serveşte doar datelor noi, care nu au fost încă procesate de Nivelul batch.

Stratul de loturi poate fi implementat cu utilizarea sistemelor, cum ar fi Hadoop. Acesta este responsabil de stocarea setului de date imputabile master. Mai mult decât atât, utilizând algoritmii MapReduce se calculează punctele de vedere ale datelor disponibile pentru diferitele aplicaţii.

Stratul de servire este responsabil pentru vizualizarea serviciilor calculate de nivelul batch. Acest proces poate fi înlesnit prin indexarea suplimentară a datelor cu scopul de a accelera citirea. Un exemplu de tehnologie folosită de obicei pentru a face acest gen de lucruri este Impala, care este uşor de integrat cu Hadoop, utilizat în stratul batch.

În cele din urmă, rolul stratului de viteză este de a calcula în timp real datele care tocmai au sosit şi nu au fost încă procesate de către nivelul batch. El deserveşte aceste date sub forma unor vizualizări în timp real, care sunt incrementate ca noi date de intrare şi pot fi folosite împreună cu vizualizările batch pentru o imagine completă a datelor.

Această arhitectură integrată cu Hadoop este prezentată în Figura 15.



Figura 15. Arhitectura Lambda integrată cu Hadoop

În figura de mai sus sunt prezente (detaliat) cele trei straturi ale Arhitectura Lambda integrată cu Hadoop: stratul de operare pe loturi, stratul de servire şi stratul de viteză. În continuare sunt prezentate – în noua formă – cele trei straturi ale arhitecturii.

Stratul de loturi (Batch layer)

În acest strat este aplicat Apache Hadoop. Acest strat stochează seturile de date nemutabile, care se măresc în mod constant (HDFS), şi calculează vederi (view) arbitrare din acest set de date (MapReduce), în mod continuu, prin iteraţii MapReduce. Vederile ar trebui să fie calculate din întregul set de date şi, în consecinţă, stratul de loturi nu actualizează vederile în mod frecvent. Fiecare iteraţie poate dura mai multe ore, în funcţie de mărimea setului de date şi a clusterului.

Stratul de servire (Cloudera Impala)

Ieşirea de la stratul de loturi este un set de fişiere obişnuite care conţin vederi precalculate. Stratul de servire este responsabil pentru indexarea şi expunerea de vederi astfel încât acestea să poată fi interogate. Deoarece vederile în loturi sunt statice, stratul de servire trebuie să furnizeze actualizări în loturi şi citiri aleatoare, lucru care se realizează cu Cloudera Impala. Pentru a expune vederile utilizând Impala, stratul de servire ar trebui să creeze o tabelă în Hive Metastore care să indice fişierele HDFS. După aceasta, utilizatorii ar trebui să poată utiliza Impala ca să interogheze vederile imediat. Deoarece straturile de loturi şi de

Arhitectura Lambda

QFD 1 QFD 2

QFD N

Vederi precalculate (MapReduce)

Toate datele (HDFS)

Vederi loturi

Hadoop

Recalculare loturi

QFD 1 QFD 2

QFD N

Vederi în timp real (Apache HBase)

Vederi incrementale

Flux de procesare

Incrementare în timp real

Fluxuri noi de date

Interogări (Impala)

Storm

Stratul de loturi

Stratul de viteză

Stratul de servire



servire nu satisfac nicio cerinţă de timp real, deoarece MapReduce are din proiectare o latenţă mare, ceea ce conduce la o întârziere de câteva ore în reprezentarea datelor în vederi şi pentru propagarea la stratul de servire. Din această cauză s-a mai introdus şi stratul de viteză. În arhitectura Lambda, timp real semnifică posibilitatea de a procesa o cantitate de date capturate după startarea iteraţiei curente în straturile în loturi.

Stratul de viteză (Storm, Apache HBase)

Stratul de viteză are aceiaşi funcţionalitate cu stratul de loturi, în sensul că el calculează vederi din datele pe care le primeşte. Acest strat compensează, însă, latenţa mare a stratului de loturi, prin calcularea de vederi în timp real cu Storm. Vederile în timp real conţin numai rezultatele intermediare care sunt suplimentare vederilor în loturi. Modelul din stratul de viteză este incremental în cadrul acestuia procesându-se datele care sosesc după realizarea unei iteraţii în stratul de loturi.

Au fost propuse o serie de abordări pentru prelucrarea Big Data în timp real. În continuare sunt descrise 8 cerinţe de prelucrare a datelor în timp real (Stonebraker, Çetintemel şi Zdonik, 2005):

• păstrarea datelor în mişcare, • folosirea de interogări SQL pe Fluxuri (StreamSQL), • tratarea imperfecţiunilor din fluxuri, • generarea de rezultate previzibile, • integrarea datelor stocate şi de streaming, • garantarea securităţii datelor şi disponibilitatea lor, • partiţionarea şi scalarea aplicaţiilor în mod automat, • procesarea şi răspunsul să fie instantanee.

De asemenea alte abordări despre subiectul în timp real sau aproape de procesarea în timp real a Big Data pot fi găsite în literatura de specialitate (Zhu şi Shasha, 2002), (Herodotou şi alţii, 2011).

3.1.2.5. Analiza Arhitecturii Multi-Agent Big Data Abordarea prezentată pentru procesarea Big Data într-o manieră în timp real încearcă

să rezolve problema principală de a analiza seturi de date de mari dimensiuni, ce sunt în continuă creştere. Arhitectura Lambda este una dintre cele mai noi metode şi a câştigat în ultimul timp o popularitate mare, în principal prin simplitate şi utilizând instrumente consacrate pentru prelucrarea datelor. Cele trei nivele uşor de recunoscut, de loturi, de viteză şi de servire, fac o diviziune clară a funcţionalităţii componentelor. Mai mult decât atât, pentru fiecare dintre acest nivel, există o mare varietate de soluţii de implementare. Cele mai multe dintre acestea sunt disponibile pe piaţă de ani de zile şi sunt cunoscute pentru fiabilitate.

În ciuda faptului, că arhitectura amintită este prezentată ca una simplă şi clară, mai sunt încă multe decizii şi o mulţime de lucruri ce trebuiesc integrate. Arhitectura oferă orientări cu privire la modul în care ar trebui să fie proiectat sistemul şi ce părţi ar trebui să conţină. Acest lucru dă libertate în alegerea soluţiilor existente pentru o sarcină specifică. Totuşi, interacţiunea între nivelele de loturi, de servire şi de viteză trebuie să fie manipulată în mod corespunzător. Mai mult, chiar într-un singur nivel, câteva componente trebuie să



interacţioneze împreună folosind diferite protocoale şi metode de comunicare. În mediile Big Data pentru a face faţă la integrarea sistemelor distribuite de prelucrare a datelor trebuie să luăm în considerare scalabilitatea şi fiabilitatea.

Arhitectura Lambda pentru prelucrarea Big Data poate fi modelată ca un mediu multi-agent heterogen. Există trei nivele distincte, cu caracteristici diferite, între care componentele trebuie să interacţioneze unele cu altele. Această comunicare poate fi simplificată utilizând abordarea sistemului multi-agent. Fiecare agent este responsabil de task-uri specifice în prelucrarea datelor, de exemplu: primirea de date, rezultatul agregării etc. Agenţi sunt autonomi şi distribuiţi, iar cooperarea între agenţii se face folosind mesaje de trecere. Toţi agenţii comunică în acelaşi mod şi prin urmare, integrarea este simplificată.

Figura 16. Arhitectura pentru prelucrarea Big Data folosind sisteme multi-agent

Figura 16 prezintă arhitectura Lambda pentru prelucrarea Big Data, folosind sisteme multi-agent. Nu există modificări faţă de conceptul principal. În abordarea MAS există încă stratul de loturi, de viteză şi de servire.

• Stratul de loturi creează agregate - vizualizări batch (Batch Views) - de la toate datele. • Stratul de viteză este doar incremental - Vizualizări în timp real (Real-Time Views) -

pentru datele noi, non-arhivate. • Stratul de servire utilizează atât datele calculate online, cât şi offline (vizualizări)

pentru rezolvarea problemelor specifice, de exemplu interogări analitice, decizii noi de credit, recomandări de muzică etc.

Datele de intrare sunt procesate de sistem ca un flux de date. În funcţie de domeniu, acesta poate fi un flux de: pagini vizualizate, tranzacţii utilizator, fişierele jurnal de sistem, evenimente de diagnostic etc. Fluxul (Stream) - ca serie de date - este colectat de către Agentul Receptor de Flux (Stream Receiver Agent). Acest agent este responsabil de pre-procesarea simplă a datelor cum ar fi: filtrarea, schimbarea formatului de date, serializare a obiectelor etc. După aceea, fiecare eveniment de date din flux este trecut la Agentul de Arhivare (Archiver Agent) şi la Agentul de Procesare Flux (Stream Processing Agent). Ambii agenţi se ocupă cu manipularea noilor date din nivelul batch şi din nivelul de viteză.



Procesul de prelucrare a noilor date începe cu scrierea în Depozitul de Date (Data Store), de exemplu, Sistemul Distribuit de Fişiere Hadoop (HDFS) (Shvachko, Kuang, Radia şi Chansler, 2010). Depozitul de date trebuie să se ocupe de seturi mari de date şi să stocheze toate evenimentele din sistem. Faptul că deţine fiecare eveniment din fluxul de date îi permite să ruleze calculul pentru o perioadă selectată de timp din memorie. Calculele sunt coordonate de către Agentul Coordonator al Loturilor (Batch Driver Agent). Acest agent este creat pentru task-uri specifice, în timp ce lucrul efectiv este realizat de agenţii săi secundari – Agenţii de Lucru cu Loturi (Batch Worker Agent). Fiecare agent de lucru procesează o parte din date pentru a produce cu succes ieşirea din job - vizualizări ale loturilor (Batch Views). Vizualizările loturilor conţin diferite agregări ce trebuie produse din datele stocate. Aceasta este o prezentare generală a procesării loturilor, care poate fi implementată cu uşurinţă într-un cluster de prelucrare distribuit ca YARN (Vavilapalli, şi alţii, 2013) sau Mesos (Hindman, şi alţii, 2011).

Aceleaşi evenimente din datele primite sunt prelucrate de către stratul de viteză. Aici, un Agent de Procesare al Fluxului (Stream Processing Agent) este primul punct de contact. Agentul de Procesare (Processing Agent) rutează fiecare eveniment la Agentul de Lucru în Timp Real (Real-Time Worker Agent) corespunzător, acolo unde sunt executate efectiv task-urile. Rezultatul este reprezentat de Vizualizările în Timp Real (Real-Time Views), care sunt actualizate online. Aceste vizualizări sunt seturi rapide în memoria de date, pregătite pentru accesul online rapid. Atât Vizualizările de loturi, cât şi cele în timp real sunt create pentru un caz specific de utilizare. Această problemă de utilizare a cazului este rezolvată în Nivelul de Servire (Serving Layer). Cererea din exterior este manipulată de către un Agent de Serviciu dedicat (Service Agent). O problemă particulară, este rezolvată de tipurile adecvate de agenţi. Pentru fiecare cerere nouă este creat Agentul de Serviciu. Pentru a rezolva problema dată şi pentru a pregăti răspunsul, Agentul de Serviciu colectează datele necesare. Datele anterioare sunt furnizate Vizualizărilor de loturi precalculate. Pentru a accesa aceste date este folosit Agentul Agregator de Loturi (Batch Aggregator Agent). Acest agent interoghează vizualizările de loturi corespunzătoare.

O prelucrare similară se face pentru colectarea noilor date online. Agentul Agregator în Timp Real pregăteşte seturile de date de la Vizualizările în Timp Real. Ambele vizualizări de loturi şi cele în timp real sunt combinate pentru a prezenta imaginea de ansamblu a datelor. După colectarea tuturor datelor necesare de la agenţii agregatori este creat răspunsul. În acest moment, în care cererea este servită şi răspunsul este trimis înapoi la client, ciclul de viaţă al Agentului de Serviciu se încheie.

În funcţie de infrastructură şi domeniul sistemului, nivelul online (online layer) poate avea vizualizări pentru diferite perioade de timp. Acestea pot varia de la zi la secundă. Ideea principală din spatele stratelor de batch şi de viteză este de a lucra împreună pentru a prezenta o imagine coerentă pentru datele din stratul de servire. Primul lucru care poate fi observat în arhitectura MAS propusă este că toate comunicaţiile din sistem sunt doar între agenţi. Fiecare sarcină unică prezentată în arhitectura Lambda este încapsulată în interiorul unui agent autonom. Aceste rezultate conduc la integrare simplificată şi la calcul distribuit.

Mai mult decât atât, în abordarea prezentată se recomandă folosirea aceleiaşi reprezentări eveniment în ambele procese: de batch şi online. În ciuda diferenţelor de



infrastructură, o schemă de date poate fi la fel (pentru Lambda cele mai comune sunt Hadoop pentru batch şi Storm pentru procesările online). Atunci când agenţii sunt proiectaţi pentru o singură sarcină aceştia pot fi reutilizaţi în nivelul de viteză şi de loturi. De exemplu: acelaşi calcul făcut de Agentul de Lucru cu Loturi şi de Agentul de Lucru în Timp Real se poate face prin implementarea aceluiaşi agent.

3.2. Tehnologii pentru Big Data Unele tipuri de date precum text şi voce, există de mult timp, însă volumul acestora în

mediul Internet şi în alte structuri digitale anunţă începutul unei noi ere, precum şi a unor noi tehnologii care permit analizarea acestor tipuri de date.

În esenţă, Big Data înseamnă date coerente de mari dimensiuni, diverse ca natură, complexe ca structură care sunt păstrate în condiţii de securitate utilizând medii de stocare diverse, performante dar ieftine, date procesate cu ajutorul unor algoritmi avansaţi care asigură rapid rezultate optime cu costuri de exploatare minime.

Pornind de la această definiţie constatăm că sunt de definit două categorii distincte de tehnologii asociate conceptului Big Data. Prima categorie se referă la tehnologiile care gestionează datele de volum şi varietate foarte mare în formate şi pe platforme hardware diverse. A doua categorie se referă la noile tehnologii de prelucrare a datelor care se bazează pe algoritmi performanţi oferind rezultate deosebite la viteze de calcul demne de remarcat. Aceste tehnologii asigură încredere în date şi în rezultatele prelucrărilor lor.

3.2.1. Mecanisme de stocare pentru Big Data Există numeroase studii şi cercetări în domeniul tehnologiilor Big Data analizează

dezvoltarea mecanismelor de stocare a Big Data. Mecanismele de stocare pentru Big Data existente pot fi clasificate pe trei niveluri, dispuse de la bază spre vârf, astfel: (1) sisteme de fişiere, (2) baze de date şi (3) modele de programare.

Sistemele de fişiere reprezintă baza pentru aplicaţiile de nivel superior. Spre exemplu, sistemul de fişiere GFS de la Google este un sistem de fişiere distribuit ce poate fi extins pentru a putea fi utilizat de aplicaţii distribuite pe scară largă (Cattell, 2010). GFS utilizează servere fără resurse puternice pentru a obţine toleranţa la erori şi oferă servicii de înaltă performanţă. GFS suporta aplicaţii ce utilizează fişiere de mari dimensiuni, în care citirea este mai frecventă decât scrierea datelor. Sistemul GFS are şi unele limitări, cum ar fi de exemplu, un singur punct de eroare şi performanţe mai scăzute pentru fişierele mici.

Modele de programare În general, Big Data se stochează pe sute şi chiar mii de servere comerciale. Astfel,

modelele tradiţionale de programare paralelă, cum ar fi de exemplu MPI şi OpenMP, ar putea să nu fie adecvate pentru astfel de aplicaţii paralele la scară largă. Recent, au fost propuse noi modele de programare paralelă care îmbunătăţesc în mod eficient performanţa sistemelor NoSQL şi care reduc decalajul de performanţă faţă de bazele de date relaţionale. Prin urmare, aceste modele au devenit fundamentul pe care se bazează analiza datelor de tip Big Data.

MapReduce: este un model simplu însă deosebit de puternic pentru programarea la scară largă utilizând un număr mare de clustere formate din servere comerciale (Dean and



Ghemawat, 2008). Acesta poate realiza procesarea automată a datelor în mod paralel şi distribuit. În MapReduce, modelul de calcul are doar două funcţii, şi anume, map şi reduce, ambele fiind programate de către utilizatori. Funcţia map are rolul de a procesa datele de intrare şi de a genera perechi intermediare de tipul cheie-valoare. Apoi, sistemul va combina toate valorile intermediare legate de aceeaşi cheie şi le va transmite funcţiei reduce care procesa valorile stabilite anterior într-o mulţime cu mai puţine elemente. MapReduce are avantajul că evită etapele complicate pentru dezvoltarea de aplicaţii paralele, ca de exemplu, distribuirea datelor, toleranţa la defecte, şi rezolvă problemele de comunicaţii între sisteme. Utilizatorul trebuie doar să programeze cele două funcţii pentru a dezvolta o aplicaţie. Cadrul MapReduce nu a permis iniţial mai multe seturi de date într-o aplicaţie, însă acest lucru a fost îmbunătăţit recent.

Pentru a îmbunătăţi eficienţa în programarea aplicaţiilor MapReduce, au fost propuse anumite limbaje avansate, de exemplu, Sawzall de către Google, Pig Latin de către Yahoo, Hive de Facebook.

3.2.1.1. Baze de date Sistemele de gestiune a bazelor de date sunt dezvoltate cu scopul de a oferi suport

pentru administrarea unor seturi de date de diferite dimensiuni ce sunt utilizate în cadrul aplicaţiilor software. De peste 25 de ani bazele de date relaţionale (RDBMS) sunt modalitatea preferată pentru a stoca baze de date.

După cum se ştie, bazele de date s-au dezvoltat urmărind mai multe modele. Dintre aceste modele modelul relaţional a fost cel mai răspândit. La baza lor a stat SQL. Când se invocă acronimul SQL, informaticienii se referă în mod natural la Structure Query Language adică la un limbaj de cereri peste o bază de date relaţională. Dar în acelaşi timp SQL denumeşte şi o clasă de baze de date relaţionale cu acest nume sau cu nume derivate din acestea, de exemplu SQL şi MySQL.

Aceste baze de date cât şi toate bazele de date relaţionale dezvoltate pornind de la ele se caracterizează prin faptul că pun mare accent pe stabilirea relaţiilor dintre entităţi care generează implicit o schemă complexă a bazei de date cu proprietatea de consistenţă. Complexitatea schemei bazei de date şi cerinţa de consistenţă a ei sunt constrângeri care grevează asupra dimensiunii bazei de date şi a performanţei aplicaţiilor informatice dezvoltate pe ea. Aceasta şi numai pentru faptul că liniile din tabelele bazei de date, în acest caz, sunt limitate ca număr.

De aceea teoreticienii bazelor de date au propus câteva idei, destul de îndrăzneţe, care vizează modificarea modelului relaţional. Pe de o parte, această modificare trebuie să conducă la mărirea capacităţii de stocare a bazelor de date. Pe de altă parte se asigură flexibilitatea prelucrărilor de date şi implicit mărirea performanţei aplicaţiilor în ceea ce priveşte timpul de calcul.

Bazele de date relaţionale au la bază aşa-zis-ul model Atomocity-Consistency-Isolation-Durability (ACID). De fapt acestea sunt patru scopuri pe care trebuie să le îndeplinească orice bază de date relaţională ca să fie considerată fiabilă. Atomicitatea este o expresie a principiului “totul sau nimic”. Conform acestui principiu orice tranzacţie pe baza



de date, considerată a fi un “atom”, trebuie să înceapă şi să se încheie cu succes în caz contrar acea tranzacţie se consideră că nu a existat.

Consistenţa este o cerinţă a schemei relaţionale a bazei de date la care se adaugă setul de cerinţe asupra datelor elementare. Numai tranzacţiile care respectă aceste cerinţe sunt înregistrate în baza de date, ele menţinând consistenţa bazei de date. Izolarea tranzacţiilor este o regulă după care se înregistrează în baza de date tranzacţiile multiple care se adresează aceleaşi înregistrări din aceiaşi entitate a bazei de date.

Regula este “primul sosit primul servit” cu aşteptarea terminării tranzacţiei în execuţie. Durabilitatea este o proprietate a bazelor de date relaţionale care se referă la faptul că orice tranzacţie încheiată cu succes nu se pierde. Mai mult, utilizând tehnici variate, de exemplu tehnica jurnalului, se poate reveni la starea anterioară a bazei de date, adică acea stare dinaintea începerii ultimei sesiuni de tranzacţii. Dacă se vrea să se rămână la nivelul modelului ACID, nici o astfel de caracteristică tratată anterior nu trebuie să fie violată.

Bazele de date relaţionale tradiţionale nu pot face însă faţă provocărilor actuale aduse de către Big Data. În ultima vreme bazele de date de tipul NoSQL (baze de date non-relaţionale) sunt din ce în ce mai populare pentru stocarea datelor de mari dimensiuni.

Ele au apărut din nevoia unor companii precum Google, Facebook sau Twitter de a manipula cantităţi imense de date cărora bazele de date tradiţionale pur şi simplu nu le pot face faţă. Aşa că bazele de date NoSQL au fost proiectate pentru a stoca volume foarte mari de date în general fără o schemă fixă şi partiţionate pe multiple servere.

Bazele de date NoSQL oferă moduri flexibile de lucru, suport pentru copierea datelor mult mai simplu şi mai uşor, un API simplu, şi coerenţa eventuală a datelor. Bazele de date NoSQL devin astfel tehnologia de bază pentru Big Data.

În funcţie de modul în care stochează informaţiile, bazele de date NoSQL se împart în: colecţii de perechi cheie-valoare, implementări BigTable, colecţii de documente şi baze de date graf.

Care sunt factorii care au dus la dezvoltarea rapidă a tehnologiilor NoSQL în ultima vreme?

În primul rând o nouă formă de trafic internet generată de Web 2.0 care face posibile variaţii considerabile în numărul de vizite pe care un site le primeşte. Creşterile explozive de trafic pot fi predictibile (de exemplu: Crăciun, evenimente sportive) sau impredictibile (atacul de la 11/09/2001), iar site-uri precum Facebook pot aduce cantităţi imense de trafic “peste noapte” unui site dacă un articol devine viral.

Al doilea motiv este acela că structura datelor dintr-o aplicaţie se modifică în timp ceea ce duce la un număr mare de tabele modificate şi adaptate să servească noile nevoi.

Al treilea factor este accesibilitatea tehnologiei. Până recent doar firmele foarte mari care aveau nevoie absolută îşi permiteau să dezvolte o astfel de soluţie, dar cum baze de date NoSQL există acum ca pachete open-source acum oricine îşi poate permite să le folosească.

Care sunt situaţiile în care se recomandă folosirea unei soluţii NoSQL?



baza de date tradiţională nu mai poate fi scalată la un preţ acceptabil;

generaţi foarte multe informaţii temporare cum ar fi: coşuri de cumpărături, chestionare incomplete, istorice de navigare, personalizări etc.;

baza de date a fost deja denormalizată pentru a îmbunătăţi performanţele;

stocaţi cantităţi foarte mari de text şi/sau imagini;

aveţi nevoie să rulaţi interogări de date care nu implică doar simple relaţii ierarhice; de exemplu: “toţi oamenii dintr-o reţea socială care nu au cumpărat anul acesta o carte dar au legătură cu o persoană care a cumpărat”;

tranzacţiile nu trebuie să fie perfect consistente; de exemplu un buton de “like”, dacă tranzacţia eşuează nu este nici o problemă, utilizatorul cel mai probabil va mai apăsa o dată butonul.

Caracteristicile generale ale acestor soluţii:

memorarea unor volume mari de date (companiile amintite mai sus folosesc între 10-100K servere)

nu există o structură fixă a datelor

între date se pot stabili legături (prin referinţe la date memorate în alte baze de date)

aceleaşi date pot sǎ fie memorate pe mai multe servere (partajare şi replicare)

la interogare nu se folosesc operaţii de join (mari consumatoare de timp)

sunt soluţii foarte bune pentru cazuri particulare (NU pentru orice gestiune de date)

Dezavantaje ale modelelor NoSQL:

nu există standarde (cum există standardul SQL la bazele de date relaţionale)

nu se asigurǎ consistenţa bazei de date (de cǎtre sistemul de gestiune)

nu existǎ metode performante pentru protecţia datelor

modelele propuse sunt la primele versiuni

existǎ posibilităţi limitate de interogare

aproape toate sistemele apărute sunt open-source

există relativ puţini dezvoltatori software pentru NoSQL

3.2.1.2. Tehnologia NoSQL NoSQL (Not Only SQL) sunt baze de date non relaţionale. Principalul avantaj al

utilizării bazelor de date NoSQL este acela că permit lucrul eficient cu date structurate, precum e-mailul, multimedia, procesoare de text. Bazele de date NoSQL, ca nouă generaţie de baze de date: nu sunt relaţionale, sunt distribuite, sunt Open Source şi se caracterizează prin scalabilitate orizontală. O altă caracteristică importantă a sistemelor NoSQL este arhitectura “shared nothing” prin care fiecare nod-server este independent, nu partajează memorie sau spaţiu.

NoSQL nu înseamnă ”nu SQL” ci mai degrabă ”nu numai SQL”, vezi (MAC CREARY and KELLY, 2014). Acest nou SGBD face ceea ce niciun promotor al modelului ACID nu s-ar fi aşteptat, renunţându-se la structura, relaţii între entităţi, numerotarea



realizărilor entităţilor şi la mai toate principiile acestui model. Se propune un nou model mai flexibil numit Basic Availability Soft State Eventual Consistency (BASE).

Bazele de date NoSQL au o structură mai simplă şi o tehnologie diferită pentru stocarea şi extragerea datelor decât bazele de date relaţionale şi oferă performanţe mai bune pentru analize în timp real sau pe volume mari de date.

Într-o bază de date NoSQL nu există o schemă propriu-zisă a datelor, ele fiind stocate ca perechi cheie-valoare (foarte eficient şi flexibil, dar datele nu sunt self-describing), sau de coloane (folosit pentru date împrăştiate), sau document (folosit pentru depozite XML, dar ineficient ca performanţă), sau graf (folosit pentru traversări relaţionate, dar ineficient la căutări).

Astfel mişcarea NoSQL reprezintă o încercare de a depăşi limitările modelului relaţional şi un pas de trecere către NewSQL şi anume relaţional plus extra funcţionalităţi NoSQL.

În continuare se vor prezenta principalele trei tipuri de baze de date NoSQL: baze de date cheie-valoare, baze de date orientate pe coloane şi baze de date dedicate pentru documente.

• Bazele de date cheie-valoare: Bazele de date cheie-valoare sunt constituite în baza unui model al datelor simplu, potrivit căruia datele sunt stocate corespunzător unei perechi cheie-valoare. Fiecare cheie este unică, iar clienţii pot introduce valori pentru fiecare cheie. De-a lungul ultimilor ani au fost implementate foarte multe baze de date de tipul cheie-valoare fiind inspirate după sistemul Amazon Dynamo (DeCandia et al., 2007).

o Dynamo: este un sistem distribuit de stocare al datelor de tipul cheie-valoare. Acesta are drept principale caracteristici disponibilitatea şi posibilitatea de extindere şi este utilizat pentru a stoca şi gestiona serviciile de bază din cadrul platformei de e-Commerce de la Amazon. Dynamo poate să ofere facilităţi precum elasticitatea şi disponibilitate prin utilizarea unor mecanisme care se bazează pe partiţiile de date, copierea şi editarea obiectelor componente. Dynamo transferă datele la N seturi de servere, în care N este un parametru configurabil cu scopul de a obţine o disponibilitate ridicată. Dynamo oferă şi eventuala coerenţă a datelor, astfel încât se pot realiza modificări asincrone pe toate copiile.

o Voldemort: este un sistem de stocare cheie-valoare care a fost iniţial dezvoltat de către compania LinkedIn. Voldemort oferă actualizarea asincronă şi controlul simultan pentru mai multe versiuni, dar nu asigură coerenţa datelor. Cu toate acestea, Voldemort permite actualizarea multi-înregistare coerentă utilizând o tehnică bazată pe blocarea optimistă a scrierilor, ceea ce presupune că atunci când apare un conflict între actualizare şi orice alte operaţiuni, operaţiunea de actualizare va fi oprită. Mecanismul de copiere al datelor utilizat de Voldemort este acelaşi cu cel al Dynamo.

Aşa cum am menţionat anterior, bazele de date de tip cheie-valoare au apărut recent fiind profund influenţate de Amazon Dynamo. Alte sisteme de stocare de tipul cheia-valoare includ Redis, Memcached, Memcache DB, Riak, Scalaris etc.



• Baze de date orientate pe coloane: bazele de date orientate pe coloane stochează şi prelucrează datele în funcţie de coloane şi nu de rânduri ca în cazul sistemelor relaţionale tradiţionale. Atât coloanele cât şi rândurile sunt segmentate în mai multe noduri pentru a suporta extinderea bazei de date. Bazele de date orientate pe coloane sunt inspirate în principal de BigTable ce a fost realizat de către Google. Acesta va fi prezentat succint în continuare şi apoi vor fi introduse câteva instrumente similare.

o BigTable: este un sistem distribuit de stocare a datelor structurate, care este proiectat pentru a procesa datele la scară largă (de ordinul PB) utilizând servere obişnuite (Chang et al., 2008). BigTable se bazează pe mai multe componente fundamentale ale infrastructurii Google, inclusiv GFS, sistemul de management al clusterelor de calcul, formatul de fişiere SSTable şi Chubby. GFS este folosit pentru a stoca datele şi fişierele jurnal. Sistemul de management al clusterelor este responsabil pentru programarea încărcării cu aplicaţii, partajarea resurselor, procesarea erorilor sistemelor de calcul şi monitorizarea stării sistemelor. Fişierele în format SSTable sunt utilizate pentru a stoca intern datele BigTable. Chubby este utilizat pentru următoarele sarcini: 1) să se asigure că există cel mult o copie master activă în orice moment; 2) pentru stocarea locaţiei bootstrap pentru datele din BigTable; 3) căutare server Tablet; 4) recuperare din eroare în caz de defecţiune a unui server Tablet; 5) oferirea de informaţii referitoare la schema de date BigTable; 6) de a stoca tabela de control acces.

o Cassandra: este un sistem de stocare distribuit special proiectat pentru a gestiona o cantitatea mare de date structurate cu ajutorul unor servere obişnuite (Lakshman and Malik, 2009). Acest instrument a fost dezvoltat de către Facebook şi a fost făcut open source în anul 2008. Cassandra adoptă ideile şi conceptele Amazon Dynamo şi Google BigTable, în special în domeniul integrării tehnologiei sistemelor distribuite utilizate de Dynamo cu modelul structurării datelor utilizat de BigTable.

o Alte instrumente inspirate de BigTable: deoarece codul sursă al aplicaţiei BigTable nu poate fi obţinut prin intermediul unei licenţe open source, mai multe proiecte open source au fost iniţiate cu scopul de a pune în aplicare conceptele utilizate de tehnologia BigTable şi de a dezvolta sisteme similare, cum ar fi, de exemplu, HBase şi Hypertable.

HBase este o versiune open source inspirată de BigTable şi care a fost dezvoltată în limbajul de programare Java (George, 2011). Aceasta face parte din ecosistemul Hadoop, mai precis din cadrul componentei MapReduce. HBase înlocuieşte GFS cu HDFS şi utilizează memoria RAM pentru a actualiza conţinutul bazelor de date şi apoi transcrie în mod regulat în fişiere pe discuri.

• Baze de date dedicate pentru documente: comparativ cu bazele de date de tip cheie-valoare, bazale de date dedicate pentru documente pot gestiona tipuri de date mult mai complexe. În continuare se va face o scurtă trecere în revistă a principalelor soluţii pentru baze de date dedicate pentru documente, respectiv MongoDB, SimpleDB, şi CouchDB.

o MongoDB: este un produs open-source pentru stocarea documentelor (Chodorow and Dirolf, 2010). MongoDB utilizează obiecte de tipul Binary JSON (BSON) pentru stocarea datelor.

o SimpleDB: este o bază de date distribuită pentru stocarea documentelor ce oferă o interfaţă bazată pe servicii web. Aceasta a fost dezvoltată de către



Amazon. SimpleDB este organizat sub forma de domenii în care pot fi stocate datele. Domeniile pot avea proprietăţi diferite. Datele sunt copiate pe diverse maşini aflate în diferite centre de date cu scopul de a asigura siguranţa datelor şi de a îmbunătăţi performanţa.

o CouchDB: Apache CouchDB este o bază de date dedicată pentru documente ce a fost implementată în limbajul de programare Erlang (Anderson, Lehnardt, and Slater, 2010). Datele stocate în cadrul CouchDB sunt organizate sub forma unor documente ce sunt compuse din câmpuri diferite accesate pe baza de chei/nume şi valori, şi care sunt stocate şi accesate sub forma de obiecte de tipul JSON. Fiecare document are un identificator unic. CouchDB permite accesul la documentele stocate în baze de date prin intermediul unui API de tipul RESTful.

Dacă o bază de date a fost simplificată în acest mod este clar că cererile aşa cum sunt ele ştiute de la bazele de date relaţionale nu mai au suport şi în consecinţă trebuie găsite alte mecanisme pentru regăsirea datelor. În cazul bazelor de date NoSQL acest nou mecanism este funcţia hash. Ea este un algoritm matematic care poate prelua o intrare de lungime variabilă oferind o ieşire consistentă de lungime fixă. Când la intrare într-o bazĂ NoSQL apare un cuplu cheie / valoare, cheii respective i se aplică funcţia hash, iar cuplul hash cheie-valoare respectiv este direcţionat către un anumit NoSQL Server unde se stochează şi de unde ulterior va fi găsit. Când o aplicaţie încearcă să găsească o pereche cheie-valoare ea furnizează numele bazei de date şi cheia respectivă. Procedeul hash se repetă ca la stocare şi dacă cheia există în acea bază de date înseamnă că motorul de găsire a cuplului cheie-valoare va trebui s-o găsească pe serverul respectiv. Desigur că după cum s-a văzut NoSQL este orientat spre stocare masivă a informaţiilor şi regăsire rapidă atunci când este nevoie. Cereri complexe, ca în cazul bazelor de date relaţionale, nu se pot lansa în acest caz. Există şi beneficii a acestei arhitecturi numită NoSQL. Primul beneficiu provine din acceptarea redondanţei. Pe baza ei administratorii bazei de date pot replica o înregistrare existentă şi apoi să o reconfigureze aşa cum doresc. Celălalt beneficiu se referă la scalabilitate. Aceasta însemnă că administratorul bazei de date poate adăuga practic oricâte înregistrări vrea iar acestea sunt prelucrate de funcţia hash cu stocarea balansată la nivelul serverului.

Deşi NoSQL îşi găseşte destul de multe aplicaţii, cele mai multe fiind cele care necesită date de volum foarte mare dar de complexitate mică, nu se poate spune că ele vor substitui bazele de date relaţionale.

Dacă în subcapitolul anterior au fost prezentate avantajele folosirii NoSQL, bineînţeles ca există şi dezavantaje. Printre acestea amintim:

nu există un limbaj universal valabil. Bazele de date relaţionale au SQL, care chiar dacă are multe extensii proprietare totuşi utilizatorii ştiu la ce să se aştepte;

maturitatea – majoritatea sistemelor NoSQL încă sunt la primele variante sau încă în plină dezvoltare;

suport – fiind în general proiecte open source, iar firmele ce oferă suport sunt mici, de multe ori startup-uri şi poate nu oferă suficientă credibilitate;

disponibilitatea dezvoltatorilor – evident fiind o tehnologie nouă, comparativ cu bazele de date tradiţionale sunt mult mai puţini dezvoltatori software NoSQL.



Sistemele NoSQL se potrivesc foarte bine şi cu tehnologia Cloud, care se bazează pe virtualizare.

Bazele de date NoSQL reprezintă o trecere către baze de date superioare ce vor integra flexibilitatea şi performanţele lor actuale cu modelul relaţional. Odată cu apariţia bazelor de date NoSQL, dezvoltatorii au oportunitatea de a beneficia de mai multă agilitate în modelul de date abordat. De asemenea aceste baze de date constituie modelul optim pentru aplicaţiile web. De aceea cunoaşterea caracteristicilor lor este foarte importantă, în special înainte de a migra la o astfel de soluţie.

Cele mai populare baze de date NoSQL în acest moment sunt: Cassandra, Mongodb, CouchDB, Redis, Riak, Membase, Neo4j şi HBase.

3.3. Seturi Big Data Big data reprezintă o colecţie de seturi de date complexă şi de dimensiune foarte mare

şi care nu poate fi procesată cu ajutorul aplicaţiilor standard fiind necesare aplicaţii capabile să ruleze în mod paralel pe un număr foarte mare de servere. Printre dificultăţile întâlnite în procesarea acestor date se numără: captura, curăţarea, stocarea, căutarea, partajarea, transferul, analiza şi vizualizarea.

Sistemele de Big Data pot furniza informaţie atât organizaţiilor guvernamentale cât şi cetăţenilor, provenind din diferite surse care pot fi identificate după cum urmează:

• document pe hârtie (mediu fizic)

• documente digitale

• puncte de acces la reţeaua de Internet guvernamentală

• site-uri localizate pe platformele online de socializare

• sisteme operaţionale disponibile.

Informaţia furnizată de sistemele Big Data nu include informaţii personale sau informaţii restricţionate de mecanisme de control şi confidenţialitate.

Strategiile de Big Data, în general, presupun o serie de schimbări în orice companie, schimbări legate de surse, de infrastructură, de abilităţi, în condiţiile în care vorbim de seturi de date greu de structurat. Acest volum mare de date, variat şi care se modifică rapid, însă, oferă o viziune în profunzime asupra noilor pieţe, dar şi asupra noilor nevoi ale consumatorilor.

3.3.1. Categorii de date Potrivit Garter, pentru a gestiona un volum mare de date, informaţiile ar putea fi

incluse în categorii, în funcţie de sursă. Firma de consultanţă americană a identificat cinci astfel de tipuri de informaţii:

1. Date operaţionale

Sunt date despre consumatori, furnizori, parteneri şi angajaţi deja accesibile pe baza unor procese de tranzacţie sau din baze de date.

http://cassandra.apache.org/

http://www.mongodb.org/

http://couchdb.apache.org/

http://redis.io/

http://www.basho.com/Riak.html

http://www.couchbase.org/membase

http://neo4j.org/

http://hbase.apache.org/



2. Date ascunse (Dark Data)

„Dark date” sunt informaţiile adunate de-a lungul vremii în arhive, dar care nu pot fi clar structurate. În acest caz ar fi incluse mail-urile, contractele, informaţiile multimedia.

3. Date comerciale

Sunt date care pot veni prin intermediul agregatoarelor de date (care citesc RSS-urile) specifice, în funcţie de industrie.

4. Date publice

Datele publice aparţin instituţiilor statului (informaţii care vin de la Guvern, de la ministere).

5. Date din social media

Sunt datele care arată activitatea unui utilizator pe un blog, pe reţelele de socializare. Ele sunt utile pentru a stabili trenduri, atitudini, preferinţe.

“Big Data” reprezintă seturi mari de informaţii complexe care în urma unei analize pot identifica trenduri în afaceri, pot contribui la prevenirea bolilor şi chiar combate rata criminalităţii.

3.3.2. Procesul de achiziţie a datelor Procesul de achiziţie Big Data include activităţi precum colectarea, transferul şi pre-

procesarea datelor (Chen, Mao, and Liu, 2014). Seturile de date astfel obţinute pot include însă informaţii care sunt redundante sau informaţii care sunt complet nefolositoare şi care cresc nejustificat necesarul pentru spaţiul de stocare. În plus, procesul de analiză poate să fie influenţat în mod negativ de calitatea datelor utilizate. Spre exemplu, problema redundanţei datelor este comună în cazul seturilor de date furnizate de senzorii de monitorizarea a mediului. În astfel de situaţii se utilizează în mod frecvent tehnica compresiei datelor. În continuare vor fi introduse şi prezentate aceste activităţi specifice procesului de achiziţie a datelor.

3.3.2.1. Colectarea datelor Colectarea este un proces ce se bazează pe tehnici specifice necesare pentru obţinerea

datelor neprelucrate (brute) de le senzori sau alte surse dedicate. Cele mai importante surse pentru colectarea datelor sunt:

1. Fişierele de tip log (log-file). Aceste fişiere înregistrează în mod automat informaţii specifice în operarea aplicaţiilor şi sistemelor de calcul, precum serverele web, serverele de baze de date, serverele de mail ş.a. (Wahab, Mohd, and Hanafi, 2008). În situaţia în care dimensiunea datelor stocate devine exagerat de mare, pentru a îmbunătăţi performanţele legate de accesarea şi interogarea acestora, în locul fişierelor standard se pot utiliza baze de date dedicate sau alte sisteme specializate.

2. Monitorizarea prin intermediul senzorilor. Senzorii au devenit omni-prezenţi în viaţa de zi cu zi. Aceştia măsoară diverşi parametri de mediu şi transformă cantităţi fizice în semnale digitale ce sunt stocate şi apoi prelucrate. Datele furnizate de senzori pot fi clasificate în funcţie de domeniul de provenienţă precum: subiectul uman, mediul ambiant, clădiri, automobile etc. Informaţiile oferite de senzori sunt transferate către o bază de date cu ajutorul reţelelor wireless.



3. Reţele de date. În prezent, obţinerea de date din cadrul reţelelor de calculatoare se realizează prin intermediul unor aplicaţii specializate, utilizând metode şi tehnici specifice. Spre exemplu, principale tehnologii utilizate pentru achiziţionarea datelor din cadrul unei reţele includ înregistrarea pachetelor de date cu ajutorul aplicaţiei Libpcap sau înregistrarea pachetelor de date cu ajutorul tehnologiei zero-copy. Se pot înregistra de asemenea datele cu ajutorul unor aplicaţii dedicate de monitorizare precum Wireshark, SmartSniff sau WinNetCap.

• Tehnologia de achiziţionare a datelor bazată pe Libpcap. Această aplicaţie este o bibliotecă extrem de populară ce este utilizată pentru înregistrarea pachetelor de date în cadrul reţelelor de calculatoare. Este un instrument care nu depinde de nicio altă aplicaţie sau sistem şi care operează la nivelul 2 în cadrul stivei de protocoale de reţea (nivelul de date). Principalele sale avantaje sunt uşurinţa în utilizare, portabilitatea şi faptul că este extrem de simplu. Pe de altă parte, dezavantajul major al acestei tehnologii este eficienţa foarte scăzută. În anumite situaţii de încărcare şi de latenţă foarte scăzută pot apărea frecvent pierderi de date.

• Tehnologia de achiziţionare a datelor utilizând metoda zero-copy. Aşa-numita metodă zero-copy (ZC) presupune că, în cadrul procesului de transfer al pachetelor recepţionate către o nouă destinaţie, nu se realizează nicio copiere a datelor în memoria sistemului de calcul. La transmiterea datelor, pachetele sunt preluate direct din zona de memorie alocată special pentru aplicaţia respectivă, sunt redirecţionate către interfeţele de reţea şi apoi sunt transferate în reţea.

• Echipamentele mobile. Cu cât dispozitivele mobile devin din ce în ce mai sofisticate, acestea includ un număr tot mai mare de senzori pentru înregistrarea datelor. Astfel, dispozitivele mobile pot înregistra informaţii referitoare la localizarea geografică, pot înregistra date video, imagini, sunete, informaţii de mediu precum presiunea atmosferică, date referitoare la activităţile utilizatorului, etc. Spre exemplu, un telefon inteligent precum iPhone poate colecta date referitoare la reţele wireless, localizarea geografică a utilizatorului şi poate transmite aceste informaţii companiei Apple pentru a fi procesate. În mod similar, şi alte sisteme de operare pentru dispozitivele mobile precum Android de la Google şi Windows Phone de Microsoft pot colecta informaţii similare pe care le trimit apoi către companiile respective.

4. Experimentele ştiinţifice. În afara acestor trei metode principale de achiziţie a datelor ce au fost menţionate anterior, în cadrul experimentelor ştiinţifice, instrumentele de laborator pot înregistra datele experimentale, spre exemplu spectrometrele magnetice sau radiotelescoapele.

Metodele de colectare a datelor pot fi clasificate şi din perspectiva surselor de date. Astfel, acestea pot fi împărţite în metode de colectare direct de la sursă sau metode de colectare a datelor prin intermediul unor instrumente auxiliare.

3.3.2.2. Transferul datelor Odată ce a fost finalizat procesul de colectare a datelor, acestea vor fi transferate în

cadrul unui sistem de stocare pentru a fi procesate şi ulterior analizate. Big Data este stocat pe o infrastructură de calcul la dimensiunea unui centru de date. Modul în care sunt dispuse aceste date este extrem de important deoarece acest lucru influenţează atât eficienţa computaţională cât şi activitatea de mentenanţă a infrastructurii.



Transferul datelor constă din două faze: transferul Inter data-center şi transferul Intra data-center.

• Transferul Inter data-center: este transferul de la sursă către centrul de date. În general acesta este realizat prin intermediul Internet.

• Transferul Intra data-center: acest mod de transfer constă în copierea datelor în cadrul unui centru de date. Acesta depinde de tipul infrastructurii de reţea utilizate în cadrul centrului de date, cum ar fi de exemplu arhitectura de reţea, modul de realizare a conexiunilor, componentele hardware de memorie şi unitate de procesare, etc. În general, un centru de date constă din mai multe rack-uri care sunt interconectate între ele prin intermediul unei reţele private.

3.3.2.3. Pre-procesarea datelor Datorită numărului foarte de mare al surselor de date, seturile de date colectate

prezintă o serie de probleme precum redundanţa, consistenţa sau elemente nerelevante care pot fi incluse în categoria zgomot. Aceste inconveniente produc totodată şi o risipă a spaţiului de stocare. În plus, anumite metode de analiză a datelor necesită un minim standard de calitate pentru acestea.

Astfel, pentru realizarea activităţii de analiză a datelor trebuie să se implementeze un proces de pre-procesare al datelor provenite din mai multe surse, ce conduce la reducerea necesarului de spaţiu de stocare şi creşte totodată acurateţea analizei. Câteva din cele mai importante tehnici de pre-procesare a datelor sunt prezentate în continuare:

• Integrarea: este o operaţie de procesare a datelor ce provin din surse diferite şi care se bazează pe combinarea informaţiilor şi prezentarea unei imagini unitare asupra seturilor de date (Lenzerini, 2002). În practică sunt utilizate două mari strategii: depozitarea datelor (data warehouse) şi federalizarea datelor (data federation). Depozitarea datelor include un proces denumit ETL (Extract, Transform, Load). Extragerea datelor implică realizarea unei conexiuni între sistemele sursă pentru date, iar apoi selectarea, colectarea, analizarea şi procesarea acestora. Transformarea reprezintă executarea unor serii de acţiuni definite sub forma de reguli de procesare care sunt aplicate datelor extrase. Încărcarea se referă la importarea datelor extrase şi prelucrate în cadrul infrastructurii de stocare. Aceasta este şi cea mai complexă procedură dintre cele trei, deoarece include operaţii precum transformarea, copierea, corectarea, standardizarea, filtrarea şi organizarea datelor.

• Filtrarea: este un proces prin care se identifică datele inexacte, incomplete sau pur şi simplu eronate şi care sunt apoi modificate sau eliminate, astfel încât să se îmbunătăţească calitatea acestora. La modul general, filtrarea datelor include cinci proceduri complementare, respectiv: definirea şi determinarea tipurilor de erori, căutarea şi identificarea erorilor, corectarea erorilor, documentarea exemplelor de erori precum şi a tipurilor de erori şi modificarea procedurilor de introducerea a datelor pentru a reduce numărul de erori (Maletic and Marcus, 2000). Filtrarea datelor este esenţială pentru menţinerea integrităţii, aceasta fiind imperios necesară în diferite domenii de activitate precum sectorul bancar, industria de retail, telecomunicaţii sau controlul de trafic aerian. În domeniul comerţului electronic datele sunt colectate automat ceea ce poate genera anumite probleme legate de calitatea acestora. Principalele probleme legate de calitatea datelor provin din cauza unor defecte software, proasta configurare a sistemelor sau a unor erori umane.



• Eliminarea redundanţei: Redundanţa datelor se referă la repetarea unor informaţii, fenomen des întâlnit la majoritatea seturilor de date. Aceasta determină creşterea atât a costului de transfer al datelor cât şi a costului de stocare prin risipa de spaţiu de stocare, şi poate afecta integritatea sau fiabilitatea datelor. Cele mai importante tehnici utilizate pentru reducerea redundanţei datelor includ detectarea redundanţei, filtrarea şi compresia datelor. Eliminarea redundanţei poate avea însă şi câteva efecte negative. De exemplu, compresia şi apoi decompresia datelor au anumite costuri computaţionale. Din acest motiv trebuie să se pună în balanţă atât avantajele, cât şi dezavantajele acestei metode.

3.3.3. Sisteme distribuite pentru stocarea datelor Una dintre cele mai mari provocări legate de Big Data se referă la dezvoltarea unor

sisteme de stocare distribuite la scară largă pentru procesarea eficientă şi analiza datelor. În utilizarea unui astfel de sistem distribuit pentru stocarea Big Data, trebuie să fie luaţi în considerare următorii factori:

• Coerenţa: un sistem de stocare distribuit necesită mai multe servere pentru a stoca datele într-un mod coordonat. Deoarece sunt utilizate mai multe servere, probabilitatea de a avea probleme cu un server este mai mare. De obicei, datele sunt împărţite în mai multe eşantioane cu scopul de a fi stocate pe diferite servere pentru a asigura disponibilitatea în cazul unei probleme pe un anumit server. Cu toate acestea, defecţiunile unui server sau a sistemului de fişiere paralel pot provoca apariţia unor inconsecvenţe între diferitele copii ale aceloraşi date. Coerenţa se referă la asigurarea că mai multe copii ale aceloraşi date sunt identice.

• Disponibilitatea: un sistem de stocare distribuit operează cu mai multe servere organizate sub forma de clustere. Cu cât sunt utilizate mai multe servere, cu atât creşte probabilitatea apariţiei unor defecţiuni sau probleme cu anumite sisteme. Acest lucru este inevitabil. Ar fi de dorit ca în cazul în care un sistem nu este afectat serios să poată răspunde totuşi cererilor utilizatorilor. Această proprietate se numeşte disponibilitate.

• Toleranţa la partiţionare: mai multe servere într-un sistem de stocare distribuit sunt conectate printr-o reţea. Reţeaua ar putea avea anumite probleme cu conexiunile între sisteme sau se poate să apară o congestie temporară. Sistemul distribuit ar trebui să aibă un anumit nivel de toleranţă la problemele cauzate de defecţiunile de reţea. Ar fi de dorit ca stocarea distribuită să funcţioneze corect chiar şi atunci când reţeaua este fragmentată.

În anul 2000, Eric Brewer a propus teoria CAP (Brewer, 2000; Gilbert and Lynch, 2002) conform căreia un sistem distribuit nu ar putea satisface în acelaşi timp cerinţele privind coerenţa, disponibilitatea şi toleranţa la partiţionare; cel mult două dintre cele trei cerinţe pot fi satisfăcute simultan. Seth Gilbert şi Nancy Lynch de la MIT au dovedit corectitudinea teoriei CAP în anul 2002. Deoarece coerenţa, disponibilitatea şi toleranţa la partiţionare nu ar putea fi atinse în acelaşi timp, se poate ajunge la sisteme de tipul CA prin ignorarea toleranţei la partiţionare, sisteme de tipul CP prin renunţarea la disponibilitate, şi sisteme de tipul AP care ignoră coerenţa. Aceste trei sisteme sunt prezentate în cele ce urmează.

Sistemele de tipul CA nu oferă toleranţa la partiţionare, respectiv nu pot face faţă erorilor de reţea. Prin urmare, sistemele de tipul CA sunt în general considerate ca fiind



sistemele de stocare cu un singur server, cum ar fi de exemplu bazele de date relaţionale tradiţionale, de mici dimensiuni.

Astfel de sisteme sunt dotate cu un singur exemplar al datelor, astfel încât este uşor de asigurat coerenţa acestora. Disponibilitatea este garantată prin însăşi principiile de proiectare ale bazelor de date relaţionale. Cu toate acestea, din moment ce sistemele de tipul CA nu pot face faţă erorilor de reţea, acestea nu pot fi extinse pentru a utiliza mai multe servere. Prin urmare, cele mai multe sisteme de stocare la scară largă sunt sistemele de tipurile CP şi AP.

Comparativ cu sistemele de tipul CA, sistemele de tipul CP asigură toleranţa la partiţionarea reţelei. Prin urmare, sistemele CP pot fi extinse pentru a deveni sisteme distribuite. Sisteme de tipul CP menţin, în general, mai multe copii ale aceloraşi date, cu scopul de a asigura un nivel de toleranţă la erori. Sistemele de tipul CP asigură, de asemenea, consistenţa datelor. De exemplu, mai multe copii ale aceloraşi date sunt garantate că sunt complet identice. Cu toate acestea, sistemele CP nu pot asigura disponibilitatea din cauza costului ridicat pentru asigurarea coerenţei. Prin urmare, sistemele de tipul CP sunt utile pentru scenariile de utilizare având o sarcină moderată şi cerinţe stricte cu privire la acurateţea datelor (de exemplu datele privitoare la tranzacţii financiare). Bigtable şi Hbase sunt două sisteme de tipul CP.

Sistemele de tipul AP asigură, de asemenea, toleranţa la partiţionarea reţelei. Cu toate acestea, sistemele de tipul AP sunt diferite faţă de sistemele de tipul CP datorită faptului că sistemele AP asigură şi disponibilitate datelor. Însă sistemele de tipul AP pot asigura că la un moment dat se va ajunge la o eventuală coerenţă, însă nu şi coerenţa care este garantată în cadrul sistemelor CA şi CP.

Prin urmare, sistemele de tipul AP sunt utile mai ales pentru exemple de utilizare cu cereri frecvente, dar fără cerinţe foarte mari de acurateţe. De exemplu, în cadrul serviciilor de tipul reţelelor sociale sunt utilizate foarte multe apeluri concurente la date, însă doar o anumită cantitate de erori sunt tolerabile. Deoarece însă sistemele de tipul AP asigură şi eventuala coerenţă, datele exacte pot fi obţinute după o anumită perioadă de întârziere. Prin urmare, sistemele de tipul AP pot fi de asemenea utilizate şi în astfel de circumstanţe, fără cerinţe stricte referitoare la răspunsul în timp real. Dynamo şi Cassandra sunt două sisteme populare de tipul AP.

3.3.4. Domenii de aplicabilitate a Big Data

Exemple de domenii în care proiectele Big Data sunt realizabile: Sănătate (analiza statistică a cazurilor, telemedicină etc.), Cultură, eCommerce, Securitate naţională.

În cele ce urmează prezentăm o listă de domenii în care folosirea “Big Data” este răspândită şi aduce cele mai mari beneficii.

1. Publicitatea orientată către client

Aceasta este una dintre zonele cele mai mediatizate referitoare la „Big Data”. Informaţiile relevante precum locaţia şi datele noastre personale, preferinţele şi hobbyurile noastre sunt folosite pentru a ne înţelege ca şi clienţi, pentru a putea determina comportamentele şi preferinţele noastre. Companiile sunt dornice să-şi extindă bazele de date



cu informaţii de pe reţelele sociale, din istoricul browser-elor web, precum şi datele de analiză şi senzori de text pentru a obţine o imagine mai completă a clienţilor lor. Cel mai important obiectiv este, în multe cazuri, acela de a crea modele de previziune pentru a putea face reclamă unui anumit produs direct grupurilor de persoane interesate de acesta, anticipând nevoile lor.

2. Înţelegerea şi optimizarea proceselor de afaceri

Analiza „Big Data” este utilizată din ce în ce mai mult pentru a optimiza procesele de afaceri. Comercianţii sunt capabili să-şi îmbunătăţească acţiunile pe baza previziunilor generate de datele de pe reţelele sociale, tendinţele de căutare web şi prognoze meteo. Spre exemplu, un proces important este optimizarea lanţului de aprovizionare sau a drumului de livrare. Aici, poziţionarea geografică şi identificarea senzorilor de frecvenţă radio sunt folosite pentru a urmări bunurile sau livrarea vehiculelor şi pentru a optimiza rutele prin integrarea live a traficului de date.

3. Îmbunătăţirea personală şi optimizarea performanţei

„Big Data” nu este utilizată doar de companii şi guverne, ci este importantă pentru noi toţi. Putem beneficia acum de informaţii generate de dispozitive portabile inteligente, cum ar fi ceasurile sau brăţările inteligente. Spre exemplu, „The Up Band” de la Jawbone este o brăţară specială care colectează informaţii despre utilizatori referitoare la consumul de calorii, nivelul de activitate şi felul în care ei dorm. În timp ce ea poate oferi indicii valoroase unui utilizator unic, valoarea ei reală rezidă în colectarea şi analiza datelor tuturor utilizatorilor. În cazul „Jawbone”, compania colectează acum peste 60 de ani de somn în fiecare noapte de la utilizatorii săi, acestea fiind date valoroase. Alta zona unde putem beneficia de analiza „Big Data” este găsirea unui partener – în mediul online. Cele mai multe site-uri online de matrimoniale folosesc instrumente şi algoritmi pentru a ne găsi cei mai potriviţi parteneri.

4. Îmbunătăţirea sănătăţii şi a serviciilor medicale

Puterea de calcul a „Big Data” ne permite să înţelegem întregile şiruri de ADN în câteva minute, să găsim noi tratamente pentru boli şi să anticipăm potenţiale epidemii. Gândiţi-vă la ce s-ar putea întâmpla atunci când toate datele individuale colectate de la utilizatorii de ceasuri inteligente şi dispozitive portabile vor putea fi folosite pentru a preveni apariţia bolilor. Studiile clinice din viitor nu vor fi limitate de probe de mici dimensiuni, ci ar putea viza întreaga populaţie.

Tehnici „Big Data” sunt deja folosite pentru a monitoriza copiii într-o unitate specializată pentru copii născuţi prematur sau bolnavi. Prin înregistrarea şi analiza modelului bătăilor inimii şi respiraţiei fiecărui copil, unitatea a fost capabilă să dezvolte algoritmi care acum pot prezice infecţii cu 24 de ore înainte de apariţia oricărui simptom fizic. Astfel, echipa poate interveni mai devreme pentru a salva copiii într-un mediu în care fiecare oră contează. Ceea ce este şi mai important, analiza „Big Data” ne permite să monitorizăm şi să prezicem evoluţia epidemiilor şi focarelor de boli. Integrarea datelor din dosarele medicale cu analiza mediului social ne permite să monitorizăm focare de gripă în timp real, doar prin ascultarea a ceea ce postează oamenii, cum ar fi "Mă simt rău astăzi – sunt în pat cu o răceală".



5. Îmbunătăţirea performanţelor sportive

Cele mai multe sporturi de elită au îmbrăţişat acum analiza „Big Data”. Există instrumente precum „IBM SlamTracker” pentru turnee de tenis. Folosind analiza video, care urmăreşte performanţa fiecărui jucător într-un meci şi tehnologia cu senzor din echipamentele sportive ne permite să obţinem feedback (prin intermediul telefoanelor inteligente şi a serverelor „cloud”) referitor la felul în care se desfăşoară jocul şi să oferim metode de îmbunătăţire. Multe echipe de sport de elită urmăresc sportivii în afara mediului de antrenament – folosind tehnologia inteligentă pentru a urmări hrana şi somnul necesar, precum şi conversaţiile sociale pentru a monitoriza fericirea emoţională.

6. Îmbunătăţirea domeniului ştiinţei şi al cercetării

Domeniul ştiinţei şi al cercetării este în prezent transformat de noile posibilităţi pe care le oferă „Big Data”. Luaţi, de exemplu, CERN, laboratorul elveţian de fizică nucleară cu al său „Large Hadron Collider”, cel mai mare şi cel mai puternic accelerator de particule. Experimentele realizate pentru a debloca secretele universului - cum a început şi funcţionează - generează cantităţi uriaşe de date. Centrul de date CERN are 65.000 de procesoare de analiză pentru cei 30 petabytes de date, folosind puterea de calcul a miilor de calculatoare distribuite pe 150 de centre de prelucrare a informaţiei din întreaga lume. Asemenea puteri de calcul pot fi folosite în multe alte domenii ale ştiinţei şi cercetării.

7. Optimizarea performanţei dispozitivelor şi a maşinăriilor

Analiza „Big Data” ajută maşinăriile şi dispozitive să devină mai inteligente şi mai independente. De exemplu, instrumente „Big Data” sunt utilizate pentru a opera modul de conducere automat Google. Toyota Prius este dotat cu aparat de fotografiat, GPS, precum şi computere puternice şi senzori de conducere în siguranţă pe drum fără a fi nevoie de intervenţia oamenilor.

8. Îmbunătăţirea sistemelor de securitate şi a eficienţei poliţiei

„Big Data” este aplicat masiv în îmbunătăţirea securităţii, pentru a permite aplicarea legii. Sunt deja faimoase dezvăluirile Agenţiei Naţionale de Securitate (NSA) în SUA, care foloseşte analiza „Big Data” pentru a dejuca comploturile teroriste. Alţii utilizează astfel de tehnici pentru a detecta şi preveni atacurile cibernetice, forţele de poliţie putând prinde criminali, prezice activitatea criminală şi detecta tranzacţii frauduloase.

9. Îmbunătăţirea şi optimizarea oraşelor şi ţărilor

„Big Data” este utilizat, de asemenea, pentru a îmbunătăţi diverse aspecte ale oraşelor noastre. De exemplu, permite oraşelor să optimizeze fluxurile de trafic bazându-se pe informaţii din trafic în timp real, precum şi pe informaţii de pe reţelele sociale şi date meteorologice, astfel minimizând ambuteiajele. Un număr de oraşe implementează în prezent analiza datelor cu scopul de a se transforma în „oraşe inteligente”, caz în care procesele de infrastructură şi utilităţi sunt grupate toate împreună.

10. Tranzacţiile financiare

Ultima categorie prezentată de aplicaţii ale „Big Data” se referă la tranzacţiile financiare. Tranzacţiile de înaltă frecvenţă (HFT) reprezintă o zonă unde datele sunt foarte utilizate. Aici, algoritmii sunt utilizaţi pentru a lua decizii de tranzacţionare. Majoritatea



tranzacţionării de capital are loc prin algoritmi de date, care iau din ce în ce mai mult în considerare semnalele de pe reţelele sociale şi site-uri de ştiri pentru a lua, cumpăra şi vinde decizii în câteva secunde.

Inovaţiile tehnologice care au facilitat apariţia Big Data pot fi, în general, combinate în două familii: pe de o parte tehnologia de stocare, alimentată în special de dezvoltarea Cloud Computing. Pe de altă parte, apariţia tehnologiilor de prelucrare adecvate, inclusiv dezvoltarea de noi baze de date potrivite pentru date nestructurate (Hadoop) şi dezvoltarea modurilor de calcul de înaltă performanţă (MapReduce). Aceste două inovaţii, sprijinite de Google şi Yahoo, au pus bazele actuale de prelucrare Big Data: astfel este posibil a se procesa volume mari de date într-un timp scurt - redus cu aproape 50 de ori mai mult de tehnologii anterioare - pentru toate tipurile de date.

3.4. Impactul Big Data şi Analytics asupra sistemului public Aspectele prezentate în această secţiune au la bază, în principal, capitolul 2- „Big

Data and Analytics for Government Innovation” din lucrarea (Morabito, 2015).

3.4.1. Evoluţii recente ale sistemului public În mod tradiţional, ideea de bază pentru activităţile specifice serviciului public a

constituit-o relaţia tranzacţională dintre cetăţeni şi administraţia publică: aceştia plătesc taxe şi beneficiază în schimb de diferite domenii, sănătate, educaţie, întreţinerea drumurilor şi altele.

O primă modificare semnificativă de dată recentă o reprezintă plasarea cetăţeanului în rolul de partener. Astfel oamenii au grijă sporită de rezolvarea propriilor probleme. Informaţia de tip Social Media şi telefoanele de tip smart pot uşura interacţiunea dintre cetăţeni şi administraţia publică şi pot amplifica de asemenea comunicarea şi implicarea comunităţilor publice. Un exemplu îl constituie aplicaţiile care permit cetăţenilor şi rezidenţilor să raporteze şi să furnizeze informaţie administraţiei publice locale despre toate problemele cetăţeneşti, de la gropi la graffiti, trotuare sparte sau lumini stradale defecte. Acest lucru se poate face sub anonimat sau nu, se pot încărca fotografii care se pot fixa pe o hartă a străzii. Acest raport este trimis consiliilor şi progresul rezolvării sale este urmărit online.

O a doua tendinţă în curs de afirmare pe baza evoluţiei suportului tehnologic necesar o constituie democraţia online prin care cetăţenilor le este transferată putere de decizie pe teme de interes ale comunităţii din care fac parte. Deocamdată această soluţie este exersată la nivel local, dar utilizarea sa pentru probleme de interes global nu va întârzia, ceea ce va implica în mod evident probleme specifice Big Data: volume mari de date nestructurate, culese şi prelucrate în timp real.

O a treia tendinţă relevantă în contextul acestui raport o constituie dezvoltarea marilor aglomerări urbane, a căror dinamică de creştere generează probleme de mare complexitate pentru sistemele publice respective. Abordarea tehnologică în curs de afirmare o constituie arhitecturile de tip „smart city”, bazate pe Internetul obiectelor şi Big Data.



3.4.2. Oportunităţi specifice serviciilor publice Externalizarea unui serviciu devine un termen obişnuit şi deschide noi perspective

pentru crearea de valoare publică gratuită, angajament civic şi transparenţă. Un exemplu îl constituie un serviciu online proiectat pentru ajutarea cetăţenilor în raportarea diferitelor probleme din vecinătate, printr-o interfaţă web, Facebook sau aplicaţii ale telefoanelor mobile. Procesul este urmărit online, similar modului în care companiile de logistică urmăresc livrarea pachetelor la destinaţie, cu deosebirea că informaţia este publicată pe Twitter şi Facebook pentru public. Se elimină timpul pierdut prin deplasarea către instituţii pentru a scrie un memoriu sau contactare telefonică. Acum, toţi cei care au un telefon mobil de tip smart pot raporta diferitele probleme. În plus, contactul direct şi trasabilitatea dau oamenilor satisfacţia că au contribuit la a face bine.

Interacţiunea directă dintre cetăţeni şi administraţia publică încapsulează trei obiective ale administraţiei publice: (i) angajarea cetăţenilor în viaţa publică; (ii) reducerea costurilor serviciilor publice, datorită voluntariatului oamenilor şi a scutirii de taxe; (iii) îmbunătăţirea transparenţei proceselor serviciilor publice.

Internetul lucrurilor (IoT) se referă la reţeaua dispozitivelor formate din senzori care măsoară mediul înconjurător, elemente de acţionare care trimit reacţie de răspuns, procesoare care gestionează şi stochează datele generate, noduri care coordonează administrarea acestor. IoT reprezintă suportul pentru aplicaţii şi servicii avansate de tip case inteligente, aplicaţii de sănătate, transport inteligent, bazat pe comunicarea între dispozitive dotate cu senzori şi un anumit nivel de inteligenţă, care au capacitatea de culegere şi transmitere a informaţiei. IoT este esenţial pentru consolidarea conceptului de „smart city”.

Într-o a doua etapă este nevoie de soluţii de prelucrare eficientă a informaţiilor generate de infrastructurile IoT, pentru valorificarea lor în deciziile adoptate la nivelul comunităţilor beneficiare. În această tranziţie spre conceptul de „cognitive city” este esenţială utilizarea soluţiilor specifice Big Data şi BDA. Atât timp cât datele reprezintă materia primă a cunoaşterii, interpretarea acestor date poate fi realizată prin furnizarea de previziuni, cunoştinţe, aptitudini etc. Imprimarea documentelor atestă proprietatea individuală a ideilor, era digitală consacră co-proprietatea. Comunităţile online au devenit o importantă sursă de cunoştinţe şi idei noi. Disponibilitatea conceptului de “Big Data” arată că mai multe idei pot converge spre modul în care pot fi exploatate aceste date. O astfel de soluţie este Kaggle, o platformă online, care funcţionează ca un broker de cunoştinţe între companiile care au ca scop externalizarea concursurilor de modelare predictivă şi o reţea de peste 100.000 de specialişti (https://www.kaggle.com/).

Relaţiile de parteneriat de tip public-privat sunt promovate în aproape toate aspectele legate de furnizarea serviciilor publice. Cu privatizarea majorităţii utilităţilor şi tendinţa de externalizare, o mare parte a sectorului public în societăţile avansate este administrat de către organizaţiile private. Ne îndreptăm către o nouă fază a relaţiilor dintre organizaţiile publice şi private, aceea de parteneriat. Managementul Big Data are un rol central de jucat în sprijinirea deciziilor tuturor parteneriatelor, motiv pentru care guvernele au interesul să sprijine dezvoltarea acestui domeniu. Coroborat cu tendinţa de a creşte transparenţa şi controlul privind activitatea administraţiei publice şi de implicare a cetăţenilor în adoptarea deciziilor, aceste parteneriate au implicaţii asupra proprietăţii şi gestionării

https://www.kaggle.com/



datelor în toate serviciile publice, de la sănătate şi resurse naturale la publicitatea datelor la contractare, infrastructura cheltuielilor publice şi ajutorul de stat către terţi. Există câteva argumente care motivează utilitatea acestor parteneriate:

- lipsa de experienţă în administraţia publică privind domeniile respective şi modalităţile de susţinere şi evaluare a acestora,

- capacitatea financiară şi tehnică a partenerilor privaţi de a investi în infrastructura informatică necesară (Big Data, cloud),

- experimentarea noilor soluţii tehnologice la scară mică, ceea ce facilitează ulterior implementarea la nivelul administraţiei publice.

Legat de furnizarea serviciile publice, tehnologiile Big Data oferă soluţii referitoare la autentificare şi managementul identităţii, combaterea fraudei, îmbunătăţirea monitorizării atacurilor de securitate.

O tehnologie esenţială asociată Big Data în administraţia publică o constituie cloud computing, care facilitează acoperirea teritorială cu soluţii de e-guvernare, independent de nivelul de pregătire al unităţilor administraţiei locale pentru furnizarea de e-servicii. Arhitectura orientată pe servicii facilitează furnizarea de servicii compuse, în care un client poate fi un cetăţean sau o întreprindere. Această tendinţă, numită deja C-Government, este confirmată prin numărul tot mai mare de unităţi ale administraţiei publice, firme sau cetăţeni care îşi păstrează datele în cloud pentru a beneficia de avantajul accesării lor de pe orice echipament, oriunde, oricând.

3.4.3. Provocări specifice sectorului public Proprietatea datelor: caracterul deschis al datelor generează probleme majore legate

de proprietatea acestora şi, implicit, de responsabilitatea privind administrarea, memorarea, protecţia, utilizarea şi abuzurile în utilizarea acestor date. Pe de altă parte trebuie avut în vedere că o mare parte din datele utilizate în sectorul public au caracter privat, în sensul că sunt fie date personale ale cetăţenilor, fie date care descriu funcţionarea serviciului public. Aceasta înseamnă că instituţiile publice la nivel central şi local sunt custodele datelor cetăţenilor, obţinând acest rol în schimbul furnizării de servicii publice în beneficiul acestora. O problemă sensibilă din acest punct de vedere o reprezintă datele generate de dispozitivele de monitorizare a localizării şi comportamentului cetăţenilor.

Calitatea datelor: Big Data poate amplifica repercusiunile şi implicaţiile calităţii slabe a datelor, şi este o problemă deosebit de importantă pentru administraţiile publice şi cetăţeni deopotrivă. Datele înregistrate pot fi eronate, fragmentate sau incomplete din cauza presiunii generate de volumul mare de muncă şi de interfeţele utilizator. Datele ar trebui verificate din punct de vedere al caracterului complet, al conformităţii, consistenţei, acurateţei, duplicării şi integrităţii, al existenţei bunelor practici legate de verificarea calităţii datelor. Datele de calitate slabă pot rezulta din integrarea surselor de date, din federalizarea şi conglomerarea datelor. Este deci foarte importantă tratarea informaţiilor cu cea mai mare rigoare, având în vedere sensibilitatea serviciilor publice faţă de acest aspect, în primul rând prin prisma implicaţiilor de natură juridică pe care le poate genera.



Intimitatea şi libertăţile civile: determinarea profilului cetăţenilor pe baza stării lor de sănătate, a locaţiei, a consumului de energie electrică, a activităţii online, creşte riscul de discriminare şi excludere. Când acestea implică accesul la serviciile publice, cresc repercusiunile. Promisiunea Big Data se bazează pe posibilitatea de previziune a unor posibile atacuri. Dacă, de exemplu, se pot prevedea potenţiale spargerile dintr-o anumită zonă, administraţia locală poate creşte securitatea în această zonă pentru a preveni astfel de incidente. Această promisiune se bazează pe utilizarea algoritmilor de predicţie care utilizează diverse categorii de big date, de exemplu informaţiile sociale. O asemenea abordare, probele sunt înlocuite cu estimări de risc, ceea ce poate fi considerată o restrânge a libertăţilor civile. In plus, odată cu capabilităţile predictive crescute vine şi responsabilitatea crescută de a evita aceste ameninţări, care poate determina o atitudine mai conservatoare din partea administraţiei publice în abordarea riscurilor sociale. O problema sensibilă o constituie egalitatea în ceea ce priveşte tratamentul public al persoanelor şi grupurilor care nu participă pe deplin la societatea informaţională, deoarece nu au mijloacele sau timpul necesare. Statisticile indică mari diferenţe în implicarea digitală de la o ţară la alta, pe grupe de vârstă, clase socio-economice, mediul urban sau rural. Riscul constă în faptul că guvernele care se bazează preponderent pe Big Data pot neglija interesele celor care rămân în afara ariei de acoperire a acestei soluţii de colectarea a datelor referitoare la nevoi, interese, opinii.

Recrutarea de personal competent: având în vedere deficitul analiştilor de date, sectorul public se confruntă cu greutăţi în a atrage aceşti analişti. Guvernele trebuie să ia în considerare numărul mare de bănci, organizaţii de asigurări, comercianţi online şi organizaţiile ce se ocupă de consultanţă aflate în competiţie pentru astfel de resurse, pentru a putea păstra analişti talentaţi. Pe de altă parte, guvernele pot folosi universităţile – o resursă insuficient folosită în special în Europa, în ciuda competenţelor relevante pentru sectorul public.

3.4.4. Beneficii specifice sectorului public Organizaţiile care reuşesc să abordeze cele 4 caracteristici ale Big Data au potenţialul

de a furniza noi servicii, de a reduce costurile, de a optimiza investiţiile TIC existente. Câteva exemple furnizate de (Oracle, 2012) sunt prezentate în continuare.

Opinia alegătorilor: informaţia de urmărire pe site-uri, blog-uri, feed-uri Twitter şi surse mass-media poate ajuta factorii de decizie să prioritizeze abordarea de noi servicii sau zone neacoperite de potenţiale revendicări civile.

Detectarea şi prevenirea fraudelor: organizaţiile colectoare de venituri sau cele furnizoare de servicii sociale pot urmări şi analiza mai eficient activităţile cetăţenilor, pentru a identifica modele de comportament anormal care pot conduce la greşeli costisitoare sau fraudă.

Analiza economică: prin interpretarea datelor din mai multe surse, economiştii guvernamentali pot corela mai bine nivelul de volatilitate al situaţiei curente cu previziunile financiare mai precise.



Sănătate: analiza tendinţelor din sistemul de sănătate publică şi din înregistrările pacienţilor pot ajuta organizaţiile din domeniu să răspundă proactiv la ameninţările la adresa sănătăţii, îmbunătăţind în acelaşi timp îngrijirea pacientului şi diminuând frauda.

Guvernarea deschisă: libera circulaţie a informaţiei de la organizaţii către cetăţeni promovează o mai mare încredere între cetăţeni şi guvern.

Colectarea taxelor: organizaţiile pot integra date structurate şi nestructurate din social media şi din alte surse pentru a valida informaţiile de plată a taxelor sau pentru a decide asupra unui audit.

Identificarea ameninţărilor: investigarea informaţiilor financiare, a ştirilor şi social media (wiki, bloguri, site-uri web) pot ajuta organizaţiile specializate să descopere corelaţii în finanţarea şi transportul unor materiale periculoase.

Securitatea cibernetică: soluţiile Big Data pot colecta, organiza şi analiza cantităţi imense de date din reţelele de calculatoare ale administraţiei publice, pentru a sprijini investigarea şi contracararea unor atacuri cibernetice.



4. Criterii de selecţie a celor mai reprezentative tehnologii, bune practici şi soluţii de sisteme informaţionale guvernamentale

Big Data se referă la posibilitatea de utilizare a volumului, din ce în ce mai mare, de date. După cum spunea Eric Schmidt, Executive Chairman la Google, de la începuturile civilizaţiei până în anul 2003, umanitatea a generat cinci exabytes de date. Aceeaşi cantitate de date este produsă, acum, în două zile.

Pentru stabilirea unor criterii în vederea alegerii şi utilizării tehnologiilor şi sistemelor informaţionale de tip Big Data este necesar să se stabilească nişte criterii de evaluare a necesităţii acestora în cadrul sistemelor informaţionale guvernamentale, pe baza măsurării performanţelor actuale şi a necesităţilor analitice pentru cantităţi masive de date de diferite tipuri, în vederea atingerii unor obiective de performanţă administrativă şi de conducere eficientă.

4.1. Fundamentarea necesităţii abordării Big Data în cadrul sistemelor informaţionale guvernamentale

Tendinţe ale domeniului Big Data în cadrul Ciclului de promovare a tehnologiilor emergente

Domeniul Big Data, ca şi celelalte tehnologii şi soluţii de procesare a datelor din domeniul informaticii şi comunicaţiilor, are diferite etape de cercetare, fundamentare şi de utilizare care sunt surprinse foarte bine în Figura 17, adaptată după un studiu realizat de Gartner în anul 2014 despre aplicarea tehnologiilor emergente (Rivera, 2014).

Figura 17. Ciclul de execuţie pentru tehnologiile emergente

Simț Bioacustic S ecuritate digitală

Vehicule autonome

Asistent personal virtual Spațiu de lucru inteligent Casă

Interfață creier calculator

Auto

Sporirea capacității

Calcul

Definire prin software a

Ecrane volumetrice și holografice S isteme de bioprintare 3D

Roboți

Calcul

Biocipuri Business neural

Operații analitice

Știința d l

Consilieri inteligenți Tipărire 3D pentru

Traducere vorbire-în-

Internetul lucrurilor Răspunsuri la întrebări în limbaj

Interfețe utilizator pentru dispozitive portabile purtate pe corp

O Depășit înainte de platou

Monede criptate Procesarea evenimentelor complexe

Sisteme de management al bazelor de date în memorie Operații analitice asupra conținutului Calcul în Cloud

Gamification (elemente de Realitatea îmbogățită

Servicii de comunicație M-to- Monitorizare mobilă a sănătății

Calcul în

NFC

Realitate virtuală Controlul

Operații analitice în

Fluxuri de

Printare 3D în

Scanare 3D

Telematică consumator

Recunoaștere vorbire

Declanșare inovație Vârf de așteptări exagerate

Prin deziluzie Panta iluminării Platoul productivității

Platoul va fi atins în: Mai puțin de 2 ani 2 la 5 ani 5 la 10 ani Mai mult de 10 ani

timp

Așteptări

Big Data-(date imense)



Provocări şi consideraţii esenţiale în realizarea de sisteme Big Data în domeniul guvernamental

Următoarele criterii şi direcţii de abordare a realizării de sisteme informatice bazate pe utilizarea Big Data trebuie avute în vedere în organizaţiile guvernamentale (ExecBlueprints, 2013):

Arhitectura: • În legătură cu multele tipuri de arhitecturi trebuie stabilit care este cea mai bună

alegere. Există instrumente apropiate ca valoare, între care, cu greu se poate face alegerea. Sursele deschise (open source) au un rol foarte important în domeniul Big Data. În această alegere a viitoarei arhitecturi şi a instrumentelor trebuie pornit de la analiza a ceea ce există deja în folosinţă.

Instrumente: • Este necesar să se analizeze diferite instrumente pentru a stabili cea mai bună opţiune.

În urma analizelor se pot trage diferite concluzii:

o Identificarea unei unităţi de business pentru calcularea utilităţii utilizării Big Data;

o Identificarea unui nou proces sau îmbunătăţirea unui nou proces ca urmare a analizării Big Data.

Guvernarea datelor: • Cine deţine datele;

• Cum se vor trata securitatea datelor, integritatea şi respectarea reglementărilor;

• Cine va administra depozitul de date. Operaţii analitice:

• Cum se încadrează operaţiile analitice în organizaţie;

• Dacă se utilizează operaţii analitice descriptive şi predictive în cadrul activităţii de inteligenţă de business;

• Cât de sofisticat este procesul.

Utilizarea Cloud-ului: • Va deveni Cloud-ul un egalizator sau va promova mai multe preocupări cu privire la

guvernarea datelor?

• Se vor putea realiza colectarea, partajarea şi analizarea depozitelor mai mari de date de la distanţă?

Returnarea investiţiei: • Producerea de analize şi metrici pentru determinarea efectului pe care l-a produs

resursele utilizate.

Priorităţi ale managerului de Big Data: • Utilizarea celor mai bune practici la nivel de întreprindere şi implementarea lor în

unităţile operaţionale;

• Asigurarea faptului că politicile de management aderă la reglementările în vigoare;

• Căutarea unor căi noi de utilizare în comun a datelor în întreprindere şi dezvoltarea de operaţii analitice sofisticate.

Provocările Big Data în domeniul sistemelor informaţionale guvernamentale:



• Stabilirea domeniilor în care acestea sunt necesare prin analiza stării actuale a sistemelor informaţionale, prin identificarea unor posibile necesităţi de analiză şi decizie şi stabilirea instrumentelor şi resurselor necesare pentru realizarea obiectivelor propuse.

Moduri de utilizare: • Big Data pentru consumatori;

• Big Data pentru business;

• Big Data pentru cercetare. Big Data şi Ştiinţa Datelor:

• Deosebirea dintre Big Data şi utilizarea tradiţională a datelor ce pot fi procesate în cadrul organizaţiei.

• Deosebirea dintre abordarea Big Data (bazată pe Hadoop), depozitele de date de întreprindere (Data Warehouse) şi pieţele de date (Data Mart).

Etica în cazul Big Data: • Provocările anonimităţii;

• Provocările confidenţialităţii. Surse şi structuri Big Data:

• Date generate de oameni;

• Date generate de maşini;

• Date structurate;

• Date nestructurate.

Criterii generale de satisfacere a cerinţelor Big Data

Cerinţe referitoare la procesarea în timp real Exemple de utilizare a procesării în timp real a Big Data pentru a satisface necesitatea

de a răspunde unei probleme care este sensibilă la timp şi este critică pentru activităţile respective (Hurwitz, 2013):

• Detectarea performanţelor unui echipament din spital

• Detectarea riscurilor de intruziune potenţiale

• Monitorizarea unei excepţii cu o nouă piesă de informaţii, cum ar fi frauda / inteligenţa

• Monitorizarea fluxurilor de ştiri şi mass-media socială pentru a determina evenimente care pot afecta pieţele financiare, cum ar fi reacţia unui client la anunţarea unui produs nou

• Schimbarea locului de plasare a unui anunţ în timpul unui eveniment sportiv important pe baza unor fluxuri Twitter în timp real

• Furnizarea unui cupon pentru un client pe baza a ceea ce a cumpărat de la punctul de vânzare.

Ţinând seama de varietatea surselor de informaţii şi de viteza cu care acestea vin se poate analiza dacă acea problemă poate fi rezolvată cu metodele tradiţionale de management a informaţiei sau sunt necesare a fi utilizate capabilităţile oferite de tehnologiile Big Data.



În acest context, de procesare în timp real a unei cantităţi enorme de informaţii variate, care se produc/vin la viteze mari, este necesar de luat în considerare criterii de satisfacere a cerinţelor infrastructurii care să suporte capabilităţi specifice procesării în timp real:

• Latenţă mică. Acest criteriu se referă la puterea de calcul a sistemului de calcul şi la constrângerile reţelei. Pentru procesarea în timp real este necesară o latenţă mică, astfel încât serviciile de procesare să se execute în mediul respectiv într-un timp cât mai scurt.

• Scalabilitate. Acest criteriu se referă la capabilitatea de a se realiza un anumit nivel de performanţă chiar şi în cazul unor încărcări mai mari.

• Versatilitate. Acest criteriu se referă la posibilitatea ca sistemul să suporte atât fluxuri de date structurate cât şi nestructurate.

• Format nativ. Acest criteriu se referă la posibilitatea de a mări performanţele procesării în cazul în care datele sunt utilizate în forma lor nativă, deoarece transformarea datelor necesită timp suplimentar.

Criterii de selecţie şi analiza cerinţelor Cele mai importante dimensiuni ale Big Data sunt: volumul (se referă la cantitatea

enormă de date care sunt generate în fiecare secundă), viteza (se referă la viteza cu care sunt generate date noi şi viteza cu care se mişcă datele sub formă de mesaje care pot fi analizate în timp real), varietatea (se referă la utilizarea unor tipuri diferite de date), veridicitatea (se referă la cât de încredere sau de îndoielnice sunt datele).

Alte caracteristici asociate Big Data sunt:

• Nesiguranţa (uncertainty)

• Scalabilitatea

• Procesarea în timp real.

Unităţi de măsură pentru Big Data În continuare enumerăm câteva unităţi noi de măsură pentru Big Data (McFedries,

2015):

• 1 gigabyte = 1.000 megabytes

• 1 terabyte = 1.000 gigabytes

• 1 petabyte = 1.000 terabytes

• 1 yottabyte = 1.000.000.000 petabytes = 1.000.000.000.000 terabytes

• 1 brontobytes = 1000 yottabytes = 1.000.000.000.000.000 terabytes (o mie de trilioane)

• 1 geopbyte = 1.000 brontobytes

• Hellabytes = al naibii de foarte multe date.



4.2. Criterii de evaluare a infrastructurii hard Infrastructura hard pentru Big Data trebuie să conţină tehnologii care să permită

manipularea unui volum uriaş de date:

• Pentru stocarea datelor este necesară o platformă de Cloud Computing care să conţină tehnologii de virtualizare.

• Pentru transferul datelor este necesară o tehnologie performantă de reţea.

• Resursele trebuie administrate prin intermediul unei tehnologii de monitorizare a resurselor.

4.2.1. Criterii de utilizare ale Cloud Computing pentru Big Data Cloud-ul are un rol foarte important în domeniul Big Data. Cloud-ul permite

utilizatorilor să acceseze resursele de calcul şi de stocare care le sunt necesare, cu puţin suport IT, sau fără a fi necesar să cumpere mai mult hardware sau software decât au nevoie. În funcţie de cerinţele utilizatorului se pot adăuga sau micşora resursele în timp real pe baza schimbării cerinţelor.

Calculul în Cloud este o metodă de furnizare a unor resurse de calcul partajate în care sunt incluse aplicaţii, calcul, stocare, reţele, dezvoltare şi platforme de implementare, precum şi procese de business (Hurwitz, 2013). În norul de calcul (cloud computing) orice poate fi furnizat ca serviciu: putere de calcul, infrastructura de calcul, aplicaţii, procese de business, date şi metode analitice.

Exemple de echipamente obişnuite (commodity hardware) în contextul Hadoop

Caracteristicile principale ale echipamentelor obişnuite (commodity hardware) utilizate în mediul Hadoop sunt următoarele:

• Clusterele Hadoop funcţionează pe servere.

• Serverele obişnuite utilizate în clusterele Hadoop au o raţie medie între spaţiul de pe disc şi memorie (spre deosebire de echipamentele specializate cu memorie mare şi multe CPU).

• Serverele nu sunt proiectate în mod specific ca părţi ale unui mediu de stocare şi procesare distribuit, dar au fost însuşite pentru acest rol în Hadoop.

Conform firmei Cloudera specificaţiile hardware sugerate pentru clusterul Hadoop sunt (Kevin, 2013):

• Patru discuri de 1 TB în configuraţie JBOD (Just Bunch Of Disks)

• Două unităţi centrale (CPU) cu „quad core”, funcţionând la 2-2.5 GHz.

• 16-24 GBs de RAM (24-32 GB dacă se utilizează Hbase)

• Ethernet la 1 Gigabit/s

OpenLogic sugerează că un cluster mai puternic ar trebui să fie constituit din:

• şase hard discuri de câte 2 TB, cu RAID 1 peste două din acele discuri

• două unităţi centrale (CPU) cu „quad core”



• 32-64 GBs de RAM cu ECC (Error Correcting Code)

• Ethernet la 2-4 Gigabits

4.2.2. Existenţa backbon-ului 5G pentru aplicaţii Big Data şi Internetul lucrurilor. Backbone-ul pentru aplicaţiile Big Data şi pentru Internetul lucrurilor (Internet of

Things-IoT) va fi, în viitor, realizat de reţelele 5G. Intenţia tehnologiei 5G este aceea de îmbunătăţire de sute de ori a vitezei de comunicaţie faţă de tehnologiile 4G. 5G va permite transmisia a zeci de megabiţi pe secundă către mii de utilizatori mobili, şi ajungând la o viteză de un gigabit pe secundă în cadrul birourilor. Unele din primele demonstraţii de comunicaţii 5G s-au făcut la Austin, Texas, în anul 2015, la săptămâna National Instruments (McCormick, 2015).

4.3. Criterii de evaluare a tehnologiilor şi soluţiilor software

4.3.1. O clasificare a tehnologiilor Big Data Big Data aduce multe oportunităţi, dar include şi multe provocări. Deoarece

tehnologiile precedente, bazate pe modelul relaţional al datelor nu reuşeşte, printre altele, să satisfacă cerinţele de procesare în timp real a fluxurilor de date mari, a fost necesar să se dezvolte o nouă generaţie de tehnologii informatice care să se ocupe de Big Data.

Tehnologiile care sunt încorporate în Big Data sunt (Loshin, 2013):

• Paralelismul masiv,

• Volumul uriaş de date,

• Distribuirea datelor,

• Reţelele de mare viteză,

• Calcul de înaltă performanţă,

• Managementul Thread-urilor şi a sarcinilor (taskurilor),

• Analizarea şi mineritul datelor (data mining and analytics).

Utilizând o altă clasificare, bazată pe ierarhia de procesare a datelor, tehnologiile Big Data pot fi clasificate în cinci categorii:

1. Tehnologii care asigură infrastructura:

• Platforma Cloud Computing

• Stocarea în Cloud

• Tehnologia de virtualizare

• Tehnologia de reţea

• Tehnologia de monitorizare a resurselor 2. Achiziţia datelor

• Bus-ul pentru date

• Instrumentele ETL 3. Stocarea datelor



• Sistem de fişiere distribuite

• Baze de date relaţionale

• Tehnologii NoSQL

• Integrarea bazelor de date relaţionale şi a bazelor de date neraţionale

• Baze de date din memorie 4. Calculul datelor

• Interogarea datelor, Statistici şi Analize

• Data mining (mineritul datelor - extragerea cunoştinţelor din date) şi Analiza Grafurilor de predicţie

• Inteligenţa business-ului (Business Intelligence –BI) 5. Afişare şi interacţiune

• Grafice şi Rapoarte

• Instrumente de vizualizare

• Tehnologia realităţii sporite (Augmented Reality Technology).

4.3.2. Criterii de selecţie a celor mai reprezentative servicii Big data as a service (BDaaS) (Big Data ca serviciu) se referă la furnizarea de

instrumente pentru analize statistice sau de informaţii de către un furnizor din afară care ajută organizaţiile să înţeleagă şi să utilizeze buna cunoaştere acumulată din cantităţile mari de informaţie în scopul obţinerii unui avantaj competitiv. BDaaS permite procesarea datelor nestructurate, care sunt generate în cadrul unei organizaţii, să fie procesate de un furnizor care are competenţă în analize predictive şi în prelucrarea seturilor mari de date. BDaaS poate lua două forme: software care asistă la procesarea datelor, sau printr-un contract de servicii din partea unei echipe de specialişti din domeniul datelor.

BDaaS este o formă de servicii administrate de o terţă parte contractantă, similare cu Software as a Service sau Infrastructure as a Service. Big Data ca serviciu se bazează cel mai des pe stocarea în Cloud pentru a menţine accesul continuu la date, atât pentru organizaţia care deţine informaţia, cât şi pentru furnizorul care lucrează cu ea.

4.3.3. Stiva metodelor analitice predictive pentru Big Data în timp real În Figura 18 (Adaptare după prezentarea lui David Smith, “Real-Time Big Data

Analytics: From Deployment To Production”) este prezentată stiva metodelor analitice predictive pentru Big Data în timp real.

În stratul de date există date structurate în RDBMS, NoSQL, Hbase sau Impala; date nestructurate în MapReduce din Hadoop; date în flux din web, media socială, senzori şi sisteme operaţionale; şi capabilităţi limitate pentru realizarea de operaţii analitice descriptive. În acest strat se găsesc, de asemenea, instrumente ca Hive, Hbase, Storm şi Spark. Acest strat s-ar putea împărţi în două substraturi: unul pentru stocare şi, al doilea, pentru procesarea interogărilor.



Următorul strat este cel analitic, care este situat deasupra celui de date. Stratul analitic include un mediu de producţie pentru implementarea notării în timp real şi operaţii analitice dinamice; un mediu de dezvoltare pentru construirea de modele şi o piaţă de date locale care este actualizată în mod periodic din stratul de date, situat lângă maşina analitică pentru îmbunătăţirea performanţei.

Deasupra stratului analitic este stratul de integrare. Acest strat deţine aplicaţiile end-user şi motoarele de reguli sau maşinile de tratare a evenimentelor complexe (CEP) şi un API pentru operaţii analitice care intermediază comunicaţia între dezvoltatorii de aplicaţii şi specialiştii în date.

Figura 18. Stiva metodelor analitice predictive pentru Big Data în timp real

Cel mai de sus strat este stratul de decizie. Acesta poate include aplicaţii end-user cum sunt aplicaţii web pentru desktop, mobile şi interactive dar şi software de inteligenţă de business (business intelligence). Acest strat este cel pe care îl folosesc cei mai mulţi utilizatori. În acest strat analiştii de business, şefii firmelor şi clienţii interacţionează cu sistemul analitic Big Data în timp real.

Stiva metodelor analitice predictive pentru Big Data în timp real

Mediu de producţie pentru Revolution R Enterprise

Pieţe de date locale

Mediu de dezvoltare de Revolution R Enterprise

Ana

litic

Hadoop Dispozitive de depozitare a datelor

Alte surse de date

Dat

e

Aplicaţii desktop (de ex. Excel)

Inteligenţă de business

Aplicaţii Web şi mobile interactive D

eciz

i

Servicii Web RevoDeployR

Inte

gra Motor de reguli



4.3.4. Criterii utilizate în alegerea modului de stocare şi procesare primară a datelor Stocarea Big Data

Pentru stocarea datelor sunt necesare instrumente şi servicii care să captureze, valideze şi să asambleze elementele de date mari în colecţii contextuale relevante. Pentru aceasta este necesar un sistem de fişiere distribuite care să permită descompunerea fluxurilor de date şi care să ofere capacitate de stocare şi de scalare.

Stocarea datelor se poate face în Cloud utilizând servicii specifice: IaaS, PaaS, SaaS şi DaaS.

Infrastructura ca Serviciu (Infrastructure as a Service - IaaS) este o formă de calcul în Cloud care furnizează resurse de calcul virtualizate peste Internet. IaaS este una din cele trei mari categorii ale serviciilor de calcul în Cloud, alături de Software as a Service (SaaS) şi Platform as a Service (PaaS). Date ca serviciu (Data as a Service – DaaS) se referă la un serviciu din Cloud prin care datele sunt furnizate la cerere utilizatorului indiferent de situarea geografică a furnizorului şi a consumatorului.

În cadrul acestor tehnologii de stocare mai sunt incluse şi următoarele servicii:

• Servicii de serializare, care sunt necesare pentru stocarea persistentă a datelor şi pentru apelurile RPC.

• Servicii de coordonare, care sunt necesare pentru construirea aplicaţiilor distribuite.

• Servicii de workflow, care sunt necesare pentru planificarea job-urilor şi pentru furnizarea unei structuri pentru sincronizarea elementelor de procesare în cadrul straturilor.

Problematica transferului de fişiere de date mari (Big Data)

Organizaţiile în care se generează seturi mari de date nestructurate trebuie să le mute în diferite locuri de stocare uşor accesibile, utilizând, de exemplu, HDFS (Hadoop distributed file system) pentru a fi procesate cu metode analitice utilizând Hadoop.

Metodele obişnuite de transfer de date în cadrul reţelelor, cum sunt FTP şi HTTP nu sunt eficiente în aceste cazuri.

De exemplu, pentru realizarea unei analize eficiente a imaginilor de la camerele video de supraveghere utilizând un cluster Hadoop, este necesar ca datele video capturate în locaţii aflate la distanţă, să fie mai întâi transferate într-o zonă de stocare accesibilă clusterului. De exemplu, imaginile video HD (High Definition) necesită rate de înregistrate de 50Mbps. Soluţia aceasta a transferului unor cantităţi mari de date se găseşte în soluţiile SaaS/PaaS (software ca serviciu şi platformă ca serviciu) oferite de calculul în nor (cloud computing). Cloud-ul public oferă putere de calcul, reţelistică şi stocare, ceea ce dă companiilor şi organizaţiilor interesate acces la capabilităţi de analiză a datelor mari (Big Data).

4.3.5. Criterii în alegerea metodelor de stocare a datelor în sistemele Big Data În alegerea metodelor de stocare a datelor este necesar să se analizeze utilizarea

următoarelor variante de tehnologii de stocare, astfel încât să se poată alege cele mai bune soluţii:



• Sistem de fişiere distribuite

• Baze de date relaţionale

• Tehnologii NoSQL

• Integrarea bazelor de date relaţionale şi a bazelor de date neraţionale

• Baze de date din memorie

În alegerea metodelor de construire şi de utilizare a bazelor de date mari, astfel încât acestea să permită dezvoltarea de aplicaţii scalabile, se constată necesitatea analizării şi a comparării facilităţilor bazelor de date SQL şi cele NoSQL, principalul criteriu referindu-se la consistenţa datelor. Consistenţa datelor diferă între cele două tipuri de baze de date. Tehnologia SQL este utilizată pentru tranzacţii care se bazează pe proprietăţile ACID (Atomicitate, Consistenţă, Izolare şi Durabilitate).

În tabelul 3 se prezintă o comparaţie a celor mai importante caracteristici ale bazelor de date SQL şi NoSQL (Hurwitz, 2013).

Tabelul 3. Comparaţie a celor mai importante caracteristici ale bazelor de date SQL şi NoSQL

Maşină (Engine)

Limbaj de interogare

Reducere detalii (Map Reduce)

Tipuri de date

Tranzacţii Exemple

Relational SQL, Python, C

No Typed ACID PostgreSQL, Oracle, DB/2

Columnar Ruby Hadoop Predefinite şi typed

Da, dacă este activat

HBase

Graph Walking, Search, Cypher

No Untyped ACID Neo4J

Document Commands JavaScript Typed Nu MongoDB, CouchDB

Key-value Lucene, Commands

JavaScript BLOB, semityped

Nu Riak, Redis

După înţelegerea cerinţelor şi a tipurilor de date adunate şi a modului în care acestea vor fi utilizate este necesar ca ele să fie astfel organizate astfel încât acestea să fie consumate pentru analiză, raportare sau pentru aplicaţii specifice.

4.3.6. Comparaţii între conceptul de depozit de date (data warehouse) şi abordarea Big Data

Caracteristici generale ale depozitului de date (data warehouse)

Depozitele de date (data warehouse - EDW) sunt magazii de date integrate din una sau mai multe surse. În ele sunt stocate date curente şi date istorice (Sonra-1, 2015). Depozitele de date (warehouse) au fost construite pentru a ingera date structurate din sisteme tranzacţionale. Aceste sisteme sunt utilizate zilnic în activitatea de business şi includ HR, ERP, Vânzări şi Marketing etc. O dată cu evoluţia aplicaţiilor SaaS şi a Arhitecturii Orientate



pe Servicii (SOA) din ultimii ani, au fost introduse în EDW şi date semistructurate JSON şi XML.

Preluarea datelor se face în loturi, de obicei, în timpul nopţii. Datele de la surse sunt transferate în zone de aşteptare ce se află în infrastructura depozitului de date. Din zona de aşteptare, datele sunt încărcate în platforma ETL care realizează transformările solicitate, integrarea datelor şi sarcinile de curăţare. Uneori, mai sunt utilizate şi instrumente dedicate pentru calitatea datelor, managementul datelor şi operaţii analitice.

Datele transformate sunt apoi încărcate înapoi în depozitul de date într-o reprezentare fizică a Modelului Datelor de Întreprindere (Enterprise Data Model - EDM). EDM constituie o reprezentare a tuturor proceselor de business dintr-o întreprindere. Din depozitul de date, datele sunt încărcate în pieţe de date specifice (data marts) sau în cuburi OLAP. Acestea sunt modele de date care sunt optimizate pentru operaţii analitice şi raportări. Aplicaţiile de inteligenţă de business (BI) de pe desktop şi cele mobile se conectează la modele dimensionale şi expun datele prin intermediul foilor de bord, a rapoartelor şi a instrumentelor de interogare ad-hoc.

Baze de date relaţionale în depozitele de date şi cerinţe noi determinate de Big Data

Depozitele de date (warehouse) se bazează, de obicei, pe baze de date relaţionale (RDBMS). Pentru volume mai mici de date sunt utilizate bazele de date standard cum sunt: PostgreSQL, MS SQL Server sau Oracle.

Pentru volume mai mari de date sunt utilizate aparate (appliances) construite special în acest scop care să includă hardware optimizat şi software specific pentru a se realiza performanţe superioare. Astfel de aparate (appliances), cum sunt Teradata sau Exadata formează fundamentul pentru depozitul de date.

Mai recent, baze de date paralele masive (MPP) cum sunt Vertica sau GreenPlum pot să funcţioneze şi pe echipamente obişnuite (commodity hardware). Asocierea existentă până acum, între depozitele de date (warehouse) şi bazele de date relaţionale, nu pare că mai este aşa de puternică deoarece un declin al importanţei bazelor de date relaţionale apare din următoarele considerente (Sonra-2, 2015):

• Reţinerea datelor referitoare la tot mai multe aspecte şi creşterea exponenţială a volumului de date pun semne de întrebare asupra eficacităţii şi scalabilităţii bazelor de date relaţionale cu scopuri generale pentru depozitele de date. Aici intervin modele de cost pentru licenţe care sunt bazate pe numărul de CPU-uri şi costurile hardware pentru aparatele de stocare a datelor în depozite.

• Bazele de date relaţionale generale nu sunt potrivite pentru ingerarea anumite tipuri de date, cum sunt datele nestructurate, datele ierarhice complexe care apar în grafuri şi în poliarbori.

• Depozitul de date (warehouse) a fost destinat să fie depozit central pentru business. Deoarece volumul de date creşte acest lucru este mai greu de susţinut.

• Bazele de date relaţionale generale necesită o schemă predefinită. Acest fapt face ca modelarea datelor să fie foarte costisitoare.



4.3.7. Criterii de alegere a software-ului de stocare şi procesare pentru Big Data În alegerea componentelor software ale unui nucleu, în cadrul oferit de proiectul

Hadoop pentru sisteme Big Data, trebuie să se ia în considerare unele din următoarele caracteristici ale acestuia (Gartner, 2015):

1. Hadoop este un cadru deschis de software sursă pentru stocarea şi prelucrarea datelor mari peste grupuri mari de produse hardware. Hadoop conţine două părţi principale: Sistemul de fişiere distribuite Hadoop - HDFS şi Map Reduce.

2. Sistemul distribuit de fişiere Hadoop (HDFS) gestionează regăsirea şi stocarea datelor şi a metadatelor necesare pentru calcul.

3. Apache Pig este o platformă de nivel înalt de creare a programelor MapReduce care sunt utilizate cu Hadoop.

4. Apache Hive este o platformă de depozitare a datelor, care este construită peste Hadoop.

5. Cascading este un cadru de dezvoltare de aplicaţii Java pentru analiză de date bogate şi de gestionare a aplicaţiilor datelor care rulează peste "o varietate de medii de calcul", cu accent pe Hadoop şi distribuţii compatibile cu acest API, în conformitate cu Concurent - compania care a dezvoltat Cascading. Cadrul de lucru Cascading, alături de biblioteca Apache Crunch oferă API-uri de nivel mai înalt decât MapReduce. Faţă de abstractizarea simplă de tipul cheie-valoare, aceste biblioteci utilizează operaţii cu tuple, cum sunt join-urile, iar job-urile de pe mai multe nivele sunt tratate implicit de biblioteci(operaţiile sunt compilate în job-uri MapReduce). Ambele proiecte furnizează şi API Scala, care permite interogări foarte concise. Un avantaj al acestor două sisteme faţă de Pig şi Hive constă în posibilitatea de a scrie funcţii definite de utilizator într-un mod mai uşor, utilizând Cascading şi Crunch, deoarece ele sunt scrise în limbaje gazdă (Java sau Scala), nefiind necesar un alt limbaj cum este cazul cu Java pentru PIG şi Hive, deşi PIG suportă, de asemenea, şi Python.

6. Instrumente de integrare Big Data. Instrumente semi-automat de modelare, cum ar fi CR-X permite să se dezvolte modele interactiv la viteză rapidă, precum şi instrumentele pot ajuta să configuraţi baza de date, care va rula Google Analytics. CR-X este un ETL în timp real (Extract, Transform, Load) instrument de integrare a datelor mari şi motor de transformare.

7. Baze de date analitice. Bazele de date analitice scalare cum sunt Pivotal Greenplum sau IBM Netezza oferă încărcarea şi reîncărcarea rapidă a datelor pentru modele analitice.

8. Considerarea satisfacţiei clientului. Pachetele analitice Big Data de la ISVs (cum este ClickFox) rulează utilizând baze de date pentru a satisface aspecte de business cum este satisfacţia clientului.

9. Abordare tranzacţională. Proiecte tranzacţionale Big Data nu pot utiliza Hadoop deoarece acesta nu este în timp real. Pentru sistemele tranzacţionale care nu necesită o bază de date care să satisfacă cerinţele ACID (Atomicitate, Consistenţă, Izolare, Durabilitate) se pot utiliza baze de date NoSQL, deşi consistenţa poate fi una slabă.



10. Punerea la un loc a acestora. Figura 19 arată componentele majore puse împreună într-o soluţie Big Data completă.

În continuare sunt enumerate câteva instrumente care au fost descrise în subcapitolul 3.1.1 care completează cadrul ecosistemului Hadoop cum sunt: Apache Flume, Apache Oozie, Apache Avro, Apache HCatalog, Apache Mahout şi alte instrumente care sunt descrise mai jos.

• Sqoop este un sistem de preluare a datelor în bloc, fiind utilizat pentru realizarea de salvări zilnice ale datelor din bazele de date relaţionale tranzacţionale în Hadoop pentru analiză offline.

• Apache Bigtop testează şi împachetează un set cunoscut de componente Hadoop, scutind utilizatorii de această povară. Distribuţii de Hadoop cum sunt CDH de la Cloudera şi HDP de la Hortonworks sunt construite cu Bigtop pentru testare şi împachetare.

• Apache Ambari şi Cloudera Manager furnizează o interfaţă la nivel de cluster pentru administrarea configuraţiei, monitorizare, alerte, căutarea fişierelor de log, pentru dependinţe între servicii şi pentru actualizarea serviciilor.

• YARN (Yet Another Resource Negotiator) este un cadru de management a resurselor pentru versiunea a doua a lui Hadoop, care generalizează procesarea datelor dincolo de MapReduce. YAN deschide puterea de procesare a clusterului Hadoop pentru algoritmi noi de procesare distribuită, cum este procesarea grafurilor de scară mare.

•

Figura 19. Componentele majore puse împreună într-o soluţie Big Data completă

Procesare și Date originale

Sisteme de fișiere cu localizare

Urmăritori de job-uri și Task-uri

Limbaje de nivel înalt

Securitate și management

Modelare

Baze de Date ușor de încărcat

Procesare și Date originale

Sistem de fișiere De ex. HDFS

NoSQL DB De ex. Hbase Cassandra

Hadoop Motorul MapReduce

Pig Hive (DW)

Cascading

ETL (Extrage, Încărcare Transformată) Instrumente de Modelare, de ex. CR-X

Kerberos

de ex. Greenplum Netezza

ClickFox, Merced etc. Straturi de abstractizare



4.3.7.1 Criterii de selectare a modalităţilor de stocare a Big Data Fundaţia stivei de tehnologii Big Data este stratul de stocare. Printre cerinţele

operaţionale fundamentale în domeniul Big Data sunt incluse performanţa, disponibilitatea, accesibilitatea şi flexibilitatea.

Pentru satisfacerea celor mai importante cerinţe care trebuie îndeplinite în fundamentarea soluţiilor optime de stocare a datelor de tip Big Data, următoarele criterii ar trebui să fie incluse (Rouda, 2015):

• Scalabilitatea pentru volume de date mari. Având în vedere creşterea volumului de date stocate, este necesar să se aibă în vedere posibilităţile viitoare de stocare, atât din punct de vedere al limitelor fizice, cât şi al costurilor de scalare.

• Performanţa pentru viteza Big Data. Imensele cantităţi de date trebuie procesate şi analizate într-un timp adecvat. Cerinţele analitice ale fluxurilor de date în timp real măresc importanţa acestui criteriu. Pe lângă metodele de indexare potrivite, formatele de tip coloană, păstrarea datelor în memorie este necesar să existe capabilităţi de stocare superioare, printre care şi stocarea flash care permite o creştere a datelor utilizate în mod activ de metodele analitice.

• Niveluri dinamice pentru cea mai bună combinaţie de caracteristici. Deoarece scalabilitatea şi performanţa pot fi realizabile dar pot fi foarte scumpe dacă de utilizează medii rapide, este necesar să se realizeze o platformă bună care să permită atingerea necesităţilor de business şi să furnizeze un mix ierarhic de calităţi.

• Accesibilitatea multiprotocol pentru gama largă de date de tip Big Data. Diferite surse de date vor avea, probabil, diferite cazuri de utilizare. Diferite aplicaţii ar putea avea nevoie de a utiliza aceleaşi seturi de date local, şi realizarea de numeroase mutări şi operaţiuni de join ale datelor, care adaugă overhead şi întârziere. Criteriul de alegere, în acest caz, atât din punct de vedere economic, cât şi al uşurinţei de administrare, constă în utilizarea unui loc de stocare central care poate fi utilizat în scopuri multiple.

Arhitecţii de Big Data trebuie să considere o gamă largă de opţiuni pentru platforme de stocare, în care sunt incluse SAN, NAS şi IaaS furnizat de cloud. Fiecare din aceste modele este posibil, dar profilele rezultatelor sunt diferite.

4.3.7.2 Exemplu de platformă de stocare a datelor-Spectrum Scale de la IBM Platforma de stocare Spectrum Scale de la IBM satisface cerinţele cele mai importante

pentru stocarea Big Data (Rouda, 2015):

• Scalabilitate extremă de creştere, prin evitarea copiilor pe medii de stocare separate şi redundante

• Overhead redus în mutarea datelor, deoarece nu este nevoie de mutarea datelor într-un cluster HDFS sau Hadoop, utilizând un singur mediu pentru stocarea datelor pe termen lung, procesarea ETL şi stocarea datelor Hadoop.

• Accesibilitate uşoară pentru diferiţi utilizatori, deoarece aceştia pot utiliza aplicaţiile pe care le doresc, cu o singură copie de date ce este disponibilă simultan la distribuţii multiple ale MapReduce, Yarn şi alte instrumente din ecosistemul Hadoop.

• Independenţă de localizarea geografică prin utilizarea seturilor de date din cache-ul local.



• Funcţionalitate de stocare avansată, utilizând instrumente specifice: File Placement Optimizer (FPO), managementul de stocare ierarhic, IBM Spectrum Protect şi posibilitatea de administrare şi automatizare a întregului ciclu de viaţă.

De asemenea, IBM a dezvoltat multe soluţii analitice pentru Big Data:

• BigInsights (Hadoop)

• Watson (cognitiv)

• PureData (depozit de date)

• DB2 cu Blu Acceleration (bază de date în memorie)

• Informix (baze de date IoT-Internet of Things)

• Cloudant (baze de date ca serviciu).

4.3.8. Criterii utilizate în alegerea metodelor şi modelelor analitice

Pregătirea datelor pentru analiză

În pregătirea datelor pentru analiză apar următoarele aspecte care trebuie să fie analizate:

• Provocările calităţii datelor

• Instrumente ETL pentru Extragere, transformare şi încărcare. În acest mod datele se încarcă şi se convertesc în datele structurate şi nestructurate în Hadoop. Hadoop este cel mai utilizat set de produse de organizare a Big Data, fiind menţinut de Apache Foundation.

Capabilităţi analitice pentru Big Data

Capabilităţile analitice pentru Big Data se referă la aplicarea capabilităţilor analitice la seturi de date uriaşe, variate şi care se schimbă rapid:

• Monitorizarea şi detectarea anomaliilor.

• Data mining şi analizarea textului.

• Analizele predictive explică tendinţele sau evenimentele care au impact de schimbare, care sunt unice sau sunt revoluţionare în practica de bussiness.

• Rapoartele şi tablourile de bord sunt utilizate atât pentru reprezentarea prietenoasă, într-o modalitate tradiţională, a informaţiei din diferite surse, cât şi pentru noi tipuri de baze de date NoSQL.

• Vizualizare Big Data. Ieşirile tind să fie foarte interactive şi dinamice. Utilizatorii pot să urmărească schimbările în date utilizând diferite tehnici de vizualizare: hărţi, hărţi de căldură, grafice de informare şi diagrame de conectare. Aceste tehnici, alături de rapoarte finalizează activitatea de business.

• Rolul Excel în Big Data.

Transformarea Big Data în valoare

În figura 20 se prezintă principalele etape şi elemente componente prin care datele se transformă în valoare pornind de la extragerea datelor, verificarea faptului că au caracteristicile specifice Big Data, analizarea datelor utilizând metode analitice şi crearea valorii pentru atingerea obiectivelor de performanţă a businessului.



Figura 20. Transformarea Big Data în valoare

Crearea de modele predictive din Big Data

Utilizarea modelelor predictive poate să conducă la optimizarea unei game largi de activităţi:

• Se pot prezice alegerile clienţilor, vânzătorii pot prezice ce produse se vor vinde, sau companiile de asigurări vor înţelege cât de bine conduc clienţii lor.

• Optimizarea proceselor de business: optimizare stocuri, optimizare rute.

• Îmbunătăţirea sănătăţii: legătura dintre stilul de viaţă şi boli, monitorizarea şi prezicerea epidemiilor.

• Îmbunătăţirea securităţii şi respectarea legii: detectare atacuri cibernetice şi atacuri teroriste, detectarea tranzacţiilor bancare frauduloase.

• Îmbunătăţirea performanţelor sportive: utilizarea senzorilor, a analizei video.

• Îmbunătăţirea şi optimizarea oraşelor şi ţărilor: optimizarea traficului.

4.3.9. Criterii de selecţie asociate cadrului general al metodelor analitice pentru Big Data în timp real

Metodele analitice pentru Big Data în timp real utilizează un proces iterativ care implică instrumente şi sisteme multiple. Un model în cinci faze al procesului analitic al Big Data este descris de Smith ca un cadru pentru metodele analitice predictive (Barlow, 2013). Acest proces implică diferite criterii de alegere în cadrul celor cinci faze ale sale: distilarea datelor, dezvoltarea modelului, validarea şi implementarea, evaluarea sistemelor în timp-real şi reîmprospătarea modelului.

Distilarea datelor

Deoarece datele din stratul de date sunt brute şi neordonate ele nu satisfac cerinţele de structurare necesare pentru construirea de modele şi realizarea de analize.

Următoarele criterii sunt urmărite în distilarea datelor:

• modul de extragere a caracteristicilor din texte nestructurate

• modul de combinare a surselor de date disparate

Activități Conversații Voce Cuvinte Date operaționale Media socială

Loguri de Browser

Fotografii Video Senzori

Extragere date

Analiză text Analiză sentimente Recunoaștere fețe Analiză voce Analiză mișcare Analiză date operaționale

Analiza Big Data:

Volum Viteză Varietate Veridic

Au caracteristici Big Data:

Atingere obiective: - Analiza datelor în

noi modalități, potențând noi surse

Valoare:



• modul de filtrare a populaţiilor de interes

• modul de selectare a caracteristicilor relevante şi a rezultatelor pentru modelare

• modul în care seturile de date distilate sunt exportate la o piaţă de date locală (local data mart).

Dezvoltarea modelului

În această fază se creează un model predictiv care este puternic, robust, comprehensibil şi implementabil. Pentru aceasta trebuie să fie incluse criterii pentru următoarele:

• Selectarea caracteristicilor

• Eşantionarea şi agregarea

• Transformarea variabilă

• Estimarea modelului

• Rafinarea modelului

• Testarea modelului.

Cele mai importante cerinţe pentru specialiştii în date, în această fază, sunt viteza, flexibilitatea, productivitatea şi reproductibilitatea. Deoarece aceste cerinţe sunt critice în domeniul Big Data, un specialist în date va construi, rafina şi va compara zeci de modele în căutarea unui algoritm în timp real puternic şi robust.

Validarea şi implementarea

Validarea procesului descris în cadrul modelului constă în reextragerea de date noi, prelucrarea lor conform modelului, şi compararea rezultatelor cu setul de validare. Dacă modelul funcţionează corect, el se poate implementa într-un mediu de producţie.

Criterii de evaluare a sistemelor în timp-real

Punctajul pentru sistemele în timp real se face în stratul de decizie (de către consumatori de la un website sau de către un sistem operaţional prin intermediul unui API). Comunicaţia este intermediată de stratul de integrare. În faza de evaluare a punctajului, unele sisteme în timp real vor utiliza acelaşi hardware care este folosit şi în stratul de date sau în pieţele de date (data mart). În această fază apar limitările pe care le are Hadoop în succesul ca sistem în timp-real, deşi acesta are rezultate mulţumitoare în acţiuni de populare a tabelelor mari sau în punctarea operaţiunilor de pre-calcul. Tehnologii mai noi, cum este Impala de la Cloudera, sunt proiectate să îmbunătăţească capabilităţile în timp real ale Hadoop.

Reîmprospătarea modelului

Deoarece datele se schimbă, este necesar ca acestea să fie reîmprospătate şi, de asemenea, modelul construit cu datele originale trebuie refăcut utilizând scripturile sau programele utilizate iniţial. Este recomandat să se facă analize exploratorii ale datelor şi reîmprospătarea periodică a modelului. Procesul de reîmprospătare, ca şi cel de validare şi implementare pot fi automatizate utilizând servicii Web cum este RevoDeployR, care este o parte a soluţiei RevolutionR Enterprise.



Algoritmi maşină de învăţare utilizaţi frecvent în analizarea Big Data

Următorii algoritmi sunt utilizaţi în mod frecvent în metodele analitice pentru derivarea valoarea de business:

• Supervised Unsupervised • Linear Nonlinear • Single Combined • Easy to Interpret Hard to Interpret • Linear • Regression • Logistic • Regression • Perceptron • Bagging Boosting Random Forest • Decision Rule • Trees Learning • Naïve k-Nearest • Bayes Neighbours • Multi-Layer SVM • Perceptron • K-Means • EM Self-Organizing Maps

Figura 21. Algoritmi de învăţare maşină pentru analiza Big Data (după IBM, 2015)

Algoritmii comuni de învăţare maşină pentru analizarea Big Data pot fi ierarhizaţi conform Figurii 21.



4.4. Rolul specialiştilor în date şi criterii de alegere a acestora

4.4.1. Joburi specifice Big Data Un specialist în domeniul datelor (data scientist) este un titlu de job (loc de muncă)

pentru un angajat sau un consultant de business intelligence (BI) care excelează în analizarea datelor, în mod particular în mari cantităţi de date, pentru a ajuta un business să câştige un avantaj competitiv.

Un specialist în domeniul datelor posedă o combinaţie de calificări analitice, statistice, de învăţare a maşinilor, de minare a datelor şi are experienţă în algoritmi şi în programare. El trebuie să poată explica semnificaţia datelor într-un mod care poate fi înţeles cu uşurinţă de alţii.

Profesii în domeniul Big Data (McFedries, 2015):

Arhitecţi de date (Data architects) – specialişti în construirea modelelor de date.

Custode de date (Data custodians) sau administrator de date (data stewards) - administrează surse de date.

Vizualizator de date (Data visualizer) – care traduce datele în forme vizuale.

Agenţi de schimbare a datelor şi exploratori de date – schimbă modul de realizare a afacerilor pe baza analizei datelor companiilor.

Alături de aceste profesii specializate, sunt necesare activităţi clasice de configurare, administrare şi management.

4.5. Big Data în Guvernare - Ghid de bune practici

De ce Big Data în sectorul guvernamental? De ce acum?

"Afacerea" de guvernare este destul de diversă, cuprinzând multe funcţii diferite incluzând, printre multe altele serviciile sociale, gestionarea infrastructurii, impozitarea, supravegherea respectării legii, apărarea şi securitatea.

Volumul de informaţii necesare pentru gestionarea oricărui program în timp util şi eficient ar depăşi capabilităţile oricărui sistem clasic. În plus, există imperative suplimentare pentru creşterea agilităţii, responsabilităţii şi preciziei în luarea deciziilor, care evidenţiază cerinţa imediată pentru sisteme de înaltă performanţă scalabile capabile să utilizeze cantităţi masive de date, inclusiv:

• Necesitatea de a coordona programe în cadrul unei agenţii.

• Cerinţe sporite de coordonare şi utilizare partajată de cantităţi masive de date în cadrul şi între agenţii.

• Luarea de decizii mai bine informate şi inteligente.

• Rezultate mai sigure şi previzibile.



• Publicarea de date pentru o mai mare transparenţă şi vizibilitate pentru public.

• Identificarea şi eliminarea fraudelor, pierderilor şi abuzurilor.

Este recunoscut faptul că trebuie abordate neajunsurile existente ale infrastructurii aferente tehnologiei actuale. Partajarea informaţiilor neguvernamentale implică existenţa a numeroase erori şi neconcordanţe ale datelor, în timp ce costurile asociate menţinerii a numeroase sisteme disparate depăşesc capabilităţile unei agenţii, afectând grav capacitatea de coordonare şi colaborare. În concluzie, este nevoie de o mai bună abordare care să depăşească limitările mediilor existente.

Există o recunoaştere clară a potenţialului Big Data de a răspunde nevoii mereu crescânde pentru performanţe scalabile pentru o varietate largă de analize mixte (de exemplu, raportare, interogare, analize algoritmice) pe o varietate de seturi de date guvernamentale şi nu numai. Unele propuneri fundamentale valoroase şi seturi de competenţe necesare existente includ un cost iniţial scăzut (în special atunci când se utilizează produse open source) şi anticipează soluţionarea unor probleme de afaceri şi analiză ale căror cerinţe de performanţă depăşesc capacităţile mediului existent.

Introducerea Big Data în sectorul guvernamental

Regăsirea şi analiza facilă şi în timp util de informaţii corelate sau necorelate este esenţială pentru guvern pentru a satisface şi a îmbunătăţi cerinţele misiunii sale, care sunt variate de la o agenţie la alta. Datele continuă să fie generate şi arhivate digital cu viteze tot mai mari datorită iniţiativelor de e-Guvernare şi pentru o guvernare “deschisa”, senzorilor, interacţiunilor cu cetăţenii şi tranzacţiilor aferente programului de guvernare. Organizaţiile guvernamentale au început să implementeze sisteme suport de decizie, analiza automatizării interfeţelor, să descopere organizarea datelor şi managementul infrastructurii. Sunt incluse utilizarea de servere standardizate, reţele, stocarea datelor şi software pentru clustere, toate acestea fiind utilizate şi pentru implementarea pe scară largă a tehnologiei Big Data. Drept exemplu, se poate face referire la software-ul care prelucrează şi pregăteşte toate tipurile de date pentru analiză. Acest strat extrage, curăţă, normalizează, etichetează şi integrează datele. Acest strat include software pentru descoperirea ad-hoc şi analiză profundă şi software care suportă analiza în timp real, de luare automată a deciziilor tranzacţionale bazate pe reguli. Aplicaţii cu funcţionalităţi necesare pentru a sprijini colaborarea, evaluarea scenariilor, gestionarea riscurilor, precum şi captarea deciziilor.

Există deci multe oportunităţi pentru introducerea unor tehnologii Big Data în sectorul guvernamental, inclusiv în securitatea cibernetică; tehnologii de analiza seturilor de date de mari dimensiuni în domeniul ştiinţei şi cercetării, precum şi data mining utilizate pentru a preveni comiterea de acte de teroare şi / sau pentru a preveni risipa, frauda şi abuzurile; fuziunea datelor şi informatica medicală, pentru a numi doar câteva. Toate aceste probleme de afaceri reflectă caracteristicile legate de Big Data - volume masive de date, mare varietate de date, integrarea tehnicilor de analiză, precum şi o nevoie de scalabilitate crescută. Cu toate acestea, există percepţia conform căreia costurile iniţiale reduse pentru software-ul de Big Data, cum ar fi Hadoop, sugerează un mod rentabil pentru a înlocui infrastructura existentă, sugerând faptul că Hadoop (şi variantele sale comerciale) sunt complementare formulelor existente de business intelligence, analizei şi metodelor deja livrate din arhitecturile existente.



În calcularea costurilor totale pentru arhitectura de Big Data trebuie incluse cele aferente a patru factori majori: oameni, software, hardware şi date.

Big Data poate adăuga valoare ca resursă utilizată pentru a spori analiza şi modelarea predictivă şi pentru a impulsiona fluxuri masive de date. Utilizatorii de date pentru afaceri ar trebui însă să fie conştienţi de faptul că, în timp ce costurile iniţiale ale software-ului open source pentru tehnologiile de Big Data au fost reduse, acest fapt nu este neapărat valabil şi pentru costul total de dezvoltare, operare şi de întreţinere. Introducerea analizei de Big Data ar trebui să se concentreze pe cazuri de utilizare a lor în afaceri şi pe măsuri clar definite de performanţă demonstrând valoarea adusă afacerii şi, cu siguranţă, în guvernare, este de neconceput renunţarea la tehnologia existentă pentru una în curs de dezvoltare. Mai degrabă, Big Data ar trebui să fie parte integrantă a unei strategii globale de analiză, care nu poate trece peste cele mai bune practici asociate cu aderarea la ciclul de viaţă din dezvoltarea sistemului.

Trebuie însă recunoscut şi pericolul de a ignora nevoia de a capta, gestiona şi analiza eficient cantităţi masive de date. Fie că este vorba de identificarea rapidă a ameninţărilor cibernetice, expunerea insidioasă la metode de comportament fraudulos sau de menţinerea responsabilităţii pentru costurile crescânde de susţinere a extinderii programelor sociale, nu poate fi ignorată necesitatea unor sisteme de calcul de înaltă performanţă scalabile, care să sprijine activităţile critice din guvern.

Exemple de utilizare a Big Data

O reacţie impulsivă la beneficiile promise de Big Data este finanţarea şi iniţierea de proiecte pilot pentru a evalua tehnologiile aferente, utilizând costuri iniţiale scăzute sau chiar nule (cum ar fi pentru produse gratuite sau produse open-source). Cu toate acestea, adoptarea tehnologiei de Big Data nu va produce imediat beneficii.

Ca şi în adoptarea oricărei noi tehnologii, beneficiile trebuie să fie încadrate în contextul valorii de business aduse organizaţiei şi nu ţinând seama de reacţia mass-mediei, curiozităţii ştiinţifice sau chiar fricii de "a fi lăsat în urmă". Succesul unui sistem pilot de Big Data trebuie să fie măsurat în raport cu îndeplinirea obiectivelor propuse pentru îmbunătăţirea performanţei, creşterea vitezei de execuţie, obţinerea de rezultate mai precise sau cu capacitatea de a absorbi şi a folosi seturi mai mari şi mai diverse de date. Prin urmare, aceste caracteristici trebuie luate în considerare pentru a stabili dacă o soluţie de Big Data este potrivită pentru o anumită problemă de afaceri:

• Volume mari de date - S-ar putea sugera că ceea ce califică datele ca fiind de "mare" dimensiune este faptul că practic cantitatea de date depăşeşte capacitatea existentă de prelucrare a datelor într-un timp util. Procesele de afaceri care beneficiază de volume crescute de date sunt potrivite pentru soluţii Big Data.

• Varietate semnificativă a datelor - Acest lucru sugerează probleme de afaceri care pot beneficia de potenţialul de a extrage “bucăţi” semnificative de informaţii din datele provenind din surse diferite, cu structură şi conţinut variate.



• Limitări privind performanţa sistemului / Intensitatea analizei - Procesele de afaceri care sunt blocate ca urmare a unor întârzieri de calcul (cum ar fi algoritmi complecşi de calcul cu cerinţe restrictive sau algoritmi euristici care încearcă să optimizeze global soluţiile), volume de date sau restricţii asociate cu varietatea datelor, viteza fluxului de date, latenţa accesului la date şi / sau disponibilitatea datelor.

• Potenţial de paralelizare - Aceasta se referă la probleme de afaceri care pot fi defalcate în unităţi mai mici de lucru care pot fi executate simultan. Performanţele execuţiei acestor procese de afaceri pot fi îmbunătăţite prin paralelismul datelor sau paralelizarea aplicată unor segmente de date distribuite independente.

Ca producător important şi consumator de seturi de date de mari dimensiuni (şi de dimensiuni în creştere), agenţiile guvernamentale sunt zone fertile care pot beneficia de tehnologia de Big Data. După cum este sugerat în Tabelul 4, sectorul public se confruntă cu multe probleme de afaceri care prezintă una sau mai multe dintre criteriile de conformitate menţionate şi pentru care se pot măsura cu claritate îmbunătăţirile obţinute ca urmare a implementării Big Data.

Tabelul 4. Probleme guvernamentale de afaceri potrivite pentru o soluţie de Big Data

Problema de afaceri

Descriere / Exemple Adecvarea soluţiei de Big Data

Securitate cibernetică

Monitorizarea activităţilor şi comportamentelor în reţea pentru a identifica modele cunoscute sau suspecte de acces care indică o breşă, inclusiv atacuri asupra serviciului, scurgeri de date, atacuri asupra site-urilor Web şi pentru a detecta spionajul cibernetic.

• Numeroase fluxuri de date cu o varietate semnificativă de structură, format şi conţinut, cum ar fi DNS, DHCP, NetFlow, log-uri Web, alerte, date de configurare, audituri, e-mailuri şi fluxuri de date în reţele sociale. • Cantităţi masive de date de la fiecare sursă, rată foarte mare de streaming. • Performanţă afectată de nevoia de a capta, organiza şi analiza cantităţi masive de date. • Sarcini paralele care includ numeroase comparaţii aplicate bazei de cunoştinţe pentru căutarea de tipare cunoscute, precum şi analiză continuă pentru identificarea modelelor emergente de comportament suspect.

Fraude, pierderi şi abuzuri

Tranziţia de la detectarea fraudei existente şi recuperarea plăţilor necuvenite către identificarea proactivă a comportamentului fraudulos înainte de efectuarea plăţilor. Se utilizează modele în reţea pentru a identifica metode colaborative de fraudă şi abuz şi a declanşa rapid investigaţii cât mai eficiente.

• Absorbţia şi analiza unor cantităţi masive de istoric de tranzacţie. • Seturi multiple de date, inclusiv seturi structurate de tranzacţii de la o largă varietate de organizaţii, precum şi date demografice din surse nestructurate. • Algoritmi de calcul intensiv pentru dezvoltarea de modele predictive pentru identificarea fraudei şi abuzului. • Analizarea şi compararea în paralel a unor modele diferite.

Securitate şi protecţie

Acordarea de sprijin în caz de dezastru natural, atac terorist,

• Utilizarea unor colecţii mari de date. • Absorbirea şi utilizarea de seturi de date



dezastru provocat de om sau pentru a identifica ameninţări potenţiale la adresa securităţii.

eterogene. • Favorizarea creării de modele mari pentru simulare şi analiză.

Analiza datelor de la senzori

Diverse activităţi de fuziune a datelor care combină datele furnizate de senzori pentru analiză şi orientare. Integrarea şi analiza unei cantităţi masive de date ştiinţifice sau de inginerie obţinute de la senzori, inclusiv date despre reţeaua electrică, vreme, date climatice, bioinginerie sau date GPS.

• Cantităţi masive de date transmise la viteze progresiv mai mari. • Colectarea şi fuziunea de informaţii de la diferite tipuri de maşini / senzori. • Algoritmi care necesită analiză statistică scalabilă.

Analiza, partajarea şi căutarea documentelor

Colectarea, colaţionarea şi indexarea de documente de la o mare varietate de agenţii, partajarea documentelor inter-organizaţionale, oferind acces la căutare pentru cercetare.

• Masive şi colecţii în creştere de documente. • Numeroase surse cu structură redusă sau inexistentă. • Corelarea cu seturi de date structurate existente. • Paralelizarea sarcinilor, ceea ce permite scalabilitate pentru căutări simultane

Informatică medicală

Analizarea calităţii asistenţei medicale, compararea eficacităţii cercetării, monitorizarea sănătăţii populaţiei şi management.

• Volume explosive de documente, imagini şi date provenind de la senzori. • Utilizarea a numeroase sisteme pentru gestionarea într-o varietate de moduri a dosarelor medicale electronice. • Utilizarea de algoritmi complecşi de analiză a formelor pentru analiza procedurile şi corelarea rezultatelor. • Necesitatea scalabilităţii în toate aspectele activităţilor.

Big Data ca parte a unei arhitecturi cu informaţii unificate

Există oportunităţi clare pentru a obţine avantaje din încorporarea metodelor şi tehnologiilor de Big Data în noile arhitecturi hibride de Big Data (cum se poate vedea în încorporarea de tehnologii în Hadoop propuse de liderii în modalităţi curente de depozitare a datelor cum ar fi Oracle, IBM, Pivotal şi Teradata. Astfel, ar fi naiv să presupunem că investiţii semnificative în infrastructură şi ani de dezvoltare de aplicaţii ar putea fi pur şi simplu înlocuiţi cu orice nouă tehnologie, bazată pe produse open-source în mare parte nesigure. Aceste abordări necesită abilităţi în tehnici cum ar fi MapReduce, care sunt greu de stăpânit pentru cele mai multe agenţiilor guvernamentale şi mult mai puţin ieftine. Multe aplicaţiile guvernamentale din Tabelul 4 au fost deja abordate într-un anumit fel utilizând tehnologii deja disponibile, aşa că poate fi mai înţelept să se caute oportunităţi pentru a mări mediul existent decât să se încerce reconstruirea lui de la zero.



Prin urmare, o abordare mai rezonabilă urmăreşte impulsionarea obţinerii de beneficii prin utilizarea Big Data într-un mod care completează managementul existent al datelor şi cadrul de analiză. Acest fapt sugerează integrarea treptată a proiectelor selectate de Big Data în organizaţie ca parte a unei strategii informaţionale cuprinzătoare şi a unui plan de realizare a unei arhitecturi informaţionale unificate. Ar trebui antrenată o comunitate de utilizatori de afaceri cărora să li se solicite opiniile cu privire la modul în care accesul mai larg la analiza bazată pe volume masive de date poate îmbunătăţi potenţialul de succes în afaceri. De asemenea, ar trebui să evalueze măsura în care problemele lor prezintă caracteristicile care le fac potrivite pentru o soluţie de Big Data.

Totodată, ar trebui să identifice criterii de performanţă, să se înţeleagă cum tehnicile specifice de Big Data îmbunătăţesc performanţele şi problemele de scalabilitate şi, în general să evalueze impactul potenţial pozitiv al unei soluţii de Big Data.

Odată ce se trage concluzia că scenariile de afaceri pot fi îmbunătăţite prin încorporarea tehnologiilor de Big Data, trebuie să se examineze modul de a integra instrumentele, tehnicile, precum şi competenţe necesare pentru producţionalizare în cadrul mediului existent de gestionare a informaţiilor, cum ar fi:

• Procesare intens paralelă (PIP), concepută pentru a oferi atât performanţă scalabilă liniar cu cât sunt adăugate mai multe noduri de prelucrare, cât şi elasticitate pentru a permite aplicaţiilor să utilizeze puterea de procesare necesară pentru a executa cererea.

• Dispozitive analitice, constând din sisteme hardware de specialitate organizate în jurul unui cadru PIP combinat cu viteză crescută, reţele de lăţime de bandă largă şi canale de I / O. Aceste sisteme sunt special realizate pentru aplicaţii de înaltă performanţă consumatoare de cantităţi masive de date.

• Etichetare şi prelucrare semantice care pot fi utilizate pentru a organiza ontologii şi ierarhii referitoare la termeni de afaceri, sensul lor în funcţie de context şi metodele de armonizare a conceptelor implicite.

• Analiză de text, tot mai importanţă pentru extragerea de informaţii relevante din cantităţile masive de date nestructurate disponibile şi utilizarea de ontologii semantice pentru analiza.

• Prelucrare eveniment complex (referită şi ca prelucrare flux de evenimente) care permite scanarea şi analiza formelor pentru monitorizare în timp real şi secvenţele de evenimente reprezentate implicit în fluxuri de date diferite.

• Mesaje şi fluxuri de date cu latenţă scăzută, care sunt esenţiale pentru prevenirea scăderii performanţelor datorată blocărilor cauzate de tranzacţiile din reţea necesare schimbului de date.

• Dezvoltarea, execuţia, testarea şi implementarea aplicaţiilor de Big Data, cum ar fi suita de instrumente Hadoop, care oferă o paletă de instrumente pentru dezvoltarea de aplicaţii, programare, execuţie, gestionare a datelor, precum şi diverse alte instrumente de sprijin pentru aplicaţie.



Fiecare dintre aceste tipuri de tehnologii contribuie la capacitatea de a efectua analize de Big Data, dar când vine vorba de dezvoltarea unui soluţii de Big Data, dezvoltarea de aplicaţii de management şi analiză de Big Data este indisolubil legată de cele mai bune practici generale de gestionare a informaţiilor.

Multe analize vor combina profilele existente în depozite de date tradiţionale cu aplicaţii de Big Data, în timp ce rezultatele aplicaţiilor algoritmice trebuie reintroduse în infrastructura existentă în moduri care îmbunătăţesc aplicaţiile care sunt deja şi vor rămâne în utilizare.

Cu alte cuvinte: în viitorul apropiat sau pe termen mediu, aplicaţiile nou-dezvoltate care exploatează tehnici de Big Data trebuie să se bazeze pe mediile tradiţionale existente de date structurate, care sunt în prezent folosite pentru a rezolva problemele guvernamentale.

Noţiuni de bază în domeniul utilizării Big Data în proiecte guvernamentale pilot

Nu există nici o îndoială că alura şi strălucirea unei noi tehnologii pot fi orbitoare, iar primul punct critic de luat în considerare pentru orice proiect de Big Data este de a-l începe ţinând mereu cont de beneficiile ce trebuie aduse afacerii şi de a se concentra mereu pe afacere. Implementarea tehnologiei fără a ţine cont de starea curentă şi rezultatul final dorit poate duce la stagnare şi insucces în finalizarea proiectului.

Drept urmare, putem presupune că utilizatorii au fost angajaţi în proiect şi că au fost identificaţi unul sau mai mulţi specialişti în Big Data. Acesta este momentul în care agenţia este pregătită pentru a începe o abordare mai generală a evaluării propunerii de Big Data, astfel încât un proiect pilot rezonabil poate fi proiectat, care va fi privit în viitor ca un indicativ de valoare.

Va fi identificată cu atenţie posibilitatea de a aborda o anumită problemă specifică folosind Big Data, punând în balanţă beneficiile potenţiale şi nivelul de efort implicat. Pentru rezolvarea problemei selectate, poate fi propus un proiect pilot pentru dezvoltarea unei aplicaţii cu Big Data. În cazul în care proiectul este considerat un succes, el poate fi folosit ca model pentru determinarea volumului de muncă necesar pentru a trece aplicaţia în faza de producţie. Nivelul de efort necesar cuprinde integrarea abordării ca parte a managementului informaţiilor unificate şi a arhitecturii de procesare ca parte a sistemului de producţie pe durata ciclului de viaţă.

Acestea fiind spuse, odată ce s-a decis abordarea proiectului pilot de Big Data şi bugetul a fost aprobat şi alocat, este necesară utilizarea unei liste de verificare a sarcinilor de îndeplinit pentru demararea proiectului-pilot:

1. Definirea criteriilor de succes, care sunt legate de acţiuni cheie cum ar fi creşterea veniturilor, scăderea costurilor, îmbunătăţirea relaţiilor cu cetăţenii sau reducerea riscului.

2. Stabilirea cerinţelor pentru achiziţia de date prin discuţii cu proprietarii proceselor de afaceri pentru a înţelege ce tipuri de seturi de date ar fi valoroase ca parte a aplicaţiei de Big Data, precum şi sursele lor, mijloacele prin care aceste date sunt achiziţionate, metoda de obţinere a datelor, frecvenţa de reîmprospătare a datelor, orice metadate disponibile (sau necesare), şi critic, volumul de date.



3. Caracterizarea scenariilor de utilizare a datelor prin examinarea modului în care seturi de date vor fi modelate şi utilizate. Aceasta include examinarea modelelor datelor, precizând politici pentru păstrarea datelor, decizând cu privire la tipurile de analize care trebuie efectuate şi tipurile de rapoarte care trebuie generate şi integrarea operaţională în cadrul proceselor de afaceri selectate.

4. Evaluarea cerinţelor platformei aplicaţiei pentru proiectarea, construirea, execuţia şi testarea pilot. Se identifică cerinţele de componente tehnologice necesare şi se elaborează un plan de dobândire a acestor resurse.

5. Evaluarea cerinţelor de competenţe care depăşesc stereotipul "specialist în date": ingineri de sistem, programatori cu experienţă cu înaltă performanţă în calcul paralel / distribuit / managementul datelor şi practicieni în integrarea datelor, precum şi practicieni în business intelligence.

6. Selectarea platformei pilot prin contactarea potenţialilor furnizori ai tehnologiei şi solicitarea ajutorului lor pentru furnizarea unei platforme, precum şi evaluarea modului în care instrumentele open source cum pot fi instalate pe hardware-ul propus. Compararea opţiunilor disponibile şi selectarea uneia pentru pilot.

7. Pregătirea mediului de dezvoltare pentru proiectul pilot prin instalarea şi configurarea hardware, stocarea, gestionarea, integrarea, raportarea / analiza datelor şi dezvoltarea componentelor aplicaţiei pentru a permite proiectarea, dezvoltarea şi testarea acesteia.

8. Activarea metodelor de integrare a datelor pentru accesarea, analiza şi stocarea datelor într-un mod care să sprijine nevoia pentru înaltă performanţă.

9. Instituirea de metrici de performanţă care sunt definite la începutul procesului ca măsuri specifice care sunt puse în aplicare prin măsurare continuă.

10. Proiectarea, dezvoltarea şi testarea aplicaţiei în cadrul unui mediu de dezvoltare care permite programarea, executarea iterativă, depanarea şi analiza performanţelor pentru a ajuta la optimizarea vitezei de execuţie. Testele corespunzătoare este necesar să fi fost deja dezvoltate şi pot fi executate punând la dispoziţie rezultate obţinute.

11. Evaluarea indicatorilor de performanţă şi verificarea ca valorile obţinute de către sistemul pilot sunt în concordanţă cu valorile anticipate şi obiectivele de performanţă.

În acest moment, ar trebui să fie clar dacă sau nu Soluţia de Big Data are potenţial de a adăuga valoare afacerii. Cu toate acestea, acest fapt nu poate fi unicul factor decisiv, mai ales atunci când intenţia este de a include aceste noi tehnologii în mediul existent. Alte consideraţii includ posibilitatea trecerii tehnologiei în mediul de producţie, cum se aliniază cu tehnologiile existente, efortul implicat în scalarea aplicaţiei pentru a satisface nevoile de producţie, formarea şi gestionarea competenţelor, dezvoltarea unui plan de integrare şi asigurarea că tehnologia este scalabilă pentru un număr mai mare de utilizatori, fiecare tinzând spre performanţe tot mai mari.



Recomandări pentru Guvern

Agenţiile guvernamentale ar trebui să exploreze tehnologii viabile economic de gestionare a înregistrărilor automate şi soluţii pentru a reduce povara responsabilităţilor de administrare a înregistrărilor. Tehnologia este în continuă evoluţie pentru a oferi soluţii avansate pentru a sprijini backup-ul datelor, recuperarea, precum şi cerinţele de arhivare. Infrastructura de stocare, care este capabilă să satisfacă cerinţele specifice legate de volumul de date, viteza şi varietatea (trei din patru "V", aşa cum este descris în cadrul Big Data) va fi esenţială pentru agenţiile guvernamentale pentru a utiliza şi procesa cu succes Big Data. O mai mare vizibilitate a informaţiilor organizaţionale - împreună cu capacitatea de a produce documentaţia atunci când este nevoie - permite agenţiilor sporirea eficienţei şi productivităţii angajaţilor, răspunsul la întrebări, luarea de decizii în cunoştinţă de cauză, prin conectarea informaţiilor corelate sau necorelate şi furnizarea de informaţiile necesare pentru transparenţă, colaborare şi guvernare participativă.

Agenţiile guvernamentale ar trebui să găsească în mod strategic soluţii pentru creşterea tot a mare a volumului de date, cum ar fi planuri care abordează stocarea datelor tradiţionale, precum şi stocarea informaţiilor digitale - structurate şi nestructurate şi metadate. Constrângerile bugetare forţează agenţiile să redimensioneze modul de stocare a informaţiilor Big Data. Planurile ar trebui să includă stocarea pe niveluri, bandă, backup şi recuperare în Cloud, precum şi o analiză a costurilor în raport cu beneficiile multiplelor opţiuni de stocare. Banda oferă stocarea eficientă, eficienţa din punct de vedere al costurilor şi de încredere pentru datele inactive şi, rareori solicitate. Aceasta permite agenţiilor guvernamentale să păstreze date valoroase companiei securizate pe bandă. Majoritatea informaţiilor guvernamentale sunt probabil inactive. Banda oferă depozitare pe tot parcursul vieţii, capacitate mare pentru păstrarea datelor pe termen lung pentru a sprijini păstrarea, precum şi arhivarea datelor inactive. Backup-ul pe bandă şi recuperarea oferă o opţiune mai sigură şi mai economică decât soluţiile bazate pe disc, dar este nevoie de un management mai complicat. Stocarea datelor pe disc şi pe bandă faţă de stocarea numai pe disc poate oferi un mediu de stocare mai ieftin pentru datele inactive, care să permită agenţiilor optimizarea procesele de backup la faţa locului şi offsite. Backup-ul, recuperarea şi arhivarea bazate pe Cloud oferă beneficii diferite şi pot juca un rol complementar într-o strategie de stocare. Pentru datele care sunt în continuă schimbare şi necesită acces scurt şi în timp real, tehnologia Cloud oferă o soluţie excelentă de backup şi recuperare. Aceasta permite mişcarea mai rapidă şi mai frecventă şi regăsirea practic instantanee a datelor. În timp ce soluţiile bazate pe Cloud pot fi, pe termen lung, mai scumpe decât cele cu bandă, ele oferă backup automat şi arhivare rapidă care ajută la reducerea volumului de muncă în IT.

Folosirea tehnologiei Cloud pentru backup, recuperare, precum şi pentru activităţi de arhivare oferă un sistem flexibil, scalabil, ajutând la menţinerea scăzută a costurilor, în timp ce resursele necesare pentru a gestiona procesele aferente sunt minimizate.

Multe agenţii regândesc rolul modului tradiţional de stocare şi implementează abordări combinate rentabile utilizând banda pentru arhivare, discurile pentru înregistrări frecvent solicitate şi stocarea în Cloud pentru informaţii Big Data.



O abordare strategică pentru stocare permite agenţiilor să producă documentaţia atunci când este nevoie, sporeşte eficienţa şi productivitatea angajaţilor şi oferă informaţiile necesare pentru transparenţă, colaborare şi guvernare participativă.

4.6. Utilizarea bunelor practici în domeniul Big Data

4.6.1. Aspecte generale teoretice legate de bunele practici Câteva din caracteristicile principale ale bunelor practici sunt prezentate de

(Stenstrom, 2006):

1) Caracteristici referitoare la funcţionalitate: a) seturi de funcţii care generează învăţarea; b) practici care şi-au dovedit validitatea prin obţinerea de rezultate bune; c) realizări care pot fi transferate oriunde ca seturi funcţionale.

2) Caracteristici referitoare la procesare: a) metode care ajută la atingerea obiectivelor definite pentru o activitate; b) utilizarea cercetării pentru stabilirea procedurilor de colectare a datelor.

3) Caracteristici inovatoare şi transformatoare: a) Bunele practici sunt inovative şi, în consecinţă, acestea permit introducerea de noi proceduri şi abordări; b) bunele practici sunt asociate cu proiecte de succes; c) bunele practici pot fi resurse pentru alte noi bune practici deoarece ele conţin elemente necesare în rezolvarea unor probleme şi, deci, pot fi transformate să se potrivească unor situaţii diferite.

Pornind de la aceste caracteristici, în domeniul Big Data, putem identifica următoarele criterii preliminare pentru bune practici:

• Ele oferă soluţii unor probleme sau introduc noi proceduri.

• Ele oferă posibilităţi noi de înţelegere a unor mecanisme economice şi sociale.

• Ele asigură o utilizare mai eficientă a datelor

• Ele asigură luarea nor decizii mai bune pe baza rezultatelor obţinute din analizarea datelor de tip Big Data.

• Ele asigură integrarea unor surse de date eterogene.

• Ele permit evaluarea performanţelor sectorului public.

4.6.2. Bune practici pentru managementul Big Data Într-un mediu Big Data specialiştii IT trebuie să se asigure că (ExecBlueprints, 2013):

• Prin utilizarea unor instrumente de date se monitorizează frecvent performanţa pentru a localiza gâtuirile, căderile sistemului şi anomaliile;

• Sunt logate toate interacţiunile din cadrul sistemului, incluzând statisticile, datele despre evenimente şi datele despre tranzacţii;

• În mod fizic şi operaţional, depozitul Big Data aderă la toate reglementările aplicabile;

• Depozitele de date sunt administrate în mod unitar peste seturile mari de date;

• Un ghid de bune practici este dezvoltat şi revăzut în mod regulat astfel încât el să rămână actualizat şi corect, fiind aplicat la unităţile de business;



• O bibliotecă a infrastructurii IT (ITIL) documentează planurile, efortul şi schimbările, asociate cu depozitul Big Data;

• Politicile şi procedurile sunt în mod continuu actualizate ca să răspundă noilor tehnologii şi reglementărilor;

• Problemele sunt rezolvate în mod incremental, prin ajustări minore, pentru a evita ieşirea în afara cadrului normal într-un mod dezastruos.

4.6.3. Studiu de caz – Proiectul European Anticorupţie În cadrul proiectului European “Anticorruption Policies Revisited-Global Trends and

European Responses to the Challenge of Corruption”, la care participă douăzeci de grupuri de cercetare din douăzeci de ţări, cu perioadă de desfăşurare între anii 2012 şi 2017, una din activităţile importante constă în Măsurarea Riscului Corupţiei utilizând Big Data generate în cadrul achiziţiilor publice din Europa Centrală şi de Est.

Centrul de cercetare a corupţiei de la Budapesta (Corruption Research Center Budapest - CRCB) este o organizaţie neguvernamentală, care este formată dintr-o echipă interdisciplinară de cercetători din domeniul politicii, economişti, cercetători din domeniul informaticii şi avocaţi. CRCB a colectat în ultimii ani cantităţi imense de date neexploatate înainte, din câteva ţări din Europa, calculând din aceste seturi de date riscul corupţiei şi evidenţiind cartelurile, prin utilizarea unor metode cantitative şi calitative. CRCB a definit mai mulţi indicatori care sunt bazaţi pe date administrative. Aceste date sunt preluate de la agenţii publice şi de la departamente funcţionale, unele din aceste date fiind publice, iar altele fiind private în cadrul organizaţiilor internaţionale, private sau publice. Astfel prin analizarea unor cantităţi mari de date diferite, se poate depista că, deşi unele licitaţii apar ca fiind imparţiale, corecte, deschise, furnizând acces egal competitorilor, ele sunt, de fapt, incorecte (Figura 22).

Figura 22. Carteluri – Unele firme licitează împreună cu un câştigător şi pierd periodic

Astfel, se poate descoperi din analiza datelor că un singur ofertant a transmis o ofertă, apelul pentru licitaţie nu a fost publicat într-o publicaţie oficială, că a fost utilizată o procedură de urgenţă pentru a urgenta procesul, procesul de licitaţie a fost anulat sau a fost



relansat, criteriilor nefinanciare le-a fost acordată o prea mare importanţă, contractele au fost modificate în timpul implementării, valoarea sau durata contractului au crescut. Construirea unor indicatori de guvernare de generaţie nouă utilizând Big Data necesită, în timp real, disponibilitatea datelor din surse electronice. Aceste seturi de date sunt derivate din sisteme tranzacţionale ale administraţiei publice, la nivel de micro-date, care descriu comportamentul actorilor din sistem. Datele trebuie să fie legate pentru a genera constatări comparabile între ţări, organizaţii şi în timp (Karippacheril, 2014), (Fazekas, 2014).



4. Concluzii şi planul de continuare Datorită volumelor din ce în ce mai mari de date din cadrul organizaţiilor, stocarea şi

procesarea acestora cu ajutorul sistemelor de baze de date clasice a devenit din ce în ce mai dificilă. Astfel a fost necesară dezvoltarea unor tehnologii care să stocheze cât mai eficient datele, cu o redundanţă cât mai mică şi care sa aplice tehnici de procesare paralelă pentru reducerea timpului necesar extragerii informaţiilor dorite.

Printre problemele legate de integrarea ”Big Data” se numără varietatea surselor de date, calitatea datelor ce urmează a fi integrate şi vizualizarea datelor.

Una dintre cele mai utilizate tehnologii de integrare ”Big Data” este MapReduce, fiind utilizată de companii precum Google, Yahoo sau Facebook deoarece oferă o serie de avantaje: suport pentru seturi foarte mari de date distribuite în clustere de computere şi posibilitatea de procesare atât a datelor structurate cât şi a celor nestructurate.

Big Data este o oportunitate de a descoperi perspective în tipuri noi şi emergente de date şi de conţinut, pentru a crea un business mai agil şi pentru a răspunde întrebărilor care anterior erau considerate de neatins.

Capacitatea de a utiliza Big Data pentru a conduce la rezultate mai bune în afaceri face ca acesta să fie foarte atractiv.

Big Data înseamnă schimbarea în profunzime a modului de operare a business-ului – prin trecerea de la modelul bazat, majoritar, pe experienţa decidentului, la cel bazat pe informaţii cu valoare reală pentru afacere şi organizaţie în sine.

Accelerarea creşterii volumului de date va servi doar la rezolvarea problemelor rezultate din complexitatea inerentă a managementului informaţiilor guvernamentale şi din analizele necesare în afaceri. Infrastructura existentă este extrem de inadecvată pentru a permite niveluri corecte de agilitate pentru a face faţă provocărilor din următoarele decenii. Acum este momentul de a evalua cu grijă managementul existent în agenţiile guvernamentale şi cerinţele de analiză a informaţiilor, luând în considerare necesitatea de a continua sprijinirea eficientă a programelor existente şi, în acelaşi timp, a schimbărilor politice viitoare. Este momentul potrivit pentru Big Data şi analiza lor.

Trebuie început luând în considerare obiectivele cheie de afaceri şi determinând gradul în care capabilităţile de analiză a datelor sunt limitate de platformele tehnologice existente. Este necesară examinarea tipurilor de probleme de afaceri care urmează să fie abordate pentru a evalua adecvarea lor la o soluţie tehnologică de Big Data. Trebuie luaţi în considerare factorii cheie de performanţă operaţională cum ar fi: scalabilitate în raport cu volumele de date şi scopul analizei, extensibilitate a mediului de a creşte în pas cu cererea şi elasticitatea în a satisface cererea de sarcini de lucru analitice mixte dintr-o varietate de afaceri pentru consumatori de informaţii diferiţi. Este necesară concentrarea pe variabilele cheie: volumele de date, varietatea datelor, nevoia de performanţă şi paralelizarea.

Se face apoi dezvoltarea planului strategic pentru a evalua alternativele de Big Data. Se apreciază cerinţele de performanţă care sunt utilizate pentru a selecta furnizori şi produse diferite. Clarificarea criteriilor de succes permite cea mai bună determinare a valorii. Planul



strategic trebuie să alinieze tehnologiile de Big Data cu infrastructurile de Business Intelligence şi de analiză existente. Cu cât Big Data câştigă teren, suntem în pragul unei noi ere în managementul informaţiilor. Datele de mari dimensiuni pot adăuga valoare prin consolidarea analizei şi practicilor de modelare predictive. Cu toate acestea, este binevenită investirea de efort pentru definirea corespunzătoare a domeniului programului de Big Data pentru a-l alinia cu mediul existent. Big Data vor fi o parte integrantă a unei strategii globale de analiză, dar nu pot ocoli cele mai bune practici asociate cu aderarea la ciclul de viaţă al dezvoltării sistemului.

Rezultatele prezentate în lucrare confirmă realizarea obiectivelor etapei actuale şi se constituie într-o bază solidă de informaţii necesare pentru realizarea etapei următoare „Analiza tehnologiilor, bunelor practici şi a soluţiilor de eGuvernare care utilizează Big Data la nivel naţional, european şi internaţional”.

Pornind de la rezultatele obţinute, în etapa următoare colectivul de cercetare are de realizat următoarele activităţi:

- Identificarea şi analiza tehnologiilor, bunelor practici şi a soluţiilor implementate în

sisteme informaţionale guvernamentale

- Analiza soluţiilor de Cloud Computing ca suport pentru tehnologii Big Data

- Determinarea unui set de caracteristici reprezentative pentru dezvoltarea de servicii

bazate pe Big Data pentru sisteme informaţionale guvernamentale

- Diseminarea rezultatelor prin Comunicări şi articole în reviste din ţară şi/sau din

străinătate



5. Bibliografie 1. Adelaide O'Brien, 2012, The Impact of Big Data on Government WHITE PAPER,

October 2012, IDC Government Insights, pp.1-12.

2. Anuganti, V., Typical “Big” Data Architecture. 2012. Retrieved from: http://venublog.com/2012/11/30/typical-big-data-architecture/.

3. Apache Software Foundation. (2013a). Welcome to Apache Hadoop. Retrieved from http://hadoop.apache.org/.

4. Apache Software Foundation. (2013b). Welcome to Apache HBase. Retrieved from http://hbase. apache.org/.

5. Apache Software Foundation. (2013c). Architecture overview: What is the difference between HBase and Hadoop/HDFS? Retrieved from http://hbase.apache.org/book/ architecture. html#arch.overview.

6. Awadallah, A., Graham, D., Hadoop and the data warehouse: When to use which. Dayton, OH: Teradata Corporation. 2011. Retrieved from http://www.teradata.com/white-papers/Hadoop-and-the-Data-Warehouse-When-to-Use-Which/.

7. Azzini, A., Ceravolo, P., Consistent process mining over big data triple stores, în Proceeding of the International Congress on Big Data (Big Data '13), pp. 54–61, 2013.

8. Bodapati, V., Data Integration Ecosystem for Big Data and Analytics. 2013. Retrieved from: http://smartdatacollective.com/raju-bodapati/103326/data-integration-ecosystem-big-data-and-analytics.

9. Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., Brandic, I., Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation Computer Systems, vol. 25, no. 6, pp. 599-616, 2009.

10. Cao, L., Weiss, G., Yu, P., A brief introduction to agent mining, Autonomous Agent Multi-Agent Systems, vol. 25, pp. 419–424, 2012.

11. Cattell, R., Scalable SQL and NoSQL data stores. ACM SIGMOD Record 39(4), pp. 12–27, 2011.

12. Chan, J. O., An Architecture for Big Data Analytics, Communications of the IIMA; 2013, vol. 13, no. 2, pp.1-13.

13. Chen, H., Chiang, R. H. L., Storey, V. C., Business intelligence and analytics: From big data to big impact. MIS Quarterly, vol. 36, no. 4, pp. 1165-1188, 2012.

14. CommVault, 5 Ways to illuminate your dark data, 2014, http://nth.com/wp-content/uploads/2015/03/5_Ways_to_Illuminate_Your_Dark_Data.pdf.

15. David Loshin, Big Data and Government: Business Drivers and Best Practices, 2013

16. Dayley Alan: File Analysis Innovation Delivers an Understanding of Unstructured Dark Data, Gartner Inc. Innovation Insight, March 2013.

17. Execblueprints, Ideas to Build Upon & Action Points, ExecBlueprints, Copyright Books24x7, 2013.

18. Fazekas, Mihály., István János Tóth - Three indicators of institutionalised grand corruption using administrative data, Explanatory note for the U4 - Proxy Workshop, Bergen, Norway, 4/2/2014, http://www.crcb.eu/wpcontent/uploads/2014/01/CRCB_3%20indicators%20of%20inst%20grand%20corr_U4ProxyChallenge_2014.pdf.

http://hbase.apache.org/book/

http://nth.com/wp-content/uploads/2015/03/5_Ways_to_Illuminate_Your_Dark_Data.pdf

http://nth.com/wp-content/uploads/2015/03/5_Ways_to_Illuminate_Your_Dark_Data.pdf

http://www.crcb.eu/wpcontent/uploads/2014/01/CRCB_3%20indicators%20of%20inst%20grand%20corr_U4ProxyChallenge_2014.pdf

http://www.crcb.eu/wpcontent/uploads/2014/01/CRCB_3%20indicators%20of%20inst%20grand%20corr_U4ProxyChallenge_2014.pdf



19. Gartner, „Answering Big Data's 10 Biggest Vision and Strategy Questions”. August 2014. (http://www.gartner.com/doc/2822220?refval=&pcp=mpe).

20. Gartner: 10 Big Data Software Requirements, http://www.information-management.com/gallery/Big-Data-Required-Software-Applications-10026664-1.html, accesat august 2015.

21. Gang-Hoon Kim, Silvana Trimi, Ji-Hyong Chung, “Big-Data Applications în the Government Sector”. Communications of the ACM, 57(3), 2014, pp: 78-85.

22. Gantz, J., D. Reinsel, Extracting value from chaos. IDC iView, 2011, pp 1–12.

23. Hadoop, A., Hadoop, 2009, http://hadoop.apache.org/.

24. Hedlund, B., Understanding Hadoop clusters and the network. 2011. Retrieved from http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/.

25. Herodotou, H., şi alţii, Starfish: A self-tuning system for big data analytics, ser. CIDR2011, 2011.

26. Hindman, B., Konwinski, A., Zaharia, M., Ghodsi, A., Joseph, A. D., Katz, R., Shenker, S., Stoica, I., Mesos: a platform for fine-grained resource sharing în the data center, Proceedings of the 8th USENIX conference on Networked systems design and implementation, p. 22, 2011. [Online]. Available: http://dl.acm.org/citation.cfm?id=1972457.1972488.

27. Howard, J.H., M.L. Kazar, S.G. Menees, D.A. Nichols, M. Satyanarayanan, R.N. Sidebotham, M.J. WEST, Scale and performance în a distributed file system. ACM Trans Computing Systems 6(1), 1988, pp. 51–81.

28. Hurwitz, J., Alan Nugent, Fern Halper, Marcia Kaufman, Big Data For Dummies, ISBN 1118504224, 2013, pp. 1-336.

29. Karippacheril, Tina George., Robert P. Beschel, Measuring Corruption Risk using ‘Big’ Public Procurement Data în Central & Eastern Europe, http://blogs.worldbank.org/governance/measuring-corruption-risk-using-big-public-procurement-data-central-eastern-europe, 2014.

30. Kevin O'Dell, How-to: Select the Right Hardware for Your New Hadoop Cluster, http://blog.cloudera.com/blog/2013/08/how-to-select-the-right-hardware-for-your-new-hadoop-cluster/, 2013.

31. Khan, N., Yaqoob, I., Hashem, I. A. T., et al., Big Data: Survey, Technologies, Opportunities, and Challenges, The Scientific World Journal, vol. 2014, Article ID 712826, 18 pagini, 2014. doi:10.1155/2014/712826.

32. Kim, H., Raman, A., Liu, F., Lee, J., August, D. I., Scalable speculative parallelization on commodity clusters. Proceedings of the 2010 43rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO ’43), pp. 3-14, 2010. doi: 10.11.09/ MICRO.2010.19.

33. Labrinidis, A., H.V. Jagadish, Challenges and opportunities with big data. Proceedings of Very Large Data Base Endowment, 2012, 5(12), pp. 2032-2033.

34. Laney, D., 3-d data management: controlling data volume, velocity and variety. META Group Research Note, 6 February 2001.

35. Loshin, David., Big Data Analytics From Strategic Planning to Enterprise Integration with Tools, Techniques, NoSQL, and Graph, Morgan Kaufmann -Elsevier Inc., 2013, ISBN: 978-0-12-417319-4, pp. 1-120.

http://www.gartner.com/doc/2822220?refval=&pcp=mpe

http://www.information-management.com/gallery/Big-Data-Required-Software-Applications-10026664-1.html

http://www.information-management.com/gallery/Big-Data-Required-Software-Applications-10026664-1.html

http://learning.acm.org/primarytemplatefiles/customcode/skillport_main.cfm?h=5&isbn=52660

http://blogs.worldbank.org/governance/measuring-corruption-risk-using-big-public-procurement-data-central-eastern-europe

http://blogs.worldbank.org/governance/measuring-corruption-risk-using-big-public-procurement-data-central-eastern-europe

http://blog.cloudera.com/blog/2013/08/how-to-select-the-right-hardware-for-your-new-hadoop-cluster/

http://blog.cloudera.com/blog/2013/08/how-to-select-the-right-hardware-for-your-new-hadoop-cluster/



36. Marz, N., Warren, J., Big data - Principles and best practices of scalable realtime data systems (Chapter 1), 2014.

37. MccormicK, Douglas., Samsung, Nokia Show 5G Tech at NI Week, http://spectrum.ieee.org/tech-talk/at-work/test-and-measurement/samsung-nokia-show-5g-tech-at-ni-week, 2015.

38. Mcfedries, Paul., Beyond Just “Big” Data, We need new words to describe the coming wave of machine-generated information, http://spectrum.ieee.org/computing/software/beyond-just-big-data, 2015.

39. Minelli, M., Chambers, M., Dhiraj, A., Big data, big analytics: Emerging business intelligence and analytic trends for today’s businesses, 2013. Hoboken, NJ: John Wiley & Sons, Inc.

40. Morabito, V., “Big Data and Analytics”. Springer International Publishing Switzerland 2015. DOI 10.1007/978-3-319-10665-6_2.

41. Mac Creary, D., Kelly, A. (2014). Making Sense of NoSQL: A guide for managers and the rest of us. Manning, ISBN-13: 978-1617291074, ISBN-10: 1617291072.

42. Obama (2012.) “Obama Administration Unveils ‘Big Data’ Initiative: Announces $200 Million în New R&D Investments,” accessed via http://www.whitehouse.gov/sites/default/files/microsites/ostp/big_data_press_release_final_2.pdf

43. Oracle, Big Data: A Big Deal for Public Sector Organizations. Oracle’s big data solutions, 2012. https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC0QFjAAahUKEwjQ_67qu5HHAhUCWRQKHbnDDyM&url=http%3A%2F%2Fwww.oracle.com%2Fus%2Findustries%2Fpublic-sector%2Fpublic-sector-big-data-br-1676649.pdf&ei=qcHBVZCHG4KyUbmHv5gC&usg=AFQjCNFHaDsyH6PJi VQ1feOIMX7_vq1fyA&sig2=KW5VsoW5RCjcH5cQX7LzeA

44. Rivera, Janessa., Rob Van Der Meulen, Gartner's 2014 Hype Cycle for Emerging Technologies Maps the Journey to Digital Business, http://www.gartner.com/newsroom/id/2819918, 2014.

45. Rouda, Nik., Mark Peters, IBM: The Optimal Storage Platform for Big Data, White paper, The Enterprise Strategy Group, March, 2015.

46. Sonra-1, Admin., Data Warehousing în the age of Big Data. The end of an era?, 2015, http://sonra.io/data-warehousing-in-the-age-of-big-data-the-end-of-an-era/.

47. Sonra-2, Admin., Data Warehousing în the Age of Big Data. RDBMS Scalability, Exploding Data Volumes and License Costs, http://sonra.io/data-warehousing-in-the-age-of-big-data-rdbms-scalability-exploding-data-volumes-and-license-costs/.

48. Stenstrom, M., Laine, K., Towards good practices for practice-oriented assessment în European vocational education, Institute for Educational Research, University of Jyväskylä, Finland, http://www.ktl-julkaisukauppa.fi/, ISSN 1456-5153, 2006, pp. 1-68.

49. O’Driscoll, A., Daugelaite, J., Sleator, R. D., ’Big data’, Hadoop and cloud computing în genomics, Journal of Biomedical Informatics, vol. 46, no. 5, pp. 774–781, 2013.

50. Sathi, A., Big data analytics: Disruptive technologies for changing the game. 2012. Boise, ID: MC Press.

51. Shvachko, K., Kuang, H., Radia, S., Chansler, R., The hadoop distributed file system, în MSST, 2010, pp. 1–10.

http://spectrum.ieee.org/tech-talk/at-work/test-and-measurement/samsung-nokia-show-5g-tech-at-ni-week

http://spectrum.ieee.org/tech-talk/at-work/test-and-measurement/samsung-nokia-show-5g-tech-at-ni-week

http://spectrum.ieee.org/computing/software/beyond-just-big-data

http://www.whitehouse.gov/sites/default/files/microsites/ostp/big_data_press_release_final_2.pdf

http://www.whitehouse.gov/sites/default/files/microsites/ostp/big_data_press_release_final_2.pdf

https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC0QFjAAahUKEwjQ_67qu5HHAhUCWRQKHbnDDyM&url=http%3A%2F%2Fwww.oracle.com%2Fus%2Findustries%2Fpublic-sector%2Fpublic-sector-big-data-br-1676649.pdf&ei=qcHBVZCHG4KyUbmHv5gC&usg=AFQjCNFHaDsyH6PJi%20VQ1feOIMX7_vq1fyA&sig2=KW5VsoW5RCjcH5cQX7LzeA





http://www.gartner.com/newsroom/id/2819918

http://sonra.io/data-warehousing-in-the-age-of-big-data-the-end-of-an-era/

http://sonra.io/data-warehousing-in-the-age-of-big-data-rdbms-scalability-exploding-data-volumes-and-license-costs/

http://sonra.io/data-warehousing-in-the-age-of-big-data-rdbms-scalability-exploding-data-volumes-and-license-costs/

http://www.ktl-julkaisukauppa.fi/



52. Sindol, D., Big Data Basics - Part 3 - Overview of Hadoop, 2014, Retrieved from: https://www.mssqltips.com/sqlservertip/3140/big-data-basics--part-3--overview-of-hadoop/.

53. Stonebraker, M., Çetintemel, U., Zdonik, S., The 8 requirements of real-time stream processing, SIGMOD Rec., vol. 34, no. 4, pp. 42–47, Dec. 2005. [Online]. Available: http://doi.acm.org/10.1145/1107499.1107504.

54. Tantisiriroj, W., Patil, S., Gibson, G., Data intensive file systems for internet services: A rose by any other name. 2008. Pittsburgh, PA: Parallel Data Laboratory, Carnegie Mellon University. Retrieved from http://www.pdl.cs.cmu.edu/PDL-FTP/PDSI/CMU-PDL-08-114.pdf.

55. Twardowski, B., Ryzko, D. Multi-agent architecture for real-time Big Data processing. In 2014 IEEE/WIC/ACM International Joint Conferences on Web Intelligence (WI) and Intelligent Agent Technologies (IAT). IEEE 2014, pp. 333-337, doi: 10.1109/WI-IAT.2014.185.

56. Vavilapalli, V. K., Murthy, A. C., Douglas, C., Agarwal, S., Konar, M., Evans R., Graves, T., Lowe, J., Shah, H., Seth, S., Saha, B., Curino, C., O’Malley, O., Radia, S., Reed, B., Baldeschwieler, E., Apache hadoop yarn: Yet another resource negotiator, în Proceedings of the 4th Annual Symposium on Cloud Computing, ser. SOCC ’13. New York, NY, USA: ACM, 2013, pp. 5:1–5:16. [Online]. Available: http://doi.acm.org/10.1145/2523616.2523633.

57. Zhu, Y., Shasha, D., Statstream: Statistical monitoring of thousands of data streams în real time, în Proceedings of the 28th International Conference on Very Large Data Bases, ser. VLDB ’02. VLDB Endowment, 2002, pp. 358–369. [Online]. Available: http://dl.acm.org/citation.cfm?id=1287369.1287401.



6. Anexa - Glosar de termeni

Big Data Volum crescut, viteză crescută şi varietate mare de active de informaţie care cer eficienţă, forme inovative ale procesării informaţiei pentru înţelegere îmbunătăţită şi luare decizii.

Business intelligence (inteligenţa în afaceri)

Un set de tehnici şi instrumente pentru transformarea datelor brute în informaţii semnificative şi utile în scopuri de analiză de afaceri.

Crowdsourcing Procesul obţinerii serviciilor, ideilor sau conţinutului necesare prin solicitarea contribuţiilor de la un grup mare de oameni, şi în special de la comunitatea online, mai degrabă decât de la angajaţii tradiţionali sau de la furnizori.

Data Scientist (specialist în date)

Rolul critic pentru extragerea perspectivă de la active de informaţie şi iniţiativele "big data" care necesită o combinaţie largă de competenţe.

OLAP (analiza online a datelor)

O tehnică bazată pe calculator pentru analiză multi-dimensională a datelor afacerii.

Dark data (date întunecate)

Activele de informaţii colectate de organizaţii, procesare şi stocare în timpul activităţilor de afaceri obişnuite, care nu reuşesc în general să fie utilizate în alte scopuri (de exemplu, analiză, relaţii de afaceri şi valorificare directă); stocarea şi securizarea datelor suportă de obicei cheltuieli în plus (şi câteodată risc crescut) decât valoare [Gartner].

Big Data Analytics-BDA (analiza big data)

Aplicarea capacităţilor analitice (descript pe seturi de date uriaşe, variate şi în schimbare.

Internet of Things (IoT) Internetul lucrurilor (sau al obiectelor) se referă la soluţiile tehnologice bazate pe Internet care permit interconectarea şi comunicarea între cele mai diverse dispozitive.

Analytics Procese de analiză a datelor.

Loosse coupling Legături slabe, este o abordare a interconectare a componentelor într-un sistem sau reţea, astfel încât aceste componente, numite elemente, depind unele de altele cât mai puţin posibil.

Sinks Colectoare de date

Bucketing concept Altă tehnică pentru descompunerea tabelei de date în mai multe părţi uşor de mânuit.

PLANUL SECTORIAL DE CERCETARE-DEZVOLTARE AL MSI ...

Documents

Transcript of PLANUL SECTORIAL DE CERCETARE-DEZVOLTARE AL MSI ...