Le moderne librerie R e / o Python rendono SQL obsoleto?

Lavoro in un ufficio in cui SQL Server è la spina dorsale di tutto ciò che facciamo, dall'elaborazione dei dati alla pulizia fino alla pulizia. Il mio collega è specializzato nella scrittura di funzioni complesse e procedure memorizzate per elaborare metodicamente i dati in entrata in modo che possano essere standardizzati e messi in funzione in report, visualizzazioni e progetti di analisi. Prima di iniziare qui, ho avuto pochissima esperienza con SQL, oltre a scrivere le query più basilari. La stragrande maggioranza del mio lavoro di preparazione all'analisi è stata fatta in R. Il mio capo insiste sul fatto che io perfeziono le mie abilità SQL, anche se sembrano esserci pochissimi incarichi che non possono essere eseguiti in modo più efficiente e con molte meno righe di codice usando R pacchetti come dplyr, data.table e tidyr (solo per citarne alcuni). La mia domanda è: ha senso?

Un paio di settimane fa, mi sono trovato di fronte al compito di ottenere un elenco di nomi di colonna per ogni riga in una tabella che soddisfacesse determinati criteri e concatenarli in un vettore di stringhe. C'era una scadenza serrata e all'epoca stavo vivendo qualche blocco e non riuscivo a avvolgere la testa attorno al problema. Ho chiesto al mio capo, che a sua volta ha chiesto al mio collega di scrivere uno script TSQL per risolvere il problema. Mentre ci stava lavorando, ho trovato un modo per farlo in R scrivendo una funzione abbastanza semplice e applicandola sul frame di dati. Il mio collega è tornato con la sua sceneggiatura circa due ore dopo. Erano almeno 75 le linee che comprendevano due anelli nidificati. Gli chiesi di avvisare quando finiva di funzionare e mi disse che ci sarebbero volute diverse ore. Nel frattempo il mio script R è stato in grado di eseguire il ciclo dei ~ 45.000 record in circa 30 secondi.

Ho ragione a supporre che R sia una scelta molto migliore per la pulizia e la pulizia dei dati? Forse lo sviluppatore SQL nel mio ufficio è solo inetto? Sono curioso di sapere se qualcuno che ha lavorato con R e SQL (o Python e SQL per quella materia) abbia qualche idea al riguardo.

R e SQL sono due bestie completamente diverse. SQL è un linguaggio che è possibile utilizzare per eseguire query sui dati archiviati nei database come già sperimentato. I vantaggi di SQL rispetto a R risiedono principalmente nel fatto che il server di database (MS SQL, Oracle, PostgreSQL, MySQL, ecc.).

La maggior parte, se non tutti, i moderni server di database consentono a più utenti di eseguire query sui dati dalla stessa origine dati e di inserire, aggiornare ed eliminare i dati nelle stesse tabelle, garantendo al contempo che i dati rimangano coerenti. Questo è essenziale per dire la registrazione di una transazione bancaria. Riesci a immaginare di gestire una banca su R? È qui che entrano in gioco i server di database. Assicurano che le proprietà ACID delle procedure vengano eseguite sul database. ACID è l'acronimo di Atomicity, concorrenza, isolamento e durata (vedere la descrizione ACID su Wikipedia ). R è una piattaforma per utente singolo in cui tutto accade in memoria. Pertanto, se il computer smette di funzionare a metà in una grande operazione, i dati non verranno archiviati. Sei anche l'unica persona che può accedere ai dati. Per essere chiari, R non è considerata un'alternativa per i server di database e / o SQL.

Un altro vantaggio principale dei server di database è che una buona progettazione del database garantirà la possibilità di eseguire rapidamente query sul database eseguendo l'ottimizzazione delle query. A tale scopo, i server di database tengono traccia della progettazione di una tabella. Vedi per una discussione completa su questo argomento la pagina wiki . R non può eseguire l'ottimizzazione della query. Cattiva progettazione del database, può portare a un'esecuzione lenta delle query. I server di database possono anche eseguire l'ottimizzazione su query che eseguono query su più tabelle se le chiavi esterne sono utilizzate correttamente nella progettazione del database.

Il linguaggio SQL ha una sintassi molto diversa e condivido la tua esperienza sul fatto che è più breve scrivere passaggi di munging dei dati utilizzando la tabella dei dati o la sintassi dplyr. Tuttavia, a volte i dati sono troppo grandi per R o è necessario archiviare i risultati nel database come parte di un processo batch periodico, che richiederà di codificare la logica in SQL.

Nella mia esperienza ci sono casi d'uso particolari per SQL e R / Python. SQL è ottimo per l'archiviazione di dati business-critical e per consentire a più persone di accedere, modificare, inserire ed eliminare i dati in un ambiente centralizzato. Per qualsiasi dato una tantum il munging R e Python sono fantastici. Se è necessario eseguire periodicamente il munging dei dati, sarà necessario eseguire il porting dello script R / Python su SQL.

Questi non sono nemmeno comparabili, davvero. SQL è un linguaggio pensato per accedere ai dati, R è un linguaggio pensato per lavorare con i dati.

SQL non è uno strumento efficace per il munging perché è difficile vedere passaggi intermedi e quando genera errori, non è probabile che affronti la forma / qualità / struttura dei dati.

Il mio flusso di lavoro è in genere:

1. Ottieni dati grezzi dalla query SQL (in R)
2. Costruisci routine munging
3. Se possibile, riscrivere la query SQL per eseguire il munging eseguito in R

Inoltre, ti rendi conto che non tutti gli utenti di dati utilizzano R, ma molti interfacciano ancora la loro piattaforma preferita con i dati che utilizzano SQL.

library (dbplyr) ha l'approccio corretto: scrivi tutto in R (usando il tidyverse) e lascia che la libreria just-in-time "compili" il codice R in SQL di basso livello.

Poiché non tutto il munging è traducibile, un altro approccio è quello adottato da SQL Server: lasciare che gli snippet di codice R vengano richiamati dai comandi SQL "select".

L'approccio 1., 2., 3. menzionato da HEITZ è nella mia esperienza possibile estendere con un'alternativa per 3. in cui si riscrivono i dati da R (data.table) in MySQL.

Quindi i passaggi completi sono MySQL-> data.table-> MySQL

Se ti assicuri di utilizzare la sintassi data.table in cui non copi il DT è anche compatibile con la RAM.

In una parola NO . SQL è un potente modo conciso e flessibile per descrivere e sintetizzare dati strutturati semistrutturati e persino non strutturati, quando viene posizionato un livello interprete appropriato sopra di esso. A proposito, sqlè considerato un must per i data scientist.

SQL è un modo conciso e potente per eseguire le sue operazioni principali di:

• proiezioni ( seleziona ..)
• filtro ( dove ..)
• raggruppamento / filtro ( raggruppa per e avendo )
• aggregazioni di base ( conteggio , somma , media ..)
• si unisce

Il vero potere arriva quando si combinano i risultati usando le viste incorporate . Quando ho bisogno di fare che userò una delle sqldf, pandasql, pysparkSql/ sparkSqlo una connessione diretta RDBMS. Scrivere lo stesso nel modo più conciso possibile con data.table(molto meglio di data.frame) o datatable(meglio di pandas) è ancora più goffo, molto più goffo o quasi impossibile a seconda della complessità delle query tentate.

Per il munging dei dati : questa è una storia diversa: alcune operazioni sono facilmente espresse in sql e altre non così tanto. Quando tuttavia incorporate UDFs, vi è una latitudine più ampia di ciò che può essere raggiunto. La mia attività attuale include una serie di UDFoperazioni da eseguire come operazioni di intersezione dei clienti , aggregazioni personalizzate e metodi di punteggio personalizzati .