Schimbările majore din mediul afacerilor au făcut ca o companie, oricât de departe s-ar afla de tehnologie, să fie și o companie software și, prin extensie, o companie de date. De obicei, companiile nu au nevoie imediat de o arhitectură complexă sau de o echipă de specialiști în BigData pentru a obține rezultate din date analitice și business intelligence (BI). Când nu sunteți sigur ce cale este de urmat pentru a rula analize avansate fără un efort suplimentar de planificare și strategie (construirea unei arhitecturi, echipe de programatori, costuri de stocare, infrastructură) - sunteți convinși că organizația dumneavoastră are nevoie de o nouă viziune. Aici intervin sistemele Middleware și soluțiile Cloud de stocare de date, precum Google BigQuery.
Experiența noastră de lucru cu numeroase companii, ne-a făcut să observăm că există trei principii care sunt necesare pentru a explora și rula analize avansate de date și a obține BI. În primul rând, companiile, trebuie să identifice, să combine și să gestioneze sursele de date multiple. În al doilea rând, acestea trebuie să poată să obțină analize avansate utilizând concepte cu care sunt familiare. În al treilea rând, un aspect critic este alegerea de tehnologie și arhitectură accesibilă în consonanță cu capacitățile personale existente.
Dorim un backend, o bază de date cu efort de mentenanță minim, care să poată fi scalat la nivel de terabytes, să suporte analiză profundă pe date mari, din surse multiple, complexe și nestructurate. Dorim, de asemenea, să avem costuri reduse, un limbaj de interogare simplu (de preferat SQL sau Javascript). Vom analiza cum Google BigQuery rezolvă această problemă pentru a ne atinge scopul final: să ajungem de la volum redus de date la Bigdata, să stocăm și să facem totul accesibil prin SQL.
BigQuery este un serviciu de baze de date oferit de Google pe Google Cloud Platform. Este destinat în principiu analizei Online Analytical Processing (OLAP), unde putem efectua interogări sofisticate. Are o performanță mare la interogări complexe, nu are nevoie de mentenanță și este ușor de integrat la o platformă deja existentă. Este potrivit pentru toate tipurile de afaceri: mici, startup, enterprise etc., deoarece nu este necesar o arhitectură proprie și este ușor de folosit de programatorii care au cunoștințe de baze de date: SQL, REST, ODBC, tehnici streaming data și event-based. Se poate scala la nivel de petabytes, rulează pe infrastructura Google și disponibilitatea resurselor nu se epuizează cu creșterea datelor.
Cu tehnologia de azi având la dispoziție sisteme de stocare de date variate, înseamnă că ne permitem financiar să ţinem datele în mai multe locuri. Programatorii împart componentele unei aplicații în bucăţi mai mici numite microservicii. Cea mai grea parte când vine vorba de microservicii sunt chiar datele, deoarece aceste sisteme au propria copie a datelor, nu sunt pregătite pentru interogări încrucișate, iar noi nu putem efectua analize combinate.
Primul lucru pe care trebuie să îl facem este să ne asigurăm că putem identifica, combina și gestiona surse de date multiple.
Când vorbim de identificarea datelor, de multe ori ne concentrăm doar la ce am configurat în tabele și nu ne dăm seama de potenţialul datelor aflate în procesare, pe care ajungem să nu îl stocăm. Unele date care rezultă din calcule, sunt disponibile la execuție pentru a se lua decizii în cod, dar în cele mai multe cazuri nu mai sunt disponibile pentru analiză pentru că nu sunt stocate. Combinând datele persistente cu celelalte date calculate vom obţine un event-based stream, vom trimite această structură către un backend pentru stocare. Ceea ce, indirect, va duce la obţinerea de BigData adică date cu viteză, variate, și în volum mare. Subit ne dăm seama că avem nevoie de un backend capabil să stocheze volume mari de date, un stream mare de date, și alte forme nestructurate pentru a obţine rezultate de BI din rapoarte.
Am menţionat anterior că propuneam Google BigQuery pentru backend, deoarece este un serviciu gestionat și nu trebuie să luăm în calcul strategia pentru echipament. Echipamentele au o implicaţie serioasă asupra bugetului dacă trebuie noi să rulăm, să cumpărăm propriul hardware pentru a stoca terabytes de date. Gestionarea unei soluţii găzduite de noi, precum clusterul ElasticSearch/MongoDB, presupune efort de la programatori și administratori de sistem pentru mentenanţa lor. Din experienţă știm că nodurile de pe clusterul EL/MongoDb au capacitate finită în scalare.
Când datele sunt stocate de subsisteme multiple avem nevoie de un colector unificator de date. FluentD sau Kafka Stream Processing sunt componente open source ce trimit datele primite spre destinaţii variate, ambele având multe integrări de librării. Vom folosi FluentD pe post de Middleware. Acesta este ușor de instalat, are un fișier de configurare simplu și este ușor de folosit. Trebuie doar să trimitem datele la input definit prin TCP endpoint. Routerul de evenimente ia datele și le multiplică către mai multe outputuri. A avea o astfel de componentă în arhitectură voastră vă va permite să colectați datele și în afară, pe platforme precum BigQuery sau spre arhivare în Google Storage sau Amazon S3.
Cu o mică schimbare în aplicaţia noastră pentru a trimite evenimente JSON către FluentD, am legat o componentă ce ne ajută să avem datele în mai multe sisteme, chiar și externe. Această schimbare se face cu un apel CURL către FluentD care conține o structura JSON. Datele vor fi redirecţonate pe baza template-ului de configurare către outputuri diferite.
În Google BigQuery putem insera date în două feluri, fie printr-un job de încărcare (load job) folosind un fișier JSON de până la 5TB sau prin streaming insert. Limita standard a destinaţiei streaming insert este de 100.000 rânduri/secundă. Dacă ne uităm doar la cele două numere de mai sus, ne dăm seama că BigQuery este potrivit și pentru o soluţie scalabilă la nivel de petabyte pentru stocări de date enterprise. Deci, dacă startupul vostru depășește creșterea anticipată a volumului de date, vom avea deja un backend pregătit care să facă fața volumul mare pe termen lung.
FluentD are un plugin BigQuery pe care îl putem folosi, iar datele noastre vor fi transmise căre o tabelă BigQuery. BigQuery are o structură DB familiară: tabele, views, records, nested, JSON. Limbajul de interogare se bazează pe standarul SQL 2011 deci include toate aspectele moderne ale limbajului SQL: window functions, with statements etc...
Aceasta presupune că în cadrul unei companii mici se va găsi programatorul necesar pentru a putea lucra cu BigQuery folosind limbajul SQL, neavând nevoie de efortul de a gestiona o echipă de specialiști BigData.
Includem aici un exemplu din cadrul routerului FluentD pentru a demonstra trei acţiuni pe care le poate face. Primul bloc este despre modulul record_transformer unde folosim Ruby pentru a transforma datele de intrare.
<filter frontend.user.*>
@type record_transformer
enable_ruby
remove_keys host
<record>
bq {"insert_id":"${uid}","host":"${host}",
"created":"${time.to_i}"}
</record>
</filter>În exemplul nostru îndepărtăm `host` din JSON și adăugăm o cheie `bq` în JSON cu o nouă structură. Putem utiliza la maxim simplitatea și flexibilitatea acestui modul pentru a transforma datele noastre. De multe ori dorim ca datele extrase să se muleze pe schema logică a bazei de date externe și nu dorim ca acest lucru să se reflecte și în aplicaţie. S-ar putea să dorim să transformăm anumite elemente datetime, numere, operaţii cu șiruri etc. . Am folosit acest transformator pentru toate evenimentele ce sunt identificate prin *frontend.user.**.
<match frontend.user.*>
@type copy
<store>
@type forest
subtype file
<template>
path /tank/storage/${tag}.*.log
time_slice_format %Y%m%d
time_slice_wait 10m
</template>
</store>
<store>
@type bigquery
method insert
auth_method json_key
json_key /etc/td-agent/keys/key-31da042be48c.json
project project_id
dataset dataset_name
time_field timestamp
time_slice_format %Y%m%d
table user$%{time_slice}
ignore_unknown_values
schema_path /etc/td-agent/schema/user_login.json
</store>
</match>Următoarele două blocuri demonstrează situaţia când aceleași date sunt redirecţionate spre destinaţii multiple. Primul este un proces de logging într-un fișier. Parametrii ne permit să alegem formatul fișierului și perioada de împărţire.
Apoi, aceleași date sunt inserate într-o tabelă BigQuery. Am configurat un service account pe GCP și am configurat cheia pentru a autentifica BigQuery API pentru FluentD.
Cu BigQuery putem crea tabele partiţionate la nivel de zi, ceea ce înseamnă că datele sunt inserate într-o partiţie definită la nivel de zi. Partiţia la nivel de zi este metoda recomandată de a stoca datele în BigQuery, deoarece se poate scrie interogări referitoare doar la ultimele 7 zile, de exemplu, iar acestea sunt mai rapide decât a scana un tabel întreg, ceea ce duce la performanţă ridicată și costuri reduse.
Deoarece FluentD redirecţionează o copie a evenimentului și spre fișier, am mai adăugat un feature platformei. Avem toate datele arhivate la nivel de fișier. Putem spune că este un backup al jurnalului de tranzacţii/evenimente. Stocarea acestor elemente în Cloud este ieftin în zilele noastre când avem mai multe tipuri de stocare pe timp lung. Costurile nu sunt vizate de acest articol, dar costurile pentru 1 TB se ridică undeva la 20 de dolari pe lună.
Beneficiul este că, dacă, mai târziu, introducem un nou tip de sistem sau bază de date în arhitectură avem posibilitatea să redăm datele în ordinea cum s-a întâmplat. Este important să ţinem cont de tehnicile Bigdata și să fim pregătiţi pentru perioada următoare de asemenea. Se vor lansa din ce în ce mai multe tooluri pe piaţă, iar faptul că ne păstrăm datele la nivel granular, ca stream, poate fi foarte util în viitor pentru redarea lor în alt sistem.
Acum că arhitectura este pusă la punct, iar datele se află în BigQuery, un serviciu gestionat și scalabil, să vedem cum aduce acest lucru valoare afacerii.
Pe un sistem legacy, unde avem doar o bază de date și servicii web pentru a analiza datele analitice, abilitatea de a rula raporte în timp real poate fi o problemă, deoarece avem un sistem care poate nu face față la interogări complexe.
În alte ordine de idei, avem joburi cron, care vor avea nevoie de câteva minute pentru a porni, putem avea procesare de date batch care pot dura câteva ore și care sunt de multe ori executate noaptea când serverele nu au load mare din timpul zilei. Datele pe care le analizăm pot fi obținute cu întârziere în câteva zile, și am putea reacţiona târziu sau lua decizia greșită.
În lumea BigData dorim să procesăm totul în timp real. De multe ori, experţii definesc timpul real aproximativ (near realtime) deoarece există o întârziere de câteva secunde. De ce este acest lucru important?
Dacă avem rapoarte care analizează date în timp real sau streamed putem detecta oportunităţile și Business Insights imediat, comparat cu un sistem legacy unde avem doar date agregate și avem nevoie de ore sau zile până când se finalizează raportul.
Studiu de caz 1: Un flow de înregistrare a unui utilizator pe un site web cu pași multipli. Imaginaţi-vă 10 pași, iar pentru fiecare pas un eveniment definit care ajunge în baza de date BigQuery, pe măsură ce utilizatorul își completează profilul. Cu un tipar append-only nu există actualizări(UPDATE) la nivel de rând, acestea fiind rânduri noi în tabela BigQuery(INSERT). Deci, pentru un utilizator vom avea linii de intrare multiple, iar fiecare linie va conţine un marcaj de timp și noi coloane completate pentru fiecare pas. Semnificaţia datelor poate fi surprinsă într-un raport pentru a arăta de ce pasul 3 durează mai mult decât ceilalţi pași și ce s-ar putea îmbunătăţi. Acest lucru se poate face cu o integrare AVG() SQL. Vom afla că pasul 3 se referă la alegerea ţării și deducem că durează mai mult, deoarece utilizatorul trebuie să caute într-o listă lungă, ceea ce durează câteva secunde bune. Putem îmbunătăţi pagina și să recomandăm metode de actualizare a pasului pentru a preselecta ţara pe baza adresei IP, sau pentru a avea listate primele 5 cele mai utilizate ţări. Dacă utilizatorii vor putea alege rapid din opţiuni, aceștia vor finaliza pasul mai repede.
Pe un sistem tradiţional nu ne putem permite să păstrăm toate evenimentele, deci nu vom putea obţine un raport ca cel de mai sus, și nu vom putea identifica pași intermediari în procesul de înregistrare .
Studiu de caz 2: Urmărirea obiceiurilor utilizatorilor de a deschide emailuri și a da click pe linkuri. Putem înregistra fiecare acţiune de deschidere de email sau click și putem obţine o colecție de date despre obiceiurilor utilizatorilor, fructificând putem să le trimitem mesajul potrivit la momentul potrivit. Putem face aceasta folosind SQL analytics pe datele colectate în baza de date BigQuery, observând că Alice își deschide emailurile la ora 9AM și cumpără ceva la ora 11AM. Cu această informaţie, putem programa să primească un email cu 5 minute înainte de 9AM, email care ar fi primul din Inbox. Dacă nu cumpără, îi putem reaminti de ofertă la ora 11AM, deoarece până atunci probabil a luat deja o decizie.
Cele două studii de caz se pot realiza din datele colectate, prelucrate cu SQL analytics, date pe care le-am stocat cât mai granular cu putinţă și nu agregate.
Deoarece datele sunt stocate când evenimentul se întâmplă în timp real, analiștii pot rula interogări pe BigQuery chiar și fără ajutor din partea programatorilor, utilizând tooluri GUI ce se integrează cu BigQuery, precum Tableau, Talend. Cum BigQuery se integrează și el cu Google Docs, experienţa similară cu un format Excel este utilă pentru companiile mici. Pentru cei ce cunosc limbajul SQL, ei pot scrie interogările în BigQuery și obţine rezultate rulând imediat, deci nu trebuie să le ceară programatorilor să implementeze rapoarte. Un alt avantaj este că BigQuery este gestionat de Google și rulează pe infrastructura Google, resursele vor fi mereu acolo, acesta fiind un tool ce poate trata petabytes de date și răspunde rapid.
Este important ca o companie mică să aibă acces la tooluri moderne BigData fără a avea o echipă specială pentru acest aspect. Cu o schimbare mică în proiectul curent, precum trimiterea de evenimente (data events) și utilizarea unui Middleware precum FluentD pentru a direcționa datele către backenduri multiple, și având un backend precum BigQuery pentru procesare OLAP, se pot obține rapoarte în timp real. BigQuery este o bază de date complementară care nu înlocuiește cele tradiționale. Adevăratele beneficii fiind gestionată de Google, ţin de lipsa instalărilor, lipsa mentenanței, lipsa nevoii de a avea un plan de execuție la scară largă, disponibilitate permanentă a resurselor. Ce e și mai important - datele nu mai trebuie aruncate, expirate, agregate, astfel încât concentrarea este pe stocarea datelor granulate din care se pot face rapoarte corecte.
de Bálint Ákos
de Andrei Oneț
de Raul Boldea
de Ioana Varga
