Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La observabilidad de los datos le permite comprender el estado de los datos y los sistemas de datos mediante la recopilación y correlación de eventos entre áreas como datos, almacenamiento, proceso y canalizaciones de procesamiento.
La creación y el funcionamiento de una plataforma de datos resistente, escalable y eficaz requiere la adopción de procesos probados inspirados en DevOps en equipos que representan dominios funcionales. La observabilidad de los datos permite a los propietarios de empresas, ingenieros de DevOps, arquitectos de datos, ingenieros de datos e ingenieros de confiabilidad de sitios web automatizar la detección, predicción y prevención de problemas, y evitar tiempos de inactividad que puedan interrumpir el análisis de producción y la inteligencia artificial.
Áreas principales de la observabilidad de los datos
La mayoría de las plataformas de datos funcionan en estas áreas principales de observabilidad de los datos:
- Supervisión del servicio de plataforma de datos
- Supervisión del rendimiento de la canalización de datos
- Supervisión de la calidad de los datos
- Linaje de los datos
- Detección de datos
La observabilidad de los datos de un extremo a otro implica no solo capturar eventos y medir métricas en todos estos componentes, sino también correlacionar esos eventos y métricas. Esto proporciona una vista completa del estado y la confiabilidad del entorno de datos empresariales.
En este artículo se describe cada componente y cómo contribuye a lograr la observabilidad de los datos.
Supervisión del servicio de plataforma de datos
La infraestructura fundamental de una plataforma de datos empresarial puede incluir una combinación de infraestructura administrada por el proveedor y autoadministrada para habilitar el almacenamiento y la informática. Los ingenieros de DevOps o ingenieros de infraestructura deben supervisar esta infraestructura fundamental para poder identificar y resolver interrupciones del sistema y cuellos de botella de rendimiento que afectan a las canalizaciones modernas de datos y análisis.
La supervisión de datos de bases de datos y capas de red puede mejorar el rendimiento del procesamiento y minimizar la latencia de red. Los equipos necesitan herramientas que puedan usar para capturar métricas, notificar, supervisar y corregir incidentes y correlacionarse con los datos y los problemas de análisis.
Se recomienda que los equipos incorporen la observabilidad como código en la capa de infraestructura como código, de forma que la instrumentación de supervisión esté habilitada de forma predeterminada en cuanto creen un recurso. La mayoría de los servicios de Azure ofrece instrumentación integrada para métricas de recursos clave, como los datos de diagnóstico.
Supervisión del rendimiento de la canalización de datos
Las canalizaciones de datos cada vez más complejas que contienen varias fases y dependencias ahora generan grandes cantidades de datos de supervisión. Estos datos incluyen eventos, métricas y registros. Puede optimizar el rendimiento de la canalización de datos mediante la recopilación y el análisis de los datos de supervisión.
Los equipos de datos deben supervisar el estado de las canalizaciones de datos en varios productos de datos relacionados y dominios empresariales. Cuando el equipo recibe una notificación anticipada sobre errores o tiempos de ejecución que son más largos de lo esperado, se puede minimizar y corregir el tiempo de inactividad. La correlación de los datos de supervisión de canalización y la supervisión del servicio de plataforma puede proporcionar recomendaciones para el ajuste del rendimiento, como aumentar la CPU y la memoria para las canalizaciones de carga alta.
Supervisión de la calidad de los datos
La calidad de los datos es el grado en que los datos son precisos, completos, oportunos y coherentes con los requisitos de su organización. Debe supervisar constantemente los conjuntos de datos para asegurarse de que las aplicaciones de datos que potencian sigan siendo fiables y de confianza. DataOps ha mejorado constantemente la confiabilidad y el rendimiento de los datos mediante la automatización de las pruebas de calidad de datos (unitarias, funcionales y de integración). Estas mejoras hacen posible la detección de errores y un análisis de datos más rápido y eficaz.
Para adoptar DevOps y principios de SRE en la calidad de los datos, los equipos deben crear procesos y marcos repetibles e iterativos para detectar problemas de calidad de datos, supervisar esos problemas en los paneles y configurar alertas para cualquier desviación.
Se puede hacer un seguimiento del tiempo de detección (TTD), el tiempo de recuperación (TTR) y otras métricas de calidad de datos desde la supervisión de la calidad de los datos. TTD hace referencia al período de tiempo que tarda el equipo de datos en detectar un problema de calidad de datos de cualquier tipo, desde anomalías de actualización hasta cambios de esquema que interrumpen canalizaciones completas. TTR hace referencia al período de tiempo necesario para que el equipo resuelva un incidente de datos una vez alertado. Mejorar la calidad de los datos es más que un desafío técnico; implica un importante apoyo organizativo y cultural.
La sección de gobernanza sobre la calidad de los datos explora cómo puede implementar la calidad de los datos en su escenario.
Linaje de datos
El linaje de datos se entiende ampliamente como un registro continuo que sigue el origen, las transformaciones y el movimiento de los datos a lo largo del tiempo en su patrimonio de datos. El linaje de datos se usa en tareas retrospectivas, como la solución de problemas, la depuración y el seguimiento de las causas principales de los problemas de canalización. El linaje también se usa en el análisis de calidad de los datos, el cumplimiento y los escenarios de tipo "what if", a los que a menudo se hace referencia como análisis de impacto.
El linaje se representa visualmente para mostrar los datos que se transfieren del origen al destino; asimismo, también se incluye el modo en que se transforman los datos a lo largo del tiempo.
La sección de gobernanza sobre el linaje de los datos explora cómo puede implementar el linaje de los datos en su escenario.
Detección de datos
Para los consumidores, la detección de datos es el primer paso en una carga de trabajo de análisis o gobernanza de datos. En una plataforma de lago de datos empresarial, es difícil para los consumidores de datos (como científicos y analistas de datos) localizar los datos que necesitan y evaluar su confiabilidad. Los catálogos de datos con metadatos precisos facilitan las búsquedas mediante el índice de datos que proporciona:
- Ubicaciones de datos disponibles
- Detección de calidad de datos
- Comprensión de la estructura de datos
- Comprensión del linaje de datos
- Acceso a los datos deseados
Los catálogos de datos que ofrecen estas funcionalidades de búsqueda aumentan la velocidad de todos los procesos de detección de datos.
La sección de gobernanza sobre los catálogos de datos explora cómo puede implementar el descubrimiento de los datos en su escenario.
Establecimiento de acuerdos de nivel de servicio (SLA), indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO)
Los equipos de su organización pueden adoptar procedimientos de ingeniería de confiabilidad de sitios (SRE) de estilo DevOps para la supervisión de datos. Los acuerdos de nivel de servicio (SLA), los indicadores de nivel de servicio (SLI) y los objetivos de nivel de servicio (SLO) pueden ayudar a su organización a reducir el tiempo de inactividad y garantizar la confiabilidad de los datos.
Contratos de nivel de servicio (SLA)
Los acuerdos de nivel de servicio requieren SLI bien definidos, que son medidas cuantitativas de calidad del servicio y SLO acordados, que son los valores o intervalos ideales que debe cumplir cada SLI.
Establecer un Acuerdo de Nivel de Servicio de datos requiere la participación activa y la colaboración de todas las partes interesadas que se verán afectadas por el mismo. Estas partes interesadas pueden incluir productores de datos, ingenieros de datos, analistas de datos, consumidores de datos, analistas de negocios y otros.
La configuración de acuerdos de nivel de servicio de confiabilidad suele incluir tres pasos: definir, medir y supervisar.
Comience a establecer el Acuerdo de Nivel de Servicio definiendo lo que significa la confiabilidad. Todas las partes interesadas clave deben acordar esta definición. Asegúrese de que todas las partes interesadas clave participen y se impliquen, especialmente si los consumidores de bajada proceden de diferentes equipos o de diferentes regiones geográficas y zonas horarias.
Su Acuerdo de Nivel de Servicio se debe diseñar cuidadosamente. Implique a su equipo legal si los consumidores de datos son clientes de pago externos. Para los clientes internos, la definición del Acuerdo de Nivel de Servicio debe incluir áreas clave como la promesa de datos, la calidad de los datos y un proceso para controlar incidentes de datos si no se cumple la promesa.
Ejemplo de Acuerdo de Nivel de Servicio
Supongamos que Contoso es una empresa de medios que ejecuta un lago de datos empresarial y este lago de datos alimenta múltiples productos de datos en diferentes dominios empresariales. El equipo de aplicaciones de datos de Contoso es responsable de proporcionar los datos de ventas del día anterior que alimentan el panel de información de Contoso. Cuando se pierde una entrega de datos o se entregan datos incompletos, el equipo de ingeniería de datos se enfrenta a correos electrónicos de ejecutivos frustrados y tiene que evaluar manualmente la canalización rota que se supone que debe entregar datos de ventas. Para medir y mejorar sus resultados, el equipo de datos establece un Acuerdo de Nivel de Servicio con el equipo de ventas, como se muestra en la sección siguiente.
Acuerdo de Nivel de Servicio: equipo de datos a equipo de ventas
Contrato | Descripción |
---|---|
Área de negocio | El equipo de datos promete potenciar la capacidad del equipo de ventas para tomar decisiones basadas en datos |
Promise | El equipo de datos se compromete a entregar los datos de ventas del día anterior que alimentan el panel de información de ventas. Estos datos pueden proporcionar tasas de ventas y conversión para todas las regiones de EE. UU. Las canalizaciones de datos entregarán datos al panel de información de ventas antes de las 6:00 UTC |
Calidad de los datos | Comprobación de valores NULL: el nombre del cliente no puede ser NULL. Valor ausente: la región del cliente no puede faltar. Actualización: la fecha de ventas debe incluir cualquier transacción anterior a las 24:00 UTC |
Administración de incidentes de datos | Si no se cumple la promesa anterior de entrega de datos, el equipo de ventas puede notificar el problema y el equipo de datos se compromete a resolverlo con un TTR < 6 horas. |
Indicadores de nivel de servicio (SLI)
Los SLI siempre deben cumplir o superar los SLO descritos en el Acuerdo de Nivel de Servicio. Al establecer un SLI, empiece por identificar las métricas clave que puede supervisar y medir para lograr el Acuerdo de Nivel de Servicio acordado.
Ejemplo de SLI
Supongamos que el equipo de datos de Contoso identifica métricas clave de diferentes áreas para cumplir el Acuerdo de Nivel de Servicio descrito en el ejemplo anterior. También crean un panel de información, configuran alertas por si las métricas clave se desvían de una línea base establecida y automatizan acciones para mitigar algunos problemas.
Métrica | Propósito |
---|---|
Uso de la CPU y la memoria del clúster de Spark | Para medir cualquier cuello de botella de rendimiento en la infraestructura subyacente que se usa para ejecutar canalizaciones de datos |
Tiempo total de ejecución de la canalización en minutos | Para medir si una canalización tarda más tiempo de lo esperado en ejecutarse |
Tasas de errores y éxito de las canalizaciones | Para medir cuántas canalizaciones producen un error o se realizan correctamente |
Métricas de calidad de datos (bajada) | Para asegurarse de que los datos entregados por la canalización de datos cumplen las expectativas |
Métricas de calidad de datos (subida) | Para garantizar el cumplimiento de la calidad de subida de los datos sin procesar |
Transformación de actualizaciones de metadatos | Para garantizar que el linaje, desde la subida hasta la bajada, contenga metadatos sobre todas las transformaciones aplicadas a los datos |
Indexación y actualizaciones de datos de bajada | Para garantizar que el equipo de ventas detecta todos los conjuntos de datos que activan su panel de información |
Proceso definido para medir TTD y TTR | Para medir TTD y TTR y garantizar TTR < 6 horas |
Objetivos de nivel de servicio (SLO)
Un SLO consta de una SLI, la duración sobre la que se mide la SLI y la tasa de éxito objetivo que prácticamente se puede lograr. Definir la dirección y el objetivo de éxito puede ser una tarea abrumadora al principio. No espere la perfección, sino una mejora estable en varias iteraciones.
Los SLO pueden depender de:
- Producto de datos
- Categoría de datos
- Regiones de origen de datos
- Componentes de observabilidad de datos
Ejemplo de SLO
Supongamos que el equipo de datos de Contoso ofrece datos de ventas en siete regiones diferentes de Estados Unidos. Cada año se entregan 210 conjuntos de datos en todas las regiones, de los cuales solo 200 están completos y cumplen el Acuerdo de Nivel de Servicio. Estas entregas exitosas se traducen en una tasa de éxito del 95,99 % durante ese año. Los 10 conjuntos de datos erróneos (incompletos) tuvieron una tasa de errores aceptable del 4 %.
El equipo de datos crea un panel de información de supervisión que hace un seguimiento de los SLI agregados para supervisar este SLO durante un período de 30 días. Tanto el equipo de datos como el equipo de ventas reciben notificaciones cuando no se logra la tasa de éxito prevista.
Modelo de madurez de la observabilidad de los datos
La observabilidad de los datos es una parte esencial del marco de DataOps y debe tenerse en cuenta paralelamente a sus esfuerzos por mejorar los procesos de DataOps de la organización. El siguiente modelo de madurez puede ayudarle a evaluar el estado actual de la observabilidad de los datos y tomar decisiones sobre los pasos siguientes de su recorrido.
Fase | Supervisión del servicio de plataforma de datos | Supervisión del rendimiento de la canalización de datos | Supervisión de la calidad de los datos | Linaje de datos | Detección de datos |
---|---|---|---|---|---|
Fase 5 (muy avanzada) | Los datos se recopilan en todos los componentes de observabilidad de los datos de uno o varios productos de datos en una vista unificada y se correlacionan mediante el aprendizaje automático para encontrar anomalías. Los paneles hacen un seguimiento de SLO, SLI y SLA en todos los componentes de observabilidad de datos. | Las métricas de rendimiento de la canalización de datos se supervisan a través de múltiples productos de datos. El análisis de la causa raíz se completa y es impulsado por el sistema. | Se establece un alto nivel de confianza en la calidad de los datos. Los consumidores de datos pueden comprobar la confiabilidad de los datos. | El linaje de datos se representa visualmente y se usa de múltiples maneras, como la supervisión de las causas principales del error de canalización, el análisis de la calidad de los datos y el cumplimiento. | Los consumidores de datos pueden encontrar fácilmente los datos disponibles que necesitan. |
Fase 4 (avanzada) | Los paneles hacen un seguimiento de SLO, SLI y SLA en los componentes de observabilidad de datos más críticos. Los datos de supervisión de la plataforma y los datos de supervisión del rendimiento de la canalización se correlacionan mediante la automatización. | Las herramientas de incidentes de datos supervisan y miden las métricas TTD y TTR para comprobar cualquier incidente. | La calidad de los datos se mantiene a través de un marco que se puede usar en varios productos de datos y se supervisa mediante paneles de información. | El linaje de datos incluye etiquetas de calidad de los datos y está conectado a la detectabilidad de los datos. | El linaje de datos ahora está conectado a la detectabilidad de los datos e incluye también etiquetas de calidad de los datos. |
Fase 3 (en evolución) | Los SLO, SLI y SLA bien definidos abarcan casi todos los componentes más críticos para la observabilidad de los datos. Los incidentes de datos se administran con herramientas especializadas. | Los datos de supervisión de la plataforma se correlacionan con la supervisión del rendimiento de la canalización de datos mediante cierta cantidad de automatización. | Las comprobaciones de calidad de los datos están bien definidas y se asignan a métricas personalizadas. | El linaje de datos ha madurado para contener suficientes metadatos necesarios para la toma de decisiones. | La detectabilidad de los datos se logra mediante herramientas especializadas de catálogo de datos. |
Fase 2 (Planificación) | Un borrador inicial de SLO, SLI y SLA abarca los componentes más críticos necesarios para la observabilidad de los datos. Los datos de supervisión de la plataforma están centralizados y hay una vista unificada de todo el entorno de datos. La administración de los incidentes de datos es totalmente manual. | Las métricas de rendimiento de la canalización de datos se definen y miden. | Existen comprobaciones de calidad de datos, pero no se define, mide y visualiza ninguna métrica estándar. | El linaje de datos se limita al producto de datos único o no se supervisa. | Se logra la detectabilidad de datos, pero no se usan herramientas sofisticadas. |
Fase 1 Aprendizaje | Cada servicio de plataforma crítico (administrado por el proveedor y autoadministrado) se supervisa en la infraestructura de datos. | La supervisión de canalizaciones es mínima. Los errores desencadenan alertas, pero no tienen información sobre ninguna causa posible. | Las pruebas de calidad de datos se pueden ejecutar desde la canalización, pero no se mide ni se supervisa ninguna métrica. | El linaje de datos no existe. | La detectabilidad de datos no existe. |