Dlaczego ludzie wolą Pandy niż SQL?

Używam SQL od 1996 roku, więc mogę być stronniczy. Korzystałem intensywnie z MySQL i SQLite 3, ale także Microsoft SQL Server i Oracle.

Zdecydowaną większość operacji, które widziałem, wykonałem za pomocą Pandas, można łatwiej wykonać za pomocą SQL. Obejmuje to filtrowanie zestawu danych, wybieranie określonych kolumn do wyświetlenia, zastosowanie funkcji do wartości itd.

Zaletą SQL jest optymalizator i trwałość danych. SQL ma również komunikaty o błędach, które są jasne i zrozumiałe. Panda ma nieco tajemniczy interfejs API, w którym czasem należy użyć jednego [ stuff ], innym razem potrzebujesz [[ stuff ]], a czasem potrzebujesz .loc. Część złożoności Pand wynika z faktu, że dzieje się tak wiele przeciążeń.

Próbuję więc zrozumieć, dlaczego Pandy są tak popularne.

Prawdziwe pierwsze pytanie brzmi: dlaczego ludzie są bardziej produktywni dzięki abstrakcjom DataFrame niż abstrakcjom czysto SQL.

TLDR; SQL nie jest ukierunkowany na (ludzki) proces tworzenia i debugowania, a DataFrames są.

Głównym powodem jest to, że abstrakcje DataFrame pozwalają konstruować instrukcje SQL, unikając jednocześnie pełnego i nieczytelnego zagnieżdżania. Schemat pisania zagnieżdżonych procedur, komentowania ich w celu sprawdzenia, a następnie odkomentowania, zastępuje się pojedynczymi liniami transformacji. Możesz oczywiście uruchamiać rzeczy wiersz po wierszu w replice (nawet w Spark) i przeglądać wyniki.

Rozważ przykład dodania nowej tabeli przekształconej (kolumna zniekształconego łańcucha) do tabeli, a następnie pogrupowanie według niej i wykonanie pewnych agregacji. SQL staje się dość brzydki. Pandy mogą to rozwiązać, ale brakuje pewnych rzeczy, jeśli chodzi o naprawdę duże zbiory danych lub poszczególne partycje (być może ostatnio ulepszone).

Ramki danych powinny być postrzegane jako wysokopoziomowe interfejsy API do procedur SQL, nawet jeśli w przypadku pand w ogóle nie są renderowane w niektórych planistach SQL.

-

Prawdopodobnie możesz przeprowadzić wiele dyskusji technicznych na ten temat, ale rozważam perspektywę użytkownika poniżej.

Jednym z prostych powodów, dla których możesz zobaczyć o wiele więcej pytań na temat manipulacji danymi Pandas, w przeciwieństwie do SQL, jest to, że używanie SQL z definicji oznacza korzystanie z bazy danych i wiele przypadków użycia w dzisiejszych czasach wymaga po prostu kawałków danych dla „ zadania „gotowe” (z .csv, interfejsu API itp.). W takich przypadkach ładowanie, przechowywanie, manipulowanie i wyodrębnianie z bazy danych nie jest wykonalne.

Jednak biorąc pod uwagę przypadki, w których przypadek użycia może uzasadniać użycie Pandy lub SQL, na pewno się nie mylisz. Jeśli chcesz wykonać wiele powtarzających się zadań związanych z manipulowaniem danymi i zachować wyniki, zawsze zalecałbym najpierw przejście przez SQL. Z tego, co widziałem, powód, dla którego wielu użytkowników, nawet w tych przypadkach, nie korzysta z SQL, jest dwojaki.

Po pierwsze, główną zaletą pand w porównaniu z SQL jest to, że jest częścią szerszego wszechświata Pythona, co oznacza, że ​​za jednym zamachem mogę ładować, czyścić, manipulować i wizualizować moje dane (mogę nawet wykonywać SQL poprzez Pandas ...). Po drugie, zbyt wielu użytkowników nie zna zakresu możliwości SQL. Każdy początkujący uczy się składni SQL (SELECT, FROM, WHERE itp.) Jako sposobu na przeniesienie danych z bazy danych do następnego miejsca. Niektórzy mogą wybrać bardziej zaawansowaną składnię grupowania i iteracji. Ale potem pojawia się znaczna przepaść wiedzy, dopóki nie dojdziesz do ekspertów (DBA, Data Engineers itp.).

tl; dr: Często zależy to od przypadku użycia, wygody lub luki w wiedzy dotyczącej zakresu możliwości SQL.

O ile nakładanie się tych dwóch rzeczy zachodzi na siebie, to porównuje się jabłka z pomarańczami.

panda to zestaw narzędzi do analizy danych zaimplementowany w Pythonie, języku programowania ogólnego przeznaczenia. SQL jest językiem specyficznym dla domeny do wyszukiwania danych relacyjnych (zwykle w systemie zarządzania relacyjnymi bazami danych, których przykładami są SQLite, MySQL, Oracle, SQL Server, PostgreSQL itp.).

SQL implikuje

• praca z danymi w RDBMS *, które mogą, ale nie muszą być odpowiednie do obciążenia, nawet jeśli jest to tylko mała baza danych SQLite,
• znajomość domeny bazy danych (jako użytkownik końcowy, programista i / lub administrator; często sugeruję, że „SQL jest szybszy” to ogromne uproszczenie), oraz
• pokonywanie nieistotnej krzywej uczenia się w efektywnym korzystaniu z SQL, szczególnie w specjalistycznych aplikacjach, takich jak analiza danych (w przeciwieństwie do tworzenia prostych raportów prostych danych).

* Warto podkreślić fakt, że SQL jest tak specyficzny dla domeny, że staje się coraz mniej odpowiedni do pracy z coraz bardziej popularnymi alternatywami dla relacyjnych baz danych, takich jak bazy danych NoSQL . Stanowi to zasadniczą zmianę w sposobie przechowywania i struktury danych, a tak naprawdę nie ma powszechnie powszechnego sposobu dostępu do nich, takiego jak rozwój normalizacji SQL, który ma zostać osiągnięty.

Z drugiej strony Python (pandy są dość „pytoniczne”, więc to prawda), jest elastyczny i dostępny dla osób z różnych środowisk. Może być używany jako „język skryptowy”, jako język funkcjonalny oraz w pełni funkcjonalny język OOP. Możliwości wizualizacji i współdziałanie źródeł danych są wbudowane w pandy, ale możesz dowolnie włączać wszystko, co Python może zrobić w swój przepływ pracy (co jest większością rzeczy); naukowy ekosystem Pythona rozkwitł i zawiera świetne narzędzia, takie jak Notatnik Jupyter i niezbędne biblioteki Scipy, takie jak Matplotlib i Numpy (na których bazują pandy). Istotnymi elementami analizy danych pand jest R- zainspirowane, a statystycy na ogół nie zastanawiają się nad tym, czy używają R (a może coraz częściej pand!) nad umieszczaniem wszystkiego w bazie danych i pisaniem analiz w SQL.

Nie twierdzę, że pandy są lepsze niż SQL i odwrotnie, ale SQL jest narzędziem bardzo specyficznym dla domeny, podczas gdy pandy są częścią gigantycznego, elastycznego i dostępnego ekosystemu. Pracuję z systemami danych geoprzestrzennych, których relacyjne bazy danych stanowią ogromną część, a SQL jest potężnym i niezbędnym narzędziem. Jednak pandy są równie istotną, jeśli nie bardziej istotną częścią mojego codziennego zestawu narzędzi, a SQL często sprowadza się do pobierania danych - być może z pewnym wstępnym przetwarzaniem - więc mogę to robić w pandach.

Po pierwsze, pandy nie są tak popularne. Używam zarówno pand, jak i SQL. Najpierw próbuję zrozumieć zadanie - jeśli można to zrobić w języku SQL, wolę SQL, ponieważ jest on bardziej wydajny niż pandy. Spróbuj pracować na dużych danych (10 000 000 x 50). Spróbuj wykonać operację grupowania zarówno w SQL, jak i pandach. Zrozumiesz.

Używam pand tam, gdzie jest to przydatne - na przykład dzielenie wartości kolumny na tablicę i robienie na niej pewnych rzeczy (np. Wybieranie tylko niektórych wartości z tej tablicy). Teraz tego rodzaju zadanie jest stosunkowo trudne do zakodowania w SQL, ale pandy ułatwią zadanie.

Jestem jedną z tych osób, które korzystałyby (w moim przypadku) z języka R (języka, niekoniecznie narzędzia) w każdym przypadku, gdybym mógł, mimo że znam mój SQL.

Główną korzyścią, którą widzę w potokach Pandas / dplyr / data.table, jest to, że operacje są atomowe i można je czytać od góry do dołu.

W SQL musisz parsować cały skrypt, przeskakując (co jest sumamrizowane, co się łączy i jak - lewy? Wewnętrzny? Prawy ?, czy zastosowano jakieś filtry?), Aby w pełni zrozumieć, co się dzieje.

W Pandas i wsp. Każdy etap potoku jest samodzielny, robi coś z danymi wejściowymi i zwraca dane wyjściowe, ten sekwencyjny proces ułatwia zrozumienie, co się dzieje, ponieważ dla każdej operacji jest jasno określony stan, a nie tylko poziom zapytania.

I tak, możesz wykonywać WITHinstrukcje, ale wymaga to znacznie więcej kodu i nie jest tak jasne, jaki obiekt jest używany w porównaniu do potokowania.

Jestem dość nowy w Pandas / Python, ale mam ponad 20 lat jako SQLServer DBA, architekt, administrator itp. Uwielbiam Pandy i staram się, aby zawsze działać w Pandach przed powrotem do mojej wygody, przytulny świat SQL.

Dlaczego RDBMS są lepsze: Zaletą RDBMS jest ich wieloletnie doświadczenie w optymalizacji szybkości zapytań i operacji odczytu danych. Imponujące jest to, że mogą to zrobić, jednocześnie równoważąc potrzebę optymalizacji prędkości zapisu i zarządzania wysoce równoczesnym dostępem. Czasami te dodatkowe koszty ogólne przewyższają zalety Pandas, jeśli chodzi o proste przypadki użycia przez jednego użytkownika. Ale nawet wtedy doświadczony DBA może dostroić bazę danych, aby była wysoce zoptymalizowana pod kątem szybkości odczytu w porównaniu z prędkością zapisu. DBA mogą korzystać z takich rzeczy, jak optymalizacja przechowywania danych, strategiczny rozmiar strony dysku, wypełnianie / wypełnianie strony, strategie kontrolera danych i partycjonowania dysku, zoptymalizowane plany We / Wy, przypinanie danych w pamięci, wstępnie zdefiniowane plany wykonania, indeksowanie, kompresja danych , i wiele więcej. Mam wrażenie, że wielu programistów Pandas nie „ t zrozumieć głębokość, która jest tam dostępna. Myślę, że zwykle dzieje się tak, że jeśli programista Pandas nigdy nie ma danych wystarczająco dużych, aby potrzebować tych optymalizacji, nie doceniają, ile czasu mogą zaoszczędzić od razu po wyjęciu z pudełka. Świat RDBMS ma 30-letnie doświadczenie w optymalizacji tego, więc jeśli potrzebna jest surowa prędkość na dużych zestawach danych, RDBMS można pokonać.

Dlaczego Python / Pandas jest lepszy: To powiedziawszy, prędkość to nie wszystko, aw wielu przypadkach nie jest czynnikiem napędzającym. To zależy od tego, jak korzystasz z danych, czy są one udostępniane i czy zależy Ci na szybkości przetwarzania. RDBMS są na ogół bardziej sztywne w swoich strukturach danych i nakładają na programistę obciążenie, które jest bardziej deterministyczne w zakresie kształtów danych. Pandy pozwalają ci być bardziej luźnym. I to jest mój ulubiony powód, że jesteś w prawdziwym języku programowania. Języki programowania zapewniają nieskończenie większą elastyczność w stosowaniu zaawansowanej logiki do danych. Oczywiście istnieje również bogaty ekosystem modułów i struktur zewnętrznych, do których SQL nie może się zbliżyć. Możliwość przejścia od nieprzetworzonych danych do prezentacji internetowej lub wizualizacji danych w jednej bazie kodu jest BARDZO wygodna. Jest także znacznie bardziej przenośny. Możesz uruchomić Python niemal wszędzie, w tym zeszyty publiczne, które mogą zwiększyć zasięg twoich wyników i szybciej dotrzeć do ludzi. Bazy danych nie przodują w tym.

Moja rada? Jeśli zauważysz, że przechodzisz na coraz większe zbiory danych, musisz się zanurzyć i dowiedzieć się, w jaki sposób RDBMS może pomóc. Widziałem milion wierszy, łączenie wielu tabel, sumowane zapytania zagregowane z 5 minut do 2 sekund. To zrozumienie w pasku narzędzi czyni z ciebie bardziej zaokrąglonego naukowca danych. Możesz być w stanie zrobić wszystko w Pandach dzisiaj, ale pewnego dnia możesz mieć zadanie, w którym RDBMS jest najlepszym wyborem.

Rzeczy, które Pandy mogą zrobić, czego nie potrafi SQL

1. df.describe()
2. Rysowanie, np df['population'].plot(kind='hist')
3. Użyj ramki danych bezpośrednio do szkolenia algorytmów uczenia maszynowego

Rzeczy, które potrafi zrobić Panda, nie wiedziałem, że SQL potrafi również

1. Eksport do csv: df.to_csv('foobar.sv'). Jest to ważne, gdy chcesz pokazać coś właścicielowi firmy, który chce pracować z programem Excel. I jest df.to_excelteż. Ale w SQL możesz to zrobić SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(dziękuję, vy32!)

Jedyną rzeczą nieuwzględnioną w tych odpowiedziach, o której chciałbym wspomnieć, jest to, że zależy to również od tego, jak używasz SQL. Weźmy na przykład arcpy. Z jakiegoś powodu żadna z funkcji arcpy.da nie ma funkcji wykonywania wielu. To jest naprawdę dziwne, ponieważ robi to prawie każda inna biblioteka języka Python SQL. Instrukcja Where w funkcjach arcpy.da jest również ograniczona do około 120 znaków. Zasadniczo oznacza to, że jeśli masz dość dużą liczbę rzeczy, które próbujesz zrobić z bazą danych, jedynym prawdziwym wyborem jest wielokrotne wywołanie wybranej funkcji arcpy.da, zmieniając za każdym razem instrukcję where. Istnieje kilka sztuczek, których można użyć, aby przyspieszyć ten proces - na przykład możesz iterować fragmenty zbioru danych - ale dosłownie każda z tych sztuczek jest znacznie wolniejsza niż użycie jednego pliku arcpy.da. searchcursor, aby załadować całą tabelę do ramki danych pand, a następnie manipulować nią za pomocą pand, numpy i, jeśli twoje dane są tak ogromne, dask. Muszę tutaj podkreślić, że w tym przypadku pandy nie są tylko trochę szybsze. Jest obrzydliwie szybszy. Jest o wiele szybszy, że dosłownie śmiałem się z siebie, że nie zrobiłem tego wcześniej. Korzystanie z pand skróciło czas wykonywania jednego skryptu ze znacznie ponad godziny - zapominam, czy był to skok z 3,5 godziny, czy z 1,5 godziny - do dosłownie 12 minut. jest o wiele szybszy, że dosłownie śmiałem się z siebie, że nie zrobiłem tego wcześniej. Korzystanie z pand skróciło czas wykonywania jednego skryptu ze znacznie ponad godziny - zapominam, czy był to skok z 3,5 godziny, czy z 1,5 godziny - do dosłownie 12 minut. jest o wiele szybszy, że dosłownie śmiałem się z siebie, że nie zrobiłem tego wcześniej. Korzystanie z pand skróciło czas wykonywania jednego skryptu ze znacznie ponad godziny - zapominam, czy był to skok z 3,5 godziny, czy z 1,5 godziny - do dosłownie 12 minut.

Należy zauważyć, że chociaż mógłbym to zrobić za pomocą SQL, zajęłoby mi to dużo więcej czasu. Musiałbym albo nauczyć się operacji specjalnie dla sql w Accessie - tam właśnie skończyły się dane dla tego skryptu - - sql w Accessie nie był tak solidny, jak powinienem być, kiedy tak naprawdę chciałem to zrobić - lub Musiałbym zapisać wszystkie moje dane w bazie danych sqlite3, zmanipulować je, a następnie umieścić w programie Access. Chociaż może to dać mi podobne wyniki wydajności, trudniej byłoby zmodyfikować mój skrypt w przyszłości.

Więc tak, czasami Pandy i jest po prostu zdecydowanie lepsze niż korzystanie z opcji SQL, które masz do dyspozycji . Wszystko, co musiałem zrobić w sql, zostało zrobione z funkcją w pandach. Możesz także użyć składni sql z pandami, jeśli chcesz. Nie ma powodu, aby nie używać pand i sql w tandemie.

Jeszcze jedną rzeczą, o której chcę wspomnieć o Pandach i Numpy, jest to, że obie te biblioteki są z natury oparte na zestawach. Możesz przeszukiwać ramki danych i tworzyć serie za pomocą tych bibliotek, ale naprawdę trudno jest modyfikować dane w takich strukturach, więc skończysz na pisaniu bardziej wydajnego - opartego na zestawie kodu - w obu tych bibliotekach tylko dlatego, że o wiele łatwiej jest zrobić. Bycie „prowadzonym”, jeśli nie nakierowanym na podejście oparte na zestawach, nie jest czymś, czego doświadczyłem w SQL.

Jeszcze jedna ogromna rzecz, o której zapomniałem wspomnieć o Pandach. Pieniądze . Pandy to narzędzie, z którego wiele zadań związanych z nauką danych chce wiedzieć, jak korzystać. Prawie każde zadanie w zakresie Data Science, na które spojrzałem, opłacało więcej niż zadania typu zarządzanie bazą danych. Jedyny wyjątek od tego, co zauważyłem, dotyczy inżynierii danych, ale widziałem znacznie mniej takich ofert pracy. Wygląda na to, że pandy na pierwszy rzut oka dają więcej pieniędzy.

Pomyślałem, że dodam, że wykonuję wiele analiz danych na podstawie szeregów czasowych, a pandy resamplei reindexmetody są do tego nieocenione. Tak, możesz robić podobne rzeczy w SQL (zwykle tworzę DateDimensiontabelę, aby pomóc w zapytaniach związanych z datą), ale uważam, że metody pand są znacznie łatwiejsze w użyciu.

Ponadto, jak powiedzieli inni, reszta mojego modelowania jest w Pythonie i często mam połączenia internetowe lub pliki CSV.

Spróbuję odpowiedzieć na to pytanie na podstawie własnego doświadczenia. W przeciwieństwie do innych odpowiedzi, wolę Sqlgłębokie uczenie się i rzeczy związane z dużymi danymi. Jest tego wiele przyczyn. Jak widać tutaj ,

Panda zapewnia intuicyjną, wydajną i szybką analizę danych tabelarycznych. Ponieważ jednak Pandas używa tylko jednego wątku wykonania i wymaga, aby wszystkie dane były w pamięci jednocześnie, nie skaluje się dobrze do zestawów danych znacznie powyżej skali gigabajtów.

$B ^+$

Inną różnicą jest to, że operacje CRUD w Sql mogą być stosowane rozproszone z różnymi zasadami autoryzacji, które nie są możliwe w pandach.

Nie ma na celu powiedzieć, co jest lepsze, wszystko zależy od twojego zadania. Do obliczeń na dużą skalę wolę Sql, a do małych - pandy.

Są inne rzeczy, których nie ma w pandach, które są naprawdę ważne dla szybkiego doświadczenia w wydobywaniu danych, o których powiem później. Na razie spójrz tutaj .

Panda jest bardziej popularna, ponieważ python w postaci notatników jupyter jest najbardziej popularnym zestawem narzędzi wykorzystywanym przez naukowców z obszaru sieci neuronowych. Python staje się „językiem”. Możliwe jest nawet użycie backendu SQL, ale nie jesteś związany SQL tylko z pandą.

Nie do końca odpowiedź na pytanie, ale ponieważ sam przybyłem tutaj, aby poszukać różnic w praktycznym zastosowaniu:

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