팬더가 data.table보다 빠릅니다.


17

https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping

data.table 벤치 마크는 2014 년 내가 들어 본 곳 이후 업데이트되지 않은 Pandas지금보다 더 빨리이다 data.table. 이것이 사실입니까? 누구든지 벤치 마크를 했습니까? 나는 전에 파이썬을 사용한 적이 없지만 pandas이길 수 있다면 전환을 고려할 것 data.table입니까?


7
그것은 파이썬으로 전환 해야하는 정말 나쁜 이유입니다.
— Matthew Drury

2
@MatthewDrury 어떻게 그렇게? 데이터와 데이터 조작은 내 업무의 80 %입니다. 20 %만이 모델과 프리젠 테이션에 적합합니다. 왜 가장 빠른 결과를 제공하는 것을 선택해서는 안됩니까?
— xiaodai

2
파이썬과 R은 모두 거대한 생태계와 커뮤니티를 가진 확립 된 언어입니다. 하나의 도서관에 대한 선택을 줄이는 것은 광대 한 숲에서 하나의 나무를 숭배하는 것입니다. 그럼에도 불구하고 효율성은 단일 라이브러리의 경우에도 많은 관심사 중 하나입니다 (인터페이스 표현 방식, 다른 라이브러리에 연결하는 방법, 코드베이스 확장 성, 개발자 개방성). 나는 선택 자체가 거짓 이분법이라고 주장한다. 두 커뮤니티 모두 다른 초점을 가지고 있으며, 이는 언어에 다른 강점을 부여합니다.
— Matthew Drury

3
작업의 20 %에 적합한 거대한 숲이 있습니까? 작업의 80 %에 영향을 미치는 선택을하지 않습니까? 팬더를 사용하여 데이터 준비를 수행 한 다음 R python 또는 Julia에서 모델링하는 것을 막을 수는 없습니다. 내 생각은 건전하다고 생각합니다. 팬더가 더 빠르면 주 도구로 선택해야합니다.
— xiaodai

1
당신은 찾을 수 있습니다 그물 관심 / 사용의 R에 패키지를. 또한 R이 데이터베이스와 작업 / 재생하도록하는 데 많은 노력이 기울여지고 있습니다 ( dbplyr 과 같은 노력 참조 ).
— slackline

답변:


15

누구든지 벤치 마크를 했습니까?

예, 귀하의 질문에 링크 한 벤치 마크는 최근 버전의 data.table 및 pandas에 대해 최근 업데이트되었습니다. 또한 다른 소프트웨어가 추가되었습니다. 업데이트 된 벤치 마크는 https://h2oai.github.io/db-benchmark 에서 찾을 수 있습니다.
불행히도 125GB 메모리 시스템 (원래 시스템은 244GB가 아님)에 예약되어 있습니다. 결과적으로 팬더와 dask는 groupby데이터를 읽을 때 메모리가 부족하여 1e9 행 (50GB csv) 데이터를 시도 할 수 없습니다 . 따라서 팬더와 data.table의 경우 1e8 행 (5GB) 데이터를 봐야합니다.

요청한 콘텐츠를 연결하기 위해 해당 솔루션에 대한 최신 타이밍을 붙여 넣습니다.

그 타이밍은 오래 참고하시기 바랍니다
방문 https://h2oai.github.io/db-benchmark을 업데이트 타이밍에 대한

| in_rows|question              | data.table| pandas|
|-------:|:---------------------|----------:|------:|
|   1e+07|sum v1 by id1         |      0.140|  0.414|
|   1e+07|sum v1 by id1:id2     |      0.411|  1.171|
|   1e+07|sum v1 mean v3 by id3 |      0.574|  1.327|
|   1e+07|mean v1:v3 by id4     |      0.252|  0.189|
|   1e+07|sum v1:v3 by id6      |      0.595|  0.893|
|   1e+08|sum v1 by id1         |      1.551|  4.091|
|   1e+08|sum v1 by id1:id2     |      4.200| 11.557|
|   1e+08|sum v1 mean v3 by id3 |     10.634| 24.590|
|   1e+08|mean v1:v3 by id4     |      2.683|  2.133|
|   1e+08|sum v1:v3 by id6      |      6.963| 16.451|
|   1e+09|sum v1 by id1         |     15.063|     NA|
|   1e+09|sum v1 by id1:id2     |     44.240|     NA|
|   1e+09|sum v1 mean v3 by id3 |    157.430|     NA|
|   1e+09|mean v1:v3 by id4     |     26.855|     NA|
|   1e+09|sum v1:v3 by id6      |    120.376|     NA|

질문 5 개 중 4 개에서 data.table이 더 빠르며 더 잘 확장되는 것을 볼 수 있습니다.
바로이 타이밍은 지금과 같다주의 , 어디서 id1, id2및 id3문자 필드입니다. 이것은 곧 범주 형 완료 로 변경 될 것 입니다. 또한 가까운 미래에 타이밍에 영향을 줄 수있는 다른 요소들도 있습니다 ( 병렬 DONE 그룹화 와 같은 ). 우리는 또한 별도의 벤치 마크를 추가하려고 의 NA를 가진 데이터 및 다양한 카디널리티는 DONE .

당신이에 관심이 있다면, 그래서 다른 작업이 지속적으로 벤치마킹 프로젝트에오고있다 join, sort, read등 확실히 나중에 확인합니다.
물론 프로젝트 리포지토리에 피드백을 제공 할 수 있습니다.


1
JuliaDB는 어떻습니까?
— skan

1
@skan 당신은에 그 상태를 추적 할 수 있습니다 github.com/h2oai/db-benchmark/issues/63
— jangorecki

1
좋은 답변-AFAICT 연결하는 벤치 마크가 모두 동일한 VM에서 실행 되었습니까? 즉, 동일한 조건에서 팬더와 dask는 50GB 테이블에 128GB RAM이 필요하지만 다른 것들은이 제약 조건에서 수행 할 수 있습니까? 그렇다면 팬더가 RAM이 매우 비효율적이며 보통 (~ 10GB) 테이블의 많은 일상적인 작업에 대한 내 경험을 반영하며 대부분의 경우 실행 속도보다 훨씬 큰 문제입니다. (특정 워크로드에 따라 모든 이벤트에서 훨씬 더 가깝고 앞뒤로 교환됩니다.)
— jkf

@jkf 그렇습니다. 500GB 데이터 세트 (10e9 행)에서 mem 처리를 테스트 할 계획이므로 머신은 128GB 메모리입니다. 현재 spark 및 pydatatable만이이를 지원하며 곧 클릭 하우스를 추가 할 것입니다.
— jangorecki

@jangorecki는 매우 유용한 벤치 마크입니다. 노력해 주셔서 감사합니다. 나는 50GB 데이터 세트를 소화하지 않는 것에 대해 약간 당황했다. Dask는 파티션 크기를 매개 변수 중 하나로 설정합니다 (예 : blocksizein read_csv). compute()메모리에 전체 출력 테이블이 어셈블되는 것을 피하기 위해 호출을 피하고 디스크에 출력을 덤프하지 않습니까?
— Mischa Lisovyi

14

동료와 저는 팬더와 data.table의 성능 차이에 대한 예비 연구를 수행했습니다. 블로그 에서 연구 (두 부분으로 나뉘어 있음)를 찾을 수 있습니다 ( 여기에서 두 번째 부분을 찾을 수 있음 ).

우리는 팬더가 data.table을 분명히 능가하는 작업이 있지만 data.table이 훨씬 빠른 경우도 있다고 생각했습니다. 직접 확인하여 결과에 대한 의견을 알려주십시오.

편집 :
블로그를 자세히 읽고 싶지 않다면 설정 및 결과에 대한 간략한 요약입니다.

설정

우리는 비교 pandas하고 data.table우리가 시나리오라고합니다 (지금까지) 다음과 같은 작업에 12 개 가지 시뮬레이션 데이터 세트에.

  • 선택과 유사한 조작으로 데이터 검색
  • 조건부 선택 작업으로 데이터 필터링
  • 데이터 정렬 작업
  • 데이터 집계 작업

계산은 4 개의 물리적 코어, 16GB RAM 및 SSD 하드 드라이브가 장착 된 Intel i7 2.2GHz 시스템에서 수행되었습니다. 소프트웨어 버전은 OS X 10.13.3, Python 3.6.4 및 R 3.4.2입니다. 사용 된 각 라이브러리 버전은 팬더의 경우 0.22, 데이터의 경우 1.10.4-3입니다.

간단히 말해서

  • data.table열을 선택할 때 더 빠른 것 같습니다 ( pandas평균 50 % 더 시간이 걸립니다)
  • pandas 행 필터링 속도가 빠릅니다 (평균 50 % 정도).
  • data.table정렬 속도가 상당히 빠릅니다 ( pandas때로는 100 배 느림).
  • 새 열을 추가하면 pandas
  • 집계 결과가 완전히 혼합됩니다

나는 당신을 죽이지 않기 위해 가능한 한 결과를 단순화하려고 노력했습니다. 보다 완벽한 시각화를 위해 연구를 읽으십시오. 웹 페이지에 액세스 할 수 없으면 메시지를 보내 주시면 내용을 전달하겠습니다. GitHub 에서 전체 연구를위한 코드를 찾을 수 있습니다 . 연구 개선 방법에 대한 아이디어가 있으면 이메일을 보내주십시오. GitHub에서 연락처를 찾을 수 있습니다.


1
내 대답을 읽었을 수도 있지만 이미 결과가 혼합되어 있다고 말합니다. 답변에 좀 더 구체적으로 설명하고 잠재적으로 일부 숫자를 자세히 설명해야합니다.
— Tobias Krabel

1
"이 사이트에 대한 액세스가 제한되었습니다." 전화 나 업무용 컴퓨터에서 사이트에 액세스 할 수 없습니다.
— xiaodai

1
읽어서 죄송합니다. 전화로 직접 확인했는데 아무런 문제가 없었습니다. 연결하려는 국가와 관련이있을 수 있습니까?
— Tobias Krabel

1
"4 개의 물리적 코어"= 8 개의 논리적 코어. 또한 어떤 특정 인텔 i7 2.2GHz (어느 세대? 어떤 변형? -HQ?)와 캐시 크기를 말하는 데 도움이됩니다. 그리고 SSD의 읽기 및 쓰기 속도는 어떻습니까?
— smci

Julia 데이터 프레임 및 JuliaDB와 어떻게 비교됩니까?
— skan

3

사실, 데이터 세트 크기가 팬더가 충돌하는 sooooooo 크기이면 기본적으로 dask에 갇혀있어 간단한 그룹 별 합계를 수행 할 수도 없습니다. dplyr은 빠르지 않지만 엉망이되지 않습니다.

나는 현재 약간의 2G 데이터 세트를 작업 중이며 간단한 작업 print(df.groupby(['INCLEVEL1'])["r"].sum())은 어둡습니다.

dplyr에서이 오류가 발생하지 않았습니다.

따라서 팬더가 데이터 세트를 처리 할 수 ​​있다면 팬더를 사용합니다. 그렇지 않으면 R 데이터 테이블을 고수합니다.

그리고 예, 간단하게 dask를 팬더 데이터 프레임으로 다시 변환 할 수 df.compute() 는 있지만 꽤 오랜 시간이 걸리므로 팬더가로드되거나 데이터 테이블을 읽을 때까지 인내심을 가질 수도 있습니다.


1
Dask가 그렇게 나쁘다는 것을 몰랐습니다. 아마도 R의 disk.frame을 시도하고 싶습니까? github.com/xiaodaigh/disk.frame 내가 저자입니다
— xiaodai

1

나는 이것이 오래된 게시물이라는 것을 알고 있지만 언급 할 가치가 있다고 생각했습니다. 깃털 (R과 Python에서)을 사용하면 데이터 프레임 / 데이터 테이블에서 작업하고 깃털을 통해 결과를 공유 할 수 있습니다.

페더의 github 페이지 참조


중대형 데이터 셋을위한 Segfaults
— jangorecki
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.