AWS Glue 크롤러를 실행하면 크롤러가 서로 유사해 보이는 스키마를 포함한 테이블을 여러 개 만듭니다. 크롤러가 스키마를 어떻게 감지하는지 알고 싶습니다.
해결 방법
크롤러에서 스키마 감지
크롤러를 처음 실행할 때, 크롤러는 각 파일의 첫 레코드 1,000개 또는 첫 메가바이트를 읽어 스키마를 추론합니다. 크롤러가 읽는 데이터의 양은 파일 형식과 유효한 레코드의 가용성에 따라 달라집니다. 예를 들어 입력 파일이 JSON 파일인 경우, 크롤러는 파일의 첫 1MB를 읽어 스키마를 추론합니다.
크롤러가 파일의 처음 1MB 내에서 유효한 레코드를 읽은 경우 크롤러는 스키마를 추론합니다. 1MB 이후에도 크롤러가 스키마를 추론할 수 없는 경우, 파일에서 최대 10MB까지 1MB씩 계속 읽습니다.
CSV 파일의 경우, 크롤러가 첫 1,000개의 레코드 또는 첫 1MB의 데이터 중 먼저 나오는 것을 읽습니다. Parquet 파일의 경우 크롤러가 파일에서 스키마를 직접 추론합니다. 크롤러는 모든 하위 폴더 및 파일에서 추론하는 스키마를 비교한 다음, 하나 이상의 테이블을 만듭니다.
크롤러가 테이블을 만들 때, 크롤러는 다음과 같은 요인을 검사합니다.
- 데이터의 형식, 압축 유형 및 포함된 경로가 동일함
- 스키마가 파티션 임계값에서 얼마나 비슷한지 및 다양한 스키마 수
크롤러가 스키마를 유사하다고 간주하려면 다음 조건에 맞아야 합니다.
- 파티션 임계값이 0.7(70%)보다 큽니다.
- 서로 다른 스키마의 최대 수(이 맥락에서는 ‘클러스터’라고도 함)가 5개를 초과하지 않습니다.
크롤러는 폴더 수준에서 스키마를 추론하고 모드 폴더의 스키마를 비교합니다. 비교한 스키마가 70%를 초과하는 파티션 임계값과 일치하는 경우, 크롤러는 해당 스키마를 테이블의 파티션으로 표시합니다. 일치하지 않는 경우, 크롤러는 각 폴더에 대하여 테이블을 만들고 그 결과 테이블 수가 많아집니다.
예제 시나리오
예시 1
다음 예시에서 폴더 DOC-EXAMPLE-FOLDER1에는 파일이 10개 있고, 그중 파일 8개에는 스키마 SCH_A, 나머지 파일 2개에는 스키마 SCH_B가 있습니다.
파일은 다음 예시와 비슷합니다.
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개 있고, 그중 파일 7개에는 스키마 SCH_A가 있고 나머지 파일 3개에는 스키마 SCH_B가 있습니다.
크롤러는 Amazon S3 경로 s3://DOC-EXAMPLE-FOLDER2를 크롤링할 때 파일마다 테이블을 한 개씩 만듭니다. 이는 파일의 70%는 스키마 SCH_A에 속하고 파일의 30%는 스키마 SCH_B에 속하기 때문입니다. 따라서 스키마다 파티션 임계값을 충족하지 않습니다.
참고: 테이블에 관한 정보를 얻으려면 Amazon CloudWatch에서 크롤러 로그를 확인하십시오.
크롤러 옵션
크롤러 동작을 사용자 지정할 때 다음 옵션 중 하나를 선택할 수 있습니다.
관련 정보
크롤러를 사용해 Data Catalog 채우기
크롤러 동작 사용자 지정
분류자 정의 및 관리