Disnidificazione dello schema

Quando ti integri con i servizi di analisi tramite Zero-ETL, puoi scegliere in che modo le strutture annidate vengono rappresentate nelle tabelle di destinazione. AWS Glue Zero-ETL offre opzioni di unnesting dello schema per appiattire strutture di dati complesse in formati più intuitivi per l'analisi.

Opzioni di disnidificazione

Quando si crea un'integrazione Zero-ETL con un'origine, è possibile scegliere tra le seguenti opzioni di disnidificazione. Queste opzioni corrispondono a valori di enumerazione specifici che utilizzerai per chiamare l'API. CreateIntegrationTableProperty Per tutte le opzioni non necessarie, passeremmo alla maggior parte del livello interno e mapperemmo il tipo DDB per indirizzarlo al tipo primitivo con il massimo sforzo. spark/iceberg La mappatura dei tipi tra il DDB di origine e la tabella di destinazione è la seguente:

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",
      }
  }'

Esempi di disnidificazione

Si consideri un elemento di DynamoDB con la seguente struttura:

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

Esempio NO_UNNEST

Con NO_UNNEST, l'intera riga viene memorizzata all'interno di una colonna più la chiave primaria. Le informazioni sul tipo DynamoDB vengono conservate. Ciò mantiene la compatibilità con i pattern di interrogazione di Redshift.

Tabella Iceberg risultante (supponendo che col_1 sia la chiave primaria):

{
  "col_2": {
    "M": {
      "col_3": {
        "M": {
          "id": {
            "S": "value_3"
          }
        }
      },
      "col_4": {
        "BOOL": true
      }
    }
  }
}

Le query dovrebbero utilizzare modelli di accesso a strutture e array:

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

Esempio TOP_LEVEL

Con TOP_LEVEL, solo i campi di primo livello non vengono annidati, mantenendo intatti i campi nidificati come strutture. Le informazioni sul tipo DynamoDB vengono rimosse e la digitazione viene mantenuta. Converte in tipo stringa quando si verificano conflitti di schema.

Tabella Glue risultante dopo la replica:

{
  "col_3": {
    "id": "value_3"
  },
  "col_4": true
}

Le query sarebbero semplificate per il primo livello:

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

Esempio COMPLETO

Con l'unnesting FULL, sia i campi di primo livello che i campi nidificati vengono appiattiti. struct/map La notazione a punti viene utilizzata per i campi annidati (ad esempio, «col_2.col_3.id»). Gli elementi dell'array rimangono non annidati. Ogni nodo foglia diventa una colonna di primo livello.

Tabella Glue risultante dopo la replica:

Le query verrebbero completamente appiattite:

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