Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Carga de datos en Amazon Redshift Existen varias formas de cargar datos en una base de datos de Amazon Redshift. Un origen popular de datos para cargar son los archivos de Amazon S3. En la siguiente tabla se resumen algunos de los métodos que se utilizarán al empezar desde un origen de Amazon S3. | Método a utilizar | Descripción | Cuando se necesita un método | | --- | --- | --- | | COPY command | Ejecuta una ingesta de archivos por lotes para cargar datos de los archivos de Amazon S3. Este método aprovecha las capacidades de procesamiento en paralelo de Amazon Redshift. Para obtener más información, consulte [Carga de tablas con el comando COPY](t_Loading_tables_with_the_COPY_command.md). | Debe usarse cuando se necesiten requisitos básicos de carga de datos para iniciar la ingesta manual de archivos por lotes. Este método se utiliza principalmente con canalizaciones de ingesta de archivos personalizadas y de terceros o cargas de trabajo de ingesta de archivos puntuales. | | COPY... Comando CREATE JOB (copia automática) | Ejecuta los comandos COPY automáticamente cuando se crea un nuevo archivo en las rutas rastreadas de Amazon S3. Para obtener más información, consulte [Creación de una integración de eventos de S3 para copiar automáticamente archivos desde buckets de Amazon S3](loading-data-copy-job.md). | Se debe usar cuando una canalización de ingesta de archivos necesite ingerir datos automáticamente al crear un nuevo archivo en Amazon S3. Amazon Redshift hace un seguimiento de los archivos que se pueden ingerir para evitar la duplicación de datos. Este método requiere que los propietarios de los buckets de Amazon S3 lo configuren. | | Carga desde consultas de lagos de datos | Cree tablas externas para ejecutar consultas de lagos de datos en los archivos de Amazon S3 y, a continuación, ejecute el comando INSERT INTO para cargar los resultados de las consultas de los lagos de datos en las tablas locales. Para obtener más información, consulte [Tablas externas para Redshift Spectrum](c-spectrum-external-tables.md). | Se debe utilizar en cualquiera de los siguientes escenarios: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/t_Loading_data.html) | | Otros métodos que puede considerar | | Ingesta de streaming | La ingesta de streaming proporciona una ingesta de alta velocidad y baja latencia de datos de flujos de Amazon Kinesis Data Streams y Amazon Managed Streaming para Apache Kafka en una vista materializada de Amazon Redshift aprovisionado o Redshift sin servidor. Para obtener más información, consulte [Introducción a la ingesta de streaming de Amazon Kinesis Data Streams](materialized-view-streaming-ingestion-getting-started.md) y [Introducción a la ingesta de transmisiones desde orígenes de Apache Kafka](materialized-view-streaming-ingestion-getting-started-MSK.md). | Debe tenerse en cuenta para los casos de uso en los que los datos se transmiten primero a archivos en Amazon S3 y, después, se cargan desde Amazon S3. Si no es necesario conservar los datos en Amazon S3, a menudo puede considerar la posibilidad de transmitirlos directamente a Amazon Redshift. | | Ejecución de consultas del lago de datos | Ejecución de consultas directamente desde una tabla de un lago de datos en lugar de ingerir el contenido de la tabla a una tabla local. Para obtener más información, consulte [Amazon Redshift Spectrum](c-using-spectrum.md). | Se debe usar cuando el caso de uso no requiera el rendimiento de consultas de tablas locales en Amazon Redshift. | | Carga por lotes con el editor de consultas de Amazon Redshift v2 | Puede preparar y ejecutar las cargas de trabajo de ingesta de archivos por lotes visualmente en el editor de consultas de Amazon Redshift v2. Para obtener más información, consulte [Carga de datos desde S3](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data) en la *Guía de administración de Amazon Redshift*. | Se debe usar cuando desee que el editor de consultas v2 prepare las instrucciones COPY y desee una herramienta visual que simplifique el proceso de preparación de las instrucciones COPY. | | Carga de datos desde un archivo local con el editor de consultas de Amazon Redshift v2 | Puede cargar archivos directamente desde el escritorio a las tablas de Amazon Redshift sin necesidad de cargar los archivos manualmente en Amazon S3. Para obtener más información, consulte [Carga de datos desde una configuración de archivo local y flujo de trabajo](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-loading.html#query-editor-v2-loading-data-local) en la *Guía de administración de Amazon Redshift*. | Se debe usar cuando necesite cargar archivos rápidamente desde el equipo local para realizar consultas únicas. Con este método, el editor de consultas de Amazon Redshift v2 almacena temporalmente el archivo en un bucket de Amazon S3 propiedad del cliente y ejecuta un comando de copia mediante esta ruta de Amazon S3. | La forma más eficiente de cargar una tabla es mediante el comando COPY. También puede agregar datos a las tablas mediante el uso de los comandos INSERT, aunque ese método es menos efectivo que usar COPY. El comando COPY puede leer datos de diferentes archivos y flujos de datos de forma simultánea. Amazon Redshift asigna la carga de trabajo a los nodos de Amazon Redshift y realiza las operaciones de carga en paralelo, incluida la ordenación de las filas y la distribución de los datos entre los sectores de los nodos. **nota** Las tablas externas de Amazon Redshift Spectrum solo se pueden leer. No puede utilizar COPY ni INSERT en una tabla externa. Para acceder a los datos en otros recursos de AWS, Amazon Redshift debe tener permiso para acceder a tales recursos y para realizar las acciones necesarias para acceder a los datos. Puede usar AWS Identity and Access Management (IAM) para limitar el acceso de los usuarios a los datos y recursos de Amazon Redshift. Tras la carga de datos inicial, si agrega, modifica o elimina una cantidad de datos significativa, a continuación debe ejecutar un comando VACUUM para reorganizar los datos y recuperar espacio tras las eliminaciones. También debe ejecutar un comando ANALYZE para actualizar las estadísticas de la tabla. **Topics** + [Carga de tablas con el comando COPY](t_Loading_tables_with_the_COPY_command.md) + [Creación de una integración de eventos de S3 para copiar automáticamente archivos desde buckets de Amazon S3](loading-data-copy-job.md) + [Carga de tablas con comandos DML](t_Updating_tables_with_DML_commands.md) + [Realización de una copia profunda](performing-a-deep-copy.md) + [Análisis de tablas](t_Analyzing_tables.md) + [Limpieza de tablas](t_Reclaiming_storage_space202.md) + [Administración de operaciones de escritura simultáneas](c_Concurrent_writes.md) + [Tutorial: Carga de datos desde Amazon S3](tutorial-loading-data.md) # Carga de tablas con el comando COPY El comando COPY utiliza la arquitectura de procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos en paralelo desde archivos de Amazon S3, desde una tabla de DynamoDB o desde un texto de salida de uno o más alojamientos remotos. Antes de obtener información sobre todas las opciones del comando COPY, le recomendamos que obtenga información sobre las opciones básicas para cargar datos de Amazon S3. La *Guía de introducción de Amazon Redshift* muestra un uso sencillo del comando COPY para cargar datos de Amazon S3 mediante un rol de IAM predeterminado. Consulte [Paso 4: Carga de datos desde Amazon S3 a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) para obtener más información. **nota** Le recomendamos encarecidamente que use el comando COPY para cargar grandes cantidades de datos. El uso de instrucciones INSERT individuales para completar una tabla podría ser prohibitivamente lento. O bien, si los datos ya existen en otras tablas de la base de datos de Amazon Redshift, puede utilizar INSERT INTO… SELECT o CREATE TABLE AS para mejorar el rendimiento. Para obtener información, consulte [INSERT](r_INSERT_30.md) o [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Para cargar datos desde otro recurso de AWS, Amazon Redshift debe tener permiso para acceder al recurso y realizar las acciones necesarias. Para otorgar o revocar el privilegio de carga de datos en una tabla mediante una instrucción COPY, otorgue o revoque el privilegio INSERT. Los datos deben tener el formato correcto para cargase en la tabla de Amazon Redshift. En esta sección, se presentan las directrices para preparar y controlar sus datos antes de la carga y para validar una instrucción COPY antes de ejecutarla. Para proteger la información en los archivos, puede cifrar los archivos de datos antes de cargarlos al bucket de Amazon S3; COPY descifrará los datos a medida que realice la carga. También puede otorgarles a los usuarios credenciales de seguridad temporales para limitar su acceso a los datos cargados. Las credenciales de seguridad temporales proporcionan mayor seguridad debido a su breve vigencia y al hecho de que no se pueden reutilizar cuando vencen. Amazon Redshift tiene características integradas en COPY para cargar datos delimitados y sin comprimir de forma rápida. No obstante, puede comprimir sus archivos utilizando los formatos gzip, lzop o bzip2 para ahorrar tiempo cuando cargue los archivos. No se admitirá la división automática de datos sin comprimir si las siguientes palabras clave aparecen en la consulta COPY: ESCAPE, REMOVEQUOTES y FIXEDWIDTH. Pero sí se admite la palabra clave CSV. Para ayudar a mantener la protección de los datos en tránsito en la nube de AWS, Amazon Redshift utiliza la tecnología SSL con aceleración por hardware para comunicarse con Amazon S3 o Amazon DynamoDB en las operaciones de COPY, UNLOAD, copia de seguridad y restauración. Si carga una tabla directamente desde una tabla de Amazon DynamoDB, puede optar por controlar la cantidad de rendimiento aprovisionado por Amazon DynamoDB que se va a consumir. De forma alternativa, puede permitirle a COPY que analice los datos de entrada y aplique las codificaciones de compresión óptimas a su tabla de manera automática, como parte del proceso de carga. **Topics** + [Credenciales y permisos de acceso](loading-data-access-permissions.md) + [Preparación de los datos de entrada](t_preparing-input-data.md) + [Carga de datos desde Amazon S3](t_Loading-data-from-S3.md) + [Carga de datos desde Amazon EMR](loading-data-from-emr.md) + [Carga de datos desde hosts remotos](loading-data-from-remote-hosts.md) + [Carga de datos desde una tabla de Amazon DynamoDB](t_Loading-data-from-dynamodb.md) + [Comprobación de carga correcta de datos](verifying-that-data-loaded-correctly.md) + [Validación de datos de entrada](t_Validating_input_files.md) + [Carga de tablas con compresión automática](c_Loading_tables_auto_compress.md) + [Optimización del almacenamiento para tablas angostas](c_load_compression_hidden_cols.md) + [Carga de valores de columna predeterminados](c_loading_default_values.md) + [Solución de problemas en cargas de datos](t_Troubleshooting_load_errors.md) # Credenciales y permisos de acceso Para cargar o descargar datos con otro recurso de AWS, como Amazon S3, Amazon DynamoDB, Amazon EMR o Amazon EC2, Amazon Redshift debe tener permiso para acceder al recurso y realizar las acciones necesarias para acceder a los datos. Por ejemplo, para cargar datos de Amazon S3, COPY debe tener acceso LIST para el bucket y acceso GET para los objetos del bucket. Para obtener una autorización para acceder a un recurso, Amazon Redshift debe estar autenticado. Puede elegir un control de acceso basado en un rol o en una clave. En esta sección, se presenta información general relacionada con los dos métodos. Para obtener todos los detalles y ejemplos, consulte [Permisos para acceder a otros recursos de AWS](copy-usage_notes-access-permissions.md). ## Control de acceso con base en roles Con el control de acceso basado en roles, Amazon Redshift adopta de forma temporal un rol de AWS Identity and Access Management (IAM) en su nombre. Luego, en función de las autorizaciones que se otorgaron al rol, Amazon Redshift puede acceder a los recursos de AWS requeridos. Recomendamos el uso del control de acceso basado en roles porque brinda un control más preciso y seguro del acceso a los recursos de AWS y a la información confidencial de los usuarios, además de salvaguardar las credenciales de AWS. Para utilizar el control de acceso basado en roles, primero debe crear un rol de IAM mediante el tipo de rol de servicio de Amazon Redshift y, luego, asociar el rol al almacenamiento de datos. Como mínimo, el rol debe tener los permisos especificados en [Permisos de IAM para COPY, UNLOAD y CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). Para obtener información acerca de cómo crear un rol de IAM y adjuntarlo al clúster, consulte [Creación de un rol de IAM que permita al clúster de Amazon Redshift acceder a los servicios de AWS](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html#authorizing-redshift-service-creating-an-iam-role) en la *Guía de administración de Amazon Redshift*. Puede agregar un rol a un clúster o ver los roles asociados a un clúster mediante la consola de administración, la CLI o la API de Amazon Redshift. Para obtener más información, consulte [Autorización del uso de las operaciones COPY y UNLOAD mediante roles de IAM](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role.html) en la *Guía de administración de Amazon Redshift*. Al crear un rol de IAM, IAM devuelve el Amazon Resource Name (ARN, Nombre de recurso de Amazon) del rol. Para ejecutar un comando COPY con un rol de IAM, proporcione el ARN del rol mediante el parámetro IAM\$1ROLE o el parámetro CREDENTIALS. En el siguiente ejemplo de comando COPY, se usa el parámetro IAM\$1ROLE con el rol `MyRedshiftRole` para su autenticación. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::12345678901:role/MyRedshiftRole'; ``` Como mínimo, el usuario de AWS debe tener los permisos que aparecen en [Permisos de IAM para COPY, UNLOAD y CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). ## Control de acceso basado en claves Con el control de acceso basado en claves, se proporciona el ID de clave de acceso y la clave de acceso secreta de un usuario que está autorizado a acceder a los recursos de AWS que contienen los datos.  **nota** Recomendamos encarecidamente que use un rol de IAM para su autenticación, en lugar de brindar un ID de clave de acceso y una clave de acceso secreta como texto sin formato. Si elige el control de acceso basado en claves, nunca utilice las credenciales (raíz) de su cuenta de AWS. Siempre cree un usuario de IAM y proporcione el ID de clave de acceso y la clave de acceso secreta de ese usuario. Si desea conocer los pasos necesarios para crear un usuario de IAM, consulte [Creación de un usuario de IAM en su cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). # Preparación de los datos de entrada Si los datos de entrada no son compatibles con las columnas de la tabla que los recibirá, el comando COPY dará error. Use las siguientes directrices para ayudar a garantizar que los datos de entrada sean válidos: + Los datos solo pueden contener caracteres multibyte UTF-8 de hasta un máximo de cuatro bytes. + Compruebe que las cadenas CHAR y VARCHAR no sean más largas que las columnas correspondientes. Las cadenas VARCHAR se miden en bytes, no en caracteres, por lo que, por ejemplo, una cadena de cuatro caracteres chinos que ocupan cuatro bytes cada uno requiere una columna VARCHAR(16). + Los caracteres multibyte solo pueden usarse en columnas VARCHAR. Compruebe que los caracteres multibyte no sean de más de cuatro bytes. + Compruebe que los datos para las columnas CHAR solo contengan caracteres de un byte. + No incluya sintaxis ni caracteres especiales para indicar el último campo de un registro. Este campo puede ser un delimitador. + Si sus datos incluyen terminaciones nulas, también denominadas NUL (UTF-8 0000) o cero binario (0x000), puede cargar esos caracteres como NULLS en columnas CHAR o VARCHAR mediante la opción NULL AS del comando COPY: `null as '\0'` o `null as '\000'`. Si no usa NULL AS, las terminaciones nulas harán que COPY produzca un error. + Si sus cadenas tienen caracteres especiales, como delimitadores y caracteres de línea nueva insertados, use la opción ESCAPE del comando [COPY](r_COPY.md). + Compruebe que todas las comillas simples y dobles estén en pares correctamente. + Compruebe que las cadenas de punto flotante estén en formato de punto flotante estándar, como 12.123, o en formato exponencial, como 1.0E4. + Compruebe que todas las cadenas de fecha y marca temporal sigan las especificaciones para [Cadenas TIMEFORMAT y DATEFORMATEjemplo](r_DATEFORMAT_and_TIMEFORMAT_strings.md). El formato de marca temporal predeterminado es AAAA-MM-DD hh:mm:ss y el formato de fecha predeterminado es AAAA-MM-DD. + Para obtener más información acerca de los límites y las limitaciones de los tipos de datos individuales, consulte [Tipos de datos](c_Supported_data_types.md). Para obtener más información acerca de errores con caracteres multibyte, consulte . [Errores de carga de caracteres multibyte](multi-byte-character-load-errors.md) # Carga de datos desde Amazon S3 El comando COPY utiliza la arquitectura de procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos en paralelo desde uno o varios archivos de un bucket de Amazon S3. Puede aprovechar al máximo los beneficios del procesamiento en paralelo mediante la división de los datos en distintos archivos, en los casos en que los archivos estén comprimidos. (Hay excepciones a esta regla. Se detallan en [Divida los datos de carga](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-use-multiple-files.html)). También puede aprovechar al máximo los beneficios del procesamiento en paralelo mediante la configuración de claves de distribución en las tablas. Para obtener más información acerca de las claves de distribución, consulte [Distribución de datos para la optimización de consultas](t_Distributing_data.md). Los datos se cargan en la tabla destino, una línea por fila. Los campos en el archivo de datos se corresponden con las columnas de la tabla, de izquierda a derecha. Los campos en los archivos de datos pueden ser de ancho fijo o con caracteres delimitados; el delimitador predeterminado es la barra vertical (\$1). De manera predeterminada, se cargan todas las columnas de la tabla, pero de manera alternativa se puede definir una lista de columnas separadas por comas. Si una columna de la tabla no se encuentra en la lista de columnas especificada en el comando COPY, se carga con un valor predeterminado. Para obtener más información, consulte [Carga de valores de columna predeterminados](c_loading_default_values.md). **Topics** + [Carga de datos desde archivos comprimidos y sin comprimir](t_splitting-data-files.md) + [Carga de archivos en Amazon S3 para utilizar con COPY](t_uploading-data-to-S3.md) + [Uso del comando COPY para cargar desde Amazon S3](t_loading-tables-from-s3.md) # Carga de datos desde archivos comprimidos y sin comprimir Cuando cargue datos comprimidos, le recomendamos que divida los datos de cada tabla en distintos archivos. Cuando carga datos delimitados y sin comprimir, el comando COPY utiliza rangos de escaneo y procesamiento masivo en paralelo (MPP) para cargar datos de archivos de gran tamaño en un bucket de Amazon S3. ## Carga de datos desde varios archivos comprimidos Cuando tenga datos comprimidos, le recomendamos que divida los datos de cada tabla en varios archivos. El comando COPY puede cargar datos desde distintos archivos en paralelo. Puede cargar varios archivos especificando un prefijo común o el *prefijo de clave* del conjunto, o enumerando explícitamente los archivos en un archivo de manifiesto. Divida los datos en archivos de manera tal que la cantidad de archivos sea múltiplo de la cantidad de sectores en su clúster. De esa manera, Amazon Redshift puede dividir los datos de forma uniforme entre los sectores. El número de sectores por nodo depende del tamaño de nodo del clúster. Por ejemplo, cada nodo de computación dc2.large tiene dos sectores y cada nodo de computación dc2.8xlarge tiene 16 sectores. Para obtener más información acerca de la cantidad de sectores que tiene cada tamaño de nodo, consulte [Acerca de clústeres y nodos](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) en la *Guía de administración de Amazon Redshift*. Todos los nodos participan en la ejecución de consultas en paralelo y trabajan en datos que se distribuyen de la manera más uniforme posible entre los sectores. Si tiene un clúster con dos nodos dc2.large, podría dividir los datos en cuatro archivos o en un múltiplo de cuatro. Amazon Redshift no tiene en cuenta el tamaño de los archivos a la hora de dividir la carga de trabajo. Por lo tanto, debe asegurarse de que los archivos tengan aproximadamente el mismo tamaño, de 1 MB a 1 GB después de la compresión. Para utilizar prefijos de objeto para identificar los archivos de carga, nombre cada archivo con un prefijo común. Por ejemplo, si desea dividir el archivo `venue.txt` podría hacerlo en cuatro archivos, de la siguiente manera: ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` Si coloca en su bucket una carpeta con archivos distintos, y nombra a esa carpeta como el prefijo, COPY cargará todos los archivos que se encuentren en ella. Si detalla de manera explícita los archivos que deben cargarse mediante un archivo de manifiesto, los archivos pueden encontrarse en diferentes buckets o carpetas. Para obtener más información sobre los archivos de manifiesto, consulte [Uso de un manifiesto para especificar archivos de datos](r_COPY_command_examples.md#copy-command-examples-manifest). ## Carga de datos desde archivos delimitados y sin comprimir Cuando se cargan datos delimitados y sin comprimir, el comando COPY utiliza la arquitectura de procesamiento masivo en paralelo (MPP), de Amazon Redshift. Amazon Redshift utiliza automáticamente sectores que funcionan en paralelo para cargar rangos de datos de un archivo de gran tamaño en un bucket de Amazon S3. El archivo debe estar delimitado para que se produzca una carga paralela. Por ejemplo, delimitado por canalización. La carga automática de datos en paralelo con el comando COPY también está disponible para los archivos CSV. Igualmente, puede aprovechar los beneficios del procesamiento en paralelo mediante la configuración de claves de distribución en las tablas. Para obtener más información acerca de las claves de distribución, consulte [Distribución de datos para la optimización de consultas](t_Distributing_data.md). No se admite la carga automática de datos en paralelo cuando la consulta COPY incluye cualquiera de las siguientes palabras clave: ESCAPE, REMOVEQUOTES y FIXEDWIDTH. Los datos de uno o más archivos se cargan en la tabla destino, una línea por fila. Los campos en el archivo de datos se corresponden con las columnas de la tabla, de izquierda a derecha. Los campos en los archivos de datos pueden ser de ancho fijo o con caracteres delimitados; el delimitador predeterminado es la barra vertical (\$1). De manera predeterminada, se cargan todas las columnas de la tabla, pero de manera alternativa se puede definir una lista de columnas separadas por comas. Si una columna de la tabla no está incluida en la lista de columnas especificada en el comando COPY, esta se cargará con un valor predeterminado. Para obtener más información, consulte [Carga de valores de columna predeterminados](c_loading_default_values.md). Siga este proceso general para cargar datos de Amazon S3, cuando los datos estén delimitados y sin comprimir: 1. Cargue sus archivos en Amazon S3. 1. Ejecute el comando COPY para cargar la tabla. 1. Compruebe que los datos se hayan cargado correctamente. Para ver ejemplos de comandos COPY, consulte [Ejemplos de COPY](r_COPY_command_examples.md). Para obtener información acerca de los datos cargados en Amazon Redshift, consulte las tablas de sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) y [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md). Para obtener más información acerca de los nodos y de los sectores que tiene cada nodo, consulte [Acerca de clústeres y nodos](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) en la *Guía de administración de Amazon Redshift*. # Carga de archivos en Amazon S3 para utilizar con COPY Hay un par de enfoques que se deben adoptar cuando se carguen archivos de texto en Amazon S3: + Si tiene archivos comprimidos, le recomendamos que divida los archivos de gran tamaño para aprovechar los beneficios del procesamiento en paralelo en Amazon Redshift. + Por otro lado, COPY divide automáticamente los datos de archivos de texto de gran tamaño que estén delimitados y sin comprimir para facilitar el paralelismo y distribuir eficazmente los datos de archivos de gran tamaño. Cree un bucket de Amazon S3 para que contenga sus archivos de datos y, luego, cargue los archivos de datos en él. Para obtener más información acerca de la creación de buckets y la carga de archivos, consulte [Trabajo con buckets de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) en la *Guía del usuario de Amazon Simple Storage Service*. **importante** El bucket de Amazon S3 que tiene los archivos de datos debe crearse en la misma región de AWS que el clúster, a menos que use la opción [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar la región en la que se encuentra el bucket de Amazon S3. Asegúrese de que los rangos de IP de S3 estén agregados a la lista de permitidos. Para obtener más información acerca de los rangos de IP de S3 necesarios, consulte [Aislamiento de red](https://docs.aws.amazon.com//redshift/latest/mgmt/security-network-isolation.html#network-isolation). Puede crear un bucket de Amazon S3 en una región específica. Para ello, seleccione la región mientras crea el bucket con la consola de Amazon S3 o especifique un punto de conexión mientras crea el bucket con la CLI o la API de Amazon S3. Luego de la carga de los datos, corrobore que los archivos presentes en Amazon S3 sean los correctos. **Topics** + [Administración de la consistencia de los datos](managing-data-consistency.md) + [Carga de datos cifrados en Amazon S3](t_uploading-encrypted-data.md) + [Comprobación de que los archivos presentes en el bucket son los correctos](verifying-that-correct-files-are-present.md) # Administración de la consistencia de los datos Amazon S3 proporciona una sólida consistencia de lectura tras escritura para las operaciones COPY, UNLOAD, INSERT (tabla externa), CREATE EXTERNAL TABLE AS y Amazon Redshift Spectrum en los buckets de Amazon S3 en todas las regiones de AWS. Además, las operaciones de lectura en Amazon S3 Select, las listas de control de acceso de Amazon S3, las etiquetas de objeto de Amazon S3 y los metadatos de objetos (por ejemplo, el objeto HEAD) son muy consistentes. Para obtener más información acerca de la consistencia de los datos, consulte [Modelo de coherencia de datos de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Introduction.html#ConsistencyModel) en la *Guía del usuario de Amazon Simple Storage Service*. # Carga de datos cifrados en Amazon S3 Amazon S3 admite tanto el cifrado del lado del servidor como el cifrado del lado del cliente. En este tema, se analizan las diferencias entre el cifrado del lado del cliente y el cifrado del lado del servidor, y se describen los pasos para usar un cifrado del lado del cliente con Amazon Redshift. El cifrado del lado del servidor es transparente para Amazon Redshift. ## Cifrado en el servidor El cifrado del lado del servidor es el cifrado de datos en reposo; es decir, Amazon S3 cifra los datos a medida que los carga y los descifra para usted cuando obtiene acceso a estos. Cuando se cargan tablas con un comando COPY, no existe diferencia alguna en la forma de carga desde objetos con cifrado del lado del servidor o sin cifrado en Amazon S3. Para obtener más información acerca del cifrado del lado del servidor, consulte [Uso del cifrado del lado del servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) en la *Guía del usuario de Amazon Simple Storage Service*. ## Cifrado del lado del cliente En el cifrado en el cliente, su aplicación cliente administra el cifrado de los datos, las claves de cifrado y las herramientas relacionadas. Puede cargar los datos a un bucket de Amazon S3 con el cifrado del lado del cliente y, luego, cargar los datos con el comando COPY con la opción ENCRYPTED y una clave de cifrado privada para proporcionar mayor seguridad. Usted cifra los datos con cifrado de sobre. Con el *cifrado de sobre*, la aplicación controla todo el cifrado de manera exclusiva. Las claves de cifrado privadas y los datos sin cifrar nunca se envían a AWS, por lo que es muy importante que administre con seguridad las claves de cifrado. Si pierde las claves de cifrado, no podrá descifrar los datos, y estas no se podrán recuperar desde AWS. El cifrado de sobre combina el rendimiento de un cifrado simétrico rápido al mismo tiempo que mantiene la mayor seguridad que brinda la administración de claves con claves asimétricas. El cliente de cifrado de Amazon S3 genera una clave simétrica de un solo uso (la clave simétrica de sobre) para cifrar los datos. Luego, esa clave se cifra mediante la clave raíz y se almacena junto con los datos en Amazon S3. Cuando Amazon Redshift obtiene acceso a los datos durante la carga, la clave simétrica cifrada se recupera y se descifra con la clave real y, luego, se descifran los datos. Para trabajar en Amazon Redshift con datos cifrados del lado del cliente de Amazon S3, siga los pasos que se indican en el artículo [Protección de datos con el cifrado del lado del cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) en la *Guía del usuario de Amazon Simple Storage Service*, con el requisito adicional de que utilice lo siguiente: + **Cifrado simétrico**: el AWS SDK para Java en su clase `AmazonS3EncryptionClient` usa el cifrado de sobre, descrito antes, que se basa en el cifrado con claves simétricas. Use esta clase para crear un cliente de Amazon S3 en el que cargar datos cifrados del lado del cliente. + **Una clave raíz simétrica con cifrado AES de 256 bits**: una clave raíz cifra la clave de sobre. La clave raíz se pasa a la instancia de la clase `AmazonS3EncryptionClient`. Guarde esa clave, ya que la necesitará para copiar los datos en Amazon Redshift. + **Metadatos de los objetos que van a almacenar la clave de sobre cifrada**: de forma predeterminada, Amazon S3 almacena la clave de sobre como metadatos de los objetos de la clase `AmazonS3EncryptionClient`. La clave de sobre cifrada que se almacena como metadatos de los objetos se usa durante el proceso de descifrado. **nota** Si obtiene un mensaje de error de cifrado cuando usa la Application Programming Interface (API, Interfaz de programación de aplicaciones) de cifrado por primera vez, su versión del Java Development Kit (JDK, Kit de desarrollo de Java) puede tener un archivo de política de jurisdicción de Java Cryptography Extension (JCE, Extensión de criptografía Java) que limite la longitud máxima de la clave para las transformaciones de cifrado y descifrado a 128 bits. Para obtener información acerca de cómo solucionar este problema, consulte [Especificación del cifrado del lado del cliente con AWS SDK para Java](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryptionUpload.html) en la *Guía del usuario de Amazon Simple Storage Service*. Para obtener información acerca de la carga de archivos cifrados del lado del cliente en las tablas de Amazon Redshift con el comando COPY, consulte [Carga de archivos de datos cifrados desde Amazon S3](c_loading-encrypted-files.md). ## Ejemplo: Carga de datos cifrados en el cliente Si desea obtener un ejemplo sobre cómo se utiliza AWS SDK para Java para cargar datos cifrados del lado del cliente, consulte [Protección de datos mediante el cifrado del lado del cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/encrypt-client-side-symmetric-master-key.html) en la *Guía del usuario de Amazon Simple Storage Service*. En la segunda opción, se muestran las decisiones que debe tomar durante el cifrado del lado del cliente para que los datos puedan cargarse en Amazon Redshift. Específicamente, en el ejemplo se muestra el uso de metadatos de los objetos para almacenar la clave de sobre cifrada y el uso de una clave raíz simétrica con cifrado AES de 256 bits. En este ejemplo, se proporciona un código de ejemplo que utiliza AWS SDK para Java para crear una clave raíz simétrica con cifrado AES de 256 bits y guardarla en un archivo. Luego, se incluye un ejemplo de carga de un objeto en Amazon S3 con un cliente de cifrado de S3 que primero cifra los datos de muestra en el cliente. En el ejemplo, también se descarga el objeto y se comprueba que los datos sean los mismos. # Comprobación de que los archivos presentes en el bucket son los correctos Una vez que cargue los archivos en su bucket de Amazon S3, le recomendamos que enumere el contenido del bucket para corroborar que este tenga todos los archivos correctos y que no incluya ningún archivo no deseado. Por ejemplo, si el bucket `amzn-s3-demo-bucket` tiene un archivo denominado `venue.txt.back`, ese archivo será cargado, quizás de manera no intencional, por el siguiente comando: ``` COPY venue FROM 's3://amzn-s3-demo-bucket/venue' … ; ``` Si desea controlar de manera específica qué archivos se cargan, puede usar un archivo de manifiesto para listar los archivos de datos de manera explícita. Para obtener más información acerca del uso de un archivo de manifiesto, consulte la opción [copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file) para el comando COPY y [Uso de un manifiesto para especificar archivos de datos](r_COPY_command_examples.md#copy-command-examples-manifest) en los ejemplos de COPY. Para obtener más información acerca de cómo mostrar el contenido del bucket, consulte [Listas de claves de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ListingKeysUsingAPIs.html) en la *Guía para desarrolladores de Amazon S3*. # Uso del comando COPY para cargar desde Amazon S3 Uso del comando [COPY](r_COPY.md) para cargar una tabla en paralelo desde los archivos de datos en Amazon S3. Puede especificar los archivos que se cargarán mediante un prefijo de objeto de Amazon S3 o un archivo de manifiesto. La sintaxis para especificar los archivos por cargar mediante el uso de un prefijo es la siguiente: ``` COPY FROM 's3:///' authorization; ``` El archivo de manifiesto es un archivo con formato JSON que lista los archivos de datos que se deben cargar. La sintaxis para especificar los archivos por cargar mediante el uso de un archivo de manifiesto es la siguiente: ``` COPY FROM 's3:///' authorization MANIFEST; ``` La tabla que se cargará ya debe existir en la base de datos. Para obtener más información acerca de la creación de una tabla, consulte [CREATE TABLE](r_CREATE_TABLE_NEW.md) en la referencia de SQL. Los valores de *autorización* proporcionan la autorización de AWS que Amazon Redshift necesita para acceder a los objetos de Amazon S3. Para obtener más información acerca de los permisos necesarios, consulte [Permisos de IAM para COPY, UNLOAD y CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). El método de autenticación preferido es especificar el parámetro IAM\$1ROLE y proporcionar el Amazon Resource Name (ARN, Nombre de recurso de Amazon) de un rol de IAM con los permisos necesarios. Para obtener más información, consulte  [Control de acceso con base en roles](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based) . Para realizar la autenticación con el parámetro IAM\$1ROLE, reemplace ** y **, tal y como se observa en la siguiente sintaxis. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` En el siguiente ejemplo, se muestra la autenticación con un rol de IAM. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/mydata' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Para obtener más información acerca de otras opciones de autorización, consulte . [Parámetros de autorización](copy-parameters-authorization.md) Si desea validar los datos sin cargar de hecho la tabla, use la opción NOLOAD con el comando [COPY](r_COPY.md). En el siguiente ejemplo, se muestran las primeras filas de datos delimitados por barras verticales en un archivo denominado `venue.txt`. ``` 1|Toyota Park|Bridgeview|IL|0 2|Columbus Crew Stadium|Columbus|OH|0 3|RFK Stadium|Washington|DC|0 ``` Antes de cargar el archivo en Amazon S3, divídalo en distintos archivos para que el comando COPY pueda cargarlo usando el procesamiento en paralelo. La cantidad de archivos debe ser múltiplo de la cantidad de secciones en su clúster. Divida los archivos de datos de carga de modo tal que sean de igual tamaño, entre 1 MB y 1 GB, después de la compresión. Para obtener más información, consulte [Carga de datos desde archivos comprimidos y sin comprimir](t_splitting-data-files.md). Por ejemplo, el archivo `venue.txt` podría dividirse en cuatro archivos, de la siguiente manera: ``` venue.txt.1 venue.txt.2 venue.txt.3 venue.txt.4 ``` El siguiente comando COPY carga la tabla VENUE con datos delimitados por barras verticales en los archivos de datos con el prefijo “venue” del bucket de Amazon S3 `amzn-s3-demo-bucket`. **nota** El bucket `amzn-s3-demo-bucket` de Amazon S3 no está presente en los siguientes ejemplos. Para ver información acerca de comandos COPY de muestra que usan datos reales de un bucket de Amazon S3 existente, consulte [Carga de datos de muestra](https://docs.aws.amazon.com/redshift/latest/gsg/cm-dev-t-load-sample-data.html). ``` COPY venue FROM 's3://amzn-s3-demo-bucket/venue' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|'; ``` Si no hay objetos de Amazon S3 con el prefijo de clave “venue”, se producirá un error en la carga. **Topics** + [Uso de un manifiesto para especificar archivos de datos](loading-data-files-using-manifest.md) + [Carga de archivos de datos comprimidos desde Amazon S3](t_loading-gzip-compressed-data-files-from-S3.md) + [Carga de datos de ancho fijo desde Amazon S3](t_loading_fixed_width_data.md) + [Carga de datos multibyte desde Amazon S3](t_loading_unicode_data.md) + [Carga de archivos de datos cifrados desde Amazon S3](c_loading-encrypted-files.md) # Uso de un manifiesto para especificar archivos de datos Puede usar un manifiesto para asegurarse de que el comando COPY cargue todos los archivos requeridos, y solo los requeridos, en la carga de datos. Puede usar un manifiesto para cargar archivos de diferentes buckets o archivos que no comparten el mismo prefijo. En lugar de proporcionar la ruta de un objeto para el comando COPY, se proporciona el nombre de un archivo de texto en formato JSON que lista explícitamente los archivos por cargar. El URL en el manifiesto debe especificar el nombre del bucket y la ruta completa del objeto para el archivo, no solo un prefijo. Para obtener más información acerca de los archivos de manifiesto, consulte el ejemplo COPY [Uso de un manifiesto para especificar archivos de datos](r_COPY_command_examples.md#copy-command-examples-manifest). En el siguiente ejemplo, se muestra el JSON para cargar archivos de diferentes buckets y con nombres de archivo que comiencen con marcas de fecha. ``` { "entries": [ {"url":"s3://amzn-s3-demo-bucket1/2013-10-04-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket1/2013-10-05-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket2/2013-10-04-custdata", "mandatory":true}, {"url":"s3://amzn-s3-demo-bucket2/2013-10-05-custdata", "mandatory":true} ] } ``` La marca opcional `mandatory` especifica si COPY debe devolver un error en caso de que el archivo no se encuentre. El valor predeterminado de `mandatory` es `false`. Independientemente de cualquier configuración obligatoria, COPY terminará si no se encuentran archivos. En el siguiente ejemplo, se ejecuta el comando COPY con el manifiesto del ejemplo anterior, que se denomina `cust.manifest`. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/cust.manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MANIFEST; ``` ## Uso de un manifiesto creado por UNLOAD Un manifiesto creado por una operación [UNLOAD](r_UNLOAD.md) que usa el parámetro MANIFEST podría tener claves no requeridas para la operación COPY. Por ejemplo, en el siguiente manifiesto de `UNLOAD`, se incluye una clave `meta` que es necesaria para una tabla externa de Amazon Redshift Spectrum y para cargar archivos de datos con el formato `ORC` o `Parquet`. La clave `meta` contiene una clave `content_length` con un valor que es el tamaño real del archivo en bytes. La operación COPY requiere solo la clave `url` y una clave `mandatory` opcional. ``` { "entries": [ {"url":"s3://amzn-s3-demo-bucket/unload/manifest_0000_part_00", "meta": { "content_length": 5956875 }}, {"url":"s3://amzn-s3-demo-bucket/unload/unload/manifest_0001_part_00", "meta": { "content_length": 5997091 }} ] } ``` Para obtener más información sobre los archivos de manifiesto, consulte [Uso de un manifiesto para especificar archivos de datos](r_COPY_command_examples.md#copy-command-examples-manifest). # Carga de archivos de datos comprimidos desde Amazon S3 Para cargar archivos de datos comprimidos con gzip, lzop o bzip2, incluya la opción que corresponda: GZIP, LZOP o BZIP2. Por ejemplo, el siguiente comando carga desde archivos comprimidos con lzop. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/customer.lzo' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' LZOP; ``` **nota** Si comprime un archivo de datos con la compresión lzop y utiliza la opción *--filter*, el comando COPY no la admite. # Carga de datos de ancho fijo desde Amazon S3 Los archivos de datos de ancho fijo tienen longitudes uniformes para cada columna de datos. Cada campo de un archivo con datos de ancho fijo tiene exactamente la misma longitud y posición. En el caso de datos de caracteres (CHAR y VARCHAR) en un archivo de datos de ancho fijo, debe incluir espacios a la izquierda o a la derecha como marcadores de posición, con objeto de mantener la uniformidad del ancho. En el caso de números enteros, se deben usar ceros a la izquierda como marcadores de posición. Un archivo de datos de ancho fijo no tiene delimitador para separar columnas. Para cargar un archivo de datos de ancho fijo en una tabla existente, USE el parámetro FIXEDWIDTH del comando COPY. Las especificaciones de la tabla deben coincidir con el valor de fixedwidth\$1spec con objeto de que los datos se carguen de manera correcta. Para cargar datos de ancho fijo en una tabla desde un archivo, emita el siguiente comando: ``` COPY table_name FROM 's3://amzn-s3-demo-bucket/prefix' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' FIXEDWIDTH 'fixedwidth_spec'; ``` El parámetro *fixedwidth\$1spec* es una cadena que contiene un identificador para cada columna y el ancho de cada columna, separados por dos puntos. Los pares **column:width** están delimitados por comas. El identificador puede ser lo que usted elija: números, letras o una combinación de los dos. El identificador no se relaciona con la tabla en sí, por lo que la especificación debe tener las columnas en el mismo orden que la tabla. En los siguientes dos ejemplos, se observa la misma especificación; la primera usa identificadores numéricos y la segunda usa identificadores de cadena: ``` '0:3,1:25,2:12,3:2,4:6' ``` ``` 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6' ``` En el siguiente ejemplo, se muestran datos de muestra de ancho fijo que podrían cargarse en la tabla VENUE con las especificaciones anteriores: ``` 1 Toyota Park Bridgeview IL0 2 Columbus Crew Stadium Columbus OH0 3 RFK Stadium Washington DC0 4 CommunityAmerica Ballpark Kansas City KS0 5 Gillette Stadium Foxborough MA68756 ``` El siguiente comando COPY carga este conjunto de datos en la tabla VENUE: ``` COPY venue FROM 's3://amzn-s3-demo-bucket/data/venue_fw.txt' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' FIXEDWIDTH 'venueid:3,venuename:25,venuecity:12,venuestate:2,venueseats:6'; ``` # Carga de datos multibyte desde Amazon S3 Si los datos incluyen caracteres multibyte no ASCII (como caracteres cirílicos o chinos) debe cargar los datos en columnas VARCHAR. El tipo de datos VARCHAR admite caracteres UTF-8 de cuatro bytes, pero el tipo de datos CHAR solo acepta caracteres ASCII de un solo byte. No puede cargar caracteres de cinco bytes o más en tablas de Amazon Redshift. Para obtener más información acerca de los comandos CHAR y VARCHAR, consulte [Tipos de datos](c_Supported_data_types.md). Para comprobar qué cifrado usa un archivo de entrada, use el comando *`file`* de Linux: ``` $ file ordersdata.txt ordersdata.txt: ASCII English text $ file uni_ordersdata.dat uni_ordersdata.dat: UTF-8 Unicode text ``` # Carga de archivos de datos cifrados desde Amazon S3 Puede usar el comando COPY para cargar archivos de datos cargados en Amazon S3 usando el cifrado del lado del servidor, el cifrado del lado del cliente o de ambos. El comando COPY es compatible con los siguientes tipos de cifrado de Amazon S3: + Cifrado en el servidor con claves administradas por Amazon S3 (SSE-S3) + Cifrado del lado del servidor con AWS KMS keys (SSE-KMS) + Cifrado del lado del cliente con una clave raíz simétrica del lado del cliente El comando COPY no es compatible con los siguientes tipos de cifrado de Amazon S3: + Cifrado en el servidor con claves proporcionadas por el cliente (SSE-C) + Cifrado del lado del cliente con una AWS KMS key + Cifrado del lado del cliente con una clave raíz asimétrica provista por el cliente Para obtener más información acerca del cifrado de Amazon S3, consulte [Protección de datos con el cifrado del lado del servidor](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) y [Protección de datos con el cifrado del lado del cliente](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html) en la Guía del usuario de Amazon Simple Storage Service. El comando [UNLOAD](r_UNLOAD.md) cifra los archivos con SSE-S3 de manera automática. También puede descargar con cifrado del cliente o SSE-KMS con una clave simétrica administrada por el cliente. Para obtener más información, consulte [Descarga de archivos de datos cifrados](t_unloading_encrypted_files.md) El comando COPY reconoce automáticamente y carga los archivos cifrados con SSE-S3 y SSE-KMS. Puede cargar archivos cifrados con una clave raíz simétrica del lado del cliente especificando la opción ENCRYPTED y proporcionando el valor de clave. Para obtener más información, consulte [Carga de datos cifrados en Amazon S3](t_uploading-encrypted-data.md). Para cargar archivos de datos cifrados del lado del cliente, proporcione el valor de clave raíz con el parámetro MASTER\$1SYMMETRIC\$1KEY e incluya la opción ENCRYPTED. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MASTER_SYMMETRIC_KEY '' ENCRYPTED DELIMITER '|'; ``` Para cargar archivos de datos cifrados que están comprimidos en gzip, lzop o bzip2, incluya la opción GZIP, LZOP o BZIP2 junto con el valor de clave raíz y la opción ENCRYPTED. ``` COPY customer FROM 's3://amzn-s3-demo-bucket/encrypted/customer' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' MASTER_SYMMETRIC_KEY '' ENCRYPTED DELIMITER '|' GZIP; ``` # Carga de datos desde Amazon EMR Puede utilizar el comando COPY para cargar datos en paralelo desde un clúster de Amazon EMR configurado para escribir archivos de texto en el sistema de archivos distribuido de Hadoop (HDFS) del clúster, como archivos de ancho fijo, archivos delimitados por caracteres, archivos CSV o archivos con formato JSON. ## Proceso para cargar datos desde Amazon EMR En esta sección, se detalla el proceso de carga de datos desde un clúster de Amazon EMR. En las siguientes secciones, se proporcionan los detalles que debe completar en cada paso. + **[Paso 1: Configurar los permisos de IAM](#load-from-emr-steps-configure-iam)** Los usuarios que crean el clúster de Amazon EMR y ejecutan el comando COPY de Amazon Redshift deben tener los permisos necesarios. + **[Paso 2: Crear un clúster de Amazon EMR](#load-from-emr-steps-create-cluster)** Configure el clúster para que produzca archivos de texto para Hadoop Distributed File System (HDFS). Necesitará el ID de clúster de Amazon EMR y el DNS público principal del clúster (el punto de conexión de la instancia de Amazon EC2 que aloja el clúster). + **[Paso 3: Recuperar la clave pública del clúster de Amazon Redshift y las direcciones IP del nodo del clúster](#load-from-emr-steps-retrieve-key-and-ips)** La clave pública permite a los nodos del clúster de Amazon Redshift establecer conexiones SSH a los alojamientos. Usará la dirección IP para cada nodo del clúster con objeto de configurar los grupos de seguridad del alojamiento para que permitan obtener acceso desde su clúster de Amazon Redshift con esas direcciones IP. + **[Paso 4: Agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas de cada alojamiento de Amazon EC2](#load-from-emr-steps-add-key-to-host)** Debe agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento para que este último reconozca el clúster de Amazon Redshift y acepte la conexión SSH. + **[Paso 5: Configurar los alojamientos para que acepten todas las direcciones IP del clúster de Amazon Redshift](#load-from-emr-steps-configure-security-groups)** Modifique los grupos de seguridad de la instancia de Amazon EMR para agregar reglas de entrada que acepten las direcciones IP de Amazon Redshift. + **[Paso 6: Ejecutar el comando COPY para cargar los datos](#load-from-emr-steps-run-copy)** Ejecute el comando COPY desde una base de datos de Amazon Redshift para cargar los datos en una tabla de Amazon Redshift. ## Paso 1: Configurar los permisos de IAM Los usuarios que crean el clúster de Amazon EMR y ejecutan el comando COPY de Amazon Redshift deben tener los permisos necesarios. **Pasos para configurar los permisos de IAM** 1. Agregue los siguientes permisos para el usuario que creará el clúster de Amazon EMR. ``` ec2:DescribeSecurityGroups ec2:RevokeSecurityGroupIngress ec2:AuthorizeSecurityGroupIngress redshift:DescribeClusters ``` 1. Agregue el siguiente permiso para el rol o usuario de IAM que ejecutará el comando COPY. ``` elasticmapreduce:ListInstances ``` 1. Agregue el siguiente permiso al rol de IAM del clúster de Amazon EMR. ``` redshift:DescribeClusters ``` ## Paso 2: Crear un clúster de Amazon EMR El comando COPY carga datos de archivos en el Hadoop Distributed File System (HDFS) de Amazon EMR. Cuando cree el clúster de Amazon EMR, configúrelo para que genere archivos de datos para el HDFS del clúster. **Para crear un clúster de Amazon EMR** 1. Cree un clúster de Amazon EMR en la misma región de AWS que el clúster de Amazon Redshift. Si el clúster de Amazon Redshift se encuentra en una VPC, el clúster de Amazon EMR debe encontrarse en el mismo grupo de la VPC. Si el clúster de Amazon Redshift usa el modo EC2-Classic (es decir, no se encuentra en una VPC), el clúster de Amazon EMR también debe usar el modo EC2-Classic. Para obtener más información, consulte [Administración de clústeres en una nube privada virtual (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) en la *Guía de administración de Amazon Redshift*. 1. Configure el clúster para que genere archivos de datos para el HDFS del clúster. Los nombres de los archivos HDFS no deben incluir asteriscos (\$1) ni signos de interrogación (?). **importante** Los nombres de los archivos no deben incluir asteriscos (\$1) ni signos de interrogación (?). 1. Especifique **No** en la opción **Auto-terminate** (Terminar automáticamente) de la configuración del clúster de Amazon EMR para que el clúster permanezca disponible mientras se ejecuta el comando COPY. **importante** Si se cambia o se elimina cualquiera de los archivos de datos antes de que se complete la operación COPY, se podrían obtener resultados inesperados o la operación COPY podría provocar un error. 1. Tome nota del ID de clúster y del DNS público principal del clúster (el punto de conexión para la instancia de Amazon EC2 que aloja el clúster). Usará esa información en pasos posteriores. ## Paso 3: Recuperar la clave pública del clúster de Amazon Redshift y las direcciones IP del nodo del clúster Usará la dirección IP para cada nodo del clúster con objeto de configurar los grupos de seguridad del alojamiento para que permitan obtener acceso desde su clúster de Amazon Redshift con esas direcciones IP. **Para recuperar la clave pública del clúster de Amazon Redshift y las direcciones IP del nodo del clúster para su clúster con la consola** 1. Acceda a la consola de administración de Amazon Redshift. 1. Elija el enlace de **Clusters** (Clústeres) en el panel de navegación. 1. Seleccione su clúster de la lista. 1. Localice el grupo **SSH Ingestion Settings (Configuración de ingestión de SSH)**. Tome nota de los valores de **Cluster Public Key (Clave pública del clúster)** y **Node IP addresses (Direcciones IP del nodo)**. Los usará en pasos posteriores. ![\[Captura de pantalla del grupo de configuración de ingestión de SSH que muestra la clave pública del clúster y las direcciones IP del nodo.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/copy-from-ssh-console-2.png) En el paso 3, usará las direcciones IP privadas para configurar el host de Amazon EC2 de forma que acepte la conexión de Amazon Redshift. Para recuperar la clave pública del clúster y las direcciones IP del nodo del clúster para su clúster mediante la CLI de Amazon Redshift, ejecute el comando describe-clusters. Por ejemplo: ``` aws redshift describe-clusters --cluster-identifier ``` La respuesta incluirá un valor ClusterPublicKey y la lista de direcciones IP públicas y privadas, similar a la siguiente: ``` { "Clusters": [ { "VpcSecurityGroups": [], "ClusterStatus": "available", "ClusterNodes": [ { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "LEADER", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-0", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-1", "PublicIPAddress": "10.nnn.nnn.nnn" } ], "AutomatedSnapshotRetentionPeriod": 1, "PreferredMaintenanceWindow": "wed:05:30-wed:06:00", "AvailabilityZone": "us-east-1a", "NodeType": "dc2.large", "ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift", ... ... } ``` Para recuperar la clave pública del clúster y las direcciones IP del nodo del clúster para su clúster mediante la API de Amazon Redshift, use la acción `DescribeClusters`. Para obtener más información, consulte [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) en la *Guía de la CLI de Amazon Redshift* o [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) en la Guía de la API de Amazon Redshift. ## Paso 4: Agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas de cada alojamiento de Amazon EC2 Debe agregar la clave pública del clúster al archivo de claves autorizadas de cada alojamiento en todos los nodos del clúster de Amazon EMR para que los alojamientos reconozcan a Amazon Redshift y acepten la conexión SSH. **Para agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento** 1. Obtenga acceso al host con una conexión Secure Shell (SSH, Shell seguro). Para obtener información acerca de cómo conectarse a una instancia con SSH, consulte [Conexión con la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) en la *Guía del usuario de Amazon EC2*. 1. Copie la clave pública de Amazon Redshift desde la consola o desde el texto de respuesta de la CLI. 1. Copie y pegue el contenido de la clave pública en el archivo `/home//.ssh/authorized_keys` que se encuentra en el host. Incluya la cadena completa, incluso el prefijo "`ssh-rsa`" y el sufijo "`Amazon-Redshift`". Por ejemplo: ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Paso 5: Configurar los alojamientos para que acepten todas las direcciones IP del clúster de Amazon Redshift Para permitir el tráfico de entrada a las instancias del alojamiento, edite el grupo de seguridad y agregue una regla de entrada por cada nodo del clúster de Amazon Redshift. En **Type (Tipo)**, seleccione SSH with TCP protocol on Port 22 (SSH con protocolo TCP en el puerto 22). En **Source** (Origen), ingrese las direcciones IP privadas de los nodos del clúster de Amazon Redshift que recuperó en [Paso 3: Recuperar la clave pública del clúster de Amazon Redshift y las direcciones IP del nodo del clúster](#load-from-emr-steps-retrieve-key-and-ips). Para obtener más información acerca de cómo se agregan las reglas a un grupo de seguridad de Amazon EC2, consulte [Autorización del tráfico de entrada para sus instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) en la *Guía del usuario de Amazon EC2*. ## Paso 6: Ejecutar el comando COPY para cargar los datos Ejecute un comando [COPY](r_COPY.md) para conectarse al clúster de Amazon EMR y cargar los datos en una tabla de Amazon Redshift. El clúster de Amazon EMR debe seguir ejecutándose hasta que se complete la ejecución del comando COPY. Por ejemplo, no configure el clúster para que se termine automáticamente. **importante** Si se cambia o se elimina cualquiera de los archivos de datos antes de que se complete la operación COPY, se podrían obtener resultados inesperados o la operación COPY podría provocar un error. En el comando COPY, especifique el ID del clúster de Amazon EMR y el nombre y la ruta del archivo HDFS. ``` COPY sales FROM 'emr://myemrclusterid/myoutput/part*' CREDENTIALS IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Puede usar los caracteres comodín de asterisco (`*`) y de signo de interrogación (`?`) como parte del argumento de nombre del archivo. Por ejemplo, `part*` carga los archivos `part-0000`, `part-0001` y, así, sucesivamente. Si solo especifica el nombre de una carpeta, COPY prueba cargar todos los archivos que se encuentran en ella. **importante** Si usa caracteres comodín o solo el nombre de la carpeta, controle que no se carguen archivos no deseados o el comando COPY provocará un error. Por ejemplo, algunos procesos podrían escribir un archivo de registro en la carpeta de salida. # Carga de datos desde hosts remotos Puede utilizar el comando COPY para cargar datos en paralelo desde uno o más alojamientos remotos, como instancias de Amazon EC2 u otros equipos. COPY se conecta a los alojamientos remotos por medio de SSH y ejecuta los comandos en los alojamientos remotos para generar texto de salida. El alojamiento remoto puede ser una instancia de Linux de Amazon EC2 u otro equipo Linux o Unix configurado para aceptar conexiones SSH. En esta guía, se asume que su alojamiento remoto es una instancia de Amazon EC2. Cuando el procedimiento sea diferente para otro equipo, en la guía se señalará la diferencia. Amazon Redshift puede conectarse a varios alojamientos y puede establecer varias conexiones SSH en cada alojamiento. Amazon Redshift envía un único comando a través de cada conexión para generar el texto que aparecerá en la salida estándar del alojamiento, que Amazon Redshift leerá después como cualquier otro archivo de texto. ## Antes de empezar Antes de empezar, debe haber implementado lo siguiente: + Uno o más equipos de alojamiento, como las instancias de Amazon EC2, a los que puede conectarse mediante SSH. + Orígenes de datos en los hosts. Proporcionará comandos que el clúster de Amazon Redshift ejecutará en los alojamientos para generar el texto de salida. Una vez que el clúster se conecta a un alojamiento, el comando COPY ejecuta los comandos, lee el texto de la salida estándar de los alojamientos y carga los datos en paralelo en una tabla de Amazon Redshift. El texto de salida debe tener un formato que el comando COPY pueda incorporar. Para obtener más información, consulte [Preparación de los datos de entrada](t_preparing-input-data.md) + Obtenga acceso a los hosts desde su equipo. En caso de una instancia de Amazon EC2, usará una conexión SSH para obtener acceso al alojamiento. Debe acceder al host para agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del host. + Un clúster de Amazon Redshift en ejecución. Para obtener información acerca de cómo lanzar un clúster, consulte [Guía de introducción a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/). ## Proceso de carga de datos En esta sección, se detalla el proceso de carga de datos desde hosts remotos. En las siguientes secciones, se proporcionan los detalles que debe completar en cada paso. + **[Paso 1: Recuperar la clave pública del clúster y las direcciones IP del nodo del clúster](#load-from-host-steps-retrieve-key-and-ips)** La clave pública permite a los nodos del clúster de Amazon Redshift establecer conexiones SSH a los alojamientos remotos. Usará la dirección IP para cada nodo del clúster con el fin de configurar el firewall o los grupos de seguridad del alojamiento para que permitan obtener acceso desde su clúster de Amazon Redshift con esas direcciones IP. + **[Paso 2: Agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento](#load-from-host-steps-add-key-to-host)** Debe agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento para que este último reconozca el clúster de Amazon Redshift y acepte la conexión SSH. + **[Paso 3: Configurar el alojamiento para que acepte todas las direcciones IP del clúster de Amazon Redshift](#load-from-host-steps-configure-security-groups)** Para Amazon EC2, modifique los grupos de seguridad de la instancia para agregar reglas de entrada que acepten las direcciones IP de Amazon Redshift. En caso de otros alojamientos, modifique el firewall de modo que los nodos de Amazon Redshift puedan establecer conexiones SSH al alojamiento remoto. + **[Paso 4: Obtener la clave pública para el host](#load-from-host-steps-get-the-host-key)** De manera alternativa, puede especificar que Amazon Redshift debe usar la clave pública para identificar el alojamiento. Debe localizar la clave pública y copiar el texto en el archivo de manifiesto. + **[Paso 5: Crear un archivo de manifiesto](#load-from-host-steps-create-manifest)** El manifiesto es un archivo de texto con formato JSON que tiene la información que Amazon Redshift necesita para conectarse a los alojamientos y obtener los datos. + **[Paso 6: Cargar el archivo de manifiesto en un bucket de Amazon S3](#load-from-host-steps-upload-manifest)** Amazon Redshift lee el manifiesto y usa esa información para conectarse al alojamiento remoto. Si el bucket de Amazon S3 no se encuentra en la misma región que el clúster de Amazon Redshift, debe usar la opción [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar la región en la que se encuentran los datos. + **[Paso 7: Ejecutar el comando COPY para cargar los datos](#load-from-host-steps-run-copy)** Ejecute el comando COPY desde una base de datos de Amazon Redshift para cargar los datos en una tabla de Amazon Redshift. ## Paso 1: Recuperar la clave pública del clúster y las direcciones IP del nodo del clúster Usará la dirección IP para cada nodo del clúster con objeto de configurar los grupos de seguridad del alojamiento para que permitan obtener acceso desde su clúster de Amazon Redshift con esas direcciones IP. **Pasos para recuperar la clave pública del clúster y las direcciones IP del nodo del clúster para su clúster con la consola** 1. Acceda a la consola de administración de Amazon Redshift. 1. Elija el enlace de **Clusters** (Clústeres) en el panel de navegación. 1. Seleccione su clúster de la lista. 1. Localice el grupo **SSH Ingestion Settings (Configuración de ingestión de SSH)**. Tome nota de los valores de **Cluster Public Key (Clave pública del clúster)** y **Node IP addresses (Direcciones IP del nodo)**. Los usará en pasos posteriores. ![\[Captura de pantalla del grupo de configuración de ingestión de SSH que muestra la clave pública del clúster y las direcciones IP del nodo.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/copy-from-ssh-console-2.png) En el paso 3, usará las direcciones IP para configurar el alojamiento de forma que acepte la conexión desde Amazon Redshift. Según el tipo de host al que se conecta y si se encuentra en una Virtual Private Cloud (VPC, Nube virtual privada), usará las direcciones IP públicas o las privadas. Para recuperar la clave pública del clúster y las direcciones IP del nodo del clúster para su clúster mediante la CLI de Amazon Redshift, ejecute el comando describe-clusters. Por ejemplo: ``` aws redshift describe-clusters --cluster-identifier ``` La respuesta incluirá el valor ClusterPublicKey y la lista de direcciones IP públicas y privadas, similar a la siguiente: ``` { "Clusters": [ { "VpcSecurityGroups": [], "ClusterStatus": "available", "ClusterNodes": [ { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "LEADER", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-0", "PublicIPAddress": "10.nnn.nnn.nnn" }, { "PrivateIPAddress": "10.nnn.nnn.nnn", "NodeRole": "COMPUTE-1", "PublicIPAddress": "10.nnn.nnn.nnn" } ], "AutomatedSnapshotRetentionPeriod": 1, "PreferredMaintenanceWindow": "wed:05:30-wed:06:00", "AvailabilityZone": "us-east-1a", "NodeType": "dc2.large", "ClusterPublicKey": "ssh-rsa AAAABexamplepublickey...Y3TAl Amazon-Redshift", ... ... } ``` Para recuperar la clave pública del clúster y las direcciones IP del nodo del clúster para su clúster mediante la API de Amazon Redshift, use la acción DescribeClusters. Para obtener más información, consulte [describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html) en la *Guía de la CLI de Amazon Redshift* o [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) en la Guía de la API de Amazon Redshift. ## Paso 2: Agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento Debe agregar la clave pública del clúster al archivo de claves autorizadas de cada alojamiento para que este último reconozca a Amazon Redshift y acepte la conexión SSH. **Para agregar la clave pública del clúster de Amazon Redshift al archivo de claves autorizadas del alojamiento** 1. Obtenga acceso al host con una conexión Secure Shell (SSH, Shell seguro). Para obtener información acerca de cómo conectarse a una instancia con SSH, consulte [Conexión con la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html) en la *Guía del usuario de Amazon EC2*. 1. Copie la clave pública de Amazon Redshift desde la consola o desde el texto de respuesta de la CLI. 1. Copie y pegue el contenido de la clave pública en el archivo `/home//.ssh/authorized_keys` que se encuentra en el host remoto. `` debe coincidir con el valor del campo "username" del archivo de manifiesto. Incluya la cadena completa, incluso el prefijo "`ssh-rsa`" y el sufijo "`Amazon-Redshift`". Por ejemplo: ``` ssh-rsa AAAACTP3isxgGzVWoIWpbVvRCOzYdVifMrh… uA70BnMHCaMiRdmvsDOedZDOedZ Amazon-Redshift ``` ## Paso 3: Configurar el alojamiento para que acepte todas las direcciones IP del clúster de Amazon Redshift Si está trabajando con una instancia de Amazon EC2 o con un clúster de Amazon EMR, agregue reglas de entrada al grupo de seguridad del alojamiento para permitir tráfico desde cada nodo del clúster de Amazon Redshift. En **Type (Tipo)**, seleccione SSH with TCP protocol on Port 22 (SSH con protocolo TCP en el puerto 22). En **Source** (Origen), ingrese las direcciones IP de los nodos del clúster de Amazon Redshift que recuperó en [Paso 1: Recuperar la clave pública del clúster y las direcciones IP del nodo del clúster](#load-from-host-steps-retrieve-key-and-ips). Para obtener más información acerca de cómo se agregan las reglas a un grupo de seguridad de Amazon EC2, consulte [Autorización del tráfico de entrada para sus instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html) en la *Guía del usuario de Amazon EC2*. Use las direcciones IP privadas en los casos que se muestran a continuación: + Tiene un clúster de Amazon Redshift que no se encuentra en una Virtual Private Cloud (VPC) y una instancia de Amazon EC2-Classic, y ambas se encuentran en la misma región de AWS. + Tiene un clúster de Amazon Redshift que se encuentra en una VPC y una instancia de Amazon EC2-VPC, y ambas se encuentran en la misma región de AWS y en la misma VPC. De lo contrario, use las direcciones IP públicas. Para obtener más información acerca del uso de Amazon Redshift en una VPC, consulte [Administración de clústeres en nube privada virtual (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html) en la *Guía de administración de Amazon Redshift*. ## Paso 4: Obtener la clave pública para el host De manera opcional, puede proporcionar la clave pública del alojamiento en el archivo de manifiesto de manera que Amazon Redshift pueda identificar al alojamiento. El comando COPY no requiere la clave pública del host; no obstante, por motivos de seguridad, le recomendamos encarecidamente que use una clave pública para ayudar a evitar ataques de tipo "man-in-the-middle". Puede encontrar la clave pública del host en la siguiente ubicación, donde `` es el nombre único de la clave pública del host: ``` : /etc/ssh/.pub ``` **nota** Amazon Redshift solo es compatible con claves RSA. No es compatible con claves DSA. Al crear el archivo de manifiesto en el paso 5, copiará el texto de la clave pública en el campo "Public Key", en la entrada del archivo de manifiesto. ## Paso 5: Crear un archivo de manifiesto El comando COPY puede conectarse con distintos hosts mediante Secure Shell (SSH, Shell seguro) y puede crear distintas conexiones SSH a cada host. COPY ejecuta un comando a través de cada conexión al host y, luego, carga la salida en la tabla desde los comandos en paralelo. El archivo de manifiesto es un archivo de texto con formato JSON que Amazon Redshift usa para conectarse al alojamiento. En el archivo de manifiesto, se especifican los puntos de conexión del alojamiento SSH y los comandos que se ejecutan en los alojamientos para devolver los datos a Amazon Redshift. De forma opcional, puede incluir la clave pública del host, el nombre de usuario de inicio de sesión y una marca obligatoria para cada entrada. Cree el archivo de manifiesto en su equipo local. En un paso posterior, cargará el archivo en Amazon S3. El archivo de manifiesto se encuentra en el siguiente formato: ``` { "entries": [ {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": ""}, {"endpoint":"", "command": "", "mandatory":true, "publickey": "", "username": "host_user_name"} ] } ``` El archivo de manifiesto tiene una construcción "entries" para cada conexión SSH. Cada entrada representa una conexión SSH única. Puede tener distintas conexiones a un único host o distintas conexiones a distintos hosts. Se requieren comillas dobles, como se muestra, para los valores y los nombres de campo. El único valor que no necesita comillas dobles es el valor booleano **true** o **false** del campo obligatorio. A continuación se describen los campos del archivo de manifiesto. endpoint La dirección URL o dirección IP del host. Por ejemplo, “`ec2-111-222-333.compute-1.amazonaws.com`” o “`22.33.44.56`” comando El comando que el alojamiento ejecutará para generar la salida binaria o de texto (en formato gzip, lzop o bzip2). El comando puede ser cualquiera que el usuario *"host\$1user\$1name" (nombre\$1de\$1usuario\$1del\$1host)* tenga permiso para ejecutar. El comando puede ser tan sencillo como imprimir un archivo, o podría consultar una base de datos o lanzar un script. La salida (archivo de texto o archivo binario gzip, lzop o bzip2) debe estar en un formato que el comando COPY de Amazon Redshift pueda capturar. Para obtener más información, consulte [Preparación de los datos de entrada](t_preparing-input-data.md). publickey (Opcional) La clave pública del host. Si se proporciona la clave pública, Amazon Redshift la usará para identificar el alojamiento. Si no se proporciona la clave pública, Amazon Redshift no intentará identificar el alojamiento. Por ejemplo, si la clave pública del host remoto es: `ssh-rsa AbcCbaxxx…xxxDHKJ root@amazon.com`, escriba el siguiente texto en el campo de clave pública: `AbcCbaxxx…xxxDHKJ`. mandatory (Opcional) Indica si el comando COPY debe fallar en caso de que la conexión falle. El valor predeterminado es `false`. Si Amazon Redshift no logra al menos una conexión de manera correcta, se produce un error en el comando COPY. nombre de usuario (Opcional) Se trata del nombre de usuario que se utilizará para iniciar sesión en el sistema de alojamiento y ejecutar el comando remoto. El nombre de inicio de sesión de usuario debe ser el mismo que el del inicio de sesión que se utilizó para agregar la clave pública al archivo de claves autorizadas del host en el paso 2. El nombre de usuario predeterminado es "redshift". En el siguiente ejemplo, se observa un manifiesto completado para abrir cuatro conexiones en el mismo alojamiento y ejecutar un comando diferente a través de cada conexión: ``` { "entries": [ {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata1.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata2.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata3.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"}, {"endpoint":"ec2-184-72-204-112.compute-1.amazonaws.com", "command": "cat loaddata4.txt", "mandatory":true, "publickey": "ec2publickeyportionoftheec2keypair", "username": "ec2-user"} ] } ``` ## Paso 6: Cargar el archivo de manifiesto en un bucket de Amazon S3 Cargue el archivo de manifiesto en un bucket de Amazon S3. Si el bucket de Amazon S3 no se encuentra en la misma región de AWS que el clúster de Amazon Redshift, debe usar la opción [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar la región de AWS en la que se encuentra el manifiesto. Para obtener información acerca de cómo crear un bucket de Amazon S3 y cómo cargar un archivo, consulte [Guía del usuario de Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/). ## Paso 7: Ejecutar el comando COPY para cargar los datos Ejecute un comando [COPY](r_COPY.md) para conectarse al alojamiento y cargar los datos en una tabla de Amazon Redshift. En el comando COPY, especifique la ruta de objeto de Amazon S3 de forma explícita para el archivo de manifiesto e incluya la opción para el SSH. Por ejemplo, ``` COPY sales FROM 's3://amzn-s3-demo-bucket/ssh_manifest' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' SSH; ``` **nota** Si utiliza la compresión automática, el comando COPY realizará dos lecturas de datos, lo que significa que ejecuta el comando remoto dos veces. La primera lectura se realiza para proporcionar una muestra para el análisis de compresión, la segunda lectura es la que carga los datos. Si la ejecución del comando remoto dos veces puede ocasionar un problema debido a efectos secundarios potenciales, debe desactivar la compresión automática. Para desactivar la compresión automática, ejecute el comando COPY con la opción COMPUPDATE establecida en OFF. Para obtener más información, consulte [Carga de tablas con compresión automática](c_Loading_tables_auto_compress.md). # Carga de datos desde una tabla de Amazon DynamoDB Puede usar el comando COPY para cargar una tabla con datos de una tabla específica de Amazon DynamoDB. **importante** La tabla de Amazon DynamoDB que proporciona los datos debe crearse en la misma región de AWS que el clúster, a menos que use la opción [REGION](copy-parameters-data-source-s3.md#copy-region) para especificar la región de AWS en la que se encuentra la tabla de Amazon DynamoDB. El comando COPY utiliza la arquitectura de procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos en paralelo desde una tabla de Amazon DynamoDB. Para aprovechar al máximo los beneficios del procesamiento en paralelo, puede establecer estilos de distribución en las tablas de Amazon Redshift. Para obtener más información, consulte [Distribución de datos para la optimización de consultas](t_Distributing_data.md). **importante** Cuando el comando COPY lee los datos desde la tabla de Amazon DynamoDB, la transferencia de datos resultante es parte del rendimiento aprovisionado de esa tabla. Para evitar el consumo de cantidades excesivas de rendimiento de lectura aprovisionado, le recomendamos que no cargue datos de las tablas de Amazon DynamoDB que se encuentren en entornos de producción. Si efectivamente carga datos desde tablas de producción, le recomendamos que establezca la opción READRATIO en un valor mucho más bajo que el porcentaje promedio de rendimiento provisionado no usado. Una configuración READRATIO baja ayudará a minimizar los problemas de limitación controlada. Para usar el rendimiento aprovisionado completo de una tabla de Amazon DynamoDB, establezca el valor de READRATIO en 100. El comando COPY establece una concordancia entre los nombres de atributo de los elementos recuperados de la tabla de DynamoDB y los nombres de columna de una tabla de Amazon Redshift existente mediante las siguientes reglas: + Las columnas de la tabla de Amazon Redshift establecen una concordancia, sin distinción entre mayúsculas y minúsculas, con los atributos de los elementos de Amazon DynamoDB. Si un elemento en la tabla de DynamoDB tiene varios atributos que difieren solo en las mayúsculas y minúsculas, como Price y PRICE, el comando COPY provocará un error. + Las columnas de la tabla de Amazon Redshift que no concuerdan con ningún atributo de la tabla de Amazon DynamoDB se cargan como NULL o empty, según el valor especificado en la opción EMPTYASNULL del comando [COPY](r_COPY.md). + Los atributos de Amazon DynamoDB que no concuerdan con ninguna columna de la tabla de Amazon Redshift se descartan. Los atributos se leen antes de hacerlos coincidir, por lo que incluso los atributos descartados consumen parte del rendimiento provisionado de esa tabla. + Solo se admiten los atributos de Amazon DynamoDB con tipos de datos STRING y NUMBER escalares. No se admiten los tipos de datos BINARY y SET de Amazon DynamoDB. Si un comando COPY prueba cargar un atributo con un tipo de dato incompatible, el comando provocará un error. Si el atributo no concuerda con una columna de la tabla de Amazon Redshift, COPY no intenta cargarlo y no genera un error. El comando COPY usa la siguiente sintaxis para cargar datos desde una tabla de Amazon DynamoDB: ``` COPY FROM 'dynamodb://' authorization readratio ''; ``` Los valores de *authorization* (autorización) son las credenciales de AWS necesarias para obtener acceso a la tabla de Amazon DynamoDB. Si estas credenciales corresponden a un usuario, este último debe tener permiso para el uso de SCAN y DESCRIBE en la tabla de Amazon DynamoDB que se está cargando. Los valores de *authorization* (autorización) proporcionan la autorización de AWS que el clúster necesita para obtener acceso a la tabla de Amazon DynamoDB. El permiso debe incluir el uso de SCAN y DESCRIBE en la tabla de Amazon DynamoDB que se está cargando. Para obtener más información acerca de los permisos requeridos, consulte [Permisos de IAM para COPY, UNLOAD y CREATE LIBRARY](copy-usage_notes-access-permissions.md#copy-usage_notes-iam-permissions). El método de autenticación preferido es especificar el parámetro IAM\$1ROLE y proporcionar el Amazon Resource Name (ARN, Nombre de recurso de Amazon) de un rol de IAM con los permisos necesarios. Para obtener más información, consulte [Control de acceso con base en roles](copy-usage_notes-access-permissions.md#copy-usage_notes-access-role-based). Para realizar la autenticación con el parámetro IAM\$1ROLE, reemplace ** y **, tal y como se observa en la siguiente sintaxis. ``` IAM_ROLE 'arn:aws:iam:::role/' ``` En el siguiente ejemplo, se muestra la autenticación con un rol de IAM. ``` COPY favoritemovies FROM 'dynamodb://ProductCatalog' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` Para obtener más información acerca de otras opciones de autorización, consulte . [Parámetros de autorización](copy-parameters-authorization.md) Si desea validar los datos sin cargar de hecho la tabla, use la opción NOLOAD con el comando [COPY](r_COPY.md). En el siguiente ejemplo, la tabla FAVORITEMOVIES se carga con datos de la tabla de DynamoDB my-favorite-movies-table. La actividad de lectura puede consumir hasta el 50% del rendimiento provisionado. ``` COPY favoritemovies FROM 'dynamodb://my-favorite-movies-table' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' READRATIO 50; ``` Para maximizar el rendimiento, el comando COPY carga los datos desde una tabla de Amazon DynamoDB en paralelo en todos los nodos informáticos del clúster. ## Rendimiento aprovisionado con compresión automática De forma predeterminada, el comando COPY aplica una compresión automática siempre que especifique una tabla destino vacía sin cifrado de compresión. En un principio, el análisis de compresión automático realiza una muestra de una gran cantidad de filas de la tabla de Amazon DynamoDB. El tamaño de la muestra se basa en el valor del parámetro COMPROWS. El valor predeterminado es 100 000 filas por sector. Una vez terminado el muestreo, las filas de muestra se descartan y se carga la tabla completa. Como resultado, muchas filas se leen dos veces. Para obtener más información acerca de cómo funciona la compresión automática, consulte [Carga de tablas con compresión automática](c_Loading_tables_auto_compress.md). **importante** Cuando el comando COPY lee datos de la tabla de Amazon DynamoDB, incluidas las filas usadas para el muestreo, la transferencia de datos resultante es parte del rendimiento aprovisionado de esa tabla. ## Carga de datos multibyte desde Amazon DynamoDB Si los datos incluyen caracteres multibyte no ASCII (como caracteres cirílicos o chinos) debe cargar los datos en columnas VARCHAR. El tipo de datos VARCHAR admite caracteres UTF-8 de cuatro bytes, pero el tipo de datos CHAR solo acepta caracteres ASCII de un solo byte. No puede cargar caracteres de cinco bytes o más en tablas de Amazon Redshift. Para obtener más información acerca de los comandos CHAR y VARCHAR, consulte [Tipos de datos](c_Supported_data_types.md). # Comprobación de carga correcta de datos Luego de que se complete la operación de carga, consulte la tabla de sistema [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md) para controlar que se hayan cargado los archivos esperados. Ejecute el comando COPY y la verificación de carga en la misma transacción, de manera que si se produce un problema con la carga, se pueda revertir toda la transacción. La siguiente consulta devuelve entradas para la carga de las tablas en la base de datos TICKIT: ``` SELECT query, trim(filename) AS filename, curtime, status FROM stl_load_commits WHERE filename like '%tickit%' order by query; query | filename | curtime | status -------+---------------------------+----------------------------+-------- 22475 | tickit/allusers_pipe.txt | 2013-02-08 20:58:23.274186 | 1 22478 | tickit/venue_pipe.txt | 2013-02-08 20:58:25.070604 | 1 22480 | tickit/category_pipe.txt | 2013-02-08 20:58:27.333472 | 1 22482 | tickit/date2008_pipe.txt | 2013-02-08 20:58:28.608305 | 1 22485 | tickit/allevents_pipe.txt | 2013-02-08 20:58:29.99489 | 1 22487 | tickit/listings_pipe.txt | 2013-02-08 20:58:37.632939 | 1 22489 | tickit/sales_tab.txt | 2013-02-08 20:58:37.632939 | 1 (6 rows) ``` # Validación de datos de entrada Para validar los datos de los archivos de entrada de Amazon S3 o de la tabla de Amazon DynamoDB antes de que los datos se carguen, use la opción NOLOAD con el comando [COPY](r_COPY.md). Use NOLOAD con los mismos comandos COPY y con las mismas opciones que usaría para cargar los datos. NOLOAD comprueba la integridad de todos los datos sin cargarlos en la base de datos. La opción NOLOAD muestra los errores que se producen si intenta cargar los datos. Por ejemplo, si especificó una ruta de Amazon S3 incorrecta para el archivo de entrada, Amazon Redshift mostrará el siguiente error. ``` ERROR: No such file or directory DETAIL: ----------------------------------------------- Amazon Redshift error: The specified key does not exist code: 2 context: S3 key being read : location: step_scan.cpp:1883 process: xenmaster [pid=22199] ----------------------------------------------- ``` Para solucionar problemas con los mensajes de error, consulte [Referencia de error de carga](r_Load_Error_Reference.md). Para ver un ejemplo de uso de la opción NOLOAD, consulte [Comando COPY con la opción NOLOAD](r_COPY_command_examples.md#r_COPY_command_examples-load-noload-option). # Carga de tablas con compresión automática Puede aplicar codificaciones de compresión manualmente a las columnas de las tablas, en función de su propia evaluación de los datos. También puede utilizar el comando COPY con COMPUPDATE establecido en ON para analizar y aplicar la compresión de forma automática en función de los datos de muestra. Puede usar la compresión automática al crear y cargar una tabla completamente nueva. El comando COPY realiza un análisis de compresión. También puede realizar un análisis de compresión sin cargar datos ni cambiar la compresión de una tabla ejecutando el comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) en una tabla que ya contenga datos. Por ejemplo, puede ejecutar ANALYZE COMPRESSION si desea analizar la compresión de una tabla para utilizarla más adelante y presentar las instrucciones del lenguaje de definición de datos (DDL) existente. La compresión automática equilibra el rendimiento general al elegir las codificaciones de compresión. Los exámenes de rango restringido podrían tener un rendimiento deficiente cuando las columnas de clave con ordenación se comprimen mucho más que otras columnas en la misma consulta. Como resultado, la compresión automática omitirá la fase de análisis de datos en las columnas con la clave de ordenación y mantendrá los tipos de codificación definidos por el usuario. La compresión automática elige la codificación RAW si no se ha definido explícitamente ningún tipo de codificación. ANALYZE COMPRESSION hace lo mismo. Para obtener un rendimiento óptimo de las consultas, considere la posibilidad de utilizar RAW con las claves de ordenación. ## Cómo funciona la compresión automática Cuando el parámetro COMPUDATE está establecido en ON, el comando COPY aplica la compresión automática siempre que se ejecute con una tabla de destino y todas las columnas de la tabla tengan codificación RAW o no tengan codificación. Para aplicar la compresión automática en una tabla vacía, independientemente de sus codificaciones de compresión actuales, ejecute el comando COPY con la opción COMPUPDATE establecida en ON. Para desactivar la compresión automática, ejecute el comando COPY con la opción COMPUPDATE establecida en OFF. No puede aplicar la compresión automática a una tabla que ya tiene datos. **nota** El análisis de compresión automático requiere suficientes filas en los datos cargados (al menos 100 000 filas por sector) con objeto de generar una muestra significativa. La compresión automática realiza estas operaciones en segundo plano como parte de la transacción de carga: 1. Una muestra inicial de filas se carga desde el archivo de entrada. El tamaño de la muestra se basa en el valor del parámetro COMPROWS. El valor predeterminado es 100,000. 1. Las opciones de compresión se seleccionan para cada columna. 1. Las filas de muestra se eliminan de la tabla. 1. La tabla se recrea con las codificaciones de compresión seleccionadas. 1. El archivo de entrada completo se carga y se comprime con las codificaciones nuevas. Una vez ejecutado el comando COPY, la tabla se encuentra completamente cargada, comprimida y lista para su uso. Si carga más datos con posterioridad, las filas agregadas se comprimen según la codificación existente. Si solo desea realizar un análisis de compresión, ejecute ANALYZE COMPRESSION, lo cual es más eficiente que ejecutar COPY por completo. Luego, puede evaluar los resultados para decidir si usar la compresión automática o recrear la tabla manualmente. La compresión automática es compatible solo para el comando COPY. De manera alternativa, puede aplicar la codificación de compresión manualmente al crear la tabla. Para obtener información acerca de la codificación de compresión manual, consulte [Compresión de columnas para reducir el tamaño de los datos almacenados](t_Compressing_data_on_disk.md). ## Ejemplo de compresión automática En este ejemplo, se asume que la base de datos TICKIT tiene una copia de la tabla LISTING denominada BIGLIST y que usted desea aplicar la compresión automática en esta tabla una vez cargada con, aproximadamente, 3 millones de filas. **Pasos para cargar y comprimir una tabla automáticamente** 1. Asegúrese de que la tabla esté vacía. Puede aplicar la compresión automática solamente a una tabla vacía: ``` TRUNCATE biglist; ``` 1. Cargue la tabla con un comando COPY único. Aunque la tabla esté vacía, cierta codificación podría haberse especificado con anterioridad. Para facilitar que Amazon Redshift realice un análisis de compresión, establezca el parámetro COMPUPDATE en ON. ``` COPY biglist FROM 's3://amzn-s3-demo-bucket/biglist.txt' IAM_ROLE 'arn:aws:iam::0123456789012:role/MyRedshiftRole' DELIMITER '|' COMPUPDATE ON; ``` Como no se especifica una opción COMPROWS, se usa el tamaño de la muestra predeterminado y recomendado, que es 100 000 filas por sector. 1. Observe el esquema nuevo para la tabla BIGLIST con objeto de revisar los esquemas de codificación seleccionados de manera automática. ``` SELECT "column", type, encoding from pg_table_def where tablename = 'biglist'; Column | Type | Encoding ----------------+-----------------------------+---------- listid | integer | az64 sellerid | integer | az64 eventid | integer | az64 dateid | smallint | none numtickets | smallint | az64 priceperticket | numeric(8,2) | az64 totalprice | numeric(8,2) | az64 listtime | timestamp without time zone | az64 ``` 1. Compruebe que se haya cargado la cantidad de filas esperada: ``` select count(*) from biglist; count --------- 3079952 (1 row) ``` Cuando, posteriormente, se agreguen filas a esta tabla mediante instrucciones COPY o INSERT, se aplican las mismas codificaciones de compresión. # Optimización del almacenamiento para tablas angostas Si tiene una tabla con muy pocas columnas, pero con una gran cantidad de filas, las tres columnas de identidad de metadatos ocultas (INSERT\$1XID, DELETE\$1XID, ROW\$1ID) consumirán una cantidad desproporcionada del espacio en disco para la tabla. Para optimizar la compresión de las columnas ocultas, cargue la tabla en una transacción COPY única siempre que sea posible. Si carga la tabla con distintos comandos COPY por separado, la columna INSERT\$1XID no se comprimirá bien. Si usa distintos comandos COPY, debe realizar una operación de limpieza, pero no mejorará la compresión de INSERT\$1XID. # Carga de valores de columna predeterminados De manera opcional, puede definir una lista de columnas en su comando COPY. Si una columna de la tabla se omite en la lista de columnas, COPY la copiará o con el valor proporcionado por la opción DEFAULT especificada en el comando CREATE TABLE o con NULL, si la opción DEFAULT no se especificó. Si COPY prueba asignar NULL a una columna que está definida como NOT NULL, el comando COPY falla. Para obtener información acerca de asignar la opción DEFAULT, consulte [CREATE TABLE](r_CREATE_TABLE_NEW.md). Cuando se realiza la carga desde los archivos de datos en Amazon S3, las columnas de la lista de columnas deben encontrarse en el mismo orden en que se encuentran los campos en el archivo de datos. Si un campo en el archivo de datos no tiene una columna correspondiente en la lista de columnas, el comando COPY provocará un error. Cuando se realiza la carga desde una tabla de Amazon DynamoDB, el orden no importa. Los campos en los atributos de Amazon DynamoDB que no concuerdan con ninguna columna de la tabla de Amazon Redshift se descartan. Al usar el comando COPY para cargar valores DEFAULT en una tabla se aplican las siguientes restricciones: + Si se incluye una columna [IDENTITY](r_CREATE_TABLE_NEW.md#identity-clause) en la lista de columnas, también se debe especificar la opción EXPLICIT\$1IDS en el comando [COPY](r_COPY.md), o este último provocará un error. De manera similar, si se omite una columna IDENTITY de la lista de columnas y se especifica la opción EXPLICIT\$1IDS, la operación COPY provocará un error. + Como la expresión DEFAULT evaluada para una columna dada es la misma para todas las filas cargadas, una expresión DEFAULT que usa una función RANDOM() asignará el mismo valor a todas las filas. + Las expresiones DEFAULT que tienen CURRENT\$1DATE o SYSDATE se establecen según la marca temporal de la transacción actual. Para obtener un ejemplo, consulte "Load data from a file with default values" en [Ejemplos de COPY](r_COPY_command_examples.md). # Solución de problemas en cargas de datos Al cargar datos en tablas de Amazon Redshift, es posible que encuentre errores de Amazon S3, datos de entrada no válidos y errores del comando COPY. En las siguientes secciones, se ofrece información acerca de cómo identificar y resolver errores en la carga de datos. **Topics** + [Solución de los errores de la integración de eventos de S3 y COPY JOB](s3-integration-troubleshooting.md) + [Errores S3ServiceException](s3serviceexception-error.md) + [Tablas de sistema para la solución de problemas de cargas de datos](system-tables-for-troubleshooting-data-loads.md) + [Errores de carga de caracteres multibyte](multi-byte-character-load-errors.md) + [Referencia de error de carga](r_Load_Error_Reference.md) # Solución de los errores de la integración de eventos de S3 y COPY JOB Utilice la siguiente información para solucionar problemas habituales de la integración de eventos de Amazon S3 y COPY JOB con Amazon Redshift. ## Error en la creación de la integración de eventos de S3 Si se ha producido un error en la creación de la integración de eventos de S3, el estado de la integración será `Inactive`. Asegúrese de que lo siguiente sea correcto para el almacenamiento de datos de Amazon Redshift. + Ha añadido la entidad principal autorizada y el origen de la integración correctos para su espacio de nombres de destino en Amazon Redshift. Consulte [Requisitos previos para crear una integración de eventos de S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). + Ha añadido la política basada en recursos correcta al bucket de Amazon S3 de origen. Consulte [Requisitos previos para crear una integración de eventos de S3](loading-data-copy-job.md#loading-data-copy-job-prerequisites). ## Los datos de Amazon S3 no aparecen en la base de datos de destino Si no aparecen los datos de un COPY JOB, compruebe lo siguiente. + Consulte SYS\$1COPY\$1JOB\$1DETAIL para ver si el archivo de Amazon S3 se ha cargado, si está pendiente de ingesta o si hay algún error. Para obtener más información, consulte [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md). + Consulte STL\$1ERROR o SYS\$1COPY\$1JOB\$1INFO si el archivo de Amazon S3 no está ahí o si se produce un tiempo de espera inesperado. Busque errores de credenciales o cualquier cosa que sugiera que la integración está inactiva. Para obtener más información, consulte [STL\$1ERROR](r_STL_ERROR.md) y [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md). # Errores S3ServiceException Los errores s3ServiceException más comunes son causados por una cadena de credenciales incorrecta o sin el formato adecuado, la presencia del clúster y el bucket en regiones de AWS diferentes y permisos de Amazon S3 insuficientes. En esta sección, se proporciona información acerca de cómo solucionar problemas para cada tipo de error. ## Cadena de credenciales no válida Si la cadena de credenciales no tiene el formato adecuado, recibirá el siguiente mensaje de error: ``` ERROR: Invalid credentials. Must be of the format: credentials 'aws_access_key_id=;aws_secret_access_key= [;token=]' ``` Compruebe que la cadena de credenciales no tenga espacios ni saltos de línea y que se encuentre delimitada entre comillas simples. ## ID de clave de acceso no válida Si el ID de clave de acceso no existe, recibirá el siguiente mensaje de error: ``` [Amazon](500310) Invalid operation: S3ServiceException:The AWS Access Key Id you provided does not exist in our records. ``` Este suele ser un error de copiado y pegado. Compruebe que el ID de clave de acceso se haya escrito correctamente. Además, si utiliza claves de sesiones temporales, compruebe que esté definido el valor de `token`. ## Clave de acceso secreta no válida Si su clave de acceso secreta es incorrecta, recibirá el siguiente mensaje de error: ``` [Amazon](500310) Invalid operation: S3ServiceException:The request signature we calculated does not match the signature you provided. Check your key and signing method.,Status 403,Error SignatureDoesNotMatch ``` Este suele ser un error de copiado y pegado. Compruebe que la clave de acceso secreta se haya escrito correctamente y que sea la clave correcta para el ID de clave de acceso. ## El bucket está en una región diferente El bucket de Amazon S3 especificado en el comando COPY debe estar en la misma región de AWS que el clúster. Si su bucket de Amazon S3 y su clúster están en regiones diferentes, se producirá un error similar al siguiente: ``` ERROR: S3ServiceException:The bucket you are attempting to access must be addressed using the specified endpoint. ``` Puede crear un bucket de Amazon S3 en una región específica. Para ello, seleccione la región mientras crea el bucket con la consola de administración de Amazon S3 o especifique un punto de conexión mientras crea el bucket con la CLI o la API de Amazon S3. Para obtener más información, consulte [Carga de archivos en Amazon S3 para utilizar con COPY](t_uploading-data-to-S3.md). Para obtener más información acerca de las regiones de Amazon S3, consulte [Acceso a un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html#access-bucket-intro) en la *Guía del usuario de Amazon Simple Storage Service*. También puede especificar la región utilizando la opción [REGION](copy-parameters-data-source-s3.md#copy-region) con el comando COPY. ## Acceso denegado Si el usuario no tiene permisos suficientes, recibirá el siguiente mensaje de error: ``` ERROR: S3ServiceException:Access Denied,Status 403,Error AccessDenied ``` Una causa posible es que el usuario identificado por las credenciales no tiene acceso LIST y GET al bucket de Amazon S3. Para otras causas, consulte [Solucionar errores de acceso denegado (403 Prohibido) en Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html) en la *Guía del usuario de Amazon Simple Storage Service*. Para obtener información sobre cómo administrar el acceso de los usuarios a los buckets, consulte [Administración de identidades y accesos en Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) en la *Guía del usuario de Amazon Simple Storage Service*. # Tablas de sistema para la solución de problemas de cargas de datos Las siguientes tablas del sistema de Amazon Redshift pueden ser útiles para solucionar problemas relacionados con la carga de datos: + Ejecute la consulta [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) para encontrar los errores que ocurrieron durante cargas específicas. + Ejecute la consulta [STL\$1FILE\$1SCAN](r_STL_FILE_SCAN.md) para ver los tiempos de carga de archivos específicos o para ver si un archivo específico siquiera se leyó. + Ejecute la consulta [STL\$1S3CLIENT\$1ERROR](r_STL_S3CLIENT_ERROR.md) para encontrar detalles sobre los errores que surgieron mientras se transferían datos desde Amazon S3. **Pasos para encontrar y diagnosticar errores de carga** 1. Cree una vista o defina una consulta que devuelve detalles sobre errores de carga. En el siguiente ejemplo, se combina la tabla STL\$1LOAD\$1ERRORS y la tabla STV\$1TBL\$1PERM para hacer coincidir los ID de tabla con los nombres reales de tabla. ``` create view loadview as (select distinct tbl, trim(name) as table_name, query, starttime, trim(filename) as input, line_number, colname, err_code, trim(err_reason) as reason from stl_load_errors sl, stv_tbl_perm sp where sl.tbl = sp.id); ``` 1. Establezca la opción MAXERRORS en el comando COPY en un valor lo suficientemente grande como para permitirle a COPY que devuelva información útil sobre sus datos. Si COPY encuentra errores, un mensaje de error le indica que consulte la tabla STL\$1LOAD\$1ERRORS para obtener detalles. 1. Consulte la vista LOADVIEW para obtener detalles del error. Por ejemplo: ``` select * from loadview where table_name='venue'; ``` ``` tbl | table_name | query | starttime --------+------------+-------+---------------------------- 100551 | venue | 20974 | 2013-01-29 19:05:58.365391 | input | line_number | colname | err_code | reason +----------------+-------------+---------+----------+-------------------- | venue_pipe.txt | 1 | 0 | 1214 | Delimiter not found ``` 1. Corrija el problema en el archivo de entrada o en el script de carga, en función de la información que devuelva la vista. Entre los errores de carga habituales por buscar se incluyen los siguientes: + Discrepancia entre los tipos de datos de la tabla y los valores de los campos de datos de entrada. + Discrepancia entre la cantidad de columnas de la tabla y la cantidad de campos de datos de entrada. + Discrepancia en las comillas. Amazon Redshift admite comillas simples y dobles; no obstante, las comillas deben equilibrarse de forma adecuada. + Formato incorrecto para los datos de fecha/hora en los archivos de entrada. + Valores fuera de rango en los archivos de entrada (para las columnas numéricas). + La cantidad de valores distintos para una columna supera la limitación para su codificación de compresión. # Errores de carga de caracteres multibyte Las columnas con un tipo de datos CHAR aceptan solamente caracteres UTF-8 de un solo byte, hasta un valor de byte 127 o 7F hexadecimal, que también es el conjunto de caracteres ASCII. Las columnas VARCHAR aceptan caracteres multibyte UTF-8 de hasta un máximo de cuatro bytes. Para obtener más información, consulte [Tipos de caracteres](r_Character_types.md). Si una línea de los datos cargados contiene un carácter no válido para el tipo de datos de la columna, COPY devuelve un error y registra una fila en la tabla de registro del sistema STL\$1LOAD\$1ERRORS con el número de error 1220. El campo ERR\$1REASON incluye la secuencia de bytes, en hexadecimal, para el carácter no válido. Una alternativa a corregir caracteres no válidos en los datos de carga es sustituir los caracteres no válidos durante el proceso de carga. Para reemplazar los caracteres UTF-8 no válidos, especifique la opción ACCEPTINVCHARS del comando COPY. Si se ha configurado la opción ACCEPTINVCHARS, el carácter que especifique sustituye al punto de código. Si la opción ACCEPTINVCHARS no está configurada, Amazon Redshift acepta los caracteres como UTF-8 válido. Para obtener más información, consulte [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars). La siguiente lista de puntos de código es UTF-8 válida, las operaciones COPY no devuelven un error si la opción ACCEPTINVCHARS no está configurada. No obstante, estos puntos de código son caracteres no válidos. Puede utilizar la opción [ACCEPTINVCHARS](copy-parameters-data-conversion.md#acceptinvchars) para reemplazar un punto de código por un carácter que especifique. Estos puntos de código incluyen el rango de valores de `0xFDD0` a `0xFDEF` y valores hasta `0x10FFFF`, terminando con `FFFE` o `FFFF`: + `0xFFFE`, `0x1FFFE`, `0x2FFFE`, …, `0xFFFFE`, `0x10FFFE` + `0xFFFF`, `0x1FFFF`, `0x2FFFF`, …, `0xFFFFF`, `0x10FFFF` En el siguiente ejemplo, se muestra la razón del error cuando COPY intenta cargar el carácter UTF-8 `e0 a1 c7a4` en una columna CHAR. ``` Multibyte character not supported for CHAR (Hint: Try using VARCHAR). Invalid char: e0 a1 c7a4 ``` Si el error se relaciona con un tipo de datos VARCHAR, la razón del error incluye un código de error y la secuencia hexadecimal UTF-8 no válida. En el siguiente ejemplo, se muestra la razón del error cuando COPY prueba cargar el carácter UTF-8 `a4` en un campo VARCHAR. ``` String contains invalid or unsupported UTF-8 codepoints. Bad UTF-8 hex sequence: a4 (error 3) ``` En la siguiente tabla, se presentan las descripciones y las soluciones a problemas sugeridas para los errores de carga VARCHAR. Si se produce uno de estos errores, reemplace el carácter por una secuencia de código UTF-8 válida o elimínelo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/multi-byte-character-load-errors.html) # Referencia de error de carga Si se producen errores mientras se cargan datos desde un archivo, ejecute una consulta en la tabla [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md) para identificar el error y determinar una explicación posible. La siguiente tabla presenta todos los códigos de error que podrían producirse durante cargas de datos: ## Códigos de error de carga [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/r_Load_Error_Reference.html) # Creación de una integración de eventos de S3 para copiar automáticamente archivos desde buckets de Amazon S3 **nota** La versión preliminar de la copia automática ha finalizado. Por consiguiente, los clústeres de la versión preliminar se eliminarán automáticamente 30 días después de que finalice el periodo de la versión preliminar. Si tiene pensado seguir utilizando la copia automática, le recomendamos que vuelva a crear sus trabajos de copia automática existentes en otro clúster de Amazon Redshift. No se admite la actualización de un clúster de la versión preliminar a la versión más reciente de Amazon Redshift. Puede utilizar un trabajo de copia automática para cargar datos en las tablas de Amazon Redshift desde archivos almacenados en Amazon S3. Amazon Redshift detecta cuándo se agregan nuevos archivos de Amazon S3 a la ruta especificada en el comando COPY. A continuación, se ejecuta automáticamente un comando COPY sin tener que crear una canalización de ingesta de datos externa. Amazon Redshift hace un seguimiento de los archivos que se han cargado. Amazon Redshift determina la cantidad de archivos agrupados en lotes por comando COPY. Puede ver los comandos COPY resultantes en las vistas del sistema. El primer paso para crear un COPY JOB automático es crear una integración de eventos de S3. Cuando aparece un archivo nuevo en el bucket de origen de Amazon S3, Amazon Redshift administra la carga de los archivos en la base de datos mediante el comando COPY. ## Requisitos previos para crear una integración de eventos de S3 Para configurar la integración de eventos de S3, confirme que se cumplen los siguientes requisitos previos. + El bucket de Amazon S3 debe tener una política de bucket que permita varios permisos de Amazon S3. Por ejemplo, la siguiente política de ejemplo da permisos al bucket de recursos `amzn-s3-demo-bucket` que está alojado en *us-east-1*. Tanto el bucket de Amazon S3 como la integración están en la misma Región de AWS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Auto-Copy-Policy-01", "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": [ "s3:GetBucketNotification", "s3:PutBucketNotification", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket:*", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:redshift:us-east-1:111122223333:integration:*" }, "StringEquals": { "aws:SourceAccount": "111122223333" } } } ] } ``` ------ + El clúster aprovisionado de Amazon Redshift de destino o el espacio de nombres de Redshift sin servidor deben tener permiso para el bucket. Confirme que un rol de IAM asociado a su clúster o espacio de nombres sin servidor tiene una política de IAM que concede los permisos adecuados. La política debe permitir tanto `s3:GetObject` para un recurso de bucket como `amzn-s3-demo-bucket` y `s3:ListBucket` para un recurso de bucket y su contenido como, por ejemplo, `amzn-s3-demo-bucket/*`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AutoCopyReadId", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } ] } ``` ------ Añada la política a un rol de IAM que tenga una relación de confianza para el rol de la siguiente manera. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Si el almacenamiento de datos de destino es un clúster aprovisionado, puede asociar un rol de IAM al clúster aprovisionado mediante la consola de Amazon Redshift en la pestaña **Permisos del clúster** de los detalles del clúster. Para obtener información sobre cómo asociar un rol al clúster aprovisionado, consulte [Asociación de roles de IAM a los clústeres](https://docs.aws.amazon.com/redshift/latest/mgmt/copy-unload-iam-role-associating-with-clusters.html) en la *Guía de administración de Amazon Redshift*. Si el almacenamiento de datos de destino es Redshift sin servidor, puede asociar un rol de IAM al espacio de nombres sin servidor mediante la consola de Redshift sin servidor en la pestaña **Seguridad y cifrado** de los detalles del espacio de nombres. Para obtener información sobre cómo asociar un rol al espacio de nombres sin servidor, consulte [Concesión de permisos a Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-security-other-services.html) en la *Guía de administración de Amazon Redshift*. + Su almacenamiento de datos de Amazon Redshift también debe tener una política de recursos que permita el bucket de Amazon S3. Si utiliza la consola de Amazon Redshift, al crear la integración de eventos de S3, Amazon Redshift ofrece la opción **Arréglalo por mí** para añadir esta política al almacenamiento de datos de Amazon Redshift. Para actualizar una política de recursos por su cuenta, puede usar el comando [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/redshift/put-resource-policy.html) de la AWS CLI. Por ejemplo, para asociar una política de recursos al clúster aprovisionado de Amazon Redshift para una integración de eventos de S3 con un bucket de Amazon S3, ejecute un comando de la AWS CLI similar al siguiente. En el siguiente ejemplo, se muestra una política para un espacio de nombres del clúster aprovisionado en la Región de AWS *us-east-1* para la cuenta de usuario *123456789012*. El bucket se denomina *amzn-s3-demo-bucket*. ``` aws redshift put-resource-policy \ --policy file://rs-rp.json \ --resource-arn "arn:aws:redshift: us-east-1:123456789012:namespace/cc4ffe56-ad2c-4fd1-a5a2-f29124a56433" ``` Donde `rs-rp.json` contiene: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": "redshift:AuthorizeInboundIntegration", "Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/myRedshiftRole" }, "Action": "redshift:CreateInboundIntegration", "Resource": "arn:aws:redshift:us-east-1:123456789012:namespace:cc4ffe56-ad2c-4fd1-a5a2-f29124a56433", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } } ] } ``` ------ Para asociar una política de recursos a su espacio de nombres de Redshift sin servidor para una integración de eventos de S3 con un bucket de Amazon S3, ejecute un comando de la AWS CLI similar al siguiente. En el siguiente ejemplo, se muestra una política para un espacio de nombres sin servidor en la Región de AWS *us-east-1* para la cuenta de usuario *123456789012*. El bucket se denomina *amzn-s3-demo-bucket*. ``` aws redshift put-resource-policy \ --policy file://rs-rp.json \ --resource-arn "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1" ``` Donde `rs-rp.json` contiene: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "redshift.amazonaws.com" }, "Action": "redshift:AuthorizeInboundIntegration", "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/myUser" }, "Action": "redshift:CreateInboundIntegration", "Resource": "arn:aws:redshift-serverless:us-east-1:123456789012:namespace/namespace-1", "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket", "aws:SourceAccount": 111122223333 } } } ] } ``` ------ ## Creación de una integración de eventos de S3 Para configurar su trabajo de copia, primero debe definir una integración de eventos de S3. ------ #### [ Amazon Redshift console ] **Creación de una integración de eventos de Amazon S3 en la consola de Amazon Redshift** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. En el panel de navegación izquierdo, elija **Integraciones de eventos de S3**. 1. Elija **Crear integración de eventos de Amazon S3** para abrir el asistente y crear una integración de eventos de S3 que se utilizará con la copia automática. Su bucket de Amazon S3 de origen y el almacenamiento de datos de Amazon Redshift de destino deben estar en la misma Región de AWS. Especifique la siguiente información al realizar los pasos para crear una integración: + **Nombre de la integración**: es un identificador único en todas las integraciones que son propiedad de su Cuenta de AWS en la Región de AWS actual. + **Descripción**: es un texto que describe la integración de eventos de Amazon S3 para consultarlo más adelante. + **Bucket de S3 de origen**: es el bucket de Amazon S3 en la Cuenta de AWS y la Región de AWS actuales, que es el origen de la ingesta de datos en Amazon Redshift. + **Almacenamiento de datos de Amazon Redshift**: es el clúster aprovisionado de Amazon Redshift de destino o el grupo de trabajo de Redshift sin servidor que recibe los datos de la integración. Si su Amazon Redshift objetivo está en la misma cuenta, podrá seleccionar el objetivo. Si el destino está en una cuenta diferente, especifique el **ARN del almacenamiento de datos de Amazon Redshift**. El destino debe tener una política de recursos con entidades principales y un origen de integración autorizados. Si no tiene las políticas de recursos correctas en el destino y su destino está en la misma cuenta, puede seleccionar la opción **Arréglalo por mí** para aplicar automáticamente las políticas de recursos durante el proceso de creación de la integración. Si su objetivo se encuentra en otra Cuenta de AWS diferente, debe aplicar la política de recursos en el almacén de Amazon Redshift de forma manual. 1. Introduzca hasta 50 **claves** de etiquetas y añada un **valor** opcional: para proporcionar metadatos adicionales sobre la integración. 1. Se muestra una página de revisión en la que puede seleccionar **Crear integración de eventos de S3**. ------ #### [ AWS CLI ] Para crear una integración de eventos de Amazon S3 mediante la AWS CLI, utilice el comando `create-integration` con las siguientes opciones: + `integration-name`: especifique un nombre para la integración. + `source-arn`: especifique el ARN del bucket de origen de Amazon S3. + `target-arn`: especifique el ARN del espacio de nombres del clúster aprovisionado de Amazon Redshift o del destino del grupo de trabajo de Redshift sin servidor. El siguiente ejemplo crea una integración proporcionando el nombre de la integración, el ARN de origen y el ARN de destino. La integración no está cifrada. ``` aws redshift create-integration \ --integration-name s3-integration \ --source-arn arn:aws:s3:us-east-1::s3-example-bucket \ --target-arn arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 { "IntegrationArn": "arn:aws:redshift:us-east-1:123456789012:integration:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "IntegrationName": "s3-integration", "SourceArn": "arn:aws:s3:::s3-example-bucket", "SourceType": "s3-event-notifications", "TargetArn": "arn:aws:redshift:us-east-1:123456789012:namespace:a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "Status": "creating", "Errors": [], "CreateTime": "2024-10-09T19:08:52.758000+00:00", "Tags": [] } ``` También puede utilizar los siguientes comandos de la AWS CLI para administrar la integración de eventos de S3. + `delete-integration`: especifique un ARN de integración para eliminar una integración de eventos de S3. + `modify-integration`: especifique un ARN de integración para cambiar el nombre o la descripción (o ambos) de una integración de eventos de S3. + `describe-integrations`: especifique un ARN de integración para ver las propiedades de una integración de eventos de S3. Consulte la [https://docs.aws.amazon.com/cli/latest/reference/redshift/](https://docs.aws.amazon.com/cli/latest/reference/redshift/) para obtener más información sobre estos comandos. ------ A continuación, Amazon Redshift crea una integración de eventos de S3 con el origen y el destino asociados, el estado y la información sobre el estado de un trabajo de copia automática asociado. Para ver la información sobre una integración de eventos de S3 en la consola de Amazon Redshift, seleccione **Integraciones de eventos de S3** y elija la integración para ver sus detalles. Hay diferentes integraciones: las que se crean **En mi cuenta** y las **De otras cuentas**. La lista **En mi cuenta** muestra las integraciones en las que el origen y el destino están en la misma cuenta. La lista **De otras cuentas** muestra las integraciones en las que el origen es propiedad de otra cuenta. Si elimina una integración de eventos de S3, el estado de COPY JOB correspondiente cambia de `1` (activo) a `0` (inactivo/pendiente). Sin embargo, el COPY JOB correspondiente no se elimina automáticamente. Si más adelante intenta crear un COPY JOB con el mismo nombre, puede que se produzca un conflicto. ## Creación y supervisión de un COPY JOB Una vez creada la integración, en la página **Detalles de la integración de eventos de S3** de la integración que ha creado, elija **Crear trabajo de copia automática** para ir al editor de consultas V2 de Amazon Redshift, donde puede crear el trabajo de copia automática para la integración. Amazon Redshift hace corresponder el bucket en la cláusula FROM de la instrucción COPY JOB CREATE con el bucket utilizado en la integración de eventos de S3. Para obtener más información acerca del editor de consultas V2 de Amazon Redshift, visite [Consulta de una base de datos mediante el editor de consultas V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2.html) en la *Guía de administración de Amazon Redshift*. Por ejemplo, ejecute el siguiente comando COPY en el editor de consultas V2 para crear un COPY JOB automático que haga corresponder el bucket de Amazon S3 `s3://amzn-s3-demo-bucket/staging-folder` con una integración de eventos de Amazon S3. ``` COPY public.target_table FROM 's3://amzn-s3-demo-bucket/staging-folder' IAM_ROLE 'arn:aws:iam::123456789012:role/MyLoadRoleName' JOB CREATE my_copy_job_name AUTO ON; ``` El comando COPY JOB se define una vez. Los mismos parámetros se utilizan para ejecuciones futuras. Para definir y administrar un COPY JOB, debe tener permiso para hacerlo. Para obtener información sobre cómo conceder y revocar el permiso para un COPY JOB, consulte [GRANT](r_GRANT.md) y [REVOKE](r_REVOKE.md). Para obtener información sobre cómo conceder y revocar permisos con ámbito para un COPY JOB, consulte [Concesión de permisos acotados](r_GRANT.md#grant-scoped-syntax) y [Revocación de los permisos acotados](r_REVOKE.md#revoke-scoped-permissions). Las operaciones de carga se administran utilizando opciones para trabajos CREATE, LIST, SHOW, DROP, ALTER y RUN. Para obtener más información, consulte [COPY JOB](r_COPY-JOB.md). Puede consultar las vistas del sistema para ver el estado y el progreso de COPY JOB. Las vistas se proporcionan de la siguiente manera: + [SYS\$1COPY\$1JOB](SYS_COPY_JOB.md): contiene una fila para cada COPY JOB definido actualmente. + [SYS\$1COPY\$1JOB\$1DETAIL](SYS_COPY_JOB_DETAIL.md): contiene detalles sobre archivos pendientes, con errores e ingeridos para cada COPY JOB. + [SYS\$1COPY\$1JOB\$1INFO](SYS_COPY_JOB_INFO.md): contiene los mensajes registrados acerca de un COPY JOB. + [SYS\$1LOAD\$1HISTORY](SYS_LOAD_HISTORY.md): contiene detalles de los comandos COPY. + [SYS\$1LOAD\$1ERROR\$1DETAIL](SYS_LOAD_ERROR_DETAIL.md): contiene detalles de los errores del comando COPY. + [SVV\$1COPY\$1JOB\$1INTEGRATIONS](SVV_COPY_JOB_INTEGRATIONS.md): contiene detalles de las integraciones de eventos de S3. + [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md): contiene errores de los comandos COPY. + [STL\$1LOAD\$1COMMITS](r_STL_LOAD_COMMITS.md): contiene información que se utiliza para solucionar problemas de carga de datos del comando COPY. Para obtener información acerca de la solución de errores de la integración de eventos de S3, consulte [Solución de los errores de la integración de eventos de S3 y COPY JOB](s3-integration-troubleshooting.md). Para obtener la lista de archivos que carga un COPY JOB, ejecute el siguiente SQL, pero primero reemplace **: ``` SELECT job_id, job_name, data_source, copy_query, filename, status, curtime FROM sys_copy_job copyjob JOIN stl_load_commits loadcommit ON copyjob.job_id = loadcommit.copy_job_id WHERE job_id = ; ``` ## Consideraciones a la hora de crear la integración de eventos de S3 para la copia automática Tenga en cuenta lo siguiente cuando utilice la copia automática. + Puede crear un máximo de 200 COPY JOBS para cada clúster o grupo de trabajo de una Cuenta de AWS. + Puede crear un máximo de 50 integraciones de eventos de S3 para cada destino de Amazon Redshift. + No puede crear una integración de eventos de S3 con un bucket de Amazon S3 de origen que tenga un punto (.) en su nombre. + Solo puede crear una integración de eventos de S3 entre origen y destino iguales. Es decir, solo puede haber una integración de eventos de S3 entre un bucket de Amazon S3 y un almacenamiento de datos de Amazon Redshift a la vez. + No puede tener ninguna notificación de evento existente para el tipo de evento `S3_OBJECT_CREATED` que se define en el bucket de S3 de Amazon de origen. No obstante, una vez creada la integración de un evento de S3, puede actualizar la notificación de eventos del bucket de S3 de Amazon con un prefijo/sufijo de ámbito más restringido. De esta manera, también puede configurar `S3_OBJECT_CREATED` para otro prefijo/sufijo a otros destinos y evitar un conflicto con la integración de eventos de S3. Si experimenta problemas con la copia automática y esta no funciona como esperaba, prepare el registro de AWS CloudTrail de la acción `s3:PutBucketNotificationConfiguration` en el bucket de S3 para el periodo de tiempo en cuestión cuando se ponga en contacto con AWS Support. ## Regiones admitidas Estas son las regiones disponibles para la copia automática. | Región | Copia automática | | --- | --- | | África (Ciudad del Cabo) | Disponible | | Asia-Pacífico (Hong Kong) | Disponible | | Asia-Pacífico (Taipéi) | Disponible | | Asia-Pacífico (Tokio) | Disponible | | Asia-Pacífico (Seúl) | Disponible | | Asia-Pacífico (Osaka) | Disponible | | Asia-Pacífico (Mumbai) | Disponible | | Asia-Pacífico (Hyderabad) | Disponible | | Asia-Pacífico (Singapur) | Disponible | | Asia-Pacífico (Sídney) | Disponible | | Asia-Pacífico (Yakarta) | Disponible | | Asia-Pacífico (Melbourne) | Disponible | | Asia-Pacífico (Malasia) | Disponible | | Asia-Pacífico (Nueva Zelanda) | No disponible | | Asia-Pacífico (Tailandia) | Disponible | | Canadá (centro) | Disponible | | Oeste de Canadá (Calgary) | Disponible | | China (Pekín) | Disponible | | China (Ningxia) | Disponible | | Europa (Fráncfort) | Disponible | | Europa (Zúrich) | Disponible | | Europa (Estocolmo) | Disponible | | Europa (Milán) | Disponible | | Europa (España) | Disponible | | Europa (Irlanda) | Disponible | | Europa (Londres) | Disponible | | Europa (París) | Disponible | | Israel (Tel Aviv) | Disponible | | Medio Oriente (EAU) | Disponible | | Medio Oriente (Baréin) | Disponible | | México (centro) | Disponible | | América del Sur (São Paulo) | Disponible | | Este de EE. UU. (Norte de Virginia) | Disponible | | Este de EE. UU. (Ohio) | Disponible | | Oeste de EE. UU. (Norte de California) | Disponible | | Oeste de EE. UU. (Oregón) | Disponible | | AWS GovCloud (Este de EE. UU.) | Disponible | | AWS GovCloud (Oeste de EE. UU.) | Disponible | # Carga de tablas con comandos DML Amazon Redshift es compatible con comandos estándar de lenguaje de manipulación de datos (DML) (INSERT, UPDATE y DELETE) que puede usar para modificar las filas de las tablas. También puede utilizar el comando TRUNCATE para realizar eliminaciones masivas rápidas. **nota** Le recomendamos usar el comando [COPY](r_COPY.md) para cargar grandes cantidades de datos. El uso de instrucciones INSERT individuales para completar una tabla podría ser prohibitivamente lento. O bien, si los datos ya existen en otras tablas de la base de datos de Amazon Redshift, puede utilizar INSERT INTO… SELECT FROM o CREATE TABLE AS para mejorar el rendimiento. Para obtener información, consulte [INSERT](r_INSERT_30.md) o [CREATE TABLE AS](r_CREATE_TABLE_AS.md). Si inserta, actualiza o elimina una cantidad significativa de filas en una tabla, en relación con la cantidad de filas antes de los cambios, ejecute los comandos ANALYZE y VACUUM en la tabla cuando termine. Si cierta cantidad de cambios pequeños se acumulan en su aplicación con el paso del tiempo, puede que le convenga programar los comandos ANALYZE y VACUUM para que se ejecuten a intervalos regulares. Para obtener más información, consulte [Análisis de tablas](t_Analyzing_tables.md) y [Limpieza de tablas](t_Reclaiming_storage_space202.md). **Topics** + [Actualización e inserción de datos nuevos](t_updating-inserting-using-staging-tables-.md) # Actualización e inserción de datos nuevos Puede agregar eficazmente nuevos datos a una tabla existente mediante el comando MERGE. Realice una operación de fusión mediante la creación de una tabla provisional y, a continuación, utilice uno de los métodos descritos en esta sección para actualizar la tabla de destino a partir de la tabla provisional. Para obtener más información sobre el comando MERGE, consulte [MERGE](r_MERGE.md). En los [Ejemplos de fusión](merge-examples.md) se usa un conjunto de datos de muestra para Amazon Redshift, denominado conjunto de datos TICKIT. Como requisito previo, puede configurar las tablas y los datos de TICKIT según las instrucciones disponibles en [Introducción a tareas comunes de bases de datos](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Encontrará información más detallada sobre el conjunto de datos de muestra en [Base de datos de muestra](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). ## Método de fusión 1: Reemplazar filas existentes Si sobrescribe todas las columnas de la tabla de destino, el método más rápido para realizar una combinación es sustituir las filas existentes. Esto escanea la tabla de destino solo una vez, mediante una combinación interna para eliminar las filas que se actualizarán. Una vez eliminadas las filas, se reemplazan por filas nuevas mediante una operación de inserción única desde la tabla provisional. Aplique este método si se satisfacen todas las siguientes condiciones: + La tabla destino y la provisional tienen las mismas columnas. + Desea reemplazar todos los datos de las columnas de la tabla destino por los de las columnas de la tabla provisional. + Usará todas las filas de la tabla provisional en la fusión. Si alguno de estos criterios no se aplica, utilice el Método de fusión 2: especificación de una lista de columnas sin utilizar MERGE, descrito en la siguiente sección. Si no usará todas las filas de la tabla provisional, filtre las instrucciones DELETE e INSERT al usar una cláusula WHERE para excluir las filas que no cambiarán. No obstante, si la mayoría de las filas de la tabla provisional no participarán en la fusión, recomendamos ejecutar los comandos UPDATE e INSERT en distintos pasos, según se describe posteriormente en esta sección. ## Método de fusión 2: especificación de una lista de columnas sin utilizar MERGE Aplique este método para actualizar columnas específicas de la tabla destino, en lugar de sobrescribir filas enteras. Este método tarda más que el anterior porque requiere un paso de actualización adicional y no utiliza el comando MERGE. Aplique este método si se satisface alguna de las siguientes condiciones: + No todas las columnas de la tabla destino se actualizarán. + La mayoría de las filas de la tabla provisional no se usarán en las actualizaciones. **Topics** + [Método de fusión 1: Reemplazar filas existentes](#merge-method-replace-existing-rows) + [Método de fusión 2: especificación de una lista de columnas sin utilizar MERGE](#merge-method-specify-column-list) + [Creación de una tabla provisional temporal](merge-create-staging-table.md) + [Realización de una operación de fusión al reemplazar filas existentes](merge-replacing-existing-rows.md) + [Realización de una operación de fusión al especificar una lista de columnas sin usar el comando MERGE](merge-specify-a-column-list.md) + [Ejemplos de fusión](merge-examples.md) # Creación de una tabla provisional temporal La *tabla provisional* es una tabla temporal que tiene todos los datos que se usarán para hacer los cambios en la *tabla de destino*, incluidas las actualizaciones e inserciones. Una operación de fusión requiere una combinación entre la tabla provisional y la tabla destino. Para colocar las filas de combinación, establezca la clave de distribución de la tabla provisional en la misma columna que la clave de distribución de la tabla destino. Por ejemplo, si la tabla destino usa una columna de clave externa como su clave de distribución, use la misma columna para la clave de distribución de la tabla provisional. Si crea la tabla provisional mediante una instrucción [CREATE TABLE LIKE](r_CREATE_TABLE_NEW.md#create-table-like), la tabla provisional heredará la clave de distribución de la tabla principal. Si usa una instrucción CREATE TABLE AS, la tabla nueva no hereda la clave de distribución. Para obtener más información, consulte [Distribución de datos para la optimización de consultas](t_Distributing_data.md) Si la clave de distribución no es igual a la clave primaria y si no se actualiza como parte de la operación de fusión, agregue un predicado de combinación redundante en las columnas de la clave de distribución para permitir una combinación colocada. Por ejemplo: ``` where target.primarykey = stage.primarykey and target.distkey = stage.distkey ``` Para corroborar que la consulta usará una combinación colocada, ejecute la consulta con [EXPLAIN](r_EXPLAIN.md) y, luego, controle la presencia de DS\$1DIST\$1NONE en todas las combinaciones. Para obtener más información, consulte [Evaluación del plan de consulta](c_data_redistribution.md) # Realización de una operación de fusión al reemplazar filas existentes Cuando ejecute la operación de fusión detallada en el procedimiento, ponga todos los pasos, excepto la creación y eliminación de la tabla provisional, en una transacción única. La transacción se anula si se produce un error en algún paso. El uso de una transacción única también reduce la cantidad de confirmaciones, lo cual ahorra tiempo y recursos. **Pasos para realizar una operación de fusión al reemplazar filas existentes** 1. Cree una tabla provisional y, luego, complétela con los datos que se fusionarán, como se muestra en el siguiente pseudocódigo. ``` CREATE temp table stage (like target); INSERT INTO stage SELECT * FROM source WHERE source.filter = 'filter_expression'; ``` 1. Utilice MERGE para realizar una unión interna con la tabla provisional para actualizar las filas de la tabla de destino que coincidan con la tabla provisional y, a continuación, inserte en la tabla de destino todas las filas restantes que no coincidan con la tabla provisional. Le recomendamos que ejecute las operaciones de actualización e inserción en un único comando MERGE. ``` MERGE INTO target USING stage [optional alias] on (target.primary_key = stage.primary_key) WHEN MATCHED THEN UPDATE SET col_name1 = stage.col_name1 , col_name2= stage.col_name2, col_name3 = {expr} WHEN NOT MATCHED THEN INSERT (col_name1 , col_name2, col_name3) VALUES (stage.col_name1, stage.col_name2, {expr}); ``` 1. Elimine la tabla provisional. ``` DROP TABLE stage; ``` # Realización de una operación de fusión al especificar una lista de columnas sin usar el comando MERGE Cuando ejecute la operación de fusión detallada en el procedimiento, ponga todos los pasos en una transacción única. La transacción se anula si se produce un error en algún paso. El uso de una transacción única también reduce la cantidad de confirmaciones, lo cual ahorra tiempo y recursos. **Pasos para realizar una operación de fusión al especificar una lista de columnas** 1. Coloque toda la operación en un único bloque de transacción. ``` BEGIN transaction; … END transaction; ``` 1. Cree una tabla provisional y, luego, complétela con los datos que se fusionarán, como se muestra en el siguiente pseudocódigo. ``` create temp table stage (like target); insert into stage select * from source where source.filter = 'filter_expression'; ``` 1. Actualice la tabla destino mediante el uso de una combinación interna con la tabla provisional. + En la cláusula UPDATE, especifique de manera explícita las columnas que se actualizarán. + Realice una combinación interna con la tabla provisional. + Si la clave de distribución es diferente a la clave primaria y si no se actualiza, agregue un predicado de combinación redundante en las columnas de la clave de distribución. Para corroborar que la consulta usará una combinación colocada, ejecute la consulta con [EXPLAIN](r_EXPLAIN.md) y, luego, controle la presencia de DS\$1DIST\$1NONE en todas las combinaciones. Para obtener más información, consulte [Evaluación del plan de consulta](c_data_redistribution.md) + Si la tabla de destino se ordena según la marca temporal, agregue un predicado para aprovechar los análisis de rango restringido en la tabla de destino. Para obtener más información, consulte [Prácticas recomendadas de Amazon Redshift para el diseño de consultas](c_designing-queries-best-practices.md). + Si no usará todas las filas en la fusión, agregue una cláusula para filtrar las filas que desea cambiar. Por ejemplo, agregue un filtro de desigualdad a una o más columnas para excluir las filas que no han cambiado. + Ponga las operaciones de actualización, eliminación e inserción en un bloque de transacción único de manera que, si se produce un problema, todo se revierta. Por ejemplo: ``` begin transaction; update target set col1 = stage.col1, col2 = stage.col2, col3 = 'expression' from stage where target.primarykey = stage.primarykey and target.distkey = stage.distkey and target.col3 > 'last_update_time' and (target.col1 != stage.col1 or target.col2 != stage.col2 or target.col3 = 'filter_expression'); ``` 1. Elimine las filas innecesarias de la tabla provisional mediante el uso de una combinación interna con la tabla destino. Algunas de las filas de la tabla destino ya coinciden con las filas correspondientes en la tabla provisional y otras se actualizaron en el paso anterior. En cualquiera de los casos, no se necesitan para la inserción. ``` delete from stage using target where stage.primarykey = target.primarykey; ``` 1. Inserte las filas restantes desde la tabla provisional. Use la misma lista de columnas de la cláusula VALUES que usó en la instrucción UPDATE del paso dos. ``` insert into target (select col1, col2, 'expression' from stage); end transaction; ``` 1. Elimine la tabla provisional. ``` drop table stage; ``` # Ejemplos de fusión En los siguientes ejemplos, se realiza una fusión para actualizar la tabla SALES. En el primer ejemplo, se usa el método más simple de eliminar desde la tabla destino y, luego, se insertan todas las filas desde la tabla provisional. En el segundo ejemplo, se requiere la actualización de columnas seleccionadas de la tabla destino, por lo que se incluye un paso de actualización adicional. En los [Ejemplos de fusión](#merge-examples) se usa un conjunto de datos de muestra para Amazon Redshift, denominado conjunto de datos TICKIT. Como requisito previo, puede configurar las tablas y los datos de TICKIT siguiendo las instrucciones disponibles en [Introducción a las tareas comunes de bases de datos](https://docs.aws.amazon.com/redshift/latest/gsg/database-tasks.html). Encontrará información más detallada sobre el conjunto de datos de muestra en [Base de datos de muestra](https://docs.aws.amazon.com/redshift/latest/dg/c_sampledb.html). **Origen de datos de la fusión de muestra** Los ejemplos de esta sección requieren de un origen de datos de muestra que incluye tanto actualizaciones como inserciones. Para los ejemplos, crearemos una tabla de muestra denominada SALES\$1UPDATE que usa datos de la tabla SALES. Llenaremos la tabla nueva con datos aleatorios que representan la actividad de ventas nueva para diciembre. Usaremos la tabla de muestra SALES\$1UPDATE para crear la tabla provisional de los ejemplos a continuación. ``` -- Create a sample table as a copy of the SALES table. create table tickit.sales_update as select * from tickit.sales; -- Change every fifth row to have updates. update tickit.sales_update set qtysold = qtysold*2, pricepaid = pricepaid*0.8, commission = commission*1.1 where saletime > '2008-11-30' and mod(sellerid, 5) = 0; -- Add some new rows to have inserts. -- This example creates a duplicate of every fourth row. insert into tickit.sales_update select (salesid + 172456) as salesid, listid, sellerid, buyerid, eventid, dateid, qtysold, pricepaid, commission, getdate() as saletime from tickit.sales_update where saletime > '2008-11-30' and mod(sellerid, 4) = 0; ``` **Ejemplo de una fusión que reemplaza filas existentes en las claves coincidentes** El siguiente script usa la tabla SALES\$1UPDATE para realizar una operación de fusión en la tabla SALES con datos nuevos para la actividad de ventas de diciembre. En este ejemplo se reemplazan las filas de la tabla SALES que tienen actualizaciones. Para este ejemplo, actualizaremos las columnas qtysold y pricepaid, pero dejaremos sin cambios commission y saletime. ``` MERGE into tickit.sales USING tickit.sales_update sales_update on ( sales.salesid = sales_update.salesid and sales.listid = sales_update.listid and sales_update.saletime > '2008-11-30' and (sales.qtysold != sales_update.qtysold or sales.pricepaid != sales_update.pricepaid)) WHEN MATCHED THEN update SET qtysold = sales_update.qtysold, pricepaid = sales_update.pricepaid WHEN NOT MATCHED THEN INSERT (salesid, listid, sellerid, buyerid, eventid, dateid, qtysold , pricepaid, commission, saletime) values (sales_update.salesid, sales_update.listid, sales_update.sellerid, sales_update.buyerid, sales_update.eventid, sales_update.dateid, sales_update.qtysold , sales_update.pricepaid, sales_update.commission, sales_update.saletime); -- Drop the staging table. drop table tickit.sales_update; -- Test to see that commission and salestime were not impacted. SELECT sales.salesid, sales.commission, sales.salestime, sales_update.commission, sales_update.salestime FROM tickit.sales INNER JOIN tickit.sales_update sales_update ON sales.salesid = sales_update.salesid AND sales.listid = sales_update.listid AND sales_update.saletime > '2008-11-30' AND (sales.commission != sales_update.commission OR sales.salestime != sales_update.salestime); ``` **Ejemplo de fusión que especifica una lista de columnas sin utilizar MERGE** En el siguiente ejemplo, se realiza una operación de fusión para actualizar la tabla SALES con datos nuevos para la actividad de ventas de diciembre. Necesitamos datos de muestra que incluyan tanto actualizaciones como inserciones, junto con filas que no hayan cambiado. Para este ejemplo, deseamos actualizar las columnas QTYSOLD y PRICEPAID, y dejar COMMISSION y SALETIME sin cambios. El siguiente script usa la tabla SALES\$1UPDATE para realizar una operación de fusión en la tabla SALES. ``` -- Create a staging table and populate it with rows from SALES_UPDATE for Dec create temp table stagesales as select * from sales_update where saletime > '2008-11-30'; -- Start a new transaction begin transaction; -- Update the target table using an inner join with the staging table -- The join includes a redundant predicate to collocate on the distribution key –- A filter on saletime enables a range-restricted scan on SALES update sales set qtysold = stagesales.qtysold, pricepaid = stagesales.pricepaid from stagesales where sales.salesid = stagesales.salesid and sales.listid = stagesales.listid and stagesales.saletime > '2008-11-30' and (sales.qtysold != stagesales.qtysold or sales.pricepaid != stagesales.pricepaid); -- Delete matching rows from the staging table -- using an inner join with the target table delete from stagesales using sales where sales.salesid = stagesales.salesid and sales.listid = stagesales.listid; -- Insert the remaining rows from the staging table into the target table insert into sales select * from stagesales; -- End transaction and commit end transaction; -- Drop the staging table drop table stagesales; ``` # Realización de una copia profunda Una copia profunda recrea y vuelve a completar una tabla mediante una operación de inserción masiva, que ordena la tabla de manera automática. Si una tabla tiene una gran región no ordenada, una copia profunda es mucho más rápida que una limpieza. Le recomendamos que solo realice actualizaciones simultáneas durante una operación de copia profunda si puede realizar un seguimiento de ellas. Una vez finalizado el proceso, mueva las actualizaciones delta a la nueva tabla. La operación VACUUM admite de forma automática las actualizaciones simultáneas. Para crear una copia de una tabla original, puede elegir uno de los siguientes métodos: + Usar el DDL de la tabla original. Si el CREATE TABLE DDL se encuentra disponible, este es el método más rápido y preferido. Si crea una tabla nueva, puede especificar todos los atributos de tabla y columna, entre ellos la clave principal y las claves externas. Para buscar el DDL original, use la función SHOW TABLE. + Use CREATE TABLE LIKE. Si el DDL original no se encuentra disponible, puede usar CREATE TABLE LIKE para recrear la tabla original. La tabla nueva hereda los atributos ENCODING, DISTKEY, SORTKEY y NOT NULL de la tabla principal. La tabla nueva no hereda los atributos de clave principal y clave externa de la tabla principal, pero puede agregarlos con [ALTER TABLE](r_ALTER_TABLE.md). + Crear una tabla temporal y truncar la tabla original. Si debe retener los atributos de clave principal y clave externa de la tabla principal. Si la tabla principal tiene dependencias, puede usar CREATE TABLE... AS (CTAS) para crear una tabla temporal. A continuación, trunque la tabla original y rellénela desde la tabla temporal. El uso de una tabla temporal mejora el rendimiento significativamente en comparación con el uso de una tabla permanente, pero existe el riesgo de perder datos. Una tabla temporal se elimina automáticamente al final de la sesión en la que se crea. TRUNCATE se confirma inmediatamente, incluso si se encuentra dentro de un bloque de transacciones. Si TRUNCATE tiene éxito pero la sesión se cierra antes de que se complete la acción INSERT siguiente, los datos se pierden. Si la pérdida de los datos es inaceptable, use una tabla permanente. Después de crear una copia de una tabla, es posible que deba conceder acceso a la nueva tabla. Puede usar [GRANT](r_GRANT.md) para definir privilegios de acceso. Para ver y adjudicar todos los privilegios de acceso de una tabla, debe ser uno de los siguientes: + Un superusuario. + El propietario de la tabla que desea copiar. + Un usuario con el privilegio ACCESS SYSTEM TABLE para ver los privilegios de la tabla y con el privilegio de conceder todos los permisos pertinentes. Además, es posible que tenga que conceder permisos de uso para el esquema en el que se encuentra la copia profunda. Es necesario conceder el permiso de uso si el esquema de la copia profunda es diferente del esquema de la tabla original y también lo es del esquema `public`. Para ver y adjudicar privilegios de uso, debe ser uno de los siguientes: + Un superusuario. + Un usuario que puede adjudicar el permiso USAGE para el esquema de la copia profunda. **Pasos para realizar una copia profunda al usar el DDL de la tabla original** 1. (Opcional) Recree el DDL de la tabla al ejecutar un script denominado `v_generate_tbl_ddl`. 1. Cree una copia de la tabla al usar el CREATE TABLE DDL original. 1. Use una instrucción INSERT INTO … SELECT para completar la copia con datos desde la tabla original. 1. Compruebe los permisos adjudicados en la tabla anterior. Puede ver estos permisos en la vista de sistema SVV\$1RELATION\$1PRIVILEGES. 1. Si es necesario, adjudique los permisos de la tabla antigua a la nueva. 1. Adjudique permisos de uso a todos los grupos y usuarios que tengan privilegios en la tabla original. Este paso no es necesario si la tabla de copia profunda está en el esquema `public` o está en el mismo esquema que la tabla original. 1. Elimine la tabla original. 1. Use una instrucción ALTER TABLE para renombrar la copia con el nombre de la tabla original. El ejemplo siguiente realiza una copia profunda en la tabla SAMPLE con un duplicado de SAMPLE denominado sample\$1copy. ``` --Create a copy of the original table in the sample_namespace namespace using the original CREATE TABLE DDL. create table sample_namespace.sample_copy ( … ); --Populate the copy with data from the original table in the public namespace. insert into sample_namespace.sample_copy (select * from public.sample); --Check SVV_RELATION_PRIVILEGES for the original table's privileges. select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type; --Grant the original table's privileges to the copy table. grant DELETE on table sample_namespace.sample_copy to group group1; grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2; grant SELECT on table sample_namespace.sample_copy to user1; grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2; --Grant usage permission to every group and user that has privileges in the original table. grant USAGE on schema sample_namespace to group group1, group group2, user1, user2; --Drop the original table. drop table public.sample; --Rename the copy table to match the original table's name. alter table sample_namespace.sample_copy rename to sample; ``` **Pasos para realizar una copia profunda al usar CREATE TABLE LIKE** 1. Cree una tabla nueva al usar CREATE TABLE LIKE. 1. Use una instrucción INSERT INTO … SELECT para copiar las filas de la tabla actual a la tabla nueva. 1. Compruebe los permisos adjudicados en la tabla anterior. Puede ver estos permisos en la vista de sistema SVV\$1RELATION\$1PRIVILEGES. 1. Si es necesario, adjudique los permisos de la tabla antigua a la nueva. 1. Adjudique permisos de uso a todos los grupos y usuarios que tengan privilegios en la tabla original. Este paso no es necesario si la tabla de copia profunda está en el esquema `public` o está en el mismo esquema que la tabla original. 1. Elimine la tabla actual. 1. Use una instrucción ALTER TABLE para renombrar la tabla nueva con el nombre de la tabla original. En el siguiente ejemplo, se usa CREATE TABLE LIKE para realizar una copia profunda de la tabla SAMPLE. ``` --Create a copy of the original table in the sample_namespace namespace using CREATE TABLE LIKE. create table sameple_namespace.sample_copy (like public.sample); --Populate the copy with data from the original table. insert into sample_namespace.sample_copy (select * from public.sample); --Check SVV_RELATION_PRIVILEGES for the original table's privileges. select * from svv_relation_privileges where namespace_name = 'public' and relation_name = 'sample' order by identity_type, identity_id, privilege_type; --Grant the original table's privileges to the copy table. grant DELETE on table sample_namespace.sample_copy to group group1; grant INSERT, UPDATE on table sample_namespace.sample_copy to group group2; grant SELECT on table sample_namespace.sample_copy to user1; grant INSERT, SELECT, UPDATE on table sample_namespace.sample_copy to user2; --Grant usage permission to every group and user that has privileges in the original table. grant USAGE on schema sample_namespace to group group1, group group2, user1, user2; --Drop the original table. drop table public.sample; --Rename the copy table to match the original table's name. alter table sample_namespace.sample_copy rename to sample; ``` **Pasos para realizar una copia profunda al crear una tabla temporal y truncar la tabla original** 1. Use CREATE TABLE AS para crear una tabla temporal con las filas de la tabla original. 1. Trunque la tabla actual. 1. Use una instrucción INSERT INTO … SELECT para copiar las filas de la tabla temporal a la tabla original. 1. Elimine la tabla temporal. En el siguiente ejemplo, se realiza una copia profunda de la tabla SALES al crear una tabla temporal y truncar la tabla original. Como la tabla original permanece, no es necesario adjudicar permisos a la tabla de copia. ``` --Create a temp table copy using CREATE TABLE AS. create temp table salestemp as select * from sales; --Truncate the original table. truncate sales; --Copy the rows from the temporary table to the original table. insert into sales (select * from salestemp); --Drop the temporary table. drop table salestemp; ``` # Análisis de tablas La operación ANALYZE actualiza los metadatos estadísticos que el planificador de consultas usa para seleccionar planes óptimos. En la mayoría de los casos, no necesita ejecutar de forma explícita el comando ANALYZE. Amazon Redshift monitorea los cambios realizados en la carga de trabajo y, de forma automática, actualiza las estadísticas en segundo plano. Además, el comando COPY realiza un análisis automáticamente cuando carga datos en una tabla vacía. Para analizar una tabla o toda la base de datos de manera explícita, ejecute el comando [ANALYZE](r_ANALYZE.md). ## Análisis automático Amazon Redshift monitorea constantemente la base de datos y, de forma automática, realiza operaciones de análisis en segundo plano. Para minimizar el impacto en el rendimiento del sistema, el análisis automático se ejecuta durante periodos en los que hay poca carga de trabajo. El análisis automático está habilitado de forma predeterminada. Para desactivar el análisis automático, establezca el parámetro `auto_analyze` en **false** modificando el grupo de parámetros del clúster. Para reducir el tiempo de procesamiento y mejorar el rendimiento general del sistema, Amazon Redshift omite el análisis automático de cualquier tabla con pocas modificaciones. Una operación de análisis omite las tablas que tienen estadísticas actualizadas. Si ejecuta ANALYZE como parte del flujo de trabajo de extracción, transformación y carga (ETL), el análisis automático omite las tablas con estadísticas actuales. De forma similar, un comando ANALYZE explícito omite tablas cuando el análisis automático ha actualizado las estadísticas de la tabla. ## Análisis de los datos nuevos de las tablas De manera predeterminada, el comando COPY realiza una operación ANALYZE una vez que carga datos en una tabla vacía. Puede forzar una operación ANALYZE sin importar si una tabla se encuentra vacía estableciendo STATUPDATE en ON. Si especifica STATUPDATE en OFF, no se realiza la operación ANALYZE. Solo el propietario de la tabla o un super usuario pueden ejecutar el comando ANALYZE o el comando COPY con STATUPDATE establecido en ON. Amazon Redshift también analiza las tablas nuevas que se crean con los siguientes comandos: + CREATE TABLE AS (CTAS) + CREATE TEMP TABLE AS + SELECT INTO Amazon Redshift devuelve un mensaje de advertencia si ejecuta una consulta en una tabla nueva que no se analizó después de la carga de datos inicial. No se producen avisos al ejecutar una consulta en una tabla tras una carga o actualización posterior. El mismo mensaje de aviso se devuelve al ejecutar el comando EXPLAIN en una consulta que hace referencia a tablas que no se han analizado. Si al agregar datos a una tabla que no está vacía cambia significativamente el tamaño de la tabla, puede actualizar de forma explícita las estadísticas. Para ello, debe ejecutar un comando ANALYZE o usar la opción STATUPDATE ON con el comando COPY. Para ver los detalles de la cantidad de filas que se han insertado o eliminado desde la última vez que se ejecutó ANALYZE, ejecute una consulta en la tabla de catálogo del sistema [PG\$1STATISTIC\$1INDICATOR](r_PG_STATISTIC_INDICATOR.md). Puede especificar el ámbito del comando [ANALYZE](r_ANALYZE.md) en uno de los siguientes lugares: + la base de datos actual completa; + una sola tabla; + una o más columnas específicas en una tabla única; + las columnas que, probablemente, se usen como predicados en consultas. El comando ANALYZE obtiene una muestra de filas desde la tabla, realiza cálculos y guarda las estadísticas de columna resultantes. De manera predeterminada, Amazon Redshift ejecuta un pase de muestra en la columna DISTKEY y otro pase de muestra en todas las demás columnas de la tabla. Si desea generar estadísticas para un subconjunto de columnas, puede especificar una lista de nombres de columnas separada por comas. Puede ejecutar ANALYZE con la cláusula PREDICATE COLUMNS para omitir las columnas que no se usan como predicados. Las operaciones ANALYZE consumen muchos recursos, por lo que debe ejecutarlas solamente en tablas y columnas que realmente requieran actualizaciones de las estadísticas. No es necesario que analice todas las columnas de las tablas de manera regular ni en el mismo programa. Si los datos cambian considerablemente, analice las columnas que se usan con frecuencia en los siguientes: + operaciones de agrupamiento y ordenación; + Uniones + predicados de consultas. Para reducir el tiempo de procesamiento y mejorar el rendimiento general del sistema, Amazon Redshift omite ANALYZE en cualquier tabla que tenga un porcentaje bajo de filas modificadas, en función de lo que determine el parámetro [analyze\$1threshold\$1percent](r_analyze_threshold_percent.md). De manera predeterminada, el umbral de análisis está establecido en 10 por ciento. Puede cambiar el umbral de análisis para la sesión actual al ejecutar un comando [SET](r_SET.md). Es menos probable que las columnas que representan hechos, medidas y cualquier atributo relacionado que en realidad nunca se consulta, como las columnas VARCHAR grandes, requieran análisis frecuentes. Por ejemplo, veamos el caso de la tabla LISTING en la base de datos TICKIT. ``` select "column", type, encoding, distkey, sortkey from pg_table_def where tablename = 'listing'; column | type | encoding | distkey | sortkey ---------------+--------------------+----------+---------+--------- listid | integer | none | t | 1 sellerid | integer | none | f | 0 eventid | integer | mostly16 | f | 0 dateid | smallint | none | f | 0 numtickets | smallint | mostly8 | f | 0 priceperticket | numeric(8,2) | bytedict | f | 0 totalprice | numeric(8,2) | mostly32 | f | 0 listtime | timestamp with... | none | f | 0 ``` Si esta tabla se carga diariamente con una gran cantidad de registros nuevos, la columna LISTID, que frecuentemente se usa en consultas como una clave de combinación, se debe analizar con regularidad. Si TOTALPRICE y LISTTIME se usan con frecuencia como restricciones en consultas, puede analizar esas columnas y la clave de distribución todos los días de la semana. ``` analyze listing(listid, totalprice, listtime); ``` Supongamos que los vendedores y los eventos en la aplicación son mucho más estáticos y los ID de fecha se refieren a un conjunto de días fijo que cubre solo dos o tres años. En este caso, los valores únicos de estas columnas no cambian de manera significativa. No obstante, la cantidad de instancias de cada valor único aumentará de manera constante. Además, veamos el caso en que se ejecutan consultas sobre las medidas NUMTICKETS y PRICEPERTICKET de manera poco frecuente, en comparación con la columna TOTALPRICE. En este caso, puede ejecutar el comando ANALYZE sobre la tabla completa una vez por fin de semana para actualizar las estadísticas correspondientes a las cinco columnas que no se analizan a diario: **Columnas de predicados** Como alternativa conveniente a especificar una lista de columnas, puede optar por analizar solo las columnas que probablemente utilice como predicados. Al ejecutar una consulta, cualquier columna usada en una combinación, condición de filtro o cláusula de agrupación se marca como columna de predicado en el catálogo de sistema. Al ejecutar ANALYZE con la cláusula PREDICATE COLUMNS, la operación de análisis incluye solo las columnas que cumplen con los siguientes criterios: + La columna se marca como columna de predicado. + La columna es una clave de distribución. + La columna forma parte de una clave de ordenación. Si ninguna de las columnas de una tabla se marca como predicado, ANALYZE incluye todas las columnas, incluso si se especifica PREDICATE COLUMNS. Si no se marca ninguna columna como columna de predicado, podría ser porque la tabla aún no se ha consultado. Podría elegir usar PREDICATE COLUMNS una vez que el patrón de consultas de su carga de trabajo esté relativamente estable. Cuando el patrón de consultas es variable, con el uso frecuente de columnas diferentes como predicados, el uso de PREDICATE COLUMNS podría dar como resultado temporario estadísticas obsoletas. Las estadísticas obsoletas pueden llevar a planes de tiempo de ejecución de consultas poco óptimos y tiempos de ejecución prolongados. No obstante, la próxima vez que ejecute ANALYZE y use PREDICATE COLUMNS, se incluirán las columnas de predicado nuevas. Para ver detalles de las columnas de predicado, use el siguiente SQL para crear una vista denominada PREDICATE\$1COLUMNS. ``` CREATE VIEW predicate_columns AS WITH predicate_column_info as ( SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num, a.attname as col_name, CASE WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||') WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||') WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||') ELSE NULL::varchar END AS pred_ts FROM pg_statistic s JOIN pg_class c ON c.oid = s.starelid JOIN pg_namespace ns ON c.relnamespace = ns.oid JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum) SELECT schema_name, table_name, col_num, col_name, pred_ts NOT LIKE '2000-01-01%' AS is_predicate, CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use, CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze FROM predicate_column_info; ``` Supongamos que ejecuta la siguiente consulta en la tabla LISTING. Observe que LISTID, LISTTIME y EVENTID se usan en la combinación, el filtro y las cláusulas de agrupamiento. ``` select s.buyerid,l.eventid, sum(l.totalprice) from listing l join sales s on l.listid = s.listid where l.listtime > '2008-12-01' group by l.eventid, s.buyerid; ``` Al ejecutar consultas en la vista PREDICATE\$1COLUMNS, como se observa en el siguiente ejemplo, se ve que LISTID, EVENTID y LISTTIME se marcan como columnas de predicado. ``` select * from predicate_columns where table_name = 'listing'; ``` ``` schema_name | table_name | col_num | col_name | is_predicate | first_predicate_use | last_analyze ------------+------------+---------+----------------+--------------+---------------------+-------------------- public | listing | 1 | listid | true | 2017-05-05 19:27:59 | 2017-05-03 18:27:41 public | listing | 2 | sellerid | false | | 2017-05-03 18:27:41 public | listing | 3 | eventid | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41 public | listing | 4 | dateid | false | | 2017-05-03 18:27:41 public | listing | 5 | numtickets | false | | 2017-05-03 18:27:41 public | listing | 6 | priceperticket | false | | 2017-05-03 18:27:41 public | listing | 7 | totalprice | false | | 2017-05-03 18:27:41 public | listing | 8 | listtime | true | 2017-05-16 20:54:32 | 2017-05-03 18:27:41 ``` Mantener las estadísticas actualizadas mejora el rendimiento de las consultas, ya que permite que el planificador de consultas elija los planes óptimos. Amazon Redshift actualiza las estadísticas de forma automática en segundo plano, y usted también puede ejecutar de forma explícita el comando ANALYZE. Si decide ejecutar explícitamente el comando ANALYZE, haga lo siguiente: + Ejecute el comando ANALYZE antes de ejecutar cualquier consulta. + Ejecute el comando ANALYZE en la base de datos de manera habitual al final de cada ciclo de carga o actualización regular. + Ejecute el comando ANALYZE en toda tabla nueva que cree y en cualquier tabla o columna existente que sufra cambios significativos. + Considere ejecutar operaciones ANALYZE en programas diferentes para diferentes tipos de tablas y columnas, según su uso en consultas y su tendencia al cambio. + Para ahorrar tiempo y recursos del clúster, al ejecutar ANALYZE use la cláusula PREDICATE COLUMNS. No tiene que ejecutar explícitamente el comando ANALYZE después de restaurar una instantánea en un clúster aprovisionado o en un espacio de nombres sin servidor, ni después de reanudar un clúster aprovisionado en pausa. Amazon Redshift conserva la información de la tabla del sistema en estos casos, lo que hace innecesarios los comandos ANALYZE manuales. Amazon Redshift seguirá ejecutando operaciones de análisis automáticas según sea necesario. Una operación de análisis omite las tablas que tienen estadísticas actualizadas. Si ejecuta ANALYZE como parte del flujo de trabajo de extracción, transformación y carga (ETL), el análisis automático omite las tablas con estadísticas actuales. De forma similar, un comando ANALYZE explícito omite tablas cuando el análisis automático ha actualizado las estadísticas de la tabla. ## Historial del comando ANALYZE Saber cuándo fue la última vez que el comando ANALYZE se ejecutó en una tabla o base de datos es útil. Cuando se ejecuta el comando ANALYZE, Amazon Redshift ejecuta distintas consultas que se ven de la siguiente manera: ``` padb_fetch_sample: select * from table_name ``` Ejecute la consulta STL\$1ANALYZE para ver el historial de las operaciones ANALYZE. Si Amazon Redshift analiza una tabla mediante el análisis automático, la columna `is_background` se establece en `t` (true). De lo contrario, se establece en `f` (falso). En el siguiente ejemplo, se combina STV\$1TBL\$1PERM para mostrar el nombre de la tabla y los detalles de tiempo de ejecución. ``` select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, a.starttime, a.endtime from stl_analyze a join stv_tbl_perm t on t.id=a.table_id where name = 'users' order by starttime; xid | name | status | rows | modified_rows | starttime | endtime -------+-------+-----------------+-------+---------------+---------------------+-------------------- 1582 | users | Full | 49990 | 49990 | 2016-09-22 22:02:23 | 2016-09-22 22:02:28 244287 | users | Full | 24992 | 74988 | 2016-10-04 22:50:58 | 2016-10-04 22:51:01 244712 | users | Full | 49984 | 24992 | 2016-10-04 22:56:07 | 2016-10-04 22:56:07 245071 | users | Skipped | 49984 | 0 | 2016-10-04 22:58:17 | 2016-10-04 22:58:17 245439 | users | Skipped | 49984 | 1982 | 2016-10-04 23:00:13 | 2016-10-04 23:00:13 (5 rows) ``` De manera alternativa, puede ejecutar una consulta más compleja que devuelva todas las instrucciones que se ejecutaron en cada transacción completada que incluyó un comando ANALYZE: ``` select xid, to_char(starttime, 'HH24:MM:SS.MS') as starttime, datediff(sec,starttime,endtime ) as secs, substring(text, 1, 40) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid desc, starttime; xid | starttime | secs | substring -----+--------------+------+------------------------------------------ 1338 | 12:04:28.511 | 4 | Analyze date 1338 | 12:04:28.511 | 1 | padb_fetch_sample: select count(*) from 1338 | 12:04:29.443 | 2 | padb_fetch_sample: select * from date 1338 | 12:04:31.456 | 1 | padb_fetch_sample: select * from date 1337 | 12:04:24.388 | 1 | padb_fetch_sample: select count(*) from 1337 | 12:04:24.388 | 4 | Analyze sales 1337 | 12:04:25.322 | 2 | padb_fetch_sample: select * from sales 1337 | 12:04:27.363 | 1 | padb_fetch_sample: select * from sales ... ``` # Limpieza de tablas Amazon Redshift puede ordenar y realizar una operación VACUUM DELETE de forma automática en las tablas en segundo plano. Para limpiar las tablas tras una carga o una serie de actualizaciones incrementales, también puede ejecutar el comando [VACUUM](r_VACUUM_command.md), ya sea en la base de datos completa o en tablas individuales. **nota** Solo los usuarios con los permisos de tabla necesarios pueden vaciar una tabla de forma eficaz. Si se ejecuta VACUUM sin los privilegios de tabla necesarios, la operación se completa correctamente pero no tiene ningún efecto. Para obtener una lista de los permisos de tabla válidos para ejecutar VACUUM de forma eficaz, consulte [VACUUM](r_VACUUM_command.md). Por esta razón, recomendamos realizar una limpieza de tablas individual según sea necesario. También recomendamos esta opción porque es probable que una limpieza de la base de datos completa sea una operación costosa. ## Clasificación automática de tablas Amazon Redshift ordena los datos en segundo plano de forma automática para mantener los datos de la tabla en el orden de su clave de ordenación. Amazon Redshift realiza un seguimiento de sus consultas de análisis para determinar las secciones de la tabla que se beneficiarán de la ordenación. Amazon Redshift también realiza un seguimiento de las consultas de análisis de los clústeres que escalan de forma simultánea. En el caso de arquitecturas de varios clústeres que utilizan el uso compartido de datos de Amazon Redshift, Amazon Redshift también rastrea las consultas de análisis que se originan en los clústeres o grupos de trabajo de consumidores de la malla de datos, incluidos los clústeres/grupos de trabajo de diferentes regiones. Las estadísticas de análisis del clúster principal, los clústeres de escalado simultáneos y los clústeres de los consumidores se agregan para determinar qué secciones de la tabla se beneficiarán de la ordenación. Según la carga en el sistema, Amazon Redshift inicia de forma automática la ordenación. La ordenación automática disminuye la necesidad de ejecutar el comando VACUUM para mantener los datos en orden de clave de ordenación. Si necesita que los datos estén ordenados en clave de ordenación, por ejemplo después de una gran carga de datos, puede ejecutar manualmente el comando VACUUM. Para determinar si su tabla se beneficia al ejecutar VACUUM SORT, monitorice la columna `vacuum_sort_benefit` en [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Amazon Redshift realiza un seguimiento de las consultas de análisis que utilizan la clave de ordenación en cada tabla. Amazon Redshift calcula el porcentaje máximo de mejora al analizar y filtrar los datos de cada tabla (si la tabla estaba completamente ordenada). Esta estimación está visible en la columna `vacuum_sort_benefit` en [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). Puede utilizar esta columna junto con la columna `unsorted` para determinar si las consultas pueden beneficiarse de la ejecución manual de VACUUM SORT en una tabla. La columna `unsorted` refleja el orden de clasificación físico de una tabla. La columna `vacuum_sort_benefit` especifica el impacto que tiene ordenar una tabla mediante la ejecución de VACUUM SORT de forma manual. Por ejemplo, fíjese en la consulta siguiente: ``` select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1; ``` ``` table | unsorted | vacuum_sort_benefit -------+----------+--------------------- sales | 85.71 | 5.00 event | 45.24 | 67.00 ``` Para la tabla “sales”, aunque la tabla está físicamente desordenada un 86 %, la repercusión del rendimiento de la consulta de la tabla estando desordenada un 86 % es de solo un 5 %. Esto puede ser porque solo se puede acceder a una pequeña parte de la tabla por consultas o porque muy pocas consultas accedieron a la tabla. Para la tabla “event”, la tabla está desordenada físicamente un 45 %. Pero la repercusión del rendimiento de la consulta de un 67 % indica que se puede acceder a una gran parte de la tabla por consultas o que la cantidad de consultas que accedieron a la tabla fue grande. La tabla “event” se puede beneficiar potencialmente de ejecutar VACUUM SORT. ## Eliminación de limpieza automática Cuando se realiza una eliminación, las filas se marcan para eliminarse, pero esto no sucede. Amazon Redshift ejecuta de forma automática una operación VACUUM DELETE en segundo plano en función de la cantidad de filas eliminadas en las tablas de base de datos. Amazon Redshift programa la operación VACUUM DELETE para que se ejecute durante periodos de carga reducida y pone en pausa la operación durante periodos de carga elevada. **Topics** + [Clasificación automática de tablas](#automatic-table-sort) + [Eliminación de limpieza automática](#automatic-table-delete) + [Frecuencia de ejecución de VACUUM](#vacuum-frequency) + [Fase de ordenación y fase de fusión](#vacuum-stages) + [Umbral de limpieza](#vacuum-sort-threshold) + [Tipos de limpieza](#vacuum-types) + [Cómo minimizar los tiempos de limpieza](vacuum-managing-vacuum-times.md) ## Frecuencia de ejecución de VACUUM Debe limpiar con tanta frecuencia como sea necesario para mantener un rendimiento de consultas coherente. Al determinar con cuánta frecuencia debe ejecutar el comando VACUUM, considere los siguientes factores: + Ejecute VACUUM durante periodos en los que espera actividad mínima en el clúster, como por la noche o durante ventanas de administración de la base de datos designadas. + Ejecute los comandos VACUUM fuera de los periodos de mantenimiento. Para obtener más información, consulte [Programación de periodos de mantenimiento](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html). + Una región grande sin ordenar da como resultado tiempos de limpieza más prolongados. Si retrasa la limpieza, esta demorará más porque se necesitará reorganizar más datos. + VACUUM es una operación con muchas E/S, por lo que cuanto más demore en completarse la limpieza, más efecto tendrá sobre las consultas simultáneas y otras operaciones de base de datos que se ejecuten en su clúster. + VACUUM demora más en tablas con ordenación intercalada. Para evaluar si las tablas intercaladas necesitan reordenarse, consulte la vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). ## Fase de ordenación y fase de fusión Amazon Redshift realiza una operación de limpieza en dos fases: primero, ordena las filas de la región no ordenada y, luego, de ser necesario, fusiona las filas recién ordenadas con las filas ya existentes en el final de la tabla. Al limpiar una tabla grande, la operación de limpieza avanza en una serie de pasos que consisten en ordenaciones incrementales seguidas de fusiones. Si se produce un error en la operación o si Amazon Redshift se desconecta durante una limpieza, la tabla o la base de datos limpiada de forma parcial se encontrarán en estado consistente, pero debe reiniciar la operación de limpieza de forma manual. Las ordenaciones incrementales se pierden, pero las filas fusionadas confirmadas antes del error no necesitar limpiarse de nuevo. Si la región sin ordenar es grande, el tiempo perdido podría ser significativo. Para obtener más información acerca de las fases de ordenación y fusión, consulte [Reducción del volumen de filas fusionadas](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows). Los usuarios pueden obtener acceso a las tablas mientras se limpian. Puede realizar consultas y escribir operaciones mientras se limpia una tabla, pero cuando se ejecutan DML y una limpieza de manera simultánea, ambas operaciones podrían demorar más de lo usual. Si se ejecutan las instrucciones UPDATE y DELETE durante una limpieza, el rendimiento del sistema podría reducirse. Las fusiones incrementales bloquean temporalmente las operaciones UPDATE y DELETE simultáneas, y estas últimas, a su vez, bloquean temporalmente los pasos de fusión incrementales en las tablas afectadas. Las operaciones DDL, como ALTER TABLE, se bloquean hasta que la operación de limpieza finaliza con la tabla. **nota** Hay varios modificadores de VACUUM que controlan la forma en que funciona. Puede utilizarlos para adaptar la operación de limpieza a las necesidades actuales. Por ejemplo, el uso de VACUUM RECLUSTER acorta la operación de limpieza, ya que no se realiza una operación de fusión completa. Para obtener más información, consulte [VACUUM](r_VACUUM_command.md). ## Umbral de limpieza De manera predeterminada, VACUUM omite la fase de ordenación para cualquier tabla que tenga más del 95 por ciento de las filas de la tabla ordenadas. La omisión de la fase de ordenación puede mejorar significativamente el rendimiento de VACUUM. Para cambiar el umbral de ordenación predeterminado de una tabla única, incluya el nombre de la tabla y el parámetro TO *threshold (umbral)* PERCENT cuando ejecute el comando VACUUM. ## Tipos de limpieza Para obtener más información acerca de los distintos tipos de limpieza, consulte [VACUUM](r_VACUUM_command.md). # Cómo minimizar los tiempos de limpieza Amazon Redshift ordena los datos de forma automática y ejecuta VACUUM DELETE en segundo plano. Esto disminuye la necesidad de ejecutar el comando VACUUM. La limpieza es un proceso que puede durar mucho tiempo. Según la naturaleza de los datos, le recomendamos las siguientes prácticas para minimizar los tiempos de limpieza. **Topics** + [Decisión de si se debe reindexar](#r_vacuum-decide-whether-to-reindex) + [Reducción del tamaño de la región no ordenada](#r_vacuum_diskspacereqs) + [Reducción del volumen de filas fusionadas](#vacuum-managing-volume-of-unmerged-rows) + [Carga de los datos en orden de clave de clasificación](#vacuum-load-in-sort-key-order) + [Uso de tablas de series temporales para reducir los datos almacenados](#vacuum-time-series-tables) ## Decisión de si se debe reindexar A menudo puede mejorar de manera significativa el rendimiento de consultas al usar un estilo de ordenación intercalada, pero, con el tiempo, el rendimiento podría degradarse si cambia la distribución de los valores en las columnas con claves de ordenación. Cuando inicialmente se carga una tabla intercalada vacía mediante COPY o CREATE TABLE AS, Amazon Redshift crea el índice intercalado de forma automática. Si carga inicialmente una tabla intercalada mediante INSERT, necesita ejecutar VACUUM REINDEX a continuación para inicializar el índice intercalado. Con el tiempo, a medida que agrega filas con valores de clave de ordenación nuevos, el rendimiento podría degradarse si cambia la distribución de los valores en las columnas con claves de ordenación. Si las filas nuevas caen principalmente dentro del rango de los valores de clave de ordenación existentes, la reindexación no es necesaria. Ejecute VACUUM SORT ONLY o VACUUM FULL para restaurar el orden de ordenación. El motor de consultas puede usar el orden de ordenación para seleccionar de manera eficiente qué bloques de datos deben analizarse para procesar una consulta. En caso de una ordenación intercalada, Amazon Redshift analiza los valores en las columnas con clave de ordenación para determinar el orden óptimo. Si la distribución de los valores de clave cambia o se sesga a medida que se agregan filas, la estrategia de ordenación ya no será óptima y el beneficio en rendimiento brindado por la ordenación se degradará. Para volver a analizar la distribución de claves de ordenación se puede ejecutar VACUUM REINDEX. La operación de reindexación lleva mucho tiempo; en consecuencia, para decidir si una tabla se beneficiará de una reindexación, ejecute una consulta en la vista [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md). Por ejemplo, la siguiente consulta muestra los detalles de las tablas que usan claves de ordenación intercalada. ``` select tbl as tbl_id, stv_tbl_perm.name as table_name, col, interleaved_skew, last_reindex from svv_interleaved_columns, stv_tbl_perm where svv_interleaved_columns.tbl = stv_tbl_perm.id and interleaved_skew is not null; tbl_id | table_name | col | interleaved_skew | last_reindex --------+------------+-----+------------------+-------------------- 100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45 100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45 100072 | part | 0 | 1.65 | 2015-04-22 22:05:45 100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45 (4 rows) ``` El valor de `interleaved_skew` es una relación que indica el grado de sesgo. Un valor de 1 indica que no existe sesgo. Si el sesgo es mayor que 1,4, VACUUM REINDEX usualmente mejorará el rendimiento a menos que el sesgo en el conjunto subyacente sea inherente. Puede usar el valor de fecha en `last_reindex` para determinar cuánto tiempo ha pasado desde la última reindexación. ## Reducción del tamaño de la región no ordenada La región no ordenada aumenta cuando se cargan grandes cantidades de datos nuevos en tablas que ya tienen datos o cuando no se limpian las tablas como parte de las operaciones de mantenimiento de rutina. Para evitar las operaciones de limpieza prolongadas, aplique las siguientes prácticas: + Ejecutar las operaciones de limpieza según un programa regular. Si carga tablas en incrementos pequeños (como actualizaciones diarias que representan un bajo porcentaje de la cantidad total de filas de la tabla), el ejecutar VACUUM con regularidad lo ayudará a asegurarse de que las operaciones de limpieza individuales se realicen con rapidez. + Ejecutar la carga más grande primero. Si necesita cargar una tabla nueva con distintas operaciones COPY, ejecute la carga más grande primero. Cuando se ejecuta una carga inicial en una tabla nueva o truncada, todos los datos se cargan directamente en la región ordenada, por lo que no se requiere limpieza alguna. + Truncar una tabla en lugar de eliminar todas las filas. Eliminar las filas de una tabla no recupera el espacio que estas ocupaban sino hasta que se realiza una operación de limpieza; no obstante, el truncar una tabla la vacía y recupera el espacio en el disco, por lo que no se requiere limpieza alguna. De manera alternativa, elimine la tabla y recréela. + Truncar o eliminar las tablas de prueba. Si carga una cantidad pequeña de filas en una tabla con fines de prueba, no elimine las filas una vez que termine. En cambio, trunque la tabla y vuelva a cargar las filas como parte de la operación de carga de producción subsecuente. + Realizar una copia profunda. Si una tabla que usa una tabla con clave de ordenación compuesta tiene una región no ordenada grande, una copia profunda es mucho más rápida que una limpieza. Una copia profunda recrea y vuelve a completar una tabla mediante una operación de inserción masiva, que vuelve a ordenar la tabla de manera automática. Si una tabla tiene una gran región no ordenada, una copia profunda es mucho más rápida que una limpieza. La diferencia es que durante una operación de copia profunda no se pueden hacer actualizaciones simultáneas, lo cual sí puede hacerse durante una limpieza. Para obtener más información, consulte [Prácticas recomendadas de Amazon Redshift para el diseño de consultas](c_designing-queries-best-practices.md). ## Reducción del volumen de filas fusionadas Si una operación de limpieza necesita fusionar filas nuevas en la región ordenada de una tabla, el tiempo requerido para una limpieza aumentará a medida que la tabla aumente. Puede mejorar el rendimiento de la limpieza al reducir la cantidad de filas que deben fusionarse. Antes de una limpieza, una tabla consta de una región ordenada en la parte superior, seguida de una región no ordenada que aumenta cada vez que se agregan o actualizan filas. Cuando se agrega un conjunto de filas mediante una operación COPY, el conjunto nuevo de filas se ordena en la clave de ordenación a medida que se agrega a la región no ordenada que se encuentra al final de la tabla. Las filas nuevas se ordenan dentro de su propio conjunto, pero no dentro de la región no ordenada. En el siguiente diagrama, se ilustra la región no ordenada luego de dos operaciones COPY sucesivas, donde la clave de ordenación es CUSTID. Para mayor simpleza, en este ejemplo se muestra una clave de ordenación compuesta, pero los mismos principios se aplican a las claves de ordenación intercaladas, excepto que, para las tablas intercaladas, el impacto de la región no ordenada es mayor. ![\[Una tabla sin clasificar que contiene los registros de dos operaciones COPY.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region.png) Una operación de limpieza restaura el orden de la tabla en dos fases: 1. Ordena la región no ordenada en una región recién ordenada. La primera fase es relativamente poco costosa, porque solo se rescribe la región no ordenada. Si el rango de valores de clave de clasificación de la región recién ordenada es mayor que el rango existente, solo se deben rescribir las filas nuevas y la limpieza se completa. Por ejemplo, si la región ordenada tiene valores de ID de 1 a 500 y las operaciones de copia subsecuentes agregan valores de clave mayores que 500, solo se debe rescribir la región no ordenada. 1. Fusiona la región recién ordenada con la región anteriormente ordenada. Si las claves de la región recién ordenada se superponen con las claves de la región ordenada, VACUUM necesita fusionar las filas. Desde el comienzo de la región recién ordenada (en la clave de ordenación más baja), la limpieza escribe las filas fusionadas de las regiones anteriormente y recién ordenadas en un nuevo conjunto de bloques. El grado de superposición del nuevo rango de claves de ordenación en relación con las claves de ordenación existentes determina hasta dónde es necesario rescribir la región antes ordenada. Si las claves no ordenadas se encuentran esparcidas por todo el rango de ordenación existente, podría necesitarse una limpieza que rescriba partes de la tabla. En el siguiente diagrama, se muestra cómo una limpieza ordenaría y fusionaría las filas agregadas a una tabla en la que CUSTID es la clave de ordenación. Como cada operación de COPY agrega un nuevo conjunto de filas con valores de clave que se superponen con las claves existentes, se debe rescribir casi toda la tabla. En el diagrama, se muestra una única ordenación y fusión, pero, en la práctica, una operación de limpieza grande consiste en una serie de pasos incrementales de ordenación y fusión. ![\[Una operación VACCUM en la tabla de ejemplo en dos pasos. Primero se ordenan las nuevas filas y, a continuación, se fusionan con las filas existentes.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png) Si el rango de las claves de ordenación en un conjunto de filas nuevas se superpone con el rango de claves existentes, el costo de la fase de fusión continúa aumentando de manera proporcional al tamaño de la tabla, a medida que la tabla aumenta mientras el costo de la fase de ordenación se mantiene proporcional al tamaño de la región no ordenada. En tal caso, el costo de la fase de fusión supera el costo de la fase de ordenación, como lo muestra el diagrama a continuación. ![\[Diagrama que muestra cómo la etapa de fusión se vuelve más costosa cuando las filas nuevas tienen claves de clasificación superpuestas a las filas existentes.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-example-merge-region-grows.png) Para determinar qué proporción de una tabla se volvió a fusionar, ejecute una consulta SVV\$1VACUUM\$1SUMMARY una vez terminada la operación de limpieza. La siguiente consulta muestra el efecto de seis limpiezas consecutivas, a medida que CUSTSALES aumenta cada vez más con el paso del tiempo. ``` select * from svv_vacuum_summary where table_name = 'custsales'; table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_ | | partitions | increments | time | delta | delta | delta | partitions -----------+------+------------+------------+------------+-------+------------+---------+--------------- custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47 custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47 custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47 custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47 custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47 custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47 (6 rows) ``` La columna merge\$1increments indica la cantidad de datos fusionados en cada operación de limpieza. Si la cantidad de incrementos de fusión durante las limpiezas consecutivas aumenta de manera proporcional al crecimiento en el tamaño de la tabla, indica que cada operación de limpieza vuelve a fusionar una cantidad cada vez mayor de filas en la tabla, debido a que las regiones ordenadas ya existentes y las nuevas se superponen. ## Carga de los datos en orden de clave de clasificación Si carga los datos en orden de clave de clasificación mediante un comando COPY, es posible que reduzca o incluso elimine la necesidad de ejecutar una limpieza. COPY agrega automáticamente filas nuevas a la región ordenada de la tabla cuando se satisfacen todas las siguientes condiciones: + La tabla usa una clave de ordenación compuesta con solo una columna de ordenación. + La columna de ordenación es NOT NULL. + La tabla está 100 por ciento ordenada o vacía. + Todas las filas nuevas son mayores en cuanto al orden de ordenación que las filas existentes, entre ellas las filas marcadas para eliminación. En esta instancia, Amazon Redshift usa los primeros ocho bytes de la clave de ordenación para determinar el orden. + El comando COPY no desencadena determinadas optimizaciones de carga. Al cargar grandes volúmenes de datos, Amazon Redshift puede optimizar el rendimiento mediante la creación de nuevas particiones ordenadas en lugar de agregar filas a la región ordenada de la tabla. Suponga, por ejemplo, que tiene una tabla que registra los eventos de los clientes con un ID de cliente y la hora. Si ordena a partir del ID de cliente, es probable que el rango de clave de ordenación de las filas nuevas agregadas con cargas incrementales se superponga con el rango existente, como se observa en el ejemplo anterior, lo cual conduce a una operación de limpieza costosa. Si establece la clave de clasificación en una columna de marca temporal, las filas nuevas se anexarán en orden de ordenación al final de la tabla, como lo muestra el diagrama a continuación, lo que reducirá o incluso eliminará la necesidad de ejecutar una limpieza. ![\[Una tabla que utiliza una columna de marca temporal como clave de clasificación, con lo que se obtienen nuevos registros que no es necesario ordenar.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png) ## Uso de tablas de series temporales para reducir los datos almacenados Si mantiene datos durante un periodo acumulativo, use una serie de tablas, como se ilustra en el siguiente diagrama. ![\[Cinco tablas con datos de cinco trimestres. La tabla más antigua se suprime para mantener un año de tiempo continuo.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png) Cree una tabla nueva cada vez que agrega un conjunto de datos y, luego, elimine la tabla más antigua de la serie. Se obtiene un beneficio doble: + Se evita el costo adicional de eliminar filas, porque una operación DROP TABLE es mucho más eficiente que una operación DELETE masiva. + Si las tablas se ordenan por marca temporal, no se necesita una limpieza. Si cada tabla tiene los datos correspondientes a un mes, una limpieza deberá, cuanto mucho, rescribir los datos de todo un mes, incluso si las tablas no se ordenan por marca temporal. Puede crear una vista UNION ALL para usar al informar consultas, lo cual oculta el hecho de que los datos se almacenan en distintas tablas. Si una consulta filtra según la clave de ordenación, el planificador de consultas puede omitir de manera eficiente todas las tablas que no se usan. UNION ALL puede ser menos eficiente para otros tipos de consultas, por lo que debería evaluar el rendimiento de consultas en el contexto de todas las consultas que usan las tablas. # Administración de operaciones de escritura simultáneas Algunas aplicaciones no solo requieren la ejecución simultánea de consultas y cargas, sino también la capacidad de escribir en distintas tablas o en la misma tabla de manera simultánea. En este contexto, *simultánea* significa "superpuesta", no "programada para que se ejecute exactamente al mismo tiempo". Dos transacciones se consideran simultáneas si la segunda comienza antes de que se confirme la primera. Las operaciones concurrentes pueden originarse en sesiones diferentes controladas por el mismo usuario o por usuarios diferentes. Amazon Redshift es compatible con estos tipos de aplicaciones porque permite que las tablas se lean mientras se cargan o modifican de forma progresiva. Las consultas simplemente ven la última versión confirmada o una *instantánea* de los datos, en lugar de esperar a que se confirme la siguiente versión. Si desea que una consulta particular espere por una confirmación de otra operación de escritura, debe programarla de manera acorde. **nota** Amazon Redshift admite el comportamiento de *confirmación automática* predeterminado en el que cada comando SQL ejecutado por separado se confirma individualmente. Si incluye un conjunto de comandos en un bloque de transacciones (definido por instrucciones [BEGIN](r_BEGIN.md) y [END](r_END.md)), el bloque se confirma como una transacción, de manera que puede revertirse de ser necesario. Las excepciones a este comportamiento son los comandos TRUNCATE y VACUUM, que confirman automáticamente todos los cambios pendientes realizados en la transacción actual. Algunos clientes SQL emiten los comandos BEGIN y COMMIT automáticamente, por lo que el cliente controla si un grupo de instrucciones se ejecuta como una transacción o si cada instrucción individual se ejecuta como su propia transacción. Consulte la documentación de la interfaz que está utilizando. Por ejemplo, cuando se utiliza el controlador JDBC de Amazon Redshift, una cadena `PreparedStatement` de JDBC con consulta que contiene varios comandos SQL (separados por punto y coma) ejecuta todas las instrucciones como una sola transacción. Por el contrario, si utiliza SQL Workbench/J y establece AUTO COMMIT ON, si ejecuta varias instrucciones, cada una de ellas se ejecuta como una transacción propia. En los temas a continuación, se describen algunos de los conceptos clave y los casos de uso que incluyen transacciones, instantáneas de base de datos, actualizaciones y comportamiento simultáneo. **Topics** + [Niveles de aislamiento en Amazon Redshift](c_serial_isolation.md) + [Operaciones de lectura y escritura y de escritura](c_write_readwrite.md) + [Ejemplos de escritura simultánea](r_Serializable_isolation_example.md) + [Solución de problemas de errores de aislamiento serializable](c_serial_isolation-serializable-isolation-troubleshooting.md) # Niveles de aislamiento en Amazon Redshift Las operaciones de escritura simultáneas son compatibles con Amazon Redshift en modo protegido, con bloqueos de escritura en las tablas y el principio de *aislamiento serializable*. El aislamiento serializable conserva la ilusión de que una transacción que se ejecuta en una tabla es la única transacción ejecutándose en ella. Las bases de datos de Amazon Redshift admiten operaciones de escritura simultáneas, ya que cada operación utiliza la última versión confirmada, o instantánea, de sus datos al inicio de la transacción. Una instantánea de base de datos se crea dentro de una transacción con la primera aparición de la mayoría de las instrucciones SELECT, los comandos DML como COPY, DELETE, INSERT, UPDATE y TRUNCATE, y los siguientes comandos DDL: + ALTER TABLE (para agregar o eliminar columnas) + CREATE TABLE + DROP TABLE + TRUNCATE TABLE Ninguna otra transacción puede cambiar esta instantánea, lo que significa que las transacciones están aisladas unas de otras. Es decir, las transacciones simultáneas son invisibles entre sí, no pueden detectar los cambios de la otra. Cualquier ejecución simultánea de transacciones debe producir los mismos resultados que la ejecución en serie de esas transacciones. Si ninguna ejecución en serie de esas transacciones puede producir los mismos resultados, la transacción que ejecuta una instrucción que podría afectar la capacidad de serialización se anula y revierte. Por ejemplo, supongamos que un usuario intenta ejecutar dos transacciones simultáneas, T1 y T2. La ejecución de T1 y T2 debe producir los mismos resultados que al menos uno de los siguientes escenarios: + T1 y T2 se ejecutan en serie en ese orden. + T2 y T1 se ejecutan en serie en ese orden. Los niveles de aislamiento de Amazon Redshift evitan los siguientes problemas: + Lecturas incorrectas: una lectura incorrecta se produce cuando una transacción lee datos que aún no se han confirmado. Por ejemplo, supongamos que la transacción 1 actualiza una fila. La transacción 2 lee la fila actualizada antes de que T1 confirme la actualización. Si T1 anula el cambio, T2 habrá leído los datos de las filas no confirmadas que Amazon Redshift considera ahora que nunca existieron. + Lecturas no repetibles: se produce una lectura no repetible cuando una sola transacción lee la misma fila dos veces, pero obtiene datos diferentes cada vez. Por ejemplo, supongamos que la transacción 1 lee una fila. La transacción 2 actualiza o elimina esa fila y confirma la actualización o la eliminación. Si T1 vuelve a leer la fila, recupera valores de fila diferentes o descubre que la fila se ha eliminado. + Fantasmas: un fantasma es una fila que coincide con los criterios de búsqueda pero que no se ve inicialmente. Por ejemplo, supongamos que la transacción 1 lee un conjunto de filas que cumplen sus criterios de búsqueda. La transacción 2 genera una nueva fila en una instrucción UPDATE o INSERT que coincide con los criterios de búsqueda de T1. Si T1 vuelve a ejecutar su instrucción de búsqueda, obtiene un conjunto de filas diferente. ## Aislamiento SNAPSHOT y SERIALIZABLE Los aislamientos SNAPSHOT y SERIALIZABLE son dos niveles de aislamiento serializable disponibles en Amazon Redshift. El aislamiento SNAPSHOT es el nivel de aislamiento predeterminado al crear clústeres aprovisionados y grupos de trabajo sin servidor, lo que permite procesar volúmenes de datos más grandes que el aislamiento SERIALIZABLE en menos tiempo. El aislamiento SERIALIZABLE lleva más tiempo, pero implementa restricciones más estrictas en las transacciones simultáneas. Este nivel de aislamiento evita problemas como las anomalías en el sesgo de escritura, ya que solo permite que se confirme una transacción y cancela todas las demás transacciones simultáneas con un error de infracción del aislamiento que se puede serializar. A continuación, se muestra un ejemplo cronológico de cómo se gestionarían dos operaciones de escritura simultáneas al utilizar el aislamiento SNAPSHOT. La instrucción UPDATE de cada usuario puede confirmarse porque no entra en conflicto al intentar actualizar las mismas filas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_serial_isolation.html) Si se ejecuta el mismo escenario mediante aislamiento serializable, Amazon Redshift termina el usuario 2 debido a una infracción serializable y devuelve un error `1023`. Para obtener más información, consulte [Solución de problemas de errores de aislamiento serializable](c_serial_isolation-serializable-isolation-troubleshooting.md). En este caso, solo el usuario 1 puede confirmar correctamente. ## Consideraciones Cuando utilice niveles de aislamiento en Amazon Redshift, tenga en cuenta lo siguiente: + Consulte la vista del catálogo STV\$1DB\$1ISOLATION\$1LEVEL para ver qué nivel de aislamiento utiliza la base de datos. Para obtener más información, consulte [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md). + Consulte la vista de PG\$1DATABASE\$1INFO para ver cuántas transacciones simultáneas se admiten para la base de datos. Para obtener más información, consulte [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + Las tablas de catálogo del sistema (PG) y otras tablas del sistema de Amazon Redshift no se bloquean en una transacción. Por lo tanto, los cambios realizados en los objetos de base de datos que surjan de las operaciones DDL y TRUNCATE son visibles con cualquier transacción simultánea cuando se confirman. Por ejemplo, supongamos que la tabla A existe en la base de datos al momento en que comienzan dos transacciones simultáneas, T1 y T2. Supongamos que T2 devuelve una lista de tablas al seleccionar las de la tabla de catálogo PG\$1TABLES. Luego T1 elimina la tabla A y confirma los cambios y, a continuación, T2 vuelve a especificar las tablas. La tabla A ya no aparece en la lista. Si T2 intenta ejecutar una consulta en la tabla eliminada, Amazon Redshift devuelve un error de tipo “la relación no existe”. La consulta de catálogo que le devuelve la lista de tablas a T2 o que verifica la existencia de la tabla A no se encuentra sujeta a las mismas reglas de aislamiento que las operaciones que se realizan en las tablas de usuario. Las transacciones de las actualizaciones de estas tablas se ejecutan en un modo de aislamiento de lectura confirmada. + Las tablas de catálogo con el prefijo PG no son compatibles con el aislamiento de SNAPSHOT. # Operaciones de lectura y escritura y de escritura Puede administrar el comportamiento específico de las operaciones simultáneas de escritura al decidir cuándo y cómo ejecutar diferentes tipos de comandos. Los siguientes comandos son relevantes en este análisis: + Comandos COPY, que realizan cargas (iniciales o incrementales). + Comandos INSERT, que agregan una o más filas por vez. + Comandos UPDATE, que modifican filas existentes. + Comandos DELETE, que eliminan filas. Las operaciones COPY e INSERT son operaciones de escritura pura. Las operaciones DELETE y UPDATE son operaciones de lectura/escritura (para eliminar o actualizar filas, primero hay que leerlas). Los resultados de las operaciones simultáneas de escritura dependen de los comandos específicos que se están ejecutando simultáneamente. Las operaciones UPDATE y DELETE se comportan de manera diferente porque dependen de una lectura inicial de la tabla antes de cualquier escritura. Dado que las transacciones simultáneas son invisibles entre sí, tanto UPDATE como DELETE deben leer una snapshot de los datos de la última confirmación. Cuando la primera operación UPDATE o DELETE levanta el bloqueo, la segunda debe determinar si los datos con los que trabajará son potencialmente obsoletos. No lo serán, porque la segunda transacción no obtiene su snapshot de los datos sino hasta después de que la primera transacción haya levantado su bloqueo. ## Posible situación de bloqueo para transacciones de escritura simultáneas que involucran múltiples tablas Cuando las transacciones involucren actualizaciones de más de una tabla, existe la posibilidad de que transacciones que se ejecutan de manera simultánea se bloqueen al querer escribir en el mismo conjunto de tablas. Una transacción levanta todos los bloqueos de tabla a la vez, ya sea cuando confirma o cuando se revierte; no los libera de a uno. Por ejemplo, supongamos que las transacciones T1 y T2 comienzan, aproximadamente, al mismo tiempo. Si T1 comienza a escribir en la tabla A y T2 comienza a escribir en la tabla B, ambas transacciones pueden continuar sin conflictos. No obstante, si T1 finaliza la escritura de la tabla A y necesita comenzar a escribir en la tabla B, no podrá hacerlo porque T2 aún la bloquea. Del mismo modo, si T2 termina de escribir en la tabla B y necesita comenzar a escribir en la tabla A, tampoco podrá hacerlo porque T1 aún la bloquea. Como ninguna de las transacciones puede liberar los bloqueos sino hasta que todas las operaciones de escritura se hayan confirmado, ninguna transacción puede avanzar. Para evitar este tipo de bloqueo, debe programar las operaciones de escritura simultáneas con sumo cuidado. Por ejemplo, siempre debe actualizar las tablas en el mismo orden en las transacciones y, si especifica bloqueos, bloquee las tablas en el mismo orden antes de realizar cualquier operación DML. ## Posible situación de bloqueo para transacciones de escritura simultáneas que involucran una sola tabla En un entorno de aislamiento de instantáneas, pueden producirse bloqueos al ejecutar transacciones de escritura simultáneas en la misma tabla. El bloqueo de aislamiento de instantáneas ocurre cuando las instrucciones INSERT o COPY simultáneas comparten un bloqueo y avanzan, y otra instrucción necesita realizar una operación (UPDATE, DELETE, MERGE o DDL) que requiere un bloqueo exclusivo en la misma tabla. Veamos la siguiente situación: Transacción 1 (T1): ``` INSERT/COPY INTO table_A; ``` Transacción 2 (T2): ``` INSERT/COPY INTO table_A; table_A ``` Puede producirse un bloqueo cuando varias transacciones con operaciones INSERT o COPY se ejecutan simultáneamente en la misma tabla con un bloqueo compartido, y una de esas transacciones sigue la operación de escritura pura con una operación que requiere un bloqueo exclusivo, como una instrucción UPDATE, MERGE, DELETE o DDL. Para evitar el bloqueo en estas situaciones, puede separar las instrucciones que requieren un bloqueo exclusivo (instrucciones UPDATE/MERGE/DELETE/DDL) en una transacción diferente para que las instrucciones INSERT/COPY puedan progresar simultáneamente y las instrucciones que requieren bloqueos exclusivos puedan ejecutarse después de ellas. De forma alternativa, para transacciones con instrucciones INSERT/COPY y MERGE/UPDATE/MERGE en la misma tabla, puede incluir lógica de reintento en las aplicaciones para evitar posibles bloqueos. # Ejemplos de escritura simultánea En los siguientes ejemplos de pseudocódigo, se demuestra cómo, cuando se ejecutan de manera simultánea, las transacciones avanzan o esperan. ## Ejemplos de escritura simultánea con aislamiento serializable ### Operaciones COPY simultáneas en la misma tabla con aislamiento serializable La transacción 1 copia filas en la tabla LISTING: ``` begin; copy listing from ...; end; ``` La transacción 2 comienza de manera simultánea en una sesión por separado y copia más filas en la tabla LISTING. La transacción 2 debe esperar hasta que la transacción 1 levante el bloqueo de escritura de la tabla LISTING; luego, podrá avanzar. ``` begin; [waits] copy listing from ; end; ``` El mismo comportamiento se observaría si una o ambas transacciones tuvieran un comando INSERT, en lugar de COPY. ### Operaciones DELETE simultáneas desde la misma tabla con aislamiento serializable La transacción 1 elimina filas de una tabla: ``` begin; delete from listing where ...; end; ``` La transacción 2 comienza de manera simultánea y elimina filas de la misma tabla. Tendrá éxito porque espera a que la transacción 1 termine antes de probar eliminar filas. ``` begin [waits] delete from listing where ; end; ``` El mismo comportamiento se observaría si una o ambas transacciones tuvieran un comando UPDATE para la misma tabla, en lugar de DELETE. ### Transacciones simultáneas con una mezcla de operaciones de lectura y escritura con aislamiento serializable En este ejemplo, la transacción 1 elimina filas de la tabla USERS, vuelve a cargar la tabla, ejecuta una consulta COUNT(\$1) y, luego, ANALYZE, antes de confirmar: ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` Mientras tanto, comienza la transacción 2. Esta transacción prueba copiar filas adicionales en la tabla USERS, analizarla y, luego, ejecutar la misma consulta COUNT(\$1) que la primera transacción: ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` La segunda transacción tendrá éxito porque debe esperar a que la primera termine. Su consulta COUNT devolverá el recuento en función de la carga que ha completado. ## Ejemplos de escritura simultánea con aislamiento de instantánea ### Operaciones de copia simultáneas en la misma tabla con aislamiento de instantánea La transacción 1 copia filas en la tabla LISTING: ``` begin; copy listing from ...; end; ``` La transacción 2 comienza de manera simultánea en una sesión por separado y copia más filas en la tabla LISTING. La transacción 2 puede progresar simultáneamente hasta que cualquiera de las transacciones necesite escribir datos en la tabla de destino `listing`, momento en el que se ejecutarán secuencialmente. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` El mismo comportamiento se observaría si una o ambas transacciones tuvieran un comando INSERT, en lugar de COPY. ### Operaciones DELETE simultáneas desde la misma tabla con aislamiento de instantánea Las operaciones DELETE y UPDATE simultáneas desde la misma tabla con aislamiento de instantánea se ejecutan igual que las operaciones ejecutadas con aislamiento serializable. ### Transacciones simultáneas con una mezcla de operaciones de lectura y escritura con aislamiento de instantánea Las transacciones simultáneas que se ejecutan con mezclas de operaciones con aislamiento de instantánea se ejecutan igual que las transacciones con mezclas de operaciones que se ejecutan con aislamiento serializable. # Solución de problemas de errores de aislamiento serializable ## ERROR:1023 DETAIL: Serializable isolation violation on a table in Redshift Cuando Amazon Redshift detecta un error de aislamiento serializable, se muestra un mensaje de error como el siguiente. ``` ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift ``` Para solucionar el error de aislamiento serializable, puede probar los métodos siguientes: + Volver a intentar la transacción cancelada. Amazon Redshift detectó que una carga de trabajo simultánea no es serializable. Sugiere que hay deficiencias en la lógica de la aplicación, que por lo general se pueden solucionar si se intenta realizar la transacción en la que se encontró el error de nuevo. Si el problema persiste, pruebe uno de los métodos siguientes. + Mover cualquier operación que no tenga que estar en la misma transacción atómica fuera de la transacción. Este método se aplica cuando las operaciones individuales dentro de dos transacciones tienen referencias cruzadas entre sí de forma que pueden afectar al resultado de la otra transacción. Por ejemplo, las dos sesiones siguientes inician una transacción cada una. ``` Session1_Redshift=# begin; ``` ``` Session2_Redshift=# begin; ``` El resultado de la instrucción SELETCT en cada transacción se podría ver afectado por una instrucción INSERT en la otra. Dicho de otro modo, suponga que ejecuta las siguientes instrucciones en serie, en cualquier orden. En cada caso, el resultado es que una de las instrucciones SELECT devuelve una fila más que si las transacciones se ejecutaran de forma simultánea. No hay ningún orden en que las operaciones se puedan ejecutar en serie que produzca el mismo resultado que cuando se ejecutan de forma simultánea. Así, la última operación que se ejecuta da lugar a un error de aislamiento serializable. ``` Session1_Redshift=# select * from tab1; Session1_Redshift=# insert into tab2 values (1); ``` ``` Session2_Redshift=# insert into tab1 values (1); Session2_Redshift=# select * from tab2; ``` En muchos casos, el resultado de las instrucciones SELECT no es importante. Dicho de otro modo, la atomicidad de las operaciones en las transacciones no es importante. En estos casos, saque las instrucciones SELECT de sus transacciones, como se muestra en los ejemplos siguientes. ``` Session1_Redshift=# begin; Session1_Redshift=# insert into tab1 values (1) Session1_Redshift=# end; Session1_Redshift=# select * from tab2; ``` ``` Session2_Redshift # select * from tab1; Session2_Redshift=# begin; Session2_Redshift=# insert into tab2 values (1) Session2_Redshift=# end; ``` En estos ejemplos, no hay ninguna referencia cruzada en las transacciones. Las dos instrucciones INSERT no se ven afectadas entre sí. En estos ejemplo, hay al menos un orden en el que las transacciones se pueden ejecutar en serie y producir el mismo resultado que si se ejecutan de manera simultánea. Estos significa que las transacciones son serializables. + Obligue a la serialización bloqueando todas las tablas en cada sesión. El comando [LOCK](r_LOCK.md) bloquea operaciones que dan lugar a errores de aislamiento serializable. Cuando utilice el comando LOCK, asegúrese de hacer lo siguiente: + Bloquee todas las tablas que se ven afectadas por la transacción, incluidas aquellas afectadas por instrucciones SELECT de solo lectura dentro de la transacción. + Bloquee las tablas en el mismo orden, con independencia del orden en que se ejecutan las operaciones. + Bloquee todas las tablas al principio de la transacción, antes de llevar a cabo alguna operación. + Utilizar el aislamiento de instantáneas para transacciones simultáneas Utilice un comando ALTER DATABASE con aislamiento de instantáneas. Para obtener más información sobre el parámetro SNAPSHOT para ALTER DATABASE, consulte [Parameters](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters). ## ERROR:1018 DETAIL: Relation does not exist Cuando ejecuta operaciones simultáneas de Amazon Redshift en sesiones diferentes, se muestra un mensaje de error como el siguiente. ``` ERROR: 1018 DETAIL: Relation does not exist. ``` Las transacciones en Amazon Redshift utilizan el aislamiento de la instantánea. Una vez que se inicia una transacción, Amazon Redshift toma una instantánea de la base de datos. En todo el ciclo de vida de la transacción, la transacción realiza las operaciones en el estado de la base de datos como se refleja en la instantánea. Si la transacción realiza la lectura desde una tabla que no existe en la instantánea, arroja el mensaje de error 1018 mostrado anteriormente. Incluso cuando otra transacción simultánea crea una tabla después de que la transacción haya tomado la instantánea, la transacción no puede realizar la lectura desde la tabla recién creada. Para solucionar este error de serialización del aislamiento, puede intentar cambiar el inicio de la transacción a un punto en el que sepa que existe la tabla. Si otra transacción crea la tabla, este punto será después de que se haya confirmado la transacción. Además, asegúrese de que no se haya confirmado ninguna transacción simultánea que pueda haber eliminado la tabla. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session2 = # BEGIN; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # SELECT * FROM A; ``` La última operación que ejecuta session2 como la operación de lectura da lugar a un error de aislamiento serializable. Este error ocurre cuando session2 toma una instantánea y la tabla ya ha sido eliminada por una session1 confirmada. En otras palabras, aunque una session3 simultánea haya creado la tabla, la session2 no ve la tabla porque no está en la instantánea. Para resolver este error, puede reordenar las sesiones de la siguiente manera. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # BEGIN; session2 = # SELECT * FROM A; ``` Cuando session2 toma su instantánea, session3 ya se ha confirmado y la tabla está en la base de datos. La session2 puede leer desde la tabla sin ningún error. # Tutorial: Carga de datos desde Amazon S3 En este tutorial, siga el proceso de creación de datos en las tablas de bases de datos de Amazon Redshift desde archivos de datos en un bucket de Amazon S3 de principio a fin. En este tutorial, aprenderá a hacer lo siguiente: + Descargar archivos de datos que utilicen formatos de ancho fijo, con caracteres delimitados y de valores separados por comas (CSV). + crear un bucket de Amazon S3 y, luego, cargar los archivos de datos en él + lanzar un clúster de Amazon Redshift y crear tablas de base de datos + usar los comandos COPY para cargar las tablas desde los archivos de datos en Amazon S3 + Solucionar errores de carga y modificar los comandos COPY para corregir los errores. ## Requisitos previos Necesita los siguientes requisitos previos: + Una cuenta de AWS para lanzar un clúster de Amazon Redshift y crear un bucket en Amazon S3. + Sus credenciales de AWS (rol de IAM) para cargar datos de prueba de Amazon S3. Si necesita un nuevo rol de IAM, diríjase a [Creación de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html). + Un cliente SQL como el editor de consultas de la consola de Amazon Redshift. Este tutorial está diseñado para que pueda realizarlo por sí mismo. Además de este tutorial, recomendamos completar los siguientes tutoriales para obtener un conocimiento más completo sobre cómo diseñar y utilizar las bases de datos de Amazon Redshift: + En la [Guía de introducción a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/), se detalla el proceso de la creación de un clúster de Amazon Redshift y de la carga de datos de muestra. ## Descripción general Puede agregar datos a las tablas de Amazon Redshift mediante el uso de un comando INSERT o uno COPY. En la escala y la velocidad de un almacenamiento de datos de Amazon Redshift, el comando COPY es muchas veces más rápido y eficiente que los comandos INSERT. El comando COPY utiliza la arquitectura de procesamiento masivo en paralelo (MPP) de Amazon Redshift para leer y cargar datos en paralelo desde varios orígenes de datos. Puede cargar datos desde archivos de datos en Amazon S3, Amazon EMR o cualquier alojamiento remoto que sea accesible a través de una conexión Secure Shell (SSH). También puede cargarlos directamente desde una tabla de Amazon DynamoDB. En este tutorial, se utiliza el comando COPY para cargar datos desde Amazon S3. Muchos de los principios presentados aquí también aplican para la carga desde otros orígenes de datos. Para obtener más información acerca del uso del comando COPY, consulte los siguientes recursos: + [Prácticas recomendadas de Amazon Redshift para la carga de datos](c_loading-data-best-practices.md) + [Carga de datos desde Amazon EMR](loading-data-from-emr.md) + [Carga de datos desde hosts remotos](loading-data-from-remote-hosts.md) + [Carga de datos desde una tabla de Amazon DynamoDB](t_Loading-data-from-dynamodb.md) ## Paso 1: creación de un clúster Puede omitir este paso si ya dispone del clúster que desea utilizar. Para los ejercicios de este tutorial, use un clúster de cuatro nodos. **Pasos para crear un clúster** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). En el menú de navegación, elija **Panel de clústeres aprovisionados**. **importante** Asegúrese de que el usuario cuente con los permisos necesarios para realizar las operaciones del clúster. Para obtener información sobre la concesión de los permisos necesarios, consulte [Autorización a Amazon Redshift para obtener acceso a los servicios de AWS](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html). 1. En la parte superior derecha, seleccione la región de AWS en la que quiera crear el clúster. Para realizar este tutorial, elija **EE. UU. Oeste (Oregón)**. 1. En el menú de navegación, elija **Clusters** (Clústeres) y, a continuación, elija **Create cluster** (Crear clúster). Se abrirá la página **Create cluster (Crear clúster)**. 1. En la página **Create cluster** (Crear un clúster), ingrese los parámetros para su clúster. Elija sus propios valores para los parámetros, excepto cambiar los siguientes valores: + Elija **dc2.large** para el tipo de nodo. + Elija **4** para la opción **Number of nodes** (Número de nodos). + En la sección **Cluster permissions (Permisos del clúster)**, seleccione un rol de IAM de los **Available IAM roles (Roles de IAM disponibles)**. Este rol debería ser uno que haya creado previamente y que tenga acceso a Amazon S3. Luego, elija **Associate IAM role** (Asociar un rol de IAM) para agregarlo a la lista de **Associated IAM roles** (Roles de IAM asociados) del clúster. 1. Elija **Create cluster**. Siga los pasos de la [Guía de introducción a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/) para conectarse al clúster desde un cliente SQL y probar una conexión. No necesita completar los pasos de introducción restantes para crear tablas, cargar datos y probar consultas de ejemplo. ## Paso 2: Descargar los archivos de datos En este paso, se descarga un conjunto de archivos de datos de muestra en su equipo. En el paso siguiente, se cargan los archivos a un bucket de Amazon S3. **Descarga de los archivos de datos** 1. Descargue el archivo comprimido: [LoadingDataSampleFiles.zip](samples/LoadingDataSampleFiles.zip). 1. Extraiga los archivos en una carpeta de su equipo. 1. Verifique que la carpeta contiene los siguientes archivos. ``` customer-fw-manifest customer-fw.tbl-000 customer-fw.tbl-000.bak customer-fw.tbl-001 customer-fw.tbl-002 customer-fw.tbl-003 customer-fw.tbl-004 customer-fw.tbl-005 customer-fw.tbl-006 customer-fw.tbl-007 customer-fw.tbl.log dwdate-tab.tbl-000 dwdate-tab.tbl-001 dwdate-tab.tbl-002 dwdate-tab.tbl-003 dwdate-tab.tbl-004 dwdate-tab.tbl-005 dwdate-tab.tbl-006 dwdate-tab.tbl-007 part-csv.tbl-000 part-csv.tbl-001 part-csv.tbl-002 part-csv.tbl-003 part-csv.tbl-004 part-csv.tbl-005 part-csv.tbl-006 part-csv.tbl-007 ``` ## Paso 3: Cargar los archivos en un bucket de Amazon S3 En este paso, cree un bucket de Amazon S3 y cargue los archivos de datos en él. ### **Para cargar los archivos en un bucket de Amazon S3** 1. Cree un bucket de Amazon S3. Para obtener más información acerca de la creación de un bucket, consulte [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) en la *Guía del usuario de Amazon Simple Storage Service*. 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Elija **Crear bucket**. 1. Elija un valor para Región de AWS. Cree el bucket en la misma región del clúster. Si el clúster se encuentra en la región Oeste de EE. UU. (Oregón), elija **US West (Oregon) Region (us-west-2)** (Región Oeste de EE. UU. [Oregón] [us-west-2]). 1. En el cuadro **Nombre del bucket** del cuadro de diálogo **Crear bucket**, escriba el nombre del bucket. El nombre de bucket que elija debe ser único entre todos los nombres de buckets existentes en Amazon S3. Una forma de garantizar su unicidad es agregar el nombre de su organización delante del nombre del bucket. Los nombres de los buckets deben cumplir una serie de reglas. Para obtener más información, consulte [Restricciones y limitaciones de buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) en la *Guía del usuario de Amazon Simple Storage Service*. 1. Elija los valores predeterminados recomendados para el resto de las opciones. 1. Elija **Crear bucket**. Cuando Amazon S3 cree con éxito el bucket, la consola mostrará el bucket vacío en el panel **Buckets**. 1. Crear una carpeta. 1. Seleccione el nombre del nuevo bucket. 1. Elija el botón **Crear carpeta**. 1. Asigne un nombre para la nueva carpeta **load**. **nota** El bucket que ha creado no se encuentra en un entorno de pruebas. En este ejercicio, se agregan objetos a un bucket real. Se le cobra una cantidad nominal según el tiempo durante el cuál almacena los objetos en el bucket. Para obtener más información acerca de los precios de Amazon S3, visite la página [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/). 1. Cargue los archivos de datos en el bucket de Amazon S3 nuevo. 1. Elija el nombre de la carpeta de datos. 1. En el asistente Cargar, elija **Agregar archivos**. Siga las instrucciones de la consola de Amazon S3 para cargar todos los archivos que descargó y extrajo, 1. Seleccione **Cargar**. **de usuario autentic.** El comando COPY de Amazon Redshift debe tener acceso para leer los objetos de los archivos del bucket de Amazon S3. Si utiliza las mismas credenciales de usuario para crear el bucket de Amazon S3 y ejecutar el comando COPY de Amazon Redshift, el comando COPY tiene todos los permisos necesarios. Si desea utilizar credenciales de usuario diferentes, puede conceder acceso mediante los controles de acceso de Amazon S3. El comando COPY de Amazon Redshift requiere como mínimo los permisos de ListBucket y GetObject para obtener acceso a los objetos de los archivos del bucket de Amazon S3. Para obtener más información acerca del control del acceso a los recursos de Amazon S3, visite [Administración de permisos de acceso para los recursos de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). ## Paso 4: Crear las tablas de muestra En este tutorial, se utiliza un conjunto de tablas basadas en el esquema de Star Schema Benchmark (SSB). En el siguiente diagrama se muestra el modelo de datos en SSB. ![\[Las cinco tablas del esquema SSB y sus relaciones entre sí.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/tutorial-optimize-tables-ssb-data-model.png) Puede que las tablas de SSB ya existan en la base de datos actual. Si es el caso, deberá eliminarlas para quitarlas de la base de datos antes de crearlas con los comandos CREATE TABLE en el siguiente paso. Las tablas utilizadas en este tutorial pueden tener atributos diferentes a las tablas existentes. **Creación de las tablas de muestra** 1. Para eliminar las tablas SSB, ejecute los siguientes comandos en su cliente SQL. ``` drop table part cascade; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` 1. Ejecute los siguientes comandos CREATE TABLE en el cliente SQL. ``` CREATE TABLE part ( p_partkey INTEGER NOT NULL, p_name VARCHAR(22) NOT NULL, p_mfgr VARCHAR(6), p_category VARCHAR(7) NOT NULL, p_brand1 VARCHAR(9) NOT NULL, p_color VARCHAR(11) NOT NULL, p_type VARCHAR(25) NOT NULL, p_size INTEGER NOT NULL, p_container VARCHAR(10) NOT NULL ); CREATE TABLE supplier ( s_suppkey INTEGER NOT NULL, s_name VARCHAR(25) NOT NULL, s_address VARCHAR(25) NOT NULL, s_city VARCHAR(10) NOT NULL, s_nation VARCHAR(15) NOT NULL, s_region VARCHAR(12) NOT NULL, s_phone VARCHAR(15) NOT NULL ); CREATE TABLE customer ( c_custkey INTEGER NOT NULL, c_name VARCHAR(25) NOT NULL, c_address VARCHAR(25) NOT NULL, c_city VARCHAR(10) NOT NULL, c_nation VARCHAR(15) NOT NULL, c_region VARCHAR(12) NOT NULL, c_phone VARCHAR(15) NOT NULL, c_mktsegment VARCHAR(10) NOT NULL ); CREATE TABLE dwdate ( d_datekey INTEGER NOT NULL, d_date VARCHAR(19) NOT NULL, d_dayofweek VARCHAR(10) NOT NULL, d_month VARCHAR(10) NOT NULL, d_year INTEGER NOT NULL, d_yearmonthnum INTEGER NOT NULL, d_yearmonth VARCHAR(8) NOT NULL, d_daynuminweek INTEGER NOT NULL, d_daynuminmonth INTEGER NOT NULL, d_daynuminyear INTEGER NOT NULL, d_monthnuminyear INTEGER NOT NULL, d_weeknuminyear INTEGER NOT NULL, d_sellingseason VARCHAR(13) NOT NULL, d_lastdayinweekfl VARCHAR(1) NOT NULL, d_lastdayinmonthfl VARCHAR(1) NOT NULL, d_holidayfl VARCHAR(1) NOT NULL, d_weekdayfl VARCHAR(1) NOT NULL ); CREATE TABLE lineorder ( lo_orderkey INTEGER NOT NULL, lo_linenumber INTEGER NOT NULL, lo_custkey INTEGER NOT NULL, lo_partkey INTEGER NOT NULL, lo_suppkey INTEGER NOT NULL, lo_orderdate INTEGER NOT NULL, lo_orderpriority VARCHAR(15) NOT NULL, lo_shippriority VARCHAR(1) NOT NULL, lo_quantity INTEGER NOT NULL, lo_extendedprice INTEGER NOT NULL, lo_ordertotalprice INTEGER NOT NULL, lo_discount INTEGER NOT NULL, lo_revenue INTEGER NOT NULL, lo_supplycost INTEGER NOT NULL, lo_tax INTEGER NOT NULL, lo_commitdate INTEGER NOT NULL, lo_shipmode VARCHAR(10) NOT NULL ); ``` ## Paso 5: Ejecutar los comandos COPY Ejecute los comandos COPY para cargar cada una de las tablas en el esquema SSB. Los ejemplos del comando COPY muestran cómo cargar desde diferentes formatos de archivo, utilizar varias opciones de comando COPY y solucionar los errores de carga. ### Sintaxis del comando COPY La sintaxis básica del comando [COPY](r_COPY.md) es la siguiente. ``` COPY table_name [ column_list ] FROM data_source CREDENTIALS access_credentials [options] ``` Para ejecutar un comando COPY, proporcione los siguientes valores. **Nombre de la tabla** La tabla de destino para el comando COPY. La tabla ya debe existir en la base de datos. La tabla puede ser temporal o persistente. El comando COPY adjunta los nuevos datos de entrada a cualquier fila existente en la tabla. **Lista de columnas** De forma predeterminada, COPY carga los campos desde los datos de origen a las columnas de la tabla en orden. Si lo desea, también puede especificar una *lista de columnas*, que es una lista de nombres de columnas separadas por una coma, para asignar los campos de datos a columnas específicas. No utiliza listas de columnas en este tutorial. Para obtener más información, consulte [Column List](copy-parameters-column-mapping.md#copy-column-list) en COPY command reference. Origen de datos Puede utilizar el comando COPY para cargar datos desde un bucket de Amazon S3, un clúster de Amazon EMR, un alojamiento remoto que utilice una conexión SSH o una tabla de Amazon DynamoDB. Para este tutorial, realice la carga a partir de archivos de datos en un bucket de Amazon S3. Cuando realice cargas desde Amazon S3, debe proporcionar el nombre del bucket y la ubicación de los archivos de datos. Para ello, proporcione o bien una ruta de objecto para los archivos de datos o bien la ubicación de un archivo de manifiesto que enumere explícitamente cada archivo de datos y su ubicación. + Prefijo de clave Un objeto almacenado en Amazon S3 se identifica de manera única por una clave de objeto, que incluye el nombre del bucket, de las carpetas, si hay alguna, y de los objetos. El *prefijo de clave* hace referencia a un conjunto de objetos con el mismo prefijo. La ruta de objeto es un prefijo de clave que el comando COPY utiliza para cargar todos los objetos que comparten el prefijo de clave. Por ejemplo, el prefijo de clave `custdata.txt` puede referirse a un archivo individual o a un conjunto de archivos, incluidos `custdata.txt.001`, `custdata.txt.002` y así sucesivamente. + Archivo de manifiesto En algunos casos, es posible que necesite cargar archivos con diferentes prefijos; por ejemplo, de múltiples buckets o carpetas. En otros, puede que necesite excluir archivos con un mismo prefijo. En estos casos, puede utilizar un archivo de manifiesto. El *archivo de manifiesto* muestra explícitamente cada archivo de carga y su clave de objeto única. Se utiliza un archivo de manifiesto para cargar la tabla PART más adelante en este tutorial. **Credenciales** Para obtener acceso a los recursos de AWS que contienen los datos que se van a cargar, debe proporcionar las credenciales de acceso de AWS de un usuario con privilegios suficientes. Estas credenciales incluyen el Nombre de recurso de Amazon (ARN) de un rol de IAM. Para cargar datos desde Amazon S3, las credenciales deben incluir los permisos de ListBucket y GetObject. Se requerirán credenciales adicionales si los datos están cifrados. Para obtener más información, consulte [Parámetros de autorización](copy-parameters-authorization.md) en COPY command reference. Para obtener más información acerca de la administración del acceso, visite [Administración de permisos de acceso a los recursos de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html). Opciones Puede especificar un número de parámetros con el comando COPY para especificar los formatos de archivo, administrar los formatos de datos, administrar errores y controlar otras características. En este tutorial, utilice las siguientes opciones y características del comando COPY: + Prefijo de clave Para obtener información sobre cómo cargar desde varios archivos especificando un prefijo de clave, consulte [Carga de tabla PART con NULL AS](#tutorial-loading-load-part). + formato CSV Para obtener información sobre cómo cargar datos en formato CSV, consulte [Carga de tabla PART con NULL AS](#tutorial-loading-load-part). + NULL AS Para obtener información sobre cómo cargar PART mediante la opción NULL AS, consulte [Carga de tabla PART con NULL AS](#tutorial-loading-load-part). + Formato delimitado por caracteres Para obtener información sobre cómo utilizar la opción DELIMITER, consulte [Las opciones DELIMITER y REGION](#tutorial-loading-load-supplier). + REGION Para obtener información sobre cómo utilizar la opción REGION, consulte [Las opciones DELIMITER y REGION](#tutorial-loading-load-supplier). + Ancho de formato fijo Para obtener información sobre cómo cargar la tabla CUSTOMER a partir de datos de ancho fijo, consulte [Carga de tabla CUSTOMER con MANIFEST](#tutorial-loading-load-customer). + MAXERROR Para obtener información sobre cómo utilizar la opción MAXERROR, consulte [Carga de tabla CUSTOMER con MANIFEST](#tutorial-loading-load-customer). + ACCEPTINVCHARS Para obtener información sobre cómo utilizar la opción ACCEPTINVCHARS, consulte [Carga de tabla CUSTOMER con MANIFEST](#tutorial-loading-load-customer). + MANIFEST Para obtener información sobre cómo utilizar la opción MANIFEST, consulte [Carga de tabla CUSTOMER con MANIFEST](#tutorial-loading-load-customer). + DATEFORMAT Para obtener información sobre cómo utilizar la opción DATEFORMAT, consulte [Carga de la tabla DWDATE con DATEFORMAT](#tutorial-loading-load-dwdate). + GZIP, LZOP y BZIP2 Para obtener información sobre cómo comprimir los archivos, consulte [Carga de varios archivos de datos](#tutorial-loading-load-lineorder). + COMPUPDATE Para obtener información sobre cómo utilizar la opción COMPUPDATE, consulte [Carga de varios archivos de datos](#tutorial-loading-load-lineorder). + Múltiples archivos Para obtener información sobre cómo cargar varios archivos, consulte [Carga de varios archivos de datos](#tutorial-loading-load-lineorder). ### Carga de las tablas SSB Utilice los siguientes comandos COPY para cargar cada una de las tablas en el esquema SSB. El comando de cada tabla muestra diferentes técnicas de solución de problemas y opciones de COPY. Siga estos pasos para cargar las tablas SSB: 1. [Sustituya el nombre del bucket y las credenciales de AWS.](#tutorial-loading-run-copy-replaceables) 1. [Carga de tabla PART con NULL AS](#tutorial-loading-load-part) 1. [Carga de tabla CUSTOMER con MANIFEST](#tutorial-loading-load-customer) 1. [Carga de la tabla DWDATE con DATEFORMAT](#tutorial-loading-load-dwdate) #### Sustituya el nombre del bucket y las credenciales de AWS. En este tutorial, los comandos COPY se presentan en el siguiente formato. ``` copy table from 's3:///load/key_prefix' credentials 'aws_iam_role=arn:aws:iam:::role/' options; ``` Para cada comando COPY, haga lo siguiente: 1. Sustituya ** por el nombre de un bucket de la misma región que el clúster. En este paso se asume que el bucket y el clúster están en la misma región. También puede especificar la región utilizando la opción [REGION](copy-parameters-data-source-s3.md#copy-region) con el comando COPY. 1. Reemplace ** y ** por Cuenta de AWS y con el rol de IAM. El segmento de la cadena de credenciales que está delimitado entre comillas simples no debe contener espacios ni saltos de línea. Tenga en cuenta que el formato del ARN puede diferir ligeramente del de la muestra. Es mejor copiar el ARN del rol desde la consola de IAM para asegurarse de que es correcto cuando ejecute los comandos COPY. #### Carga de tabla PART con NULL AS En este paso, utilice las opciones CSV y NULL AS para cargar la tabla PART. El comando COPY puede cargar datos desde varios archivos en paralelo, lo que es mucho más rápido que cargar desde un archivo individual. Para demostrar este principio, los datos de cada tabla en este tutorial se dividen en ocho archivos, aunque los archivos sean muy pequeños. En un paso posterior, se compara la diferencia de tiempo entre cargar desde un archivo individual y cargar desde varios archivos. Para obtener más información, consulte [Dividir los datos de carga](c_best-practices-use-multiple-files.md). **Prefijo de clave** Puede cargar desde varios archivos especificando un prefijo de clave para el conjunto de archivos o enumerando explícitamente los archivos en un archivo de manifiesto. En este paso, se utiliza un prefijo de clave. En un paso posterior, se utiliza un archivo de manifiesto. El prefijo de clave `'s3://amzn-s3-demo-bucket/load/part-csv.tbl'` carga el siguiente conjunto de los archivos en la carpeta `load`. ``` part-csv.tbl-000 part-csv.tbl-001 part-csv.tbl-002 part-csv.tbl-003 part-csv.tbl-004 part-csv.tbl-005 part-csv.tbl-006 part-csv.tbl-007 ``` **formato CSV** CSV, que significa valores separados por comas, es un formato común utilizado para importar y exportar datos de hojas de cálculo. CSV es más flexible que el formato delimitado por comas porque le permite incluir cadenas entre comillas dentro de los campos. El carácter de comilla predeterminado para COPY desde un formato CSV es una comilla recta doble ( " ), pero puede especificar otro con la opción QUOTE AS. Cuando utilice el carácter de comilla dentro del campo, encierre el carácter con otro carácter de comilla. El siguiente fragmento de una archivo de datos con formato CSV para la tabla PART muestra cadenas encerradas entre comillas dobles (`"LARGE ANODIZED BRASS"`). También muestra un string comprendido entre dos comillas dobles dentro de un string encomillado (`"MEDIUM ""BURNISHED"" TIN"`). ``` 15,dark sky,MFGR#3,MFGR#47,MFGR#3438,indigo,"LARGE ANODIZED BRASS",45,LG CASE 22,floral beige,MFGR#4,MFGR#44,MFGR#4421,medium,"PROMO, POLISHED BRASS",19,LG DRUM 23,bisque slate,MFGR#4,MFGR#41,MFGR#4137,firebrick,"MEDIUM ""BURNISHED"" TIN",42,JUMBO JAR ``` Los datos de la tabla PART contienen caracteres que pueden provocar que COPY falle. En este ejercicio, se identifican los errores y se corrigen. Para cargar datos que estén en formato CSV, agregue `csv` al comando COPY. Ejecute el siguiente comando para cargar la tabla PART. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv; ``` Podría obtener un mensaje de error similar al siguiente. ``` An error occurred when executing the SQL command: copy part from 's3://amzn-s3-demo-bucket/load/part-csv.tbl' credentials' ... ERROR: Load into table 'part' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000] Execution time: 1.46s 1 statement(s) failed. 1 statement(s) failed. ``` Para obtener más información acerca del error, consulte la tabla STL\$1LOAD\$1ERRORS. La siguiente consulta utiliza la función SUBSTRING para acortar columnas y facilitar su legibilidad y utiliza LIMIT 10 para reducir el número de filas que se devuelven. Puede ajustar los valores en `substring(filename,22,25)` para permitir la longitud del nombre de bucket. ``` select query, substring(filename,22,25) as filename,line_number as line, substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text, substring(raw_field_value,0,15) as field_text, substring(err_reason,0,45) as reason from stl_load_errors order by query desc limit 10; ``` ``` query | filename | line | column | type | pos | --------+-------------------------+-----------+------------+------------+-----+---- 333765 | part-csv.tbl-000 | 1 | | | 0 | line_text | field_text | reason ------------------+------------+---------------------------------------------- 15,NUL next, | | Missing newline: Unexpected character 0x2c f ``` **NULL AS** Los archivos de datos `part-csv.tbl` utilizan el carácter de terminación NUL (`\x000` o `\x0`) para indicar los valores NULL. **nota** A pesar de tener nombres muy similares, NUL y NULL no son lo mismo. NUL es un carácter UTF-8 con punto de código `x000` que suele utilizarse para indicar el fin de registro (EOR). NULL es un valor SQL que representa una ausencia de datos. De manera predeterminada COPY trata el carácter de terminación NUL como un carácter EOR y termina el registro, lo que suele ocasionar resultados inesperados o un error. No hay un método estándar único para indicar NULL en datos de texto. Por lo tanto, la opción de comando NULL AS COPY le permite especificar qué carácter sustituir por NULL cuando carga la tabla. En este ejemplo, desea que COPY trate el carácter de terminación NUL como un valor NULL. **nota** La columna de la tabla que recibe el valor NULL debe estar configurada como *nullable*. Es decir, no debe incluir la restricción NOT NULL en la especificación CREATE TABLE. Para cargar PART por medio de la opción NULL AS, ejecute el siguiente comando COPY. ``` copy part from 's3:///load/part-csv.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' csv null as '\000'; ``` Para verificar que COPY cargó los valores NULL, ejecute el siguiente comando para seleccionar solo las filas que contienen NULL. ``` select p_partkey, p_name, p_mfgr, p_category from part where p_mfgr is null; ``` ``` p_partkey | p_name | p_mfgr | p_category -----------+----------+--------+------------ 15 | NUL next | | MFGR#47 81 | NUL next | | MFGR#23 133 | NUL next | | MFGR#44 (2 rows) ``` #### Las opciones DELIMITER y REGION Las opciones DELIMITER y REGION son importantes para entender cómo se cargan los datos. **Formato delimitado por caracteres** Los campos en un archivo delimitado por caracteres están separados por un carácter específico, como un carácter de barra vertical ( \$1 ), una coma ( , ) o una pestaña ( \$1t ). Los archivos delimitados por caracteres pueden utilizar cualquier carácter único ASCII, incluido uno de los caracteres ASCII no imprimibles, como el delimitador. El carácter delimitador se especifica mediante la opción DELIMITER. El delimitador predeterminado es el carácter de barra vertical ( \$1 ). El siguiente fragmento de los datos para la tabla SUPPLIER utiliza el formato delimitado por la barra vertical. ``` 1|1|257368|465569|41365|19950218|2-HIGH|0|17|2608718|9783671|4|2504369|92072|2|19950331|TRUCK 1|2|257368|201928|8146|19950218|2-HIGH|0|36|6587676|9783671|9|5994785|109794|6|19950416|MAIL ``` **REGION** Siempre que sea posible, debe ubicar los datos de carga en la misma región de AWS que el clúster de Amazon Redshift. Si los datos y el clúster se encuentran en la misma región, se reduce la latencia y se evitan los costos de la transferencia de datos entre regiones. Para obtener más información, consulte [Prácticas recomendadas de Amazon Redshift para la carga de datos](c_loading-data-best-practices.md). Si debe cargar datos de una región de AWS diferente, utilice la opción REGION para especificar la región de AWS en la que se ubican los datos de carga. Si especifica una región, todos los datos de carga, incluidos los archivos de manifiesto, deben encontrarse en la región mencionada. Para obtener más información, consulte [REGION](copy-parameters-data-source-s3.md#copy-region). Por ejemplo, si el clúster se encuentra en la región Este de EE. UU. (Norte de Virginia) y su bucket de Amazon S3 se encuentra en la región Oeste de EE. UU. (Oregón), el siguiente comando COPY muestra cómo cargar la tabla SUPPLIER a partir de datos delimitados por la barra vertical. ``` copy supplier from 's3://amzn-s3-demo-bucket/ssb/supplier.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' delimiter '|' gzip region 'us-west-2'; ``` #### Carga de tabla CUSTOMER con MANIFEST En este paso, se utilizan las opciones FIXEDWIDTH, MAXERROR, ACCEPTINVCHARS Y MANIFEST para cargar la tabla CUSTOMER. Los datos de muestra para este ejercicio contienen caracteres que provocan errores cuando COPY trata de cargarlos. Utilice la opción MAXERRORS y la tabla de sistema STL\$1LOAD\$1ERRORS para solucionar los errores de carga y luego utilice las opciones ACCEPTINVCHARS y MANIFEST para eliminar los errores. **Formato de ancho fijo** El formato de ancho fijo define cada campo como un número fijo de caracteres, en lugar de separar los campos con un delimitador. El siguiente fragmento de los datos para la tabla CUSTOMER utiliza el formato de ancho fijo. ``` 1 Customer#000000001 IVhzIApeRb MOROCCO 0MOROCCO AFRICA 25-705 2 Customer#000000002 XSTf4,NCwDVaWNe6tE JORDAN 6JORDAN MIDDLE EAST 23-453 3 Customer#000000003 MG9kdTD ARGENTINA5ARGENTINAAMERICA 11-783 ``` El orden de los pares etiqueta/ancho debe coincidir con el orden de las columnas de la tabla de forma exacta. Para obtener más información, consulte [FIXEDWIDTH](copy-parameters-data-format.md#copy-fixedwidth). La cadena de especificaciones de ancho fijo para la tabla CUSTOMER es la siguiente. ``` fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' ``` Para cargar la tabla CUSTOMER desde los datos de ancho fijo, ejecute el siguiente comando. ``` copy customer from 's3:///load/customer-fw.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10'; ``` Debería obtener un mensaje de error, similar al siguiente. ``` An error occurred when executing the SQL command: copy customer from 's3://amzn-s3-demo-bucket/load/customer-fw.tbl' credentials'... ERROR: Load into table 'customer' failed. Check 'stl_load_errors' system table for details. [SQL State=XX000] Execution time: 2.95s 1 statement(s) failed. ``` **MAXERROR** De forma predeterminada, la primera vez que COPY encuentra un error, el comando falla y devuelve un mensaje de error. Para ahorrar tiempo durante las pruebas, puede utilizar la opción MAXERROR para indicar a COPY que omita un número específico de errores antes de fallar. Dado que se esperan errores la primera vez que se prueba la carga de los datos de la tabla CUSTOMER, agregue `maxerror 10` al comando COPY. Para realizar la prueba utilizando las opciones FIXEDWIDTH y MAXERROR, ejecute el siguiente comando. ``` copy customer from 's3:///load/customer-fw.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' maxerror 10; ``` Esta vez, en lugar de un mensaje de error, obtendrá un mensaje de advertencia, similar al siguiente. ``` Warnings: Load into table 'customer' completed, 112497 record(s) loaded successfully. Load into table 'customer' completed, 7 record(s) could not be loaded. Check 'stl_load_errors' system table for details. ``` La advertencia indica que COPY encontró siete errores. Para comprobar los errores, consulte la tabla STL\$1LOAD\$1ERRORS, como se muestra en el siguiente ejemplo. ``` select query, substring(filename,22,25) as filename,line_number as line, substring(colname,0,12) as column, type, position as pos, substring(raw_line,0,30) as line_text, substring(raw_field_value,0,15) as field_text, substring(err_reason,0,45) as error_reason from stl_load_errors order by query desc, filename limit 7; ``` Los resultados de la consulta a STL\$1LOAD\$1ERRORS deben ser similares a los siguientes. ``` query | filename | line | column | type | pos | line_text | field_text | error_reason --------+---------------------------+------+-----------+------------+-----+-------------------------------+------------+---------------------------------------------- 334489 | customer-fw.tbl.log | 2 | c_custkey | int4 | -1 | customer-fw.tbl | customer-f | Invalid digit, Value 'c', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 6 | c_custkey | int4 | -1 | Complete | Complete | Invalid digit, Value 'C', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 3 | c_custkey | int4 | -1 | #Total rows | #Total row | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 5 | c_custkey | int4 | -1 | #Status | #Status | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl.log | 1 | c_custkey | int4 | -1 | #Load file | #Load file | Invalid digit, Value '#', Pos 0, Type: Integ 334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8 334489 | customer-fw.tbl000 | 1 | c_address | varchar | 34 | 1 Customer#000000001 | .Mayag.ezR | String contains invalid or unsupported UTF8 (7 rows) ``` Al examinar los resultados, podrá ver que hay dos mensajes en la columna `error_reasons`: + ``` Invalid digit, Value '#', Pos 0, Type: Integ ``` El archivo `customer-fw.tbl.log` provoca estos errores. El problema es que este es un archivo de registro, no de datos, y no debe cargarse. Puede utilizar el archivo de manifiesto para evitar la carga del archivo incorrecto. + ``` String contains invalid or unsupported UTF8 ``` El tipo de datos VARCHAR es compatible con caracteres multibyte UTF-8 de hasta tres bytes. Si los datos de carga contienen caracteres no válidos o no compatibles, puede utilizar la opción ACCEPTINVCHARS para reemplazar cada carácter no válido por un carácter alternativo especificado. Otro problema con la carga que es más difícil de detectar es cuando la carga produjo resultados inesperados. Para investigar este problema, ejecute el siguiente comando para consultar la tabla CUSTOMER. ``` select c_custkey, c_name, c_address from customer order by c_custkey limit 10; ``` ``` c_custkey | c_name | c_address -----------+---------------------------+--------------------------- 2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE 2 | Customer#000000002 | XSTf4,NCwDVaWNe6tE 3 | Customer#000000003 | MG9kdTD 3 | Customer#000000003 | MG9kdTD 4 | Customer#000000004 | XxVSJsL 4 | Customer#000000004 | XxVSJsL 5 | Customer#000000005 | KvpyuHCplrB84WgAi 5 | Customer#000000005 | KvpyuHCplrB84WgAi 6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx 6 | Customer#000000006 | sKZz0CsnMD7mp4Xd0YrBvx (10 rows) ``` Las filas deben ser únicas, pero están duplicadas. Otra forma de comprobar los resultados inesperados es verificar el número de filas que se cargaron. En nuestro caso, deberían haberse cargado 100 000 filas, pero el mensaje de carga notificó que se cargaron 112 497 registros. Las filas adicionales se cargaron porque COPY cargo un archivo extraño, `customer-fw.tbl0000.bak`. En este ejercicio, se utiliza un archivo de manifiesto para evitar la carga de los archivos incorrectos. **ACCEPTINVCHARS** De forma predeterminada, cuando COPY encuentra un carácter que no es compatible con los tipos de datos de la columna, omite la fila y devuelve un error. Para obtener más información acerca de los caracteres UTF-8 no válidos, consulte [Errores de carga de caracteres multibyte](multi-byte-character-load-errors.md). Puede utilizar la opción MAXERRORS para ignorar los errores y continuar la carga, luego consulte STL\$1LOAD\$1ERRORS para ubicar los caracteres no válidos y después corrija los archivos de datos. No obstante, MAXERRORS es más adecuado para solucionar problemas de carga y en general no debe utilizarse en un entorno de producción. La opción ACCEPTINVCHARS suele ser una mejor elección para administrar caracteres no válidos. ACCEPTINVCHARS le indica a COPY reemplazar cada carácter no válido por un carácter válido especificado y continuar con la operación de carga. Puede especificar cualquier carácter ASCII válido, excepto NULL, como el carácter de sustitución. El carácter de sustitución predeterminado es un signo de interrogación (?). COPY reemplaza los caracteres multibyte con una cadena de sustitución de igual longitud. Por ejemplo, un carácter de 4 bytes se reemplazaría con `'????'`. COPY devuelve el número de filas que contenían caracteres UTF-8 no válidos. Además agrega una entrada a la tabla de sistema STL\$1REPLACEMENTS para cada fila afectada, hasta un máximo de 100 filas por sector del nodo. También se sustituyen los caracteres UTF-8 no válidos adicionales, pero esos eventos de sustitución no se registran. ACCEPTINVCHARS es válido solo para las columnas VARCHAR. En este paso, se agrega el ACCEPTINVCHARS con el carácter de reemplazo `'^'`. **MANIFEST** Cuando utiliza el comando COPY desde Amazon S3 mediante un prefijo de clave, existe el riesgo de cargar tablas no deseadas. Por ejemplo, la carpeta `'s3://amzn-s3-demo-bucket/load/` contiene ocho archivos de datos que comparten el prefijo de clave `customer-fw.tbl`, `customer-fw.tbl0000`, `customer-fw.tbl0001` y así sucesivamente. No obstante, la misma carpeta también contiene los archivos extraños `customer-fw.tbl.log` y `customer-fw.tbl-0001.bak`. Para garantizar que carga todos los archivos correctos, y únicamente los archivos correctos, utilice un archivo de manifiesto. El manifiesto es un archivo de texto en formato JSON que muestra explícitamente la clave de objeto única para cada archivo de origen a cargar. Los objetos de archivos pueden encontrarse en diferentes carpetas o diferentes buckets, pero deben estar en la misma región. Para obtener más información, consulte [MANIFEST](copy-parameters-data-source-s3.md#copy-manifest). A continuación se muestra el texto `customer-fw-manifest`. ``` { "entries": [ {"url":"s3:///load/customer-fw.tbl-000"}, {"url":"s3:///load/customer-fw.tbl-001"}, {"url":"s3:///load/customer-fw.tbl-002"}, {"url":"s3:///load/customer-fw.tbl-003"}, {"url":"s3:///load/customer-fw.tbl-004"}, {"url":"s3:///load/customer-fw.tbl-005"}, {"url":"s3:///load/customer-fw.tbl-006"}, {"url":"s3:///load/customer-fw.tbl-007"} ] } ``` **Para cargar los datos para la tabla CUSTOMER utilizando un archivo de manifiesto** 1. Abra el archivo `customer-fw-manifest` en un editor de texto. 1. Sustituya ** por el nombre del bucket. 1. Guarde el archivo. 1. Cargue el archivo a la carpeta de carga en el bucket. 1. Ejecute el siguiente comando COPY. ``` copy customer from 's3:///load/customer-fw-manifest' credentials 'aws_iam_role=arn:aws:iam:::role/' fixedwidth 'c_custkey:10, c_name:25, c_address:25, c_city:10, c_nation:15, c_region :12, c_phone:15,c_mktsegment:10' maxerror 10 acceptinvchars as '^' manifest; ``` #### Carga de la tabla DWDATE con DATEFORMAT En este paso, se utilizan las opciones DELIMITER y DATEFORMAT para cargar la tabla DWDATE . Cuando se cargan las columnas DATE y TIMESTAMP, COPY espera el formato predeterminado, que es AAAA-MM-DD para fechas y AAAA-MM-DD HH:MM:SS para marcas temporales. Si los datos de carga no utilizan un formato predeterminado, puede utilizar DATEFORMAT y TIMEFORMAT para especificar el formato. El siguiente fragmento muestra formatos de fecha en la tabla DWDATE. Observe que los formatos de fecha en la columna dos son inconsistentes. ``` 19920104 1992-01-04 Sunday January 1992 199201 Jan1992 1 4 4 1... 19920112 January 12, 1992 Monday January 1992 199201 Jan1992 2 12 12 1... 19920120 January 20, 1992 Tuesday January 1992 199201 Jan1992 3 20 20 1... ``` **DATEFORMAT** Puede especificar solo un formato de fecha. Si los datos de carga contienen formatos inconsistentes, posiblemente en diferentes columnas, o si en el tiempo de carga no se conoce el formato, utilice DATEFORMAT con el argumento `'auto'`. Cuando se especifica `'auto'`, COPY reconoce cualquier formato válido de fecha u hora y lo convierte al formato predeterminado. La opción `'auto'` reconoce varios formatos que no son compatibles cuando se utiliza una cadena de DATEFORMAT y TIMEFORMAT. Para obtener más información, consulte [Utilización del reconocimiento automático con DATEFORMAT y TIMEFORMAT](automatic-recognition.md). Para cargar la tabla DWDATE, ejecute el siguiente comando COPY. ``` copy dwdate from 's3:///load/dwdate-tab.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' delimiter '\t' dateformat 'auto'; ``` #### Carga de varios archivos de datos Puede usar las opciones GZIP y COMPUPDATE para cargar una tabla. Puede cargar una tabla desde un único archivo de datos o desde varios archivos. Esto le permite comparar los tiempos de carga de ambos métodos. **GZIP, LZOP y BZIP2** Puede comprimir los archivos utilizando los formatos de compresión gzip, lzop o bzip2. Cuando se carga desde archivos comprimidos, COPY descomprime los archivos durante el proceso de carga. La compresión de los archivos ahorra espacio de almacenamiento y reduce los tiempos de carga. **COMPUPDATE** Cuando COPY carga una tabla vacía sin codificaciones de compresión, analiza los datos de carga para determinar las codificaciones óptimas. Luego modifica la tabla para utilizar esas codificaciones antes de comenzar la carga. Este proceso de análisis toma tiempo, pero ocurre una sola vez por tabla, como máximo. Para ahorrar tiempo, puede omitir este paso desactivando COMPUPDATE. Para habilitar una evaluación precisa de los tiempos de COPY, se desactiva COMPUPDATE en este paso. **Múltiples archivos** El comando COPY puede cargar datos desde varios archivos en paralelo de manera muy eficiente, en lugar de desde un archivo individual. Puede dividir los datos en archivos de manera tal que la cantidad de archivos sea múltiplo de la cantidad de sectores en su clúster. Si lo hace, Amazon Redshift divide la carga de trabajo y distribuye los datos de manera uniforme entre los sectores. El número de sectores por nodo depende del tamaño de nodo del clúster. Para obtener más información acerca de la cantidad de sectores que tiene cada tamaño de nodo, consulte [Acerca de clústeres y nodos](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) en la *Guía de administración de Amazon Redshift*. Por ejemplo, los nodos de computación del clúster que se utiliza en este tutorial tienen dos sectores cada uno, por lo que un clúster de cuatro nodos tendrá ocho sectores. En los pasos anteriores, los datos de carga estaban contenidos en ocho archivos, aunque los archivos sean muy pequeños. Puede comparar la diferencia de tiempo entre cargar desde un solo archivo grande y cargar desde varios archivos. Incluso los archivos que contienen 15 millones de registros y ocupan alrededor de 1,2 GB son muy pequeños en la escala de Amazon Redshift, pero son suficientes para demostrar la ventaja de rendimiento que supone cargar desde varios archivos. En la siguiente imagen se muestran los archivos de datos para LINEORDER. ![\[Los datos de la tabla LINEORDER se dividen en nueve archivos.\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/images/tutorial-load-lineorder-files.png) **Para evaluar el rendimiento de COPY con varios archivos** 1. En una prueba de laboratorio, se ejecutó el siguiente comando para realizar la copia desde un único archivo. Este comando muestra un bucket ficticio. ``` copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-single.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' gzip compupdate off region 'us-east-1'; ``` 1. Los resultados fueron los siguientes. Observe el tiempo de ejecución. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 51.56s ``` 1. Luego, se ejecutó el siguiente comando para realizar la copia desde varios archivos. ``` copy lineorder from 's3://amzn-s3-demo-bucket/load/lo/lineorder-multi.tbl' credentials 'aws_iam_role=arn:aws:iam:::role/' gzip compupdate off region 'us-east-1'; ``` 1. Los resultados fueron los siguientes. Observe el tiempo de ejecución. ``` Warnings: Load into table 'lineorder' completed, 14996734 record(s) loaded successfully. 0 row(s) affected. copy executed successfully Execution time: 17.7s ``` 1. Compare los tiempos de ejecución. En nuestro experimento, el tiempo para cargar 15 millones de registros se redujo de 51,56 segundos a 17,7 segundos, lo que supone una disminución del 65,7 %. Estos resultados se basan en la utilización de un clúster de cuatro nodos. Si el clúster tiene más nodos, el ahorro de tiempo se multiplica. Para los clústeres de Amazon Redshift típicos, que tienen de decenas a cientos de nodos, la diferencia es aún más grande. Si tiene un clúster de un nodo, hay una diferencia pequeña entre los tiempos de ejecución. ## Paso 6: Limpiar y analizar la base de datos Siempre que agregue, elimine o modifique una cantidad importante de filas, debe ejecutar un comando VACUUM y luego un comando ANALYZE. Una *limpieza* recupera el espacio de las filas eliminadas y restaura el orden. El comando ANALYZE actualiza los metadatos estadísticos, lo que permite al optimizador de consultas generar planes de consultas más precisos. Para obtener más información, consulte [Limpieza de tablas](t_Reclaiming_storage_space202.md). Si carga los datos en orden de clave de ordenación, la limpieza es rápida. En este tutorial, agregó un número importante de filas, pero lo hizo en tablas vacías. Siendo ese el caso, no hay necesidad de reordenar y no borró ninguna fila. COPY actualiza automáticamente las estadísticas después de cargar una tabla vacía, por lo que las estadísticas deben estar actualizadas. No obstante, por una cuestión de buena organización, se completa este tutorial con la limpieza y el análisis de la base de datos. Para limpiar y analizar la base de datos, ejecute los siguientes comandos. ``` vacuum; analyze; ``` ## Paso 7: Eliminar los recursos El clúster seguirá acumulando cargos mientras esté en ejecución. Una vez que haya completado este tutorial, debe restablecer el entorno al estado anterior si sigue los pasos que se indican en [Paso 5: Revocar el acceso y eliminar el clúster de muestra](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) en la *Guía de introducción a Amazon Redshift*. Si desea mantener el clúster y recuperar el almacenamiento utilizado por las tablas de SSB, ejecute los siguientes comandos. ``` drop table part; drop table supplier; drop table customer; drop table dwdate; drop table lineorder; ``` ### Siguiente [Resumen](#tutorial-loading-data-summary) ## Resumen En este tutorial, ha cargado archivos de datos en Amazon S3 y ha utilizado los comandos COPY para cargar los datos de los archivos en tablas de Amazon Redshift. Cargó datos utilizando los siguientes formatos: + Delimitado por caracteres + CSV + De ancho fijo Utilizó la tabla del sistema STL\$1LOAD\$1ERRORS para solucionar errores de carga y luego utilizó las opciones REGION, MANIFEST, MAXERROR, ACCEPTINVCHARS, DATEFORMAT y NULL AS para resolver los errores. Aplicó las siguientes prácticas recomendadas para cargar datos: + [Uso del comando COPY para cargar datos](c_best-practices-use-copy.md) + [Dividir los datos de carga](c_best-practices-use-multiple-files.md) + [Uso de un único comando COPY para cargar desde archivos múltiples](c_best-practices-single-copy-command.md) + [Compresión de los archivos de datos](c_best-practices-compress-data-files.md) + [Control de los archivos de datos antes y después de una carga](c_best-practices-verifying-data-files.md) Para obtener más información acerca de las prácticas recomendadas de Amazon Redshift, consulte los siguientes enlaces: + [Prácticas recomendadas de Amazon Redshift para la carga de datos](c_loading-data-best-practices.md) + [Prácticas recomendadas de Amazon Redshift para el diseño de tablas](c_designing-tables-best-practices.md) + [Prácticas recomendadas de Amazon Redshift para el diseño de consultas](c_designing-queries-best-practices.md)