Ciao, Habr! Al momento è aperto un nuovo corso in OTUS. . In vista dell'inizio del corso, continuiamo a condividere con voi materiale utile.
Gestione dei dati
Una gestione solida dei dati (Strong Data Governance) è un principio fondamentale di Twitter Engineering. Poiché stiamo implementando 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 su Google Cloud, offrendo un'interfaccia e un'API unificate ai nostri utenti. Con il passare del tempo, Google si sta dirigendo verso la pubblicità, quindi lo includeremo nei nostri progetti per fornire agli utenti funzionalità come la ricerca nelle colonne.
BigQuery consente di condividere facilmente i dati e di accedervi, ma abbiamo bisogno di controllare questo processo in certa misura per prevenire l'esfiltrazione dei dati. Tra gli altri strumenti, abbiamo scelto due funzionalità:
- : una funzione beta che vieta agli utenti di condividere set di dati BigQuery con utenti al di fuori di Twitter.
- : un controllo che previene l'esfiltrazione dei dati e richiede agli utenti di accedere a BigQuery da intervalli IP noti.
Abbiamo implementato i requisiti di autenticazione, autorizzazione e auditing (AAA) per garantire la sicurezza nel seguente modo:
- Autenticazione: abbiamo utilizzato gli account utente GCP per richieste ad hoc e gli account di servizio per richieste di lavoro.
- Autorizzazione: abbiamo richiesto che ogni set di dati avesse un account di servizio proprietario e un gruppo di lettori.
- Audit: abbiamo esportato i log dei stackdriver di BigQuery, contenenti dettagli sull'esecuzione delle query, in un set di dati BigQuery per una comoda analisi.
Per garantire una corretta gestione dei dati personali degli utenti di Twitter, dobbiamo registrare tutti i set di dati BigQuery, annotare i dati personali, mantenere una corretta conservazione e rimuovere (pulire) i dati che sono stati eliminati dagli utenti.
Abbiamo preso in considerazione Google , che utilizza l'apprendimento automatico per classificare e modificare i dati sensibili, ma abbiamo deciso di optare per l'annotazione manuale del set di dati a causa della precisione. Pianifichiamo di utilizzare l'API di prevenzione della perdita di dati per integrare l'annotazione da parte degli utenti.
Su 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 richiesta in base al principio del minor privilegio. Ogni set di dati ha un gruppo di lettori separato e monitoreremo l'uso di singoli account.
- I set di dati a sensibilità media (pseudonimi unidirezionali con hashing salato) non contengono informazioni personali identificabili (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 svolgere attività analitiche, come calcolare il numero di utenti che hanno utilizzato una funzione, senza sapere chi siano reali utenti.
- I set di dati a bassa sensibilità contengono tutte le informazioni che identificano l'utente. Questo approccio è valido dal punto di vista della riservatezza, ma non può essere utilizzato per analisi a livello utente.
- 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 (), archivio di metadati di Twitter. Gli utenti annoteranno i set di dati con informazioni sulla privacy e indicheranno il periodo di conservazione. Per quanto riguarda la pulizia, stiamo valutando l'efficienza e il costo 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 le esigenze dei diversi gruppi e dei 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 sorveglianza. È stato facile garantire una grande capacità sia per lo storage che per il calcolo. Avremmo potuto modificare la riserva di slot creando ticket di supporto a Google. Abbiamo identificato miglioramenti potenziali, come l'auto-servizio per la distribuzione degli slot e il miglioramento del dashboard per il monitoraggio, e abbiamo inoltrato queste richieste a Google.
Costo
La nostra analisi preliminare ha mostrato che i costi delle query per BigQuery e Presto erano simili. Abbiamo acquisito slot a un costo mensile fisso anziché pagare per TB di dati elaborati. Questa soluzione è stata anche basata sui feedback degli utenti, che non volevano preoccuparsi dei costi prima di eseguire ogni richiesta.
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 di BigQuery. . Stiamo lavorando alla connessione di Scalding con i set di dati di BigQuery, che eliminerà la necessità di archiviare i set di dati sia in GCS che in BigQuery.
Per i casi rari che richiedevano richieste infrequenti per decine di petabyte, abbiamo deciso che l'archiviazione dei set di dati in BigQuery non fosse economicamente sostenibile e abbiamo usato Presto per accedere direttamente ai set di dati in GCS. A questo proposito stiamo esaminando le BigQuery External Data Sources.
Prossimi passi
Abbiamo notato un grande interesse per BigQuery sin dal rilascio della sua versione alpha. Stiamo aggiungendo più set di dati e più team a BigQuery. Stiamo sviluppando connettori per strumenti di analisi dei dati, come Scalding, per leggere e scrivere nel magazzino di BigQuery. Stiamo considerando strumenti come Looker e Apache Zeppelin per creare report aziendali sulla qualità e annotazioni utilizzando i set di dati di BigQuery.
La collaborazione con Google è stata molto produttiva e siamo felici di continuare e sviluppare questo partenariato. Abbiamo lavorato con Google per implementare il nostro , per inviare direttamente richieste a Google. Alcune di esse, come il caricatore BigQuery Parquet, sono già state realizzate da Google.
Ecco alcune delle nostre richieste di funzionalità ad alta priorità per Google:
- Strumenti per l'importazione semplice dei dati e supporto per il formato LZO-Thrift.
- Segmentazione oraria
- Miglioramenti nella gestione degli accessi, come permessi 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
Democratizzare l'analisi dei dati, la visualizzazione e l'apprendimento automatico in modo sicuro è la massima priorità per il team Data Platform. Abbiamo identificato Google BigQuery e Data Studio come strumenti in grado di aiutarci a raggiungere questo obiettivo e abbiamo lanciato l'Alpha di BigQuery per l'intera azienda lo scorso anno.
Abbiamo riscontrato che le query in BigQuery erano semplici ed efficienti. Per ricevere e trasformare i dati abbiamo utilizzato strumenti Google per pipeline semplici, ma per pipeline più complesse abbiamo dovuto costruire la nostra infrastruttura Airflow. Nel campo della gestione dei dati, i servizi di BigQuery per autenticazione, autorizzazione e auditing soddisfano le nostre esigenze. Per la gestione dei metadati e la conformità alla privacy ci serviva maggiore flessibilità e abbiamo dovuto creare i nostri sistemi. BigQuery, essendo un servizio gestito, è stato semplice da utilizzare. I costi delle query erano simili a quelli degli strumenti esistenti. Lo storage dei dati in BigQuery ha comportato costi aggiuntivi oltre 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 più set di dati, coinvolgere più team e creare più pipeline con BigQuery. Twitter utilizza diversi dati, per i quali sarà necessaria una combinazione di strumenti come Scalding, Spark, Presto e Druid. Abbiamo intenzione di continuare a potenziare i nostri strumenti di analisi dei dati e fornire indicazioni chiare ai nostri utenti su come sfruttare al meglio le nostre offerte.
Parole di ringraziamento
Vorrei ringraziare i miei coautori e colleghi di squadra, Anju Jha e Will Pascucci, per la loro straordinaria collaborazione e il duro lavoro su questo progetto. Vorrei anche ringraziare ingegneri e manager di diversi team di Twitter e Google che ci hanno supportato e agli utenti di BigQuery su Twitter, fornendo preziosi feedback.
Se sei interessato a lavorare su queste sfide, dai un'occhiata alle nostre nel team Data Platform.
Fonte: habr.com
