Odottaessa uuden virtauksen käynnistämistä nopeudella Olemme laatineet käännöksen mielenkiintoisesta materiaalista.
Arvostelu
Puhumme melko suositusta mallista, jossa sovellukset käyttävät useita tietovarastoja, joissa jokaista varastoa käytetään omiin tarkoituksiinsa, esimerkiksi tallentamaan kanonista datamuotoa (MySQL jne.), tarjoamaan edistyneitä hakuominaisuuksia (ElasticSearch, jne.) .), välimuisti (Memcached jne.) ja muut. Useita tietovarastoja käytettäessä tyypillisesti yksi niistä toimii ensisijaisena varastona ja muut johdannaisvarastoina. Ainoa ongelma on kuinka synkronoida nämä tietovarastot.
Tarkastelimme useita erilaisia malleja, jotka yrittivät ratkaista useiden varastojen synkronointiongelman, kuten kaksoiskirjoitukset, hajautetut tapahtumat jne. Näillä lähestymistavoilla on kuitenkin merkittäviä rajoituksia todellisen käytön, luotettavuuden ja ylläpidon kannalta. Tietojen synkronoinnin lisäksi joidenkin sovellusten on myös rikastettava tietoja soittamalla ulkoisiin palveluihin.
Delta kehitettiin ratkaisemaan nämä ongelmat. Delta tarjoaa viime kädessä johdonmukaisen, tapahtumalähtöisen alustan tietojen synkronointia ja rikastamista varten.
Olemassa olevat ratkaisut
Kaksinkertainen sisäänkäynti
Jos haluat pitää kaksi tietovarastoa synkronoituna, voit käyttää kaksoiskirjoitusta, joka kirjoittaa yhteen varastoon ja kirjoittaa sitten toiseen välittömästi sen jälkeen. Ensimmäinen tallennus voidaan yrittää uudelleen ja toinen voidaan keskeyttää, jos ensimmäinen epäonnistuu sen jälkeen, kun yritysten määrä on käytetty loppuun. Kaksi tietovarastoa voivat kuitenkin tulla epäsynkroniseksi, jos kirjoittaminen toiseen varastoon epäonnistuu. Tämä ongelma ratkaistaan yleensä luomalla palautusmenettely, joka voi ajoittain siirtää tietoja uudelleen ensimmäisestä tallennustilasta toiseen tai tehdä niin vain, jos tiedoissa havaitaan eroja.
ongelmat:
Palautustoimenpiteen suorittaminen on tietty työ, jota ei voi käyttää uudelleen. Lisäksi tallennuspaikkojen välinen data pysyy epäsynkronissa, kunnes palautustoiminto suoritetaan. Ratkaisusta tulee monimutkaisempi, jos käytössä on enemmän kuin kaksi tietovarastoa. Lopuksi palautusmenettely voi lisätä kuormitusta alkuperäiseen tietolähteeseen.
Muuta lokitaulukkoa
Kun taulukkojoukkoon tehdään muutoksia (kuten tietueen lisääminen, päivitys ja poistaminen), muutostietueet lisätään lokitaulukkoon osana samaa tapahtumaa. Toinen säie tai prosessi pyytää jatkuvasti tapahtumia lokitaulukosta ja kirjoittaa ne yhteen tai useampaan tietovarastoon, tarvittaessa poistaen tapahtumia lokitaulukosta sen jälkeen, kun tietue on vahvistettu kaikissa varastoissa.
ongelmat:
Tämä malli tulisi toteuttaa kirjastona ja mieluiten muuttamatta sitä käyttävän sovelluksen koodia. Monikielisessä ympäristössä tällaisen kirjaston toteutuksen pitäisi olla millä tahansa tarvittavalla kielellä, mutta toimivuuden ja käyttäytymisen johdonmukaisuuden varmistaminen eri kielillä on erittäin vaikeaa.
Toinen ongelma on saada skeemamuutoksia järjestelmiin, jotka eivät tue tapahtumaskeeman muutoksia [1][2], kuten MySQL. Siksi muutosten tekeminen (esimerkiksi skeeman muutos) ja tapahtuman mukainen kirjaaminen muutoslokitaulukkoon ei aina toimi.
Hajautetut tapahtumat
Hajautettuja tapahtumia voidaan käyttää tapahtuman jakamiseen useiden heterogeenisten tietovarastojen kesken siten, että toiminto on joko sitoutunut kaikkiin käytettyihin tietovarastoihin tai ei sitoutunut mihinkään niistä.
ongelmat:
Hajautetut tapahtumat ovat erittäin suuri ongelma heterogeenisille tietovarastoille. Luonteeltaan ne voivat luottaa vain kyseessä olevien järjestelmien pienimpään yhteiseen nimittäjään. Esimerkiksi XA-tapahtumat estävät suorittamisen, jos sovellusprosessi epäonnistuu valmisteluvaiheessa. Lisäksi XA ei tarjoa lukkiutuman havaitsemista tai tue optimistisia samanaikaisuuden ohjausjärjestelmiä. Lisäksi jotkin järjestelmät, kuten ElasticSearch, eivät tue XA:ta tai muita heterogeenisiä tapahtumamalleja. Näin ollen kirjoitusatomisuuden varmistaminen erilaisissa tiedontallennustekniikoissa on edelleen erittäin haastava tehtävä sovelluksille [3].
Delta
Delta on suunniteltu vastaamaan olemassa olevien tietojen synkronointiratkaisujen rajoituksiin ja mahdollistaa myös tietojen rikastamisen lennossa. Tavoitteenamme oli poistaa kaikki nämä monimutkaiset asiat pois sovelluskehittäjiltä, jotta he voisivat keskittyä täysin liiketoimintatoimintojen toteuttamiseen. Seuraavaksi kuvataan "Movie Search", Netflixin Deltan todellinen käyttötapa.
Netflix käyttää laajasti mikropalveluarkkitehtuuria, ja jokainen mikropalvelu palvelee tyypillisesti yhden tyyppistä dataa. Elokuvan perustiedot sisältyvät Movie Service -nimiseen mikropalveluun, ja siihen liittyviä tietoja, kuten tietoja tuottajista, näyttelijöistä, myyjistä ja niin edelleen, hallinnoivat useat muut mikropalvelut (eli Deal Service, Talent Service ja Vendor Service).
Netflix Studiosin yrityskäyttäjien on usein tehtävä hakuja erilaisilla elokuvakriteereillä, minkä vuoksi on erittäin tärkeää, että he pystyvät hakemaan kaikista elokuviin liittyvistä tiedoista.
Ennen Deltaa elokuvahakutiimin piti hakea tiedot useista mikropalveluista ennen elokuvatietojen indeksointia. Lisäksi tiimin piti kehittää järjestelmä, joka päivittää hakuindeksiä ajoittain pyytämällä muutoksia muilta mikropalveluilta, vaikka muutoksia ei olisi ollenkaan. Tästä järjestelmästä tuli nopeasti monimutkainen ja vaikea ylläpitää.
Kuva 1. Pollausjärjestelmä Deltalle
Deltan käytön jälkeen järjestelmä yksinkertaistettiin tapahtumalähtöiseksi järjestelmäksi seuraavan kuvan mukaisesti. CDC (Change-Data-Capture) -tapahtumat lähetetään Keystone Kafka -aiheisiin Delta-Connectorin avulla. Delta Stream Processing Frameworkilla (Flinkiin perustuva) rakennettu Delta-sovellus vastaanottaa CDC-tapahtumat aiheesta, rikastaa niitä kutsumalla muita mikropalveluita ja välittää lopuksi rikastetut tiedot Elasticsearchin hakuhakemistoon. Koko prosessi tapahtuu lähes reaaliajassa, eli heti, kun tietovarastoon sitoutuu muutoksia, hakuindeksit päivitetään.
Kuva 2. Deltaa käyttävä dataputki
Seuraavissa osioissa kuvataan Delta-Connectorin toimintaa, joka muodostaa yhteyden tallennustilaan ja julkaisee CDC-tapahtumat siirtokerrokseen, joka on reaaliaikainen tiedonsiirtoinfrastruktuuri, joka reitittää CDC-tapahtumat Kafka-aiheisiin. Ja aivan lopussa puhumme Delta stream -käsittelykehyksestä, jota sovelluskehittäjät voivat käyttää tietojenkäsittelyyn ja rikastuslogiikkaan.
CDC (Change-Data-Capture)
Olemme kehittäneet CDC-palvelun nimeltä Delta-Connector, joka voi tallentaa tehdyt muutokset tietovarastosta reaaliajassa ja kirjoittaa ne streamiin. Reaaliaikaiset muutokset otetaan tapahtumalokista ja tallennusvedoksista. Dumpeja käytetään, koska tapahtumalokit eivät yleensä tallenna koko muutoshistoriaa. Muutokset sarjoidaan yleensä Delta-tapahtumina, joten vastaanottajan ei tarvitse huolehtia siitä, mistä muutos tulee.
Delta-Connector tukee useita lisäominaisuuksia, kuten:
- Kyky kirjoittaa mukautettuja lähtötietoja Kafkan ohi.
- Mahdollisuus aktivoida manuaaliset vedokset milloin tahansa kaikille taulukoille, tietylle taulukolle tai tietyille ensisijaisille avaimille.
- Kaatopaikat voidaan noutaa paloina, joten vikatilanteissa ei tarvitse aloittaa alusta.
- Taulukoihin ei tarvitse asettaa lukkoja, mikä on erittäin tärkeää varmistaaksemme, ettei palvelumme koskaan estä tietokannan kirjoitusliikennettä.
- Korkea käytettävyys AWS-saatavuusvyöhykkeiden redundanttien esiintymien vuoksi.
Tuemme tällä hetkellä MySQL:ää ja Postgresia, mukaan lukien käyttöönotot AWS RDS:ssä ja Aurorassa. Tuemme myös Cassandraa (multi-master). Saat lisätietoja Delta-Connectorista täältä .
Kafka ja kuljetuskerros
Deltan tapahtumansiirtokerros on rakennettu alustan viestintäpalveluun .
Historiallisesti Netflixissä julkaiseminen on optimoitu käytettävyyden sijaan pitkäikäisyyden vuoksi (katso alla). ). Kompromissi oli mahdollinen välittäjätietojen epäjohdonmukaisuus eri reunaskenaarioissa. Esimerkiksi, epäpuhdas johtajan valinta on vastuussa siitä, että vastaanottajalla on mahdollisesti päällekkäisiä tai kadonneita tapahtumia.
Deltan kanssa halusimme vahvempia kestävyystakuita varmistaaksemme CDC-tapahtumien toimituksen johdettuihin liikkeisiin. Tätä tarkoitusta varten ehdotimme erityisesti suunniteltua Kafka-klusteria ensiluokkaiseksi esineeksi. Voit tarkastella joitain välittäjän asetuksia alla olevasta taulukosta:
Keystone Kafka -klustereissa epäpuhdas johtajan valinta yleensä mukana julkaisijoiden käytettävyyden varmistamiseksi. Tämä voi johtaa viestin katoamiseen, jos synkronoimaton replika valitaan johtajaksi. Uusi korkean käytettävyyden Kafka-klusteri, vaihtoehto epäpuhdas johtajan valinta pois päältä viestien katoamisen estämiseksi.
Lisäsimme myös replikaatiotekijä 2-3 ja insync-kopioiden vähimmäismäärä 1–2. Julkaisijat, jotka kirjoittavat tähän klusteriin, vaativat kuittaukset kaikilta muilta, jotta varmistetaan, että kahdessa kolmesta replikistä on julkaisijan uusimmat viestit.
Kun välittäjäilmentymä päättyy, uusi ilmentymä korvaa vanhan. Uuden välittäjän on kuitenkin päästävä kiinni synkronoimattomiin replikoihin, mikä voi kestää useita tunteja. Tämän skenaarion palautusajan lyhentämiseksi aloimme käyttää lohkotietojen tallennustilaa (Amazon Elastic Block Store) paikallisten välittäjälevyjen sijaan. Kun uusi ilmentymä korvaa lopetetun välittäjän ilmentymän, se liittää lopetetulla ilmentymällä olevan EBS-taltion ja alkaa saada uusia viestejä. Tämä prosessi lyhentää ruuhkan selvitysaikaa tunneista minuutteihin, koska uuden ilmentymän ei enää tarvitse replikoida tyhjästä tilasta. Yleensä erilliset varastointi- ja välittäjän elinkaarit vähentävät merkittävästi välittäjän vaihdon vaikutusta.
Tietojen toimitustakuun lisäämiseksi edelleen käytimme havaita viestien katoaminen äärimmäisissä olosuhteissa (esimerkiksi kellon desynkronointi osion johtajassa).
Stream Processing Framework
Deltan prosessointikerros on rakennettu Netflix SPAaS -alustan päälle, joka tarjoaa Apache Flink -integraation Netflixin ekosysteemiin. Alusta tarjoaa käyttöliittymän, joka hallitsee Flink-töiden käyttöönottoa ja Flink-klusterien organisointia Titus-konttihallinta-alustamme päällä. Käyttöliittymä hallitsee myös töiden määrityksiä ja antaa käyttäjien tehdä konfiguraatiomuutoksia dynaamisesti ilman, että Flink-töitä tarvitsee kääntää uudelleen.
Delta tarjoaa Flinkiin ja SPAaS:ään perustuvan stream-käsittelykehyksen huomautuspohjainen DSL (Domain Specific Language) teknisten yksityiskohtien tiivistämiseen. Esimerkiksi määrittääkseen vaiheen, jossa tapahtumia rikastetaan kutsumalla ulkoisia palveluita, käyttäjien on kirjoitettava seuraava DSL, jonka perusteella puitteet luovat mallin, jonka Flink suorittaa.
Kuva 3. Esimerkki DSL:n rikastamisesta Deltassa
Prosessointikehys ei vain vähennä oppimiskäyrää, vaan tarjoaa myös yleisiä virrankäsittelyominaisuuksia, kuten duplikoinnin, kaavamaisen muodon ja joustavuuden ja joustavuuden yleisten toimintaongelmien ratkaisemiseksi.
Delta Stream Processing Framework koostuu kahdesta avainmoduulista, DSL & API -moduulista ja Runtime-moduulista. DSL- ja API-moduuli tarjoaa DSL- ja UDF-sovellusliittymiä (User-Defined-Function), jotta käyttäjät voivat kirjoittaa oman käsittelylogiikkansa (kuten suodatuksen tai muunnokset). Runtime-moduuli tarjoaa toteutuksen DSL-jäsentimestä, joka rakentaa sisäisen esityksen käsittelyvaiheista DAG-malleissa. Suorituskomponentti tulkitsee DAG-malleja alustaakseen todelliset Flink-lauseet ja suorittaakseen lopulta Flink-sovelluksen. Kehyksen arkkitehtuuri on havainnollistettu seuraavassa kuvassa.
Kuva 4. Delta Stream Processing Framework -arkkitehtuuri
Tällä lähestymistavalla on useita etuja:
- Käyttäjät voivat keskittyä liiketoimintalogiikkaan ilman, että heidän tarvitsee sukeltaa Flinkin tai SPAaS-rakenteen erityispiirteisiin.
- Optimointi voidaan tehdä käyttäjille läpinäkyvästi ja virheet voidaan korjata ilman, että käyttäjäkoodiin (UDF) tarvitsee tehdä muutoksia.
- Delta-sovelluskokemus on yksinkertaistettu käyttäjille, koska alusta tarjoaa joustavuutta ja joustavuutta heti käyttöönoton jälkeen ja kerää erilaisia yksityiskohtaisia mittareita, joita voidaan käyttää hälytyksiin.
Tuotantokäyttö
Delta on ollut tuotannossa yli vuoden ja sillä on avainrooli monissa Netflix Studio -sovelluksissa. Hän auttoi tiimejä toteuttamaan käyttötapauksia, kuten hakuindeksointia, tietojen tallennusta ja tapahtumapohjaisia työnkulkuja. Alla on yleiskatsaus Delta-alustan korkean tason arkkitehtuuriin.
Kuva 5. Deltan korkean tason arkkitehtuuri.
Kiitokset
Haluamme kiittää seuraavia ihmisiä, jotka osallistuivat Deltan luomiseen ja kehittämiseen Netflixissä: 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 ja Zhenzhong Xu.
lähteet
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online-tapahtumien käsittely. Commun. ACM 62(5): 43–49 (2019). DOI:
: "Datan Build Tool for Amazon Redshift Storage."
Lähde: will.com