오리처럼 헤엄치면 오리다. 테이블처럼 보이면 질의할 수 있다

DuckDB 파이썬 패키지를 설치하고 어떤 의존성을 프로그램에 먼저 들여와야 하는지 익히는 것으로 시작한다. 그다음 인메모리 DuckDB 연결을 얻거나 데이터베이스 파일을 여는 서로 다른 선택지를 논한다. 이것을 파악해두는 일이 이 장뿐 아니라 이어지는 장들에도 중요하다. DuckDB와 상호작용하는 파이썬 생태계의 도구를 더 배우게 되기 때문이다.

파이썬 패키지 설치 6.1.1

DuckDB 파이썬 패키지는 PyPI에 배포되어 있다.

데이터베이스 연결 열기 6.1.2

어떤 프로그래밍 환경에서 데이터베이스를 쓸 때 흔히 떠오르는 물음 가운데 하나가 연결을 어떻게 여는가다. DuckDB의 경우 답이 간단하다. 열 필요가 없다. 임베디드 데이터베이스로서 이미 여러분의 파이썬 프로세스 안에서 돌고 있기 때문이다. 패키지를 설치하고 나면 파이썬 인터프리터에서 duckdb를 그냥 써서 인메모리 데이터베이스와 상호작용할 수 있다.

여기서 이 장의 두 축이 갈라진다. sql은 DuckDB의 관계형 파이썬 API로 들어가는 입구이고, execute는 Python DB-API 2.0을 쓴다.

제3·4장에서는 관계라는 수학적 개념을 너무 깊이 파고들지 않고 넘어갈 수 있었다. 이제는 피해 갈 방법이 없다. 이미 배운 대로 테이블만이 아니라 뷰와 함수도 질의할 수 있고, 다른 질의의 결과도 질의할 수 있다. 테이블, 뷰, 사영, 그리고 테이블처럼 행동하는 함수가 모두 관계다.

관계는 본질적으로 테이블의 일반화된 형태이며, 행과 컬럼 대신 튜플과 속성으로 이루어진다. 관계형 데이터베이스에서 튜플은 이름이 붙고 순서가 있는 속성의 목록으로 정의된다. 관계의 각 튜플이 하나의 레코드에 대응하고, 튜플의 각 속성이 하나의 컬럼에 대응한다. 저자들의 정리가 편하다. 관계를 테이블과 거의 같은 것으로 생각하라.

그리고 이 장에서 가장 자주 인용될 문단이 나온다. 요컨대 관계는 오리 시험을 통과한다. 오리처럼 보이고 오리처럼 헤엄치고 오리처럼 꽥꽥거리면 아마 오리다. 테이블처럼 보이면 질의할 수 있다. 데이터베이스 안에서 질의를 돌릴 때는 이것이 대개 자연스럽게 느껴지고 달리 기대하지도 않는다. DuckDB 파이썬 패키지는 이 개념을 파이썬 자체에 들여온다. 서로 다른 객체를 데이터베이스의 테이블이나 뷰인 것처럼 질의하게 해준다. 관계형 스키마를 가진 영속 저장소를 갖는 것과, 그저 관계처럼 행동할 뿐인 객체를 갖는 것 사이의 선이 여기서 상당히 흐려진다.

파이썬 API로 CSV 데이터 들이기 6.2.1

제3장과 비슷하게 닭과 달걀의 문제가 있다. 데이터가 없으면 질의할 것이 없다. 그래서 다시 데이터를 들이는 것으로 시작한다. 다만 이번에는 데이터를 위한 관계형 스키마를 만들지 않고, 제공된 객체를 그대로 관계로 쓴다.

소재는 제2장에서 소개한 Populations CSV 파일이다. 전과 같이 httpfs 확장을 쓰지만, 이번에는 파일 처리에 DuckDB의 SQL 함수 read_csv가 아니라 파이썬 API의 같은 이름 함수 read_csv를 쓴다. 이 방식이 파이썬 기반 작업 흐름과 매끄럽게 통합되며, "파이썬다운(pythonic)" 데이터 조작 방식을 제공해 SQL 데이터베이스와 파이썬 데이터 구조 사이의 틈을 메워준다.

그러나 관계형 API는 그보다 훨씬 많은 것이며 SQL 문을 쓰는 것의 대안으로 쓸 수 있다. 본질적으로 유창한(fluent) API이며 질의를 점진적으로 구성하게 해준다. DuckDBPyRelation 노드와 관계들로 이루어지고, 그것들은 SQL 질의의 상징적 표상으로 볼 수 있다. 그 노드의 재사용을 지원하고 집합 연산, 필터, 사영, 집계를 지원한다.

그리고 이 API의 성격을 규정하는 한 문장이 여기 있다. 관여하는 어떤 객체도 데이터를 들고 있지 않으며, 명시적 fetch나 보여주기 같은 트리거 메서드가 호출될 때까지 어떤 질의도 실행되지 않는다.

지금까지는 주로 관계의 레코드를 세는 법만 살펴보았다. 그것은 능력의 일부만 엿본 것이다. API는 DuckDBPyRelation을 위한 함수 한 벌을 제공한다.

왜 문자열 이어 붙이기보다 나은가

관계형 API를 빌더로 쓰는 것은 평범한 SQL을 쓸 때 부딪히는 문제 몇 가지를 해결해준다. 질의가 생성되거나 사용자 입력에 기반하는 경우가 많다. 그런데 SQL은 값을 표상하는 매개변수는 허용하지만 테이블이나 컬럼 이름을 매개변수화하는 것은 허용하지 않는다. 그래서 사람들은 동적인 테이블에서 선택하는 질의를 만들기 위해 흔히 어떤 종류의 문자열 이어 붙이기를 쓴다.

관계형 API는 그런 질의를 프로그램적으로 만드는 데 이점을 준다. 문자열 이어 붙이기와 씨름하는 대신 맥락을 아는 전용 메서드를 부를 수 있다. 그로써 유효하지 않은 질의나 SQL 주입에 취약한 질의를 만들 가능성이 줄고, 코드는 더 읽기 쉽고 조합하기 좋아진다.

이제 이 메서드들을 조합하면 무엇을 할 수 있는지 본다. 아래는 원서 6.2절이 차례로 보여주는 일곱 가지 조립을, 파이썬 쪽 코드와 그에 대응하는 SQL을 나란히 놓아 견줄 수 있게 만든 장치다. 결과는 모두 원서에 인쇄된 값을 그대로 옮겼다.

이 장치를 눌러보면 저자들이 짚은 두 가지가 손에 잡힌다. 첫째, 관계형 API를 쓸 때 연산의 순서는 성능에 영향을 주지 않는다. 중간에 어떤 결과도 실체화되지 않기 때문이다. 이것은 뒤에 논할 pandas 통합과 다르다. 결과 집합이 pandas 데이터프레임으로 변환되면 그 데이터프레임은 pandas의 성질을 갖게 되고, 그것은 통상 값이 즉시 계산된다는 뜻이다.

둘째, show 함수가 호출될 때까지 질의는 실행되지 않으며 메서드가 돌려주는 객체는 여전히 같은 질의 빌더다. 그러므로 예컨대 limit 뒤에 offset을 더 불러 건너뛸 행 수를 지정할 수도 있다.

그리고 over_10m이라는 변수 하나가 이 절의 주인공이 된다. 필터 부분을 복사해 붙이는 대신 잘 정의된 필터를 하나 만들어 여러 질의에서 매끄럽고 일관되게 재사용하는 것이다. over_10m 관계는 테이블이나 뷰, 공통 테이블 표현식이 하는 것과 똑같이 행동한다. 그것으로 지역별 집계를 구동하기도 하고, 필터를 하나 더 얹어 확장하기도 한다. 두 경우 모두 원래 정의를 손대지 않고 재사용했다.

관계형 객체는 SQL 테이블과 똑같은 유연함으로 다룰 수 있다. 이 능력이 파이썬 기반 데이터 연산과 SQL식 질의 사이를 유동적으로 넘나들게 해준다. 위 장치의 마지막 탭이 그 실물이다. FROM over_10m이라고 적었지만 over_10m은 테이블이 아니라 파이썬 변수다. 그런데 질의 안에서는 테이블처럼 취급된다.

관계형 API가 방대한 기능을 제공하기는 하지만, 특히 매개변수화된 질의가 관여하는 어떤 시나리오에서는 그 타고난 능력이 제약처럼 느껴질 수 있다. 그 틈을 메우기 위해 DuckDB는 Python DB-API 2.0을 따르는 execute 함수를 제공한다.

그리고 이 절의 마지막 문단이 이 장 전체의 지적 정점이다. 저자들의 논리를 그대로 옮기면 이렇다. execute에 넘긴 질의는 이름 붙은 매개변수를 쓰며 여느 준비된 문장과 똑같이 보인다. 그런데 그것이 질의하는 대상은 실제 테이블이 아니라 관계형 객체 over_10m이다. 게다가 그 관계형 객체 자체도 사영할 컬럼이나 질의할 밑단 테이블에 매개변수를 쓰는 방식으로 만들어졌을 수 있다. 그래서 모든 경우에 문자열 이어 붙이기를 피할 수 있다.

두 API의 한계가 서로의 빈자리를 정확히 메운다는 이 구도는, 설계가 잘된 도구에서만 볼 수 있는 종류의 균형이다. 어느 한쪽이 다른 쪽을 대체하려 하지 않았기에 얻어진 결과다.

데이터 생태계에서 DuckDB가 얻은 인기는 튼튼한 질의 엔진에 크게 힘입은 것이다. 파일 기반 연산에만 국한되지 않고, 이 엔진은 여러 데이터 인프라 도구의 인메모리 데이터 구조와 매끄럽게 통합된다. 그 영역에서 두드러진 도구 하나가 pandas다. 데이터 공동체에서 널리 쓰이는, 자리를 굳힌 오픈소스 데이터 분석 라이브러리다. DuckDB와 pandas의 결합은 데이터베이스 엔진의 능력과 데이터 조작 라이브러리의 유연함을 잇는다.

데이터를 다루는 사람이라면 기존 데이터베이스 함수가 내 특정한 필요를 채워주지 못하는 상황을 자주 만난다. 그것을 알기에 DuckDB는 강력한 기능을 갖췄다. 파이썬 패키지 안에서 사용자 정의 함수(UDF)를 만드는 능력이다.

UDF의 아름다움은 SQL 언어의 고유 능력을 확장하는 데 있다. 사용자가 자기만의 맞춤 함수를 정의할 수 있고, 파이썬 라이브러리의 방대한 생태계에서 이득을 본다. 복잡한 데이터 조작이든 수학적 계산이든 외부 도구와 API와의 통합이든, 가능성이 사실상 무한해진다. 실용적으로 말하면 이렇다. DuckDB에서 SQL 질의를 쓰다가 어떤 특정 함수가 있었으면 하고 바란 적이 있다면, 이제 파이썬으로 그것을 만들어 SQL 코드 안에서 불러 쓸 수 있다.

공백 서른다섯 칸의 문제

데이터 수집은 어떤 분석 파이프라인에서나 기본 단계이지만 그 자체의 어려움을 함께 데려온다. 원자료는 지저분할 수 있고, 의미 있는 분석을 하기 전에 바로잡아야 할 오류를 만나는 일이 드물지 않다. 이 장 처음에 수집한 CSV 파일에도 손봐야 할 별스러움이 하나 나타났다.

문제는 데이터셋의 Region 필드에 있다. 이 필드가 지나친 공백 문자로 채워져 있어 데이터 처리와 분석이 번거로워진다. 문제의 크기를 눈으로 보기 위해 유일한 Region 값과 각각의 총 문자 길이를 구해본다.

타입을 명시하는 것은 명료함을 위해, 타입 추론의 함정을 막기 위해, 그리고 서로 다른 환경에서 일관된 동작을 보장하기 위해 이롭다. 함수를 명시적 타입으로 다시 정의하려면 충돌을 피하기 위해 먼저 앞서 등록한 판본을 제거해야 한다.

쉼표를 점으로 바꾸는 것과 로케일을 이해하는 것

다양한 출처의 데이터를 다루면 지역적 차이에서 비롯되는 어려움이 흔히 끼어든다. 그 훌륭한 예가 소수의 표기다. 유럽 지역에서는 다른 지역이 쓰는 마침표(.) 대신 쉼표(,)를 소수 구분자로 쓰는 것이 통상이다. 데이터를 데이터베이스에 들일 때 이런 로케일별 표기법은 복잡함을 불러오며, 시스템의 로케일이 데이터의 형식과 맞지 않으면 더욱 그렇다.

이 데이터셋에서도 소수를 표상하는 필드에서 그런 어려움을 만났다. 유럽식 형식 때문에 DuckDB가 그것들을 VARCHAR로 해석했고, 수치 분석을 방해할 수 있다. 바로잡기 위해 파이썬의 광범위한 라이브러리 생태계를 활용한다. locale 모듈이 이 특정한 어려움에 해법을 준다.

데이터 분석의 영역에서 적응성은 튼튼한 시스템을 규정하는 성질이다. 서로 다른 형식이나 플랫폼 사이를 매끄럽게 넘나드는 능력이 효율적인 데이터 조작과 저장과 시각화를 가능하게 한다. DuckDB의 강점 하나는 인메모리든 외부든 다양한 데이터 형식과 상호작용하는 능력이다. 이 상호운용성은 특히 다른 도구와 통합하거나 결과를 후속 분석을 위해 내보낼 때 값을 헤아릴 수 없이 요긴하다.

Polars, 그리고 그 밑에 깔린 Arrow

데이터 과학 생태계에 도구가 넘쳐나지만, 더 나은 성능이나 독특한 기능을 제공하는 라이브러리가 끊임없이 등장한다. 그 떠오르는 별 하나가 Polars다. pandas가 오랫동안 파이썬 데이터 분석의 사실상 표준이었지만, Polars는 흥미로운 대안으로 스스로를 내세운다. 성능 특성으로 알려진 언어인 Rust로 개발되었고, 빠르면서 메모리 효율적인 데이터프레임 연산을 제공한다.

그런데 이 절에서 정말 중요한 것은 Polars가 아니라 그 밑에 깔린 것이다. Polars가 쓰는 메모리 모델은 Apache Arrow에 기반한다. Arrow는 인메모리 데이터를 위한 언어 횡단 개발 플랫폼으로, 평면 데이터와 계층 데이터 양쪽에 대해 표준화되고 언어에 독립적인 컬럼 메모리 형식을 규정한다. 그리고 그 결과가 이것이다. Arrow는 무복사(zero-copy) 읽기를 허용하며, 언어와 시스템 사이에 직렬화 부담 없이 빠른 데이터 접근과 교환을 가능하게 한다.

사실 Arrow를 인메모리 형식으로 쓰는 프레임워크가 Polars만은 아니다. pandas 데이터프레임과 NumPy, PySpark 같은 다른 파이썬 라이브러리도 그렇다. 그러니 Arrow는 경쟁하는 도구들이 딛고 선 공통의 바닥인 셈이며, DuckDB가 그 바닥에 직접 닿는다는 것이 이 절의 요지다.