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.
Computere bliver klogere, og det er vi ikke.
–Tim Berners Lee, webudvikler
Google, Amazon og Netflix har betinget os. Som forbrugere forventer vi intelligente applikationer, der forudsiger, foreslår og forudser alle vores bevægelser. Vi ønsker, at de skal gennemsøge de millioner af muligheder og foreslå nogle få, der passer til vores behov. Vi vil have applikationer, der tager os med på en personlig rejse gennem en verden af uendelige muligheder.
Disse personlige rejser kræver, at systemer lagrer og giver mening i enorme datamængder på en acceptabel tid. Dette har været Hadoops stærke side siden dag ét.
At levere rejsen kræver også, at applikationer integreres direkte med dyb analyse. Dette er fortsat en udfordring, da de fleste driftssystemer kører uden for Hadoop og placerer driftsdata og analyser i separate siloer.
Teknologier som Apache Hadoop YARN og Apache Slider begynder at nedbryde disse siloer. YARN giver Hadoop ressourceisoleringskontroller, der gør det muligt dybt at analysere applikationsdata på stedet og samtidig give svar inden for en acceptabel tidsramme. Og Apache Slider gør det nemt at implementere langvarige driftssystemer i Hadoop.
YARN er det arkitektoniske center for Hadoop, der gør det muligt for flere databehandlingsmotorer såsom interaktiv SQL, realtidsstreaming, datavidenskab og batchbehandling at håndtere data, der er gemt på en enkelt platform, hvilket åbner op for en helt ny tilgang til analyse. Dette giver en problemfri integration af operationelle og analytiske systemer og et grundlag, som virksomheden kan bygge en moderne dataarkitektur (MDA) på.
State of the Art i Hadoop
Det er muligt at blande operationel og analytisk sammen i Hadoop i dag, og faktisk ser vi mange af vores kunder gøre det.
De stykker, du skal bruge, er allerede i Hadoop:
- Apache HBase er NoSQL-databasen til Hadoop og er fantastisk til hurtige opdateringer og dataadgang med lav latenstid.
- Apache Phoenix (udviklet af Salesforce) er et SQL-skin til data i HBase. Phoenix undersøger allerede integration med transaktionsadministratorer som Tephra (fra Cask).
- Apache Hive er de-facto SQL-motoren til Hadoop, der leverer den dybeste SQL-analyse og understøtter både batch- og interaktive forespørgselsmønstre. Se vores seneste Stinger.Next-indlæg for fremskridt såsom Hive LLAP.
Vi ser vores kunder bruge disse dele i dag til at bygge applikationer med dyb analyse, f.eks. inkluderer et meget almindeligt mønster, vi ser:
- Brug af HBase som online driftsdatalager til hurtige opdateringer af varme data, såsom aktuelle partition for timen, dagen osv.
- Udførelse af operationelle forespørgsler direkte mod HBase ved hjælp af Apache Phoenix.
- Aldning af data i HBase til Hive-tabeller ved hjælp af standard ETL-mønstre.
- Udførelse af dyb SQL-analyse ved hjælp af Hive
Dette virker, men det skaber en række kompleksiteter for udviklere. For eksempel:
- Hvilken SQL-grænseflade bruger jeg og hvornår? Bruger jeg Hive, som tilbyder dyb SQL, men lav TPS? Eller bruger jeg Phoenix med høj TPS og grundlæggende SQL? Eller bruger jeg begge dele?
- Hvis jeg bruger begge, hvordan deler jeg data mellem Hive og HBase?
- Hvordan tuner jeg min klynge, så jeg med succes kan lokalisere HBase og Hive, mens jeg opfylder mine SLA'er?
Disse spørgsmål tyder på, at der er behov for dybere integration for at forenkle bygning af applikationer med dyb analyse på Hadoop.
HBase og Hive:Bedre sammen
Hvilke muligheder er der for dybere integration? I øjeblikket er kunder ved at sammensætte løsninger, der udnytter HBase, Phoenix, Hive osv. til at bygge skræddersyet et lukket sløjfesystem til driftsdata og SQL-analyse. Vi føler, at der er en mulighed for at give out-of-the-box integration med brugervenlighed og yderligere funktioner såsom transaktioner, cross datacenter failover osv.
Hive, HBase og Phoenix har alle et meget aktivt fællesskab af udviklere og bruges i produktionen i utallige organisationer. Disse er solide, dokumenterede operationelle egenskaber, der kan være grundlaget og fremtiden for transaktionsbehandling på Hadoop.
Så ved at bruge den samme tilgang som det succesfulde Stinger Initiative, søger Hortonworks at investere yderligere i disse kerneprojekter og skabe momentum i stedet for at opgive dem og starte forfra. Vi planlægger at investere i forbedringer, der fremmer en integreret operationel og analytisk oplevelse via en tæt integreret Hive og HBase. Dette adresserer reelle og interessante use cases på en måde, der bevarer investeringer og skaber reel værdi for kunderne.
Vi ser fire store udviklingsområder for at hjælpe med at realisere visionen om intelligente applikationer:
1. Et samlet SQL-lag med Hive
Udviklere, der bygger SQL-applikationer, bør ikke skulle vælge mellem forskellige SQL-løsninger, hver med sine egne styrker og svagheder. Vi forestiller os et samlet SQL-lag, aktiveret af Hives understøttelse af SQL:2011, som transparent bruger den passende motor baseret på forespørgselsadgangsmønsteret.
Denne kombination giver en enkelt SQL-dialekt og en enkelt forbindelse. Dataarkitekter og DBA'er kan bestemme, hvor data skal lagres baseret på brugsmønstre uden at belaste brugerapplikationer med behovet for at oprette forbindelse til flere systemer.
2. Forbedring af HBase som en operationel butik
HBase modnes hurtigt som en operationel butik og vil være i stand til at løfte mere og mere krævende arbejdsbyrder. I det seneste år har HBase tilføjet en SQL-grænseflade, sekundær indeksering og høj tilgængelighed. Disse funktioner vil fortsætte med at modnes, og derudover vil HBase tilføje yderligere funktioner i virksomhedskvalitet såsom multi-table, transaktioner på tværs af datacenter og mere.
Projekter som Omid (Yahoo), Tephra (
3. Delt metadatakatalog og transaktionsadministrator
Data oprettet i HBase bør automatisk være synlige i Hive og omvendt. Denne evne gør datadeling mellem online og analytisk fuldstændig triviel. En delt transaktionsadministrator gør det muligt for Hives nye ACID-funktion og multi-table HBase-transaktioner at arbejde problemfrit sammen.
4. GARN-aktiveret Mixed Workload Support
I dag implementerer kunder typisk HBase og Hive i separate klynger. Udvikling af et analysesystem med lukket kredsløb kræver en effektiv kombination af operationelle og analytiske arbejdsbelastninger på en måde med flere lejere. Med YARN kan vi effektivt skabe et enkelt-system ved at udnytte ressourceisolering og arbejdsbelastningsstyrings primitiver i YARN til at understøtte forskellige former for adgang til data. Slider gør brug af disse, når den implementerer HBase i YARN, mens Hive LLAP &Tez er native YARN-applikationer, og derved forenkler processen med at køre et analytisk system med lukket sløjfe i henhold til en forudsigelig SLA.
Konklusion
Virksomheder bruger allerede eksisterende teknologier, der er tilgængelige i HDP, såsom Apache HBase, Apache Hive, Apache Phoenix osv. til at håndtere hurtige opdateringer til aktuelle data og analyser over en bred vifte af datasæt, alle lagret i HDFS for at udføre et lukket-loop analysesystem . Vi håber at kunne udnytte de samme integrationsmønstre til at give kunderne en problemfri oplevelse ved at gøre Apache HBase og Apache Hive bedre – bedre sammen, snarere end nye teknologier, som brugerne kan forstå og forbruge.
