▲

GN⁺: 파이썬 데이터프레임 라이브러리 Ibis, Pandas 와 Dask 백엔드를 폐기

 (ibis-project.org)
8P by neo with xguru 3달전 | favorite | 댓글 2개
  • pandas와 dask 백엔드를 폐기하고 버전 10.0에서 제거할 예정임
  • pandas 백엔드와 기본 DuckDB 백엔드 간의 기능 차이가 없으며, DuckDB가 훨씬 더 성능이 뛰어남
  • pandas DataFrame은 여전히 Ibis에서 데이터를 주고받는 형식으로 사용 가능하지만, pandas를 사용하여 쿼리를 실행하는 것은 지원하지 않음
  • 대부분의 논리는 dask 백엔드에도 적용되며, dask는 훌륭한 프로젝트로 Ibis 외부에서는 계속 사용해야 함

왜 pandas인가? 그리고 Ibis의 역사

  • Ibis 초기에는 Impala 백엔드만 존재했음
  • Postgres 백엔드가 추가되었지만, 설치가 복잡하여 사용자가 쉽게 Ibis를 시도할 수 없었음
  • 노트북 이외의 추가 인프라 없이 Ibis API를 시험해 볼 수 있는 방법이 필요했음
  • 당시 유일한 인메모리 DataFrame 엔진인 pandas 백엔드를 연결하는 것이 명백한 답이었음

Pandas 백엔드의 어려움

  • pandas는 당시 최고의 선택이었지만, Ibis의 데이터 분석 모델과 잘 맞지 않았음
  • pandas 백엔드는 다른 백엔드와 근본적으로 달라 가장 많은 특수 코드를 가지고 있음
  • pandas는 본질적으로 즉시 실행 엔진이며, Ibis는 지연 실행 모델을 사용함
  • pandas 인터페이스를 지연 방식으로 작동하게 만드는 것은 어려움
  • pandas 백엔드는 다른 백엔드보다 느리며, 이를 위해 수천 줄의 코드가 필요함
  • pandas의 NaN과 Ibis의 NULL은 근본적으로 다른 개념이지만, 이를 같은 것으로 취급해야 함
    • pandas에서 NaN을 결측값의 표시로 사용했지만, 이는 다른 백엔드와의 호환성 문제를 일으킴
    • NULL은 결측값을 나타내고, NaN은 숫자가 아님을 나타내는 fundamentally 다른 개념임
  • pandas의 새로운 Arrow 기반 타입은 큰 개선이지만, 여전히 문제점이 있음

새로운 사용자에게 혼란을 줌

  • 사람들은 익숙한 것을 선호함
  • 처음 Ibis를 사용할 때 Ibis와 백엔드를 모두 선택해야 함
  • 새로운 사용자들은 종종 "Ibis가 느리다"고 보고함
  • 이는 대부분 pandas 백엔드를 사용했기 때문임
  • DuckDB나 Polars를 사용했다면 훨씬 쉽게 시작할 수 있었을 것임

기능 동등성

  • pandas 백엔드를 제거하는 가장 강력한 이유는 중복성 때문임
  • DuckDB 백엔드는 pandas DataFrame을 원활하게 쿼리할 수 있으며, 여러 형식의 UDF를 지원하고, parquet, CSV, JSON 등 다양한 형식을 읽고 쓸 수 있음
  • DuckDB는 설치가 쉽고, 로컬에서 실행되며, 매우 빠르고, Python 생태계와 잘 상호작용함

GN⁺의 정리

  • DuckDB를 기본 백엔드로 채택한 것은 매우 현명한 결정으로 보임. 설치가 쉽고, 로컬에서 실행되며, 매우 빠르고, 파이썬 생태계와 잘 상호작용함. 이는 Ibis가 처음에 pandas를 백엔드로 추가한 이유이기도 함
  • pandas가 여전히 데이터 주고받는 포맷으로 사용될 수 있다는 점은 기존 pandas 사용자에게 좋은 소식임. 기존 코드를 완전히 버릴 필요는 없음
  • 그러나 쿼리 실행에 pandas를 더 이상 사용하지 않는 것은 올바른 방향으로 보임. pandas의 열성적 실행 모델은 Ibis의 지연 실행 모델과 맞지 않음. 이로 인해 pandas 백엔드는 종종 직접 pandas를 사용하는 것보다 훨씬 느림
  • Ibis가 점점 더 많은 백엔드를 지원함에 따라 특정 백엔드에 맞춰진 코드를 유지보수하는 것은 점점 더 어려워질 것임. pandas 백엔드를 제거하면 코드베이스가 더 깔끔해지고 유지보수가 쉬워질 것임
  • DuckDB 백엔드를 사용하는 것이 pandas의 모든 기능을 대체할 수 있다면, pandas 백엔드를 유지할 이유가 없어 보임. 오히려 새로운 사용자에게 혼란을 줄 수 있음
▲
yangeok 3달전  [-]

제일 익숙한 pandas를 여전히 많이 쓰고 있는게 현실이죠,,

답변달기
▲
neo 3달전  [-]
Hacker News 의견

  • NaN은 0/0의 결과로, 값이 존재하지만 정확히 알 수 없음을 의미함

    • NULL은 특정 위치의 값을 알 수 없음을 의미함
    • NaN과 NULL의 구현이 다르지만 완전히 무관하지 않음
    • Python의 None은 NaN과 NULL과 다름

  • pandas보다 더 나은 컴퓨팅 엔진이 많음

    • 기존 코드베이스와 서드파티 통합 때문에 pandas를 계속 사용함
    • 작은 데이터 작업에는 pandas가 충분히 적합함

  • 최근 몇 달 동안 새로운 프로젝트에서 pandas를 ibis로 대체함

    • ibis의 문법이 pandas보다 더 유연함
    • 연산 체이닝이 코드 스니펫을 더 이식 가능하게 만듦
    • Duckdb 백엔드가 매우 빠름
    • 커뮤니티가 매우 활발하고 친절함
    • ibis를 동료들에게 홍보 중임

  • pandas의 멀티 인덱스 기능이 가장 강력함

    • 열에도 사용할 수 있음
    • 새로운 도구들이 이 기능을 어떻게 처리할지 확신이 없음

  • Polars를 고려해봤는지 궁금함

    • 그룹에서 pandas를 싫어해서 Polars를 표준으로 사용 중임

  • pandas는 새로운 유형의 열에 확장 가능함

    • Polars가 이를 지원하는지 확실하지 않음

  • Ibis의 가치는 DuckDB를 사용할 수 있다는 점이 아님

    • 새로운 도구가 나와도 문법이 계속 작동함

  • Ibis에 대해 많이 들어본 적이 없음

    • pandas에서 벗어나면 Ibis를 시도할 가능성이 낮아짐
    • 새로운 프레임워크가 pandas/numpy에서 벗어나고 있지만, 호환성과 엣지 케이스가 해결될 때까지 기다릴 예정임
    • 몇 밀리초 더 기다려도 상관없음

  • pandas의 라이브러리 API가 항상 직관적이지 않음

    • NaN/None 문제가 있지만 이는 사소한 불편함임

  • pandas를 사용하는 이유는 통합된 생태계 때문임

    • json 파일, csv 파일, python dict 등에서 데이터를 읽고 plotly로 시각화할 때 pandas가 편리함
    • Ibis가 pandas 데이터프레임과 호환된다면 백엔드에 크게 신경 쓰지 않음
답변달기