AI‑네이티브 데이터 디스커버리를 위한 MCP 서버 구축: Rust Crates Ecosystem: Part I

Source: Dev.to

소개

전통적인 데이터 탐색은 미리 정의된 쿼리—SQL 코드, 대시보드, BI 도구—에 의존합니다.
데이터 웨어하우스를 대화형으로 탐색하면서, 개방형 질문을 하고 AI가 여러분이 생각하지 못한 패턴을 찾아낸다면 어떨까요?

Model Context Protocol (MCP)이 이를 가능하게 합니다. 저는 Rust 생태계를 분석하기 위해 MCP 서버를 구축하고 Claude가 이를 탐색하도록 하여, 크레이트, 의존성, 트렌드에 대한 질문에 답하도록 했습니다.

따라해 보고 싶다면 **Rust Crates Analytics Repo**에서 전체 프로젝트를 확인하세요.

crates.io 데이터 이해하기

crates.io DB 덤프를 다운로드하고 압축을 푼 뒤(README의 download link 참조) 다음을 받게 됩니다:

• 로컬에 로드하기 위한 지침이 포함된 PostgreSQL 덤프
• 실제 내용을 나타내는 CSV 파일이 들어 있는 data 폴더

엔터티 개요

사실 테이블

• version_downloads – 버전별 일일 다운로드 수 시계열 (최근 3개월만).
• crate_downloads – 크레이트별 전체 다운로드 수 합계.

연결 테이블

• crates_categories – 크레이트와 카테고리를 연결.
• crate_owners – 크레이트와 사용자 또는 팀을 연결.
• crates_keywords – 크레이트와 키워드를 연결.
• dependencies – 버전과 해당 버전이 의존하는 크레이트를 연결.

지원 테이블

• metadata – total_downloads가 들어 있는 단일 행.
• reserved_crate_names – 보호/사용 불가 크레이트 이름 목록.
• default_versions – 크레이트와 기본 버전을 연결.

히스토리 데이터

• version_downloads 테이블은 가장 최근 3개월 데이터만 보관합니다.
• 오래된 일일 CSV 덤프(크레이트.io 사이트에서 제공)에는 version_id와 downloads 열이 있으며, 날짜는 파일명에서 추론해야 합니다.
• 다른 모든 테이블은 덤프 시점의 생태계 상태를 나타냅니다(예: crates.created_at, crates.updated_at).

핵심 요점

• DB 덤프는 매일 새로 고쳐져 다운로드 시점의 생태계를 반영합니다.
• 매일 3개월 창에서 한 날치 데이터가 삭제되고 CSV 아카이브에 보관됩니다.
• 분석에 가장 중요한 테이블은 crates, versions, version_downloads, dependencies입니다.

아키텍처 개요

ELT 파이프라인 설계

추출

• crates.io DB 덤프(tar.gz)를 다운로드하고 CSV 파일을 추출합니다.

적재

• 모든 CSV를 raw 스키마에 전체 새로 고침 전략으로 가져옵니다—새 덤프가 기존 raw 테이블을 교체해 현재 상태의 깨끗한 스냅샷을 제공합니다.

변환

• staging 스키마에서 데이터 품질 규칙을 적용합니다:
  • 모든 타임스탬프를 UTC로 정규화.
  • stg_version_downloads는 증분 로드(새 날짜만 추가). 첫 실행에서는 가능한 모든 날짜를 ingest하고 이후 실행에서는 새로운 데이터만 추가.
  • 차원 테이블(categories, crates, versions, …)은 전체 새로 고침으로 업데이트를 반영.
  • 데이터 계약을 강제하고 품질 테스트를 실행.

이 접근법은 3개월 롤링 윈도우를 효율적으로 처리하면서 stg_version_downloads에 완전한 히스토리 아카이브를 보존합니다.

히스토리 다운로드 백필링

• 히스토리 아카이브는 2014‑11‑11까지 거슬러 올라갑니다.
• 시작/종료 날짜를 매개변수로 받는 백필 스크립트가 오래된 CSV를 직접 stg_version_downloads에 ingest합니다.
• crates, dependencies, versions의 스냅샷도 함께 저장해 덤프 간 변화를 포착합니다.

제약 조건 및 기술 스택

모든 프로젝트 의존성은 uv로 관리되며, 사전 요구사항은 uv가 설치되어 있는 것뿐입니다.

고아 버전 조사

흥미로운 데이터 품질 검사 중 하나는 stg_version_downloads 테이블에 존재하는 고아 버전—versions 테이블에 존재하지 않는 version_id 레코드—를 찾는 것이었습니다.

조사 단계:

1. 고아 행 식별

   SELECT vd.version_id
   FROM stg_version_downloads vd
   LEFT JOIN stg_versions v ON vd.version_id = v.id
   WHERE v.id IS NULL
   LIMIT 100;

2. 문제 규모 파악

   SELECT COUNT(*) AS orphan_count
   FROM stg_version_downloads vd
   LEFT JOIN stg_versions v ON vd.version_id = v.id
   WHERE v.id IS NULL;

3. 근본 원인 분석

   • 고아는 종종 yanked(삭제)되었거나 삭제된 크레이트에서 발생합니다.
   • 3개월 창 안에 다운로드 기록은 현재 versions 테이블에 존재하지 않는 버전에 대한 데이터가 포함될 수 있습니다.

4. 해결 전략

   • 히스토리 완전성을 위해 고아 행을 유지하되, 다운스트림 분석에서는 플래그를 지정합니다.
   • 선택적으로, yanked/삭제된 버전 메타데이터를 보관하는 별도 “historical versions” 테이블을 유지할 수 있습니다.

이 검사는 자동화된 dbt 테스트의 일부가 되어 향후 로드 시에도 고아 행을 감지하도록 합니다.