🤜🏼 🥊 🤫 Cómo evitar errores al crear informes en Power BI y llegar a la construcción de un sistema de carga para big data 💒 🚭 ⛹🏻

Detrás de los hermosos y comprensibles paneles de Power BI a menudo hay semanas de preparación y minería de datos. Especialmente cuando se trata de crear informes de BI útiles en una organización grande con un volumen de tráfico de decenas de millones de visitantes cada mes.

En este artículo, quiero describir una serie de aspectos negativos que encontré al crear informes de BI basados en datos de sistemas de análisis web en varias compañías (grandes representantes del comercio electrónico ruso, compañías de seguros, etc.). El artículo no pretende hacer publicidad, o viceversa, la publicidad de ciertas herramientas o decisiones. Está preparado para ayudar a evitar posibles momentos negativos para otros usuarios e indicar opciones para soluciones.

Descargo de responsabilidad

Estoy hablando de grandes cantidades de datos y mostrando ejemplos de carga y muestreo de Google Analytics 360. En proyectos con una pequeña cantidad de datos, tales dificultades pueden no existir. Conocí todos los problemas identificados en la práctica y en el artículo describo solo mi experiencia en la resolución: la suya puede ser completamente diferente.

Conector a Yandex.Metrica

Yandex.Metrica tiene condiciones de muestreo más suaves y una interfaz intuitiva en comparación con Google Analytics. Por lo tanto, muchos especialistas en marketing prefieren Yandex.Metrica y crean informes de BI sobre la carga de datos desde allí. Para hacer esto, use el conector de Maxim Uvarov. Este método no es seguro y no permite procesar solicitudes complejas.

Las grandes empresas necesitan una garantía de que la información confidencial no caerá en manos de los detractores, y los indicadores financieros se utilizarán solo para las partes interesadas y exclusivamente dentro de la empresa.

El primer gran inconveniente es que para usar el conector, en Power BI debe habilitar la configuración "Ignorar niveles de privacidad", de lo contrario, simplemente no funcionará.

Por lo tanto, los datos confidenciales pueden caer en manos de cualquier usuario no autorizado. Esto se confirma con un extracto de la Ayuda de Power BI.

La conexión de datos es anónima. Sin embargo, no hay autorización o verificación de permiso para usar estos datos para aquellos usuarios que realmente están autorizados a hacerlo.

Para que estos conectores funcionen, debe obtener un token de acceso oauth. La descripción del conector proporciona un enlace sobre cómo dar acceso a la aplicación a su cuenta.

De hecho, una aplicación de terceros obtendrá acceso a su cuenta. Nadie tiene una garantía para la seguridad de sus datos.

El segundo inconveniente es que la API Yandex.Metrica no puede procesar grandes cantidades de datos en proyectos grandes y, como resultado, el conector también se niega a trabajar con consultas complejas en datos Yandex.Metrica sin procesar, no los descarga.

Por ejemplo, debe cargar datos durante un año, sin filtros complejos. El conector arroja un error: "La solicitud es demasiado compleja. Reduzca el espaciado de fecha o el muestreo ".

Por supuesto, esta es una traducción del error de la API Yandex.Metrica. Sin embargo, en este caso, no tenemos otra opción para descargar datos con un desglose por mes o día, por ejemplo, para completar los datos de cada mes y combinarlos en un solo conjunto de datos que supere un error de API.
Si reduce significativamente el período, la API le permite bombear datos, pero esto es solo una pequeña parte de lo que necesitamos.

Para generar informes de gran tamaño, la descarga por períodos cortos no es práctica ni conveniente. En la práctica, a menudo necesita descargar a través de embudos complejos de sitios abiertos con una gran cantidad de visitas por día. Especialmente cuando se utilizan segmentos complejos de visitas, es prácticamente imposible cargar los datos necesarios.

Incluso si pudo cargar los datos, no es un hecho que sea posible cargarlos en el modelo de datos para generar el informe en sí, porque de vez en cuando aparecen varios errores de carga. Por alguna razón, incluso con una tabla cargada normalmente, se producen errores.

Para que todas las partes interesadas dentro de la empresa puedan usar el informe creado en el conector API Yandex.Metrica, debe publicar el informe en el servicio PowerBI. En este caso, los niveles de privacidad también deberán ignorarse.

Cuando se configura la visualización y el informe se publica en la nube de Microsoft, el conector mostrará un error de consulta combinado y no se actualizará a través del servicio Power BI; no podrá configurar la actualización programada de su informe. El error ocurre cuando una de las consultas, que forma la tabla de carga final, contiene la lógica del trabajo simultáneo con la consulta externa e interna.

En el error, la

tabla "Función llamada" solo se indica: esta tabla se obtiene debido a la función PQYM, que funciona con una fuente de datos externa: Yandex.Metrica API. El mecanismo de actualización de informes en Power BI no funciona y solicita rehacer la combinación de consultas. Esto se debe a los enlaces internos de una solicitud para conectarse a una solicitud externa, así como a la estructura de la función misma.

Decidimos no usar dicho conector al crear informes y cambiamos a descargar datos de la API Yandex.Metrica a través de scripts de Python, más sobre esto más adelante en el artículo.

Conector de Google Analytics

Para generar informes sobre los datos de Google Analytics (estamos hablando de descargas directas desde el sistema de análisis), también hay un conector Maxim Uvarov.

Aquí también deberá establecer "Ignorar los niveles de privacidad". El acceso a la API de su sistema de análisis, que contiene datos sobre ventas en línea, se realiza mediante una conexión anónima.

De acuerdo con las instrucciones, nuevamente tendrá que abrir el acceso a una aplicación de terceros, solo para una cuenta de Google, que contiene una amenaza para la privacidad de sus datos.

Puede reescribir algunos datos en el conector y comenzar a usarlos para su propia aplicación. Para hacer esto, registre "OAuth 2.0 Client ID" en cloud.google.com, obtenga tokens de acceso e ingrese las claves de acceso necesarias en su mecanismo de trabajo. Pero incluso estas acciones no ayudarán en la lucha contra el muestreo y la actualización de sus informes.

Siempre que toque los datos agregados de la API de Google Analytics, siempre encontraremos muestras.

El conector tiene la opción de descargar un día, pero incluso no siempre se guarda. El indicador de muestreo incorporado en el conector muestra que está allí incluso en un día.

Por ejemplo, los datos de sesión desglosados por Shopping Stage no se pueden cargar sin tomar muestras de tales cantidades de datos. Esto generará grandes errores en los datos y las medidas al crear informes, especialmente cuando sea necesario calcular con precisión la conversión de la transición de un paso a otro, o cargar datos en embudos con una estructura compleja de segmentos.

Incluso si la pérdida de datos no es crítica para usted, aún no puede configurar la actualización programada de sus informes a través del servicio Power BI.

El mismo error del mecanismo de trabajo interfiere, solo las funciones PQGA.

También nos negamos a trabajar con este conector.

Conector nativo de Google Analytics

A veces, Google y Microsoft hacen concesiones entre sí: Power BI tiene un conector estándar de Google Analytics. Desafortunadamente, no existe tal opción para Yandex.Metrica.

El mecanismo para trabajar con la API de Google Analytics se implementa más convenientemente aquí que en el conector de Maxim Uvarov, pero al descargar una gran cantidad de indicadores, los datos se muestrean demasiado. Los números que se repiten en la captura de pantalla son los datos muestreados.

Puede evitar el muestreo si descarga mini-tablas desglosadas solo por fecha y cualquier indicador. Por ejemplo, fecha, número de sesiones y tipo de dispositivo. Y luego de estas tablas para recopilar los informes necesarios.

Si no tiene millones de tráfico, esto puede ayudar. Sin embargo, los informes no serán informativos y con limitaciones en la escalabilidad: debido a las muchas mini-tablas en el modelo de datos, es difícil crear relaciones entre ellas. Esto impone una restricción en la creación de filtros y sectores.

Puede volver a escribir el conector estándar y obligarlo a cargar datos para cada día, mientras que los datos estarán cerca de los números reales en la interfaz de GA, pero no podrá evitar el muestreo.

Según mis observaciones, en el desglose de las sesiones de la Etapa de compras, ni un solo conector ha podido cargar datos normalmente sin muestrear grandes cantidades de datos.

En el conector estándar, no puede personalizar las fechas de descarga. Todo lo que se trata es simplemente una selección de parámetros y métricas de las API de Google Analytics organizadas en carpetas.

Este conector es adecuado para proyectos de Internet pequeños y medianos con poco tráfico. Aquí, surge una situación similar con la obtención de datos de Yandex.Metrica. Toda la información necesaria sin pérdida de precisión solo se puede descargar directamente a través de la API mediante scripts o servicios especiales de transmisión de datos, más sobre esto más adelante en el artículo.

Sticks in Wheels de Google

Recientemente, notamos un bloqueo extraño: al intentar configurar la actualización para el conector "nativo" de Google Analytics, apareció un error de autorización a través de una cuenta de Google en la interfaz del Servicio Power BI.

Intentamos averiguar de Google qué hacer en tal situación y cómo "blanquear" la reputación de la cuenta, pero nuestros intentos fallaron. Intentamos registrar nuevas cuentas e iniciar sesión a través de diferentes dispositivos: Google bloqueó cualquier intento de autorización.

Aproximadamente un mes después del bloqueo, todavía logramos iniciar sesión a través de la misma cuenta, pero tal incidente puede interferir seriamente con la publicación de los informes de BI necesarios de manera oportuna y poner al cliente en una posición incómoda. Inmediatamente después de la cerradura, comenzamos a buscar una posible salida de la situación. Para evitar bloqueos inesperados, decidimos crear nuestro propio entorno controlado con los datos necesarios para los informes de BI.

Opciones de solucion

Obtenga los informes de BI necesarios para organizaciones medianas y grandes, e incluso sin muestreo es posible. Pero debe probar un poco y elegir una de varias maneras.

Puede usar servicios listos para transmitir datos. Su objetivo principal es cargar datos desde el sistema de análisis, varios sistemas de publicidad, CRM y otros servicios a cualquier almacenamiento. Conveniente, rápido y práctico, pero no gratuito. En grandes volúmenes de datos o datos con múltiples fuentes, las cantidades son tangibles.

Los servicios más famosos:

Cada uno de estos sistemas le permite configurar la transmisión diaria de datos no muestreados desde sistemas de análisis web (Yandex.Metrics y Google Analytics) a bases de datos (por ejemplo, BigQuery, Azure SQL Database, Microsoft SQL Server o ClickHouse) para conectarse a través de Power BI y generar informes.

Si las herramientas enumeradas son demasiado caras para la empresa, puede intentar implementar su sistema de carga de datos y usar Power BI + Python + Any Cloud Server (o Yandex.Cloud) + PostgreSQL. Este es el método que utilizamos al crear informes de BI.

Esquema de interacción del sistema:

Tal esquema de trabajo proporciona la seguridad necesaria, la autonomía y la agregación de datos. Una vez que haya establecido dicho esquema una vez, no necesitará perder tiempo recopilando información: todo está en el repositorio, solo tiene que conectarse y comenzar a hacer un informe sobre Power BI.

Los scripts de Python "extraen" todos los datos de acuerdo con la API de las fuentes necesarias, escriben en la base de datos o descargan formularios (por ejemplo, en formato csv). Las secuencias de comandos para cargar desde la API y cargar en la base de datos merecen un artículo separado, y algún día lo escribiré.

Por supuesto, hay muchas plantillas y soluciones preparadas en Internet, pero para una mayor ampliación es necesario conocer las necesidades individuales del sistema bajo el cual se crean los scripts para la descarga.

Los datos se escriben en una base de datos pre-creada y configurada, en nuestro caso, PostgreSQL. Los scripts extraen datos de cada día y los escriben en tablas según un cronograma. Están ubicados en un servidor en la nube bajo nuestro control o bajo el control del servicio de seguridad de TI del cliente.

Hay una gran cantidad de empresas que brindan servicios de almacenamiento en la nube. Basado en preferencias personales, se seleccionó Yandex . Cloud .

Ventajas de Yandex.Cloud:

Configuración conveniente y alquiler de servidores con PostgreSQL preinstalado.
Amplia documentación en ruso, que está claramente establecida y le permite aprender rápidamente cómo usar el servicio.
Conveniente gestión del servidor.
Soporte rápido de especialistas.
Flexibilidad de varias configuraciones y tarifas de equipos: nadie impone ningún paquete de configuración listo para usar, usted elige la configuración de su equipo usted mismo, además puede solicitar de inmediato la configuración predeterminada de cualquier base de datos.

Las cargas resultantes se escriben en la base de datos PostgreSQL. Se eligió esta base de datos porque es un DBMS relacional de objetos (que funciona con matrices multidimensionales y soporte JSON desde el "cuadro", por lo que deben tener estructuras de datos complejas). Es flexible, confiable, gratuito y también tiene una gran comunidad de soporte.

Power BI tiene un conector directo incorporado en PostgreSQL. En la primera conexión, debe instalar Npgsql adicional . Power BI le notifica esto y proporciona un enlace.

Para configurar las actualizaciones de informes cuando se usa el almacenamiento en la nube, debe configurar Power BI Gateway . Es necesario configurar la actualización de los informes de BI y garantizar la seguridad de los datos confidenciales al transferirlos desde una base de datos, que debe ubicarse en el circuito interno de TI de su organización o en un servidor seguro en la nube.

La puerta de enlace proporciona una transferencia de datos rápida y segura entre los almacenes de datos ubicados en la red interna de la organización y los servicios en la nube de Microsoft. La transferencia de datos entre Power BI y la puerta de enlace es segura, y todas las credenciales proporcionadas por los administradores de la puerta de enlace se cifran para proteger la información en la nube y se descifran solo en la computadora de la puerta de enlace.

Después de descargar Power BI Gateway e iniciarlo, aparece un cuadro de diálogo.

Para registrar y operar la puerta de enlace, se requieren las credenciales del servicio en la nube del Servicio Power BI.

Después de todas las configuraciones, aparecerá una ventana sobre la puerta de enlace en funcionamiento. A continuación, debe realizar configuraciones adicionales.

Una alternativa más simple para personalizar PostgreSQL es Google BigQuery. Power BI tiene un conector incorporado en Google BigQuery. En este caso, es necesario seguir el principio de "siete veces para calcular el costo, una vez para cumplir con la solicitud".

BigQuery se puede utilizar de forma gratuita durante un año, simplemente atando una tarjeta bancaria a un acuerdo para usar el servicio. El dinero después de la fecha límite sin su conocimiento no será cargado. Nuevas tarifas: de acuerdo con las tarifas del sistema en sí, pero con algunas "ventajas" agradables.

Si los datos descargados de sus sistemas no alcanzan los 10 GB por mes (!), No habrá ningún cargo por la descarga.

Si el procesamiento de datos mensual no excede 1 TB, tampoco se cobrará ninguna tarifa por esto. Si es más, entonces $ 5 por cada tratamiento 1 TB.

Si necesita almacenar más de 10 GB por mes, cada gigabyte posterior costará $ 0.010.

Las tarifas se describen con más detalle en la página BigQuery.

Resumen

Si necesita datos de varios sistemas de análisis y, al mismo tiempo, la seguridad, la agregación continua, la usabilidad y la falta de muestreo son fundamentales para usted, tiene dos formas.

El primero es la transmisión de servicios. Son fáciles de usar, cuentan con soporte técnico continuo e integración lista para usar con almacenes de datos.

Desventajas

Costos tangibles en grandes cantidades de datos.
Tipo limitado de integración proporcionada.
Procesos no controlados del lado del proveedor de servicios de transmisión para trabajar con su información.

El segundo es su propia secuencia de carga y agregación de datos. Escalable, controlado, con seguridad de datos. Puede parecer complicado y llevar mucho tiempo implementarlo. Si la empresa necesita una organización efectiva de informes de BI, su mayor escalabilidad y seguridad de datos, entonces esta opción es la más aceptable.

Todos aquellos que solo piensan en informes de BI completos deben agregar el lema "Acumular, estructurar y proteger estos datos de los jóvenes" en la cultura corporativa. No hay nada mejor que una base de datos tolerante a fallas completa con una copia de seguridad regular y con derechos diferenciados para usarla para diferentes categorías de partes interesadas.

Es necesario acumular, estructurar y agregar sus datos desde sistemas analíticos, y desde una aplicación móvil, y desde otros servicios al cliente. Todo esto en el futuro ayudará a analizar tanto su audiencia como sus productos en cualquier sección. La información y los datos ahora gobiernan el mundo y a veces cuestan más que el dinero.

Cómo implementar el enfoque descrito en el artículo para transferir datos analíticos a una base de datos PostgreSQL usando scripts Python y detalles de implementación, lo analizaré en los siguientes artículos.

Cómo evitar errores al crear informes en Power BI y llegar a la construcción de un sistema de carga para big data