Snowflake의 Microsoft Fabric 미러된 데이터베이스의 현재 제한 사항이 이 페이지에 나열되어 있습니다. 이 페이지는 변경될 수 있습니다.
연결 및 인증 제한 사항
- 다음 표에서는 Snowflake에 대한 미러링에 지원되는 인증 방법을 나열합니다.
| 인증 방법 | 지원됨 | 비고 |
|---|---|---|
| 사용자 이름 및 암호 | Yes | Snowflake 네이티브 인증 |
| Microsoft Entra ID(SSO) | Yes | Entra ID를 통한 Single Sign-On |
| 키 쌍 인증 | Yes | 서비스 계정 시나리오에 대한 RSA 키 쌍 |
| 작업 영역 ID | 아니오 | 현재 Snowflake에 대해 지원되지 않음 |
작업 영역 ID는 현재 Snowflake 미러링에 지원되지 않습니다. SharePoint 같은 선택 원본에 사용할 수 있습니다.
Fabric 작업 영역과 Snowflake 간의 Private Link 연결은 아직 사용할 수 없습니다. 중간에 프라이빗 연결을 위해 가상 네트워크 데이터 게이트웨이 또는 온-프레미스 데이터 게이트웨이를 사용합니다.
공유 받는 사람을 작업 영역에 추가해야 합니다. 데이터 세트 또는 보고서를 공유하려면 먼저 관리자, 멤버, 읽기 권한자 또는 기여자 역할을 사용하여 작업 영역에 access 추가합니다.
대/소문자 구분: 웨어하우스 이름, 데이터베이스 이름, 스키마 이름, 테이블 이름 및 뷰 이름을 포함한 모든 Snowflake 식별자는 미러링 연결을 구성할 때 및 미러링 REST API를 사용할 때 대/소문자를 구분합니다. Fabric에 입력한 대/소문자 표기는 Snowflake에 구성된 것과 정확히 일치해야 합니다. 대/소문자가 일치하지 않으면 연결 오류가 발생하거나 테이블이 복제에 표시되지 않을 수 있으며, 설명 오류 메시지가 없는 경우가 많습니다. 예를 들어 Snowflake 웨어하우스 이름이 ANALYTICS_WH인 경우, Fabric 연결에서 analytics_wh가 아니라 ANALYTICS_WH를 입력해야 합니다.
지원되는 개체 형식
- 다음 표에서는 미러링에 지원되는 Snowflake 개체 형식을 나열합니다.
| 객체 유형 | 지원됨 | 비고 |
|---|---|---|
| 관리되는 테이블 | Yes | 복제에 대해 완벽하게 지원됨 |
| 빙산 테이블 | Yes | 기본 Iceberg 테이블 스토리지에 대한 스토리지 연결이 필요합니다. 동일한 스토리지 연결을 통해 연결할 수 있는 Iceberg 테이블만 함께 미러링할 수 있습니다. |
| Views | Yes | 12시간마다 동기화 지원 |
| 구체화된 뷰 | Yes | 12시간마다 동기화 지원 |
| 외부 테이블 | 아니오 | 지원되지 않음 |
| 임시 테이블 | 아니오 | 지원되지 않음 |
| 임시 테이블 | 아니오 | 지원되지 않음 |
| 동적 테이블 | 아니오 | 지원되지 않음 |
복제 및 데이터 제한 사항
- 원본 테이블에 업데이트가 없으면 복제 엔진은 최대 1시간까지 해당 테이블에 대해 기하급수적으로 증가하는 시간 간격으로 대기합니다. 일시적인 오류가 발생하여 데이터 새로 고침을 방지하는 경우에도 마찬가지입니다. 업데이트된 데이터가 검색된 후 복제자 엔진이 자동으로 일반 폴링을 다시 시작합니다.
- 원본 스키마 계층 구조는 미러된 데이터베이스에 복제됩니다. 이 기능을 사용하도록 설정하기 전에 만든 미러된 데이터베이스의 경우 원본 스키마가 평면화되고 스키마 이름이 테이블 이름으로 인코딩됩니다. 스키마를 사용하여 테이블을 다시 구성하려면 미러된 데이터베이스를 다시 만듭니다. 원본 스키마 계층복제를 통해 더 많이 배웁니다.
- 미러링에서는 이름에 공백 또는 특수 문자(예:
,;{}()\n\t=)가 포함된 열을 복제할 수 있습니다. 이 기능을 사용하도록 설정하기 전에 복제 중인 테이블의 경우 미러된 데이터베이스 설정을 업데이트하거나 미러링을 다시 시작하여 해당 열을 포함해야 합니다. Delta 열 매핑 지원에 대해 자세히 알아보세요. - 패브릭으로 미러링할 수 있는 테이블의 최대 수는 1,000개 테이블입니다. 현재 1000 제한을 초과하는 테이블은 복제할 수 없습니다.
- 미러링을 구성할 때 모든 데이터 미러링을 선택하면, 모든 테이블은 스키마 이름과 테이블 이름에 따라 사전순으로 정렬됩니다. 그 후, 정렬된 목록에서 처음 1,000개의 테이블이 미러링할 테이블로 결정됩니다. 알파벳 목록의 맨 아래에 있는 나머지 테이블 집합은 미러링되지 않습니다.
- 모든 데이터 미러의 선택을 취소하고 개별 테이블을 선택하면 1,000개 이상의 테이블을 선택할 수 없습니다.
- 계산 열 및 계산 테이블: 미러된 데이터베이스는 읽기 전용입니다. 미러된 데이터베이스에서 직접 계산 열 또는 계산 테이블을 만들 수 없습니다. 계산된 열을 추가하려면 Lakehouse를 만들고 바로 가기를 사용하여 미러링된 데이터를 참조한 다음, 노트북 또는 SQL을 사용해 Lakehouse에서 계산된 열을 만듭니다.
성능 제한 사항
- 큰 테이블의 대부분의 데이터를 변경하는 경우 미러링을 중지하고 다시 시작하는 것이 더 효율적입니다. 수십억 개의 레코드를 삽입하거나 업데이트하는 데 시간이 오래 걸릴 수 있습니다.
- 일부 스키마 변경 내용은 즉시 반영되지 않습니다. 스키마 변경 내용이 Fabric 복제되기 전에 일부 스키마 변경에는 데이터 변경(삽입, 업데이트 또는 삭제)이 필요합니다.
- 지역 간 고려 사항: Snowflake 인스턴스 및 Fabric 용량이 다른 클라우드 지역에 있는 경우 복제 대기 시간 및 데이터 송신 요금이 더 높을 수 있습니다. 최적의 성능을 위해 지역 간 송신 비용을 방지하려면 Snowflake 인스턴스와 동일한 클라우드 지역에 Fabric 용량을 배포합니다. 지역 간 배포가 불가피한 경우 Snowflake 및/또는 Azure 추가 송신 요금을 고려합니다. 자세한 내용은 Snowflake 데이터 반출 문서를 참조하세요.
- Snowflake에서 고객의 OneLake로 데이터를 미러링하는 경우 프로세스는 일반적으로 인라인 URL을 통해 데이터를 단계별로 처리하여 성능을 향상시킵니다. Snowflake 계정 수준 매개 변수 PREVENT_UNLOAD_TO_INLINE_URL true로 설정된 경우 다음 동작이 적용됩니다.
| 연결 방법 | PREVENT_UNLOAD_TO_INLINE_URL = true인 경우의 영향 |
|---|---|
| 직접(퍼블릭 엔드포인트) | 미러링은 Snowflake에서 직접 읽기로 대체됩니다. 이 대체 방식으로 인해 복제 시간이 더 길어지고, 특히 대규모 데이터 세트의 경우 연결 시간 초과 위험이 커집니다. |
| VNet(Virtual Network) 데이터 게이트웨이 | 미러링이 완전히 차단되었습니다. VNet 게이트웨이 시나리오는 직접 읽기를 사용할 수 없으며 인라인 URL 준비 경로가 필요합니다. |
| OPDG(온-프레미스 데이터 게이트웨이) | 미러링이 완전히 차단되었습니다. OPDG 시나리오는 직접 읽기를 사용할 수 없으며 인라인 URL 준비 경로가 필요합니다. |
계획된 해결 방법: 스토리지 통합 지원은 개발 중이며 PREVENT_UNLOAD_TO_INLINE_URL true로 설정된 경우 작동하는 대체 준비 경로를 제공합니다. 이 솔루션은 VNet 및 OPDG 시나리오의 차단을 해제합니다. 가용성에 대한 업데이트는 이 페이지를 확인하세요.
-
재시드 동작: 재시드는 전체 테이블의 데이터를 완전히 다시 로드하는 것입니다. 변경된 행만 처리하는 증분 동기화와 달리, 리시드는 테이블의 모든 데이터를 다시 읽고 다시 씁니다. 리시드는 특히 대형 테이블의 경우 상당한 Snowflake 컴퓨팅 비용을 초래할 수 있습니다.
- 재시드를 유발하는 경우:
| Trigger | Description |
|---|---|
| DDL 변경 내용 | 테이블의 DDL 타임스탬프를 수정하는 모든 DDL 변경은 다시 시딩을 트리거합니다. 이 트리거에는 열을 추가, 삭제 또는 이름을 바꾸거나, 데이터 형식을 변경하거나, 테이블 속성을 수정하는 ALTER TABLE 문이 포함됩니다. |
| 스키마 수정 도구(예: DBT) | DBT와 같은 도구가 되풀이 일정에 따라 테이블 정의를 수정하는 경우(예: 테이블을 삭제하고 다시 만드는 dbt 실행을 통해) 각 수정은 다시 시작됩니다. 이러한 도구를 자주 실행하면 (예: 몇 분마다) 지속적인 재시드 루프가 발생할 수 있습니다. |
| 미러링 중지 및 다시 시작 | 미러링을 중지하고 다시 시작할 때마다 전체 테이블이 처음부터 다시 가져옵니다. |
| 확장 용량 일시 중단 | Fabric 용량이 장기간 일시 중지되면 다시 시작할 때 미러링이 처음부터 다시 시작될 수 있습니다. Fabric 용량의 변경 내용을 참조하세요. |
- 불필요한 재시드 방지 모범 사례:
- 활성 미러링 중이 아닐 때 스키마 변경을 예약합니다. DBT 또는 다른 스키마 관리 도구를 사용하는 경우 스키마 변경 내용을 실행하기 전에 유지 관리 기간 동안 예약하거나 미러링을 일시 중지합니다.
- 빈번한 DDL 변경은 피하십시오. 하루 종일 증분 변경을 수행하지 않고 더 적은 수의 더 큰 일괄 처리로 스키마 변경 내용을 통합합니다.
- 예기치 않은 재시드를 모니터링합니다. 미러링 상태 페이지에서 초기 복사 동작을 반복적으로 표시하는 테이블을 확인합니다. 큰 테이블이 몇 분마다 다시 시딩되는 경우 업스트림 DDL 변경 내용을 확인합니다.
- 비용에 미치는 영향에 유의하세요. 2억 2,600만 행 테이블(~26.5GB)의 재시드에는 상당한 컴퓨팅 시간이 걸립니다. 이 비용을 스키마 변경 빈도에 곱하여 비용 영향을 예측합니다.
보안 제한 사항
- Fabric RLS(Snowflake Row-Level Security) 및 CLS(Column-Level Security) 정책을 복제하지 않습니다. Fabric 해당 보안 정책을 수동으로 다시 구성해야 합니다.
- 공유 받는 사람을 작업 영역에 추가해야 합니다. 데이터 세트 또는 보고서를 공유하려면 먼저 관리자, 멤버, 읽기 권한자 또는 기여자 역할을 사용하여 작업 영역에 access 추가합니다.
비용 및 청구 고려 사항
미러링에서 Snowflake 컴퓨팅 비용을 최소화하려면 다음 모범 사례를 고려하세요.
- 기존 웨어하우스를 다시 사용합니다. 미러링을 위한 전용 웨어하우스를 만드는 대신 애플리케이션이 원본 테이블을 업데이트하는 데 이미 사용하는 것과 동일한 웨어하우스를 사용하도록 미러링을 구성합니다. 이 접근 방식은 웨어하우스의 불필요한 활성화 및 자동 일시 중단 반복을 방지합니다. 애플리케이션이 테이블을 업데이트하면 미러링 리플리케이터가 웨어하우스가 아직 활성 상태인 동안 변경 사항을 거의 즉시 감지하므로 별도의 웨어하우스를 깨울 필요가 없습니다. 일부 조직에서는 예산 격리를 위해 전용 웨어하우스를 선호할 수 있습니다. 이 선택은 비용 절감과 예산 세분성 간의 절상입니다.
- 필요한 테이블만 미러링합니다. 전체 데이터베이스를 미러링하면 예기치 않게 높은 Snowflake 사용량과 Fabric 용량 급증이 발생할 수 있습니다. 먼저 분석 시나리오에 필요한 테이블만 선택합니다. 나중에 필요에 따라 테이블을 추가할 수 있습니다.
- 예기치 않은 재시드를 모니터링합니다. reseed(전체 데이터 다시 로드)는 전체 테이블을 처리하고 테이블 크기에 비례하여 컴퓨팅 비용을 발생합니다. DBT와 같은 도구에 의해 트리거되는 스키마 변경 내용을 포함하여 스키마 변경으로 인해 연속 다시 시딩이 발생할 수 있습니다. 반복되는 초기 복사 동작을 보여 주는 테이블에 대한 미러링 상태 페이지를 모니터링하고, 트리거 및 문제 해결 지침에 대한 Reseeding 섹션을 검토합니다.
- 미러링은 지속적으로 실행된다는 점에 유의하세요. 미러링에서는 현재 예약 또는 복제 기간을 지원하지 않습니다. 복제자는 지속적으로 변경 내용을 폴링하여 지속적인 Snowflake 컴퓨팅 사용량을 생성합니다. 그에 따라 눈송이 예산을 계획하십시오.
지원되는 지역
데이터베이스 미러링 및 개방형 미러링을 모든 Microsoft Fabric 지역에서 사용할 수 있습니다. 자세한 내용은 Fabric 지역 가용성을 참조하세요.