데이터베이스에 아무것도 담지 않고 데이터베이스를 쓰는 법

영속화하지 않고 데이터를 탐색하고 분석하는 것이 이치에 맞는 경우가 있다. 원격에 저장된 데이터를 다룰 때다. 예컨대 파일이 아마존 S3에 놓여 있다고 하자. 이 데이터로 운영 파이프라인을 지을지 아직 알 수 없으니, 제3장에서 했던 것처럼 데이터 모델을 정의하는 데 한참을 쓰고 원격 데이터를 DuckDB의 저장 형식으로 수집해 넣고 싶지는 않다. 또는 프라이버시 때문에 영속화하고 싶지 않은 데이터일 수도 있다.

그러면서도 앞 장들에서 배운 DuckDB와 SQL을 활용해 데이터의 모양과 크기를 파악하고는 싶다. 여기에 요긴한 사실이 하나 붙는다. 파일 형식과 저장 위치에 따라, DuckDB는 파일 내용 전부를 내려받을 필요조차 없을 수 있다. 나중 단계에 가서 데이터를 DuckDB로 수집하기로 정할 수도 있다. 곧, 영속화는 선택이고 그 선택을 뒤로 미룰 수 있다는 것이다.

이미 갖고 있는 데이터베이스를 그대로 쓰기

웬만하면 인프라에 이미 어떤 종류의 데이터베이스가 있을 것이다. DuckDB는 다른 여러 데이터베이스의 저장 시스템을 쓸 수 있다. 가장 두드러진 것이 SQLite와 Postgres 통합이다. 전자는 SQLite 저장 파일에 직접 동작하고, 후자는 Postgres 클라이언트–서버 프로토콜의 이진 전송 모드로 동작한다. 어느 경우든 데이터는 DuckDB 프로세스 안에 없지만, 그럼에도 DuckDB의 빠른 질의 엔진과 SQL 지원의 이점을 누릴 수 있다.

그리고 저자들이 던지는 숫자 하나가 이 절의 백미다. TPC-H 벤치마크 질의 22개 가운데 많은 경우, Postgres 통합을 쓴 DuckDB가 Postgres 자신보다 빨랐다. 그리고 자체 저장을 쓸 때는 모든 질의에서 더 빨랐다. 남의 창고에 든 데이터를 남의 프로토콜로 꺼내 오면서도 주인보다 빨리 계산한다는 이야기이니, 엔진의 값어치를 이보다 선명하게 보여주는 문장을 찾기 어렵다.

DuckDB에는 파일 또는 파일 집합을 처리하기 아주 쉽게 만들어주는 기능이 둘 있다. 읽고 있는 것이 어떤 종류의 파일인지—파일 형식 자동 추론—와 그 파일 안 데이터의 스키마를 모두 알아낸다.

파일 형식 자동 추론

DuckDB로는 CSV, JSON, Parquet 같은 지원 형식의 내용을 FROM 'flights.csv';만큼 간단하게 질의할 수 있다. 이 기능은 별도 설정 없이 제공되며, 앞 장들에서 언급한 모든 SQL 절과 함수를 지원한다. 그런 질의를 내리면 DuckDB는 먼저 그것이 현재 스키마의 테이블이나 뷰를 질의하는 것이 아니라는 사실을 알아낸다. 파일이 파일시스템에 존재하면 확장자로 파일 형식을 판정하고, 그 데이터 형식을 처리하는 법을 아는 적절한 함수를 호출해 파일을 읽는다.

그 함수들은 동작과 형식 양쪽에 대해 합리적인 기본값을 제공한다. 동작이라면 데이터 타입을 결정하기 전에 떠볼 표본의 개수 같은 것이고, 형식이라면 날짜와 시각 형식 같은 것이다. 그 기본값이 맞지 않으면 테이블 함수 read_csv_auto, read_json_auto, read_parquet_auto를 찾아보면 된다. 앞의 질의를 내릴 때 내부적으로 호출되는 바로 그 함수들이다. 세부를 하나씩 바꿀 인자를 잔뜩 제공하면서도 컬럼 이름과 객체 구조 같은 것은 여전히 자동으로 도출해준다. 그러니 FROM 'a_file.csv'나 FROM 'data*.json'이라고만 쓰는 대신, 필요한 인자를 붙여 FROM read_json_auto('data*.json')이라고 쓰게 된다.

스키마 자동 추론

DuckDB는 처리하라고 시킨 어떤 데이터 원천이든 그 스키마를 자동으로 추론한다. Parquet 같은 형식이라면 쉽다. 파일에 내장된 스키마가 있어 DuckDB가 그것을 쓸 수 있기 때문이다. CSV나 JSON 같은 다른 형식이라면 설정 가능한 개수의 표본 객체로부터 스키마를 추론한다. DuckDB는 CSV 파일의 방언까지 추론하고, 머리글 행이 있는지도 감지한다.

추론 결과가 온전히 마음에 들지 않으면 컬럼 전부, 또는 일부만의 타입을 덮어쓸 수 있다. 그럴 때는 밋밋한 파일 이름이 아니라 "자동이 아닌" 함수—read_csv 같은 것—를 쓴다.

여러 파일을 한 번에 읽을 때

DuckDB는 서로 다른 종류의 여러 파일—CSV, Parquet, JSON 등—을 동시에 읽을 수 있다. glob 문법을 쓰거나 읽을 파일의 목록을 주면 된다. 그런데 여러 파일에서 읽을 때 DuckDB는 그 파일들의 스키마를 결합해야 한다. 파일마다 자기 스키마를 가질 수 있고 그것이 다른 파일과 다를 수 있기 때문이다. 통합 방법은 둘이다.

• 컬럼 위치로 통합(기본값) — DuckDB는 주어진 첫 파일의 스키마를 읽고, 뒤따르는 파일들의 컬럼을 위치로 통합한다. 모든 파일이 같은 이름의 같은 스키마를 동일한 위치에 갖고 있는 한 올바르게 작동한다.
• 컬럼 이름으로 통합 — 그렇지 않다면 read_xxx 함수의 union_by_name 옵션을 쓴다. 위치가 아니라 모든 이름을 읽어 스키마를 구성하게 해준다.

CSV 파싱에 관한 노트 5.2.1

저자들의 첫 문장이 솔직하다. CSV 파싱은 놀랄 만큼 어렵다. 형식이 단순하고 첫눈에는 명료해 보이는데도 그렇다. DuckDB는 read_csv_auto를 쓰거나 read_csv에 auto_detect를 참으로 준 모든 경우에 표본 추출을 쓴다. 파일에서 일정 개수의 행—기본값 20,480행—을 읽어 다음을 감지한다.

• CSV 파일의 방언 — 구분자, 인용 규칙, 이스케이프 등
• 각 컬럼의 타입
• 파일에 머리글 행이 있는지

이 셋 가운데 저자들이 가장 중요하다고 보는 것은 타입 감지다. 이후 어느 단계에서든 좋은 데이터 품질을 보장하는 데 가장 큰 요인이라는 것이다. DuckDB는 다음 타입들을 내림차순 우선순위로 판정하려 시도한다.

read_csv_auto나 read_csv의 동작을 제어하고 싶거나 제어해야 할 가능성이 상당히 높다. DuckDB 문서는 가장 중요한 인자들을 별도 절에 열거해두었고, 이 매개변수들은 대응하는 내보내기 함수에도 적용된다. 저자들이 도움이 되었다고 꼽은 인자는 다음과 같다.

• names — 머리글 행이 없을 때 컬럼 이름을 설정한다.
• dateformat · timestampformat · decimal_separator — 날짜와 숫자 형식을 지정한다.
• filename — 여러 파일을 한 번에 다룰 때. 처리한 파일의 이름을 담은 인공 컬럼을 결과에 더해준다.

그리고 문서에 접근할 수 없는 처지에 놓였다면, DuckDB에게 자기 함수의 인자 목록을 내놓으라고 질의할 수 있다.

DuckDB에 내장된 JSON 확장에는 JSON 문자열을 만들고 읽고 조작하는 함수들이 있다. 그 일은 타입과 컬럼 이름을 자동으로 감지한 다음 JSON 안의 값들을 DuckDB의 벡터로 변환하는 방식으로 이루어진다.

소재는 프리미어리그 축구 경기에서 나온 슛을 표상하는 JSON 파일 한 벌이다. understatapi 라이브러리로 만든 것이며, 원천 데이터는 JSON lines 형식으로 한 줄에 한 경기다. 파일은 xg라는 하위 디렉터리에 있는데, xg는 understat 사이트에서 빌려온 용어 expected goals(기대 득점)를 뜻한다.

각 JSON 문서의 상위 구조는 CLI에서 질의 하나로 살펴볼 수 있다. 여기서 한 파일만이 아니라 여러 파일을 한꺼번에 질의할 수 있다는 사실이 시연된다. xg/shots_*.json은 xg 디렉터리에서 접두사 shots_와 접미사 .json을 가진 모든 파일을 찾아내는 와일드카드 표현이다.

그런데 예제 파일들의 스키마가 조금씩 달라서 위치로든 이름으로든 통합이 잘 되지 않는다. 그래서 그것을 직접 처리하고 기본값—위치로 통합—을 고수한다. JSON 객체를 별도 행으로 펼쳐낸 다음, 그 과정에서 드러나는 적합성 문제를 손으로 고칠 것이다. 필드가 많아 기본 duckbox 표현 모드로는 잘려 나가므로 line 모드를 쓴다.

해체는 네 걸음으로 나뉘고, 걸음마다 데이터의 모양이 바뀐다. 아래에서 걸음을 하나씩 눌러 그 모양의 변화를 좇을 수 있다. 표본 행은 원서에 실린 그것—2015년 12월 6일 뉴캐슬–리버풀 경기의 43분 헤더—을 그대로 옮겼다.

2단계에서 눈여겨볼 대목이 있다. 각 행의 원천은 JSON 객체지만 DuckDB가 돌려주는 것은 DuckDB의 구조체(struct)다. JSON과 얼마간 닮았지만 JSON으로 파싱되지는 않는다. 둘을 같은 것으로 여기고 JSON 함수를 들이대면 낭패를 본다.

그리고 뷰를 만드는 이유를 저자들이 정직하게 밝힌다. 뷰는 물리적으로 실체화되지 않고 매번 밑에 깔린 질의를 실행한다. 그러니 뷰를 정의해서 얻는 이득은 성능이 아니라 매번 파일의 전체 위치를 적어내지 않아도 되는 줄임말이다. 이 장에서 뷰의 값어치가 그것 하나로 충분하다는 것이 요점이다.

추론이 어긋났을 때 — CAST와 try_cast

DuckDB의 추론은 완벽하지 않았다. X, Y, xG는 원본 JSON에서 좌표이고 모두 수치 타입—예컨대 DOUBLE—이어야 한다. 그렇지 않으면 그 필드에 수치 연산을 할 수 없다. 고치는 방법은 추론된 STRUCT 타입을 가져와 문제되는 필드의 타입 정의를 바꾸고, 각 행을 그 새 STRUCT로 캐스팅하는 것이다. 목록 5.1이 그것이다.

여기에 저자들이 붙인 조건절이 실무의 무게를 담고 있다. 이 경우처럼 운이 좋으면 타입 전체를 그냥 캐스팅해도 된다. DuckDB의 표본 추출이 틀렸던 것이니까. 그러나 DuckDB의 표본 추출이 옳았고 정말로 문자열 아닌 타입으로 자동 캐스팅될 수 없는 필드가 있다면, 그 뷰에 대한 질의는 골칫거리가 된다. 수치 타입에는 놀랄 일이 숨어 있을 수 있고, 저자들의 경험으로는 타임스탬프의 표현이 다루기 가장 어려운 경우가 잦다. 날짜와 타임스탬프 양쪽에 대해 충분한 ISO 표준이 있는데도 그렇다는 대목에서 쓴웃음이 난다.

더 조심할 점이 있다. DuckDB는 JSON 구조의 속성 이름은 검증하지만, 뷰가 정의되는 순간에 각 값을 캐스팅해보지는 않는다. 그러므로 기대한 형식에 맞지 않는 데이터가 입력에 잠복해 있을 수 있다. 게다가 파이프라인에 새 파일을 더하면 새로운 부적합 데이터가 나타날 수 있다. 그때 SELECT row.x FROM shots를 질의하면 Error: Conversion Error: Could not convert string 'abc' to DOUBLE 같은 오류로 끝난다. 이것이 정확히 원하는 바일 때도 있고, 아닐 때도 있다.

대처하는 길은 둘이다.

• 필드 수준으로 내려가 하나씩 고친다 — 5.4절에서 그렇게 한다. 이 길을 택한다면 캐스팅 전에 DuckDB가 제공하는 날짜 형식화 함수 가운데 아무거나 하나를 반드시 쓴다. 다만 이런 탐색적 쓰임에서 필드 수준까지 내려가는 것은 노력이 많이 드는 일이고, 그만한 값어치가 없을 수 있다.
• cast를 try_cast로 바꾼다 — 저자들의 권고다. DOUBLE로 캐스팅될 수 없는 데이터를 가진 필드는 이제 리터럴 NULL 값으로 돌아온다. 오류로 멈추는 대신 빈칸으로 남기는 쪽을 고르는 것이다.

구조체를 컬럼으로 펼치기

이 지점에서 뷰에 곧바로 질의를 쓸 수도 있지만, DuckDB가 지원하는 깔끔한 기능이 하나 더 있다. 구조체를 컬럼으로 펼치는 것이다. 중첩된 필드를 가진 컬럼 하나가 아니라, 필드마다 자기 컬럼이 되는 것이다. 그러면 처음부터 그 컬럼을 쉽게 지목할 수 있고 어떤 함수나 집계든 적용할 수 있다.

원본 JSON 파일의 리스트를 펼치던—평탄화하던—방식과 비교해볼 만하다. [1, 2, 3] 같은 구조를 1, 2, 3 세 행으로 바꾸는 일이었다. 구조체와 맵 모양 타입에도 같은 것이 지원되며, 그것을 펼치면 속성 또는 키마다 컬럼 하나가 나온다.

중첩 JSON 탐색은 질의 하나로 맺는다. 2022 시즌 기대 득점이 가장 높은 팀들을 찾는 질의다. 이 지표와 관련된 데이터를 제공하는 것이 곧 understat의 사명이기 때문이다.

데이터 엔지니어링의 흔한 과제가 한 데이터 형식을 다른 형식으로 변환하는 일이다. 이 분야의 초기 도구들은 목표 형식으로 변환하기 전에 원천 데이터셋 전체를 메모리에 적재해야 한다고 가정했다. DuckDB는 메모리 한도를 설정해 원천 데이터 행을 제한된 개수만 메모리에 적재하게 해준다. 큰 데이터셋을 다룰 때나 자원이 제한된 기계를 쓸 때 요긴하다.

왜 Parquet인가

Parquet은 Apache Spark 같은 빅데이터 처리 프레임워크를 위해 설계된, 널리 쓰이는 컬럼 저장 파일 형식이다. 효율적인 압축과 인코딩 기법으로, 메타데이터 없는 텍스트 기반 형식—CSV나 JSON—에 비해 저장 요구량을 줄이고 질의 성능을 높이는 이득을 준다.

여기에 하나가 더 붙는다. 이 파일 형식은 조건 푸시다운과 사영 푸시다운을 쓴다. 선택적 질의의 실행을 가능하게 하고 데이터 전송을 최소화하는데, 분산 환경에서 특히 이롭다. 이 기제로 저장 계층에게 질의와 일치 조건에 관련된 선택된 컬럼이나 특정 구간만 가져오라고 말할 수 있고, 나머지 저장 데이터는 완전히 손대지 않은 채로 남겨둘 수 있다.

여덟 개의 CSV, 310만 행

저장소의 ch05 디렉터리로 이동하면 atp_ 접두사 파일들을 담은 atp 디렉터리가 보인다. 1970년대까지 거슬러 올라가는 프로 테니스 선수들의 랭킹 데이터다. 그리고 선수 메타데이터를 담은 atp_players.csv 파일 하나가 따로 있다.

행 그룹 크기라는 저울

행 수를 미리 알아두는 것이 왜 중요한가. 컬럼 형식으로서 Parquet 파일은 행들을 묶어 그룹으로 만들기 때문이다. 한 그룹의 행 수를 알맞게 정하는 일이 중요하고, 양쪽으로 다 위험이 있다.

CSV 파일과 달리 Parquet 파일은 전용 데이터 타입을 가진 자기 서술적 스키마를 담고 있다. CSV라면 기본적으로 모든 것이 통상 문자열이고 각 컬럼을 표본으로 떠서 실제로 어떤 데이터가 들었는지 판정해야 하는데, Parquet 파일은 이 정보를 이미 담고 있다.

다만 Parquet이 원래 저장하는 데이터 타입은 몇 개뿐이며, 이를 물리 데이터 타입이라 부른다. 그럼에도 주석을 덧붙임으로써 더 많은 타입을 표상할 수 있고, 그것을 논리 타입이라 부른다. 예컨대 Parquet 파일은 날짜를 수치로 저장하지만, 추가 메타데이터가 읽는 쪽에게 그 수치를 날짜로 해석하라고 알려준다.

8자리 숫자를 날짜로 되돌리기

값어치 있는 Parquet 파일을 만들려면 먼저 CSV 파일을 살펴, 다루는 각 컬럼이 가장 구체적이고 정밀한 데이터 타입을 담고 있는지 확인해야 한다. 이 타입들이 목표 파일의 스키마에 쓰이기 때문이다.

지금은 각 행이 어느 선수를 가리키는지 모른다. atp_players.csv 파일을 조인해 알아낼 수 있다. 선수 CSV 파일의 dob—생년월일—필드도 %Y%m%d 형식의 문자열이라는 문제를 함께 고친다.

이제 결과를 Parquet 파일로 내보낸다. 이 명령은 스크립트로 짜인 데이터 파이프라인의 일부로 돌리게 될 것이므로, 먼저 .exit로 CLI를 나간다. 내보내는 데이터 양은 메모리에 넉넉히 들어가지만 memory_limit 설정으로 DuckDB가 쓰는 메모리를 제한할 수 있다. 메모리가 제한된 파이프라인이나 서버리스 환경에서 이 능력은 값지다. 기본적으로 DuckDB는 사용 가능한 전체 램의 80%를 쓴다.

Parquet 파일은 데이터 처리 파이프라인에서 널리 쓰일 뿐 아니라 DuckDB 안에서 질의할 훌륭한 데이터 원천이기도 하다. 메타데이터에 스키마를 제공하므로 CSV나 JSON 파일보다 데이터베이스에 훨씬 가깝다.

그래서 저자들은 상황을 하나 상정한다. 이 atp_rankings.parquet 파일을 내가 만든 것이 아니라 남에게서 받았을 수도 있다. 구조도 내용도 모르는데 그것으로 보고서를 만들라는 과제를 받았다. 이 절은 그 처지에서 시작한다.

이 스키마만으로도 데이터를 질의하고 분석하기에는 충분하다. 그러니 여기서 멈추고 파일을 테이블처럼 취급해 제3·4장의 SQL 지식을 적용해도 된다. 그러나 정말로 자신이 DuckDB로 그 파일을 만들었다면 더 깊이 들어가고 싶어질 것이다.

Parquet에는 물리 타입이 몇 개뿐임을 기억해두자. 불리언, 여러 크기의 숫자, 바이트 배열이며, 그 타입들로부터 더 "고수준"의 무엇으로 변환해야 한다. 거대한 데이터셋을 다룰 때는 숫자가 특별한 관심사가 될 수 있다. Parquet에는 정수를 위해 int32, int64, int96이 있다. 더 작은 수치 타입에서 더 많은 벡터 기반 연산을 병렬로 실행할 수 있으므로, 최적 성능이 목표라면 데이터를 담을 수 있는 가장 작은 데이터 타입을 쓰려 해야 한다.

이 메타데이터에서 눈에 걸리는 것이 있다. rank, points, player_id, height가 모두 64비트 정수로 표상되어 있다. 부호 있는 64비트 정수의 최댓값은 9,223,372,036,854,775,807이다. 포인트나 키 필드의 값이 그만한 공간을 필요로 한다면 놀라운 일이겠다. 그러니 실제 최댓값을 질의로 확인해본다.

Parquet 파일 자체의 구조도 parquet_metadata 함수로 탐색할 수 있다. 이 함수는 행 그룹마다, 컬럼마다 레코드 하나를 돌려준다. 컬럼을 많이 돌려주므로 표 형태로 인쇄되지 않도록 다시 line 모드를 쓴다.

DuckDB의 또 하나 흥미로운 기능은 다른 데이터베이스에 붙여 그 내용을 질의할 수 있다는 것이다. 그중 하나가 임베디드 OLTP 데이터베이스 SQLite다. 까다로운 분석 질의를 쓰면서 DuckDB 질의 엔진의 이점을 누리고 싶다면, 기존 SQLite 파일을 DuckDB에서 질의하고 싶어질 만하다.

다만 저자들이 미리 경고를 둔다. SQL 표준이 데이터 타입과 동작을 부분적으로 정의하기는 하지만, 벤더마다의 구현 사이에는 이름과 의미론에서 많은 차이가 있을 수 있다. 외래 데이터베이스를 DuckDB에 붙이는 일은 때로 그 어긋남을 우회해야 한다는 뜻이다. 자동 추론이 통하는 일이 잦지만, 통하지 않을 때도 있다. 그런 이치로, 외래 저장소를 질의할 때도 앞 절의 CSV에서 했던 것과 같은 변환 작업을 해야 할 수 있다. 그리고 이 절은 정확히 그 "통하지 않을 때"의 기록이다.

소재는 Kaggle의 유럽 축구 데이터베이스다. 25,000경기가 넘는 유럽 프로 축구 경기와 선수, 팀 속성 데이터를 담고 있으며, 300MB SQLite 데이터베이스로 제공된다. 예제 저장소에는 압축된 형태로 들어 있으니 먼저 풀어야 한다.

약한 타입과 강한 타입이 만나는 자리

진단은 이렇다. SQLite는 약한 타입(weakly typed) 데이터베이스 시스템이다. 데이터를 저장할 때 타입이 강제되지 않는다는 뜻이다. 반면 DuckDB는 강한 타입 시스템이며 모든 컬럼이 정의된 타입을 갖기를 요구한다. DuckDB는 SQLite의 타입 체계에 충실하려 하는데, 이 경우에는 그것이 잘 통하지 않았다. height 컬럼이 SQLite에서 INT로 정의되어 있는데도 일부 float 값을 담고 있기 때문이다.

DESCRIBE Player;로 각 필드의 타입을 확인하면 height가 BIGINT로 나오는데, 앞의 질의에서 그것이 float 값을 담고 있음을 이미 보았다. 저자들은 weight 필드에도 문제가 있을 수 있다고 짚으면서 한마디 붙인다. "아마 그 필드에 소수값이 없어서 운이 좋았을 뿐일지도 모른다." 약한 타입의 데이터는 이렇게 운에 의존하는 코드를 만든다.

이제 sqlite_all_varchar를 false로 되돌리고 나머지 뷰들을 손으로 만든다. Player_Attributes, Country, League, Match, Team, Team_Attributes 여섯 개를 각각 sqlite_scan으로 감싼다. 그리고 두 SQLite 테이블을 조인해 가장 최근 평가에 기반한 최고 선수들을 찾는 질의를 쓴다.

DuckDB는 Microsoft Office Open XML(OOXML, 확장자 .xlsx)로 저장된 Excel 파일을 읽고 쓸 수 있다. 이 형식은 2007년부터 마이크로소프트 오피스가 써왔고 LibreOffice와 구글 시트를 포함한 다른 응용들도 지원한다. 그런데 조건이 하나 붙는다. DuckDB에 spatial 확장이 설치되어 있어야 한다. 이 확장은 주로 공간 데이터를 다루는 데 쓰이지만, 그 밑에 깔린 기계 장치가 OOXML도 지원하기 때문이다. 지리 정보 확장으로 엑셀을 읽는다는 것이 조금 우습지만, 형식을 다루는 코드가 어디서 재활용되는지를 보여주는 사례로는 흥미롭다.

쓰기 지원은 제한적이다. 날짜와 타임스탬프 같은 일부 데이터 타입은 지원되지 않아 문자열로 캐스팅하거나 문자열로 형식화해야 한다. 5.4절에서 만든 Parquet과 같은 데이터를 Excel로 내보내면 어떤 일이 벌어지는지가 이 절의 마지막 교훈이다.