Bună, Habr! Înscrierea pentru un nou flux de curs este deschisă chiar acum la OTUS . În așteptarea începerii cursului, v-am pregătit în mod tradițional o traducere a unui material interesant.
În fiecare zi, peste o sută de milioane de oameni vizitează Twitter pentru a afla ce se întâmplă în lume și pentru a discuta despre asta. Fiecare tweet și orice altă acțiune a utilizatorului generează un eveniment care este disponibil pentru analiza internă a datelor Twitter. Sute de angajați analizează și vizualizează aceste date, iar îmbunătățirea experienței lor este o prioritate de top pentru echipa Twitter Data Platform.
Considerăm că utilizatorii cu o gamă largă de abilități tehnice ar trebui să poată descoperi date și să aibă acces la instrumente de analiză și vizualizare bazate pe SQL performante. Acest lucru ar permite unui grup complet nou de utilizatori mai puțin tehnici, inclusiv analiști de date și manageri de produs, să extragă informații din date, permițându-le să înțeleagă și să utilizeze mai bine capacitățile Twitter. Așa democratizăm analiza datelor pe Twitter.
Pe măsură ce instrumentele noastre și capabilitățile interne de analiză a datelor s-au îmbunătățit, am văzut că Twitter se îmbunătățește. Cu toate acestea, mai este loc de îmbunătățire. Instrumentele actuale precum Scalding necesită experiență de programare. Instrumentele de analiză bazate pe SQL, cum ar fi Presto și Vertica, au probleme de performanță la scară. Avem, de asemenea, problema distribuirii datelor pe mai multe sisteme fără acces constant la acestea.
Anul trecut am anunțat , în cadrul căruia transferăm părți ale noastre pe Google Cloud Platform (GCP). Am ajuns la concluzia că instrumentele Google Cloud ne poate ajuta cu inițiativele noastre de a democratiza analiza, vizualizarea și învățarea automată pe Twitter:
- : depozit de date enterprise cu motor SQL bazat , care este renumit pentru viteză, simplitate și face față .
- instrument de vizualizare a datelor mari cu funcții de colaborare asemănătoare Google Docs.
În acest articol, veți afla despre experiența noastră cu aceste instrumente: ce am făcut, ce am învățat și ce vom face în continuare. Acum ne vom concentra asupra analizei pe lot și interactiv. Vom discuta despre analiza în timp real în articolul următor.
Istoricul magazinelor de date Twitter
Înainte de a te scufunda în BigQuery, merită să relatezi pe scurt istoria depozitării de date Twitter. În 2011, analiza datelor Twitter a fost efectuată în Vertica și Hadoop. Am folosit Pig pentru a crea joburi MapReduce Hadoop. În 2012, am înlocuit Pig cu Scalding, care avea un API Scala cu beneficii precum capacitatea de a crea conducte complexe și ușurința de testare. Cu toate acestea, pentru mulți analiști de date și manageri de produs care au fost mai confortabil să lucreze cu SQL, a fost o curbă de învățare destul de abruptă. În jurul anului 2016, am început să folosim Presto ca interfață SQL pentru datele Hadoop. Spark a oferit o interfață Python, ceea ce o face o alegere bună pentru știința datelor ad-hoc și învățarea automată.
Din 2018, am folosit următoarele instrumente pentru analiza și vizualizarea datelor:
- Opărire pentru transportoare de producție
- Scalding și Spark pentru analiza de date ad-hoc și învățarea automată
- Vertica și Presto pentru analiză SQL ad-hoc și interactivă
- Druid pentru acces interactiv, explorator și cu latență scăzută la valorile seriei de timp
- Tableau, Zeppelin și Pivot pentru vizualizarea datelor
Am descoperit că, în timp ce aceste instrumente oferă capabilități foarte puternice, am avut dificultăți în a pune aceste capabilități la dispoziția unui public mai larg pe Twitter. Prin extinderea platformei noastre cu Google Cloud, ne concentrăm pe simplificarea instrumentelor noastre de analiză pentru tot Twitter.
Depozitul de date BigQuery de la Google
Mai multe echipe de la Twitter au încorporat deja BigQuery în unele dintre conductele lor de producție. Folosind expertiza lor, am început să evaluăm capacitățile BigQuery pentru toate cazurile de utilizare Twitter. Scopul nostru a fost să oferim BigQuery întregii companii și să îl standardizăm și să îl sprijinim în cadrul setului de instrumente Data Platform. Acest lucru a fost dificil din multe motive. Aveam nevoie să dezvoltăm o infrastructură care să ingereze în mod fiabil volume mari de date, să sprijine gestionarea datelor la nivel de companie, să asigurăm controale adecvate de acces și să asigurăm confidențialitatea clienților. De asemenea, a trebuit să creăm sisteme pentru alocarea resurselor, monitorizare și rambursări, astfel încât echipele să poată folosi BigQuery în mod eficient.
În noiembrie 2018, am lansat o versiune alfa la nivel de companie a BigQuery și Data Studio. Le-am oferit angajaților Twitter unele dintre foile noastre de calcul cele mai frecvent utilizate cu date personale curățate. BigQuery a fost folosit de peste 250 de utilizatori dintr-o varietate de echipe, inclusiv de inginerie, finanțe și marketing. Cel mai recent, rulau aproximativ 8 de solicitări, procesau aproximativ 100 PB pe lună, fără a lua în calcul cererile programate. După ce am primit feedback foarte pozitiv, am decis să mergem mai departe și să oferim BigQuery ca resursă principală pentru interacțiunea cu datele de pe Twitter.
Iată o diagramă de nivel înalt a arhitecturii noastre de depozit de date Google BigQuery.
Copiăm datele din clustere Hadoop locale în Google Cloud Storage (GCS) folosind instrumentul intern Cloud Replicator. Apoi folosim Apache Airflow pentru a crea conducte care folosesc "» pentru a încărca date din GCS în BigQuery. Folosim Presto pentru a interoga seturile de date Parquet sau Thrift-LZO în GCS. BQ Blaster este un instrument intern Scalding pentru încărcarea seturilor de date HDFS Vertica și Thrift-LZO în BigQuery.
În secțiunile următoare, discutăm abordarea și expertiza noastră în domeniile ușurinței de utilizare, performanță, management al datelor, sănătatea sistemului și cost.
Ușor de utilizat
Am descoperit că pentru utilizatori a fost ușor să înceapă cu BigQuery, deoarece nu necesita instalare de software și utilizatorii îl puteau accesa printr-o interfață web intuitivă. Cu toate acestea, utilizatorii trebuiau să se familiarizeze cu unele dintre caracteristicile și conceptele GCP, inclusiv resurse precum proiecte, seturi de date și tabele. Am dezvoltat materiale educaționale și tutoriale pentru a ajuta utilizatorii să înceapă. Cu o înțelegere de bază dobândită, utilizatorilor le-a fost ușor să navigheze în seturi de date, să vizualizeze scheme și date din tabel, să execute interogări simple și să vizualizeze rezultatele în Data Studio.
Scopul nostru pentru introducerea datelor în BigQuery a fost să permitem încărcarea fără întreruperi a seturilor de date HDFS sau GCS cu un singur clic. Ne-am gândit (gestionat de Airflow), dar nu l-au putut folosi din cauza modelului nostru de securitate de partajare restricționată în domeniu (mai multe despre acest lucru în secțiunea Gestionarea datelor de mai jos). Am experimentat cu utilizarea Serviciului de transfer de date Google (DTS) pentru a orchestra sarcinile de lucru BigQuery. Deși DTS s-a configurat rapid, nu a fost flexibil pentru a construi conducte cu dependențe. Pentru versiunea noastră alfa, am construit propriul nostru cadru Apache Airflow în GCE și îl pregătim pentru a rula în producție și pentru a putea suporta mai multe surse de date, cum ar fi Vertica.
Pentru a transforma datele în BigQuery, utilizatorii creează conducte simple de date SQL folosind interogări programate. Pentru conductele complexe în mai multe etape cu dependențe, intenționăm să folosim fie propriul nostru cadru Airflow, fie Cloud Composer împreună cu .
productivitate
BigQuery este conceput pentru interogări SQL de uz general care procesează cantități mari de date. Nu este destinat pentru interogările cu latență scăzută și cu randament ridicat cerute de o bază de date tranzacțională sau pentru analiza seriilor temporale cu latență scăzută implementată . Pentru interogările de analiză interactivă, utilizatorii noștri se așteaptă la timpi de răspuns mai mici de un minut. A trebuit să ne proiectăm utilizarea BigQuery pentru a îndeplini aceste așteptări. Pentru a oferi performanțe previzibile pentru utilizatorii noștri, am folosit funcționalitatea BigQuery, disponibilă clienților cu o taxă fixă, care le permite proprietarilor de proiecte să rezerve spații minime pentru interogările lor. BigQuery este o unitate de putere de calcul necesară pentru a executa interogări SQL.
Am analizat peste 800 de interogări care procesau aproximativ 1 TB de date fiecare și am constatat că timpul mediu de execuție a fost de 30 de secunde. De asemenea, am învățat că performanța depinde în mare măsură de utilizarea slotului nostru în diferite proiecte și sarcini. A trebuit să delimităm clar rezervele noastre de producție și sloturi ad-hoc pentru a menține performanța pentru cazurile de utilizare în producție și analiza online. Acest lucru a influențat foarte mult designul nostru pentru rezervările de sloturi și ierarhia proiectelor.
Vom vorbi despre managementul datelor, funcționalitatea și costul sistemelor în zilele următoare în a doua parte a traducerii, dar acum îi invităm pe toți să , timp în care veți putea afla în detaliu despre curs, precum și să puneți întrebări expertului nostru - Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Citeste mai mult:
Sursa: www.habr.com