MySQL 데이터 계보: 뷰 및 ETL SQL을 통한 열 계보 추적

MySQL 데이터 계보 MySQL 뷰를 통해 데이터가 흐르는 방식을 열별로 보여주는 맵입니다. 삽입 ... 선택 작업 및 ETL 스크립트: 어떤 소스 열이 각 대상 열에 전달되는지, 그리고 어떤 조인, 필터 및 집계를 통해 전달되는지. MySQL 자체는 이를 보여줄 수 없습니다. 정보 스키마 데이터 흐름이 아닌 구조를 설명합니다. Gudu SQLFlow 이 프로그램은 전용 MySQL 방언 파서를 사용하여 MySQL SQL을 분석함으로써 자동으로 계보를 구축하고, 개별 열까지 자세히 살펴볼 수 있는 대화형 다이어그램을 생성합니다.

information_schema를 사용해도 MySQL 데이터 계보를 확인할 수 없는 이유는 무엇일까요?

MySQL의 정보 스키마 구조 카탈로그입니다. 그것은 당신에게 다음을 알려줄 것입니다. 일일 수익 다섯 개의 열이 있고, 각 열의 유형이 무엇이며 (via) 키 열 사용량어떤 외래 키가 어디를 가리키는지 알려줍니다. 하지만 절대 알려주지 않는 것은 바로 이것입니다. 일일 매출.순매출 는 다음으로부터 계산됩니다. 주문 금액 마이너스 주문 할인필터링됨 주문 상태그리고 그룹화됨 고객 지역.

데이터 흐름에 대한 정보는 오직 한 곳, 즉 SQL 텍스트 자체에만 존재합니다. 일반적인 MySQL 환경에서는 뷰 정의(정보 스키마.뷰 텍스트를 저장하지만, 아무것도 그것을 해석하지 않습니다. 삽입 ... 선택 그리고 중복 키 업데이트 시 ETL 작업에서 실행되는 SQL 문, DDL에서 생성된 열 표현식, 애플리케이션 측 쿼리 파일 등이 있습니다. 이러한 요소들을 SQL 계보로 변환하려면 실제로 SQL을 구문 분석하고 의미론적으로 해석하는 작업이 필요합니다. 선택하다 *조인, 서브쿼리 및 뷰 스택을 통해 열을 추적하는 것. 이것이 SQLFlow의 기능입니다.

예시: INSERT-SELECT 문을 통해 데이터가 입력되는 보고 테이블

다음은 수천 개의 MySQL 기반 보고 시스템에서 매일 밤 실행되는 명령문의 예입니다. 이 명령문은 주문을 집계하여 요약 테이블에 추가하는 업서트(upsert) 작업입니다.

INSERT INTO daily_revenue (report_date, region, order_count, gross_revenue, net_revenue) SELECT o.order_date, c.region, COUNT(*), SUM(o.amount), SUM(o.amount - o.discount) FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'completed' GROUP BY o.order_date, c.region ON DUPLICATE KEY UPDATE order_count = VALUES(order_count), gross_revenue = VALUES(gross_revenue), net_revenue = VALUES(net_revenue);

SQLFlow를 통해 실행하면 대상 열별로 해당 값에 직접 값을 제공하는 열과 결과에 직접 포함되지는 않지만 결과를 변형하는 열을 모두 추출합니다.

대상 열	직접 출처	간접적 영향
일일 매출 보고서 날짜	주문.주문_날짜	주문 상태
일일 수익.지역	고객 지역	고객 ID, 주문.고객_ID, 주문 상태
일일 매출.총 매출	주문 금액 ~을 통해 합집합()	주문.주문_날짜, 고객 지역 (그룹화 기준), 조인 키, 주문 상태
일일 매출.순매출	주문 금액, 주문 할인 ~을 통해 합집합()	위와 동일

세 번째 열의 차이점은 중요합니다. 주문 상태 절대 나타나지 않음 일일 수익하지만 데이터 입력 방식을 변경하면 보고서의 모든 수치가 바뀝니다. SQLFlow는 이를 모델링합니다. 간접 혈통 (열은 다음과 같이 사용됩니다) 어디, 가입하다, 그리고 그룹화 기준다이어그램에서 별도의 토글 가능한 관계 유형으로 표시하는 것이 좋습니다. 대부분의 계보 도구는 이러한 구분을 전혀 하지 않는데, 이는 정확한 영향 분석을 위해 반드시 필요한 기능입니다.

스택형 뷰를 포함한 MySQL 뷰를 통한 뷰 계보

뷰는 테이블 수준의 계보 도구가 조용히 기능을 포기하는 지점입니다. BI 대시보드에는 다음과 같이 표시됩니다. v_지역_kpis다음 중에서 선택합니다. v_완료된_주문다음 중에서 선택합니다. 명령 그리고 고객"이 대시보드 열에 어떤 데이터가 입력되는가?"라는 질문에 답하려면, 데이터 계보 엔진은 뷰 스택의 모든 계층을 통해 열 참조를 확인하고, 필요한 경우 데이터를 확장해야 합니다. 선택하다 * 기본 정의에 반하여 변환을 진행합니다.

SQLFlow는 의미 분석의 일환으로 뷰, CTE, 서브쿼리 및 스타 확장을 통해 열 참조를 해결합니다. JDBC를 통해 스키마를 지정하면 DDL과 뷰 정의를 직접 가져오므로, 계보 그래프는 오래된 마이그레이션 폴더에 있는 뷰가 아닌 데이터베이스에 실제로 존재하는 뷰를 반영합니다.

생성된 열: 단일 테이블 내의 계보

MySQL에서 생성된 열은 데이터 흐름을 DDL에 직접 포함합니다.

CREATE TABLE order_items ( quantity INT, unit_price DECIMAL(10,2), line_total DECIMAL(12,2) AS (quantity * unit_price) STORED );

라인 합계 해당 열은 어떤 INSERT 문에 의해서도 기록되지 않으므로, DML만 감시하는 접근 방식은 그 출처를 완전히 파악하지 못합니다. SQLFlow는 생성된 열 표현식을 SQL로 파싱하기 때문입니다. 라인 합계 적절한 계보 엣지를 얻습니다. 수량 그리고 단가그리고 그 하류에서 읽는 모든 것 라인 합계 모든 추적은 그 두 개의 물리적 기둥까지 거슬러 올라갑니다.

SQLFlow를 사용하여 MySQL 리니지를 구축하는 방법

1. SQL을 수집하세요. 명령문을 붙여넣거나 파일을 업로드하세요. SQLFlow 클라우드또는 JDBC를 통해 MySQL 인스턴스에 연결하여 SQLFlow가 DDL 및 뷰 정의를 직접 읽도록 할 수 있습니다. dbt 사용자는 dbt 매니페스트를 가져올 수 있습니다.
2. MySQL 방언을 사용하여 구문 분석합니다. SQLFlow는 방언별 MySQL 파서(일반적인 ANSI 문법이 아닌 39개 방언 파서 중 하나)를 사용하므로 MySQL 관련 구문(예: 중복 키 업데이트 시백틱으로 묶인 식별자와 생성된 열은 건너뛰지 않고 올바르게 분석됩니다.
3. 탐색하고 내보내기. 대화형 다이어그램에서 모든 열의 상위 또는 하위 경로를 추적하고, 간접 계보 기능을 켜거나 끌 수 있으며, 그래프를 JSON, CSV 또는 PNG 형식으로 내보내거나 REST API를 통해 프로그래밍 방식으로 가져올 수 있습니다. 버전 8.2.3부터는 "어떤 보고서가 다음에 의존하나요?"와 같은 일반적인 질문도 할 수 있습니다. 고객 지역AI가 인용하는 모든 표와 열은 표시하기 전에 분석된 그래프와 비교하여 유효성을 검사합니다.

아래쪽에 있는 엔진은 일반 SQL 파서, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. Lineage quality is a parsing problem before it is anything else, and that regression corpus is what keeps real-world MySQL — with all its dialect quirks — from silently falling out of the graph.

오픈소스 MySQL 리니지 옵션은 어떤가요?

오픈소스 파서(예: ...) sqllineage 그리고 sqlglot MySQL의 개별 SELECT 및 INSERT 문을 잘 처리하며, Python 파이프라인 내에서 몇 개의 간단한 쿼리에 대한 데이터 계보가 필요한 경우 시작하기에 적합한 플랫폼입니다. DataHub 및 OpenMetadata와 같은 카탈로그 플랫폼은 일단 데이터 계보가 생성되면 이를 구성하고 표시하는 데 탁월합니다. 하지만 대규모 환경에서 하드 SQL 쿼리로부터 정확한 데이터 계보를 생성하는 데에는 한계가 있습니다. 즉, 실시간 스키마 메타데이터를 사용하는 스택형 뷰를 통해 열을 해석하고, 직접 계보와 간접 계보를 구분하며, 데이터 계보를 확장하는 것이 중요합니다. 선택하다 * 수천 개의 스크립트에 걸쳐 정확하게 작업을 수행하는 것이 중요합니다. SQLFlow는 이러한 추출 문제에 집중한 다음 DataHub, Microsoft Purview 및 OpenMetadata용 내보내기 어댑터를 통해 결과를 카탈로그에 제공합니다.

MySQL이 전체 그림의 일부일 뿐일 때

MySQL은 전체 데이터베이스를 구성하는 경우는 드뭅니다. 종종 데이터 웨어하우스를 구축하는 데 사용되는 OLTP 소스이거나, ETL 레이어에서 여러 엔진 중 하나로 사용됩니다. SQLFlow는 동일한 열 수준 분석을 통해 39가지 SQL 방언을 분석하므로 MySQL에서 시작하여 Snowflake, BigQuery 또는 기타 엔진으로 끝나는 데이터 계보를 추적할 수 있습니다. 포스트그레스 SQL 모든 데이터가 하나의 그래프에 저장됩니다. 엔터프라이즈 환경에서는 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 대규모 환경을 일괄 스캔하고, 증분 스캔 및 영구적인 데이터 계보 저장소를 활용합니다. SQL 텍스트가 네트워크 외부로 유출되는 것을 허용할 수 없는 팀에게 적합합니다. 온프레미스 SQLFlow Docker 또는 Kubernetes에서 완전히 격리된 상태로 실행됩니다.

실제 구문(다중 조인 삽입, 뷰 스택, 저장 프로시저 등)에서 출력 결과가 어떻게 나타나는지 확인하려면 다음을 참조하십시오. 데이터 계보 예시.

자주 묻는 질문

MySQL 데이터 계보를 구축하려면 내 데이터에 대한 접근 권한이 필요합니까?

아니요. SQLFlow는 SQL 코드에 대한 정적 분석을 수행하며, 선택적으로 테이블 및 뷰 정의와 같은 스키마 메타데이터도 분석합니다. 하지만 테이블 행 데이터는 절대 읽지 않습니다. 온프레미스 버전을 사용하는 경우 SQL 텍스트조차도 네트워크 내에 유지됩니다.

SQLFlow는 INSERT, SELECT, ON DUPLICATE KEY UPDATE 구문을 통해 추적 계보를 확인할 수 있습니까?

예. MySQL 방언 파서는 전체 문장을 분석합니다. 각 대상 열은 SELECT 문의 소스 열과 연결되며, 집계 함수 내의 표현식도 포함됩니다. 또한 upsert 절은 동일한 데이터 흐름의 일부로 처리됩니다.

information_schema에 계보 정보가 포함되어 있습니까?

아니요. 정보 스키마 테이블, 열, 유형, 키 및 뷰 정의의 원시 텍스트와 같은 구조를 설명합니다. SQL을 해석하지 않으므로 특정 대상 열에 어떤 소스 열이 사용되었는지 알 수 없습니다. 뷰 계보를 확인하려면 뷰와 DML SQL을 구문 분석해야 하며, SQLFlow가 바로 이 작업을 수행합니다.

SQLFlow는 MySQL 뷰에서 SELECT *를 어떻게 처리하나요?

SQLFlow 확장 선택하다 * 실제 스키마(JDBC에서 가져오거나 DDL로 제공됨)를 기준으로 하므로 스타 구조를 통과하는 모든 열은 모호한 테이블 간 화살표 대신 고유한 계보를 갖게 됩니다.

MySQL 데이터 계보를 무료로 체험해 볼 수 있는 방법이 있을까요?

네. SQLFlow Cloud는 무료 티어를 제공합니다. 브라우저에 MySQL SQL을 붙여넣으면 즉시 열 수준 다이어그램을 볼 수 있습니다. 프리미엄은 월 $49.99이며, 온프레미스는 월 $500 또는 선택한 데이터베이스 유형당 1회 $4,800입니다. 자세한 내용은 다음을 참조하세요. 가격.

MySQL 데이터 계보를 데이터 카탈로그로 내보낼 수 있나요?

예. JSON, CSV 또는 PNG 형식으로 내보내거나, REST API를 쿼리하거나, 엔터프라이즈 환경에서 DataHub, Microsoft Purview 및 OpenMetadata용 내장 내보내기 어댑터를 사용할 수 있습니다.