Zephyrnet-logotyp

Amazon Managed Service för Apache Flink stöder nu Apache Flink version 1.18 | Amazon webbtjänster

Datum:

Apache Flash är en distribuerad bearbetningsmotor med öppen källkod, som erbjuder kraftfulla programmeringsgränssnitt för både ström- och batchbearbetning, med förstklassigt stöd för tillståndsbearbetning och händelsetidssemantik. Apache Flink stöder flera programmeringsspråk, Java, Python, Scala, SQL och flera API:er med olika abstraktionsnivåer, som kan användas omväxlande i samma applikation.

Amazon Managed Service för Apache Flink, som erbjuder en helt hanterad, serverlös upplevelse av att köra Apache Flink-applikationer, stöds nu Apache Flink 1.18.1, den senaste versionen av Apache Flink i skrivande stund.

I det här inlägget diskuterar vi några av de intressanta nya funktionerna och funktionerna i Apache Flink, introducerade med de senaste stora utgåvorna, 1.16, 1.17 och 1.18, och nu stöds i Managed Service för Apache Flink.

Nya kontakter

Innan vi dyker in i de nya funktionerna hos Apache Flink som är tillgängliga med version 1.18.1, låt oss utforska de nya funktionerna som kommer från tillgängligheten av många nya kontakter med öppen källkod.

Opensearch

En hängiven Opensearch connector är nu tillgänglig för att inkluderas i dina projekt, vilket gör att en Apache Flink-applikation kan skriva data direkt i OpenSearch, utan att förlita sig på Elasticsearch-kompatibilitetsläget. Denna kontakt är kompatibel med Amazon OpenSearch Service tillhandahålls och OpenSearch Service Serverlös.

Den här nya kontakten stöder SQL och tabell-API:er, som arbetar med både Java och Python, och DataStream API, endast för Java. Ur lådan ger den åtminstone en gång garantier, och synkroniserar skrivningarna med Flink-kontrollpunkten. Du kan uppnå exakt-en gångs semantik med deterministiska ID:n och upsert-metoden.

Som standard använder anslutningen OpenSearch version 1.x-klientbibliotek. Du kan byta till version 2.x genom lägga till rätt beroenden.

Amazon DynamoDB

Apache Flink-utvecklare kan nu använda en dedikerad kontakt för att skriva data in i Amazon DynamoDB. Denna kontakt är baserad på Apache Flink AsyncSink, utvecklad av AWS och nu en integrerad del av Apache Flink-projektet, för att förenkla implementeringen av effektiva sänkkontakter, med hjälp av icke-blockerande skrivförfrågningar och adaptiv batchning.

Denna kontakt stöder även båda SQL och tabell API:er, Java och Python, och Datastream API, endast för Java. Som standard skriver diskbänken i omgångar för att optimera genomströmningen. En anmärkningsvärd egenskap hos SQL-versionen är stöd för PARTITIONED BY-satsen. Genom att ange en eller flera nycklar kan du uppnå viss deduplicering på klientsidan, och endast skicka den senaste posten per nyckel med varje batchskrivning. En motsvarighet kan uppnås med DataStream API genom att specificera en lista med partitionsnycklar för överskrivning inom varje batch.

Denna kontakt fungerar endast som ett handfat. Du kan inte använda den för att läsa från DynamoDB. För att slå upp data i DynamoDB måste du fortfarande implementera en uppslagning med hjälp av Flink Async I/O API eller implementera en anpassad användardefinierad funktion (UDF) för SQL.

MongoDB

En annan intressant kontakt är för MongoDB. I det här fallet finns både källa och diskbänk tillgängliga för både SQL och tabell API: er och Datastream API. Den nya kontakten är nu officiellt en del av Apache Flink-projektet och stöds av communityn. Den här nya kontakten ersätter den gamla som tillhandahålls av MongoDB direkt, som endast stöder äldre Flink Sink och Source API:er.

Som för andra datalagringsanslutningar kan källan antingen användas som en begränsad källa, i batch-läge eller för uppslagningar. Diskbänken fungerar både i batch-läge och streaming, och stöder både upsert- och append-läge.

Bland de många anmärkningsvärda funktionerna i den här kontakten är en som är värd att nämna möjligheten att aktivera cachelagring när du använder källan för uppslagningar. Ur lådan stöder diskbänken minst en gång garantier. När en primärnyckel är definierad kan diskbänken stödja exakt-engångs-semantik via idempotenta upserts. Sink-kontakten stöder också exakt-en gångs semantik, med idempotenta upserts, när primärnyckeln är definierad.

Ny anslutningsversion

Ingen ny funktion, men en viktig faktor att ta hänsyn till när du uppdaterar en äldre Apache Flink-applikation, är den nya versionen av kopplingen. Från och med Apache Flink version 1.17 har de flesta kontakter externiserats från Apache Flinks huvuddistribution och följer oberoende versionshantering.

För att inkludera rätt beroende måste du ange artefaktversionen med formuläret: <connector-version>-<flink-version>

Till exempel den senaste Kafka-kontakten, arbetar också med Amazon Managed Streaming för Apache Kafka (Amazon MSK), är i skrivande stund version 3.1.0. Om du använder Apache Flink 1.18 är beroendet att använda följande:

<dependency> 
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kafka</artifactId> 
    <version>3.1.0-1.18</version>
</dependency>

För Amazon Kinesis, den nya kontaktversionen är 4.2.0. Beroendet för Apache Flink 1.18 kommer att vara följande:

<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kinesis</artifactId> 
    <version>4.2.0-1.18</version>
</dependency>

I följande avsnitt diskuterar vi fler av de kraftfulla nya funktionerna som nu är tillgängliga i Apache Flink 1.18 och stöds i Amazon Managed Service för Apache Flink.

SQL

I Apache Flink SQL kan användare tillhandahålla tips för att gå med i frågor som kan användas för att föreslå optimeraren för att få effekt i frågeplanen. I synnerhet i streamingapplikationer, uppslag ansluter används för att berika en tabell, som representerar strömmande data, med data som efterfrågas från ett externt system, vanligtvis en databas. Sedan version 1.16 har flera förbättringar införts för lookup joins, så att du kan justera beteendet för joinen och förbättra prestandan:

  • Slå upp cache är en kraftfull funktion som låter dig cachelagra de mest använda posterna i minnet, vilket minskar trycket på databasen. Tidigare var uppslagscache specifik för vissa kontakter. Sedan Apache Flink 1.16 har det här alternativet blivit tillgängligt för alla kontakter som internt stöder uppslag (FLIP-221). När detta skrivs, JDBC, Bikupaoch HBase kontakter stöder lookup cache. Lookup cache har tre tillgängliga lägen: FULL, för en liten datauppsättning som kan hållas helt i minnet, PARTIAL, för en stor datamängd, cachelagrar endast de senaste posterna, eller NONE, för att helt inaktivera cacheminnet. För PARTIAL cache, kan du också konfigurera antalet rader som ska buffras och tiden att leva.
  • Asynkron sökning är en annan funktion som avsevärt kan förbättra prestandan. Async lookup tillhandahåller i Apache Flink SQL en funktion som liknar Asynkron I/O tillgängligt i DataStream API. Det tillåter Apache Flink att skicka nya förfrågningar till databasen utan att blockera bearbetningstråden tills svar på tidigare uppslagningar har tagits emot. På samma sätt som Async I/O kan du konfigurera asynkronsökning för att framtvinga ordning eller tillåta oordnade resultat, eller justera buffertkapaciteten och timeouten.
  • Du kan också konfigurera en slå upp en ny strategi i kombination med PARTIAL or NONE lookup cache, för att konfigurera beteendet i händelse av en misslyckad uppslagning i den externa databasen.

Alla dessa beteenden kan kontrolleras med hjälp av en LOOKUP tips, som i följande exempel, där vi visar en uppslagskoppling med asynkron uppslagning:

SELECT 
    /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ 
    O.order_id, O.total, C.address
FROM Orders AS O 
JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C 
  ON O.customer_id = O.customer_id

PyFlink

I det här avsnittet diskuterar vi nya förbättringar och support i PyFlink.

Stöd för Python 3.10

Apache Flinks senaste versioner introducerade flera förbättringar för PyFlink-användare. Först och främst stöds nu Python 3.10 och Python 3.6-stödet har tagits bort helt (FLINK-29421). Managed Service för Apache Flink använder för närvarande Python 3.10 runtime för att köra PyFlink-applikationer.

Närmare funktionsparitet

Ur programmerings-API:s perspektiv kommer PyFlink närmare Java för varje version. DataStream API stöder nu funktioner som sidoutgångar och sändningstillstånd, och luckor i fönster-API:et har stängts. PyFlink stöder nu också nya kontakter som Amazon Kinesis dataströmmar direkt från DataStream API.

Förbättringar av trådläge

PyFlink är mycket effektivt. Omkostnaden för att köra Flink API-operatörer i PyFlink är minimal jämfört med Java eller Scala, eftersom körtiden faktiskt kör operatörsimplementeringen i JVM direkt, oavsett språket i din applikation. Men när du har en användardefinierad funktion är saker och ting lite annorlunda. En rad med Python-kod så enkelt som lambda x: x + 1, eller lika komplex som en Pandas-funktion, måste köras i en Python-körtid.

Som standard kör Apache Flink en Python-runtime på varje Task Manager, externt till JVM. Varje post serialiseras, överlämnas till Python-körtiden via kommunikation mellan processer, deserialiseras och bearbetas i Python-körtiden. Resultatet serialiseras sedan och lämnas tillbaka till JVM, där det deserialiseras. Det här är PyFlink PROCESS-läge. Det är mycket stabilt men det introducerar en overhead, och i vissa fall kan det bli en prestandaflaskhals.

Sedan version 1.15 stöder Apache Flink också THREAD-läge för PyFlink. I det här läget körs Python användardefinierade funktioner i själva JVM, vilket tar bort serialisering/deserialisering och kommunikation mellan processer. THREAD-läget har vissa begränsningar; till exempel kan THREAD-läget inte användas för Pandas eller UDAFs (användardefinierade aggregatfunktioner, bestående av många indataposter och en utdatapost), men kan avsevärt förbättra prestandan för en PyFlink-applikation.

Med version 1.16 har stödet för THREAD-läget utökats avsevärt, vilket även omfattar Python DataStream API.

THREAD-läget stöds av Managed Service för Apache Flink, och kan vara det aktiveras direkt från din PyFlink-applikation.

Apple Silicon-stöd

Om du använder Apple Silicon-baserade maskiner för att utveckla PyFlink-applikationer, som utvecklar för PyFlink 1.15, har du förmodligen stött på några av de kända Python-beroendeproblemen på Apple Silicon. Dessa problem har äntligen lösts (FLINK-25188). Dessa begränsningar påverkade inte PyFlink-applikationer som körs på Managed Service för Apache Flink. Före version 1.16, om du ville utveckla en PyFlink-applikation på en maskin som använder M1, M2 eller M3 chipset, var du tvungen att använda några lösningar, eftersom det var omöjligt att installera PyFlink 1.15 eller tidigare direkt på maskinen.

Ojusterade förbättringar av kontrollpunkten

Apache Flink 1.15 stödde redan Incremental Checkpoints och Buffer Debloating. Dessa funktioner kan användas, särskilt i kombination, för att förbättra kontrollpunktens prestanda, vilket gör kontrollpunktens varaktighet mer förutsägbar, särskilt i närvaro av mottryck. För mer information om dessa funktioner, se Optimera checkpointing i din Amazon Managed Service för Apache Flink-applikationer med buffertdebloating och ojusterade checkpoints.

Med version 1.16 och 1.17 har flera ändringar införts för att förbättra stabiliteten och prestanda.

Hantera skev data

Apache Flink använder vattenstämplar för att stödja semantik vid händelsetid. Vattenstämplar är speciella poster, normalt injicerade i flödet från källoperatören, som markerar händelsetidens förlopp för operatörer som aggregation av händelsetidsfönster. En vanlig teknik är att fördröja vattenstämplar från den senast observerade händelsetiden, för att tillåta händelser att vara ur funktion, åtminstone till viss del.

Användningen av vattenstämplar kommer dock med en utmaning. När applikationen har flera källor, till exempel tar den emot händelser från flera partitioner av ett Kafka-ämne, genereras vattenstämplar oberoende för varje partition. Internt väntar varje operatör alltid på samma vattenstämpel på alla ingångspartitioner, praktiskt taget justerar det på den långsammaste partitionen. Nackdelen är att om en av partitionerna inte tar emot data, utvecklas inte vattenstämplar, vilket ökar fördröjningen från slut till ände. Av denna anledning, an valfri timeout för tomgång har introducerats i många streamingkällor. Efter den konfigurerade timeout ignorerar generering av vattenstämplar alla partitioner som inte tar emot någon post, och vattenstämplar kan fortsätta.

Du kan också möta en liknande men motsatt utmaning om en källa tar emot händelser mycket snabbare än de andra. Vattenstämplar justeras till den långsammaste partitionen, vilket innebär att all fönsteraggregation väntar på vattenstämpeln. Poster från den snabba källan måste vänta och buffras. Detta kan resultera i att en överdriven mängd data buffras och en okontrollerbar ökning av operatörstillståndet.

För att ta itu med problemet med snabbare källor, från och med Apache Flink 1.17, kan du aktivera vattenstämpeljustering av källdelning (FLINK-28853). Denna mekanism, inaktiverad som standard, ser till att inga partitioner utvecklar sina vattenmärken för snabbt jämfört med andra partitioner. Du kan binda samman flera källor, som flera inmatningsämnen, tilldela samma inriktningsgrupp-ID och konfigurera varaktigheten för den maximala driften från det aktuella vattenmärket. Om en specifik partition tar emot händelser för snabbt, pausar källoperatören att konsumera den partitionen tills driften reduceras under det konfigurerade tröskelvärdet.

Du kan aktivera det för varje källa separat. Allt du behöver är att ange ett inriktningsgrupp-ID, som kommer att binda samman alla källor som har samma ID, och varaktigheten av den maximala driften från det aktuella minimala vattenmärket. Detta kommer att pausa konsumtion från källdeluppgiften som går för snabbt framåt, tills driften är lägre än den angivna tröskeln.

Följande kodavsnitt visar hur du kan ställa in vattenstämpeljustering av källuppdelningar på en Kafka-källa som avger vattenstämplar som inte är i ordning:

KafkaSource<Event> kafkaSource = ...
DataStream<Event> stream = env.fromSource(
    kafkaSource,
    WatermarkStrategy.<Event>forBoundedOutOfOrderness( Duration.ofSeconds(20))
        .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)),
    "Kafka source"));

Denna funktion är endast tillgänglig med FLIP-217 kompatibla källor, som stöder vattenstämpeljustering av källdelningar. I skrivande stund är det bara Kafka-källan som stöder den här funktionen bland de stora strömningskällorna.

Direkt stöd för Protobuf-format

SQL- och tabell-API:erna stöder nu direkt Protobuf-format. För att använda detta format måste du generera Protobuf Java-klasserna från .proto schemadefinitionsfiler och inkludera dem som beroenden i din applikation.

Protobuf-formatet fungerar bara med SQL- och Table-API:erna och endast för att läsa eller skriva Protobuf-serialiserad data från en källa eller till en diskbänk. För närvarande stöder Flink inte direkt Protobuf för att serialisera tillstånd direkt och det stöder inte schemautveckling, som det gör för Avro, till exempel. Du måste fortfarande registrera en anpassad serializer med lite overhead för din ansökan.

Att hålla Apache Flink öppen källkod

Apache Flink förlitar sig internt på Akka för att skicka data mellan deluppgifter. År 2022, Lightbend, företaget bakom Akka, tillkännagav en licensändring för framtida Akka-versioner, från Apache 2.0 till en mer restriktiv licens, och att Akka 2.6, versionen som används av Apache Flink, inte skulle få någon ytterligare säkerhetsuppdatering eller fix.

Även om Akka har varit historiskt mycket stabil och inte kräver frekventa uppdateringar, representerade denna licensändring en risk för Apache Flink-projektet. Apache Flink-communityts beslut var att ersätta Akka med en gaffel av version 2.6, kallad Apache Pekko (FLINK-32468). Denna gaffel kommer att behålla Apache 2.0-licensen och ta emot alla nödvändiga uppdateringar av communityn. Under tiden kommer Apache Flink-communityt att överväga om beroendet av Akka eller Pekko helt ska tas bort.

Tillståndskompression

Apache Flink erbjuder valfri komprimering (standard: av) för alla kontrollpunkter och räddningspunkter. Apache Flink identifierade en bugg i Flink 1.18.1 där operatörstillståndet inte kunde återställas korrekt när ögonblicksbildskomprimering är aktiverad. Detta kan resultera i antingen dataförlust eller oförmåga att återställa från kontrollpunkten. För att lösa detta har Managed Service för Apache Flink backporterat fast som kommer att ingå i framtida versioner av Apache Flink.

Uppgraderingar på plats med Managed Service för Apache Flink

Om du för närvarande kör en applikation på Managed Service för Apache Flink med Apache Flink 1.15 eller äldre, kan du nu uppgradera den på plats till 1.18 utan att förlora tillståndet, med hjälp av AWS-kommandoradsgränssnitt (AWS CLI), AWS molnformation or AWS Cloud Development Kit (AWS CDK), eller något verktyg som använder AWS API.

Smakämnen Uppdatera applikation API-åtgärd stöder nu uppdatering av Apache Flink-runtimeversionen av en befintlig Managed Service för Apache Flink-applikation. Du kan använda UpdateApplication direkt på en applikation som körs.

Innan du fortsätter med uppdateringen på plats måste du verifiera och uppdatera de beroenden som ingår i din applikation och se till att de är kompatibla med den nya Apache Flink-versionen. I synnerhet måste du uppdatera alla Apache Flink-bibliotek, kontakter och eventuellt Scala-versioner.

Vi rekommenderar också att du testar det uppdaterade programmet innan du fortsätter med uppdateringen. Vi rekommenderar att du testar lokalt och i en icke-produktionsmiljö, med hjälp av målversionen av Apache Flink-runtime, för att säkerställa att inga regressioner infördes.

Och slutligen, om din ansökan är uttalad rekommenderar vi att du tar en ögonblicksbild av det körande programmets tillstånd. Detta gör att du kan gå tillbaka till den tidigare applikationsversionen.

När du är redo kan du nu använda Uppdatera applikation API-åtgärd eller uppdateringsapplikation AWS CLI-kommando för att uppdatera runtime-versionen av applikationen och peka den på den nya applikationsartefakten, JAR- eller zip-filen, med de uppdaterade beroenden.

För mer detaljerad information om processen och API:t, se Uppgradering på plats för Apache Flink. Dokumentationen innehåller steg-för-steg-instruktioner och en video som guidar dig genom uppgraderingsprocessen.

Slutsatser

I det här inlägget undersökte vi några av de nya funktionerna i Apache Flink, som stöds i Amazon Managed Service för Apache Flink. Denna lista är inte heltäckande. Apache Flink introducerade också några mycket lovande funktioner, som TTL på operatörsnivå för SQL och Table API [FLIP-292] och tidsresor [FLIP-308], men dessa stöds ännu inte av API:et och är inte riktigt tillgängliga för användare ännu. Av denna anledning beslutade vi att inte täcka dem i det här inlägget.

Med stöd av Apache Flink 1.18 stöder Managed Service för Apache Flink nu den senaste versionen av Apache Flink. Vi har sett några av de intressanta nya funktionerna och nya kontakter som finns tillgängliga med Apache Flink 1.18 och hur Managed Service för Apache Flink hjälper dig att uppgradera en befintlig applikation på plats.

Du kan hitta mer information om de senaste släppen från Apache Flink-bloggen och släppkommentarer:

Om du är ny på Apache Flink rekommenderar vi vår guide för att välja rätt API och språk och följer Uppstartnings Guide för att börja använda Managed Service för Apache Flink.


Om författarna

Lorenzo NicoraLorenzo Nicora arbetar som Senior Streaming Solution Architect på AWS och hjälper kunder i hela EMEA. Han har byggt molnbaserade, dataintensiva system i över 25 år och arbetat i finansbranschen både genom konsultföretag och för FinTech-produktföretag. Han har utnyttjat öppen källkodsteknik i stor utsträckning och bidragit till flera projekt, inklusive Apache Flink.

Francisco MorilloFrancisco Morillo är en Streaming Solutions Architect på AWS. Francisco arbetar med AWS-kunder och hjälper dem att designa analysarkitekturer i realtid med hjälp av AWS-tjänster, stödja Amazon MSK och Amazon Managed Service för Apache Flink.

plats_img

Senaste intelligens

plats_img