데이터 계보 예시: SQL과 다이어그램을 활용한 6가지 실제 시나리오

에이 데이터 계통 예시 구체적인 SQL 구문을 통해 어떤 소스 테이블과 열이 어떤 출력 열에 데이터를 제공하는지, 그리고 데이터가 그 과정에서 어떤 변환을 거치는지 보여줍니다. 아래의 여섯 가지 예제는 데이터 엔지니어가 실제로 접하는 상황을 다룹니다. 삽입-선택이 예제들은 다중 CTE 변환, 뷰 체인, 동적 SQL을 사용하는 저장 프로시저, dbt 모델 체인, 그리고 교차 데이터베이스 ETL 흐름을 포함합니다. 각 예제는 SQL 쿼리를 제공하고, 해당 쿼리의 계보 그래프가 어떻게 생겼는지 정확하게 설명합니다.

이 예시들을 읽는 방법

각 계보 그래프에는 두 종류의 에지가 있습니다. A 직접 엣지(edge)는 데이터가 소스 열에서 대상 열로 물리적으로 흐르는 것을 의미하며, 이 과정에서 함수나 집계 함수를 거칠 수도 있습니다. 간접 edge는 열이 결과에 직접 닿지 않고 결과를 형성하는 것을 의미합니다. 사용된 열은 다음과 같습니다. 어디, 가입하다, 그리고 그룹화 기준 조항들. 간접적인 영향을 간과하는 것이 영향 분석이 잘못되는 이유입니다. 필터 열을 삭제하는 것만으로도 선택된 열을 삭제하는 것만큼이나 보고서가 제대로 작동하지 않기 때문입니다. 이러한 용어가 생소하다면 다음부터 시작해 보세요. 데이터 계보란 무엇인가 그리고 컬럼 수준 계보는 어떻게 작동하는가그러고 나서 돌아오세요.

예시 1: 간단한 INSERT-SELECT 데이터 계보 예시

계보에 대한 논의의 출발점은 집계된 데이터를 요약표에 기록한 하나의 진술입니다.

INSERT INTO sales_summary (region, total_amount) SELECT c.region, SUM(o.amount) FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.status = 'completed' GROUP BY c.region;

계보 그래프에는 세 개의 테이블이 있습니다(명령, 고객, 판매 요약) 그리고 이러한 열 수준 에지:

대상 열	원본 열	엣지 타입	을 통해
판매 요약.지역	고객 지역	직접	일반 사본
판매 요약.총액	주문 금액	직접	합집합()
판매 요약.*	주문 상태	간접	어디 필터
판매 요약.*	주문.고객_ID, 고객 ID	간접	가입하다 상태

그래프가 이미 알려주는 내용 중 테이블 수준 보기에서는 알 수 없는 부분을 주목하세요. 고객 이메일 그리고 나머지 손대지 않은 열들은 여기서 아무런 역할도 하지 않습니다. 주문 상태 출력 결과에 나타나지 않더라도 중요한 요소입니다. 많은 계보 도구는 이러한 마지막 부분을 완전히 건너뛰지만, SQLFlow는 직접 계보와 간접 계보를 별도의 전환 가능한 관계 유형으로 모델링합니다.

예시 2: 다중 CTE 변환

CTE는 손으로 그린 계보도가 시작되는 지점인데, 각 CTE는 그래프가 원래 소스를 잃지 않고 거쳐야 하는 임시 관계이기 때문입니다.

WITH daily AS ( SELECT order_date, customer_id, SUM(amount) AS day_total FROM orders GROUP BY order_date, customer_id ), ranked AS ( SELECT customer_id, day_total, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY day_total DESC) AS rn FROM daily ) SELECT customer_id, day_total AS best_day_revenue FROM ranked WHERE rn = 1;

계보 그래프가 표시됩니다 일일 그리고 순위 중간 노드로서, 관심 있는 열의 전체 경로는 다음과 같습니다. 주문 금액 → 합집합() → 일일 합계 → 순위.일_총합 → 최고 매출윈도우 함수는 보다 미묘한 연쇄 반응을 일으킵니다. rn 는 다음으로부터 계산됩니다. 고객 ID (분할) 및 일별 합계 (순서대로), 그리고 나서 여기서 rn = 1 만들다 rn 모든 출력 열에 대한 간접 입력입니다. 따라서 주문 금액 영향 최고 매출 두 가지 경로가 있습니다. 하나는 합계를 통한 직접적인 경로이고, 다른 하나는 어떤 행이 남을지 결정하는 순위를 통한 간접적인 경로입니다. 열 이름만 패턴으로 일치시키는 리졸버는 두 번째 경로를 인식할 수 없습니다.

예시 3: 일련의 관점

뷰는 누적됩니다. 잘 구축된 데이터 웨어하우스에서는 보고서가 물리적 테이블에서 3~4단계의 뷰 정의를 거쳐야 하는 경우가 많으며, "이 숫자는 실제로 어디에서 온 것일까?"라는 질문에 답하려면 전체 과정을 살펴봐야 합니다.

CREATE VIEW v_active_customers AS SELECT id, name, email FROM customers WHERE status = 'active'; CREATE VIEW v_customer_revenue AS SELECT a.id, a.name, SUM(o.amount) AS revenue FROM v_active_customers a JOIN orders o ON o.customer_id = a.id GROUP BY a.id, a.name;

그래프는 다음을 보여줍니다 v_고객_수익.수익 시야 경계를 따라 다시 추적하여 주문 금액, 와 함께 고객 상태 첫 번째 뷰의 필터에서 상속받은 간접 에지로 연결되어 있습니다. 또한 반대 방향으로도 유용한 정보를 제공합니다. v_active_customers.email 첫 번째 뷰에서 선택되지만 하위 단계에서는 전혀 사용되지 않는 열입니다. 이처럼 사용되지 않는 열은 정리 또는 마이그레이션 전에 찾아내야 할 대상이며, 테이블 수준에서는 보이지 않습니다. 뷰 정의에서 사용하는 경우 선택하다 *SQLFlow는 스키마에 대해 별표를 확장하므로 상속된 모든 열은 여전히 물리적 소스로 확인됩니다.

예제 4: 동적 SQL을 사용한 저장 프로시저

이 예시는 대상 테이블 이름이 코드에 문자 그대로 존재하지 않기 때문에 리니지 도구들을 구분하는 기준이 됩니다. 다음은 임시 테이블과 동적으로 생성된 테이블을 통해 월별 스냅샷을 생성하는 SQL Server 프로시저입니다. 끼워 넣다:

CREATE PROCEDURE dbo.load_monthly_snapshot @month VARCHAR(7) AS BEGIN SELECT o.customer_id, SUM(o.amount) AS month_total INTO #monthly FROM dbo.orders o WHERE CONVERT(VARCHAR(7), o.order_date, 126) = @month GROUP BY o.customer_id; DECLARE @sql NVARCHAR(MAX) = N'INSERT INTO dbo.snapshot_monthly (customer_id, month_total) ' + N'SELECT customer_id, month_total FROM #monthly'; EXEC sp_executesql @sql; END

올바른 계보 그래프는 두 가지 장애물을 모두 통과합니다. 주문 금액 → 합집합() → #월간.월_총계 → 스냅샷_월.월_총계, 와 함께 주문.주문_날짜 간접적인 에지로서 어디 조항과 @월 해당 필터의 입력으로 추적되는 매개변수입니다. 이를 구현하려면 실제 T-SQL 프로시저 파서(문장 분할기가 아닌), 문장 간 임시 테이블 추적, 그리고 전달된 SQL 문자열의 해석이 필요합니다. sp_executesql. SQLFlow has dedicated procedural parsers for SQL Server T-SQL and Oracle PL/SQL, resolves dynamic SQL inside procedures, and additionally renders a call graph of which procedures invoke which, so procedure-to-procedure lineage is visible too. Dynamic SQL is the most common blind spot in lineage tooling; if you evaluate any tool, test it with this pattern first.

예시 5: dbt 모델 체인

dbt는 별도의 설정 없이 모델 수준의 계보 정보를 제공합니다. ref()하지만 흥미로운 질문은 열 수준에서 발생합니다. 어떤 소스 필드가 어떤 스테이징 이름 변경을 거쳐 어떤 마트 열에 데이터를 제공하는가 하는 것입니다.

-- models/staging/stg_orders.sql SELECT id AS order_id, customer_id, amount, status FROM {{ source('raw', 'orders') }} -- models/marts/fct_customer_revenue.sql SELECT customer_id, SUM(amount) AS lifetime_revenue FROM {{ ref('stg_orders') }} WHERE status = 'completed' GROUP BY customer_id

프로젝트의 dbt 매니페스트를 SQLFlow로 가져오면 그래프가 템플릿화된 참조를 구체적인 열 체인으로 해석합니다. 원 주문 금액 → stg_orders.amount → 합집합() → fct_고객_수익.평생_수익이름이 바뀌면서 ID → 주문 ID 스테이징 홉에 보존됨 상태 마트의 필터에서 간접적인 에지로 전달됩니다. 매니페스트가 모델을 해당 모델이 구축하는 웨어하우스 객체와 연결하기 때문에 동일한 그래프가 dbt에서 관리하는 계보를 dbt 외부에서 해당 테이블에 접근하는 모든 것과 일치시킵니다.

예제 6: 교차 데이터베이스 ETL

부동산은 엔진 전반에 걸쳐 있습니다. 일반적인 흐름은 다음과 같습니다. 운영 중인 SQL Server 데이터베이스가 클라우드 스토리지로 추출되어 Snowflake 스테이징에 로드된 다음 분석 스키마로 변환됩니다. 로드 및 변환 과정은 다음과 같습니다.

-- Snowflake COPY INTO staging.orders_raw FROM @s3_extract/orders/; INSERT INTO analytics.fct_orders (order_id, customer_id, amount_usd) SELECT r.order_id, r.customer_id, r.amount * fx.rate FROM staging.orders_raw r JOIN staging.fx_rates fx ON fx.currency = r.currency;

스노우플레이크 측에서 그래프는 다음과 같습니다. 금액_달러 두 개의 직접적인 부모를 가진 계산 열로서, 주문_원금 그리고 fx_rates.rate산술 표현식을 통해 연결된 것, 그리고 더하기 통화 조인 조건에서 파생된 간접적인 연결선입니다. 전체 파이프라인을 처리하기 위해 SQLFlow에는 양쪽 모두에 각각의 방언으로 데이터를 입력합니다. T-SQL 추출 로직은 SQL Server 파서로, Snowflake 스크립트는 Snowflake 파서로 파싱하며, 총 39개의 방언별 파서가 제공됩니다. 엔터프라이즈 환경에서는 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 대규모 환경을 일괄 스캔하는 영구적인 데이터 계보 저장소에 결과가 저장됩니다. 따라서 SQL Server에서 Snowflake까지의 전체 파이프라인을 하나의 그래프로 시각화하고 DataHub, Microsoft Purview 또는 OpenMetadata로 내보낼 수 있습니다.

이 여섯 가지 사례의 공통점은 무엇일까요?

위의 모든 그래프는 순전히 SQL 텍스트와 스키마 메타데이터만을 기반으로 생성되었습니다. 이것이 바로 핵심 방법론입니다. SQL 기반 데이터 계보변환 로직이 이미 SQL에 존재하므로, 해당 SQL에 대한 정적 분석을 통해 에이전트나 쿼리 로그 접근 없이, 그리고 데이터의 어떤 행도 읽지 않고도 데이터 계보를 재구성할 수 있습니다. 예제 간의 차이점은 단일 SQL에서 구문 분석의 난이도에 있을 뿐입니다. 삽입-선택 프로시저 내에서 동적 SQL을 사용합니다.

예	운동 효과	어려운 부분
1. 삽입-선택	직접 에지 vs 간접 에지	모델링 어디/가입하다 계보로서의 열
2. 다중 CTE	중간 관계	윈도우 함수 입력; 순위 기반 필터 경로
3. 체인 보기	중첩된 정의	별의 확장; 죽은 기둥 찾기
4. 저장 프로시저	절차 코드	임시 테이블 및 동적 SQL 해석
5. dbt 체인	템플릿화된 SQL	해결 중 ref()/원천() 실제 사물에
6. 크로스 데이터베이스 ETL	다양한 방언	엔진별 그래프를 하나의 저장소로 통합

자주 묻는 질문

데이터 계보도란 무엇인가요?

데이터 계보 다이어그램은 노드가 테이블, 뷰 또는 컬럼이고 에지가 SQL 변환을 통해 데이터가 이들 간에 어떻게 흐르는지를 보여주는 방향 그래프입니다. 이 페이지에서 설명하는 것과 같은 컬럼 수준 다이어그램은 소스 컬럼과 대상 컬럼 간의 관계마다 하나의 에지를 그리고, 해당 에지를 생성한 함수 또는 절을 주석으로 표시합니다.

제가 직접 이러한 예시들을 재현할 수 있을까요?

네. 위의 SQL 코드 조각 중 아무거나 붙여넣으세요. 무료 SQLFlow 시각화 도구해당 방언을 선택하면 몇 초 만에 대화형 다이어그램이 나타납니다. 클라우드 버전은 무료 티어를 제공합니다.

직접 혈통과 간접 혈통의 차이점은 무엇인가요?

직접 계보란 데이터가 소스 열에서 대상 열로 흐르는 것을 의미합니다. 예를 들어 SUM(주문 수량) 급송 총액간접적인 영향이란 열이 결과에 직접 나타나지 않고도 결과에 영향을 미치는 것을 의미합니다. 예를 들어, 어디 필터 또는 가입하다 핵심은 SQLFlow가 두 가지 유형을 별도의 토글 가능한 엣지 유형으로 추적한다는 점입니다. 대부분의 도구는 직접 흐름만 캡처합니다.

저장 프로시저와 동적 SQL에서 데이터 계보를 추출할 수 있습니까?

네, 하지만 쿼리 파서뿐만 아니라 프로시저 파서도 필요합니다. SQLFlow는 Oracle PL/SQL 및 SQL Server T-SQL 전용 파서를 제공하며, 매개변수와 임시 테이블을 통해 계보를 추적하고, 프로시저 내부에 있는 SQL 문자열을 해석하고, 프로시저 간 호출 그래프를 그립니다.

오픈소스 도구는 이러한 예제를 처리할 수 있습니까?

부분적으로 그렇습니다. 도서관 같은 곳들이요. sqllineage 그리고 sqlglot 개별 쿼리를 분석하는 데는 정말 탁월하며, 예제 1과 2도 잘 처리합니다. 커밋하기 전에 테스트해 볼 가치가 있는 예제는 4~6번입니다. 동적 SQL을 사용하는 절차적 코드, 별도의 엣지 유형으로 표현되는 간접 계보, 그리고 여러 방언이 사용되는 환경을 하나의 대화형 그래프로 통합하는 예제입니다. 평가하는 모든 도구를 사용하여 가장 복잡한 저장 프로시저를 실행하고 결과를 비교해 보세요.

이 예제들은 어떤 SQL 방언과 호환되나요?

SQLFlow는 Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL, Trino를 포함한 39개의 방언별 파서를 제공합니다. 위의 예제는 일반 SQL, T-SQL, dbt 템플릿 SQL 및 Snowflake 구문을 사용하며, 각각은 일반 ANSI 문법이 아닌 자체 문법으로 파싱됩니다.