La recuperación ante desastres es un requisito estándar para muchos sistemas de producción, especialmente en las industrias reguladas. Como muchas empresas dependen de los datos para tomar decisiones, también se requiere implementar la recuperación ante desastres para las canalizaciones de procesamiento de datos.
En specific, los clientes de las industrias reguladas a menudo deben proteger sus aplicaciones de la nube y las interrupciones del servicio mediante la implementación en arquitecturas de múltiples regiones o nubes. Los patrones multirregionales o multinube requieren la coordinación de la conmutación por error y la conmutación por recuperación, lo que a menudo puede conducir a un conjunto complejo de pasos y datos que se procesan varias veces.
Muchos clientes de Databricks tienen recuperación ante desastres implementada para las cargas de trabajo que se ejecutan en Databricks Lakehouse Platform, aunque la complejidad de la implementación depende en gran medida de los proveedores de nube, las tecnologías y las herramientas específicas que se utilicen. Puede encontrar más información sobre el enfoque basic para la recuperación ante desastres para Databricks en documentación y en una serie de entrada en el weblog.
El objetivo de este weblog es mostrar cómo Delta Reside Tables (DLT) simplifica y agiliza aún más la recuperación ante desastres en Databricks, gracias a sus capacidades en torno a los reintentos automáticos en caso de fallas y la ingestión de datos que garantiza un procesamiento único. Hacemos esto explicando nuestro diseño DR probado, incluido el código Terraform para orquestar la implementación. La implementación last que mejor funcione dependerá de las fuentes de datos, los patrones de flujo de datos y las necesidades de RTO/RPO. Señalamos a lo largo del weblog dónde se puede generalizar esta implementación para adaptarla a las necesidades del cliente.
¿Por qué es importante la recuperación ante desastres para Delta Reside Tables?
DLT es el primer marco ETL que utiliza un enfoque declarativo easy para construir canalizaciones de datos confiables. DLT administra automáticamente su infraestructura a escala para que los analistas de datos y los ingenieros puedan dedicar menos tiempo a las herramientas y concentrarse en obtener valor de los datos.
Como tal, DLT brinda los siguientes beneficios a los desarrolladores que lo usan:
- Acelere el desarrollo de ETL: Declare SQL/Python y DLT organiza automáticamente el DAG, maneja los reintentos y cambia los datos.
- Administre automáticamente sus datos e infraestructura: Automatiza actividades complejas y tediosas como la recuperación, el escalado automático, la optimización del rendimiento y el mantenimiento de datos.
- Garantice una alta calidad de los datos: Proporcione datos confiables con controles de calidad, pruebas, monitoreo y cumplimiento incorporados
- Unifique lote y transmisión: Obtenga la simplicidad de SQL con la frescura de la transmisión con una API unificada
Nuestro diseño proporciona un enfoque simplificado para implementar políticas de DR en la mayoría de las canalizaciones de DLT, lo que acelera aún más el desarrollo de ETL y permite a los clientes cumplir con los requisitos de sus políticas de DR.
Resumen del diseño
Cuando los datos se ingieren usando DLT, se procesa exactamente una vez. Esto es útil para la recuperación ante desastres porque las canalizaciones DLT idénticas producirán resultados de tabla idénticos si se alimentan con el mismo flujo de datos (suponiendo que la canalización de datos no dependa del entorno, por ejemplo, los lotes de datos dependen de la hora de llegada de los datos). Por lo tanto, una tubería en una región de nube separada puede producir los mismos resultados en la mayoría de los casos, si la tubería tiene:
- La misma definición en las regiones primaria y secundaria
- Ambas canalizaciones reciben los mismos datos.
Para nuestra solución, configuramos una canalización de DLT principal y una secundaria en dos espacios de trabajo de Databricks en distintas regiones. Cada canalización tiene una zona de aterrizaje independiente, una fuente de registros solo para agregar que se puede leer mediante la función de cargador automático. Usamos esta capa de la zona de aterrizaje para construir una capa de bronce. Las transformaciones posteriores en la canalización y las tablas se consideran transformaciones de “capa plateada”, que terminan con una “capa dorada” last correspondiente a nuestra arquitectura medallón.
Cuando llega un nuevo archivo, debe copiarse en ambas zonas de aterrizaje en las regiones primaria y secundaria. Cómo hacerlo depende de la fuente disponible. En nuestra implementación, el sistema de origen de los datos sin procesar period Amazon DMS, por lo que se configuró una tarea de replicación de DMS para escribir datos en ambas zonas de aterrizaje. Se pueden realizar configuraciones similares con Azure Knowledge Manufacturing facility o incluso con un trabajo programado que copie directamente de un depósito a otro.
Consideraciones de diseño
Nuestro diseño se centra principalmente en interrupciones regionales para Databricks y AWS S3, aunque este mismo patrón se puede generalizar a otras nubes o incluso a un diseño de varias nubes. Una interrupción complete del proveedor de la nube (o una interrupción del sistema de origen, como un clúster de Kafka o AWS DMS) requeriría otras consideraciones que serían específicas del proveedor de la nube y el sistema de origen.
Vale la pena señalar que este enfoque no copia ninguna tabla Delta entre regiones. Más bien, utiliza conjuntos de datos de zona de aterrizaje idénticos escritos en las regiones primaria y secundaria. La ventaja de no copiar tablas entre regiones es que:
- la solución es más easy y no implica ninguna copia handbook o secuencias de comandos que un cliente deba implementar
- las copias de tablas significan que los puntos de management de transmisión se pierden debido a la infraestructura de la nube subyacente, por lo que este enfoque de DR significa que la transmisión todavía es suitable.
Finalmente, en nuestra implementación, la canalización principal se ejecutó continuamente y la secundaria se activó a intervalos regulares pero no de forma continua. El intervalo de activación acordado se estableció para cumplir con los requisitos de RTO/RPO del cliente. Los clientes favorecen el costo sobre los tiempos de procesamiento en la región secundaria, la canalización secundaria solo se puede iniciar esporádicamente, ya que Auto Loader cargará todos los archivos que se han acumulado en la zona de aterrizaje y aún no se han procesado.
Ilustración de conmutación por error y conmutación por recuperación
Ilustramos un conjunto de pasos necesarios para la conmutación por error y la conmutación por recuperación:
- Durante las operaciones regulares, los datos se escriben en las zonas de aterrizaje primaria y secundaria. La región principal se utiliza para las operaciones regulares de canalización y para entregar los datos procesados a los consumidores.
- Conmutación por error: Después de una interrupción en la región principal, la región secundaria debe estar activa. DLT comienza a procesar cualquier dato en la zona de aterrizaje que aún no se haya consumido. Los puntos de management del cargador automático le indican a la canalización qué archivos aún no se han procesado. Terraform se puede utilizar para poner en marcha la canalización de la región secundaria y para redirigir a los consumidores a la región secundaria.
- Conmutación por recuperación: Cuando se resuelve la interrupción en la región principal, la canalización de DLT en la región principal se reinicia y reanuda automáticamente el consumo. Los puntos de management del cargador automático informan a la canalización qué archivos aún no se han procesado, y DLT se reiniciará y volverá a intentarlo automáticamente de acuerdo con su programación. La canalización se puede reiniciar con Terraform, procesar los datos y dirigir a los consumidores a la región principal.
Recomendamos usar una marca de tiempo que sea común a las zonas de aterrizaje principal y secundaria para detectar cuándo se ha puesto al día el procesamiento después de la conmutación por error/recuperación. Esta marca de tiempo fue proporcionada por los registros de la base de datos de origen en nuestra implementación.
Por ejemplo, el último mensaje tiene una marca de tiempo event_ de 2023-02-28T13:00:00Z. Incluso si el evento llega a la región principal 5 minutos más tarde que a la región secundaria, el mensaje copiado en ambas zonas de aterrizaje tendrá la misma marca de tiempo. La consulta de ejemplo a continuación devolverá la marca de tiempo del último evento procesado en una región.
Choose max(event_timestamp) from gold_table…Esto le permite responder preguntas como “¿Mi región secundaria procesó todos los eventos antes del inicio de la interrupción?”.
Consistencia de canalización y técnicas de conmutación por error con Terraform
Para evitar cualquier trabajo handbook y hacer cumplir el seguimiento de los cambios en las canalizaciones, todo se implementa utilizando la solución Terraform como infraestructura como código. El código está organizado de la siguiente manera:
- DLT Pipeline se outline como un módulo Terraform separado. El módulo recibe todos los parámetros necesarios (rutas del cuaderno, ubicación de almacenamiento, …), además de la
active_regionMarca que especifica si la región está activa (por lo que la canalización se ejecuta continuamente) o no (la ejecución de la canalización DLT la desencadena el trabajo de Databricks). - Cada región tiene su propia configuración que utiliza el módulo Terraform, pasando todos los parámetros necesarios, incluido el indicador que especifica si esta región está activa o no.
El código de Terraform está organizado en el repositorio de la siguiente manera:
En caso de conmutación por error, la configuración de la región secundaria se actualiza estableciendo el active_region marca a verdadero, y aplicando los cambios. Esto deshabilitará el trabajo de Databricks que desencadena la canalización de DLT y la canalización se ejecutará de forma continua.
Cuando ocurre la conmutación por recuperación, la configuración de la región secundaria se actualiza nuevamente configurando el active_region marcar a falso y aplicar los cambios. Después de eso, la canalización vuelve al modo desencadenado impulsado por el trabajo de Databricks.
El código para el módulo Terraform que outline la canalización DLT se encuentra a continuación. Outline los recursos para los cuadernos de Databricks, el trabajo y la propia canalización:
useful resource "databricks_notebook" "dlt_pipeline" {
for_each = toset(var.notebooks)
supply = "${path.module}/notebooks/${every.worth}"
path = "${var.notebooks_directory}/${every.worth}"
}
useful resource "databricks_job" "dlt_pipeline" {
title = "Job for ${var.pipeline_name}"
activity {
task_key = "DLT"
pipeline_task {
pipeline_id = databricks_pipeline.dlt_pipeline.id
}
}
schedule {
quartz_cron_expression = "0 0 1 * * ?"
timezone_id = "America/New_York"
pause_status = var.active_region ? "PAUSED" : "UNPAUSED"
}
}
useful resource "databricks_pipeline" "dlt_pipeline" {
channel = "CURRENT"
steady = var.active_region
version = var.pipeline_edition
title = var.pipeline_name
storage = var.pipeline_storage
goal = var.pipeline_target
dynamic "library" {
for_each = toset(var.notebooks)
content material {
pocket book {
path = databricks_notebook.dlt_pipeline(library.worth).id
}
}
}
# ... extra customization - clusters, tags, ...
}
Y luego cada región llama al módulo dado related a lo siguiente:
module "dlt_pipeline" {
supply = "../module"
active_region = true # or false for secondary area
pipeline_name = "pipeline"
pipeline_storage = "s3://<area>/dlt/"
notebooks = ("notebook1.py", "notebook2.py")
notebooks_directory = "/Pipelines/Pipeline1"
}
Conclusión
Delta Reside Tables es un marco resistente para el procesamiento de ETL. En este weblog, discutimos una implementación de recuperación ante desastres para Delta Reside Tables que hace uso de funciones como reintentos automáticos, mantenimiento y optimización simples, y compatibilidad con Auto Loader para leer un conjunto de archivos que se han entregado a regiones primarias y secundarias. . De acuerdo con las necesidades de RTO y RPO de un cliente, las canalizaciones se construyen en dos entornos y los datos se pueden procesar de manera rutinaria en la región secundaria. Con el código de Terraform que explicamos, se pueden hacer que las canalizaciones se inicien para la conmutación por error y la conmutación por recuperación, y se puede redirigir a los consumidores. Con el apoyo de nuestra solución Catastrophe Restoration, pretendemos aumentar la disponibilidad de la plataforma para las cargas de trabajo de los usuarios.
Asegúrese de que sus canalizaciones de DLT no se vean afectadas por interrupciones del servicio y le proporcione acceso a los datos más recientes. ¡Revise e implemente una estrategia de recuperación ante desastres para canalizaciones de procesamiento de datos!
