DuckDB 데이터 계보: 프로세스 내 분석을 위한 열 수준 계보

DuckDB 데이터 계보 이는 DuckDB SQL에서 데이터가 이동하는 방식을 열 수준에서 보여주는 지도입니다. 즉, 각 파생 테이블에 어떤 Parquet 파일과 소스 테이블이 제공되는지, 그리고 어떤 조인, 형변환, 필터 및 집계가 사용되는지를 나타냅니다. Gudu SQLFlow 이 도구는 전용 DuckDB 방언 파서를 사용하여 DuckDB 스크립트를 분석하고 쿼리를 실행하거나 데이터를 건드리지 않고도 대화형 계보도를 자동으로 생성합니다.

DuckDB 파이프라인에 진정한 계보 추적 기능이 필요한 이유

DuckDB는 조용히 중요한 데이터 인프라로 자리매김했습니다. 데이터 변환 계층을 운영하고 있습니다. dbt-덕DB 프로젝트, 로컬 분석, 그리고 나중에 데이터 웨어하우스로 전송되는 분석을 지원하고, 애플리케이션과 노트북에 내장되어 있으며, 점점 더 Parquet 데이터 레이크의 컴퓨팅 엔진 역할을 수행합니다. 이러한 파이프라인의 SQL은 데이터 웨어하우스 SQL과 동일한 종류의 결정을 내립니다. 즉, 매출을 계산하고, 고객을 필터링하고, 대시보드가 읽는 테이블을 구축합니다.

하지만 DuckDB 프로젝트는 일반적으로 데이터 웨어하우스처럼 엄격한 데이터 계보 관리를 받지 못합니다. 여기에는 구조적인 이유가 있습니다. 대부분의 데이터 계보 관리 도구는 데이터베이스 서버를 전제로 하기 때문입니다. 런타임 로그 기반 계보 관리는 중앙 엔진에서 쿼리 로그를 수집하고, 카탈로그 우선 플랫폼은 서버의 메타데이터를 크롤링합니다. DuckDB는 프로세스 내에서 실행됩니다. 서버가 없고, 공유되는 쿼리 기록도 없으며, 설치해야 할 카탈로그 에이전트도 없습니다. 변환 로직은 프로세스 자체에 존재합니다. .sql 파일, dbt 모델 및 스크립트가 저장소에 체크인됩니다.

이러한 이유로 정적 SQL 분석은 DuckDB 데이터 계보를 구축하는 가장 자연스럽고, 종종 유일한 방법입니다. SQLFlow는 SQL 텍스트 자체를 구문 분석하므로 해당 SQL이 노트북에서 실행되든, CI 작업에서 실행되든, 애플리케이션 프로세스 내부에서 실행되든 동일하게 작동합니다.

SQLFlow는 어떻게 DuckDB 데이터 계보를 구축하는가

SQLFlow는 다음을 기반으로 구축되었습니다. 일반 SQL 파서(GSP)DuckDB는 2000년대 중반부터 개발되어 약 13,600개의 방언별 SQL 테스트 픽스처를 통해 검증된 상용 SQL 컴파일러 프런트엔드 중 하나입니다. 방언별 구문 분석기가 포함된 39개의 데이터베이스 — DuckDB의 구문을 덧붙인 일반적인 ANSI 문법이 아닙니다. 파이프라인은 다음과 같습니다.

1. 섭취하세요. DuckDB SQL을 붙여넣거나, 스크립트 파일을 업로드하거나, dbt 매니페스트를 가져오세요. dbt-덕DB 프로젝트.
2. 구문 분석 및 해석. GSP는 CTE, 서브쿼리, 뷰 등을 통해 모든 열 참조를 해결하여 각 문장의 완전한 의미론적 모델을 구축합니다. 선택하다 * 확장.
3. 데이터 흐름을 추출합니다. 데이터 흐름 분석기는 각 출력 열에 대해 어떤 소스 열이 어떤 함수, 형변환, 조인 및 집합 연산자를 통해 해당 열로 전달되는지 정확하게 기록합니다.
4. 시각화하고 내보내기. 대화형 다이어그램을 자세히 살펴보고, 모든 열의 상위 또는 하위 경로를 추적하고, 그래프를 JSON, CSV 또는 PNG 형식으로 내보내거나 REST API를 통해 가져올 수 있습니다.

예시: read_parquet() 및 CTAS를 통한 계보 분석

DuckDB의 대표적인 패턴은 다음과 같습니다. 테이블을 SELECT 형식으로 생성합니다. Parquet 파일을 직접 읽기 - 스테이징 로드 없음, Parquet 파일 ~이다 출처. 일반적인 보고서 작성 방식:

CREATE TABLE reporting.daily_revenue AS SELECT CAST(o.order_ts AS DATE) AS order_date, c.region AS region, SUM(o.amount) AS revenue, COUNT(DISTINCT o.customer_id) AS buyers FROM read_parquet('lake/orders/*.parquet') AS o JOIN dim_customers AS c ON o.customer_id = c.customer_id WHERE o.status = 'completed' GROUP BY 1, 2;

SQLFlow의 DuckDB 파서는 다음을 이해합니다. read_parquet() 테이블 소스로 사용되므로 Parquet 경로는 미해결 함수 호출이 아닌 계보 그래프에서 실제 노드로 표시됩니다. 이 하나의 문장에서 다음을 추출합니다.

• 일일 수익.수익 ~에 의해 공급됩니다 o.금액 파르케 소스에서 시작하여, 합집합().
• 일일 매출.주문일 ~에 의해 공급됩니다 o.order_ts를 통해 깁스 에게 날짜.
• 일일 수익.지역 바로 거기서 가져온 것입니다 dim_customers.region.
• o.상태, o.customer_id, 그리고 c.customer_id 출력 결과에는 나타나지 않지만 출력 형태를 결정짓기 때문에 SQLFlow는 이를 간접 계보로 기록합니다(자세한 내용은 아래 참조).

dbt 프로젝트나 야간 스크립트에 이러한 문장을 50개 정도 연결하면 그래프가 점점 복잡해집니다. SQLFlow는 모든 중간 테이블을 연결하여 대시보드 번호를 해당 번호가 시작된 정확한 Parquet 열까지 추적할 수 있도록 해줍니다.

직접 혈통 vs 간접 혈통

위 예시에서, o.상태 절대 나타나지 않음 일일 수익하지만 방식을 바꾸고 있습니다. 상태 데이터가 채워지면 모든 수익 수치가 조용히 변경됩니다. SQLFlow는 이를 다음과 같이 모델링합니다. 간접적 (영향) 계보: 사용된 열 어디, 가입하다, 그리고 그룹화 기준 절과 내부 집계는 직접적인 데이터 흐름과 함께 별도로 전환 가능한 관계 유형을 형성합니다. 대부분의 경쟁 도구는 이러한 구분을 하지 않기 때문에 영향 분석에서 숨겨진 데이터 버그를 유발하는 종속성을 정확히 파악하지 못합니다.

DuckDB 파이프라인의 경우 이는 두 배로 중요합니다. 파일 기반 소스에는 경고를 표시하는 외래 키나 제약 조건이 없으므로 SQL 자체에만 이러한 종속성이 기록됩니다.

dbt-duckdb 프로젝트의 계보

dbt-덕DB DuckDB가 실제 운영 환경에서 실행되는 가장 일반적인 방식 중 하나이며, dbt 자체의 DAG는 모델 레벨에서 멈춥니다. 즉, 다음과 같은 정보를 제공합니다. 일일 수익 ~에 따라 다릅니다 stg_orders종속성을 갖는 열이 무엇인지는 중요하지 않습니다. SQLFlow는 dbt 매니페스트를 가져와서 생성합니다. 컬럼 레벨 컴파일된 모델 전체에 걸쳐 계보를 확인할 수 있으므로 "어떤 마트가..."라는 질문에 답할 수 있습니다. stg_orders.amount 변경하기 전에 "실제로 먹이를 주는 건가요?"라고 물어보세요.

마이그레이션 시점에도 동일한 분석이 효과적입니다. 팀들은 종종 DuckDB에서 프로토타입을 제작한 후 나중에 모델을 다른 데이터베이스로 이전합니다. 클릭하우스, 포스트그레스 SQL또는 클라우드 웨어하우스. SQLFlow는 이러한 모든 데이터를 방언별 문법으로 파싱하기 때문에 이동 전에 실제 종속성 그래프를 매핑하고 이동 후에 고아 데이터가 없는지 확인할 수 있습니다. 즉, 양쪽 모두에서 하나의 도구와 하나의 계보 모델을 사용할 수 있습니다.

DuckDB 계보 추적에는 어떤 옵션이 있나요?

접근하다	잘한다	DuckDB의 격차
수동 문서화	의도와 비즈니스 맥락 파악	작성된 다음 날이면 내용이 식상해짐; 칼럼 세부 정보 없음
오픈소스 파서(sqllineage, sqlglot)	Python 워크플로에서 개별 쿼리를 구문 분석합니다. (무료)	해상도, 별의 확장, 교차 진술 연결 및 시각화를 직접 조립해야 합니다. 간접적인 계승은 당신에게 달려 있습니다.
런타임 로그 기반 계보	서버에서 실제로 실행된 내용을 관찰하기	로그를 생성하는 중앙 엔진을 가정합니다. 노트북이나 앱 내에서 실행되는 인프로세스 DuckDB는 수집할 데이터가 없습니다.
카탈로그 우선 플랫폼	전체 스택에 걸친 거버넌스 워크플로, 소유권, 용어집	계보의 깊이는 방언별 SQL 구문 분석에 따라 달라지므로, 내장된 DuckDB 스크립트는 제대로 된 정보 소스가 되기 어렵습니다.
Gudu SQLFlow	SQL 텍스트 자체에 대한 정적 열 수준 분석으로, 방언을 인식하고 직접 및 간접 계보를 추적합니다.	팀 규모 사용을 위한 유료 요금제 (개인 문의는 무료 요금제 이용 가능)

이 두 가지는 상호 배타적이지 않습니다. 이미 카탈로그를 실행 중인 경우 SQLFlow의 엔터프라이즈 배포는 계보를 내보냅니다. DataHub, Microsoft Purview 및 OpenMetadata그래서 그것은 당신이 관리하는 카탈로그의 구문 분석 엔진이 됩니다.

배포 및 개인정보 보호

SQLFlow는 SQL 코드에 대한 정적 분석만 수행하며, 테이블이나 Parquet 파일의 행을 읽지 않습니다. DuckDB 스크립트에 자체 로직이 포함된 팀의 경우, 온프레미스 SQLFlow SQLFlow Cloud는 네트워크 내부에서 Docker 또는 Kubernetes로 실행되므로(에어갭 설치 지원) SQL 텍스트조차도 인프라 외부로 유출되지 않습니다. SQLFlow Cloud는 무료로 시작하며 프리미엄 버전은 월 $49.99입니다. 온프레미스 버전은 월 $500 또는 선택한 데이터베이스 유형당 1회 $4,800이며, 두 대의 서버에 설치할 수 있습니다. 두 버전 모두 헤드리스 CLI 및 REST API를 통해 스크립트 실행이 가능하여 DuckDB의 자동화 중심 CI 문화에 적합합니다.

반대로, 동일한 엔진이 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 대규모 환경을 증분 스캔 및 영구적인 데이터 계보 저장소를 사용하여 일괄 스캔하므로 스택의 DuckDB 부분과 데이터 웨어하우스를 하나의 데이터 계보 그래프에서 관리할 수 있습니다.

자주 묻는 질문

SQLFlow는 read_parquet() 및 파일 소스를 통해 계보를 추적할 수 있습니까?

예. DuckDB 방언 분석기는 다음과 같이 처리합니다. read_parquet() 테이블 소스로 사용되므로 파일 경로는 계보 그래프에서 소스 노드로 나타나고 Parquet에서 읽은 열은 다른 열과 마찬가지로 하위 테이블로 추적됩니다.

데이터 계보를 얻으려면 DuckDB 쿼리를 실행해야 하나요?

아니요. SQLFlow는 정적 분석 도구입니다. SQL 텍스트를 파싱할 뿐 실행하지는 않습니다. 따라서 서버 측 쿼리 로그를 수집할 필요가 없는 인프로세스 DuckDB에 적합합니다.

SQLFlow는 dbt-duckdb 프로젝트를 지원하나요?

예. dbt 매니페스트를 가져오면 SQLFlow가 모델 전체에 걸쳐 열 수준의 계보를 생성합니다. 이는 dbt 자체의 모델 수준 DAG보다 더 세밀한 정보입니다.

DuckDB는 실제 방언 파서를 지원하나요, 아니면 일반 ANSI SQL을 지원하나요?

진정한 방언 파서입니다. SQLFlow는 DuckDB를 포함한 39개 데이터베이스에 대한 방언별 파서를 제공하며, 이 파서 엔진은 방언별로 약 13,600개의 SQL 테스트 픽스처를 통해 검증되었습니다.

DuckDB 스크립트에서 생성된 데이터 계보 정보를 내 데이터 카탈로그에 추가할 수 있나요?

예. 엔터프라이즈 배포에는 DataHub, Microsoft Purview 및 OpenMetadata용 내보내기 어댑터와 JSON 및 CSV 내보내기, 사용자 지정 통합을 위한 REST API가 포함됩니다.

SQLFlow를 이용한 DuckDB 데이터 계보 분석 비용은 얼마인가요?

SQLFlow 클라우드는 무료 티어를 제공하며, 프리미엄 티어는 월 $49.99입니다. 온프레미스 버전은 월 $500 또는 선택한 데이터베이스 유형당 일회성 $4,800입니다. 자세한 내용은 다음을 참조하세요. 가격 자세한 내용은 다음을 참조하세요.