Primeros pasos en la arquitectura no transaccional

1

Objetivos y presentación del proyecto

2

Aprende qué es un Data Warehouse

3

Bases de datos columnares y arquitectura orientada a optimización de consultas

4

¿Cómo funciona AWS Redshift?

Configura tu entorno de trabajo para Redshift

5

Creando nuestro entorno de trabajo en AWS

6

Configura tu primer cluster

7

Consumiendo Redshift: empieza la magia

8

Sentencias SQL en Redshift

Cómo diseñar tu base de datos para mejorar su desempeño

9

¿Qué es la compresión en Redshift?

10

Algoritmos de compresión con Redshift

11

Aplicando algoritmos de compresión

12

Análisis de desempeño con diferentes tipos de compresión

13

Estilos de distribución con Redshift

14

Evaluando los estilos de distribución

15

Llaves de ordenamiento para optimizar nuestras consultas

16

Aplicando ordenamiento de columnas

17

Evaluando algoritmos de ordenamiento

18

Buenas prácticas para diseñar tablas en Redshift

19

Tipos de datos en AWS Redshift

20

Reto: mejora el desempeño de tu base de datos

Manipular enormes cantidades de datos

21

Olvídate de los insert, el copy llego para quedarse

22

Cargando archivos tipo JSON

23

El comando copy a fondo

24

Manifiestos y uso de COMPUPDATE para carga con compresión automática

25

Métodos de carga alternativos al comando copy

26

¿Cómo ejecutar sentencias UPDATE y DELETE?

27

¿Cómo mantener el desempeño de tu base de datos?

28

Estadísticas y limpieza de las tablas

Buenas prácticas para diseñar y ejecutar consultas en tu base de datos

29

Agrupamiento, ordenamiento y subqueries

30

¿Qué es y cómo interpretar un explain plan?

Análisis de comportamiento y descarga de datos con Redshift

31

¿Cómo descargar datos eficientemente con UNLOAD?

32

Otras tablas útiles de Redshift para entender el comportamiento de nuestros datos

Conclusiones

33

Próximos pasos con AWS Redshift

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Métodos de carga alternativos al comando copy

25/33
Recursos

¿Cómo insertar datos en Repsheet sin archivos planos?

Sin duda, la habilidad para cargar datos a una base de datos es esencial en el campo del análisis de datos. En caso de no contar con acceso a archivos planos o buckets, existen alternativas para cargar tus datos. Aquí exploraremos el uso de la instrucción INSERT INTO en Repsheet como una técnica valiosa, aunque menos óptima que el comando COPY.

¿Cuál es la mejor manera de usar el comando INSERT INTO?

Para evitar sobrecargar el sistema al cargar datos en Repsheet, es crucial manejar múltiples inserciones en una sola instrucción. Esto maximiza el uso del multiproceso y preserva el rendimiento de la base de datos. Un solo INSERT para cada fila puede ser perjudicial para bases de datos orientadas a columnas, por lo que siempre es preferible realizar inserciones por lotes.

INSERT INTO estudiante VALUES 
(5, 'Brandon', 'Huertas', 24, '2020-01-01'),
(6, 'Cristian', 'Salas', 30, '2020-01-01'),
(7, 'Holman', 'Campos', NULL, '2020-01-01'),
(8, 'Natalia', 'Montenegro', NULL, '2020-01-01');

¿Qué es el bulk select insert en SQL?

Otra opción para cargar datos en Repsheet es el concepto de "bulk insert", que permite mover grandes volúmenes de datos de una tabla a otra. Esta técnica es invaluable para realizar tareas como análisis o reestructuración de datos ya presentes en Repsheet.

CREATE TABLE total_priceByEvent AS
SELECT e.eventID, e.eventName, SUM(s.pricePaid) AS totalPrice, SUM(s.commission) AS totalCommission
FROM sales s
INNER JOIN event e ON s.eventID = e.eventID
GROUP BY e.eventID, e.eventName
ORDER BY e.eventID;

¿Cómo realizar un deep copy de tablas en Repsheet?

Finalmente, el "deep copy" es una técnica efectiva para duplicar la estructura y los datos de una tabla. Es especialmente útil para analizar y mejorar configuraciones de tablas sin interrumpir el acceso de los usuarios a los datos.

CREATE TABLE like_sales (LIKE sales);
INSERT INTO like_sales SELECT * FROM sales;
DROP TABLE sales;
ALTER TABLE like_sales RENAME TO sales;

Usar un "deep copy" te permite experimentar con diferentes configuraciones de compresión y esquema e implementar mejoras sin afectar la funcionalidad de la tabla original.

Para obtener los mejores resultados en el manejo de tus datos en Repsheet, es crucial entender y utilizar adecuadamente cada una de estas técnicas. Siempre que sea posible, opta por el comando COPY por su superior eficiencia y versatilidad. Sin embargo, las técnicas alternativas presentadas aquí son igualmente útiles y ofrecen soluciones prácticas en situaciones donde COPY no está disponible. ¡Sigue aprendiendo y explorando maneras efectivas de manejar tus datos!

Aportes 6

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Deep Copy

Una copia profunda recrea y vuelve a llenar una tabla mediante una inserción masiva, que ordena automáticamente la tabla. Si una tabla tiene una región grande sin clasificar, una copia profunda es mucho más rápida que una aspiradora. La compensación es que no debe realizar actualizaciones simultáneas durante una operación de copia profunda a menos que pueda rastrearla y mover las actualizaciones delta a la nueva tabla después de que se haya completado el proceso. Una operación de VACÍO admite actualizaciones simultáneas de forma automática.

Puede elegir uno de los siguientes métodos para crear una copia de la tabla original:

  • Utilice la tabla DDL original.

Si el DDL CREATE TABLE está 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, incluidas la clave principal y las claves externas.

  • Utilice CREAR TABLA COMO.

Si el DDL original no está disponible, puede usar CREATE TABLE LIKE para recrear la tabla original. La nueva tabla hereda los atributos encoding, distkey, sortkey y notnull de la tabla principal. La nueva tabla no hereda los atributos de clave principal y clave externa de la tabla principal, pero puede agregarlos usando ALTER TABLE.

  • Cree una tabla temporal y trunque la tabla original.

Si necesita conservar la clave principal y los atributos de clave externa de la tabla principal, o si la tabla principal tiene dependencias, puede usar CREATE TABLE … AS (CTAS) para crear una tabla temporal, luego truncar la tabla original y completar de 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 compromete inmediatamente, incluso si está dentro de un bloque de transacción. Si TRUNCATE tiene éxito pero la sesión finaliza antes de que finalice el INSERT subsiguiente, los datos se pierden. Si la pérdida de datos es inaceptable, use una tabla permanente.

Para realizar una copia profunda utilizando la tabla original DDL

  1. (Opcional) Vuelve a crear la tabla DDL ejecutando un script llamado v_generate_tbl_ddl.

  2. Crea una copia de la tabla usando el CREATE TABLE DDL original.

  3. Utilisa una instrucción INSERT INTO … SELECT para completar la copia con datos de la tabla original.

  4. Suelta la mesa original.

  5. Utilisa una instrucción ALTER TABLE para cambiar el nombre de la copia al nombre de la tabla original.

El siguiente ejemplo realiza una copia profunda en la tabla SALES usando un duplicado de SALES llamado SALESCOPY.

create table salescopy ( … );
insert into salescopy (select * from sales);
drop table sales;
alter table salescopy rename to sales;

Para realizar una copia profunda usando CREATE TABLE LIKE

  1. Cree una nueva tabla usando CREATE TABLE LIKE.

  2. Utilice una instrucción INSERT INTO … SELECT para copiar las filas de la tabla actual a la nueva tabla.

  3. Suelta la tabla actual.

  4. Utilice una instrucción ALTER TABLE para cambiar el nombre de la nueva tabla al nombre de la tabla original.

  5. El siguiente ejemplo realiza una copia profunda en la tabla SALES usando CREATE TABLE LIKE.

create table likesales (like sales);
insert into likesales (select * from sales);
drop table sales;
alter table likesales rename to sales;

Para realizar una copia en profundidad creando una tabla temporal y truncando la tabla original

  1. Utilice CREATE TABLE AS para crear una tabla temporal con las filas de la tabla original.

  2. Truncar la tabla actual.

  3. Utilice una instrucción INSERT INTO … SELECT para copiar las filas de la tabla temporal a la tabla original.

  4. Suelta la mesa temporal.

El siguiente ejemplo realiza una copia profunda en la tabla SALES creando una tabla temporal y truncando la tabla original:

create temp table salestemp as select * from sales;
truncate sales;
insert into sales (select * from salestemp);
drop table salestemp;
SELECT * FROM estudiante;

INSERT INTO estudiante VALUES
(5, 'Brandon', 'Huertas', 24, '2020-01-01'),
(6, 'Cristian', 'Salas', 30, '2020-03-01'),
(7, 'Holman', 'Capos', 25, '2020-02-01'),
(8, 'Natalia', 'Montenegro', 25, '2020-04-01');

-- bulk insert, datos por lotes
SELECT e.eventname, e.starttime, sum(pricepaid) pricepaid, sum(commission) commission 
FROM sales s 
INNER JOIN event e
ON s.eventid = e.eventid 
GROUP BY e.eventname , e.starttime;

CREATE TABLE total_price_by_event AS (
SELECT e.eventname, e.starttime, sum(pricepaid) pricepaid, sum(commission) commission 
FROM sales s 
INNER JOIN event e
ON s.eventid = e.eventid 
GROUP BY e.eventname , e.starttime
);

SELECT * FROM total_price_by_event;

-- deep copy
CREATE TABLE likesales (like sales);
INSERT INTO likesales (SELECT * FROM sales);
DROP TABLE sales;
ALTER TABLE likesales RENAME TO sales;

SELECT * FROM sales;

Acá les dejo unos querys.

INSERT INTO estudiante VALUES
(8, 'Juan', 'Perez', 31, '2020-03-22'),
(9, 'Maria', 'Lopez', 31, '2020-01-22'),
(10, 'Josue', 'Ramirez', 31, '2020-02-22');

--Bulk select/insert
CREATE TABLE total_price_by_event as (
	SELECT e.eventname, e.starttime, sum(pricepaid) pricepaid, sum(commission) commission
	FROM sales s
	INNER JOIN event e ON s.eventid = e.eventid
	GROUP BY e.eventname, e.starttime
);

SELECT *
FROM total_price_by_event;
Es común que al tener los datos en S3,un catalogo de tablas en "Glue Catalog" y se usa Redshift Spectrum para leer esos datos, se hagan bulk insert a las tables del DWH. Este segmento de datos en S3 junto con Glue Catalog y LakeFormation permita tener un lago de datos que pueda ser consumido por Redshift.
### **Métodos de Carga Alternativos al Comando COPY en Amazon Redshift** Aunque el comando `COPY` es el método más eficiente para cargar datos en Amazon Redshift, existen alternativas que pueden ser útiles según el caso de uso, el volumen de datos o las herramientas disponibles. ### **1. INSERT Statements** El método más básico para insertar datos en Amazon Redshift. #### **Uso** INSERT INTO table\_name (column1, column2, ...) VALUES ('value1', 'value2', ...), ('value3', 'value4', ...); #### **Ventajas** * Sencillo para cargas pequeñas o pruebas rápidas. * Útil para datos generados dinámicamente. #### **Desventajas** * Lento para grandes volúmenes de datos. * No aprovecha las optimizaciones internas de Redshift para cargas masivas. ### **2. Amazon Redshift Data API** Permite interactuar con Redshift sin necesidad de un cliente o controlador JDBC/ODBC. #### **Uso** La API acepta comandos SQL, incluidos INSERT y COPY, desde aplicaciones modernas. #### **Ventajas** * Ideal para aplicaciones serverless o sin infraestructura fija. * Puede integrarse con herramientas como AWS Lambda. #### **Desventajas** * Menos eficiente que `COPY` para cargas masivas. ### **3. AWS Glue** AWS Glue puede usarse para preparar y cargar datos en Amazon Redshift. #### **Proceso** 1. Configurar un catálogo de datos en Glue. 2. Crear y ejecutar un trabajo de ETL (Extract, Transform, Load) en Glue. 3. Escribir los datos transformados directamente en una tabla de Redshift. #### **Ventajas** * Excelente para transformar y cargar datos complejos. * Automático y escalable. #### **Desventajas** * Configuración inicial más compleja. * Puede ser más lento que `COPY` si no se optimiza. ### **4. Redshift Spectrum** Carga datos directamente desde S3 sin necesidad de moverlos a Redshift, ideal para análisis en datos no estructurados. #### **Uso** Crea una tabla externa vinculada a un bucket de S3: CREATE EXTERNAL TABLE schema\_name.table\_name ( column1 data\_type, column2 data\_type ) STORED AS file\_format LOCATION 's3://bucket\_name/'; #### **Ventajas** * Permite trabajar directamente con grandes volúmenes de datos en S3. * No es necesario cargar los datos físicamente a Redshift. #### **Desventajas** * Las consultas pueden ser más lentas que con tablas internas. * Requiere AWS Glue para definir el catálogo. ### **5. Amazon Kinesis Data Firehose** Envía flujos de datos en tiempo real a Amazon Redshift. #### **Proceso** 1. Configura una entrega de datos en Kinesis Data Firehose con destino a Redshift. 2. Proporciona las credenciales y la tabla de destino. #### **Ventajas** * Ideal para cargas en tiempo real. * Automatiza la ingesta de datos. #### **Desventajas** * No es adecuado para grandes volúmenes de datos históricos. * Configuración más avanzada. ### **6. Herramientas de ETL Externas** Herramientas de terceros como **Informatica**, **Talend**, **Matillion**, o **Pentaho** pueden integrarse con Redshift para cargar datos. #### **Ventajas** * Interfaces gráficas fáciles de usar. * Funciones avanzadas de transformación. #### **Desventajas** * Licencias y costos adicionales. * Menor control sobre la optimización. ### **7. Unload/Load desde y hacia Amazon S3** Se utiliza para mover datos entre tablas de Redshift o entre clústeres. #### **Proceso** 1. Exporta los datos desde Redshift a S3 con `UNLOAD`.UNLOAD ('SELECT \* FROM table\_name') TO 's3://bucket\_name/prefix' CREDENTIALS 'aws\_iam\_role=arn:aws:iam::123456789012:role/MyRole' PARALLEL ON; 2. Carga los datos en otra tabla o clúster usando `COPY`. #### **Ventajas** * Ideal para migraciones o copias entre entornos. * Mantiene la eficiencia del comando `COPY`. #### **Desventajas** * Requiere espacio en S3 para datos temporales. * Puede ser más lento que `COPY` directo. ### **8. Federated Queries** Permite cargar datos desde bases de datos externas como RDS o Aurora directamente a Redshift. #### **Uso** Define una fuente de datos externa y utiliza consultas SQL para cargar los datos: CREATE EXTERNAL SCHEMA ext\_schema FROM POSTGRES DATABASE 'db\_name' URI 'jdbc:postgresql://host:port' IAM\_ROLE 'arn:aws:iam::123456789012:role/MyRole'; #### **Ventajas** * No es necesario extraer datos manualmente. * Reduce la duplicación de datos. #### **Desventajas** * Las consultas federadas pueden ser más lentas que el uso de `COPY`. ### **Conclusión** * **Volúmenes grandes y cargas masivas:** El comando `COPY` sigue siendo el más eficiente. * **Datos en tiempo real:** Kinesis Data Firehose es la mejor opción. * **Transformación compleja de datos:** AWS Glue o herramientas de ETL externas. * **Análisis directo en S3:** Redshift Spectrum. Elegir el método adecuado depende de las necesidades específicas, la infraestructura existente y los requisitos de transformación y velocidad.

Buena clase