데이터베이스 커넥터 개념¶

커넥터 구성 요소¶

Snowflake Database 커넥터는 Marketplace에서 Snowflake 계정에 설치되는 Snowflake Native App과 온프레미스 또는 클라우드의 인프라 내부에서 실행되는 Agent 애플리케이션으로 구성됩니다.

• Agent 는 원본 데이터베이스에 직접 연결하고, 복제하기로 선택한 테이블의 업데이트를 추적하며, Snowflake 계정에 변경 사항을 업로드합니다. Agent는 Snowflake와 데이터 원본에 연결하기 위해 한 번만 구성하면 되며, 그 이후로는 새 버전이 출시될 때만 업그레이드하면 됩니다. 그 외에는 Native App을 통해 완전히 제어 및 구성됩니다.

• Native Apps 는 데이터 복제 프로세스를 제어합니다. Native Apps는 에이전트에게 추적할 테이블을 지시하고 변경 사항을 수신하여 대상 데이터베이스에 병합합니다. 대부분의 상호 작용은 Native App을 통해 이루어집니다. 새 버전이 출시되면 자동으로 업그레이드됩니다.

커넥터가 외부 연결이 차단된 네트워크에서 원본 데이터베이스에 안전하게 액세스할 수 있도록 에이전트가 로컬에서 실행되는 이러한 모델이 필요합니다.

하나의 Agent 인스턴스는 항상 단일 Native App 인스턴스에 연결되고, 하나의 Native App은 항상 하나의 Agent와 함께 작동합니다. 예컨대 연결이 끊어진 네트워크에서 원본 데이터베이스를 복제하기 위해 Agent 인스턴스를 여러 개 실행해야 하는 경우 Native App의 여러 인스턴스를 설치하고 구성해야 합니다. 도움이 필요하면 Snowflake 지원팀 에 문의하십시오.

내부적으로, 커넥터는 비동기식 이벤트 기반 명령 교환에 의존합니다. Native App도 Agent와 통신하고 조정해야 합니다. 명령 실행 시점과 해당 명령의 효과가 나타나는 시점 사이에 지연이 발생할 수 있는 이유가 바로 이것입니다.

데이터 원본, 테이블, 저널 및 대상¶

커넥터를 통한 데이터 흐름에 대해 이야기할 때는 다음 스테이지를 구분합니다.

데이터 원본

커넥터가 복제 중인 테이블을 보관하는 데이터베이스입니다. 데이터베이스 엔진에 따라 이는 전체 데이터베이스 서버 일 수도 있고 서버 내부 에 호스팅된 데이터베이스 중 하나일 수도 있습니다.

Agent가 모든 데이터 원본에 직접 연결할 수 있는 한, 단일 커넥터 인스턴스가 여러 데이터 원본에서 복제할 수 있습니다.

원본 테이블

커넥터가 변경 사항을 추적하여 Snowflake에 복제하는 원본 데이터베이스의 특정 테이블입니다. 각 데이터 원본에는 동일한 커넥터 인스턴스에 의해 동시에 복제되는 원본 테이블이 여러 개 포함될 수 있습니다.

데이터 원본에서 원본 테이블의 직계 상위는 Snowflake에서 해당 대상 테이블의 스키마가 됩니다.

저널

커넥터의 Native App이 소유하고 관리하는 Snowflake 테이블로, 원본 테이블에 적용된 모든 변경 사항(삽입, 업데이트, 삭제)을 수신하고 저장합니다. 사실상 원본 테이블 데이터의 변경 로그로, 그 구조는 데이터베이스 엔진이 일반적으로 복제본에 변경 사항을 브로드캐스트하는 방식을 반영합니다.

원본 테이블마다 별도의 저널 테이블이 있습니다.

대상 테이블

커넥터가 데이터를 복제하는 계정의 Snowflake 테이블입니다. 원본 테이블마다 별도의 대상 테이블이 있습니다. 대상 테이블의 열 이름은 원본 테이블의 이름을 반영하고, 열 이름의 유형은 원본 열의 해당 Snowflake 유형입니다.

각 대상 테이블에는 복제 정보가 담긴 열인 _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_DELETED 열도 포함되며, 각각 해당 행의 최초 삽입, 마지막 업데이트 및 삭제 타임스탬프를 가진 열입니다.

대상 테이블에는 스트림 생성을 허용하도록 변경 내용 추적이 미리 활성화되어 있습니다. 커넥터의 Native App은 테이블에 대한 OWNERSHIP 권한 부여를 유지합니다.

스냅샷 및 증분 로드¶

새로 추가된 테이블의 데이터 복제는 스냅샷 로드 로 시작됩니다. Agent는 원본 테이블에서 단일 SELECT <columns> 문을 실행한 다음, 모든 레코드를 Snowflake의 임시 테이블로 스트리밍한 후 대상 테이블에 복사합니다. 이 작업은 원본 데이터베이스에서 많은 리소스를 사용할 수 있으며, 대형 테이블의 경우 일반적으로 시간이 오래 걸립니다. 대상 테이블에 첫 번째 레코드가 나타날 때까지 기다려야 할 수도 있습니다.

다음 시나리오에서는 스냅샷 로드를 반복하여 이전에 복제된 데이터를 대체함으로써 원본 테이블과 대상 테이블을 동기화할 수도 있습니다.

• 지원되지 않는 데이터 타입, 크기, 커넥터 버그 또는 기타 문제로 인해 테이블 복제가 영구적으로 실패하는 경우.

• 복제가 일시 중지된 경우와 재개된 후에는 원본 데이터베이스의 변경 로그에 테이블이 마지막으로 복제된 이후의 항목이 더 이상 포함되지 않습니다.

초기 스냅샷이 완료되면 테이블 복제가 증분 로드 로 전환됩니다. Agent는 원본 데이터베이스의 변경 로그를 추적하고 이러한 변경 사항을 해당 저널 테이블로 스트리밍하며, 이후에 저널 테이블에서 변경 사항이 대상 테이블에 병합됩니다. 이러한 읽기, 스트리밍, 병합의 순환은 지속적으로 수행할 수도 있고 일정에 따라 수행할 수도 있습니다. 이러한 모드에 대한 자세한 내용은 다음 단계 및 다음 단계 섹션을 참조하십시오.

테이블 복제 수명 주기¶

새로 추가된 원본 테이블의 복제 주기는 스키마 자가 분석 으로 시작됩니다. 바로 이 지점에서 커넥터가 원본 테이블의 열, 열 이름, 유형을 검색한 다음 이들을 Snowflake와 커넥터의 제한 사항에 비추어 검증합니다. 검증에 실패하면 이 스테이지도 실패하고 주기가 완료됩니다. 스키마 자가 분석을 성공적으로 완료한 후 커넥터는 빈 대상 테이블을 생성합니다.

두 번째 스테이지는 스냅샷 로드 로, 여기서 커넥터가 원본 테이블에서 사용 가능한 모든 데이터를 대상 테이블에 복사합니다. 이 스테이지가 실패하면 주기도 끝나게 되고, 더 이상 데이터가 복제되지 않습니다. 성공적으로 완료되면 원본 테이블의 전체 데이터 세트를 대상 테이블에서 사용할 수 있습니다.

마지막으로, 테이블은 증분 로드 로 이동하며 여기서 커넥터가 계속해서 원본 테이블의 변경 내용을 추적하고 대상 테이블에 복사합니다. 테이블이 복제에서 제거될 때까지 이 과정이 계속됩니다. 이 스테이지에서 실패하면 문제가 해소될 때까지 원본 테이블 복제가 영구적으로 중지됩니다.

테이블의 현재 복제 단계를 확인하는 방법에 대한 지침은 Snowflake Connector for MySQL 모니터링하기 및 Snowflake Connector for PostgreSQL 모니터링하기 섹션을 참조하십시오.

원본에서 대상으로의 데이터 흐름¶

커넥터는 스냅샷 또는 증분 로드의 수행 여부에 따라 원본 테이블에서 대상으로 데이터를 다르게 이동합니다. 자세한 내용은 스냅샷 및 증분 로드 을 참조하십시오.

연속 복제와 예약 복제¶

새로 추가된 데이터 원본의 기본 복제 모드는 연속 입니다. 이 모드에서 커넥터는 가능한 한 빨리 데이터 변경 사항을 복제하는 것을 목표로 합니다. 자주 변경되는 데이터 원본에 적합한 모드로, 해당 데이터를 Snowflake에서 짧은 지연 시간으로 사용할 수 있도록 해야 합니다.

데이터 원본을 예약 모드로 복제하도록 변경할 수 있으며, 이 모드에서는 정해진 일정에 따라 원본에서 대상 테이블로 데이터가 일괄적으로 복사됩니다. 이 모드는 변경 빈도가 낮은 데이터 원본이거나 크레딧 사용량을 줄이고 Snowflake에서 짧은 지연 시간으로 데이터를 제공할 필요가 없는 경우에 가장 적합합니다.

연속 복제 실행 시 증분 로드는 “완료”로 보고되지 않습니다. 예약 모드에서는 모든 데이터 배치가 대상 테이블에 병합된 후 증분 로드가 완료된 것으로 보고됩니다. 예약 모드의 “배치”는 이전에 예약된 실행과 다음으로 예약된 실행이 시작되는 순간 사이의 모든 변경 로그 항목으로 구성됩니다.

웨어하우스 유형¶

커넥터를 작동하려면 다음 두 웨어하우스가 필요합니다.

• 때때로 Ops 웨어하우스라고도 하는 운영 웨어하우스 는 커넥터의 명령 및 제어 작업을 실행하는 데 사용됩니다. 이 웨어하우스는 설치 마법사를 통해 자동으로 생성되며, 최적의 크기는 XS입니다.

• 컴퓨팅 웨어하우스 는 저널에서 대상 테이블로 데이터를 이동하는 병합 작업을 실행하는 데 사용됩니다. 이 웨어하우스는 설치 마법사를 통해 만들거나 수동으로 직접 만들 수도 있습니다. 최적의 크기와 유형은 복제 규모에 따라 달라집니다.

위의 구분은 대량의 데이터를 이동하는 쿼리와 함께 운영 쿼리를 큐에 넣지 않고 적절한 시기에 실행하는 데 필수적입니다. 이는 운영 웨어하우스를 커넥터 인스턴스 간에 재사용할 수 없으며 계정의 다른 워크로드와 공유해서는 안 된다는 것을 의미하기도 합니다.

따라서 컴퓨팅 웨어하우스를 다른 커넥터 인스턴스 및 워크로드와 공유할 수 있습니다. 하지만 이 웨어하우스를 공유하면 대상 테이블에 데이터를 표시하는 시간이 지연될 수 있다는 점에 유의하십시오.