Perché le persone preferiscono i panda a SQL?

Uso SQL dal 1996, quindi potrei essere di parte. Ho usato ampiamente MySQL e SQLite 3, ma ho anche usato Microsoft SQL Server e Oracle.

La stragrande maggioranza delle operazioni che ho visto fare con Panda può essere eseguita più facilmente con SQL. Ciò include il filtraggio di un set di dati, la selezione di colonne specifiche per la visualizzazione, l'applicazione di una funzione a un valore e così via.

SQL ha il vantaggio di avere un ottimizzatore e la persistenza dei dati. SQL ha anche messaggi di errore chiari e comprensibili. Pandas ha un'API in qualche modo criptica, in cui a volte è appropriato usarne una singola [ stuff ], altre volte che ti serve [[ stuff ]]e talvolta hai bisogno di un .loc. Parte della complessità dei panda deriva dal fatto che ci sono così tanti sovraccarichi in corso.

Quindi sto cercando di capire perché Pandas è così popolare.

La vera prima domanda è perché le persone sono più produttive con le astrazioni DataFrame rispetto alle astrazioni SQL pure.

TLDR; SQL non è orientato allo sviluppo (umano) e al processo di debug, come lo sono DataFrames.

Il motivo principale è che le astrazioni DataFrame consentono di costruire istruzioni SQL evitando l'annidamento dettagliato e illeggibile. Il modello di scrivere routine annidate, commentarle per verificarle e quindi decommentarle è sostituito da singole linee di trasformazione. Puoi naturalmente eseguire le cose riga per riga in un sostituto (anche in Spark) e visualizzare i risultati.

Si consideri l'esempio di aggiungere una nuova trasformata (colonna con stringhe di stringhe) a una tabella, quindi raggrupparla e fare alcune aggregazioni. L'SQL diventa piuttosto brutto. I panda possono risolverlo, ma mancano alcune cose quando si tratta di big data o in partizioni particolari (forse migliorate di recente).

I DataFrame dovrebbero essere visualizzati come un'API di alto livello per le routine SQL, anche se con i panda non vengono affatto rappresentati in alcuni planner SQL.

-

Probabilmente puoi avere molte discussioni tecniche su questo, ma sto prendendo in considerazione la prospettiva dell'utente di seguito.

Un semplice motivo per cui potresti vedere molte più domande sulla manipolazione dei dati di Pandas rispetto a SQL è che usare SQL, per definizione, significa usare un database e molti casi d'uso in questi giorni richiedono semplicemente bit di dati per " compiti "one-and-done" (da .csv, api web, ecc.). In questi casi non è possibile caricare, archiviare, manipolare ed estrarre da un database.

Tuttavia, considerando i casi in cui il caso d'uso può giustificare l'uso di Pandas o SQL, sicuramente non ti sbagli. Se vuoi fare molte, ripetitive attività di manipolazione dei dati e persistere gli output, ti consiglio sempre di provare prima a passare tramite SQL. Da quello che ho visto il motivo per cui molti utenti, anche in questi casi, non passano tramite SQL è duplice.

In primo luogo, il principale vantaggio che Panda ha su SQL è che fa parte del più ampio universo Python, il che significa che in un colpo solo posso caricare, pulire, manipolare e visualizzare i miei dati (posso persino eseguire SQL attraverso Pandas ...). L'altro è, semplicemente, che troppi utenti non conoscono l'estensione delle capacità di SQL. Ogni principiante impara la 'sintassi di estrazione' di SQL (SELECT, FROM, WHERE, ecc.) Come mezzo per portare i tuoi dati da un DB al posto successivo. Alcuni potrebbero raccogliere alcune delle sintassi di raggruppamento e iterazione più avanzate. Ma dopo ciò tende ad esserci un abisso piuttosto significativo nella conoscenza, fino a quando non si arriva agli esperti (DBA, Data Engineer, ecc.).

tl; dr: dipende spesso dal caso d'uso, dalla praticità o da una lacuna nella conoscenza dell'estensione delle capacità di SQL.

Per quanto vi sia sovrapposizione nell'applicazione di queste due cose, si tratta di confrontare le mele con le arance.

Panda è un toolkit di analisi dei dati implementato in Python, un linguaggio di programmazione generico. SQL è un linguaggio specifico del dominio per l'interrogazione dei dati relazionali (di solito in un sistema di gestione di database relazionali quali SQLite, MySQL, Oracle, SQL Server, PostgreSQL ecc. Sono esempi).

SQL implica

• lavorare con i dati in un RDBMS * che può essere o non essere appropriato per il carico di lavoro, anche se è solo un piccolo database SQLite,
• conoscenza del dominio del database (come utente finale, sviluppatore e / o amministratore; il suggerimento che "SQL è più veloce" che vedo spesso è un'enorme semplificazione eccessiva) e
• superare la curva di apprendimento non insignificante nell'uso efficace di SQL, in particolare in applicazioni specializzate come l'analisi dei dati (invece di creare semplici report di dati semplici).

* Vale la pena sottolineare che SQL è così specifico per il dominio che sta diventando molto meno rilevante nel lavorare con alternative sempre più comuni ai database relazionali come i database NoSQL . Ciò rappresenta un cambiamento fondamentale nel modo in cui i dati vengono archiviati e strutturati e in realtà non esiste un modo universalmente comune per accedervi come lo sviluppo della standardizzazione SQL che mira a raggiungere.

Python d'altra parte (i panda sono abbastanza "pitonici", quindi è vero qui) è flessibile e accessibile a persone di diversa estrazione. Può essere usato come "linguaggio di scripting", come linguaggio funzionale e un linguaggio OOP completo. Le funzionalità di visualizzazione e l'interoperabilità delle origini dati sono integrate nei panda, ma sei libero di incorporare qualsiasi cosa Python possa fare nel tuo flusso di lavoro (che è la maggior parte delle cose); l'ecosistema scientifico di Python è cresciuto a maglie e include grandi strumenti come Jupyter Notebook e librerie di scipy essenziali come matplotlib e numpy (su cui panda si basa). Elementi significativi dell'analisi dei dati dei panda sono R-ispirato e in genere non troverete statistici canticchiando e chiedendo se usano R (o forse sempre più panda!) oltre a mettere tutto in un database e scrivere le loro analisi in SQL.

Non sto dicendo che Panda sia meglio di SQL o viceversa, ma SQL è uno strumento molto specifico del dominio mentre Panda è parte di un ecosistema gigante, flessibile e accessibile. Lavoro con sistemi di dati geospaziali, di cui i database relazionali sono una parte enorme e SQL è uno strumento potente ed essenziale. Tuttavia, Panda è una parte altrettanto se non più essenziale del mio toolkit quotidiano e SQL è spesso relegato al recupero di dati, forse con qualche pre-elaborazione, quindi posso fare qualcosa con esso in Panda.

In primo luogo, i panda non sono così popolari. Uso entrambi i panda e SQL. Per prima cosa provo a capire l'attività: se può essere fatto in SQL, preferisco SQL perché è più efficiente dei panda. Prova a lavorare su dati di grandi dimensioni (10.000.000 x 50). Prova a fare alcune operazioni di groupby sia in SQL che in Panda . Capirai.

Uso i panda dove è utile, come suddividere i valori di una colonna in un array e fare alcune cose su di esso (come scegliere solo alcuni valori da quell'array). Ora questo tipo di attività è relativamente difficile da codificare in SQL, ma i panda faciliteranno l'attività.

Sono una di quelle persone che userebbero (nel mio caso) R's dplyr (il linguaggio, non necessariamente lo strumento) in ogni caso se potessi anche se conosco il mio SQL.

Il principale vantaggio che vedo nelle pipeline Pandas / dplyr / data.table è che le operazioni sono atomiche e possono essere lette dall'alto verso il basso.

In SQL devi analizzare l'intero script, saltando in giro (cosa viene riassunto, cosa viene unito e come - a sinistra? Interno? A destra ?, ci sono dei filtri applicati?) Per comprendere appieno ciò che sta accadendo.

In Pandas et al. Ogni fase della pipeline è autonoma, fa qualcosa con i dati di input e restituisce i dati di output, questo processo sequenziale rende più facile ragionare su ciò che sta accadendo poiché esiste uno stato chiaramente definito per ogni operazione piuttosto che solo un livello di query.

E sì, puoi fare WITHaffermazioni e simili, ma richiede molto più codice e non è chiaro quale oggetto viene utilizzato rispetto alle tubazioni.

Sono abbastanza nuovo per Panda / Python ma ho più di 20 anni come DBA di SQL Server, architetto, amministratore, ecc. Adoro i Panda e mi sto spingendo per cercare sempre di far funzionare le cose in Panda prima di tornare al mio comodo, accogliente mondo SQL.

Perché i RDBMS sono migliori: Il vantaggio degli RDBMS sono i loro anni di esperienza nell'ottimizzazione della velocità delle query e delle operazioni di lettura dei dati. La cosa impressionante è che possono farlo mentre bilanciano contemporaneamente la necessità di ottimizzare la velocità di scrittura e gestire un accesso altamente simultaneo. A volte queste spese generali aggiuntive inclinano il vantaggio rispetto a Panda quando si tratta di casi d'uso semplici per singolo utente. Ma anche in questo caso, un DBA esperto può ottimizzare un database per essere altamente ottimizzato per la velocità di lettura rispetto alla velocità di scrittura. I DBA possono trarre vantaggio da cose come l'ottimizzazione dell'archiviazione dei dati, il dimensionamento strategico delle pagine del disco, il riempimento / riempimento delle pagine, il controller dei dati e le strategie di partizionamento del disco, i piani I / O ottimizzati, il pinning dei dati in memoria, i piani di esecuzione predefiniti, l'indicizzazione, la compressione dei dati , e molti altri. Ho l'impressione da molti sviluppatori di Panda che non capire la profondità che è disponibile lì. Quello che penso di solito accade è che se lo sviluppatore Pandas non ha mai dati abbastanza grandi da richiedere queste ottimizzazioni, non apprezzano quanto tempo possono salvarti fuori dalla scatola. Il mondo RDBMS ha 30 anni di esperienza nell'ottimizzazione di questo, quindi se è necessaria la velocità pura su set di dati di grandi dimensioni, è possibile battere RDBMS.

Perché Python / Panda è meglio: Detto questo, la velocità non è tutto e in molti casi d'uso non è il fattore trainante. Dipende da come stai usando i dati, se sono condivisi e se ti interessa la velocità del trattamento. Gli RDBMS sono generalmente più rigidi nelle loro strutture di dati e gravano sullo sviluppatore per essere più deterministici con le forme dei dati. Panda ti permette di essere più libero qui. Inoltre, e questa è la mia ragione preferita, sei in un vero linguaggio di programmazione. I linguaggi di programmazione offrono una flessibilità infinitamente maggiore per applicare una logica avanzata ai dati. Naturalmente c'è anche il ricco ecosistema di moduli e framework di terze parti a cui SQL non può avvicinarsi. Essere in grado di passare dai dati grezzi fino alla presentazione web o alla visualizzazione dei dati in una base di codice è MOLTO conveniente. È anche molto più portatile. Puoi eseguire Python quasi ovunque, inclusi i blocchi note pubblici che possono estendere la portata dei risultati per raggiungere le persone più rapidamente. I database non eccellono in questo.

Il mio consiglio? Se ti ritrovi a passare a set di dati sempre più grandi, devi farlo per fare un grande passo e imparare come RDBMS può aiutare. Ho visto milioni di righe, join multi-tabella, query aggregate sommate ottimizzate da 5 minuti a 2 secondi. Avere questa comprensione nella cintura degli strumenti ti rende uno scienziato di dati più completo. Oggi potresti essere in grado di fare tutto in Panda, ma un giorno potresti avere un incarico in cui RDBMS è la scelta migliore.

Le cose che i panda possono fare, che SQL non può fare

1. df.describe()
2. Trama, ad es df['population'].plot(kind='hist')
3. Utilizzare un dataframe direttamente per la formazione di algoritmi di machine learning

Le cose che Panda può fare, non sapevo che anche SQL potesse fare

1. Esporta in CSV: df.to_csv('foobar.sv'). Questo è importante quando vuoi mostrare qualcosa a un imprenditore che vuole lavorare con Excel. E c'è df.to_excelanche. Ma in SQL, puoi farlo SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(grazie, vy32!)

L'unica cosa non trattata in queste risposte che vorrei menzionare è che dipende anche da come stai usando SQL. Prendi ad esempio arcpy. Per qualche motivo nessuna delle funzioni arcpy.da ha molte funzionalità. Questo è davvero strano perché praticamente ogni altra libreria sql di Python lo fa. Anche l'istruzione Where nelle funzioni arcpy.da è limitata a circa 120 caratteri. Ciò significa essenzialmente che se hai un numero relativamente elevato di cose che stai cercando di fare con il tuo database, l'unica vera scelta è quella di chiamare la funzione arcpy.da scelta più volte, cambiando l'istruzione where ogni volta che lo fai. Ci sono alcuni trucchi che puoi usare per rendere questo processo più veloce - puoi iterare su pezzi del tuo set di dati per esempio - ma letteralmente ognuno di questi trucchi è molto più lento del solo usare un arcpy.da. searchcursor per caricare l'intera tabella in un frame di dati Panda, quindi manipolarla utilizzando Panda, Numpy e, se i tuoi dati sono davvero così enormi, Dask. Devo sottolineare qui che i panda non sono solo un po 'più veloci in questo caso. È disgustosamente più veloce. È molto più veloce che stavo letteralmente ridendo di me stesso per non averlo fatto prima. Usando i panda è sceso il tempo di esecuzione di uno script da ben oltre un'ora - dimentico se questo è stato il salto da 3,5 ore o da 1,5 ore - a letteralmente 12 minuti. è molto più veloce che stavo letteralmente ridendo di me stesso per non averlo fatto prima. Usando i panda è sceso il tempo di esecuzione di uno script da ben oltre un'ora - dimentico se questo è stato il salto da 3,5 ore o da 1,5 ore - a letteralmente 12 minuti. è molto più veloce che stavo letteralmente ridendo di me stesso per non averlo fatto prima. Usando i panda è sceso il tempo di esecuzione di uno script da ben oltre un'ora - dimentico se questo è stato il salto da 3,5 ore o da 1,5 ore - a letteralmente 12 minuti.

Una cosa da notare è che mentre avrei potuto farlo con sql, mi ci sarebbe voluto molto più tempo per imparare. Avrei dovuto imparare le operazioni specificamente per sql in Access - ecco dove sono finiti i dati per questo script - - sql in Access non era così robusto come avevo bisogno che fosse quando stavo davvero cercando di farlo -, oppure Avrei dovuto scrivere tutti i miei dati su un database sqlite3, manipolarli lì e poi metterli in Access. Anche se questo avrebbe potuto darmi risultati simili in termini di prestazioni, in futuro avrebbe reso più difficile la modifica del mio script.

Quindi sì, a volte Panda ed è semplicemente meglio dell'uso delle opzioni sql che hai a tua disposizione . Tutto ciò che avrei dovuto fare in sql è stato fatto con una funzione in panda. Puoi anche usare la sintassi sql con i panda se vuoi. Ci sono pochi motivi per non usare i panda e sql in tandem.

Un'altra cosa che voglio menzionare su Pandas e numpy è che entrambe queste librerie sono per natura approcci basati. È possibile eseguire il ciclo tra i frame di dati e la generazione di serie con queste librerie, ma è davvero difficile modificare i dati in queste strutture in questo modo, quindi si finirà per scrivere codice più efficiente - basato su set - con entrambe queste librerie puramente perché è molto più facile fare. Essere "guidati" se non su rotaia nell'uso di approcci basati su set non è qualcosa che ho sperimentato con SQL.

Un'altra cosa enorme che ho dimenticato di menzionare con i panda. Soldi . Pandas è uno strumento che molti lavori di Data Science vogliono che tu sappia usare. Praticamente ogni lavoro di Data Science che ho visto ha pagato di più dei lavori di gestione del database. L'unica eccezione a ciò che ho notato è in Data Engineering, ma ho visto molto meno di quelle offerte di lavoro. Panda sembra che ti faccia più soldi a colpo d'occhio.

Ho pensato di aggiungere che faccio molte analisi dei dati basate su serie temporali e che i panda resamplee i reindexmetodi sono preziosi per farlo. Sì, puoi fare cose simili in SQL (tendo a creare una DateDimensiontabella per aiutare con le query relative alla data), ma trovo che i metodi panda siano molto più facili da usare.

Inoltre, come altri hanno già detto, il resto della mia modellazione è in Python e spesso ho chiamate web o file CSV.

Cercherò di rispondere a questa domanda in base alla mia esperienza. Contrariamente alle altre risposte, preferisco Sqll'apprendimento profondo e le cose relative ai big data. Ci sono numerose ragioni per questo. Come si può vedere qui ,

Pandas offre un'esperienza di analisi dei dati intuitiva, potente e veloce su dati tabulari. Tuttavia, poiché Pandas utilizza solo un thread di esecuzione e richiede che tutti i dati siano in memoria contemporaneamente, non si adatta bene ai set di dati molto oltre la scala dei gigabyte.

$B ^+$

Un'altra differenza è che le operazioni CRUD in SQL possono essere applicate distribuite con diverse politiche di autorizzazione che non sono possibili nei panda.

Non ha lo scopo di dire quale è meglio, tutto dipende dal tuo compito. Per il calcolo su larga scala preferisco Sql e per quelli piccoli, preferisco i panda.

Ci sono altre cose che non sono presenti nei panda e che sono veramente importanti per una rapida esperienza di estrazione dei dati a cui farò riferimento in seguito. Per ora, dai un'occhiata qui .

Panda è più popolare poiché Python sotto forma di notebook jupyter è la cassetta degli attrezzi più popolosa utilizzata dallo scienziato di dati nell'area della rete neurale. Python sta diventando "il" linguaggio. È anche possibile utilizzare il back-end SQL, ma non si è legati a SQL solo con Panda.

Non esattamente la risposta alla domanda, ma poiché io stesso sono venuto qui per cercare differenze nell'applicazione pratica:

https://pandas.pydata.org/pandas-docs/stable/getting_started/comparison/comparison_with_sql.html