Dit is een gezamenlijk bericht dat is geschreven in samenwerking met Nir Tsruya van Klarna Bank AB.

Klarna is een toonaangevende wereldwijde betalings- en winkelservice die slimmere en flexibelere winkel- en aankoopervaringen biedt aan 150 miljoen actieve consumenten bij meer dan 500,000 verkopers in 45 landen. Klarna biedt directe betalingen, opties voor betalen na levering en afbetalingsplannen in een soepele aankoopervaring met één klik waarmee consumenten kunnen betalen wanneer en hoe ze dat willen. De mogelijkheid om gegevens te gebruiken om bijna realtime beslissingen te nemen, is een bron van concurrentievoordeel voor Klarna.

Dit bericht presenteert een referentiearchitectuur voor real-time vragen en besluitvorming over het gebruik van AWS Amazon Kinesis-gegevensanalyse voor Apache Flink. Daarnaast leggen we uit waarom het Klarna Decision Tooling-team Kinesis Data Analytics voor Apache Flink koos voor hun eerste real-time beslissingsqueryservice. We laten zien hoe Klarna Kinesis Data Analytics voor Apache Flink gebruikt als onderdeel van een end-to-end oplossing inclusief Amazon DynamoDB en Apache Kafka om real-time besluitvorming te verwerken.

AWS biedt een rijke set aan diensten die u kunt gebruiken om real-time inzichten te realiseren. Deze diensten omvatten Kinesis Data Analytics voor Apache Flink, de oplossing die Klarna tegenwoordig gebruikt om geautomatiseerde besluitvorming in hun bedrijf te ondersteunen. Met Kinesis Data Analytics voor Apache Flink kunt u eenvoudig streamverwerkingsapplicaties bouwen voor verschillende bronnen, waaronder Amazon Kinesis-gegevensstromen, Amazon Managed Streaming voor Apache Kafka (Amazon MSK), en Amazon MQ.

De uitdaging: real-time besluitvorming op schaal

Klanten van Klarna verwachten een realtime, probleemloze online ervaring bij het online winkelen en betalen. Op de achtergrond moet Klarna risico's zoals kredietrisico, fraudepogingen en het witwassen van geld beoordelen voor elk klantkredietverzoek in elke operationele regio. De uitkomst van deze risicobeoordeling wordt een beslissing. Beslissingen genereren dagelijks miljoenen risicobeoordelingstransacties die bijna in realtime moeten worden uitgevoerd. De uiteindelijke beslissing is de registratie of Klarna het verzoek om krediet aan een consument te verstrekken heeft goedgekeurd of afgewezen. Deze acceptatiebeslissingen zijn kritische artefacten. Ten eerste bevatten ze informatie die om juridische redenen moet worden bewaard. Ten tweede worden ze gebruikt om profielen en modellen op te bouwen die worden ingevoerd in verzekeringspolissen om het besluitvormingsproces te verbeteren. Onder de motorkap is een beslissing de som van een aantal transacties (bijvoorbeeld kredietcontroles), gecoördineerd en voortgezet via een beslissing winkel.

Klarna wilde een raamwerk bouwen om ervoor te zorgen dat beslissingen succesvol blijven, waardoor een tijdige risicobeoordeling en snelle beslissingen voor klanten worden gegarandeerd. Ten eerste probeerde het Klarna-team het probleem van het produceren en vastleggen van beslissingen op te lossen door een combinatie van Apache Kafka en AWS Lambda. Door beslissingsartefacten rechtstreeks naar een Kafka-onderwerp te publiceren, ontdekte het Klarna-team dat een hoge latentie lange wachttijden voor transacties kon veroorzaken of transacties helemaal werden afgewezen, wat leidde tot vertragingen bij het tijdig krijgen van geratificeerde beslissingen bij klanten en mogelijk verloren inkomsten. Deze aanpak veroorzaakte ook operationele overhead voor het Klarna-team, waaronder het beheer van de schema-evolutie, het opnieuw afspelen van oude gebeurtenissen en native integratie van Lambda met hun zelfbeheerde Apache Kafka-clusters.

Ontwerp voorwaarden

Klarna was in staat om hun eisen uiteen te zetten voor een oplossing om risicobeoordelingsartefacten (beslissingen) vast te leggen, die als een bron van waarheid fungeren voor alle acceptatiebeslissingen binnen Klarna. De belangrijkste vereisten waren onder meer een betrouwbaarheid van ten minste één keer en latentie van milliseconden, waardoor realtime toegang tot besluitvorming mogelijk is en de mogelijkheid om gebeurtenissen uit het verleden opnieuw af te spelen in het geval van ontbrekende gegevens in downstream-systemen. Bovendien had het team een ​​systeem nodig dat kon worden geschaald om gelijke tred te houden met Klarna's snelle [10 keer] groei.

Overzicht oplossingen

De oplossing bestaat uit twee componenten: een combinatie van een zeer beschikbare API met DynamoDB als datastore om elke beslissing op te slaan, en Amazon DynamoDB-streams met Kinesis-gegevensanalyse. Kinesis Data Analytics is een volledig beheerde Apache Flink-service en wordt gebruikt om de beslissing in realtime te streamen, verwerken, verrijken en standaardiseren en om gebeurtenissen uit het verleden opnieuw af te spelen (indien nodig).

Het volgende diagram illustreert de algehele stroom van de eindgebruiker naar de downstream-systemen.

De stroom omvat de volgende stappen:

1. Terwijl de eindgebruiker een aankoop doet, beoordelen de beleidscomponenten het risico en wordt de beslissing via de Decision Store API naar een decision store gestuurd.
2. De Decision Store API bewaart de gegevens in DynamoDB en reageert op de aanvrager. Beslissingen voor elke transactie worden op tijd geordend en gestreamd door DynamoDB Streams. Decision Store maakt ook gecentraliseerd schemabeheer mogelijk en verwerkt de evolutie van gebeurtenisschema's.
3. De toepassing Kinesis Data Analytics voor Apache Flink is de consument van DynamoDB-streams. De applicatie zorgt ervoor dat de vastgelegde beslissingen in overeenstemming zijn met het verwachte gebeurtenisschema dat vervolgens wordt gepubliceerd naar een Kafka-onderwerp om te worden gebruikt door verschillende downstream-systemen. Hier speelt Kinesis Data Analytics voor Apache Flink een cruciale rol bij het leveren van die gebeurtenissen: gegevens verzamelen, verrijken en in kaart brengen om te voldoen aan het gebeurtenisschema. Dit biedt consumenten een gestandaardiseerde manier om toegang te krijgen tot beslissingen van hun respectieve producenten. De applicatie maakt het mogelijk om ten minste één keer af te leveren, en Flink's checkpoint- en retry-mechanisme garandeert dat elke gebeurtenis wordt verwerkt en behouden.
4. De gepubliceerde Kafka-gebeurtenissen worden gebruikt door de downstream-systemen en opgeslagen in een Amazon eenvoudige opslagservice (Amazon S3) emmer. De gebeurtenissen die zijn opgeslagen in Amazon S3 weerspiegelen elke beslissing die ooit is genomen door de producerende beleidscomponenten, en kunnen door de beslissingsopslag worden gebruikt om eerdere gebeurtenissen aan te vullen en opnieuw af te spelen. Naast het bewaren van de geschiedenis van beslissingsgebeurtenissen, worden gebeurtenissen ook opgeslagen als een set variabelen in de variabelenopslag.
5. Beleidscomponenten gebruiken de variabele store om te controleren op vergelijkbare beslissingen uit het verleden om te bepalen of een aanvraag onmiddellijk kan worden geaccepteerd of geweigerd. Het verzoek wordt dan verwerkt zoals beschreven door de voorgaande werkstroom, en het volgende volgende verzoek wordt beantwoord door de variabele opslag op basis van het resultaat van de vorige beslissing.

De beslissingsopslag biedt een gestandaardiseerde workflow voor het verwerken en produceren van gebeurtenissen voor downstream-systemen en klantenondersteuning. Met alle gebeurtenissen vastgelegd en veilig opgeslagen in DynamoDB, biedt de beslissingsopslag een API voor ondersteuningstechnici (en andere ondersteunende tools zoals chatbots) om in bijna realtime beslissingen uit het verleden op te vragen en te openen.

Oplossing effect

De oplossing bood voordelen op drie gebieden.

Ten eerste zorgde de beheerde aard van Kinesis Data Analytics ervoor dat het Klarna-team zich kon concentreren op de ontwikkeling van toepassingen met toegevoegde waarde in plaats van op het beheer van de infrastructuur. Het team kan nieuwe use-cases in minder dan een week onboarden. Ze kunnen optimaal profiteren van de functie voor automatisch schalen in Kinesis Data Analytics en vooraf gebouwde bronnen en bestemmingen.

Ten tweede kan het team Apache Flink gebruiken om de nauwkeurigheid, volledigheid, consistentie en betrouwbaarheid van gegevens te waarborgen. Flink's native vermogen van stateful berekening en gegevensnauwkeurigheid door het gebruik van checkpoints en savepoints ondersteunt direct de visie van het Klarna-team om meer logica toe te voegen aan de pijplijnen, waardoor het team vol vertrouwen kan uitbreiden naar verschillende use cases. Bovendien zorgt de lage latentie van de service ervoor dat verrijkte beslissingsartefacten beschikbaar zijn voor consumenten en vervolgens voor de beleidsmedewerkers voor toekomstige besluitvorming in bijna realtime.

Ten derde stelt de oplossing het Klarna-team in staat om te profiteren van de Apache Flink open-source community, die uitgebreide community-ondersteuning biedt en de mogelijkheid biedt om bij te dragen aan de community door bugs te repareren of nieuwe functies toe te voegen.

Deze oplossing is schaalbaar gebleken met een toegenomen acceptatie van een nieuwe use-case, wat zich vertaalt in een 10-voudige toename van evenementen gedurende 3 maanden.

Lessen uit het verleden

Het Klarna-team stond voor een aantal uitdagingen met Flink-serialisatie en het upgraden van Apache Flink-versies. Flink-serialisatie is een interessant concept en cruciaal voor de prestaties van de applicatie. Flink gebruikt een andere set serializers om gegevens tussen de operators te serialiseren. Het is aan het team om de beste en meest efficiënte serializer te configureren op basis van de use case. Het Klarna-team configureerde de objecten als Flink POJO, waardoor de looptijd van de pijplijn met 85% werd verkort. Voor meer informatie, zie Flink Serialisatie Tuning Vol. 1: Uw serializer kiezen - als u kunt voordat een Flink-applicatie in productie wordt genomen.

De andere uitdaging voor het team was het upgraden van de Apache Flink-versie in Kinesis Data Analytics. Momenteel vereist de toepassing Kinesis Data Analytics voor Apache Flink de creatie van een nieuwe toepassing Kinesis Data Analytics voor Apache Flink. Momenteel is het hergebruiken van een momentopname (het binaire artefact dat de status van de Flink-applicatie vertegenwoordigt, gebruikt om de applicatie te herstellen naar het laatst genomen checkpoint) niet mogelijk tussen twee verschillende applicaties. Om die reden vereist het upgraden van de Apache Flink-versie extra stappen om ervoor te zorgen dat de applicatie geen gegevens verliest.

Wat biedt de toekomst voor Klarna en Kinesis Data Analytics voor Apache Flink?

Het team onderzoekt de uitbreiding van het gebruik van Kinesis Data Analytics en Flink in Klarna. Omdat het team al zeer ervaren is in de technologie, zal hun eerste ambitie zijn om eigenaar te worden van de infrastructuur van een Kinesis Data Analytics voor Apache Flink-implementatie en deze te verbinden met verschillende Klarna-gegevensbronnen. Het team zal vervolgens de bedrijfslogica hosten die wordt geleverd door andere afdelingen in Klarna, zoals Fraud Prevention. Hierdoor kunnen de gespecialiseerde teams zich concentreren op de bedrijfslogica en algoritmen voor fraudedetectie, terwijl de besluitvormingstools de infrastructuur voor hun rekening nemen.

Klarna, AWS en de Flink-community

Een belangrijk onderdeel van de keuze voor Kinesis Data Analytics voor Apache Flink was de open-source community en ondersteuning.

Verschillende teams binnen Klarna creëerden verschillende implementaties van een Flink DynamoDB-connector, die intern door meerdere teams werden gebruikt. Klarna identificeerde vervolgens de mogelijkheid om een ​​enkele onderhouden DynamoDB Flink-connector te maken en deze bij te dragen aan de open-sourcegemeenschap. Dit heeft geleid tot een samenwerking binnen Klarna, geleid door de Klarna Flink-experts en begeleid door Flink open-source bijdragers van AWS.

Het belangrijkste principe voor het ontwerpen van de DynamoDB Flink-connector was het gebruik van de verschillende schrijfcapaciteitsmodi van DynamoDB. DynamoDB ondersteunt On-demand en Provisioned capacity-modi en elk gedraagt ​​zich anders als het gaat om hoe het omgaat met inkomende doorvoer. On-demand-modus schaalt automatisch de DynamoDB-schrijfcapaciteit op en past zichzelf toe op de inkomende belasting. De ingerichte modus is echter beperkter en beperkt inkomend verkeer op basis van de ingerichte schrijfcapaciteit.

Om aan dit proces te voldoen, is de DynamoDB Flink-connector ontworpen om gelijktijdig schrijven naar DynamoDB mogelijk te maken. Het aantal gelijktijdige verzoeken kan worden geconfigureerd om te voldoen aan de capaciteitsmodus van DynamoDB. Bovendien ondersteunt de DynamoDB Flink-connector het omgaan met tegendruk in het geval dat de DynamoDB-schrijfvoorziening laag is in vergelijking met de binnenkomende belasting van de Apache Flink-toepassing.

Op het moment van schrijven, de DynamoDB Flink-connector is open source gemaakt.

Conclusie

Klarna draait sinds oktober 2020 met succes Kinesis Data Analytics voor Apache Flink in productie. Het biedt verschillende belangrijke voordelen. Het ontwikkelteam van Klarna kan zich richten op ontwikkeling, niet op cluster- en bedrijfsvoering. Hun applicaties kunnen snel worden aangepast en geüpload. De lage latentie-eigenschappen van de service zorgen voor een bijna-realtime ervaring voor eindgebruikers, dataconsumenten en producenten, die de risicobeoordeling en de besluitvormingsprocessen ondersteunen die ten grondslag liggen aan de continue groei van het verkeer. Tegelijkertijd zorgt de exact-eenmalige verwerking in combinatie met Flink-checkpoints en savepoints ervoor dat cruciale besluitvormings- en juridische gegevens niet verloren gaan.

Voor meer informatie over Kinesis Data Analytics en aan de slag gaan, zie Een Studio-notebook gebruiken met Kinesis Data Analytics voor Apache Flink en Meer Kinesis Data Analytics-oplossingen op GitHub.

Over de auteurs

Nir Tsuruya is hoofdingenieur bij Klarna. Hij leidt 2 technische teams die zich voornamelijk richten op real-time gegevensverwerking en -analyse op grote schaal.

Ankit Gupta is een Senior Solutions Architect bij Amazon Web Serves, gevestigd in Stockholm, Zweden, waar we klanten in Scandinavië helpen slagen in de cloud. Hij is vooral gepassioneerd door het bouwen van een sterke netwerkbasis in de cloud.

Daniël Arenhage is een Solutions Architect bij Amazon Web Services in Göteborg, Zweden.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• EVM Financiën. Uniforme interface voor gedecentraliseerde financiën. Toegang hier.
• Quantum Media Groep. IR/PR versterkt. Toegang hier.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/how-klarna-bank-ab-built-real-time-decision-making-with-amazon-kinesis-data-analytics-for-apache-flink/