Big Data Processing Engines - Welke gebruik ik?:Deel 1

Deze blogpost is gepubliceerd op Hortonworks.com vóór de fusie met Cloudera. Sommige links, bronnen of verwijzingen zijn mogelijk niet langer nauwkeurig.

Speciale dank aan Bill Preachuk en Brandon Wilson voor het beoordelen en leveren van hun expertise

Inleiding

Opslag in kolommen is een veelbesproken onderwerp in de wereld van de verwerking en opslag van big data tegenwoordig - er zijn honderden formaten, structuren en optimalisaties waarin u uw gegevens kunt opslaan en zelfs meer manieren om deze op te halen, afhankelijk van wat u van plan bent te doen ermee. Deze overvloed aan opties kwam tot stand vanwege de noodzaak om niet alleen snel gegevens op te nemen met behulp van On-Line Transactional Processing (OLTP)-tools, maar ook vanwege de noodzaak om gegevens efficiënter te consumeren en te analyseren met behulp van On-Line Analytical Processing (OLAP) gereedschap. Duizenden verschillende use-cases hebben elk hun eigen specifieke behoeften en dus zijn er veel opties opgedoken. Het lezen van beurstickergegevens vereist bijvoorbeeld een heel andere mentaliteit dan het analyseren van kwaliteitsstatistieken in een productielijn. Met al deze keuzes kun je gemakkelijk verdwalen bij het navigeren naar je einddoel:een tool kiezen die voor jou werkt.

HDP bevat een aantal opslagoplossingen, die elk op maat zijn gemaakt voor specifieke gebruikssituaties. We willen deze blogreeks beginnen door te praten over de volgende drie tools/engines en de bijbehorende opslagformaten:

• Apache Hive gebruikt Apache ORC als een efficiënte kolomvormige opslagindeling die prestaties mogelijk maakt voor zowel OLAP- als diepe SQL-queryverwerking
• Apache Phoenix/Apache HBase vormen samen een OLTP-database die realtime query's over miljarden records mogelijk maakt en snelle willekeurige op sleutels gebaseerde zoekopdrachten en updates biedt
• Apache Druid is een hoogwaardige gegevensopslag die realtime tijdreeksanalyse mogelijk maakt van gebeurtenisstromen en OLAP-analyse over historische gegevens met extreem lage latentie

In dit artikel willen we duidelijk maken welke tool geschikt is voor een bepaalde use case, de verschillende tools vergelijken en contrasteren, en een basisrichtlijn geven voor het kiezen van de juiste tool of set tools voor uw use case.

Dit lijkt veel op het spelen van Tetris - elk stuk heeft een andere niche, maar ze voegen elk een unieke waarde toe aan de grotere structuur

Big data-verwerking en zijn overeenkomsten

Gegevens zijn gegroepeerd op kolommen in de opslag, omdat we vaak proberen sommen, gemiddelden of andere berekeningen voor een specifieke kolom te beperken. Stelt u zich eens voor dat u een luchtvaartmaatschappij bent die probeert te begrijpen hoeveel brandstof een vliegtuig moet geven wanneer het is aangemeerd. Misschien wilt u het gemiddelde aantal afgelegde kilometers per vlucht berekenen uit een tabel met vluchtgegevens. Hiervoor zou de gemiddelde functie op een enkele kolom moeten worden uitgevoerd. We zouden deze gegevens in kolomformaat opslaan omdat sequentiële leesbewerkingen op schijf snel zijn, en wat we in dit geval willen doen, is één volledige kolom opeenvolgend uit de tabel lezen (en dan een gemiddelde berekening uitvoeren).

Er zijn veel verschillen tussen deze engines, maar welke dataverwerkingsengine u ook kiest, u profiteert van een aantal overeenkomsten. Een daarvan is de gedeelde functie van caching. Elk van deze drie engines werkt hand in hand met in-memory caching om de verwerkingsprestaties te verbeteren zonder het backend-opslagformaat te wijzigen, waardoor responstijden van minder dan een seconde worden bereikt. HBase heeft de BlockCache, Hive heeft de LLAP IO-laag en Druid heeft verschillende in-memory caching-opties. Vaak is het dure deel van het afhandelen van een query het ontleden van het verzoek en het gaan naar de permanente opslag om de subset van gegevens op te halen waarin de gebruiker is geïnteresseerd. Die hele stap kan echter worden vermeden wanneer een in-memory caching-mechanisme wordt gebruikt, omdat zoveel kolomvormige opslagformaten gebruiken, waardoor het proces in een fractie van een seconde in het geheugen kan reiken naar eerder opgevraagde gegevens. Laten we teruggaan naar ons voorbeeld van brandstofberekening:stel dat ik zojuist heb gevraagd naar het gemiddelde aantal gevlogen mijlen voor alle vluchten in mijn bedrijf, maar besef dat voor binnenlandse vluchten veel andere brandstofvereisten gelden dan voor internationale vluchten. Ik wil dan mijn vorige zoekopdracht filteren met een WHERE country='US' (of gelijkwaardige landcode) clausule. Dit querypatroon is heel gebruikelijk voor gegevensverkenning. Omdat we de gegevens van de vorige query al in het geheugen hebben, kunnen de resultaten van deze query worden geretourneerd zonder dat er een dure schijflezing hoeft te worden uitgevoerd.

De structuur van Hive's LLAP-laag - een deel van de geheugenruimte wordt gebruikt voor caching, terwijl opslag op lange termijn op HDFS staat. HBase en Druid hebben ook een soortgelijk concept van cache en opslag.

Een andere overeenkomst bestaat in de snelkoppelingen die elk van deze motoren gebruikt om in te zoomen op de specifieke gegevens die worden opgevraagd. HBase heeft op HashMap gebaseerde O(1) willekeurige toegang, Druid gebruikt omgekeerde bitmapindexen om uit te zoeken welke kolomwaarden in welke rijen staan, en Hive-tabellen hebben statistieken, indexen en partitionering om snel toegang tot gegevens te krijgen. Deze functies stellen de engines in staat om de manier waarop gegevens worden opgeslagen te combineren met de manier waarop ze worden benaderd, waardoor snelle analyses mogelijk zijn, terwijl de efficiëntie van de hardware wordt geoptimaliseerd en het maximale uit de beschikbare CPU en RAM wordt gehaald.

De laatste overeenkomst is de bedrijfsgereedheid van elk van deze motoren. Aan de kant van de gegevensredundantie gebruiken alle drie deze engines HDFS als hun diepe opslagmechanisme; de HDFS-replicatiefactor van 3x zorgt ervoor dat kopieën van de gegevens elders bestaan, zelfs als twee knooppunten tegelijkertijd uitvallen. De gegevens kunnen onmiddellijk opnieuw worden gerepliceerd naar gezonde knooppunten om de redundantie te behouden. Wat betreft fouttolerantie binnen een cluster, elk gereedschap vult de leemte op de een of andere manier op. HBase biedt regio-replicatie, Druid heeft duplicatie van master- en worker-componenten en een verhoogde replicatiefactor op HDFS, en Hive heeft HDFS naast de fouttolerante logica van het YARN-framework. Bedrijfsgereedheid zorgt ervoor dat deze motoren bestand zijn tegen storingen en vanaf dag één klaar zijn om in productie te gaan.

De verschillen tussen onze Big Data Processing Engines

Wat is de beste manier om gegevens op te nemen? Hoe haal je er snel inzichten uit als je eenmaal je data hebt verwerkt? Laten we eens kijken hoe deze drie grote gegevensverwerkingsengines deze reeks gegevensverwerkingstaken ondersteunen

Deze engines zijn soms mentaal gebundeld en er wordt op dezelfde manier over nagedacht vanwege hun vermogen om Big Data op te slaan en te verwerken, maar zoals we zullen ontdekken, zijn ze gekozen voor gebruiksscenario's en doeleinden die specifiek geschikt zijn voor hun sterke punten. U zult zien dat de verzameling tools die het Hortonworks Data Platform bevat, zeer geschikt is voor elke big data-workload die u eraan kunt geven, vooral met HDP 3.0 en de realtime databasemogelijkheden die we hebben geïntroduceerd.

Hive is de OLAP-engine die representatief is voor de meest uiteenlopende gebruiksscenario's, waarbij meestal het Hadoop Distributed File System (HDFS) als opslaglaag wordt gebruikt om de opslag van vrijwel elk type gegevens mogelijk te maken. Het kan ongestructureerde tekstgegevens, CSV-bestanden, XML, semi-gestructureerde JSON, zuilvormig Parquet en tal van andere formaten opvragen, verwerken en analyseren. Hive ondersteunt ook alternatieve opslagmedia zoals cloudopslag, Isilon en andere. De de facto opslagstandaard voor Hive is ORC, die het meest efficiënt optimaliseert en de voordelen plukt van kolomvormige opslag. Eenmaal geconverteerd naar ORC worden uw gegevens gecomprimeerd en worden de kolommen in uw tabel achtereenvolgens op schijf opgeslagen, waardoor Hive's in-memory caching-laag LLAP de gegevens één keer van schijf kan halen en meerdere keren uit het geheugen kan serveren. De combinatie van Hive+LLAP wordt gebruikt voor ad-hocanalyse, het berekenen van grote aggregaten en rapportage met lage latentie. Een geweldige use-case voor Hive is het dagelijks uitvoeren van een reeks dashboardrapporten voor gebruikers; de repetitieve zoekopdrachten profiteren niet alleen van de LLAP-cache, maar ook van de functie 'Query Results Cache' - die vrijwel onmiddellijke resultaten oplevert als de gegevens niet zijn gewijzigd (terzijde:de cache met queryresultaten is een functie die beschikbaar is in Hive 3.0 - uitgebracht in HDP 3.0). Daarnaast is een Hive Data Warehouse een geweldig gebruik van de ad-hoc analyses waar Hive toe in staat is; gebruikers kunnen gegevens samenvoegen, gelijktijdige query's uitvoeren en ACID-transacties uitvoeren. Beschouw Hive in dat opzicht als een alleskunner voor SQL, terwijl de andere twee engines extreem snelle prestaties leveren voor specifieke nichegebruikssituaties.

Onze tweede engine, HBase, is een gedistribueerde sleutelwaardeopslag met willekeurige lees-, schrijf-, update- en verwijdermogelijkheden. HBase (een NoSQL-variant) is ontworpen als een OLTP-engine, die een architectuur van transactieverwerkingen met een hoog volume mogelijk maakt, denk aan berichtenplatforms waarbij voortdurend berichten worden uitgewisseld tussen gebruikers of transacties die worden gegenereerd in een financieel systeem. HBase is uiterst efficiënt in het snel binnenhalen van gegevens, het opslaan en weer uitserveren - willekeurige inserts/updates/deletes met ultralage latentie. Waar het niet voor is ontworpen, is het aggregeren en samenvoegen van gegevens - deze functionaliteit wordt bereikt via Phoenix, een SQL-laag en -engine bovenop HBase, maar wordt niet aanbevolen voor grotere hoeveelheden gegevens, omdat de gegevens niet zo zijn gestructureerd dat ze optimaal zijn prestaties (gebruik in plaats daarvan Hive). Samenvattend:HBase is geweldig in het verwerken van grote hoeveelheden Create-Update-Delete-bewerkingen, maar schiet tekort als het tijd is om die gegevens in een verbruiksformaat voor gebruikers te presenteren.

Ten slotte is Druid de derde engine en een die geschikt is voor OLAP-tijdreeksworkloads met lage latentie en voor realtime indexering van streaminggegevens. Druid biedt OLAP-query's met kubussnelheid voor uw cluster. Het tijdreekskarakter van Druid is een hoeksteen van de motor; het is op deze manier ontworpen omdat tijd een primair filter is wanneer op tijd gebaseerde gegevens worden geanalyseerd. Denk er eens over na wanneer u vluchttijden analyseert om een ​​reis te boeken - ik wil de goedkoopste vlucht naar Italië weten binnen deze specifieke periode van 2 weken. Druid past in de niche van het zeer snel opnemen van gegevens en het lokaliseren ervan wanneer daarom wordt gevraagd. Aan de andere kant kunnen zakelijke gebruikers en analisten de gegevens opvragen en begrijpen via Superset, een visualisatielaag die nauw verbonden is met Druid. Druid blinkt uit in het lokaliseren van een handvol rijen gegevens tussen honderden miljoenen of miljarden in minder dan een seconde, en het blinkt ook uit in het extreem snel berekenen van geaggregeerde waarden over diezelfde hoeveelheid gegevens. Het doet echter geen joins en kan daarom niet worden gebruikt voor het combineren van datasets voor analyse. Als je van plan bent om een ​​combinatie van datasets in Druid te analyseren, is het verstandig om de gegevens vooraf te joinen voordat je ze in Druid invoegt of Hive (en door Druid ondersteunde Hive-tabellen) te gebruiken om joins uit te voeren. Met andere woorden, Druid past goed in de rol van de laatste stop voor uw gegevens nadat deze zijn verwerkt en getransformeerd in hoe uw zakelijke gebruikers er toegang toe zullen krijgen. Druid is geweldig voor bedrijfsanalisten omdat ze kunnen inloggen op Superset en statistieken in dashboardvorm kunnen visualiseren zonder dat ze vragen hoeven te schrijven; ze gebruiken gewoon een GUI om de querygegevensbron en filters te selecteren. Het is ook geweldig als ondersteunende gegevensbron voor systeemdashboards, zowel operationeel als analytisch, vanwege de snelle querytijden.

Hier is een manier waarop u de besluitvorming kunt uitsplitsen over welke tool u voor uw werklast moet gebruiken:

Verenigde SQL

We hebben tot nu toe meerdere systemen besproken en ze hebben elk hun eigen manieren om toegang te krijgen tot hun gegevens. Dit is geweldig als uw gebruikers weten hoe al deze tools werken, maar ze kunnen een leercurve doormaken voordat ze volledige productiviteit kunnen bereiken als ze afkomstig zijn uit een wereld van SQL, SQL en meer SQL, zoals de meeste analisten doen. Daarom hebben we geprobeerd deze interactie zo eenvoudig mogelijk te maken; met Hive 3.0 in HDP 3.0 kun je Hive's SQL-achtige HQL-syntaxis gebruiken om te communiceren met zoveel verschillende datastores in deze ruimte. Hive kan worden gebruikt als een portaal voor toegang tot en wijziging van Druid, HBase en alles dat een JDBC-interface en -stuurprogramma biedt. Hive kan worden gebruikt om een ​​druïde-opnametaak te beheren die naar Kafka luistert, wat een eenvoudige manier biedt voor realtime opname. En tot slot kan Hive worden gebruikt om alles bij elkaar te brengen:sla uw gegevens op waar dat het meest logisch is en open ze vanaf één plek. Voeg het samen, misschien sla je dat nieuwe resultaat zelfs op een andere locatie op. De mogelijkheden zijn talrijk, maar de interface is aanzienlijk vereenvoudigd, zodat uw gebruikers minder tijd kunnen besteden aan het leren van een andere tool en meer tijd kunnen besteden aan het toevoegen van waarde aan het bedrijf.

Conclusie

Hive, Druid en HBase hebben allemaal verschillende plaatsen in een data-architectuur, zoals we uit de vorige analyse hebben gezien. Het zijn echter aanvullende instrumenten; je zou transactiegegevens kunnen opnemen met HBase met zijn snelle zoekacties, die gegevens naar Druid kunnen verplaatsen voor snel inzoomen / aggregeren, en Hive de twee kunnen laten integreren samen met zijn eigen door Hive beheerde gegevens zodat gebruikers gegevens kunnen combineren waar deze zich ook bevinden voor één blik en een schat aan inzichten. Met deze aanpak slaat Druid gegevens op die op zichzelf toegankelijk zijn, maar die functionaliteit wordt uitgebreid door Hive, die Druid-gegevens kan binnenhalen en die kan combineren met aanvullende gegevens. Voeg hieraan de belangrijkste verbeteringen toe die met Hive 3.0 in het spel zijn gekomen, waaronder gematerialiseerde weergaven, verbeterde integraties met Druid en vele andere engines, en verhoogde datawarehouse-achtige functionaliteit, en je hebt een groep van tools die zowat elke use case kunnen oplossen.

Architecturen zoals de bovengenoemde brengen het beste van elke tool naar voren om uw workflow te optimaliseren en tegelijkertijd de details weg te nemen voor die gebruikers die zich alleen met de gegevens bezighouden. De architecten zetten de pijplijnen op en zetten de data waar ze thuishoren op basis van de use case. Dat leidt vervolgens naar de data-analisten, die Hive als hun enige interface gebruiken om kennis en inzichten op te doen. Ze kunnen interessante patronen in de gegevens vinden in plaats van zich zorgen te maken over waar de gegevens zijn opgeslagen of een nieuwe syntaxis te leren om er toegang toe te krijgen - het zou je verbazen hoe vaak we dit in de wereld zien.

Op dit punt hebben we de sterke en zwakke punten en best practices van elke tool gedemonstreerd; we hopen dat je naar huis gaat met een beter begrip van wat waar past, evenals het grotere geheel van het combineren van alle drie om de beste resultaten te krijgen.