Orsakerna till att människor migrerar för att Gnista. Bild: Databricks
Hadoop och MapReduce, parallell programmering paradigm och API ursprungligen bakom Hadoop, som används för att vara synonymt. Idag när vi talar om Hadoop, vi främst att tala om ett ekosystem av verktyg byggda runt den gemensamma filsystemet lager av HDFS, och programmeras via Gnista.
Gnista är den nya Hadoop. En av de utmärkande tendenser i denna tid, som bekräftades av både praktiker inom området och undersökningar, är den en masse flytta till Gnista för Hadoop användare. Gnista är själv ett ekosystem av olika slag, som erbjuder alternativ för SQL-baserad åtkomst till data, streaming, och maskininlärning.
Människor migrerar för att Gnista för ett antal orsaker, bland annat med enklare programmering paradigm. Enklare än MapReduce inte nödvändigtvis lätt men, och det finns ett antal gotchas vid programmering och driftsättning Gnista program.
Problemet med Gnista och vad man kan göra åt det
Så varför människor migrerar för att Gnista? Den främsta anledningen verkar vara resultat: 91 procent av 1615 människor från över 900 organisationer som deltar i Databricks Apache Gnista Undersökning 2016 ovan som deras skäl för att använda Gnista. Men det finns mer. Avancerade analyser och enkel programmering är nästan lika viktigt, som citeras av 82 procent och 76 procent av de tillfrågade.
Alla källor vi har talat med under de senaste månaderna pekar i samma riktning: programmering mot Spark ‘ s API är lättare än att använda MapReduce, så MapReduce ses som ett arv API på denna punkt. Leverantörer kommer att fortsätta att erbjuda stöd för det så länge det finns kunder som använder det, men praktiskt taget alla nya utveckling är Spark-baserade.
Inte alla som använder Gnista har samma ansvar eller kompetens. Bild: Databricks
Som Aska Munshi, Pepperdata VD uttrycker det: “Spark erbjuder en enhetlig ram och SQL-åtkomst, vilket innebär att du kan göra avancerade analyser, och det är där de stora pengarna finns. Plus att det är lättare att programmera: ger dig en fin abstraction layer, så att du inte behöver oroa dig för alla de uppgifter som du har att hantera när man arbetar med MapReduce. Programmering på högre nivå innebär att det är lättare för folk att förstå ned och smutsiga detaljer och för att distribuera sina appar.”
Bra. Vad är problemet då? Munshi påpekar att den andra sidan av Gnista abstraktion, speciellt när man kör i Hadoop GARN miljö som inte gör det alltför lätt att extrahera metadata är att en stor del av genomförandet detaljerna är dolda. Detta innebär att det är svårt att sätta fingret på vilka rader av kod få någonting att hända i detta komplexa distribuerade system, och det är också svårt att ställa prestanda.
Med komplexa distribuerade system i vilket program körs betyder också att du måste vara medveten om inte bara din egen programmets genomförande och resultat, men också i bredare utförande miljö. Pepperdata kallar kluster vädret problem: behovet av att veta i vilket sammanhang ett program körs. Ett vanligt problem i kluster utbyggnad till exempel finns en inkonsekvens i kör gånger på grund av övergående arbetsbelastning.
Data för Forskare att få automation: tuning Gnista kluster
Pepperdata är inte den enda som har noterat. Ett par månader tillbaka Alpina Data också satt fingret på samma fråga, om än med en något annorlunda inramning. Alpina Data pekade på det faktum att Gnista är extremt känslig för hur jobben är konfigurerad och resurser, kräver data för forskare att ha en djup förståelse för både Gnista och konfiguration och användning av Hadoop kluster används.
Underlåtenhet att korrekt resurs Gnista jobb kommer ofta att leda till fel på grund av att minnet är fel, vilket leder till ineffektiva och tidskrävande, trial-and-error resurser experiment. Detta krav avsevärt begränsar nyttan av Gnistan och påverkar dess användning utanför djupt kunnig data forskare, enligt Alpina Data.
Detta är baserat på surt förvärvade erfarenheter, som Alpin Data co-founder & CPO Steven Hillion förklaras. Vid något tillfälle en av Alpina Data: s kunder var med Alpina Data Vetenskap plattform (ADSP) för att göra några mycket stor skala bearbetning på konsumenternas data: miljarder rader och tusentals variabler. ADSP använder Gnista under huven för data knaprande jobb, men problemet var att dessa jobb skulle antingen ta en evighet eller bryta.
Anledningen var att trimma av Gnista parametrar i klustret var inte rätt. Människor med hjälp av ADSP i så fall var data forskare, inte data ingenjörer. De var skickliga i att hitta rätt modeller för att bearbeta data och utvinna insikter ur dem, men inte nödvändigtvis för att utveckla och sprida dem i stor skala.
Resultatet var att data forskare skulle få på telefonen med ADSP tekniker för att hjälpa dem att diagnostisera problem och föreslå konfigurationer. Detta skulle naturligtvis inte skala, Alpina Data kom upp med idén om att bygga logiken ingenjörer som tillämpas i denna process i ADSP. Alpina Data säger att det fungerade, som möjliggör för kunder att skapa arbetsflöden inom några dagar och distribuera dem i timmar utan att några manuella ingrepp.
Så nästa steg var att kombinera detta som en del av ADSP och börja levereras den, som Alpin Labs gjorde under Hösten 2016. Detta presenterades i Spark Toppmötet Öster 2017, och Hillion säger responsen har varit “nästan överväldigande. I Boston hade vi en lång rad av människor som kommer för att fråga om detta”.
Hillion betonade att deras tillvägagångssätt är formella, som inte bygger på ML. Detta kan låta konstigt, med tanke på deras ML kompetens. Alpina Labs men säger att detta inte är en statisk konfiguration, men fungerar genom att bestämma den korrekta resurser och konfiguration för den Gnista jobb vid run-time är baserat på storleken och djupet av indata, komplexiteten i den Gnista jobb, och tillgången på resurser på Hadoop-kluster.
“Du kan se det som en form av ekvationen som om du kommer att, på ett förenklat sätt, som uttrycker hur vi finjustera parametrar”, säger Hillion. “Ställa in dessa parametrar kommer genom erfarenhet, så på ett sätt vi utbildning-modell med hjälp av våra egna data. Jag skulle inte kalla det maskininlärning, men sedan igen, vi lär oss något från maskiner.”
Data Ingenjörer få automation: analysera Gnista program
Pepperdata nu också erbjuder en lösning för Spark automation med förra veckans utgåva av Pepperdata Code Analyzer för Apache Gnista (PCAAS), men ta itu med en annan publik med en annan strategi. Uppgifter som forskare gör för 23 procent av alla Gnista användare, men data ingenjörer och arkitekter tillsammans göra för en summa av 63 procent av alla Gnista användare. Detta är publiken Pepperdata syftar till att med PCAAS.
Arkitekter är människor som designar (big data) system och data ingenjörer är de som arbetar med data för forskare att ta sina analyser till produktion. Munshi säger PCAAS syftar till att ge dem möjlighet att ta kör Spark program, analysera dem för att se vad som är på gång och sedan knyta tillbaka till specifika rader kod.
De tänker att det är att genom att kunna förstå mer om CPU-användning, sophämtning eller I/O som är relaterade till deras applikationer, ingenjörer och arkitekter ska kunna optimera applikationer. PCAAS har möjlighet att göra en del av felsökning, genom att isolera misstänkta block av kod och föranledde ingenjörer att titta in i dem.
PCAAS syftar till att hjälpa dechiffrera kluster väder också, vilket gör det möjligt att förstå om körning inkonsekvenser bör hänföras till en specifik ansökan eller att arbetsbördan vid tidpunkten för genomförandet. Munshi påpekar också det faktum att GARN tungt använder statisk schemaläggning, medan du använder mer dynamisk strategier skulle kunna resultera i bättre hårdvara utnyttjande.
Bättre hårdvara utnyttjande är helt klart en topp oro i termer av ROI, men för att förstå hur detta förhåller sig till PCAAS och varför Pepperdata anspråk på att kunna övervinna GARN begränsningar vi behöver se där PCAAS sitter i Pepperdata: s produktfamilj. PCAAS är Pepperdata är senaste tillskottet till en linje av produkter, bland annat Ansökan Profiler, Kluster Analyzer, Kapacitet Optimizer, och den Policy för Verkställighet.
De tre sistnämnda är om att samla telemetri data, medan de två förstnämnda är på väg att ingripa i realtid, säger Munshi. Pepperdata s övergripande ambition är att överbrygga klyftan mellan Dev och Ops, och Munshi anser att PCAAS är ett steg i samma riktning: ett verktyg för Ops kan ge till Devs att själv diagnostisera frågor, vilket resulterar i bättre samverkan och fler snabba varv cykler.
Intressant, Hillion också överens om att det finns en tydlig uppdelning mellan egenutvecklade algoritmer för att trimma ML jobb och den information som en Gnista kluster kan ge för att informera dessa algoritmer. Det finns skillnader såväl som likheter i Alpina Labs och Pepperdata erbjudanden om.
Vart är vi på väg?
Till att börja med, både erbjudanden är inte fristående. Väcka auto-tuning är en del av ADSP, medan PCAAS beroende av telemetri data som tillhandahålls av andra Pepperdata lösningar. Så om du bara är intresserad av att automatisera delar av din Gnista kluster tuning eller ansökan profilering, otur.
När man diskuterar med Hillion, vi påpekade det faktum att alla inte är intresserade av Gnista auto tuning kommer nödvändigtvis vill prenumerera ADSP i sin helhet, så kanske att göra denna kapacitet tillgänglig som en fristående produkt skulle vara meningsfullt. Hillion nämnt att en del av deras lösning som handlar om att få Gnista cluster metadata från GARN kan vara öppen källkod, medan auto-tune funktionerna kan säljas separat på någon punkt.
Alpina Labs är orolig om att ge bort för mycket av deras IP, men detta problem kan vara att hålla dem tillbaka från en kommersiell framgång. När man står inför en liknande situation, inte att varje organisation reagerar på samma sätt. Typexempel: Metamarkets byggt Druid och sedan öppen källkod. Varför? “Vi byggde den för att vi behövde det, och vi öppen källkod den, för om vi inte hade, något annat skulle ha ersatt den.”
AI-lås-i-loop: stora investeringar som leder till bättre resultat avla större investeringar. Bild: Azeem Azhar / Schibsted
I rättvisans namn även för Metamarkets Druid är bara infrastruktur, inte kärnverksamheten, medan det för Alpina Labs ADSP är deras bröd och smör. För Pepperdata, de lekte med tanken på att ge fri tillgång till PCAAS för icke-produktionsområden för att få fotfäste i organisationer. Resonemanget är testade och sanna: få ingenjörer vet och kärlek som ett verktyg, och ett verktyg som kommer så småningom att sprida sig och hitta sin väg i IT-budgetar.
Hursomhelst, om du är bland dem som skulle dra nytta av att ha en sådan automatisering för din Gnista distribution, för den tid som du inte har mycket av ett val. Du kommer att antingen betala en premie och förbinda sig till en plattform, eller vänta tills sådan förmåga så småningom att sippra ner.
Den större bilden är dock tydlig: automation är att hitta en alltmer central roll i big data. Big data plattformar kan vara det substrat som automation-applikationer utvecklas, men det kan också fungera tvärtom: automation kan bidra till att lindra stora data smärtpunkter.
Kom ihåg AI lock i slingan? “First-mover advantage kan visa sig vara av betydelse här, som sitter på toppen av miljoner av telemetri data poäng kan göra underverk för din produkt. Detta är exakt den position Pepperdata är i, och den avser att utnyttja den för att applicera Djupt Lärande för att lägga till förebyggande underhåll kapacitet samt tjäna pengar på det på andra sätt.
Om Pepperdata klarar av att köra på som strategi och hur andra kommer att reagera är en annan fråga, men på denna punkt ser det ut som en strategi som har fler chanser att tillgodose behoven för big data automation services.