복사 작업 성능 문제 해결

  • 아티클

적용 대상: Azure Data Factory Azure Synapse Analytics

팁

기업용 올인원 분석 솔루션인 Microsoft Fabric의 Data Factory를 사용해 보세요. Microsoft Fabric은 데이터 이동부터 데이터 과학, 실시간 분석, 비즈니스 인텔리전스 및 보고에 이르기까지 모든 것을 다룹니다. 무료로 새 평가판을 시작하는 방법을 알아봅니다!

이 문서에서는 Azure Data Factory의 복사 작업 성능 문제를 해결하는 방법을 간략하게 설명합니다.

복사 작업을 실행한 후 복사 작업 모니터링 보기에서 실행 결과 및 성능 통계를 수집할 수 있습니다. 예를 들면 다음과 같습니다.

Monitor copy activity run details

성능 튜닝 팁

일부 시나리오에서는 복사 작업을 실행할 때 위 예제에서 보이는 것과 같이 맨 위에 "성능 튜닝 팁"이 표시됩니다. 팁은 복사 처리량을 높이는 방법에 대한 제안과 함께 이 특정 복사 실행에 대해 서비스에서 식별한 병목 상태를 알려줍니다. 권장 사항을 변경한 후 복사를 다시 실행합니다.

참고로 현재 성능 튜닝 팁은 다음과 같은 경우에 대한 제안을 제공합니다.

범주 성능 튜닝 팁
데이터 저장소 관련 Azure Synapse Analytics에 데이터 로드: PolyBase 또는 COPY 문을 사용하지 않는 경우 사용하는 것이 좋습니다.
  Azure SQL Database에서/로 데이터 복사: DTU 사용률이 높은 경우 더 높은 계층으로 업그레이드하는 것이 좋습니다.
  Azure Cosmos DB에서/로 데이터 복사: RU 사용률이 높은 경우 더 큰 RU로 업그레이드하는 것이 좋습니다.
SAP 테이블에서 데이터 복사: 대량의 데이터를 복사할 때 SAP 커넥터의 파티션 옵션을 활용하여 병렬 로드를 사용하도록 설정하고 최대 파티션 수를 늘리는 것이 좋습니다.
  Amazon Redshift에서 데이터 수집: UNLOAD를 사용하지 않는 경우 사용하는 것이 좋습니다.
데이터 저장소 제한 복사하는 동안 많은 읽기/쓰기 작업이 데이터 저장소에 의해 제한되는 경우 검사 제안하고 데이터 저장소에 허용되는 요청 속도를 높이거나 동시 워크로드를 줄입니다.
통합 런타임 자체 호스팅 IR(Integration Runtime)을 사용하고 복사 작업이 IR에서 실행할 수 있는 리소스가 나올 때까지 큐에서 오래 대기하는 경우 IR을 확장/확장하는 것이 좋습니다.
  최적이 아닌 영역에 있는 Azure Integration Runtime을 사용하여 읽기/쓰기 속도가 느려지는 경우 다른 지역에서 IR을 사용하도록 구성하는 것이 좋습니다.
내결함성 내결함성을 구성하고 호환되지 않는 행을 건너뛰면 성능이 저하되는 경우 원본 및 싱크 데이터가 호환되는지 확인하는 것이 좋습니다.
준비된 복사 준비된 복사본이 구성되었지만 원본 싱크 쌍에 유용하지 않은 경우 제거를 제안합니다.
Resume 복사 작업이 마지막 실패 지점에서 다시 시작되지만 원래 실행 후 DIU 설정을 변경하면 새 DIU 설정이 적용되지 않습니다.

복사 작업 실행 세부 정보 이해

복사 작업 모니터링 보기의 맨 아래에 있는 실행 세부 정보 및 기간은 복사 작업이 진행하는 주요 단계(이 문서의 시작 부분에 있는 예제 참조)를 설명합니다. 이는 복사 성능 문제를 해결하는 데 특히 유용합니다. 복사 실행의 병목 상태는 기간이 가장 긴 병목 현상입니다. 각 단계의 정의에 대한 다음 표를 참조하고 Azure IR 의 복사 작업 문제를 해결하고 이러한 정보를 사용하여 자체 호스팅 IR에서 복사 작업 문제를 해결하는 방법을 알아봅니다.

단계 설명
Queue 복사 작업이 통합 런타임에서 실제로 시작될 때까지 경과된 시간입니다.
사전 복사 스크립트 IR에서 시작하는 복사 작업과 싱크 데이터 저장소에서 사전 복사 스크립트 실행을 완료하는 복사 작업 사이의 경과된 시간입니다. 데이터베이스 싱크에 대한 사전 복사 스크립트를 구성할 때 적용합니다. 예를 들어 Azure SQL Database에 데이터를 쓸 때 새 데이터를 복사하기 전에 클린 수행합니다.
이전 이전 단계의 끝과 원본에서 싱크로 모든 데이터를 전송하는 IR 사이의 경과된 시간입니다.
전송 중인 하위 단계가 병렬로 실행되며 일부 작업은 이제 파일 형식 구문 분석/생성과 같이 표시되지 않습니다.

- 첫 번째 바이트까지의 시간: 이전 단계의 끝과 IR이 원본 데이터 저장소에서 첫 번째 바이트를 수신하는 시간 사이에 경과된 시간입니다. 파일 기반이 아닌 원본에 적용됩니다.
- 원본 나열: 소스 파일 또는 데이터 파티션을 열거하는 데 소요된 시간입니다. 후자는 Oracle/SAP HANA/Teradata/Netezza/etc와 같은 데이터베이스에서 데이터를 복사하는 경우와 같이 데이터베이스 원본에 대한 파티션 옵션을 구성할 때 적용됩니다.
-원본에서 읽기: 원본 데이터 저장소에서 데이터를 검색하는 데 소요된 시간입니다.
- 싱크에 쓰기: 싱크 데이터 저장소에 데이터를 쓰는 데 소요된 시간입니다. 현재 Azure AI Search, Azure Data Explorer, Azure Table Storage, Oracle, SQL Server, Common Data Service, Dynamics 365, Dynamics CRM, Salesforce/Salesforce Service Cloud를 비롯한 일부 커넥터에는 이 메트릭이 없습니다.

Azure IR에서 복사 작업 문제 해결

성능 튜닝 단계에 따라 시나리오에 대한 성능 테스트를 계획하고 수행합니다.

복사 작업 성능이 예상을 충족하지 못하는 경우 Azure Integration Runtime에서 실행되는 단일 복사 활동의 문제를 해결하려면 복사 모니터링 보기에 성능 튜닝 팁이 표시되면 제안을 적용하고 다시 시도하세요. 그렇지 않으면 복사 작업 실행 세부 정보를 이해하고, 기간이 가장 긴 단계를 검사 다음 지침을 적용하여 복사 성능을 향상시킵니다.

  • "사전 복사 스크립트"는 긴 기간을 경험했습니다. 즉, 싱크 데이터베이스에서 실행되는 사전 복사 스크립트를 완료하는 데 시간이 오래 걸립니다. 지정된 사전 복사 스크립트 논리를 조정하여 성능을 향상시킵니다. 스크립트 개선에 대한 추가 도움이 필요한 경우 데이터베이스 팀에 문의하세요.

  • ‘전송 - 첫 번째 바이트까지의 시간’에 긴 작업 시간 발생: 즉, 원본 쿼리가 데이터를 반환하는 데 시간이 오래 걸린다는 것을 의미합니다. 쿼리 또는 서버를 확인하고 최적화합니다. 추가 도움이 필요하면 데이터 저장소 팀에 문의하세요.

  • "전송 - 원본 나열" 작업 기간이 길어짐: 원본 파일 또는 원본 데이터베이스 데이터 파티션을 열거하는 속도가 느리다는 것을 의미합니다.

    • 파일 기반 소스에서 데이터를 복사할 때 폴더 경로 또는 파일 이름(wildcardFolderPath 또는 wildcardFileName)에 와일드 카드 필터를 사용하거나 파일의 마지막 수정 시간 필터(modifiedDatetimeStart 또는 modifiedDatetimeEnd)를 사용하는 경우 해당 필터는 지정된 폴더 아래의 모든 파일을 클라이언트 쪽으로 복사 활동을 나열하게 한 다음 필터를 적용합니다. 이러한 파일 열거형은 특히 작은 파일 집합만 필터 규칙을 충족하는 경우 병목 상태가 될 수 있습니다.

      • datetime 분할된 파일 경로 또는 이름을 기준으로 파일을 복사할 수 있는지 확인합니다. 이러한 방식은 원본 쪽을 나열하는 데 부담을 주지 않습니다.

      • 대신 데이터 저장소의 기본 필터, 특히 Amazon S3/Azure Blob Storage/Azure Files의 경우 ‘prefix’, ADLS Gen1의 경우 ‘listAfter/listBefore’를 사용할 수 있는지 확인합니다. 이러한 필터는 데이터 저장소 서버 쪽 필터이며 훨씬 더 나은 성능을 제공합니다.

      • 큰 데이터 집합 하나를 작은 데이터 집합 여러 개로 분할하고 이러한 복사 작업이 데이터의 각 부분을 동시에 실행하는 것을 고려하세요. Lookup/GetMetadata + ForEach + Copy를 사용하여 이 작업을 수행할 수 있습니다. 일반적인 예로 여러 컨테이너에서 파일 복사 또는 Amazon S3에서 ADLS Gen2 솔루션 템플릿으로 데이터 마이그레이션을 참조하세요.

    • 서비스에서 원본에 대한 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

    • 원본 데이터 저장소 지역과 동일하거나 가까운 지역에서 Azure IR을 사용합니다.

  • "전송 - 원본에서 읽기"는 긴 작업 기간을 경험했습니다.

    • 적용되는 경우 커넥터별 데이터 로드 모범 사례를 채택합니다. 예를 들어 Amazon Redshift에서 데이터를 복사할 때 Redshift UNLOAD를 사용하도록 구성합니다.

    • 서비스가 원본에서 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

    • 복사 원본 및 싱크 패턴을 확인합니다.

    • 원본 데이터 저장소 지역과 동일하거나 가까운 지역에서 Azure IR을 사용합니다.

  • “전송 - 싱크에 쓰기”에서 긴 작업 기간 발생:

    • 적용되는 경우 커넥터별 데이터 로드 모범 사례를 채택합니다. 예를 들어 Azure Synapse Analytics에 데이터를 복사하는 경우 PolyBase 또는 COPY 문을 사용합니다.

    • 서비스가 싱크에서 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

    • 복사 원본 및 싱크 패턴을 확인합니다.

      • 복사 패턴이 4개 이상의 DIU(데이터 통합 단위)를 지원하는 경우, 자세한 내용은 이 섹션을 참조하세요. 일반적으로 DIU를 늘려 성능을 향상시킬 수 있습니다.

      • 그렇지 않으면 병렬 복사본을 점진적으로 조정합니다. 병렬 복사본이 너무 많으면 성능이 저하될 수 있습니다.

    • 싱크 데이터 저장소 지역과 동일하거나 가까운 지역에서 Azure IR을 사용합니다.

자체 호스팅 IR에서 복사 작업 문제 해결

성능 튜닝 단계에 따라 시나리오에 대한 성능 테스트를 계획하고 수행합니다.

복사 성능이 기대에 미치지 못하는 경우 Azure Integration Runtime에서 실행되는 단일 복사 작업의 문제를 해결하려면 복사 모니터링 보기에 성능 튜닝 팁이 표시되는 경우 제안을 적용하고 다시 시도하세요. 그렇지 않으면 복사 작업 실행 세부 정보를 이해하고, 기간이 가장 긴 단계를 검사 다음 지침을 적용하여 복사 성능을 향상시킵니다.

  • "큐"에 긴 기간이 발생했습니다. 이는 자체 호스팅 IR에서 실행할 리소스가 될 때까지 복사 작업이 큐에서 오래 대기한다는 것을 의미합니다. IR 용량 및 사용량을 확인하고 워크로드에 따라 확장 또는 확장 합니다.

  • ‘전송 - 첫 번째 바이트까지의 시간’에 긴 작업 시간 발생: 즉, 원본 쿼리가 데이터를 반환하는 데 시간이 오래 걸린다는 것을 의미합니다. 쿼리 또는 서버를 확인하고 최적화합니다. 추가 도움이 필요하면 데이터 저장소 팀에 문의하세요.

  • "전송 - 원본 나열" 작업 기간이 길어짐: 원본 파일 또는 원본 데이터베이스 데이터 파티션을 열거하는 속도가 느리다는 것을 의미합니다.

    • 자체 호스팅 IR 머신이 원본 데이터 저장소에 연결하는 대기 시간이 짧은지 확인합니다. 원본이 Azure에 있는 경우 이 도구를 사용하여 자체 호스팅 IR 컴퓨터에서 Azure 지역으로 대기 시간을 검사 수 있습니다.

    • 파일 기반 소스에서 데이터를 복사할 때 폴더 경로 또는 파일 이름(wildcardFolderPath 또는 wildcardFileName)에 와일드 카드 필터를 사용하거나 파일의 마지막 수정 시간 필터(modifiedDatetimeStart 또는 modifiedDatetimeEnd)를 사용하는 경우 해당 필터는 지정된 폴더 아래의 모든 파일을 클라이언트 쪽으로 복사 활동을 나열하게 한 다음 필터를 적용합니다. 이러한 파일 열거형은 특히 작은 파일 집합만 필터 규칙을 충족하는 경우 병목 상태가 될 수 있습니다.

      • datetime 분할된 파일 경로 또는 이름을 기준으로 파일을 복사할 수 있는지 확인합니다. 이러한 방식은 원본 쪽을 나열하는 데 부담을 주지 않습니다.

      • 대신 데이터 저장소의 기본 필터, 특히 Amazon S3/Azure Blob Storage/Azure Files의 경우 ‘prefix’, ADLS Gen1의 경우 ‘listAfter/listBefore’를 사용할 수 있는지 확인합니다. 이러한 필터는 데이터 저장소 서버 쪽 필터이며 훨씬 더 나은 성능을 제공합니다.

      • 큰 데이터 집합 하나를 작은 데이터 집합 여러 개로 분할하고 이러한 복사 작업이 데이터의 각 부분을 동시에 실행하는 것을 고려하세요. Lookup/GetMetadata + ForEach + Copy를 사용하여 이 작업을 수행할 수 있습니다. 일반적인 예로 여러 컨테이너에서 파일 복사 또는 Amazon S3에서 ADLS Gen2 솔루션 템플릿으로 데이터 마이그레이션을 참조하세요.

    • 서비스에서 원본에 대한 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

  • "전송 - 원본에서 읽기"는 긴 작업 기간을 경험했습니다.

    • 자체 호스팅 IR 머신이 원본 데이터 저장소에 연결하는 대기 시간이 짧은지 확인합니다. 원본이 Azure에 있는 경우 이 도구를 사용하여 자체 호스팅 IR 컴퓨터에서 Azure 지역으로 대기 시간을 검사 수 있습니다.

    • 자체 호스팅 IR 시스템에 데이터를 효율적으로 읽고 전송할 수 있는 충분한 인바운드 대역폭이 있는지 확인합니다. 원본 데이터 저장소가 Azure에 있는 경우 이 도구를 사용하여 다운로드 속도를 확인할 수 있습니다.

    • Azure Portal -> 데이터 팩터리 또는 Synapse 작업 영역 -> 개요 페이지에서 자체 호스팅 IR의 CPU 및 메모리 사용량 추세를 확인합니다. CPU 사용량이 높거나 사용 가능한 메모리가 낮은 경우 IR을 확장/스케일 아웃하는 것이 좋습니다.

    • 적용되는 경우 커넥터별 데이터 로드 모범 사례를 채택합니다. 예시:

    • 서비스가 원본에서 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

    • 복사 원본 및 싱크 패턴을 확인합니다.

  • “전송 - 싱크에 쓰기”에서 긴 작업 기간 발생:

    • 적용되는 경우 커넥터별 데이터 로드 모범 사례를 채택합니다. 예를 들어 Azure Synapse Analytics에 데이터를 복사하는 경우 PolyBase 또는 COPY 문을 사용합니다.

    • 자체 호스팅 IR 머신이 싱크 데이터 저장소에 연결하는 대기 시간이 짧은지 확인합니다. 싱크가 Azure에 있는 경우 이 도구를 사용하여 자체 호스팅 IR 시스템에서 Azure 지역까지의 대기 시간을 확인할 수 있습니다. 이는 적을수록 좋습니다.

    • 자체 호스팅 IR 머신에 데이터를 효율적으로 전송하고 쓰기에 충분한 아웃바운드 대역폭이 있는지 확인합니다. 싱크 데이터 저장소가 Azure에 있는 경우 이 도구를 사용하여 업로드 속도를 검사 수 있습니다.

    • Azure Portal -> 데이터 팩터리 또는 Synapse 작업 영역 -> 개요 페이지에서 자체 호스팅 IR의 CPU 및 메모리 사용량 추세를 확인합니다. CPU 사용량이 높거나 사용 가능한 메모리가 낮은 경우 IR을 확장/스케일 아웃하는 것이 좋습니다.

    • 서비스가 싱크에서 제한 오류를 보고하는지 또는 데이터 저장소의 사용률이 높은지 확인합니다. 그렇다면 데이터 저장소의 워크로드를 줄이거나 데이터 저장소 관리자에게 문의하여 제한 한도 또는 사용 가능한 리소스를 늘리십시오.

    • 병렬 복사를 점차적으로 조정하는 것이 좋습니다. 병렬 복사가 너무 많으면 성능이 저하될 수도 있습니다.

커넥트or 및 IR 성능

이 섹션에서는 특정 커넥터 유형 또는 통합 런타임에 대한 몇 가지 성능 문제 해결 가이드를 살펴봅니다.

활동 실행 시간은 Azure IR 및 Azure VNet IR을 사용하여 달라집니다.

작업 실행 시간은 데이터 집합이 다른 Integration Runtime을 기반으로 하는 경우에 달라집니다.

  • 증상: 데이터 세트에서 연결된 서비스 드롭다운을 전환하기만 하면 동일한 파이프라인 작업이 수행되지만 런타임은 크게 다릅니다. 데이터 세트가 Managed Virtual Network Integration Runtime을 기반으로 하는 경우 기본 통합 런타임을 기반으로 하는 경우 실행보다 평균 시간이 더 많이 걸립니다.

  • 원인: 파이프라인 실행의 세부 정보를 확인하면 일반 파이프라인이 Azure IR에서 실행되는 동안 느린 파이프라인이 관리형 VNet(Virtual Network) IR에서 실행되고 있음을 확인할 수 있습니다. 기본적으로 관리되는 VNet IR은 서비스 인스턴스당 하나의 컴퓨팅 노드를 예약하지 않으므로 Azure IR보다 더 긴 큐 시간이 소요되므로 각 복사 작업을 시작할 수 있도록 준비되며, 주로 Azure IR이 아닌 VNet 조인에서 발생합니다.

Azure SQL Database에 데이터를 로드할 때 성능 저하

  • 증상: Azure SQL Database에 데이터를 복사하는 속도가 느려집니다.

  • 원인: 문제의 근본 원인은 주로 Azure SQL Database 쪽의 병목 현상에 의해 트리거됩니다. 다음은 몇 가지 가능한 원인입니다.

    • Azure SQL Database 계층이 충분히 높지 않습니다.

    • Azure SQL Database DTU 사용량은 100%에 가깝습니다. 성능을 모니터링하고 Azure SQL Database 계층을 업그레이드하는 것을 고려할 수 있습니다.

    • 인덱스가 올바르게 설정되지 않았습니다. 데이터를 로드하기 전에 모든 인덱스를 제거하고 로드가 완료된 후 다시 만듭니다.

    • WriteBatchSize가 스키마 행 크기에 맞게 충분히 크지 않습니다. 문제에 대한 속성을 확대해 봅니다.

    • 대량 삽입 대신 저장 프로시저를 사용 중이므로 성능이 저하될 것으로 예상됩니다.

큰 Excel 파일을 구문 분석할 때 시간 제한 또는 성능 저하

  • 증상:

    • Excel 데이터 세트를 만들고 연결/저장소, 미리 보기 데이터, 목록 또는 새로 고침 워크시트에서 스키마를 가져올 때 Excel 파일 크기가 큰 경우 시간 제한 오류가 발생할 수 있습니다.

    • 복사 작업을 사용하여 큰 Excel 파일(>= 100MB)에서 다른 데이터 저장소로 데이터를 복사할 때 성능이 저하되거나 OOM 문제가 발생할 수 있습니다.

  • 원인:

    • 스키마 가져오기, 데이터 미리 보기, Excel 데이터 집합에서 워크시트 나열과 같은 작업의 경우 시간 제한이 100초이며 고정적입니다. 큰 Excel 파일의 경우 이러한 작업은 시간 제한 값 내에서 완료되지 않을 수 있습니다.

    • 복사 작업은 전체 Excel 파일을 메모리로 읽은 다음 지정된 워크시트와 셀을 찾아 데이터를 읽습니다. 이 동작은 서비스에서 사용하는 기본 SDK 때문입니다.

  • 해결 방법:

    • 스키마를 가져오기 위해 원본 파일의 하위 집합인 더 작은 샘플 파일을 생성하고 "연결/저장소에서 스키마 가져오기" 대신 "샘플 파일에서 스키마 가져오기"를 선택할 수 있습니다.

    • 워크시트를 나열하는 경우 워크시트 드롭다운에서 "편집"을 클릭하고 대신 시트 이름/인덱스를 입력할 수 있습니다.

    • 큰 Excel 파일(>100MB)을 다른 저장소로 복사하려면 스포츠 스트리밍이 더 잘 읽고 성능을 발휘하는 Data Flow Excel 원본을 사용할 수 있습니다.

큰 JSON/Excel/XML 파일을 읽는 OOM 문제

  • 증상: 큰 JSON/Excel/XML 파일을 읽을 때 작업 실행 중에 OOM(메모리 부족) 문제가 발생합니다.

  • 원인:

    • 큰 XML 파일의 경우: 큰 XML 파일을 읽는 OOM 문제는 의도적으로 설계되었습니다. 그 이유는 전체 XML 파일이 단일 개체이므로 메모리로 읽은 다음 스키마가 유추되고 데이터가 검색되기 때문에 발생합니다.
    • 큰 Excel 파일의 경우: 큰 Excel 파일을 읽는 OOM 문제는 의도적으로 설계되었습니다. 그 이유는 사용된 SDK(POI/NPOI)가 전체 Excel 파일을 메모리로 읽은 다음 스키마를 유추하고 데이터를 가져와야 하기 위해서입니다.
    • 대용량 JSON 파일의 경우: 큰 JSON 파일을 읽는 OOM 문제는 JSON 파일이 단일 개체일 때 디자인된 것입니다.

  • 권장 사항: 다음 옵션 중 하나를 적용하여 문제를 해결합니다.

    • 옵션-1: 강력한 컴퓨터(높은 CPU/메모리)를 사용하여 온라인 자체 호스팅 통합 런타임을 등록하여 복사 작업을 통해 큰 파일에서 데이터를 읽습니다.
    • 옵션-2: 최적화된 메모리 및 큰 크기 클러스터(예: 48코어)를 사용하여 매핑 데이터 흐름 작업을 통해 큰 파일에서 데이터를 읽습니다.
    • 옵션-3: 큰 파일을 작은 파일로 분할한 다음 복사 또는 매핑 데이터 흐름 작업을 사용하여 폴더를 읽습니다.
    • 옵션-4: XML/Excel/JSON 폴더를 복사하는 동안 OOM 문제가 중단되거나 충족되는 경우 파이프라인에서 foreach 작업 + 복사/매핑 데이터 흐름 작업을 사용하여 각 파일 또는 하위 폴더를 처리합니다.
    • 옵션-5: 기타:
      • XML의 경우 메모리 최적화 클러스터에서 Notebook 작업을 사용하여 각 파일에 동일한 스키마가 있는 경우 파일에서 데이터를 읽습니다. 현재 Spark에는 XML을 처리하는 다른 구현이 있습니다.
      • JSON의 경우 매핑 데이터 흐름 원본 아래의 JSON 설정에서 여러 문서 양식(예: 단일 문서, 줄당 문서 및 문서 배열)을 사용합니다. JSON 파일 콘텐츠가 줄당 문서인 경우 메모리가 거의 소비되지 않습니다.

기타 참조

다음은 지원되는 일부 데이터 저장소에 대한 성능 모니터링 및 튜닝 참조입니다.

관련 콘텐츠

다른 복사 작업 문서를 참조하세요.