Bună, Habr! Înscrierea pentru un nou flux de curs este deschisă chiar acum la OTUS . În așteptarea începerii cursului, vom continua să vă împărtășim materiale utile.
Management de date
Strong Data Governance este un principiu de bază al Twitter Engineering. Pe măsură ce implementăm BigQuery în platforma noastră, ne concentrăm pe descoperirea datelor, controlul accesului, securitate și confidențialitate.
Pentru a descoperi și gestiona datele, am extins Stratul de acces la date la ) pentru a oferi instrumente atât pentru datele on-premise, cât și pentru datele Google Cloud, oferind o singură interfață și API pentru utilizatorii noștri. Ca Google se îndreaptă către disponibilitatea generală, o vom include în proiectele noastre pentru a oferi utilizatorilor funcții precum căutarea în coloane.
BigQuery facilitează partajarea și accesul la date, dar trebuia să avem un anumit control asupra acestui lucru pentru a preveni exfiltrarea datelor. Printre alte instrumente, am selectat două funcții:
- : Funcție beta pentru a împiedica utilizatorii să partajeze seturi de date BigQuery cu utilizatorii din afara Twitter.
- : un control care previne exfiltrarea datelor și solicită utilizatorilor să acceseze BigQuery din intervalele de adrese IP cunoscute.
Am implementat cerințele de autentificare, autorizare și auditare (AAA) pentru securitate, după cum urmează:
- Autentificare: am folosit conturi de utilizator GCP pentru solicitările ad-hoc și conturi de serviciu pentru cererile de producție.
- Autorizare: am cerut fiecărui set de date să aibă un cont de serviciu proprietar și un grup de cititori.
- Audit: am exportat jurnalele BigQuery stackdriver, care conțineau informații detaliate de execuție a interogărilor, într-un set de date BigQuery pentru o analiză ușoară.
Pentru a ne asigura că datele personale ale utilizatorilor Twitter sunt gestionate corect, trebuie să înregistrăm toate seturile de date BigQuery, să adnotăm datele personale, să menținem o stocare adecvată și să ștergem (răzuim) datele care au fost șterse de utilizatori.
Ne-am uitat la Google , care folosește învățarea automată pentru a clasifica și edita datele sensibile, dar a decis în favoarea adnotării manuale a setului de date datorită preciziei. Intenționăm să folosim API-ul Data Loss Prevention pentru a spori adnotarea personalizată.
La Twitter, am creat patru categorii de confidențialitate pentru seturile de date din BigQuery, enumerate aici în ordinea descrescătoare a sensibilității:
- Seturi de date extrem de sensibile sunt puse la dispoziție în funcție de necesități, pe baza principiului privilegiului minim. Fiecare set de date are un grup separat de cititori și vom urmări utilizarea de către conturile individuale.
- Seturile de date cu sensibilitate medie (pseudonime unidirecționale care utilizează hashing sărat) nu conțin informații de identificare personală (PII) și sunt accesibile unui grup mai mare de angajați. Acesta este un echilibru bun între preocupările legate de confidențialitate și utilitatea datelor. Acest lucru permite angajaților să efectueze sarcini de analiză, cum ar fi calcularea numărului de utilizatori care au folosit o caracteristică, fără a ști cine sunt utilizatorii reali.
- Seturi de date cu sensibilitate redusă, cu toate informațiile de identificare a utilizatorului. Aceasta este o abordare bună din perspectiva confidențialității, dar nu poate fi utilizată pentru analiza la nivel de utilizator.
- Seturile de date publice (eliberate în afara Twitter) sunt disponibile pentru toți angajații Twitter.
În ceea ce privește înregistrarea în jurnal, am folosit sarcini programate pentru a enumera seturile de date BigQuery și a le înregistra cu Stratul de acces la date (), depozitul de metadate Twitter. Utilizatorii vor adnota seturile de date cu informații de confidențialitate și, de asemenea, vor specifica o perioadă de păstrare. În ceea ce privește curățarea, evaluăm performanța și costul a două opțiuni: 1. Curățarea seturi de date în GCS utilizând instrumente precum Scalding și încărcarea lor în BigQuery; 2. Utilizarea instrucțiunilor DML BigQuery. Probabil că vom folosi o combinație a ambelor metode pentru a îndeplini cerințele diferitelor grupuri și date.
Funcționalitatea sistemului
Deoarece BigQuery este un serviciu gestionat, nu a fost nevoie să implicați echipa SRE a Twitter în gestionarea sistemelor sau în sarcinile de birou. A fost ușor să oferiți mai multă capacitate atât pentru stocare, cât și pentru calcul. Am putea schimba rezervarea sloturilor creând un bilet cu suport Google. Am identificat domenii care ar putea fi îmbunătățite, cum ar fi alocarea de sloturi cu autoservire și îmbunătățirile tabloului de bord pentru monitorizare și am trimis acele solicitări la Google.
Costa
Analiza noastră preliminară a arătat că costurile de interogare pentru BigQuery și Presto au fost la același nivel. Am achiziționat sloturi pentru prețul să aibă un cost lunar stabil în loc de plată pe TB de date prelucrate. Această decizie s-a bazat și pe feedback-ul utilizatorilor care nu au vrut să se gândească la costuri înainte de a face fiecare cerere.
Stocarea datelor în BigQuery a adus costuri în plus față de costurile GCS. Instrumente precum Scalding necesită seturi de date în GCS și, pentru a accesa BigQuery, a trebuit să încărcăm aceleași seturi de date în format BigQuery . Lucrăm la o conexiune Scalding la seturile de date BigQuery, care va elimina necesitatea de a stoca seturi de date atât în GCS, cât și în BigQuery.
Pentru cazurile rare care necesită interogări rare de zeci de petaocteți, am decis că stocarea seturilor de date în BigQuery nu era rentabilă și am folosit Presto pentru a accesa direct seturile de date în GCS. Pentru a face acest lucru, ne uităm la sursele de date externe BigQuery.
Pașii următori
Am observat mult interes pentru BigQuery de la lansarea alfa. Adăugăm mai multe seturi de date și mai multe comenzi la BigQuery. Dezvoltăm conectori pentru instrumente de analiză a datelor, cum ar fi Scalding, pentru a citi și a scrie în stocarea BigQuery. Ne uităm la instrumente precum Looker și Apache Zeppelin pentru a crea rapoarte și note de calitate pentru întreprindere folosind seturi de date BigQuery.
Colaborarea noastră cu Google a fost foarte productivă și suntem încântați să continuăm și să dezvoltăm acest parteneriat. Am lucrat cu Google pentru a le implementa pe a noastră pentru a trimite interogări direct la Google. Unele dintre ele, cum ar fi încărcătorul BigQuery Parquet, au fost deja implementate de Google.
Iată câteva dintre solicitările noastre de funcții prioritare pentru Google:
- Instrumente pentru recepția convenabilă a datelor și suport pentru formatul LZO-Thrift.
- Segmentarea orară
- Îmbunătățiri ale controlului accesului, cum ar fi permisiunile la nivel de tabel, rând și coloană.
- Bigquery. cu integrarea Hive Metastore și suport pentru formatul LZO-Thrift.
- Integrare îmbunătățită a catalogului de date în interfața de utilizator BigQuery
- Self-service pentru alocarea și monitorizarea sloturilor.
Concluzie
Democratizarea analizei datelor, a vizualizării și a învățării automate într-un mod sigur este o prioritate de top pentru echipa Platformei de date. Am identificat Google BigQuery și Data Studio ca instrumente care ar putea ajuta la atingerea acestui obiectiv și am lansat BigQuery Alpha la nivel de companie anul trecut.
Am constatat că interogările din BigQuery sunt simple și eficiente. Am folosit instrumentele Google pentru a ingera și transforma date pentru conducte simple, dar pentru conducte complexe a trebuit să ne construim propriul cadru Airflow. În spațiul de gestionare a datelor, serviciile BigQuery pentru autentificare, autorizare și auditare satisfac nevoile noastre. Pentru a gestiona metadatele și a menține confidențialitatea, aveam nevoie de mai multă flexibilitate și a trebuit să ne construim propriile sisteme. BigQuery, fiind un serviciu gestionat, a fost ușor de utilizat. Costurile de interogare au fost similare cu instrumentele existente. Stocarea datelor în BigQuery implică costuri în plus față de costurile GCS.
În general, BigQuery funcționează bine pentru analiza SQL generală. Observăm un mare interes pentru BigQuery și ne străduim să migrăm mai multe seturi de date, să aducem mai multe echipe și să construim mai multe conducte cu BigQuery. Twitter folosește o varietate de date care vor necesita o combinație de instrumente precum Scalding, Spark, Presto și Druid. Intenționăm să continuăm să ne consolidăm instrumentele de analiză a datelor și să oferim îndrumări clare utilizatorilor noștri cu privire la modul de utilizare optimă a ofertelor noastre.
Cuvinte de recunoștință
Aș dori să le mulțumesc coautorilor și colegilor mei, Anju Jha și Will Pascucci, pentru marea colaborare și munca asiduă la acest proiect. De asemenea, aș dori să mulțumesc inginerilor și managerilor mai multor echipe de la Twitter și Google care ne-au ajutat și utilizatorilor BigQuery de pe Twitter care au oferit feedback valoros.
Dacă sunteți interesat să lucrați la aceste probleme, consultați-ne în echipa Platformei de date.
Sursa: www.habr.com