Ciao, Habr! Le iscrizioni per un nuovo flusso di corsi sono aperte proprio ora su OTUS . In attesa dell'inizio del corso, continuiamo a condividere con voi materiale utile.
Gestione dei dati
Una forte governance dei dati è un principio fondamentale di Twitter Engineering. Quando implementiamo BigQuery nella nostra piattaforma, ci concentriamo sul rilevamento dei dati, sul controllo degli accessi, sulla sicurezza e sulla privacy.
Per individuare e gestire i dati, abbiamo ampliato il nostro livello di accesso ai dati a ) per fornire strumenti sia per i dati on-premise che per quelli di Google Cloud, fornendo un'unica interfaccia e API per i nostri utenti. Come Google si sta muovendo verso la disponibilità generale, lo includeremo nei nostri progetti per fornire agli utenti funzionalità come la ricerca nelle colonne.
BigQuery semplifica la condivisione e l'accesso ai dati, ma dovevamo avere un certo controllo su questo aspetto per impedire l'esfiltrazione dei dati. Tra gli altri strumenti, abbiamo selezionato due funzioni:
- : funzionalità beta per impedire agli utenti di condividere set di dati BigQuery con utenti esterni a Twitter.
- : un controllo che impedisce l'esfiltrazione dei dati e richiede agli utenti di accedere a BigQuery da intervalli di indirizzi IP noti.
Abbiamo implementato i requisiti di autenticazione, autorizzazione e controllo (AAA) per la sicurezza come segue:
- Autenticazione: abbiamo utilizzato account utente GCP per richieste ad hoc e account di servizio per richieste di produzione.
- Autorizzazione: abbiamo richiesto che ogni set di dati avesse un account di servizio proprietario e un gruppo di lettori.
- Controllo: abbiamo esportato i log dello stackdriver BigQuery, che contenevano informazioni dettagliate sull'esecuzione delle query, in un set di dati BigQuery per una facile analisi.
Per garantire che i dati personali degli utenti Twitter vengano gestiti correttamente, dobbiamo registrare tutti i set di dati BigQuery, annotare i dati personali, mantenere un'archiviazione adeguata ed eliminare (scraping) i dati che sono stati eliminati dagli utenti.
Abbiamo guardato Google , che utilizza l'apprendimento automatico per classificare e modificare i dati sensibili, ma ha deciso di annotare manualmente il set di dati per ragioni di precisione. Prevediamo di utilizzare l'API Data Loss Prevention per aumentare l'annotazione personalizzata.
Noi di Twitter abbiamo creato quattro categorie di privacy per i set di dati in BigQuery, elencate qui in ordine decrescente di sensibilità:
- I set di dati altamente sensibili vengono resi disponibili in base alle necessità in base al principio del privilegio minimo. Ogni set di dati ha un gruppo separato di lettori e monitoreremo l'utilizzo da parte dei singoli account.
- I set di dati a media sensibilità (pseudonimi unidirezionali che utilizzano hashing salted) non contengono informazioni di identificazione personale (PII) e sono accessibili a un gruppo più ampio di dipendenti. Si tratta di un buon equilibrio tra preoccupazioni sulla privacy e utilità dei dati. Ciò consente ai dipendenti di eseguire attività di analisi, come calcolare il numero di utenti che hanno utilizzato una funzionalità, senza sapere chi sono gli utenti reali.
- Set di dati a bassa sensibilità con tutte le informazioni di identificazione dell'utente. Questo è un buon approccio dal punto di vista della privacy, ma non può essere utilizzato per l'analisi a livello di utente.
- I set di dati pubblici (rilasciati al di fuori di Twitter) sono disponibili per tutti i dipendenti di Twitter.
Per quanto riguarda la registrazione, abbiamo utilizzato attività pianificate per enumerare i set di dati BigQuery e registrarli con il livello di accesso ai dati (), archivio di metadati di Twitter. Gli utenti annoteranno i set di dati con informazioni sulla privacy e specificheranno anche un periodo di conservazione. Per quanto riguarda la pulizia valutiamo la resa ed il costo di due opzioni: 1. Pulire i set di dati in GCS utilizzando strumenti come Scalding e caricandoli in BigQuery; 2. Utilizzo delle istruzioni DML BigQuery. Probabilmente utilizzeremo una combinazione di entrambi i metodi per soddisfare i requisiti di gruppi e dati diversi.
Funzionalità del sistema
Poiché BigQuery è un servizio gestito, non è stato necessario coinvolgere il team SRE di Twitter nella gestione dei sistemi o nei compiti di desk. È stato facile fornire maggiore capacità sia per l'archiviazione che per l'elaborazione. Potremmo modificare la prenotazione degli slot creando un ticket con il supporto di Google. Abbiamo identificato le aree che potrebbero essere migliorate, come l'assegnazione degli slot self-service e i miglioramenti della dashboard per il monitoraggio, e abbiamo inviato tali richieste a Google.
costo
La nostra analisi preliminare ha mostrato che i costi delle query per BigQuery e Presto erano allo stesso livello. Abbiamo acquistato slot per prezzo per avere un costo mensile stabile invece del pagamento per TB di dati elaborati. Questa decisione si è basata anche sul feedback degli utenti che non hanno voluto pensare ai costi prima di effettuare ogni richiesta.
L'archiviazione dei dati in BigQuery ha comportato costi aggiuntivi rispetto ai costi 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 . Stiamo lavorando a una connessione Scalding ai set di dati BigQuery che eliminerà la necessità di archiviare set di dati sia in GCS che in BigQuery.
Per i rari casi che richiedevano query poco frequenti di decine di petabyte, abbiamo deciso che archiviare i set di dati in BigQuery non era conveniente e abbiamo utilizzato Presto per accedere direttamente ai set di dati in GCS. Per fare ciò, esaminiamo le origini dati esterne BigQuery.
Prossimi passi
Abbiamo riscontrato molto interesse per BigQuery sin dalla versione alpha. Stiamo aggiungendo più set di dati e più comandi a BigQuery. Sviluppiamo connettori per strumenti di analisi dei dati come Scalding per leggere e scrivere nello spazio di archiviazione BigQuery. Stiamo esaminando strumenti come Looker e Apache Zeppelin per creare report e note di qualità aziendale utilizzando set di dati BigQuery.
La nostra collaborazione con Google è stata molto produttiva e siamo lieti di continuare e sviluppare questa partnership. Abbiamo collaborato con Google per implementare il nostro per inviare query 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 una comoda ricezione dei dati e supporto per il formato LZO-Thrift.
- Segmentazione oraria
- Miglioramenti del controllo dell'accesso come autorizzazioni a livello di tabella, riga e colonna.
- BigQuery con integrazione Hive Metastore e supporto per il formato LZO-Thrift.
- Integrazione migliorata del catalogo dati nell'interfaccia utente di BigQuery
- Self-service per l'assegnazione e il monitoraggio degli slot.
conclusione
Democratizzare l'analisi dei dati, la visualizzazione e l'apprendimento automatico in modo sicuro è una priorità assoluta per il team di Data Platform. Abbiamo identificato Google BigQuery e Data Studio come strumenti che potrebbero contribuire a raggiungere questo obiettivo e lo scorso anno abbiamo rilasciato BigQuery Alpha a livello aziendale.
Abbiamo riscontrato che le query in BigQuery sono semplici ed efficienti. Abbiamo utilizzato gli strumenti di Google per importare e trasformare i dati per pipeline semplici, ma per pipeline complesse abbiamo dovuto creare il nostro framework Airflow. Nell'ambito della gestione dei dati, i servizi di BigQuery per l'autenticazione, l'autorizzazione e il controllo soddisfano le nostre esigenze. Per gestire i metadati e preservare la privacy, avevamo bisogno di maggiore flessibilità e abbiamo dovuto costruire i nostri sistemi. BigQuery, essendo un servizio gestito, era facile da usare. I costi delle query erano simili a quelli degli strumenti esistenti. L'archiviazione dei dati in BigQuery comporta costi aggiuntivi rispetto ai costi GCS.
Nel complesso, BigQuery funziona bene per l'analisi SQL generale. Stiamo riscontrando molto interesse per BigQuery e stiamo lavorando per migrare più set di dati, coinvolgere più team e creare più pipeline con BigQuery. Twitter utilizza una varietà di dati che richiederanno una combinazione di strumenti come Scalding, Spark, Presto e Druid. Intendiamo continuare a rafforzare i nostri strumenti di analisi dei dati e fornire indicazioni chiare ai nostri utenti su come utilizzare al meglio le nostre offerte.
Parole di gratitudine
Vorrei ringraziare i miei coautori e compagni di squadra, Anju Jha e Will Pascucci, per la loro grande collaborazione e il duro lavoro su questo progetto. Vorrei anche ringraziare gli ingegneri e i manager di diversi team di Twitter e Google che ci hanno aiutato e gli utenti BigQuery su Twitter che hanno fornito preziosi feedback.
Se sei interessato a lavorare su questi problemi, consulta il nostro nel team della piattaforma dati.
Fonte: habr.com