En previsió del llançament d'un nou flux al ritme Hem preparat una traducció de material interessant.
visió de conjunt
Parlarem d'un patró força popular pel qual les aplicacions utilitzen diversos magatzems de dades, on cada botiga s'utilitza per als seus propis propòsits, per exemple, per emmagatzemar la forma canònica de dades (MySQL, etc.), proporcionar capacitats de cerca avançades (ElasticSearch, etc.) .), memòria cau (Memcached, etc.) i altres. Normalment, quan s'utilitzen diversos magatzems de dades, un d'ells actua com a magatzem principal i els altres com a magatzems derivats. L'únic problema és com sincronitzar aquests magatzems de dades.
Hem analitzat una sèrie de patrons diferents que intentaven resoldre el problema de sincronitzar diverses botigues, com ara escriptures dobles, transaccions distribuïdes, etc. Tanmateix, aquests enfocaments tenen limitacions importants pel que fa a l'ús real, la fiabilitat i el manteniment. A més de la sincronització de dades, algunes aplicacions també necessiten enriquir les dades trucant a serveis externs.
Delta es va desenvolupar per resoldre aquests problemes. En última instància, Delta ofereix una plataforma consistent i basada en esdeveniments per a la sincronització i l'enriquiment de dades.
Solucions existents
Doble entrada
Per mantenir dos magatzems de dades sincronitzats, podeu utilitzar l'escriptura dual, que escriu a una botiga i després escriu a l'altra immediatament després. El primer enregistrament es pot tornar a intentar i el segon es pot avortar si el primer falla després d'haver esgotat el nombre d'intents. Tanmateix, els dos magatzems de dades poden estar fora de sincronització si falla l'escriptura al segon magatzem. Aquest problema se sol resoldre mitjançant la creació d'un procediment de recuperació que pot tornar a transferir dades periòdicament del primer emmagatzematge al segon, o fer-ho només si es detecten diferències en les dades.
Problemes:
Realitzar un procediment de recuperació és un treball específic que no es pot reutilitzar. A més, les dades entre les ubicacions d'emmagatzematge romanen fora de sincronització fins que es produeix el procediment de restauració. La solució es torna més complexa si s'utilitzen més de dos magatzems de dades. Finalment, el procediment de restauració pot afegir càrrega a la font de dades original.
Canvia la taula de registre
Quan es produeixen canvis en un conjunt de taules (com ara inserir, actualitzar i suprimir un registre), els registres de canvis s'afegeixen a la taula de registre com a part de la mateixa transacció. Un altre fil o procés sol·licita constantment esdeveniments de la taula de registre i els escriu a un o més magatzems de dades, si cal, eliminant els esdeveniments de la taula de registre després que tots els magatzems confirmin el registre.
Problemes:
Aquest patró s'ha d'implementar com una biblioteca, i idealment sense canviar el codi de l'aplicació que l'utilitza. En un entorn políglot, una implementació d'aquesta biblioteca hauria d'existir en qualsevol llenguatge necessari, però és molt difícil assegurar la coherència de la funcionalitat i el comportament entre els idiomes.
Un altre problema rau en l'obtenció de canvis d'esquema en sistemes que no admeten canvis d'esquema transaccional [1][2], com ara MySQL. Per tant, el patró de fer un canvi (per exemple, un canvi d'esquema) i registrar-lo de manera transaccional a la taula de registre de canvis no sempre funcionarà.
Transaccions distribuïdes
Les transaccions distribuïdes es poden utilitzar per dividir una transacció en diversos magatzems de dades heterogenis, de manera que l'operació es compromet a tots els magatzems de dades utilitzats o no es compromet a cap d'ells.
Problemes:
Les transaccions distribuïdes són un problema molt important per als magatzems de dades heterogenis. Per la seva naturalesa, només poden confiar en el mínim comú denominador dels sistemes implicats. Per exemple, les transaccions XA bloquegen l'execució si el procés d'aplicació falla durant la fase de preparació. A més, XA no proporciona detecció de bloqueig ni admet esquemes de control de concurrència optimistes. A més, alguns sistemes com ElasticSearch no admeten XA ni cap altre model de transacció heterogeni. Així, garantir l'atomicitat de l'escriptura en diverses tecnologies d'emmagatzematge de dades segueix sent una tasca molt difícil per a les aplicacions [3].
Delta
Delta va ser dissenyat per abordar les limitacions de les solucions de sincronització de dades existents i també permet l'enriquiment de dades sobre la marxa. El nostre objectiu era abstraure totes aquestes complexitats dels desenvolupadors d'aplicacions perquè poguessin centrar-se completament en la implementació de la funcionalitat empresarial. A continuació, descrivim "Movie Search", el cas d'ús real del Delta de Netflix.
Netflix utilitza àmpliament una arquitectura de microservei i, normalment, cada microservei serveix un tipus de dades. La informació bàsica sobre la pel·lícula es troba en un microservei anomenat Movie Service, i les dades associades, com ara informació sobre productors, actors, venedors, etc., són gestionades per diversos altres microserveis (és a dir, Deal Service, Talent Service i Vendor Service).
Els usuaris empresarials de Netflix Studios sovint necessiten cercar en diferents criteris de pel·lícules, per això és molt important que puguin cercar totes les dades relacionades amb les pel·lícules.
Abans de Delta, l'equip de cerca de pel·lícules necessitava extreure dades de diversos microserveis abans d'indexar les dades de la pel·lícula. A més, l'equip havia de desenvolupar un sistema que actualitzés periòdicament l'índex de cerca sol·licitant canvis a altres microserveis, encara que no hi hagués cap canvi. Aquest sistema ràpidament es va fer complex i difícil de mantenir.
Figura 1. Sistema de votació a Delta
Després d'utilitzar Delta, el sistema es va simplificar a un sistema impulsat per esdeveniments, tal com es mostra a la figura següent. Els esdeveniments CDC (Change-Data-Capture) s'envien als temes de Keystone Kafka mitjançant Delta-Connector. Una aplicació Delta creada amb el marc de processament de Delta Stream (basat en Flink) rep esdeveniments CDC d'un tema, els enriqueix trucant a altres microserveis i, finalment, passa les dades enriquides a un índex de cerca a Elasticsearch. Tot el procés té lloc gairebé en temps real, és a dir, tan aviat com es fan canvis al magatzem de dades, els índexs de cerca s'actualitzen.
Figura 2. Conducte de dades utilitzant Delta
A les seccions següents, descriurem el funcionament del Delta-Connector, que es connecta a l'emmagatzematge i publica esdeveniments CDC a la capa de transport, que és una infraestructura de transmissió de dades en temps real que encamina els esdeveniments de CDC als temes de Kafka. I al final, parlarem del marc de processament del flux de Delta, que els desenvolupadors d'aplicacions poden utilitzar per al processament de dades i la lògica d'enriquiment.
CDC (Canvi-Captura de dades)
Hem desenvolupat un servei de CDC anomenat Delta-Connector, que pot capturar els canvis compromesos del magatzem de dades en temps real i escriure'ls en un flux. Els canvis en temps real es prenen del registre de transaccions i dels abocadors d'emmagatzematge. Els abocaments s'utilitzen perquè els registres de transaccions normalment no emmagatzemen tot l'historial de canvis. Els canvis solen ser serialitzats com a esdeveniments Delta, de manera que el destinatari no s'ha de preocupar d'on prové el canvi.
Delta-Connector admet diverses funcions addicionals, com ara:
- Capacitat d'escriure dades de sortida personalitzades més enllà de Kafka.
- Possibilitat d'activar els abocaments manuals en qualsevol moment per a totes les taules, una taula específica o per a claus primàries específiques.
- Els abocadors es poden fer en trossos, de manera que no cal tornar a començar en cas de fallada.
- No cal col·locar bloquejos a les taules, la qual cosa és molt important per garantir que el trànsit d'escriptura de la base de dades no es bloquegi mai pel nostre servei.
- Alta disponibilitat a causa de les instàncies redundants a les zones de disponibilitat d'AWS.
Actualment admetem MySQL i Postgres, inclosos els desplegaments a AWS RDS i Aurora. També donem suport a Cassandra (multi-master). Podeu obtenir més informació sobre Delta-Connector aquí .
Kafka i la capa de transport
La capa de transport d'esdeveniments de Delta es basa en el servei de missatgeria de la plataforma .
Històricament, la publicació a Netflix s'ha optimitzat per a l'accessibilitat en lloc de la longevitat (vegeu més avall). ). La compensació va ser una possible inconsistència de les dades del corredor en diversos escenaris de punta. Per exemple, elecció de líder brut és responsable que el destinatari pugui tenir esdeveniments duplicats o perduts.
Amb Delta, volíem garanties de durabilitat més fortes per garantir el lliurament d'esdeveniments de CDC a les botigues derivades. Amb aquesta finalitat, vam proposar un clúster de Kafka especialment dissenyat com a objecte de primera classe. Podeu consultar alguns paràmetres del corredor a la taula següent:
Als clústers Keystone Kafka, elecció de líder brut normalment s'inclouen per garantir l'accessibilitat de l'editor. Això pot provocar la pèrdua de missatges si s'escull una rèplica no sincronitzada com a líder. Per a un nou clúster Kafka d'alta disponibilitat, l'opció elecció de líder brut desactivat per evitar la pèrdua de missatges.
També hem augmentat factor de replicació del 2 al 3 i rèpliques mínimes insincronitzades 1 a 2. Els editors que escriuen a aquest clúster requereixen acks de tots els altres, assegurant-se que 2 de cada 3 rèpliques tinguin els missatges més actuals enviats per l'editor.
Quan una instància de corredor finalitza, una nova instància substitueix l'antiga. Tanmateix, el nou corredor haurà de posar-se al dia amb les rèpliques no sincronitzades, cosa que pot trigar diverses hores. Per reduir el temps de recuperació d'aquest escenari, vam començar a utilitzar l'emmagatzematge de dades en bloc (Amazon Elastic Block Store) en comptes de discos de corredor local. Quan una instància nova substitueix una instància de corredor finalitzada, enllaça el volum EBS que tenia la instància finalitzada i comença a posar-se al dia amb els missatges nous. Aquest procés redueix el temps d'eliminació de l'endarreriment d'hores a minuts perquè la nova instància ja no necessita replicar-se des d'un estat buit. En general, els cicles de vida d'emmagatzematge i de corredor separats redueixen significativament l'impacte del canvi de corredor.
Per augmentar encara més la garantia de lliurament de dades, hem utilitzat per detectar qualsevol pèrdua de missatge en condicions extremes (per exemple, desincronització del rellotge al líder de la partició).
Marc de processament de fluxos
La capa de processament de Delta es construeix a la part superior de la plataforma Netflix SPaaS, que proporciona la integració d'Apache Flink amb l'ecosistema de Netflix. La plataforma proporciona una interfície d'usuari que gestiona el desplegament de treballs de Flink i l'orquestració de clústers Flink a la part superior de la nostra plataforma de gestió de contenidors Titus. La interfície també gestiona les configuracions de treballs i permet als usuaris fer canvis de configuració de manera dinàmica sense haver de recompilar els treballs de Flink.
Delta proporciona un marc de processament de flux basat en Flink i SPaaS que utilitza basat en anotacions DSL (Domain Specific Language) per resumir detalls tècnics. Per exemple, per definir el pas en què els esdeveniments s'enriquiran trucant a serveis externs, els usuaris han d'escriure el següent DSL i el marc crearà un model basat en ell, que serà executat per Flink.
Figura 3. Exemple d'enriquiment en DSL a Delta
El marc de processament no només redueix la corba d'aprenentatge, sinó que també ofereix funcions de processament de flux comunes com ara la deduplicació, l'esquematització i la flexibilitat i la resistència per resoldre problemes operatius comuns.
Delta Stream Processing Framework consta de dos mòduls clau, el mòdul DSL i API i el mòdul Runtime. El mòdul DSL i API proporciona API DSL i UDF (User-Defined-Function) perquè els usuaris puguin escriure la seva pròpia lògica de processament (com ara filtratge o transformacions). El mòdul Runtime proporciona una implementació d'un analitzador DSL que crea una representació interna dels passos de processament en models DAG. El component d'execució interpreta els models DAG per inicialitzar les declaracions de Flink reals i, finalment, executar l'aplicació Flink. L'arquitectura del marc s'il·lustra a la figura següent.
Figura 4. Arquitectura Delta Stream Processing Framework
Aquest enfocament té diversos avantatges:
- Els usuaris poden centrar-se en la seva lògica empresarial sense haver d'aprofundir en les especificitats de Flink o l'estructura SPaaS.
- L'optimització es pot fer d'una manera transparent per als usuaris, i els errors es poden solucionar sense requerir cap canvi al codi d'usuari (UDF).
- L'experiència de l'aplicació Delta es simplifica per als usuaris perquè la plataforma ofereix flexibilitat i resiliència des de la caixa i recull una varietat de mètriques detallades que es poden utilitzar per a les alertes.
Ús de producció
Delta porta més d'un any en producció i té un paper clau en moltes aplicacions de Netflix Studio. Va ajudar els equips a implementar casos d'ús com ara la indexació de cerca, l'emmagatzematge de dades i els fluxos de treball basats en esdeveniments. A continuació es mostra una visió general de l'arquitectura d'alt nivell de la plataforma Delta.
Figura 5. Arquitectura d'alt nivell de Delta.
Agraïments
Volem agrair a les persones següents que van participar en la creació i desenvolupament de Delta a 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 i Zhenzhong Xu.
Fonts
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Processament d'esdeveniments en línia. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Eina de creació de dades per a Amazon Redshift Storage".
Font: www.habr.com