Ciao, Habr! Al momento è aperto un nuovo corso in OTUS. . In vista dell'inizio del corso, abbiamo tradizionalmente preparato per voi una selezione di materiale interessante.
Ogni giorno oltre cento milioni di persone visitano Twitter per scoprire cosa sta succedendo nel mondo e discuterne. Ogni tweet e ogni altra azione degli utenti generano eventi disponibili per l'analisi interna dei dati su Twitter. Centinaia di dipendenti analizzano e visualizzano questi dati, e migliorare la loro esperienza è la massima priorità del team Twitter Data Platform.
Riteniamo che gli utenti con una vasta gamma di competenze tecniche debbano avere la possibilità di trovare dati e accedere a strumenti di analisi e visualizzazione ben funzionanti basati su SQL. Questo consentirebbe a un nuovo gruppo di utenti con minori inclinazioni tecniche, inclusi analisti di dati e product manager, di estrarre informazioni dai dati, permettendo loro di comprendere e utilizzare meglio le opportunità offerte da Twitter. In questo modo democratizziamo l'analisi dei dati su Twitter.
Con il miglioramento dei nostri strumenti e delle capacità di analisi interna dei dati, abbiamo assistito a un miglioramento del servizio Twitter. Tuttavia, c'è ancora spazio per crescere. Gli attuali strumenti, come Scalding, richiedono competenze di programmazione. Gli strumenti di analisi basati su SQL, come Presto e Vertica, presentano problemi di performance su larga scala. Abbiamo anche la questione della distribuzione dei dati su più sistemi senza un accesso costante a essi.
Lo scorso anno abbiamo annunciato , attraverso la quale trasferiamo parti della nostra sulla Google Cloud Platform (GCP). Abbiamo concluso che gli strumenti di Google Cloud possono aiutarci nelle nostre iniziative per democratizzare l'analisi, la visualizzazione e il machine learning su Twitter:
- : un repository di dati aziendali con un motore SQL basato su , noto per la sua velocità, facilità d'uso e capace di gestire .
- uno strumento per la visualizzazione di grandi dati con funzioni di collaborazione, come in Google Docs.
In questo articolo scoprirai la nostra esperienza con questi strumenti: cosa abbiamo fatto, cosa abbiamo imparato e cosa faremo in futuro. Al momento ci concentreremo sull'analisi batch e interattiva. L'analisi in tempo reale la discuteremo nel prossimo articolo.
La storia dei data warehouse su Twitter
Prima di approfondire BigQuery, vale la pena riassumere brevemente la storia dei data warehouse su Twitter. Nel 2011, l'analisi dei dati su Twitter veniva effettuata in Vertica e Hadoop. Per creare MapReduce utilizzavamo Hadoop con Pig. Nel 2012 abbiamo sostituito Pig con Scalding, che aveva un'API Scala con vantaggi come la possibilità di costruire pipeline complesse e la facilità di testing. Tuttavia, per molti analisti di dati e product manager, che si sentivano più a loro agio a lavorare con SQL, questa 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 buona scelta per ricerche ad hoc e machine learning.
A partire dal 2018 abbiamo utilizzato i seguenti strumenti per l'analisi e la visualizzazione dei dati:
- Scalding per i conveyor di produzione
- Scalding e Spark per analisi dati ad hoc e machine learning
- Vertica e Presto per SQL ad hoc e analisi interattiva
- Druid per accesso interattivo, esplorativo e 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'accesso a queste funzionalità per un pubblico più ampio su Twitter. Espandendo la nostra piattaforma con Google Cloud, ci concentriamo sul semplificare i nostri strumenti analitici per tutto Twitter.
Data Warehouse BigQuery di Google
Alcuni team su Twitter hanno già integrato BigQuery in parte dei loro pipeline produttivi. Sfruttando la loro esperienza, abbiamo iniziato a valutare le potenzialità 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 del set di strumenti della Data Platform. Questo si è rivelato difficile per vari motivi. Era necessario sviluppare un'infrastruttura in grado di gestire in modo affidabile grandi volumi di dati, supportare la gestione dei dati su scala aziendale, garantire il controllo degli accessi adeguato e proteggere la riservatezza dei clienti. Abbiamo anche dovuto creare sistemi per la distribuzione delle risorse, il monitoraggio e il rimborso per consentire ai team di utilizzare BigQuery in modo efficace.
Nel novembre 2018, abbiamo rilasciato la versione alpha di BigQuery e Data Studio per tutta l'azienda. Abbiamo offerto ai dipendenti di Twitter alcune delle nostre tabelle più utilizzate con dati personali depurati. Oltre 250 utenti di vari team, compresi ingegneria, finanza e marketing, hanno utilizzato BigQuery. Recentemente, hanno eseguito circa 8.000 query, elaborando circa 100 PB al mese, escluse le query programmate. Ricevuti feedback molto positivi, abbiamo deciso di andare avanti e proporre BigQuery come risorsa principale per l'interazione con i dati in Twitter.
Ecco uno 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. Successivamente, utilizziamo Apache Airflow per creare pipeline che usano «» per caricare i dati da GCS in BigQuery. Utilizziamo 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 seguenti capitoli discuteremo il nostro approccio e la nostra expertise in materia di facilità d'uso, prestazioni, gestione dei dati, operatività del sistema e costi.
Semplicità 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 familiarizzassero con alcune funzionalità di GCP e le sue concezioni, inclusi elementi come progetti, set di dati e tabelle. Abbiamo creato materiali didattici e tutorial per aiutare gli utenti a iniziare. Con una comprensione di base, agli utenti è stato facile navigare tra i set di dati, visualizzare lo schema 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 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 con Google Data Transfer Service (DTS) per organizzare i carichi di lavoro di BigQuery. Sebbene DTS fosse veloce da configurare, non era flessibile per costruire pipeline con dipendenze. Per la nostra versione alfa, abbiamo creato il nostro ambiente Apache Airflow in GCE e lo stiamo preparando per il lavoro in produzione e per supportare più fonti di dati, come Vertica.
Per trasformare i dati in BigQuery, gli utenti creano semplici pipeline di dati SQL utilizzando query programmate. Per pipeline complesse a più fasi con dipendenze, abbiamo in programma di utilizzare o la nostra infrastruttura Airflow oppure Cloud Composer insieme a .
Prestazioni
BigQuery è progettato per query SQL generiche che elaborano grandi volumi di dati. Non è destinato a query a bassa latenza ad alta capacità, necessarie per database transazionali, né per l'analisi delle serie temporali a bassa latenza. . Per le query analitiche interattive, i nostri utenti si aspettano tempi di risposta inferiori a un minuto. Abbiamo dovuto progettare l'uso di BigQuery in modo da soddisfare queste aspettative. Per garantire prestazioni prevedibili per i nostri utenti, abbiamo utilizzato le funzionalità di BigQuery disponibili per i clienti a pagamento fisso, che consentono ai proprietari dei progetti di riservare slot minimi per le loro query. BigQuery è un'unità di potenza di calcolo necessaria per eseguire query SQL.
Abbiamo analizzato oltre 800 richieste che gestiscono circa 1 TB di dati ciascuna, e abbiamo scoperto che il tempo medio di esecuzione è stato di 30 secondi. Abbiamo anche appreso che le prestazioni dipendono fortemente dall'uso della nostra prenotazione in diversi progetti e compiti. Abbiamo dovuto distinguere chiaramente le nostre riserve di slot produttivi e ad hoc per mantenere le prestazioni nei casi d'uso produttivi e nell'analisi interattiva. Questo ha avuto un forte impatto sul nostro design per la prenotazione degli slot e la gerarchia dei progetti.
Parleremo della gestione dei dati, delle funzionalità e dei costi dei sistemi nei prossimi giorni nella seconda parte della traduzione, ma ora invitiamo tutti gli interessati a , durante il quale sarà possibile scoprire in dettaglio il corso e porre domande al nostro esperto — Yegor Mateshchuk (Senior Data Engineer, MaximaTelecom).
Leggi di più:
Fonte: habr.com
