En previsión do lanzamento dun novo fluxo ao ritmo Preparamos unha tradución de material interesante.
Comentar
Falaremos dun patrón bastante popular polo cal as aplicacións usan varios almacéns de datos, onde cada tenda se usa para os seus propios propósitos, por exemplo, para almacenar a forma canónica dos datos (MySQL, etc.), proporcionar capacidades de busca avanzadas (ElasticSearch, etc.) .), caché (Memcached, etc.) e outros. Normalmente, cando se usan varios almacéns de datos, un deles actúa como almacén principal e os outros como almacéns derivados. O único problema é como sincronizar estes almacéns de datos.
Analizamos unha serie de patróns diferentes que tentaban resolver o problema da sincronización de varias tendas, como escrituras dobres, transaccións distribuídas, etc. Non obstante, estes enfoques teñen limitacións significativas en termos de uso real, fiabilidade e mantemento. Ademais da sincronización de datos, algunhas aplicacións tamén precisan enriquecer os datos chamando a servizos externos.
Delta foi desenvolvido para resolver estes problemas. En última instancia, Delta ofrece unha plataforma consistente e impulsada por eventos para a sincronización e o enriquecemento de datos.
Solucións existentes
Dobre entrada
Para manter sincronizados dous almacéns de datos, pode usar a escritura dual, que escribe nunha tenda e despois escribe na outra inmediatamente despois. Pódese tentar de novo a primeira gravación e abortar a segunda se a primeira falla despois de esgotar o número de intentos. Non obstante, os dous almacéns de datos poden estar dessincronizados se falla a escritura na segunda tenda. Este problema adoita resolverse creando un procedemento de recuperación que pode volver transferir periodicamente os datos do primeiro almacenamento ao segundo, ou facelo só se se detectan diferenzas nos datos.
Problemas:
Realizar un procedemento de recuperación é un traballo específico que non se pode reutilizar. Ademais, os datos entre as localizacións de almacenamento permanecen fóra de sincronización ata que se realice o procedemento de restauración. A solución faise máis complexa se se usan máis de dous almacéns de datos. Finalmente, o procedemento de restauración pode engadir carga á fonte de datos orixinal.
Cambiar a táboa de rexistro
Cando se producen cambios nun conxunto de táboas (como inserir, actualizar e eliminar un rexistro), os rexistros de cambios engádense á táboa de rexistro como parte da mesma transacción. Outro fío ou proceso solicita constantemente eventos da táboa de rexistro e escríbeos nun ou máis almacéns de datos, se é necesario, eliminando eventos da táboa de rexistro despois de que o rexistro fose confirmado por todas as tendas.
Problemas:
Este patrón debería implementarse como unha biblioteca, e idealmente sen cambiar o código da aplicación que o utiliza. Nun ambiente políglota, unha implementación desta biblioteca debería existir en calquera linguaxe necesaria, pero é moi difícil garantir a coherencia da funcionalidade e do comportamento entre as linguas.
Outro problema reside na obtención de cambios de esquema en sistemas que non admiten cambios de esquema transaccional [1][2], como MySQL. Polo tanto, o patrón de facer un cambio (por exemplo, un cambio de esquema) e rexistralo transaccionalmente na táboa de rexistro de cambios non sempre funcionará.
Transaccións distribuídas
As transaccións distribuídas pódense usar para dividir unha transacción en varios almacéns de datos heteroxéneos de modo que a operación se comprometa a todos os almacéns de datos utilizados ou non se comprometa a ningún deles.
Problemas:
As transaccións distribuídas son un problema moi grande para os almacéns de datos heteroxéneos. Pola súa natureza, só poden confiar no mínimo común denominador dos sistemas implicados. Por exemplo, as transaccións XA bloquean a execución se o proceso de aplicación falla durante a fase de preparación. Ademais, XA non ofrece detección de puntos mortos nin admite esquemas de control de concorrencia optimistas. Ademais, algúns sistemas como ElasticSearch non admiten XA nin ningún outro modelo de transacción heteroxéneo. Así, garantir a atomicidade de escritura en varias tecnoloxías de almacenamento de datos segue sendo unha tarefa moi desafiante para as aplicacións [3].
Delta
Delta foi deseñado para abordar as limitacións das solucións de sincronización de datos existentes e tamén permite o enriquecemento de datos sobre a marcha. O noso obxectivo era abstraer todas estas complexidades dos desenvolvedores de aplicacións para que puidesen centrarse plenamente na implementación da funcionalidade empresarial. A continuación iremos describindo "Movie Search", o caso de uso real de Delta de Netflix.
Netflix usa amplamente unha arquitectura de microservizos, e cada microservizo normalmente serve un tipo de datos. A información básica sobre a película está contida nun microservizo chamado Movie Service, e os datos asociados, como a información sobre produtores, actores, vendedores, etc., son xestionados por outros microservizos (é dicir, Deal Service, Talent Service e Vendor Service).
Os usuarios empresariais de Netflix Studios adoitan necesitar buscar en varios criterios de películas, polo que é moi importante que poidan buscar en todos os datos relacionados coas películas.
Antes de Delta, o equipo de busca de películas necesitaba extraer datos de varios microservizos antes de indexar os datos de películas. Ademais, o equipo tivo que desenvolver un sistema que actualizase periodicamente o índice de busca solicitando cambios a outros microservizos, aínda que non houbese ningún cambio. Este sistema fíxose rapidamente complexo e difícil de manter.
Figura 1. Sistema de votación a Delta
Despois de usar Delta, o sistema simplificouse a un sistema impulsado por eventos como se mostra na seguinte figura. Os eventos CDC (Change-Data-Capture) envíanse aos temas de Keystone Kafka mediante Delta-Connector. Unha aplicación Delta creada mediante o marco de procesamento de Delta Stream (baseado en Flink) recibe eventos CDC dun tema, enriqueceos chamando a outros microservizos e, finalmente, pasa os datos enriquecidos a un índice de busca en Elasticsearch. Todo o proceso ten lugar case en tempo real, é dicir, en canto se comprometen os cambios no almacén de datos, os índices de busca actualízanse.
Figura 2. Canalización de datos usando Delta
Nas seguintes seccións, describiremos o funcionamento do Delta-Connector, que se conecta ao almacenamento e publica eventos CDC na capa de transporte, que é unha infraestrutura de transmisión de datos en tempo real que encamiña os eventos CDC aos temas de Kafka. E ao final, falaremos do marco de procesamento de fluxos Delta, que os desenvolvedores de aplicacións poden usar para o procesamento de datos e a lóxica de enriquecemento.
CDC (cambio-captura de datos)
Desenvolvemos un servizo CDC chamado Delta-Connector, que pode capturar os cambios confirmados do almacén de datos en tempo real e escribilos nun fluxo. Os cambios en tempo real tómanse do rexistro de transaccións e dos vertedoiros de almacenamento. Os volcados utilízanse porque os rexistros de transaccións normalmente non almacenan todo o historial de cambios. Os cambios adoitan ser serializados como eventos Delta, polo que o destinatario non ten que preocuparse de onde procede o cambio.
Delta-Connector admite varias funcións adicionais, como:
- Capacidade de escribir datos de saída personalizados despois de Kafka.
- Capacidade de activar os volcados manuais en calquera momento para todas as táboas, unha táboa específica ou para chaves primarias específicas.
- Os vertederos pódense recuperar en anacos, polo que non hai que comezar de novo en caso de falla.
- Non é necesario colocar bloqueos nas táboas, o que é moi importante para garantir que o tráfico de escritura da base de datos nunca sexa bloqueado polo noso servizo.
- Alta dispoñibilidade debido ás instancias redundantes en AWS Availability Zones.
Actualmente admitimos MySQL e Postgres, incluíndo implementacións en AWS RDS e Aurora. Tamén apoiamos a Cassandra (multimaster). Podes atopar máis detalles sobre Delta-Connector aquí .
Kafka e a capa de transporte
A capa de transporte de eventos de Delta está construída no servizo de mensaxería da plataforma .
Históricamente, a publicación en Netflix optimizouse para a accesibilidade e non para a lonxevidade (ver a continuación). ). A compensación foi a posible inconsistencia dos datos do corredor en varios escenarios de borde. Por exemplo, elección de líder impuro é responsable de que o destinatario poida ter eventos duplicados ou perdidos.
Con Delta, queriamos garantías de durabilidade máis fortes para garantir a entrega de eventos CDC ás tendas derivadas. Para este propósito, propuxemos un clúster de Kafka especialmente deseñado como obxecto de primeira clase. Podes ver algunhas opcións de corretor na táboa seguinte:
En clusters Keystone Kafka, elección de líder impuro adoita incluírse para garantir a accesibilidade dos editores. Isto pode producir mensaxes perdidas se se elixe unha réplica non sincronizada como líder. Para un novo clúster Kafka de alta dispoñibilidade, a opción elección de líder impuro desactivado para evitar a perda de mensaxes.
Tamén aumentamos factor de replicación de 2 a 3 e mínimos de réplicas insincronizadas 1 a 2. Os editores que escriben neste clúster requiren acks de todos os demais, para garantir que 2 de cada 3 réplicas teñan as mensaxes máis recentes enviadas polo editor.
Cando unha instancia de corretor finaliza, unha nova instancia substitúe a antiga. Non obstante, o novo corredor terá que poñerse ao día coas réplicas non sincronizadas, o que pode levar varias horas. Para reducir o tempo de recuperación deste escenario, comezamos a usar o almacenamento de datos en bloque (Amazon Elastic Block Store) en lugar de discos de intermediarios locais. Cando unha nova instancia substitúe a unha instancia de corretor finalizada, anexa o volume EBS que tiña a instancia finalizada e comeza a poñerse ao día coas novas mensaxes. Este proceso reduce o tempo de eliminación do atraso de horas a minutos porque a nova instancia xa non precisa replicarse desde un estado baleiro. En xeral, os ciclos de vida separados do almacenamento e do intermediario reducen significativamente o impacto do cambio de intermediario.
Para aumentar aínda máis a garantía de entrega de datos, utilizamos para detectar calquera perda de mensaxes en condicións extremas (por exemplo, a desincronización do reloxo no líder da partición).
Marco de procesamento de fluxos
A capa de procesamento de Delta está construída sobre a plataforma Netflix SPaaS, que proporciona a integración de Apache Flink co ecosistema de Netflix. A plataforma ofrece unha interface de usuario que xestiona o despregamento de traballos de Flink e a orquestración de clústeres Flink enriba da nosa plataforma de xestión de contedores Titus. A interface tamén xestiona as configuracións dos traballos e permite aos usuarios facer cambios de configuración de forma dinámica sen ter que recompilar os traballos de Flink.
Delta ofrece un marco de procesamento de fluxos baseado en Flink e SPaaS que usa baseado en anotacións DSL (Domain Specific Language) para resumir detalles técnicos. Por exemplo, para definir o paso no que se enriquecerán os eventos chamando a servizos externos, os usuarios deben escribir o seguinte DSL e o marco creará un modelo baseado nel, que será executado por Flink.
Figura 3. Exemplo de enriquecemento en DSL en Delta
O marco de procesamento non só reduce a curva de aprendizaxe, senón que tamén ofrece funcións comúns de procesamento de fluxos, como a deduplicación, a esquematización e a flexibilidade e resistencia para resolver problemas operativos comúns.
Delta Stream Processing Framework consta de dous módulos clave, o módulo DSL e API e o módulo Runtime. O módulo DSL e API proporciona API DSL e UDF (User-Defined-Function) para que os usuarios poidan escribir a súa propia lóxica de procesamento (como filtrado ou transformacións). O módulo Runtime proporciona unha implementación dun analizador DSL que constrúe unha representación interna dos pasos de procesamento nos modelos DAG. O compoñente de execución interpreta os modelos DAG para inicializar as instrucións de Flink reais e, finalmente, executar a aplicación Flink. A arquitectura do marco móstrase na seguinte figura.
Figura 4. Arquitectura Delta Stream Processing Framework
Este enfoque ten varias vantaxes:
- Os usuarios poden centrarse na súa lóxica empresarial sen ter que afondar nos detalles específicos de Flink ou da estrutura SPaaS.
- A optimización pódese facer dun xeito transparente para os usuarios e os erros pódense corrixir sen necesidade de modificar o código de usuario (UDF).
- A experiencia da aplicación Delta simplifícase para os usuarios porque a plataforma ofrece flexibilidade e resistencia e recolle unha variedade de métricas detalladas que se poden usar para alertas.
Uso da produción
Delta leva máis dun ano en produción e desempeña un papel fundamental en moitas aplicacións de Netflix Studio. Axudou aos equipos a implementar casos de uso como a indexación de buscas, o almacenamento de datos e os fluxos de traballo dirixidos por eventos. A continuación móstrase unha visión xeral da arquitectura de alto nivel da plataforma Delta.
Figura 5. Arquitectura de alto nivel de Delta.
Agradecementos
Queremos agradecer ás seguintes persoas que participaron na creación e desenvolvemento 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 e Zhenzhong Xu.
Fontes
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Procesamento de eventos en liña. Comun. ACM 62(5): 43–49 (2019). DOI:
: "Ferramenta de creación de datos para o almacenamento de Amazon Redshift".
Fonte: www.habr.com