Ciao, Habr! Al momento in OTUS è aperto il reclutamento per un nuovo ciclo del corso . In attesa dell'inizio del corso, continuiamo a condividere con voi materiali utili.
Gestione dei dati
Una forte gestione dei dati (Strong Data Governance) è un principio fondamentale di Twitter Engineering. Mentre implementiamo BigQuery nella nostra piattaforma, ci concentriamo sulla scoperta dei dati, sul controllo degli accessi, sulla sicurezza e sulla privacy.
Per la scoperta e la gestione dei dati, abbiamo ampliato il nostro livello di accesso ai dati (Data Access Layer - ), per fornire strumenti sia per i dati locali che per quelli di Google Cloud, offrendo un'unica interfaccia e un'API per i nostri utenti. Man mano che Google si muove verso la pubblicità, lo includeremo nei nostri progetti per fornire agli utenti funzionalità come la ricerca per colonne.
BigQuery consente di condividere e accedere facilmente ai dati, ma abbiamo dovuto controllare questo accesso per prevenire l'estrazione non autorizzata di dati. Tra gli altri strumenti, abbiamo selezionato due funzionalità:
- : una funzione beta che impedisce agli utenti di condividere set di dati BigQuery con utenti al di fuori di Twitter.
- : un controllo che previene l'estrazione di dati e richiede agli utenti di accedere a BigQuery da range di indirizzi IP conosciuti.
Abbiamo implementato i requisiti di autenticazione, autorizzazione e audit (AAA) per garantire la sicurezza nel modo seguente:
- Autenticazione: abbiamo utilizzato account utente GCP per richieste ad hoc e account di servizio per richieste operative.
- Autorizzazione: richiedevamo che ogni set di dati avesse un account di servizio proprietario e un gruppo di lettori.
- Audit: abbiamo esportato i log del stack driver di BigQuery, che contenevano dettagli sulle esecuzioni delle query, in un set di dati BigQuery per agevolarne l'analisi.
Per garantire un'adeguata gestione dei dati personali degli utenti di Twitter, dobbiamo registrare tutti i set di dati BigQuery, annotare i dati personali, mantenere un corretto stoccaggio e cancellare (ripulire) i dati che sono stati rimossi dagli utenti.
Abbiamo esaminato Google , che utilizza l'apprendimento automatico per classificare e modificare i dati riservati, ma si è deciso di optare per l'annotazione manuale del set di dati a causa della precisione. Prevediamo di utilizzare l'API di prevenzione della perdita di dati per integrare l'annotazione degli utenti.
In Twitter abbiamo creato quattro categorie di riservatezza per i set di dati in BigQuery, elencate qui in ordine decrescente di sensibilità:
- I set di dati ad alta sensibilità sono accessibili su base necessaria secondo il principio del minimo privilegio. Ogni set di dati ha un gruppo di lettori separato e monitoreremo l'uso di singoli account.
- I set di dati di media sensibilità (pseudonimi unidirezionali che utilizzano l'hashing salato) non contengono informazioni personali (Personally Identifiable Information - PII) e sono accessibili a un gruppo più ampio di dipendenti. Questo rappresenta un buon equilibrio tra considerazioni di riservatezza e utilità dei dati. Permette ai dipendenti di eseguire attività analitiche, come il calcolo del numero di utenti che hanno utilizzato una funzione, senza sapere chi siano realmente gli utenti.
- I set di dati a bassa sensibilità contengono informazioni che identificano l'utente. Questo approccio è valido dal punto di vista della riservatezza, ma non può essere utilizzato per analisi a livello di utente.
- I set di dati pubblici (rilasciati al di fuori di Twitter) sono accessibili a tutti i dipendenti di Twitter.
Per quanto riguarda la registrazione, abbiamo utilizzato attività pianificate per elencare i set di dati BigQuery e registrarli nel Data Access Layer (), il data warehouse dei metadati di Twitter. Gli utenti annoteranno i set di dati con informazioni sulla riservatezza e specificheranno anche il periodo di conservazione. Per quanto riguarda la pulizia, stiamo valutando le prestazioni e i costi di due opzioni: 1. Pulizia dei set di dati in GCS utilizzando strumenti come Scalding, e caricamento in BigQuery; 2. Utilizzo degli operatori DML di BigQuery. Probabilmente utilizzeremo una combinazione di entrambi i metodi per soddisfare i requisiti di diversi gruppi e dati.
Funzionalità del sistema
Poiché BigQuery è un servizio gestito, non è stato necessario coinvolgere il team SRE di Twitter nella gestione dei sistemi o nell'esecuzione di compiti di guardia. È stato facile garantire una grande capacità sia per l'archiviazione che per il calcolo. Avremmo potuto modificare la prenotazione degli slot aprendo ticket di supporto a Google. Abbiamo identificato aree di miglioramento, come l'autoservizio per la distribuzione degli slot e il potenziamento del dashboard per il monitoraggio, e abbiamo inoltrato queste richieste a Google.
Prezzo
La nostra analisi preliminare ha mostrato che il costo delle query per BigQuery e Presto era equivalente. Abbiamo acquisito slot a a consumo L'archiviazione dei dati in BigQuery ha comportato costi aggiuntivi oltre a quelli di GCS. Strumenti come Scalding richiedono set di dati in GCS, e per accedere a BigQuery abbiamo dovuto caricare gli stessi set di dati nel formato BigQuery
Capacitor Per i casi rari che richiedevano query non frequenti su decine di petabyte, abbiamo deciso che archiviare i set di dati in BigQuery non fosse economicamente vantaggioso e abbiamo utilizzato Presto per accedere direttamente ai set di dati in GCS. A tal fine, stiamo considerando i BigQuery External Data Sources.
Abbiamo registrato un grande interesse per BigQuery sin dal rilascio dell'alpha. Stiamo aggiungendo più set di dati e più team in BigQuery. Stiamo sviluppando connettori per strumenti di analisi dei dati, come Scalding, per la lettura e la scrittura nello storage di BigQuery. Stiamo esplorando strumenti come Looker e Apache Zeppelin per realizzare report aziendali sulla qualità e note utilizzando set di dati di BigQuery.
Passaggi successivi
La collaborazione con Google è stata molto produttiva, e siamo felici di proseguire e sviluppare questa partnership. Abbiamo lavorato con Google per implementare il nostro
Partner Issue Tracker , per inviare richieste direttamente a Google. Alcuni di essi, come il caricatore BigQuery Parquet, sono già stati implementati da Google.
Ecco alcune delle nostre richieste di funzionalità ad alta priorità per Google:
- Strumenti per la raccolta facilitata dei dati e supporto per il formato LZO-Thrift.
- Segmentazione oraria
- Miglioramenti nel controllo degli accessi, come le autorizzazioni a livello di tabelle, righe e colonne.
- BigQuery con integrazione e supporto per Hive Metastore per il formato LZO-Thrift.
- Integrazione migliorata del catalogo dati nell'interfaccia utente di BigQuery
- Self-service per la distribuzione e il monitoraggio dei slot.
Conclusione
La democratizzazione dell'analisi dei dati, della visualizzazione e dell'apprendimento automatico in modo sicuro è la massima priorità per il team della Data Platform. Abbiamo identificato Google BigQuery e Data Studio come strumenti che possono aiutare a raggiungere questo obiettivo e abbiamo rilasciato BigQuery Alpha per l'intera azienda lo scorso anno.
Abbiamo scoperto che le query su BigQuery erano semplici ed efficaci. Per la raccolta e la trasformazione dei dati abbiamo utilizzato strumenti Google per pipeline semplici, ma per pipeline più complesse abbiamo dovuto creare la nostra infrastruttura Airflow. Nel campo della gestione dei dati, i servizi di BigQuery per autenticazione, autorizzazione e audit soddisfano le nostre esigenze. Per la gestione dei metadati e il rispetto della privacy avevamo bisogno di maggiore flessibilità e abbiamo dovuto creare sistemi propri. BigQuery, essendo un servizio gestito, era facile da utilizzare. I costi delle query erano simili a quelli degli strumenti esistenti. L'archiviazione dei dati in BigQuery comportava costi aggiuntivi rispetto a quelli di GCS.
In generale, BigQuery funziona bene per l'analisi SQL generale. Notiamo un grande interesse per BigQuery e stiamo lavorando per trasferire un numero maggiore di set di dati, coinvolgere più team e creare più pipeline con BigQuery. A Twitter vengono utilizzati diversi dati, per i quali sarà necessario un mix di strumenti come Scalding, Spark, Presto e Druid. Intendiamo continuare a potenziare i nostri strumenti di analisi dei dati e fornire raccomandazioni chiare ai nostri utenti su come utilizzare al meglio le nostre offerte.
Parole di ringraziamento
Vorrei ringraziare i miei coautori e compagni di squadra, Anju Dja e Will Pascucci, per la loro splendida collaborazione e il duro lavoro in questo progetto. Vorrei anche ringraziare gli ingegneri e i manager di diversi team di Twitter e Google, che ci hanno aiutato e agli utenti di BigQuery su Twitter, fornendo preziosi feedback.
Se sei interessato a lavorare su questi progetti, dai un'occhiata alle nostre nel team Data Platform.
Fonte: habr.com
