DataLakes și DataWarehouses: Cum sunt utilizate în SEO
Publicat: 2021-02-16Deși conceptele DataWarehouses și DataLakes au devenit parte din limbajul de zi cu zi al analiștilor de date și al cercetătorilor de date cu mult timp în urmă, am auzit despre ele doar în alte industrii în ultimii câțiva ani.
De exemplu, analiștii web și experții SEO încep să arunce o privire serioasă asupra acestor concepte, datorită naturii joburilor lor și a conexiunii puternice care există între ceea ce fac și manipularea datelor. Multe articole recente vorbesc despre interesul implementării unui SEO DataLake sau a unui SEO DataWarehouse, tratând cei doi termeni ca fiind interschimbabili și fără a face distincție între cei doi.
În acest articol, vă vom ghida în determinarea diferențelor dintre DataLakes și DataWarehouses pentru a înțelege scopurile și cazurile lor de utilizare în SEO și analiză web.
DataWarehouse: depozit structurat pentru date
Prima utilizare a termenului „DataWarehouse” datează din 1988 într-o lucrare de Paul Murphy și Barry Delvin, An architecture for a business and information systems . Acest articol ne oferă o primă definiție a conceptului ca mediu de baze de date relaționale ușor de accesat, reunind toate datele de afaceri utile pentru luarea deciziilor strategice.
Ce conține un DataWarehouse?
DataWarehouse este folosit pentru a colecta într-un singur loc datele de afaceri utile pentru luarea deciziilor strategice pentru companie. Vorbim despre date de afaceri care pot acoperi orice, de la date despre clienți, la informații despre inventar, la conversii pe un site comercial sau vizite organice (de la un motor de căutare precum Google de exemplu).
Este de obicei acceptat că datele trimise către un DataWarehouse sunt date structurate, preprocesate, utilizate pentru descărcarea bazelor de date operaționale, ceea ce permite în cele din urmă ca aceste baze de date operaționale să fie solicitate cât mai puțin posibil în scopuri de interogare.
Scopul principal al unui DataWarehouse și al celor care îl administrează este acela de a compila date din surse diverse, eterogene (atât interne, cât și externe), pentru a le standardiza astfel încât diversele surse să poată comunica între ele. Scopul final este de a utiliza aceste date pentru a efectua analize, raportare, sprijin pentru luarea deciziilor etc.
Cine sunt utilizatorii zilnici ai unui DataWarehouse?
Datorită naturii DataWarehouse și formatului și tipului de date pe care le conține, este un loc de joacă ideal pentru analiștii de date și web.
Analiștii de date lucrează alături de administratorul DataWarehouse (sau echipa de administrare). Ele definesc nevoile de afaceri și cazurile de utilizare. Ele identifică sursele de date și acțiunile necesare pentru a procesa datele în amonte. Aceste date vor fi apoi utilizate de către analiștii de date la sfârșitul lanțului.
Cum comunică utilizatorii cu un DataWarehouse?
Odată ce sursele de date au fost identificate și datele procesate, ingerate și legate în DataWarehouse, analistul de date poate folosi aceste date în analize și pentru a crea noi combinații de date. Acest proces poate fi utilizat pentru a menține tablouri de bord de raportare, tablouri de bord de alertă etc.
Cel mai des folosit limbaj de programare pentru interogări într-un DataWarehouse este SQL (sau limbaje asemănătoare SQL). SQL permite analiștilor de date să manipuleze și să prelucreze datele pentru a răspunde nevoilor afacerii: monitorizare, luare a deciziilor strategice etc.
Ce cazuri de utilizare și tipuri de proiecte servesc DataWarehouses?
Este imposibil să se întocmească o listă exhaustivă a cazurilor de utilizare care implică utilizarea unui DataWarehouse. Cu toate acestea, iată câteva exemple de proiecte la care este probabil să lucreze un analist de date:
Îmbunătățirea unui DataWarehouse:
Acest tip de proiect este adesea întâlnit la înființarea unui DataWarehouse, dar și atunci când se identifică o nouă nevoie sau un caz de utilizare în afaceri.
Este vorba aici de a adăuga date noi la un DWH (din nou, acestea pot fi date interne sau externe).
În acest caz vorbim adesea de un proces ETL (Extraction-Transformation-Loading):
- Extracţie:
Un prim pas constând în identificarea și colectarea datelor din diversele surse necesare operațiunilor ulterioare. - Transformare:
Acest al doilea pas este foarte important, deoarece fără ajustare, fără standardizare, este în general imposibil să se utilizeze date noi și să le facă să comunice cu cele deja existente în DWH.
Este deci o fază de standardizare necesară care poate fi uneori complicată de rigiditatea impusă de DWH în ceea ce privește formatarea și schema tabelului. - Se încarcă:
Faza de ingerare a datelor prelucrate (și astfel structurate) în DWH.
Realizarea de analize statistice:
Aceasta este o utilizare foarte frecventă a DWH-urilor. Scopul poate fi acela de a demonstra X sau Y prin intermediul datelor, de a produce statistici pe baza datelor istorice disponibile sau de a stabili legături cauzale pentru a explica o constatare etc.
Raportare și alerte:
Acesta este, din nou, un caz de utilizare foarte frecvent. De fapt, deoarece datele dintr-un DWH sunt foarte structurate și formatate (partajând o schemă fixă și predefinită), toate sunt potrivite pentru împingerea datelor către tablourile de bord de raportare sau alertă.
Aceasta este o solicitare recurentă din partea managementului de vârf, care trebuie să poată monitoriza echipele operaționale și starea de sănătate a rezultatelor, vânzărilor etc. în cel mai simplu și rapid mod posibil.
Dacă le rezumăm pe toate, avem mai mult sau mai puțin 2 tipuri de proiecte: proiecte de achiziție și integrare a datelor (care pot fi comparate și cu o formă de stocare și istoricizare a datelor) și proiecte de analiză și evaluare a datelor (prin monitorizare/dashboarding și alertă). ).
Conceptul de DWH este prezent de mult timp în limbajul de zi cu zi al celor care lucrează cu date. Modul în care funcționează și numeroasele sale cazuri de utilizare au fost de mult confirmate, iar DWH-urile pot fi găsite în multe companii de maturitate diferită în ceea ce privește problemele legate de managementul datelor.
Acesta este mai puțin cazul conceptului de DataLakes, care este mult mai tânăr și mult mai puțin răspândit.
Date oncrawl³
DataLake: lacul megadatelor (BigData)
Originea acestui concept este atribuită lui James Dixon, CTO al Penthao, care îl definește ca o soluție pentru stocarea și exploatarea unor volume mari de date, fără preprocesare și fără neapărat un caz de utilizare specific... Spre deosebire de DWH-urile, care sunt foarte orientate spre activarea imediată.
DL încearcă să umple golul, care este din ce în ce mai important odată cu apariția BigData, despre ce să facem cu toată această masă de date pe care suntem capabili să colectăm astăzi și cum să profităm de ea.
Ce conține un DataLake?
Voi începe prin a-l cita pe James Dixon care folosește o comparație foarte evocatoare, servind atât ca explicație pentru numele de „lac” al conceptului său, cât și ca diferențiere cu DWH:
„Dacă te gândești la un datamart ca la un depozit de apă îmbuteliată – curățată, ambalată și structurată pentru un consum ușor – lacul de date este un corp mare de apă într-o stare mai naturală. Conținutul lacului de date provine dintr-o sursă pentru a umple lacul, iar diverși utilizatori ai lacului pot veni să examineze, să se scufunde sau să ia mostre.”
Acest citat ilustrează perfect diferența dintre tipul de date conținut într-un DWH, care este structurat și organizat în tabele cu modele precise, fixe, și tipul de date conținut într-un DataLake, care este brut, fără procesare prealabilă, disponibil pentru a lua mostre de la nevoie, fie că sunt exploratorii sau nu.
Acolo unde un DWH este limitat pentru a găzdui date structurate, DataLake este conceput pentru a stoca tot felul de date brute (structurate sau nu). O dezbatere între Tamara Dull (Amazon Web Service) și Anne Buff (Microsoft SAS) ne oferă o viziune ceva mai concretă asupra conținutului unui DataLake:
„Un lac de date este un depozit de stocare care deține o cantitate mare de date brute în formatul său nativ, inclusiv date structurate, semi-structurate și nestructurate. Structura și cerințele datelor nu sunt definite până când datele nu sunt necesare.”
Cine sunt utilizatorii zilnici ai DataLakes?
Acolo unde un analist de date era perfect potrivit pentru a lucra cu datele structurate conținute într-un ACM, datele brute sunt în schimb specialitatea cercetătorilor de date, care sunt adesea mai bine echipați pentru a manipula acest tip de date.
Această modificare a profilului de date și a utilizatorului principal are ca rezultat, de asemenea, diferite limbaje de programare și cazuri de utilizare.
Ce cazuri de utilizare și tipuri de proiecte servesc DataLakes?
Datorită naturii sale nestructurate și volumului considerabil de date pe care le poate conține un DataLake, cazurile de utilizare pot fi foarte diferite de cele găsite anterior în cadrul DWH, de exemplu:
- Implementarea algoritmilor de învățare automată pentru a crea valoare adăugată pentru BigData:
Deseori vorbim aici despre analiza predictivă, bazată pe algoritmi de învățare automată care exploatează tot felul de date.
Pentru a lua un exemplu mai concret, să ne imaginăm că o companie din sectorul financiar (bancar și asigurări) dorește să determine probabilitatea ca o tranzacție financiară X să fie frauduloasă. Acest lucru poate face apel la Data Scientists, capabili să creeze algoritmi de învățare automată care se vor antrena cu privire la cantitatea astronomică de date conținute în DataLake (cantitate, dată, frecvență, profilul obișnuit al tranzacțiilor efectuate de proprietarul contului etc.). Scopul este realizarea unui studiu predictiv care va fi folosit pentru identificarea tranzacțiilor potențial frauduloase și astfel să permită companiei să-și reducă timpul de reacție în detectarea acestora și, în final, să evite pierderi mari pentru ei și clienții lor.
Acesta este un exemplu simplu care este folosit în mod regulat pentru a ilustra interesul și valoarea adăugată a învățării automate, dar există tot atâtea altele, așa cum vă puteți imagina. - DataLakes ca sursă de date pentru un DataWarehouse:
Foarte simplu, un DataLake poate acționa ca o zonă de tranzit între diferitele surse de date interne și externe și DWH. Însuși principiul unui DataLake este acela de a centraliza tot felul de date, structurate sau nestructurate, pentru a realiza studii predictive prin ML, sau pentru extragerea ca mostre pentru analiză. DWH pare așadar foarte potrivit pentru această a doua categorie de proiecte și beneficiază de un DataLake ca sursă potențială (cu condiția ca datele DataLake să fie importate într-un mod structurat prin preprocesare, dacă este necesar). - De la DataLake la software-ul BI (Business Intelligence):
Putem vedea aceasta ca o utilizare similară cu cea pe care am văzut-o cu DataWarehouses, crezând că există anumite specificități în utilizarea unui DataLake în acest scop. Un DataLake vă va permite să faceți vizualizări puțin mai exotice (datorită varietății de date pe care le conține), prin instrumente precum Tableau, Qlikview, Google Data Studio, Microstrategy etc.
Cum comunică utilizatorii cu un DataLake?
Având în vedere cazurile de utilizare și utilizatorii (Data Scientists), vom găsi foarte des limbaje de programare precum Python, Java, R, Scala etc...
În cea mai mare parte, aceste limbi au fost prezente în domeniul științei datelor de mult timp.
Un DataLake este, prin urmare, un instrument pentru gestionarea BigData. Se bazează pe stocarea masivă a datelor brute în scopuri avansate de analiză și vizualizare, permițând astfel îmbunătățirea datelor care anterior nu au fost folosite prea mult.
Pentru a rezuma, iată un tabel al elementelor de diferențiere stabilite încă de la începutul acestui articol:
DataWarehouse | DataLake | |
---|---|---|
Tipul de date | Date structurate, preprocesate, organizate în tabele cu scheme definite | Date brute, stocate într-o manieră structurată sau nestructurată |
Utilizatori | Analiști de date, analiști web | Oamenii de știință ai datelor (uneori analiști de date) |
Volumul datelor | Mic mare (În funcție de nevoie și de caz de utilizare) | Potenţial foarte mare (Date mare) |
Limbajul de programare folosit | SQL sau asemănător SQL | Python, R, Java, Scala, printre altele |
Tip de proiect | Proiecte analitice și statistice, rapoarte, alerte, proiecte de tip ELT (export, transformare, încărcare), unele analize predictive și bazate pe date | Analiză predictivă, învățare automată, zonă de tranzit între sursele de date și DWH, vizualizare avansată – BI, analiză bazată pe date |
Analiză predictivă, învățare automată, zonă de tranzit între sursele de date și DWH, vizualizare avansată – BI, analiză bazată pe date
Aceste diferențe fac din aceste două concepte instrumente complementare. În multe cazuri, în funcție de maturitatea guvernanței unei companii și a gestionării datelor, acestea se pot baza pe o combinație a acestor două instrumente.
Un DWH este utilizat în principal pentru raportarea și analiza tradițională, în timp ce un DataLake servește ca sursă de date înainte de a-și atinge potențialul maxim pe măsură ce compania se apropie de maturitatea subiectelor datelor.
După părerea mea, DataLake-urile sunt mai degrabă un răspuns la noile probleme de date ale secolului 21, în special odată cu apariția BigData și capacitatea tot mai mare a companiilor de a colecta date, decât un înlocuitor pentru DWH, așa cum ar putea crede unii.
Ambele au avantajele, dezavantajele, punctele forte și punctele lor slabe. Cea mai bună modalitate de a profita la maximum de ambele este încă să le folosiți pe ambele împreună pentru a putea face față oricărei eventualități și pentru a aborda o varietate mai largă de nevoi.
Acum că am definit clar conceptele, ne vom concentra în sfârșit pe utilizarea DataWarehouses și DataLakes pentru marketing și mai precis pentru SEO (chiar dacă în multe cazuri, ceea ce este adevărat pentru primul va fi adevărat pentru al doilea, iar vice invers).
DataWarehouse și DataLake SEO
Vom vorbi aici despre un DataWarehouse sau un DataLake (sau ambele) unde cel puțin o parte din datele prezente pot fi folosite pentru cazuri de utilizare SEO.
De ce să asociați DataLakes și DataWarehouses cu marketing și SEO?
SEO (și, mai general, marketing) a luat deja o întorsătură foarte marcată către date în ultimii ani. Din ce în ce mai multe sarcini necesită utilizarea diferitelor surse de date:
- Date analitice (Google Analytics, AT internet etc.)
- Date de performanță (Google Search Console, Analytics)
- Datele de jurnal, o „sursă” de date foarte mare pentru unele site-uri, care necesită o frecvență mare de actualizare și o capacitate mare de stocare.
- Date de conectare la net (Majestic, Ahrefs, Babbar)
- Date de poziționare (SEMRush, Monitorank etc.)
- Datele accesate cu crawlere (OnCrawl etc.)
- Uneori și date de afaceri/industrie
La această listă ar trebui să adăugăm și utilizarea API-urilor de instrumente precum Search Console, Majestic, Google Analytics de exemplu, care ne împinge în mod firesc către genul de soluții descrise mai devreme în acest articol.
Această conexiune puternică dintre SEO și Date îi împinge pe tot mai mulți analiști web și experți în SEO să învețe despre noi modalități de a-și organiza canalul de date.
Cu toate acestea, motoarele pentru această tranziție nu se referă doar la potențialul și interconectarea SEO și a datelor. Multe cazuri de utilizare zilnică rezonează cu tipurile de proiecte enumerate mai sus pentru DWH și DL.
Cazurile de utilizare ale unui SEO DataWarehouse sau ale unui SEO DataLake.
Voi începe mai întâi de la punctele dureroase întâlnite în mod obișnuit de experții SEO înainte de a explica cum utilizarea unui DataLake sau a unui DataWarehouse este un răspuns care trebuie luat în considerare atunci când le adresez.
Dintre principalele puncte dureroase, se remarcă următoarele:
- Înmulțirea fișierelor Excel (hârtia cu foi libere a deceniului nostru) și copierea și lipirea asociate:
Pentru mulți SEO, aceasta este încă norma, dar să fim sinceri, este atât consumator de timp, constrângător și foarte propice erorii umane. Pentru aceasta, un DataWarehouse este o soluție perfectă. DataWarehouse-urile nu numai că permit ca toți KPI-urile necesare pentru a efectua cutare sau cutare audituri/analize să fie adunate din diferitele surse de date disponibile, dar permit și automatizarea procesării necesare pentru a obține rezultatul așteptat.
Pe măsură ce se construiește un DataWarehouse, sunt identificate tot mai multe cazuri de utilizare și tot mai multe probleme sunt rezolvate, ceea ce duce la economii de timp din ce în ce mai semnificative în timp. - Limite de capacitate (ca reamintire, Excel poate deschide un întreg fișier numai dacă nu depășește 1.048.576 de linii. Acest lucru pare mult, dar nu este chiar atât de mult în volumele de astăzi): Nu există cu adevărat niciun caz de utilizare special aici, deoarece în general, atât DataLakes, cât și DataWarehouses nu suferă de acest tip de limită. Ambele oferă mijloacele de a solicita volume mari de date pentru orice tip de nevoie. Pentru acest caz concret, este important să rețineți că, în funcție de nevoie, una sau alta vă va permite să vă eliberați de limitele de capacitate și, în cele din urmă, să abordați mai ușor aceste situații.
- Răspundeți la nevoia de istoricizare a datelor
Spoiler: unul dintre cazurile de utilizare poate fi, de exemplu, salvarea unui istoric al datelor din Google Search Console într-un depozit de date SEO, mai degrabă decât să copiați și să paginați datele acestuia într-un foi de calcul Google în fiecare săptămână pentru a menține un tablou de bord Data Studio. parerea mea, avem aici unul dintre cele mai frecvente cazuri de utilizare in randul expertilor SEO, fie in agentii, fie in-house: istoricizarea datelor. Într-adevăr, mulți analiști SEO se uită la datele istorice și trag concluzii din acestea.
Exemplul care v-a venit direct în minte este cazul Google Search Console. Oferă acces doar la 16 luni de istorie astăzi (chiar și prin API). Și dacă rămâne posibilă un stoc manual prin exporturi care să fie lipite în Foi de calcul Google în fiecare săptămână (sau alte metode obscure), este o pierdere considerabilă de timp, pe lângă faptul că este dureroasă și plictisitoare.
Acesta este un lucru bun, deoarece este o problemă relativ simplă de rezolvat cu un DataWarehouse. Tot ce trebuie să faceți este să configurați o conexiune automată la API-ul Google Search Console, să definiți diferitele combinații posibile de preprocesare și date necesare pentru a obține date cu valoare adăugată reală și, în final, să automatizați apelurile API. - Dorința de a duce analizele mai departe, de a îmbina sau de a „analiza încrucișat” datele de crawlere, datele de audiență, jurnalele etc., într-un mod industrializat.
Pentru că un mic avantaj competitiv nu strica niciodată. Descrierile pe care le-am dat despre un DataWarehouse și un DataLake vorbesc de la sine aici. Unul dintre scopurile principale ale ambelor instrumente este de a deschide noi posibilități de analiză, prin colectarea datelor și analize încrucișate și/sau învățare automată.
Pentru a cita un singur exemplu foarte reprezentativ; utilizarea algoritmilor de învățare automată, cum ar fi Random Forest sau XG-Boost, pentru a face predicții de clasare pe Google.
Foarte simplu, ideea este de a antrena un algoritm pe un număr mare de SERP-uri Google (pagini de rezultate) și toate valorile SEO recoltabile pentru aceste SERP-uri pentru a determina, pe baza acelorași metrici, potențialul de clasare al unei anumite adrese URL (și prin urmare, chiar mai ales, pentru a determina cele mai importante valori de clasat într-un anumit sector/temă).
→ Metodologia completă o veți găsi în articolul lui Vincent Terrasi, director de produs la Oncrawl, „Successfully predicting Google rankings at the cutting edge of data science” , 2018. - Dorința de a automatiza raportarea cât mai mult posibil, pentru a se concentra pe sarcini cu valoare adăugată mare. Din nou, aceasta se încadrează literalmente în cazurile de utilizare clasice ale unui DataWarehouse. Oferă posibilitatea de a automatiza întreaga recuperare și procesare a diferitelor surse de date și abordează perfect acest punct de durere. Odată configurat, un tabel va fi alimentat automat în DWH și poate fi folosit ca conexiune la software-ul BI pentru tablouri de bord, fie pentru monitorizare, alertă etc. Desigur, automatizarea nu se oprește doar la raportarea proiectelor. Atât un DWH, cât și un DL pot fi folosite pentru multe optimizări automate SEO. De exemplu, actualizări dinamice ale blocurilor de link-uri interne privind clasamentul, bugetul de accesare cu crawlere, audiența SEO etc. (toate datele conținute în DWH).
- Dorința de a pune capăt odată pentru totdeauna preocupărilor de securitate (știm cine a făcut ce și unde să le găsim) și de a evita să petrecem timp cu întreținere. Încheiem aici cu un aspect mai orientat spre proces decât un caz de utilizare, strict vorbind.
Atât DataLakes, cât și DataWarehouses implică implementarea unor procese particulare care pot fi prezentate în următorul mod simplificat:- Punctul de plecare este o observație care se defalcă într-o declarație de nevoi (echipă de afaceri / SEO – Data Analyst).
- Apoi, aceasta este transformată într-o specificație mai tehnică care va permite echipei care administrează instrumentul să înțeleagă ce trebuie făcut și cum trebuie făcut.
- Aceeași echipă de administrație realizează cererea.
- Echipa de afaceri și analiștii de date produc un caz de utilizare procedural pentru munca efectuată.
- Există un proces în desfășurare în care cele două capete ale lanțului (echipa de afaceri și echipa de administrare a DataWarehouse sau DataLake) se asigură că nimic nu se schimbă în ceea ce privește intrarea și ieșirea.
Acesta este în special cazul unui DWH, care va respinge orice date care nu fac parte din structură (schema predefinită).
Din nou, aceasta este o listă neexhaustivă de puncte dureroase și posibile cazuri de utilizare pentru DataWarehouse – DataLake SEO. Limitele se întâlnesc mai mult prin lipsa de imaginație a celor care le folosesc decât în instrumentele în sine.
Alegerea unui DataWarehouse sau DataLake pentru utilizările dvs. SEO
În concluzie, spre deosebire de ceea ce auziți sau citiți adesea, DataWarehouses și DataLakes sunt structuri separate pentru stocarea și colectarea datelor și nu sunt incompatibile. Nu este nevoie să alegi unul în detrimentul celuilalt, dimpotrivă. Ambele au cazuri de utilizare diferite și există chiar și unele aderențe.
Cazul SEO este un exemplu grăitor și întărește nevoia de DataWarehouses și DataLakes în general. Datele sunt omniprezente în SEO: trebuie să manipulăm cantități uriașe de date din diferite surse. Deci nu este de mirare că vorbim despre DataWarehouses și DataLakes în acest context. Ne putem imagina o mulțime de cazuri de utilizare ale DataWarehouses sau DataLakes în SEO, fie că este vorba în scopuri de automatizare, pentru a efectua analize „augmentate” prin intermediul datelor sau pur și simplu pentru a rezolva probleme recurente (puncte dure).