Procedimientos recomendados para la confiabilidad

En este artículo se tratan los procedimientos recomendados para la confiabilidad organizados por principios de arquitectura enumerados en las secciones siguientes.

1. Diseñar considerando los errores

Usar un formato de datos que admita transacciones ACID

Las transacciones ACID son una característica fundamental para mantener la integridad y la coherencia de los datos. Elegir un formato de datos que admita transacciones ACID ayuda a crear canalizaciones más sencillas y mucho más confiables.

Delta Lake es un marco de almacenamiento de código abierto que proporciona transacciones ACID, así como la aplicación de esquemas, el control escalable de metadatos y unifica el procesamiento de flujos de datos y el procesamiento de datos por lotes. Delta Lake es totalmente compatible con las API de Apache Spark y está diseñado para una estrecha integración con el streaming estructurado, lo que le permite usar fácilmente una única copia de los datos tanto para las operaciones por lotes como para el streaming y proporcionar un procesamiento incremental a escala.

Uso de un motor de datos distribuido resistente para todas las cargas de trabajo

Apache Spark, como motor de proceso del almacén de lago de Azure Databricks, se basa en un procesamiento de datos distribuido y resistente. Si una tarea interna de Spark no devuelve un resultado como se esperaba, Apache Spark reprograma automáticamente las tareas que faltan y continúa ejecutando el trabajo completo. Esto es útil para fallos fuera de código, como un breve problema de red o una máquina virtual puntual revocada. Al trabajar tanto con la API de SQL como con la API de Spark DataFrame, esta resistencia está integrada en el motor.

En Databricks Lakehouse, Photon, un motor vectorizado nativo escrito completamente en C++, es un proceso de alto rendimiento compatible con las API de Apache Spark.

Rescate automático de datos no válidos o no compatibles

Los datos no válidos o no conformes pueden provocar el bloqueo de las cargas de trabajo que dependen de un formato de datos establecido. Para aumentar la resistencia de un extremo a otro de todo el proceso, se recomienda filtrar los datos no válidos y no compatibles en la ingesta. La compatibilidad con los datos rescatados le asegura que nunca perderá o echará en falta datos durante la ingesta o la ETL. La columna de datos rescatada contiene cualquier dato que no se haya analizado, ya sea porque faltaba en el esquema dado, porque había un desajuste de tipo o porque el cuerpo de la columna en el registro o archivo no coincidía con el del esquema.

• Databricks Auto Loader: Auto Loader es la herramienta perfecta para el streaming de la ingesta de archivos. Admite datos rescatados para JSON y CSV. Por ejemplo, para JSON, la columna de datos rescatados contiene los datos que no se han analizado porque posiblemente no estaban en el esquema indicado, porque había un error de coincidencia de tipos o porque el uso de mayúsculas y minúsculas de la columna no coincidía. La columna de datos rescatados forma parte del esquema devuelto por el cargador automático como _rescued_data de manera predeterminada mientras se infiere el esquema.
• Delta Live Tables: otra opción para crear flujos de trabajo para la resistencia es el uso de Delta Live Tables con restricciones de calidad. Consulte Administración de la calidad de los datos con Delta Live Tables. De forma predeterminada, Delta Live Tables admite tres modos: retener, quitar y generar errores en registros no válidos. Para poner en cuarentena registros no válidos identificados, se pueden definir reglas de expectativas de forma específica para que los registros no válidos se almacenen ("se pongan en cuarentena") en otra tabla. Consulte Poner en cuarentena datos no válidos.

Configuración de trabajos para reintentos y terminación automáticos

Los sistemas distribuidos son complejos, y un error en un punto puede potencialmente reproducirse en todo el sistema.

• Los trabajos de Azure Databricks admiten directivas de reintentos para tareas que determinan cuándo y cuántas veces se reintentan las ejecuciones con errores. Consulte Set a retry policy (Establecimiento de una directiva de reintentos).
• Puede configurar los umbrales de duración opcionales para una tarea, incluido un tiempo de finalización esperado para la tarea y un tiempo de finalización máximo para la tarea.
• Delta Live Tables también automatiza la recuperación de errores mediante el aumento de los reintentos para equilibrar la velocidad y la confiabilidad. Consulte Modos de desarrollo y producción.

Por otro lado, una tarea bloqueada puede impedir que se complete todo el trabajo, lo que da lugar a costos elevados. Los trabajos de Databricks admiten la configuración de un tiempo de espera para finalizar los trabajos que tardan más de lo esperado.

Uso de una infraestructura de servicio de modelos escalable y de nivel de producción

Para la inferencia por lotes y de streaming, use trabajos de Azure Databricks y MLflow para implementar modelos como UDF de Apache Spark a fin de aprovechar la programación de trabajos, los reintentos, la escalabilidad automática, etc. Consulte Implementación de modelos para la inferencia y predicción por lotes.

El servicio de modelos proporciona una infraestructura de servicio de modelos escalable y de nivel de producción para el servicio de modelos en tiempo real. Los modelos de Machine Learning se procesan mediante MLflow y se exponen como puntos de conexión de API REST. Esta funcionalidad usa el proceso sin servidor, lo que significa que los puntos de conexión y los recursos de proceso asociados se administran y se ejecutan en la cuenta de nube de Azure Databricks.

Uso de servicios administrados siempre que sea posible

Aproveche los servicios administrados (proceso sin servidor) de la plataforma de Data Intelligence de Databricks, como:

• Almacenes de SQL sin servidor
• Servicio de modelos
• trabajos sin servidor
• Proceso sin servidor para cuadernos
• Delta Live Tables

Estos servicios son operados por Databricks de forma confiable y escalable sin costo adicional para el cliente, lo que hace que las cargas de trabajo sean más confiables.

2. Administrar la calidad de los datos

Uso de una arquitectura de almacenamiento en capas

Mantenga los datos mediante la creación de una arquitectura en capas y la garantía de que la calidad de estos aumenta a medida que se mueven por ellas. Un enfoque de estructura en capas común es:

• Capa sin procesar (bronce): los datos de origen se ingieren en el lago en la primera capa y deben conservarse ahí. Cuando todos los datos posteriores se crean a partir de la capa sin procesar, es posible reconstruir las capas posteriores a partir de esta capa según sea necesario.
• Capa mantenida (plata): el propósito de la segunda capa es contener datos limpios, refinados, filtrados y agregados. El objetivo de esta capa es proporcionar una base sólida y fiable para el análisis y la elaboración de informes en todos los roles y las funcionalidades.
• Capa final (oro): la tercera capa se crea en torno a las necesidades empresariales o del proyecto. Proporciona una vista diferente en forma de productos de datos a otras unidades de negocio o proyectos, y prepara los datos en torno a las necesidades de seguridad (como datos anónimos) u optimiza el rendimiento (por ejemplo, con vistas agregadas previamente). Los productos de datos de esta capa se consideran la verdad para la empresa.

La capa final debe contener solo datos de alta calidad y ser de plena confianza desde el punto de vista empresarial.

Mejora de la integridad de los datos mediante la reducción de la redundancia de los datos

Copiar o duplicar datos crea redundancia de datos y lleva a la pérdida de la integridad y el linaje de los datos y, a menudo, a permisos de acceso diferentes. Esto reduce la calidad de los datos del almacén de lago.

Una copia temporal o desechable de los datos no es perjudicial en sí misma: a veces es necesaria para aumentar la agilidad, la experimentación y la innovación. Sin embargo, cuando estas copias se vuelven operativas y se usan regularmente para tomar decisiones empresariales, se convierten en silos de datos. Cuando estos silos de datos se desincronizan, tiene un impacto negativo significativo en la integridad y calidad de los datos, planteando preguntas como "¿Qué conjunto de datos es el maestro?" o "¿Está actualizado el conjunto de datos?

Administración activa de esquemas

Los cambios de esquema no controlados pueden conducir a datos no válidos y trabajos con errores que usan estos conjuntos de datos. Azure Databricks tiene varios métodos para validar y aplicar el esquema:

• Delta Lake admite la validación y la aplicación de esquemas mediante el control automático de variaciones de esquema para evitar la inserción de registros incorrectos durante la ingesta. Consulte Aplicación de esquemas.
• El cargador automático detecta la adición de nuevas columnas a medida que se procesan los datos. De forma predeterminada, la adición de una nueva columna hace que los flujos de datos se detengan con una excepción UnknownFieldException. El cargador automático admite varios modos de evolución del esquema.

Uso de restricciones y expectativas de datos

Las tablas de Delta admiten cláusulas SQL estándar de administración de restricciones que garantizan la comprobación automática de la calidad y la integridad de los datos que se agregan a una tabla. Cuando se infringe una restricción, Delta Lake produce un error InvariantViolationException para indicar que los nuevos datos no se pueden agregar. Consulte Restricciones en Azure Databricks.

Para mejorar aún más este control, Delta Live Tables admite expectativas: las expectativas definen las restricciones de calidad de los datos en el contenido de un conjunto de datos. Una expectativa consiste en una descripción, una invariable y una acción, que se debe realizar cuando se produce un error en la invariable en un registro. Las expectativas sobre consultas usan decoradores de Python o cláusulas de restricción SQL. Consulte Administración de la calidad de los datos con Delta Live Tables.

Adopción de un enfoque centrado en los datos para el aprendizaje automático

Un principio fundamental que se mantiene en el centro de la visión de la IA para la Plataforma de Data Intelligence de Databricks es un enfoque del aprendizaje automático centrado en los datos. A medida que la IA generativa se hace más frecuente, esta perspectiva sigue siendo igual de importante.

Los componentes centrales de cualquier proyecto de ML pueden considerarse simplemente canalizaciones de datos: las canalizaciones de ingeniería de características, entrenamiento, implementación de modelos, inferencia y supervisión son todas canalizaciones de datos. Por lo tanto, la operacionalización de una solución de ML requiere la combinación de datos de tablas de predicción, supervisión y características con otros datos pertinentes. Fundamentalmente, la manera más fácil de lograr esto es desarrollar soluciones con tecnología de inteligencia artificial en la misma plataforma que se usa para administrar los datos de producción. Consulte MLOps y LLMOps centrados en datos

3. Diseñar para la escalabilidad automática

Habilitación del escalado automático para cargas de trabajo de ETL

El escalado automático permite que los clústeres cambien de tamaño automáticamente en función de las cargas de trabajo. La escalabilidad automática puede ser beneficiosa en muchos casos de uso y escenarios tanto desde el punto de vista de los costos como del rendimiento. En la documentación se exponen algunas consideraciones para determinar si se debe usar el escalado automático y cómo obtener el máximo beneficio.

Para las cargas de trabajo de streaming, Databricks recomienda usar Delta Live Tables con la escalabilidad automática. La escalabilidad automática mejorada de Databricks optimiza el uso del clúster mediante la asignación automática de los recursos de clúster en función del volumen de la carga de trabajo, con un impacto mínimo en la latencia del procesamiento de datos de las canalizaciones.

Habilitación de la escalabilidad automática para el almacén de SQL

El parámetro de escalado de un almacén de SQL establece el número mínimo y máximo de clústeres entre los que se distribuyen las consultas enviadas al almacén. El valor predeterminado es un clúster sin escalado automático.

Para controlar más usuarios simultáneos en un almacén determinado, aumente el número de clústeres. Para saber cómo Azure Databricks agrega clústeres a un almacén y los elimina de él, vea Dimensionamiento, escalado y comportamiento en cola del almacén SQL.

4. Probar los procedimientos de recuperación

Recuperación ante errores de consulta de Structured Streaming

El flujo estructurado proporciona tolerancia a errores y coherencia de datos para las consultas de streaming. Con los trabajos de Databricks, puede configurar fácilmente las consultas de Structured Streaming para que se reinicien automáticamente en caso de error. Si habilitar el uso de puntos de control para una consulta de streaming, podrá reiniciar la consulta después de un error. La consulta reiniciada continuará desde donde se dejó la consulta con errores. Consulte Puntos de control de flujo estructurado y Consideraciones de producción para flujo estructurado.

Recuperación de trabajos de ETL usando las capacidades de viaje en el tiempo de los datos

A pesar de las pruebas exhaustivas, un trabajo puede fallar en producción o producir datos inesperados, incluso no válidos. A veces esto puede arreglarse con un trabajo adicional después de comprender el origen del problema y arreglar la canalización que lo causó en primer lugar. Sin embargo, a menudo esto no es sencillo y el trabajo en cuestión debería volver a implementarse. El uso del viaje en el tiempo de Delta permite a los usuarios revertir fácilmente los cambios en una versión anterior o marca de tiempo, reparar la canalización y reiniciar la canalización corregida.

Una manera práctica de hacerlo es el comando RESTORE.

Aprovechamiento de un marco de automatización de trabajos con recuperación integrada

Los trabajos de Databricks están diseñados para la recuperación. Cuando falla una tarea en un trabajo multitarea (y, por tanto, todas las tareas dependientes), los trabajos de Azure Databricks proporcionan una vista matricial de las ejecuciones que permite investigar el problema que causó el fallo, consulte Ver ejecuciones de un trabajo. Ya sea un problema de red breve o un problema real en los datos, puede corregirlo e iniciar una ejecución de reparación en los trabajos de Azure Databricks. Ejecutará solo las tareas fallidas y dependientes y conservará los resultados satisfactorios de la ejecución anterior, ahorrando tiempo y dinero, consulte Solución de problemas y reparación de trabajos fallidos

Configuración de un patrón de recuperación ante desastres

Para una plataforma de análisis de datos nativa de la nube como Azure Databricks, es fundamental contar con un patrón claro de recuperación ante desastres. Es fundamental que sus equipos de datos puedan usar la plataforma Azure Databricks incluso en el raro evento de que se produzca una interrupción regional y en todo el servicio de un proveedor de servicios en la nube, ya sea causada por un desastre regional como un huracán, un terremoto o cualquier otro origen.

Azure Databricks suele ser una parte fundamental de un ecosistema general de datos que incluye muchos servicios, como los servicios de ingesta de datos ascendentes (por lotes o streaming), almacenamiento nativo en la nube como Azure Data Lake Storage Gen2, herramientas ascendentes y servicios como las aplicaciones de inteligencia empresarial, así como instrumentos de orquestación. Algunos casos de uso pueden ser especialmente susceptibles a una interrupción en todo el servicio de la región.

La recuperación ante desastres implica un conjunto de directivas, herramientas y procedimientos que permiten la recuperación o continuación de sistemas e infraestructuras tecnológicos esenciales a consecuencia de desastres de origen humano. Un gran servicio en la nube como Azure sirve a muchos clientes y tiene protecciones integradas contra un único fallo. Por ejemplo, una región es un grupo de edificios conectados a diferentes fuentes de energía para asegurar que un solo apagón no colapse una región. Sin embargo, pueden producirse errores en la región de nube y la gravedad del error y su impacto en su empresa puede variar.

5. Automatizar las implementaciones y las cargas de trabajo

Consulte Excelencia operativa: automatización de implementaciones y cargas de trabajo.

6. Supervisar sistemas y cargas de trabajo

Consulte Excelencia operativa: configurar la supervisión, las alertas y el registro.