크로스 워크스페이스 배포에서 의존성 바인딩을 이해하기

Fabric 항목을 작업 공간 전반(예: 개발, 테스트, 운영 단계)에 배포할 때, 항목 간 의존성이 깨질 수 있습니다. 일부 항목은 의존성에 대한 참조를 객체 ID (작업 공간별 GUID)로 저장하는 반면, 다른 항목은 논리 ID (파일에 저장된 .platform 교차 작업 공간 휴대용 식별자)를 사용합니다.

정의에서 논리 ID를 사용하는 항목은 대상 작업 공간 내 해당 항목에 올바르게 바인딩됩니다. 객체 ID를 사용하는 항목은 여전히 소스 작업 공간을 가리키고 있어 배포가 중단됩니다.

이 글에서는 Git 통합을 사용할 때 논리 ID를 통해 의존성 바인딩을 지원하는 Fabric 항목 유형과 그렇지 않은 항목 유형을 설명합니다. 논리 ID와 소스 컨트롤에서 아이템이 어떻게 표현되는지에 대해 더 알고 싶다면 Fabric의 논리 ID를 참조하세요.

주요 개념

  • 논리적 ID: .platform 파일에서 자동으로 생성되는 워크스페이스 간 식별자입니다. 동일한 논리 ID를 가진 항목은 작업 공간 간에 동일한 항목으로 취급됩니다.
  • 객체 ID: 특정 인스턴스를 식별하는 작업 공간별 GUID. 객체 ID는 수동 개입이나 매개변수화 없이는 교차 작업 공간 배포를 견디기 어렵습니다.
  • 의존성 바인딩(Git): Git 브랜치를 새 작업 공간에 동기화하면, Fabric은 논리 ID를 사용해 의존성 참조를 해결하여 대상 작업 공간 내 올바른 항목을 자동으로 가리킵니다.
  • 이름별 또는 URI별로: 일부 항목은 ID 대신 디스플레이 이름이나 URI로 의존성을 참조합니다. 이 참조들은 작업 공간 간 명명 규칙에 따라 올바르게 해결될 수도 있고 아닐 수도 있습니다.

의존성 결속의 작동 원리

작업 공간 내에서 아이템들은 객체 ID를 사용하여 의존성을 참조합니다. Fabric이 아이템을 Git으로 내보낼 때, 일부 객체 ID를 파일 내 .platform 논리 ID로 대체합니다. Git 브랜치를 다른 작업 공간에 동기화하면, Fabric이 해당 논리 ID를 대상 작업 공간의 올바른 객체 ID로 다시 해석합니다. 이것이 의존성 결속이 작동하는 이유입니다.

하지만 내보내기 시 모든 의존성 참조가 논리 ID로 대체되는 것은 아닙니다. 객체 ID를 Git 표현으로 유지하는 항목들은 동기화 후에도 여전히 원래 작업 공간을 가리키며, 수동으로 또는 파라미터화를 통해 업데이트해야 합니다.

Important

의존성 바인딩은 동일한 작업 공간 내 Fabric 항목 간의 참조에만 적용됩니다. 만약 아이템이 다른 작업 공간의 Fabric 아이템을 참조한다면, 그 참조는 객체 ID를 사용하고 자동으로 바인딩되지 않습니다. Connections(데이터 소스 연결, 게이트웨이)에 대한 참조도 자동 바인딩되지 않습니다. 환경 간 연결 참조를 관리하기 위해 환경별 값 집합을 가진 변수 라이브러리 를 사용하세요.

의존성 바인딩 호환성

다음 표는 각 Fabric 항목 유형의 의존성이 작업 공간 간 배포 시 올바르게 결합되는지 보여줍니다. 현재 이 글은 Git 통합 동작에 대해 다룹니다. 바인딩은 각 항목이 정의에서 의존성 참조를 어떻게 저장하는지에 따라 결정되기 때문에, 배포 파이프라인이나 가져오기(대량) API 등 해당 정의를 재사용하는 다른 배포 메커니즘에도 동일한 동작이 적용됩니다.

이 테이블들은 의존성이 소스 항목과 같은 작업 공간 내 다른 항목이라고 가정합니다. 다른 작업 공간에 있는 아이템에 대한 참조는 절대 자동 결속되지 않습니다. 테이블에 표시된 값과 상관없이 원본 객체 ID에 고정되어 있습니다.

Git 열에서 자동 바인딩은 다음을 나타냅니다:

  • 네: Git의 항목 정의는 의존성 참조를 논리적 ID로 저장합니다. 브랜치를 새 작업 공간에 동기화하면, 참조가 자동으로 해당 작업 공간 내 일치하는 항목에 바인딩됩니다.
  • 아니요: Git의 항목 정의는 의존성 참조를 객체 ID(작업 공간별 GUID)로 저장합니다. 참조는 동기화 후에도 계속 소스 작업 공간을 가리킵니다. 크로스 워크스페이스 배포를 위해 수동으로 업데이트하거나 매개변수화해야 합니다.
  • 부분: 항목은 이름이나 URI로 종속성을 확인하며, 작업 공간 전반에서 명명 방식이 일관된 경우 작동할 수 있습니다.

Notebooks

종속성 Git에서의 자동 바인딩 Notes
Lakehouse Yes 노트북 설정에서 "Lakehouse Auto-Binding in Git"을 활성화해야 합니다. 활성화되면 객체 ID가 논리 ID notebook-settings.json로 대체됩니다. 이 설정은 기본적으로 해제되어 있습니다. 자세한 내용은 Git의 Lakehouse 자동 바인딩을 참조하세요.
Environment Yes
미러된 데이터베이스 No

비고

Notebook에서 Lakehouse 바인딩은 기본적으로 활성화되어 있지 않습니다. 각 노트북의 설정에서 "Git의 Lakehouse 자동 바인딩" 설정을 켜야 합니다. 자세한 내용은 Notebook 소스 제어 및 배포를 참조하세요.

Reports

종속성 Git에서의 자동 바인딩 Notes
의미 모델 (Power BI 보고서에서) Partial 보고서는 명시적 논리 ID가 아닌 상대 byPath 참조 definition.pbir를 통해 모델을 참조합니다. 모델이 대상 작업 공간 내 동일한 상대 위치로 배포되면 올바르게 해결되지만, 논리 ID를 통해 바인딩되지는 않습니다. 자세한 내용은 Power BI Desktop 프로젝트 보고서 폴더를 참조하세요.
시맨틱 모델(페이지를 매긴 보고서에서) No 보고서의 연결 문자열은 배포 시 다시 작성되지 않는 작업 공간별 ID로 의미 모델을 참조하여 소스 모델을 가리킵니다. 크로스 워크스페이스 배포를 위해 이 참조를 업데이트해야 합니다. (Report Builder에서 모델을 이름으로 참조하는 보고서는 대신 표시 이름인 Partial로 확인될 수 있습니다.)

Pipeline

종속성 Git에서의 자동 바인딩 Notes
Pipeline Yes
Notebook Yes
데이터 흐름 Gen2 Yes
SQL Database Yes
Spark 작업 정의 No SparkJobDefinition 활동은 논리 ID가 아닌 객체 ID로 Spark Job Definition을 참조하므로, 배포 후에도 소스 항목을 가리킵니다. 이 값을 크로스 워크스페이스 배포를 위해 매개변수화해야 합니다.
Lakehouse Yes
의미 체계 모델 No PBISemanticModelRefresh 활동은 논리 ID가 아닌 항목 ID로 의미 모델을 참조합니다. 이 값을 크로스 워크스페이스 배포를 위해 매개변수화해야 합니다.
창고 No 웨어하우스 artifactId 는 논리 ID를 통해 해결하고 리바인딩하지만, linkedService 소스 작업 공간의 SQL endpoint(재작성되지 않음)도 저장합니다. 작업 영역 간 배포를 위해 endpoint를 매개 변수화하세요.

의미론적 모델

종속성 Git에서의 자동 바인딩 Notes
의미 체계 모델 Partial 체인 또는 복합 모델 참조는 이름별로 연결 문자열을 사용합니다.
SQL 분석 엔드포인트(레이크하우스) No TMDL expressions.tmdl 의 Direct Lake 연결 문자열에는 작업 공간별 엔드포인트 URL과 데이터베이스 GUID가 포함되어 있습니다. 크로스 워크스페이스 배포를 위해서는 이 매개변수들을 교체해야 합니다.
KQL 데이터베이스 No TMDL 표현식에서 클러스터 URI가 포함된 연결 문자열은 작업 공간별 값을 포함합니다.
SQL database No TMDL 표현식의 연결 문자열은 작업 공간별 값을 포함합니다.
창고 No 웨어하우스 SQL 분석 엔드포인트와의 연결은 작업 공간별 URL을 사용합니다.

레이크하우스

종속성 Git에서의 자동 바인딩 Notes
레이크하우스 (지름길) Yes 다른 Fabric 항목(예: 레이크하우스 또는 웨어하우스)을 가리키는 내부 OneLake 바로 가기는 논리 ID로 저장되며 대상 작업 영역 항목에 다시 바인딩됩니다. Azure Data Lake Storage Gen2나 Amazon S3와 같은 외부 소스로 가는 단축키는 Fabric 외부를 가리키며 연결 참조를 포함하므로 논리 ID 바인딩의 대상이 되지 않습니다. 단축키 목표 전체 목록은 OneLake 단축키를 참조하세요. 배포 동작에 대해서는 Lakehouse Git 통합 및 배포 파이프라인을 참조하세요.

Dataflows (Gen2)

기본적으로 Dataflow Gen2는 Fabric 항목에 대한 절대 참조를 생성합니다: 쿼리는 소스 작업 공간 ID와 아이템의 객체 ID를 저장하며, 배포 시 이 두 가지는 다시 작성되지 않습니다. source 참조는 대신 relative reference를 사용할 수 있습니다. Fabric 커넥터에서 !(Current Workspace) 노드 아래의 항목을 선택하면 쿼리는 해당 항목을 이름으로 저장하고(GUID 없음), 배포 시 대상 작업 영역의 일치하는 항목으로 해석됩니다. 출력 목적지 는 항상 절대 참조를 사용하고 리바인딩하지 않습니다. 목적지와 절대 소스 참조에 대해, 크로스 워크스페이스 배포를 위해 값을 매개변수화하세요. 자세한 내용은 Dataflow Gen2의 Fabric 커넥터와 CI/CD 및 Git 통합이 포함된 Dataflow Gen2의 관련 참조를 참조하세요.

출처:

종속성 Git에서의 자동 바인딩 Notes
Lakehouse Partial 상대 참조(!(Current Workspace))로 작성된 경우에만 다시 바인딩되며, 기본 절대 참조는 재바인딩되지 않습니다.
창고 Partial 상대 참조(!(Current Workspace))로 작성된 경우에만 다시 바인딩되며, 기본 절대 참조는 재바인딩되지 않습니다.

목적지 참고:

종속성 Git에서의 자동 바인딩 Notes
Lakehouse No
창고 No
SQL Database No

Spark 작업 정의

종속성 Git에서의 자동 바인딩 Notes
Environment Yes
Lakehouse No 객체 defaultLakehouseArtifactId ID를 사용합니다.

복사 작업

종속성 Git에서의 자동 바인딩 Notes
Lakehouse Yes
창고 No 웨어하우스 artifactId 는 논리 ID를 통해 해결하고 리바인딩하지만, linkedService 소스 작업 공간의 SQL endPoint(재작성되지 않음)도 저장합니다. 작업 영역 간 배포를 위해 endPoint를 매개 변수화하세요.
SQL Database Yes

GraphQL API들

종속성 Git에서의 자동 바인딩 Notes
SQL 엔드포인트 Yes
창고 Yes
SQL Database Yes

모든 GraphQL API 데이터 소스에 대해, 배포 후 연결과 자격 증명을 재구성해야 할 수도 있습니다.

이벤트스트림

종속성 Git에서의 자동 바인딩 Notes
Lakehouse Yes
Eventhouse Yes 항목이 동일한 작업 공간에 있을 때 모든 목적지는 CI/CD에 완전히 지원됩니다. Eventhouse의 Direct Inestion 모드는 배포 후 연결을 수동으로 재설정해야 할 수도 있습니다. 자세한 내용은 Eventstream CI/CD를 참조하세요.
액티베이터(Reflex) Yes 항목이 동일한 작업 공간에 있을 때 모든 목적지는 CI/CD에 완전히 지원됩니다. 자세한 내용은 Eventstream CI/CD를 참조하세요.

KQL 항목

종속성 Git에서의 자동 바인딩 Notes
KQL 데이터베이스에서 이벤트하우스로 Yes in parentEventhouseItemId 은 DatabaseProperties.json 논리적 ID이며 대상 이벤트하우스에 결합됩니다. KQL 데이터베이스는 모 이벤트하우스의 자식 데이터베이스로 배포됩니다.
KQL 쿼리셋에서 KQL 데이터베이스로 Partial 항목 ID가 아니라 clusterUri 및 databaseName를 통해 확인됩니다. 정의에는 가 포함되어 databaseItemId있지만, 객체 ID는 재결속되지 않으므로 해상도는 환경 간 URI에 따라 달라집니다.
실시간 대시보드에서 KQL 데이터베이스로 Partial 클러스터 URI가 있는 배열을 사용합니다 dataSources . KQL 쿼리셋과 같은 패턴입니다.

창고

종속성 Git에서의 자동 바인딩 Notes
창고 (상호 참조) No 다른 웨어하우스에 대한 참조는 객체 ID를 사용합니다.
SQL 엔드포인트 No SQL 엔드포인트 참조는 작업 공간별 식별자를 사용합니다.

변수 라이브러리

종속성 Git에서의 자동 바인딩 Notes
Fabric 항목(ItemReference 유형) No ItemReference 변수 형식은 workspaceId 및 itemId를 원시 GUID 형식으로 저장합니다. 이 값들은 환경별로 값 세트를 통해 수동으로 업데이트하거나 덮어써야 합니다.

의존성이 없는 항목들

다음 항목들은 작업 공간 간 의존성 결합 문제가 없습니다:

  • Environment
  • SQL Database
  • 이벤트하우스 (컨테이너 아이템; KQL 데이터베이스에서도 이를 참조합니다)
  • 미러드 데이터베이스 (외부 소스 구성만)

요약

Fabric 항목을 여러 작업 공간에 걸쳐 배포할 때 참조가 이식 가능한 논리적 ID 대신 작업 공간별 객체 ID로 저장되면 항목 간 종속성이 깨질 수 있습니다. 모든 항목 유형이 논리 ID를 통한 의존성 바인딩을 지원하는 것은 아닙니다. 크로스 워크스페이스 배포를 설정하기 전에 이 글의 호환성 표를 검토하여 어떤 의존성이 자동으로 바인딩되는지, 어떤 것이 수동 매개변수화가 필요한지 확인하세요.

관련 콘텐츠

  • Last updated on