I väntan på lanseringen av ett nytt flöde i takt Vi har förberett en översättning av intressant material.
Обзор
Vi kommer att prata om ett ganska populärt mönster där applikationer använder flera datalager, där varje butik används för sina egna syften, till exempel för att lagra den kanoniska formen av data (MySQL, etc.), tillhandahålla avancerade sökfunktioner (ElasticSearch, etc.) .), cachning (Memcachad, etc.) och andra. Vanligtvis, när du använder flera datalagrar, fungerar en av dem som det primära lagret och de andra som derivatlager. Det enda problemet är hur man synkroniserar dessa datalagrar.
Vi tittade på ett antal olika mönster som försökte lösa problemet med att synkronisera flera butiker, såsom dubbelskrivningar, distribuerade transaktioner, etc. Dessa tillvägagångssätt har dock betydande begränsningar när det gäller användning i verkligheten, tillförlitlighet och underhåll. Förutom datasynkronisering behöver vissa applikationer även berika data genom att ringa externa tjänster.
Delta utvecklades för att lösa dessa problem. Delta tillhandahåller i slutändan en konsekvent, händelsedriven plattform för datasynkronisering och anrikning.
Befintliga lösningar
Dubbel ingång
För att hålla två datalager synkroniserade kan du använda dubbel skrivning, som skriver till en lagring och sedan skriver till den andra direkt efteråt. Den första inspelningen kan göras om och den andra kan avbrytas om den första misslyckas efter att antalet försök har förbrukats. De två datalagren kan dock bli osynkroniserade om skrivning till det andra minnet misslyckas. Detta problem löses vanligtvis genom att skapa en återställningsprocedur som med jämna mellanrum kan överföra data från den första lagringen till den andra, eller bara göra det om skillnader upptäcks i data.
Problem:
Att utföra ett återställningsförfarande är ett specifikt jobb som inte kan återanvändas. Dessutom förblir data mellan lagringsplatser osynkroniserade tills återställningsproceduren äger rum. Lösningen blir mer komplex om fler än två datalager används. Slutligen kan återställningsproceduren lägga till laddning till den ursprungliga datakällan.
Ändra loggtabell
När ändringar sker i en uppsättning tabeller (som att infoga, uppdatera och ta bort en post), läggs ändringsposterna till i loggtabellen som en del av samma transaktion. En annan tråd eller process begär ständigt händelser från loggtabellen och skriver dem till ett eller flera datalager, om nödvändigt, tar bort händelser från loggtabellen efter att posten har bekräftats av alla butiker.
Problem:
Detta mönster bör implementeras som ett bibliotek, och helst utan att ändra koden för applikationen som använder det. I en polyglotmiljö bör en implementering av ett sådant bibliotek existera på vilket språk som helst, men att säkerställa enhetlighet i funktionalitet och beteende mellan språk är mycket svårt.
Ett annat problem ligger i att få schemaändringar i system som inte stöder transaktionsschemaändringar [1][2], såsom MySQL. Därför kommer mönstret att göra en ändring (till exempel en schemaändring) och transaktionsregistrera den i ändringsloggtabellen inte alltid att fungera.
Distribuerade transaktioner
Distribuerade transaktioner kan användas för att dela upp en transaktion över flera heterogena datalager så att operationen antingen är förpliktad till alla datalager som används, eller inte binder till någon av dem.
Problem:
Distribuerade transaktioner är ett mycket stort problem för heterogena datalager. Till sin natur kan de bara förlita sig på den minsta gemensamma nämnaren av de inblandade systemen. Till exempel blockerar XA-transaktioner exekvering om applikationsprocessen misslyckas under förberedelsefasen. Dessutom tillhandahåller inte XA detektering av dödläge eller stöder inte optimistiska system för samtidighetskontroll. Dessutom stöder vissa system som ElasticSearch inte XA eller någon annan heterogen transaktionsmodell. Att säkerställa skrivatomicitet i olika datalagringstekniker förblir således en mycket utmanande uppgift för applikationer [3].
Delta
Delta designades för att ta itu med begränsningarna hos befintliga datasynkroniseringslösningar och möjliggör även databerikning i farten. Vårt mål var att ta bort alla dessa komplexiteter från applikationsutvecklare så att de helt kunde fokusera på att implementera affärsfunktionalitet. Härnäst kommer vi att beskriva "Movie Search", det faktiska användningsfallet för Netflix Delta.
Netflix använder i stor utsträckning en mikrotjänstarkitektur, och varje mikrotjänst betjänar vanligtvis en typ av data. Grundläggande information om en film finns i en mikrotjänst som kallas Movie Service, och relaterad data, såsom information om producenter, skådespelare, leverantörer och så vidare, hanteras av flera andra mikrotjänster (nämligen Deal Service, Talent Service och Vendor Service).
Affärsanvändare på Netflix Studios behöver ofta söka bland olika filmkriterier, varför det är väldigt viktigt för dem att kunna söka i all filmrelaterad data.
Innan Delta behövde filmsökningsteamet hämta data från flera mikrotjänster innan filmdata indexerades. Dessutom var teamet tvunget att utveckla ett system som med jämna mellanrum skulle uppdatera sökindexet genom att begära ändringar från andra mikrotjänster, även om det inte fanns några ändringar alls. Detta system blev snabbt komplext och svårt att underhålla.
Figur 1. Pollingsystem till Delta
Efter att ha använt Delta förenklades systemet till ett händelsestyrt system som visas i följande figur. CDC-händelser (Change-Data-Capture) skickas till Keystone Kafka-ämnen med hjälp av Delta-Connector. En Delta-applikation byggd med Delta Stream Processing Framework (baserat på Flink) tar emot CDC-händelser från ett ämne, berikar dem genom att anropa andra mikrotjänster och skickar slutligen den berikade datan till ett sökindex i Elasticsearch. Hela processen sker nästan i realtid, det vill säga så fort ändringar görs i datalagret uppdateras sökindexen.
Figur 2. Datapipeline med Delta
I följande avsnitt kommer vi att beskriva driften av Delta-Connector, som ansluter till lagringen och publicerar CDC-händelser till transportlagret, som är en dataöverföringsinfrastruktur i realtid som dirigerar CDC-händelser till Kafka-ämnen. Och i slutet kommer vi att prata om Delta-strömbehandlingsramverket, som applikationsutvecklare kan använda för databearbetning och anrikningslogik.
CDC (Change-Data-Capture)
Vi har utvecklat en CDC-tjänst som heter Delta-Connector, som kan fånga engagerade ändringar från datalagret i realtid och skriva dem till en ström. Realtidsändringar tas från transaktionsloggen och lagringsdumpar. Dumpar används eftersom transaktionsloggar vanligtvis inte lagrar hela förändringshistoriken. Ändringar serialiseras vanligtvis som Delta-händelser, så mottagaren behöver inte oroa sig för var ändringen kommer ifrån.
Delta-Connector stöder flera ytterligare funktioner som:
- Möjlighet att skriva anpassade utdata med Kafka.
- Möjlighet att aktivera manuella dumpningar när som helst för alla tabeller, en specifik tabell eller för specifika primärnycklar.
- Dumpar kan tas i bitar, så det finns ingen anledning att börja om från början i händelse av misslyckande.
- Det finns inget behov av att placera lås på tabeller, vilket är mycket viktigt för att säkerställa att databasskrivtrafik aldrig blockeras av vår tjänst.
- Hög tillgänglighet på grund av redundanta instanser i AWS Availability Zones.
Vi stöder för närvarande MySQL och Postgres, inklusive distributioner på AWS RDS och Aurora. Vi stödjer även Cassandra (multimaster). Du kan ta reda på mer information om Delta-Connector här .
Kafka och transportskiktet
Deltas händelsetransportlager är byggt på plattformens meddelandetjänst .
Historiskt sett har inlägg på Netflix optimerats för tillgänglighet snarare än livslängd (se nedan). ). Avvägningen var potentiell inkonsekvens av mäklardata i olika kantscenarier. Till exempel, orent ledareval ansvarar för att mottagaren kan ha dubbletter eller förlorade händelser.
Med Delta ville vi ha starkare hållbarhetsgarantier för att säkerställa leverans av CDC-evenemang till härledda butiker. För detta ändamål föreslog vi ett specialdesignat Kafka-kluster som ett förstklassigt objekt. Du kan titta på några mäklarinställningar i tabellen nedan:
I Keystone Kafka-kluster, orent ledareval vanligtvis inkluderat för att säkerställa utgivarens tillgänglighet. Detta kan resultera i förlorade meddelanden om en osynkroniserad kopia väljs som ledare. För ett nytt Kafka-kluster med hög tillgänglighet, alternativet orent ledareval avstängd för att förhindra förlust av meddelanden.
Vi ökade också replikationsfaktor från 2 till 3 och minsta insynkroniserade repliker 1 till 2. Utgivare som skriver till det här klustret kräver ackord från alla andra, för att säkerställa att 2 av 3 repliker har de senaste meddelandena som skickas av utgivaren.
När en mäklarinstans avslutas ersätter en ny instans den gamla. Den nya mäklaren kommer dock att behöva komma ikapp de osynkroniserade replikerna, vilket kan ta flera timmar. För att minska återställningstiden för detta scenario började vi använda blockdatalagring (Amazon Elastic Block Store) istället för lokala mäklardiskar. När en ny instans ersätter en avslutad mäklarinstans bifogar den EBS-volymen som den avslutade instansen hade och börjar komma ikapp med nya meddelanden. Denna process minskar tiden för rensning av eftersläpning från timmar till minuter eftersom den nya instansen inte längre behöver replikera från ett tomt tillstånd. I allmänhet minskar separata lagrings- och mäklarlivscykler effekten av mäklarbyte avsevärt.
För att ytterligare öka dataleveransgarantin använde vi för att upptäcka eventuella meddelandeförluster under extrema förhållanden (till exempel klockavsynkronisering i partitionsledaren).
Stream Processing Framework
Deltas bearbetningslager är byggt ovanpå Netflix SPaaS-plattformen, som ger Apache Flink-integration med Netflix ekosystem. Plattformen tillhandahåller ett användargränssnitt som hanterar distributionen av Flink-jobb och orkestrering av Flink-kluster ovanpå vår Titus containerhanteringsplattform. Gränssnittet hanterar även jobbkonfigurationer och tillåter användare att göra konfigurationsändringar dynamiskt utan att behöva kompilera om Flink-jobb.
Delta tillhandahåller ett ramverk för strömbehandling baserat på Flink och SPaaS som använder anteckningsbaserad DSL (Domain Specific Language) för att abstrakta tekniska detaljer. Till exempel, för att definiera steget vid vilket händelser kommer att berikas genom att anropa externa tjänster, måste användare skriva följande DSL, och ramverket kommer att skapa en modell baserad på den, som kommer att exekveras av Flink.
Figur 3. Exempel på anrikning på DSL i Delta
Bearbetningsramverket minskar inte bara inlärningskurvan, utan tillhandahåller också vanliga strömbehandlingsfunktioner såsom deduplicering, schematisering och flexibilitet och motståndskraft för att lösa vanliga driftsproblem.
Delta Stream Processing Framework består av två nyckelmoduler, DSL & API-modulen och Runtime-modulen. DSL & API-modulen tillhandahåller DSL och UDF (User-Defined-Function) API:er så att användare kan skriva sin egen bearbetningslogik (som filtrering eller transformationer). Runtime-modulen tillhandahåller en implementering av en DSL-parser som bygger en intern representation av bearbetningssteg i DAG-modeller. Execution-komponenten tolkar DAG-modeller för att initiera de faktiska Flink-satserna och slutligen köra Flink-applikationen. Ramverkets arkitektur illustreras i följande figur.
Figur 4. Arkitektur för Delta Stream Processing Framework
Detta tillvägagångssätt har flera fördelar:
- Användare kan fokusera på sin affärslogik utan att behöva fördjupa sig i detaljerna i Flink eller SPaaS-strukturen.
- Optimering kan göras på ett sätt som är transparent för användarna, och fel kan åtgärdas utan att det krävs några ändringar i användarkoden (UDF).
- Delta-applikationsupplevelsen är förenklad för användare eftersom plattformen ger flexibilitet och motståndskraft direkt från lådan och samlar in en mängd detaljerade mätvärden som kan användas för varningar.
Produktionsanvändning
Delta har varit i produktion i över ett år och spelar en nyckelroll i många Netflix Studio-applikationer. Hon hjälpte team att implementera användningsfall som sökindexering, datalagring och händelsedrivna arbetsflöden. Nedan finns en översikt över högnivåarkitekturen för Delta-plattformen.
Figur 5. Deltas högnivåarkitektur.
Kvitteringar
Vi vill tacka följande personer som var involverade i skapandet och utvecklingen av Delta på 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 och Zhenzhong Xu.
källor
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Data Build Tool för Amazon Redshift Storage."
Källa: will.com