En previsión del lanzamiento de un nuevo flujo a razón Hemos preparado una traducción de material interesante.
Descripción
Hablaremos de un patrón bastante popular según el cual las aplicaciones utilizan múltiples almacenes de datos, donde cada almacén se usa para sus propios fines, por ejemplo, para almacenar la forma canónica de datos (MySQL, etc.), proporciona capacidades de búsqueda avanzada (ElasticSearch, etc.) .), almacenamiento en caché (Memcached, etc.) y otros. Normalmente, cuando se utilizan varios almacenes de datos, uno de ellos actúa como almacén principal y los demás como almacenes derivados. El único problema es cómo sincronizar estos almacenes de datos.
Analizamos varios patrones diferentes que intentaron resolver el problema de sincronizar múltiples tiendas, como escrituras dobles, 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 llamando a servicios externos.
Delta fue desarrollado para resolver estos problemas. En última instancia, Delta proporciona una plataforma consistente basada en eventos para la sincronización y el enriquecimiento de datos.
Soluciones existentes
doble entrada
Para mantener sincronizados dos almacenes de datos, puede utilizar la escritura dual, que escribe en un almacén y luego escribe en el otro inmediatamente después. Se puede volver a intentar la primera grabación y se puede abortar la segunda si la primera falla una vez agotado el número de intentos. Sin embargo, los dos almacenes de datos pueden no estar sincronizados si falla la escritura en el segundo almacén. Este problema generalmente se resuelve creando un procedimiento de recuperación que pueda volver a transferir datos periódicamente del primer almacenamiento al segundo, o hacerlo solo si se detectan 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 ubicaciones de almacenamiento no están sincronizados hasta que se lleva a cabo el procedimiento de restauración. La solución se vuelve más compleja si se utilizan más de dos almacenes de datos. Finalmente, el procedimiento de restauración puede agregar carga a la fuente de datos original.
Cambiar tabla de registro
Cuando se producen cambios en un conjunto de tablas (como insertar, actualizar y eliminar un registro), los registros de cambios se agregan a la tabla de registro como parte de la misma transacción. Otro hilo o proceso solicita constantemente eventos de la tabla de registro y los escribe en uno o más almacenes de datos, si es necesario, eliminando eventos de la tabla de registro después de que todos los almacenes hayan confirmado el registro.
Problemas
Este patrón debería implementarse como una biblioteca, e idealmente sin cambiar el código de la aplicación que lo utiliza. En un entorno políglota, debería existir una implementación de dicha biblioteca en cualquier idioma necesario, pero es muy difícil garantizar la coherencia de la funcionalidad y el comportamiento en todos los idiomas.
Otro problema radica en la obtención de cambios de esquema en sistemas que no admiten cambios de esquema transaccionales [1][2], como MySQL. Por lo tanto, el patrón de realizar un cambio (por ejemplo, un cambio de esquema) y registrarlo transaccionalmente en la tabla de registro de cambios no siempre funcionará.
Transacciones distribuidas
Las transacciones distribuidas se pueden utilizar para dividir una transacción en varios almacenes de datos heterogéneos, de modo que la operación se confirme en todos los almacenes de datos utilizados o no se confirme en ninguno de ellos.
Problemas
Las transacciones distribuidas son un problema muy grande para los almacenes de datos heterogéneos. Por su naturaleza, sólo pueden confiar en el mínimo común denominador de los sistemas involucrados. Por ejemplo, las transacciones XA bloquean la ejecución si el proceso de solicitud falla durante la fase de preparación. Además, XA no proporciona detección de interbloqueos ni admite esquemas de control de concurrencia optimistas. 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 escritura en diversas tecnologías de almacenamiento de datos sigue siendo una tarea muy desafiante 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 permite el enriquecimiento de datos sobre la marcha. Nuestro objetivo era abstraer todas estas complejidades de los desarrolladores de aplicaciones para que pudieran centrarse por completo en implementar la funcionalidad empresarial. A continuación describiremos la "Búsqueda de películas", el caso de uso real de Delta de Netflix.
Netflix utiliza ampliamente una arquitectura de microservicios y cada microservicio normalmente proporciona un tipo de datos. La información básica sobre la película está contenida en un microservicio llamado Movie Service, y los datos asociados, como información sobre productores, actores, proveedores, etc., son administrados por varios otros microservicios (a saber, Deal Service, Talent Service y Vendor Service).
Los usuarios comerciales de Netflix Studios a menudo necesitan buscar según varios criterios de películas, por lo que es muy importante para ellos poder buscar entre todos los datos relacionados con las películas.
Antes de Delta, el equipo de búsqueda de películas necesitaba extraer datos de múltiples 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 a otros microservicios, incluso si no hubiera ningún cambio. Este sistema rápidamente se volvió complejo y difícil de mantener.
Figura 1. Sistema de votación para 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 temas de Keystone Kafka mediante Delta-Connector. Una aplicación Delta creada con Delta Stream Processing Framework (basado en Flink) recibe eventos CDC de un tema, los enriquece llamando a otros microservicios y finalmente pasa los datos enriquecidos a un índice de búsqueda en Elasticsearch. Todo el proceso se lleva a cabo casi en tiempo real, es decir, tan pronto como se envían los cambios al almacén de datos, los índices de búsqueda se actualizan.
Figura 2. Canalización de datos utilizando Delta
En las siguientes secciones, describiremos el funcionamiento del Delta-Connector, que se conecta al almacenamiento y publica eventos CDC en la capa de transporte, que es una infraestructura de transmisión de datos en tiempo real que enruta eventos CDC a temas de Kafka. Y al final, hablaremos sobre el marco de procesamiento de flujo Delta, que los desarrolladores de aplicaciones pueden utilizar para el procesamiento de datos y la lógica de enriquecimiento.
CDC (Cambio-Datos-Captura)
Hemos desarrollado un servicio CDC llamado Delta-Connector, que puede capturar cambios confirmados del almacén de datos en tiempo real y escribirlos en una secuencia. Los cambios en tiempo real se toman del registro de transacciones y de los volcados de almacenamiento. Los volcados se utilizan porque los registros de transacciones normalmente no almacenan el historial completo de cambios. Los cambios normalmente se serializan como eventos Delta, por lo que el destinatario no tiene que preocuparse por el origen del cambio.
Delta-Connector admite varias funciones adicionales, como:
- Capacidad para escribir datos de salida personalizados más allá de Kafka.
- Capacidad de activar volcados manuales en cualquier momento para todas las tablas, una tabla específica o claves primarias específicas.
- Los volcados se pueden recuperar en partes, por lo que no es necesario comenzar de nuevo en caso de falla.
- No es necesario colocar bloqueos en las tablas, lo cual es muy importante para garantizar que nuestro servicio nunca bloquee el tráfico de escritura de la base de datos.
- Alta disponibilidad debido a instancias redundantes en zonas de disponibilidad de AWS.
Actualmente admitimos MySQL y Postgres, incluidas implementaciones en AWS RDS y Aurora. También admitimos Cassandra (multi-master). Puede encontrar más detalles sobre Delta-Connector aquí .
Kafka y la capa de transporte
La capa de transporte de eventos de Delta se basa en el servicio de mensajería de la plataforma .
Históricamente, las publicaciones en Netflix se han optimizado para la accesibilidad en lugar de la longevidad (ver más abajo). ). La contrapartida fue una posible inconsistencia de los datos de los corredores en varios escenarios extremos. Por ejemplo, elección de líder inmundo es responsable de que el destinatario tenga potencialmente eventos duplicados o perdidos.
Con Delta, queríamos garantías de durabilidad más sólidas para garantizar la entrega de eventos CDC a las tiendas derivadas. Para ello, propusimos un clúster Kafka especialmente diseñado como objeto de primera clase. Puede consultar algunas configuraciones del corredor en la siguiente tabla:
En los grupos de Keystone Kafka, elección de líder inmundo normalmente se incluye para garantizar la accesibilidad del editor. Esto puede provocar la pérdida de mensajes si se elige como líder una réplica no sincronizada. Para un nuevo clúster Kafka de alta disponibilidad, la opción elección de líder inmundo desactivado para evitar la pérdida de mensajes.
También aumentamos factor de replicación de 2 a 3 y réplicas insync mínimas 1 a 2. Los editores que escriben en este clúster requieren confirmaciones de todos los demás, lo que garantiza que 2 de cada 3 réplicas tengan los mensajes más recientes enviados por el editor.
Cuando finaliza una instancia de intermediario, una nueva instancia reemplaza a la anterior. Sin embargo, el nuevo intermediario deberá ponerse al día con las réplicas no sincronizadas, lo que puede tardar varias horas. Para reducir el tiempo de recuperación para este escenario, comenzamos a utilizar almacenamiento de datos en bloques (Amazon Elastic Block Store) en lugar de discos de intermediarios locales. Cuando una nueva instancia reemplaza una instancia de broker terminada, adjunta el volumen de EBS que tenía la instancia terminada y comienza a ponerse al día con los nuevos mensajes. Este proceso reduce el tiempo de eliminación de trabajos pendientes de horas a minutos porque la nueva instancia ya no necesita replicarse desde un estado vacío. En general, los ciclos de vida de intermediario y almacenamiento separados reducen significativamente el impacto del cambio de intermediario.
Para aumentar aún más la garantía de entrega de datos, utilizamos para detectar cualquier pérdida de mensaje en condiciones extremas (por ejemplo, desincronización del reloj en la partición líder).
Marco de procesamiento de flujo
La capa de procesamiento de Delta está construida sobre la plataforma Netflix SPaaS, que proporciona integración de Apache Flink con el ecosistema de Netflix. La plataforma proporciona una interfaz de usuario que gestiona 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 trabajos 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 basado en Flink y SPaaS que utiliza basado en anotaciones DSL (lenguaje específico de dominio) para resumir detalles técnicos. Por ejemplo, para definir el paso en el que los eventos se enriquecerán llamando a servicios externos, los usuarios deben escribir el siguiente DSL y el marco creará un modelo basado en él, que será ejecutado por Flink.
Figura 3. Ejemplo de enriquecimiento en DSL en Delta
El marco de procesamiento no solo reduce la curva de aprendizaje, sino que también proporciona características comunes de procesamiento de flujo, como deduplicación, esquematización y flexibilidad y resistencia para resolver problemas operativos comunes.
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 API DSL y UDF (función definida por el usuario) para que los usuarios puedan escribir su propia lógica de procesamiento (como filtrado o transformaciones). El módulo Runtime proporciona una implementación de un analizador DSL que crea una representación interna de los pasos de procesamiento en modelos DAG. El componente de ejecución interpreta los modelos DAG para inicializar las declaraciones de Flink reales y, en última instancia, ejecutar la aplicación Flink. La arquitectura del marco se ilustra en la siguiente figura.
Figura 4. Arquitectura del marco de procesamiento de Delta Stream
Este enfoque tiene varias ventajas:
- Los usuarios pueden centrarse en su lógica empresarial sin tener que profundizar en los detalles de Flink o la estructura SPaaS.
- La optimización se puede realizar de forma transparente para los usuarios y los errores se pueden corregir sin necesidad de realizar ningún cambio en el código de usuario (UDF).
- La experiencia de la aplicación Delta se simplifica para los usuarios porque la plataforma proporciona flexibilidad y resiliencia listas para usar y recopila una variedad de métricas detalladas que se pueden usar para alertas.
Uso de producción
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. A continuación se muestra una descripción general de la arquitectura de alto nivel de la plataforma Delta.
Figura 5. Arquitectura de alto nivel de Delta.
Agradecimientos
Nos gustaría agradecer a las siguientes personas que participaron en 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
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: procesamiento de eventos en línea. Comunitario. ACM 62(5): 43–49 (2019). DOI:
: "Herramienta de creación de datos para el almacenamiento de Amazon Redshift".
Fuente: habr.com