Várva egy új áramlás elindítását az ütemben Érdekes anyag fordítását készítettük el.
Értékelés
Beszélni fogunk egy meglehetősen népszerű mintáról, amely szerint az alkalmazások több adattárolót használnak, ahol minden tárolót a saját céljaira használnak fel, például az adatok kanonikus formájának tárolására (MySQL stb.), fejlett keresési lehetőségeket biztosítanak (ElasticSearch, stb.) .), gyorsítótárazás (Memcached stb.) és mások. Általában több adattár használatakor az egyik elsődleges tárolóként, a többi pedig származékos tárolóként működik. Az egyetlen probléma az, hogy hogyan lehet ezeket az adattárakat szinkronizálni.
Számos különböző mintát vizsgáltunk, amelyek megpróbálták megoldani a több tároló szinkronizálásának problémáját, mint például a kettős írás, az elosztott tranzakciók stb. Ezeknek a megközelítéseknek azonban jelentős korlátai vannak a valós használat, a megbízhatóság és a karbantartás tekintetében. Az adatszinkronizálás mellett egyes alkalmazásoknak külső szolgáltatások hívásával is gazdagítaniuk kell az adatokat.
A Deltát ezen problémák megoldására fejlesztették ki. A Delta végül konzisztens, eseményvezérelt platformot biztosít az adatok szinkronizálásához és gazdagításához.
Meglévő megoldások
Kettős könyvvitel
Két adattár szinkronban tartásához használhat kettős írást, amely az egyik tárolóba ír, majd közvetlenül utána a másikba. Az első felvételt újra meg lehet próbálni, a másodikat meg lehet szakítani, ha az első sikertelen a próbálkozások számának kimerülése után. A két adattár azonban nem szinkronizálhat, ha a második tárolóba írás nem sikerül. Ezt a problémát általában úgy oldják meg, hogy létrehoznak egy helyreállítási eljárást, amely időszakonként újra tudja vinni az adatokat az első tárolóból a másodikba, vagy csak akkor, ha eltéréseket észlel az adatokban.
A problémák a következők:
A helyreállítási eljárás végrehajtása egy meghatározott feladat, amely nem használható fel újra. Ezenkívül a tárolóhelyek közötti adatok szinkronban maradnak mindaddig, amíg a visszaállítási eljárás meg nem történik. A megoldás bonyolultabbá válik, ha kettőnél több adattárat használunk. Végül a visszaállítási eljárás növelheti az eredeti adatforrás terhelését.
Naplótábla módosítása
Ha egy táblakészletben változás történik (például rekord beszúrása, frissítése és törlése), a változásrekordok ugyanannak a tranzakciónak a részeként hozzáadódnak a naplótáblához. Egy másik szál vagy folyamat folyamatosan eseményeket kér a naplótáblából, és kiírja egy vagy több adattárba, szükség esetén eltávolítja az eseményeket a naplótáblából, miután a rekordot minden tároló megerősítette.
A problémák a következők:
Ezt a mintát könyvtárként kell megvalósítani, ideális esetben az azt használó alkalmazás kódjának megváltoztatása nélkül. Poliglott környezetben egy ilyen könyvtár megvalósításának léteznie kell bármely szükséges nyelven, de nagyon nehéz biztosítani a funkcionalitás és a viselkedés konzisztenciáját a nyelvek között.
Egy másik probléma a sémamódosítások beszerzése olyan rendszerekben, amelyek nem támogatják a tranzakciós sémamódosításokat [1][2], például a MySQL-ben. Ezért nem mindig működik a változtatás (például sémamódosítás) végrehajtásának és a változási naplótáblázatban történő tranzakciós rögzítésének mintája.
Elosztott tranzakciók
Az elosztott tranzakciók segítségével egy tranzakciót fel lehet osztani több heterogén adattár között úgy, hogy a művelet vagy az összes használt adattárra le van kötve, vagy egyikre sem.
A problémák a következők:
Az elosztott tranzakciók nagyon nagy problémát jelentenek a heterogén adattárak számára. Természetüknél fogva csak az érintett rendszerek legalacsonyabb közös nevezőjére hagyatkozhatnak. Például az XA-tranzakciók blokkolják a végrehajtást, ha az alkalmazási folyamat meghiúsul az előkészítési szakaszban. Ezenkívül az XA nem nyújt holtpont-észlelést, és nem támogatja az optimista párhuzamossági vezérlési sémákat. Ezenkívül egyes rendszerek, például az ElasticSearch nem támogatják az XA-t vagy bármely más heterogén tranzakciós modellt. Így az írási atomitás biztosítása a különböző adattárolási technológiákban továbbra is igen nagy kihívást jelent az alkalmazások számára [3].
Delta
A Delta célja a meglévő adatszinkronizálási megoldások korlátainak kezelése, és lehetővé teszi az adatok menet közbeni gazdagítását is. Célunk az volt, hogy ezeket a bonyolultságokat elvonjuk az alkalmazásfejlesztőktől, hogy teljes mértékben az üzleti funkciók megvalósítására összpontosíthassanak. Ezután a „Movie Search”-t írjuk le, amely a Netflix Delta tényleges használati esete.
A Netflix széles körben használ mikroszolgáltatási architektúrát, és minden mikroszolgáltatás általában egy típusú adatot szolgál ki. A filmmel kapcsolatos alapvető információkat a Movie Service nevű mikroszolgáltatás tartalmazza, és a kapcsolódó adatokat, például a producerekről, színészekről, szállítókról és így tovább, számos más mikroszolgáltatás (nevezetesen a Deal Service, a Talent Service és a Vendor Service) kezeli.
A Netflix Studios üzleti felhasználóinak gyakran különféle filmkritériumok alapján kell keresniük, ezért nagyon fontos számukra, hogy a filmekkel kapcsolatos összes adat között kereshessenek.
A Delta előtt a filmkereső csapatnak több mikroszolgáltatásból kellett adatokat gyűjtenie a filmadatok indexelése előtt. Ezenkívül a csapatnak ki kellett fejlesztenie egy olyan rendszert, amely időszakonként frissíti a keresési indexet más mikroszolgáltatások változtatásainak kérésével, még akkor is, ha egyáltalán nem történt változás. Ez a rendszer gyorsan bonyolulttá és nehezen karbantarthatóvá vált.
1. ábra Lekérdezési rendszer a Deltához
A Delta használata után a rendszer eseményvezérelt rendszerré egyszerűsödött, amint az a következő ábrán látható. A CDC (Change-Data-Capture) események elküldésre kerülnek a Keystone Kafka témákhoz a Delta-Connector segítségével. A Delta Stream Processing Framework segítségével (Flink alapú) épített Delta alkalmazás CDC eseményeket fogad egy témából, gazdagítja azokat más mikroszolgáltatások hívásával, végül pedig továbbítja a gazdagított adatokat az Elasticsearch keresési indexének. A teljes folyamat szinte valós időben zajlik, vagyis amint az adattárházba változtatásokat kötnek, a keresési indexek frissülnek.
2. ábra. Adatfolyam a Delta használatával
A következő részekben a Delta-Connector működését ismertetjük, amely a tárolóhoz csatlakozik és CDC eseményeket tesz közzé a szállítási rétegnek, ami egy valós idejű adatátviteli infrastruktúra, amely a CDC eseményeket Kafka témákhoz irányítja. A legvégén pedig szó lesz a Delta stream feldolgozó keretrendszerről, amelyet az alkalmazásfejlesztők használhatnak adatfeldolgozásra és dúsítási logikára.
CDC (Change-Data-Capture)
Kifejlesztettünk egy Delta-Connector nevű CDC szolgáltatást, amely valós időben képes rögzíteni az adattárból az elkövetett változtatásokat, és folyamba írni. A valós idejű változások a tranzakciós naplóból és a tárolási kiíratokból származnak. A kiíratásokat azért használják, mert a tranzakciós naplók általában nem tárolják a változások teljes előzményét. A változtatások általában Delta-eseményként kerülnek sorba, így a címzettnek nem kell aggódnia, hogy honnan származik a változás.
A Delta-Connector számos további funkciót támogat, mint például:
- Lehetőség egyéni kimeneti adatok írására a Kafka segítségével.
- Lehetőség a kézi kiíratások bármikori aktiválására az összes táblához, egy adott táblához vagy meghatározott elsődleges kulcsokhoz.
- A szemétlerakók darabonként kinyerhetők, így meghibásodás esetén nem kell elölről kezdeni.
- Nincs szükség a táblákra zárolásra, ami nagyon fontos, hogy az adatbázis írási forgalmat soha ne blokkolja szolgáltatásunk.
- Magas rendelkezésre állás az AWS elérhetőségi zónáiban található redundáns példányoknak köszönhetően.
Jelenleg támogatjuk a MySQL-t és a Postgres-t, beleértve az AWS RDS-en és az Aurora-n történő telepítést. Cassandrát (multi-master) is támogatjuk. A Delta-Connectorról további részleteket itt talál .
Kafka és a szállítóréteg
A Delta eseményátviteli rétege a platform üzenetküldő szolgáltatására épül .
A történelem során a Netflixen való közzétételt a hozzáférhetőségre optimalizálták, nem pedig a hosszú élettartamra (lásd alább). ). A kompromisszum a brókeradatok lehetséges inkonzisztenciája volt különböző szélső forgatókönyvekben. Például, tisztátalan vezetőválasztás felelős azért, hogy a címzett esetlegesen ismétlődő vagy elveszett eseményei legyenek.
A Deltával erősebb tartóssági garanciákat akartunk, hogy biztosítsuk a CDC-események eljuttatását a származtatott üzletekbe. Erre a célra egy speciálisan tervezett Kafka klasztert javasoltunk első osztályú objektumként. Néhány brókerbeállítást megtekinthet az alábbi táblázatban:
A Keystone Kafka klaszterekben tisztátalan vezetőválasztás rendszerint a kiadói hozzáférés biztosítása érdekében szerepel. Ez üzenetek elvesztéséhez vezethet, ha egy nem szinkronizált replikát választanak vezetőnek. Egy új, magas rendelkezésre állású Kafka-fürthez a lehetőség tisztátalan vezetőválasztás ki van kapcsolva az üzenetvesztés elkerülése érdekében.
Mi is növeltük replikációs faktor 2-től 3-ig és minimális insinkron replikák 1-től 2-ig. Az ebbe a fürtbe író megjelenítők minden mástól jóváhagyást kérnek, biztosítva, hogy 2 replikából kettő a kiadó által küldött legfrissebb üzeneteket tartalmazza.
Amikor egy közvetítőpéldány megszűnik, egy új példány váltja fel a régit. Az új brókernek azonban utol kell érnie a nem szinkronizált replikákat, ami több órát is igénybe vehet. Ennek a forgatókönyvnek a helyreállítási idejének csökkentése érdekében a helyi közvetítőlemezek helyett blokkos adattárolást (Amazon Elastic Block Store) kezdtünk használni. Amikor egy új példány leváltja a lezárt közvetítőpéldányt, csatolja a lezárt példányhoz tartozó EBS-kötetet, és elkezdi utolérni az új üzeneteket. Ez a folyamat órákról percekre csökkenti a lemaradás törlésének idejét, mivel az új példánynak már nem kell üres állapotból replikálnia. Összességében a különálló tárolási és közvetítői életciklusok jelentősen csökkentik a közvetítőváltás hatását.
Az adatszolgáltatási garancia további növelésére használtuk szélsőséges körülmények közötti üzenetvesztés észlelésére (például óra deszinkronizálása a partícióvezetőben).
Stream Processing Framework
A Delta feldolgozási rétege a Netflix SPAaS platformra épül, amely biztosítja az Apache Flink integrációját a Netflix ökoszisztémájával. A platform egy felhasználói felületet biztosít, amely kezeli a Flink-feladatok telepítését és a Flink-fürtök összehangolását a Titus konténerkezelési platformján. A felület kezeli a jobkonfigurációkat is, és lehetővé teszi a felhasználók számára, hogy dinamikusan módosítsák a konfigurációt anélkül, hogy újra kellene fordítaniuk a Flink jobokat.
A Delta egy Flink-en és az SPAaS-en alapuló adatfolyam-feldolgozási keretrendszert biztosít annotáció alapú DSL (Domain Specific Language) a technikai részletek elvonatkoztatásához. Például annak meghatározásához, hogy az események milyen lépésben gazdagodjanak külső szolgáltatások hívásával, a felhasználóknak meg kell írniuk a következő DSL-t, és a keretrendszer ez alapján készít egy modellt, amelyet a Flink hajt végre.
3. ábra. Példa a DSL dúsítására a Deltában
A feldolgozási keretrendszer nemcsak a tanulási görbét csökkenti, hanem olyan közös adatfolyam-feldolgozási funkciókat is biztosít, mint például a deduplikáció, sematizálás, valamint rugalmasság és rugalmasság a gyakori működési problémák megoldásához.
A Delta Stream Processing Framework két kulcsmodulból áll, a DSL és API modulból és a Runtime modulból. A DSL és API modul DSL és UDF (User-Defined-Function) API-kat biztosít, így a felhasználók megírhatják saját feldolgozási logikájukat (például szűrés vagy átalakítás). A Runtime modul egy DSL-elemző megvalósítását biztosítja, amely a DAG-modellek feldolgozási lépéseinek belső reprezentációját építi fel. Az Execution komponens a DAG-modelleket értelmezi, hogy inicializálja a tényleges Flink utasításokat, és végül futtassa a Flink alkalmazást. A keretrendszer felépítését a következő ábra szemlélteti.
4. ábra: Delta Stream Processing Framework architektúra
Ennek a megközelítésnek számos előnye van:
- A felhasználók az üzleti logikájukra összpontosíthatnak anélkül, hogy elmélyülniük kellene a Flink vagy az SPAaS struktúra sajátosságaiban.
- Az optimalizálás a felhasználók számára átlátható módon történhet, a hibák pedig a felhasználói kód (UDF) módosítása nélkül javíthatók.
- A Delta alkalmazás élménye leegyszerűsödik a felhasználók számára, mert a platform rugalmasságot és rugalmasságot biztosít a dobozból, és számos részletes mérőszámot gyűjt össze, amelyek a riasztásokhoz használhatók.
Termelési felhasználás
A Delta több mint egy éve készül, és számos Netflix Studio alkalmazásban kulcsszerepet játszik. Segített a csapatoknak olyan használati esetek megvalósításában, mint a keresési indexelés, az adattárolás és az eseményvezérelt munkafolyamatok. Az alábbiakban áttekintjük a Delta platform magas szintű architektúráját.
5. ábra A Delta magas szintű architektúrája.
Köszönetnyilvánítás
Szeretnénk köszönetet mondani a következő személyeknek, akik részt vettek a Delta létrehozásában és fejlesztésében a Netflixnél: 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 és Zhenzhong Xu.
forrás
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online eseményfeldolgozás. Commun. ACM 62(5): 43–49 (2019). DOI:
: „Data Build Tool for Amazon Redshift Storage.”
Forrás: will.com