컬럼 수준 데이터 계보: 무엇이며 테이블 수준만으로는 부족한 이유

컬럼 수준 데이터 계보 쿼리, 뷰 또는 보고서의 모든 출력 열을 해당 쿼리, 뷰 또는 보고서를 생성한 정확한 소스 열에 매핑하며, 그 과정에서 적용된 모든 변환(함수, 형변환, 조인, 집계 및 필터)도 포함합니다. 여기서 테이블 수준 계보는 "테이블"을 의미합니다. 명령 사료 테이블 수익 보고서", 컬럼 수준 계보는 다음과 같습니다."수익 보고서.총액 ~이다 SUM(주문 수량)필터링됨 주문 상태 그리고 그룹화됨 고객 지역이는 영향 분석, 디버깅 및 감사 답변이 근사치가 아닌 정확성을 확보할 수 있는 세분성입니다.

이 페이지에서는 용어를 정의하고, CTE, 조인 및 집계를 사용하는 실제 쿼리를 통해 하나의 출력 열을 살펴보고, 이러한 정보를 추출하는 데 패턴 매칭이 아닌 시맨틱 SQL 구문 분석이 필요한 이유를 설명합니다. 데이터 계보라는 개념이 생소하다면 이 페이지부터 시작하세요. 데이터 계보란 무엇이며 왜 중요한가그런 다음 여기로 돌아와서 열별 세부 정보를 확인하세요.

컬럼 수준 데이터 계보에는 어떤 기록이 있나요?

문장이 쓰거나 반환하는 모든 열에 대해 열 수준 계보 그래프는 다음 세 가지를 저장합니다.

• 원본 열: 출력으로 전달되는 물리적 열의 값은 CTE, 서브쿼리, 뷰, 임시 테이블과 같은 여러 중간 계층을 거쳐 결정됩니다.
• 변환: 경로에 적용된 연산, 예: 합집합(), 깁스(), 사례 표현식, 문자열 함수 및 집합 연산자 등 노동 조합.
• 관계 유형: 소스 열의 값이 실제로 출력에 반영되는지(직접 계보) 아니면 필터, 조인 또는 그룹화를 통해 결과에 영향을 미치는지(간접 계보)를 구분하는 것입니다. 대부분의 도구는 이 부분을 생략하기 때문에 아래에서 이 차이점에 대해 자세히 설명합니다.

테이블 수준의 계보 정보만으로는 충분하지 않은 이유

테이블 수준의 데이터 계보는 생성 비용이 저렴하고 초기 방향 설정에 매우 유용합니다. 어떤 테이블과 뷰가 어떤 데이터에 데이터를 제공하는지 보여주는 지도 역할을 하기 때문입니다. 하지만 문제는 데이터 팀이 실제로 답을 얻어야 하는 질문은 컬럼 수준의 질문이라는 점이며, 테이블 수준의 세분화는 지나치게 근사치를 사용하게 만든다는 것입니다.

질문	표 수준 답변	컬럼 수준 답변
이름을 바꾸면 어떤 문제가 발생하나요? 고객 이메일?	읽는 모든 객체 고객 — 흔히 수십 건의 오탐이 발생합니다.	참조하는 견해, 절차 및 보고서만 해당됩니다. 이메일 구체적으로
대시보드에 표시된 이 잘못된 번호는 어디에서 온 것입니까?	“이 네 개의 테이블 상류 어딘가에”	대시보드 필드에서 물리적 소스 열까지 이어지는 정확한 표현식 체인
어떤 출력물에 개인 식별 정보(PII)가 포함되어 있습니까? ssn?	원본 테이블 이후의 모든 테이블은 (원본 테이블 여부와 관계없이) ssn 전파하다	정확한 열 세트는 다음과 같습니다. ssn 실제 가치는 도달합니다
이 스테이징 열을 삭제할 수 있을까요?	알 수 없음 — 표가 참조되어 있으므로, 참조되지 않았다고 가정합니다.	예, 하위 열에서 직접 또는 간접적으로 해당 값을 읽지 않는 경우입니다.

오탐으로 인한 비용은 단순한 이론적 문제가 아닙니다. 스키마 변경으로 인해 테이블 수준에서 40개의 하위 대시보드가 경고를 받았지만 실제로 변경된 열을 사용하는 대시보드는 3개뿐이라면, 나머지 37개는 불필요하게 재테스트되거나, 더 나쁘게는 팀이 데이터 계보 도구를 무시하게 될 수 있습니다. 데이터 계보의 신뢰성은 정확성에 달려 있으며, 그 정확성은 열 수준에서 결정됩니다.

예시: CTE, 조인 및 집계를 통해 하나의 열을 처리하는 방법

다음은 간단하지만 현실적인 질문입니다. 목표는 정확히 어디에서 발생하는지 추적하는 것입니다. 총수익 ~에서 유래합니다.

최근 주문 테이블(recent_orders)에서 o.order_id, o.customer_id, o.amount, o.status 값을 선택하고, o.order_date가 '2026-01-01' 이상인 주문 테이블(orders)의 c.region과 r.amount의 합계를 총 수익(total_revenue)으로 계산한 후, c.customer_id와 r.customer_id가 같은 고객 테이블(customers c)을 조인합니다. 이때 r.status 값이 'COMPLETED'인 조건을 만족하는 고객 테이블을 c.region으로 그룹화합니다.

해결 중 총수익 세 번의 홉이 필요합니다:

1. 총수익 다음과 같이 정의됩니다. 합계(r.amount)그러므로 그 값은 해당 열에서 가져옵니다. 양 별칭이 지정된 관계 아르 자형집계 함수를 통과했습니다.
2. 아르 자형 이것은 표가 아닙니다. 이것은 CTE입니다. 최근 주문의 양 컬럼은 통과입니다. 주문 금액별칭, CTE 및 열 투영은 모두 물리적 소스를 파악하기 전에 해결되어야 합니다.
3. 따라서 완전한 직계 혈통은 하나의 물리적 기둥으로 이루어져 있습니다. 주문 금액 → 최근 주문 금액 → 합집합() → 총수익.

하지만 결과에 나타나지 않으면서도 결과에 영향을 미치는 다섯 개의 요소가 더 있습니다. 주문.주문_날짜 CTE 내부의 행을 필터링합니다. 주문 상태 외부에서 다시 필터링합니다. 어디, 주문.고객_ID 그리고 고객.고객_ID 어떤 행들을 결합할지 결정하고 고객 지역 행을 집계 버킷으로 그룹화하는 방법을 결정합니다. 이러한 항목 중 어느 하나라도 의미론을 변경하면 총수익 값이 출력 결과에 나타나지 않더라도 변경 사항이 발생합니다. 텍스트 검색을 하면 "이 쿼리는 다음을 건드립니다"라는 결과가 표시됩니다. 명령 그리고 고객"열 수준 계보는 어떤 열이 값을 가지고 있는지, 그리고 그 값을 관리하는 다섯 개의 열이 무엇인지 알려줍니다."

직접 혈통과 간접 혈통의 차이: fdd/fddi 구분법

이 두 가지 유형의 관계는 각각 다른 이름으로 불릴 만합니다. Gudu SQLFlow의 계보 모델에서는, 직접 데이터 흐름 (표시됨) fdd)는 소스 열의 값이 함수, 형변환 또는 집계에 의해 변환되어 대상 열로 전달됨을 의미합니다. 간접 데이터 흐름 (표시됨) fddi)는 소스 열이 값을 제공하지 않고 대상에 영향을 미치는 것을 의미합니다. 사용된 열 어디 술어, 가입하다 정황, 그룹화 기준 키 및 유사한 조항.

SQLFlow는 이러한 요소들을 다이어그램에서 각각 별도로 토글 가능한 관계 유형으로 모델링합니다. 간접 계보를 끄면 순수한 값 출처만 볼 수 있는데, 이는 감사자가 규제 보고서에 어떤 소스 필드가 포함되는지 입증할 때 필요한 보기입니다. 반대로, 전체 영향 범위를 보려면 켜야 합니다. 이는 엔지니어가 열을 수정하기 전에 필요한 보기인데, 필터 열을 삭제하면 모든 하위 집계가 자동으로 변경되기 때문입니다. 대부분의 경쟁 계보 도구는 이러한 구분을 전혀 하지 않습니다. 직접 흐름만 보고하여 실제 영향을 놓치거나, 모든 것을 하나로 묶어 열 수준으로 옮겨 놓았던 오탐을 다시 발생시키기도 합니다.

이것이 정규 표현식이 아닌 의미론적 구문 분석을 필요로 하는 이유는 무엇일까요?

테이블 이름과 컬럼 이름을 SQL 텍스트에서 패턴 매칭하여 계보를 추출하려는 유혹이 있지만, 이러한 접근 방식은 실제 운영 환경에서 흔히 볼 수 있는 SQL 구문과 정확히 일치하는 문제점을 드러냅니다.

• 별의 팽창. 선택하다 * 열 이름을 전혀 지정하지 않습니다. 어떤 열이 전달되는지는 분석 시점의 기본 관계 스키마에 따라 달라지며, 조인의 경우 조인된 모든 관계의 결합된 스키마에 따라 달라집니다. 해결 * 메타데이터와 범위 규칙이 필요하며, 텍스트 패턴으로는 열 목록을 생성할 수 없습니다.
• 보기 해상도. 쿼리가 읽힐 때 v_sales.net_amount진정한 계보는 뷰의 정의를 통해 이어지며, 뷰는 일반적으로 다른 뷰 위에 쌓입니다. 분석기는 각 정의를 재귀적으로 확장하고 열 매핑을 연결해야 하는데, 이는 문자열이 아닌 해결된 의미 모델에 대한 작업입니다.
• 범위와 모호성. 자격 미달 칼럼은 다음과 같습니다. 상태 세 테이블을 조인할 때, 해당 테이블은 SQL의 범위 지정 규칙과 테이블 스키마에 따라 정확히 하나의 관계에 속하게 됩니다. 잘못 추측하면 계보 그래프가 조용히 손상될 수 있습니다.
• 표현. COALESCE(ax, by), 사례 분기 및 윈도우 함수는 각각 서로 다른 기여 열 집합을 정의합니다. 오직 실제 표현식 트리만이 이를 포착할 수 있습니다.
• 방언. 오라클의 연결 방법T-SQL의 산출 조항, BigQuery의 제외하고 별표 목록에서 각 방언은 일반적인 ANSI 문법이 구문 분석에 실패하는 구문을 가지고 있습니다. SQLFlow는 하나의 최소 공통분모 문법 대신 39개의 방언별 구문 분석기를 제공합니다.

In short, accurate column-level lineage is a compiler problem. SQLFlow is built on the General SQL Parser, a full SQL compiler front-end (lexer, parser, semantic resolver, data-flow analyzer) developed commercially since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. The same engine resolves the hardest cases: stored procedure bodies in Oracle PL/SQL and SQL Server T-SQL, lineage through procedure parameters and temp tables, and dynamic SQL assembled inside procedures.

컬럼 수준의 계보를 실제로 확인하는 방법

Gudu SQLFlow는 자동화된 도구입니다. SQL 데이터 계보 도구 이 도구는 붙여넣은 쿼리, 업로드된 파일, JDBC를 통한 실시간 데이터베이스 메타데이터, dbt 매니페스트 파일, Snowflake 쿼리 기록 및 Redshift 쿼리 로그 등 어떤 SQL 쿼리를 사용하든 이 페이지에 설명된 열 수준 그래프를 생성합니다. 출력은 열별로 자세히 살펴볼 수 있는 대화형 다이어그램과 JSON 또는 CSV 형식의 구조화된 계보 데이터, PNG 내보내기, 그리고 REST API입니다.

엔터프라이즈 규모에서 SQLFlow는 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 환경을 일괄 스캔하고, 영구적인 계보 저장소에 대해 증분 스캔을 실행하며, DataHub, Microsoft Purview 및 OpenMetadata로 내보내므로 열 수준의 계보를 기존에 사용 중인 카탈로그 내에서 관리할 수 있습니다. 분석은 정적으로 이루어지기 때문에 SQLFlow는 SQL 코드와 스키마 메타데이터만 읽고 테이블의 행은 절대 읽지 않으며, 온프레미스 버전은 SQL 텍스트를 네트워크 내에 완전히 보관합니다.

위와 같은 추적 정보를 더 자세히 보려면, 서브쿼리, 뷰, 저장 프로시저 및 dbt 모델 전반에 걸친 추적 정보를 확인하려면 저희 라이브러리를 참조하세요. 작업 데이터 계보 예시.

자주 묻는 질문

테이블 수준 데이터 계보와 컬럼 수준 데이터 계보의 차이점은 무엇인가요?

테이블 수준 계보는 어떤 테이블과 뷰가 어떤 객체 쌍에 데이터를 제공하는지, 그리고 각 객체 쌍마다 하나의 연결선을 기록합니다. 열 수준 계보는 모든 출력 열에 대해 해당 열에 데이터를 제공하는 정확한 소스 열과 적용된 변환을 기록합니다. 이러한 열 수준의 세분화는 영향 분석에서 오탐을 제거하고 감사 결과를 정확하게 만드는 데 필수적입니다.

간접적(영향) 계보란 무엇인가요?

간접 계보는 소스 열을 해당 열의 값에는 영향을 주지 않고 출력에 연결하는 방식입니다. WHERE 절, JOIN 조건, GROUP BY 키 및 집계 조건식에 사용되는 열이 이에 해당합니다. SQLFlow는 이를 직접 데이터 흐름(fdd)과 별도로 다이어그램에서 활성화/비활성화할 수 있는 별도의 관계 유형(fddi)으로 모델링합니다.

정규 표현식이나 grep을 사용하여 열 수준의 계보를 추출할 수 있나요?

신뢰할 수 없습니다. 스타 확장, 뷰 해상도, 한정되지 않은 열 이름, CASE 또는 COALESCE와 같은 표현식은 모두 SQL의 실제 구문 분석과 스키마 메타데이터를 기반으로 구축된 의미 모델을 필요로 합니다. 패턴 매칭은 테이블 이름은 찾을 수 있지만, 어떤 열이 어디로 흐르는지는 파악할 수 없습니다.

뷰와 SELECT *를 통해 컬럼 수준의 계보 추적이 가능한가요?

네, 도구가 이를 해결한다면 가능합니다. SQLFlow는 SELECT * 쿼리를 스키마 메타데이터에 대해 확장하고 뷰, CTE 및 서브쿼리를 통해 열 참조를 재귀적으로 해결하므로, 최종 출력 열부터 물리적 소스 열까지 모든 계보를 추적할 수 있습니다.

저장 프로시저와 동적 SQL에서도 작동하나요?

예. SQLFlow는 Oracle PL/SQL 및 SQL Server T-SQL을 위한 전용 프로시저 파서를 제공하고, 프로시저 매개변수 및 임시 테이블을 통해 계보를 추적하며, 프로시저 내에서 구성된 동적 SQL을 해석하고, 프로시저 간 호출 그래프를 생성합니다.

내 SQL 쿼리에 대한 열 수준 계보를 어떻게 얻을 수 있나요?

SQLFlow Cloud의 무료 티어에 쿼리를 붙여넣으면 브라우저에서 열 수준 다이어그램이 표시됩니다. 전체 데이터베이스의 경우 JDBC를 통해 연결하거나 dbt 매니페스트를 가져올 수 있습니다. 규제 환경의 경우 SQLFlow On-Premise는 자체 네트워크 내의 Docker 또는 Kubernetes에서 실행됩니다.