"Quando uso una parola", disse Humpty Dumpty in tono sprezzante, "significa proprio quello che ho scelto di significare, né più né meno".
La questione è, disse Alice, se si può far sì che le parole significhino così tante cose diverse".
- Attraverso lo specchio, Lewis Caroll
I "Big Data", come la maggior parte delle parole d'ordine, ha generato molte definizioni parzialmente sovrapposte. (In effetti, l'autore è dell'opinione che, proprio come le mandrie di mucche e gli omicidi di corvi, le raccolte di definizioni abbiano bisogno di un proprio sostantivo collettivo. Rispettosamente propone "opinione", come in "un'opinione di definizioni", come scelta naturale). Questo post non intende aggiungere un'altra definizione di Big Data. Si tratta di considerare le implicazioni operative e architettoniche del chiamare qualcosa Big Data.
Quindi, prendete la vostra definizione (o le vostre definizioni) preferita e una manciata rappresentativa di dati e considerate quanto segue:
- Ogni pezzo dei miei dati è vitale? Sarei turbato se una piccola percentuale casuale si allontanasse e diventasse un non-dato?
- Ho bisogno delle garanzie tradizionali che i database relazionali hanno tradizionalmente fornito? (Come l'ACID e la rigidità e specificità delle connessioni tra i dati).
- I dati in forma aggregata offrono spunti di riflessione che non possono essere trovati analizzando solo un sottoinsieme?
- I miei dati sono non strutturati? Generati da dispositivi IoT? Generati dall'attività degli utenti nelle applicazioni o nei servizi web?
Si noti l'assenza di domande sul volume, la velocità o la varietà dei set di dati. Si tratta di considerazioni importanti, ma è anche utile pensare ai Big Data come a un paradigma in cui si accettano determinati compromessi che tradizionalmente non si sarebbero accettati; in alternativa, si può pensare ai Big Data come a un ecosistema in cui si utilizzano determinati modelli di soluzione.
Ad esempio, immaginiamo che stiate elaborando transazioni finanziarie. Le risposte alle domande poste in (1) e (2) sarebbero "Sì", "Estremamente" e "Sì". Questa parte del sistema deve probabilmente essere un database relazionale tradizionale. Perché? Le architetture di Big Data sono in genere tolleranti nei confronti di una certa perdita di dati. Dopo tutto, avete molti dati.
Sebbene questo sembri assurdo per le transazioni finanziarie, ricordiamo che la maggior parte delle tecnologie Big Data sono nate da aziende del "Web 2.0" che cercavano di risolvere i problemi che si trovavano ad affrontare. MapReduce (e quindi Hadoop) è stato utilizzato da Google per indicizzare il Web. Kafka ha aiutato LinkedIn a elaborare i dati di log. In entrambi i casi, l'occasionale dati occasionalmente persi non ha avuto conseguenze.
D'altra parte, se avete risposto sì alle domande (3) e (4), probabilmente disponete di dati elaborati al meglio con le tecnologie Big Data. In questo caso i dati sono talmente tanti che nessun singolo pezzo è particolarmente importante, ma lo è l'aggregato e la capacità di analizzare l'aggregato. Ciò di cui avete bisogno è un modo facile da usare per lavorare con questi dati.
SnapLogic Elastic Integration Platform gestisce dati di piccole dimensioni, dati di medie dimensioni, Big Data, dati cloud , dati batch o dati in streaming - in pratica, gestisce i dati, indipendentemente dagli aggettivi che si vogliono applicare ad essi. Non è necessario scegliere una sola dimensione per tutti i dati. Il vantaggio di avere un data lake è che ogni parte della vostra infrastruttura può utilizzare la soluzione più adatta alla sua applicazione, ma tutti i pezzi possono essere collegati tra loro senza soluzione di continuità. Possiamo collaborare con voi per implementare un'architettura complessiva che sia adatta alle vostre esigenze di oggi e che possa essere scalata per le necessità di domani.
