Ciao, Habr! Al momento in OTUS è aperto il reclutamento per un nuovo ciclo del corso . In vista dell'inizio del corso, abbiamo tradizionalmente preparato per voi la traduzione di un materiale interessante.
Ogni giorno oltre cento milioni di persone visitano Twitter per scoprire cosa sta accadendo nel mondo e discuterne. Ogni tweet e ogni altra azione dell'utente generano un evento, disponibile per l'analisi interna dei dati su Twitter. Centinaia di dipendenti analizzano e visualizzano questi dati, e migliorare la loro esperienza è la priorità principale per il team della Twitter Data Platform.
Riteniamo che gli utenti con una vasta gamma di competenze tecniche debbano avere la possibilità di trovare dati e avere accesso a strumenti di analisi e visualizzazione basati su SQL che funzionano bene. Questo consentirebbe a un nuovo gruppo di utenti con meno inclinazione tecnica, inclusi data analyst e product manager, di estrarre informazioni dai dati, permettendo loro di comprendere e utilizzare meglio le opportunità di Twitter. Così democratizziamo l'analisi dei dati in Twitter.
Con il miglioramento dei nostri strumenti e delle capacità per l'analisi interna dei dati, abbiamo assistito a un miglioramento del servizio Twitter. Tuttavia, c'è ancora molto da fare. Gli strumenti attuali, come Scalding, richiedono competenze di programmazione. Gli strumenti di analisi basati su SQL, come Presto e Vertica, hanno problemi di prestazioni su larga scala. Abbiamo anche il problema della distribuzione dei dati su più sistemi senza un accesso continuo ad essi.
Lo scorso anno abbiamo annunciato , nell'ambito della quale stiamo trasferendo parti della nostra sulla Google Cloud Platform (GCP). Abbiamo concluso che gli strumenti Google Cloud possono aiutarci nelle nostre iniziative per democratizzare l'analisi, la visualizzazione e l'apprendimento automatico in Twitter:
- : un archivio di dati aziendali con un motore SQL basato su , noto per la sua velocità, semplicità e capacità di gestire .
- uno strumento per la visualizzazione di big data con funzionalità di collaborazione, proprio come in Google Docs.
In questo articolo scoprirete la nostra esperienza con questi strumenti: cosa abbiamo fatto, cosa abbiamo imparato e cosa faremo in seguito. Ora ci concentreremo sull'analisi batch e interattiva. L'analisi in tempo reale la discuteremo nel prossimo articolo.
Storia dei data warehouse in Twitter
Prima di approfondire BigQuery, è opportuno riassumere brevemente la storia dei data warehouse in Twitter. Nel 2011, l'analisi dei dati in Twitter veniva effettuata in Vertica e Hadoop. Per creare il MapReduce di Hadoop, abbiamo utilizzato Pig. Nel 2012 abbiamo sostituito Pig con Scalding, che aveva un'API Scala con vantaggi come la possibilità di costruire pipeline complesse e facilità di test. Tuttavia, per molti data analyst e product manager, che si sentivano più a loro agio con SQL, c'era una curva di apprendimento piuttosto ripida. Circa nel 2016 abbiamo iniziato a utilizzare Presto come interfaccia SQL per i dati Hadoop. Spark offriva un'interfaccia Python, che lo rendeva una scelta eccellente per ricerche dati ad hoc e machine learning.
A partire dal 2018, abbiamo utilizzato i seguenti strumenti per l'analisi e la visualizzazione dei dati:
- Scalding per pipeline produttive
- Scalding e Spark per analisi dati ad hoc e machine learning
- Vertica e Presto per analisi SQL ad hoc e interattiva
- Druid per interattività ridotta, ricerca e accesso a bassa latenza a metriche di serie temporali
- Tableau, Zeppelin e Pivot per la visualizzazione dei dati
Abbiamo scoperto che, sebbene questi strumenti offrano funzionalità molto potenti, abbiamo riscontrato difficoltà nell'implementare l'accessibilità di queste funzionalità a un pubblico più ampio in Twitter. Espandendo la nostra piattaforma con Google Cloud, ci concentriamo sul semplificare i nostri strumenti analitici per tutto Twitter.
Il data warehouse BigQuery di Google
Diversi team su Twitter hanno già integrato BigQuery in alcuni dei loro flussi di lavoro produttivi. Utilizzando la loro esperienza, abbiamo iniziato a valutare le possibilità di BigQuery per tutti gli scenari di utilizzo di Twitter. Il nostro obiettivo era quello di offrire BigQuery all'intera azienda, oltre a standardizzarlo e supportarlo all'interno dell'insieme di strumenti della Data Platform. Questo si è rivelato difficile per molte ragioni. Era necessario sviluppare un'infrastruttura per ricevere in modo affidabile grandi quantità di dati, supportare la gestione dei dati su scala aziendale, garantire un adeguato controllo degli accessi e tutelare la riservatezza dei clienti. Abbiamo anche dovuto creare sistemi per la distribuzione delle risorse, il monitoraggio e la gestione dei pagamenti, affinché i team potessero utilizzare BigQuery in modo efficace.
Nel novembre 2018 abbiamo rilasciato una versione alpha di BigQuery e Data Studio per l'intera azienda. Abbiamo offerto ai dipendenti di Twitter alcune delle nostre tabelle più utilizzate contenenti dati personali anonimizzati. Più di 250 utenti provenienti da vari team, tra cui ingegneria, finanza e marketing, hanno utilizzato BigQuery. Recentemente, hanno eseguito circa 8.000 query, elaborando circa 100 PB al mese, senza contare le query pianificate. Ricevendo feedback molto positivi, abbiamo deciso di andare avanti e offrire BigQuery come risorsa principale per l'interazione con i dati su Twitter.
Ecco lo schema dell'architettura ad alto livello del nostro data warehouse Google BigQuery.
Copiamo i dati dai cluster Hadoop locali in Google Cloud Storage (GCS), utilizzando uno strumento interno chiamato Cloud Replicator. Poi utilizziamo Apache Airflow per creare pipeline che utilizzano «» per caricare i dati da GCS in BigQuery. Usiamo Presto per interrogare i set di dati Parquet o Thrift-LZO in GCS. BQ Blaster è uno strumento interno di Scalding per caricare set di dati HDFS Vertica e Thrift-LZO in BigQuery.
Nei prossimi capitoli discuteremo del nostro approccio e delle nostre conoscenze in merito a facilità d'uso, prestazioni, gestione dei dati, operatività del sistema e costi.
Facilità d'uso
Abbiamo scoperto che gli utenti trovavano facile iniziare con BigQuery, poiché non richiedeva l'installazione di software e gli utenti potevano accedervi tramite un'interfaccia web intuitiva. Tuttavia, era necessario che gli utenti si familiarizzassero con alcune funzionalità di GCP e le sue concettualizzazioni, inclusi risorse come progetti, set di dati e tabelle. Abbiamo sviluppato materiali formativi e tutorial per aiutare gli utenti a iniziare. Con una comprensione di base acquisita, agli utenti è diventato facile navigare tra i set di dati, visualizzare la struttura e i dati delle tabelle, eseguire query semplici e visualizzare i risultati in Data Studio.
Il nostro obiettivo riguardo l'immissione dei dati in BigQuery era garantire un caricamento fluido dei set di dati HDFS o GCS con un clic del mouse. Abbiamo considerato (gestito da Airflow), ma non siamo riusciti a utilizzarlo a causa del nostro modello di sicurezza “Domain Restricted Sharing” (maggiori dettagli nella sezione “Gestione dei dati” qui sotto). Abbiamo sperimentato l'uso del Google Data Transfer Service (DTS) per organizzare i carichi di lavoro per BigQuery. Sebbene DTS si configurasse rapidamente, non era flessibile per costruire pipeline con dipendenze. Per la nostra versione alpha, abbiamo creato un nostro ambiente Apache Airflow in GCE e lo stiamo preparando per il lavoro in produzione e per la possibilità di supportare più fonti di dati, come Vertica.
Per la trasformazione dei dati in BigQuery, gli utenti creano semplici pipeline di dati SQL utilizzando query pianificate. Per pipeline complesse multi-step con dipendenze, abbiamo in programma di utilizzare la nostra infrastruttura Airflow o Cloud Composer insieme a .
Prestazioni
BigQuery è progettato per query SQL generiche che elaborano grandi volumi di dati. Non è adatto per query a bassa latenza e ad alta capacità necessarie per un database transazionale, né per l'analisi di serie temporali a bassa latenza realizzata . Per le richieste analitiche interattive, i nostri utenti si aspettano un tempo di risposta inferiore a un minuto. Abbiamo dovuto progettare l'uso di BigQuery in modo da soddisfare queste aspettative. Per garantire prestazioni prevedibili ai nostri utenti, abbiamo utilizzato la funzionalità di BigQuery disponibile per i clienti a pagamento fisso, che consente ai proprietari dei progetti di riservare slot minimi per le loro richieste. BigQuery è un'unità di potenza di calcolo necessaria per eseguire richieste SQL.
Abbiamo analizzato oltre 800 richieste che elaborano circa 1 TB di dati ciascuna e abbiamo scoperto che il tempo medio di esecuzione è stato di 30 secondi. Abbiamo anche scoperto che le prestazioni dipendono molto dall'uso dei nostri slot in diversi progetti e compiti. Dovevamo chiaramente separare le nostre riserve di slot produttive e ad hoc per mantenere prestazioni per scenari di utilizzo produttivi e analisi interattive. Questo ha avuto un grande impatto sul nostro design per la riserva di slot e la gerarchia dei progetti.
Parleremo della gestione dei dati, della funzionalità e dei costi dei sistemi nei prossimi giorni nella seconda parte della traduzione, e ora invitiamo tutti gli interessati a , durante il quale sarà possibile conoscere in dettaglio il corso e porre domande al nostro esperto — Egor Mateshchuk (Senior Data Engineer, MaximaTelecom).
Leggi anche:
Fonte: habr.com
