수신자가 공유 테이블로 실제로 수행하는 작업
작성자: Jordan Soldo , Nikhil Tallam
많은 데이터 공유 아키텍처는 익숙한 패턴으로 시작합니다.
이 블로그의 파트 1에서는 공유 테이블이 반복되는 파일이나 API 피드보다 더 나은 대안이 될 수 있는 이유를 설명했습니다. 이제 수신자가 해당 테이블로 실제로 무엇을 하는지 살펴보겠습니다.
이 가이드는 Databricks 간(D2D) 공유에 중점을 둡니다. 수신자는 Unity Catalog가 활성화된 Databricks 워크스페이스를 가지고 있으며 공유 카탈로그를 통해 공유 테이블에 액세스합니다. 제공자는 히스토리와 함께 테이블을 공유하므로 수신자가 이를 Structured Streaming 소스로 사용할 수 있습니다. Databricks-to-Open(D2O) 공유에 대해서는 이 글의 후반부에서 다시 다루겠습니다.
Delta 테이블은 테이블에 이루어진 모든 변경 사항에 대한 정렬된 히스토리를 유지합니다. OpenSharing은 파일을 복사하지 않고 오픈 프로토콜을 통해 해당 테이블을 노출합니다. 데이터는 제공자의 스토리지에 남아 있고, 수신자는 이를 라이브로 읽습니다.
수신자 측에서는 Structured Streaming 리더를 공유 테이블로 지정합니다. Apache Spark는 체크포인트에 읽기 진행 상황을 기록하므로, 각 실행은 마지막 실행 이후에 발생한 변경 사항 만 가져옵니다. "마지막으로 확인한 이후 무엇이 새로워졌는지" 추적하는 작업은 엔진의 몫이 되며, 거버넌스, 계보 및 액세스 제어가 유지된 상태로 거버넌스 데이터 위에서 실행됩니다.
예를 들어, 한 소매업체가 실시간 주문 테이블을 유지 관리하고 이를 Databricks를 실행하는 외부 수신자와 공유한다고 가정해 보겠습니다. 수신자는 매일 밤 CSV를 받는 대신 공유 주문 테이블을 직접 쿼리할 수 있습니다. 분석이나 다운스트림 워크로드를 위해 로컬 복사본이 필요한 경우, 데이터를 Delta 테이블에 증분 방식으로 구체화할 수 있습니다. 설정은 한 번만 수행되며 제공자와 수신자 간에 분할됩니다.
Change Data Feed를 켠 상태로 소스 테이블을 생성한 다음, WITH HISTORY 옵션을 사용하여 공유에 게시합니다. 히스토리는 테이블을 증분 소스로 만드는 요소입니다. 히스토리가 없으면 수신자는 정적 스냅샷만 받게 됩니다. 아래의 주요 증분 읽기에는 Change Data Feed(delta.enableChangeDataFeed) 활성화가 선택 사항입니다. 나중에 업서트 및 삭제 경로를 사용할 계획인 경우에만 켜세요. Databricks Runtime 19 이상을 사용하는 경우 속성을 건너뛰고 자동 Change Data Feed를 사용할 수 있습니다. 이 기능은 행 추적이 활성화된 테이블에 대해 쿼리 시점에 행 수준 변경 사항을 계산하며 Databricks-to-OpenSharing과 함께 작동합니다.
공유 식별자로 수신자를 등록한 다음 공유 권한을 부여합니다.
CREATE SHARE 및 CREATE RECIPIENT에는 워크스페이스 관리자 권한뿐만 아니라 메타스토어 수준의 권한이 필요합니다.
이제 공유가 메타스토어에 제공자로 표시됩니다. 카탈로그로 마운트하면 다른 테이블처럼 읽을 수 있습니다.
공유가 shared_in으로 마운트되면 읽기 작업은 Structured Streaming에서 처리합니다.
Trigger.AvailableNow는 하나 이상의 마이크로 배치(micro-batch)를 사용하여 현재 사용 가능한 모든 처리되지 않은 데이터를 처리한 다음 종료됩니다. 따라서 예약된 증분 작업에 적합합니다. 고정된 일정 대신 공유 테이블에 테이블 업데이트 트리거를 사용하여 작업을 구성할 수도 있으므로, 제공자가 새 데이터를 커밋할 때만 작업이 실행됩니다. 체크포인트는 UC Volumes와 같은 내구성 있는 클라우드 스토리지에 저장하는 것이 좋습니다.
참고: 이 예제는 Delta Sharing을 통해 공유 테이블을 읽으므로 ignoreChanges를 사용합니다. 일반 Delta 테이블에서 직접 스트리밍하는 경우 최신 Databricks 런타임은 추가 전용(append-only) 처리를 위해 skipChangeCommits를 사용합니다.
실제로 증분 방식인지 확인하려면 초기 행 세트를 기준으로 스트림을 한 번 실행하세요. 제공자에 새 행이 생긴 후에 다시 실행합니다. 대상 테이블의 커밋 히스토리에 두 개의 스트리밍 쓰기가 표시됩니다.
Version | Operation | Operation Metrics |
|---|---|---|
2 | STREAMING UPDATE | numRemovedFiles: 0, numOutputRows: 200, numOutputBytes: 2307, numAddedFiles: 1 |
1 | STREAMING UPDATE | numRemovedFiles: 0, numOutputRows: 1000, numOutputBytes: 4958, numAddedFiles: 1 |
0 | CREATE TABLE | {} |
두 번째 실행에서는 1200행이 아니라 200행을 썼습니다. 체크포인트가 마지막으로 읽은 버전을 추적하므로 실행 시 새로운 항목만 가져왔습니다.
ignoreChanges는 이 증분 랜드 패턴에 적합하지만, 행을 다시 내보낼 수 있으며 삭제를 전파하지 않습니다. 다운스트림 소비자에게 삽입, 업데이트 및 삭제가 필요한 경우 대신 공유 테이블의 Change Data Feed를 읽으세요.
새 고객이 추가될 때 제공자는 새로운 SFTP 엔드포인트를 만들거나 새로운 내보내기 작업을 구현할 필요가 없습니다. 제공자는 수신자에게 공유에 대한 액세스 권한을 부여합니다. 수신자는 자체 대상 테이블과 다운스트림 비즈니스 로직을 별도로 유지하면서 동일한 일반 패턴을 사용합니다. 운영상의 차이는 상당합니다.
위의 모든 작업은 수신자가 Databricks에서 Apache Spark를 실행하기 때문에 작동하며, 이것이 체크포인트 스트리밍 및 CDF를 가능하게 하는 요소입니다. pandas, BI 도구, Snowflake 등의 다른 수신자는 메타스토어 공유 ID 대신 자격 증명 파일을 사용하여 OpenSharing을 통해 연결합니다.
OSS Spark를 실행하는 경우 읽기 작업은 delta-sharing 커넥터를 통한 동일한 spark.readStream 코드입니다. Apache Spark가 없으면 연속 스트림이 없으므로 버전 범주별로 변경 사항을 가져옵니다.
유용한 첫 번째 프로젝트가 모든 공유 시나리오를 해결할 필요는 없습니다. 하나의 일반 Delta 테이블과 하나의 수신자로 시작하세요.
스트림을 구현하기 전에 다음 질문에 답하세요.
이러한 질문에 대한 답변이 명확해지면 가능한 가장 작은 엔드투엔드 흐름을 검증하세요. 공유를 만들고, 초기 스냅샷을 읽고, 새 행을 쓰고, 행을 업데이트하고, 행을 삭제한 후 수신자가 예상된 결과를 보는지 확인합니다.
이것이 바로 OpenSharing이 가능하게 하는 실질적인 변화입니다. 모든 고객마다 새로운 전송 및 수집 워크플로를 구축하는 대신, 거버넌스 데이터 공유 계약을 체결하고 각 수신자가 자신의 플랫폼에 맞는 경로를 통해 데이터를 소비하도록 할 수 있습니다.
OpenSharing이 처음이신가요? OpenSharing이란 무엇인가요? 및 OpenSharing용 공유 만들기부터 시작한 다음, 하나의 테이블과 하나의 수신자를 대상으로 위의 최소한의 엔드투엔드 흐름을 설정하세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.