Negli ultimi anni, ho avuto molte conversazioni con amici e colleghi frustrati da quanto sia imperscrutabilmente complesso l’ecosistema dell’infrastruttura dati. Anche se non così male come il mondo front-end, le cose stanno cambiando abbastanza velocemente per creare una zuppa parola d’ordine.

Come principiante, è super impegnativo decidere quali strumenti sono giusti per te. La Apache Foundation elenca 38 progetti nella sezione “Big Data” e questi strumenti hanno tonnellate di sovrapposizione sui problemi che affermano di affrontare. Ad esempio, Flink, Samza, Storm e Spark Streaming sono “distributed stream processing engine”, Apex e Beam “unify stream and batch processing”.

In questo post, spero di fornire qualche aiuto nella navigazione delle opzioni mentre si imposta per costruire l’infrastruttura dati. Questi sono approssimativamente i passi che seguirei oggi, sulla base delle mie esperienze nell’ultimo decennio e delle conversazioni con i colleghi che lavorano in questo spazio.

All’inizio del tuo progetto, probabilmente stai partendo con nient’altro che un obiettivo di “ottenere informazioni dai miei dati” in mano. Mappare questo a un set specifico di tecnologie è estremamente scoraggiante. Probabilmente non hai un grande senso per quali strumenti sono popolari, cosa significa “stream” o “batch” o se hai addirittura bisogno di un’infrastruttura di dati.

In questo post, spero di fornire alcune indicazioni per aiutarti a decollare rapidamente ed estrarre valore dai tuoi dati. Credo fermamente nel mantenere le cose semplici il più a lungo possibile, introducendo la complessità solo quando è necessaria per la scalabilità. Questo post segue quell’arco attraverso tre fasi. In molti modi, ripercorre le fasi di costruzione di infrastrutture di dati che ho seguito nel corso degli ultimi anni.

Si noti che non esiste un modo giusto per progettare l’infrastruttura dati. Per gli esperti che leggono questo, potresti aver preferito alternative alle soluzioni suggerite qui. E ‘ fantastico, e mette in evidenza la diversità di strumenti sorprendenti che abbiamo in questi giorni. Abbiamo fatto molta strada da quando Hadoop MapReduce era tutto quello che avevamo.

Quindi ecco la cosa: probabilmente non hai ancora “big data”. Quasi 4 anni dopo, l’articolo di Chris Stucchio del 2013 Non usare Hadoop è ancora sul punto. Se si dispone di meno di 5 TB di dati, iniziare in piccolo. Questo ti farà risparmiare mal di testa operativi con sistemi di manutenzione che non ti servono ancora. Ma hey, se ami le esercitazioni antincendio 3am da fallimenti di lavoro, sentiti libero di saltare questa sezione Otherwise

Altrimenti, stai lontano da tutte le tecnologie di buzzword all’inizio e concentrati su due cose: (1) rendere i tuoi dati interrogabili in SQL e (2) scegliere uno strumento di BI. Questi saranno la spina dorsale “Ciao, Mondo” per tutta la tua futura infrastruttura dati.

Tutto in SQL

Questo è davvero importante, perché sblocca i dati per l’intera organizzazione. Con rare eccezioni per le persone di marketing più intrepide, non convincerai mai i tuoi colleghi non tecnici a imparare Kibana, a grep alcuni log o a usare l’oscura sintassi del tuo datastore NoSQL.

Fornire l’accesso SQL consente all’intera azienda di diventare analisti self-service, eliminando il team di progettazione già in fase avanzata dal percorso critico. Si trasforma anche tutti in un team di QA gratuito per i vostri dati. Il “hey, questi numeri sembrano un po ‘strano…” è inestimabile per trovare bug nei tuoi dati e persino nel tuo prodotto.

Se il tuo datastore primario è un database relazionale come PostgreSQL o MySQL, questo è davvero semplice. Puoi semplicemente impostare una replica di lettura, accedere al provisioning e tutto è pronto.

Con un database NoSQL come ElasticSearch, MongoDB o DynamoDB, dovrai fare più lavoro per convertire i tuoi dati e inserirli in un database SQL. Se sei nuovo nel mondo dei dati, lo chiamiamo una pipeline ETL. Evitare di costruire questo da soli, se possibile, come cablaggio su una soluzione off-the-shelf sarà molto meno costoso con piccoli volumi di dati. A seconda dell’infrastruttura esistente, potrebbe esserci un provider ETL cloud come il segmento che puoi sfruttare.

Se si scopre che è necessario creare le proprie pipeline di dati, mantenerle estremamente semplici all’inizio. Scrivi uno script per scaricare periodicamente gli aggiornamenti dal tuo database e scriverli da qualche parte interrogabile con SQL.

La storia dei dati ETLing da fonti di terze parti è simile a quella dei database NoSQL. Utilizzare un provider ETL-as-a-service o scrivere uno script semplice e basta depositare i dati in un database SQL-interrogabile.

Imposta una macchina per eseguire i tuoi script ETL come cron giornaliero e sei fuori per le gare.

Strumento di BI

Un buon strumento di BI è una parte importante della comprensione dei dati. Alcuni ottimi strumenti da considerare sono Chartio, Mode Analytics e Periscope Data: ognuno di questi dovrebbe funzionare alla grande per far decollare le tue analisi. Nella maggior parte dei casi, è possibile puntare questi strumenti direttamente al database SQL con una configurazione rapida e tuffarsi a destra nella creazione di dashboard.

Tirando tutto insieme, ecco il “Ciao, Mondo” dell’infrastruttura dati:

Stage 1: La piccola pipeline di dati” Hello, World “

Stage 2: Chiamiamola” media ” data

A questo punto, hai più di qualche terabyte in giro, e il tuo cron+script ETL non sta abbastanza al passo. Forse hai proliferato datastore e hai una miscela eterogenea di backend SQL e NoSQL. Si può anche ora avere una manciata di terze parti si sta raccogliendo dati da. Infine, potresti iniziare ad avere più fasi nelle pipeline ETL con alcune dipendenze tra i passaggi.

Gestione del flusso di lavoro& Automazione

Il primo passo in questa fase dovrebbe essere la creazione di Airflow per gestire le pipeline ETL. Airflow ti consentirà di pianificare i lavori a intervalli regolari ed esprimere sia le dipendenze temporali che logiche tra i lavori. È anche un ottimo posto nella tua infrastruttura per aggiungere tentativi di lavoro, monitorando & avvisi per errori di attività. È uno scherzo in esecuzione che ogni avvio al di sopra di una certa dimensione scrive il proprio workflow manager / job scheduler. Tra gli altri, Spotify ha scritto Luigi, e Pinterest ha scritto Pinball. Tuttavia, questi hanno meno slancio nella comunità e mancano di alcune caratteristiche rispetto al flusso d’aria.

Costruzione di pipeline ETL

Man mano che la tua attività cresce, i requisiti della pipeline ETL cambieranno in modo significativo. Sarà necessario iniziare a costruire un’infrastruttura più scalabile perché un singolo script non lo taglierà più. È anche probabile che i tuoi obiettivi si espandano semplicemente abilitando l’accesso SQL per includere il supporto di altri lavori downstream che elaborano gli stessi dati.

alla fine, le pipeline semplici non scaleranno

Per soddisfare questi requisiti mutevoli, è necessario convertire gli script ETL in esecuzione come lavoro distribuito su un cluster. Il numero di possibili soluzioni qui è assolutamente schiacciante. Consiglierei vivamente di iniziare con Apache Spark. Spark ha un enorme, comunità molto attiva, scale bene, ed è abbastanza facile da ottenere rapidamente installato e funzionante. Su AWS, è possibile eseguire Spark utilizzando EMR; per GCP, utilizzando Cloud Dataproc. Se stai ingerendo dati da un database relazionale, Apache Sqoop è praticamente lo standard.

A questo punto, l’infrastruttura ETL inizierà a sembrare fasi pipeline di lavori che implementano i tre verbi ETL: estrarre i dati dalle origini, trasformare i dati in formati standardizzati su storage persistente e caricarli in un datastore interrogabile SQL.

Data Warehouse

In questa fase, ottenere tutti i dati in SQL rimarrà una priorità, ma questo è il momento in cui si vorrà iniziare a costruire un data warehouse “reale”.

Per quelli appena agli inizi, consiglierei di usare BigQuery. BigQuery è facile da configurare (puoi semplicemente caricare i record come JSON), supporta tipi di dati nidificati/complessi ed è completamente gestito/serverless in modo da non avere più infrastrutture da mantenere. Come per molte delle raccomandazioni qui, sono disponibili alternative a BigQuery: su AWS, Redshift e on-prem, Presto. Ho una forte preferenza per BigQuery rispetto a Redshift grazie al suo design serverless, alla semplicità di configurazione di sicurezza/controllo adeguati e al supporto per tipi complessi. Presto vale la pena considerare se si dispone di un requisito difficile per on-prem.

Quando si pensa di configurare il data warehouse, un modello conveniente consiste nell’adottare un modello a 2 stadi, in cui i dati non elaborati vengono scaricati direttamente in un set di tabelle e un secondo lavoro post-elabora questi dati in tabelle “più pulite”.

Considera queste tabelle più pulite come un’opportunità per creare una vista curata nella tua attività. Per ciascuna delle entità chiave della tua azienda, devi creare e curare una tabella con tutte le metriche/KPI e le dimensioni che usi frequentemente per analizzare quell’entità. Ad esempio, una tabella” utenti ” potrebbe contenere metriche come l’ora di registrazione, il numero di acquisti e dimensioni come la posizione geografica o il canale di acquisizione.

Alla fine di tutto questo, la tua infrastruttura dovrebbe essere simile a questa:

Fase 2: la pipeline di dati” media”

🚀 Fase 3: Andando grande

Con le giuste basi, un’ulteriore crescita non deve essere dolorosa. Spesso è possibile fare semplicemente lanciando hardware al problema della gestione di volumi di dati aumentati.

I problemi più impegnativi in questo periodo spesso non sono solo la scala grezza, ma i requisiti in espansione. Ad esempio, forse è necessario supportare i test A/B, addestrare i modelli di apprendimento automatico o trasformare i dati in un cluster ElasticSearch.

Alcune cose che potresti prendere in considerazione in questa fase:

  • Quasi in tempo reale: Probabilmente non avrai bisogno di una coda distribuita o di un’infrastruttura quasi in tempo reale fino a molto più tardi di quanto potresti pensare. Viene fornito con un sacco di complessità aggiunta per gestire tutte le possibili modalità di guasto, che non ne vale la pena nella fase iniziale. Una volta che il calcolo del ROI ha senso, prova Kafka o Cloud Pub/Sub.
  • Scalabilità: con un singolo cluster Spark monolitico, quasi certamente incontrerai problemi con la contesa delle risorse. Quando lo fai, i cluster Spark con ambito di lavoro completamente elastici meritano di essere esplorati.
  • Sicurezza & Controllo: Ad un certo punto potresti voler applicare controlli di accesso più granulari ai dati del data warehouse. Se si utilizza BigQuery, è possibile eseguire il provisioning dell’accesso al set di dati a Google Groups e gestire in modo programmatico tale accesso utilizzando Deployment Manager. BigQuery fornisce anche registri di controllo per comprendere le query degli utenti. Altri strumenti come Apache Knox e Apache Sentry sono disponibili per soluzioni di sicurezza on-prem.
  • Test A/B: per la costruzione di test A/B interni e la sperimentazione di supporto, purtroppo non ci sono molte soluzioni disponibili. Costruire una pipeline di lavori Spark che popolano le tabelle nel data warehouse è probabilmente la soluzione migliore.
  • Apprendimento automatico: per l’estrazione delle funzionalità, è possibile creare pipeline di dati aggiuntive in Spark. Per i modelli stessi, dovresti iniziare di nuovo in piccolo. Le tue funzionalità elaborate sono probabilmente abbastanza piccole da adattarsi a una macchina, quindi puoi addestrare i modelli usando scikit-learn o TensorFlow. Quando una macchina non è più sufficiente, è possibile utilizzare Spark MLlib o distributed TensorFlow.

Il futuro

È emozionante vedere quanto l’ecosistema dell’infrastruttura dati sia migliorato negli ultimi dieci anni. Abbiamo percorso una lunga strada da babysitting cluster Hadoop e ginnastica per costringere la nostra logica di elaborazione dei dati in mappe e riduce in Java imbarazzante. A quei tempi, costruire infrastrutture di dati sembrava cercare di costruire un grattacielo usando un martello giocattolo.

Oggi abbiamo una straordinaria varietà di strumenti. Spark ha chiaramente dominato come il jack-of-all-trades sostituzione di Hadoop MapReduce; lo stesso sta iniziando ad accadere con TensorFlow come piattaforma di apprendimento automatico. Con pochissime eccezioni, non è necessario costruire infrastrutture o strumenti da zero in-house in questi giorni, e probabilmente non è necessario gestire i server fisici. Il grattacielo è già lì, devi solo scegliere i colori della vernice.

il serverless futuro — sarà totalmente come questo

Guardando al futuro, mi aspetto infrastruttura di dati e strumenti di continuare a spostare verso interamente serverless piattaforme — DataBricks appena annunciato una tale offerta per la Scintilla. L’infrastruttura serverless consente un’elegante separazione delle preoccupazioni: i fornitori di cloud possono preoccuparsi dell’hardware, dei devops e degli strumenti, consentendo agli ingegneri di concentrarsi sui problemi che sono unici per (e allineati con) le loro attività. Il futuro è uno senza guasti hardware, freakout ZooKeeper, o problemi con la contesa risorsa filato, e questo è davvero cool.

Modifica: aggiunta di collegamenti ad alcuni post precedenti che ho scritto sull’infrastruttura dati di Thumbtack:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

lg