Av Techopedia Staff, 2 juni 2016
Takeaway: Hadoop-ekosystemet används på stordatorer för att behandla big data snabbt och effektivt.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar, det är klockan fyra östra på en torsdag, och i dag betyder det naturligtvis dags för Hot Technologies. Ja, jag heter Eric Kavanagh. Jag kommer att vara din moderator för dagens webbseminarium. Det är bra grejer, folkens, "Big Iron, Meet Big Data" - Jag älskar bara den rubriken - "Liberating Mainframe Data with Hadoop and Spark." Vi ska prata om gamla möter nya. Wow! Vi täcker spektrumet av allt vi har pratat om under de senaste 50 åren av IT-företag. Spark möter stordator, jag älskar det.
Det finns en plats om din verkligen och nog om mig. Året är varmt. Vi pratar om heta ämnen i den här serien eftersom vi verkligen försöker hjälpa folk att förstå vissa discipliner, vissa utrymmen. Vad betyder det till exempel att ha en analytisk plattform? Vad betyder det att frigöra big data från mainframes? Vad betyder allt det här? Vi försöker hjälpa dig att förstå specifika typer av teknik, var de passar in i blandningen och hur du kan använda dem.
Vi har två analytiker idag och sedan naturligtvis Tendü Yogurtçu från Syncsort. Hon är en visionär i vårt utrymme, mycket nöjd med att ha henne online idag, med vår egen Dez Blanchfield och Dr. Robin Bloor. Jag säger bara ett par snabba ord. Den ena är att, folk, du spelar en stor roll i den här processen, så snälla var inte blyg och ställa några bra frågor. Vi skulle vilja komma till dem under Q & A-komponenten i webcasten, som vanligtvis är i slutet av showen. Och allt jag måste säga är att vi har mycket bra innehåll, så jag är glad att höra vad dessa pojkar har att säga. Och med det ska jag överlämna det till Dez Blanchfield. Dez, golvet är ditt, ta bort det.
Dez Blanchfield: Tack, Eric, och tack alla för att du deltog i dag. Så jag blir ganska upphetsad när jag får chansen att prata om en av mina favorit saker i världen, mainframes. De får inte mycket kärlek i dag. Min uppfattning är mainframe var den ursprungliga big data-plattformen. Vissa skulle hävda att de var den enda datorn då och det är en rimlig sak att göra, men i över 60 år nu har de verkligen varit maskinrummet för vad big data som sent har varit populärt att vara. Och jag ska ta dig med på en liten resa om varför jag tror att så är fallet.
Vi har sett en resa i teknologin hårdvarubunken i samband med stordatorer förändras från bilden som du ser på skärmen nu. Detta är en gammal FACOM-stordator, en av mina favoriter. Vi har flyttat oss in i den stora järnfasen, slutet av nittiotalet och dot-com-boom. Det här är Sun Microsystems E10000. Den här saken var ett absolut monster på 96 processorer. Ursprungligen 64 men det kan uppgraderas på 96 CPU: er. Varje CPU kunde köra 1 024 trådar. Varje tråd kan vara i applikationshastighet samtidigt. Det var bara monströst och det drev faktiskt dot-com-boom. Det här är alla stora enhörningar som vi kallar dem, nu kör vi, och inte bara de stora företagen, några av de stora webbplatserna.
Och sedan slutade vi med den här vanliga PC-modellen utanför hyllan. Vi gick bara med massor av billiga maskiner tillsammans och skapade ett kluster och vi närmade oss den stora järnutmaningen och vad som blev big data, särskilt i form av Hadoop-projektet som stammade från open source-sökmotorn, Nutch. Och vi återskapade i huvudsak mainframe och massor av små CPU: ar som limmades ihop och kunde fungera som L-banor och i form av att köra separata jobb eller delar av jobb och de var ganska effektiva på många sätt. Billigare om du började mindre, men alltid har många av dessa stora kluster blivit dyrare än en stordator.
Min åsikt om dessa saker är att i rusan från dot-com boom till det som blev Web 2.0 och nu jagar enhörningar, har vi glömt bort att det finns denna plattform som fortfarande driver många av våra största uppdragskritiska system där ute. När vi tänker på vad som körs på stordatorplattformarna där ute. Det är väldigt stor data, särskilt datahästen, men verkligen big data. Traditionella företags- och statliga system som bank- och förmögenhetsförvaltning och försäkring använder vi alla varje dag.
Flygbolagsbokning och flygledningssystem, särskilt flygledning där realtid är avgörande. Nästan varje stat och federal regering har någon gång haft en stordator och alltid har många fortfarande dem. Detaljhandel och tillverkning. Några av den gamla programvaran som just har funnits och aldrig har försvunnit. Fortsätter bara till krafttillverkningsmiljöer och verkligen detaljhandeln i skala. Medicinska system. Försvarssystem, verkligen försvarssystem.
De senaste veckorna har jag läst många artiklar om att vissa av missilkontrollsystemen fortfarande körs på gamla stordatorer som de kämpar för att hitta delar till. De räknar ut hur man kan uppgradera till nya stordatorer. Transport- och logistiksystem. Dessa kanske inte låter som de sexiga ämnena, men det är de ämnen som vi behandlar dagligen över hela linjen. Och vissa mycket stora telekommunikationsmiljöer drivs fortfarande på stordatorplattformar.
När du tänker på vilken typ av data som finns där är de alla uppdragskritiska. Det är verkligen viktiga plattformar och plattformar som vi tar för givet varje dag och på många sätt gör livet möjligt. Så vem använder fortfarande en mainframe och vem är alla dessa människor som håller fast vid dessa stora plattformar och har alla dessa uppgifter? Tja, som jag sa här tror jag att det är lätt att luras av medias skift från stort järn till rack med vanliga klyftor utanför hyllan eller billiga datorer eller x86-maskiner, till att tänka att stordatorn dog och försvann. Men uppgifterna säger att stordatorn aldrig försvann och att den faktiskt är här för att stanna.
Den forskning som jag har sammanställt här under de senaste veckorna har visat att 70 procent av företagsdata, särskilt stora företagsdata, fortfarande ligger på en stordator av någon form. Sjutton procent av Fortune 500-talet driver fortfarande kärnverksamhetssystem på stordatorer någonstans. Faktum är att vi här i Australien har ett antal organisationer som har ett datacenter mitt i en stad. Det är en verklig underjordisk dator effektivt och antalet stordatorer som bara kör där, kryssar och lyckligt gör sitt jobb. Och väldigt få människor vet att det är ett enormt datacenter fylt med stordatorer att gå runt på gatorna, precis under deras fötter i en viss del av staden. Nittiotvå av 100 av bankerna runt om i världen, de 100 bästa bankerna som är, driver fortfarande banksystem på stordatorer. Tjugotre av de 25 främsta detaljhandelskedjorna runt om i världen använder stordatorer för att fortfarande köra sina detaljhandelssystem i EIP- och BI-plattformar.
Intressant nog kör 10 av de 10 bästa försäkringsbolagen fortfarande sina plattformar på mainframe, och de driver faktiskt sina molntjänster på mainframe. Om du använder ett webbgränssnitt eller en mobilapp någonstans som det finns mellanprogram ett gränssnitt är, som faktiskt pratar med något riktigt tungt och stort i slutet.
Jag hittade över 225 statliga och lokala myndigheter över hela världen som fortfarande körs på stordatorplattformar. Jag är säker på att det finns mycket anledning till det. De kanske inte har budgeten att överväga nytt järn men det är ett enormt fotavtryck av mycket stora miljöer som körs på mainframe med mycket kritisk information. Och som jag nämnde tidigare driver de flesta länder fortfarande sina viktiga försvarssystem på mainframe. Jag är säker på många sätt de försöker komma dit men där går du.
2015 genomförde IDC en undersökning och 350 av de undersökta CIO: erna rapporterade att de fortfarande ägde och hanterade stort järn i form av stordatorer. Och det slog mig att det är troligt att det är mer än antalet storskaliga Hadoop-kluster som för närvarande körs över hela världen i produktion - en intressant liten stat där. Jag kommer att gå vidare och validera det, men det var ett stort nummer. Tre hundra femtio CIO rapporterade att de har en eller flera stordatorer som fortfarande är i produktion.
Förra året 2015 gav IBM oss den mäktiga Z13, den 13: e iterationen av deras mainframe-plattform. Media gick vild med den här saken eftersom de var förvånade över att IBM fortfarande skapade stordatorer. När de lyft upp huven och tittade på vad som fanns under saken, insåg de att det faktiskt var i nivå med nästan alla moderna plattformar som vi hade blivit upphetsade med i form av big data, Hadoop och säkert klusterna. Den här saken gick Spark och nu Hadoop infödda. Du kan köra tusentals och tusentals Linux-maskiner på det och det såg ut och kändes som alla andra kluster. Det var en helt fantastisk maskin.
Ett antal organisationer tog upp dessa saker och faktiskt gjorde jag lite information om hur många av dessa maskiner som tar upp. Nu har jag haft den uppfattningen att 3270 textterminal har ersatts av webbläsare och mobilappar under en tid och det finns gott om data som stöder det. Jag tror att vi nu går in i en era där vi har insett att dessa stordatorer inte försvinner och det finns en betydande mängd data om dem. Och det vi gör nu är att helt enkelt lägga till det jag kallar analysverktyg utanför hyllan. Dessa är inte specialbyggda appar. Det här är saker som är skräddarsydda enstaka. Det här är saker som du bokstavligen bara kan köpa i en paketerad låda i sig och ansluta till ditt mainframe och göra några analyser.
Som jag sa tidigare, faktiskt har mainframe funnits i över 60 år. När vi tänker på hur länge det är så är det längre än de flesta levande IT-yrkes karriärer faktiskt sträcker sig över. Och i själva verket förmodligen en del av deras liv, till och med. 2002 sålde IBM 2 300 mainframes. 2013 växte det till 2 700 mainframes. Det är 2 700 försäljningar av stordatorer under ett år 2013. Jag kunde inte få exakta uppgifter om 2015 men jag kan tänka mig att det snabbt kommer att komma nära de 3 000 enheter som såldes per år 2015, 2013. Och jag ser fram emot att kunna bekräfta det.
Med lanseringen av Z13, den 13: e iterationen av en stordatorplattform, som jag tror kostade dem ungefär 1, 2 eller 1, 3 miljarder dollar för att utvecklas från grunden, IBM, det vill säga, här är en maskin som ser ut och känns precis som alla andra kluster som vi har idag, och driver nativt Hadoop och Spark. Och kan säkert anslutas till från andra analys- och big data-verktyg eller alltid vara ansluten till en av dina befintliga eller nya Hadoop-kluster. Jag anser att det är ett måste att inkludera stordatorplattformen i din big data-strategi. Uppenbarligen, om du har en, har du mycket data och du vill ta reda på hur du tar bort det där. Och de lämnas för att samla damm på många sätt, mentalt och känslomässigt när det gäller näringslivet, men de är här för att stanna.
Anslutning och gränssnitt för alla dina analysverktyg till mainframe-värddata bör vara en viktig del av ditt företag och särskilt statliga big data-planer. Och alltid märker programvaran dem, tar en lång och lång titt på dem och inser vad som finns i dessa saker och förbinder sinnen som börjar få lite insikt och lite känsla för vad som faktiskt är under huven. Och med det ska jag överlämna till min kära kollega, Dr. Robin Bloor och han kommer att lägga till den lilla resan. Robin, ta bort den.
Robin Bloor: Tja, tack. Okej, ja, eftersom Dez har sjungit låten i stordatorn, ska jag gå in på vad jag tror händer i termer av den gamla stordatorvärlden och den nya Hadoop-världen. Jag antar att den stora frågan här är, hur hanterar du all den informationen? Det är inte min uppfattning att stordatorn utmanas med avseende på dess stora datafunktioner - dess stordatafunktion är extremt, som Dez har påpekat, den är extremt kapabel. I själva verket kan du sätta Hadoop-kluster på det. Där det utmanas är när det gäller dess ekosystem och jag ska lite utarbeta det.
Här är några stordatorpositionering. Det har en hög inträdeskostnad och vad som faktiskt har hänt tidigare, sedan mitten av 90-talet när populariteten för stordatorerna började sjunka, det tenderade att ha tappat sin låga slut, de människor som hade köpt billiga stordatorer och det var inte Det är verkligen inte särskilt ekonomiskt för dessa människor. Men högre upp faktiskt i mellanklassen och högskalan av stordatorn som det fortfarande faktiskt var, och påvisbart faktiskt är, otroligt billig datoranvändning.
Det var, det måste sägas, räddades av Linux eftersom Linux implementerat på en mainframe gjorde det naturligtvis möjligt att köra alla Linux-applikationer. Många Linux-applikationer åkte dit innan big data till och med var ett ord, eller två ord antar jag. Det är faktiskt en ganska utmärkt plattform för privat moln. På grund av detta kan den delta i hybridmolninstallationer. Ett av problemen är att stordatorfärdigheterna är bristfälliga. De stordatorfärdigheter som finns är åldrande i den meningen att människor lämnar branschen för pensionering år efter år och att de bara byts ut när det gäller antalet människor. Så det är en fråga. Men det är fortfarande billig datoranpassning.
Området där det naturligtvis har utmanats är hela Hadoop-saken. Det är en bild av Doug Cutting med den ursprungliga Hadoop-elefanten. Hadoop-ekosystemet är - och det kommer att förbli - det dominerande big data-ekosystemet. Det erbjuder bättre skala än vad mainframe faktiskt kan uppnå och det är lägre kostnader som datalager långt. Hadoop-ekosystemet utvecklas. Det bästa sättet att tänka på detta är en gång en speciell hårdvaruplattform och driftsmiljön med den blir dominerande, då blir ekosystemet bara levande. Och det hände med IBM: s stordator. Tja, senare hände med Digital VAX, hände med Suns servrar, hände med Windows, hände med Linux.
Och vad som hände är att Hadoop, som jag alltid tänker på, eller gillar att tänka på, som en slags distribuerad miljö för data, ekosystemet utvecklas i en otrolig takt. Jag menar om du bara nämna de olika imponerande bidrag som är öppen källkod, Spark, Flink, Kafka, Presto, och så lägger du till några av databaserna, NoSQL och SQL-funktionerna som nu sitter på Hadoop. Hadoop är det mest aktiva ekosystemet som faktiskt finns där, säkert inom företags computing. Men om du vill behandla den som en databas, har den bara ingen jämförelse för tillfället med vad jag brukar betrakta som riktiga databaser, särskilt i datalagerutrymmet. Och det förklarar till viss del framgången för ett antal stora NoSQL-databaser som inte körs på Hadoop som CouchDB och så vidare.
Som en datasjö har den ett mycket rikare ekosystem än någon annan plattform och det kommer inte att förskjutas från det. Ekosystemet är inte bara öppen källkod. Det finns nu ett dramatiskt antal mjukvarumedlemmar som har produkter som i grunden är byggda för Hadoop eller har importerats till Hadoop. Och de har precis skapat ett ekosystem som det inte finns något som kan konkurrera med det när det gäller dess bredd. Och det betyder verkligen att det har blivit plattformen för big data-innovation. Men enligt min mening är det fortfarande omogna och vi kunde ha långa diskussioner om vad som är och inte är, låt oss säga, operationellt moget med Hadoop, men jag tror att de flesta som tittar på det här området är väl medvetna om att Hadoop är decennier bakom stordatorn vad gäller driftsförmåga.
Den utvecklande datasjön. Datasjön är en plattform av vilken definition som helst och om du tänker på att det finns ett datalag i företags computing nu är det väldigt lätt att tänka på det i termer av de fasta databaser plus datasjön som utgör dataskiktet. Data lake-applikationer är många och varierande. Jag har ett diagram här som bara går igenom de olika datakrackande saker som måste göras om du använder Hadoop som iscenesättningsområde eller Hadoop och Spark som iscenesättningsområde. Och du har det hela - datalinje, rensning av data, hantering av metadata, upptäckt av metadata - det kan användas för ETL själv men kräver ofta att ETL ska lägga in uppgifterna. Huvuddatahantering, affärsdefinitioner av data, servicehantering av vad som händer i Hadoop, livscykelhantering av data och ETL ur Hadoop, och du har också direkta analysapplikationer som du kan köra på Hadoop.
Och det är därför det har blivit mycket kraftfullt och där det har implementerats och implementerats framgångsrikt, normalt har det åtminstone en samling av dessa typer av applikationer som körs ovanpå det. Och de flesta av dessa applikationer, särskilt de som jag har informerats om, de är bara inte tillgängliga på stordatorn just nu. Men du kan köra dem på mainframe, på ett Hadoop-kluster som kördes i en partition av mainframe.
Datasjön blir, enligt min mening, det naturliga iscenesättningsområdet för snabb databasanalys och för BI. Det blir platsen där du tar in data, oavsett om det är företagsdata eller extern data, röra med dem tills det är, låt oss säga, tillräckligt rent för att använda och välstrukturerat för att använda och sedan vidarebefordra det. Och allt detta är fortfarande i sin spädbarn.
Tanken, enligt min mening, om mainframe / Hadoop-samexistens, det första är att stora företag troligtvis inte kommer att överge stordatorn. I själva verket antyder indikationerna som jag nyligen har sett att det finns en ökande investering i stordatorn. Men de kommer inte att ignorera Hadoop-ekosystemet heller. Jag ser siffror på 60 procent av stora företag som använder Hadoop även om många av dem bara prototyper och experimenterar.
Förhållandet är då: "Hur får du dessa två saker att leva tillsammans?" Eftersom de kommer att behöva dela data. Data som föras in i datasjön som de behöver för att överföra till mainframe. Data som finns på stordatorn kan behöva gå till datasjön eller genom datasjön för att kopplas till andra data. Och det kommer att hända. Och det betyder att det kräver snabb dataöverföring / ETL-kapacitet. Det är osannolikt att arbetsbelastningar kommer att delas dynamiskt i, låt oss säga, en stordatormiljö eller med något i en Hadoop-miljö. Det kommer att vara data som delas. Och majoriteten av uppgifterna kommer oundvikligen att ligga på Hadoop helt enkelt för att det är den lägsta kostnadsplattformen för det. Och den slutliga analysbehandlingen kommer förmodligen att ligga där också.
Sammanfattningsvis måste vi i slutändan tänka i termer av ett datalag för företag, som för många företag kommer att inkludera stordatorn. Och det dataskiktet måste hanteras proaktivt. Annars kommer de två inte samexistera bra. Jag kan skicka bollen tillbaka till dig Eric.
Eric Kavanagh: Återigen, Tendü, jag gjorde just dig till presentatören, så ta bort det.
Tendü Yogurtçu: Tack, Eric. Tack för att jag fick komma. Hej allihopa. Jag kommer att prata om Syncsort-upplevelsen med kunderna i förhållande till hur vi ser data som en tillgång i organisationen är planerad från stordator till big data på analysplattformar. Och jag hoppas att vi också får tid i slutet av sessionen att ha frågor från publiken, för det är verkligen den mest värdefulla delen av dessa webbsändningar.
Bara för människor som inte vet vad Syncsort gör, är Syncsort ett mjukvaruföretag. Vi har faktiskt funnits i över 40 år. Började på mainframe-sidan och våra produkter sträcker sig från mainframe till Unix till big data-plattformar, inklusive Hadoop, Spark, Splunk, både på premissen och i molnet. Vårt fokus har alltid varit på dataprodukter, databehandlingsprodukter och dataintegrationsprodukter.
Vår strategi med avseende på big data och Hadoop har verkligen varit att bli en del av ekosystemet från första dagen. Som innehavare av leverantörer som verkligen har varit inriktade på databehandling med mycket lätta motorer trodde vi att det fanns en stor möjlighet att delta i att Hadoop blev en databehandlingsplattform och vara en del av denna nästa generations datalagerarkitektur för organisationen. Vi har bidragit med Apache-projekten med öppna källor sedan 2011, med början med MapReduce. Har varit i topp tio för Hadoop version 2, och deltagit faktiskt i flera projekt, inklusive Spark-paket, några av våra kontakter publiceras i Spark-paket.
Vi utnyttjar vår mycket lätta databehandlingsmotor, som är helt platt-baserade metadata, och passar mycket bra med de distribuerade filsystemen som Hadoop Distribuerad filsystem. Och vi utnyttjar vårt arv på stordatorn, vår expertis med algoritmer när vi lägger ut våra big data-produkter. Och vi samarbetar mycket nära de stora leverantörerna, de stora aktörerna här inklusive Hortonworks, Cloudera, MapR, Splunk. Hortonworks meddelade nyligen att de kommer att sälja vår produkt för ETL ombord med Hadoop. Med Dell och Cloudera har vi ett mycket nära partnerskap som också återförsäljer vår ETL-produkt som en del av deras big data-apparat. Och med Splunk faktiskt publicerar vi en mainframe-telemetri och säkerhetsdata i Splunk-instrumentpaneler. Vi har ett nära partnerskap.
Vad tänker alla ledare på C-nivå? Det är verkligen "Hur använder jag mina datatillgångar?" Alla pratar om big data. Alla pratar om Hadoop, Spark, nästa datorplattform som kan hjälpa mig att skapa affärsrörlighet och öppna upp nya transformativa applikationer. Nya marknadsföringsmöjligheter. Varje enskild chef tänker: "Vad är min datastrategi, vad är mitt datainitiativ och hur ser jag till att jag inte håller mig bakom min tävling, och jag är fortfarande på den här marknaden under de kommande tre åren?" se detta när vi talar till våra kunder, medan vi talar till vår globala kundbas, som du kan föreställa dig, eftersom vi har funnits ett tag.
När vi talar med alla dessa organisationer ser vi detta också i teknologibunken i störningen som hände med Hadoop. Det är verkligen för att tillgodose denna efterfrågan på data som tillgång. Utnyttja alla datatillgångar en organisation har. Och vi har sett företagets datalagerarkitektur utvecklas så att Hadoop nu är det nya centrumet för den moderna dataarkitekturen. Och de flesta av våra kunder, oavsett om det är finansiella tjänster, oavsett om det är försäkring, detaljhandelens telco, initiativ är ofta antingen finner vi Hadoop som en tjänst eller data som en tjänst. Eftersom alla försöker göra datatillgångarna tillgängliga för antingen sina externa klienter eller interna klienter. Och i några av organisationerna ser vi initiativ som nästan en datormarknad för sina kunder.
Och ett av de första stegen för att uppnå det är allt från att skapa ett företag datahub. Ibland kommer människor att kalla det en datasjö. Att skapa detta företags datahub är faktiskt inte så enkelt som det låter eftersom det verkligen kräver åtkomst till och insamling av praktiskt taget all data i företaget. Och den här informationen kommer nu från alla de nya källorna som mobila sensorer och gamla databaser och är i batch-läge och i strömmande läge. Dataintegration har alltid varit en utmaning, men med antalet och olika datakällor och de olika leveransstilarna, oavsett om det är batch eller streaming i realtid, är det ännu mer utmanande nu jämfört med fem år sedan, för tio år sedan. Vi hänvisar ibland till det, "Det är inte din fars ETL längre."
Så vi pratar om de olika datatillgångarna. Eftersom företagen försöker förstå de nya uppgifterna, de data de samlar in från mobila enheter, vare sig sensorerna i en biltillverkare eller det är användardata för ett mobilt spelföretag, behöver de ofta hänvisa till de mest kritiska datatillgångarna i företaget, som till exempel är kundinformation. Dessa mest kritiska datatillgångar lever ofta på stordatorn. Att korrelera mainframe-data med dessa nya nya källor, samlade i molnet, samlas in via mobil, samlade på tillverkningslinjen för ett japanskt bilföretag, eller internet av saker-applikationer, måste förstå denna nya information genom att hänvisa till sina gamla datauppsättningar. Och dessa äldre datauppsättningar finns ofta på stordatorn.
Och om dessa företag inte kan göra det, inte har möjlighet att använda mainframe-data, finns det en missad möjlighet. Då utnyttjar data som en tjänst eller utnyttjar alla företagsdata inte riktigt de mest kritiska tillgångarna i organisationen. Det finns också en del av telemetri och säkerhetsdata eftersom nästan alla transaktionsdata lever på stordatorn.
Föreställ dig att du går till en bankomat, jag tror att en av de deltagande skickade ett meddelande till deltagarna här för att skydda banksystemet, när du sveper ditt kort att transaktionsdata är ganska mycket globalt på stordatorn. Och att säkra och samla in säkerhetsdata och telemetri-data från stordatorer och göra dem tillgängliga genom antingen Splunk-instrumentbrädor eller andra, Spark, SQL, blir mer kritisk nu än någonsin på grund av datamängden och datamängden.
Kompetensuppsättningar är en av de största utmaningarna. Eftersom du å ena sidan har en snabbt föränderlig big data-stack, vet du inte vilket projekt som kommer att överleva, vilket projekt som inte kommer att överleva, ska jag anställa Hive eller Pig-utvecklare? Ska jag investera i MapReduce eller Spark? Eller nästa sak, Flink, sa någon. Ska jag investera i en av dessa datorplattformar? Å ena sidan är det en utmaning att hålla jämna steg med det snabbt föränderliga ekosystemet, och å andra sidan har du dessa gamla datakällor. De nya kompetensuppsättningarna matchar inte riktigt och du kan ha ett problem eftersom dessa resurser faktiskt går i pension. Det finns ett stort gap när det gäller skicklighetsuppsättningar för människor som förstår dessa gamla datastackar och som förstår den nya teknikbunken.
Den andra utmaningen är styrningen. När du verkligen har åtkomst till alla företagsdata över plattformar, har vi kunder som väckte oro för att "Jag vill inte att min data ska landa. Jag vill inte att mina data ska kopieras på flera platser eftersom jag vill undvika flera kopior så mycket som möjligt. Jag vill ha åtkomst från slutet till slut utan att landa dem i mitten där. ”Att styra dessa data blir en utmaning. Och den andra delen är att om du får åtkomst till data som flaskhalsar, om du samlar in de flesta av dina data i molnet och får åtkomst till och hänvisar till gamla data, blir nätverksbandbredden ett problem, en klusterplattform. Det finns många utmaningar när det gäller att ha detta big data-initiativ och avancerade analysplattformar och ändå utnyttja alla företagsdata.
Vad Syncsort erbjuder är, vi kallas "helt enkelt bäst" inte för att vi helt enkelt är de bästa, men våra kunder verkligen hänvisar till oss som helt enkelt de bästa på att få tillgång till och integrera mainframe-data. Vi stöder alla dataformat från mainframe och gör dem tillgängliga för big data-analys. Oavsett om det är på Hadoop eller Spark eller nästa datorplattform. Eftersom våra produkter verkligen isolerar datorplattformens komplexitet. Du är som utvecklare potentiellt att utveckla på en bärbar dator, fokusera på datapipeline och vad är dataförberedelserna, stegen för att göra denna information skapad för analysen, nästa fas och ta samma applikation i MapReduce eller ta det samma applikation i Spark.
Vi hjälpte våra kunder att göra det när YARN blev tillgängliga och de var tvungna att flytta sina applikationer från MapReduce version 1 till YARN. Vi hjälper dem att göra samma sak med Apache Spark. Vår produkt, nya version 9, körs också med Spark och levereras med en dynamisk optimering som kommer att isolera dessa applikationer för framtida datoramverk.
Så vi har åtkomst till mainframe-data, oavsett om det är VSAM-filer, oavsett om det är DB2, eller om det är telemetri-data, som SMF-poster eller Log4j eller syslogs, som måste visualiseras via Splunk-instrumentpaneler. Och under det att organisationen kan utnyttja sina befintliga datatekniker eller ETL-kompetensuppsättningar, minskas utvecklingstiden avsevärt. I själva verket med Dell och Cloudera fanns det ett oberoende riktmärke sponsrat, och det riktmärket fokuserade på utvecklingstid som det tar om du gör handkodning eller använder andra verktyg som Syncsort, och det var ungefär 60, 70 procent minskning av utvecklingstiden . Att överbrygga färdigheten sätter klyftor mellan grupper, över dessa datafilvärdar och även de datafilvärdarna i termer av människorna.
Vanligtvis talar inte det stora datateamet, eller dataintagsteamet, eller det team som har till uppgift att utveckla denna information som en servicearkitektur med mainframe-teamet. De vill minimera denna interaktion nästan i många av organisationerna. Genom att stänga det gapet har vi avancerat. Och den viktigaste delen är verkligen att säkra hela processen. För i företaget när du har att göra med den här typen av känslig information finns det många krav.
I högreglerade branscher som försäkring och banker frågar våra kunder, sade de: ”Du erbjuder denna mainframe-åtkomst och det är fantastiskt. Kan du också erbjuda mig att göra detta EBCDIC-kodade inspelningsformat behållet i sitt ursprungliga format så att jag kan uppfylla mina revisionskrav? ”Så vi får Hadoop och Apache Spark att förstå stordatorinformation. Du kan behålla informationen i dess ursprungliga inspelningsformat, göra din bearbetnings- och nivåfördelare datorplattform och om du behöver sätta tillbaka det kan du visa posten inte ändras och postformatet inte ändras kan du uppfylla lagkraven .
Och de flesta organisationer, när de skapar datahuben eller datasjön, försöker de också göra detta med ett enda klick för att kunna kartlägga metadata från hundratals scheman i en Oracle-databas till Hive-tabeller eller ORC- eller parkettfiler blir nödvändig. Vi skickar verktyg och vi tillhandahåller verktyg för att göra detta till ett stegs datatillträde, auto-genererande jobb eller datarörelsen och auto-genererande jobb för att göra datakartläggningen.
Vi pratade om anslutningsdelen, efterlevnaden, styrningen och databehandlingen. Och våra produkter är tillgängliga både på premissen och i molnet, vilket gör det verkligen väldigt enkelt eftersom företagen inte behöver tänka på vad som kommer att hända under nästa år eller två om jag bestämmer mig för att gå helt i public cloud versus hybrid miljö, eftersom vissa av klustren kanske körs på premiss eller i molnet. Och våra produkter finns både på Amazon Marketplace, på EC2, Elastic MapReduce och även i en Docker-behållare.
Bara för att ta bort, så vi har tillräckligt med tid för frågor och svar, det handlar verkligen om att komma åt, integrera och följa datastyrningen, men ändå göra allt detta enklare. Och medan vi gör denna enklare, "design en gång och distribuera var som helst" i verklig mening på grund av våra öppna källkodsbidrag, går vår produkt naturligt i Hadoop-dataflöde och nativt med Spark, och isolerar organisationerna från det snabbt föränderliga ekosystemet. Och tillhandahålla en enda datapipeline, ett enda gränssnitt, både för batch och streaming.
Och detta hjälper också organisationer ibland att utvärdera dessa ramverk, eftersom du kanske vill skapa applikationer och bara köra på MapReduce kontra Spark och se själv, ja, Spark har detta löfte och ger alla framsteg på iterativa algoritmer som fungerar för bästa maskininlärning och prediktiva analysapplikationer fungerar med Spark, kan jag också göra mina strömmar och batcharbetsbelastningar på den här datorramen? Du kan testa olika datorplattformar med våra produkter. Och den dynamiska optimeringen, oavsett om du kör på en fristående server, på din bärbara dator, i Google Cloud kontra Apache Spark, är verkligen ett stort värde förslag för våra kunder. Och det drevs verkligen av de utmaningar som de hade.
Jag kommer bara att täcka en av fallstudierna. Detta är Guardian Life Insurance Company. Och Guardians initiativ var verkligen att centralisera deras datatillgångar och göra det tillgängligt för sina kunder, minska dataförberedelsetiden och de sa att alla pratar om dataförberedelser som tar 80 procent av den totala databehandlingsrörledningen och de sa att det faktiskt tog ungefär 75 till 80 procent för dem och de ville minska datapreparatet, omvandlingstider, tid till marknad för analysprojekt. Skapa den smidigheten när de lägger till nya datakällor. Och göra den centraliserade datatillgängligheten tillgänglig för alla sina kunder.
Deras lösning, inklusive Syncsort-produkter, är just nu de har en Amazon Marketplace lookalike datamarknad som stöds av en datasjö, som i princip är Hadoop och NoSQL-databas. Och de använder våra produkter för att föra alla datatillgångar till datasjön, inklusive DB2 på mainframe, inklusive VSAM-filer på mainframe, och databasens gamla datakällor samt de nya datakällorna. Och till följd av detta har de centraliserat de återanvändbara datatillgångarna som är sökbara, tillgängliga och tillgängliga för sina kunder. Och de kan verkligen lägga till de nya datakällorna och betjäna sina kunder mycket snabbare och effektivare än tidigare. Och analysinitiativen fortskrider även mer på den prediktiva sidan. Så jag kommer att pausa och jag hoppas att detta var användbart och om du har några frågor till mig om något av de relaterade ämnen snälla, är du välkommen.
Eric Kavanagh: Visst, och Tendü, jag ska bara kasta en in. Jag fick en kommentar från en publikmedlem som bara sa: "Jag gillar den här designen en gång, distribuera någonstans." Jag menar, vad har du gjort för att möjliggöra den typen av smidighet och finns det någon skatt? Som när vi till exempel pratar om virtualisering, finns det alltid en liten skatt på prestanda. Vissa människor säger två procent, fem procent 10 procent. Vad du har gjort för att möjliggöra designen en gång, distribuera var som helst - hur gör du det och är det någon skatt i samband med det när det gäller prestanda?
Tendü Yogurtçu: Visst, tack. Nej, för till skillnad från några av de andra leverantörerna genererar vi inte riktigt Hive eller Pig eller någon annan kod som inte är ursprunglig för våra motorer. Det är här våra open source-bidrag spelade en enorm roll, eftersom vi har arbetat med Hadoop-leverantörer, Cloudera, Hortonworks och MapR mycket nära och på grund av våra open-source-bidrag, fungerar faktiskt vår motor som en del av flödet, som en del av Hadoop-flödet, som en del av gnistan.
Vad det också översätter, vi har denna dynamiska optimering. Detta var något som kom till följd av att våra kunder blev utmanade med datoramverk. När de gick i produktion med några av applikationerna kom de tillbaka, de sa: ”Jag stabiliserar bara mitt Hadoop-kluster, stabiliserar på MapReduce YARN version 2, MapReduce version 2, och folk pratar om att MapReduce är död, Spark är nästa sak, och vissa säger att Flink kommer att vara nästa sak, hur ska jag klara det här? ”
Och dessa utmaningar blev verkligen så uppenbara för oss, vi investerade i att ha denna dynamiska optimering som vi kallar intelligent utförande. Vid körtid, när jobbet, när denna datapipeline lämnas in, baserat på klustret, oavsett om det är Spark, om det är MapReduce eller en Linux fristående server, beslutar vi hur vi ska köra det här jobbet, nativt i vår motor, som en del av det Hadoop eller Spark-dataflöde. Det finns ingen overhead eftersom allt görs genom denna dynamiska optimering som vi har och allt görs också eftersom vår motor är så inbyggt integrerad på grund av våra open source-bidrag. Svarar det på din fråga?
Eric Kavanagh: Ja, det är bra. Och jag vill ta upp ytterligare en fråga där borta, och sedan kan Dez, kanske vi dra dig och Robin också. Jag fick precis en rolig kommentar från en av våra deltagare. Jag ska läsa det för att det verkligen är ganska smidigt. Han skriver, "Det verkar som att det i historien om saker HOT" - få det? Som IoT - "är det att ju mer du försöker 'förenkla' något som verkligen är komplex, oftare än inte det enklare det verkar göra saker, mer hängande rep levereras. Tänk databasfråga, explosion, flergängning, etc. ”Kan du kommentera denna paradox som han hänvisar till? Enkelhet kontra komplexitet, och vad är det egentligen som händer under omslagen?
Tendü Yogurtçu: Visst. Jag tror att det är en mycket giltig punkt. När du förenklar saker och gör dessa optimeringar, på ett sätt under täcken, måste någon ta den komplexiteten av vad som behöver hända, eller hur? Om du förlamar något eller om du bestämmer dig för hur du kör ett visst jobb med avseende på datoramverket, är det uppenbarligen en del av jobbet som drivs oavsett om det är i användaränden, menykodning eller på motoroptimeringen. Det är en del av det genom att förenkla användarupplevelsen finns det en enorm fördel när det gäller att kunna utnyttja kompetensuppsättningar som finns i företaget.
Och du kan på något sätt mildra den paradoxen, mildra den utmaningen av, "Ja, men jag har inte kontroll över allt som händer under skyddet, under huven i den motorn, " genom att utsätta saker för de mer avancerade användare om de vill ha den typen av kontroll. Genom att också investera i några av de olika typerna av service. Att kunna erbjuda mer operativa metadata, mer operativa data, som i exemplet som den deltagaren gav, för en SQL-fråga såväl som med motorn igång. Jag hoppas att det svarar.
Eric Kavanagh: Ja det låter bra. Dez, ta bort det.
Dez Blanchfield: Jag är verkligen angelägen om att få lite mer inblick i ditt fotavtryck i öppen källkodbidrag och resan som du har tagit från din traditionella, långvariga erfarenhet inom mainframe och den egenutvecklade världen och sedan övergången till bidra till öppen källkod och hur det skedde. Och det andra jag är angelägen om att förstå är den uppfattning du ser att företag, inte bara IT-avdelningar, utan företag nu tar med avseende på datahubar eller datalakes som folk säger nu och om de ser denna trend med bara en enda, konsoliderad datasjö eller om vi ser distribuerade dataljöar och människor använder verktyg för att sätta ihop dem?
Tendü Yogurtçu: Visst. För det första var det en väldigt intressant resa som innehavare av mjukvaruföretag, ett av de första efter IBM. Men återigen började allt med att våra evangelistkunder tittade på Hadoop. Vi hade dataföretag som ComScore, de var ett av de första som antog Hadoop eftersom de samlade in digitala data över hela världen och inte kunde hålla 90 dagar med data om de inte investerade en datalagerlåda på tio miljoner dollar i deras miljö. De började titta på Hadoop. Med det började vi också titta på Hadoop.
Och när vi fattade ett beslut och erkände att Hadoop verkligen kommer att vara framtidens dataplattform, kom vi också till förståelsen att vi inte kommer att kunna spela i detta, ett framgångsrikt spel i detta, såvida vi inte var en del av ekosystemet. Och vi arbetade väldigt nära med Hadoop-leverantörer, med Cloudera, Hortonworks, MapR, etc. Vi började verkligen prata med dem eftersom partnerskap blir väldigt viktigt för att validera det värde en leverantör kan ge och också ser till att vi tillsammans kan gå till företaget och erbjuder något mer meningsfullt. Det krävde mycket relationsbyggnad eftersom vi inte var kända för Apache-open source-projekten, men vi hade stort stöd från dessa Hadoop-leverantörer, måste jag säga.
Vi började arbeta tillsammans och titta på navet, hur vi kan få värde utan att ens vår innehavarprogramvara i rymden. Det var viktigt. Det handlar inte bara om att sätta några API: er som din produkt kan köras på, det är för att kunna säga att jag kommer att investera i detta eftersom jag tror att Hadoop kommer att bli en framtidens plattform, så genom att investera i de källor vi ville göra säker på att den mognar och blir företagsklar. Vi kan faktiskt aktivera några av de användningsfall som inte fanns tillgängliga innan våra bidrag. Det kommer att gynna hela ekosystemet och vi kan utveckla dessa partnerskap mycket nära.
Det tog ganska mycket tid. Vi började bidra 2011 och 2013, 21 januari - jag kommer ihåg datumet eftersom det datumet vårt största bidrag åtagits vilket innebar att vi nu kan ha våra produkter generellt tillgängliga från och med den tiden - det tog ganska lång tid att utveckla dessa relationer, visa värdet, partners blir designpartners med leverantörerna och med pendlarna i öppen källkod. Men det var mycket roligt. Det var mycket givande som ett företag för oss att vara en del av det ekosystemet och utveckla ett fantastiskt partnerskap.
Den andra frågan om datahub / datasjön, tror jag när vi ser dessa data som en serviceimplementering i de flesta fall, ja, det kan vara kluster, fysiskt enstaka eller flera kluster, men det är mer konceptuellt än att bli den enda platsen för alla uppgifter. Eftersom vi i vissa organisationer ser stora klusterdistribution på plats, men de har också kluster, till exempel i det offentliga molnet, eftersom en del av de data som samlas in från onlinesektioner verkligen förvaras i molnet. Det är att kunna ha en enda datapipeline som du faktiskt kan utnyttja båda dessa, och använda dem som ett enda datahub, singeldatasjö, blir viktigt. Inte nödvändigtvis bara den fysiska platsen, men att ha datahuben och datasjön över kluster, över geografier och kanske på premiss och moln kommer att bli mycket kritiskt, tror jag. Särskilt framåt. I år började vi se fler och fler molninstallationer. Det är fantastiskt. Det första halvåret i år hittills har vi sett en hel del molninstallationer.
Eric Kavanagh: Okej, cool. Och Robin, har du några frågor? Jag vet att vi bara har några minuter kvar.
Robin Bloor: Okej, jag kan ställa henne en fråga. Det första som hände mig är att det har varit mycket spänning kring Kafka och jag var intresserad av din åsikt om Kafka och hur du integrerar med hur människor använder Kafka?
Tendü Yogurtçu: Visst. Ja, Kafka blir ganska populär. Bland våra kunder ser vi att det är typ av datatransportlager och ser att uppgifterna är en buss, ganska mycket. Till exempel använde en av våra kunder faktiskt en sorts konsumtionsdata som sköt in i denna Kafka bland flera, som tusentals onlineanvändare och som kunde klassificera det och driva igenom.
Återigen är Kafka en databuss för de olika konsumenterna av dessa uppgifter. Klassificera vissa avancerade användare kontra inte så avancerade användare och gör något annorlunda framåt i datapipeline. Hur vi integrerar med Kafka är i princip, vår produkt DMX-h blir en pålitlig konsument, en mycket effektiv och pålitlig konsument för Kafka. Den kan läsa data och det skiljer sig inte från att läsa data från någon annan datakälla för oss. Vi ger användarna möjlighet att kontrollera fönstret antingen när det gäller det tidsbehov som de har eller antalet meddelanden som de kan konsumera från Kafka-bussen. Och då kan vi också göra anrikning av dessa data när de går igenom vår produkt och skjuts tillbaka in i Kafka. Vi har testat detta. Vi har benchmarkat det på kundplatsen. Även certifierad av Confluent. Vi arbetar nära med de Confluent killarna och det är mycket högpresterande och lätt att använda. Återigen ändrar API: erna men du behöver inte oroa dig för att produkten verkligen behandlar det som bara en annan datakälla, en strömmande datakälla. Det är ganska kul att arbeta med vår produkt och Kafka, faktiskt.
Robin Bloor: Okej, jag har en annan fråga som bara är en generell affärsfråga, men jag har känt Syncsort länge och du har alltid haft rykte och levererat extra snabb programvara för ETL och mainframe-världen. Är det så att större delen av ditt företag nu överförs till Hadoop? Är det så att du på ett eller annat sätt har spridit ditt företag ganska dramatiskt från mainframe-världen?
Tendü Yogurtçu: Våra stordatorprodukter kör fortfarande 50 procent av stordatorerna globalt. Så vi har en mycket stark mainframe-produktlinje utöver vad vi gör på big data och Hadoop-slutet. Och vi är fortfarande i de flesta av IT-förenklings- eller optimeringsprojekten eftersom det finns ena änden som du vill kunna utnyttja dina mainframe-data i Bigtex Multex-plattformar och utnyttja all företagsdata, men det finns också mycket kritiska transaktionsarbetsbelastningar som fortfarande körs på mainframe och vi erbjuder dessa kunder sätten att verkligen göra dessa applikationer mer effektiva, köra i zIIP-motorn så att de inte konsumerar så mycket processcykler och MIPS, gör dem kostnadseffektiva.
Vi fortsätter att investera i mainframe-produkterna och spelar faktiskt in i det här utrymmet där människor går från mainframe big iron till big data och spänner över produktlinjen även över dessa plattformar. Så vi flyttar inte nödvändigtvis hela verksamheten till en sida, vi fortsätter att ha mycket framgångsrika affärer på båda sidor. Och förvärven är också ett stort fokus för oss. Eftersom denna datahantering och databehandlingsutrymme för stordataplattformarna utvecklas är vi också skyldiga att göra en hel del kostnadsfria förvärv.
Robin Bloor: Jag antar att jag inte kan fråga dig vad de är för du skulle inte få berätta för mig. Jag är intresserad av om du har sett många implementeringar av Hadoop eller Spark faktiskt på stordatorn eller om det är en mycket sällsynt sak.
Tendü Yogurtçu: Vi har inte sett något. Det finns mer fråga om det. Jag tror att Hadoop på mainframe inte var mycket meningsfullt på grund av typen av kärnstruktur. Men Spark on mainframe är ganska meningsfullt och Spark är verkligen väldigt bra med maskininlärningen och prediktiv analys och att kunna ha några av dessa applikationer med mainframe-data verkligen är, tror jag, ganska meningsfullt. Vi har inte sett någon göra det ännu, men det är verkligen användningsfallet som driver dessa saker. Om ditt användningsfall som företag är mer att föra den stordatorinformationen och integrera med resten av datauppsättningarna i stordataplattformen, är det en historia. Det kräver åtkomst till mainframe-data från Bigtex-Multex-plattformen eftersom du troligtvis inte tar med dig dina datauppsättningar från öppna system och kallas tillbaka till mainframe. Men om du har vissa mainframe-data som du bara vill utforska och göra lite upptäckt av datautforskning, tillämpa lite avancerad AI och avancerad analys, kan Spark vara ett bra sätt att gå och köra på mainframe som det.
Eric Kavanagh: Och här är ytterligare en fråga från publiken, faktiskt två till. Jag kommer att ge dig en tag-team-fråga, så kommer vi att samla in. En deltagare frågar: "Integrerar IBM dina bidrag med öppen källkod i sitt offentliga molnekosystem, med andra ord Bluemix?" Och en annan deltagare gjorde en riktigt bra poäng och noterade att Syncsort är bra för att hålla stort järn levande för dem som har redan det, men om företag överger nya stordatorer till förmån för vad han kallar CE, fördunker allt, att det troligtvis kommer att minska, men konstaterar att ni är riktigt bra på att flytta data genom att kringgå operativsystem upp till en gigabyte per sekund. Kan du prata lite om din kärnstyrka, som han nämnde, och om IBM integrerar dina grejer i Bluemix eller inte?
Tendü Yogurtçu: Med IBM är vi redan samarbetspartner med IBM och vi hade diskussioner för deras datormolntjänster som erbjuder produkten. Våra bidrag med öppen källkod är öppna för alla som vill utnyttja dem. En del av mainframe-anslutningen finns också i Spark-paket, så inte bara IBM. Vem som helst kan utnyttja dessa. I Bluemix har vi inte gjort något specifikt om det än. Och har du något emot att upprepa den andra frågan?
Eric Kavanagh: Ja, den andra frågan handlade om ditt kärnområde med funktionalitet genom åren, som verkligen hanterade flaskhalsar av ETL och uppenbarligen är det något som ni fortfarande kommer att göra som stordatorer, ja, teoretiskt håller sig borta, även om Dez's punkt är fortfarande typ av gungning och rullning där ute. Men deltagaren noterade just att Syncsort är mycket bra på att flytta data genom att kringgå operativsystem och upp till en gigabyte per sekund. Kan du bara kommentera det?
Tendü Yogurtçu: Ja, verkligen den totala resurseffektiviteten har varit vår styrka och skalbarhet och prestanda har varit vår styrka. Vi kompromissar inte, förenkla har många betydelser, vi kompromissar inte från dessa. När folk började prata om Hadoop 2014, till exempel, såg många av organisationerna inte riktigt på prestationer från början. De sa: "Åh, om något händer kan jag lägga till ytterligare ett par noder och jag kommer att ha det bra, prestanda är inte mitt krav."
Medan vi pratade om att ha bästa prestanda eftersom vi redan körde nativt, hade vi inte ens några av de initiala hicka som Hive hade med flera MapReduce-jobb och omkostnader med att starta dem. Folk sa till oss: "Åh, det är inte min oro, oroa dig inte för det för tillfället."
När vi kom till 2015 har landskapet förändrats eftersom några av våra kunder redan överskred lagringarna som de hade i sina produktionskluster. Det blev mycket kritiskt för dem att se vad Syncsort kan erbjuda. Om du tar en del data från en databas eller mainframe och skriver till ett parkettformat i klustren, oavsett om du landar och scenar och gör en ny transformation eller bara gör inflight-transformationen och landade målfilformatet, gjorde du en skillnad eftersom du sparar från lagring, du sparar från nätverksbandbredd, du sparar från arbetsbelastningen i klustret eftersom du inte kör extra jobb. De styrkor som vi spelar när det gäller att vara mycket medvetna, vi känner resurseffektiviteten under vår hud, verkar det.
Det är så vi beskriver det. Det är avgörande för oss. Vi tar det inte för givet. Vi tog det aldrig för givet så vi kommer att fortsätta att vara starka med den hävstångseffekten i Apache Spark eller nästa datoram. Det kommer att fortsätta vara vårt fokus. Och när det gäller datarörelsedelen och datatillgångsdelen är det definitivt en av våra styrkor och vi får åtkomst till DB2- eller VSAM-data på stordatorerna i samband med Hadoop eller Spark.
Eric Kavanagh: Det är ett bra sätt att avsluta webcasten, folkens. Tack så mycket för din tid och uppmärksamhet. Tack till er, Tendü och Syncsort, för att ni kom in i informationsrummet och gick in i rundan, som de säger. Många bra frågor från publiken. Det är en ständigt rörlig miljö där ute, folkens. Vi kommer att arkivera denna Hot Tech som vi gör med alla andra. Du hittar oss på insideanalysis.com och på techopedia.com. Vanligtvis går det upp om ungefär en dag. Och med det kommer vi att hälsa dig, folkens. Tack så mycket. Vi pratar snart. Ta hand om dig. Hejdå.
