질의 하나가 내 기계와 클라우드에 걸쳐 실행된다

MotherDuck은 협업형 서버리스 분석 플랫폼이다. 브라우저나 DuckDB의 어떤 API로든 클라우드 데이터베이스와 클라우드 저장소의 데이터를 질의하고 분석하게 해준다. 여기서 서버리스가 뜻하는 바를 저자들이 분명히 정의한다. 사용자가 서버나 클러스터를 띄우거나 데이터베이스 인스턴스를 설정하는 일을 다룰 필요가 없다는 뜻이다. 대신 데이터베이스만 만들면 나머지는 서비스가 알아서 한다.

어떻게 작동하는가 7.1.1

쓰는 길이 여럿이다. 서비스에 가입하면 브라우저에서 돌아가는 MotherDuck 웹 UI에 이르게 된다. 이 UI는 MotherDuck과 통신하는 법을 아는 특별한 DuckDB 판본을 브라우저에서 돌리고 있다. UI는 데이터베이스를 관리하는 도구이면서, 질의를 입력하고 실행하고 결과를 보는 노트북 기반 접근이기도 하다.

다른 입구는 물론 CLI와 파이썬 같은 언어 통합이다. 여기서 md: 확장의 두 갈래 역할이 갈린다.

• 파서 — 데이터베이스와 공유 관리를 둘러싼 기능으로 확장된다.
• 질의 엔진 — 확장이 테이블이 로컬에 있는지 원격에 있는지 분석하고 알맞은 실행 엔진을 써서 데이터를 그에 맞게 조인한다. 필요하면 로컬 데이터의 일부를 조인이나 필터를 위해 서버로 보내거나, 원격 쪽 데이터를 가져와 로컬에서 조인한다.

아키텍처의 핵심 구성 요소는 넷이다.

그리고 이 절에서 뒤의 비용 논의로 이어지는 복선이 하나 놓인다. MotherDuck은—다른 현대적 클라우드 데이터 플랫폼과 마찬가지로—저장과 연산 설비를 분리한다. 이것이 결국 MotherDuck을 쓸 때 발생하는 비용에 중요해진다. 7.3.5절에서 그 분리가 요금표로 어떻게 나타나는지 보게 된다.

왜 MotherDuck을 쓰는가 7.1.2

첫째이자 무엇보다, DuckDB에 기반한 단순하고 성능 좋고 효율적인 데이터 웨어하우스를 제공한다. 저자들의 진단이 이 책 전체의 문제의식과 이어진다. 대부분의 사람은 클라우드 데이터 웨어하우스 사용자의 긴 꼬리에 속하고, 수십 수백 테라바이트의 뜨거운 데이터를 위한 분석 처리 능력을 필요로 하지 않는다. 그런 쓰임새는 분산 시스템에 기반하지 않고 클라우드를 주된 데이터 저장소로, DuckDB를 질의 엔진으로 쓰는 더 단순하고 효율적인 아키텍처에서 이득을 볼 수 있다.

나머지 세 쓰임새도 정리해둘 만하다.

• 다종 원천으로 이루어진 데이터 레이크의 질의 엔진 — Parquet으로 저장된 차가운 데이터, S3의 CSV 파일, 또는 Apache Iceberg에 저장된 데이터 같은 것이다. 그 데이터를 MotherDuck에 직접 저장된 뜨거운 데이터와 손쉽게 조인할 수 있다.
• 데이터 애플리케이션·대시보드·API의 서버리스 백엔드 — 주 트랜잭션 데이터베이스에서 분석 질의를 돌리는 대신, 전용 분석 데이터베이스에서 그 질의를 돌린다.
• 읽기 전용 스냅숏의 공유 — 다른 MotherDuck 사용자에게 데이터베이스의 스냅숏을 공유할 수 있다. 그들은 공유된 대로 원천을 쓸 수도 있고, 자기 인스턴스의 데이터를 그 데이터셋과 조인할 수도 있다.

책 전체에서 CLI나 파이썬 통합을 썼는데, MotherDuck을 시작하려면 먼저 브라우저를 띄워야 한다. 가입 버튼을 눌러 GitHub 계정이나 구글 계정으로, 또는 이메일 주소를 주고 무료 계정을 만들 수 있다.

UI로 MotherDuck 쓰기 7.2.1

웹 기반 UI는 세 가지를 한자리에 모아준다. 모든 원격 데이터베이스에 접근하고 질의하기, 계정 설정 관리하기, 그리고 S3의 원격 데이터 원천을 질의하는 데 필요한 비밀을 저장하기다. UI 밖에서 MotherDuck에 접근하는 데 필요한 API 토큰도 여기서 얻는다.

이 구조에서 따라오는 이득이 있다. SQL 질의의 결과가 브라우저에 로컬한 DuckDB 인스턴스에 캐시되어, 질의 결과를 즉시 정렬하고 피벗하고 필터링할 수 있다. 서버를 다시 부르지 않고 손에서 결과를 만지작거릴 수 있다는 뜻이다.

질의를 실행하는 경험은 주피터 노트북과 비슷하게 마련되어 있다. 자동 완성과 함께 SQL 문을 쓰고, 실행하고, 셀 아래의 데이터 격자에 렌더링된 질의 결과를 본다. 출력 격자는 로컬 정렬, 출력 컬럼 선택, 컬럼 머리글에 히스토그램과 집계 표시, 데이터의 피벗과 필터링을 지원한다. 그리고 질의를 담은 UI의 상태가 세션을 넘어 유지되므로, 브라우저를 닫고 나중에 이어서 할 수 있다.

CSV와 Parquet 파일을 UI에서 직접 업로드하는 것도 지원된다. 업로드한 파일은 어떤 질의에서든 접근할 수 있게 되고, CREATE TABLE AS SELECT 문을 활용하거나 필요에 맞게 변환하게 된다.

토큰 기반 인증으로 DuckDB를 MotherDuck에 연결하기 7.2.2

DuckDB는 공유 데이터베이스 인스턴스를 열려고 하는 순간에 MotherDuck과의 인증 과정을 촉발한다. 이름 붙은 데이터베이스일 수도 있고 기본 데이터베이스일 수도 있다.

7.3절의 도입에서 저자들은 이 절의 목표를 정리해둔다. 데이터를 클라우드에 넣고, 동료와 협력자에게 데이터베이스를 공유하도록 도와주는 모든 기능이다. 그리고 첫 예제의 동기가 현실적이다. 제6장에서 파이썬 통합으로 나라 데이터를 담은 데이터베이스를 만들고 데이터셋의 문제를 정리했다. 이제 그 작업을 동료와 공유하고 싶다.

한 방법은 저자들이 "스프레드시트식 삶의 방식"이라 부르는 것이다. countries.duckdb 저장 파일을 이메일에 첨부하거나 네트워크 폴더에 복사하고 넘어가는 것. 더 낫고 덜 부서지기 쉬운 공유 방법이 MotherDuck이다.

앞 절에서는 기존 데이터베이스를 올렸다. 대안으로 클라우드에서 직접 스키마를 처음부터 지을 수 있다. 그리고 그 편이 나은 경우를 저자들이 분명히 짚는다. 스키마의 내용이 대체로 다른 공용 클라우드에 저장된 파일에 의존한다면, 그것을 먼저 로컬 DuckDB 인스턴스로 내려받고 그 데이터베이스를 다시 MotherDuck에 올리는 것은 시간과 자원의 낭비다. 대부분의 경우 MotherDuck이 내 로컬 시스템보다 S3 버킷에 더 가까이서 돌아가므로, 클라우드에서 MotherDuck으로 직접 들이는 편이 시간과 돈을 아껴줄 수 있다.

MotherDuck은 데이터베이스의 읽기 전용 스냅숏을 공유하는 능력을 제공한다. 데이터를 공유하는 데만 좋은 것이 아니라 협업 분석과 기능의 공유에도 좋다. 그 까닭이 이 절의 핵심이다. 스냅숏은 데이터만이 아니라 모든 뷰를 담으며, 그와 함께 그 뷰를 만드는 동안 들인 모든 노력을 담는다. 저자들의 표현으로는 "스테로이드를 맞은 스프레드시트"다.

제3·5장에서 뷰가 논리를 감싸두는 수단이라고 배웠다. 그 뷰가 그대로 건너간다는 것은, 정제 규칙과 단위 환산과 조인 논리까지 함께 건너간다는 뜻이다. 파일 하나를 이메일로 보내는 것과는 다른 종류의 공유다.

저자들이 준비해둔 공유들

저자들은 독자를 위해 흥미로운 공유 몇 개를 준비해두었다. 제3·4장의 완전한 데이터베이스—그 장들에서 만든 모든 테이블과 뷰를 담은—와 스택 오버플로의 완전한 덤프, 그리고 표본 데이터 모음이다.

저자들의 맺음말이 이 공유들의 목적을 말한다. 이 데이터셋들은 여러 다른 주제를 제공하니, SQL 실력을 단련하거나 DuckDB와 MotherDuck의 가능성을 탐색하는 데 쓸 수 있다.

앞 장들에서는 http://나 https:// 프로토콜로 직접 접근할 수 있는 파일에서 데이터를 들였다. 그러나 파일 저장에 아마존 S3를 쓰는 일이 잦고, 그것은 s3:// 프로토콜로 접근한다. MotherDuck과 DuckDB는 그 프로토콜도 말하지만, 여러분을 대신해 아마존 S3에 인증하려면 비밀이 필요하다.

여기에 MotherDuck을 쓸 때의 이점이 하나 붙는다. 비밀을 그들의 시스템에 저장해두면 MotherDuck에 접속된 모든 세션에서 쓸 수 있다. 웹 UI로 하거나 전용 문장으로 한다.

클라우드 기반 해법을 돌리는 데는 여러 종류의 비용이 든다. 연산, 저장, 데이터 인그레스, 데이터 이그레스가 그중에 있다. 그리고 이 절의 핵심 능력이 여기서 나온다. MotherDuck 확장은 함수가 클라우드에서 실행될지 내 로컬 기계에서 실행될지에 대한 촘촘한 제어를 준다.

저자들이 든 반례가 명료하다. 이미 로컬에 있는 큰 Parquet 파일을 처리하고 싶다면, 그것을 S3에 먼저 올린 다음 MotherDuck에서 처리를 돌리는 것은 무의미하다. MotherDuck의 연산 비용과 S3의 이그레스 비용을 둘 다 물게 되기 때문이다. 인터넷이 빠르다면 로컬에서 처리하고 내 기계에서 MotherDuck으로 그냥 올리는 편이 아마 낫다.

확장은 read_ 접두사로 시작하는 모든 함수—read_json, read_csv_auto 같은 것—를 확장해 MD_RUN 매개변수를 지원하게 만든다. 아래에서 원천과 MD_RUN 값을 갈아 끼워, 함수가 어디서 실행되고 그것이 무엇을 뜻하는지 확인할 수 있다.

차가운 저장과 뜨거운 저장

무료 등급을 넘어서면 MotherDuck은 표준 등급을 제공한다. 저자들이 적어둔 집필 시점의 값은 다음과 같다.

두 저장의 뜻이 다르다. 차가운 저장(cold storage)은 데이터베이스와 파일을 위한 영속 저장을 가리킨다. 뜨거운 저장(hot storage)은 질의를 실행하는 데 쓰이며 메모리 사용에 해당하고, 필요에 맞게 미세 조정한 최대치로 제한할 수 있다. DuckDB에서 뜨거운 저장은 상한까지 자동으로 확장되고 초와 기가바이트 단위로 계량된다.

SQL이 영어와 어느 정도 닮았다고는 하나 익히기가 늘 쉽지는 않고, 처음 접하는 사람에게는 어떤 구성물은 노골적으로 겁을 준다.

그런데 구조화된 언어로 된 질의는 곧잘 생성될 수 있다. MotherDuck은 자연어로 데이터를 질의하게 해주는 생성 AI 기능을 제공한다. 데이터를 서술할 수 있고, SQL 문을 생성해주거나 기존 문장을 고쳐준다. 작동 원리를 저자들이 분명히 밝혀둔다. 데이터베이스 스키마를 상세한 프롬프트와 여러분의 질문과 함께 대규모 언어 모델(LLM)로 보내면, 그것이 요청된 SQL 문을 생성하고 선택적으로 실행한다.

저자들의 총평은 균형이 잡혀 있다. 데이터베이스에 대한 질의를 생성하는 데 LLM을 쓰는 것에는 잠재력이 많고, 특히 모델이 데이터베이스 스키마로 증강될 수 있을 때 그렇다. 다만 보고서와 애플리케이션을 위해 전문가가 쓰고 조율한 질의를 대체하지는 못할 가능성이 크다. 그럼에도 데이터베이스 시스템을 훨씬 넓은 청중에게 접근할 수 있게 만들어줄 것이다. 무엇을 대체하고 무엇을 넓히는지를 나누어 적는 이 절제가 미덥다.

덧붙여, 2024년 초에 MotherDuck은 FixIt을 도입했다. 같은 기술에 기반한 UI용 빠른 SQL 오류 수정기이며, 구문이 잘못된 SQL 문이나 UI에 직접 인라인으로 있는 문장을 고쳐준다.

MotherDuck은 다양한 데이터 전송, 비즈니스 인텔리전스, 데이터 시각화 도구를 지원한다. 저자들이 그린 그림의 구도는 이렇다. 왼쪽에서 오른쪽으로 가면서 중간에 선택적인 변환을 두면, MotherDuck이 파이프라인의 가운데에 앉을 수 있다.

원천은 직접 수집되거나 추가 서비스를 거쳐 수집되어 MotherDuck의 저장소에 놓이고, 그다음 비즈니스 인텔리전스 쓰임새나 특정 데이터 과학 도구가 그것을 질의한다. 그리고 한 가지가 더 붙는다. LLM 모델을 위한 검색 증강 생성(RAG)의 정보 검색 구성 요소로도 쓸 수 있다.

그리고 그것에 필요한 것이 무엇인지를 저자들이 한 문장으로 적어둔다. 데이터베이스 접속 문자열에 md: 접두사를 끼워 넣고 ?motherduck_token=<token> 매개변수를 덧붙이는 것뿐이다. 제6장에서 duckdb.connect(':memory:')였던 자리가 duckdb.connect('md:?motherduck_token=…')으로 바뀌는 것 하나로 로컬이 클라우드가 된다. API를 바꾸지 않고 URL만 바꾸는 이 설계가 이 장 전체를 관통하는 요령이다.