La Guía de analistas para Diseñar un Almacén de datos Moderno

, por lo que se le pedirá que cree un almacén de datos para su empresa. Un almacén de datos eficiente, escalable y confiable. Si su empresa se está embarcando seriamente en la implementación de informes de datos como un activo estratégico clave para su negocio, la construcción de un almacén de datos eventualmente aparecerá en la conversación.

Pero construir un almacén de datos no es fácil ni trivial. Más del 50 por ciento de los proyectos de almacenamiento de datos tienen una aceptación limitada o serán fracasos absolutos.

¿Cómo debería comenzar a diseñar y construir su almacén de datos? ¿Cuáles son los escollos y cómo debe optimizarlos? Lo más importante, ¿por dónde debo empezar?

Esta publicación proporciona una guía de alto nivel sobre cómo pensar en configurar su almacén de datos para evitar algunos errores comunes.

¿Qué es un almacén de datos?

Una empresa moderna normalmente tiene datos almacenados en diferentes lugares (fuentes de datos). Estos pueden ser datos de:

• Bases de datos de aplicaciones: Para startups, esta es probablemente su aplicación de producto principal. Para otras empresas, puede ser su aplicación de punto de venta,
• Aplicaciones web: Pueden ser aplicaciones que se necesitan para escalar un negocio o mantener las operaciones comerciales. Algunos ejemplos podrían ser software de marketing por correo electrónico como Mailchimp, aplicaciones de análisis web como Google Analytics o Mixpanel, o incluso software de contabilidad como Xero y Quickbooks.
• Hojas de cálculo: Puede ser en forma de hojas de cálculo de escritorio (Excel, CSV) u hojas de cálculo en línea, como hojas de cálculo de Google. Estos datos pueden ser actualizados manualmente por alguien, o actualizados por una actividad de Zapier.

Un almacén de datos sincroniza datos de diferentes fuentes en un solo lugar para todas las necesidades de informes de datos.

Proporciona datos en los que se puede confiar para que sean confiables y puede manejar la carga de trabajo de consulta de todos los empleados de la empresa.

Diseñar un almacén de datos

Lea también: ¿Cuándo debe obtener un almacén de datos?

Así es como se ve una configuración de almacén de datos típica:

Usted diseña y construye su almacén de datos en función de sus requisitos de informes. Después de identificar los datos que necesita, los diseña para que fluyan información a su almacén de datos.

Crear un esquema para cada fuente de datos

Crear un esquema de base de datos para cada fuente de datos que desee sincronizar con la base de datos. Este

1. le ayuda a identificar rápidamente la fuente de datos de la que proviene cada tabla, lo que ayuda a medida que aumenta el número de fuentes de datos. Los futuros analistas de datos y los miembros del equipo empresarial que se unan a su empresa también pueden aprender rápidamente lo que tiene cada fuente de datos.
2. Le permite asignar permisos específicos (lectura/escritura) para cada fuente de datos. Por ejemplo, es posible que un ingeniero de datos no quiera permitir que un analista junior solo lea, pero no escriba en un esquema específico.

Esto es especialmente útil cuando el número de fuentes de datos crece con el tiempo. Basta con ver la cantidad de fuentes en las que podrían estar sus datos.

Por ejemplo, puede configurar un esquema llamado mailchimpxeroo fbads para los datos de marketing por correo electrónico, finanzas y publicidad que desee importar de estas aplicaciones a su almacén, respectivamente.

Cuando importas tu tabla de contactos de Mailchimp a tu base de datos, puedes consultarlos como:

SELECT name, email FROM mailchimp.contacts

¿Cómo crear un esquema

la Creación de un esquema es fácil. Solo necesita escribir una línea para crear un nuevo esquema. De hecho, son solo 3 palabras en Postgres.

CREATE SCHEMA 

Ejemplo:

CREATE SCHEMA mailchimp

Nota 1: los Nuevos analistas pueden confundirse entre un esquema de base de datos. Hay 2 definiciones de esquema. Un esquema se puede usar para describir

1. Cómo se relacionan las tablas y los campos de una base de datos, o
2. Una carpeta para tablas de base de datos, al igual que las carpetas organizan sus archivos

Nota 2: Las bases de datos MySQL no admiten esquemas, por lo que es posible que desee usar una convención de nomenclatura para nombrar las tablas que importa, como mailchimp_contacts, etc. Esa es una de las razones por las que animamos a nuestros clientes a usar PostgreSQL para su base de datos de informes.

Mover los datos de origen a su almacén de datos

El siguiente paso es sincronizar los datos de origen en su almacén de datos. Sus ingenieros pueden conocer esto como un script ETL.

Diseñe su script de importación con las siguientes consideraciones:

1. Elimine las columnas que obviamente son innecesarias. No es tan difícil para ti agregarlos más tarde si te das cuenta de que los necesitas.
2. Cambie el nombre de las columnas para hacerlas más descriptivas o amigables con la base de datos (como usar minúsculas o minúsculas).
3. Filtrar registros obviamente innecesarios. Esto puede ser registros de la prueba de los usuarios internos en su sistema de producción (a veces, los usuarios pueden agregar datos como [email protected] o establecer su nombre de pila como pruebas)
4. Asignar valores de registro para que sean más legibles. Esto le ahorrará a sus analistas el esfuerzo de cambiarles el nombre durante el informe con CASE-IFs más adelante). Por ejemplo, algunos registros pueden almacenar claves numéricas (1, 2, 3, 99, etc.) o nombres abreviados que pueden no ser conocidos por el resto de la organización. En esos casos, es posible que desee asignar estas claves a sus valores reales durante el proceso de importación.
5. Aplicar índices de base de datos a la tabla de destino una vez realizada la importación. Nota hemos escrito sobre qué índices de base de datos son en un post anterior.
6. Gestión de errores: Configure los correos electrónicos / / Mensaje de alerta de Slack para enviar a las partes interesadas relevantes (especialmente a los analistas de datos) con registros de errores detallados cuando falla el trabajo. Es posible que desee configurar intentos de reintento automatizados (o procesos de recuperación automatizados) dentro de un período de tiempo específico para reducir el número de falsos positivos en este caso.

¿Debe transformar sus datos de origen (sin procesar)?

Una pregunta que a menudo nos hacen es cómo aplicar transformaciones de datos antes de mover los datos al almacén.

a través de GIPHY

Nuestro consejo general es no hacerlo. Al menos no al principio. Especialmente si este es su primer proyecto de almacén de datos. Hay algunas razones para esto.

a. Es poco probable que tenga requisitos claros en sus necesidades de transformación de datos

Incluso si se le dan «requisitos claros», es probable que este requisito cambie a lo largo del proyecto o se desactualice.

No querrá pasar tiempo revisando su script ETL en función de lo que las diferentes partes interesadas desean en diferentes momentos del tiempo.

Mover los datos de origen (sin transformar) le ayuda a separar la dependencia de su script ETL de los «requisitos de negocio».

b. Es probable que necesite los datos de origen para otros casos

Piense en sus datos de origen como una base de interacción que se puede derivar en varias tablas derivadas, ya sea agregándolas a lo largo de diferentes dimensiones o uniéndolas con tablas de otras fuentes.

Vea el ejemplo a continuación sobre cómo rastrear la efectividad de la conversión del vendedor.

Al transformar datos, se pierden detalles de los datos de origen que pueden ser necesarios para futuros casos de uso de informes.

Por ejemplo, cuando resume los ingresos por ventas por período de tiempo, pierde detalles de los registros de transacciones específicos que otro usuario puede necesitar correlacionar con otros informes.

Mover sus datos de origen no transformados le dará flexibilidad para combinarlos con otras fuentes de datos.

La necesidad de datos de origen se vuelve más importante cuando comienza a buscar la creación de modelos de datos reutilizables para responder a diferentes preguntas. Vea un ejemplo a continuación sobre un informe de cohorte creado con una serie de datos post-transformados. Esto será más difícil de hacer si no tiene

c. Reducir la carga en sus sistemas de origen

La ejecución de transformaciones de datos en el sistema de origen puede requerir recursos considerables, especialmente si tiene una base de datos que presta servicio a clientes de todo el mundo.

No querrá sobrecargarlo con trabajos de transformación de datos de larga duración antes de trasladarlos.

Hay algunos casos que pueden tener sentido para que transforme los datos antes de trasladarlos, pero estos casos suelen ser para empresas que ya han configurado un almacén de datos confiable y buscan mejorarlo aún más.

Transformar datos para resolver un problema específico

Pensar en cómo transformar datos puede ser complejo. Si no se controla, puede terminar gastando mucho tiempo optimizando datos que no aportan valor a la empresa.

Planificar, diseñar e implementar transformaciones de datos sin un resultado claro es una solución que busca un problema.

Una buena regla general es comenzar con el final en mente. Las transformaciones de datos solo deben crearse para abordar un caso de uso práctico o un problema a partir de sus informes.

Una buena manera de encontrar (y priorizar) esos casos prácticos de uso es comenzar a crear los informes y paneles con los datos que importó.

Cuando los usuarios empiecen a plantear problemas de rendimiento de las consultas, puede buscar la posibilidad de transformar los datos.

Esto puede deberse a informes de que
(a) contiene subconsultas anidadas o expresiones de tabla personalizadas (CTE)

(b) O tiene varias (caras) uniones en varias tablas.

Aquí es donde la flexibilidad de los informes basados en SQL es útil para ayudar a identificar los problemas que la transformación de datos puede abordar.

Es fácil para cualquier analista identificar rápidamente la causa raíz de los informes con consultas de larga duración e iniciarlos para optimizar su rendimiento.

Esto se hace en gran medida a través de la preagregación automática de los datos. Esto se puede hacer con vistas materializadas donde puede crear trabajos de transformación de datos que:

1. Agreguen tablas de transacciones grandes para acelerar el rendimiento de las consultas.
2. Crear tablas derivadas con columnas de diferentes fuentes de datos
3. Reemplazar / enmascarar datos confidenciales para grupos seleccionados de usuarios.

Otra recomendación es crear un nuevo esquema de base de datos en su almacén de datos para almacenar sus tablas transformadas (o postprocesadas).

Al igual que el enfoque anterior de separar cada fuente de datos por esquemas, crear un esquema específico puede ayudarlo a identificar la lista de tablas de datos derivadas/transformadas. Esto será útil más adelante, cuando comience a encadenar una serie de importaciones de datos, los trabajos de transformación de datos en secuencia a medida que crece la madurez de los datos.

Cree sus documentos de datos internos

Esto es importante, especialmente si no desea que su almacén de datos sea una caja negra donde solo unos pocos ingenieros entiendan cómo usarlo. Si tus usuarios no lo entienden, no estarán seguros de consultarlo.

Puede comenzar creando un documento compartido (puede ser Google Doc) que describa un entendimiento común de:

• Tablas y columnas en sus datos de origen, y cómo interpretarlas
• Incluir diagrama de datos si lo hubiera.
• Cómo leer las columnas de los informes (panel de control, métricas) y las suposiciones subyacentes detrás de ellas

Cada vez que se cree (o actualice) un informe, actualice este documento para reflejar cualquier nuevo nivel de comprensión empresarial de los datos.

Compartiremos más detalles sobre cómo crear y estructurar este documento de datos internos en una publicación separada, ¡así que tenga cuidado con este espacio!

¡Eso es todo!

¡Esperamos que esta guía haya sido útil! Háganos saber cómo podemos ayudarle con su viaje para construir un almacén de datos confiable.