Le 10 peggiori pratiche per i big data

Sì, puoi danneggiare i big data. Tuttavia, puoi ostacolarlo nel modo giusto o nel modo sbagliato. Ecco le 10 peggiori pratiche da evitare.

1. Scegliere MongoDB come piattaforma per big data. Perché scelgo MongoDB? Non lo sono, ma per qualsiasi motivo, il database NoSQL più abusato a questo punto è MongoDB. Mentre MongoDB ha un framework di aggregazione che sa di MapReduce e persino un connettore Hadoop (molto scarsamente documentato), il suo punto debole è un database operativo, non un sistema analitico.

[Andrew C. Oliver risponde alla domanda nella mente di tutti: quale fottuto database dovrei usare? | Anche su: Il tempo per gli standard NoSQL è ora | Ottieni un riassunto delle storie chiave ogni giorno nella newsletter quotidiana. ]

Quando inizia la tua frase, "Useremo Mongo per analizzare ...", fermati lì e pensa a quello che stai facendo. A volte intendi davvero "raccogliere per analisi successive", il che potrebbe essere OK, a seconda di cosa stai facendo. Tuttavia, se intendi davvero utilizzare MongoDB come una sorta di tecnologia di data warehousing malata, il tuo progetto potrebbe essere condannato all'inizio.

2. Utilizzo dello schema RDBMS come file. Sì, hai scaricato ogni tabella dal tuo RDBMS in un file. Hai intenzione di archiviarlo su HDFS. Hai intenzione di usare Hive su di esso.

Prima di tutto, sai che Hive è più lento del tuo RDBMS per qualcosa di normale, giusto? MapReduce anche una semplice selezione. Guarda il percorso "ottimizzato" per i join "tabella". Successivamente, diamo un'occhiata alle dimensioni delle righe: sai, hai file flat misurati in kilobyte a una cifra. Hadoop funziona al meglio su grandi set di dati relativamente piatti. Sono sicuro che puoi creare un estratto più denormalizzato.

3. Creazione di stagni di dati. Sulla strada per creare un data lake, hai svoltato su un cavalcavia diverso e hai creato una serie di data pool. La legge di Conway ha colpito di nuovo e hai consentito a ciascun gruppo aziendale non solo di creare la propria analisi dei dati, ma anche i propri mini-repository. All'inizio non suona male, ma con diversi estratti e modi di affettare e sminuzzare i dati, ti ritroverai con visualizzazioni diverse dei dati. Non intendo piatto rispetto a cubo, intendo risposte diverse per alcune delle stesse domande. Schema-on-read non significa "non pianificare affatto", ma significa "non pianificare per ogni domanda che potresti porre".

Tuttavia, dovresti pianificare il quadro generale. Se vendi widget, c'è una buona probabilità che qualcuno voglia vedere quanti, a chi e con quale frequenza hai venduto widget. Vai avanti e prendilo nei formati comuni e fai un piccolo design iniziale per assicurarti di non finire con bacini di dati e pozzanghere di proprietà di ogni singolo gruppo aziendale.

4. Non riuscire a sviluppare casi d'uso plausibili. L'idea del data lake viene venduta dai fornitori per sostituire i casi d'uso reali. (È anche un modo per sfuggire ai vincoli dei finanziamenti dipartimentali.) L'approccio del data-lake può essere valido, ma dovresti avere in mente casi d'uso reali. Non è difficile trovarli nella maggior parte delle aziende di medie e grandi dimensioni. Inizia esaminando l'ultima volta che qualcuno ha detto: "No, non possiamo, perché il database non è in grado di gestirlo". Quindi passa a "duh". Ad esempio, lo "sviluppo aziendale" non dovrebbe essere solo una promozione titolare per il tuo miglior venditore; dovrebbe significare qualcosa.

Che ne dici, ad esempio, dell'utilizzo di Mahout per trovare gli ordini dei clienti che sono valori anomali comuni? Nella maggior parte delle aziende, la maggior parte degli ordini dei clienti si assomigliano. Ma per quanto riguarda gli ordini che avvengono abbastanza spesso ma non corrispondono a quelli comuni? Questi potrebbero essere troppo piccoli per i venditori, ma potrebbero indicare una futura linea di business per la tua azienda (ovvero, l'effettivo sviluppo del business). Se non riesci a tirare fuori almeno un paio di buoni usi nel mondo reale per Hadoop, forse non ne hai bisogno, dopotutto.

5. Thinking Hive è l'essenza, la fine di tutto. Conosci SQL. Ti piace SQL. Hai fatto SQL. Capisco, amico, ma forse puoi crescere anche tu? Forse dovresti approfondire un decennio o tre e ricordare il ragazzino che ha imparato SQL e ha visto i mondi che gli si aprivano. Ora immagina che impari un'altra cosa allo stesso tempo.