Una guida per ingegneri di dati agli archivi di dati non tradizionali

Ingegneria dei dati

Con l'ascesa dei big data e della scienza dei dati, molti ruoli ingegneristici vengono sfidati e ampliati. Un ruolo new age è l'ingegneria dei dati .

In origine, lo scopo dell'ingegneria dei dati era il caricamento di origini dati esterne e la progettazione di database (progettazione e sviluppo di pipeline per raccogliere, manipolare, archiviare e analizzare i dati).

Da allora è cresciuto per supportare il volume e la complessità dei big data. Quindi l'ingegneria dei dati ora racchiude un'ampia gamma di competenze, dalla scansione del Web, alla pulizia dei dati, al calcolo distribuito e all'archiviazione e recupero dei dati.

Per l'ingegneria dei dati e gli ingegneri dei dati, l'archiviazione e il recupero dei dati è la componente critica della pipeline insieme al modo in cui i dati possono essere utilizzati e analizzati.

Negli ultimi tempi sono emerse molte nuove e diverse tecnologie di archiviazione dei dati. Tuttavia, quale è più adatto e ha le funzionalità più appropriate per l'ingegneria dei dati?

La maggior parte degli ingegneri ha familiarità con i database SQL, come PostgreSQL, MSSQL e MySQL, che sono strutturati in tabelle di dati relazionali con archiviazione orientata alle righe.

Dato quanto sono onnipresenti questi database, non ne discuteremo oggi. Invece, esploriamo tre tipi di archivi di dati alternativi che stanno diventando sempre più popolari e che hanno introdotto approcci diversi alla gestione dei dati.

Nel contesto dell'ingegneria dei dati, queste tecnologie sono motori di ricerca, archivi di documenti e archivi a colonne.

• I motori di ricerca eccellono nelle query di testo. Rispetto alle corrispondenze di testo nei database SQL, come LIKE , i motori di ricerca offrono funzionalità di query più elevate e prestazioni migliori immediatamente.
• Gli archivi di documenti offrono una migliore adattabilità dello schema dei dati rispetto ai database tradizionali. Archiviando i dati come singoli oggetti documento, spesso rappresentati come JSON, non richiedono la predefinizione dello schema.
• I negozi a colonna sono specializzati in query a colonna singola e aggregazioni di valori. Le operazioni SQL, come SUM e AVG , sono notevolmente più veloci negli archivi a colonne, poiché i dati della stessa colonna vengono archiviati più vicini sul disco rigido.

In questo articolo esploriamo tutte e tre le tecnologie: Elasticsearch come motore di ricerca, MongoDB come archivio di documenti e Amazon Redshift come archivio a colonne.

Comprendendo l'archiviazione dei dati alternativa, possiamo scegliere quella più adatta per ogni situazione.

Per confrontare queste tecnologie, esamineremo il modo in cui indicizzano, shard e aggregano i dati.

Ogni strategia di indicizzazione dei dati migliora determinate query mentre ne ostacola altre.

Sapere quali query vengono utilizzate più spesso può influenzare quale archivio dati adottare.

Lo sharding, una metodologia mediante la quale i database dividono i propri dati in blocchi, determina come l'infrastruttura crescerà man mano che vengono inseriti più dati.

La scelta di uno che corrisponda al nostro piano di crescita e al nostro budget è fondamentale e questo vale per qualsiasi azienda di data science, indipendentemente dalle dimensioni.

Infine, ciascuna di queste tecnologie aggrega i propri dati in modo molto diverso.

Quando abbiamo a che fare con gigabyte e terabyte di dati, una strategia di aggregazione errata può limitare i tipi e le prestazioni dei report che possiamo generare.

In qualità di ingegneri dei dati, dobbiamo considerare tutti e tre gli aspetti quando valutiamo diversi archivi di dati.

Contendersi

Motore di ricerca: Elasticsearch

Elasticsearch ha rapidamente guadagnato popolarità tra i suoi colleghi per la sua scalabilità e facilità di integrazione. Basato su Apache Lucene, offre una potente funzionalità di indicizzazione e ricerca di testo pronta all'uso. Oltre alle tradizionali attività dei motori di ricerca, alla ricerca di testo e alle query di valori esatti, Elasticsearch offre anche funzionalità di aggregazione a più livelli.

Archivio documenti: MongoDB

A questo punto, MongoDB può essere considerato il database NoSQL di riferimento. La sua facilità d'uso e flessibilità hanno rapidamente guadagnato la sua popolarità. MongoDB supporta query avanzate e adattabili per scavare in documenti complessi. I campi sottoposti a query frequenti possono essere accelerati tramite l'indicizzazione e, quando si aggrega una grande quantità di dati, MongoDB offre una pipeline a più stadi.

Negozio Colonnare: Amazon Redshift

Oltre alla crescita della popolarità di NoSQL, anche i database colonnari hanno attirato l'attenzione, in particolare per l'analisi dei dati. Memorizzando i dati in colonne anziché nelle solite righe, le operazioni di aggregazione possono essere eseguite direttamente dal disco, aumentando notevolmente le prestazioni. Alcuni anni fa, Amazon ha lanciato il suo servizio in hosting per un negozio colonnare chiamato Redshift.

Indicizzazione

Capacità di indicizzazione di Elasticsearch

In molti modi, i motori di ricerca sono archivi di dati specializzati nell'indicizzazione di testi.

Mentre altri archivi di dati creano indici basati sui valori esatti del campo, i motori di ricerca consentono il recupero con solo un frammento del campo (solitamente di testo).

Per impostazione predefinita, questo recupero viene eseguito automaticamente per ogni campo tramite analizzatori.

Un analizzatore è un modulo che crea più chiavi di indice valutando i valori del campo e suddividendoli in valori più piccoli.

Ad esempio, un analizzatore di base potrebbe esaminare "la rapida volpe marrone è saltata sopra il cane pigro" in parole come "il", "veloce", "marrone", "volpe" e così via.

Questo metodo consente agli utenti di trovare i dati cercando frammenti all'interno dei risultati, classificati in base al numero di frammenti che corrispondono agli stessi dati del documento.

Un analizzatore più sofisticato potrebbe utilizzare modificare le distanze, n-grammi e filtrare per stopword, per creare un indice di recupero completo.

Capacità di indicizzazione di MongoDB

Come archivio dati generico, MongoDB ha molta flessibilità per l'indicizzazione dei dati.

A differenza di Elasticsearch, per impostazione predefinita indicizza solo il campo _id e dobbiamo creare manualmente gli indici per i campi comunemente richiesti.

Rispetto a Elasticsearch, l'analizzatore di testo di MongoDB non è così potente. Ma fornisce molta flessibilità con i metodi di indicizzazione, dal composto e geospaziale per query ottimali al TTL e sparse per la riduzione dello spazio di archiviazione.

Capacità di indicizzazione di Redshift

A differenza di Elasticsearch, MongoDB o persino dei database tradizionali, incluso PostgreSQL, Amazon Redshift non supporta un metodo di indicizzazione.

Al contrario, riduce il tempo di query mantenendo un ordinamento coerente sul disco.

Come utenti, possiamo configurare un insieme ordinato di valori di colonna come chiave di ordinamento della tabella. Con i dati ordinati sul disco, Redshift può saltare un intero blocco durante il recupero se il suo valore non rientra nell'intervallo richiesto, aumentando notevolmente le prestazioni.

Frammentazione

Capacità di sharding di Elasticsearch

Elasticsearch è stato costruito su Lucene per scalare orizzontalmente ed essere pronto per la produzione.

Il ridimensionamento viene eseguito creando più istanze Lucene (shard) e distribuendole su più nodi (server) all'interno di un cluster.

Per impostazione predefinita, ogni documento viene instradato al rispettivo shard tramite il campo _id .

Durante il recupero, il nodo master invia a ogni shard una copia della query prima di aggregarla e classificarla per l'output.

Capacità di sharding di MongoDB

All'interno di un cluster MongoDB, ci sono tre tipi di server: router, config e shard.

Ridimensionando il router, i server possono accettare più richieste, ma il lavoro pesante si verifica sui server shard.

Come con Elasticsearch, i documenti MongoDB vengono instradati (per impostazione predefinita) tramite _id ai rispettivi shard. Al momento della query, il server di configurazione notifica al router, che esegue lo shard della query, e il server del router distribuisce la query e aggrega i risultati.

Capacità di sharding di Redshift

Un cluster Amazon Redshift è costituito da un nodo leader e diversi nodi di calcolo.

Il nodo leader gestisce la compilazione e la distribuzione delle query, nonché l'aggregazione dei risultati intermedi.

A differenza dei server router di MongoDB, il nodo leader è coerente e non può essere ridimensionato orizzontalmente.

Sebbene ciò crei un collo di bottiglia, consente anche la memorizzazione nella cache efficiente dei piani di esecuzione compilati per le query più comuni.

Aggregare

Capacità di aggregazione di Elasticsearch

I documenti all'interno di Elasticsearch possono essere inseriti in un bucket in base a valori esatti, a intervalli o anche temporali e di geolocalizzazione.

Questi bucket possono essere ulteriormente raggruppati in una granularità più fine tramite l'aggregazione nidificata.

Le metriche, comprese le medie e le deviazioni standard, possono essere calcolate per ogni livello, offrendo la possibilità di calcolare una gerarchia di analisi all'interno di una singola query.

Essendo un archivio basato su documenti, subisce la limitazione dei confronti tra i campi all'interno del documento.

Ad esempio, mentre è utile filtrare se un campo follower è maggiore di 10, non possiamo verificare se i follower sono maggiori di un altro campo che segue .

In alternativa, possiamo iniettare script come predicati personalizzati. Questa funzione è ottima per l'analisi una tantum, ma le prestazioni ne risentono durante la produzione.

Capacità di aggregazione di MongoDB

La pipeline di aggregazione è potente e veloce.

Come suggerisce il nome, opera sui dati restituiti in modo graduale.

Ogni passaggio può filtrare, aggregare e trasformare i documenti, introdurre nuove metriche o rimuovere gruppi precedentemente aggregati.

Poiché queste operazioni vengono eseguite in modo graduale e assicurando che i documenti e i campi vengano ridotti al solo filtraggio, il costo della memoria può essere ridotto al minimo. Rispetto a Elasticsearch e persino a Redshift, Aggregation Pipeline è un modo estremamente flessibile per visualizzare i dati.

Nonostante la sua adattabilità, MongoDB soffre della stessa mancanza di confronto tra i campi all'interno del documento di Elasticsearch.

Inoltre, alcune operazioni, incluso $group , richiedono che i risultati vengano passati al nodo master.

Pertanto, non sfruttano il calcolo distribuito.

Coloro che non hanno familiarità con il calcolo della pipeline graduale troveranno alcuni compiti non intuitivi. Ad esempio, la somma del numero di elementi in un campo array richiederebbe due passaggi: prima, l'operazione $unwind e quindi l'operazione $group .

Capacità di aggregazione di Redshift

I vantaggi di Amazon Redshift non possono essere sottovalutati.

Le aggregazioni frustranti su MongoDB durante l'analisi del traffico mobile vengono risolte rapidamente da Amazon Redshift.

Supportando SQL, gli ingegneri di database tradizionali si divertiranno a migrare le loro query su Redshift.

A parte il tempo di onboarding, SQL è un linguaggio di query collaudato, scalabile e potente, che supporta facilmente i confronti tra campi interni a documenti/righe. Amazon Redshift migliora ulteriormente le sue prestazioni compilando e memorizzando nella cache le query più comuni eseguite sui nodi di calcolo.

Come database relazionale, Amazon Redshift non ha la flessibilità dello schema di MongoDB ed Elasticsearch. Ottimizzato per le operazioni di lettura, subisce un calo delle prestazioni durante gli aggiornamenti e le eliminazioni.

Per mantenere il miglior tempo di lettura, le righe devono essere ordinate, aggiungendo ulteriori sforzi operativi.

Progettato su misura per chi ha problemi di dimensioni petabyte, non è economico e probabilmente non vale l'investimento a meno che non ci siano problemi di ridimensionamento con altri database.

Scegliere il vincitore

In questo articolo, abbiamo esaminato tre diverse tecnologie – Elasticsearch, MongoDB e Amazon Redshift – nel contesto dell'ingegneria dei dati. Tuttavia, non esiste un chiaro vincitore poiché ciascuna di queste tecnologie è all'avanguardia nella sua categoria di tipo di archiviazione.

Per l'ingegneria dei dati, a seconda del caso d'uso, alcune opzioni sono migliori di altre.

• MongoDB è un fantastico database di partenza. Fornisce la flessibilità che desideriamo quando lo schema dei dati deve ancora essere determinato. Detto questo, MongoDB non supera i casi d'uso specifici in cui sono specializzati altri database.
• Sebbene Elasticsearch offra uno schema fluido simile a MongoDB, è ottimizzato per più indici e query di testo a scapito delle prestazioni di scrittura e delle dimensioni dello storage. Pertanto, dovremmo prendere in considerazione la migrazione a Elasticsearch quando ci troviamo a mantenere numerosi indici in MongoDB.
• Redshift richiede uno schema di dati predefinito e manca dell'adattabilità fornita da MongoDB. In cambio, surclassa altri database per query che coinvolgono solo singole (o poche) colonne. Quando il budget lo consente, Amazon Redshift è una grande arma segreta quando altri non sono in grado di gestire la quantità di dati.