# 스키마 중첩 해제
<a name="zero-etl-ddb-schema-unnesting"></a>

 제로 ETL을 통해 분석 서비스와 통합할 때 대상 테이블에 중첩 구조가 표시되는 방식을 선택할 수 있습니다. AWS Glue 제로 ETL은 복잡한 데이터 구조를 분석에 더 적합한 형식으로 평면화하기 위해 스키마 중첩 해제 옵션을 제공합니다.

## 중첩 해제 옵션
<a name="unnesting-options"></a>

 소스와 제로 ETL 통합을 생성할 때 다음의 중첩 해제 옵션 중에서 선택할 수 있습니다. 이러한 옵션은 CreateIntegrationTableProperty API를 호출할 때 사용하는 특정 열거 값에 해당합니다. 모든 중첩 해제 옵션의 경우 가장 안쪽 계층까지 이동하고 최선의 노력을 기울여 DDB 유형을 대상 spark/iceberg 프리미티브 유형에 매핑합니다. 소스 DDB와 대상 테이블 간의 유형 매핑은 아래와 같습니다.


| DDB 소스 데이터 형식 | 대상 테이블 데이터 형식 | 
| --- | --- | 
| "S" | StringType | 
| "B" | BinaryType | 
| "N" | DoubleType | 
| "BOOL" | BooleanType | 
| "SS" | ArrayType(StringType) | 
| "NS" | ArrayType(DoubleType) | 
| "BS" | ArrayType(BinaryType) | 
| "L" | ArrayType(StringType) | 
| "NULL" | 무시 | 
| "M" | StructType(TOP/NOUNNEST) | 

중첩 해제 없음 - NO\_UNNEST  
 **API 값: `NO_UNNEST`**   
 Amazon DynamoDB 항목의 원래 중첩 구조를 보존합니다. 맵 및 목록은 대상에 구조화된 열로 저장됩니다.  
 최적의 용도: 분석 도구가 중첩된 데이터를 처리할 수 있는 경우 Amazon DynamoDB 데이터의 정확한 구조를 보존하는 데 가장 적합합니다.

최상위 수준 - TOP\_LEVEL  
 **API 값: `TOP_LEVEL`**   
 중첩 맵의 최상위 수준을 개별 열로 평면화합니다. 목록 구조는 중첩 상태로 유지됩니다.  
 최적의 용도: 분석 도구가 DDB 유형 정보가 모두 제거된 중첩된 데이터를 처리할 수 있는 경우 Amazon DynamoDB 데이터의 정확한 구조를 보존하는 데 가장 적합합니다.  
 최적의 용도: Amazon DynamoDB 테이블 항목에 일관된 스키마가 있는 경우 데이터 구조의 보존과 쿼리 단순성 사이의 균형을 맞추는 데 가장 적합합니다.

모든 수준 중첩 해제 - FULL(기본값)  
 **API 값: `FULL`**   
 모든 중첩 구조(맵 및 목록)를 점 표기법을 사용하여 개별 열로 재귀적으로 평면화하고 이름을 지정합니다.  
 최적의 용도: 심층 중첩 구조와 평평한 스키마를 선호하는 분석 도구와 함께 작업하는 경우 쿼리 단순화를 극대화하는 데 가장 적합합니다.  
 DynamoDB 데이터에 변동 가능 또는 심층 중첩 구조가 있다면 완전한 중첩 해제로 인해 매우 넓은 테이블과 많은 열이 생성될 수 있습니다.

**Example API에서 중첩 해제 옵션 사용**  
 CreateIntegrationTableProperty API를 통해 스키마 중첩 해제를 구성할 때 UnnestSpec 파라미터에서 중첩 해제 옵션을 지정합니다.  

```
aws glue create-integration-table-property 
  --resource-arn "arn:aws:glue:us-east-1:123456789012:database/my_db" 
  --table-name "my-table" 
  --cli-input-json '{
      "TargetTableConfig": {
          "UnnestSpec": "FULL",
          "TargetTableName": "my-target-table",
      }
  }'
```

## 중첩 해제 예제
<a name="unnesting-examples"></a>

 다음 구조가 있는 DynamoDB 항목을 고려하세요.

```
// Input DynamoDB Record
{
  "Item": {
    "col_1": {
      "S": "value_1"
    },
    "col_2": {
      "M": {
        "col_3": {
          "M": {
            "id": {
              "S": "value_3"
            }
          }
        },
        "col_4": {
          "BOOL": true
        }
      }
    }
  }
}
```

### NO\_UNNEST 예제
<a name="no-unnesting-example"></a>

 NO\_UNNEST를 사용하면 전체 행이 하나의 열과 프라이머리 키 내에 저장됩니다. DynamoDB 유형 정보는 보존됩니다. 이렇게 하면 Redshift 쿼리 패턴과의 호환성이 유지됩니다.

결과 Iceberg 테이블(col\_1이 프라이머리 키라고 가정):


| col\_1(문자열) | 값(구조체) | 
| --- | --- | 
| value\_1 | <pre>{<br />  "col_2": {<br />    "M": {<br />      "col_3": {<br />        "M": {<br />          "id": {<br />            "S": "value_3"<br />          }<br />        }<br />      },<br />      "col_4": {<br />        "BOOL": true<br />      }<br />    }<br />  }<br />}</pre> | 

쿼리는 구조체와 배열 액세스 패턴을 사용해야 합니다.

```
SELECT 
  value.col_1,
  value.col_2.M.col_3.M.id.S,
  value.col_2.M.col_4.BOOL
FROM product_table;
```

### TOP\_LEVEL 예제
<a name="unnest-one-level-example"></a>

 TOP\_LEVEL을 사용하면 중첩된 필드를 구조체로 그대로 유지하면서 최상위 필드만 중첩 해제됩니다. DynamoDB 유형 정보가 제거되고 입력이 유지됩니다. 스키마 충돌이 발생할 때 문자열 유형으로 변환합니다.

복제 후 결과 Glue 테이블:


| col\_1(문자열) | col\_2(구조체) | 
| --- | --- | 
| value\_1 | <pre>{<br />  "col_3": {<br />    "id": "value_3"<br />  },<br />  "col_4": true<br />}</pre> | 

첫 번째 수준에서는 쿼리가 간소화됩니다.

```
SELECT 
  col_1, 
  col_2.col_3.id,
  col_2.col_4
FROM product_table;
```

### FULL 예제
<a name="unnest-all-levels-example"></a>

 FULL 중첩 해제를 사용하면 최상위 필드와 중첩된 구조체/맵 필드가 모두 평면화됩니다. 중첩된 필드에 점 표기법이 사용됩니다(예: "col\_2.col\_3.id"). 배열 요소는 중첩 해제 상태로 유지됩니다. 각 리프 노드는 최상위 열이 됩니다.

복제 후 결과 Glue 테이블:


| col\_1(문자열) | col\_2.col\_3.id(문자열) | col\_2.col\_4(부울) | 
| --- | --- | --- | 
| value\_1 | value\_3 | TRUE | 

쿼리는 완전히 평면화됩니다.

```
SELECT 
  col_1, 
  "col_2.col_3.id",
  "col_2.col_4"
FROM product_table;
```