Ciao, Habr! Le iscrizioni per un nuovo flusso di corsi sono aperte proprio ora su OTUS . In previsione dell'inizio del corso, tradizionalmente prepariamo per voi la traduzione di materiale interessante.
Ogni giorno più di cento milioni di persone visitano Twitter per scoprire cosa succede nel mondo e discuterne. Ogni tweet e ogni altra azione dell'utente genera un evento disponibile per l'analisi dei dati interni di Twitter. Centinaia di dipendenti analizzano e visualizzano questi dati e migliorare la loro esperienza è una priorità assoluta per il team di Twitter Data Platform.
Riteniamo che gli utenti con un'ampia gamma di competenze tecniche debbano essere in grado di scoprire dati e avere accesso a strumenti di analisi e visualizzazione basati su SQL efficienti. Ciò consentirebbe a un gruppo completamente nuovo di utenti meno tecnici, inclusi analisti di dati e product manager, di estrarre approfondimenti dai dati, consentendo loro di comprendere e utilizzare meglio le capacità di Twitter. Ecco come democratizziamo l'analisi dei dati su Twitter.
Man mano che i nostri strumenti e le capacità di analisi dei dati interni sono migliorati, abbiamo visto Twitter migliorare. Tuttavia, c’è ancora spazio per miglioramenti. Gli strumenti attuali come Scalding richiedono esperienza di programmazione. Gli strumenti di analisi basati su SQL come Presto e Vertica presentano problemi di prestazioni su larga scala. Abbiamo anche il problema della distribuzione dei dati su più sistemi senza un accesso costante ad essi.
L'anno scorso abbiamo annunciato , all'interno del quale trasferiamo parti del ns su Google Cloud Platform (GCP). Abbiamo concluso che gli strumenti Google Cloud può aiutarci con le nostre iniziative per democratizzare l'analisi, la visualizzazione e l'apprendimento automatico su Twitter:
- : data warehouse aziendale basato su motore SQL , che è famoso per la sua velocità, semplicità e capacità di affrontare .
- strumento di visualizzazione di big data con funzionalità di collaborazione simili a Google Docs.
In questo articolo imparerai la nostra esperienza con questi strumenti: cosa abbiamo fatto, cosa abbiamo imparato e cosa faremo dopo. Ci concentreremo ora sull'analisi batch e interattiva. Discuteremo dell'analisi in tempo reale nel prossimo articolo.
Storia degli archivi dati di Twitter
Prima di approfondire BigQuery, vale la pena raccontare brevemente la storia del data warehousing di Twitter. Nel 2011, l'analisi dei dati di Twitter è stata eseguita in Vertica e Hadoop. Abbiamo utilizzato Pig per creare lavori MapReduce Hadoop. Nel 2012 abbiamo sostituito Pig con Scalding, che disponeva di un'API Scala con vantaggi quali la possibilità di creare pipeline complesse e facilità di test. Tuttavia, per molti analisti di dati e product manager che si sentivano più a loro agio nel lavorare con SQL, la curva di apprendimento era piuttosto ripida. Intorno al 2016 abbiamo iniziato a utilizzare Presto come interfaccia SQL per i dati Hadoop. Spark ha offerto un'interfaccia Python, che lo rende una buona scelta per la scienza dei dati ad hoc e l'apprendimento automatico.
Dal 2018 utilizziamo i seguenti strumenti per l'analisi e la visualizzazione dei dati:
- Scottatura per trasportatori di produzione
- Scalding e Spark per analisi dati ad hoc e machine learning
- Vertica e Presto per analisi SQL ad hoc e interattive
- Druid per un accesso interattivo, esplorativo e a bassa latenza alle metriche delle serie temporali
- Tableau, Zeppelin e Pivot per la visualizzazione dei dati
Abbiamo scoperto che, sebbene questi strumenti offrano funzionalità molto potenti, abbiamo avuto difficoltà a renderle disponibili a un pubblico più ampio su Twitter. Espandendo la nostra piattaforma con Google Cloud, ci stiamo concentrando sulla semplificazione dei nostri strumenti di analisi per tutto Twitter.
Il data warehouse BigQuery di Google
Diversi team di Twitter hanno già incorporato BigQuery in alcune delle loro pipeline di produzione. Utilizzando la loro esperienza, abbiamo iniziato a valutare le capacità di BigQuery per tutti i casi d'uso di Twitter. Il nostro obiettivo era offrire BigQuery all'intera azienda e standardizzarlo e supportarlo all'interno del set di strumenti della piattaforma dati. Questo è stato difficile per molte ragioni. Avevamo bisogno di sviluppare un'infrastruttura per acquisire in modo affidabile grandi volumi di dati, supportare la gestione dei dati a livello aziendale, garantire controlli di accesso adeguati e garantire la privacy dei clienti. Abbiamo anche dovuto creare sistemi per l'allocazione delle risorse, il monitoraggio e i riaddebiti in modo che i team potessero utilizzare BigQuery in modo efficace.
Nel novembre 2018 abbiamo rilasciato una versione alpha di BigQuery e Data Studio a livello aziendale. Abbiamo offerto ai dipendenti di Twitter alcuni dei nostri fogli di calcolo utilizzati più di frequente con dati personali ripuliti. BigQuery è stato utilizzato da oltre 250 utenti appartenenti a diversi team, tra cui ingegneria, finanza e marketing. Più recentemente, hanno eseguito circa 8 richieste, elaborando circa 100 PB al mese, senza contare le richieste pianificate. Dopo aver ricevuto feedback molto positivi, abbiamo deciso di andare avanti e offrire BigQuery come risorsa principale per interagire con i dati su Twitter.
Ecco un diagramma di alto livello della nostra architettura di data warehouse di Google BigQuery.
Copiamo i dati dai cluster Hadoop on-premise a Google Cloud Storage (GCS) utilizzando lo strumento Cloud Replicator interno. Utilizziamo quindi 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 Scalding interno per caricare set di dati HDFS Vertica e Thrift-LZO in BigQuery.
Nelle sezioni seguenti, discutiamo il nostro approccio e la nostra competenza nelle aree di facilità d'uso, prestazioni, gestione dei dati, integrità del sistema e costi.
Facilità d'uso
Abbiamo scoperto che è stato facile per gli utenti iniziare a utilizzare BigQuery perché non richiedeva l'installazione di software e gli utenti potevano accedervi tramite un'interfaccia web intuitiva. Tuttavia, gli utenti dovevano acquisire familiarità con alcune funzionalità e concetti di GCP, comprese risorse come progetti, set di dati e tabelle. Abbiamo sviluppato materiali didattici e tutorial per aiutare gli utenti a iniziare. Una volta acquisita una conoscenza di base, gli utenti hanno trovato facile esplorare set di dati, visualizzare dati di schemi e tabelle, eseguire query semplici e visualizzare risultati in Data Studio.
Il nostro obiettivo per l'immissione dei dati in BigQuery era consentire il caricamento continuo di set di dati HDFS o GCS con un clic. Abbiamo considerato (gestito da Airflow) ma non siamo riusciti a utilizzarlo a causa del nostro modello di sicurezza di condivisione limitata del dominio (maggiori informazioni su questo argomento nella sezione Gestione dei dati di seguito). Abbiamo sperimentato l'utilizzo di Google Data Transfer Service (DTS) per orchestrare i carichi di lavoro BigQuery. Sebbene DTS fosse rapido da configurare, non era flessibile per la creazione di pipeline con dipendenze. Per la nostra versione alpha, abbiamo creato il nostro framework Apache Airflow in GCE e lo stiamo preparando per essere eseguito in produzione ed essere in grado di supportare più origini dati come Vertica.
Per trasformare i dati in BigQuery, gli utenti creano semplici pipeline di dati SQL utilizzando query pianificate. Per pipeline complesse a più fasi con dipendenze, prevediamo di utilizzare il nostro framework Airflow o Cloud Composer insieme a .
Производительность
BigQuery è progettato per query SQL generiche che elaborano grandi quantità di dati. Non è destinato alle query a bassa latenza e ad alto throughput richieste da un database transazionale o all'analisi di serie temporali a bassa latenza implementata . Per le query di analisi interattive, i nostri utenti si aspettano tempi di risposta inferiori a un minuto. Abbiamo dovuto progettare il nostro utilizzo di BigQuery per soddisfare queste aspettative. Per fornire prestazioni prevedibili ai nostri utenti, abbiamo sfruttato la funzionalità BigQuery, disponibile per i clienti a tariffa fissa che consente ai proprietari dei progetti di riservare spazi minimi per le loro query. BigQuery è un'unità di potenza di calcolo necessaria per eseguire query SQL.
Abbiamo analizzato oltre 800 query che elaboravano circa 1 TB di dati ciascuna e abbiamo scoperto che il tempo di esecuzione medio era di 30 secondi. Abbiamo anche appreso che le prestazioni dipendono fortemente dall'utilizzo del nostro slot in diversi progetti e attività. Abbiamo dovuto delineare chiaramente la nostra produzione e le riserve di slot ad hoc per mantenere le prestazioni per i casi d'uso di produzione e l'analisi online. Ciò ha influenzato notevolmente la nostra progettazione per le prenotazioni degli slot e la gerarchia dei progetti.
Di gestione dei dati, funzionalità e costo dei sistemi parleremo nei prossimi giorni nella seconda parte della traduzione, ma ora invitiamo tutti a , durante il quale potrai conoscere in dettaglio il corso e porre domande al nostro esperto: Egor Mateshuk (Senior Data Engineer, MaximaTelecom).
Per saperne di più:
Fonte: habr.com