Big Data Processing Engines – Hvilken skal jeg bruge?:Del 1

Dette blogindlæg blev offentliggjort på Hortonworks.com før fusionen med Cloudera. Nogle links, ressourcer eller referencer er muligvis ikke længere nøjagtige.

Særlig tak til Bill Preachuk og Brandon Wilson for at anmelde og levere deres ekspertise

Introduktion

Søjlelagring er et ofte diskuteret emne i big data-behandling og -lagringsverdenen i dag - der er hundredvis af formater, strukturer og optimeringer, som du kan gemme dine data på og endnu flere måder at hente dem på, afhængigt af hvad du planlægger at gøre med det. Denne overflod af muligheder opstod på grund af behovet for ikke kun at indtage data hurtigt ved hjælp af On-Line Transactional Processing (OLTP) værktøjer, men også på grund af behovet for at forbruge og analysere data med større effektivitet ved hjælp af On-Line Analytical Processing (OLAP) værktøjer. Tusindvis af forskellige use cases har hver deres specifikke behov, og derfor er der dukket mange muligheder op. For eksempel kræver læsning af aktiemarkeds-ticker-data en helt anden tankegang end at analysere kvalitetsmålinger i en produktionslinje. Med alle disse valg er det nemt at gå tabt, når du navigerer til dit slutmål:at vælge et værktøj, der fungerer for dig.

HDP inkorporerer en række opbevaringsløsninger, som hver især er skræddersyet til specifikke anvendelsestilfælde. Vi vil starte denne blogserie med at tale om følgende tre værktøjer/motorer og deres tilhørende lagerformater:

• Apache Hive bruger Apache ORC som et effektivt søjleformet lagerformat, der muliggør  ydelse til både OLAP og dyb SQL-forespørgselsbehandling
• Apache Phoenix/Apache HBase danner tilsammen en OLTP-database, der muliggør realtidsforespørgsler over milliarder af poster og tilbyder hurtige tilfældige nøglebaserede opslag samt opdateringer
• Apache Druid er et højtydende datalager, der muliggør tidsserieanalyse i realtid på hændelsesstrømme og OLAP-analyser over historiske data med ekstremt lav latenstid

I denne artikel har vi til hensigt at formulere, hvilket værktøj der er passende til en given use case, sammenligne og sammenligne de forskellige værktøjer og give en grundlæggende guideline til at vælge det passende værktøj eller sæt værktøjer til at håndtere din use case.

Det er meget som at spille Tetris – hvert stykke har sin egen niche, men de tilføjer hver især unik værdi til den større struktur

Big Data Processing og dens ligheder

Data er grupperet efter kolonner i lager, fordi vi ofte forsøger at indsnævre summer, gennemsnit eller andre beregninger på en specifik kolonne. Forestil dig, at du er et flyselskab, der prøver at forstå, hvor meget brændstof et fly skal give, når det er forankret – du vil måske beregne gennemsnittet for hver flyvning fra en tabel med flyrejsedata. Dette ville kræve at udføre gennemsnitsfunktionen på en enkelt kolonne. Vi ville gemme disse data i kolonneformat, fordi sekventielle læsninger på disken er hurtige, og det, vi ønsker at gøre i dette tilfælde, er at læse en hel kolonne fra tabellen sekventielt (og derefter udføre en gennemsnitsberegning).

Der er mange forskelle mellem disse motorer, men uanset hvilken databehandlingsmotor du vælger, vil du drage fordel af et par fællestræk. En af dem er den delte funktion ved cachelagring. Hver af disse tre motorer arbejder hånd i hånd med caching i hukommelsen for at øge ydeevnen af ​​dens behandling uden at ændre backend-lagerformatet, hvilket opnår svartider på under sekunder. HBase har BlockCache, Hive har LLAP IO-laget, og Druid har flere muligheder for cachelagring i hukommelsen. Ofte involverer den dyre del af servicering af en forespørgsel at analysere anmodningen og gå til persistent lager for at hente den delmængde af data, som brugeren er interesseret i. Hele dette trin kan dog undgås, når du bruger en caching-mekanisme i hukommelsen, da mange søjleformede lagringsformater bruge, så processen kan nå ind i hukommelsen efter tidligere forespurgte data på brøkdele af et sekund. Lad os gå tilbage til vores brændstofberegningseksempel:lad os sige, at jeg lige har bedt om de gennemsnitlige fløjede miles for alle flyvninger hos mit selskab, men indse, at indenrigsflyvninger vil have brændstofbehov, der er meget anderledes end internationale flyvninger. Jeg vil derefter filtrere min tidligere forespørgsel med en WHERE country='US' (eller tilsvarende landekode) klausul. Dette forespørgselsmønster er meget almindeligt for dataudforskning. Da vi allerede har den tidligere forespørgsels data i hukommelsen, kan resultaterne af denne forespørgsel returneres uden at skulle udføre en dyr disklæsning.

Strukturen af ​​Hives LLAP-lag – en del af dets hukommelsesplads bruges til caching, mens langtidslagring er på HDFS. HBase og Druid har også et lignende koncept for cache og lagring.

En anden lighed findes i de genveje, som hver af disse motorer bruger til at nulstille de specifikke data, der forespørges. HBase har HashMap-baseret O(1) tilfældig adgang, Druid bruger inverterede bitmap-indekser til at finde ud af, hvilke kolonneværdier der er i hvilke rækker, og Hive-tabeller har statistik, indekser og partitionering for at genveje dataadgang. Disse funktioner gør det muligt for motorerne at kombinere den måde, data lagres på, med den måde, de tilgås på, hvilket muliggør hurtige analyser, samtidig med at effektiviteten af ​​hardwaren optimeres og den tilgængelige CPU og RAM udnyttes bedst muligt.

Den sidste lighed er virksomhedens parathed for hver af disse motorer. På dataredundanssiden bruger alle disse tre motorer HDFS som deres dybe lagringsmekanisme; HDFS-replikeringsfaktoren på 3x sikrer, at kopier af data findes andre steder, selvom to noder fejler samtidigt. Dataene kan straks re-replikeres igen til sunde noder for at opretholde redundans. Med hensyn til fejltolerance inden for en klynge udfylder hvert værktøj hullet på en eller anden måde. HBase tilbyder regionsreplikering, Druid har duplikering af master- og arbejderkomponenter samt øget replikeringsfaktor på HDFS, og Hive har HDFS sammen med YARN-frameworkens fejltolerante logik. Virksomhedsberedskab sikrer, at disse motorer er modstandsdygtige over for fejl og klar til at fungere i produktionen fra dag ét.

Forskellene mellem vores Big Data Processing Engines

Hvad er den bedste måde at indtage data på? Når du har indtaget dine data, hvordan trækker du så hurtigt indsigt ud af dem? Lad os dykke ned i, hvordan disse tre store databehandlingsmotorer understøtter dette sæt af databehandlingsopgaver

Disse motorer er nogle gange mentalt bundet sammen og tænkt på lignende måde på grund af deres evne til at gemme såvel som at behandle Big Data, men som vi vil finde ud af, er de udvalgt til brugstilfælde og formål, der er specifikt tilpasset deres styrker. Du vil se, at samlingen af ​​værktøjer, som Hortonworks-dataplatformen indeholder, er velegnet til enhver big data-arbejdsbyrde, du kan kaste på den, især med HDP 3.0 og de realtidsdatabasefunktioner, vi har introduceret.

Hive er OLAP-motoren, der er repræsentativ for den største bredde af brugssager, som oftest anvender Hadoop Distributed File System (HDFS) som lagringslag for at tillade lagring af næsten enhver type data. Det kan forespørge, behandle og analysere ustrukturerede tekstdata, CSV-filer, XML, semi-struktureret JSON, columnar Parket og en lang række andre formater. Hive understøtter også alternative lagringsmedier såsom Cloud storage, Isilon og andre. De facto-lagringsstandarden for Hive er ORC, som optimerer mest effektivt og høster fordelene ved søjleopbevaring. Når de er konverteret til ORC, komprimeres dine data, og kolonnerne i din tabel gemmes sekventielt på disken, hvilket gør det muligt for Hives in-memory cachelag LLAP at trække dataene fra disken én gang og tjene dem fra hukommelsen flere gange. Kombinationen af ​​Hive+LLAP bruges til ad hoc-analyse, beregning af store aggregater og rapportering med lav latens. Et godt eksempel på Hive er at køre et sæt dashboard-rapporter til brugere dagligt; de gentagne forespørgsler udnytter ikke kun LLAP-cachen, men også funktionen 'Query Results Cache' – som returnerer næsten øjeblikkelige resultater, hvis dataene ikke er ændret (bortset fra:Query Result cache er en funktion tilgængelig i Hive 3.0 – udgivet i HDP 3.0). Sideløbende med det er et Hive Data Warehouse en stor brug af den ad-hoc analyse, Hive er i stand til; brugere kan sammenføje data, køre samtidige forespørgsler og køre ACID-transaktioner. Betragt Hive for at være en SQL jack of all trades i den henseende, mens de to andre motorer giver ekstremt hurtig ydeevne til specifikke nichebrugssager.

Vores anden motor, HBase, er et distribueret nøgleværdilager, der har tilfældige læse-, skrive-, opdaterings- og slettefunktioner. HBase (en NoSQL-variant) er designet til at være en OLTP-motor, der muliggør en arkitektur af store transaktionsoperationer – tænk på meddelelsesplatforme med konstante beskeder, der udveksles mellem brugere, eller transaktioner, der genereres i et finanssystem. HBase er ekstremt effektiv til at bringe data hurtigt ind, gemme dem og servere dem igen – tilfældige indsættelser/opdateringer/sletninger med ultralav latenstid. Det, det ikke er designet til, er at aggregere og sammenføje data – denne funktionalitet opnås gennem Phoenix, et SQL-lag og en motor oven på HBase, men anbefales ikke til større mængder data, da dataene ikke er struktureret på en måde, der opnår optimal ydeevne (brug Hive i stedet). For at opsummere det, så er HBase fantastisk til at behandle store mængder af Opret-Opdater-Slet-operationer, men kommer til kort, når det er tid til at præsentere disse data i et forbrugsvenligt format for brugerne.

Endelig er Druid den tredje motor og en egnet til OLAP-tidsseriearbejdsbelastninger med lav latens samt realtidsindeksering af streamingdata. Druid leverer OLAP-forespørgsler med terninghastighed til din klynge. Druidens tidsseriekarakter er en hjørnesten i motoren; det er designet på denne måde, fordi tid er et primært filter, når tidsbaserede data analyseres. Tænk på, når du analyserer flytider for at bestille en rejse – jeg vil gerne vide den billigste flyrejse til Italien inden for denne særlige 2-ugers tidsramme. Druid passer til nichen med at være meget hurtig til at indtage data samt lokalisere dem, når de bliver bedt om det. På den anden side giver det også forretningsbrugere og analytikere mulighed for at forespørge dataene og forstå dem gennem Superset, et visualiseringslag tæt forbundet med Druid. Druid udmærker sig ved at udpege en håndfuld rækker af data blandt hundredvis af millioner eller milliarder på under et sekund, og den udmærker sig også ved at beregne aggregerede værdier over den samme mængde data ekstremt hurtigt. Det gør dog ikke joins og kan derfor ikke bruges til at kombinere datasæt til analyse. Hvis du planlægger at analysere en kombination af datasæt i Druid, vil du gøre klogt i at forudføje dataene, før du indsætter dem i Druid eller bruge Hive (og Druid-støttede Hive-tabeller) til at udføre joins. Sagt med andre ord, så passer Druid godt ind i rollen som sidste stop for dine data, efter at de er blevet behandlet og transformeret til, hvordan dine forretningsbrugere vil få adgang til dem. Druid er fantastisk til forretningsanalytikere, da de kan logge på Superset og visualisere metrics i dashboardform uden at skulle skrive nogen forespørgsler; de bruger simpelthen en GUI til at vælge forespørgselsdatakilden og filtrene. Det er også fantastisk som en understøttende datakilde til systemdashboards, uanset om det er operationelt eller analytisk, på grund af dets hurtige forespørgselstider.

Her er en måde, hvorpå du kan nedbryde beslutningstagningen om, hvilket værktøj du skal bruge til din arbejdsbyrde:

Unified SQL

Vi har diskuteret flere systemer indtil dette punkt, og de har hver deres måde at få adgang til deres data på. Dette er fantastisk, når dine brugere ved, hvordan alle disse værktøjer fungerer, men de kan have en læringskurve, før de kan nå fuld produktivitet, hvis de kommer fra en verden af ​​SQL, SQL og mere SQL, som de fleste analytikere gør. Det er derfor, vi har forsøgt at gøre denne interaktion så enkel som muligt; med Hive 3.0 i HDP 3.0 kan du bruge Hives SQL-lignende HQL-syntaks til at interagere med så mange forskellige datalagre i dette rum. Hive kan bruges som en portal til at få adgang til og ændre Druid, HBase og alt, der giver en JDBC-grænseflade og driver. Hive kan bruges til at administrere en Druid-indtagelsesopgave, der lytter til Kafka, hvilket giver en enkel vej til indtagelse i realtid. Og endelig kan Hive bruges til at samle det hele – gem dine data, hvor det giver mest mening, og få adgang til dem fra ét sted. Slå det sammen, gem måske endda det nye resultat et andet sted. Mulighederne er mange, men grænsefladen er blevet meget forenklet, så din brugerbase kan bruge mindre tid på at lære et andet værktøj og mere tid på at skabe værdi til virksomheden.

Konklusion

Hive, Druid og HBase har alle forskellige steder i en dataarkitektur, som vi har set fra den tidligere analyse. De er dog komplementære værktøjer; du kan indtage transaktionsdata med HBase med dets hurtige opslag, flytte disse data ind i Druid for hurtig drill-down/aggregering og få Hive til at integrere de to sammen med sine egne Hive-administrerede data for at give brugerne mulighed for at kombinere data, uanset hvor de befinder sig. en enkelt udsigt og et væld af indsigter. Med denne tilgang gemmer Druid data, der kan tilgås på egen hånd, men denne funktionalitet er forstærket af Hive, som kan trække Druid-data og forbinde dem med yderligere data. Tilføj hertil de store forbedringer, der er kommet i spil med Hive 3.0, ikke mindst af hvilke er materialiserede visninger, forbedrede integrationer med Druid såvel som mange andre motorer og øget datavarehus-lignende funktionalitet, og du har en gruppe af værktøjer, der kan løse stort set enhver use case.

Arkitekturer som de førnævnte bringer det bedste ind fra hvert værktøj for at optimere dit arbejdsflow og samtidig abstrahere detaljerne for de brugere, der kun er beskæftiget med dataene. Arkitekterne sætter rørledningerne op og sætter dataene, hvor de hører hjemme, baseret på use casen. Det fører så til dataanalytikerne, der bruger Hive som deres enkelt interface til at få viden og indsigt. De er i stand til at finde interessante mønstre i dataene i stedet for at bekymre sig om, hvor dataene er gemt eller lære en ny syntaks for at få adgang til dem – du vil blive overrasket over at finde ud af, hvor ofte vi ser dette ude i verden.

På dette tidspunkt har vi demonstreret hvert værktøjs styrker, svagheder og bedste praksis; vi håber, du går derfra med en bedre forståelse af, hvad der passer hvor, samt det større billede af at kombinere alle tre for at få de bedste resultater.