AWS Glue 크롤러는 스키마를 어떻게 감지합니까?

최종 업데이트 날짜: 2021년 8월 27일

AWS Glue 크롤러를 실행 중입니다. 스키마가 비슷해 보이지만 크롤러는 여러 테이블을 만들고 있습니다. 내 크롤러가 스키마를 어떻게 감지하는지 알고 싶습니다.

해결 방법

AWS Glue 크롤러를 실행하면 크롤러가 다음을 수행합니다.

  1. 데이터 분류
  2. 데이터를 테이블 또는 파티션으로 그룹화합니다.
  3. AWS Glue 데이터 카탈로그에 메타데이터 쓰기

다음을 검토하여 크롤러를 실행할 때 어떤 일이 발생하는지와 크롤러가 스키마를 감지하는 방법을 알아보십시오.

크롤러 정의

AWS Glue 크롤러를 정의할 때 데이터 형식을 평가하여 스키마를 추론하는 사용자 지정 분류자를 하나 이상 선택할 수 있습니다. 크롤러가 실행되면 데이터 스토어를 성공적으로 인식하는 목록의 첫 번째 분류자가 테이블의 스키마를 만드는 데 사용됩니다. 크롤러를 정의하기 전에 사용자 정의 분류자를 정의합니다. 크롤러가 실행되면 크롤러는 데이터 스토어에서 일치하는 항목을 찾기 위해 정의한 사용자 지정 분류자를 사용합니다. 각 분류자와 일치하면 확실성이 생성됩니다. 처리 중에 분류자가 확실성=1.0을 반환하면 크롤러는 분류자가 올바른 스키마를 만들 수 있다는 것을 100% 확신합니다. 이 경우 크롤러는 다른 분류자 호출을 중지한 다음 사용자 지정 분류자와 일치하는 분류자가 있는 테이블을 만듭니다.

AWS Glue가 100% 확실하게 입력 데이터 형식에 맞는 사용자 지정 분류자를 찾지 못하면 AWS Glue는 기본 제공 분류자를 호출합니다. 기본 제공 분류자는 형식이 일치하면 확실성=1.0을 반환하고, 형식이 일치하지 않으면확실성=0.0을 반환합니다. 확실성=1.0을 반환하는 분류자가 없으면, AWS Glue는 확실성이 가장 높은 분류자의 출력을 사용합니다. 0.0보다 높은 확실성을 반환하는 분류자가 없으면 AWS Glue는 기본 분류 문자열인 알 수 없음을 반환합니다. AWS Glue의 기본 제공 분류자 현재 목록과 해당 분류자가 호출되는 순서는 AWS Glue의 기본 제공 분류자를 참조하십시오.

크롤러의 스키마 감지

첫 번째 크롤러가 실행되는 동안 크롤러는 각 파일의 처음 1,000개의 레코드 또는 첫 메가바이트를 읽어 스키마를 유추합니다. 읽히는 데이터의 양은 파일 형식과 유효한 레코드의 가용성에 따라 다릅니다. 예를 들어 입력 파일이 JSON 파일인 경우 크롤러는 파일의 처음 1MB를 읽어 스키마를 유추합니다. 파일의 처음 1MB 내에서 유효한 레코드를 읽으면 크롤러가 스키마를 유추합니다. 크롤러가 처음 1MB를 읽은 후 스키마를 유추할 수 없는 경우 크롤러는 한 번에 1MB씩 증가시켜, 최대 10MB의 파일을 읽습니다. CSV 파일의 경우 크롤러는 처음 100개의 레코드 또는 처음 1MB의 데이터를 읽습니다. Parquet 파일의 경우 크롤러는 파일에서 직접 스키마를 유추합니다. 크롤러는 모든 하위 폴더와 파일에서 유추된 스키마를 비교한 다음 하나 이상의 테이블을 만듭니다. 크롤러가 테이블을 만들 때 다음 요소를 고려합니다.

  • 데이터가 동일한 형식, 압축 유형 및 포함 경로인지 확인하는 데이터 호환성
  • 파티션 임계값과 서로 다른 스키마의 수 측면에서 스키마가 얼마나 유사한지 확인하기 위한 스키마 유사성

스키마가 비슷한 것으로 간주되려면 다음 조건이 충족되어야 합니다.

  • 파티션 임계값이 0.7(70%) 보다 높다.
  • 서로 다른 스키마(이 맥락에서 “클러스터”라고도 함)의 최대 수가 5를 초과하지 않는다.

크롤러는 폴더 수준에서 스키마를 유추하고 모든 폴더에서 스키마를 비교합니다. 비교되는 스키마가 일치하는 경우, 즉 파티션 임계값이 70% 보다 높으면 스키마가 테이블의 파티션으로 표시됩니다. 일치하지 않으면 크롤러가 각 폴더에 대한 테이블을 생성하여 테이블 수가 더 많아집니다.

예제 시나리오

예 1: DOC-EXAMPLE-FOLDER1 폴더에 10개의 파일, 즉, 스키마가 SCH_A인 파일 8개와 SCH_B인 파일 2개가 있다고 가정합니다.

SHC_A 스키마가 있는 파일이 다음과 유사하다고 가정합니다.

{ "id": 1, "first_name": "John", "last_name": "Doe"}
{ "id": 2, "first_name": "Li", "last_name": "Juan"}

SCH_B 스키마가 있는 파일이 다음과 유사하다고 가정합니다.

{"city":"Dublin","country":"Ireland"}
{"city":"Paris","country":"France"}

크롤러가 Amazon Simple Storage Service(Amazon S3) 경로 s3: //DOC-EXAMPLE-FOLDER1을 크롤링하면 하나의 테이블이 생성됩니다. 이 테이블은 스키마 SCH_A 및 SCH_B의 열로 구성됩니다. 이는 경로에 있는 파일의 80%가 SCH_A 스키마에 속하고 그러한 파일의 20%가 SCH_B 스키마에 속하기 때문입니다. 따라서 파티션 임계값이 충족됩니다. 또한 서로 다른 스키마 수가 클러스터 수를 초과하지 않았으며 클러스터 크기 제한을 초과하지 않습니다.

예 2: DOC-EXAMPLE-FOLDER2 폴더에 10개의 파일, 즉, SCH_A 스키마가 있는 파일 7개, SCH_B 스키마가 있는 파일 3개가 있다고 가정합니다.

크롤러가 Amazon S3 경로 s3://DOC-EXAMPLE-FOLDER2를 크롤링하면 크롤러는 각 파일에 대해 하나의 테이블을 생성합니다. 이는 파일의 70%가 SCH_A 스키마에 속하고 30%가 스키마 SCH_B에 속하기 때문입니다. 즉, 파티션 임계값이 충족되지 않습니다. Amazon CloudWatch에서 크롤러 로그를 확인하여 생성된 테이블에 대한 정보를 얻을 수 있습니다.

크롤러 옵션

  • 단일 스키마 생성: 스키마 유사성을 무시하고 하나의 스키마만 생성하도록 크롤러를 구성하려면 각 S3 경로에 대해 단일 스키마 생성 옵션을 사용합니다. 자세한 내용은 각 Amazon S3 포함 경로에 대해 단일 스키마를 생성하는 방법을 참조하세요. 그러나 크롤러가 데이터 비호환성을 감지하면 크롤러는 여러 테이블을 생성합니다.
  • 테이블 위치 지정: 테이블 레벨 크롤러 옵션을 사용하면 테이블의 위치 및 파티션 생성 방법을 크롤러에게 알릴 수 있습니다. 테이블 수준 값을 지정하면 Amazon S3 버킷에서 해당 절대 수준에서 테이블이 생성됩니다. 콘솔에서 크롤러를 구성할 때 테이블 수준 크롤러 옵션의 값을 지정할 수 있습니다. 값은 테이블 위치(데이터 집합의 절대 수준)를 나타내는 양의 정수여야 합니다. 최상위 폴더의 수준은 1입니다. 예를 들어 mydataset/a/b 경로의 경우 레벨이 3으로 설정된 경우 mydataset/a/b 위치에 테이블이 생성됩니다. 자세한 내용은 테이블 위치 지정 방법을 참조하십시오.

이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요하세요?