Big Data Processing Engines – Vilken ska jag använda?:Del 1

Det här blogginlägget publicerades på Hortonworks.com före sammanslagningen med Cloudera. Vissa länkar, resurser eller referenser kanske inte längre är korrekta.

Särskilt tack till Bill Preachuk och Brandon Wilson för att de granskat och tillhandahållit sin expertis

Introduktion

Kolumnlagring är ett ofta diskuterat ämne i den stora databearbetnings- och lagringsvärlden idag – det finns hundratals format, strukturer och optimeringar där du kan lagra din data och ännu fler sätt att hämta den beroende på vad du planerar att göra med det. Denna uppsjö av alternativ kom till på grund av behovet av att inte bara ta in data snabbt med hjälp av On-Line Transactional Processing (OLTP)-verktyg, utan också på grund av behovet av att konsumera och analysera data med större effektivitet med On-Line Analytical Processing (OLAP) verktyg. Tusentals olika användningsfall har var och en sina egna specifika behov och därför har många alternativ dykt upp. Att till exempel läsa börsinformation kräver ett helt annat tankesätt än att analysera kvalitetsmått i en tillverkningslinje. Med alla dessa val är det lätt att gå vilse när du navigerar till ditt slutmål:att välja ett verktyg som fungerar för dig.

HDP innehåller ett antal lagringslösningar, som var och en är skräddarsydd för specifika användningsfall. Vi vill börja den här bloggserien med att prata om följande tre verktyg/motorer och deras tillhörande lagringsformat:

• Apache Hive använder Apache ORC som ett effektivt kolumnformat lagringsformat som möjliggör  prestanda för både OLAP och djup SQL-frågebehandling
• Apache Phoenix/Apache HBase bildar tillsammans en OLTP-databas som möjliggör realtidsfrågor över miljarder poster och erbjuder snabba slumpmässiga nyckelbaserade uppslagningar samt uppdateringar
• Apache Druid är ett högpresterande datalager som möjliggör tidsserieanalys i realtid av händelseströmmar och OLAP-analys över historisk data med extremt låg latens

I den här artikeln har vi för avsikt att formulera vilket verktyg som är lämpligt för ett visst användningsfall, jämföra och kontrastera de olika verktygen och ge en grundläggande riktlinje för att välja rätt verktyg eller uppsättning verktyg för att hantera ditt användningsfall.

Det här är ungefär som att spela Tetris – varje pjäs har sin egen nisch men var och en tillför ett unikt värde till den större strukturen

Big Data Processing och dess likheter

Data grupperas efter kolumner i lagring eftersom vi ofta försöker begränsa summor, medelvärden eller andra beräkningar på en specifik kolumn. Föreställ dig att du är ett flygbolag som försöker förstå hur mycket bränsle som ska ge ett plan när det är dockat – du kanske vill beräkna genomsnittliga mil som flygs av varje flyg från en tabell med flygresorsdata. Detta skulle kräva att den genomsnittliga funktionen utfördes på en enda kolumn. Vi skulle lagra dessa data i kolumnformat eftersom sekventiell läsning på disk är snabb, och vad vi vill göra i det här fallet är att läsa en hel kolumn från tabellen sekventiellt (och sedan utföra en genomsnittlig beräkning).

Det finns många skillnader mellan dessa motorer men oavsett vilken databehandlingsmotor du väljer kommer du att dra nytta av ett par gemensamma drag. En av dessa är den delade funktionen för cachelagring. Var och en av dessa tre motorer arbetar hand i hand med cachelagring i minnet för att förbättra prestanda för dess bearbetning utan att ändra backend-lagringsformatet, vilket ger svarstider på under sekunder. HBase har BlockCache, Hive har LLAP IO-lagret och Druid har flera alternativ för cachning i minnet. Ofta innebär den dyra delen av att betjäna en fråga att analysera begäran och gå till beständig lagring för att hämta den delmängd av data som användaren är intresserad av. Hela det steget kan dock undvikas när man använder en mekanism för cachning i minnet eftersom många kolumnära lagringsformat använda, vilket gör att processen kan nå in i minnet för tidigare efterfrågade data på bråkdelar av en sekund. Låt oss gå tillbaka till vårt bränsleberäkningsexempel:säg att jag just har bett om genomsnittliga mil flugna för alla flygningar på mitt företag, men inser att inrikesflyg kommer att ha bränslekrav som är mycket annorlunda än internationella flygningar. Jag vill sedan filtrera min tidigare fråga med en WHERE country=’US’ (eller motsvarande landskod) klausul. Detta frågemönster är mycket vanligt för datautforskning. Eftersom vi redan har den föregående frågans data i minnet, kan resultaten av denna fråga returneras utan att behöva utföra en dyr diskläsning.

Strukturen för Hives LLAP-lager – en del av dess minnesutrymme används för cachning, medan långtidslagring är på HDFS. HBase och Druid har också ett liknande koncept för cache och lagring.

En annan likhet finns i genvägarna som var och en av dessa motorer använder för att nollställa de specifika data som efterfrågas. HBase har HashMap-baserad O(1) slumpmässig åtkomst, Druid använder inverterade bitmappsindex för att ta reda på vilka kolumnvärden som finns i vilka rader, och Hive-tabeller har statistik, index och partitionering för genvägsdataåtkomst. Dessa funktioner gör det möjligt för motorerna att kombinera hur data lagras med hur de nås, vilket möjliggör snabba analyser samtidigt som de optimerar effektiviteten hos hårdvaran och får ut det mesta av processorn och RAM-minnet.

Den sista likheten är företagsberedskapen hos var och en av dessa motorer. På dataredundanssidan använder alla dessa tre motorer HDFS som sin djuplagringsmekanism; HDFS-replikeringsfaktorn på 3x säkerställer att kopior av data finns någon annanstans även om två noder misslyckas samtidigt. Data kan omedelbart replikeras igen till friska noder för att upprätthålla redundans. När det gäller feltolerans inom ett kluster, fyller varje verktyg luckan på något sätt. HBase erbjuder regionreplikering, Druid har duplicering av master- och arbetarkomponenter samt ökad replikeringsfaktor på HDFS, och Hive har HDFS tillsammans med YARN-ramverkets feltoleranta logik. Företagsberedskap säkerställer att dessa motorer är motståndskraftiga mot fel och redo att prestera i produktion från dag ett.

Skillnaderna mellan våra Big Data Processing Engines

Vilket är det bästa sättet att få in data? När du har fått in din data, hur tar du snabbt fram insikter ur den? Låt oss dyka in i hur dessa tre stora databearbetningsmotorer stöder denna uppsättning databearbetningsuppgifter

Dessa motorer är ibland mentalt samlade och tänkte på liknande sätt på grund av deras förmåga att lagra och bearbeta Big Data, men som vi kommer att ta reda på är de valda för användningsfall och ändamål som är specifikt anpassade till deras styrkor. Du kommer att se att samlingen av verktyg som Hortonworks Data Platform innehåller är väl lämpad för alla stora data-arbetsbelastningar du kan lägga på den, särskilt med HDP 3.0 och realtidsdatabasfunktionerna som vi har introducerat.

Hive är OLAP-motorn som är representativ för den största bredd av användningsfall, som oftast använder Hadoop Distributed File System (HDFS) som lagringslager för att tillåta lagring av nästan alla typer av data. Den kan fråga, bearbeta och analysera ostrukturerad textdata, CSV-filer, XML, semi-strukturerad JSON, kolumnartad parkett och en mängd andra format. Hive stöder också alternativa lagringsmedier som molnlagring, Isilon och andra. De facto lagringsstandarden för Hive är ORC, som optimerar mest effektivt och skördar fördelarna med pelarlagring. När de har konverterats till ORC komprimeras dina data och kolumnerna i din tabell lagras sekventiellt på disken, vilket gör att Hives minnescachinglager LLAP kan hämta data från disken en gång och servera den från minnet flera gånger. Kombinationen av Hive+LLAP används för ad-hoc-analys, beräkning av stora aggregat och rapportering med låg latens. Ett bra användningsfall för Hive är att köra en uppsättning instrumentpanelsrapporter för användare dagligen; de upprepade frågorna drar inte bara nytta av LLAP-cachen, utan också funktionen 'Query Results Cache' – som returnerar nästan omedelbara resultat om data inte har ändrats (Aside:Query Result cache är en funktion tillgänglig i Hive 3.0 – släppt i HDP 3.0). Utöver det är ett Hive Data Warehouse en stor användning av den ad-hoc-analys som Hive kan; användare kan sammanfoga data, köra samtidiga frågor och köra ACID-transaktioner. Betrakta Hive som ett absolut bästa SQL i det avseendet, medan de andra två motorerna ger extremt snabba prestanda för specifika nischade användningsfall.

Vår andra motor, HBase, är ett distribuerat nyckel-värdelager som har slumpmässiga läs-, skriv-, uppdaterings- och raderingsmöjligheter. HBase (en NoSQL-variant) är designad för att vara en OLTP-motor, som möjliggör en arkitektur av transaktionsoperationer med stora volymer – tänk på meddelandeplattformar med konstanta meddelanden som utbyts mellan användare eller att transaktioner genereras i ett finanssystem. HBase är extremt effektiv på att snabbt ta in data, lagra den och skicka ut den igen – slumpmässiga infogar/uppdateringar/borttagningar med ultralåg latens. Vad den inte är designad för är att aggregera och sammanfoga data – den här funktionen åstadkoms genom Phoenix, ett SQL-lager och motor ovanpå HBase, men rekommenderas inte för större datamängder eftersom data inte är strukturerade på ett sätt för att uppnå optimala prestanda (använd Hive istället). För att sammanfatta det, HBase är bra på att bearbeta stora volymer av Skapa-Uppdatera-Ta bort-operationer, men kommer till korta när det är dags att presentera denna data i ett förbrukningsbart format för användarna.

Slutligen är Druid den tredje motorn och en som lämpar sig för OLAP-tidsseriearbetsbelastningar med låg latens samt realtidsindexering av strömmande data. Druid tillhandahåller OLAP-förfrågningar i kubhastighet för ditt kluster. Druidens tidsseriekaraktär är en hörnsten i motorn; den är utformad på detta sätt eftersom tid är ett primärt filter när tidsbaserad data analyseras. Tänk på när du analyserar flygtider för att boka en resa – jag vill veta det billigaste flyget till Italien inom just denna 2-veckors tidsram. Druid passar nischen att vara mycket snabb att ta in data samt hitta den när den efterfrågas. Å andra sidan tillåter det också affärsanvändare och analytiker att fråga efter data och förstå dem genom Superset, ett visualiseringslager nära knutet till Druid. Druid utmärker sig i att lokalisera en handfull rader med data bland hundratals miljoner eller miljarder på under en sekund, och den utmärker sig också i att beräkna aggregerade värden över samma datavolym extremt snabbt. Den gör dock inte kopplingar och kan därför inte användas för att kombinera datamängder för analys. Om du planerar att analysera en kombination av datauppsättningar i Druid, skulle du göra klokt i att föransluta data innan du infogar den i Druid eller använda Hive (och Druid-stödda Hive-tabeller) för att utföra joins. Sagt med andra ord, Druid passar väl in i rollen att vara det sista stoppet för din data efter att den har bearbetats och omvandlats till hur dina företagsanvändare kommer att få tillgång till den. Druid är bra för affärsanalytiker eftersom de kan logga in på Superset och visualisera mätvärden i instrumentpanelsform utan att behöva skriva några frågor; de använder helt enkelt ett GUI för att välja frågedatakällan och filtren. Det är också bra som en stöddatakälla för systeminstrumentpaneler, oavsett om det är operativt eller analytiskt, på grund av dess snabba frågetider.

Här är ett sätt du kan bryta ner beslutsfattandet om vilket verktyg du ska använda för din arbetsbelastning:

Unified SQL

Vi har diskuterat flera system fram till denna punkt och de har var och en sina egna sätt att komma åt sin data. Det här är bra när dina användare vet hur alla dessa verktyg fungerar, men de kan ha en inlärningskurva innan de kan nå full produktivitet om de kommer från en värld av SQL, SQL och mer SQL som de flesta analytiker gör. Det är därför vi har försökt göra denna interaktion så enkel som möjligt; med Hive 3.0 i HDP 3.0 kan du använda Hives SQL-liknande HQL-syntax för att interagera med så många olika datalager i detta utrymme. Hive kan användas som en portal för att komma åt och modifiera Druid, HBase och allt som tillhandahåller ett JDBC-gränssnitt och en drivrutin. Hive kan användas för att administrera en Druid-intagsuppgift som lyssnar på Kafka, vilket ger en enkel väg till realtidsintag. Och slutligen kan Hive användas för att sammanföra allt – lagra din data där det är mest meningsfullt och få tillgång till det från ett ställe. Slå ihop det, kanske till och med lagra det nya resultatet på en annan plats. Möjligheterna är många, men gränssnittet har förenklats avsevärt så att din användarbas kan lägga mindre tid på att lära sig ett annat verktyg och mer tid på att skapa värde för verksamheten.

Slutsats

Hive, Druid och HBase har alla olika platser i en dataarkitektur som vi har sett från den tidigare analysen. De är dock kompletterande verktyg; du kan mata in transaktionsdata med HBase med dess snabba uppslagningar, flytta dessa data till Druid för snabb drill-down/aggregering, och låta Hive integrera de två tillsammans med sin egen Hive-hanterade data för att tillåta användare att kombinera data varhelst den finns för en enda vy och en mängd insikter. Med detta tillvägagångssätt lagrar Druid data som kan nås på egen hand, men den funktionen utökas av Hive, som kan dra in Druid-data och förena den med ytterligare data. Lägg till detta de stora förbättringarna som har kommit i spel med Hive 3.0, inte minst av vilka är materialiserade vyer, förbättrade integrationer med Druid såväl som många andra motorer och ökad datalagerliknande funktionalitet, och du har en grupp verktyg som kan lösa nästan alla användningsfall.

Arkitekturer som de ovan nämnda tar in det bästa från varje verktyg för att optimera ditt arbetsflöde och samtidigt abstrahera bort detaljerna för de användare som bara är intresserade av data. Arkitekterna satte upp pipelines och placerade data där den hör hemma baserat på användningsfallet. Det leder sedan till dataanalytikerna, som använder Hive som sitt enda gränssnitt för att få kunskap och insikter. De kan hitta intressanta mönster i data snarare än att oroa sig för var data lagras eller lära sig en ny syntax för att komma åt det – du skulle bli förvånad över att ta reda på hur ofta vi ser detta ute i världen.

Vid det här laget har vi visat varje verktygs styrkor, svagheter och bästa praxis; vi hoppas att du kommer därifrån med en bättre förståelse för vad som passar var samt den större bilden av att kombinera alla tre för att få bästa resultat.