Capítulo 4. Ingesta de datos en la nube
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
En este capítulo, mostraremos cómo ingerir datos en la nube. Para ello, estudiaremos un escenario típico en el que una aplicación escribe archivos en un lago de datos de Amazon S3, al que a su vez necesita acceder el equipo de ingeniería de ML/ciencia de datos, así como el equipo de inteligencia empresarial/analista de datos, como se muestra en la Figura 4-1.
Figura 4-1. Una aplicación escribe datos en nuestro lago de datos S3 para los equipos de ciencia de datos, ingeniería de aprendizaje automático e inteligencia empresarial.
Amazon Simple Storage Service (Amazon S3) es un almacenamiento de objetos totalmente administrado que ofrece durabilidad extrema, alta disponibilidad y escalabilidad infinita de datos a un coste muy bajo. Por lo tanto, es la base perfecta para los lagos de datos, los conjuntos de datos de entrenamiento y los modelos. Aprenderemos más sobre las ventajas de construir lagos de datos en Amazon S3 en la siguiente sección.
Supongamos que nuestra aplicación captura datos continuamente (es decir, interacciones de clientes en nuestro sitio web, mensajes de reseñas de productos) y escribe los datos en S3 en formato de archivo de valores separados por tabulaciones (TSV).
Como científico de datos o ingeniero de aprendizaje automático, queremos explorar rápidamente conjuntos de datos sin procesar. Presentaremos Amazon Athena y mostraremos cómo aprovechar Athena como servicio de consulta interactiva para analizar datos en S3 utilizando SQL estándar, sin mover los datos. En el primer paso, registraremos los datos TSV en nuestro bucket de S3 con Athena y, a continuación, ejecutaremos algunas consultas ad hoc en el conjunto de datos. También mostraremos cómo convertir fácilmente los datos TSV en el formato de archivo columnar Apache Parquet, más optimizado para las consultas.
Nuestro equipo de inteligencia empresarial también podría querer tener un subconjunto de los datos en un almacén de datos, que luego pueden transformar y consultar con clientes SQL estándar para crear informes y visualizar tendencias. Presentaremos Amazon Redshift, un servicio de almacén de datos totalmente administrado, y mostraremos cómo insertar datos TSV en Amazon Redshift, así como combinar las consultas del almacén de datos con los datos de acceso menos frecuente que aún se encuentran en nuestro lago de datos S3 a través de Amazon Redshift Spectrum. Nuestro equipo de inteligencia empresarial también puede utilizar la funcionalidad de exportación del lago de datos de Amazon Redshift para descargar datos (transformados, enriquecidos) de vuelta a nuestro lago de datos S3 en formato de archivo Parquet.
Concluiremos este capítulo con algunos consejos y trucos para aumentar el rendimiento utilizando algoritmos de compresión y reducir el coste aprovechando S3 Intelligent-Tiering. En el Capítulo 12, profundizaremos en la seguridad de los conjuntos de datos, el seguimiento del acceso a los datos, el cifrado de los datos en reposo y el cifrado de los datos en tránsito.
Lagos de datos
En Capítulo 3, hablamos de la democratización de la inteligencia artificial y la ciencia de datos en los últimos años, de la explosión de datos y de cómo los servicios en la nube proporcionan la agilidad de infraestructura para almacenar y procesar datos de cualquier cantidad.
Sin embargo, para utilizar todos estos datos de forma eficiente, las empresas tienen la tarea de romper los silos de datos existentes y encontrar formas de analizar conjuntos de datos muy diversos, tratando con datos estructurados y no estructurados, al tiempo que garantizan los más altos estándares de gobernanza de datos, seguridad de datos y cumplimiento de las normativas de privacidad. Estos retos de los (grandes) datos sientan las bases para los lagos de datos.
Una de las mayores ventajas de los lagos de datos es que no necesitamos predefinir ningún esquema. Podemos almacenar nuestros datos brutos a escala y decidir después de qué forma necesitamos procesarlos y analizarlos. Los lagos de datos pueden contener datos estructurados, semiestructurados y no estructurados. La Figura 4-2 muestra el repositorio centralizado y seguro del lago de datos que nos permite almacenar, gobernar, descubrir y compartir datos a cualquier escala, incluso en tiempo real.
Figura 4-2. Un lago de datos es un repositorio centralizado y seguro que nos permite almacenar, gobernar, descubrir y compartir datos a cualquier escala.
Los lagos de datos proporcionan una base perfecta para la ciencia de datos y el aprendizaje automático, ya que nos dan acceso a conjuntos de datos grandes y diversos para entrenar e implementar modelos más precisos. Construir un lago de datos suele consistir en los siguientes pasos (de alto nivel), como se muestra en la Figura 4-3:
-
Prepara el almacenamiento.
-
Mover datos.
-
Limpia, prepara y cataloga los datos.
-
Configura y aplica políticas de seguridad y cumplimiento.
-
Haz que los datos estén disponibles para el análisis.
Cada de esos pasos implica una serie de herramientas y tecnologías. Aunque podemos construir un lago de datos manualmente desde cero, existen servicios en la nube que nos ayudan a agilizar este proceso, como AWS Lake Formation.
Figura 4-3. Construir un lago de datos implica muchos pasos.
Lake Formation recopila y cataloga datos de bases de datos y almacenamiento de objetos, traslada datos a un lago de datos basado en S3, asegura el acceso a datos confidenciales y deduplica datos mediante aprendizaje automático.
Las capacidades adicionales de de Lake Formation incluyen seguridad a nivel de fila, seguridad a nivel de columna y tablas "gobernadas" que admiten transacciones atómicas, consistentes, aisladas y duraderas. Con los permisos a nivel de fila y a nivel de columna, los usuarios sólo ven los datos a los que tienen acceso. Con las transacciones de Lake Formation, los usuarios pueden insertar, eliminar y modificar filas de forma concurrente y fiable en las tablas gobernadas. Lake Formation también mejora el rendimiento de las consultas compactando automáticamente el almacenamiento de datos y optimizando la disposición de los datos de las tablas gobernadas.
S3 se ha convertido en una opción popular para los lagos de datos, ya que ofrece muchas formas de ingerir nuestros datos, a la vez que permite la optimización de costes con la clasificación inteligente de los datos por niveles, incluidas las capacidades de almacenamiento en frío y archivado. S3 también expone muchos controles a nivel de objeto para la seguridad y el cumplimiento.
Encima del lago de datos S3, AWS implementa la arquitectura Lake House de. La Arquitectura Lake House integra nuestro lago de datos S3 con nuestro almacén de datos Amazon Redshift para un modelo de gobernanza unificado. Veremos un ejemplo de esta arquitectura en este capítulo cuando ejecutemos una consulta uniendo datos de nuestro almacén de datos de Amazon Redshift con nuestro lago de datos de S3.
Desde el punto de vista del análisis de datos, otra ventaja clave de almacenar nuestros datos en Amazon S3 es que acorta drásticamente el "tiempo hasta el conocimiento", ya que podemos ejecutar consultas ad hoc directamente sobre los datos en S3. No tenemos que pasar por complejos procesos de transformación y canalizaciones de datos para introducir nuestros datos en los almacenes de datos empresariales tradicionales, como veremos en las próximas secciones de este capítulo.
Importar Datos al Lago de Datos S3
Nosotros ya estamos preparados para importar nuestros datos a S3. Hemos elegido el conjunto de datos Reseñas de clientes de Amazon como conjunto de datos principal para este libro.
El conjunto de datos de opiniones de clientes de Amazon consta de más de 150 millones de opiniones de clientes sobre productos de 43 categorías de productos diferentes en el sitio web Amazon.com desde 1995 hasta 2015. Es un gran recurso para demostrar conceptos de aprendizaje automático como el procesamiento del lenguaje natural (PLN), como demostramos a lo largo de este libro.
Muchos de nosotros hemos visto estas reseñas de clientes en Amazon.com cuando contemplábamos la posibilidad de comprar productos a través del mercado de Amazon.com. La Figura 4-4 muestra la sección de opiniones de productos en Amazon.com para un dispositivo Amazon Echo Dot.
Figura 4-4. Reseñas de un dispositivo Amazon Echo Dot. Fuente: Amazon.es.
Describir el conjunto de datos
Las opiniones de los clientes son una de las herramientas más valiosas de Amazon para los clientes que desean tomar decisiones de compra informadas. En las cartas anuales de Amazon a los accionistas, Jeff Bezos (fundador de Amazon) se explaya regularmente sobre la importancia del "boca a boca" como herramienta de captación de clientes. A Jeff le encanta "el descontento constante de los clientes", como él lo llama:
"Ahora ofrecemos a los clientes... muchísimas más reseñas, contenidos, opciones de navegación y funciones de recomendación... El boca a boca sigue siendo la herramienta de captación de clientes más poderosa que tenemos, y estamos agradecidos por la confianza que nuestros clientes han depositado en nosotros. Las compras repetidas y el boca a boca se han combinado para hacer de Amazon.com el líder del mercado de venta de libros en línea."
-Jeff Bezos, Carta del Accionista ("Propietario de Acciones") de 1997
Éste es el esquema del conjunto de datos:
- mercado
- Código de país de dos letras (en este caso todo "US").
- id_cliente
- Identificador aleatorio que puede utilizarse para agregar opiniones escritas por un mismo autor.
- review_id
- Un identificador único para la revisión.
- producto_id
- El número de identificación estándar de Amazon (ASIN).
- padre_producto
- El padre de ese ASIN. Múltiples ASIN (variaciones de color o formato del mismo producto) pueden enrollarse en un único producto padre.
- título_producto
- Descripción del título del producto.
- categoría_producto
- Amplia categoría de producto que puede utilizarse para agrupar opiniones.
- clasificación_estrella
- La valoración de la reseña de 1 a 5 estrellas, donde 1 es la peor y 5 la mejor.
- votos_útiles
- Número de votos útiles para la revisión.
- total_votos
- Número total de votos que ha recibido la opinión.
- vid
- ¿La reseña se escribió como parte del programa Vine?
- compra_verificada
- ¿La opinión procedía de una compra verificada?
- titular_reseña
- El propio título de la reseña.
- cuerpo_examen
- El texto de la reseña.
- fecha_revisión
- La fecha en que se escribió la reseña.
El conjunto de datos se comparte en un bucket público de Amazon S3 y está disponible en dos formatos de archivo:
-
TSV, un formato de texto: s3://amazon-reviews-pds/tsv
-
Parquet, un formato binario columnar optimizado: s3://amazon-reviews-pds/parquet
El conjunto de datos Parquet está particionado (dividido en subcarpetas) por la columna product_category para mejorar aún más el rendimiento de las consultas. Con esto, podemos utilizar una cláusula WHERE en product_category en nuestras consultas SQL para leer sólo los datos específicos de esa categoría.
Podemos utilizar la interfaz de línea de comandos de AWS (CLI de AWS) para listar el contenido del bucket de S3 utilizando los siguientes comandos de la CLI:
-
aws s3 ls s3://amazon-reviews-pds/tsv -
aws s3 ls s3://amazon-reviews-pds/parquet
Nota
La herramienta AWS CLI proporciona una interfaz unificada de línea de comandos para Amazon Web Services. Podemos encontrar más información sobre cómo instalar y configurar la herramienta.
Los listados siguientes nos muestran los archivos de conjuntos de datos disponibles en formato TSV y la estructura de carpetas de partición Parquet.
Ficheros de conjuntos de datos en formato TSV:
2017-11-24 13:49:53 648641286 amazon_reviews_us_Apparel_v1_00.tsv.gz 2017-11-24 13:56:36 582145299 amazon_reviews_us_Automotive_v1_00.tsv.gz 2017-11-24 14:04:02 357392893 amazon_reviews_us_Baby_v1_00.tsv.gz 2017-11-24 14:08:11 914070021 amazon_reviews_us_Beauty_v1_00.tsv.gz 2017-11-24 14:17:41 2740337188 amazon_reviews_us_Books_v1_00.tsv.gz 2017-11-24 14:45:50 2692708591 amazon_reviews_us_Books_v1_01.tsv.gz 2017-11-24 15:10:21 1329539135 amazon_reviews_us_Books_v1_02.tsv.gz ... 2017-11-25 08:39:15 94010685 amazon_reviews_us_Software_v1_00.tsv.gz 2017-11-27 10:36:58 872478735 amazon_reviews_us_Sports_v1_00.tsv.gz 2017-11-25 08:52:11 333782939 amazon_reviews_us_Tools_v1_00.tsv.gz 2017-11-25 09:06:08 838451398 amazon_reviews_us_Toys_v1_00.tsv.gz 2017-11-25 09:42:13 1512355451 amazon_reviews_us_Video_DVD_v1_00.tsv.gz 2017-11-25 10:50:22 475199894 amazon_reviews_us_Video_Games_v1_00.tsv.gz 2017-11-25 11:07:59 138929896 amazon_reviews_us_Video_v1_00.tsv.gz 2017-11-25 11:14:07 162973819 amazon_reviews_us_Watches_v1_00.tsv.gz 2017-11-26 15:24:07 1704713674 amazon_reviews_us_Wireless_v1_00.tsv.gz
Ficheros de conjuntos de datos en formato Parquet:
PRE product_category=Apparel/
PRE product_category=Automotive/
PRE product_category=Baby/
PRE product_category=Beauty/
PRE product_category=Books/
...
PRE product_category=Watches/
PRE product_category=Wireless/
Ten en cuenta que PRE significa "prefijo". Por ahora, podemos pensar en los prefijos como carpetas en S3.
A veces es útil utilizar EXPLAIN en nuestras consultas para asegurarnos de que se están utilizando las particiones de S3. Spark, por ejemplo, resaltará qué particiones se están utilizando en Spark SQL. Si nuestros patrones de consulta cambian con el tiempo, puede que queramos volver a considerar la actualización de las particiones existentes, o incluso añadir nuevas particiones que se ajusten a nuestras necesidades empresariales.
Entonces, ¿qué formato de datos debemos elegir? El formato de archivo en columnas Parquet es definitivamente el preferido cuando se ejecutan consultas analíticas, ya que muchas consultas analíticas realizan estadísticas de resumen (AVG, SUM, STDDEV, etc.) sobre columnas de datos. Por otra parte, muchas aplicaciones escriben los datos en simples archivos CSV o TSV, por ejemplo, archivos de registro de aplicaciones. Así que, en realidad, vamos a suponer que no tenemos los archivos Parquet listos para usar, ya que esto nos permite mostrarnos cómo podemos obtenerlos fácilmente a partir de archivos CSV o TSV.
En un primer paso, vamos a copiar los datos TSV del bucket S3 público de Amazon en un bucket S3 alojado en privado para simular ese proceso, como se muestra en la Figura 4-5.
Figura 4-5. Copiamos el conjunto de datos del cubo S3 público a un cubo S3 privado.
Podemos volver a utilizar la herramienta CLI de AWS para realizar los siguientes pasos.
-
Crea un nuevo bucket S3 privado:
aws s3 mb s3://data-science-on-aws -
Copia el contenido del bucket S3 público a nuestro recién creado bucket S3 privado de la siguiente manera (sólo incluye los archivos que empiecen por
amazon_reviews_us_, es decir, omite cualquier archivo de índice, multilingüe y de datos de muestra de ese directorio):aws s3 cp --recursive s3://amazon-reviews-pds/tsv/ \ s3://data-science-on-aws/amazon-reviews-pds/tsv/ \ --exclude "*" --include "amazon_reviews_us_*"
Ya estamos listos para utilizar Amazon Athena para registrar y consultar los datos y transformar los archivos TSV en Parquet.
Consulta el lago de datos de Amazon S3 con Amazon Athena
Amazon Athena es un servicio de consulta interactivo que facilita el análisis de datos en Amazon S3 utilizando SQL estándar. Con Athena, podemos consultar datos sin procesar -incluidos datos cifrados- directamente desde nuestro lago de datos basado en S3. Athena separa la computación del almacenamiento y reduce el tiempo total de obtención de información para nuestra empresa. Cuando registramos una tabla de Athena con nuestros datos de S3, Athena almacena la correspondencia entre la tabla y S3. Athena utiliza AWS Glue Data Catalog, un servicio compatible con Hive Metastore, para almacenar el mapeo tabla-S3. Podemos pensar en el Catálogo de Datos AWS Glue como un almacén de metadatos persistente en nuestra cuenta de AWS. Otros servicios de AWS, como Athena y Amazon Redshift Spectrum, pueden utilizar el catálogo de datos para localizar y consultar datos. Apache Spark también lee del Catálogo de Datos de AWS Glue.
Además de el catálogo de datos, AWS Glue también proporciona herramientas para construir flujos de trabajo ETL (extraer-transformar-cargar). Los flujos de trabajo ETL pueden incluir el descubrimiento automático y la extracción de datos de distintas fuentes. Podemos aprovechar Glue Studio para componer y ejecutar visualmente flujos de trabajo ETL sin escribir código. Glue Studio también proporciona un único panel de cristal para monitorear todos los trabajos ETL. AWS Glue ejecuta los flujos de trabajo en un motor ETL sin servidor basado en Apache Spark.
Las consultas Athena se ejecutan en paralelo dentro de un motor de consultas sin servidor y escalado dinámicamente. Athena escalará automáticamente el clúster en función de la consulta y el conjunto de datos de que se trate. Esto hace que Athena sea extremadamente rápido en grandes conjuntos de datos y libera al usuario de preocuparse por los detalles de la infraestructura.
Además, Athena admite el formato de archivo columnar Parquet con decenas de millones de particiones (es decir, por product_category, year o marketplace) para mejorar el rendimiento de nuestras consultas. Por ejemplo, si planeamos ejecutar consultas frecuentes que agrupen los resultados por product_category, entonces deberíamos crear una partición en Athena para product_category. Tras la creación, Athena actualizará el Catálogo de Datos de AWS Glue en consecuencia, de modo que las consultas futuras hereden las ventajas de rendimiento de esta nueva partición.
Athena se basa en Presto, un motor de consulta SQL distribuido de código abierto diseñado para el análisis rápido y ad hoc de datos en grandes conjuntos de datos. De forma similar a Apache Spark, Presto utiliza clusters de alta RAM para realizar sus consultas. Sin embargo, Presto no requiere una gran cantidad de disco, ya que está diseñado para consultas ad hoc (frente a consultas automatizadas y repetibles) y, por tanto, no realiza el checkpointing necesario para la tolerancia a fallos.
Para trabajos Athena de larga duración, podemos escuchar eventos de finalización de consulta utilizando Amazon CloudWatch Events. Cuando finaliza la consulta, se notifica a todos los oyentes con los detalles del evento, incluido el estado de éxito de la consulta, el tiempo total de ejecución y el total de bytes escaneados.
Con una funcionalidad llamada Athena Federated Query, también podemos ejecutar consultas SQL a través de datos almacenados en bases de datos relacionales, como Amazon RDS y Aurora, bases de datos no relacionales como DynamoDB, almacenamiento de objetos como Amazon S3 y fuentes de datos personalizadas. Esto nos proporciona una visión analítica unificada de los datos almacenados en nuestro almacén de datos, lago de datos y bases de datos operativas, sin necesidad de mover realmente los datos.
Podemos acceder a Athena mediante la consola de administración de AWS, una API o un controlador de Open Database Connectivity (ODBC) o Java Database Connectivity (JDBC) para el acceso programático. Veamos cómo utilizar Amazon Athena a través de la consola de administración de AWS.
Accede a Athena desde la consola de AWS
Para utilizar Amazon Athena, primero tenemos que configurar rápidamente el servicio. En primer lugar, haz clic en Amazon Athena en la consola de administración de AWS. Si se nos pide que configuremos una ubicación de "resultados de consulta" para Athena en S3, especifica una ubicación S3 para los resultados de la consulta (por ejemplo, s3://<BUCKET>/data-science-on-aws/athena/query-results.)
En el siguiente paso, creamos una base de datos. En el editor de consultas Athena, vemos un panel de consultas con una consulta de ejemplo. Podemos empezar a escribir nuestra consulta en cualquier lugar del panel de consulta. Para crear nuestra base de datos, introducimos la siguiente sentencia CREATE DATABASE, ejecutamos la consulta y confirmamos que dsoaws aparece en la lista BASE DE DATOS del panel Catálogo:
CREATE DATABASE dsoaws;
Cuando ejecutamos las consultas CREATE DATABASE y CREATE TABLE en Athena con el Catálogo de datos de AWS Glue como fuente, vemos automáticamente cómo se crean las entradas de metadatos de la base de datos y de la tabla en el Catálogo de datos de AWS Glue.
Registrar Datos S3 como Tabla Athena
Ahora que tenemos una base de datos, estamos listos para crear una tabla basada en el Conjunto de Datos de Opiniones de Clientes de Amazon. Definimos las columnas que se asignan a los datos, especificamos cómo se delimitan los datos y proporcionamos la ruta de Amazon S3 a los datos.
Vamos a definir un "esquema en lectura" para evitar la necesidad de predefinir un esquema rígido cuando se escriben e ingestan los datos. En la Consola Athena, asegúrate de que dsoaws está seleccionado como BASE DE DATOS y, a continuación, selecciona Nueva consulta. Ejecuta la siguiente sentencia SQL para leer los archivos comprimidos (compression=gzip) y omitir la cabecera CSV (skip.header.line.count=1) de la parte superior de cada archivo. Tras ejecutar la sentencia SQL, comprueba que la tabla recién creada, amazon_reviews_tsv, aparece a la izquierda en Tablas:
CREATE EXTERNAL TABLE IF NOT EXISTS dsoaws.amazon_reviews_tsv(
marketplace string,
customer_id string,
review_id string,
product_id string,
product_parent string,
product_title string,
product_category string,
star_rating int,
helpful_votes int,
total_votes int,
vine string,
verified_purchase string,
review_headline string,
review_body string,
review_date string
) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
LINES TERMINATED BY '\n'
LOCATION 's3://data-science-on-aws/amazon-reviews-pds/tsv'
TBLPROPERTIES ('compressionType'='gzip', 'skip.header.line.count'='1')
Vamos a ejecutar una consulta de ejemplo como ésta para comprobar si todo funciona correctamente. Esta consulta producirá los resultados que se muestran en la tabla siguiente:
SELECT * FROM dsoaws.amazon_reviews_tsv WHERE product_category = 'Digital_Video_Download' LIMIT 10
| mercado | id_cliente | review_id | producto_id | título_producto | categoría_producto |
|---|---|---|---|---|---|
| US | 12190288 | R3FBDHSJD | BOOAYB23D | Iluminado | Descarga_de_vídeo_digital |
| ... | ... | ... | ... | ... | ... |
Actualiza las tablas de Athena a medida que llegan nuevos datos con AWS Glue Crawler
El siguiente código rastrea S3 cada noche a las 23:59 UTC y actualiza la tabla Athena a medida que llegan nuevos datos. Si añadimos otro archivo .tar.gz a S3, por ejemplo, veremos los nuevos datos en nuestras consultas Athena después de que el rastreador complete su ejecución programada:
glue = boto3.Session().client(service_name='glue', region_name=region)
create_response = glue.create_crawler(
Name='amazon_reviews_crawler',
Role=role,
DatabaseName='dsoaws',
Description='Amazon Customer Reviews Dataset Crawler',
Targets={
'CatalogTargets': [
{
'DatabaseName': 'dsoaws',
'Tables': [
'amazon_reviews_tsv',
]
}
]
},
Schedule='cron(59 23 * * ? *)', # run every night at 23:59 UTC
SchemaChangePolicy={
'DeleteBehavior': 'LOG'
},
RecrawlPolicy={
'RecrawlBehavior': 'CRAWL_EVERYTHING'
}
)
Crear una tabla basada en parquet en Athena
En un siguiente paso, mostraremos cómo podemos convertir fácilmente esos datos al formato de archivo columnar Apache Parquet para mejorar el rendimiento de las consultas. Parquet está optimizado para consultas basadas en columnas, como recuentos, sumas, medias y otras estadísticas de resumen basadas en la agregación, que se centran en los valores de las columnas frente a la información de las filas.
Al almacenar nuestros datos en formato de columnas, Parquet realiza lecturas secuenciales para las estadísticas de resumen de columnas. Esto da como resultado un acceso a los datos mucho más eficiente y una "simpatía mecánica" frente a hacer que el controlador de disco salte de fila en fila y tenga que volver a buscar para recuperar los datos de la columna. Si realizamos cualquier tipo de análisis de datos a gran escala, deberíamos utilizar un formato de archivo columnar como Parquet. Discutiremos las ventajas de Parquet en la sección de rendimiento.
Nota
Aunque ya tenemos los datos en formato Parquet del conjunto de datos público, creemos que crear una tabla Parquet es un tema lo suficientemente importante como para demostrarlo en este libro.
De nuevo, asegúrate de que dsoaws está seleccionado como BASE DE DATOS y, a continuación, selecciona Nueva consulta y ejecuta la siguiente sentencia SQL CREAR TABLA COMO (CTAS):
CREATE TABLE IF NOT EXISTS dsoaws.amazon_reviews_parquet
WITH (format = 'PARQUET', \
external_location = 's3://<BUCKET>/amazon-reviews-pds/parquet', \
partitioned_by = ARRAY['product_category']) AS
SELECT marketplace,
customer_id,
review_id,
product_id,
product_parent,
product_title,
star_rating,
helpful_votes,
total_votes,
vine,
verified_purchase,
review_headline,
review_body,
CAST(YEAR(DATE(review_date)) AS INTEGER) AS year,
DATE(review_date) AS review_date,
product_category
FROM dsoaws.amazon_reviews_tsv
Como podemos ver en la consulta, también estamos añadiendo una nueva columna year a nuestro conjunto de datos, convirtiendo la cadena review_date a un formato de fecha y, a continuación, extrayendo el año de la fecha. Vamos a almacenar el valor del año como un número entero. Tras ejecutar la consulta CTAS, deberíamos ver que la tabla recién creada amazon_reviews_parquet aparece también a la izquierda, debajo de Tablas. Como último paso, tenemos que cargar las particiones Parquet. Para ello, basta con ejecutar el siguiente comando SQL:
MSCK REPAIR TABLE amazon_reviews_parquet;
Nota
Podemos automatizar el comando MSCK REPAIR TABLE para cargar las particiones tras la ingesta de datos desde cualquier gestor de flujo de trabajo (o utilizar una función Lambda que se ejecute cuando se carguen nuevos datos en S3).
Podemos volver a ejecutar nuestra consulta de ejemplo para comprobar si todo funciona correctamente:
SELECT * FROM dsoaws.amazon_reviews_parquet WHERE product_category = 'Digital_Video_Download' LIMIT 10
Ambas tablas también tienen entradas de metadatos en el Catálogo de Datos AWS Glue compatible con Hive Metastore. Estos metadatos definen el esquema utilizado por muchos motores de consulta y procesamiento de datos, como Amazon EMR, Athena, Redshift, Kinesis, SageMaker y Apache Spark.
En sólo unos pasos, hemos configurado Amazon Athena para transformar los archivos del conjunto de datos TSV en el formato de archivo Apache Parquet. La consulta sobre los archivos Parquet finalizó en una fracción del tiempo en comparación con la consulta sobre los archivos TSV. Aceleramos el tiempo de respuesta de nuestra consulta aprovechando el formato de archivo Parquet columnar y el esquema de partición product_category .
Ingesta continua de nuevos datos con AWS Glue Crawler
Siempre llegan nuevos datos de las aplicaciones a , y necesitamos una forma de registrar estos nuevos datos en nuestro sistema con fines analíticos y de formación de modelos. AWS Glue proporciona sofisticadas transformaciones de limpieza de datos y aprendizaje automático, incluida la deduplicación "difusa" de registros. Una forma de registrar los nuevos datos de S3 en nuestro Catálogo de Datos de AWS Glue es con un Glue Crawler, como se muestra en la Figura 4-6.
Figura 4-6. Ingerir y registrar datos de varias fuentes de datos con AWS Glue Crawler.
Podemos activar el rastreador periódicamente según una programación o, por ejemplo, con un activador de S3. El siguiente código crea el rastreador y programa la ingesta de nuevas carpetas (prefijos) de S3 cada noche a las 23:59 UTC:
create_response = glue.create_crawler(
Name='amazon_reviews_crawler',
Role=role,
DatabaseName='dsoaws',
Description='Amazon Customer Reviews Dataset Crawler',
Targets={
'CatalogTargets': [
{
'DatabaseName': 'dsoaws',
'Tables': [
'amazon_reviews_tsv',
]
}
]
},
Schedule='cron(59 23 * * ? *)',
SchemaChangePolicy={
'DeleteBehavior': 'LOG'
},
RecrawlPolicy={
'RecrawlBehavior': 'CRAWL_NEW_FOLDERS_ONLY'
}
)
Esto supone que estamos almacenando datos nuevos en carpetas nuevas. Normalmente, utilizamos un prefijo S3 que incluye el año, el mes, el día, la hora, el cuarto de hora, etc. Por ejemplo, podemos almacenar los registros de la aplicación en carpetas S3 cada hora con la siguiente convención de nomenclatura para el prefijo S3: s3://<S3_BUCKET>/<YEAR>/<MONTH>/<DAY>/<HOUR>/. Si queremos rastrear todos los datos, podemos utilizar CRAWL_EVERYTHING para nuestro RecrawlBehavior. Podemos cambiar la programación utilizando un desencadenador cron() diferente. También podemos añadir un segundo activador para iniciar un trabajo ETL para transformar y cargar nuevos datos cuando el Glue Crawler programado alcance el estado SUCCEEDED.
Construye una casa en el lago con Amazon Redshift Spectrum
Una de las diferencias fundamentales entre los lagos de datos y los almacenes de datos es que, mientras que en nuestro lago de datos ingerimos y almacenamos enormes cantidades de datos brutos sin procesar, normalmente sólo cargamos en el almacén de datos una fracción de nuestros datos recientes. Dependiendo de nuestro caso de uso empresarial y analítico, podría tratarse de datos de los últimos dos meses, un año o quizá los últimos dos años. Supongamos que queremos tener los dos últimos años de nuestro conjunto de datos de opiniones de clientes de Amazon en un almacén de datos para analizar el comportamiento interanual de los clientes y las tendencias de las opiniones. Para ello utilizaremos Amazon Redshift como almacén de datos.
Amazon Redshift es un almacén de datos totalmente administrado que nos permite ejecutar consultas analíticas complejas contra petabytes de datos estructurados, semiestructurados y JSON. Nuestras consultas se distribuyen y paralelizan en varios nodos. A diferencia de las bases de datos relacionales, que están optimizadas para almacenar datos en filas y sirven principalmente para aplicaciones transaccionales, Amazon Redshift implementa el almacenamiento de datos en columnas, que está optimizado para aplicaciones analíticas en las que nos interesan principalmente los datos dentro de las columnas individuales.
Amazon Redshift también incluye Amazon Redshift Spectrum, que nos permite ejecutar directamente consultas SQL desde Amazon Redshift contra exabytes de datos no estructurados en nuestro lago de datos de Amazon S3 sin necesidad de mover físicamente los datos. Amazon Redshift Spectrum forma parte de la arquitectura Lake House que unifica nuestro lago de datos S3 y el almacén de datos de Amazon Redshift, incluida la seguridad compartida y el control de acceso basado en filas y columnas. Amazon Redshift Spectrum es compatible con varios marcos de almacenamiento de código abierto, incluidos Apache Hudi y Delta Lake.
Dado que Amazon Redshift Spectrum escala automáticamente los recursos informáticos necesarios en función de la cantidad de datos que se recuperan, las consultas contra Amazon S3 se ejecutan con rapidez, independientemente del tamaño de nuestros datos. Amazon Redshift Spectrum utilizará filtros pushdown, filtros bloom y vistas materializadas para reducir el tiempo de búsqueda y aumentar el rendimiento de las consultas en almacenes de datos externos como S3. Más adelante, en "Reducir costes y aumentar el rendimiento", trataremos más consejos sobre el rendimiento .
Amazon Redshift Spectrum convierte la ETL tradicional en extracción-carga-transformación (ELT) transformando y limpiando los datos después de cargarlos en Amazon Redshift. Utilizaremos Amazon Redshift Spectrum para acceder a nuestros datos en S3 y, a continuación, mostraremos cómo combinar los datos almacenados en Amazon Redshift con los datos que aún se encuentran en S3.
Esto puede sonar similar al enfoque que mostramos anteriormente con Amazon Athena, pero ten en cuenta que en este caso mostramos cómo nuestro equipo de inteligencia empresarial puede enriquecer sus consultas con datos que no están almacenados en el propio almacén de datos. Una vez que tengamos nuestro clúster Redshift establecido y configurado, podemos navegar a la Consola de AWS y a Amazon Redshift y, a continuación, hacer clic en Editor de consultas para ejecutar comandos.
Podemos aprovechar nuestra tabla creada previamente en Amazon Athena con sus metadatos e información de esquema almacenados en el Catálogo de datos de AWS Glue para acceder a nuestros datos en S3 a través de Amazon Redshift Spectrum. Todo lo que tenemos que hacer es crear un esquema externo en Amazon Redshift, apuntarlo a nuestro Catálogo de Datos de AWS Glue y apuntar Amazon Redshift a la base de datos que hemos creado.
En el Editor de consultas de Amazon Redshift (o a través de cualquier otro cliente SQL ODBC/JDBC que prefiramos utilizar), ejecuta el siguiente comando:
CREATE EXTERNAL SCHEMA IF NOT EXISTS athena FROM DATA CATALOG
DATABASE 'dsoaws'
IAM_ROLE '<IAM-ROLE>'
CREATE EXTERNAL DATABASE IF NOT EXISTS
Con este comando, estamos creando un nuevo esquema en Amazon Redshift llamado athena para resaltar el acceso a los datos que configuramos a través de nuestras tablas en Amazon Athena:
-
FROM DATA CATALOGindica que la base de datos externa está definida en el Catálogo de datos de AWS Glue. -
DATABASEse refiere a nuestra base de datos creada previamente en el Catálogo de Datos de AWS Glue. -
IAM_ROLEtiene que apuntar a un Nombre de Recurso de Amazon (ARN) para un rol IAM que nuestro clúster utiliza para la autenticación y autorización.
IAM es el servicio de AWS Identity and Access Management, que nos permite administrar y controlar el acceso a los servicios y recursos de AWS en nuestra cuenta. Con un rol IAM, podemos especificar los permisos que se conceden a un usuario o servicio. En este ejemplo, el rol IAM debe tener como mínimo permiso para realizar una operación LIST en el bucket de Amazon S3 al que se va a acceder y una operación GET en los objetos de Amazon S3 que contiene el bucket. Si la base de datos externa está definida en un catálogo de datos de Amazon Athena, el rol IAM debe tener permiso para acceder a Athena, a menos que se especifique CATALOG_ROLE. Entraremos en más detalles sobre IAM en una sección posterior de este capítulo, cuando hablemos de cómo podemos asegurar nuestros datos.
Si ahora seleccionamos athena en el menú desplegable Esquema del Editor de consultas de Amazon Redshift, podemos ver que aparecen nuestras dos tablas, amazon_reviews_tsv y amazon_reviews_parquetque hemos creado con Amazon Athena. Vamos a ejecutar de nuevo una consulta de ejemplo para asegurarnos de que todo funciona. En el Editor de consultas, ejecuta el siguiente comando:
SELECT
product_category,
COUNT(star_rating) AS count_star_rating
FROM
athena.amazon_reviews_tsv
GROUP BY
product_category
ORDER BY
count_star_rating DESC
Deberíamos ver resultados similares a los de la tabla siguiente:
| categoría_producto | conteo_estrellas |
|---|---|
| Libros | 19531329 |
| Compra_de_Ebook_digital | 17622415 |
| Inalámbrico | 9002021 |
| ... | ... |
Así, con un solo comando, ahora tenemos acceso y podemos consultar nuestro lago de datos S3 desde Amazon Redshift sin mover ningún dato a nuestro almacén de datos. Este es el poder de Amazon Redshift Spectrum.
Pero ahora, copiemos realmente algunos datos de S3 a Amazon Redshift. Vamos a extraer datos de opiniones de clientes del año 2015.
En primer lugar, creamos otro esquema de Amazon Redshift llamado redshift con el siguiente comando SQL:
CREATE SCHEMA IF NOT EXISTS redshift
A continuación, crearemos una nueva tabla que represente los datos de las opiniones de nuestros clientes. También añadiremos una nueva columna y añadiremos year a nuestra tabla:
CREATE TABLE IF NOT EXISTS redshift.amazon_reviews_tsv_2015(
marketplace varchar(2) ENCODE zstd,
customer_id varchar(8) ENCODE zstd,
review_id varchar(14) ENCODE zstd,
product_id varchar(10) ENCODE zstd DISTKEY,
product_parent varchar(10) ENCODE zstd,
product_title varchar(400) ENCODE zstd,
product_category varchar(24) ENCODE raw,
star_rating int ENCODE az64,
helpful_votes int ENCODE zstd,
total_votes int ENCODE zstd,
vine varchar(1) ENCODE zstd,
verified_purchase varchar(1) ENCODE zstd,
review_headline varchar(128) ENCODE zstd,
review_body varchar(65535) ENCODE zstd,
review_date varchar(10) ENCODE bytedict,
year int ENCODE az64) SORTKEY (product_category)
En la sección de rendimiento, profundizaremos en los atributos SORTKEY, DISTKEY y ENCODE. Por ahora, copiemos los datos de S3 en nuestra nueva tabla de Amazon Redshift y ejecutemos algunas consultas de ejemplo.
Para estas inserciones masivas, podemos utilizar un comando COPY o un comando INSERT INTO. En general, se prefiere el comando COPY, ya que carga datos en paralelo y de forma más eficiente desde Amazon S3, u otras fuentes de datos compatibles.
Si estamos cargando datos o un subconjunto de datos de una tabla en otra, podemos utilizar el comando INSERT INTO con una cláusula SELECT para una inserción de datos de alto rendimiento. Como vamos a cargar nuestros datos de la tabla athena.amazon_reviews_tsv, vamos a elegir esta opción:
INSERT
INTO
redshift.amazon_reviews_tsv_2015
SELECT
marketplace,
customer_id,
review_id,
product_id,
product_parent,
product_title,
product_category,
star_rating,
helpful_votes,
total_votes,
vine,
verified_purchase,
review_headline,
review_body,
review_date,
CAST(DATE_PART_YEAR(TO_DATE(review_date,
'YYYY-MM-DD')) AS INTEGER) AS year
FROM
athena.amazon_reviews_tsv
WHERE
year = 2015
Utilizamos una conversión de fechas para analizar el año de nuestra columna review_date y almacenarlo en una columna independiente year, que luego utilizamos para filtrar los registros de 2015. Este es un ejemplo de cómo podemos simplificar las tareas ETL, ya que ponemos nuestra lógica de transformación de datos directamente en una consulta SELECT e ingerimos el resultado en Amazon Redshift.
Otra forma de optimizar nuestras tablas en sería crearlas como una secuencia de tablas de series temporales, sobre todo cuando nuestros datos tienen un periodo de retención fijo. Supongamos que queremos almacenar datos de los dos últimos años (24 meses) en nuestro almacén de datos y actualizarlos con datos nuevos una vez al mes.
Si creamos una tabla por mes, podemos eliminar fácilmente los datos antiguos ejecutando un comando DROP TABLE en la tabla correspondiente. Este enfoque es mucho más rápido que ejecutar un proceso DELETE a gran escala y también nos ahorra tener que ejecutar un proceso VACUUM posterior para recuperar espacio y recurrir a las filas.
Para combinar los resultados de las consultas entre tablas, podemos utilizar una vista UNION ALL. Del mismo modo, cuando necesitemos eliminar datos antiguos, eliminaremos la tabla eliminada de la vista UNION ALL.
He aquí un ejemplo de una vista UNION ALL a través de dos tablas con opiniones de clientes de los años 2014 y 2015, suponiendo que tenemos una tabla cada una para los datos de 2014 y 2015. La siguiente tabla muestra los resultados de la consulta:
SELECT
product_category,
COUNT(star_rating) AS count_star_rating,
year
FROM
redshift.amazon_reviews_tsv_2014
GROUP BY
redshift.amazon_reviews_tsv_2014.product_category,
year
UNION
ALL SELECT
product_category,
COUNT(star_rating) AS count_star_rating,
year
FROM
redshift.amazon_reviews_tsv_2015
GROUP BY
redshift.amazon_reviews_tsv_2015.product_category,
year
ORDER BY
count_star_rating DESC,
year ASC
| categoría_producto | conteo_estrellas | año |
|---|---|---|
| Compra_de_Ebook_digital | 6615914 | 2014 |
| Compra_de_Ebook_digital | 4533519 | 2015 |
| Libros | 3472631 | 2014 |
| Inalámbrico | 2998518 | 2015 |
| Inalámbrico | 2830482 | 2014 |
| Libros | 2808751 | 2015 |
| Ropa | 2369754 | 2015 |
| Inicio | 2172297 | 2015 |
| Ropa | 2122455 | 2014 |
| Inicio | 1999452 | 2014 |
Ahora, vamos a ejecutar una consulta y combinar los datos de Amazon Redshift con los datos que aún están en S3. Tomemos los datos de la consulta anterior para los años 2015 y 2014 y consultemos Athena/S3 para los años 2013-1995 ejecutando este comando:
SELECT
year,
product_category,
COUNT(star_rating) AS count_star_rating
FROM
redshift.amazon_reviews_tsv_2015
GROUP BY
redshift.amazon_reviews_tsv_2015.product_category,
year
UNION
ALL SELECT
year,
product_category,
COUNT(star_rating) AS count_star_rating
FROM
redshift.amazon_reviews_tsv_2014
GROUP BY
redshift.amazon_reviews_tsv_2014.product_category,
year
UNION
ALL SELECT
CAST(DATE_PART_YEAR(TO_DATE(review_date,
'YYYY-MM-DD')) AS INTEGER) AS year,
product_category,
COUNT(star_rating) AS count_star_rating
FROM
athena.amazon_reviews_tsv
WHERE
year <= 2013
GROUP BY
athena.amazon_reviews_tsv.product_category,
year
ORDER BY
product_category ASC,
year DESC
| año | categoría_producto | conteo_estrellas |
|---|---|---|
| 2015 | Ropa | 4739508 |
| 2014 | Ropa | 4244910 |
| 2013 | Ropa | 854813 |
| 2012 | Ropa | 273694 |
| 2011 | Ropa | 109323 |
| 2010 | Ropa | 57332 |
| 2009 | Ropa | 42967 |
| 2008 | Ropa | 33761 |
| 2007 | Ropa | 25986 |
| 2006 | Ropa | 7293 |
| 2005 | Ropa | 3533 |
| 2004 | Ropa | 2357 |
| 2003 | Ropa | 2147 |
| 2002 | Ropa | 907 |
| 2001 | Ropa | 5 |
| 2000 | Ropa | 6 |
| 2015 | Automóvil | 2609750 |
| 2014 | Automóvil | 2350246 |
Exportar datos de Amazon Redshift a S3 Data Lake como Parquet
Amazon Redshift Data Lake Export nos ofrece la posibilidad de descargar el resultado de una consulta de Amazon Redshift a nuestro lago de datos S3 en el formato de archivo columnar optimizado Apache Parquet. Esto nos permite compartir cualquier transformación y enriquecimiento de datos que hayamos realizado en Amazon Redshift de vuelta a nuestro lago de datos S3 en un formato abierto. Los datos descargados se registran automáticamente en el Catálogo de Datos de AWS Glue para ser utilizados por cualquier motor de consulta compatible con Hive Metastore, incluidos Amazon Athena, EMR, Kinesis, SageMaker y Apache Spark.
Podemos especificar una o varias columnas de partición para que los datos descargados se particionen automáticamente en carpetas en nuestro bucket de Amazon S3. Por ejemplo, podemos elegir descargar nuestros datos de opiniones de clientes y particionarlos por product_category.
Podemos simplemente ejecutar el siguiente comando SQL para descargar nuestros datos de opiniones de clientes de 2015 en formato de archivo Parquet en S3, particionados por product_category:
UNLOAD (
'SELECT marketplace, customer_id, review_id, product_id, product_parent,
product_title, product_category, star_rating, helpful_votes, total_votes,
vine, verified_purchase, review_headline, review_body, review_date, year
FROM redshift.amazon_reviews_tsv_2015')
TO 's3://data-science-on-aws/amazon-reviews-pds/parquet-from-redshift/2015'
IAM_ROLE '<IAM_ROLE>'
PARQUET PARALLEL ON
PARTITION BY (product_category)
Podemos volver a utilizar la herramienta CLI de AWS para listar la carpeta S3 y ver nuestros datos descargados de 2015 en formato Parquet:
aws s3 ls s3://data-science-on-aws/amazon-reviews-pds/parquet-from-redshift/2015
Elige entre Amazon Athena y Amazon Redshift
Amazon Athena es la opción preferida cuando se ejecutan consultas SQL ad hoc sobre datos almacenados en Amazon S3. No requiere que configuremos ni administremos ningún recurso de infraestructura: no necesitamos mover ningún dato. Admite datos estructurados, no estructurados y semiestructurados. Con Athena, definimos un "esquema en lectura": básicamente, iniciamos sesión, creamos una tabla y empezamos a ejecutar consultas.
Amazon Redshift está pensado para el análisis moderno de datos en petabytes de datos estructurados. Aquí, necesitamos tener un "esquema en escritura" predefinido. A diferencia de Athena sin servidor, Amazon Redshift requiere que creemos un clúster (recursos informáticos y de almacenamiento), ingiramos los datos y construyamos tablas antes de que podamos empezar a consultar, pero atiende al rendimiento y la escala. Por tanto, para datos altamente relacionales con naturaleza transaccional (los datos se actualizan), cargas de trabajo que implican uniones complejas o requisitos de latencia de subsegundos, Amazon Redshift es la opción adecuada.
Athena y Amazon Redshift están optimizados para cargas de trabajo analíticas de lectura intensiva; no sustituyen a las bases de datos relacionales de escritura intensiva, como Amazon Relational Database Service (RDS) y Aurora. A alto nivel, utiliza Athena para análisis exploratorios y depuración operativa; utiliza Amazon Redshift para informes y cuadros de mando críticos para el negocio.
Reduce los costes y aumenta el rendimiento
En esta sección, queremos ofrecer algunos consejos y trucos para reducir el coste y aumentar el rendimiento durante la ingesta de datos, incluidos los formatos de archivo, las particiones, la compresión y las claves de clasificación/distribución. También demostraremos cómo utilizar Amazon S3 Intelligent-Tiering para reducir nuestra factura de almacenamiento.
S3 Tiering Inteligente
Nosotros presentamos Amazon S3 en este capítulo como un servicio de almacenamiento escalable y duradero para construir conjuntos de datos compartidos, como los lagos de datos en la nube. Y aunque en este libro mantenemos el uso de S3 bastante sencillo, en realidad el servicio nos ofrece diversas opciones para optimizar nuestro coste de almacenamiento a medida que crecen nuestros datos.
Dependiendo de los patrones de frecuencia de acceso a nuestros datos y de las necesidades del acuerdo de nivel de servicio (SLA), podemos elegir entre varias clases de almacenamiento de Amazon S3. La tabla 4-1 compara las clases de almacenamiento de Amazon S3 en términos de frecuencia de acceso a los datos y tiempo de recuperación de los mismos.
| De acceso frecuente | Al acceso poco frecuente | ||||
|---|---|---|---|---|---|
| S3 Estándar (clase de almacenamiento por defecto) | S3 Tiering Inteligente | Norma S3-IA | S3 Una Zona-IA | Glaciar de Amazon S3 | Archivo Profundo Glaciar de Amazon S3 |
| Almacenamiento de uso general Datos activos frecuentemente Acceso en milisegundos |
Datos con patrones de acceso patrones de acceso Acceso en milisegundos Opta por el archivado automático |
Con poca frecuencia datos de acceso infrecuente (AI) Acceso en milisegundos |
Menor durabilidad (una zona Zvailability) Datos recreables Acceso en milisegundos |
Archivar datos Acceso en minutos u horas |
Datos de archivo a largo plazo Acceso en horas |
Pero, ¿cómo sabemos qué objetos mover? Imagina que nuestro lago de datos de S3 ha crecido con el tiempo y posiblemente tenemos miles de millones de objetos repartidos en varios buckets de S3 en la clase de almacenamiento S3 Estándar. Algunos de esos objetos son extremadamente importantes, mientras que a otros quizá no hemos accedido en meses o incluso años. Aquí es donde entra en juego S3 Intelligent-Tiering.
Amazon S3 Intelligent-Tiering optimiza automáticamente nuestro coste de almacenamiento para los datos con patrones de acceso cambiantes, moviendo los objetos entre la capa de acceso frecuente optimizada para el uso frecuente de los datos y la capa de acceso infrecuente de menor coste optimizada para los datos de menor acceso. Intelligent-Tiering monitorea nuestros patrones de acceso y los niveles automáticos a un nivel de objeto granular, sin impacto en el rendimiento ni sobrecarga operativa.
Particiones de parqué y compresión
Athena admite el formato columnar Parquet para cargas de trabajo analíticas a gran escala. Parquet permite las siguientes optimizaciones de rendimiento para nuestras consultas:
- Particiones y flexiones
- Las particiones son agrupaciones físicas de datos en el disco para que coincidan con nuestros patrones de consulta (es decir,
SELECT * FROM reviews WHERE product_category='Books'). Los motores de consulta modernos, como Athena, Amazon Redshift y Apache Spark, "empujan" elWHEREhacia el sistema de almacenamiento físico para permitir que el controlador del disco busque una vez y lea todos los datos relevantes en un solo escaneo, sin saltar aleatoriamente a diferentes áreas del disco. Esto mejora el rendimiento de la consulta incluso con unidades de estado sólido (SSD), que tienen un tiempo de búsqueda menor que los discos tradicionales basados en soportes. - Codificación/compresión de diccionarios
- Cuando un pequeño número de valores categóricos se almacenan juntos en el disco (por ejemplo,
product_category, que tiene 43 valores totales en nuestro conjunto de datos), los valores pueden comprimirse en un pequeño número de bits para representar cada valor (por ejemplo,Books,Lawn_and_Garden,Software, etc.) en lugar de almacenar toda la cadena. - Compresión de tipo
- Cuando se almacenan juntos en disco valores de tipo similar (es decir, Cadena, Fecha, Entero), los valores se pueden comprimir juntos: (Cadena, Cadena), (Fecha, Fecha), (Entero, Entero). Esta compresión es más eficaz que si los valores se almacenaran por separado en el disco de forma ordenada: (Cadena, Fecha, Entero), (Cadena, Fecha, Entero)
- Agregaciones vectorizadas
- Como los valores de las columnas se almacenan juntos en el disco, el controlador de disco sólo necesita realizar una búsqueda en el disco para encontrar el principio de los datos. A partir de ese punto, escaneará los datos para realizar la agregación. Además, los chips/procesadores modernos ofrecen instrucciones de vectorización de alto rendimiento para realizar cálculos sobre grandes cantidades de datos, en lugar de hacer entrar y salir datos de las distintas cachés de datos (L1, L2) o de la memoria principal.
Mira un ejemplo de formato de datos en filas frente a datos en columnas en la Figura 4-7.
Figura 4-7. Utilizando un formato de datos en columnas como Parquet, podemos aplicar varias optimizaciones de rendimiento para la ejecución de consultas y la codificación de datos.
Diseño y compresión de tablas de Amazon Redshift
Aquí es la sentencia CREATE TABLE que utilizamos para crear las tablas de Amazon Redshift:
CREATE TABLE IF NOT EXISTS redshift.amazon_reviews_tsv_2015(
marketplace varchar(2) ENCODE zstd,
customer_id varchar(8) ENCODE zstd,
review_id varchar(14) ENCODE zstd,
product_id varchar(10) ENCODE zstd DISTKEY,
product_parent varchar(9) ENCODE zstd,
product_title varchar(400) ENCODE zstd,
product_category varchar(24) ENCODE raw,
star_rating int ENCODE az64,
helpful_votes int ENCODE zstd,
total_votes int ENCODE zstd,
vine varchar(1) ENCODE zstd,
verified_purchase varchar(1) ENCODE zstd,
review_headline varchar(128) ENCODE zstd,
review_body varchar(65535) ENCODE zstd,
review_date varchar(10) ENCODE bytedict,
year int ENCODE az64) SORTKEY (product_category)
Cuando creamos una tabla, podemos especificar una o varias columnas como SORTKEY. Amazon Redshift almacena los datos en disco ordenados según SORTKEY. Por tanto, podemos optimizar nuestra tabla eligiendo un SORTKEY que refleje los tipos de consulta que utilizamos con más frecuencia. Si realizamos muchas consultas sobre datos recientes, podemos especificar una columna de fecha y hora como SORTKEY. Si realizamos con frecuencia consultas basadas en el filtrado por rango o igualdad sobre una columna, debemos elegir esa columna como SORTKEY. Como en el próximo capítulo vamos a realizar muchas consultas filtrando sobre product_category, elijamos esa como nuestra SORTKEY.
Consejo
Amazon Redshift Advisor recomienda continuamente SORTKEYs para las tablas consultadas con frecuencia. Advisor generará un comando ALTER TABLE que ejecutaremos sin tener que volver a crear las tablas, sin afectar a las consultas concurrentes de lectura y escritura. Ten en cuenta que Advisor no proporciona recomendaciones si no ve suficientes datos (consultas) o si los beneficios son relativamente pequeños.
También podemos definir un estilo de distribución para cada tabla. Cuando cargamos datos en una tabla, Amazon Redshift distribuye las filas de la tabla entre nuestros nodos de clúster según el estilo de distribución de la tabla. Cuando realizamos una consulta, el optimizador de consultas redistribuye las filas entre los nodos del clúster según sea necesario para realizar las uniones y agregaciones. Así que nuestro objetivo debe ser optimizar la distribución de las filas para minimizar los movimientos de datos. Hay tres estilos de distribución entre los que podemos elegir:
KEYdistribución- Distribuye las filas según los valores de una columna.
ALLdistribución- Distribuye una copia de toda la tabla a cada nodo.
EVENdistribución- Las filas se distribuyen por todos los nodos de forma rotatoria, que es el estilo de distribución por defecto.
Para nuestra tabla, hemos elegido KEY distribución basada en product_id, ya que esta columna tiene una cardinalidad alta, muestra una distribución uniforme y puede utilizarse para unir con otras tablas.
En cualquier momento, podemos utilizar EXPLAIN en nuestras consultas de Amazon Redshift para asegurarnos de que se utilizan DISTKEY y SORTKEY. Si nuestros patrones de consulta cambian con el tiempo, puede que queramos volver a considerar el cambio de estas claves.
Además, utilizamos la compresión para la mayoría de las columnas con el fin de reducir la huella de almacenamiento total y reducir nuestro coste. La tabla 4-2 analiza la compresión utilizada para cada columna de Amazon Redshift en nuestro esquema.
| Columna | Tipo de datos | Codificación | Explicación |
|---|---|---|---|
| mercado | varchar(2) | zstd | Cardinalidad baja, demasiado pequeña para una mayor sobrecarga de compresión |
| id_cliente | varchar(8) | zstd | Cardinalidad alta, relativamente pocos valores repetidos |
| review_id | varchar(14) | zstd | Único, cardinalidad ilimitada, sin valores repetidos |
| producto_id | varchar(10) | zstd | Cardinalidad no limitada, número relativamente bajo de valores repetidos |
| padre_producto | varchar(10) | zstd | Cardinalidad ilimitada, número relativamente bajo de palabras repetidas |
| título_producto | varchar(400) | zstd | Cardinalidad ilimitada, número relativamente bajo de palabras repetidas |
| categoría_producto | varchar(24) | en bruto | Cardinalidad baja, muchos valores repetidos, pero la primera clave SORT es bruta |
| clasificación_estrella | int | az64 | Cardinalidad baja, muchos valores repetidos |
| votos_útiles | int | zstd | Cardinalidad relativamente alta |
| total_votos | int | zstd | Cardinalidad relativamente alta |
| vid | varchar(1) | zstd | Cardinalidad baja, demasiado pequeña para incurrir en una mayor sobrecarga de compresión |
| compra_verificada | varchar(1) | zstd | Cardinalidad baja, demasiado pequeña para incurrir en una mayor sobrecarga de compresión |
| titular_reseña | varchar(128) | zstd | Texto de longitud variable, cardinalidad alta, palabras poco repetidas |
| cuerpo_examen | varchar(65535) | zstd | Texto de longitud variable, cardinalidad alta, palabras poco repetidas |
| fecha_revisión | varchar(10) | portedict | Longitud fija, cardinalidad relativamente baja, muchos valores repetidos |
| año | int | az64 | Cardinalidad baja, muchos valores repetidos |
Nota
Aunque en el director general de AWS, Andy Jassy, sostiene que "no existe un algoritmo de compresión para la experiencia", sí existe un algoritmo de compresión para los datos. La compresión es una poderosa herramienta para el creciente mundo de los big data. Todas las herramientas modernas de procesamiento de big data son compatibles con la compresión, incluidos Amazon Athena, Redshift, Parquet, pandas y Apache Spark. Utilizar la compresión en valores pequeños como varchar(1) puede no mejorar el rendimiento. Sin embargo, debido al soporte nativo de hardware, el uso de la compresión casi no presenta inconvenientes.
zstd es un algoritmo de compresión genérico que funciona con muchos tipos de datos y tamaños de columna diferentes. Los campos star_rating y year se ajustan a la codificación por defecto az64 que se aplica a la mayoría de los campos numéricos y de fecha. Para la mayoría de las columnas, ganamos rápidamente si utilizamos la codificación por defecto az64 para los números enteros y anulamos la codificación por defecto lzo en favor de la codificación flexible zstd para todo lo demás, incluido el texto.
Estamos utilizando bytedict para que review_date realice la codificación de diccionario en las fechas basadas en cadenas (YYYY-MM-DD). Aunque aparentemente tiene un gran número de valores únicos, review_date contiene en realidad un pequeño número de valores únicos porque sólo hay ~7.300 (365 días al año × 20 años) días en un período de 20 años. Esta cardinalidad es lo suficientemente baja como para capturar todas las fechas posibles en unos pocos bits, en lugar de utilizar un varchar(10) completo para cada fecha.
Aunque product_category es un gran candidato para la codificación del diccionario bytedict, es nuestro primer (y único, en este caso) SORTKEY. Como buena práctica de rendimiento, el primer diccionario SORTKEY no debe comprimirse.
Aunque marketplace, product_category, vine, y verified_purchase parecen buenos candidatos para bytedict, son demasiado pequeños para beneficiarse de la sobrecarga adicional. Por ahora, los dejamos como zstd.
Si tenemos una tabla existente de Amazon Redshift para optimizar, podemos ejecutar el comando ANALYZE COMPRESSION en Amazon Redshift para generar un informe de codificaciones de compresión sugeridas, como se indica a continuación:
ANALYZE COMPRESSION redshift.customer_reviews_tsv_2015
El resultado será una tabla como la siguiente, que muestra el % de mejora en la compresión si cambiamos a otra codificación:
| Columna | Codificación | Reducción estimada (%) |
|---|---|---|
marketplace |
zstd |
90.84 |
customer_id |
zstd |
38.88 |
review_id |
zstd |
36.56 |
product_id |
zstd |
44.15 |
product_parent |
zstd |
44.03 |
product_title |
zstd |
30.72 |
product_category |
zstd |
99.95 |
star_rating |
az64 |
0 |
helpful_votes |
zstd |
47.58 |
total_votes |
zstd |
39.75 |
vine |
zstd |
85.03 |
verified_purchase |
zstd |
73.09 |
review_headline |
zstd |
30.55 |
review_body |
zstd |
32.19 |
review_date |
bytedict |
64.1 |
year |
az64 |
0 |
Realizamos este análisis en una versión de CREATE TABLE que no especificaba ningún atributo de ENCODE. Por defecto, Amazon Redshift utilizará az64 para los datos numéricos/fechas y lzo para todo lo demás (de ahí la ganancia del 0% para las sugerencias de az64 ). También podemos utilizar la sentencia ALTER TABLE para cambiar la compresión utilizada para cada columna.
Ten en cuenta que sólo son sugerencias y que no siempre son adecuadas para nuestro entorno específico. Deberíamos probar diferentes codificaciones para nuestro conjunto de datos y consultar la tabla STV_BLOCKLIST para comparar el % de reducción en el número físico de bloques. Por ejemplo, el analizador recomienda utilizar zstd para nuestro SORTKEY, product_category, pero nuestra experiencia demuestra que el rendimiento de la consulta se resiente cuando comprimimos el SORTKEY. Estamos utilizando el espacio extra en disco para mejorar el rendimiento de nuestra consulta.
Amazon Redshift soporta la optimización automática de tablas y otras capacidades de autoajuste que aprovechan el aprendizaje automático para optimizar el rendimiento máximo y adaptarse a las cargas de trabajo cambiantes. Las optimizaciones de rendimiento incluyen eliminaciones automáticas por vacío, gestión inteligente de la carga de trabajo, ordenación automática de tablas y selección automática de claves de ordenación de distribución y .
Utilizar filtros Bloom para mejorar el rendimiento de las consultas
Amazon Redshift es un motor de consulta distribuido y S3 es un almacén de objetos distribuido. Los sistemas distribuidos constan de muchas instancias de clúster. Para mejorar el rendimiento de las consultas distribuidas, necesitamos minimizar el número de instancias que se exploran y la cantidad de datos transferidos entre las instancias.
Los filtros de Bloom, estructuras de datos probabilísticas y eficientes en memoria, ayudan a responder a la pregunta: "¿Contiene esta instancia de cluster específica datos que podrían incluirse en los resultados de la consulta?" Los filtros de Bloom responden con un NO definitivo o con un TAL VEZ. Si el filtro de bloom responde con un NO, el motor omitirá por completo esa instancia de cluster y escaneará las instancias restantes en las que el filtro de bloom haya respondido con un TAL VEZ.
Al filtrar las filas de datos que no coinciden con la consulta dada, los filtros bloom producen enormes ganancias de rendimiento en las consultas de unión. Y como el filtrado bloom se produce cerca de la fuente de datos, se minimiza la transferencia de datos entre los nodos del clúster distribuido durante las consultas join. En última instancia, esto aumenta el rendimiento de las consultas para almacenes de datos como S3.
En realidad, Amazon Redshift Spectrum crea y administra automáticamente filtros Bloom en datos externos como S3, pero debemos ser conscientes de su importancia para mejorar el rendimiento de las consultas en almacenes de datos distribuidos. Los filtros Bloom son un patrón utilizado en toda la informática distribuida, incluidos los motores de consulta distribuidos.
Vistas materializadas en Amazon Redshift Spectrum
Vistas materializadas proporcionan un rendimiento de consulta repetible y predecible en fuentes de datos externas como S3. Pretransforman y preunen los datos antes de que se ejecuten las consultas SQL. Las vistas materializadas pueden actualizarse manualmente o según un calendario predefinido mediante Amazon Redshift Spectrum.
Resumen
En este capítulo, proporcionamos una visión general de cómo podemos cargar nuestros datos en Amazon S3, discutimos el valor de un lago de datos S3 y mostramos cómo podemos aprovechar servicios como Amazon Athena para ejecutar consultas SQL ad hoc a través de los datos en S3 sin necesidad de mover físicamente los datos. Mostramos cómo ingerir continuamente nuevos datos de aplicaciones utilizando AWS Glue Crawler. También presentamos nuestro conjunto de datos, Amazon Customer Reviews Dataset, que utilizaremos durante el resto del libro.
Como los distintos casos de uso requieren datos en formatos diferentes, explicamos cómo podemos utilizar Athena para convertir datos separados por tabulaciones en datos Parquet columnares optimizados para consultas.
A menudo es necesario que accedan a los datos de nuestro lago de datos S3 no sólo los equipos de ciencia de datos y aprendizaje automático, sino también los equipos de inteligencia empresarial. Presentamos la arquitectura Lake House basada en Amazon Redshift, el almacén de datos en la nube a escala de petabytes de AWS. Mostramos cómo utilizar Amazon Redshift Spectrum para combinar consultas entre almacenes de datos, incluidos Amazon Redshift y S3.
Para concluir este capítulo, hemos analizado los distintos formatos de compresión de datos y las opciones de jerarquización de S3, mostrando cómo pueden reducir el coste y mejorar el rendimiento de las consultas.
En el Capítulo 5 exploraremos el conjunto de datos con más detalle. Ejecutaremos consultas para comprender y visualizar nuestros conjuntos de datos. También mostraremos cómo detectar anomalías en los datos con Apache Spark y Amazon SageMaker Processing Jobs.
Get Ciencia de datos en AWS now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
