În acest articol vom supune analizei modul cum putem grupa rapoartele și dashboardurile în categorii diferite, în funcţie de viteza cu care putem aduce și actualiza datele din cadrul acestora.Timpul este un termen relativ mai ales atunci când are impact direct asupra businessului pe care îl avem. Din această cauză capacităţile de raportare ale sistemelor interne pot să aibă un impact direct asupra succesului nostru ca business.
Sunt mai multe elemente care sunt importante când vorbim despre rapoarte și timp de răspuns scurt, dar două din ele sunt relevante în această discuție.
Primul aspect este granularitatea timpului. La început, majoritatea decidenţilor unei afaceri doresc ca granularitatea să fie cât mai mică posibil, până când realizează că nu pot obţine ceva relevant la acest nivel. De multe ori ca să ajungi la o înţelegere profundă a ceea ce se întâmplă, ai nevoie și de un overview la un nivel mai ridicat care se traduce printr-o granularitate mai mare.Majoritatea sistemelor disponibile azi pe piaţă, ne permit să schimbăm granularitatea internă pe loc, făcând posibilă explorarea datelor noastre din diferite perspective temporale. Efectul este pozitiv pentru că generează flexibilitate și dinamicitate.
Al doilea aspect este intervalul de timp măsurat din momentul în care datele ajung în sistemul nostru de stocare până în momentul în care pot fi afișate în cadrul unui raport specific. Nu afirm că ar fi imposibil să avem toate datele disponibile în cadrul unui raport la momentul 0, dar acest scenariu poate fi unul foarte costisitor și s-ar putea să nu avem nevoie de date într-un timp atât de scurt.Din proprie experienţă, vă confirm că am întâlnit clienți care spun că datele trebuie afișate într-un raport imediat ce sunt disponibile în sistem. După două sau trei întâlniri, aceștia realizează că rapoartele se generează pentru săptămâna precedentă, neexistând valoare adăugată dacă datele din raport sunt gata imediat sau după o zi.
Evident, acest fapt are consecinţe directe asupra costului și asupra modului de implementare a soluţiei. Termenii "imediat" sau "în timp real" sunt relativi. Fiecare stakeholder înţelege termenii diferit chiar și atunci când face parte din aceeași echipă. Din acest motiv, este important să clarificăm acești termeni de la bun început.
Luând aceste aspecte în considerare, am început să grupez rapoartele și dashboardurile în patru categorii principale din punct de vedere al timpului:
Aceste categorii sunt definite pe baza intervalului de timp dintre momentul în care datele ajung în sistem și până în momentul în care pot fi afișate pe o interfață grafică sau sunt disponibile pentru a fi consumate.
Este important de știut că un grafic poate aparţine mai multor categorii (ex. Near-real time și Reporting). Chiar și așa, va exista un grafic pentru fiecare categorie. Soluţiile pe care ar trebui să le folosim, ar putea să difere de la o categorie la alta.
În general, în această categorie intră datele ce trebuie să fie afișate într-un raport sau dashboard cu întârziere de maxim 2-3 secunde. Acestea sunt diferite view-uri ale sistemului curent folosite în special de echipele de mentenanţă și suport pentru a obţine date despre sistem în timp real.În mod frecvent, când aveţi un astfel de sistem, veţi dori să vizualizați și modificați datele de intrare în diferite feluri. Orice proces ETL crește latenţa dintre momentul primirii datelor și momentul afișării acestora. Momentan, se observă o tendinţă a companiilor de a solicita astfel de dashboarduri, dar realitatea este că nu prea multe dintre ele au nevoie de un astfel de sistem. De exemplu, dacă nu aveţi o echipă ce monitorizează sistemul 24/7, s-ar putea va valoarea adăugată să aveți un sistem de monitorizare în timp real să nu fie atât de mare.
Mai mult, nu toate datele produse de sistem trebuie să fie parte componentă a unui sistem de raportare în real time. Un exemplu bun este monitorizarea unui grup de servere pentru că doriţi să știţi care este starea acestora și care sunt aplicaţiile care rulează în cadrul lor. Nu veţi obţine în plus nicio valoare dacă veţi putea vedea în timp real că numărul proceselor ce rulează pe servere se modifică la fiecare două secunde. O excepţie ar fi atunci când faceţi debugging, dar pentru acest lucru există Performance Counters și alte metode de a colecta și vizualiza metrici de acest gen.
Graficele real time se folosesc cu precădere în liniile de producţie din cadrul unei fabrici. În majoritatea cazurilor, chiar dacă specificaţiile iniţiale au la bază real time, odată business requirments, observăm că de fapt este vorba de un grafic near-real time, cu o latență ușor mai mare.
Acesta este un tip de grafic unde datele sunt actualizate la interval de câteva secunde. Latenţa de afișare a datelor din momentul când datele ajung în sistem și până în momentul când datele sunt afișate este de mai puţin de 30-60 secunde. Majoritatea sistemelor de timp real time sunt de fapt near-real time, neexistând un impact puternic asupra afacerii, dacă datele sunt afișate cu o latenţă de 30-60 secunde.Din perspectiva latenţei, aș afirma că până și o latenţă mai mare (2-5 minute) este tot near-real time. Pentru un astfel de sistem, cel mai important element nu este intervalul de timp actualizat, ci abilitatea de a explora datele și de a obţine perspective diferite pentru același set de date. În acest mod, echipa de suport va putea identifica problemele înainte ca acestea să apară.Majoritatea instrumentelor de raportare și monitorizare disponibile azi fac parte din această categorie. Din perspectiva costurilor, diferenţa dintre sistemele real-time și near-real time se poate ridica la valori de 3 sau 5 ori mai mari.Un instrument destul de nou, dar foarte puternic, ce poate fi folosit pentru orice tip de raportare near-real time este Azure Time Series Insights care ne permite să schimbăm perspectiva și granularitatea datelor în timp real, fără să fim nevoiți să așteptăm reprocesarea lor.
Aceasta este categoria de grafice și rapoarte pe care obișnuiesc să o numesc "clasică". Aceste view-uri asupra datelor pot fi generate la fiecare oră, zilnic sau la interval de câteva zile. Sunt rapoartele clasice cu care suntem obișnuiți de zeci de ani.Noile versiuni de sisteme disponibile pentru această categorie oferă posibilitatea creării de rapoarte dinamice unde utilizatorul poate explora datele în funcţie de nevoi.
De multe ori, această categorie se suprapune categoriei precedente, datorită faptului că instrumentele folosite pentru crearea rapoartelor și view-urilor de consolidation sunt aceleași ca cele pentru reporting. Există doar un număr limitat de cazuri unde, datorită volumului și complexităţii datelor, Hadoop sau alte instrumente similare sunt utilizate pentru pre-procesarea datelor înainte de a le expune sistemelor de raportare.Graficele care sunt parte din consolidation se generează mult mai rar (o dată pe săptămână, pe lună sau pe trimestru), fiind utilizate pentru o privire de ansamblu asupra afacerii și pentru consultarea progresului.
Categoriile reporting și consolidation se utilizează în general împreună cu succes în cadrul aceluiași intrument de analiză, permiţând utilizatorilor să aibă o privire de ansamblu și să exploreze datele.În unele cazuri, categoriile _near-real tim_e și reporting pot fi combinate, dar nu recomand acest lucru. Cea mai mare problemă o reprezintă perspectivele diferite ce pot exista. Dacă pentru near-real time, majoritatea graficelor se axează asupra perspectivei timpului, pentru raportare, graficele nu trebuie să se axeze obligatoriu pe timp.Categoriile real time și near-real time permit perspective asemănătoare, acestea mergând mână în mână.
În funcţie de timpul de actualizare și de cât de repede putem procesa datele noi, putem genera o perspectivă diferită a aceluiași grafic. Deși este la modă să afișăm date în real/near-real time, întrebaţi-vă dacă este absolut necesar și care sunt compromisurile și costurile. Nu este nevoie să se ofere astfel de soluţii dacă nu există o nevoie explicită sau dacă nu aduce plus valoare.
Mai mult, nu este același lucru să stochezi date în real time, dacă acestea sunt trimise cu o frecvenţă de 10 milisecunde vs. 5 minute. Costurile de procesare și stocare sunt diferite. Instrumentele și mecanismele folosite vor fi de asemenea diferite.Da! O soluţie poate obţine date semnificative ( insight) din toate cele patru categorii. Da, puteţi găsi o metodă de a le depozita în aceleași sisteme de stocare. Da, va trebui să puteţi crea puncte statice de date pentru categoriile reporting și consolidation. S-ar putea să nu doriţi să procesaţi 100GB de date acolo unde frecvenţa datelor este de 10 milisecunde pentru a genera un raport pentru ultimele trei luni, cu o perspectivă a datelor de o zi.
de Ovidiu Mățan
de Bogdan Bucur
de Bogdan-Constantin Pîrvu , Constantin-Bălă Zamfirescu , Samuel Pușcașu , Vlad Ruxandu
