Hvis man ser på dette billede med en liste over big data-værktøjer, kan det se ud til, at alle mulige nicher inden for dette område allerede er besat. Med så meget konkurrence burde det være meget svært at komme med banebrydende teknologi.
Apache Flink-skaberne har en anden tanke om dette. Det startede som et forskningsprojekt kaldet Stratosphere. Stratosphere blev gaflet, og denne gaffel blev det, vi kender som Apache Flink. I 2014 blev det accepteret som et Apache Incubator-projekt, og blot et par måneder senere blev det et Apache-projekt på højeste niveau. I skrivende stund har projektet næsten 12.000 commits og mere end 300 bidragydere.
Hvorfor er der så meget opmærksomhed? Det skyldes, at Apache Flink blev kaldt en ny generation af big data processing framework og har nok innovationer i bagagen til at erstatte Apache Spark og blive det nye de-facto værktøj til batch- og stream processing.
Bør du skifte til Apache Flink? Skal du holde dig til Apache Spark i et stykke tid? Eller er Apache Flink bare en ny gimmick? Denne artikel vil forsøge at give dig svar på disse og andre spørgsmål.
Medmindre du har levet under en sten i de sidste par år, har du hørt om Apache Spark. Det ser ud til, at alle moderne systemer, der foretager nogen form for databehandling, bruger Apache Spark på en eller anden måde.
I lang tid var Spark det nyeste og bedste værktøj på dette område. Det leverede nogle imponerende funktioner i forhold til sine forgængere, såsom:
- Imponerende hastighed: Det er ti gange hurtigere end Hadoop, hvis data behandles på en disk, og op til 100 gange hurtigere, hvis data behandles i hukommelsen.
- Enklere rettet acyklisk grafmodel: I stedet for at definere dine databehandlingsopgaver ved hjælp af stive MapReduce-rammer giver Spark mulighed for at definere en graf af opgaver, der kan implementere komplekse databehandlingsalgoritmer
- Streambehandling: Med fremkomsten af nye teknologier, såsom Internet of Things, er det ikke nok blot at behandle en stor mængde data. Nu er vi nødt til at behandle en enorm mængde data, efterhånden som de ankommer i realtid. Derfor har Apache Spark indført stream processing, der gør det muligt at behandle en potentielt uendelig strøm af data.
- Rigt sæt af biblioteker: For at få et bedre indtryk af, hvordan du skriver programmer med Apache Spark, skal vi se på, hvordan du kan implementere et simpelt program til at tælle ord, der tæller, hvor mange gange hvert ord blev brugt i et tekstdokument:
// Read fileval file = sc.textFile("file/path")val wordCount = file // Extract words from every line .flatMap(line => line.split(" ")) // Convert words to pairs .map(word => (word, 1)) // Count how many times each word was used .reduceByKey(_ + _)Hvis du kender Scala, bør denne kode virke ligetil og svarer til at arbejde med almindelige samlinger. Først læser vi en liste af linjer fra en fil, der ligger i file/path”. Denne fil kan enten være en lokal fil eller en fil i HDFS eller S3.
Dernæst opdeles hver linje i en liste af ord ved hjælp af
flatMap-metoden, der blot opdeler en streng ved hjælp af mellemrumssymbolet. For at implementere ordtællingen bruger vi dereftermap-metoden til at konvertere hvert ord til et par, hvor det første element i parret er et ord fra inputteksten, og det andet element er simpelthen et tal et.Det sidste trin tæller simpelthen, hvor mange gange hvert ord blev brugt ved at summere tallene for alle par for det samme ord.
Apache Spark virker som et fantastisk og alsidigt værktøj. Men hvad bringer Apache Flink til bordet?
Om første øjekast ser der ikke ud til at være mange forskelle. Arkitekturdiagrammet ser meget ens ud:
Hvis du tager et kig på kodeeksemplet for ordtællingsapplikationen til Apache Flink, vil du se, at der næsten ingen forskel er:
val file = env.readTextFile("file/path")val counts = file .flatMap(line => line.split(" ")) .map(word => (word, 1)) .groupBy(0) .sum(1)Få bemærkelsesværdige forskelle, er, at vi i dette tilfælde skal bruge
readTextFile-metoden i stedet fortextFile-metoden, og at vi skal bruge et par af metoder:groupByogsumi stedet forreduceByKey.Så hvad er alt det postyr om? Apache Flink har måske ikke nogen synlige forskelle på ydersiden, men den har helt sikkert nok innovationer, til at blive næste generation af databehandlingsværktøjet. Her er blot nogle af dem:
- Implementerer egentlig streamingbehandling: Når du behandler en stream i Apache Spark, behandler den den som mange små batchproblemer og gør dermed streambehandling til et særtilfælde. Apache Flink behandler derimod batchbehandling som et specialtilfælde og bruger ikke micro batching.
- Bedre understøttelse af cyklisk og iterativ behandling: Flink indeholder nogle ekstra operationer, der gør det muligt at implementere cyklusser i din streamingapplikation og algoritmer, der skal udføre flere iterationer på batchdata.
- Brugerdefineret hukommelsesstyring: Apache Flink er en Java-applikation, men den er ikke helt afhængig af JVM garbage collector. Den implementerer en brugerdefineret hukommelseshåndtering, der gemmer data til behandling i byte-arrays. Dette gør det muligt at reducere belastningen på en garbage collector og øge ydeevnen. Du kan læse om det i dette blogindlæg.
- Lavere latenstid og højere gennemstrømning: Flere tests udført af tredjeparter tyder på, at Apache Flink har lavere latenstid og højere gennemløb end konkurrenterne.
- Kraftige windows-operatører: Når du skal behandle en datastrøm, skal du i de fleste tilfælde anvende en funktion på en finite gruppe af elementer i en strøm. Du kan f.eks. have brug for at tælle, hvor mange klik din applikation har modtaget i hvert fem-minutters interval, eller du kan have brug for at vide, hvad der var det mest populære tweet på Twitter i hvert ti-minutters interval. Spark understøtter nogle af disse brugssituationer, men Apache Flink tilbyder et langt mere kraftfuldt sæt af operatører til strømbehandling.
- Implementerer letvægts distribuerede øjebliksbilleder: Dette gør det muligt for Apache Flink at give lavt overhead og kun én gangs behandlingsgarantier i stream processing, uden at bruge micro batching som Spark gør.
Så, du arbejder på et nyt projekt, og du skal vælge en software til det. Hvad skal ypi bruge? Spark? Flink?
Der er selvfølgelig ikke noget rigtigt eller forkert svar her. Hvis du har brug for at lave kompleks stream processing, så vil jeg anbefale at bruge Apache Flink. Den har bedre understøttelse af stream processing og nogle væsentlige forbedringer.
Hvis du ikke har brug for blødende stream processing-funktioner og ønsker at være på den sikre side, er det måske bedre at holde dig til Apache Spark. Det er et mere modent projekt det har en større brugerbase, mere undervisningsmateriale og flere biblioteker fra tredjeparter. Men husk på, at Apache Flink lukker dette hul for hvert minut. Flere og flere projekter vælger Apache Flink, efterhånden som det bliver et mere modent projekt.
Hvis du på den anden side kan lide at eksperimentere med den nyeste teknologi, skal du helt sikkert give Apache Flink en chance.
Betyder alt dette, at Apache Spark er forældet, og at vi om et par år alle vil bruge Apache Flink? Svaret vil måske overraske dig. Mens Flink har nogle imponerende funktioner, forbliver Spark ikke det samme. For eksempel introducerede Apache Spark brugerdefineret hukommelsesstyring i 2015 med udgivelsen af projekt Tungsten, og siden da er der blevet tilføjet funktioner, som først blev introduceret af Apache Flink. Vinderen er ikke afgjort endnu.
I de kommende blogindlæg vil jeg skrive mere om, hvordan du kan bruge Apache Flink til batch- og streambehandling, så hold dig opdateret!
Hvis du vil vide mere om Apache Flink, kan du tage et kig på mit Pluralsight-kursus, hvor jeg dækker Apache Flink mere detaljeret. Her er et kort preview af dette kursus.