Editorul Netology a discutat cu liderul echipei de BI în Pavel Sayapin despre ce probleme rezolvă inginerii de date din echipa sa, ce fel de instrumente folosesc pentru aceasta și cum să aleagă instrumentele potrivite pentru rezolvarea problemelor de date, inclusiv a celor atipice. Pavel este profesor la curs "".
Ce fac inginerii de date la Profi.ru
Profi.ru este un serviciu care ajută la întâlnirea clienților și specialiștilor din diverse domenii. Baza de date de servicii include peste 900 de mii de specialiști în 700 de tipuri de servicii: tutori, reparatori, traineri, experți în frumusețe, artiști și alții. Peste 10 mii de comenzi noi sunt înregistrate zilnic - toate acestea dau aproximativ 100 de milioane de evenimente pe zi. Este imposibil să menținem ordinea într-o asemenea cantitate de date fără ingineri de date profesioniști.
În mod ideal, un inginer de date dezvoltă o cultură a datelor prin care o companie poate genera profituri suplimentare sau poate reduce costurile. Aduce valoare afacerii lucrând în echipă și acționând ca o legătură importantă între diferiți participanți - de la dezvoltatori până la consumatori de raportare. Dar sarcinile pot diferi în fiecare companie, așa că să le privim folosind Profi.ru ca exemplu.
Colectați date pentru luarea deciziilor și furnizați-le utilizatorului final - manager de top, manager de produs, analist
Datele trebuie să fie clare pentru luarea deciziilor și ușor de utilizat. Nu este nevoie să vă străduiți să găsiți o descriere sau să scrieți o interogare SQL complexă care ia în considerare mulți factori diferiți. O imagine ideală - utilizatorul se uită la tabloul de bord și este mulțumit de tot. Și dacă nu există suficiente date într-o secțiune, atunci aceasta merge la baza de date și, folosind o interogare SQL simplă, obține ceea ce are nevoie.
Locul procesului de calitate a datelor în structura de ansamblu a depozitului de date
Este importantă documentația explicativă privind lucrul cu date. Acest lucru simplifică munca atât a inginerului de date (nu sunt distras de întrebări), cât și a utilizatorului de date (el poate găsi singur răspunsuri la întrebările sale). La Profi.ru, astfel de documente sunt colectate pe forumul intern.
Comoditatea înseamnă și viteza de achiziție a datelor. Viteză = accesibilitate într-un singur pas, clic - tablou de bord. Dar în practică totul este mai complicat.
Același Tableau, din punctul de vedere al utilizatorului final al tabloului de bord, nu permite afișarea tuturor măsurătorilor posibile. Utilizatorul se mulțumește cu filtrele realizate de dezvoltatorul tabloului de bord. Acest lucru dă naștere la două scenarii:
- Dezvoltatorul face multe tăieturi pentru tabloul de bord ⟶ numărul de pagini crește foarte mult. Acest lucru reduce disponibilitatea datelor: devine dificil de înțeles unde este totul.
- Dezvoltatorul creează numai secțiuni cheie. Este mai ușor să găsești informații, dar pentru o secțiune ceva mai puțin standard trebuie să mergi fie la baza de date, fie la analiști. Ceea ce are și un efect negativ asupra accesibilității.
Accesibilitatea este un concept larg. Aceasta include disponibilitatea datelor în forma adecvată și capacitatea de a obține informații pe tablouri de bord, precum și secțiunea transversală necesară a datelor.
Acumulați date din toate sursele într-un singur loc
Sursele de date pot fi interne sau externe. De exemplu, afacerea cuiva depinde de rapoartele meteorologice care trebuie colectate și stocate - din surse externe.
Informațiile trebuie stocate cu sursa indicată și, de asemenea, astfel încât datele să poată fi găsite cu ușurință. În Profi.ru această problemă este rezolvată folosind documentație automată. Fișierele YML sunt folosite ca documentație despre sursele interne de date.
Ei fac tablouri de bord
Vizualizarea datelor se realizează cel mai bine într-un instrument profesional - de exemplu, Tableau.
Majoritatea oamenilor iau decizii din punct de vedere emoțional; claritatea și estetica sunt importante. Excel, de altfel, nu este foarte potrivit pentru vizualizare: nu acoperă toate nevoile utilizatorilor de date. De exemplu, unui manager de produs îi place să se îngroape în numere, dar într-un mod care să facă acest lucru convenabil. Acest lucru îi permite să-și rezolve problemele, mai degrabă decât să se gândească la cum să obțină informații și să colecteze valori.
Vizualizarea datelor de înaltă calitate facilitează și mai rapid luarea deciziilor.
Cu cât poziția unei persoane este mai mare, cu atât este mai mare nevoia de a avea date agregate la îndemână, la telefon. Managerii de top nu au nevoie de detalii - este important să controlăm situația în ansamblu, iar BI este un instrument bun pentru asta.
Exemplu de tablou de bord al produsului Profi.ru (una dintre foi). Pentru confidențialitatea informațiilor, numele valorilor și axelor sunt ascunse
Exemple de probleme reale
Sarcina 1 - Turnați datele din sistemele sursă (de operare) într-un depozit de date sau ETL
Una dintre sarcinile de rutină ale unui inginer de date.
Pentru aceasta se pot folosi următoarele:
- scripturi auto-scrise lansate prin cron sau folosind un orchestrator special, cum ar fi Airflow sau Prefect;
- Soluții ETL open source: Pentaho Data Integration, Talend Data Studio și altele;
- soluții proprietare: Informatica PowerCenter, SSIS și altele;
- soluții cloud: Matillion, Panoply și altele.
Într-o implementare simplă, problema se rezolvă prin scrierea unui fișier YML cu 20 de linii, durează aproximativ 5 minute.
În cel mai complex caz, atunci când trebuie să adăugați o nouă sursă - de exemplu, o nouă bază de date - poate dura până la câteva zile.
În Profi, această sarcină simplă - cu un proces simplificat - constă din următorii pași:
- Aflați de la client ce date sunt necesare și unde se află.
- Înțelegeți dacă există acces la aceste date.
- Dacă nu există acces, întrebați administratorii.
- Adăugați o nouă sucursală în Git cu codul de problemă în Jira.
- Creați o migrare pentru a adăuga date la modelul ancora printr-un script Python interactiv.
- Adăugați fișiere de descărcare (fișier YML care descrie de unde provin datele și în ce tabel sunt scrise).
- Testează-l pe stand.
- Încărcați date în depozit.
- Creați o cerere de tragere.
- Treceți prin revizuirea codului.
- După trecerea revizuirii codului, datele sunt încărcate în filiala principală și lansate automat în producție (CI/CD).
Sarcina 2 - plasați convenabil datele descărcate
O altă sarcină comună este aranjarea datelor încărcate astfel încât utilizatorul final (sau instrumentul BI) să poată lucra cu ușurință cu ele și să nu fie nevoit să facă mișcări inutile pentru a finaliza majoritatea sarcinilor. Adică, construiți sau actualizați un Dimension Data Store (DDS).
Pentru aceasta, pot fi utilizate soluții de la sarcina 1, deoarece acesta este și un proces ETL. În cea mai simplă versiune, DDS este actualizat folosind scripturi SQL.
Sarcina 3 este una dintre sarcinile atipice
Analiza streamingului apare în Profi. Un număr mare de evenimente sunt generate de la echipele de produse - le înregistrăm în ClickHouse. Dar nu puteți introduce înregistrările pe rând în număr mare, așa că trebuie să combinați înregistrările în loturi. Adică nu poți scrie direct - ai nevoie de un procesor intermediar.
Folosim un motor bazat pe Apache Flink. Până acum, procedura este următoarea: motorul procesează fluxul de evenimente primite ⟶ le pune în loturi în ClickHouse ⟶ numără numărul de evenimente în 15 minute din mers ⟶ le transferă în serviciu, care determină dacă există anomalii - le compară cu valorile pentru aceleași 15 minute cu o adâncime de 3 luni ⟶ dacă există, trimite o alertă către Slack.
Schemă pentru analiza de primă linie (parte a descărcării)
Cadrul Apache Flink garantează livrarea cel puțin o dată. Cu toate acestea, există posibilitatea de dublură. În cazul RabbitMQ, acest lucru poate fi rezolvat folosind ID-ul de corelare. Apoi livrarea unică ⟶ integritatea datelor este garantată.
Numărăm numărul de evenimente, din nou folosind Apache Flink, îl afișăm printr-un tablou de bord personalizat scris în NodeJS + front în ReactJS. O căutare rapidă nu a dat soluții similare. Și codul în sine s-a dovedit a fi simplu - scrierea nu a durat mult.
Monitorizarea este mai degrabă tehnică. Căutăm anomalii pentru a preveni problemele în stadiile incipiente. Unele valori globale semnificative ale companiei nu sunt încă incluse în monitorizare, deoarece direcția analizei streaming este în stadiul de formare.
Instrumente de bază pentru inginerii de date
Sarcinile inginerilor de date sunt mai mult sau mai puțin clare, acum puțin despre instrumentele care sunt folosite pentru a le rezolva. Desigur, instrumentele din diferite companii pot (și ar trebui) să difere - totul depinde de volumul de date, viteza de primire și eterogenitate. Poate depinde, de asemenea, de părtinirea specialistului față de un anumit instrument doar pentru că a lucrat cu acesta și îl cunoaște bine. Profi.ru a stabilit aceste opțiuni →
Pentru vizualizarea datelor - Tableau, Metabase
Tableau a fost ales cu mult timp în urmă. Acest sistem vă permite să analizați rapid cantități mari de date fără a necesita o implementare costisitoare. Pentru noi este convenabil, frumos și familiar - lucrăm adesea în el.
Puțini oameni știu despre Metabase, dar este foarte bun pentru prototipare.
Dintre instrumentele de vizualizare, putem vorbi și despre Superset de la Airbnb. Caracteristica sa specială este numeroasele sale conexiuni la baze de date și capabilități de vizualizare. Cu toate acestea, pentru utilizatorul obișnuit este mai puțin convenabil decât Metabase - nu poate alătura tabele; pentru aceasta trebuie să creați vederi separate.
În Metabase, puteți conecta tabele; în plus, serviciul face acest lucru singur, ținând cont de schema bazei de date. Iar interfața Metabase este mai simplă și mai plăcută.
Există o mulțime de instrumente - doar găsește-l pe al tău.
Pentru stocarea datelor – ClickHouse, Vertica
ClickHouse este un instrument gratuit și rapid pentru stocarea evenimentelor de produs. Pe el, analiștii înșiși fac analize separate (dacă au suficiente date) sau inginerii de date preiau agregate și le reîncarcă în Vertica pentru a construi vitrine.
Vertica este un produs cool, ușor de utilizat, pentru afișarea vitrinelor finale.
Pentru a gestiona fluxurile de date și a efectua calcule - Flux de aer
Încărcăm datele prin instrumente de consolă. De exemplu, printr-un client care vine cu MySQL - acest lucru este mai rapid.
Avantajul instrumentelor console este viteza. Datele nu sunt pompate prin memoria aceluiași proces Python. Dezavantajul este că există mai puțin control asupra datelor care zboară în tranzit de la o bază de date la alta.
Principalul limbaj de programare este Python
Python are un prag de intrare mult mai scăzut + compania are competențe în această limbă. Un alt motiv este că DAG-urile Airflow sunt scrise în Python. Aceste scripturi sunt doar un înveliș peste descărcări; munca principală este realizată prin intermediul scripturilor de consolă.
Folosim Java pentru a dezvolta analize în timp real.
Abordarea alegerii instrumentelor de date - ce trebuie făcut pentru a evita crearea unei grădini zoologice tehnologice
Există multe instrumente pe piață pentru lucrul cu datele în fiecare etapă: de la apariția lor până la afișarea pe un tablou de bord pentru consiliul de administrație. Nu este surprinzător că unele companii pot ajunge cu o serie de soluții care nu au legătură - o așa-numită grădină zoologică tehnologică.
O grădină zoologică tehnologică este formată din instrumente care îndeplinesc aceleași funcții. De exemplu, Kafka și RabbitMQ pentru mesagerie sau Grafana și Zeppelin pentru vizualizare.
— puteți vedea câte soluții duplicate pot exista
De asemenea, mulți oameni pot folosi diferite instrumente ETL în scopuri personale. Exact aceasta este situatia in Profi. ETL principal este pe Airflow, dar unii oameni folosesc Pentaho pentru descărcări personale. Ei testează ipoteze și nu trebuie să ruleze aceste date prin ingineri. Practic, instrumentele „self-service” sunt folosite de specialiști destul de experimentați care sunt implicați în activități de cercetare - studiind noi modalități de dezvoltare a produsului. Setul lor de date pentru analiză îi interesează în principal și, în plus, este în continuă schimbare. În consecință, nu are rost să adăugați aceste sarcini pe platforma principală.
Revenind la grădina zoologică. Adesea, utilizarea tehnologiilor duplicate este asociată cu factorul uman. Echipele interne detașate sunt obișnuite să lucreze cu un instrument sau altul pe care o altă echipă poate să nu îl folosească. Și uneori autonomia este singura modalitate de a rezolva probleme speciale. De exemplu, echipa de cercetare și dezvoltare trebuie să testeze ceva folosind un anumit instrument - este doar convenabil, cineva din echipă l-a folosit deja sau există un alt motiv. Este o așteptare lungă pentru administratorii de sistem pentru a instala și configura acest instrument. În același timp, administratorii atenți și meticuloși mai trebuie să demonstreze că acest lucru este cu adevărat necesar. Deci, echipa instalează instrumentul pe mașinile lor virtuale și rezolvă problemele lor specifice.
Soluțiile zoo nu reprezintă o problemă numai dacă nu necesită un efort semnificativ de administrator de sistem pentru a susține instrumentul. Trebuie să luați în considerare modul în care utilizarea instrumentului afectează resursele de asistență.
Un alt motiv comun pentru apariția unor instrumente noi este dorința de a încerca un produs necunoscut într-un domeniu destul de nou în care nu s-au format încă standarde sau nu există recomandări dovedite. Un inginer de date, ca un dezvoltator, ar trebui să exploreze întotdeauna noi instrumente în speranța de a găsi o soluție mai bună la o problemă actuală sau pentru a ține pasul cu ceea ce are de oferit piața.
Tentația de a încerca instrumente noi este cu adevărat grozavă. Dar pentru a face o alegere potrivită, mai întâi ai nevoie de autodisciplină. Vă va ajuta să nu cedați complet impulsurilor de cercetare, ci să țineți cont de capacitățile companiei în susținerea infrastructurii pentru un nou instrument.
Nu folosi tehnologia de dragul tehnologiei. Cel mai bine este să abordați problema pragmatic: o sarcină ⟶ un set de instrumente care pot rezolva această problemă.
Și apoi evaluează fiecare dintre ele și alege-l pe cel optim. De exemplu, acest instrument poate rezolva o problemă mai eficient, dar nu există competență în ea, iar acesta este ceva mai puțin eficient, dar există oameni în companie care știu să lucreze cu el. Acest instrument este plătit, dar ușor de susținut și utilizat, și acesta este o sursă deschisă la modă, dar necesită un personal de administratori pentru a-l susține. Apar astfel de dihotomii, a căror soluție necesită un cap rece.
Alegerea unui instrument este jumătate un salt de credință, jumătate o experiență personală. Nu există nicio certitudine completă că instrumentul se va potrivi.
De exemplu, Profi a început cu Pentaho pentru că avea experiență în acest instrument, dar până la urmă s-a dovedit a fi o decizie greșită. Pe măsură ce proiectul creștea, depozitul intern Pentaho a început să încetinească semnificativ. Apropo, a durat un minut pentru a salva datele și, dacă aveți obiceiul de a vă salva în mod constant munca, atunci timpul pur și simplu ți-a alunecat printre degete. La aceasta s-a adăugat o pornire complexă și sarcini programate - computerul a înghețat.
Suferința s-a încheiat după trecerea la Airflow, un instrument popular cu o comunitate mare.
Prezența unui serviciu sau a unui instrument comunitar este importantă pentru rezolvarea unor probleme complexe - poți cere sfatul colegilor tăi.
Dacă compania este matură și are resurse, este logic să te gândești la achiziționarea de suport tehnic. Acest lucru vă va ajuta să depanați rapid problemele și să primiți recomandări despre cum să utilizați produsul.
Dacă vorbim despre abordarea selecției, Profi aderă la următoarele principii:
- Nu lua decizii singur. Când o persoană alege ceva, este automat convins că are dreptate. Este o altă chestiune să-i convingi pe alții atunci când trebuie să faci o apărare serioasă. Acest lucru ajută, de asemenea, să vedeți punctele slabe ale instrumentului.
- Consultați-vă cu cercetătorul șef de date (dialog vertical). Acesta ar putea fi Chief Data Engineer, șeful echipei BI. Tops văd situația mai larg.
- Comunicați cu alte echipe (dialog orizontal). Ce instrumente folosesc și cât de bine? Poate că instrumentul colegilor vă poate rezolva și problemele și nu va trebui să creați o grădină zoologică de soluții.
Competențe interne ca înlocuitor eficient pentru un furnizor extern de servicii
Utilizarea competențelor interne ale companiei poate fi considerată și o abordare în alegerea instrumentelor.
Destul de des sunt situații în care o afacere are o sarcină complexă, dar nu există bani pentru a o implementa. Sarcina este mare și importantă și cel mai bine este să implicați un furnizor extern de servicii care are experiența relevantă. Dar din moment ce nu există o astfel de oportunitate (bani), echipa internă este încredințată să rezolve problema. În plus, companiile au de obicei mai multă încredere în angajații lor dacă aceștia și-au dovedit deja eficiența.
Exemple de astfel de sarcini atunci când o nouă direcție este dezvoltată de către angajați includ testarea încărcării și crearea unui depozit de date. În special depozitul de date, deoarece este o poveste unică pentru fiecare afacere. Spațiul de depozitare nu poate fi achiziționat; puteți angaja doar specialiști externi care o vor construi cu sprijinul unei echipe interne.
Apropo, pe măsură ce se dezvoltă noua direcție, echipa poate realiza că nevoia unui furnizor extern de servicii nu mai este necesară.
La Profi, implementarea BI a fost internă. Principala dificultate a fost că afacerea dorea să lanseze rapid BI. Dar construirea unui astfel de proiect a durat timp: construirea de competențe, încărcarea datelor, construirea unui aspect convenabil de stocare, alegerea instrumentelor și stăpânirea acestora.
Faza principală - fierbinte -, când totul era construit și cristalizat, a durat aproximativ un an. Și proiectul este încă în curs de dezvoltare.
Când construiți un depozit de date corporative, este important să respectați standarde înalte, să vă apărați pozițiile și să nu faceți lucruri care să mulțumească afacerii.
Cu mare durere, am reluat cea mai mare parte a proiectului, care apoi a trebuit să fie realizat rapid.
Dar uneori este potrivită o abordare rapidă. Deci, în dezvoltarea de produse poate fi chiar singurul corect. Trebuie să avansăm rapid, să testăm ipotezele produselor și multe altele. Dar depozitarea trebuie să se bazeze pe o arhitectură puternică, altfel nu se va putea adapta rapid afacerii în creștere și proiectul se va bloca.
Managerul nostru a fost de mare ajutor în acest proiect complex, apărând progresul lucrării, explicând conducerii ce facem, extragând resurse și pur și simplu apărându-ne. Fără un astfel de sprijin, nu sunt sigur că am fi putut lansa proiectul.
În astfel de povești, un rol important îl joacă așa-zișii early adopters - cei care sunt gata să încerce lucruri noi - în rândul managerilor de top, analiștilor și managerilor de produs. Pentru ca o temă brută să descopere, avem nevoie de pionieri care să confirme că totul funcționează și este convenabil de utilizat.
Dacă cineva dorește să împărtășească soluția la a treia problemă descrisă mai sus, bine ați venit :)
Sursa: www.habr.com
