Polars #10

#전처리 #1억ROW

100,000,000 이라는 숫자는 빅데이터를 하다보면 

별로 큰 숫자도 아닌 것처럼 보인다.

그래서 Spark 를 통해서 분산처리를 하곤 한다.

특히,

복잡한 전처리 / 후처리 로직을 붙이면 메모리는 기하급수적으로 늘어나고

Spark 엔진도 터지는 현상을 보곤한다.

무엇이 문제일까?

CPU, MEMORY 둘다 문제가 될 수 있겠지만

AWS를 사용하는 환경에서 대부분 이런 문제는 Scale-out 또는 Scale-up 으로

문제를 해결하곤 한다.

Polars 는 이런 부분에서 강점이 있는 듯 하다.

간단하게 1억 ROW 데이터의 전처리를 통해서 Polars 의 강점을 확인해보았다.

먼저 Dummy Data 를 만들어보면,

좀 억지스럽지만 일단 1억개의 ROW 를 갖는 데이터를 만들고

parquet 으로 파일 저장을 마쳤다.

시나리오는,

각 사용자별 상품이 나열되고(시간순서라고 가정하면) 연속해서 3번이 나오면

해당하는 상품은 제외시키는 전처리 로직을 추가한다.

추가적으로 유니크한 상품군이 적어도 1개 이상 존재하는 사용자 데이터만 유지하도록 조건을 수행한다.

생각보다 결과가 빨리 나왔다.

이번에 unique_items 를 2개 이상으로 조정한다면?

결과는 2개가 빠진 70_000_000개의 결과를 Return 받는다.

왜 그럴까?

map_groups 에 대해서 좀 더 분석해보면

user_id 로 group 를 이미 잡았기 때문에

사용자 3번의 상품은 203 으로만 이어진 리스트가 된다.

그래서! [203, 203, 203, ... 203] 은 결국 [203, 203] 으로만 나타난다.

https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.map_groups.html

polars.map_groups — Polars documentation

해당 함수 또한 느려질 수 있다는 Warning 이 존재하기 때문에

이런 로직을 어떻게 Native API 로 변경 할 수 있는지 확인이 필요하다.