programing tip

팬더가 2012 년에 data.table이 R보다 빨리 파이썬에서 병합 된 이유는 무엇입니까?

itbloger 2020. 6. 7. 10:41
반응형

팬더가 2012 년에 data.table이 R보다 빨리 파이썬에서 병합 된 이유는 무엇입니까?


필자는 최근 파이썬 용 팬더 라이브러리를 보았습니다. 이 벤치 마크 에 따르면 매우 빠른 인 메모리 병합을 수행합니다. R data.table 패키지 보다 훨씬 빠릅니다 (분석을 위해 선택한 언어).

pandas그렇게 빠른 data.table가요? 파이썬이 R에 비해 고유 한 속도 이점 때문입니까, 아니면 알지 못하는 트레이드 오프가 있습니까? 내부 및 외부에 조인을 수행 할 수있는 방법이 있나요 data.table의지하지 않고 merge(X, Y, all=FALSE)와는 merge(X, Y, all=TRUE)?

비교

다음 은 다양한 패키지를 벤치마킹하는 데 사용되는 R 코드Python 코드 입니다.


Wes가 data.table고유 한 문자열 ( 레벨 ) 의 수가 10,000 인 경우 알려진 문제를 발견 한 것 같습니다 .

Rprof()통화에 소비 된 대부분의 시간을 공개 합니까 sortedmatch(levels(i[[lc]]), levels(x[[rc]])? 이것은 실제로 조인 자체 (알고리즘)가 아니라 예비 단계입니다.

최근에는 키에 문자 열을 허용하려는 노력이있어 왔으며, R의 자체 글로벌 문자열 해시 테이블과 더 밀접하게 통합하여이 문제를 해결해야합니다. 일부 벤치 마크 결과는 이미보고 test.data.table()되었지만 해당 코드는 아직 연결되지 않은 레벨로 대체하기 위해 연결되지 않았습니다.

팬더는 data.table일반 정수 열 보다 빨리 병합 됩니까? 알고리즘 자체와 요인 문제를 분리하는 방법이어야합니다.

또한, data.table시계열 병합 마음을. 이에 대한 두 가지 측면 : i) (id, datetime)과 같은 다중 열 순서화 된 키 ii) 빠른 roll=TRUE관측 우선 합류 ( ) 마지막으로 수행 된 관찰.

data.table제시된 것과 비교 한 첫 번째 내용이므로 확인하는 데 약간의 시간이 필요합니다 .


2012 년 7 월에 출시 된 data.table v1.8.0에서 업데이트

  • 'factor'유형의 열에 대해 i 레벨을 x 레벨과 일치시킬 때 내부 함수 sortedmatch ()가 제거되고 chmatch ()로 대체되었습니다. 이 예비 단계는 요인 열의 수준 수가 많을 때 (예 :> 10,000) (알려진) 상당한 속도 저하를 유발했습니다. Wes McKinney (Python package Pandas의 저자)가 시연 한 것처럼 4 개의 이러한 열을 결합하는 테스트에서 악화되었습니다. 예를 들어, 60 만 개의 고유 한 백만 개의 문자열이 16에서 0.5로 줄어 듭니다.

또한 그 릴리스에서 :

  • 문자 열은 이제 키로 허용되며 요인을 고려하는 것이 좋습니다. data.table () 및 setkey ()는 더 이상 문자를 고려하지 않습니다. 요소는 여전히 지원됩니다. FR # 1493, FR # 1224 및 (일부) FR # 951을 구현합니다.

  • 문자 함수에 대한 새로운 함수 chmatch () 및 % chin %, 더 빠른 버전의 match () 및 % in % R의 내부 문자열 캐시가 사용됩니다 (해시 테이블이 작성되지 않음). ? chmatch의 예제에서 match ()보다 약 4 배 빠릅니다.

2013 년 9 월 현재 data.table은 CRAN에서 v1.8.10이며 v1.9.0에서 작업하고 있습니다. 뉴스 가 실시간으로 업데이트됩니다.


그러나 내가 원래 쓴 것처럼 위의 :

data.table시계열 병합 마음에. 이에 대한 두 가지 측면 : i) (id, datetime)과 같은 다중 열 순서화 된 키 ii) 빠른 roll=TRUE관측 우선 합류 ( ) 마지막으로 수행 된 관찰.

따라서 Pandas는 두 개의 문자 열을 동등하게 결합하는 것이 아마도 data.table보다 빠릅니다. 그것이 결합 된 두 개의 열을 해시하는 것처럼 들립니다. data.table은 우선 순위가 높은 조인을 염두에두고 키를 해시하지 않습니다. data.table의 "키"는 말 그대로 정렬 순서입니다 (SQL의 클러스터형 인덱스와 유사합니다. 즉, 데이터가 RAM에서 정렬되는 방식). 예를 들어 목록에 보조 키를 추가하는 것입니다.

요약하면, 알려진 문제가 해결되었으므로 10,000 개가 넘는 고유 한 문자열을 가진이 특정 2 자 열 테스트에서 강조된 눈부신 속도 차이는 지금 나쁘지 않아야합니다.


The reason pandas is faster is because I came up with a better algorithm, which is implemented very carefully using a fast hash table implementation - klib and in C/Cython to avoid the Python interpreter overhead for the non-vectorizable parts. The algorithm is described in some detail in my presentation: A look inside pandas design and development.

The comparison with data.table is actually a bit interesting because the whole point of R's data.table is that it contains pre-computed indexes for various columns to accelerate operations like data selection and merges. In this case (database joins) pandas' DataFrame contains no pre-computed information that is being used for the merge, so to speak it's a "cold" merge. If I had stored the factorized versions of the join keys, the join would be significantly faster - as factorizing is the biggest bottleneck for this algorithm.

I should also add that the internal design of pandas' DataFrame is much more amenable to these kinds of operations than R's data.frame (which is just a list of arrays internally).


This topic is two years old but seems like a probable place for people to land when they search for comparisons of Pandas and data.table

Since both of these have evolved over time, I want to post a relatively newer comparison (from 2014) here for the interested users: https://github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

It would be interesting to know if Wes and/or Matt (who, by the way, are creators of Pandas and data.table respectively and have both commented above) have any news to add here as well.

-- UPDATE --

A comment posted below by jangorecki contains a link that I think is very useful: https://github.com/szilard/benchm-databases

https://github.com/szilard/benchm-databases/blob/master/plot.png

이 그래프는 다양한 기술에 대한 집계 및 조인 작업의 평균 시간을 나타냅니다 ( 낮음 = 빠름 ; 비교는 2016 년 9 월에 마지막으로 업데이트 됨). 정말 교육적이었습니다.

질문에 다시가는, R DT key그리고 R DTR의 data.table의 키 입력 / 설정 해제 된 맛을 참조 파이썬의 팬더 이상이 벤치 마크에 빠른 될 일이 ( Py pandas).

참고 URL : https://stackoverflow.com/questions/8991709/why-were-pandas-merges-in-python-faster-than-data-table-merges-in-r-in-2012

반응형