Pandas: 전체 복사 없이 혼합 dtype DataFrame을 구성할 수 있는 방법 없음, 제안된 솔루션

인덱스와 열이 있는 빈 프레임을 간단히 만들 수 있습니다.
그런 다음 ndarrays를 할당하십시오. 특정 dtype을 한 번에 모두 할당하는 것은 복사되지 않습니다.

원하는 경우 np.empty로 생성할 수 있습니다.

df = pd.DataFrame(index=range(2), columns=["dude", "wheres"])

df
Out[12]:
  dude wheres
0  NaN    NaN
1  NaN    NaN

x = np.empty(2, np.int32)

x
Out[14]: array([6, 0], dtype=int32)

df.dude = x

df
Out[16]:
   dude wheres
0     6    NaN
1     0    NaN

x[0] = 0

x
Out[18]: array([0, 0], dtype=int32)

df
Out[19]:
   dude wheres
0     6    NaN
1     0    NaN

나에게 복사하는 것 같습니다. 내가 작성한 코드가 의도한 것이 아니거나 발생한 복사가 내가 생략하려고 생각했던 복사가 아닌 경우가 아니면.

당신은 dtype을 변경했습니다
그것이 float로 try를 복사한 이유입니다.

y = np.empty(2, np.float64)

df
Out[21]:
   dude wheres
0     6    NaN
1     0    NaN

df.wheres = y

y
Out[23]: array([  2.96439388e-323,   2.96439388e-323])

y[0] = 0

df
Out[25]:
   dude         wheres
0     6  2.964394e-323
1     0  2.964394e-323

df = pd.DataFrame(index=range(2), columns=["dude", "wheres"])

df.dtypes
Out[27]:
dude      object
wheres    object
dtype: object

dtype은 객체이므로 float 또는 int를 사용하는지 여부에 관계없이 변경되었습니다.

In [25]: arr = np.ones((2,3))

In [26]: df = DataFrame(arr,columns=['a','b','c'])

In [27]: arr[0,1] = 5

In [28]: df
Out[28]: 
   a  b  c
0  1  5  1
1  1  1  1

혼합 유형에서 w/o 사본을 구성할 수는 있지만 상당히 까다롭습니다. 문제는 일부 유형에 복사본이 필요하다는 것입니다(예: 메모리 경합 문제를 방지하기 위한 개체). 그리고 내부 구조는 다른 유형을 통합하므로 새 유형을 추가하려면 사본이 필요합니다. 복사를 피하는 것은 대부분의 경우 매우 어렵습니다.

필요한 것을 만들고 데이터에 대한 포인터를 얻은 다음 덮어쓰기만 하면 됩니다. 그게 왜 문제야?

문제는 내가 필요로 하는 것을 생성하기 위해 내가 사용할 의사가 없는 데이터인 올바른 dtype을 복사해야 한다는 것입니다. 빈 DataFrame 생성에 대한 제안이 상당한 RAM을 사용하지 않는다고 가정하더라도 복사 비용이 줄어들지는 않습니다. 1GB DataFrame을 만들고 다른 곳에 채우려면 메모리에 1GB의 쓰레기를 복사하는 비용을 지불해야 하며 이는 전혀 필요하지 않습니다. 이것을 문제로 보지 않습니까?

예, 내부 구조가 여러 유형을 통합한다는 것을 이해합니다. 메모리 경합 문제가 무엇을 의미하는지 정확히 모르겠지만 어떤 경우에도 객체는 실제로 여기서 관심을 끄는 것이 아닙니다.

사실, 일반적으로 복사를 피하는 것은 어려운 문제이지만, 처음부터 필요한 모든 정보를 제공하기 때문에 내가 제안한 방식으로 복사를 피하는 것은 상당히 쉽습니다. 데이터에서 dtypes 및 행 수를 유추하고 데이터를 복사하는 대신 dtypes 및 행 수를 직접 지정하고 복사를 뺀 것과 동일한 방식으로 다른 모든 작업을 수행한다는 점을 제외하면 데이터에서 구성하는 것과 동일합니다.

지원되는 모든 열 유형에 대해 "빈" 생성자가 필요합니다. numpy 숫자 유형의 경우 이것은 명백합니다. DatetimeIndex에 대해 확실하지 않은 Categorical에 대해서는 0이 아닌 작업이 필요합니다.

dict를 생성자에 전달하고 copy=False가 작동해야 합니다.

그래서 이것은 작동합니다. 그러나 전달하는 배열이 고유한 dtype인지 확인해야 합니다. 그리고 일단 이것에 대해 무엇이든 하면 기본 데이터를 복사할 수 있습니다. 그래서 YMMV. 물론 1/0 대신에 np.empty 를 전달할 수 있습니다.

In [75]: arr = np.ones((2,3))

In [76]: arr2 = np.zeros((2,2),dtype='int32')

In [77]: df = DataFrame(arr,columns=list('abc'))

In [78]: df2 = DataFrame(arr2,columns=list('de'))

In [79]: result = pd.concat([df,df2],axis=1,copy=False)

In [80]: arr2[0,1] = 20

In [81]: arr[0,1] = 10

In [82]: result
Out[82]: 
   a   b  c  d   e
0  1  10  1  0  20
1  1   1  1  0   0

In [83]: result._data
Out[83]: 
BlockManager
Items: Index([u'a', u'b', u'c', u'd', u'e'], dtype='object')
Axis 1: Int64Index([0, 1], dtype='int64')
FloatBlock: slice(0, 3, 1), 3 x 2, dtype: float64
IntBlock: slice(3, 5, 1), 2 x 2, dtype: int32

In [84]: result._data.blocks[0].values.base
Out[84]: 
array([[  1.,  10.,   1.],
       [  1.,   1.,   1.]])

In [85]: result._data.blocks[1].values.base
Out[85]: 
array([[ 0, 20],
       [ 0,  0]], dtype=int32)

_ reindex 이(가) 이상한 "기능"인 캐스팅을 강제 실행하므로 작동하지 않으므로 삭제된 초기 시도가 작동하지 않습니다._

이 시도를 약간 덜 만족스럽게 만드는 '메서드'를 사용해야 합니다.

arr = np.empty(1, dtype=[('x', np.float), ('y', np.int)])
df = pd.DataFrame.from_records(arr).reindex(np.arange(100))

성능에 대해 정말로 걱정한다면 개념적으로 훨씬 간단하기 때문에 numpy를 가능한 한 많이 사용하지 않는 이유가 확실하지 않습니다.

jreback, 솔루션 주셔서 감사합니다. 이것은 Categoricals에서도 작동하는 것 같습니다(저를 놀라게 했습니다). 문제가 발생하면 알려 드리겠습니다. 무슨 말인지 잘 모르겠습니다. 이것에 대해 무엇이든 하면 복사될 수 있습니다. 무슨 뜻인가요? COW 의미 체계가 없는 한 나는 당신이 보는 것이 건설 시간에 깊은 사본과 얕은 사본과 관련하여 얻는 것이라고 생각합니다.

나는 여전히 from_empty 생성자를 구현해야 한다고 생각하고 그렇게 어렵지 않을 것이라고 생각합니다. 이 기술이 작동하는 동안에는 많은 코드 오버헤드가 포함됩니다. 원칙적으로 이것은 단일 복합 dtype과 여러 행을 지정하여 수행할 수 있습니다.

bashtage에서 이러한 솔루션은 여전히 ​​전체 DataFrame에 씁니다. 쓰기는 일반적으로 읽기보다 느리기 때문에 기껏해야 문제의 오버헤드를 절반 이하로 절약할 수 있습니다.

분명히 내가 가서 numpy를 사용하지 않았다면 pandas에는 내가 사랑하는 많은 멋진 기능과 기능이 있고 그것을 포기하고 싶지 않기 때문입니다. 당신은 정말로 묻고 있었습니까, 아니면 이 성능 저하를 원하지 않으면 numpy를 사용해야 함을 암시 했습니까?

긁어주세요. 사용자 오류입니다. 죄송합니다. copy=False인 reindex_axis가 완벽하게 작동했습니다.

bashtage에서 이러한 솔루션은 여전히 ​​전체 DataFrame에 씁니다. 쓰기는 일반적으로 읽기보다 느리기 때문에 기껏해야 문제의 오버헤드를 절반 이하로 절약할 수 있습니다.

사실이지만 method 대한 새 method reindex 는 아무것도 채워지지 않으며 쓰기/복사 없이 임의의 열 유형으로 유형이 지정된 배열을 할당할 수 있습니다.

분명히 내가 가서 numpy를 사용하지 않았다면 pandas에는 내가 사랑하는 많은 멋진 기능과 기능이 있고 그것을 포기하고 싶지 않기 때문입니다. 당신은 정말로 묻고 있었습니까, 아니면 이 성능 저하를 원하지 않으면 numpy를 사용해야 함을 암시 했습니까?

약간 수사학적이었습니다. numpy를 사용하면 매우 쉽게 작성하려고 할 때 중요한 메모리 덩어리 액세스에 더 쉽게 접근할 수 있기 때문에 성능 관점에서 진지한 제안이기도 합니다. 고성능 코드. 코드 단순성이 성능보다 더 중요할 때 항상 numpy에서 pandas로 변환할 수 있습니다.

나는 당신이 말하는 것을 본다. 나는 여전히 해결 방법보다 인터페이스의 일부가 더 깨끗해야 한다고 생각하지만 해결 방법이 진행됨에 따라 구현하기 쉽고 좋은 방법입니다.

Pandas는 여전히 주요 목표인 성능을 하나로 강조합니다. 분명히 numpy에 비해 더 높은 수준의 기능이 있으며 비용을 지불해야 합니다. 우리가 말하는 것은 더 높은 수준의 기능과 아무 관련이 없으며 필요하지 않은 곳에서 대량 사본에 비용을 지불해야 할 이유가 없습니다. 이 논의와 완전히 다른 열, 인덱스 등을 설정하는 비용에 대해 누군가가 의아해한다면 귀하의 제안이 적절할 것입니다.

나는 당신이 파이썬에서 메모리를 할당하는 코드와 작성 비용을 과대평가하고 있다고 생각합니다. 비용이 많이 드는 부분은 메모리 할당입니다. 개체 생성도 비용이 많이 듭니다.

둘 다 1GB의 메모리를 할당하며 하나는 비어 있고 하나는 0입니다.

%timeit np.empty(1, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 2.44 µs per loop

%timeit np.zeros(1, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 2.47 µs per loop

%timeit np.zeros(50000000, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 11.7 µs per loop

%timeit np.empty(50000000, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 11.4 µs per loop

150,000,000 값을 0으로 만드는 데 3µs.

이제 이것을 간단한 DataFrame에 대해 비교하십시오.

%timeit pd.DataFrame([[0]])
1000 loops, best of 3: 426 µs per loop

사소한 것의 경우 약 200배 느립니다. 그러나 더 큰 어레이의 경우 훨씬 더 나쁩니다.

%timeit pd.DataFrame(np.empty((50000000, 3)),copy=False)
1 loops, best of 3: 275 ms per loop

이 아무것도 복사되지 않았 음 - 지금은 275m의 걸립니다. 비용은 인덱스 등을 설정하는 데 소요되며 배열이 매우 클 때 분명히 매우 느립니다.

이것은 pandas의 다른 오버헤드가 너무 커서 malloc + 채우기 구성 요소의 비용이 거의 0에 가깝기 때문에 나에게 시기상조 최적화처럼 느껴집니다.

빡빡한 루프에서 무엇이든 할당하려면 성능상의 이유로 numpy 배열이어야합니다.

좋아, 여기 우리가 해야 한다고 생각하는 것이 있습니다. @quicknir 당신이 몇 가지 개선을 하고 싶다면. 2 문제.

• #4464 - 이것은 본질적으로 DataFrame 생성자에서 복합 dtype을 허용한 다음 from_records() 를 돌려서 호출합니다. 전달된 배열이 rec/structured 배열인 경우에도 호출할 수 있습니다. 기본적으로 from_records rec/structured array 처리 경로를 만들 것입니다.
• copy= 키워드를 from_records
• from_records 는 위의 concat soln을 사용할 수 있습니다. rec-array를 분할하여 연속으로 삭제한 다음 다시 함께 dtype 블록에 넣습니다. 이 부분 내부적으로 수행).

이것은 약간 중요하지 않지만 혼합 유형을 사용하여 이미 생성된 ndarray(비어 있을 수 있음)를 매우 쉽게 전달할 수 있습니다. 이것은 (첫 번째 패스 구현에서) (int/float/string)만 처리할 수 있습니다. datetime/timedelta는 특별한 위생 처리가 필요하고 이를 좀 더 복잡하게 만들 것입니다.

따라서 @bashtage 는 성능 관점에서

내가 위에서 의미한 것은 이것이다. Pandas는 유사한 dtype(예: int64,int32는 다름)을 '블록'(프레임의 2차원)으로 그룹화합니다. 이들은 연속 메모리 ndarray입니다(현재 단일 dtype에서만 작동하는 단순히 전달되지 않는 한 새로 할당됨). 그런 다음 df['new_columns'] = 5 와 같은 setitem을 수행하고 이미 int64 블록이 있는 경우 이 새 열은 궁극적으로 여기에 연결됩니다(해당 dtype에 대한 새 메모리 할당 결과). 이에 대한 보기로 참조를 사용했다면 더 이상 유효하지 않습니다. 이것이 DataFrame 내부에서 피어링 없이 사용할 수 있는 전략이 아닌 이유입니다.

@bashtage yeh 큰 비용은 당신이 언급했듯이 인덱스입니다. RangeIndex (#939 참조)는 이 문제를 완전히 해결할 것입니다. (실제로는 사이드 브랜치에서 거의 완료되며 약간의 먼지만 제거하면 됩니다.)

최적화된 RangeIndex 하더라도 NumPy 배열을 구성하는 것보다 여전히 2배 더 느릴 것입니다. 이는 훨씬 더 무거운 무게 특성과 DataFrame 의 추가 기능을 감안할 때 충분히 공정합니다.

이것은 성능 문제가 아니라 편의 기능으로 간주 될 수 있다고 생각합니다. DataFrame 또는 Panel 와 같은 혼합 유형을 초기화하는 것이 유용할 수 있습니다.

dtype=np.dtype([('GDP', np.float64), ('Population', np.int64)])
pd.Panel(items=['AU','AT'],
         major_axis=['1972','1973'],
         minor_axis=['GDP','Population'], 
         dtype=[np.float, np.int64])

이것은 API / 편의 문제 일뿐입니다.

성능이 실제로 부수적인 문제라는 데 동의했습니다(드라이버가 아님).

@bashtage

%timeit pd.DataFrame(np.empty((100, 1000000)))
100개 루프, 최고 3개: 루프당 15.6ms

%timeit pd.DataFrame(np.empty((100, 1000000)), 복사=참)
루프 1개, 최고 3개: 루프당 302ms

따라서 데이터 프레임으로 복사하는 것은 DataFrame 생성과 관련된 다른 모든 작업보다 20배 더 오래 걸리는 것 같습니다. 즉, 복사(및 추가 할당)가 시간의 95%입니다. 당신이 한 벤치마크는 올바른 것을 벤치마킹하지 않았습니다. 복사 자체 또는 할당에 시간이 걸리는 것은 실제로 중요하지 않지만 요점은 단일 dtype DataFrame에 대해 할 수 있는 방식으로 여러 dtype DataFrame에 대한 복사를 피할 수 있다면 엄청난 시간을 절약할 수 있다는 것입니다.

당신의 2단계 추론도 기만적입니다. 이것은 수행되는 유일한 작업이 아니라 디스크 읽기와 같이 시간이 걸리는 다른 작업이 수행되고 있습니다. 바로 지금, DataFrame을 만들기 위해 수행해야 하는 추가 복사본은 디스크에서 DataFrame으로 데이터를 읽는 간단한 프로그램에서 약 절반 시간이 걸립니다. 1/20의 시간이 걸린다면 디스크 읽기가 지배적일 것이며(당연히 그래야 함) 추가 개선 사항은 거의 효과가 없을 것입니다.

그래서 저는 두 분 모두에게 다시 강조하고 싶습니다. 이것은 실제 성능 문제입니다.

jreback은 연결 전략이 범주형에 대해 작동하지 않는다는 점을 감안할 때 위에서 제안한 개선 사항이 효과가 있을 것이라고 생각하지 마십시오. 나는 더 나은 출발점이 reindex가 될 것이라고 생각합니다. 현재 문제는 reindex가 많은 추가 작업을 수행한다는 것입니다. 그러나 원칙적으로 행이 0인 DataFrame에는 불필요한 작업을 수행하지 않고 정확한 행 수로 DataFrame을 생성할 수 있도록 하는 데 필요한 모든 정보가 있습니다. Btw, 이것은 팬더가 스키마 객체를 필요로 하는 것처럼 느껴지게 합니다. 하지만 그건 다른 날의 논의입니다.

나는 우리가 동의하지 않기 위해 동의해야 한다고 생각합니다. IMO DataFrames는 기본 numpy 배열과 DataFrame 생성 사이의 큰 차이의 순서로 알 수 있듯이 숫자 생태계에서 극한의 성능 개체가 아닙니다.

%timeit np.empty((1000000, 100))
1000 loops, best of 3: 1.61 ms per loop

%timeit pd.DataFrame(np.empty((1000000,100)))
100 loops, best of 3: 15.3 ms per loop

바로 지금, DataFrame을 만들기 위해 수행해야 하는 추가 복사본은 디스크에서 DataFrame으로 데이터를 읽는 간단한 프로그램에서 약 절반 시간이 걸립니다. 1/20의 시간이 걸린다면 디스크 읽기가 지배적일 것이며(당연히 그래야 함) 추가 개선 사항은 거의 효과가 없을 것입니다.

이것이 DataFrame 성능에 대해 신경 쓸 이유가 훨씬 적다고 생각합니다. 100% 무료로 만들 수 있다고 해도 총 프로그램 시간은 50%만 감소합니다.

성능 문제로 생각하든 편의 문제로 생각하든 상관없이 이 문제를 해결하기 위해 여기에서 PR을 수행할 수 있다는 데 동의합니다. 내 POV에서는 성능이 중요할 때 항상 numpy 배열을 사용하기 때문에 후자로 봅니다. Numpy는 (열을 추가하여 배열을 확장하는 것과 같은) 일부 작업에 비교적 효율적인 블록 관리자를 사용하지 않는 것과 같은 다른 작업을 수행합니다. 그러나 다른 관점에서 나쁘다.

두 가지 옵션이 있을 수 있습니다. 첫 번째는 위에서 제공한 예제와 같이 빈 생성자입니다. 이것은 아무 것도 복사하지 않지만 pandas의 다른 것들과 일관성을 유지하기 위해 Null을 채울 것입니다. Null 채우기는 매우 저렴하며 IMO 문제의 근본 원인이 아닙니다.

다른 하나는 미리 형성된 블록을 블록 관리자에게 바로 전달하는 DataFrame.from_blocks 메서드를 사용하는 것입니다. 같은 것

DataFrame.from_blocks([np.empty((100,2)), 
                       np.empty((100,3), dtype=np.float32), 
                       np.empty((100,1), dtype=np.int8)],
                     columns=['f8_0','f8_1','f4_0','f4_1','f4_2','i1_0'],
                     index=np.arange(100))

이 유형의 방법은 블록이 호환 가능한 모양을 갖고 모든 블록이 고유한 유형을 가지며 인덱스 및 열의 모양에 대한 일반적인 검사를 강제합니다. 이 유형의 방법은 데이터에 아무 것도 하지 않으며 BlockManger에서 사용합니다.

@quicknir 당신은 꽤 복잡한 것들을 결합하려고합니다. 범주형은 numpy에 존재하지 않으며 오히려 팬더 구조와 같은 복합 dtype입니다. 그런 다음 별도로 구성하고 할당해야 합니다(실제로 매우 저렴합니다. 이는 다른 단일 dtype과 같은 블록으로 결합되지 않음).

@bashtage soln이 합리적으로 보입니다. 이것은 몇 가지 간단한 검사를 제공하고 단순히 데이터를 통과할 수 있습니다(그리고 다른 내부 루틴에 의해 호출됨). 일반적으로 사용자는 내부 담당자에 대해 걱정할 필요가 없습니다. 당신이 정말로 원하기 때문에, 당신은 이것을 인식할 필요가 있습니다.

그렇긴 해도, 왜 당신이 원하는 것과 똑같은 프레임을 만들지 않는지 아직도 잘 모르겠습니다. 그런 다음 블록 포인터를 잡고 값을 변경합니다. 동일한 메모리 비용이 소요되며 @bashtage가 지적했듯이 이미 설정된 null 프레임(모든 dtype,index,columns 포함)을 만드는 것은 매우 저렴합니다.

빈 생성자가 무엇을 의미하는지 잘 모르겠지만 행과 원하는 스키마가 없는 데이터 프레임을 구성하고 reindex를 호출하는 경우 copy=True로 생성하는 것과 같은 시간입니다.

두 번째 제안은 합리적이지만 범주형을 수행하는 방법을 알아낼 수 있는 경우에만 가능합니다. 그 주제에 대해 저는 코드를 살펴보고 Categorical이 통합할 수 없다는 것을 깨달았습니다. 그래서 직감적으로 정수 배열과 두 개의 범주형 Series를 만든 다음 세 개의 DataFrame을 만들고 세 개를 모두 연결했습니다. 물론 두 개의 DataFrame이 동일한 dtype을 가졌음에도 복사를 수행하지 않았습니다. 이것이 Datetime Index에서 작동하도록 하는 방법을 보려고 노력할 것입니다.

@jreback 나는 여전히 당신이 원하는 대로 정확히 프레임을 만든다는 말의 의미를 따르지 않습니다.

@quicknir 실제로 수행하려는 작업의 코드/의사 코드 샘플을 표시하지 않는 이유는 무엇입니까?

def read_dataframe(filename, ....):
   f = my_library.open(filename)
   schema = f.schema()
   row_count = f.row_count()
   df = pd.DataFrame.from_empty(schema, row_count)
   dict_of_np_arrays = get_np_arrays_from_DataFrame(df)
   f.read(dict_of_np_arrays)
   return df

이전 코드는 먼저 numpy 배열의 사전을 구성한 다음 모든 것을 복사하기 때문에 그 사전에서 DataFrame을 구성했습니다. 거의 절반의 시간이 그것에 소비되었습니다. 그래서 이 제도로 바꾸려고 합니다. 문제는 내용에 신경 쓰지 않아도 위와 같이 df를 구성하는 것은 매우 비용이 많이 든다는 것입니다.

np 배열의 @quicknir 사전은 많은 복사가 필요합니다.

다음과 같이 하면 됩니다.

# construct your biggest block type (e.g. say you have mostly floats)
df = DataFrame(np.empty((....)),index=....,columns=....)

# then add in other things you need (say strings)
df['foo'] = np.empty(.....)

# say ints
df['foo2'] = np.empty(...)

dtype으로 이것을 하면 저렴할 것입니다.

그 다음에.

for dtype, block in df.as_blocks():
    # fill the values
    block.values[0,0] = 1

이러한 블록 값은 numpy 배열에 대한 보기이므로

유형의 구성은 일반적으로 미리 알려져 있지 않으며 가장 일반적인 사용 사례에서 float와 int의 건강한 혼합이 있습니다. 나는 이것이 30개의 float 열과 10개의 int 열이 있는 경우 이것이 어떻게 저렴할 것인지 따르지 않을 것이라고 생각합니다. 예, float는 매우 저렴할 것입니다. 그러나 int를 수행할 때 내가 누락된 모든 것을 한 번에 수행할 수 있는 방법이 없는 한 int 열을 하나 더 추가할 때마다 전체 int 블록이 재할당됩니다.

이전에 나에게 제공한 솔루션이 거의 작동하고 있는데 DatetimeIndex에서 제대로 작동하지 않는 것 같습니다.

빈 생성자가 무엇을 의미하는지 잘 모르겠지만 행과 원하는 스키마가 없는 데이터 프레임을 구성하고 reindex를 호출하는 경우 copy=True로 생성하는 것과 같은 시간입니다.

빈 생성자는 다음과 같습니다.

dtype=np.dtype([('a', np.float64), ('b', np.int64), ('c', np.float32)])
df = pd.DataFrame(columns='abc',index=np.arange(100),dtype=dtype)

이것은 다음과 동일한 출력을 생성합니다.

dtype=np.dtype([('a', np.float64), ('b', np.int64), ('c', np.float32)])
arr = np.empty(100, dtype=dtype)
df = pd.DataFrame.from_records(arr, index=np.arange(100))

데이터를 복사하지 않을 뿐입니다.

기본적으로 생성자는 다음 호출에 대해 혼합 dtype을 허용하지만 기본 dtype은 하나만 허용합니다.

df = pd.DataFrame(columns=['a','b','c'],index=np.arange(100), dtype=np.float32)

유일한 다른 _feature_는 int에 대한 누락 값이 없기 때문에 객체 dtype으로 변환하는 부작용이 있는 null-filling int 배열을 방지하는 것입니다.

두 번째 제안은 합리적이지만 범주형을 수행하는 방법을 알아낼 수 있는 경우에만 가능합니다. 그 주제에 대해 저는 코드를 살펴보고 Categorical이 통합할 수 없다는 것을 깨달았습니다. 그래서 직감적으로 정수 배열과 두 개의 범주형 Series를 만든 다음 세 개의 DataFrame을 만들고 세 개를 모두 연결했습니다. 물론 두 개의 DataFrame이 동일한 dtype을 가졌음에도 복사를 수행하지 않았습니다. 이것이 Datetime Index에서 작동하도록 하는 방법을 보려고 노력할 것입니다.

from_block 메서드는 여러 범주를 허용하지만 다른 기본 유형 중 하나만 허용하도록 통합 규칙을 알아야 합니다.

넵.. 그렇게 어렵지 않아요.... 내부를 친절하게 소개해주실 분을 구합니다..... 힌트.힌트.힌트.... :)

하하, 구현 작업을 수행할 의향이 있습니다. 오해하지 마세요. 이번 주말에 내부를 살펴보고 어떤 생성자가 구현하기 더 쉬운지 이해하려고 노력할 것입니다. 먼저 별도의 스레드에서 발생하는 일부 DatetimeIndex 문제를 처리해야 합니다.

@quicknir 이에 대한 해결책을 찾았습니까?

cython 라이브러리에서 열을 복사 없이 채울 수 있도록 혼합 dtype 데이터 프레임을 저렴하게 할당(채우기는 아님)하는 방법을 찾고 있습니다.

내가 시작하는 데 도움이 되도록 가지고 있는 코드(반 작업 포함)를 기꺼이 공유해 주시면 감사하겠습니다.

다음은 합리적인 접근 방식이 될까요? 프로토타입 데이터 프레임에서 작업하여 차단 논리를 다시 만드는 단계를 건너뛰었습니다.

범주형과 별도로 어떤 dtypes에 특별한 처리가 필요합니까?

물론 생성된 데이터 프레임을 사용하는 것은 채워질 때까지 안전하지 않습니다...

import numpy as np
from pandas.core.index import _ensure_index
from pandas.core.internals import BlockManager
from pandas.core.generic import NDFrame
from pandas.core.frame import DataFrame
from pandas.core.common import CategoricalDtype
from pandas.core.categorical import Categorical
from pandas.core.index import Index

def allocate_like(df, size, keep_categories=False):
    # define axes (waiting for #939 (RangeIndex))
    axes = [df.columns.values.tolist(), Index(np.arange(size))]

    # allocate and create blocks
    blocks = []
    for block in df._data.blocks:
        # special treatment for non-ordinary block types
        if isinstance(block.dtype, CategoricalDtype):
            if keep_categories:
                categories = block.values.categories
            else:
                categories = Index([])
            values = Categorical(values=np.empty(shape=block.values.shape,
                                                 dtype=block.values.codes.dtype),
                                 categories=categories,
                                 fastpath=True)
        # ordinary block types
        else:
            new_shape = (block.values.shape[0], size)
            values = np.empty(shape=new_shape, dtype=block.dtype)

        new_block = block.make_block_same_class(values=values,
                                                placement=block.mgr_locs.as_array)
        blocks.append(new_block)

    # create block manager
    mgr = BlockManager(blocks, axes)

    # create dataframe
    return DataFrame(mgr)


# create a prototype dataframe
import pandas as pd
a = np.empty(0, dtype=('i4,i4,f4,f4,f4,a10'))
df = pd.DataFrame(a)
df['cat_col'] = pd.Series(list('abcabcdeff'), dtype="category")

# allocate an alike dataframe
df1 = allocate_like(df, size=10)

@ARF1 최종 목표가 무엇인지 잘 모르겠습니다.
간단한 예를 제공할 수 있습니까?

copy=False와 함께 추가 concat은 일반적으로 이것을 회피합니다.

@jreback 성능상의 이유로 중간 복사 없이 데이터 프레임으로 직접 압축을 풀고 싶은 압축된 데이터 저장소에서 대용량 데이터를 열별로 읽기 위해 cython 라이브러리를 사용하고 싶습니다.

이러한 경우 일반적인 numpy 솔루션에서 차용하여 할당된 메모리 영역에 대한 포인터를 내 cython 라이브러리에 전달할 수 있도록 데이터 프레임에 대한 메모리를 미리 할당하고 싶습니다. 중간 복사 단계(또는 중간 파이썬 객체 생성) 없이 데이터 프레임을 직접 채우는 메모리 영역. 릴리스된 gil과 병렬로 여러 cython 스레드로 데이터 프레임을 채우는 옵션은 부가적인 이점이 될 것입니다.

(단순화된) 의사 코드에서 idom은 다음과 같습니다.

df = fn_to_allocate_memory()
colums = df.columns.values
column_indexes = []
for i in xrange(len(df._data.blocks)):
    column_indexes.extend(df._data.blocks[i].mgr_locs.as_array)
block_arrays = [df._data.blocks[i].values for i in len(df._data.blocks)]

some_cython_library.fill_dataframe_with_content(columns, column_indexes, block_arrays)

이것이 당신에게 의미가 있습니까?

concat 하여 copy=False 하면 동일한 dtype을 가진 열을 블록으로 병합하지 않지만 라인 아래로 작업을 수행하면 이를 트리거하므로 피하려고 하는 복사가 발생합니다. 아니면 팬더의 내부 동작을 잘못 이해한 걸까요?

나는 큰(채워지지 않은) 데이터 프레임의 인스턴스화로 약간의 진전을 이루었지만(팩터 ~6.7) 여전히 속도가 빠르지 않습니다. ~ 90의 또 다른 요소 만 가야합니다 ...

In [157]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10'))

In [158]: df = pd.DataFrame(a)

In [162]: %timeit np.empty(int(1e6), dtype=('i8,i4,i4,f4,f4,f4,a10'))
1000 loops, best of 3: 247 µs per loop

In [163]: %timeit allocate_like(df, size=int(1e6))
10 loops, best of 3: 22.4 ms per loop

In [164]: %timeit pd.DataFrame(np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10')))

10 loops, best of 3: 150 ms per loop

또 다른 희망은 이 접근 방식을 통해 소량의 데이터를 자주 읽을 때 동일한 모양의 DataFrame을 더 빠르게 반복적으로 인스턴스화할 수 있다는 것입니다. 그것이 지금까지 주요 목표는 아니었지만 무심코 이것으로 더 나은 진전을 이루었습니다.

In [157]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10'))

In [158]: df = pd.DataFrame(a)

In [159]: %timeit np.empty(0, dtype=('i8,i4,i4,f4,f4,f4,a10'))
10000 loops, best of 3: 79.9 µs per loop

In [160]: %timeit allocate_like(df, size=0)
1000 loops, best of 3: 379 µs per loop

In [161]: %timeit pd.DataFrame(np.empty(0, dtype=('i4,i4,f4,f4,f4,a10')))
1000 loops, best of 3: 983 µs per loop

편집하다

위의 타이밍은 사과를 오렌지와 비교할 때 너무 비관적인 그림을 그리는 것입니다. numpy 문자열 열은 고정 길이 기본 문자열로 생성되는 반면 pandas의 해당 열은 파이썬 객체 배열로 생성됩니다. 유사하게 비교하면 인스턴스화 시간의 약 92%를 담당하는 인덱스 생성을 제외하고 DataFrame 인스턴스화를 numpy 속도로 푸시합니다.

@ARF1 numpy 속도를 원하면 numpy를 사용하십시오. 나는 당신이 실제로 무엇을하고 있는지 또는 cython에서 무엇을하고 있는지 잘 모르겠습니다. 일반적인 해결책은 계산을 청크하거나 단일 dtypes를 cython에 전달하거나 더 큰 기계를 얻는 것입니다.

DataFrame은 데이터를 설명하고 조작하는 방법에 대해 numpy보다 훨씬 더 많은 일을 합니다. 그것은 당신이 그들과 실제로 하고 있는 것이 아닙니다.

거의 모든 팬더 작업이 복사됩니다. (대부분의 numpy 작업과 마찬가지로) 무엇을 하고 있는지 확실하지 않습니다.

@jreback 현재 numpy를 사용하고 있지만 구조화된 배열로만 (편리하게) 처리할 수 있는 혼합 dtypes가 있습니다. 그러나 구조화된 배열은 본질적으로 행 우선 순서로 되어 있어 일반적인 분석 차원과 충돌하여 성능이 저하됩니다. Pandas는 열 우선 순위로 인해 자연스러운 대안처럼 보입니다. 좋은 속도로 데이터를 데이터 프레임에 가져올 수 있다면.

물론 대안은 다른 dtyped numpy 배열의 사전을 사용하는 것이지만 슬라이싱 등이 더 이상 가능하지 않기 때문에 분석을 어렵게 만듭니다.

일반적인 해결책은 계산을 청크하고 단일 dtypes를 cython에 전달하는 것입니다.

이것이 내 예에서 block_arrays 변수로 수행하는 작업입니다.

아니면 그냥 더 큰 기계를 사세요.

100배 이상 빠른 속도는 저에게 약간의 재정적 도전입니다. ;-)

@ARF1 작동 방식에 대한 매우 이상한 모델이 있습니다. 일반적으로 적은 수의 데이터 프레임을 만든 다음 작업합니다. 생성 속도는 실제 계산이나 조작의 아주 작은 부분입니다.

@jreback : 이것은 이상한 모델이 아닙니다. 순수한 파이썬 관점에서 사물을 본다면 아마도 이상한 모델일 것입니다. C++ 코드로 작업하는 경우 파이썬 객체로 데이터를 읽는 가장 쉬운 방법은 기존 파이썬 객체에 대한 포인터를 전달하는 것입니다. 성능에 민감한 컨텍스트에서 이 작업을 수행하는 경우 파이썬 객체를 생성하기 위해 저렴하고 안정적인(메모리 위치 측면에서) 방법을 원할 것입니다.

팬더 게시판에서 이러한 태도가 왜 흔한지 솔직히 잘 모르겠습니다. 팬더가 numpy보다 높은 수준의 구성이라는 것을 이해하는 한 불행한 일이라고 생각합니다. 사람들이 팬더 "위에서" 개발하는 것이 여전히 더 쉬울 수 있습니다. pandas DataFrame은 테이블 형식 데이터를 python으로 내보내려는 C 코드가 있는 경우 작업하기에 가장 바람직한 유형이므로 이것은 실제로 중요한 사용 사례처럼 보입니다.

내가 쓰고 있는 것을 부정적으로 받아들이지 마세요. pandas DataFrames가 그렇게 훌륭하다고 생각하지 않았다면 그냥 numpy 레코드나 이와 유사한 것을 사용하고 끝낼 것입니다.

@ARF1 : 궁극적으로 이유는 기억나지 않지만 내가 할 수 있는 최선은 Copy=False인 numpy 배열에서 각 숫자 유형에 대한 DataFrame을 만든 다음 Copy=False인 pandas.concat을 다시 사용하는 것이었습니다. 연결합니다. numpy 배열에서 단일 유형 DataFrame을 만들 때 numpy 배열의 방향에 매우 주의하십시오. 방향이 잘못되면 각 열에 해당하는 numpy 배열이 자연스럽게 늘어납니다. pandas는 이것을 좋아하지 않으며 첫 번째 기회에 복사본을 만듭니다. Categorical은 통합되지 않고 나머지 프레임의 복사본을 트리거하지 않아야 하므로 끝에 Categorical을 추가할 수 있습니다.

이 작업을 단계별로 수행하고 (기본 numpy 배열의 array_interface 를 통해) 기본 데이터에 대한 포인터를 지속적으로 잡고 복사본이 실제로 생략되는지 확인하기 위해 동일한지 확인하는 몇 가지 단위 테스트를 작성하는 것이 좋습니다. 복사/인플레이스 매개변수를 존중할 필요가 없다는 것은 팬더의 매우 불행한 결정입니다. 즉, DataFrame 생성자에 대해 예를 들어 copy=False로 설정하더라도 pandas는 DataFrame을 생성하기 위해 필요하다고 결정하면 여전히 복사를 수행합니다. pandas가 인수를 사용할 수 없을 때 던지는 대신 이 작업을 수행한다는 사실은 복사본을 제거하는 코드를 안정적으로 작성하는 것을 매우 피곤하게 만들고 극도로 체계적이어야 합니다. 확인을 위해 단위 테스트를 작성하지 않으면 나중에 실수로 수정하여 복사본이 만들어질 수 있으며 이는 자동으로 발생하여 성능을 망칠 것입니다.

@quicknir 그렇게 말하면. 최적화를 시도하기 전에 간단히 프로파일링해야 한다고 생각합니다. 내가 전에 말했듯이, 그리고 prob는 다시 할 것입니다. 건설 시간이 무엇이든 지배해서는 안됩니다. 그렇다면 DataFrame을 사용하여 물건을 보관하는 것이므로 처음에 사용하는 요점은 무엇입니까? 지배하지 않는다면 무엇이 문제인가?

@jreback 아직 프로파일링을 하지 않았다고 가정하고 작성합니다. 사실, 나는 가지고있다. 동일한 데이터 형식에서 테이블 형식 데이터를 역직렬화하는 C++ 및 Python 코드가 있습니다. 파이썬 코드에 약간의 오버헤드가 있을 것으로 예상했지만 디스크 읽기 시간이 지배적이어야 하므로 차이가 작아야 한다고 생각했습니다. 내가 가서 사본을 최소화하기 위해 극도로 주의 깊게 재작업하기 전에는 파이썬 버전이 C++ 코드에 비해 두 배나 더 오래 걸리거나 더 나빠졌고 거의 모든 오버헤드가 DataFrame을 생성하는 데 있었습니다. 다시 말해, 내용에 전혀 신경 쓰지 않은 아주 큰 크기의 DataFrame을 생성하는 데 내가 관심 있는 데이터를 읽고, 압축 해제하고, 해당 DataFrame에 쓰는 것만큼 대략적으로 시간이 걸렸습니다. 그것은 매우 열악한 성능입니다.

내가 특정 작업을 염두에 두고 이 코드를 사용하는 최종 사용자였다면 아마도 지배적이지 않은 구성에 대해 말씀하신 내용이 타당할 것입니다. 사실 저는 개발자이고 이 코드의 최종 사용자는 다른 사람들입니다. 나는 그들이 DataFrame으로 무엇을 할 것인지 정확히 알지 못합니다. DataFrame은 디스크에 있는 데이터의 메모리 표현을 얻는 한 가지 방법입니다. 디스크의 데이터로 매우 간단한 작업을 수행하려면 여전히 DataFrame 형식을 거쳐야 합니다.

분명히 데이터를 가져오는 더 많은 방법(예: numpy 구문)을 지원할 수 있지만 이렇게 하면 코드에서 분기가 크게 증가하고 개발자로서 작업이 훨씬 더 어려워집니다. DataFrames가 그렇게 느려야 하는 근본적인 이유가 있다면 DataFrame, numpy 또는 둘 다를 지원할지 여부를 이해하고 결정할 것입니다. 하지만 그렇게 느려야 할 진짜 이유는 없습니다. 각 튜플에 열 이름과 유형, 행 수가 포함된 튜플 배열을 사용하는 DataFrame.empty 메서드를 작성할 수 있습니다.

이것이 내가 말하는 지원 사용자와 라이브러리 작성자의 차이점입니다. 라이브러리를 작성하는 것보다 자신의 코드를 작성하는 것이 더 쉽습니다. 그리고 라이브러리가 다른 라이브러리 작성자 대신 사용자만 지원하도록 하는 것이 더 쉽습니다. 이 경우 DataFrames의 빈 할당은 나와 @ARF1 과 같은 사람들의 삶을 더 쉽게 만들어 줄 팬더의 낮은 매달린 과일이 될 것이라고 생각합니다.

모든 귀에 합당한 테스트를 거친 문서화된 솔루션을 갖고 싶다면 글쎄요. pandas에는 꽤 많은 사용자/개발자가 있습니다. 이것이 DataFrame이 매우 다재다능한 이유이며 많은 오류 검사 및 추론이 필요한 것과 같은 이유입니다. 위에서 설명한 대로 수행할 수 있는 작업을 볼 수 있습니다.

나는 이것을 구현하는 데 시간을 할애할 의향이 있지만, 몇몇 판다 개발자들로부터 디자인에 대한 합리적인 합의가 있는 경우에만 가능합니다. 내가 풀 리퀘스트를 제출하고 사람들이 변경하기를 원하는 특정 사항이 있다면 그것은 멋진 일입니다. 또는 10시간을 투자한 후에 깔끔하게 처리할 수 있는 방법은 없고 사람들이 불쾌하다고 생각하는 것을 포함할 수 있는 유일한 방법이 있다는 것을 깨닫는다면 그것도 좋습니다. 하지만 나는 X시간을 보내는 것이 별로 좋지 않고 이것이 그다지 유용하지 않다는 말을 듣고 구현이 지저분하고 실제로 정리할 수 없다고 생각하고 코드베이스를 복잡하게 만드는 등의 작업을 수행할지 모르겠습니다. 나는 이 감정과는 거리가 멀고 이전에 OSS 프로젝트에 큰 기여를 하지 않았기 때문에 그것이 어떻게 작동하는지 모릅니다. 내 초기 게시물에서 바로 이것을 제안하기 시작했고 솔직히 말해서 나는 그것이 판다의 "범위를 벗어났다"는 인상을 받았습니다.

원하는 경우 새 문제를 열고 가능한 한 구체적인 디자인 제안을 만들고 피드백/잠정 승인이 있으면 가능한 한 작업하겠습니다.

@quicknir 의 핵심은 매우 포괄적인 전체 테스트 스위트를 통과해야 한다는 것입니다.

이것은 팬더의 범위를 벗어나는 것은 아니지만 API는 다소 사용자 친화적이어야 합니다.

왜 싫어했는지 모르겠어

concat(list_of_arrays,axis=1,copy=False) 나는 이것이 당신이 원하는 것을 정확히 수행한다고 믿습니다(그렇지 않다면 당신이 실제로 원하는 것이 무엇인지 명확하지 않습니다).

비슷한 기술을 사용했지만 각각 다른 유형의 단일 numpy 배열에서 생성된 DataFrames 목록을 사용했습니다.

우선, 이 기술을 수행할 때 여전히 일부 사본을 만난 것 같습니다. 내가 말했듯이 pandas는 항상 copy=False를 존중하지 않으므로 코드가 실제로 복사되고 있는지 확인하는 것은 매우 피곤합니다. pandas 17의 경우 개발자가 copy=True를 기본값으로 설정한 다음 복사본을 생략할 수 없을 때 copy=False가 발생하기를 진심으로 바랍니다. 하지만 어쨌든.

둘째, 또 다른 문제는 나중에 열을 재정렬해야 한다는 것이었습니다. 이것은 놀라울 정도로 어색했습니다. 복사본을 만들지 않고 이 작업을 수행할 수 있는 유일한 방법은 원래 원하는 최종 순서로 정렬된 열 이름을 정수로 만드는 것이었습니다. 그런 다음 제자리에서 인덱스 정렬을 수행했습니다. 그런 다음 열 이름을 변경했습니다.

셋째, 타임스탬프 유형(numpy datetime64)에 대해 사본이 불가피하다는 것을 발견했습니다.

이 코드는 얼마 전에 작성했기 때문에 마음에 새롭지 않습니다. 내가 실수했을 수도 있지만 꽤 신중하게 검토했고 그것이 당시 내가 생각해 낸 결과입니다.

위에서 제공한 코드는 numpy 배열에서도 작동하지 않습니다. 다음과 함께 실패합니다. TypeError: 비 NDFrame 개체를 연결할 수 없습니다. 먼저 DataFrame으로 만들어야 합니다.

당신이 여기 또는 위에서 제공한 솔루션이 마음에 들지 않는다는 것은 아닙니다. 나는 아직 작동하는 간단한 것을 보지 못했습니다.

@quicknir 위의 예는 잘 작동합니다. pls는 정확히 무엇을 하고 있는지 제공하고 도와드릴 수 있습니다.

pd.concat([np.zeros((2,2))], 축=1, 복사=거짓)

저는 팬더 0.15.2를 사용 중이므로 아마도 0.16에서 작동하기 시작했습니까?

pls는 pd.concat 의 문서 문자열을 읽습니다. DataFrame 를 통과해야 합니다.

btw copy=True 는 기본값입니다.

맞습니다. 제가 쓴 것입니다. 위에서 작성한 코드 조각에는 list_of_dataframes가 아니라 list_of_arrays가 있습니다. 어쨌든 우리는 서로를 이해하고 있다고 생각합니다. 나는 결국 pd.concat 방법을 사용하게 되었지만 꽤 사소하지 않습니다.

1) DataFrames의 목록을 생성해야 합니다. 각 DataFrame에는 정확히 하나의 고유한 dtype이 있어야 합니다. 따라서 시작하기 전에 모든 다른 dtypes를 수집해야 합니다.

2) 각 DataFrame은 원하는 dtype, 동일한 수의 행, 원하는 수의 열 및 order = 'F' 플래그의 단일 numpy 배열에서 생성되어야 합니다. order='C'(기본값)이면 pandas는 그렇지 않으면 복사하지 않을 때 종종 복사합니다.

3) 무시 1) Categoricals의 경우 나중에 추가할 수 있도록 블록으로 병합되지 않습니다.

4) 모든 개별 DataFrame을 생성할 때 열은 원하는 순서를 나타내는 정수를 사용하여 이름을 지정해야 합니다. 그렇지 않으면 복사를 트리거하지 않고 열 순서를 변경할 방법이 없을 수 있습니다.

5) DataFrames 목록을 만든 후 concat을 사용합니다. 복사를 생략할 수 없는 경우 copy=False가 발생하지 않고 조용히 복사하기 때문에 아무 것도 엉망으로 만들지 않았는지 열심히 확인해야 합니다.

6) 원하는 순서대로 열 인덱스를 정렬한 다음 열의 이름을 바꿉니다.

이 절차를 엄격하게 적용했습니다. 하나의 라이너가 아니고 실수할 곳이 많고 여전히 타임스탬프에서 작동하지 않았다고 확신합니다. 인터페이스만 사용하지 않음으로써 생략할 수 있는 불필요한 오버헤드가 많이 있습니다. 원한다면 공개 API만 사용하여 이 함수가 어떻게 생겼는지 초안을 작성할 수 있습니다. 이 기능이 실제로 사본을 생략하는지 확인하기 위해 일부 테스트와 결합할 수 있습니다.

또한 copy=False는 DataFrame 생성자의 기본값입니다. 내 요점은 인수를 존중할 수 없는 함수가 "합리적인 작업을 수행"하는 것보다 던져야 한다는 것입니다. 즉, copy=False를 적용할 수 없는 경우 예외가 발생하여 사용자가 다른 입력을 변경해야 복사 생략이 발생하거나 복사를 True로 변경해야 함을 알 수 있습니다. copy=False일 때 복사가 자동으로 발생해서는 안 됩니다. 이는 성능에 민감한 사용자가 버그를 찾는 데 더 놀랍고 덜 도움이 됩니다.

필요하지 않은 단계가 많이 있습니다.
pls는 위에서 한 것처럼 실제 예를 보여줍니다.

numpy 뷰는 매우 간단한 형태 변경 작업(때로는)으로 복사본을 반환할 수 있고 다른 것은 반환하지 않을 수 있음을 이해합니다.

단순하고 강력한 성능 코드의 목적을 정의적으로 무효화하는 많은 내성 없이는 일반적으로 불가능하기 때문에 복사에 대한 소프트 보증만 있을 것입니다.

DataFrame 구성에서 copy=False 의 동작은 numpy의 np.array 함수와 일치합니다(예: 배열 목록을 제공하면 최종 데이터는 항상 복사본을 만듭니다).

이것은 팬더의 불행한 기능 격차인 것 같습니다. IMHO, 우리는 현재 판다 내부 모델(블록을 통합하는)로는 만족스러운 솔루션을 결코 가질 수 없을 것입니다. 불행히도, 그것은 팬더를 위한 옵션이 아닙니다. 왜냐하면 팬더는 여전히 많은 열로 DataFrame을 만드는 사람들을 위해 작동해야 하기 때문입니다.

우리에게 필요한 것은 각 열을 1D numpy 배열로 독립적으로 저장하는 깔끔한 데이터 작업을 위해 특별히 설계된 대체 DataFrame 구현입니다. 이것은 열을 N차원 배열로 허용한다는 점을 제외하고는 xray 의 데이터 모델과 실제로 다소 유사합니다.

공간만 할당하는 일반적인 고성능 pandas 데이터 프레임 생성자는 지원해야 하는 다양한 열 유형을 고려할 때 중요하지 않습니다.

즉, pandas 데이터 프레임을 고성능 데이터 컨테이너로 사용하여 필요한 열 유형으로 제한된 할당 전용 데이터 프레임 생성자를 구현하려는 라이브러리 작성자에게는 상당히 간단해 보입니다.

다음 코드 세그먼트는 영감을 줄 수 있습니다. 거의 numpy 속도로 채워지지 않은 할당 전용 데이터 프레임을 인스턴스화할 수 있습니다. 코드에는 PR #9977이 필요합니다.

import numpy as np
from pandas.core.index import _ensure_index
from pandas.core.internals import BlockManager
from pandas.core.generic import NDFrame
from pandas.core.frame import DataFrame
from pandas.core.common import CategoricalDtype
from pandas.core.categorical import Categorical
from pandas.core.index import RangeIndex

def allocate_like(df, size, keep_categories=False):
    # define axes (uses PR #9977)
    axes = [df.columns.values.tolist(), RangeIndex(size)]

    # allocate and create blocks
    blocks = []
    for block in df._data.blocks:
        # special treatment for non-ordinary block types
        if isinstance(block.dtype, CategoricalDtype):
            if keep_categories:
                categories = block.values.categories
            else:
                categories = Index([])
            values = Categorical(values=np.empty(shape=block.values.shape,
                                                 dtype=block.values.codes.dtype),
                                 categories=categories,
                                 fastpath=True)
        # ordinary block types
        else:
            new_shape = (block.values.shape[0], size)
            values = np.empty(shape=new_shape, dtype=block.dtype)

        new_block = block.make_block_same_class(values=values,
                                                placement=block.mgr_locs.as_array)
        blocks.append(new_block)

    # create block manager
    mgr = BlockManager(blocks, axes)

    # create dataframe
    return DataFrame(mgr)

예제 생성자 allocate_like() 하면 성능 패널티 cf numpy는 큰 배열의 경우 x2.3(일반적으로 x333)이고 크기가 0인 배열의 경우 x3.3(일반적으로 x8.9)입니다.

In [2]: import numpy as np

In [3]: import pandas as pd

In [4]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4'))

# create template-dataframe
In [5]: df = pd.DataFrame(a)

# large dataframe timings
In [6]: %timeit np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4'))
1000 loops, best of 3: 212 µs per loop

In [7]: %timeit allocate_like(df, size=int(1e6))
1000 loops, best of 3: 496 µs per loop

In [8]: %timeit pd.DataFrame(np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4')))
10 loops, best of 3: 70.6 ms per loop

# zero-size dataframe timing
In [9]: %timeit np.empty(0, dtype=('i4,i4,f4,f4,f4'))
10000 loops, best of 3: 108 µs per loop

In [10]: %timeit allocate_like(df, size=0)
1000 loops, best of 3: 360 µs per loop

In [11]: %timeit pd.DataFrame(np.empty(0, dtype=('i4,i4,f4,f4,f4')))
1000 loops, best of 3: 959 µs per loop

죄송합니다. 잠시 동안 이 정보를 찾지 못했습니다. @ARF1 , 위의 코드 샘플에 대해 대단히 감사합니다. 성능 지표와 함께 매우 좋습니다.

데이터 없이 DataFrame의 레이아웃에 해당하는 클래스를 만들면 위와 같은 코드가 훨씬 더 자연스럽고 성능도 향상될 것이라고 생각합니다. 이 클래스는 예를 들어 행의 재인덱싱을 수행할 때 재사용할 수도 있습니다.

내가 기본적으로 제안하는 것은 dtypes, 열 이름 및 열 순서를 래핑하는 DataFrameLayout이라는 클래스입니다. 예를 들어, dtype에서 열 번호(순서용)까지의 사전과 모든 이름이 포함된 별도의 배열을 저장할 수 있습니다. 이 레이아웃에서 dict에 대한 간단하고 우아한 반복을 통해 블록 관리자를 빠르게 만들 수 있음을 알 수 있습니다. 그런 다음 이 클래스는 빈 생성자와 같은 위치 또는 재인덱싱 작업에서 사용할 수 있습니다.

더 복잡한 데이터에는 이러한 추상화가 필요하다고 생각합니다. 어떤 의미에서 DataFrame은 복합 데이터 유형이고 DataFrameLayout은 구성의 정확한 특성을 지정합니다.

그건 그렇고, 나는 비슷한 것이 범주형에 필요하다고 생각합니다. 즉, 범주, 정렬 여부, 지원 배열 유형 등을 저장하는 CategoricalType 추상화가 있어야 합니다. 즉, 실제 데이터를 제외한 모든 것입니다. 실제로 DataFrameLayout에 대해 생각할 때 모든 열에는 완전히 지정된 유형이 있어야 하며 이는 현재 Categoricals에 문제가 있음을 알게 됩니다.

사람들은 이 두 부류에 대해 어떻게 생각합니까?

@quicknir 우리는 이미 CategoricalDtype 클래스를 가지고 있습니다 -- 귀하가 설명하는 전체 CategoricalType 로 확장될 수 있다는 데 동의합니다.

나는 DataFrameLayout 클래스에 대해 완전히 확신하지 못합니다. 기본적으로 데이터 프레임에 대해 더 간단한 대안 데이터 모델을 사용할 수 있다고 생각합니다(R 또는 Julia에서 수행되는 방식과 더 유사함). 이런 종류의 일에 약간의 관심이 있고 나는 그것이 결국 어떤 형태로든 일어날 것이라고 생각하지만 아마도 조만간 (그리고 아마도 판다 프로젝트의 일부로) 일어나지 않을 것입니다.

@quicknir 예 , DataFrameLayout 는 여기서 바퀴를 재발명하고 있습니다. 우리는 이미 dtype 사양을 가지고 있습니다. 예를 들어

In [14]: tm.makeMixedDataFrame().to_records().dtype
Out[14]: dtype([('index', '<i8'), ('A', '<f8'), ('B', '<f8'), ('C', 'O'), ('D', '<M8[ns]')])

@jreback dtype 사양에는 몇 가지 주요 문제가 있으므로 바퀴를 재발명하지 않습니다.

1) 내가 볼 수 있는 한 to_records()는 전체 DataFrame의 전체 복사를 수행합니다. DataFrame에 대한 사양(지금부터 이 용어만 사용하겠습니다)을 얻는 것은 저렴하고 쉬워야 합니다.

2) to_records의 출력은 numpy 유형입니다. 이것의 의미 중 하나는 이것이 Categoricals를 적절하게 지원하도록 확장될 수 있는 방법을 알지 못한다는 것입니다.

3) 사양을 내부적으로 저장하는 이 방법은 데이터가 DataFrame 내부에 저장되는 방식(예: dtype과 같은 블록)과 쉽게 호환되지 않습니다. 이러한 사양에서 블록을 생성하려면 dtype에서 열 번호로의 사전을 사용하여 내가 제안한 방식으로 사양을 저장하여 생략할 수 있는 많은 추가 작업이 필요합니다. 2000개의 열이 있는 DataFrame이 있는 경우 비용이 많이 듭니다.

요컨대, 레코드 표현의 dtype은 적절한 사양의 부족에 대한 해결 방법에 가깝습니다. 몇 가지 주요 기능이 부족하고 성능이 훨씬 떨어집니다.

SO에는 이 기능을 요구하는 많은 스레드가 있습니다.

이 모든 문제는 개별 열을 단일 메모리 청크('블록')로 통합하는 BlockManager에서 비롯된 것 같습니다.
copy=False가 지정된 경우 가장 쉬운 수정은 데이터를 블록으로 통합하지 않는 것입니다.

비 통합 원숭이 패치 BlockManager가 있습니다.
https://stackoverflow.com/questions/45943160/can-memmap-pandas-series-what-about-a-dataframe
이 문제를 해결하는 데 사용했습니다.