Desanidamiento de esquemas

Cuando integra servicios de análisis a través de la integración zero-ETL, puede elegir cómo se representan las estructuras anidadas en las tablas de destino. AWS La integración zero-ETL de Glue proporciona opciones de desanidamiento de esquemas para aplanar estructuras de datos complejas en formatos más sencillos para el análisis.

Opciones de desanidamiento

Cuando crea una integración zero-ETL con un origen, puede elegir entre las siguientes opciones de desanidamiento. Estas opciones corresponden a valores de enumeración específicos que utilizará cuando llame a la API CreateIntegrationTableProperty. Para todas las opciones de anulación de la anidación, iríamos hasta la la capa más interior y asignaríamos el tipo DDB al tipo primitivo de spark o iceberg de destino con todo nuestro esfuerzo. El tipo de asignación entre la DDB de origen y la tabla de destino es el siguiente:

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

Ejemplos de desanidamiento

Considere un elemento de DynamoDB con la siguiente estructura:

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

Ejemplo de NO_UNNEST

Con NO_UNNEST, toda la fila se almacena en una columna más la clave principal. Se conserva la información de tipos de DynamoDB. Esto mantiene la compatibilidad con los patrones de consulta de Redshift.

Tabla Iceberg resultante (suponiendo que col_1 sea la clave principal):

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

Las consultas necesitarían usar patrones de acceso a estructuras y matrices:

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

Ejemplo de TOP_LEVEL

Con TOP_LEVEL, solo se deshacen los campos de nivel superior y se mantienen intactos los campos anidados como estructuras. Se quita la información de tipo de DynamoDB y se mantiene la escritura. Se convierte a tipo cadena cuando se producen conflictos de esquema.

Tabla Glue resultante después de la replicación:

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

Las consultas se simplificarían para el primer nivel:

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

Ejemplo de FULL

Con la anulación de anidación FULL, se aplanan tanto los campos de nivel superior como los campos de estructura o mapa anidados. La notación de puntos se usa para los campos anidados (por ejemplo, “col_2.col_3.id”). Los elementos de la matriz permanecen sin anidar. Cada nodo hoja se convierte en una columna de nivel superior.

Tabla Glue resultante después de la replicación:

Las consultas quedarían completamente aplanadas:

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