다음을 통해 공유


Azure Synapse Analytics의 전용 SQL 풀에 대한 사용자 정의 스키마

이 문서에서는 T-SQL 사용자 정의 스키마를 사용하여 전용 SQL 풀에서 솔루션을 개발하기 위한 몇 가지 팁을 제공하는 데 중점을 둡니다.

애플리케이션 경계에 대한 스키마

기존 데이터 웨어하우스는 종종 별도의 데이터베이스를 사용하여 워크로드, 도메인 또는 보안에 따라 애플리케이션 경계를 만듭니다.

예를 들어 기존 SQL Server 데이터 웨어하우스에는 스테이징 데이터베이스, 데이터 웨어하우스 데이터베이스 및 일부 데이터 마트 데이터베이스가 포함될 수 있습니다. 이 토폴로지에서 각 데이터베이스는 아키텍처에서 워크로드 및 보안 경계로 작동합니다.

반면 전용 SQL 풀은 하나의 데이터베이스 내에서 전체 데이터 웨어하우스 워크로드를 실행합니다. 데이터베이스 간 조인은 허용되지 않습니다. 전용 SQL 풀에는 웨어하우스에서 사용하는 모든 테이블이 하나의 데이터베이스 내에 저장되어야 합니다.

비고

SQL 풀은 모든 종류의 데이터베이스 간 쿼리를 지원하지 않습니다. 따라서 이 패턴을 활용하는 데이터 웨어하우스 구현을 수정해야 합니다.

권장 사항

다음은 사용자 정의 스키마를 사용하여 워크로드, 보안, 도메인 및 기능 경계를 통합하기 위한 권장 사항입니다.

  • 전용 SQL 풀에서 하나의 데이터베이스를 사용하여 전체 데이터 웨어하우스 워크로드를 실행합니다.
  • 하나의 전용 SQL 풀 데이터베이스를 사용하도록 기존 데이터 웨어하우스 환경을 통합합니다.
  • 사용자 정의 스키마를 활용하여 이전에는 데이터베이스로 구현되었던 경계를 제공합니다.

사용자 정의 스키마가 이전에 사용되지 않은 경우 클린 슬레이트가 있습니다. 전용 SQL 풀 데이터베이스에서 사용자 정의 스키마의 기준으로 이전 데이터베이스 이름을 사용합니다.

스키마가 이미 사용된 경우 다음과 같은 몇 가지 옵션이 있습니다.

  • 레거시 스키마 이름을 제거하고 새로 시작합니다.
  • 레거시 스키마 이름을 테이블 이름 앞에 추가하여 레거시 스키마 이름을 유지합니다.
  • 이전 스키마 구조를 다시 만들기 위해 추가 스키마에서 테이블에 대한 뷰를 구현하여 레거시 스키마 이름을 유지합니다.

비고

첫 번째 검사 옵션에서 3은 가장 매력적인 옵션처럼 보일 수 있습니다. 그러나, 악마는 세부 사항에 있습니다. 보기는 전용 SQL 풀에서 읽기 전용입니다. 모든 데이터 또는 테이블 수정은 기본 테이블에 대해 수행해야 합니다. 또한 옵션 3은 시스템에 뷰 계층을 도입합니다. 아키텍처에서 뷰를 이미 사용 중이라면 이에 대해 추가적인 고민을 해보는 것이 좋습니다.

예제:

데이터베이스 이름에 따라 사용자 정의 스키마를 구현합니다.

CREATE SCHEMA [stg]; -- stg previously database name for staging database
GO
CREATE SCHEMA [edw]; -- edw previously database name for the data warehouse
GO
CREATE TABLE [stg].[customer] -- create staging tables in the stg schema
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[customer] -- create data warehouse tables in the edw schema
(       CustKey BIGINT NOT NULL
,       ...
);

레거시 스키마 이름을 테이블 이름 앞에 추가하여 유지합니다. 워크로드 경계에 스키마를 사용합니다.

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the data warehouse boundary
GO
CREATE TABLE [stg].[dim_customer] --pre-pend the old schema name to the table and create in the staging boundary
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[dim_customer] --pre-pend the old schema name to the table and create in the data warehouse boundary
(       CustKey BIGINT NOT NULL
,       ...
);

보기를 사용하여 레거시 스키마 이름을 유지합니다.

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the data warehouse boundary
GO
CREATE SCHEMA [dim]; -- edw defines the legacy schema name boundary
GO
CREATE TABLE [stg].[customer] -- create the base staging tables in the staging boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE TABLE [edw].[customer] -- create the base data warehouse tables in the data warehouse boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE VIEW [dim].[customer] -- create a view in the legacy schema name boundary for presentation consistency purposes only
AS
SELECT  CustKey
,       ...
FROM    [edw].customer
;

비고

스키마 전략을 변경하려면 데이터베이스에 대한 보안 모델을 검토해야 합니다. 대부분의 경우 스키마 수준에서 권한을 할당하여 보안 모델을 간소화할 수 있습니다. 더 세부적인 권한이 필요한 경우 데이터베이스 역할을 사용할 수 있습니다.

다음 단계

더 많은 개발 팁은 개발 개요를 참조하세요.