Editar

Inteligencia empresarial

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Azure Blob Storage

En este escenario de ejemplo se muestra cómo se pueden ingerir datos en un entorno de nube desde un almacenamiento de datos local y, a continuación, se sirven mediante un modelo de inteligencia empresarial (BI). Este enfoque podría ser un objetivo final o un primer paso hacia la modernización completa con componentes basados en la nube.

Los pasos siguientes se basan en el escenario de un extremo a otro de Azure Synapse Analytics. Usa Azure Pipelines para ingerir datos de una base de datos SQL en los grupos de Azure Synapse SQL, y luego transforma los datos para su análisis.

Architecture

Diagram of enterprise BI architecture with Azure Synapse.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

Origen de datos

Ingesta y almacenamiento de datos

  1. Azure Data Lake Gen2 se usa como área de almacenamiento provisional temporal durante la ingesta de datos. Después, puede usar PolyBase para copiar datos en un grupo de SQL dedicado de Azure Synapse.

  2. Azure Synapse Analytics es un sistema distribuido diseñado para analizar grandes volúmenes de datos. Admite el procesamiento paralelo masivo (MPP), lo que lo hace idóneo para ejecutar análisis de alto rendimiento. Azure Synapse grupo de SQL dedicado es un destino para la ingesta continua desde el entorno local. Se puede usar para su posterior procesamiento, así como servir los datos de Power BI a través de DirectQuery.

  3. Azure Pipelines se usa para orquestar la ingesta y transformación de datos en el área de trabajo de Azure Synapse.

Análisis e informes

Componentes

En este escenario se usan los siguientes componentes:

Arquitectura simplificada

Diagram of the enterprise BI simplified architecture.

Detalles del escenario

Una organización tiene un gran almacenamiento de datos local almacenado en una base de datos SQL. La organización quiere usar Azure Synapse para realizar análisis, y luego servir estos conocimientos usando Power BI.

Autenticación

Microsoft Entra autentica a los usuarios que se conectan a paneles y aplicaciones de Power BI. El inicio de sesión único se usa para conectarse al origen de datos en Azure Synapse grupo aprovisionado. La autorización se produce en el origen.

Carga incremental

Cuando se ejecuta un proceso automatizado de extracción, transformación y carga de datos (ETL) o de extracción, carga de datos y transformación (ELT), lo más eficaz es cargar solo los datos que han cambiado desde la ejecución anterior. Se llama carga incremental, frente a una carga completa, en la que se cargan todos los datos. Para realizar una carga incremental, se necesita alguna forma de identificar qué datos han cambiado. El método más común es usar un valor de marca de límite superior, lo que hace un seguimiento del valor más reciente de alguna de las columnas de la tabla de origen, una columna de fecha y hora o una columna de entero único.

A partir de SQL Server 2016, puede usar tablas temporales, que son tablas con versiones del sistema que mantienen un historial completo de los cambios de datos. El motor de base de datos registra automáticamente el historial de cada cambio en una tabla de historial independiente. Para consultar los datos históricos hay que agregar una cláusula FOR SYSTEM_TIME a una consulta. Internamente, el motor de base de datos consulta la tabla del historial, pero es transparente para la aplicación.

Nota

Para las versiones anteriores de SQL Server, puede usar captura de datos modificados (CDC). Este método es menos práctico que las tablas temporales, ya que hay que consultar una tabla de cambios independiente y el seguimiento de los cambios se realiza por un número de secuencia de registro, en lugar de una marca de tiempo.

Las tablas temporales son útiles para los datos de dimensión, que pueden cambiar con el tiempo. Las tablas de hechos suele representar una transacción inmutable, como por ejemplo una venta; en ese caso no tiene sentido mantener el historial de versiones del sistema. En su lugar, las transacciones suelen tener una columna que representa la fecha de la transacción, que se puede usar como valor de marca de agua. Por ejemplo, en el Data Warehouse AdventureWorks, las tablas SalesLT.* tienen un campo LastModified.

Este es el flujo general de la canalización de ELT:

  1. En todas las tablas de la base de datos de origen, realice un seguimiento de la hora límite en que se ejecutó el último trabajo de ELT. Almacene esta información en la base de datos de almacenamiento de datos En la instalación inicial, todas las horas se establecen en 1-1-1900.

  2. Durante el paso de exportación de datos, la hora límite se pasa como parámetro a un conjunto de procedimientos almacenados de la base de datos de origen. Estos procedimientos almacenados consultan cualquier registro que se haya modificado o creado después de la hora de corte. Para todas las tablas del ejemplo, puede usar la columna ModifiedDate.

  3. Una vez completada la migración de los datos, actualice la tabla que almacena las horas límite.

Canalización de datos

En este escenario se usa la base de datos de ejemplo AdventureWorks como origen de datos. El patrón de carga de datos incremental se implementa para asegurar que solo cargamos los datos que fueron modificados o añadidos después de la ejecución más reciente de la canalización.

Herramienta de copia controlada por metadatos

La herramienta de copia basada en metadatos integrada en Azure Pipelines carga incrementalmente todas las tablas contenidas en nuestra base de datos relacional. Si navega por la experiencia basada en el asistente, puede conectar la herramienta Copiar datos a la base de datos de origen y configurar la carga incremental o completa de cada tabla. A continuación, la herramienta Copiar datos crea las canalizaciones y los scripts SQL para generar la tabla de control necesaria para almacenar datos para el proceso de carga incremental; por ejemplo, el valor o la columna de límite máximo para cada tabla. Una vez ejecutados estos scripts, la canalización está lista para cargar todas las tablas del almacenamiento de datos de origen en el grupo dedicado de Synapse.

Screenshot of metadata-driven copy data tool in Synapse Analytics.

La herramienta crea tres canalizaciones para iterar todas las tablas de la base de datos antes de cargar los datos.

Las canalizaciones generadas por esta herramienta:

  • Contar el número de objetos, como tablas, que se van a copiar en la ejecución de la canalización.
  • Recorre en iteración cada objeto que se va a cargar o copiar y, después:
    • Compruebe si se requiere una carga diferencial; de lo contrario, complete una carga completa normal.
    • Recupere el valor de marca de agua alto de la tabla de control.
    • Copie datos de las tablas de origen en la cuenta de almacenamiento provisional de ADLS Gen2.
    • Cargue datos en el grupo de SQL dedicado a través del método de copia seleccionado, por ejemplo, Polybase, comando Copy.
    • Actualice el valor de límite máximo en la tabla de control.

Cargar datos en el grupo de SQL de Azure Synapse

La actividad de copia copia los datos de la base de datos SQL en el grupo de SQL de Azure Synapse. En este ejemplo, como nuestra base de datos SQL está en Azure, utilizamos el tiempo de ejecución de integración de Azure para leer los datos de la base de datos SQL y escribir los datos en el entorno de ensayo especificado.

La sentencia de copia se utiliza entonces para cargar los datos del entorno de ensayo en escena en el grupo dedicado a Synapse.

Use Azure Pipelines

Las canalizaciones de Azure Synapse se usan para definir el conjunto ordenado de actividades para completar el modelo de carga incremental. Los desencadenadores se usan para iniciar la canalización, que se puede desencadenar manualmente o en un momento especificado.

Transformar los datos

Dado que la base de datos de ejemplo de nuestra arquitectura de referencia no es grande, creamos tablas replicadas sin particiones. Para las cargas de trabajo de producción, el uso de tablas distribuidas probablemente mejore el rendimiento de las consultas. Consulte Instrucciones para diseñar tablas distribuidas en Azure Synapse. Los scripts de ejemplo ejecutan las consultas usando una clase de recurso estático.

En un entorno de producción, considere la posibilidad de crear tablas de almacenamiento provisional con distribución round-robin. A continuación, transforme y traslade los datos a las tablas de producción con índices de almacén de columnas agrupados, que ofrecen el mejor rendimiento global de las consultas. Los índices de almacén de columnas están optimizados para consultas que examinan muchos registros. Sin embargo no funcionan tan bien para las búsquedas singleton (es decir aquellas en las que la búsqueda se reduce a una sola fila). Si tiene que realizar búsquedas singleton frecuentes, puede agregar un índice no agrupado en una tabla. Este tipo de búsquedas pueden ejecutarse mucho más rápido usando un índice no agrupado. De todas formas, las búsquedas singleton son normalmente menos comunes en escenarios de almacenamiento de datos que las cargas de trabajo OLTP. Para más información, consulte Indexación de tablas en Azure Synapse.

Nota

Las tablas de almacén de columnas agrupado no admiten tipos de datos varchar(max), nvarchar(max) o varbinary(max). En ese caso, considere la posibilidad de un índice agrupado o de montón. Puede colocar esas columnas en una tabla independiente.

Uso de Power BI Premium para acceder, modelar y visualizar datos

Power BI Premium admite varias opciones para conectarse a orígenes de datos en Azure, en particular Azure Synapse grupo aprovisionado:

  • Importar: se importan los datos en el modelo BI.
  • DirectQuery: los datos se extraen directamente del almacenamiento relacional.
  • Modelo compuesto: combine la importación para algunas tablas y DirectQuery para otras.

Este escenario se entrega con el panel de DirectQuery porque la cantidad de datos usados y la complejidad del modelo no son altas, por lo que podemos ofrecer una buena experiencia de usuario. DirectQuery delega la consulta en el motor de proceso eficaz debajo y utiliza amplias funcionalidades de seguridad en el origen. Además, al usar DirectQuery se garantiza que los resultados siempre sean coherentes con los últimos datos de origen.

El modo de importación proporciona el tiempo de respuesta de consulta más rápido y debe tenerse en cuenta cuando el modelo se ajusta completamente en la memoria de Power BI, la latencia de datos entre las actualizaciones se puede tolerar y puede haber algunas transformaciones complejas entre el sistema de origen y el modelo final. En este caso, los usuarios finales quieren acceso total a los datos más recientes sin retrasos en la actualización de Power BI y todos los datos históricos, que son mayores que los que puede controlar un conjunto de datos de Power BI, entre 25 y 400 GB, en función del tamaño de la capacidad. Como el modelo de datos del grupo de SQL dedicado ya está en un esquema de estrella y no necesita ninguna transformación, DirectQuery es una opción adecuada.

Screenshot of dashboard in Power BI.

Power BI Premium Gen2 ofrece la capacidad de manipular modelos grandes, informes paginados, canalizaciones de implementación y punto de conexión integrado de Analysis Services. También puede tener capacidad dedicada con propuesta de valor única.

Cuando el modelo de BI crece o aumenta la complejidad del panel, puede cambiar a modelos compuestos y empezar a importar partes de tablas de búsqueda, a través de tablas híbridas y algunos datos agregados previamente. Habilitar el almacenamiento en caché de consultas en Power BI para conjuntos de datos importados es una opción, así como usar tablas duales para la propiedad del modo de almacenamiento.

Dentro del modelo compuesto, los conjuntos de datos actúan como una capa de paso a través virtual. Cuando el usuario interactúa con visualizaciones, Power BI genera consultas SQL en grupos de Synapse SQL de almacenamiento dual: en memoria o consulta directa en función de cuál sea más eficaz. El motor decide cuándo cambiar de una consulta en memoria a una consulta directa e inserta la lógica en el grupo de SQL de Synapse. Según el contexto de las tablas de consulta, pueden actuar como modelos compuestos almacenados en caché (importados) o no almacenados en caché. Elija qué tabla almacenar en caché en la memoria, combine datos de uno o varios orígenes de DirectQuery o combine datos de una combinación de orígenes de DirectQuery y datos importados.

Recomendaciones: Al usar DirectQuery en Azure Synapse grupo aprovisionado de Analytics:

  • Use Azure Synapse almacenamiento en caché del conjunto de resultados para almacenar en caché los resultados de la consulta en la base de datos de usuario para su uso repetitivo, mejorar el rendimiento de las consultas hasta milisegundos y reducir el uso de recursos de proceso. Las consultas que usan conjuntos de resultados almacenados en caché no usan ranuras de simultaneidad en Azure Synapse Analytics y, por tanto, no cuentan con los límites de simultaneidad existentes.
  • Use Azure Synapse vistas materializadas para calcular, almacenar y mantener datos como una tabla. Las consultas que usan todos o un subconjunto de los datos en vistas materializadas pueden obtener un rendimiento más rápido y no necesitan hacer una referencia directa a la vista materializada definida para usarla.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Los titulares frecuentes de las infracciones de datos, las infecciones de malware y la inyección de código malintencionado se encuentran entre una amplia lista de problemas de seguridad para las empresas que buscan la modernización de la nube. Los clientes empresariales necesitan un proveedor de la nube o una solución de servicio que pueda responder a sus preocupaciones, ya que no pueden permitirse el lujo de equivocarse.

Este escenario aborda los problemas de seguridad más exigentes mediante una combinación de controles de seguridad por capas: red, identidad, privacidad y autorización. La mayor parte de los datos se almacena en Azure Synapse grupo aprovisionado, con Power BI mediante DirectQuery a través del inicio de sesión único. Puede usar Microsoft Entra ID para la autenticación. También hay controles de seguridad amplios para la autorización de datos de grupos aprovisionados.

Estas son algunas preguntas sobre seguridad habituales:

  • ¿Cómo puedo controlar quién puede ver los distintos datos?
    • Las organizaciones deben proteger sus datos para cumplir las directrices regionales, locales y empresariales para mitigar los riesgos de vulneración de datos. Azure Synapse ofrece varias funcionalidades de protección de datos para lograr el cumplimiento.
  • ¿Cuáles son las opciones para comprobar la identidad de un usuario?
  • ¿Qué tecnología de seguridad de red puedo usar para proteger la integridad, la confidencialidad y el acceso a mis redes y datos?
    • Para asegurar Azure Synapse, hay una serie de opciones de seguridad de red disponibles para considerar.
  • ¿Cuáles son las herramientas que detectan amenazas y las notifican?
    • Azure Synapse proporciona muchas capacidades de detección de amenazas como: Auditoría SQL, detección de amenazas SQL y evaluación de vulnerabilidades para auditar, proteger y supervisar las bases de datos.
  • ¿Qué puedo hacer para proteger los datos en mi cuenta de almacenamiento?
    • Las cuentas de Azure Storage son ideales para cargas de trabajo que requieren tiempos de respuesta rápidos y consistentes, o que tienen un alto número de operaciones de entrada-salida (IOP) por segundo. Las cuentas de almacenamiento contienen todos los objetos de datos de Azure Storage y tienen muchas opciones para la seguridad de la cuenta de almacenamiento.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

En esta sección se proporciona información sobre los precios de los distintos servicios implicados en esta solución y se mencionan las decisiones tomadas para este escenario con un conjunto de datos de ejemplo.

Azure Synapse

La arquitectura sin servidor de Azure Synapse Analytics le permite escalar los niveles de proceso y almacenamiento por separado. Los recursos de proceso se cobran según el uso, y puede escalar o pausar estos recursos a petición. Los recursos de almacenamiento se facturan por terabyte, por lo que los costos aumentan con la ingesta de datos.

Azure Pipelines

Los detalles de precios de las canalizaciones en Azure Synapse se pueden encontrar en la pestaña Integración de datos de la página de precios de Azure Synapse. Hay tres componentes principales que influyen en el precio de una canalización:

  1. Actividades de canalización de datos y horas en entorno de ejecución de integración
  2. Tamaño y ejecución del clúster de flujos de datos
  3. Cargos de operaciones

El precio varía en función de los componentes o actividades, la frecuencia y el número de unidades del entorno de ejecución de integración.

Para el conjunto de datos de ejemplo, el entorno de ejecución de integración hospedado en Azure estándar, la actividad de copia de datos para el núcleo de la canalización, se desencadena según una programación diaria para todas las entidades (tablas) de la base de datos de origen. El escenario no contiene flujos de datos. No hay costos operativos, ya que hay menos de 1 millón de operaciones con canalizaciones al mes.

Azure Synapse grupo dedicado y almacenamiento

Los detalles de precios de Azure Synapse grupo dedicado se pueden encontrar en la pestaña Almacenamiento de datos de la página de precios de Azure Synapse. En el modelo de consumo dedicado, los clientes se facturan por unidades de DWU aprovisionadas, por hora de tiempo de actividad. Otro factor de contribución es los costos de almacenamiento de datos: tamaño de los datos en reposo + instantáneas + redundancia geográfica, si existe.

Para el conjunto de datos de ejemplo, puede aprovisionar 500DWU, lo que garantiza una buena experiencia para la carga analítica. Puede mantener el proceso en funcionamiento durante las horas laborables de los informes. Si se toma en producción, la capacidad reservada del almacenamiento de datos es una opción atractiva para la administración de costos. Se deben usar diferentes técnicas para maximizar las métricas de costo y rendimiento, que se tratan en las secciones anteriores.

Blob Storage

Considere la posibilidad de usar la función de capacidad reservada de Azure Storage para reducir los costos de almacenamiento. Con este modelo, se obtiene un descuento si se reserva una capacidad de almacenamiento fija durante uno o tres años. Para más información Optimización de los costos de almacenamiento de blobs con capacidad reservada.

No hay almacenamiento persistente en este escenario.

Power BI Premium

Power BI Premium detalles de precios se pueden encontrar en la página de precios de Power BI.

En este escenario se usan áreas de trabajo Power BI Premium con una serie de mejoras de rendimiento integradas para satisfacer las necesidades analíticas exigentes.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Recomendaciones de DevOps

  • Cree grupos de recursos independientes para entornos de producción, desarrollo y pruebas. Los grupos de recursos independientes facilitan la administración de implementaciones, la eliminación de implementaciones de prueba y la asignación de derechos de acceso.

  • Coloque cada carga de trabajo en una plantilla de implementación independiente y almacene los recursos en los sistemas de control de código fuente. Puede implementar las plantillas de forma conjunta o individual como parte de un proceso de integración continua (CI) y entrega continua (CD), lo que facilita el proceso de automatización. En esta arquitectura, hay cuatro cargas de trabajo principales:

    • El servidor de almacenamiento de datos y los recursos relacionados.
    • Canalizaciones de Azure Synapse
    • Recursos de Power BI: paneles, aplicaciones, conjuntos de datos
    • Escenario simulado de local a la nube

    Tenga como objetivo tener una plantilla de implementación independiente para cada una de las cargas de trabajo.

  • Considere la posibilidad de almacenar provisionalmente las cargas de trabajo donde sea práctico. Realice la implementación en varias fases y ejecute comprobaciones de validación en cada fase antes de pasar a la siguiente fase. De este modo, puede enviar actualizaciones a los entornos de producción de una manera controlada y minimizar los problemas de implementación imprevistos. Use las estrategias de implementación azul-verde y versiones de valores controlados para actualizar entornos de producción en directo.

  • Tenga una buena estrategia de reversión para administrar implementaciones con errores. Por ejemplo, puede volver a implementar automáticamente una implementación anterior que sea correcta desde el historial de implementación. Ver el marcador --rollback-on-error en Azure CLI.

  • Azure Monitor es la opción recomendada para analizar el rendimiento del almacenamiento de datos y toda la plataforma de análisis de Azure para una experiencia de supervisión integrada. Azure Synapse Analytics proporciona una experiencia de supervisión dentro de Azure Portal que muestra la información a la carga de trabajo del almacenamiento de datos. Azure Portal es la herramienta recomendada al supervisar el almacenamiento de datos, porque proporciona períodos de retención configurables, alertas, recomendaciones, y gráficos y paneles personalizables para métricas y registros.

Inicio rápido

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

En esta sección se proporcionan detalles sobre las decisiones de ajuste de tamaño para dar cabida a este conjunto de datos.

Grupo aprovisionado de Azure Synapse

Hay una variedad de configuraciones de almacenamiento de datos entre las que elegir.

Unidades de almacenamiento de datos Número de nodos de proceso Número de distribuciones por nodo
DW100c 1 60
-- TO --
DW30000c 60 1

Para ver las ventajas de rendimiento de escalado, especialmente para las unidades de almacén de datos más grandes, use al menos un conjunto de datos de 1 TB. Para encontrar el mejor número de unidades de almacén de datos para su grupo de SQL dedicado, pruebe a escalarlo y reducirlo verticalmente. Ejecute algunas consultas con distintos números de unidades de almacenamiento de datos después de cargar los datos. Dado que el escalado se realiza rápidamente, puede probar varios niveles de rendimiento en una hora o menos.

Búsqueda del mejor número de unidades de almacenamiento de datos

Para un grupo de SQL dedicado en desarrollo, comience por seleccionar un número más pequeño de unidades de almacenamiento de datos. Un buen punto de partida es DW400c o DW200c. Supervise el rendimiento de la aplicación y observe el número de unidades de almacenamiento de datos seleccionadas en comparación con el rendimiento observado. Suponga una escala lineal y determine cuánto debe aumentar o reducir las unidades de almacenamiento de datos. Continúe realizando ajustes hasta llegar a un nivel de rendimiento adecuado para sus requerimientos empresariales.

Escalado del grupo de SQL de Synapse

Azure Pipelines

Para conocer las características de escalabilidad y optimización del rendimiento de las canalizaciones en Azure Synapse y la actividad de copia usada, consulte la guía de rendimiento y escalabilidad de actividad de copia.

Power BI Premium

En este artículo se usa Power BI Premium Gen 2 para demostrar las funcionalidades de BI. Las SKU de capacidad para Power BI Premium oscilan entre P1 (ocho núcleos virtuales) y P5 (128 núcleos virtuales) actualmente. La mejor manera de seleccionar la capacidad necesaria es someterse a una evaluación de carga de capacidad, instalar la aplicación de métricas de Gen 2 para la supervisión en curso y considerar la posibilidad de usar la escalabilidad automática con Power BI Premium.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes