Sugerencias para una implementación exitosa de LuckyTemplates

Continuaremos con nuestra serie sobre la planificación e implementación de proyectos de LuckyTemplates. Esta vez, hablaremos sobre el diseño , la creación de perfiles y los modos de conjuntos de datos . Consulte la primera parte de nuestra serie de planificación de proyectos que trata sobre los modos de implementación y la segunda parte que habla sobre el descubrimiento y la ingestión .

Tabla de contenido

• Diseño de conjuntos de datos para la implementación de proyectos de LuckyTemplates
  • 4 pasos para el diseño de conjuntos de datos
  • Seleccione el proceso de negocio.
    • El antipatrón a evitar en la implementación de LuckyTemplates
  • Declarar el grano.
  • Identifica las dimensiones.
  • Definir los hechos.
• Matriz de bus de datos para la implementación de proyectos de LuckyTemplates
• Creación de perfiles de datos para la implementación de LuckyTemplates
  • Servicios de integración de SQL Server
  • Estudio DAX
  • Escritorio de LuckyTemplates
• Planificación de conjuntos de datos para la implementación de LuckyTemplates
  • Elegir un modo de conjunto de datos
  • Algunas preguntas para hacer al elegir modos de conjunto de datos
• Conclusión

Diseño de conjuntos de datos para la implementación de proyectos de LuckyTemplates

Hablemos sobre el proceso de diseño de conjuntos de datos y analicemos la matriz de bus de almacenamiento de datos , que es una herramienta que existe desde hace tiempo.

El diseño de conjuntos de datos de LuckyTemplates es similar al diseño de almacenes de datos. Por lo tanto, tanto los conjuntos de datos como los almacenes de datos tienen conceptos similares, como tablas de hechos y dimensiones, esquemas en estrella, dimensiones que cambian lentamente, granularidad de tablas de hechos y claves informadas locales para construir relaciones entre tablas.

4 pasos para el diseño de conjuntos de datos

Hay cuatro pasos para el proceso de diseño del conjunto de datos: seleccione el proceso comercial , declare el grano de sus tablas de hechos, identifique las dimensiones y luego defina los hechos .

Seleccione el proceso de negocio.

Para el primer paso, cada proceso empresarial está representado por una tabla de hechos con un esquema en estrella de una relación de muchos a uno con las dimensiones.

Durante un proceso de recopilación de requisitos o descubrimiento, es difícil concentrarse en un solo proceso comercial de forma aislada, ya que los usuarios analizan regularmente múltiples procesos comerciales simultáneamente.

El antipatrón a evitar en la implementación de LuckyTemplates

El antipatrón común (que es una respuesta a un problema recurrente que generalmente es ineficaz y potencialmente contraproducente) que desea evitar en los proyectos de LuckyTemplates es el desarrollo de conjuntos de datos para proyectos o equipos específicos en lugar de para los procesos comerciales .

Por ejemplo, desarrollar un conjunto de datos exclusivamente para el equipo de marketing y otro conjunto de datos para la organización de ventas. Este enfoque conduce naturalmente al desperdicio de recursos porque los mismos datos de ventas se consultan y actualizan dos veces en ambos conjuntos de datos. Estos también consumirán recursos de almacenamiento en el servicio LuckyTemplates.

estas son algunas de las razones por las que desea pasar por un buen proceso para el diseño de conjuntos de datos. Un enfoque aislado conduce a problemas de gestión y control de versiones porque los conjuntos de datos pueden contener variaciones y transformaciones.

Aunque las necesidades analíticas de los usuarios o equipos son la prioridad de los proyectos de LuckyTemplates, también es importante planificar soluciones sostenibles que, en última instancia, puedan compartirse entre equipos.

Declarar el grano.

Las tablas de grano de hecho cubren en última instancia el nivel de detalle disponible para las consultas analíticas, así como la cantidad de datos a los que se puede acceder.

Por lo tanto, un grano más alto significa más detalles, mientras que un grano más bajo significa menos detalles. Un ejemplo de esto es cuando desea obtener el nivel de línea del pedido de ventas, o si desea que el proyecto solo contenga el nivel de resumen de cada pedido de ventas y no llegue a los productos específicos que se ordenaron como parte de esa venta.

A veces, este grano puede variar dependiendo de su marco de tiempo. Me he encontrado con una cantidad de clientes que quieren tablas de hechos muy detalladas para el trimestre actual, pero para los trimestres anteriores, solo necesitaban saber cuál fue el total de ventas del trimestre.

Durante este paso, desea determinar qué representa cada fila de los diferentes procesos comerciales . Por ejemplo, cada fila de la tabla de hechos de ventas de nuestro almacén de datos representa la línea de un pedido de ventas de un cliente.

Por el contrario, las filas de un plan de ventas y márgenes se agregarán en un mes calendario, una subcategoría de producto y una región de territorio de ventas. entonces, en este caso, tiene dos tablas de hechos diferentes y dos granos diferentes. si desea comparar los dos, habrá algún trabajo de modelado de datos involucrado.

Identifica las dimensiones.

Las dimensiones son solo el subproducto natural del grano elegido en el paso de diseño anterior.

Por lo tanto, una sola fila de muestra de la tabla de hechos debe indicar claramente las dimensiones de la entidad comercial asociadas con el proceso dado, como el cliente que compró un proyecto individual, el producto en una fecha determinada y en un momento determinado. Las tablas de hechos que representan granos inferiores tienen menos dimensiones.

Por ejemplo, una tabla de hechos que representa el nivel de encabezado de una orden de compra puede identificar al proveedor, pero no la compra del producto individual del proveedor. entonces, en ese caso, no necesitaría incluir una categoría de producto o una dimensión de subcategoría de producto.

Definir los hechos.

Los hechos representan las columnas numéricas incluidas en las tablas de hechos. Entonces, mientras que las columnas de dimensión del paso 3 se usan para relaciones, las columnas de hechos se usan en medidas que contienen lógica de agregación, como la suma de una columna de cantidad o el promedio de una columna de precio.

Matriz de bus de datos para la implementación de proyectos de LuckyTemplates

La matriz de bus del almacén de datos es un elemento básico de la arquitectura del almacén de datos de Ralph Kimball, que proporciona un enfoque incremental e integrado para el diseño del almacén de datos.

La arquitectura que ve aquí es de The Data Warehouse Toolkit , 3.ª edición de Ralph Kimball. Permite modelos de datos escalables que múltiples equipos o funciones comerciales a menudo requieren para acceder a los mismos procesos y dimensiones comerciales.

Es útil mantener una matriz de bus de almacén de datos. cuando lo complete, sabrá si hay otros conjuntos de datos que contienen tablas de dimensiones y tablas de datos de Internet similares. esto promueve la reutilización del proyecto y mejora la comunicación del proyecto.

Por lo tanto, cada fila refleja un proceso comercial importante y recurrente, como el cierre mensual del libro mayor. cada columna representa una entidad comercial, que puede relacionarse con uno o varios de los procesos comerciales, mientras que las filas sombreadas representan el proceso comercial que se incluye dentro del proyecto.

Creación de perfiles de datos para la implementación de LuckyTemplates

una vez que haya identificado el grano y se haya completado el proceso de diseño del conjunto de datos de cuatro pasos, debe seguir inmediatamente un análisis técnico de los datos de origen de las tablas de hechos y dimensiones .

Los metadatos técnicos, incluidos los diagramas de bases de datos y los resultados de perfiles de datos, son esenciales para la etapa de planificación del proyecto.

Esta información se usa para garantizar que el conjunto de datos de LuckyTemplates refleje las definiciones comerciales previstas y se base en una fuente sólida y confiable.

Entonces, tres son tres formas diferentes de recopilar esa información de perfil, que debería ser el primer paso que las personas darán una vez que salgan del proceso de diseño.

Servicios de integración de SQL Server

Hay un par de maneras de hacer esto. Un método es utilizar una tarea de generación de perfiles de datos dentro de un paquete de SQL Server Integration Services (SSIS).

La tarea de creación de perfiles de datos requiere conexiones ADO.NET y puede escribir su salida en un archivo XML o una variable SSIS.

En este ejemplo, los datos de origen de ADO.NET son un almacén de datos, una base de datos y un servidor SQL de AdventureWorks, y el destino es un archivo XML.

Entonces, una vez que se ejecuta la tarea, el archivo XML se puede leer a través de un visor de perfil de datos del servidor SQL. Puede ver los resultados en términos de recuento nulo y porcentajes de recuento nulo.

Estudio DAX

Otra forma de creación de perfiles de datos es a través de DAX Studio. tiene que ingerir los datos en un conjunto de datos de LuckyTemplates yendo a DAX Studio, vaya a la pestaña avanzada y ejecute VertiPaq Analyzer .

Le mostrará el mismo tipo de información sobre la cardinalidad de sus columnas para que sepa cuáles ocupan más espacio en su modelo de datos. incluye todas las diversas estadísticas en torno a los datos.

Escritorio de LuckyTemplates

La creación de perfiles de datos también está disponible en Power Query dentro de LuckyTemplates Desktop. si va a la pestaña Ver , puede activar cosas como la calidad de la columna, la distribución de la columna y el perfil de la columna. Para al menos las primeras mil filas, puede ver información como errores, valores nulos, promedios y desviaciones estándar.

Planificación de conjuntos de datos para la implementación de LuckyTemplates

Después de perfilar y evaluar los datos de origen con respecto a los requisitos identificados en el proceso de diseño del conjunto de datos de cuatro pasos, el equipo de BI puede analizar más a fondo las opciones de implementación para el conjunto de datos.

En casi todos los proyectos de LuckyTemplates, incluso aquellos con inversiones significativas en datos empresariales, almacén, arquitectura y herramientas y procesos ETL, se necesita cierto nivel de lógica, integración o transformación adicional para mejorar la calidad y el valor de los datos de origen.

La etapa de planificación del conjunto de datos determina cómo se abordan los problemas de transformación de datos identificados para respaldar el conjunto de datos. Además, el equipo del proyecto debe determinar si desarrollará un conjunto de datos de modo de importación , un conjunto de datos de consulta directa o un conjunto de datos compuesto .

Para aclarar el proceso de planificación del conjunto de datos, este diagrama identifica las diferentes capas del almacén de datos y el conjunto de datos de LuckyTemplates donde se puede implementar la transformación y la lógica empresarial.

en algunos proyectos, se necesita una transformación mínima y se puede incluir fácilmente en el conjunto de datos de LuckyTemplates. Por ejemplo, si solo se necesitan unas pocas columnas adicionales para una tabla de dimensiones y hay una guía sencilla sobre cómo se calcularán estas columnas, la organización de TI puede optar por implementar estas transformaciones dentro de M power queries en lugar de revisar el almacén de datos.

Si se permite que persista la brecha sustancial entre las necesidades de BI y el almacén de datos corporativo, entonces los conjuntos de datos de LuckyTemplates se vuelven más complejos de construir y mantener.

Los diseñadores de conjuntos de datos deben analizar y comunicar regularmente las implicaciones de los conjuntos de datos si hay mayores niveles de complejidad.

Sin embargo, si la lógica de transformación requerida es compleja o extensa con múltiples operaciones conjuntas, filtros de fila y cambios de tipo de datos, entonces la organización de TI puede optar por implementar cambios esenciales en el almacén de datos para respaldar el nuevo conjunto de datos y futuros proyectos de BI.

Por ejemplo, es posible que se necesite una tabla de etapas y un procedimiento de almacenamiento de SQL para respaldar, revisar y actualizar el proceso, o puede ser necesaria la creación de un índice para mejorar el rendimiento de las consultas para los conjuntos de datos de DirectQuery.

Elegir un modo de conjunto de datos

Un paso posterior, pero estrechamente relacionado con la planificación del conjunto de datos, es elegir entre el modo de importación predeterminado, DirectQuery/modo en vivo o modo compuesto.

En algunos proyectos, esta es una decisión simple en la que solo una opción es factible o realista dados los requisitos conocidos, mientras que otros proyectos implicarán un análisis significativo de los pros y los contras de cada diseño.

Entonces, si una fuente de datos se considera lenta o mal equipada para manejar un gran volumen de consultas analíticas, es muy probable que un conjunto de datos en modo de importación sea la opción preferida.

Del mismo modo, si la visibilidad casi en tiempo real de una fuente de datos es esencial, entonces DirectQuery o el modo en vivo es la única opción para lograrlo. los modos DirectQuery y en vivo son muy similares entre sí. Ambos métodos no almacenan datos dentro del propio conjunto de datos y ambos consultan los sistemas de origen directamente para recuperar datos en función de la acción del usuario. Ahora tenemos DirectQuery para conjuntos de datos de LuckyTemplates y DirectQuery para Analysis Services.

Algunas preguntas para hacer al elegir modos de conjunto de datos

Aquí hay algunas preguntas que debe hacer al decidir qué modo usar. ¿Hay una fuente única para nuestro conjunto de datos? Si no hay una sola fuente, entonces no podía usar la fuente DirectQuery/Live en el pasado.

Aunque ahora tenemos conjuntos de datos en modo compuesto, sigue siendo una buena pregunta para hacer desde el principio porque si no hay una fuente única, será importada o compuesta.

Si DirectQuery/Live source es una opción, ¿la fuente es capaz de admitir consultas analíticas? Si está trabajando con miles de millones o billones de filas, entonces tal vez un conjunto de datos en modo de importación no sea factible y tendrá que usar DirectQuery o el modo compuesto para asegurarse de que el conjunto de datos se pueda utilizar.

Si el origen de DirectQuery/Live es capaz de admitir la carga de trabajo, ¿es la conexión de DirectQuery/Live más valiosa que el rendimiento y la flexibilidad proporcionados por un modelo de importación?

Conclusión

Esta publicación concluye esta serie sobre la planificación de proyectos de LuckyTemplates. estos, creo, son los pasos esenciales para todos los proyectos de LuckyTemplates en los que trabaja. Estos pasos son importantes al realizar la diligencia debida, especialmente en un entorno de inteligencia comercial empresarial.

Mis mejores deseos,

greg deckler