Modelado Dimensional y ETL en Redshift

He estado investigando la base de datos Redshift de Amazon como un posible reemplazo futuro para nuestro almacén de datos. Mi experiencia siempre ha sido en el uso del modelado dimensional y los métodos de Ralph Kimball, por lo que fue un poco extraño ver que Redshift no admite características como el tipo de datos en serie para columnas de incremento automático.

Sin embargo, hay una publicación reciente del blog de AWS Big Data sobre cómo optimizar Redshift para un esquema en estrella: https://blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -y-Interleaved-Sorting-on-Amazon-Redshift

La pregunta que tengo es acerca de cuál es la mejor práctica para cargar un esquema de estrella en Redshift. No puedo encontrar esta respuesta en ninguna de la documentación de Redshift.

Me estoy inclinando hacia la importación de mis archivos de S3 en tablas de preparación y luego uso SQL para hacer las transformaciones, como búsquedas y generar claves sustitutas antes de insertarlas en las tablas de destino.

¿Es esto lo que otros están haciendo actualmente? ¿Existe una herramienta ETL que valga la pena para hacer esto más fácil?

Definitivamente estás en el camino correcto con Kimball en lugar de inmon para Redshift.

Hay varios patrones para esto, los he usado todos en diferentes casos de uso

1. Patrón "ELT": cargue las tablas de origen para el desplazamiento al rojo por completo, no realice ninguna transformación significativa hasta que se hayan cargado los datos. Para esto, puede cargar a s3, luego usar el comando de copia de desplazamiento al rojo o recomendaría usar "servicios de migración de datos de AWS", que pueden sincronizar una fuente (egmysql o postgres) a un destino (por ejemplo, desplazamiento al rojo) Luego, ejecute regularmente sql procesa dentro del desplazamiento al rojo para poblar dims y luego hechos. Puede usar herramientas basadas en la nube de terceros para "simplificar" este proceso si lo desea, como Matillion (no recomiendo usar una herramienta de terceros)
2. "Patrón ETL" - Transforma los datos en vuelo, usando apache spark. y cargue los dims y los hechos en redshift spark-> s3-> redshift. He usado EMR para esto, lo cual es bueno. este es también el enfoque adoptado si usa AWS Glue
3. ¡No te transformes! - similar a 1) pero solo use las tablas que se han cargado.

Tenga en cuenta que Redshift a veces funciona MEJOR si tiene una tabla amplia con valores repetidos en lugar de un hecho y dimensiones. La razón de esto es que el enfoque columnar permite a Redshift comprimir los diferentes valores hasta un nivel que es bastante eficiente. No tengo una fórmula sobre cuándo usar muchas Dimensiones frente a una mesa ancha y plana, ¡la única forma es probarla y ver!

Algunos enlaces

AWS DMS para tarta Redshift

AWS Glue

Para ETL hay AWS Glue. Es un servicio ETL administrado y sin servidor que se carga en Redshift (entre otras cosas).

https://aws.amazon.com/glue/

Actualmente estoy lidiando con una tarea similar. Es para construir procesos ETL y diseñar modelos dimensionales. He investigado mucho sobre la mejor manera de lidiar con eso y encontré una increíble fuente útil de técnicas que definitivamente deberíamos aplicar cuando trabajamos con MPP.

Para responder la pregunta

La pregunta que tengo es sobre cuál es la mejor práctica para cargar un esquema de estrella en Redshift.

asegúrese de echar un vistazo a este recurso . Apuesto a que lo encontrarás increíblemente útil. Es un documento de ~ 35 páginas con técnicas poderosas para aprovechar el uso de almacenes de columnas MPP. Es compatible con los comentarios que ves como

Tenga en cuenta que Redshift a veces funciona MEJOR si tiene una tabla amplia con valores repetidos en lugar de un hecho y dimensiones. La razón de esto es que el enfoque columnar permite a Redshift comprimir los diferentes valores hasta un nivel que es bastante eficiente. No tengo una fórmula sobre cuándo usar muchas Dimensiones frente a una mesa ancha y plana, ¡la única forma es probarla y ver!

comentario de Jon Scott

Espero que lo encuentres tan útil como yo

Creo que cargar desde S3 es un patrón común.

Necesitábamos imponer restricciones de unicidad, por lo que elegimos escribir en Postgres y luego replicar nuevos datos para el desplazamiento al rojo cada 10 minutos.

Usamos https://github.com/uswitch/blueshift para cargar en Redshift.

Dado que Redshift es una base de datos columnar, el rendimiento de almacenamiento y consulta será diferente al de los modelos RDBMS. La optimización para una base de datos columnar también es diferente. Debido a que generalmente hay menos E / S de disco y menos datos cargados desde el disco, las consultas son más rápidas.

En términos de la publicación de blog de AWS a la que hace referencia, supongo que ha examinado esas recomendaciones y ha considerado qué opciones funcionan mejor para sus datos de distribución, claves, cursores, gestión de la carga de trabajo, etc. y tiene al menos una buena idea del enfoque lo usarías Me resulta más fácil trabajar con una representación visual, puede considerar un diagrama de DB rápido y sucio que muestre cómo migrarían sus tablas existentes a Redshift. Cubriendo los principales para tener una idea de la cantidad de datos que van a dónde. Y ciertamente usaría los controladores ODBC / JDBC de Amazon, cargar grandes cantidades de datos puede ser problemático en cualquier caso, y mucho menos mudarse a un tipo de base de datos diferente.

En cuanto a ETL / ELT, hay AWS Glue como otros carteles han mencionado. Y sí, hay varias herramientas, algunas de las cuales son gratuitas. Amazon tiene una Guía de mejores prácticas de base de datos , que también podría ayudarlo. Un consejo que he visto en otros foros es cargar sus datos lo más sin procesar posible y hacer las transformaciones en Redshift. Eso lo llevaría a un proceso de ELT. Con tantas opciones, quizás sería útil mirar una comparación de los 2 métodos. Aquí hay un artículo de blog de Panopoly que explica las diferencias, podría ayudarlo a decidir el camino.

Amazon ha publicado recientemente algunas mejores prácticas para ETL en Redshift

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

En una presentación sobre este tema, Tony Gibbs, AWS Solution Architect recomienda el siguiente patrón para cargas de estilo UPSERT:

1. Cargar datos CSV (desde S3) en la tabla de etapas
2. Eliminar filas coincidentes de la tabla prd

3. Insertar datos de la etapa

   BEGIN;
   CREATE TEMP TABLE staging(LIKE …); — copies dist keys
   copy staging from ’s3://… COMPUTE OFF;
   DELETE deep_dive d
   USING staging s WHERE d.aid = s.aid;
   INSERT INTO deep_dive SELECT * FROM staging
   DROP table staging;
   COMMIT;

Cuando sea posible, prefiera DROP TABLE o TRUNCATE a DELETE para evitar filas fantasmas

Vea un video de su charla y las diapositivas .

En nuestro equipo, normalmente cargamos datos en Redshift directamente desde S3 usando la instrucción SQL COPY .

Y gestione todos nuestros ETL con la excelente herramienta Apache Airflow .

También usamos servicios de integración como Stich que escriben directamente en Redshift, y luego usamos CREATE TABLE LIKE y SELECT INTO para mover los datos a otro esquema.