데이터 소스에서 데이터 랜딩

온보딩 시 데이터를 전송하는 첫 번째 단계는 데이터를 랜딩하는 것입니다. 여기에는 데이터 소스에서 랜딩 영역으로 데이터를 전송하는 작업이 포함됩니다.

소스 연결을 통해 여러 데이터 소스에서 데이터를 랜딩할 수 있습니다.

랜딩 영역은 프로젝트를 생성할 때 정의됩니다.

• Qlik Cloud(via Amazon S3)

  Qlik Cloud(via Amazon S3)로 데이터를 랜딩할 때, 이를 사용하여 Qlik Cloud에서 분석할 준비가 된 QVD 테이블을 생성할 수 있습니다.

• 클라우드 데이터 웨어하우스

  데이터를 Snowflake 또는 Azure Synapse Analytics와 같은 클라우드 데이터 웨어하우스로 랜딩할 때, 동일한 클라우드 데이터 웨어하우스에 테이블을 저장할 수 있습니다.

• Qlik 오픈 레이크하우스

  Qlik 오픈 레이크하우스로 데이터를 랜딩할 때 데이터는 Iceberg 오픈 테이블 형식으로 저장되며 클라우드 데이터 웨어하우스로 미러링될 수 있습니다.

데이터를 Snowflake에서 관리하는 클라우드 파일 스토리지로 랜딩하는 레이크하우스로 데이터를 랜딩할 수도 있습니다. 자세한 내용은 레이크하우스에 랜딩 데이터를 참조하십시오.

랜딩 데이터 태스크 생성 및 구성

이 섹션에서는 랜딩 데이터 태스크를 생성하는 방법을 설명합니다. 데이터 파이프라인을 생성하는 가장 빠른 방법은 데이터를 온보딩하는 것입니다. 그러면 준비 및 실행할 준비가 된 랜딩 데이터 태스크와 스토리지 데이터 태스크가 생성됩니다. 자세한 내용은 데이터 웨어하우스로 데이터 온보딩를 참조하십시오.

1. 프로젝트에서 생성을 클릭하고 데이터 랜딩을 선택합니다.

2. 데이터 랜딩 대화 상자에서 데이터 태스크의 이름과 설명을 입력합니다.

   랜딩 데이터 태스크가 생성될 때 열려면 열기를 선택합니다.

   생성을 클릭합니다.

3. 소스 데이터 선택을 클릭합니다.

4. 소스 데이터에 대한 연결을 선택하고 다음을 클릭합니다.

   왼쪽 패널의 필터를 사용하여 소스 유형, 공간 및 소유자별로 연결 목록을 필터링할 수 있습니다.

   소스 데이터에 대한 연결이 아직 없는 경우 먼저 연결 추가를 클릭하여 연결을 생성해야 합니다.

   지원되는 소스에 대한 연결을 설정하는 방법에 대한 자세한 내용은 데이터 소스에 대한 연결 설정를 참조하십시오.

   정보 메모다음 단계에서 테이블을 선택한 후에는 소스 연결을 온프레미스 데이터 소스에서 클라우드 데이터 소스로 또는 그 반대로 변경할 수 없습니다. 동일한 유형의 다른 데이터 소스로만 연결을 변경할 수 있습니다.

5. 데이터 태스크에 포함할 데이터 세트를 선택합니다. 선택 대화 상자는 연결한 소스 유형에 따라 다릅니다.

   테이블 선택을 완료하면 저장을 클릭합니다.

   데이터 세트가 표시됩니다.

6. 랜딩 설정을 변경할 수 있습니다. 이 작업은 필수가 아닙니다.

   • 설정을 클릭합니다.

   설정에 대한 자세한 내용은 랜딩 설정를 참조하십시오.

7. 이제 선택한 데이터 자산 테이블의 구조와 메타데이터를 미리 볼 수 있습니다. 여기에는 명시적으로 나열된 모든 테이블과 선택 규칙과 일치하는 테이블이 포함됩니다.

   데이터 소스에서 테이블을 더 추가하려면 소스 데이터 선택을 클릭합니다.

8. 데이터 필터링 또는 열 추가와 같이 데이터 세트에 대한 기본 변환을 수행할 수 있습니다. 이 작업은 필수가 아닙니다.

   자세한 내용은 데이터 집합 관리를 참조하십시오.

9. 원하는 변환을 추가한 후 데이터 세트 검증을 클릭하여 데이터 세트를 검증할 수 있습니다. 검증에서 오류가 발견되면 계속 진행하기 전에 오류를 수정하십시오.

   자세한 내용은 데이터 집합 검증 및 조정를 참조하십시오.

10. 준비가 되면 준비를 클릭하여 데이터 태스크를 카탈로그화하고 실행을 위해 준비합니다.

    화면 하단의 준비 진행 상황에서 진행 상황을 팔로우할 수.

11. 데이터 태스크가 준비되고 데이터 복제를 시작할 준비가 되면 실행을 클릭합니다.

이제 복제가 시작되고 모니터링에서 진행 상황을 볼 수 있습니다. 자세한 내용은 Monitoring an individual data task를 참조하십시오.

데이터베이스에서 데이터 선택

특정 테이블 또는 보기를 선택하거나 선택 규칙을 사용하여 테이블 그룹을 포함하거나 제외할 수 있습니다.

%를 와일드카드로 사용하여 스키마 및 테이블에 대한 선택 기준을 정의합니다.

• %.%는 모든 스키마의 모든 테이블을 정의합니다.

• Public.%는 Public 스키마의 모든 테이블을 정의합니다.

선택 기준은 선택에 따라 미리 보기를 제공합니다.

이제 다음 중 하나를 수행할 수 있습니다.

• 선택 기준에 따라 테이블 그룹을 포함하거나 제외하는 규칙을 만듭니다.

  선택 기준에서 규칙 추가를 클릭하여 규칙을 만들고 포함 또는 제외를 선택합니다.

  선택 규칙에서 규칙을 볼 수 있습니다.

• 하나 이상의 데이터 집합을 선택하고 선택한 데이터 집합 추가를 클릭합니다.

  명시적으로 선택된 데이터 집합에서 추가된 데이터 집합을 볼 수 있습니다.

선택 규칙은 현재 테이블 및 뷰 집합에만 적용되며 향후에 추가되는 테이블 및 뷰에는 적용되지 않습니다.

변경 데이터 캡처(CDC)를 사용하여 랜딩 태스크 실행

랜딩 태스크가 준비되면 실행할 수 있습니다. 그러면 온프레미스 데이터 소스에서 랜딩 영역으로 데이터를 전송하는 복제가 시작됩니다.

• 데이터 랜딩을 시작하려면 실행을 클릭합니다.

이제 복제가 시작되고 데이터 태스크의 상태가 실행 중으로 변경됩니다. 먼저 전체 데이터 소스가 복사된 다음 변경 사항이 추적됩니다. 즉, 변경 사항이 지속적으로 추적되고 발견 시 전송됩니다. 이를 통해 랜딩 영역의 랜딩 데이터가 최신 상태로 유지됩니다.

Qlik Talend Data Integration 홈에서 랜딩 데이터가 업데이트된 상태, 날짜 및 시간, 오류가 발생한 테이블 수를 볼 수 있습니다. 데이터 태스크를 열고 테이블 탭을 선택하여 테이블의 기본 메타데이터 정보를 볼 수도 있습니다.

모니터링 탭을 열어 진행 상황을 자세히 모니터링할 수 있습니다. 자세한 내용은 Monitoring an individual data task를 참조하십시오.

모든 테이블이 로드되고 첫 번째 변경 사항 세트가 처리되면 데이터 태스크 카드의 데이터가 다음으로 업데이트됨은 해당 시간까지의 소스 변경 사항을 데이터 태스크에서 사용할 수 있음을 나타냅니다.

테이블 다시 로드

소스에서 데이터를 다시 로드할 수 있습니다.

단일 테이블 다시 로드

변경 데이터 캡처를 방해하지 않고 특정 테이블을 수동으로 다시 로드할 수 있습니다. 이는 하나 이상의 테이블에 CDC 문제가 있는 경우 유용합니다.

1. 랜딩 데이터 태스크를 열고 모니터링 탭을 선택합니다.

2. 다시 로드할 테이블을 선택합니다.

3. 클릭 테이블 다시 로드.

테이블을 다시 로드하여 문제를 해결할 수 없거나 문제로 인해 전체 태스크가 영향을 받는 경우 대신 모든 테이블을 대상으로 다시 로드할 수 있습니다. 이렇게 하면 변경 데이터 캡처가 다시 시작됩니다.

대상으로 모든 테이블 다시 로드

특정 테이블을 다시 로드하여 해결할 수 없는 CDC 문제가 발생하는 경우 모든 테이블을 대상으로 다시 로드할 수 있습니다. 문제의 예로는 누락된 이벤트, 소스 데이터베이스 재구성으로 인한 문제 또는 소스 데이터베이스 이벤트를 읽을 때의 실패 등이 있습니다.

1. 데이터 작업과 이를 사용하는 모든 작업을 중지합니다.

2. 데이터 작업을 열고 모니터링 탭을 선택합니다.

3. ...를 클릭한 다음 대상 다시 로드를 클릭합니다.

그러면 Drop-Create를 사용하여 모든 테이블이 대상에 다시 로드되고 지금부터 모든 데이터 변경 내용 캡처가 다시 시작됩니다.

• 데이터 랜딩 작업을 소비하는 저장소 작업은 비교를 통해 다시 로드되고 다음 실행 시 적용되어 동기화됩니다. 기존 기록은 유지됩니다. 유형 2 기록은 다시 로드 및 비교 프로세스가 실행된 후 변경 내용을 반영하도록 업데이트됩니다.

  유형 2 기록의 시작 날짜에 대한 타임스탬프는 다시 로드 날짜를 반영하며 반드시 소스에서 변경이 발생한 날짜는 아닙니다.

• 대상 다시 로드 작업 중에는 저장소가 동기화될 때까지 저장소 라이브 보기를 신뢰할 수 없습니다. 다음과 같은 경우 저장소가 완전히 동기화됩니다.

  • 모든 테이블은 비교 및 적용을 사용하여 다시 로드됩니다.

  • 각 테이블에 대해 한 번의 변경 주기가 수행됩니다.

다시 로드 및 비교를 사용하여 랜딩 데이터 태스크 실행

랜딩 데이터 태스크가 준비되면 이를 사용하여 데이터를 복사할 수 있습니다.

• 전체 로드를 시작하려면 실행을 클릭합니다.

이제 데이터 복사가 시작되고 데이터 태스크의 상태가 실행 중으로 변경됩니다. 전체 데이터 소스가 복사되면 상태는 완료됨이 됩니다.

Qlik Talend Data Integration 홈에서 랜딩 데이터가 업데이트된 상태, 날짜 및 시간, 오류가 발생한 테이블 수를 볼 수 있습니다. 데이터 태스크를 열고 테이블 탭을 선택하여 테이블의 기본 메타데이터 정보를 볼 수도 있습니다.

모니터링 탭을 열어 진행 상황을 자세히 모니터링할 수 있습니다. 자세한 내용은 Monitoring an individual data task를 참조하십시오.

모든 테이블이 로드되면 데이터 태스크 카드의 데이터가 다음으로 업데이트됨은 해당 시간까지의 소스 변경 사항을 데이터 자산에서 사용할 수 있음을 나타냅니다. 그러나 데이터 태스크의 일부 테이블은 로드가 시작된 시점에 따라 더 나중 시간으로 업데이트될 수 있습니다. 즉, 데이터 일관성이 보장되지 않습니다. 예를 들어 로드가 08:00에 시작되어 4시간이 걸린 경우 로드가 완료되면 데이터가 다음으로 업데이트됨에 08:00이 표시됩니다. 그러나 11:30에 다시 로드를 시작한 테이블에는 08:00에서 11:30 사이에 발생한 소스 변경 사항이 포함됩니다.

데이터가 다음으로 업데이트됨은 성공적으로 로드된 테이블만 반영합니다. 다시 로드가 실패한 테이블에 대해서는 아무것도 나타내지 않습니다. 클라우드 대상에서 모든 테이블에 오류가 발생하여 다시 로드가 완료된 경우 이 필드는 비어 있게 됩니다.

다시 로드 및 비교를 사용할 때 데이터 다시 로드

업데이트 방법으로 다시 로드 및 비교를 사용하는 경우 데이터 소스와 최신 상태를 유지하려면 데이터를 다시 로드해야 합니다.

• 모든 테이블을 수동으로 다시 로드하려면 다시 로드를 클릭합니다.

• 예약된 다시 로드를 설정합니다.

단일 테이블 다시 로드

특정 테이블을 수동으로 다시 로드할 수 있습니다. 이는 하나 이상의 테이블에 문제가 있는 경우 유용합니다.

1. 랜딩 데이터 태스크를 열고 모니터링 탭을 선택합니다.

2. 다시 로드할 테이블을 선택합니다.

3. 클릭 테이블 다시 로드.

다시 로드 및 비교 랜딩 데이터 태스크 예약

데이터 태스크의 공간에서 작동 가능 역할 또는 편집 가능 역할이 있는 경우 랜딩 데이터 태스크에 대해 주기적인 다시 로드를 예약할 수 있습니다. 일정이 활성화되려면 데이터 태스크 상태가 최소 준비됨 상태여야 합니다.

• 데이터 태스크에서 ...을 클릭하고 일정 예약을 선택합니다.

  시간 기반 일정을 설정할 수 있습니다.

  데이터 소스 유형 및 구독 계층에 따른 최소 예약 간격에 대한 자세한 내용은 허용되는 최소 예약 간격을 참조하십시오.

데이터 집합의 로드 우선 순위 설정

각 데이터 집합에 로드 우선 순위를 할당하여 데이터 작업에서 데이터 집합의 로드 순서를 제어할 수 있습니다. 예를 들어, 큰 데이터 집합보다 작은 데이터 집합을 로드하려는 경우에 유용할 수 있습니다.

1. 로드 우선 순위를 클릭합니다.

2. 각 데이터 집합의 로드 우선 순위를 선택합니다.

   기본 로드 우선 순위는 보통입니다. 데이터 집합은 다음 우선 순위에 따라 로드됩니다.

   • 가장 높음

   • 보다 높음

   • 높음

   • 기본

   • 낮음

   • 보다 낮음

   • 가장 낮음

   우선 순위가 동일한 데이터 집합은 특별한 순서 없이 로드됩니다.

3. 확인을 클릭합니다.

랜딩 데이터 태스크에 대한 작업

태스크 메뉴에서 랜딩 데이터 태스크에 대해 다음 작업을 수행할 수 있습니다.

• 열기

  랜딩 데이터 태스크를 엽니다. 테이블 구조 및 데이터 태스크에 대한 세부 정보를 볼 수 있습니다.

• 편집

  태스크의 이름과 설명을 편집할 수 있습니다.

• 삭제

  데이터 태스크를 삭제할 수 있습니다.

  다음 개체는 삭제되지 않습니다:

  • 랜딩 영역의 데이터

  • 대상 플랫폼의 스키마

• 실행

  데이터 태스크를 실행하여 데이터 복사를 시작할 수 있습니다.

  변경 데이터 캡처(CDC)를 사용하여 랜딩 태스크 실행

  다시 로드 및 비교를 사용하여 랜딩 데이터 태스크 실행

• 중지

  실행 중인 데이터 태스크의 작동을 중지할 수 있습니다. 랜딩 영역이 변경된 데이터로 업데이트되지 않습니다.

  다시 로드 일정이 있는 전체 로드 데이터 태스크를 중지하면 현재 다시 로드만 중지됩니다. 데이터 태스크 상태가 중지됨이고 활성 다시 로드 일정이 있는 경우 다음 예약된 시간에 다시 로드됩니다. 다시 로드 일정 예약에서 다시 로드 일정을 꺼야 합니다.

• 다시 로드

  다시 로드 및 비교 업데이트 모드에서 데이터 태스크의 수동 다시 로드를 수행할 수 있습니다.

• 준비

  실행을 위해 태스크를 준비합니다. 여기에는 다음이 포함됩니다.

  • 디자인이 유효한지 검증합니다.

  • 디자인과 일치하도록 물리적 테이블 및 뷰를 생성하거나 변경합니다.

  • 데이터 태스크에 대한 SQL 코드를 생성합니다.

  • 태스크 출력 데이터 세트에 대한 카탈로그 항목을 생성하거나 변경합니다.

  화면 하단의 준비 진행 상황에서 진행 상황을 팔로우할 수 있습니다.

  정보 메모작업을 준비하기 전에 바로 아래에 있는 모든 작업을 중지합니다.

• 테이블 다시 생성

  소스에서 데이터 세트를 다시 생성합니다.

  정보 메모개별 테이블에 문제가 있는 경우 테이블을 다시 만드는 대신 먼저 테이블을 다시 로드해 보는 것이 좋습니다. 테이블을 다시 만들면 기록 데이터가 손실될 수 있습니다. 주요 변경 내용이 있는 경우 데이터를 다시 로드하기 위해 다시 만들어진 데이터 작업을 사용하는 다운스트림 데이터 작업도 준비해야 합니다.

• 일정 예약

  전체 로드 모드에서 랜딩 데이터 태스크에 대한 예약된 다시 로드를 설정할 수 있습니다. 사용자 지정할 수 있는 시간 기반 일정을 설정할 수 있습니다.

  예약된 다시 로드를 켜거나 끌 수도 있습니다.

  다시 로드를 예약하려면 데이터 태스크의 공간에 대한 작동 가능 역할이 있어야 합니다.

• 데이터 저장

  이 랜딩 데이터 태스크의 데이터를 사용하는 스토리지 데이터 태스크를 생성할 수 있습니다.

메타데이터 새로 고침

작업의 설계 보기에서 소스 메타데이터의 변경 내용에 맞게 작업의 메타데이터를 새로 고칠 수 있습니다. Metadata Manager를 사용하는 SaaS 응용 프로그램의 경우 데이터 작업에서 메타데이터를 새로 고치려면 먼저 Metadata Manager를 새로 고쳐야 합니다.

1. 다음 중 하나를 수행할 수 있습니다.

   • 작업의 모든 데이터 집합에 대한 메타데이터를 새로 고치려면 ...를 클릭한 다음 메타데이터 새로 고침을 클릭합니다.

   • 단일 데이터 집합에 대한 메타데이터를 새로 고치려면 데이터 집합의 데이터 집합에서 ...를 클릭한 다음 메타데이터 새로 고침을 클릭합니다.

   화면 하단의 메타데이터 새로 고침에서 메타데이터 새로 고침 상태를 확인할 수 있습니다. 에 커서를 올려놓으면 메타데이터가 마지막으로 새로 고침된 시기를 확인할 수 있습니다.

2. 변경 내용을 적용할 데이터 작업을 준비합니다.

   데이터 작업을 준비하고 변경 내용을 적용하면 변경 내용이 메타데이터 새로 고침에서 제거됩니다.

변경 내용을 전파하려면 이 작업을 사용하는 저장소 작업을 준비해야 합니다.

열이 제거되면 저장소에서 기록 데이터가 손실되지 않도록 Null 값이 포함된 변환이 추가됩니다.

메타데이터 새로 고침에 대한 제한 사항

• 동일한 시간 슬롯에서 이전에 삭제된 열이 있으면 이름 바꾸기가 삭제된 열 이름 바꾸기로 해석됩니다(동일한 데이터 유형과 데이터 길이를 갖는 경우).

   

  이전: a b c d

  이후: a c1 d

  이 예에서는 b가 삭제되고 c가 c1로 이름이 바뀌었으며, b와 c의 데이터 유형과 데이터 길이가 동일합니다.

  이는 b의 이름이 c1로 변경되고 c가 삭제된 것으로 식별됩니다.

• 이전에 마지막 열 이름이 삭제된 경우에도 마지막 열 이름 바꾸기는 인식되지 않으며 이름이 바뀌기 전의 열도 인식되지 않습니다.

   

  이전: a b c d

  이후: a b c1

  이 예에서는 d가 삭제되고 c가 c1로 이름이 바뀌었습니다.

  이는 c 및 d가 삭제되고 c1이 추가된 것으로 식별됩니다.

• 새 열은 끝에 추가되는 것으로 가정됩니다. 다음 열과 동일한 데이터 타입으로 중간에 열이 추가되면 삭제 및 이름 바꾸기로 해석될 수 있습니다.

스키마 진화

스키마 진화를 사용하면 여러 데이터 소스의 구조적 변경 내용을 쉽게 감지하고 해당 변경 내용을 작업에 적용하는 방법을 제어할 수 있습니다. 스키마 진화는 소스 데이터 스키마에 대한 DDL 변경 내용을 감지하는 데 사용할 수 있습니다. 일부 변경 내용을 자동으로 적용할 수도 있습니다.

각 변경 유형에 대해 작업 설정의 스키마 진화 섹션에서 변경 내용을 처리하는 방법을 선택할 수 있습니다. 변경 내용을 적용하거나, 변경 내용을 무시하거나, 테이블을 일시 중단하거나, 작업 처리를 중지할 수 있습니다.

각 변경 유형에 대해 DDL 변경을 처리하는 데 사용할 작업을 설정할 수 있습니다. 일부 작업은 모든 변경 유형에 사용할 수 없습니다.

• 대상에 적용

  변경 내용을 자동으로 적용합니다.

• 무시

  변경 내용을 무시합니다.

• 일시 중단 테이블

  테이블을 일시 중단합니다. 모니터에 표가 오류로 표시됩니다.

• 작업 중지

  작업 처리를 중지합니다. 이 기능은 모든 스키마 변경 내용을 수동으로 처리하려는 경우에 유용합니다. 이렇게 하면 일정 예약도 중지되어 예약된 실행이 수행되지 않습니다.

다음과 같은 변경 내용이 지원됩니다.

• 열 추가

• 열 이름 변경

• 열 데이터 유형 변경

• 선택 패턴과 일치하는 테이블 생성
  

  패턴과 일치하는 데이터 세트를 추가하기 위해 선택 규칙을 사용한 경우, 패턴을 충족하는 새 테이블이 감지되고 추가됩니다.

태스크 설정에 대한 자세한 내용은 스키마 진화

스키마 진화로 처리되는 변경 사항에 대한 알림을 받을 수도 있습니다. 자세한 내용은 작업 변경 알림 설정를 참조하십시오.

스키마 진화에 대한 제한 사항

스키마 진화에는 다음과 같은 제한이 적용됩니다.

• 스키마 진화는 CDC를 업데이트 방법으로 사용하는 경우에만 지원됩니다.

• 스키마 진화 설정을 변경한 경우 작업을 다시 준비해야 합니다.

• 테이블 이름을 바꾸면 스키마 진화가 지원되지 않습니다. 이 경우 작업을 준비하기 전에 메타데이터를 새로 고쳐야 합니다.

• 작업을 디자인하는 경우 스키마 진화 변경 사항을 적용하려면 브라우저를 새로 고쳐야 합니다. 변경 내용에 대해 알림을 받도록 설정할 수 있습니다.

• 랜딩 작업에서는 열을 삭제하는 것이 지원되지 않습니다. 열을 삭제하고 추가하면 테이블 오류가 발생합니다.

• 랜딩 작업에서 테이블 삭제 작업을 수행해도 테이블이 삭제되지 않습니다. 테이블을 삭제한 다음 다시 테이블을 추가하면 기존 테이블만 잘리고, 새 테이블이 추가되지 않습니다.

• 대상 데이터베이스의 지원 여부에 따라, 일부 대상에서는 열 길이를 변경할 수 없습니다.

• 열 이름이 변경되는 경우, 해당 열을 사용하여 정의된 명시적 변환은 열 이름을 기반으로 하므로 적용되지 않습니다.

• 메타데이터 새로 고침에 대한 제한은 스키마 진화에도 적용됩니다.

• 작업에 아직 준비되지 않은 디자인 변경 사항이 포함되어 있고 작업 실행 시 소스 스키마 진화 변경 사항이 감지되면 충돌을 방지하기 위해 작업이 중지됩니다. 보류 중인 디자인 변경 사항을 준비하고 작업을 다시 실행합니다.

DDL 변경 사항을 캡처할 때 다음과 같은 제한이 적용됩니다.

• 소스 데이터베이스에서 빠른 일련의 작업(예: DDL>DML>DDL)이 발생하는 경우 Qlik Talend Data Integration이 잘못된 순서로 로그를 구문 분석하여 데이터가 누락되거나 예측할 수 없는 동작이 발생할 수 있습니다. 이러한 동작이 발생할 가능성을 최소화하려면 다음 작업을 수행하기 전에 대상에 변경 사항이 적용될 때까지 기다리는 것이 가장 좋습니다.

  예를 들어, 변경 사항을 캡처하는 동안 원본 테이블 이름이 빠르게 여러 번 연속해서 바뀌고 두 번째 작업에서 원래 이름으로 다시 바뀌는 경우, 해당 테이블이 대상 데이터베이스에 이미 존재한다는 오류가 발생할 수 있습니다.

• 작업에서 사용된 테이블의 이름을 변경한 다음 작업을 중지하면 Qlik Talend Data Integration은 작업이 다시 시작된 후에 해당 테이블에 적용된 변경 사항을 캡처하지 않습니다.

• 작업이 중지된 동안에는 소스 테이블의 이름을 바꾸는 것이 지원되지 않습니다.

• 테이블의 기본 키 열 재할당은 지원되지 않습니다(따라서 DDL 기록 제어 테이블에 기록되지 않음).
• 열의 데이터 유형이 변경되고 작업이 중지된 상태에서 (동일한) 열의 이름이 변경되면, DDL 변경 사항은 DDL 기록 제어 테이블에 "열 삭제"로 표시되고 작업이 다시 시작되면 "열 추가"로 표시됩니다. 장시간 지연으로 인해 동일한 동작이 발생할 수도 있습니다.
• 작업이 중지된 동안 소스에서 수행된 CREATE TABLE 작업은 작업이 다시 시작될 때 대상에 적용되지만 DDL 기록 제어 테이블에 DDL로 기록되지 않습니다.

• 메타데이터 변경 사항과 관련된 작업(ALTER TABLE, reorg, 클러스터링된 인덱스 다시 빌드 등)은 다음 중 하나에서 수행되는 경우 예측할 수 없는 동작이 발생할 수 있습니다.

  • 전체 로드 중

    -또는-

  • 변경 내용 처리 시작 타임스탬프와 현재 시간(즉, 사용자가 고급 실행 옵션 대화 상자에서 확인을 클릭하는 순간) 사이.

    예:

    IF:

    지정된 변경 사항 처리 시작 시간은 오전 10시입니다.

    AND:

    Age라는 열이 오전 10시 10분에 Employees 테이블에 추가되었습니다.

    AND:

    사용자가 오전 10시 15분에 고급 실행 옵션 대화 상자에서 확인을 클릭합니다.

    THEN:

    10:00과 10:10 사이에 발생한 변경 사항으로 인해 CDC 오류가 발생할 수 있습니다.

  정보 메모

  위의 어떤 경우든 영향을 가져오는 테이블을 다시 로드하여 데이터가 대상에 제대로 이동됨되도록 해야 합니다.

• DDL 문 ALTER TABLE ADD/MODIFY <column> <data_type> DEFAULT <>는 기본값을 대상에 복제하지 않으며 새 열 또는 수정된 열이 NULL로 설정됩니다. 과거에 열을 추가하거나 수정한 DDL이 실행된 경우에도 이런 동작이 발생할 수 있습니다. 새 열 또는 수정된 열이 Null 허용인 경우 소스 엔드포인트는 DDL 자체를 로깅하기 전에 모든 테이블 행을 업데이트합니다. 결과적으로 Qlik Talend Data Integration은 변경 사항을 캡처하지만 대상을 업데이트하지 않습니다. 새 열 또는 수정된 열이 NULL로 설정되어 대상 테이블에 기본 키 또는 고유 인덱스가 없는 경우, 후속 업데이트에서 "영향 받는 행 없음"이라는 메시지가 생성됩니다.

• TIMESTAMP 및 DATE 정밀도 열에 대한 수정 사항은 캡처되지 않습니다.

자동으로 적용되지 않는 변경 사항 처리

이 섹션에서는 대상에 적용할 수 없는 변경 사항(즉, 작업이 무시, 일시 중지 또는 태스크 중지인 경우)을 처리하는 방법을 설명합니다.

열 제거

기록이 활성화된 스토리지 데이터 태스크에서 소비하는 열을 삭제하는 경우, 기록을 보존하고 데이터 손실 가능성을 방지하려면 다음 단계를 따라야 합니다.

1. 랜딩 데이터 태스크를 중지합니다.

2. 모든 랜딩 데이터를 읽었는지 확인하기 위해 스토리지 데이터 태스크를 실행합니다.

3. 랜딩에서 열을 삭제합니다.

4. 랜딩 데이터 태스크를 실행합니다.

5. 스토리지에서 기본 식(Null 또는 기본값)을 사용하여 열을 추가하거나 열을 삭제합니다.

작업 정보 보기

메뉴 막대에서 를 클릭하여 작업 정보를 볼 수 있습니다(예:).

• 소유자

• 공간

• 데이터 플랫폼

• 프로젝트 ID

• 데이터 작업 런타임 ID

소스 연결 또는 데이터 게이트웨이 변경

소스 연결 또는 소스 데이터 게이트웨이를 변경하는 경우 모든 테이블을 다시 생성해야 합니다.

랜딩 영역 유지 관리

랜딩 영역의 자동 정리는 지원되지 않습니다. 이는 성능에 영향을 미칠 수 있습니다.
랜딩 영역에서 오래된 전체 로드 데이터의 수동 정리를 수행하는 것이 좋습니다.

• Qlik Cloud(via Amazon S3)

  전체 로드 데이터 폴더가 여러 개 있는 경우 가장 최근 폴더를 제외하고 모두 삭제할 수 있습니다. 처리된 변경 데이터 파티션을 삭제할 수도 있습니다.

• 클라우드 데이터 웨어하우스

  처리된 전체 로드 및 변경 테이블 레코드를 삭제할 수 있습니다.

권장 사항

• 소스 테이블의 기본 키를 업데이트할 수 있는 경우, 변경 처리 튜닝에서 기본 키 열을 업데이트할 때 삭제 및 삽입 옵션을 활성화합니다.

제한 사항

• 8000바이트보다 긴 varchar 데이터 또는 4000바이트보다 긴 Nvarchar 데이터 복제는 지원되지 않습니다.

• 이동된 열에서는 직접 변경하거나 변환 규칙을 사용하는 등 null 허용 여부 변경이 지원되지 않습니다. 그러나 태스크에서 생성된 새 열은 기본적으로 null을 허용합니다.

• CLOB 및 BLOB 유형의 소스 열은 소스에서 null을 허용하지 않는 것으로 표시되어 있더라도 기본적으로 null을 허용하도록 설정됩니다. null을 허용하지 않도록 변경할 수 있지만, 소스에서 null로 도착하는 경우에 대비하여 null이 아닌 값을 추가하는 식을 추가해야 합니다. 이는 삭제된 레코드에서 발생할 수 있습니다.

변환에는 다음과 같은 제한이 적용됩니다.

• 오른쪽에서 왼쪽으로 쓰는 언어가 있는 열에는 변환이 지원되지 않습니다.

• 이름에 특수 문자(예: #, \, /, -)가 포함된 열에는 변환을 수행할 수 없습니다.

• LOB/CLOB 데이터 유형에 대해 지원되는 유일한 변환은 대상에서 열을 삭제하는 것입니다.
• 변환을 사용하여 열 이름을 바꾼 다음 같은 이름의 새 열을 추가하는 것은 지원되지 않습니다.