Cargas en Amazon Redshift

Una conexión de almacenamiento puede cargar los datos semanales en tablas de tu grupo de trabajo de Amazon Redshift Serverless. No nos das ninguna clave y no guardamos ninguna tuya: creas en tu cuenta de AWS un rol que nuestro propio rol asume, solo con el ExternalId emitido para esa conexión. Las tablas, sus columnas y cómo se sustituye cada semana de una vez son las de las cargas en tu almacén de datos: una tabla por conjunto de datos, mercamap_ y su nombre, en el esquema que indiques. Por ahora no se ofrece un clúster aprovisionado.

Cómo se carga una semana

La semana de cada conjunto de datos es un paso. Sus filas van como archivos CSV comprimidos con gzip a un bucket tuyo, en mercamap/_loads/ dentro del prefijo que indiques, en una carpeta propia del paso. Después, un lote de la Data API de Redshift se ejecuta en una transacción: crea la tabla del conjunto de datos si falta, copia los archivos en una tabla de paso nuestra con el rol que tu espacio de nombres usa para COPY, borra las filas de esa semana de la tabla, inserta las de la tabla de paso y la elimina. Quien lea ve la semana anterior o la nueva, y un lote que falla no deja nada detrás. Luego se borran los archivos del paso.

Una semana sin filas solo borra sus filas. Las semanas anteriores se quedan hasta que las borres. Creamos nuestras tablas en tu esquema y no tocamos nada más de él.

Configurarlo

1. Conecta: abre Conectores y entra en Amazon Redshift. Indica el ARN del rol que vas a crear para nosotros, el de tu grupo de trabajo (en su página de Redshift Serverless), la base de datos y el esquema, un bucket en la región del grupo de trabajo, con prefijo opcional, y el rol con el que lee COPY: en blanco para el predeterminado del espacio de nombres, o el ARN de otro rol asociado a él.
2. Da acceso muestra el ExternalId, el ARN de nuestro rol y qué copiar, con Comprobar en cada punto. Crea el rol en IAM › Roles › Crear rol › Política de confianza personalizada con la del punto, que solo deja entrar a nuestro rol con este ExternalId; si lo llamas de otro modo, cambia ahí su ARN. Añádele dos políticas insertadas (Permisos › Agregar permisos › Crear política insertada): s3:PutObject y s3:DeleteObject en la carpeta de paso, y redshift-data:BatchExecuteStatement y redshift-serverless:GetCredentials en el grupo de trabajo, con redshift-data:DescribeStatement y redshift-data:CancelStatement en las instrucciones de nuestra sesión.
3. Al rol con el que lee COPY, dale s3:GetObject y s3:ListBucket en la carpeta de paso. Si el cifrado predeterminado del bucket es una clave de KMS (SSE-KMS), añade también las dos políticas opcionales: kms:GenerateDataKey y kms:Decrypt para tu rol, y kms:Decrypt para el rol de COPY, cada una solo para S3 y la carpeta de paso (o el bucket, con una clave de bucket de S3). Sin ellas, AWS rechaza cada archivo.
4. En Redshift › Editor de consultas v2, como administrador, ejecuta el SQL del punto: crea el esquema si falta y el usuario de base de datos de nuestro rol, IAMR: seguido del nombre del rol, y le concede USAGE y CREATE en el esquema y nada más. Sáltate la línea CREATE USER si el usuario ya existe.
5. Elige los datos y, en Prueba y activa, pulsa Probar la conexión: deja una fila en la carpeta de paso y, en una transacción, crea una tabla propia, copia en ella la fila, la borra y elimina la tabla, como los envíos semanales. Si sale bien, aparece Activar.

GRANT USAGE, CREATE ON SCHEMA "mercamap" TO "IAMR:mercamap-redshift";

Antes de cada sesión comprobamos que el rol exige su ExternalId: nuestro rol lo pide una vez con otro valor, con una política que no permite nada, y AWS tiene que rechazarlo; tu CloudTrail lo muestra como un AssumeRole rechazado. Un rol que nos dejara entrar con otro ExternalId dejaría entrar a cualquier cuenta que lo nombrara, así que nunca lo usamos. La sesión que tomamos después se limita a la carpeta de paso y al grupo de trabajo, aunque el rol permita más, y se llama mercamap- seguido del id de tu cuenta de MercaMap. Una regla de ciclo de vida que haga caducar los objetos de mercamap/_loads/ al cabo de un día quita cualquier archivo que una carga cortada no pudiera borrar.

Lo que cuesta

Las instrucciones se ejecutan en tu grupo de trabajo y los archivos están en tu bucket, así que AWS los factura a tu cuenta (precios de Amazon Redshift):

• Cómputo: el lote de cada semana, el COPY y la sustitución de un conjunto de datos, usa la capacidad de tu grupo de trabajo, que se factura en horas de RPU por segundos al precio de tu región, con el cargo mínimo que fija AWS; un grupo de trabajo sin actividad no cuesta nada.
• Almacenamiento: las filas que guardes, al precio del almacenamiento gestionado de Redshift; la tabla de paso dura una transacción.
• S3 (precios de Amazon S3): una petición PUT por archivo (borrar es gratis), las peticiones GET y LIST del COPY y el almacenamiento de los archivos unos minutos. Mover datos entre S3 y Redshift en la misma región es gratis.
• KMS: con una clave tuya en el bucket, la escritura de cada archivo y la lectura del COPY piden una clave a AWS KMS, que se factura por petición (precios de AWS KMS); una clave de bucket de S3 reduce esas peticiones.

Nuestras instrucciones las ejecuta el usuario de base de datos de tu rol, IAMR: y su nombre: un superusuario las encuentra en SYS_QUERY_HISTORY por ese username.

Cuando una carga falla

La conexión muestra su último fallo con nuestras palabras:

Cada uno cuenta como un fallo de la conexión: tus administradores se enteran tras 3 intentos fallidos seguidos, y tras 10 se desactiva sola. «No respondió» es nuestro o de AWS (nuestra entrada, la Data API ocupada, un lote que tardó demasiado y se canceló), y nunca cuenta.

Siguientes pasos

• Cargas en tu almacén de datos
• Conectores: adónde pueden ir tus datos
• Power BI, Excel, Tableau y Qlik, y también Data Studio y Looker