Consultar Amazon Redshift utilizando Azure Databricks

Puede leer y escribir tablas de Amazon Redshift con Azure Databricks.

El origen de datos de Redshift para Databricks usa Amazon S3 para transferir datos de forma eficaz dentro y fuera de Redshift, y usa JDBC para desencadenar automáticamente los comandos COPY y UNLOAD adecuados en Redshift.

Uso

En los ejemplos siguientes se muestra cómo conectarse con el controlador de Redshift. Reemplace los valores del parámetro url si usa el controlador JDBC de PostgreSQL.

Una vez que haya configurado las credenciales de AWS, puede usar el origen de datos con la API de origen de datos de Spark en Python, SQL, R o Scala.

Python

# Read data from a table using Databricks Runtime 10.4 LTS and below
df = (spark.read
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("forward_spark_s3_credentials", True)
  .load()
)

# Read data from a table using Databricks Runtime 11.3 LTS and above
df = (spark.read
  .format("redshift")
  .option("host", "hostname")
  .option("port", "port") # Optional - will use default port 5439 if not specified.
  .option("user", "username")
  .option("password", "password")
  .option("database", "database-name")
  .option("dbtable", "schema-name.table-name") # if schema-name is not specified, default to "public".
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("forward_spark_s3_credentials", True)
  .load()
)

# Read data from a query
df = (spark.read
  .format("redshift")
  .option("query", "select x, count(*) <your-table-name> group by x")
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("forward_spark_s3_credentials", True)
  .load()
)

# After you have applied transformations to the data, you can use
# the data source API to write the data back to another table

# Write back to a table
(df.write
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .mode("error")
  .save()
)

# Write back to a table using IAM Role based authentication
(df.write
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("aws_iam_role", "arn:aws:iam::123456789000:role/redshift_iam_role")
  .mode("error")
  .save()
)

SQL

Leer los datos mediante SQL en Databricks Runtime 10.4 LTS y los siguientes:

DROP TABLE IF EXISTS redshift_table;
CREATE TABLE redshift_table
USING redshift
OPTIONS (
  dbtable '<table-name>',
  tempdir 's3a://<bucket>/<directory-path>',
  url 'jdbc:redshift://<database-host-url>',
  user '<username>',
  password '<password>',
  forward_spark_s3_credentials 'true'
);
SELECT * FROM redshift_table;

Leer los datos mediante SQL en Databricks Runtime 11.3 LTS y versiones posteriores:

DROP TABLE IF EXISTS redshift_table;
CREATE TABLE redshift_table
USING redshift
OPTIONS (
  host '<hostname>',
  port '<port>', /* Optional - will use default port 5439 if not specified. *./
  user '<username>',
  password '<password>',
  database '<database-name>'
  dbtable '<schema-name>.<table-name>', /* if schema-name not provided, default to "public". */
  tempdir 's3a://<bucket>/<directory-path>',
  forward_spark_s3_credentials 'true'
);
SELECT * FROM redshift_table;

Escriba datos mediante SQL:

DROP TABLE IF EXISTS redshift_table;
CREATE TABLE redshift_table_new
USING redshift
OPTIONS (
  dbtable '<new-table-name>',
  tempdir 's3a://<bucket>/<directory-path>',
  url 'jdbc:redshift://<database-host-url>',
  user '<username>',
  password '<password>',
  forward_spark_s3_credentials 'true'
) AS
SELECT * FROM table_name;

SQL API solo admite la creación de tablas, no sobrescribir ni anexar.

R

Leer los datos con R en Databricks Runtime 10.4 LTS y los siguientes:

df <- read.df(
   NULL,
   "com.databricks.spark.redshift",
   tempdir = "s3a://<your-bucket>/<your-directory-path>",
   dbtable = "<your-table-name>",
   url = "jdbc:redshift://<the-rest-of-the-connection-string>")

Leer datos usando R en Databricks Runtime 11.3 LTS y versiones posteriores:

df <- read.df(
  NULL,
  "redshift",
  host = "hostname",
  port = "port",
  user = "username",
  password = "password",
  database = "database-name",
  dbtable = "schema-name.table-name",
  tempdir = "s3a://<your-bucket>/<your-directory-path>",
  forward_spark_s3_credentials = "true",
  dbtable = "<your-table-name>")

Scala

// Read data from a table using Databricks Runtime 10.4 LTS and below
val df = spark.read
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("forward_spark_s3_credentials", True)
  .load()

// Read data from a table using Databricks Runtime 11.3 LTS and above
val df = spark.read
  .format("redshift")
  .option("host", "hostname")
  .option("port", "port") /* Optional - will use default port 5439 if not specified. */
  .option("user", "username")
  .option("password", "password")
  .option("database", "database-name")
  .option("dbtable", "schema-name.table-name") /* if schema-name is not specified, default to "public". */
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("forward_spark_s3_credentials", true)
  .load()

// Read data from a query
val df = spark.read
  .format("redshift")
  .option("query", "select x, count(*) <your-table-name> group by x")
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("forward_spark_s3_credentials", True)
  .load()

// After you have applied transformations to the data, you can use
// the data source API to write the data back to another table

// Write back to a table
df.write
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .mode("error")
  .save()

// Write back to a table using IAM Role based authentication
df.write
  .format("redshift")
  .option("dbtable", table_name)
  .option("tempdir", "s3a://<bucket>/<directory-path>")
  .option("url", "jdbc:redshift://<database-host-url>")
  .option("user", username)
  .option("password", password)
  .option("aws_iam_role", "arn:aws:iam::123456789000:role/redshift_iam_role")
  .mode("error")
  .save()

Recomendaciones para trabajar con Redshift

La ejecución de consultas puede extraer grandes cantidades de datos en S3. Si tiene previsto realizar varias consultas con los mismos datos en Redshift, Databricks recomienda guardar los datos extraídos mediante Delta Lake.

Configuración

Autenticación en S3 y Redshift

El origen de datos implica varias conexiones de red, que se muestran en el diagrama siguiente:

                            ┌───────┐
       ┌───────────────────>│  S3   │<─────────────────┐
       │    IAM or keys     └───────┘    IAM or keys   │
       │                        ^                      │
       │                        │ IAM or keys          │
       v                        v               ┌──────v────┐
┌────────────┐            ┌───────────┐         │┌──────────┴┐
│  Redshift  │            │  Spark    │         ││   Spark   │
│            │<──────────>│  Driver   │<────────>| Executors │
└────────────┘            └───────────┘          └───────────┘
               JDBC with                  Configured
               username /                     in
               password                     Spark
        (SSL enabled by default)

El origen de datos lee y escribe datos en S3 al transferir datos hacia o desde Redshift. Como resultado, requiere credenciales de AWS con acceso de lectura y escritura a un cubo S3 (especificado mediante el parámetro de configuración tempdir).

En las secciones siguientes, se describen las opciones de configuración de autenticación de cada conexión:

• Controlador de Spark a Redshift
• Spark a S3
• Redshift a S3

Controlador de Spark a Redshift

El controlador de Spark se conecta a Redshift mediante JDBC con un nombre de usuario y una contraseña. Redshift no admite el uso de roles de IAM para autenticar esta conexión. De manera predeterminada, esta conexión usa el cifrado SSL; para obtener más información, vea Cifrado.

Spark a S3

S3 sirve como intermediario para almacenar datos masivos al leer o escribir en Redshift. Spark se conecta a S3 mediante las interfaces de Hadoop FileSystem y directamente mediante el cliente S3 del SDK de Amazon Java.

• Establecer claves en la configuración de Hadoop: especifique las claves de AWS en las propiedades de configuración de Hadoop. Si la tempdir configuración apunta a un s3a:// sistema de archivos, puede establecer las fs.s3a.access.key propiedades y fs.s3a.secret.key en un archivo de configuración XML de Hadoop o llamar sc.hadoopConfiguration.set() a para configurar la configuración global de Hadoop de Spark. Si usa un s3n:// sistema de archivos, puede proporcionar las claves de configuración heredadas, como se muestra en el ejemplo siguiente.

  Scala

  Por ejemplo, si usa el s3a sistema de archivos, agregue:

  sc.hadoopConfiguration.set("fs.s3a.access.key", "<your-access-key-id>")
  sc.hadoopConfiguration.set("fs.s3a.secret.key", "<your-secret-key>")
  

  Para el sistema de archivos heredado s3n, añada:

  sc.hadoopConfiguration.set("fs.s3n.awsAccessKeyId", "<your-access-key-id>")
  sc.hadoopConfiguration.set("fs.s3n.awsSecretAccessKey", "<your-secret-key>")
  

  Python

  Aunque el comando siguiente se basa en algunos elementos internos de Spark, debería funcionar con todas las versiones de PySpark y es poco probable que se interrumpa o se modifique en el futuro:

    sc._jsc.hadoopConfiguration().set("fs.s3a.access.key", "<your-access-key-id>")
    sc._jsc.hadoopConfiguration().set("fs.s3a.secret.key", "<your-secret-key>")
  

Redshift a S3

Establezca la forward_spark_s3_credentials opción para true reenviar automáticamente las credenciales de clave de AWS que Spark usa para conectarse a S3 a través de JDBC a Redshift. La consulta JDBC incorpora estas credenciales, por lo que Databricks le recomienda encarecidamente que active el cifrado SSL de la conexión JDBC.

Cifrado

• Protección de JDBC: a menos que cualquier configuración relacionada con SSL esté presente en la dirección URL de JDBC, el origen de datos habilita de manera predeterminada el cifrado SSL y también comprueba que el servidor de Redshift es de confianza (es decir, sslmode=verify-full). Para ello, se descarga automáticamente un certificado de servidor de los servidores de Amazon la primera vez que se necesita. En caso de que se produzca un error, se usa un archivo de certificado previamente agrupado como reserva. Esto se aplica para los controladores JDBC de Redshift y PostgreSQL.

  En caso de que haya algún problema con esta característica, o simplemente quiera deshabilitar SSL, puede llamar a .option("autoenablessl", "false") en el elemento DataFrameReader o DataFrameWriter.

  Si quiere especificar la configuración personalizada relacionada con SSL, puede seguir las instrucciones de la documentación de Redshift: Uso de certificados SSL y de servidor en Java y Opciones de configuración del controlador JDBC. Cualquier opción relacionada con SSL presente en el JDBC url usado con el origen de datos tiene prioridad (es decir, no se desencadenará la configuración automática).

• Cifrado de datos UNLOAD almacenados en S3 (datos almacenados al leer desde Redshift): según la documentación de Redshift sobre Descarga de datos en S3, "UNLOAD cifra automáticamente los archivos de datos mediante el cifrado del lado servidor de Amazon S3 (SSE-S3)".

  Redshift también admite el cifrado del lado cliente con una clave personalizada (vea: Descarga de archivos de datos cifrados), pero el origen de datos carece de la capacidad para especificar la clave simétrica necesaria.

• Cifrado de datos COPY almacenados en S3 (datos almacenados al escribir en Redshift): según la documentación de Redshift sobre Carga de archivos de datos cifrados desde Amazon S3:

Puede usar el comando COPY para cargar archivos de datos que se cargaron en Amazon S3 mediante el cifrado del lado servidor con claves de cifrado administradas por AWS (SSE-S3 o SSE-KMS), el cifrado del lado cliente o ambos. COPY no admite el cifrado del lado servidor de Amazon S3 con una clave proporcionada por el cliente (SSE-C).

Parámetros

El mapa de parámetros u OPTIONS que se proporcionan en Spark SQL admiten la configuración siguiente:

Opciones de configuración adicionales

Configuración del tamaño máximo de las columnas de cadena

Al crear tablas de Redshift, el comportamiento predeterminado es crear columnas TEXT para las que son de cadena. Redshift almacena columnas TEXT como VARCHAR(256), por lo que estas columnas tienen un tamaño máximo de 256 caracteres (origen).

Para admitir columnas más grandes, puede usar el campo de metadatos de columna maxlength a fin de especificar la longitud máxima de las columnas de cadena individuales. Esto también es útil para implementar optimizaciones de rendimiento de ahorro de espacio declarando columnas con una longitud máxima menor que la predeterminada.

Python

df = ... # the dataframe you'll want to write to Redshift

# Specify the custom width of each column
columnLengthMap = {
  "language_code": 2,
  "country_code": 2,
  "url": 2083,
}

# Apply each column metadata customization
for (colName, length) in columnLengthMap.iteritems():
  metadata = {'maxlength': length}
  df = df.withColumn(colName, df[colName].alias(colName, metadata=metadata))

df.write \
  .format("com.databricks.spark.redshift") \
  .option("url", jdbcURL) \
  .option("tempdir", s3TempDirectory) \
  .option("dbtable", sessionTable) \
  .save()

Scala

Este es un ejemplo de actualización de los campos de metadatos de varias columnas mediante la API de Scala de Spark:

import org.apache.spark.sql.types.MetadataBuilder

// Specify the custom width of each column
val columnLengthMap = Map(
  "language_code" -> 2,
  "country_code" -> 2,
  "url" -> 2083
)

var df = ... // the dataframe you'll want to write to Redshift

// Apply each column metadata customization
columnLengthMap.foreach { case (colName, length) =>
  val metadata = new MetadataBuilder().putLong("maxlength", length).build()
  df = df.withColumn(colName, df(colName).as(colName, metadata))
}

df.write
  .format("com.databricks.spark.redshift")
  .option("url", jdbcURL)
  .option("tempdir", s3TempDirectory)
  .option("dbtable", sessionTable)
.save()

Establecimiento de un tipo de columna personalizado

Si necesita establecer manualmente un tipo de columna, puede usar los metadatos de columna redshift_type. Por ejemplo, si quiere invalidar el buscador de coincidencias de tipo de Spark SQL Schema -> Redshift SQL para asignar un tipo de columna definido por el usuario, puede hacer lo siguiente:

Python

# Specify the custom type of each column
columnTypeMap = {
  "language_code": "CHAR(2)",
  "country_code": "CHAR(2)",
  "url": "BPCHAR(111)",
}

df = ... # the dataframe you'll want to write to Redshift

# Apply each column metadata customization
for colName, colType in columnTypeMap.items():
  metadata = {'redshift_type': colType}
  df = df.withColumn(colName, df[colName].alias(colName, metadata=metadata))

Scala

import org.apache.spark.sql.types.MetadataBuilder

// Specify the custom type of each column
val columnTypeMap = Map(
  "language_code" -> "CHAR(2)",
  "country_code" -> "CHAR(2)",
  "url" -> "BPCHAR(111)"
)

var df = ... // the dataframe you'll want to write to Redshift

// Apply each column metadata customization
columnTypeMap.foreach { case (colName, colType) =>
  val metadata = new MetadataBuilder().putString("redshift_type", colType).build()
  df = df.withColumn(colName, df(colName).as(colName, metadata))
}

Configuración de la codificación de columnas

Al crear una tabla, use el campo de metadatos de columna encoding a fin de especificar una codificación de compresión para cada columna (vea la documentación de Amazon para obtener las codificaciones disponibles).

Establecimiento de descripciones en columnas

Redshift permite que las columnas tengan descripciones adjuntas que deben aparecer en la mayoría de las herramientas de consulta (mediante el comando COMMENT). Puede establecer el campo de metadatos de columna description a fin de especificar una descripción para columnas individuales.

Inserción de consultas en Redshift

El optimizador de Spark inserta los operadores siguientes en Redshift:

• Filter
• Project
• Sort
• Limit
• Aggregation
• Join

En Project y Filter, admite las expresiones siguientes:

• La mayoría de operadores lógicos booleanos
• Comparaciones
• Operaciones aritméticas básicas
• Conversiones numéricas y de cadena
• La mayoría de funciones de cadena
• Subconsultas escalares, si se pueden insertar completamente en Redshift.

En Aggregation, admite las funciones de agregación siguientes:

• AVG
• COUNT
• MAX
• MIN
• SUM
• STDDEV_SAMP
• STDDEV_POP
• VAR_SAMP
• VAR_POP

combinadas con la cláusula DISTINCT, si procede.

En Join, admite los tipos de combinaciones siguientes:

• INNER JOIN
• LEFT OUTER JOIN
• RIGHT OUTER JOIN
• LEFT SEMI JOIN
• LEFT ANTI JOIN
• Subconsultas que el optimizador ha reescrito en Join como, por ejemplo WHERE EXISTS y WHERE NOT EXISTS

La inserción puede ser más beneficiosa en las consultas con LIMIT. Una consulta como SELECT * FROM large_redshift_table LIMIT 10 podría tardar mucho tiempo, ya que la tabla completa primero realizaría la acción UNLOAD en S3 como resultado intermedio. Con la inserción, LIMIT se ejecuta en Redshift. En las consultas con agregaciones, la inserción de la agregación en Redshift también permite reducir la cantidad de datos que se deben transferir.

La inserción de consultas en Redshift está habilitada de manera predeterminada. Esta característica se puede deshabilitar si spark.databricks.redshift.pushdown se establece en false. Incluso cuando está deshabilitada, Spark sigue insertando filtros y realiza la eliminación de columnas en Redshift.

Instalación del controlador de Redshift

El origen de datos de Redshift también requiere un controlador JDBC compatible con Redshift. Dado que Redshift se basa en el sistema de base de datos de PostgreSQL, puede usar el controlador JDBC de PostgreSQL incluido con Databricks Runtime o el controlador JDBC de Amazon recomendado. No se requiere ninguna instalación para usar el controlador JDBC de PostgreSQL. La versión del controlador JDBC de PostgreSQL incluida en cada versión de Databricks Runtime se muestra en las notas de la versión de Databricks Runtime.

Para instalar manualmente el controlador JDBC de Redshift, haga lo siguiente:

1. Descargar el controlador de Amazon.
2. Cargar el controlador en el área de trabajo de Azure Databricks. Consulte Bibliotecas.
3. Instalar la biblioteca en el clúster.

Garantías transaccionales

En esta sección se describen las garantías transaccionales del origen de datos de Redshift para Spark.

Información general sobre las propiedades de Redshift y S3

Para obtener información general sobre las garantías transaccionales de Redshift, vea el capítulo Administración de operaciones de escritura simultáneas en la documentación de Redshift. En pocas palabras, Redshift proporciona aislamiento serializable según la documentación del comando BEGIN de Redshift:

[aunque] puede usar cualquiera de los cuatro niveles de aislamiento de transacción, Amazon Redshift procesa todos los niveles de aislamiento como serializables.

Según la documentación de Redshift:

Amazon Redshift admite un comportamiento de confirmación automática predeterminado en el que cada comando SQL ejecutado de forma independiente se confirma individualmente.

Por lo tanto, los comandos individuales como COPY y UNLOAD son atómicos y transaccionales, mientras que los explícitos BEGIN y END solo deben ser necesarios para aplicar la atomicidad de varios comandos o consultas.

Al leer y escribir en Redshift, el origen de datos lee y escribe datos en S3. Tanto Spark como Redshift generan una salida con particiones y la almacenan en varios archivos en S3. Según la documentación del Modelo de coherencia de datos de Amazon S3, las operaciones de enumeración de cubos de S3 son coherentes al final, por lo que los archivos deben ir a longitudes especiales para evitar que falten datos o estén incompletos debido a este origen de coherencia final.

Garantías del origen de datos de Redshift para Spark

Anexión a una tabla existente

Al insertar filas en Redshift, el origen de datos usa el comando COPY y especifica manifiestos para protegerse contra determinadas operaciones S3 coherentes al final. Como resultado, los anexos de spark-redshift a las tablas existentes tienen las mismas propiedades atómicas y transaccionales que los comandos COPY normales de Redshift.

Creación de una tabla (SaveMode.CreateIfNotExists)

La creación de una tabla es un proceso de dos pasos, que consta de un comando CREATE TABLE seguido de otro COPY para anexar el conjunto inicial de filas. Ambas operaciones se realizan en la misma transacción.

Sobrescritura de una tabla existente

De manera predeterminada, el origen de datos usa transacciones para realizar sobrescrituras, que se implementan eliminando la tabla de destino, creando una tabla vacía y anexando filas a ella.

Si la configuración en desuso usestagingtable se establece en false, el origen de datos confirma el comando DELETE TABLE antes de anexar filas a la nueva tabla, lo que sacrifica la atomicidad de la operación de sobrescritura, pero reduce la cantidad de espacio de almacenamiento provisional que Redshift necesita durante esta sobrescritura.

Consulta de tabla de Redshift

Las consultas usan el comando UNLOAD de Redshift para ejecutar una consulta, guardar sus resultados en S3 y usar manifiestos para protegerse contra determinadas operaciones de S3 coherentes al final. Como resultado, las consultas del origen de datos de Redshift para Spark deben tener las mismas propiedades de coherencia que las consultas periódicas de Redshift.

Problemas y soluciones habituales

El cubo de S3 y el clúster de Redshift se encuentran en diferentes regiones de AWS

De manera predeterminada, las copias de S3 <-> de Redshift no funcionan si el cubo de S3 y el clúster de Redshift se encuentran en regiones de AWS diferentes.

Si intenta leer una tabla de Redshift cuando el cubo de S3 está en una región diferente, es posible que vea un error como el siguiente:

ERROR: S3ServiceException:The S3 bucket addressed by the query is in a different region from this cluster.,Status 301,Error PermanentRedirect.

Del mismo modo, intentar escribir en Redshift mediante un cubo de S3 en una región diferente puede provocar el error siguiente:

error:  Problem reading manifest file - S3ServiceException:The S3 bucket addressed by the query is in a different region from this cluster.,Status 301,Error PermanentRedirect

• Escrituras: el comando COPY de Redshift admite la especificación explícita de la región del cubo de S3, por lo que puede hacer que las escrituras en Redshift funcionen correctamente en estos casos agregando region 'the-region-name' a la configuración extracopyoptions. Por ejemplo, con un cubo en la región Este de EE. UU. (Virginia) y la API de Scala, use lo siguiente:

  .option("extracopyoptions", "region 'us-east-1'")
  

  También puede usar la configuración awsregion:

  .option("awsregion", "us-east-1")
  

• Lecturas: el comando UNLOAD de Redshift también admite la especificación explícita de la región del cubo de S3. Puede hacer que las lecturas funcionen correctamente agregando la región a la configuración awsregion:

  .option("awsregion", "us-east-1")
  

Error de autenticación al usar una contraseña con caracteres especiales en la dirección URL de JDBC

Si va a proporcionar el nombre de usuario y la contraseña como parte de la dirección URL de JDBC y la contraseña contiene caracteres especiales, como ;, ? o &, es posible que vea la excepción siguiente:

java.sql.SQLException: [Amazon](500310) Invalid operation: password authentication failed for user 'xyz'

Esto se debe a que los caracteres especiales del nombre de usuario o la contraseña no los ha agregado correctamente el controlador JDBC. Asegúrese de especificar el nombre de usuario y la contraseña mediante las opciones user y password del DataFrame correspondiente. Para obtener más información, vea Parámetros.

La consulta Spark de ejecución prolongada se bloquea indefinidamente aunque se realice la operación de Redshift correspondiente.

Si está leyendo o escribiendo grandes cantidades de datos desde y hacia Redshift, la consulta de Spark puede bloquearse indefinidamente, aunque la página Supervisión de Redshift de AWS muestre que la operación LOAD o UNLOAD correspondiente se ha completado y que el clúster está inactivo. Esto se debe a que la conexión entre Redshift y Spark agota el tiempo de espera. Para evitar esto, asegúrese de que la marca de JDBC tcpKeepAlive está habilitada y TCPKeepAliveMinutes está establecida en un valor bajo (por ejemplo, 1).

Para obtener más información, vea Configuración del controlador JDBC de Amazon Redshift.

Marca de tiempo con semántica de zona horaria

Al leer datos, los tipos de datos TIMESTAMP y TIMESTAMPTZ de Redshift se asignan a TimestampType de Spark, y un valor se convierte en hora universal coordinada (UTC) y se almacena como marca de tiempo UTC. En el caso de un elemento TIMESTAMP de Redshift, se da por hecho que la zona horaria local no tiene ninguna información de zona horaria. Al escribir datos en una tabla de Redshift, un elemento TimestampType de Spark se asigna al tipo de datos TIMESTAMP de Redshift.

Guía de migración

El origen de datos ahora requiere que establezca forward_spark_s3_credentials explícitamente antes de que las credenciales de S3 de Spark se reenvíen a Redshift. Este cambio no afecta para nada si usa los mecanismos de autenticación aws_iam_role o temporary_aws_*. Pero si se basa en el comportamiento predeterminado anterior, ahora debe establecer explícitamente forward_spark_s3_credentials en true para seguir usando el mecanismo de autenticación anterior de Redshift en S3. Para obtener una explicación de los tres mecanismos de autenticación y sus ventajas y desventajas de seguridad, vea la sección Autenticación en S3 y Redshift de este documento.