Bună, Habr! Chiar acum, OTUS a deschis înscrierea pentru noul flux al cursului . În pregătirea începerii cursului, continuăm să împărtășim cu voi materiale utile.
Gestionarea datelor
Guvernanța puternică a datelor (Strong Data Governance) este principala direcție în Twitter Engineering. Pe măsură ce implementăm BigQuery în platforma noastră, ne concentrăm pe descoperirea datelor, controlul accesului, securitatea și confidențialitatea.
Pentru descoperirea și gestionarea datelor, am extins nivelul nostru de acces la date (Data Access Layer — ), pentru a oferi instrumente atât pentru datele locale, cât și pentru datele Google Cloud, oferind o interfață și un API unificat pentru utilizatorii noștri. Pe măsură ce Google trece spre publicare, îl vom include în proiectele noastre pentru a oferi utilizatorilor funcții precum căutarea pe coloane.
BigQuery facilitează partajarea și accesul la date, dar trebuie să controlăm acest lucru într-o oarecare măsură pentru a preveni exfiltrarea datelor. Printre alte instrumente, am ales două funcții:
- : funcție beta care interzice utilizatorilor să partajeze seturi de date BigQuery cu utilizatori din afara Twitter.
- : un control care previne exfiltrarea datelor și necesită ca utilizatorii să acceseze BigQuery din intervale IP cunoscute.
Am implementat cerințele de autentificare, autorizare și audit (AAA) pentru a asigura securitatea în modul următor:
- Autentificare: am folosit conturi de utilizator GCP pentru interogări ad hoc și conturi de serviciu pentru solicitări de lucru.
- Autorizare: am cerut ca fiecare set de date să aibă un cont de serviciu proprietar și un grup de cititori.
- Audit: am exportat jurnalele stackdriver-ului BigQuery, care conțineau informații detaliate despre execuția interogărilor, în seturi de date BigQuery pentru a facilita analiza.
Pentru a asigura o gestionare adecvată a datelor personale ale utilizatorilor Twitter, trebuie să înregistrăm toate seturile de date BigQuery, să adnotăm datele personale, să menținem o stocare corespunzătoare și să eliminăm datele care au fost șterse de utilizatori.
Am analizat Google , care utilizează învățarea automată pentru clasificarea și editarea datelor sensibile, dar am decis în favoarea anotării manuale a setului de date din cauza acurateței. Plănuim să utilizăm API-ul de Prevenire a Pierderii Datelor pentru a completa anotarea realizată de utilizatori.
În Twitter, am creat patru categorii de confidențialitate pentru seturile de date din BigQuery, enumerate aici în ordinea descrescătoare a sensibilității:
- Seturile de date cu sensibiltate ridicată sunt disponibile după nevoie, bazându-ne pe principiul privilegiilor minime. Fiecare set de date are un grup separat de cititori, iar noi vom urmări utilizarea conturilor individuale.
- Seturile de date cu sensibilitate medie (pseudonime unidirecționale folosind hashing cu sare) nu conțin informații personale identificabile (Personally Identifiable Information — PII) și sunt disponibile pentru un grup mai mare de angajați. Aceasta este o bună balanță între considerațiile de confidențialitate și utilitatea datelor. Permite angajaților să efectueze sarcini de analiză, cum ar fi calcularea numărului de utilizatori care au folosit funcția, fără a ști cine sunt utilizatorii reali.
- Seturile de date cu sensibilitate scăzută includ toate informațiile care identifică utilizatorul. Aceasta este o abordare bună din punct de vedere al confidențialității, dar nu poate fi utilizată pentru analize la nivel de utilizator.
- Seturile de date publice (emise în afara Twitter) sunt disponibile tuturor angajaților Twitter.
În ceea ce privește înregistrarea, am folosit sarcini programate pentru a enumera seturile de date BigQuery și pentru a le înregistra în Data Access Layer (), depozitul de metadate Twitter. Utilizatorii vor anota seturile de date cu informații despre confidențialitate, precum și vor specifica durata de păstrare. În ceea ce privește curățarea, evaluăm performanța și costul a două opțiuni: 1. Curățarea seturilor de date în GCS cu ajutorul unor instrumente precum Scalding și încărcarea acestora în BigQuery; 2. Utilizarea operatorilor BigQuery DML. Probabil că vom utiliza o combinație a ambelor metode pentru a satisface cerințele diferitelor grupuri și date.
Funcționalitatea sistemului
Deoarece BigQuery este un serviciu gestionat, nu a fost necesară implicarea echipei SRE de la Twitter în gestionarea sistemelor sau îndeplinirea sarcinilor de gardă. A fost ușor să asigurăm o capacitate mare atât pentru stocare, cât și pentru calcule. Am putea ajusta rezervările de sloturi, creând tichete în suportul Google. Am stabilit că ar fi posibil să îmbunătățim, de exemplu, auto-serviciul pentru distribuirea sloturilor și să îmbunătățim tabloul de bord pentru monitorizare și am transmis aceste solicitări Google.
Preț
Analiza noastră preliminară a arătat că costul interogărilor pentru BigQuery și Presto era similar. Am achiziționat sloturi la pentru a avea un cost lunar stabil în loc de a plăti pe TB de date prelucrate. Această decizie a fost, de asemenea, bazată pe feedbackul utilizatorilor care nu doreau să se gândească la costurile asociate cu fiecare interogare.
Stocarea datelor în BigQuery a generat costuri suplimentare pe lângă cheltuielile cu GCS. Instrumente precum Scalding necesită seturi de date în GCS, iar pentru a accesa BigQuery a trebuit să încărcăm aceleași seturi de date în formatul BigQuery . Lucrăm la conectarea Scalding-ului cu seturile de date BigQuery, ceea ce va elimina necesitatea stocării seturilor de date atât în GCS, cât și în BigQuery.
Pentru cazurile rare care necesitau interogări ocazionale pe zeci de petabytes, am decis că stocarea seturilor de date în BigQuery nu este rentabilă și am folosit Presto pentru accesul direct la seturile de date din GCS. În acest scop, ne uităm la Sursele de Date Externe BigQuery.
Următorii pași
Am observat un interes mare pentru BigQuery încă de la lansarea versiunii alpha. Adăugăm mai multe seturi de date și mai multe echipe în BigQuery. Dezvoltăm conectori pentru instrumente de analiză a datelor, cum ar fi Scalding, pentru a citi și a scrie în stocarea BigQuery. Luăm în considerare instrumente precum Looker și Apache Zeppelin pentru a crea rapoarte corporative despre calitate și note folosind seturi de date BigQuery.
Colaborarea cu Google a fost foarte productivă și suntem încântați să continuăm și să dezvoltăm acest parteneriat. Am colaborat cu Google pentru a implementa propriul nostru , pentru a trimite solicitări direct către Google. Unele dintre acestea, cum ar fi încărcătorul Parquet BigQuery, sunt deja implementate de Google.
Iată câteva dintre cele mai importante solicitări de funcționalitate pentru Google:
- Instrumente pentru primirea ușoară a datelor și suport pentru formatul LZO-Thrift.
- Segmentare pe oră
- Îmbunătățiri în domeniul controlului accesului, cum ar fi permisiuni la nivel de tabele, rânduri și coloane.
- BigQuery cu integrarea și suportul Hive Metastore pentru formatul LZO-Thrift.
- Integrare îmbunătățită a catalogului de date în interfața utilizatorului BigQuery
- Auto-servire pentru distribuirea și monitorizarea sloturilor.
Concluzie
Democratizarea analizei datelor, vizualizării și învățării automate într-un mod sigur este o prioritate de rang înalt pentru echipa Data Platform. Am identificat Google BigQuery și Data Studio ca instrumente care pot ajuta la atingerea acestui obiectiv și am lansat anul trecut BigQuery Alpha pentru întreaga companie.
Am constatat că interogările în BigQuery au fost simple și eficiente. Pentru primirea și transformarea datelor, am folosit instrumentele Google pentru conducte simple, dar pentru conducte complexe a trebuit să ne construim propria infrastructură Airflow. În domeniul gestionării datelor, serviciile BigQuery pentru autentificare, autorizare și audit îndeplinesc nevoile noastre. Pentru gestionarea metadatelor și asigurarea confidențialității, aveam nevoie de o flexibilitate mai mare și a fost necesar să construim propriile sisteme. BigQuery, fiind un serviciu gestionat, a fost ușor de utilizat. Costurile interogărilor au fost similare cu cele ale instrumentelor existente. Stocarea datelor în BigQuery a adus cheltuieli suplimentare pe lângă costurile pentru GCS.
În general, BigQuery funcționează bine pentru analiza SQL generală. Observăm un interes mare pentru BigQuery și lucrăm la mutarea unui număr mai mare de seturi de date, atragerea unui număr mai mare de echipe și crearea unui număr mai mare de conducte cu BigQuery. În Twitter se folosesc date variate, pentru care va fi necesar un amestec de instrumente precum Scalding, Spark, Presto și Druid. Intenționăm să continuăm să ne dezvoltăm instrumentele de analiză a datelor și să oferim recomandări clare utilizatorilor noștri despre cum să folosească cel mai bine oferte noastre.
Cuvinte de mulțumire
Aș dori să le mulțumesc colegilor și colaboratorilor mei, Anju Dja și Will Pascucci, pentru colaborarea lor excelentă și munca asiduă la acest proiect. De asemenea, aș dori să le mulțumesc inginerilor și managerilor din mai multe echipe de la Twitter și Google, care ne-au ajutat pe noi și utilizatorii BigQuery de la Twitter, oferindu-ne feedback valoros.
Dacă ești interesat să lucrezi la aceste sarcini, consultă echipa Data Platform.
Sursa: habr.com
