Hadoop, Storm, Samza, Spark en Flink: Big Data Frameworks vergeleken

Invoering

Big data is een algemene term voor de niet-traditionele strategieën en technologieën die nodig zijn voor het verzamelen, organiseren, verwerken en verzamelen van inzichten uit grote datasets. Hoewel het probleem van het werken met gegevens die de rekenkracht of opslagcapaciteit van een enkele computer te boven gaan, niet nieuw is, is de alomtegenwoordigheid, schaal en waarde van dit type computergebruik de afgelopen jaren sterk uitgebreid.

In een eerdere gids hebben we enkele van de algemene concepten, verwerkingsfasen en terminologie besproken die in big data-systemen worden gebruikt. In dit artikel zullen we een van de meest essentiële componenten van een big data-systeem bekijken: verwerkingsframeworks. Verwerkingsframeworks berekenen de gegevens in het systeem, hetzij door te lezen uit niet-vluchtige opslag, hetzij wanneer deze in het systeem worden opgenomen. Computing over data is het proces van het extraheren van informatie en inzicht uit grote hoeveelheden individuele datapunten.

We behandelen de volgende kaders:

• Batch-only frameworks:
  • Apache Hadoop
  • Apache Storm
  • Apache Samza
  • Apache Spark
  • Apache Flink

  Wat zijn kaders voor big data-verwerking?

  Processing frameworks en processing engines zijn verantwoordelijk voor het berekenen van data in een datasysteem. Hoewel er geen gezaghebbende definitie bestaat die \engines van \frameworks scheidt, is het soms handig om eerstgenoemde te definiëren als het daadwerkelijke onderdeel dat verantwoordelijk is voor het werken met gegevens en het laatste als een set componenten die zijn ontworpen om hetzelfde te doen.

  Apache Hadoop kan bijvoorbeeld worden beschouwd als een verwerkingsframework met MapReduce als standaard verwerkingsengine. Engines en frameworks kunnen vaak worden verwisseld of samen worden gebruikt. Apache Spark, een ander framework, kan bijvoorbeeld worden gekoppeld aan Hadoop om MapReduce te vervangen. Deze interoperabiliteit tussen componenten is een van de redenen waarom big data-systemen zo flexibel zijn.

  Hoewel de systemen die deze fase van de gegevenslevenscyclus afhandelen, complex kunnen zijn, lijken de doelen op een breed niveau erg op elkaar: werken met gegevens om het begrip te vergroten, patronen aan het licht te brengen en inzicht te krijgen in complexe interacties.

  Om de bespreking van deze componenten te vereenvoudigen, zullen we deze verwerkingsframeworks groeperen op basis van de staat van de gegevens waarvoor ze zijn ontworpen. Sommige systemen verwerken gegevens in batches, terwijl andere gegevens verwerken in een continue stroom terwijl deze het systeem binnenstroomt. Weer anderen kunnen op een van deze manieren met gegevens omgaan.

  We zullen elk type verwerking als een concept introduceren voordat we ingaan op de details en gevolgen van verschillende implementaties.

  Batchverwerkingssystemen

  Batchverwerking heeft een lange geschiedenis binnen de big data-wereld. Batchverwerking omvat het werken met een grote, statische gegevensset en het resultaat op een later tijdstip retourneren wanneer de berekening is voltooid.

  De datasets in batchverwerking zijn typisch...

  • begrensd: batchgegevenssets vertegenwoordigen een eindige verzameling gegevens
  • permanent: gegevens worden bijna altijd ondersteund door een soort permanente opslag
  • groot: batchbewerkingen zijn vaak de enige optie voor het verwerken van extreem grote sets gegevens

  Batchverwerking is zeer geschikt voor berekeningen waarbij toegang tot een volledige set records vereist is. Bij het berekenen van totalen en gemiddelden moeten datasets bijvoorbeeld holistisch worden behandeld in plaats van als een verzameling individuele records. Deze bewerkingen vereisen dat de toestand behouden blijft voor de duur van de berekeningen.

  Taken die zeer grote hoeveelheden gegevens vereisen, kunnen vaak het beste worden afgehandeld door batchbewerkingen. Of de datasets nu rechtstreeks vanuit de permanente opslag worden verwerkt of in het geheugen worden geladen, batchsystemen worden gebouwd met het oog op grote hoeveelheden en hebben de middelen om ze te verwerken. Omdat batchverwerking uitblinkt in het verwerken van grote hoeveelheden persistente gegevens, wordt het vaak gebruikt met historische gegevens.

  De afweging voor het verwerken van grote hoeveelheden gegevens is een langere rekentijd. Daarom is batchverwerking niet geschikt in situaties waarin de verwerkingstijd bijzonder groot is.

  Apache Hadoop

  Apache Hadoop is een verwerkingsframework dat uitsluitend batchverwerking biedt. Hadoop was het eerste big data-framework dat veel aandacht kreeg in de open-sourcegemeenschap. Op basis van verschillende artikelen en presentaties van Google over hoe ze in die tijd met enorme hoeveelheden gegevens omgingen, heeft Hadoop de algoritmen en de componentenstapel opnieuw geïmplementeerd om grootschalige batchverwerking toegankelijker te maken.

  Moderne versies van Hadoop zijn samengesteld uit verschillende componenten of lagen die samenwerken om batchgegevens te verwerken:

  • HDFS: HDFS is de gedistribueerde bestandssysteemlaag die opslag en replicatie over de clusterknooppunten coördineert. HDFS zorgt ervoor dat gegevens beschikbaar blijven ondanks onvermijdelijke hoststoringen. Het wordt gebruikt als gegevensbron, om tussentijdse verwerkingsresultaten op te slaan en om de uiteindelijke berekende resultaten te bewaren.
  • GAREN: YARN, wat staat voor Yet Another Resource Negotiator, is de clustercoördinerende component van de Hadoop-stack. Het is verantwoordelijk voor het coördineren en beheren van de onderliggende resources en het plannen van uit te voeren taken. YARN maakt het mogelijk om veel meer diverse workloads op een Hadoop-cluster uit te voeren dan in eerdere iteraties mogelijk was, door te fungeren als een interface naar de clusterresources.
  • MapReduce: MapReduce is de native batchverwerkingsengine van Hadoop.

  Batchverwerkingsmodel

  De verwerkingsfunctionaliteit van Hadoop komt van de MapReduce-engine. De verwerkingstechniek van MapReduce volgt het kaart-, shuffle- en reduce-algoritme met behulp van sleutel-waardeparen. De basisprocedure omvat:

  • De dataset lezen van het HDFS-bestandssysteem
  • Het verdelen van de dataset in stukken en verdelen over de beschikbare nodes
  • De berekening op elk knooppunt toepassen op de subset van gegevens (de tussentijdse resultaten worden teruggeschreven naar HDFS)
  • De tussentijdse resultaten herverdelen naar groeperen op sleutel
  • \De waarde van elke sleutel verminderen door de resultaten die door de afzonderlijke knooppunten zijn berekend, samen te vatten en te combineren
  • Schrijf de berekende eindresultaten terug naar HDFS

  Voordelen en beperkingen

  Omdat deze methodologie sterk gebruikmaakt van permanente opslag, waarbij meerdere keren per taak wordt gelezen en geschreven, is deze vaak vrij traag. Aan de andere kant, aangezien schijfruimte doorgaans een van de meest voorkomende serverbronnen is, betekent dit dat MapReduce enorme datasets aankan. Dit betekent ook dat MapReduce van Hadoop doorgaans op goedkopere hardware kan draaien dan sommige alternatieven, omdat het niet probeert alles in het geheugen op te slaan. MapReduce heeft een ongelooflijk schaalbaarheidspotentieel en is gebruikt in productie op tienduizenden knooppunten.

  Als doel voor ontwikkeling staat MapReduce bekend om zijn vrij steile leercurve. Andere toevoegingen aan het Hadoop-ecosysteem kunnen de impact hiervan in verschillende mate verminderen, maar het kan nog steeds een factor zijn bij het snel implementeren van een idee op een Hadoop-cluster.

  Hadoop heeft een uitgebreid ecosysteem, waarbij het Hadoop-cluster zelf vaak wordt gebruikt als bouwsteen voor andere software. Veel andere verwerkingsframeworks en -engines hebben Hadoop-integraties om HDFS en de YARN-resourcemanager te gebruiken.

  Samenvatting

  Apache Hadoop en zijn MapReduce-verwerkingsengine bieden een goed getest batchverwerkingsmodel dat het meest geschikt is voor het verwerken van zeer grote datasets waarbij tijd geen significante factor is. De lage kosten van componenten die nodig zijn voor een goed functionerend Hadoop-cluster maken deze verwerking goedkoop en effectief voor veel gebruiksscenario's. Compatibiliteit en integratie met andere frameworks en engines betekenen dat Hadoop vaak kan dienen als basis voor meerdere verwerkingsworkloads met behulp van diverse technologie.

  Stroomverwerkingssystemen

  Stream processing-systemen berekenen over gegevens wanneer deze het systeem binnenkomen. Dit vereist een ander verwerkingsmodel dan het batchparadigma. In plaats van bewerkingen te definiëren die op een volledige dataset moeten worden toegepast, definiëren stroomprocessors bewerkingen die op elk afzonderlijk gegevensitem worden toegepast terwijl het door het systeem gaat.

  De datasets in stroomverwerking worden als \onbegrensd beschouwd. Dit heeft een aantal belangrijke implicaties:

  • De totale dataset wordt alleen gedefinieerd als de hoeveelheid data die tot nu toe in het systeem is ingevoerd.
  • De werkende dataset is misschien relevanter en is beperkt tot één item tegelijk.
  • De verwerking is gebaseerd op gebeurtenissen en \eindigt pas als deze expliciet wordt gestopt. De resultaten zijn onmiddellijk beschikbaar en worden voortdurend bijgewerkt als er nieuwe gegevens binnenkomen.

  Stroomverwerkingssystemen kunnen een bijna onbeperkte hoeveelheid gegevens verwerken, maar ze verwerken slechts één (echte stroomverwerking) of zeer weinig (microbatchverwerking) items tegelijk, waarbij de minimale status tussen de records wordt gehandhaafd. Hoewel de meeste systemen methoden bieden om een bepaalde toestand te behouden, is stoomverwerking sterk geoptimaliseerd voor meer functionele verwerking met weinig bijwerkingen.

  Functionele bewerkingen richten zich op discrete stappen met een beperkte status of neveneffecten. Het uitvoeren van dezelfde bewerking op hetzelfde stuk gegevens levert dezelfde uitvoer op, onafhankelijk van andere factoren. Dit soort verwerking past goed bij streams omdat de status tussen items meestal een combinatie is van moeilijk, beperkt en soms ongewenst. Dus hoewel een vorm van staatsbeheer meestal mogelijk is, zijn deze kaders veel eenvoudiger en efficiënter als ze ontbreken.

  Dit type verwerking leent zich voor bepaalde soorten werklasten. Verwerking met bijna realtime vereisten wordt goed bediend door het streamingmodel. Analyses, logboekregistratie van server- of applicatiefouten en andere op tijd gebaseerde statistieken zijn een natuurlijke combinatie, omdat reageren op veranderingen op deze gebieden van cruciaal belang kan zijn voor zakelijke functies. Streamverwerking is geschikt voor gegevens waarbij u moet reageren op veranderingen of pieken en waarbij u geïnteresseerd bent in trends in de loop van de tijd.

  Apache Storm

  Apache Storm is een raamwerk voor streamverwerking dat zich richt op extreem lage latentie en misschien wel de beste optie is voor workloads die bijna realtime verwerking vereisen. Het kan zeer grote hoeveelheden gegevens aan en levert resultaten met minder latentie dan andere oplossingen.

  Stroomverwerkingsmodel

  Stormstream-verwerking werkt door DAG's (Directed Acyclic Graphs) te orkestreren in een raamwerk dat topologieën wordt genoemd. Deze topologieën beschrijven de verschillende transformaties of stappen die zullen worden uitgevoerd op elk inkomend stukje data wanneer het het systeem binnenkomt.

  De topologieën zijn samengesteld uit:

  • Streams: conventionele datastreams. Dit zijn onbeperkte gegevens die continu bij het systeem aankomen.
  • Spouts: Bronnen van gegevensstromen aan de rand van de topologie. Dit kunnen API's, wachtrijen, enz. zijn die gegevens produceren om mee te werken.
  • Bouten: Bouten vertegenwoordigen een verwerkingsstap die streams verbruikt, er een bewerking op toepast en het resultaat uitvoert als een stream. Bouten zijn verbonden met elk van de tuiten en vervolgens met elkaar verbonden om alle noodzakelijke verwerking te regelen. Aan het einde van de topologie kan de uiteindelijke boutuitvoer worden gebruikt als invoer voor een aangesloten systeem.

  Het idee achter Storm is om kleine, discrete bewerkingen te definiëren met behulp van de bovenstaande componenten en deze vervolgens samen te stellen in een topologie. Storm biedt standaard garanties voor ten minste één keer verwerken, wat betekent dat het kan garanderen dat elk bericht ten minste één keer wordt verwerkt, maar in sommige foutscenario's kunnen er duplicaten zijn. Storm garandeert niet dat berichten op volgorde worden verwerkt.

  Om stateful verwerking precies één keer te bereiken, is er ook een abstractie genaamd Trident beschikbaar. Om expliciet te zijn, Storm zonder Trident wordt vaak Core Storm genoemd. Trident verandert de verwerkingsdynamiek van Storm aanzienlijk, verhoogt de latentie, voegt status toe aan de verwerking en implementeert een micro-batching-model in plaats van een item-voor-item puur streamingsysteem.

  Storm-gebruikers raden meestal aan om Core Storm waar mogelijk te gebruiken om die boetes te vermijden. Met dat in gedachten is de garantie van Trident om items precies één keer te verwerken nuttig in gevallen waarin het systeem dubbele berichten niet intelligent kan verwerken. Trident is ook de enige keuze binnen Storm wanneer u de status tussen items moet behouden, zoals bij het tellen hoeveel gebruikers binnen een uur op een link klikken. Trident geeft Storm flexibiliteit, ook al speelt het niet in op de natuurlijke sterke punten van het framework.

  Trident-topologieën zijn samengesteld uit:

  • Streambatches: dit zijn microbatches van streamgegevens die in stukken zijn verdeeld om semantiek voor batchverwerking te bieden.
  • Bewerkingen: dit zijn batchprocedures die op de gegevens kunnen worden uitgevoerd.

  Voordelen en beperkingen

  Storm is waarschijnlijk de beste oplossing die momenteel beschikbaar is voor bijna realtime verwerking. Het is in staat om gegevens te verwerken met extreem lage latentie voor werklasten die met minimale vertraging moeten worden verwerkt. Storm is vaak een goede keuze wanneer de verwerkingstijd direct van invloed is op de gebruikerservaring, bijvoorbeeld wanneer feedback van de verwerking direct wordt teruggekoppeld naar de pagina van een bezoeker op een website.

  Storm met Trident geeft je de mogelijkheid om micro-batches te gebruiken in plaats van pure stream-verwerking. Hoewel dit gebruikers meer flexibiliteit geeft om de tool naar een beoogd gebruik te vormen, heeft het ook de neiging om enkele van de grootste voordelen van de software ten opzichte van andere oplossingen teniet te doen. Dat gezegd hebbende, is het nog steeds nuttig om een keuze te hebben voor de streamverwerkingsstijl.

  Core Storm biedt geen bestelgaranties van berichten. Core Storm biedt garanties voor ten minste één keer verwerken, wat betekent dat de verwerking van elk bericht kan worden gegarandeerd, maar dat er duplicaten kunnen optreden. Trident biedt exact-eenmalige garanties en kan bestellen tussen batches, maar niet binnen.

  Wat betreft interoperabiliteit kan Storm worden geïntegreerd met Hadoop's YARN-resource-onderhandelaar, waardoor het gemakkelijk is om verbinding te maken met een bestaande Hadoop-implementatie. Storm heeft meer dan de meeste verwerkingsframeworks een zeer brede taalondersteuning, waardoor gebruikers veel opties hebben voor het definiëren van topologieën.

  Samenvatting

  Voor pure streamverwerkingsworkloads met zeer strikte latentievereisten is Storm waarschijnlijk de beste volwassen optie. Het kan berichtverwerking garanderen en kan met een groot aantal programmeertalen worden gebruikt. Omdat Storm geen batchverwerking uitvoert, moet u aanvullende software gebruiken als u die mogelijkheden nodig hebt. Als u een sterke behoefte heeft aan garanties voor eenmalig verwerken, kan Trident die bieden. Andere raamwerken voor streamverwerking kunnen op dat moment echter ook beter passen.

  Apache Samza

  Apache Samza is een raamwerk voor streamverwerking dat nauw is verbonden met het Apache Kafka-berichtensysteem. Hoewel Kafka door veel streamverwerkingssystemen kan worden gebruikt, is Samza speciaal ontworpen om te profiteren van de unieke architectuur en garanties van Kafka. Het gebruikt Kafka om fouttolerantie, buffering en statusopslag te bieden.

  Samza gebruikt YARN voor onderhandeling over resources. Dit betekent dat standaard een Hadoop-cluster vereist is (minstens HDFS en YARN), maar het betekent ook dat Samza kan vertrouwen op de rijke functies die in YARN zijn ingebouwd.

  Stroomverwerkingsmodel

  Samza vertrouwt op de semantiek van Kafka om de manier te definiëren waarop streams worden afgehandeld. Kafka gebruikt de volgende concepten bij het omgaan met data:

  • Onderwerpen: elke gegevensstroom die een Kafka-systeem binnenkomt, wordt een onderwerp genoemd. Een onderwerp is in feite een stroom gerelateerde informatie waarop consumenten zich kunnen abonneren.
  • Partities: om een onderwerp over nodes te verdelen, verdeelt Kafka de inkomende berichten in partities. De partitie-indelingen zijn gebaseerd op een sleutel zodat elk bericht met dezelfde sleutel gegarandeerd naar dezelfde partitie wordt verzonden. Partities hebben gegarandeerde ordening.
  • Brokers: de afzonderlijke knooppunten waaruit een Kafka-cluster bestaat, worden brokers genoemd.
  • Producer: elke component die naar een Kafka-onderwerp schrijft, wordt een producer genoemd. De producent levert de sleutel die wordt gebruikt om een onderwerp te partitioneren.
  • Consumenten: Consumenten zijn elk onderdeel dat leest uit een Kafka-onderwerp. Consumenten zijn verantwoordelijk voor het bijhouden van informatie over hun eigen compensatie, zodat ze weten welke records zijn verwerkt als er een storing optreedt.

  Omdat Kafka een onveranderlijke log vertegenwoordigt, behandelt Samza onveranderlijke streams. Dit betekent dat elke transformatie nieuwe streams creëert die door andere componenten worden gebruikt zonder de initiële stream te beïnvloeden.

  Voordelen en beperkingen

  Samza's afhankelijkheid van een Kafka-achtig wachtrijsysteem lijkt op het eerste gezicht misschien beperkend. Het biedt het systeem echter enkele unieke garanties en functies die niet gebruikelijk zijn in andere stroomverwerkingssystemen.

  Kafka biedt bijvoorbeeld al gerepliceerde opslag van gegevens die toegankelijk zijn met een lage latentie. Het biedt ook een zeer eenvoudig en goedkoop model met meerdere abonnees voor elke afzonderlijke gegevenspartitie. Alle output, inclusief tussentijdse resultaten, wordt ook naar Kafka geschreven en kan onafhankelijk worden geconsumeerd door downstream-fasen.

  In veel opzichten weerspiegelt deze sterke afhankelijkheid van Kafka de manier waarop de MapReduce-engine vaak naar HDFS verwijst. Hoewel het verwijzen naar HDFS tussen elke berekening leidt tot ernstige prestatieproblemen bij batchverwerking, lost het een aantal problemen op bij streamverwerking.

  Samza's sterke relatie met Kafka zorgt ervoor dat de verwerkingsstappen zelf heel losjes met elkaar verbonden zijn. Een willekeurig aantal abonnees kan worden toegevoegd aan de uitvoer van elke stap zonder voorafgaande coördinatie. Dit kan erg handig zijn voor organisaties waar meerdere teams mogelijk toegang moeten hebben tot vergelijkbare gegevens. Teams kunnen zich allemaal abonneren op het onderwerp van gegevens die het systeem binnenkomen, of ze kunnen zich gemakkelijk abonneren op onderwerpen die zijn gemaakt door andere teams die enige verwerking hebben ondergaan. Dit kan worden gedaan zonder extra belasting toe te voegen aan belastinggevoelige infrastructuur zoals databases.

  Rechtstreeks schrijven naar Kafka elimineert ook de problemen van tegendruk. Tegendruk is wanneer pieken in de belasting een instroom van gegevens veroorzaken met een snelheid die groter is dan de componenten in realtime kunnen verwerken, wat leidt tot vertragingen in de verwerking en mogelijk gegevensverlies. Kafka is ontworpen om gegevens zeer lang vast te houden, wat betekent dat componenten naar eigen goeddunken kunnen worden verwerkt en zonder gevolgen opnieuw kunnen worden opgestart.

  Samza kan de status opslaan met behulp van een fouttolerant controlepuntsysteem dat is geïmplementeerd als een lokale sleutel-waardeopslag. Hierdoor kan Samza een leveringsgarantie van ten minste één keer bieden, maar biedt het geen nauwkeurig herstel van de geaggregeerde status (zoals tellingen) in het geval van een storing, aangezien gegevens mogelijk meer dan eens worden afgeleverd.

  Samza biedt abstracties van hoog niveau die in veel opzichten gemakkelijker zijn om mee te werken dan de primitieven die worden geboden door systemen zoals Storm. Samza ondersteunt momenteel alleen JVM-talen, wat betekent dat het niet dezelfde taalflexibiliteit heeft als Storm.

  Samenvatting

  Apache Samza is een goede keuze voor het streamen van workloads waarbij Hadoop en Kafka al beschikbaar zijn of verstandig zijn om te implementeren. Samza zelf past goed bij organisaties met meerdere teams die datastromen gebruiken (maar niet noodzakelijkerwijs strak coördineren) in verschillende stadia van verwerking. Samza vereenvoudigt veel delen van streamverwerking aanzienlijk en biedt prestaties met lage latentie. Het past misschien niet goed als de implementatievereisten niet compatibel zijn met uw huidige systeem, als u verwerking met extreem lage latentie nodig heeft of als u sterke behoefte heeft aan exact-eenmalige semantiek.

  Hybride verwerkingssystemen: batch- en streamprocessors

  Sommige verwerkingsframeworks kunnen zowel batch- als stream-workloads aan. Deze frameworks vereenvoudigen verschillende verwerkingsvereisten door toe te staan dat dezelfde of gerelateerde componenten en API's voor beide soorten gegevens worden gebruikt.

  Zoals je zult zien, varieert de manier waarop dit wordt bereikt aanzienlijk tussen Spark en Flink, de twee frameworks die we zullen bespreken. Dit is grotendeels een functie van hoe de twee verwerkingsparadigma's bij elkaar worden gebracht en welke aannames worden gedaan over de relatie tussen vaste en niet-vaste datasets.

  Hoewel projecten gericht op één verwerkingstype nauw aansluiten bij specifieke use-cases, proberen de hybride frameworks een algemene oplossing te bieden voor gegevensverwerking. Ze bieden niet alleen methoden voor het verwerken van gegevens, ze hebben hun eigen integraties, bibliotheken en tools voor bijvoorbeeld grafiekanalyse, machine learning en interactieve query's.

  Apache vonk

  Apache Spark is een framework voor batchverwerking van de volgende generatie met mogelijkheden voor streamverwerking. Spark is gebouwd met veel van dezelfde principes van de MapReduce-engine van Hadoop en richt zich voornamelijk op het versnellen van batchverwerkingsworkloads door volledige in-memory berekeningen en verwerkingsoptimalisatie aan te bieden.

  Spark kan worden ingezet als een op zichzelf staand cluster (indien gecombineerd met een capabele opslaglaag) of kan worden gekoppeld aan Hadoop als alternatief voor de MapReduce-engine.

  Batchverwerkingsmodel

  In tegenstelling tot MapReduce verwerkt Spark alle gegevens in het geheugen en communiceert het alleen met de opslaglaag om de gegevens in eerste instantie in het geheugen te laden en aan het eind om de uiteindelijke resultaten vast te houden. Alle tussenresultaten worden in het geheugen beheerd.

  Hoewel verwerking in het geheugen substantieel bijdraagt aan de snelheid, is Spark ook sneller bij schijfgerelateerde taken vanwege holistische optimalisatie die kan worden bereikt door de volledige set taken van tevoren te analyseren. Het bereikt dit door Directed Acyclic Graphs, of DAG's te maken die alle bewerkingen vertegenwoordigen die moeten worden uitgevoerd, de gegevens waarop moet worden gewerkt, evenals de relaties daartussen, waardoor de processor meer mogelijkheden krijgt werk intelligent te coördineren.

  Om in-memory batchberekening te implementeren, gebruikt Spark een model met de naam Resilient Distributed Datasets, of RDD's, om met gegevens te werken. Dit zijn onveranderlijke structuren die in het geheugen bestaan en verzamelingen gegevens vertegenwoordigen. Bewerkingen op RDD's produceren nieuwe RDD's. Elke RDD kan zijn afstamming terugvoeren via zijn ouder-RDD's en uiteindelijk naar de gegevens op de schijf. In wezen zijn RDD's een manier voor Spark om fouttolerantie te behouden zonder na elke bewerking terug te hoeven schrijven naar de schijf.

  Stroomverwerkingsmodel

  Streamverwerkingsmogelijkheden worden geleverd door Spark Streaming. Spark zelf is ontworpen met het oog op batchgeoriënteerde workloads. Om de ongelijkheid tussen het motorontwerp en de kenmerken van streaming-workloads aan te pakken, implementeert Spark een concept genaamd micro-batches*. Deze strategie is ontworpen om gegevensstromen te behandelen als een reeks zeer kleine batches die kunnen worden verwerkt met behulp van de native semantiek van de batch-engine.

  Spark Streaming werkt door de stream in stappen van minder dan een seconde te bufferen. Deze worden verzonden als kleine vaste datasets voor batchverwerking. In de praktijk werkt dit redelijk goed, maar het leidt wel tot een ander prestatieprofiel dan echte stream processing frameworks.

  Voordelen en beperkingen

  De voor de hand liggende reden om Spark te gebruiken in plaats van Hadoop MapReduce is snelheid. Spark kan dezelfde datasets aanzienlijk sneller verwerken dankzij de in-memory berekeningsstrategie en de geavanceerde DAG-planning.

  Een ander groot voordeel van Spark is de veelzijdigheid. Het kan worden ingezet als een zelfstandig cluster of worden geïntegreerd met een bestaand Hadoop-cluster. Het kan zowel batch- als streamverwerking uitvoeren, waardoor u één cluster kunt gebruiken om meerdere verwerkingsstijlen te verwerken.

  Naast de mogelijkheden van de engine zelf, heeft Spark ook een ecosysteem van bibliotheken die kunnen worden gebruikt voor machine learning, interactieve query's, enz. Vrijwel algemeen wordt erkend dat Spark-taken gemakkelijker te schrijven zijn dan MapReduce, wat aanzienlijke gevolgen kan hebben voor de productiviteit.

  Het aanpassen van de batchmethodologie voor stroomverwerking omvat het bufferen van de gegevens wanneer deze het systeem binnenkomen. Dankzij de buffer kan het een groot aantal inkomende gegevens verwerken, waardoor de algehele doorvoer toeneemt, maar wachten om de buffer leeg te maken leidt ook tot een aanzienlijke toename van de latentie. Dit betekent dat Spark Streaming mogelijk niet geschikt is voor verwerking waarbij een lage latentie noodzakelijk is.

  Aangezien RAM over het algemeen duurder is dan schijfruimte, kan het draaien van Spark meer kosten dan op schijven gebaseerde systemen. De verhoogde verwerkingssnelheid betekent echter dat taken veel sneller kunnen worden voltooid, wat de kosten volledig kan compenseren wanneer u werkt in een omgeving waar u per uur voor resources betaalt.

  Een ander gevolg van het in-memory ontwerp van Spark is dat schaarste aan bronnen een probleem kan zijn bij inzet op gedeelde clusters. In vergelijking met Hadoop's MapReduce gebruikt Spark aanzienlijk meer bronnen, wat andere taken die op dat moment mogelijk het cluster proberen te gebruiken, kan verstoren. In wezen is Spark misschien een minder attente buur dan andere componenten die op de Hadoop-stack kunnen werken.

  Samenvatting

  Spark is een geweldige optie voor mensen met uiteenlopende verwerkingstaken. Spark-batchverwerking biedt ongelooflijke snelheidsvoordelen, in ruil voor een hoog geheugengebruik. Spark Streaming is een goede oplossing voor het verwerken van streams voor werklasten waarbij doorvoer belangrijker is dan latentie.

  Apache Flink

  Apache Flink is een raamwerk voor streamverwerking dat ook batchtaken aankan. Het beschouwt batches eenvoudigweg als gegevensstromen met eindige grenzen, en behandelt batchverwerking dus als een subset van stroomverwerking. Deze stream-first-benadering van alle verwerking heeft een aantal interessante neveneffecten.

  Deze stream-first benadering wordt de Kappa-architectuur genoemd, in tegenstelling tot de meer algemeen bekende Lambda-architectuur (waar batching wordt gebruikt als de primaire verwerkingsmethode met streams die worden gebruikt om vroege maar ongeraffineerde resultaten aan te vullen en te leveren) . Kappa-architectuur, waar streams voor alles worden gebruikt, vereenvoudigt het model en is pas sinds kort mogelijk omdat stream processing-engines steeds geavanceerder zijn geworden.

  Stroomverwerkingsmodel

  Het stroomverwerkingsmodel van Flink behandelt inkomende gegevens item voor item als een echte stream. Flink biedt zijn DataStream API om te werken met onbeperkte gegevensstromen. De basiscomponenten waar Flink mee werkt zijn:

  • Streams zijn onveranderlijke, onbegrensde datasets die door het systeem stromen
  • Operators zijn functies die op gegevensstromen werken om andere stromen te produceren
  • Bronnen zijn het toegangspunt voor streams die het systeem binnenkomen
  • Sinks zijn de plaatsen waar stromen uit het Flink-systeem stromen. Ze kunnen een database of een connector naar een ander systeem vertegenwoordigen.

  Stroomverwerkingstaken maken snapshots op ingestelde punten tijdens hun berekening om te gebruiken voor herstel in geval van problemen. Voor het opslaan van de status kan Flink werken met een aantal backends van de status, afhankelijk van verschillende niveaus van complexiteit en persistentie.

  Bovendien kan de streamverwerking van Flink het concept van \gebeurtenistijd begrijpen, wat betekent dat het tijdstip waarop de gebeurtenis daadwerkelijk plaatsvond, en kan het ook sessies afhandelen. Dit betekent dat het op een aantal interessante manieren ordening en groepering kan garanderen.

  Batchverwerkingsmodel

  Het batchverwerkingsmodel van Flink is in veel opzichten slechts een uitbreiding van het stroomverwerkingsmodel. In plaats van te lezen uit een continue stroom, leest het een begrensde dataset weg van persistente opslag als een stroom. Flink gebruikt exact dezelfde runtime voor beide verwerkingsmodellen.

  Flink biedt enkele optimalisaties voor batch-workloads. Omdat batchbewerkingen bijvoorbeeld worden ondersteund door permanente opslag, verwijdert Flink momentopnamen van batchladingen. Gegevens kunnen nog steeds worden hersteld, maar de normale verwerking is sneller voltooid.

  Een andere optimalisatie omvat het opsplitsen van batchtaken, zodat fasen en componenten alleen worden gebruikt wanneer dat nodig is. Dit helpt Flink goed te spelen met andere gebruikers van het cluster. Preventieve analyse van de taken geeft Flink de mogelijkheid om ook te optimaliseren door de volledige set bewerkingen, de omvang van de dataset en de vereisten van de komende stappen te bekijken.

  Voordelen en beperkingen

  Flink is momenteel een unieke optie in de wereld van verwerkingsframeworks. Hoewel Spark batch- en streamverwerking uitvoert, is de streaming ervan niet geschikt voor veel gebruiksscenario's vanwege de microbatch-architectuur. De stream-first-benadering van Flink biedt lage latentie, hoge doorvoer en echte entry-by-entry verwerking.

  Flink regelt veel zelf. Enigszins onconventioneel beheert het zijn eigen geheugen in plaats van te vertrouwen op de native Java-garbagecollection-mechanismen om prestatieredenen. In tegenstelling tot Spark vereist Flink geen handmatige optimalisatie en aanpassing wanneer de kenmerken van de gegevens die het verwerkt veranderen. Het zorgt ook automatisch voor gegevenspartitionering en caching.

  Flink analyseert zijn werk en optimaliseert taken op een aantal manieren. Een deel van deze analyse is vergelijkbaar met wat SQL-queryplanners doen binnen relatiedatabases, waarbij ze de meest effectieve manier in kaart brengen om een bepaalde taak uit te voeren. Het is in staat om stadia parallel te lopen die parallel kunnen worden voltooid, terwijl gegevens worden samengebracht voor blokkerende taken. Voor iteratieve taken probeert Flink om prestatieredenen berekeningen uit te voeren op de knooppunten waar de gegevens zijn opgeslagen. Het kan ook \delta iteratie doen, of iteratie op alleen de delen van de gegevens die wijzigingen hebben.

  Wat betreft gebruikerstooling biedt Flink een webgebaseerde planningsweergave om eenvoudig taken te beheren en het systeem te bekijken. Gebruikers kunnen ook het optimalisatieplan voor ingediende taken weergeven om te zien hoe het daadwerkelijk op het cluster wordt geïmplementeerd. Voor analysetaken biedt Flink query's in SQL-stijl, grafische verwerking en machine learning-bibliotheken, en in-memory berekeningen.

  Flink werkt goed met andere componenten. Het is geschreven om een goede buur te zijn als het wordt gebruikt in een Hadoop-stack, waarbij het op elk moment alleen de benodigde bronnen in beslag neemt. Het kan eenvoudig worden geïntegreerd met YARN, HDFS en Kafka. Flink kan taken uitvoeren die zijn geschreven voor andere verwerkingsframeworks zoals Hadoop en Storm met compatibiliteitspakketten.

  Een van de grootste nadelen van Flink op dit moment is dat het nog een heel jong project is. Grootschalige implementaties in het wild zijn nog steeds niet zo gewoon als andere verwerkingsframeworks en er is niet veel onderzoek gedaan naar de schaalbeperkingen van Flink. Met de snelle ontwikkelingscyclus en functies zoals de compatibiliteitspakketten, kunnen er meer Flink-implementaties komen naarmate organisaties de kans krijgen om ermee te experimenteren.

  Samenvatting

  Flink biedt zowel streamverwerking met lage latentie als ondersteuning voor traditionele batchtaken. Flink is waarschijnlijk het meest geschikt voor organisaties die zware stroomverwerkingsvereisten hebben en een aantal batchgeoriënteerde taken. De compatibiliteit met native Storm- en Hadoop-programma's en de mogelijkheid om op een door YARN beheerd cluster te draaien, maken het gemakkelijk om te evalueren. De snelle ontwikkeling maakt het de moeite waard om in de gaten te houden.

  Conclusie

  Er zijn volop mogelijkheden voor verwerking binnen een big data systeem.

  Voor batch-only workloads die niet tijdgevoelig zijn, is Hadoop een goede keuze die waarschijnlijk goedkoper te implementeren is dan sommige andere oplossingen.

  Voor alleen stream-workloads heeft Storm brede taalondersteuning en kan verwerking met zeer lage latentie leveren, maar kan duplicaten leveren en kan de volgorde in de standaardconfiguratie niet garanderen. Samza integreert nauw met YARN en Kafka om flexibiliteit, eenvoudig gebruik door meerdere teams en eenvoudig replicatie- en statusbeheer te bieden.

  Voor gemengde workloads biedt Spark snelle batchverwerking en microbatchverwerking voor streaming. Het heeft brede ondersteuning, geïntegreerde bibliotheken en tooling, en flexibele integraties. Flink biedt echte streamverwerking met ondersteuning voor batchverwerking. Het is sterk geoptimaliseerd, kan taken uitvoeren die voor andere platforms zijn geschreven en biedt verwerking met lage latentie, maar bevindt zich nog in de begindagen van acceptatie.

  Wat het beste bij uw situatie past, hangt sterk af van de staat van de te verwerken gegevens, hoe tijdgebonden uw vereisten zijn en in wat voor soort resultaten u geïnteresseerd bent. Er zijn afwegingen tussen het implementeren van een alles-in-één oplossing en werken met strak gefocuste projecten, en er zijn vergelijkbare overwegingen bij het evalueren van nieuwe en innovatieve oplossingen ten opzichte van hun volwassen en goed geteste tegenhangers.