Problema dei Big Data
I volumi di Big Data stanno crescendo in modo esponenziale. Questo fenomeno si verifica da anni, ma il suo ritmo è accelerato notevolmente dal 2012. Dai un'occhiata a questo blog intitolato Big Data Just Beginning to Explode from CSC per un punto di vista simile sull'emergere dei big data e sulle relative sfide.
L'IRI è consapevole di questa tendenza sin dalla fondazione dell'azienda alla fine degli anni '70. Il suo pacchetto CoSort di punta è progettato per gestire volumi di dati crescenti attraverso l'efficienza degli algoritmi e della progettazione software, tecniche di sfruttamento dell'hardware "portatili" e consolidamento delle attività (ad es. sort-join-aggregate-encrypt-report). La domanda che questo articolo pone è di approccio, data l'"ascesa delle macchine".
Limitazione dell'hardware nel risolverlo
Certo, le prestazioni del computer hanno accelerato sotto ogni aspetto per decenni. E per molti, gettare hardware contro il problema dei big data è semplicemente una seconda natura. Tuttavia, il problema potrebbe essere più grande di quello. Considera la legge di Moore, in cui la potenza della CPU raddoppia al massimo ogni 18 mesi e l'obsolescenza intrinseca, i problemi di manutenzione e i costi puri di una strategia incentrata sull'hardware.
Qualcosa di nuovo da considerare è anche l'aspettativa che questo paradigma delle prestazioni per i big data possa volgere al termine. Secondo Gery Menegaz, la sua premessa è che la fine della Legge di Moore è vicina. Time Magazine ha pubblicato una storia simile nel maggio 2012 intitolata Il collasso della legge di Moore: Il fisico dice che sta già accadendo. Secondo l'articolo del Time,
Dato questo, Kaku afferma che quando la legge di Moore alla fine crollerà entro la fine del prossimo decennio, "la modificheremo semplicemente un po' con computer simili a chip in tre dimensioni". Oltre a ciò, dice "potremmo dover passare ai computer molecolari e forse alla fine del 21° secolo i computer quantistici".
Per la maggior parte degli utenti, tuttavia, l'hardware viene acquistato per gestire e, in una certa misura, scalare, per far fronte alle grandi sfide di elaborazione dei dati che devono affrontare o prevedere. Ma meno efficientemente funziona il software in esecuzione su di esso, più risorse hardware devono essere spese per superare l'inefficienza. Un esempio nel nostro mondo potrebbe essere l'acquisto di un IBM p595 per eseguire /bin/sort quando una macchina di un terzo di quelle dimensioni e costo che esegue CoSort produrrebbe invece lo stesso risultato.
Nel frattempo, le appliance DB ed ELT come Exadata e Netezza basate sull'hardware richiedono già investimenti di 6-7 cifre. E mentre possono scalare per sostenere carichi maggiori, di solito c'è un limite a quanto possono scalare (certamente non in modo esponenziale), quanti soldi possono essere spesi per tentare di continuare a scalare e quanto le persone sono disposte a fare affidamento su un unico fornitore per ogni aspetto mission-critical dei propri carichi di lavoro. Ed è invece una buona idea imporre il sovraccarico della trasformazione dei big data nei database progettati per l'ottimizzazione dell'archiviazione e del recupero (query)?
Anche se tutte queste domande hanno avuto risposte facili, come vengono risolti i problemi di calcolo (anche solo con una scalabilità lineare della crescita dei big data) che richiedono un consumo di risorse esponenzialmente maggiore (come l'ordinamento)? In qualche modo la risposta non sembrerebbe risiedere semplicemente nell'attesa di un calcolo quantistico a prezzi accessibili...
Il ruolo del software
Come sanno Hadoop e gli architetti del data warehouse, l'ordinamento e le operazioni di unione, aggregazione e caricamento in ETL che si basano sull'ordinamento sono al centro della grande sfida dell'elaborazione dei dati e un consumo esponenziale di risorse informatiche. Quando i big data raddoppiano, i requisiti di risorse per ordinarli possono triplicare. Pertanto gli algoritmi, le tecniche di sfruttamento dell'hardware e gli schemi di elaborazione coinvolti nel software di smistamento multipiattaforma e multi-core sono le chiavi per gestire questo problema in modi scalabili, convenienti ed efficienti.
Contributo di CoSort
Le prestazioni di CoSort scalano linearmente in volume, più in linea con la legge di Amdahl. Mentre CoSort può trasformare centinaia di gigabyte di big data in pochi minuti con poche dozzine di core, altri strumenti possono richiedere più del doppio del tempo, non scalare altrettanto bene e/o consumano più memoria e I/O nel processo. Forse ancora più importante, CoSort integra l'ordinamento direttamente nelle applicazioni correlate e fa tutto il suo lavoro pesante al di fuori del livello DB e BI, dove i dati di staging sarebbero meno efficienti.
L'architettura di co-routine di CoSort sposta i record tra lo smistatore e programmi come SortCL (l'utilità di trasformazione, filtraggio, ricerca, report, migrazione e protezione dei dati di CoSort) in modo interattivo, attraverso la memoria. Quindi, non appena il record ordinato successivo è disponibile, può spostarsi nell'applicazione, caricarsi, ecc. Sembra che l'app stia leggendo un file di input, ma in realtà il back-end della sorgente non è ancora stato prodotto. E no, non supererai lo smistatore.
Alla fine del 2015, CoSort è diventato anche il motore all'interno della moderna piattaforma di gestione e manipolazione dei big data di IRI, Voracity. Voracity sfrutta perfettamente i motori CoSort o Hadoop.
Conclusione
Non si può contare da sole sulle risorse di calcolo fisico per affrontare il problema dell'elaborazione dei big data. L'ambiente software CoSort è quello in cui è richiesta la trasformazione dei big data e i relativi lavori non vengono eseguiti come processi standalone, ma in parallelo durante lo stesso passaggio di I/O.
Quindi, se hai bisogno di un ordinamento veloce per uno scopo diverso dal semplice tempo di ordinamento, dovresti pensare a cosa succede a valle dell'ordinamento e ai modi migliori per collegare tra loro tali processi. E una volta determinato il miglior paradigma di runtime, puoi quindi combinare hardware ad alte prestazioni con tale software per ottimizzare le prestazioni? Ad esempio, puoi mettere in scena i dati DW con CoSort nel lato server del database di Exadata? O avrebbe più senso mantenere il tuo IBM p595 e aggiungere CoSort per triplicare il throughput? Oppure, se intendi utilizzare Hadoop, considera l'utilizzo dello stesso semplice 4GL di CoSort o delle intuitive mappature ETL di Voracity per guidare i lavori MapReduce 2, Spark, Storm o Tez.
Lascia che il tuo budget e la tua immaginazione siano le tue guide per affrontare la crescita dei dati.
