Mengapa orang lebih suka Pandas daripada SQL?


69

Saya sudah menggunakan SQL sejak 1996, jadi saya mungkin bias. Saya telah menggunakan MySQL dan SQLite 3 secara ekstensif, tetapi juga menggunakan Microsoft SQL Server dan Oracle.

Sebagian besar operasi yang saya lihat dilakukan dengan Panda dapat dilakukan dengan lebih mudah dengan SQL. Ini termasuk memfilter dataset, memilih kolom tertentu untuk ditampilkan, menerapkan fungsi ke suatu nilai, dan sebagainya.

SQL memiliki keunggulan memiliki pengoptimal dan ketekunan data. SQL juga memiliki pesan kesalahan yang jelas dan dapat dimengerti. Panda memiliki API yang agak samar, di mana kadang-kadang tepat untuk menggunakan satu [ stuff ], lain kali Anda butuhkan [[ stuff ]], dan kadang-kadang Anda membutuhkan .loc. Bagian dari kompleksitas Pandas muncul dari kenyataan bahwa ada begitu banyak kelebihan yang terjadi.

Jadi saya mencoba memahami mengapa Panda begitu populer.


Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Sean Owen

Jawaban:


51

Pertanyaan pertama yang sebenarnya adalah mengapa orang lebih produktif dengan abstraksi DataFrame daripada abstraksi SQL murni.

TLDR; SQL tidak diarahkan pada proses pengembangan (manusia) dan debugging, DataFrames adalah.

Alasan utama adalah bahwa abstraksi DataFrame memungkinkan Anda untuk membangun pernyataan SQL sambil menghindari bersarang verbose dan tidak terbaca. Pola penulisan rutinitas bersarang, berkomentar untuk memeriksanya, dan kemudian membatalkan komentar digantikan oleh satu baris transformasi. Anda dapat menjalankan hal-hal baris demi baris secara alami di repl (bahkan di Spark) dan melihat hasilnya.

Pertimbangkan contoh, menambahkan transformasi baru (kolom string yang rusak) ke sebuah tabel, kemudian mengelompokkannya dan melakukan beberapa agregasi. SQL menjadi sangat jelek. Panda dapat mengatasi hal ini tetapi kehilangan beberapa hal ketika menyangkut data yang benar-benar besar atau dalam partisi tertentu (mungkin ditingkatkan baru-baru ini).

DataFrames harus dilihat sebagai API tingkat tinggi untuk rutinitas SQL, bahkan jika dengan panda, mereka sama sekali tidak ditampilkan untuk beberapa perencana SQL.

-

Anda mungkin dapat melakukan banyak diskusi teknis tentang ini, tetapi saya sedang mempertimbangkan perspektif pengguna di bawah ini.

Salah satu alasan sederhana mengapa Anda mungkin melihat lebih banyak pertanyaan seputar manipulasi data Pandas sebagai lawan dari SQL adalah bahwa untuk menggunakan SQL, menurut definisi, berarti menggunakan database, dan banyak kasus penggunaan saat ini cukup membutuhkan bit data untuk ' tugas satu-dan-selesai (dari .csv, api web, dll.). Dalam kasus ini memuat, menyimpan, memanipulasi dan mengekstraksi dari basis data tidak layak.

Namun, mempertimbangkan kasus-kasus di mana kasus penggunaan dapat membenarkan menggunakan Pandas atau SQL, Anda tentu tidak salah. Jika Anda ingin melakukan banyak, tugas manipulasi data berulang dan mempertahankan output, saya selalu merekomendasikan mencoba melalui SQL terlebih dahulu. Dari apa yang saya lihat alasan mengapa banyak pengguna, bahkan dalam kasus ini, tidak menggunakan SQL dua kali lipat.

Pertama, panda keuntungan utama memiliki lebih dari SQL adalah bahwa itu bagian dari alam semesta Python yang lebih luas, yang berarti dalam satu gerakan saya dapat memuat, membersihkan, memanipulasi, dan memvisualisasikan data saya (saya bahkan dapat menjalankan SQL melalui Pandas ...). Yang lain adalah, cukup sederhana, bahwa terlalu banyak pengguna tidak tahu sejauh mana kemampuan SQL. Setiap pemula mempelajari 'sintaksis ekstraksi' dari SQL (SELECT, FROM, WHERE, dll.) Sebagai sarana untuk mendapatkan data Anda dari DB ke tempat berikutnya. Beberapa mungkin mengambil beberapa sintaks pengelompokan dan pengulangan yang lebih maju. Tetapi setelah itu cenderung ada jurang pemisah yang cukup signifikan dalam pengetahuan, sampai Anda mencapai para ahli (DBA, Data Engineers, dll.).

tl; dr: Ini sering kali disebabkan oleh kasus penggunaan, kenyamanan, atau kesenjangan dalam pengetahuan tentang sejauh mana kemampuan SQL.


2
Saya pikir SQL sebagian besar sedang diatur berbasis memainkan peran besar, ketika banyak orang dari bidang teknis lainnya digunakan untuk menangani data baris demi baris. Juga pertimbangkan bahwa data sebagian besar hanya data ke panda, tetapi mesin SQL yang berbeda mendukung fungsi bawaan yang berbeda yang bisa sangat menjengkelkan jika Anda harus memotong dan mengubah selama hari kerja Anda
Dave

3
Saya tidak akan mengatakan itu tidak layak. Jika Anda bisa memasukkan data ke dalam bingkai data panda, Anda mungkin bisa memasukkannya ke dalam DB PostgreSQL. Tetapi untuk satu dan dilakukan, itu mungkin lebih banyak upaya dan waktu daripada Anda akan menghemat.
jpmc26

2
Saya setuju bahwa beberapa pendekatan ETL tampaknya keputusan programmer-centric. Artinya, mereka lebih memilih untuk memanipulasi data kemudian menyajikan muatan "sempurna" ini ke basis data. Namun, seperti yang Anda tunjukkan, jika itu dapat dilakukan melalui beberapa query SQL, maka lapisan program tambahan tidak diperlukan. Persis apa yang saya hadapi baru-baru ini. Seperti yang ditunjukkan oleh OP dan jawaban Anda, bisa jadi orang "jadul" atau orang yang berpusat pada DBA melihatnya dan berkata, mengapa tidak melakukannya dalam SQL (bahkan hanya beberapa pertanyaan sederhana!). Yang mengatakan, saya menemukan panda sangat kuat untuk set data yang sangat beragam.
SaltySub2

1
@SaltySub Hanya satu titik untuk memindahkan hal-hal dari lapisan terprogram ke dalam SQL: Ini adalah titik yang adil dan dapat benar-benar valid, tetapi sejauh mengubur logika aplikasi dalam prosedur SQL dapat membawa rasa sakit kepala yang khas.
Kepala Listrik

1
@ ElectrikHead Saya setuju bahwa harus ada keseimbangan yang tepat. Jika serangkaian pertanyaan SQL dapat melakukan tugas-tugas secara memadai, itu pasti bisa lebih mudah dan lebih efisien. Sebaliknya, seperti yang Anda tunjukkan, jika seseorang harus menempatkan sejumlah besar logika ke dalam prosedur SQL, dll. Maka panda harus dipertimbangkan dengan kuat. Terutama seperti di atas jika Anda menggunakan citarasa basis data yang berbeda - perbedaan sintaks SQL dapat menjadi sangat berbulu.
SaltySub2

29

Sebanyak ada tumpang tindih dalam penerapan dua hal ini, ini membandingkan apel dengan jeruk.

panda adalah toolkit analisis data yang diimplementasikan dalam Python, bahasa pemrograman tujuan umum. SQL adalah bahasa khusus domain untuk menanyakan data relasional (biasanya dalam sistem manajemen basis data relasional yang contohnya SQLite, MySQL, Oracle Server, SQL Server, PostgreSQL dll).

SQL menyiratkan

  • bekerja dengan data dalam RDBMS * yang mungkin atau mungkin tidak sesuai untuk beban kerja, bahkan jika itu hanya database SQLite kecil,
  • basis data pengetahuan domain (sebagai pengguna akhir, pengembang dan / atau administrator; saran bahwa "SQL lebih cepat" Saya sering lihat adalah penyederhanaan berlebihan yang masif), dan
  • mengatasi kurva belajar yang tidak signifikan dalam menggunakan SQL secara efektif, khususnya dalam aplikasi spesialis seperti analisis data (sebagai lawan membuat laporan sederhana data sederhana).

* Layak menggarisbawahi fakta bahwa SQL sangat spesifik-domain, menjadi kurang relevan untuk bekerja dengan alternatif yang semakin umum untuk database relasional seperti database NoSQL . Ini merupakan perubahan mendasar dalam bagaimana data disimpan dan disusun, dan benar-benar tidak ada cara umum yang universal untuk mengaksesnya seperti pengembangan standardisasi SQL yang ingin dicapai.

Python di sisi lain (panda cukup "pythonic" sehingga berlaku di sini) fleksibel dan dapat diakses oleh orang-orang dari berbagai latar belakang. Ini dapat digunakan sebagai "bahasa scripting", sebagai bahasa fungsional dan bahasa OOP berfitur lengkap. Kemampuan visualisasi dan interoperabilitas sumber data dibangun menjadi panda, tetapi Anda bebas untuk memasukkan apa pun yang dapat dilakukan Python ke dalam alur kerja Anda (yang kebanyakan hal); ekosistem Python ilmiah telah menggelembung dan mencakup alat besar seperti Jupyter Notebook dan penting scipy perpustakaan seperti matplotlib dan numpy (yang panda dibangun pada). Elemen penting dari analisis data panda adalah R-terinspirasi dan Anda biasanya tidak akan menemukan ahli statistik yang bersuara dan bersuara tentang apakah mereka menggunakan R (atau mungkin semakin banyak panda!) di atas meletakkan segala sesuatu dalam database dan menulis analisis mereka dalam SQL.

Saya tidak mengatakan panda lebih baik dari SQL atau sebaliknya, tetapi SQL adalah alat yang sangat spesifik untuk domain sedangkan panda adalah bagian dari ekosistem raksasa, fleksibel dan dapat diakses. Saya bekerja dengan sistem data geospasial, yang database relasional merupakan bagian besar, dan SQL adalah alat yang kuat dan penting. Namun, panda adalah bagian yang sama jika tidak lebih penting dari toolkit saya sehari-hari dan SQL sering diturunkan untuk mengambil data - mungkin dengan beberapa pra-pemrosesan - jadi saya dapat melakukan hal-hal dengan panda.


1
Ini adalah satu-satunya jawaban yang benar, itu harus menjadi yang dipilih. SQL dan Panda adalah dua hal yang berbeda, saya tidak mengerti perbandingan apa yang orang coba lakukan.
gented

Saya menduga ini adalah perspektif pengguna akhir dalam menulis sesuatu seperti kode untuk mengambil dan memijat beberapa data dari suatu tempat dan mengeluarkan beberapa angka. Saya tidak sepenuhnya terkejut; Saya sudah memiliki pengalaman tangan pertama bagaimana data analis disajikan dengan tua tetapi sebaliknya biasa-biasa saja database Oracle belum bahkan ide pertama apa yang dan bagaimana menghubungkan untuk itu apalagi mendapatkan data. Saya percaya itu mengkhianati kurangnya pemahaman mendasar tentang teknologi - saya sebenarnya telah menambahkan sedikit untuk mudah-mudahan menekankan seberapa cepat kesalahpahaman ruang lingkup SQL jatuh.
Kepala Listrik

Saya akan menantang bit Anda tentang menjadi tidak relevan dengan situasi NoSQL. Sebagai contoh, perhatikan langkah-langkah yang dibuat PostgreSQL dengan penyimpanan JSON-nya.
jpmc26

Saya mencoba memilih kata-kata saya dengan hati-hati; PostgreSQL masih merupakan RDBMS meskipun melakukan banyak hal dengan baik (seperti SQL Server meskipun mendukung grafik). Tapi, saya telah merilekskan sentuhan kata karena itu masih poin yang bagus: ada beberapa crossover dan, yang penting, API SQL memang ada untuk beberapa sistem NoSQL. Ini adalah crossover, SQL bukan bahasa universal dan tidak semua data disusun secara relasional.
Kepala Listrik

Saya pikir Anda bisa melakukan segalanya dalam SQL yang dimungkinkan dalam panda. SQL tidak fleksibel tetapi sangat dioptimalkan.
Media

22

Pertama, panda tidak begitu populer. Saya menggunakan panda dan SQL. Pertama saya mencoba memahami tugas-jika dapat dilakukan dalam SQL, saya lebih suka SQL karena lebih efisien daripada panda. Coba kerjakan data besar (10.000.000 x 50). Cobalah untuk melakukan beberapa operasi grup dengan SQL dan panda. Kamu akan mengerti.

Saya menggunakan panda di mana itu berguna - seperti memecah nilai kolom menjadi array dan melakukan beberapa hal di atasnya (seperti memilih hanya beberapa nilai dari array itu). Sekarang jenis tugas ini relatif sulit untuk dikodekan dalam SQL, tetapi panda akan memudahkan tugas Anda.


Apakah inefisiensi ini khusus untuk panda? Saya telah melakukan cukup banyak manipulasi data dalam memori di C # dan merasa cukup mudah dan efisien, asalkan sesuai dengan memori dan satu-shot (yaitu tidak perlu secara bertahap memperbarui indeks saat data berubah).
CodesInChaos

panda dimaksudkan untuk lebih nyaman daripada cepat, tetapi itu tidak berarti tidak bisa cepat jika Anda menggunakannya dengan benar. Pada akhirnya, mengeksekusi query SQL pada data dalam database bukanlah sihir - itu membutuhkan sumber daya seperti apa pun, hanya saja (jika Anda melakukannya dengan benar!) Anda semoga memanfaatkan sumber daya pada server database yang dikonfigurasi dengan hati-hati dan gemuk . Mendapatkan saluran pipa Anda langsung di panda atau yang serupa (misalnya mengalirkan data daripada memuat semuanya ke dalam memori) akan menentukan seberapa sukses beberapa upaya.
Kepala Listrik

@CodesInChaos Ada jawaban untuk panda vs SQl - qr.ae/TUIpzE . Di sana dijelaskan kelebihan dan kekurangan menggunakan panda.
Ankit Seth

12

Saya salah satu dari orang-orang yang akan menggunakan (dalam kasus saya) d's Rp (bahasa, belum tentu alat) dalam setiap kasus jika saya bisa meskipun saya tahu SQL saya.

Manfaat utama yang saya lihat di Pandas / dplyr / data.table pipelines adalah bahwa operasinya bersifat atomik dan dapat dibaca dari atas ke bawah.

Dalam SQL Anda perlu menguraikan seluruh skrip, melompat-lompat (apa yang diringkas, apa yang sedang bergabung dan bagaimana - kiri? Batin? Kanan ?, apakah ada filter yang diterapkan?) Untuk sepenuhnya memahami apa yang terjadi.

Dalam Pandas et al, setiap langkah dari pipeline adalah mandiri, ia melakukan sesuatu dengan data input dan mengembalikan data output, proses berurutan ini memudahkan untuk berpikir tentang apa yang terjadi karena ada keadaan yang jelas untuk setiap operasi daripada hanya pada tingkat permintaan.

Dan ya Anda bisa melakukan WITHpernyataan dan semacamnya tetapi membutuhkan lebih banyak kode dan tidak jelas objek apa yang digunakan dibandingkan dengan perpipaan.


6

Saya cukup baru untuk Pandas / Python tetapi memiliki 20+ tahun sebagai DBA SQLServer, arsitek, administrator, dll. Saya suka Pandas dan saya mendorong diri saya untuk selalu mencoba membuat sesuatu berfungsi di Panda sebelum kembali ke kenyamanan saya, dunia SQL yang nyaman.

Mengapa RDBMS Lebih Baik: Keuntungan dari RDBMS adalah pengalaman mereka dalam mengoptimalkan kecepatan query dan operasi pembacaan data. Yang mengesankan adalah mereka dapat melakukan ini sambil secara bersamaan menyeimbangkan kebutuhan untuk mengoptimalkan kecepatan tulis dan mengelola akses yang sangat bersamaan. Terkadang overhead tambahan ini memiringkan keuntungan bagi Pandas dalam hal kasus penggunaan tunggal yang sederhana. Tetapi meskipun demikian, DBA berpengalaman dapat menyetel basis data agar sangat dioptimalkan untuk kecepatan baca melebihi kecepatan tulis. DBA dapat mengambil keuntungan dari hal-hal seperti mengoptimalkan penyimpanan data, ukuran halaman disk strategis, pengisian halaman / pelapis, pengontrol data dan strategi partisi disk, dioptimalkan rencana I / O, penyematan data dalam-memori, rencana eksekusi yang telah ditentukan sebelumnya, pengindeksan, kompresi data , dan masih banyak lagi. Saya mendapat kesan dari banyak pengembang Panda bahwa mereka tidak t memahami kedalaman yang tersedia di sana. Apa yang saya pikir biasanya terjadi adalah bahwa jika pengembang Pandas tidak pernah memiliki data yang cukup besar untuk memerlukan optimasi ini, mereka tidak menghargai berapa banyak waktu yang mereka dapat menyelamatkan Anda dari kotak. Dunia RDBMS memiliki 30 tahun pengalaman dalam mengoptimalkan hal ini sehingga jika kecepatan mentah pada set data besar diperlukan, RDBMS dapat dikalahkan.

Mengapa Python / Panda Lebih Baik: Yang mengatakan, kecepatan bukanlah segalanya dan dalam banyak kasus penggunaan bukan faktor pendorong. Itu tergantung pada bagaimana Anda menggunakan data, apakah itu dibagikan, dan apakah Anda peduli tentang kecepatan pemrosesan. RDBMS pada umumnya lebih kaku dalam struktur datanya dan membebani pengembang untuk lebih deterministik dengan bentuk data. Panda membuat Anda lebih longgar di sini. Juga, dan ini adalah alasan favorit saya, Anda menggunakan bahasa pemrograman yang sebenarnya. Bahasa pemrograman memberi Anda jauh lebih banyak fleksibilitas untuk menerapkan logika lanjutan ke data. Tentu saja ada juga ekosistem modul yang kaya dan kerangka kerja pihak ke-3 yang tidak bisa didekati oleh SQL. Mampu beralih dari data mentah ke presentasi web atau visualisasi data dalam satu basis kode SANGAT nyaman. Ini juga jauh lebih portabel. Anda dapat menjalankan Python hampir di mana saja termasuk buku catatan umum yang dapat memperluas jangkauan hasil Anda untuk mencapai orang lebih cepat. Basis data tidak unggul dalam hal ini.

Saranku? Jika Anda menemukan diri Anda lulus untuk kumpulan data yang lebih besar dan lebih besar, Anda berhutang untuk mengambil risiko dan mempelajari bagaimana RDBMS dapat membantu. Saya telah melihat jutaan baris, gabungan multi-tabel, menjumlahkan kueri agregat yang disetel dari 5 menit menjadi 2 detik. Memiliki pemahaman ini di sabuk alat Anda hanya membuat Anda menjadi ilmuwan data yang lebih berpengetahuan luas. Anda mungkin dapat melakukan segalanya di Panda hari ini, tetapi suatu hari Anda mungkin memiliki tugas di mana RDBMS adalah pilihan terbaik.


5

Hal-hal yang dapat dilakukan Panda, yang tidak dapat dilakukan SQL

  1. df.describe()
  2. Merencanakan, misalnya df['population'].plot(kind='hist')
  3. Gunakan dataframe secara langsung untuk pelatihan algoritma pembelajaran mesin

Hal-hal yang dapat dilakukan Panda, saya tidak tahu bahwa SQL dapat melakukannya juga

  1. Ekspor ke csv: df.to_csv('foobar.sv'). Ini penting ketika Anda ingin menunjukkan sesuatu kepada pemilik bisnis yang ingin bekerja dengan Excel. Dan ada df.to_exceljuga. Tetapi dalam SQL, Anda bisa melakukannya SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(terima kasih, vy32!)

1
Bagus. Meskipun sebagian besar dari ini tampak seperti fungsi yang dapat diimplementasikan dalam SQL. (SQL memang memiliki ekspor CSV langsung.)
vy32

Bisakah Anda mengirimi saya permintaan yang mengekspor ke CSV? (Saya hanya tahu alat yang melakukan ini untuk beberapa database berbasis SQL, tapi saya belum pernah melihat permintaan ... jadi saya ragu bahwa ini adalah bagian dari spesifikasi SQL)
Martin Thoma

1
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table; Lihat dev.mysql.com/doc/refman/8.0/id/select-into.html
vy32

Terima kasih banyak, vy! Saya pikir saya akan menyesuaikan jawaban saya ketika saya di rumah :-)
Martin Thoma

Tentu saja. Ingat, file tersebut berakhir di server SQL, bukan klien.
vy32

3

Satu-satunya hal yang tidak tercakup dalam jawaban ini yang ingin saya sebutkan adalah bahwa itu juga tergantung pada bagaimana Anda menggunakan SQL. Ambil busur misalnya. Untuk beberapa alasan tidak ada fungsi arcpy.da yang memiliki banyak fitur eksekusi. Ini benar-benar aneh karena hampir semua perpustakaan python sql lainnya melakukannya. Pernyataan Where di fungsi arcpy.da juga terbatas hingga sekitar 120 karakter. Ini pada dasarnya berarti bahwa jika Anda memiliki jumlah relatif tinggi dari hal-hal yang Anda coba lakukan dengan database Anda, satu-satunya pilihan nyata Anda adalah memanggil fungsi arcpy.da yang Anda pilih beberapa kali, mengubah pernyataan di mana setiap kali Anda melakukannya. Ada beberapa trik yang dapat Anda gunakan untuk membuat proses ini berjalan lebih cepat - Anda dapat mengulangi potongan dataset Anda misalnya - tetapi secara harfiah setiap trik ini jauh lebih lambat daripada hanya menggunakan satu arcpy.da. searchcursor untuk memuat seluruh tabel Anda ke dalam bingkai data panda, dan kemudian memanipulasinya menggunakan panda, numpy, dan, jika data Anda benar-benar sebesar ini, dask. Saya perlu menekankan di sini bahwa panda tidak hanya sedikit lebih cepat dalam kasus ini. Ini menjijikkan lebih cepat. Jauh lebih cepat sehingga saya benar-benar menertawakan diri sendiri karena tidak melakukannya lebih cepat. Menggunakan panda menjatuhkan satu waktu eksekusi skrip dari lebih dari satu jam - saya lupa apakah ini lompatan dari 3,5 jam atau dari 1,5 jam - menjadi 12 menit. Jauh lebih cepat sehingga saya benar-benar menertawakan diri sendiri karena tidak melakukannya lebih cepat. Menggunakan panda menjatuhkan satu waktu eksekusi skrip dari lebih dari satu jam - saya lupa apakah ini lompatan dari 3,5 jam atau dari 1,5 jam - menjadi 12 menit. Jauh lebih cepat sehingga saya benar-benar menertawakan diri sendiri karena tidak melakukannya lebih cepat. Menggunakan panda menjatuhkan satu waktu eksekusi skrip dari lebih dari satu jam - saya lupa apakah ini lompatan dari 3,5 jam atau dari 1,5 jam - menjadi 12 menit.

Satu hal yang perlu diperhatikan adalah bahwa sementara saya bisa melakukan ini dengan sql akan butuh waktu lebih lama untuk saya pelajari. Saya harus mempelajari operasi khusus untuk sql di Access - di situlah data untuk skrip ini berakhir - - sql di Access tidak sekuat yang saya perlukan ketika saya benar-benar ingin melakukan hal ini -, atau Saya harus menulis semua data saya ke database sqlite3, memanipulasi di sana, dan kemudian meletakkannya di Access. Meskipun ini mungkin memberi saya hasil kinerja yang serupa, itu akan membuat skrip saya lebih sulit untuk dimodifikasi di masa depan.

Jadi ya, kadang-kadang Panda dan hanya benar-benar lebih baik daripada menggunakan opsi sql yang Anda miliki . Segala sesuatu yang saya perlu lakukan di sql dilakukan dengan fungsi di panda. Anda juga dapat menggunakan sintaks sql dengan panda jika Anda mau. Ada sedikit alasan untuk tidak menggunakan panda dan sql secara bersamaan.

Satu hal lagi yang ingin saya sebutkan tentang Pandas dan numpy adalah bahwa kedua perpustakaan ini pada dasarnya adalah pendekatan berbasiskan. Anda dapat mengulang melalui kerangka data dan pembuatan seri dengan pustaka ini, tetapi sangat sulit untuk memodifikasi data dalam struktur ini seperti itu sehingga Anda akhirnya akan menulis kode yang lebih efisien - berbasis set - dengan kedua pustaka ini murni karena jauh lebih mudah untuk melakukan. Menjadi "dipandu" jika tidak rail-road menggunakan pendekatan berbasis set bukanlah sesuatu yang saya alami dengan SQL.

Satu hal besar lagi yang saya lupa sebutkan dengan Panda. Uang . Pandas adalah alat yang banyak pekerjaan Ilmu Data ingin Anda tahu cara menggunakannya. Hampir setiap pekerjaan Ilmu Data yang saya lihat telah membayar lebih dari pekerjaan jenis manajemen basis data. Satu-satunya pengecualian untuk ini yang saya perhatikan adalah dalam Rekayasa Data, tetapi saya telah melihat jauh lebih sedikit dari postingan pekerjaan itu. Panda sepertinya membuat Anda lebih banyak uang dalam sekejap.


5
Mungkin sedih bahwa ketika datang ke pekerjaan modern ini tentang memiliki kata kunci yang tepat di resume Anda sebagai lawan dari pendekatan yang Anda ambil untuk memecahkan masalah (dengan asumsi Anda dapat belajar kata kata kunci itu relatif cepat). Sepertinya kata kunci lebih penting daripada pemecahan masalah. Ketika pemecahan masalah untuk X harus melibatkan pembelajaran dan menggunakan teknologi A, B, C, bukan sebaliknya. Saya bertanya-tanya apakah sebagian besar tim pengembangan sekarang menghancurkan hal-hal karena buzzword-isme dan trendiness, kemudian berpikir tentang pemecahan masalah sebagai hal yang sekunder, atau "old-school" karena Anda tidak tahu / menggunakan kata buzzword.
SaltySub2

1
@ ElektrikHead dalam pengalaman saya jika Anda sedang menulis fungsi Anda sendiri yang melibatkan sql di python, lebih mudah untuk hanya menyalahgunakan kursor Anda dan menulis permintaan yang buruk daripada menggunakan panda / numpy. Harus diingat bahwa tidak semua modul / perpustakaan sql dibuat sama. Dalam kasus saya, dengan arcpy.da.SearchCursors dan sejenisnya, benar-benar tidak ada cara yang baik untuk melakukan sesuatu pada banyak catatan secara efisien karena keterbatasan aneh. Jika saya menggunakan panda / numpy ada satu cara yang baik untuk melakukan sesuatu, dan itulah yang saya inginkan ketika menggunakan python.

1
Ahhh, baiklah. Maksud Anda sebuah pipa SQL tenunan pribadi melalui implementasi python dbapi vs menggunakan numpy / panda? Dalam hal ini, ya Gotcha, tidak ada argumen dari saya di sana; diperlukan perawatan! Bunyinya kepada saya sebagai vs SQL biasa yang Anda jelas perlu memahami operasi set dengan, tetapi akan menemukan itu cukup cepat ketika menjalankan query konyol dari klien database.
Kepala Listrik

1
@Steve Ya, tidak akan menghentikan orang yang mencoba untuk secara dinamis memodifikasi hal-hal dalam loop di panda atau sejenisnya :) Saya pikir memahami SQL membantu bekerja di panda secara efektif (meskipun mereka tidak menyembunyikan kesamaan dalam beberapa konsep).
Kepala Listrik

1
@Steve Memang panda juga sangat kuat ... Saya kira salah satu frustrasi saya adalah pengembang dan manajemen keduanya, termasuk saya, tidak menghabiskan waktu yang cukup untuk mengevaluasi solusi dan mengejar tren (di mana uang terlibat untuk mempromosikan diri / perusahaan). Tetapi bahkan dalam lean prototyping / mvp kita harus meletakkan dasar yang tepat untuk penskalaan. SQL, noSQL dan Pandas ... semuanya memiliki tujuan untuk tugas dan proyek yang sesuai pada tahap yang berbeda. Untuk tahun lalu plus, noSQL untuk prototipe lean / mvp tentu membantu saya dalam lebih dari satu cara. SQL akan membutuhkan banyak usaha untuk itu.
SaltySub2

3

Saya pikir saya akan menambahkan bahwa saya melakukan banyak analisis data berdasarkan seri waktu, dan panda resampledan reindexmetode sangat berharga untuk melakukan ini. Ya, Anda dapat melakukan hal serupa di SQL (saya cenderung membuat DateDimensiontabel untuk membantu dengan kueri terkait tanggal), tapi saya hanya menemukan metode panda lebih mudah digunakan.

Juga, seperti yang orang lain katakan, sisa pemodelan saya menggunakan Python, dan saya sering memiliki panggilan web atau file CSV.


2

Saya akan mencoba menjawab pertanyaan ini berdasarkan pengalaman saya sendiri. Berbeda dengan jawaban lain, saya lebih suka Sqluntuk pembelajaran mendalam dan hal-hal yang berhubungan dengan data besar. Ada banyak alasan untuk itu. Seperti yang bisa dilihat di sini ,

Panda menyediakan pengalaman analisis data yang intuitif, kuat, dan cepat pada data tabular. Namun, karena Pandas hanya menggunakan satu utas eksekusi dan mengharuskan semua data berada dalam memori sekaligus, itu tidak menskala dengan baik untuk dataset jauh melebihi skala gigabyte.

B+

Perbedaan lainnya adalah bahwa operasi CRUD di Sql dapat diterapkan didistribusikan dengan kebijakan otorisasi yang berbeda yang tidak mungkin dilakukan dalam panda.

Ini tidak dimaksudkan untuk mengatakan mana yang lebih baik, itu semua tergantung pada tugas Anda. Untuk perhitungan skala besar saya lebih suka Sql dan untuk yang kecil, saya lebih suka panda.

Ada hal-hal lain yang tidak ada dalam panda yang benar-benar penting bagi pengalaman cepat untuk ekstraksi data yang akan saya rujuk nanti. Untuk saat ini, lihat saja di sini .


1

Panda lebih populer karena python dalam bentuk notebook jupyter adalah kotak alat yang paling populer seperti yang digunakan oleh para ilmuwan data di bidang jaringan saraf. Python menjadi langauge "the". Bahkan dimungkinkan untuk menggunakan SQL backend tetapi Anda tidak terikat pada SQL hanya dengan panda.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.