👴🏻 🧠 🧔🏽 Delta: sincronización de datos y plataforma de enriquecimiento ❇️ 👆🏿 ⏰

En previsión del lanzamiento de una nueva transmisión en el curso de Ingeniero de datos, preparamos una traducción de material interesante.

Visión general

Hablaremos sobre un patrón bastante popular por el cual las aplicaciones usan varios almacenes de datos, donde cada tienda se usa para sus propios fines, por ejemplo, para almacenar la forma canónica de datos (MySQL, etc.), proporcionar capacidades de búsqueda avanzada (ElasticSearch, etc. .), almacenamiento en caché (Memcached, etc.) y otros. Por lo general, cuando se usan múltiples almacenamientos de datos, uno de ellos funciona como el almacenamiento principal y el otro como almacenamiento derivado. El único problema es cómo sincronizar estos almacenes de datos.

Observamos una serie de patrones diferentes que intentaron resolver el problema de la sincronización de múltiples repositorios, como la entrada doble, las transacciones distribuidas, etc. Sin embargo, estos enfoques tienen limitaciones significativas en términos de uso, confiabilidad y mantenimiento en la vida real. Además de la sincronización de datos, algunas aplicaciones también necesitan enriquecer los datos invocando servicios externos.

Para resolver estos problemas, se desarrolló Delta. Delta es, en última instancia, una plataforma coherente basada en eventos para sincronizar y enriquecer datos.

Soluciones existentes

Doble entrada

Para sincronizar dos almacenes de datos, puede usar la grabación doble, que escribe en una tienda y luego escribe inmediatamente en otra. El primer registro puede repetirse y el segundo puede interrumpirse si el primero falla después de agotar el número de intentos. Sin embargo, dos almacenes de datos pueden detener la sincronización si falla la escritura en el segundo almacén. Este problema generalmente se resuelve creando un procedimiento de recuperación que puede volver a transferir periódicamente datos del primer almacenamiento al segundo o hacer esto solo si se encuentran diferencias en los datos.

Problemas:

Realizar un procedimiento de recuperación es un trabajo específico que no se puede reutilizar. Además, los datos entre almacenamientos permanecen fuera de sincronización hasta que se complete el procedimiento de recuperación. La solución es complicada si se utilizan más de dos almacenes de datos. Finalmente, el procedimiento de recuperación puede agregar estrés a la fuente de datos original.

Cambiar tabla de registro

Cuando se producen cambios en un conjunto de tablas (por ejemplo, insertar, actualizar y eliminar registros), los registros de cambios se agregan a la tabla de registro como parte de la misma transacción. Otro subproceso o proceso solicita constantemente eventos de la tabla de registro y los escribe en uno o más almacenes de datos, cuando es necesario eliminar eventos de la tabla de registro después de confirmar el registro de todos los almacenes.

Problemas:

este patrón debe implementarse como una biblioteca e, idealmente, sin cambiar el código de la aplicación que lo utiliza. En un entorno políglota, la implementación de dicha biblioteca debe existir en cualquier idioma necesario, pero es muy difícil garantizar la coordinación de las funciones y el comportamiento entre los idiomas.

Otro problema radica en obtener cambios de esquema en sistemas que no admiten cambios de esquema transaccional [1] [2], como MySQL. Por lo tanto, una plantilla para realizar un cambio (por ejemplo, cambiar un esquema) y escribirla en la tabla de registro de cambios no siempre funcionará.

Transacciones distribuidas

Las transacciones distribuidas se pueden usar para dividir una transacción entre varios almacenamientos de datos heterogéneos para que la operación se confirme en todos los almacenes utilizados o no en ninguno de ellos.

Problemas:

Las transacciones distribuidas son un gran problema para los depósitos de datos heterogéneos. Por su naturaleza, solo pueden confiar en el mínimo común denominador de los sistemas involucrados. Por ejemplo, las transacciones XA bloquean la ejecución si ocurre una falla durante el proceso de preparación. Además, XA no proporciona detección de punto muerto y no admite esquemas optimistas de gestión de concurrencia. Además, algunos sistemas como ElasticSearch no admiten XA ni ningún otro modelo de transacción heterogéneo. Por lo tanto, garantizar la atomicidad de la grabación en diversas tecnologías de almacenamiento de datos sigue siendo una tarea muy difícil para las aplicaciones [3].

Delta

Delta fue diseñado para abordar las limitaciones de las soluciones de sincronización de datos existentes, y también enriquece los datos sobre la marcha. Nuestro objetivo era abstraer todos estos puntos complejos de los desarrolladores de aplicaciones para que pudieran concentrarse completamente en la implementación de la funcionalidad empresarial. A continuación, describiremos "Búsqueda de películas", el caso de uso real para Delta de Netflix.

Netflix hace un uso extensivo de la arquitectura de microservicios y cada microservicio generalmente sirve un tipo de datos. La información principal sobre la película se extrae en un microservicio llamado Servicio de películas, y los datos relacionados, como la información sobre productores, actores, vendedores, etc., son administrados por varios otros microservicios (a saber, Servicio de reparto, Servicio de talentos y Servicio de proveedor).
Los usuarios de negocios en Netflix Studios a menudo necesitan buscar varios criterios para películas, por eso es muy importante que puedan buscar todos los datos relacionados con películas.

Antes de Delta, el equipo de búsqueda de películas necesitaba recuperar datos de varios microservicios antes de indexar los datos de la película. Además, el equipo tuvo que desarrollar un sistema que actualizara periódicamente el índice de búsqueda, solicitando cambios de otros microservicios, incluso si no hubiera ningún cambio. Este sistema rápidamente se volvió demasiado complejo y difícil de mantener.

Figura 1. Sistema de votación antes de Delta
Después de usar Delta, el sistema se simplificó a un sistema controlado por eventos, como se muestra en la siguiente figura. Los eventos CDC (Change-Data-Capture) se envían a los temas de Keystone Kafka utilizando Delta-Connector. Una aplicación Delta creada con el Marco de procesamiento de Delta Stream (basado en Flink) recibe eventos CDC del tema, los enriquece, invoca otros microservicios y finalmente pasa los datos enriquecidos al índice de búsqueda en Elasticsearch. Todo el proceso tiene lugar en tiempo casi real, es decir, tan pronto como se registran los cambios en el almacén de datos, se actualizan los índices de búsqueda.

Figura 2. Canalización de datos con Delta
En las siguientes secciones, describimos el trabajo del Delta-Connector, que se conecta al repositorio y publica eventos CDC a nivel de transporte, que es una infraestructura de transmisión de datos en tiempo real que dirige los eventos CDC a los temas de Kafka. Y al final, hablaremos sobre el marco de procesamiento de flujo Delta que los desarrolladores de aplicaciones pueden usar para la lógica de procesamiento y enriquecimiento.

CDC (Cambio-Captura de datos)

Hemos desarrollado un servicio CDC llamado Delta-Connector, que puede capturar los cambios comprometidos desde el almacén de datos en tiempo real y escribirlos en la transmisión. Los cambios en tiempo real se toman del registro de transacciones y los volcados de almacenamiento. Los volcados se utilizan porque los registros de transacciones generalmente no almacenan todo el historial de cambios. Los cambios generalmente se serializan como eventos Delta, por lo que el destinatario no tiene que preocuparse de dónde proviene el cambio.

Delta-Connector admite varias características adicionales, como:

Capacidad para escribir resultados personalizados más allá de Kafka.
La capacidad de activar volcados manuales en cualquier momento para todas las tablas, una tabla específica o para ciertas claves primarias.
Los volcados pueden ser recogidos por trozos, por lo que no hay necesidad de comenzar de nuevo en caso de falla.
No es necesario poner bloqueos en las tablas, lo cual es muy importante para que nuestro tráfico nunca bloquee el tráfico de escritura en la base de datos.
Alta disponibilidad debido a las copias de seguridad en las zonas de disponibilidad de AWS.

Actualmente admitimos MySQL y Postgres, incluidas las implementaciones en AWS RDS y Aurora. También apoyamos a Cassandra (multi-master). Puede obtener más información sobre Delta-Connector en este blog .

Kafka y nivel de transporte

La capa Delta Event Transport se basa en el servicio de mensajería de la plataforma Keystone .

Históricamente, la publicación en Netflix se ha optimizado para aumentar la disponibilidad en lugar de la longevidad (ver artículo anterior ). Un compromiso fue la posible inconsistencia de los datos del corredor en varios escenarios fronterizos. Por ejemplo, la elección del líder impuro es responsable de garantizar que el destinatario potencialmente duplique o pierda eventos.

Con Delta, queríamos obtener mayores garantías de durabilidad para garantizar la entrega de eventos de CDC a almacenes derivados. Para hacer esto, propusimos un clúster Kafka especialmente diseñado como un objeto de la primera clase. Puede ver algunas configuraciones de corredores en la tabla a continuación:

En los grupos de Keystone Kafka, la elección de líder impuro generalmente está habilitada para garantizar la disponibilidad del editor. Esto puede provocar la pérdida de mensajes si se selecciona una réplica no sincronizada como líder. Para el nuevo grupo Kafka altamente confiable, la opción de elección de líder impuro está deshabilitada para evitar la pérdida de mensajes.

También aumentamos el factor de replicación de 2 a 3 y las réplicas mínimas de sincronizacióndel 1 al 2. Los editores que escriben en este clúster requieren reconocimientos de todos los demás, lo que garantiza que 2 de cada 3 réplicas tengan los mensajes más actualizados enviados por el editor.

Cuando se cierra la instancia del agente, la nueva instancia reemplaza a la anterior. Sin embargo, el nuevo agente deberá ponerse al día con las réplicas no sincronizadas, lo que puede llevar varias horas. Para reducir el tiempo de recuperación para este escenario, comenzamos a usar Amazon Elastic Block Store en lugar de discos de intermediarios locales. Cuando una nueva instancia reemplaza una instancia de intermediario completada, adjunta el volumen EBS que tenía la instancia completa y comienza a ponerse al día con los nuevos mensajes. Este proceso reduce el tiempo para eliminar el retraso de varias horas a varios minutos, ya que la nueva instancia ya no necesita ser replicada desde un estado vacío. En general, el almacenamiento por separado y los ciclos de vida del agente reducen significativamente el efecto del cambio del agente.

Para aumentar aún más la garantía de entrega de datos, utilizamos un sistema de seguimiento de mensajes para detectar cualquier pérdida de mensajes en condiciones extremas (por ejemplo, sincronización de reloj en el líder de la sección).

Marco de procesamiento de flujo

El nivel de procesamiento en Delta se basa en la plataforma Netflix SPaaS, que permite la integración de Apache Flink con el ecosistema de Netflix. La plataforma proporciona una interfaz de usuario que controla la implementación de trabajos de Flink y la orquestación de clústeres de Flink sobre nuestra plataforma de gestión de contenedores Titus. La interfaz también gestiona las configuraciones de trabajo y permite a los usuarios realizar cambios de configuración dinámicamente sin tener que volver a compilar los trabajos de Flink.

Delta proporciona un marco de procesamiento de flujo para datos basados en Flink y SPaaS, que utiliza anotacionesDSL (lenguaje específico de dominio) para abstraer detalles técnicos. Por ejemplo, para determinar el paso por el cual los eventos se enriquecerán llamando a servicios externos, los usuarios deben escribir el próximo DSL, y el marco creará un modelo basado en él que Flink ejecutará.

Figura 3. Ejemplo de enriquecimiento de DSL en Delta

El marco de procesamiento no solo acorta la curva de aprendizaje, sino que también proporciona funciones generales de procesamiento de flujo, como deduplicación, esquematización, así como flexibilidad y tolerancia a fallas para resolver problemas comunes en el trabajo.

Delta Stream Processing Framework consta de dos módulos clave, el módulo DSL y API y el módulo Runtime. El módulo DSL y API proporciona las API DSL y UDF (función definida por el usuario) para que los usuarios puedan escribir su propia lógica de procesamiento (como el filtrado o las transformaciones). El módulo Runtime proporciona una implementación del analizador DSL, que crea una representación interna de los pasos de procesamiento en los modelos DAG. El componente Ejecución interpreta los modelos DAG para inicializar las declaraciones reales de Flink y finalmente lanzar la aplicación Flink. La arquitectura del marco se ilustra en la siguiente figura.

Figura 4. Arquitectura de Delta Stream Processing Framework

Este enfoque tiene varias ventajas:

- Flink SPaaS.
, - (UDF).
Delta , , .

Delta ha estado en producción durante más de un año y desempeña un papel clave en muchas aplicaciones de Netflix Studio. Ayudó a los equipos a implementar casos de uso como indexación de búsqueda, almacenamiento de datos y flujos de trabajo basados en eventos. La siguiente es una descripción general de la arquitectura de alto nivel de la plataforma Delta.

Figura 5. La arquitectura de alto nivel de Delta.

Expresiones de gratitud

Queremos agradecer a las siguientes personas que contribuyeron a la creación y desarrollo de Delta en Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta , Steven Wu, Tharanga Gamaethige, Yun Wang y Zhenzhong Xu.

Fuentes

dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

: «Data Build Tool Amazon Redshift».

Delta: sincronización de datos y plataforma de enriquecimiento