Trino 및 Presto 데이터 계보: 연합 SQL 전반에 걸친 열 계보

트리노 데이터 계보 이는 Trino(및 Presto) SQL을 통해 데이터가 흐르는 방식을 열 수준에서 보여주는 맵입니다. 즉, 어떤 소스 열에서 어떤 카탈로그가 각 출력 열에 데이터를 제공하는지, 그리고 어떤 조인, 함수 및 필터를 거치는지 나타냅니다. Trino는 연합 쿼리 엔진이므로 단일 문으로 여러 소스 열에서 데이터를 읽을 수 있습니다. 벌집, 포스트그레스큐엘, 그리고 빙산 카탈로그를 한 번에 모두 조회해야 하므로 정확한 계보를 파악하려면 모든 열을 완전한 자격을 갖춘 값으로 변환해야 합니다. 카탈로그.스키마.테이블.컬럼 단순히 테이블 이름이 아니라, 고유한 식별자입니다. Gudu SQLFlow Trino와 Presto 각각에 대해 전용 방언 구문 분석기를 사용하여 이를 수행합니다.

연방 체제가 Trino 데이터 계보 추적을 더 어렵게 만드는 이유는 무엇일까요?

기존 데이터 웨어하우스에서는 데이터 계보가 하나의 데이터베이스 내에 존재합니다. 쿼리에 사용되는 모든 테이블은 동일한 시스템에 속하며, 두 부분으로 된 이름(예: )을 사용합니다. 판매 주문 이는 모호하지 않습니다. 하지만 Trino는 이러한 가정을 깨뜨립니다. Trino의 핵심 목적은 데이터를 결합하는 것입니다. 가로질러 시스템 내에서 S3의 Hive 테이블, PostgreSQL 운영 데이터베이스, Iceberg 레이크하우스 테이블 등이 모두 동일한 환경에 존재할 수 있습니다. 선택하다.

이로 인해 대부분의 계보 도구가 제대로 처리하지 못하는 세 가지 문제가 발생합니다.

• 카탈로그 간 이름 충돌. 하이브.판매.주문 그리고 포스트그레스SQL.판매.주문 서로 다른 시스템에 있는 서로 다른 물리적 테이블입니다. 카탈로그 한정자를 제거하는 계보 추적 기능은 이들을 하나의 노드로 병합하며, 이를 기반으로 구축된 모든 하위 영향 분석은 잘못된 결과를 초래합니다.
• 부분 자격. 실제 쿼리에서는 세 부분으로 된 이름을 모든 곳에 명시적으로 나타내는 경우는 드뭅니다. 쿼리는 세션의 기본 카탈로그 및 스키마, 별칭 등을 활용합니다. 사용 문장들입니다. 리졸버는 해당 컨텍스트에서 모든 열 참조의 전체 ID를 재구성해야 합니다.
• 시스템 간 경계를 하나의 문장으로 표현합니다. 안 빙산에 삽입... Hive와 PostgreSQL에서 선택하는 것은 데이터 이동입니다. 세 가지 시스템 사이 하나의 문장으로 표현됩니다. 테이블 수준 계보는 어떤 시스템을 거쳤는지 알려주지만, 컬럼 수준 계보만이 어떤 PostgreSQL 컬럼이 Iceberg의 어떤 컬럼에 포함되었는지 알려줍니다.

SQLFlow의 시맨틱 리졸버는 전체 내용을 유지합니다. 카탈로그.스키마.테이블.컬럼 계보 그래프의 모든 노드에 경로가 있으므로 카탈로그 간 열이 명확하게 구분되고 처음부터 끝까지 추적 가능합니다.

예시: Iceberg 타겟, Hive 및 PostgreSQL 소스

다음은 일반적인 연합 쓰기 예시입니다. 운영 중인 PostgreSQL 데이터베이스와 Hive 주문 내역을 조인하여 Iceberg 카탈로그에 고객-값 테이블을 구축하는 작업입니다.

INSERT INTO iceberg.analytics.customer_value SELECT c.customer_id, lower(c.email) AS email, sum(o.order_total) AS lifetime_value, count(*) AS order_count FROM postgresql.crm.customers AS c JOIN hive.sales.orders AS o ON c.customer_id = o.customer_id WHERE o.order_status = 'COMPLETED' GROUP BY c.customer_id, lower(c.email);

Trino 방언을 선택하여 SQLFlow를 실행하면 출력 열별로 다이어그램이 표시됩니다.

대상 열(iceberg.analytics.customer_value)	원본 열	관계
고객 ID	postgresql.crm.customers.customer_id	직접, 통과
이메일	postgresql.crm.customers.email	직접, ~을 통해 낮추다()
수명 값	hive.sales.orders.order_total	직접, ~을 통해 합집합()
주문 수	하이브.판매.주문 행	직접, ~을 통해 세다(*)
모든 열	hive.sales.orders.order_status	간접 (WHERE 필터)
모든 열	o.customer_id / c.customer_id	간접 검색(JOIN 조건, GROUP BY)

마지막 두 줄을 주목하세요. 주문 상태 출력 결과에는 전혀 나타나지 않지만, 입력 방식을 변경하면 모든 숫자가 바뀝니다. 고객 가치SQLFlow는 이를 다음과 같이 모델링합니다. 간접적 (영향) 계보직접 데이터 흐름과 함께 별도로 전환 가능한 관계 유형을 제공합니다. 대부분의 계보 도구는 이러한 구분을 하지 않는데, 이는 공유 Hive 테이블의 필터 열을 건드리기 전에 반드시 알아야 할 정보입니다.

Trino와 Presto는 서로 다른 방언입니다. SQLFlow는 둘 다 파싱합니다.

Trino는 Presto(PrestoSQL)에서 분기되어 2020년에 이름이 변경되었으며, 그 이후로 두 방언은 서로 다른 방향으로 발전해 왔습니다. SQLFlow는 이러한 발전을 지원합니다. Trino와 Presto 각각에 대해 방언별 별도 구문 분석기PrestoDB는 39개의 방언을 지원하며, 호환성 플래그가 있는 일반적인 ANSI 문법은 하나도 지원하지 않습니다. 최신 Trino 클러스터와 함께 PrestoDB를 운영하는 경우, 소스별로 일치하는 방언을 선택하면 두 방언 모두 올바르게 파싱됩니다.

이 파서는 2000년대 중반부터 개발되어 약 13,600개의 방언별 테스트 픽스처를 통해 검증된 상용 SQL 컴파일러 프런트엔드인 GSP(General SQL Parser)에서 가져온 것입니다. GSP는 CTE, 서브쿼리, 뷰 등을 통해 열 참조를 해결하여 각 문장의 완전한 의미 모델을 구축합니다. 선택하다 * 별의 팽창은 데이터 흐름 분석기를 통해 원천과 대상 간의 관계를 추출하는 중요한 요소입니다. 별의 팽창은 트리노에서 다른 어떤 곳보다 더 중요하게 작용합니다. 선택하다 * 연합 조인을 통해 여러 시스템의 열을 가져오는데, 이를 올바르게 확장하려면 각 카탈로그의 스키마 메타데이터가 필요하며, SQLFlow는 SQL과 함께 이러한 메타데이터를 수집할 수 있습니다.

SQLFlow를 사용하여 Trino 계보를 생성하는 방법

1. SQL을 수집하세요. 개별 쿼리를 붙여넣거나, ETL 스크립트 및 뷰 정의 파일을 업로드하거나, JDBC를 통해 메타데이터를 가져올 수 있습니다. 전체 환경을 관리하려면 Grabit/SQLFlow-ingester 이 유틸리티는 메타데이터를 일괄적으로 추출합니다.
2. 방언을 선택하세요. 소스별로 Trino 또는 Presto를 사용합니다. 동일한 파이프라인에 Hive DDL 또는 Spark SQL 작업이 포함된 경우 각각을 별도의 방언으로 분석합니다. SQLFlow는 모든 방언을 지원하며, 엔터프라이즈 배포 환경에서는 결과를 영구적인 계보 저장소에 저장합니다.
3. 탐색하고 내보내기. 대화형 다이어그램에서 모든 열의 상위 또는 하위 경로를 추적하고, 간접 계보 기능을 켜거나 끌 수 있으며, JSON, CSV 또는 PNG 형식으로 내보내거나 REST API를 통해 그래프를 쿼리할 수 있습니다. 버전 8.2.3부터는 "어떤 Iceberg 테이블이 다음에 의존하나요?"와 같은 일반적인 질문도 할 수 있습니다. postgresql.crm.customers.emailAI 답변의 모든 표와 열은 표시하기 전에 분석된 그래프와 비교하여 유효성을 검사합니다.

SQLFlow는 엔터프라이즈 규모에서 100개 이상의 데이터베이스와 백만 개 이상의 열을 포함하는 환경을 일괄 스캔하고, 증분 스캔을 실행하며, 영구적인 계보 저장소를 유지하고, DataHub, Microsoft Purview 및 OpenMetadata로 내보냅니다. 따라서 Trino 계보는 팀에서 이미 사용하고 있는 카탈로그에 저장됩니다.

정적 SQL 분석과 런타임 이벤트 계보 분석 비교

Trino의 계보를 얻는 또 다른 일반적인 방법은 런타임 캡처입니다. 엔진의 쿼리 이벤트를 후킹하여 실행된 각 문장에 대한 계보를 출력하는 방식입니다(OpenLineage 생태계가 이러한 방식으로 작동합니다). 런타임 캡처는 실제 세션 컨텍스트와 함께 실제로 실행된 내용을 기록하는 데 매우 효과적입니다. 하지만 범위와 깊이 면에서 한계가 있습니다. 캡처 기간 동안 실행된 쿼리만 확인할 수 있으며, 모든 클러스터에 계측을 설치해야 합니다.

SQLFlow의 접근 방식인 정적 분석은 SQL 코드 자체를 구문 분석합니다. 여기에는 아직 실행되지 않은 예약된 작업, 뷰 정의 및 검토 중인 리포지토리 코드가 포함되며 클러스터에 에이전트가 필요하지 않고 테이블 행 데이터를 읽지 않습니다. 규제 환경에서는 온프레미스 에디션 (Docker/Kubernetes)는 SQL 텍스트까지 네트워크 내부에 보관합니다. 많은 팀에서 런타임 이벤트를 운영 모니터링에 사용하고, 정적 분석을 통해 배포 전 영향 분석을 완벽하게 수행합니다.

스택의 나머지 부분에 걸친 계보

Trino만으로는 전체 상황을 파악하기 어렵습니다. Trino가 쿼리하는 Hive 테이블은 대개 Hive 또는 Spark 작업에 의해 로드되며, 결과는 종종 하위 마트에 전달됩니다. SQLFlow는 동일한 엔진을 사용하여 이러한 계층을 분석합니다. 자세한 내용은 관련 가이드를 참조하세요. 하이브 데이터 계보 그리고 클릭하우스 데이터 계보또는 전체 SQL 데이터 계보 도구 개요 39개 방언을 모두 포함합니다. 모든 계층이 영구적인 계보 저장소에 분석되므로 Hive 테이블을 작성한 Spark 작업부터 연합 Trino 쿼리를 거쳐 Iceberg 대상에 이르기까지 열을 추적할 수 있습니다.

자주 묻는 질문

SQLFlow는 Trino와 Presto를 모두 지원합니까?

네. Trino와 Presto는 SQLFlow의 39개 방언별 파서 중 두 가지입니다. 사용하는 엔진에 맞는 방언을 선택하세요. 두 파서를 모두 실행하는 경우 각 소스를 해당 방언으로 분석해야 합니다.

SQLFlow는 Trino 카탈로그 전체에서 계보를 추적할 수 있습니까?

예. SQLFlow는 모든 열을 완전한 카탈로그.스키마.테이블.열 식별자로 변환하므로 Hive, PostgreSQL 및 Iceberg 카탈로그를 조인하는 쿼리는 각 시스템의 열을 구분된 상태로 유지하는 데이터 계보를 생성합니다. 이는 카탈로그 간에 데이터를 이동하는 INSERT 문에도 적용됩니다.

SQLFlow는 Trino 클러스터 또는 데이터에 대한 접근 권한이 필요한가요?

아니요. SQLFlow는 SQL 코드에 대한 정적 분석을 수행하며, 선택적으로 스키마 메타데이터를 사용하여 이름을 확인하고 SELECT *를 확장합니다. 테이블 행을 읽지 않으며 클러스터에 에이전트가 필요하지 않습니다. 온프레미스 버전은 SQL 텍스트를 네트워크 내부에 완전히 보관합니다.

SQLFlow에서 WHERE 절과 JOIN 절의 열에 대해 어떤 결과가 표시되나요?

이러한 요소들은 간접적(영향) 계보로 나타납니다. 즉, 출력에는 직접 나타나지 않지만 결과에 영향을 미치는 열들에 대한 별도의 관계 유형입니다. 다이어그램에서 간접 계보를 켜거나 끌 수 있는데, 대부분의 계보 도구는 이러한 구분을 전혀 하지 않습니다.

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

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

SQLFlow 가격은 얼마인가요?

SQLFlow Cloud는 무료로 시작하며, 프리미엄 버전은 월 $49.99입니다. SQLFlow On-Premise는 선택한 데이터베이스 유형별로 월 $500 또는 일회성 결제 시 $4,800이며, 두 대의 서버에 설치할 수 있습니다. 자세한 내용은 다음을 참조하세요. 가격 자세한 내용은 다음을 참조하세요.