Până de curând, orice companie respectabilă construia un Data Warehouse - o bază de date de dimensiuni considerabile, în care se "strâng" datele din cât mai multe sisteme operaționale ale organizației. Cu ceva efort, în fiecare noapte acele date eterogene sunt curățate, standardizate, legate între ele și, cu puțin noroc, gata de interogare în dimineața zilei următoare.
Data Warehouse-ul a fost "sfântul Graal" al arhitecților, analiștilor și decidenților de business, în special din două motive: primul se referă la speranța că se va răspunde tuturor întrebărilor și al doilea, la dificultatea de ajunge cu implementarea până la scopul final. Bineînțeles, avantajul unei baze de date centralizate, unice, care să aibă răspunsuri pentru orice întrebare legată de activitatea organizației, este incontestabil. Dar la fel de incontestabile sunt și rezultatele - studii bine documentate au arătat că majoritatea proiectelor de a construi un Enterprise Data Warehouse eșuează, iar cele declarate un succes sunt doar parțial terminate și sunt folosite doar pentru anumite scopuri, fără să devină acel multdorit centru complet de date al companiei.
Epoca acestor monoliți a trecut fără îndoială. Și aceasta nu din pricina eforturilor mari necesare pentru dezvoltare, nici din cauza costurilor sau a complexității proceselor de implementat, ci din cauza lipsei de adaptabilitate și scalabilitate. Structurile din baza de date au devenit încetul cu încetul un corset, limitând drastic agilitatea necesară provocărilor din prezent. Analiștii doresc acum să aibă la dispoziție noi și noi seturi de date, unele semi- sau chiar ne-structurate, vor să folosească instrumente precum Prelucrarea Limbajului Natural (NLP) și sentiment analysis pe date din social media. Nu în ultimul rând, datele de ieri nu mai sunt foarte utile astăzi - majoritatea deciziilor se iau "la cald", pe baza informațiilor obținute în timp real. Pe scurt, organizația modernă are nevoie de date mai multe, mai repede, mai ușor de accesat și interogat.
Articolul de față își propune să analizeze atributele cheie ale unui nou tip de Data Warehous, cel așa numit Data Lake, deși de cele mai multe ori Data Lake este privit ca fiind complementar unui Data Warehouse și nu un înlocuitor. Pentru exemplificare, în continuare voi menționa serviciile oferite de cel mai important provider de soluții Cloud - Amazon Web Services (AWS), cu mențiunea că în general și ceilalți jucători mari de pe această piață (Microsoft Azure, Google Cloud Platform) oferă produse similare.
Aceasta a fost prima schimbare fundamentală, introdusă de apariția Hadoop și a ecosistemului de aplicații din jurul Hadoop. Acestea s-au potrivit ca o mănușă peste infrastructura din Cloud, permițând utilizatorilor să folosească (și să plătească) doar pentru volumul de date și puterea de calcul necesare la un anumit moment dat. De asemenea, a flexibilizat structura datelor care pot fi ingerate, întrucât nu mai suntem legați de un format proprietar de stocare. Nu în ultimul rând, a permis pătrunderea seturilor de date nestructurate, care nu ar fi avut niciodată un loc într-un Star Schema.
Low Latency - un atribut crucial al unui Data Lake - derivă din capacitatea acestuia de a ingera și de a lucra cu date în timp real din stream-uri. Se reduce sau chiar dispare cu totul nevoia de pre-procesare. Aceste date pot fi interogate și analizate aproape instantaneu, imediat ce au ajuns pe disc, sau chiar în timp ce se află în mișcare (vezi Amazon QuickSight).
Soluțiile de stocare în Cloud (AWS S3) oferă practic spațiu nelimitat, încât nu trebuie să ne mai îngrijorăm vreodată că depozitul de date a crescut prea mult. Acest aspect a condus la posibilitatea de a stoca datele la granularitate foarte mică, renunțând la pașii de agregare întâlniți frecvent într-un Data Warehouse și permițând astfel analize mult mai rafinate, până la nivel de tranzacție (de exemplu, analiza comportamentului clienților).
Când stocarea datelor se face în simple fișiere (obiecte) în S3, se pune imediat problema unui catalog descriptiv al datelor, flexibil dar similar structurilor dintr-o bază de date tradițională, structură în lipsa căreia analiza datelor devine frustrantă sau chiar imposibilă. În practică, menținerea separată a unui catalog de metadate este destul de dificilă atunci când structurile se schimbă frecvent. De aceea, se recurge de regulă la fișiere în format autodescriptiv, precum Parquet, Avro, ORC, JSON, XML etc., care conțin atât datele cât și structura lor.
Când punem la un loc toate componentele amintite, o arhitectură minimalistă pentru un Data Lake în AWS ar putea arăta ca în diagrama de mai jos:
Vom tinde spre achiziția datelor în timp real (cozi SQS, Kinesis sau Kafka), fără să excludem totuși metodele tradiționale de replicare, de exemplu prin fișiere.
S3 devine instrumentul central pentru stocare într-un Data Lake, cu opțiunea de a arhiva datele foarte puțin accesate în Glacier, pentru un cost infim.
Partea de procesare, clar delimitată de stocare, se poate realiza într-unul sau mai multe clustere EMR (Amazon Elastic MapReduce, distribuția oficială de Hadoop din AWS). Acesta are avantajul că poate scala, adăugând mai multe noduri la nevoie. Totodată, EMR suportă și alte framework-uri distribuite, precum Apache Spark sau Presto. Este posibil totuși ca S3 și EMR să nu înlocuiască total nevoia unui Data Warehouse clasic, în special când vorbim de modele dimensionale; aici Amazon vine cu un produs numit Redshift - un Data Warehouse ultrarapid și administrat automat, care scalează la nivel de petabytes.
În final, layer-ul de consumare a datelor deschis utilizatorului final poate acoperi cu ușurință instrumentele clasice de raportare și BI, dar vine și cu o serie de elemente noi. Aș aminti aici QuickSight (instrumentul de BI de la AWS) și platforma de Machine Learning, care deși nu impresionează deocamdată prin diversitatea algoritmilor, garantează o scalabilitate de până la miliarde de predicții pe zi, chiar și în timp real.
Ar mai fi aspecte de adăugat, precum controlul accesului și securitatea datelor în Cloud, recuperarea în caz de dezastru, costul migrării datelor către și dinspre Cloud și multe altele care pot face însă obiectul unui articol dedicat.
În concluzie, Big Data și infrastructura ca serviciu în Cloud au adus schimbări fundamentale în abordarea arhitecturii depozitelor de date. Pe de o parte, schimbări cantitative așa cum arată explozia volumului de date stocate practic și scăderea granularității, iar pe de alta, schimbări calitative reflectate în accesul mult mai rapid la informație și date nestructurate. Sistemele distribuite au devenit standardul, iar sistemele-monolit dispar sub greutatea Big Data. A îmbrățișa acest curent este acum sinonim cu asigurarea pentru companie a unui avantaj competitiv vital - informația.