사람들은 왜 Pandas를 SQL보다 선호합니까?

1996 년부터 SQL을 사용해 왔기 때문에 편견이있을 수 있습니다. MySQL과 SQLite 3을 광범위하게 사용했지만 Microsoft SQL Server와 Oracle도 사용했습니다.

Pandas로 수행 한 대부분의 작업은 SQL로 더 쉽게 수행 할 수 있습니다. 여기에는 데이터 집합 필터링, 표시 할 특정 열 선택, 값에 함수 적용 등이 포함됩니다.

SQL에는 옵티 마이저 및 데이터 지속성이 있다는 장점이 있습니다. SQL에는 명확하고 이해하기 쉬운 오류 메시지도 있습니다. 팬더에는 다소 암호화 된 API가 있습니다.이 API는 때로는 단일 [ stuff ], 다른 시간을 필요 [[ stuff ]]로하며 때로는을 사용해야하는 경우가 있습니다 .loc. 팬더의 복잡성 중 일부는 너무 많은 과부하가 발생한다는 사실에서 비롯됩니다.

그래서 Pandas가 왜 그렇게 인기가 있는지 이해하려고합니다.

실제 첫 번째 질문은 사람들이 왜 순수 SQL 추상화보다 DataFrame 추상화로 생산성이 더 높은가입니다.

TLDR; SQL은 (인간적인) 개발 및 디버깅 프로세스에 중점을 두지 않으며 DataFrames는 있습니다.

주된 이유는 DataFrame 추상화를 통해 상세하고 읽기 어려운 중첩을 피하면서 SQL 문을 구성 할 수 있기 때문입니다. 중첩 된 루틴을 작성하고 주석을 달아 주석 처리 한 후 주석을 해제하는 패턴은 단일 변환 행으로 대체됩니다. 자연스럽게 (물론 스파크에서도) 한 줄씩 사물을 실행하고 결과를 볼 수 있습니다.

테이블에 새 변환 된 (문자열 맹 글링 된 열)을 추가 한 다음 그룹화하고 집계를 수행하는 예를 고려하십시오. SQL은 꽤 추악합니다. 팬더는이 문제를 해결할 수 있지만 실제로 큰 데이터 또는 특정 파티션 (아마도 최근 개선)과 관련하여 몇 가지 사항이 누락되었습니다.

DataFrames는 팬더를 사용하더라도 일부 SQL 플래너에 렌더링되지 않더라도 SQL 루틴에 대한 고급 API로 간주되어야합니다.

-

이것에 대해 많은 기술 토론을 할 수 있지만 아래 사용자 관점을 고려하고 있습니다.

SQL과 달리 Pandas 데이터 조작에 대해 더 많은 질문을 볼 수있는 한 가지 간단한 이유는 정의에 따라 SQL을 사용하는 것이 데이터베이스를 사용한다는 의미이며 요즘에는 많은 유스 케이스가 ' 일대일 작업 (.csv, 웹 API 등) 이 경우 데이터베이스에서로드, 저장, 조작 및 추출이 불가능합니다.

그러나 사용 사례가 Pandas 또는 SQL을 사용하여 정당화 될 수있는 경우를 고려할 때 확실히 틀린 것은 아닙니다. 많은 반복적 인 데이터 조작 작업을 수행하고 출력을 유지하려면 항상 SQL을 먼저 시도하는 것이 좋습니다. 이 경우에도 많은 사용자가 SQL을 거치지 않는 이유는 두 가지입니다.

첫째, 팬더가 SQL에 비해 갖는 주요 이점은 더 넓은 파이썬 세계의 일부라는 것입니다. 즉, 한 번에 실패하면 데이터를로드, 정리, 조작 및 시각화 할 수 있습니다 (팬더를 통해 SQL을 실행할 수도 있습니다 ...). 다른 하나는, 너무 많은 사용자가 SQL의 기능 범위를 모른다는 것입니다. 모든 초보자는 DB에서 다음 장소로 데이터를 가져 오기위한 수단으로 SQL의 '추출 구문'(SELECT, FROM, WHERE 등)을 배웁니다. 일부는 더 고급 그룹화 및 반복 구문 중 일부를 선택할 수 있습니다. 그러나 그 후에는 전문가 (DBA, 데이터 엔지니어 등)에게 다가 갈 때까지 지식이 상당히 부족한 경향이 있습니다.

tl; dr : 종종 SQL의 기능 범위에 대한 사용 사례, 편의성 또는 지식의 차이로 인해 발생합니다.

이 두 가지를 겹치게하는 것은 사과와 오렌지를 비교하는 것입니다.

pandas는 범용 프로그래밍 언어 인 Python으로 구현 된 데이터 분석 툴킷입니다. SQL은 관계형 데이터를 쿼리하기위한 도메인 별 언어입니다 (일반적으로 SQLite, MySQL, Oracle, SQL Server, PostgreSQL 등이 예인 관계형 데이터베이스 관리 시스템에서).

SQL은 암시

• 작은 SQLite 데이터베이스 인 경우에도 워크로드에 적합하지 않을 수있는 RDBMS *의 데이터 작업
• 데이터베이스 도메인 지식 (최종 사용자, 개발자 및 / 또는 관리자로서, "SQL이 더 빠름"이라는 제안은 종종 지나치게 단순화 된 것임)
• SQL을 효과적으로 사용하는 데있어 중요하지 않은 학습 곡선을 극복하는 것, 특히 데이터 분석과 같은 특수 응용 프로그램에서 (단순한 데이터에 대한 간단한 보고서를 작성하는 것과는 대조적으로).

* SQL이 도메인에 따라 다르기 때문에 NoSQL 데이터베이스 와 같은 관계형 데이터베이스에 대한 일반적인 대안을 사용하는 것이 훨씬 덜 중요하다는 사실을 강조 할 가치가 있습니다. 이는 데이터 저장 및 구조 방식의 근본적인 변화를 나타내며 달성하려는 SQL 표준화의 개발과 같이 데이터에 액세스하는 보편적 인 방법은 실제로 없습니다.

반면에 파이썬은 (판다는 상당히 "pythonic"이므로 여기서는 사실이다) 유연하고 다양한 배경을 가진 사람들이 접근 할 수 있습니다. "스크립트 언어", 기능 언어 및 모든 기능을 갖춘 OOP 언어로 사용할 수 있습니다. 시각화 기능과 데이터 소스 상호 운용성은 팬더에 내장되어 있지만 Python으로 할 수있는 모든 것을 워크 플로에 자유롭게 통합 할 수 있습니다 (대부분의 작업). 과학적인 파이썬 생태계는 확장되었으며 Jupyter Notebook 과 같은 훌륭한 도구와 matplotlib 및 numpy (팬더가 빌드하는) 와 같은 필수 scipy 라이브러리를 포함 합니다. 팬더 데이터 분석의 중요한 요소는 R입니다.-영감을 얻었고 일반적으로 데이터베이스에 모든 것을 넣고 SQL로 분석을 작성하는 데 R (또는 아마도 팬더가 더 많이 사용됩니다!)을 사용하는지 여부에 대해 통계학자가 모으고 아프게하지 않습니다.

팬더가 SQL보다 낫다는 것을 말하는 것은 아니며 그 반대도 마찬가지입니다. 그러나 SQL은 도메인 고유의 도구이지만 팬더는 거대하고 유연하며 액세스 가능한 생태계의 일부입니다. 관계형 데이터베이스가 큰 지리 공간 데이터 시스템을 다루고 있으며 SQL은 강력하고 필수적인 도구입니다. 그러나 팬더는 일상적인 툴킷의 필수 요소가 아닌 경우에도 동일하게 적용되며 SQL은 종종 데이터를 가져 오는 것으로 유명합니다. 일부 전처리와 함께 팬더에서 할 수 있습니다.

첫째, 팬더는 그렇게 인기가 없습니다. 팬더와 SQL을 모두 사용합니다. 먼저 작업을 이해하려고합니다. SQL로 수행 할 수 있다면 팬더보다 효율적이기 때문에 SQL을 선호합니다. 큰 데이터 (10,000,000 x 50)로 작업 해보십시오. 일부 해보려고 GROUPBY의 SQL과 팬더 모두에서 작동합니다. 당신은 이해할 것입니다.

열 값을 배열로 분할하고 배열에서 일부 값만 선택하는 것과 같이 일부 작업을 수행하는 것과 같이 편리한 팬더를 사용합니다. 이제 이런 종류의 작업은 SQL로 코딩하기가 상대적으로 어렵지만 팬더는 작업을 쉽게 해줍니다.

나는 내 SQL을 알고 있더라도 모든 경우에 R의 dplyr (필수 도구는 아니지만 언어)을 사용하는 사람들 중 하나입니다.

Pandas / dplyr / data.table 파이프 라인에서 볼 수있는 주요 이점은 작업이 원자 적이며 위에서 아래로 읽을 수 있다는 것입니다.

SQL에서는 전체 스크립트를 구문 분석하고, 무슨 일이 일어나고 있는지, 무엇을 합쳤는지, 무엇이 합류하고 무엇이 남았습니까? 내부? 오른쪽? 어떤 필터가 적용됩니까?

Pandas 등에서 파이프 라인의 각 단계는 자체 포함되어 있으며 입력 데이터로 무언가를 수행하고 출력 데이터를 반환합니다.이 순차적 프로세스는 각 작업에 대해 명확하게 정의 된 상태가 아니기 때문에 발생하는 상황에 대해 쉽게 추론 할 수 있습니다. 쿼리 수준

그리고 네, WITH진술을 할 수는 있지만 훨씬 더 많은 코드가 필요하며 배관과 비교하여 어떤 객체가 사용되고 있는지 명확하지 않습니다.

저는 Pandas / Python을 처음 접했지만 SQLServer DBA, 설계자, 관리자 등으로 20 년 이상을 지 냈습니다. 저는 Pandas를 좋아하고 항상 편안하게 돌아 가기 전에 Pandas에서 일을하도록 노력하고 있습니다. 아늑한 SQL 세상.

RDBMS가 더 나은 이유 : RDBMS의 장점은 쿼리 속도 및 데이터 읽기 작업을 최적화 한 다년간의 경험입니다. 인상적인 점은 쓰기 속도를 최적화하고 동시에 동시 액세스를 관리 할 필요성의 균형을 유지하면서이를 수행 할 수 있다는 것입니다. 간혹 단일 사용자 사용 사례와 관련하여 이러한 추가 오버 헤드로 인해 Pandas의 이점이 줄어 듭니다. 그럼에도 불구하고 노련한 DBA는 쓰기 속도에 대한 읽기 속도에 대해 고도로 최적화되도록 데이터베이스를 조정할 수 있습니다. DBA는 데이터 스토리지 최적화, 전략적 디스크 페이지 크기 조정, 페이지 채우기 / 패딩, 데이터 컨트롤러 및 디스크 파티셔닝 전략, 최적화 된 I / O 계획, 메모리 내 데이터 고정, 사전 정의 된 실행 계획, 인덱싱, 데이터 압축과 같은 기능을 활용할 수 있습니다. , 그리고 더 많은. 많은 팬더 개발자들로부터 사용 가능한 깊이를 이해하지 마십시오. 필자가 일반적으로 생각하는 것은 Pandas 개발자가 이러한 최적화를 필요로 할 정도로 큰 데이터를 가지고 있지 않으면 시간을 얼마나 절약 할 수 있는지에 대해 감사하지 않는 것입니다. RDBMS 세계는이를 최적화 한 30 년의 경험을 가지고 있으므로 대규모 데이터 세트의 원시 속도가 필요한 경우 RDBMS를 능가 할 수 있습니다.

파이썬 / 팬더가 더 나은 이유 : 즉, 속도는 모든 것이 아니며 많은 사용 사례에서 추진 요인이 아닙니다. 데이터 사용 방법, 공유 여부 및 처리 속도에 대한 관심 여부에 따라 다릅니다. RDBMS는 일반적으로 데이터 구조가 더 엄격하며 개발자가 데이터 형태에 대해보다 결정적인 부담을 가중시킵니다. 팬더를 사용하면 더 느슨해 질 수 있습니다. 또한 이것이 제가 가장 좋아하는 이유입니다. 당신은 진정한 프로그래밍 언어에 있습니다. 프로그래밍 언어를 사용하면 데이터에 고급 논리를 적용 할 수있는 유연성이 훨씬 높아집니다. 물론 SQL이 접근 할 수없는 풍부한 모듈 에코 시스템과 타사 프레임 워크도 있습니다. 하나의 코드베이스에서 원시 데이터에서 웹 프리젠 테이션 또는 데이터 시각화로 이동할 수있는 것이 매우 편리합니다. 또한 휴대 성이 훨씬 뛰어납니다. 결과의 범위를 확장하여 사람들에게 더 빨리 접근 할 수있는 공개 노트북을 포함하여 거의 모든 곳에서 Python을 실행할 수 있습니다. 데이터베이스는이 점에서 뛰어나지 않습니다.

내 조언? 더 크고 더 큰 데이터 세트를 졸업 한 경우, 급락하여 RDBMS가 어떻게 도움이되는지 배워야합니다. 백만 행, 다중 테이블 조인, 합계 집계 쿼리가 5 분에서 2 초로 조정 된 것을 보았습니다. 공구 벨트에 대한 이러한 이해가 있으면보다 둥근 데이터 과학자가 될 수 있습니다. 오늘 Pandas에서 모든 것을 할 수 있지만 언젠가 RDBMS가 최선의 선택이 될 수 있습니다.

팬더가 할 수있는 일, SQL이 할 수없는 일

1. df.describe()
2. 플로팅 df['population'].plot(kind='hist')
3. 머신 러닝 알고리즘 교육을 위해 직접 데이터 프레임 사용

팬더가 할 수있는 일, SQL도 할 수 있다는 것을 몰랐습니다.

1. csv로 내보내기 : df.to_csv('foobar.sv'). 이것은 Excel로 작업하려는 비즈니스 소유자에게 무언가를 보여주고 싶을 때 중요합니다. 그리고 또한 df.to_excel있습니다. 그러나 SQL에서는 할 수 있습니다 SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(감사합니다, vy32!)

이 답변에서 다루지 않은 유일한 것은 SQL 사용 방법에 달려 있다는 것입니다. 예를 들어 아크 피를 가져 가라. 어떤 이유로 든 arcpy.da 함수 중 어느 것도 많은 기능을 실행하지 않습니다. 다른 모든 파이썬 SQL 라이브러리가하기 때문에 이것은 정말 이상합니다. arcpy.da 함수의 Where 문도 약 120 자로 제한됩니다. 이것은 본질적으로 데이터베이스와 관련하여 상대적으로 많은 수의 작업을 수행하려는 경우 선택한 arcpy.da 함수를 여러 번 호출하여 매번 where 문을 변경하는 것이 유일한 선택입니다. 이 프로세스를 더 빠르게하기 위해 사용할 수있는 몇 가지 트릭이 있습니다. 예를 들어 데이터 집합을 반복 할 수 있습니다. 그러나 문자 그대로 이러한 모든 트릭은 하나의 arcpy.da를 사용하는 것보다 훨씬 느립니다. searchcursor를 사용하여 전체 테이블을 팬더 데이터 프레임에로드 한 다음 팬더, numpy를 사용하여 테이블을 조작하고 데이터가 실제로이 방대한 경우에는 위험합니다. 나는이 경우 팬더가 조금 더 빠르지 않다는 것을 강조해야합니다. 역겨운 속도입니다. 너무 빨라서 문자 그대로 더 빨리하지 않는 것에 대해 스스로 웃고있었습니다. 팬더를 사용하면 스크립트 실행 시간이 1 시간이 넘게 줄어 들었습니다.이 시간이 3.5 시간에서 1.5 시간에서 말 그대로 12 분으로 점프했는지 잊어 버렸습니다. 너무 빨라서 문자 그대로 더 빨리하지 않는 것에 대해 스스로 웃고있었습니다. 팬더를 사용하면 스크립트 실행 시간이 1 시간이 넘게 줄어 들었습니다.이 시간이 3.5 시간에서 1.5 시간에서 말 그대로 12 분으로 점프했는지 잊어 버렸습니다. 너무 빨라서 문자 그대로 더 빨리하지 않는 것에 대해 스스로 웃고있었습니다. 팬더를 사용하면 스크립트 실행 시간이 1 시간이 넘게 줄어 들었습니다.이 시간이 3.5 시간에서 1.5 시간에서 말 그대로 12 분으로 점프했는지 잊어 버렸습니다.

한 가지 주목할 점은 SQL 로이 작업을 수행 할 수는 있지만 배우는 데 더 오래 걸렸다는 것입니다. Access에서 sql에 대한 작업을 구체적으로 배워야했을 것입니다.이 스크립트의 데이터가 끝났습니다 .- Access의 sql은 실제로이 작업을 수행 할 때 필요한만큼 강력하지 않았습니다. 모든 데이터를 sqlite3 데이터베이스에 작성하고 거기에서 조작 한 다음 Access에 저장해야했습니다. 이로 인해 비슷한 성능 결과를 얻을 수 있었지만 나중에 스크립트를 수정하기가 어려웠습니다.

그렇습니다. 때로는 Pandas가 있으며 원하는 SQL 옵션을 사용하는 것보다 엄격하게 좋습니다 . SQL에서해야 할 모든 것은 팬더의 함수로 수행되었습니다. 원하는 경우 팬더와 함께 SQL 구문을 사용할 수도 있습니다. 팬더와 SQL을 함께 사용하지 않는 이유는 거의 없습니다.

Pandas와 numpy에 대해 언급하고 싶은 또 다른 것은이 두 라이브러리 모두 기본적으로 설정 기반 접근 방식이라는 것입니다. 이러한 라이브러리를 사용하여 데이터 프레임 및 시리즈 빌드를 반복 할 수는 있지만 이러한 구조에서 데이터를 수정하는 것은 실제로 어렵 기 때문에 두 라이브러리를 모두 사용하여 더 효율적인 코드-세트 기반-를 작성하는 것이 훨씬 쉽습니다. 하다. 집합 기반 접근 방식을 사용하지 않는 경우 "안내"되는 것은 SQL에서 경험 한 것이 아닙니다.

팬더와 함께 언급하는 것을 잊어 버린 것 하나 더. 돈 . Pandas는 많은 데이터 과학 작업에서 사용법을 알고 싶어하는 도구입니다. 내가 본 모든 Data Science 작업은 데이터베이스 관리 유형 작업보다 많은 비용을 지불했습니다. 내가 주목 한 유일한 예외는 데이터 엔지니어링이지만, 그 채용 공고는 훨씬 적습니다. 팬더는 한 눈에 더 많은 돈을 버는 것처럼 보입니다.

나는 시계열 기반의 많은 데이터 분석을 수행한다고 덧붙이고 팬더 resample와 reindex방법은 이것을 수행하는 데 매우 중요합니다. 예, SQL에서 비슷한 작업을 수행 할 수 있습니다 ( DateDimension날짜 관련 쿼리를 돕기 위해 테이블 을 만드는 경향이 있습니다 ).하지만 팬더 방법을 사용하기가 훨씬 쉽습니다.

또한 다른 사람들이 말했듯이 나머지 모델링은 Python으로되어 있으며 종종 웹 호출이나 CSV 파일이 있습니다.

본인의 경험을 바탕으로이 질문에 답변하려고합니다. 다른 답변과 달리 Sql딥 러닝 및 빅 데이터 관련 항목을 선호 합니다. 그 이유는 여러 가지가 있습니다. 여기 에서 볼 수 있듯이

Pandas는 테이블 형식 데이터에 대해 직관적이고 강력하며 빠른 데이터 분석 환경을 제공합니다. 그러나 Pandas는 하나의 실행 스레드 만 사용하고 모든 데이터가 한 번에 메모리에 있어야하므로 기가 바이트 규모를 넘어서는 데이터 세트로 확장 할 수 없습니다.

SQL 엔진은 일반적으로 와 같은 데이터 구조에 키 또는 특수 열을 유지합니다.$B ^+$ CRUD 작업을 용이하게하기 위해 트리 . 이 데이터 구조는 데이터베이스의 모든 데이터 상태를 유지합니다. 팬더가 모든 데이터에 동시에 액세스 할 수 없기 때문에 할 수있는 것은 아닙니다. 반면에 read_csv에 사용 된 청크 매개 변수로도 일부 작업을 수행 할 수 없습니다. 예를 들어, 메모리에서 수용 할 수없는 대용량 데이터 세트에 대해서는 직접 배치 작업을 수행 할 수 없습니다. 전체 데이터 세트에 의존하는 다른 작업에는 추가 코딩이 필요합니다. 이들 모두는 간단한 쿼리만으로 추가 코딩없이 Sql에서 처리 할 수 ​​있습니다. 간단한 SQL 작업은 메모리에 대한 두려움없이 사용됩니다.

또 다른 차이점은 Sql의 CRUD 작업을 팬더에서는 불가능한 다른 권한 부여 정책으로 배포 할 수 있다는 것입니다.

어느 쪽이 더 낫다는 말은 아닙니다. 모두 당신의 임무에 달려 있습니다. 대규모 계산의 경우 Sql을 선호하고 작은 계산의 경우 팬더를 선호합니다.

팬더에없는 다른 것들이 있습니다. 나중에 언급 할 데이터 추출에 대한 빠른 경험에 정말로 중요합니다. 지금은 여기 를 보십시오 .

팬더는 주피터 노트북 형태의 파이썬이기 때문에 신경망 영역의 데이터 과학자가 사용하는 가장 대중적인 도구 상자이기 때문에 더 인기가 있습니다. 파이썬은 "언어"가되고있다. SQL 백엔드를 사용할 수도 있지만 팬더로만 SQL에 바인딩하지는 않습니다.

질문에 대한 정확한 대답은 아니지만 실제 적용에서 차이점을 찾기 위해 여기에 왔습니다.

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