돌을 옮기지 않고
탁본을 뜬다

앞선 모든 장에서 DuckDB로 다룬 것은 지역 데이터였다. MySQL 데이터베이스에 있든 CSV·JSON·Parquet 파일에 있든 모두 내 컴퓨터의 것이었다. 그러나 실제 상황에서 다루는 데이터는 통상 원격 서버에 놓이며, 여러 곳에서 오는 일이 잦다. 다행히 DuckDB는 원격 데이터셋에 접근하게 해 주는 httpfs 확장을 제공한다. 게다가 DuckDB는 Hugging Face가 호스팅하는 데이터셋에 접근하는 지원까지 제공한다.

httpfs 확장은 자동 적재 가능한(autoloadable) 확장이며, 원격 파일의 읽기와 쓰기를 허용하는 파일 시스템을 구현한다. 이 확장으로 DuckDB는 HTTP와 HTTPS 프로토콜을 통해 파일을 직접 읽고 쓸 수 있으며, 먼저 지역에 내려받을 필요가 없다. 다음 상황에서 특히 도움이 된다.

• 용량을 넘길 때 지역 저장 공간을 넘어서는 큰 데이터셋을 다룰 때.
• 실시간일 때 실시간이거나 자주 갱신되는 데이터에 접근할 때.
• 여러 곳일 때 여러 원격 원천에 분산된 데이터에 질의할 때.
• 클라우드일 때 클라우드 저장과 매끄럽게 통합할 때.

이는 효율적인 원격 데이터 분석을 가능하게 하며, 클라우드 기반 데이터 레이크, 웹 API, 분산 파일 시스템이 얽힌 상황에 이상적이다. httpfs 확장은 CSV, Parquet을 비롯해 DuckDB가 자체적으로 지원하는 여러 파일 형식을 지원한다.

import duckdb

conn = duckdb.connect()
conn.execute('''
    INSTALL httpfs;
    LOAD httpfs;
''')

제2장에서 엑셀을 읽기 위해 spatial을, MySQL에 붙기 위해 mysql을 설치했던 그 자리에 이번에는 httpfs가 놓인다. DuckDB의 확장 목록을 처음 소개한 대목에서 httpfs가 맨 앞에 있었던 것을 떠올려도 좋다. 여섯 장을 지나 그 첫 항목의 차례가 온 셈이다.

httpfs 확장이 있으면 원격에 놓인 파일에 접근할 수 있다. 웹 서버에 파일이 있다면 읽거나 쓰려는 파일을 곧바로 가리키는 URL을 그냥 쓰면 되고, DuckDB가 먼저 지역에 내려받지 않고 처리한다. 그런데 GitHub 같은 사이트에 저장된 파일이라면 원시 파일(raw file)을 담은 URL을 얻어야 한다.

표본 CSV 파일의 URL을 웹 브라우저에 띄우고 Raw 버튼을 누른다. 원시 CSV 파일을 적재하는 페이지로 옮겨지며, 그 페이지의 URL을 복사한다. 이 예에서는 Amazon.com의 과거 주가를 담은 파일이다.

https://raw.githubusercontent.com/weimenglee/DuckDB_Book/main/AMZN.csv

# 파일 전체를 질의해 pandas DataFrame으로 바꾼다
conn.execute('''
  SELECT
    *
  FROM
    'https://raw.githubusercontent.com/weimenglee/DuckDB_Book/main/AMZN.csv'
''').df()

# 원격 데이터에 여과도 걸 수 있다 — 2018년의 모든 행
conn.execute('''
  SELECT
    *
  FROM
    'https://raw.githubusercontent.com/weimenglee/DuckDB_Book/main/AMZN.csv'
  WHERE year(Date) = 2018;
''').df()

여러 CSV 파일을 한꺼번에 읽으려면 read_csv() 함수에 목록을 넘긴다.

conn.execute('''
  SELECT
    *
  FROM read_csv([
    'https://raw.githubusercontent.com/weimenglee…
    'https://raw.githubusercontent.com/weimenglee…
  ]);
''').df()

그리고 이 절의 결론이 뜻밖이다. CSV 파일은 대부분의 경우 지역 기계로 전부 내려온다. CSV가 데이터를 행 기반 형식으로 저장하기 때문이다. 큰 파일을 다룰 때 특히 시간이 걸린다. 원격 데이터를 훨씬 효율적으로 가져오는 길은 Parquet 형식을 쓰는 것이다.

제1장의 첫 그림이 여기서 다시 필요해진다. 행 기반 저장에서는 한 행을 읽으려면 그 행의 모든 열이 함께 온다. 이제 그 파일이 통신선 저쪽에 있다면, 같은 사정이 대역폭의 문제로 바뀐다. 기둥으로 세워 두지 않은 데이터는 원격에서도 쪼갤 수 없다.

Parquet 파일에 대해서 DuckDB는 Parquet 메타데이터와 HTTP 범위 요청(range request)을 조합해, 질의가 실제로 요구하는 파일의 부분만 부분적으로 내려받는다. 이 한 문장이 이 장에서 가장 값진 문장이다.

CSV 파일에서 변환한 Parquet 파일이 GitHub에 놓여 있는 경우를 본다. 원서는 같은 파일을 놓고 질의문만 바꾸어 가며, 내려받는 양이 어떻게 줄어드는지를 네 걸음으로 보인다.

# ① 파일 전체를 내려받아 DataFrame으로 바꾼다
conn.execute('''
  SELECT
    *
  FROM
  'https://github.com/weimenglee/DuckDB_Book/raw/…
''').df()

# ② 내려받지 않고 원격 파일의 스키마만 얻는다
conn.execute('''
    DESCRIBE TABLE
'https://github.com/weimenglee/DuckDB_Book/raw/ma…
''').df()

순서가 중요하다. 대개는 파일의 모든 열이 필요하지 않다. 더 나은 접근은 먼저 내려받지 않고 원격 파일의 스키마를 얻고 그다음 어떤 열을 내려받을지 정하는 것이다. 답사자가 비석 앞에서 먼저 전체 도면을 그리고, 어느 면을 떠 올지 정하는 순서와 같다.

# ③ Agency와 Agency Type 두 열만 내려받는다
conn.execute('''
  SELECT
    Agency, "Agency Type"
  FROM
    'https://github.com/weimenglee/DuckDB_Book/ra…
''').df()

# ④ age 열만 내려받아 평균을 계산한다
conn.execute('''
   SELECT
     avg(age)
   FROM
    'https://github.com/weimenglee/DuckDB_Book/ra…
''').df()

# ⑤ 데이터를 전혀 내려받지 않는다 — 메타데이터에서 읽는다
conn.execute('''
  SELECT
    count(*)
  FROM
    'https://github.com/weimenglee/DuckDB_Book/ra…
''').df()

다섯째 줄이 이 장의 정점이다. count(*)에는 데이터가 필요하지 않다. 행 수는 이미 파일 머리의 메타데이터에 적혀 있다. 비문의 글자 수를 알아내려고 굳이 종이와 먹을 챙겨 가지 않아도 되는 것과 같다. 그 수는 비석을 세울 때 이미 기록되었다.

이 절이 제1장·제2장·제4장의 이야기를 한자리에 모은다는 점도 짚어 둘 만하다. 열 기반 저장이라는 한 가지 결정이 제1장에서는 디스크 읽기를 줄였고, 제4장에서는 메모리 적재를 줄였고, 여기서는 네트워크 통신을 줄인다. 같은 구조가 세 층위에서 같은 방식으로 값을 한다.

httpfs 확장으로 HTTP(S) 프로토콜을 통해 원격 데이터셋에 질의하는 것 말고도, DuckDB는 Hugging Face가 호스팅하는 데이터셋에 대한 질의를 지원한다.

Hugging Face Datasets는 기계학습과 자연어 처리(NLP) 과제를 위한 대규모 데이터셋의 접근을 간단하게 만드는 라이브러리다. 모형의 훈련과 평가, 성능 견주기에 곧바로 쓸 수 있는 방대한 데이터셋 모음을 제공해, 손으로 데이터를 모으고 전처리할 필요를 없앤다. 아울러 데이터셋의 효율적인 적재·변환·분할을 위한 내장 함수로 사용자 정의 데이터 처리도 지원한다.

또한 Hugging Face Datasets는 분산되고 효율적인 데이터 적재에 최적화되어 있어 대규모 프로젝트에 이상적이다. Hugging Face Transformers 라이브러리와의 매끄러운 통합이 작업 흐름을 더욱 간결하게 만들며, NLP와 기계학습 과제에 종사하는 연구자와 개발자에게 값진 도구가 된다.

DuckDB에서 Hugging Face 데이터셋을 쓰려면 먼저 그것이 어떻게 구성되어 있는지 이해해야 한다. 원서는 scikit-learn 라이브러리와 함께 배포되는 Tips 데이터셋을 예로 삼아, 웹 화면에서 URL을 조립하는 순서를 다섯 걸음으로 보인다.

import duckdb

conn = duckdb.connect()
conn.execute('''
  SELECT
    *
  FROM
    'hf://datasets/scikit-learn/tips/tips.csv';
''').df()

원저자는 이어서 한 가지를 권한다. 데이터를 DuckDB 표에 저장해 두어, 뒤이은 질의마다 원격 종점에 접근하지 않도록 하라는 것이다.

conn.execute('''
  CREATE TABLE Tips AS
  FROM
    'hf://datasets/scikit-learn/tips/tips.csv';
''')

# 이제 표에 질의한다
conn.execute('''
  SELECT
    *
  FROM
    Tips
''').df()

이 권고에 이 장의 절충이 담겨 있다. 원격 질의는 편하지만 매번 통신한다. 앞 절에서 통신량을 아끼는 기법을 배웠는데, 여기서는 통신 횟수를 아끼는 기법이 나온다. 답사자가 같은 비석을 열 번 찾아가지 않고 탁본 한 장을 떠 와 책상에서 열 번 들여다보는 것과 같다.

Hugging Face 데이터셋의 파일이 특정 폴더에 저장된 경우가 있다. Adult Census Income 데이터셋이 그 예다. Files 탭을 누르면 data 폴더가 보이며, 그 안에 내려받으려는 파일이 있다. 파일 이름 옆에 표시된 아이콘을 누르고 파일 이름을 복사한다.

이 예에서 내려받으려는 것은 Parquet 파일이다. 온전한 URL은 다음과 같다. data 폴더 이름이 더해진 것을 눈여겨본다.

hf://datasets/AiresPucrs/adult-census-income/data/
train-00000-of-00001-7e70ed54d8cbb057.parquet

conn.execute('''
  SELECT
    *
  FROM
    'hf://datasets/AiresPucrs/adult-census-income'
    '/data/train-00000-of-00001-7e70ed54d8cbb057.parquet'
''').df()

여러 파일을 별표 하나로

제6장에서 다룬 glob 구문으로 여러 파일에 질의할 수 있다. 상기하는 뜻에서 glob 양상의 목록을 다시 옮긴다.

어떤 데이터셋에 geo_test.csv와 geo_train.csv 두 파일이 있다고 하자. 모든 CSV 파일을 적재하려면 별표를 쓴다.

# 두 CSV 파일을 한꺼번에 적재한다
conn.execute('''
  SELECT
    *
  FROM
    'hf://datasets/gabrielwu/city_country/*.csv'
''').df()

# question 열에 'Huaibei'가 든 행을 찾는다
conn.execute('''
   SELECT
     *
   FROM
    'hf://datasets/gabrielwu/city_country/*.csv'
  WHERE question LIKE '%Huaibei%';
''').df()

그리고 glob 양상이 가장 값을 하는 자리는 Parquet 파일이다. 파일 집합 전체를 내려받을 필요가 흔히 없기 때문이다. 두 개의 Parquet 파일을 가진 데이터셋에서 question 열만 내려받고, 그 가운데 “happened”가 든 행만 표시한다.

conn.execute('''
  SELECT
    question
  FROM
    'hf://datasets/Stanford/web_questions/data/*…
  WHERE question LIKE '%happened%';
''').df()

여기서 앞 절의 눈금이 여러 파일로 확장된다. 별표 하나가 파일의 수를 늘리고, 열 이름 하나가 통신량을 줄인다. 두 방향이 서로 어긋나지 않는다는 점이 이 기법의 힘이다. 백 개의 비석을 훑으면서도 각 비석에서 한 줄만 떠 온다.

지금까지는 공개 Hugging Face 데이터셋에 접근하는 법이었다. 비공개 데이터셋은 어떤가. 공개와 비공개의 주된 차이는, 비공개 데이터셋에는 접근하기 전에 해당 자격 증명을 제공해야 한다는 것이다. 익힐 것은 셋이다.

• 만든다 CSV 파일을 Hugging Face에 올려 비공개 데이터셋을 만든다.
• 열쇠를 얻는다 그 비공개 데이터셋에 접근할 액세스 토큰을 만든다.
• 보인다 액세스 토큰을 제공해 DuckDB로 비공개 데이터셋에 원격 접근한다.

이 모든 일을 하기 전에 Hugging Face에 계정을 만들어야 한다. https://huggingface.co로 가서 Sign Up 버튼을 누르고, 전자우편 주소와 쓰려는 비밀번호를 넣고 Next를 누른다.

비공개 데이터셋을 올린다

액세스 토큰을 만든다

인증하는 두 가지 길

액세스 토큰이 생성되었으므로 그것으로 DuckDB에서 비공개 데이터셋에 접근할 수 있다. DuckDB가 지원하는 주된 제공자(provider)는 둘이다.

import duckdb

conn = duckdb.connect()
conn.execute('''
   CREATE SECRET hf_token (
      TYPE HUGGINGFACE,
      TOKEN '<HuggingFace_Token>'
 );
''')

# 이제 공개 데이터셋의 파일에 접근하듯 쓴다
conn.execute('''
  SELECT
    *
  FROM
    'hf://datasets/Wei-Meng/StockPrices/AMZN.csv'
''').df()

비공개 데이터셋에 접근하는 CONFIG 제공자 방법은 코드에 액세스 토큰을 노출한다. 액세스 토큰을 파일에 저장하는 CREDENTIAL_CHAIN 방법이 훨씬 안전하다. 먼저 Hugging Face Hub 파이썬 꾸러미를 설치하고 로그인 유틸리티를 실행한다.

$ pip install huggingface_hub

$ huggingface-cli login
Token: <HuggingFace_Token>

# 액세스 토큰을 붙여 넣는다. 화면에 되비침이 없다.
# git 자격 증명으로 추가할지 묻는다. n을 넣고 Enter를 누른다.

Add token as git credential? (Y/n) n
Token is valid (permission: read).
Your token has been saved to /Users/weimenglee/.cache/huggingface/token
Login successful

import duckdb

conn = duckdb.connect()
conn.execute('''
  CREATE SECRET hf_token (
      TYPE HUGGINGFACE,
      PROVIDER CREDENTIAL_CHAIN
   );
''')
conn.execute('''
  SELECT
    *
  FROM
    'hf://datasets/Wei-Meng/StockPrices/AMZN.csv'
''').df()

제7장의 마지막 절이 여기서 되돌아온다. 그때도 세 가지 방법의 차이가 비밀번호를 어디에 두는가에 있었고, 운영체제나 파일에 맡기는 쪽이 권장되었다. 여기서도 같다. CREATE SECRET의 본문 한 줄이 TOKEN '…'에서 PROVIDER CREDENTIAL_CHAIN으로 바뀌는 것뿐인데, 그 한 줄이 코드에 열쇠를 박아 두는 일과 열쇠를 밖에 맡기는 일을 가른다. 열쇠를 문설주 밑에 두지 말라는 오래된 말과 다르지 않다.