Redshift 데이터 계보: 쿼리 로그를 이용한 자동화된 열 계보 확인

레드시프트 데이터 계보 데이터가 아마존 레드시프트 클러스터를 통해 어떻게 이동하는지 보여주는 열 수준의 맵입니다. 어떤 소스 테이블과 열이 각 대상 테이블, 뷰, 보고서에 데이터를 제공하는지, 그리고 그 과정에서 어떤 변환이 발생하는지를 보여줍니다. 레드시프트 자체는 이러한 맵을 저장하지 않지만, 실행하는 모든 SQL 문을 로그에 기록하고, 레드시프트에서는 모든 변환이 SQL로 표현됩니다. 이러한 로그를 분석하면 전체 데이터 계보를 자동으로 재구성할 수 있습니다. 바로 이것이 레드시프트의 핵심 기능입니다. Gudu SQLFlow 이 도구는 Redshift 쿼리 로그를 기본적으로 수집하고 실행된 SQL을 대화형 열 수준 계보 다이어그램으로 변환합니다.

Redshift에 내장된 계보 보기 기능이 없는 이유는 무엇일까요?

Redshift 콘솔과 시스템 뷰는 클러스터 운영을 위해 설계되었지 데이터 흐름을 이해하기 위한 것은 아닙니다. 쿼리 성능, 큐 동작 및 테이블 통계를 확인할 수는 있지만, Redshift에서는 출력 열을 해당 열을 생성한 소스 열과 연결하는 기능이 없습니다. Redshift가 계승한 PostgreSQL 스타일의 카탈로그 종속성 추적 기능조차도 Redshift 자체 기능 중 하나인 뷰 지연 바인딩(생성됨)에서는 제대로 작동하지 않습니다. 스키마 바인딩 없음) 의도적으로 기본 테이블에 대한 의존성을 기록하지 않습니다.

Redshift가 보관하는 것은 시스템 테이블과 같은 원자재입니다. STL_QUERYTEXT 그리고 SYS_QUERY_HISTORY 실행된 SQL 문의 텍스트를 저장하고, 감사 로깅을 통해 모든 쿼리를 S3에 저장하여 장기간 보존할 수 있습니다. SQL 기록은 모두 저장되어 있습니다. 하지만 수천 개의 SQL 문을 읽고 "어디에서"라는 질문에 대한 답을 찾는 분석 계층이 부족합니다. fact_orders.net_revenue 실제로 어디에서 온 것일까요?” 해당 분석 계층은 SQL 계보 도구입니다.

쿼리 로그에서 Redshift 데이터 계보를 얻는 방법

쿼리 로그 기반 계보는 소스 저장소만 분석하는 것보다 결정적인 장점이 하나 있습니다. 바로 실제로 실행된 내용을 포착한다는 점입니다. 예약된 ETL, 임시 백필, BI 도구 및 오케스트레이터에서 실행된 문, SQL 클라이언트에서 누군가가 실행한 일회성 수정 작업 등 모든 것이 버전 관리 시스템에 저장되어 있는지 여부와 관계없이 쿼리 기록에 남습니다. SQLFlow를 사용한 워크플로는 다음과 같습니다.

1. 실행된 SQL을 수집합니다. Redshift 시스템 테이블 또는 Redshift가 S3에 기록하는 감사 로그에서 쿼리문 텍스트를 가져옵니다. Redshift 쿼리 로그 수집은 붙여넣은 SQL, 업로드된 파일, JDBC를 통한 실시간 메타데이터와 함께 SQLFlow의 기본 입력 방식으로 이루어집니다.
2. Redshift 전용 파서를 사용하여 구문 분석합니다. SQLFlow는 일반적인 ANSI 문법이 아닌 39개의 Redshift 방언별 파서 중 하나를 사용하여 각 문장을 분석하고 CTE, 서브쿼리, 뷰 등을 통해 모든 열 참조를 해결합니다. 선택하다 * 확장.
3. 병합하고 탐색하세요. 모든 문장의 계보가 하나의 그래프로 병합되어 대화형으로 드릴다운하고, 모든 열에서 상위 또는 하위 경로를 추적하고, JSON, CSV 또는 PNG 형식으로 내보내거나 쿼리할 수 있습니다. SQLFlow REST API.

SQLFlow는 SQL 텍스트에 대한 정적 분석이므로 테이블의 행을 읽지 않습니다. 모호한 참조를 해결하기 위해 SQL과 선택적으로 스키마 메타데이터만 필요합니다.

예시: 윈도우 함수를 사용한 INSERT … SELECT

다음은 실제 Redshift 쿼리 로그를 채우는 구문의 예입니다. 윈도우 함수를 사용한 집계 쿼리가 보고 테이블에 데이터를 로드하는 내용입니다.

INSERT INTO analytics.customer_monthly_rank (customer_id, order_month, monthly_revenue, revenue_rank) SELECT o.customer_id, DATE_TRUNC('month', o.order_date) AS order_month, SUM(o.amount) AS monthly_revenue, RANK() OVER ( PARTITION BY DATE_TRUNC('month', o.order_date) ORDER BY SUM(o.amount) DESC ) AS revenue_rank FROM sales.orders o WHERE o.status = 'complete' GROUP BY o.customer_id, DATE_TRUNC('month', o.order_date);

SQLFlow는 이 단일 명령문에서 열 수준의 계보 정보를 두 가지 범주로 추출합니다.

대상 열	직접 출처	간접적 (영향) 원인
고객 ID	주문.고객_ID	주문 상태 (어디)
주문월	주문.주문_날짜 ~을 통해 날짜_트렁크	주문 상태
월별 수익	주문 금액 ~을 통해 합집합	주문 상태, 주문.고객_ID, 주문.주문_날짜 (그룹화 기준)
수익 순위	주문 금액 ~을 통해 합집합 그 다음에 RANK() OVER	주문.주문_날짜 (분할 기준) 주문 상태

두 번째 범주에 주목하세요. 주문 상태 출력 결과에는 전혀 나타나지 않지만, 값을 채우는 방식을 변경하면 대상 테이블의 모든 숫자가 변경됩니다. SQLFlow는 이를 모델링합니다. 간접 혈통 WHERE 절, GROUP BY 절, JOIN 절 및 윈도우 파티션을 통해 작동하는 열을 별도의 토글 가능한 관계 유형으로 구분합니다. 대부분의 계보 도구는 이러한 구분을 하지 않는데, 이는 "어떤 보고서가 이 열을 읽는지"와 "어떤 보고서가 이 열의 영향을 받는지"를 명확히 구분하는 차이점입니다.

Redshift 관련 구문은 여전히 SQL일 뿐입니다.

후기 결합 관점

지연 바인딩 뷰는 뷰를 기본 테이블에서 분리하기 위한 Redshift의 표준 패턴이며, 설계상 카탈로그 기반 종속성 쿼리에는 보이지 않습니다. 하지만 SQL 파서에게 지연 바인딩 뷰는 단순히 뷰 정의일 뿐입니다. SQLFlow는 뷰의 SELECT 문을 파싱하고 다른 뷰와 마찬가지로 출력 열을 소스에 연결하므로, 계보가 바로 이어집니다. 스키마 바인딩 없음.

디스트키, 정렬키, 디스트스타일

데이터 흐름이 아니라 분포 키와 정렬 키가 성능에 영향을 미칩니다. 다음과 같이 선언된 테이블은 성능에 영향을 미칩니다. DISTKEY(customer_id) SORTKEY(order_date) 다른 테이블과 마찬가지로 동일한 계보를 유지합니다. SQLFlow는 Redshift DDL을 구문 분석하고 테이블과 해당 열을 기록하며, 물리적 튜닝 절은 그래프에 영향을 주지 않고 그대로 전달됩니다. 테이블이 변경되더라도 계보는 정확하게 유지됩니다. 디스트스타일 올, 심지어, 또는 열쇠.

Redshift는 PostgreSQL이 아닙니다.

Redshift는 PostgreSQL에서 파생되었지만 구문과 동작 방식에서 상당한 차이를 보입니다. 따라서 SQLFlow는 자체 파서를 재사용하는 대신 Redshift 전용 파서를 제공합니다. 포스트그레스SQL 계보 parser — each of the 39 supported dialects gets its own grammar, validated against a corpus of roughly 13,600 per-dialect SQL test fixtures built up over two decades of commercial parser development.

Redshift SQL을 SQLFlow에 입력하는 방법

입력	그것이 당신에게 주는 것
Redshift 쿼리 로그	실행된 모든 진술의 계보 — 완전하고 정확한 진실의 그림
JDBC를 통한 실시간 메타데이터	클러스터에서 직접 가져온 DDL 및 뷰 정의
업로드된 SQL 파일	ETL 스크립트와 저장소를 일괄 분석합니다.
붙여넣은 SQL	브라우저에서 단일 문장에 대한 즉각적인 계보 추적
dbt 매니페스트	Redshift에서 빌드되는 dbt 모델 전반에 걸친 열 수준 계보

SQLFlow는 엔터프라이즈 규모에서 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 환경을 일괄 스캔하고, 증분 스캔을 실행하며, 영구적인 계보 저장소를 유지하고, DataHub, Microsoft Purview 및 OpenMetadata로 내보냅니다. 따라서 Redshift 계보 데이터가 별도의 사일로에 저장되는 대신 기존에 운영 중인 카탈로그에 바로 통합될 수 있습니다.

이 방법은 다른 접근 방식과 비교했을 때 어떤 차이가 있습니까?

오픈소스 파서(예: ...) sqllineage 그리고 sqlglot 개별적이고 잘 구성된 문장에서 계보를 추출하는 데는 효과적이며, 몇 개의 깔끔한 쿼리에는 충분할 수 있습니다. 하지만 프로덕션 Redshift 로그에서는 문제가 발생합니다. 수천 개의 문장, Redshift 고유의 구문, 뷰 위에 또 다른 뷰가 겹겹이 쌓여 있기 때문입니다. 선택하다 * 확장을 위해서는 스키마 메타데이터가 필요하고, 필터와 윈도우 파티션을 통해 간접적인 계보 추적이 필요합니다. 카탈로그 우선 플랫폼은 여러 시스템에 걸쳐 메타데이터를 구성하고 관리하는 데 강점을 보이지만, 심층적인 SQL 분석을 위해서는 일반적으로 특수 계보 엔진이 필요합니다. 이것이 바로 SQLFlow가 DataHub, Purview, OpenMetadata와 경쟁하는 대신 이러한 플랫폼용 내보내기 어댑터를 제공하는 이유입니다.

Redshift를 다른 데이터 웨어하우스와 함께 실행하는 경우, 동일한 엔진이 동일한 접근 방식으로 모든 웨어하우스를 관리합니다. 자세한 내용은 다음을 참조하세요. 스노우플레이크 데이터 계보 쿼리 기록에서 가져오는데, 이는 Redshift의 로그 기반 수집과 매우 유사하게 작동합니다. 그리고 규제 환경의 경우, 온프레미스 SQLFlow Docker 또는 Kubernetes 환경에서 네트워크 내에서 실행되므로 SQL 쿼리 결과는 인프라 외부로 유출되지 않습니다.

자주 묻는 질문

SQLFlow가 Redshift 클러스터의 데이터를 읽을 수 있나요?

아니요. SQLFlow는 SQL 코드에 대한 정적 분석을 수행하고 선택적으로 스키마 메타데이터(테이블 및 열 정의)를 읽습니다. 테이블 행은 절대 읽지 않습니다. 온프레미스 에디션의 경우 SQL 텍스트조차도 네트워크 내에 유지됩니다.

Redshift SQL은 어디에서 오는 건가요?

실행된 쿼리문이 저장된 위치(Redshift의 쿼리 기록 시스템 테이블, S3에 보관된 감사 로그, ETL 스크립트 저장소, JDBC를 통해 실시간으로 가져온 DDL 및 뷰 정의 등)에서 로그를 가져올 수 있습니다. Redshift 쿼리 로그 수집은 SQLFlow의 기본 입력 방식이므로, 클러스터에서 실제로 실행된 내용을 반영하는 계보를 제공합니다.

후기 결합 관점은 계통 분석에 문제가 될까요?

이러한 뷰는 Redshift가 설계상 해당 뷰에 대한 종속성을 기록하지 않기 때문에 카탈로그 기반 종속성 추적을 무력화합니다. 하지만 파서 기반 계보 추적에는 문제가 되지 않습니다. SQLFlow는 뷰의 SQL 정의를 직접 분석하고 다른 뷰와 마찬가지로 열을 소스에 연결합니다.

SQLFlow는 필터를 통해서만 결과에 영향을 미치는 열을 보여주나요?

예. SQLFlow는 직접 계보(실제로 출력 열로 흐르는 데이터)와 간접 계보(WHERE, JOIN, GROUP BY 및 윈도우 파티션 절을 통해 작용하는 열)를 구분하며, 다이어그램에서 각각을 독립적으로 전환할 수 있도록 합니다.

SQLFlow 가격은 얼마인가요?

SQLFlow Cloud는 무료로 시작하며, 프리미엄 계정은 월 $49.99입니다. SQLFlow On-Premise는 선택한 데이터베이스 유형당 월 $500 또는 일회성 $4,800이며, 두 대의 서버에 설치할 수 있습니다. 추가 데이터베이스 유형당 월 $100 또는 일회성 $1,000이 추가됩니다.