Af Techopedia Staff, 2. juni 2016
Takeaway: Hadoop-økosystemet bruges på mainframes til at behandle big data hurtigt og effektivt.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer, det er fire øst på en torsdag, og i disse dage betyder det selvfølgelig tid for Hot Technologies. Ja, ja, jeg hedder Eric Kavanagh. Jeg vil være din moderator til dagens webseminar. Det er gode ting, folkens, “Big Iron, Meet Big Data” - Jeg elsker bare den overskrift - “Liberating Mainframe Data with Hadoop and Spark.” Vi skal tale om gamle møder nye. Wow! Vi dækker spektret af alt, hvad vi har talt om i de sidste 50 år med virksomheds-it. Spark møder mainframe, jeg elsker det.
Der er et sted om dit virkelig og nok om mig. Året er varmt. Vi taler om varme emner i denne serie, fordi vi virkelig prøver at hjælpe folk med at forstå bestemte discipliner, bestemte rum. Hvad betyder det for eksempel at have en analytisk platform? Hvad betyder det at frigøre big data fra mainframes? Hvad betyder alt dette? Vi forsøger at hjælpe dig med at forstå specifikke slags teknologier, hvor de passer ind i blandingen, og hvordan du kan gøre brug af dem.
Vi har to analytikere i dag og derefter selvfølgelig Tendü Yogurtçu fra Syncsort. Hun er en visionær i vores rum, meget glad for at have hende online i dag med vores egen Dez Blanchfield og Dr. Robin Bloor. Jeg siger bare et par hurtige ord. Den ene er, at folk spiller en stor rolle i denne proces, så vær venlig ikke med at stille nogle gode spørgsmål. Vi vil gerne komme til dem under Q & A-komponenten i webcasten, som normalt er i slutningen af showet. Og alt hvad jeg har at sige er, at vi har meget godt indhold, så jeg er spændt på at høre, hvad disse drenge har at sige. Og med det overleverer jeg det til Dez Blanchfield. Dez, ordet er dit, tag det væk.
Dez Blanchfield: Tak, Eric, og tak alle for at deltage i dag. Så jeg bliver ret ophidset, når jeg får en chance for at tale om en af mine foretrukne ting i verden, mainframes. De får ikke meget kærlighed i disse dage. Min opfattelse er mainframe var den originale big data platform. Nogle vil hævde, at de var den eneste computer på det tidspunkt, og det er et rimeligt punkt at gøre, men i over 60 år nu har de virkelig været maskinrummet for, hvad big data for sent har været populært at være. Og jeg tager dig med på en lille rejse om, hvorfor jeg tror, det er tilfældet.
Vi har set en rejse i teknologihardwarestackene i forbindelse med mainframes skifte fra det billede, du ser på skærmen nu. Dette er en gammel FACOM mainframe, en af mine favoritter. Vi har flyttet os ind i den store jernfase, slutningen af halvfemserne og dot-com boom. Dette er Sun Microsystems E10000. Denne ting var et absolut monster på 96 CPU'er. Oprindeligt 64, men det kunne opgraderes på 96 CPU'er. Hver CPU kunne køre 1.024 tråde. Hver tråd kunne være i påføringshastighed på samme tid. Det var bare uhyrligt og faktisk drev dot-com-boom. Dette er alle de store enhjørninger, som vi kalder dem, nu kører vi, og ikke kun de store virksomheder, nogle af de store websteder.
Og så endte vi med denne almindelige PC-model uden for hylden. Vi har lige fanget masser af billige maskiner sammen, og vi skabte en klynge, og vi nærmet os den store jernudfordring, og hvad der blev big data, især i form af Hadoop-projektet, der sprang ud af open source-søgemaskinen, Nutch. Og vi genskabte grundlæggende hovedrammen og masser af små CPU'er, der blev limet sammen og kunne fungere som L-stier og i form af at køre separate job eller dele af job, og de var ret effektive på mange måder. Billigere, hvis du startede mindre, men altid er mange af disse store klynger blevet dyrere end en mainframe.
Min opfattelse af disse ting er, at i skyndet fra dot-com boom til det, der blev Web 2.0 og nu jagter enhjørninger, har vi glemt, at der er denne platform, der stadig driver mange af vores største missionskritiske systemer derude. Når vi tænker over, hvad der kører på mainframe-platforme derude. Det er meget big data, især data workhorse, men bestemt big data. Traditionelle virksomheds- og regeringssystemer som bank- og formuestyring og forsikring især bruger vi alle hver dag.
Luftfartsreservation og flystyringssystemer, især flystyring, hvor realtid er kritisk. Næsten enhver stat og føderal regering på et tidspunkt har haft en hovedramme, og altid har mange dem stadig. Detail og fremstilling. Noget af den gamle software, der netop har eksisteret og aldrig er væk. Fortsætter bare med strømproduktionsmiljøer og bestemt detailhandel i skala. Medicinske systemer. Forsvarssystemer, bestemt forsvarssystemer.
De sidste par uger har jeg læst mange artikler om det faktum, at nogle af missilkontrolsystemerne alle stadig kører på gamle mainframes, de kæmper for at finde dele til. De finder ud af, hvordan man opgraderer til nye mainframes. Transport- og logistiksystemer. Disse lyder muligvis ikke som de sexede emner, men dette er de emner, vi behandler dagligt på tværs af linjerne. Og nogle meget store telekommunikationsmiljøer køres stadig på mainframe-platforme.
Når du tænker på hvilke typer data der er, er de alle missionskritiske. Det er virkelig vigtige platforme og platforme, som vi tager for givet hver dag og på mange måder gør livet muligt. Så hvem bruger stadig en mainframe, og hvem er alle disse mennesker, der holder fast på disse store platforme og har alle disse data? Som jeg sagde her, tror jeg, det er let at narre af mediets skift fra stort jern til stativer af almindelige klynger eller billige pc'er eller x86 maskiner til at tænke, at mainframe døde og forsvandt. Men dataene siger, at mainframe aldrig forsvandt, og at de faktisk er her for at blive.
Den forskning, jeg har sammensat her i de sidste par uger, har vist, at 70 procent af virksomhedsdataene, især store virksomheder, stadig ligger på en mainframe af en eller anden form. 74 procent af Fortune 500'erne kører stadig kernevirksomhedssystemer på mainframes et eller andet sted. Faktisk har vi her i Australien en række organisationer, der har et datacenter midt i en by. Det er en faktisk underjordisk computer effektivt, og antallet af mainframes, der bare kører der, krydser og heldigvis gør deres job. Og meget få mennesker ved, at når man går rundt i gaderne, lige under deres fødder i en bestemt del af byen, er der dette enorme datacenter fyldt med mainframes. 22 ud af 100 af bankerne rundt om i verden, de 100 bedste banker, det vil sige, kører stadig banksystemer på mainframes. 23 af de 25 største detailkæder rundt om i verden bruger mainframes til stadig at køre deres retail management systemer i EIP og BI platforme.
Interessant nok kører 10 ud af de 10 bedste forsikringsselskaber stadig deres platforme på mainframe, og de driver faktisk deres skytjenester på mainframe. Hvis du bruger en webgrænseflade eller en mobilapp et sted, hvor der er mellemvare, er en grænseflade, der faktisk taler til noget virkelig tungt og stort i bagenden.
Jeg fandt over 225 statslige og lokale myndigheder overalt i verden, der stadig kører på mainframe-platforme. Jeg er sikker på, at der er en masse grund til det. Måske har de ikke budgettet til at overveje nyt jern, men det er et enormt fodaftryk af meget store miljøer, der kører på mainframe med nogle meget kritiske data. Og som jeg nævnte tidligere, kører de fleste nationer stadig deres centrale forsvarssystemer på mainframe. Jeg er sikker på, at de på mange måder forsøger at komme derfra, men der går du.
I 2015 gennemførte IDC en undersøgelse, og 350 af de undersøgte CIO'er rapporterede, at de stadig ejede og administrerede stort jern i form af mainframes. Og det slog mig, at det sandsynligvis er mere end antallet af store Hadoop-klynger, der i øjeblikket kører over hele verden i produktion - en interessant lille stat der. Jeg vil gå videre med at validere det, men det var et stort antal. Tre hundrede halvtreds CIO'er rapporterede, at de stadig har en eller flere mainframes.
Sidste år, 2015, gav IBM os den mægtige Z13, den 13. iteration af deres mainframe-platform. Medierne gik vild med denne ting, fordi de var forbløffet over, at IBM stadig lavede mainframes. Da de løftede hætten og kiggede på, hvad der var under tingene, indså de, at det faktisk var på niveau med næsten enhver moderne platform, som vi var blevet begejstrede for i form af big data, Hadoop og helt sikkert klyngerne. Denne ting kørte Spark og nu Hadoop oprindeligt. Du kunne køre tusinder og tusinder af Linux-maskiner på det, og det lignede og føltes som enhver anden klynge. Det var en ganske forbløffende maskine.
En række organisationer tog disse ting op, og faktisk gjorde jeg nogle oplysninger om, hvor mange af disse maskiner, der optager. Nu har jeg haft den opfattelse, at 3270 tekstterminal er blevet erstattet af webbrowsere og mobile apps i nogen tid, og der er masser af data, der understøtter det. Jeg tror, at vi nu går ind i en æra, hvor vi er klar over, at disse mainframes ikke forsvinder, og at der er en betydelig mængde data om dem. Og det, vi gør nu, er blot at tilføje, hvad jeg kalder analyseværktøjer uden for hylden. Dette er ikke specialbyggede apps. Dette er ting, der er skræddersyet til engangs. Dette er ting, som du bogstaveligt talt bare kan købe i en pakke i sig selv og tilslutte din mainframe og lave nogle analyser.
Som jeg sagde før, har mainframe faktisk eksisteret i over 60 år. Når vi tænker over, hvor længe det er, er det længere end de fleste levende IT-faglige karrierer faktisk spænder over. Og faktisk sandsynligvis nogle af deres liv, endda. I 2002 solgte IBM 2.300 mainframes. I 2013 voksede det til 2.700 mainframes. Det er 2.700 salg af mainframes på et år i 2013. Jeg kunne ikke få nøjagtige data om 2015, men jeg kan forestille mig, at det hurtigt kommer tæt på de 3.000 solgte enheder om året i 2015, 2013. Og jeg ser frem til at kunne bekræfte det.
Med frigivelsen af Z13, den 13. iteration af en mainframe-platform, som jeg tror koster dem omkring 1, 2 eller 1, 3 milliarder dollars at udvikle sig fra bunden, IBM er, her er en maskine der ser ud og føles ligesom enhver anden klynge, der vi har i dag, og kører naturligt Hadoop og Spark. Og kan helt sikkert forbindes til fra andre analyse- og big data-værktøjer eller altid være forbundet til en af dine eksisterende eller nye Hadoop-klynger. Jeg har den opfattelse, at det at inkludere mainframe-platformen i din big data-strategi er et must. Naturligvis, hvis du har en, har du en masse data, og du vil finde ud af, hvordan du får dem væk derfra. Og de overlades til at samle støv på mange måder, mentalt og følelsesmæssigt så langt som for forretningsverdenen går, men de er her for at blive.
Forbindelse og grænseflader til alle dine analyseværktøjer til mainframe-hostede data skal være en nøgleelement i din virksomhed og især regeringens store dataplaner. Og altid bemærker software dem, ser godt på dem og indser hvad der er inde i disse ting og forbinder sind, der begynder at få en smule indsigt og en smule fornemmelse for, hvad der faktisk er under hætten. Og med det overleverer jeg min kære kollega, Dr. Robin Bloor, og han vil tilføje den lille rejse. Robin, tag det væk.
Robin Bloor: Nå, tak. Okay, da Dez har sunget sangen af mainframe, skal jeg gå ind på, hvad jeg tror sker i form af den gamle mainframe-verden og den nye Hadoop-verden. Jeg antager, at det store spørgsmål her er, hvordan administrerer du alle disse data? Det er ikke min opfattelse, at mainframe udfordres med hensyn til dens big data-kapacitet - dens big data-kapacitet er ekstremt, som Dez har påpeget, den er yderst kapabel. Faktisk kan du sætte Hadoop-klynger på det. Hvor det bliver udfordret er med hensyn til dets økosystem, og jeg vil slags uddybe det.
Her er nogle mainframe positionering. Det har en høj indgangsomkostning, og hvad der faktisk er sket i fortiden, siden midten af 90'erne, da populariteten af mainframes begyndte at dyppe, det har tendens til at have mistet sin lave ende, de mennesker, der havde købt billige mainframes, og det var ikke er virkelig ikke særlig økonomisk for disse mennesker. Men højere op faktisk i mellemklassen og højskalaen af den hovedramme, som den stadig var, og som beviselig faktisk er, utrolig billig computing.
Det blev, skal det siges, reddet af Linux, fordi Linux implementeret på en mainframe gjorde det naturligvis muligt at køre alle Linux-applikationer. En masse Linux-applikationer gik der før big data endda var et ord, eller to ord antager jeg. Det er faktisk en temmelig fremragende platform til privat sky. På grund af det kan det deltage i hybrid sky-implementeringer. Et af problemerne er, at mainframe-færdigheder mangler. De eksisterende mainframe-færdigheder er faktisk aldring i den forstand, at folk forlader branchen til pension for år efter år, og at de kun lige erstattes med hensyn til antallet af mennesker. Så det er et problem. Men det er stadig billig computing.
Området, hvor det selvfølgelig er blevet udfordret, er hele denne Hadoop-ting. Det er et billede af Doug Cutting med den originale Hadoop-elefant. Hadoop-økosystemet er - og det vil forblive - det dominerende big data-økosystem. Det giver en bedre skala, end mainframe faktisk kan opnå, og det er lavere omkostninger som en datalager langt. Hadoop-økosystemet udvikler sig. Den bedste måde at tænke over dette på er en gang en bestemt hardwareplatform, og driftsmiljøet med det bliver dominerende, så bliver økosystemet bare levende. Og det skete med IBM mainframe. Nå, der senere skete med Digital VAX, skete med Suns servere, skete med Windows, skete med Linux.
Og hvad der er sket, er, at Hadoop, som jeg altid tænker på eller kan lide at tænke på, som et slags distribueret miljø til data, økosystemet udvikler sig i en utrolig hastighed. Jeg mener, hvis du bare nævner de forskellige imponerende bidrag, der er open source, Spark, Flink, Kafka, Presto, og så tilføjer du nogle af databaserne, NoSQL og SQL, der nu sidder på Hadoop. Hadoop er det mest aktive økosystem, der faktisk findes derude, bestemt inden for virksomhedernes computing. Men hvis du vil behandle den som en database, kan den bare ikke sammenligne i øjeblikket med, hvad jeg har tendens til at betragte som rigtige databaser, især i datalagerrummet. Og det forklarer til en vis grad succes for et antal af de store NoSQL-databaser, der ikke kører på Hadoop som CouchDB og så videre.
Som en datasø har den et langt rigere økosystem end nogen anden platform, og det vil ikke blive forskudt fra det. Dets økosystem er ikke kun open source-økosystemet. Der er nu et dramatisk antal softwaremedlemmer, der har produkter, der grundlæggende er bygget til Hadoop eller er importeret til Hadoop. Og de har lige oprettet et økosystem, at der ikke er noget, der kan konkurrere med det med hensyn til dets bredde. Og det betyder virkelig, at det er blevet platformen for big data-innovation. Men efter min mening er det stadig umodent, og vi kunne have lange diskussioner om, hvad der er og ikke er, lad os sige, operationelt modent med Hadoop, men jeg tror, at de fleste, der ser på dette særlige område, er klar over, at Hadoop er årtier bag mainframe med hensyn til operationel kapacitet.
Den udviklende datasø. Datasøen er en platform af enhver definition, og hvis du tænker på, at der er et datalag i virksomhedsberegning nu, er det meget let at tænke på det i form af de faste databaser plus datasøen, der udgør datalaget. Data lake applikationer er mange og varierede. Jeg har et diagram her, der bare går gennem de forskellige data krænkende ting, der skal gøres, hvis du bruger Hadoop som iscenesættelsesområde eller Hadoop og Spark som iscenesættelsesområde. Og du har det hele - datalinje, rensning af data, metadatastyring, opdagelse af metadata - det kan bruges til ETL selv, men kræver ofte, at ETL bringer dataene ind. Master data management, forretningsdefinitioner af data, servicestyring af hvad der sker i Hadoop, livscyklusstyring af data og ETL ud af Hadoop, og du har også direkte analyseprogrammer, som du kan køre på Hadoop.
Og det er derfor, det er blevet meget magtfuldt, og hvor det er implementeret og implementeret med succes, normalt har det i det mindste en samling af disse slags applikationer, der kører ovenpå. Og de fleste af disse applikationer, især dem, som jeg er blevet orienteret om, er de bare ikke tilgængelige på mainframe lige nu. Men du kan køre dem på mainframe, på en Hadoop-klynge, der kørte i en partition af mainframe.
Datasøen bliver efter min mening det naturlige iscenesættelsesområde til hurtig databaseanalyse og BI. Det bliver det sted, hvor du indtaster dataene, uanset om det er virksomhedsdata eller eksterne data, rod med dem, indtil det er, lad os sige, rent nok til at være brugt og velstruktureret til brug, og så videresender de det. Og alt dette er stadig i sin spædbarn.
Ideen, efter min mening, om mainframe / Hadoop-sameksistens, den første ting er, at store virksomheder sandsynligvis ikke vil opgive mainframe. Faktisk antyder indikationerne, som jeg for nylig har set, at der er en stigende investering i mainframe. Men de vil heller ikke ignorere Hadoop-økosystemet. Jeg ser tal for 60 procent af de store virksomheder, der bruger Hadoop, selvom mange af dem faktisk bare prototyper og eksperimenterer.
Forholdet er så: ”Hvordan får du disse to ting til at eksistere sammen?” Fordi de bliver nødt til at dele data. Data, der bringes ind i datasøen, de har brug for at overføre til mainframe. Data, der findes på mainframe, skal muligvis gå til datasøen eller gennem datasøen for at blive knyttet til andre data. Og det vil ske. Og det betyder, at det kræver hurtig dataoverførsel / ETL-kapacitet. Det er usandsynligt, at arbejdsbelastningen vil blive delt dynamisk i, lad os sige, et mainframe-miljø eller med noget i et Hadoop-miljø. Det bliver data, der deles. Og størstedelen af data kommer uundgåeligt til at opholde sig på Hadoop, simpelthen fordi det er den billigste platform til det. Og den endelige-til-ende analytiske behandling vil sandsynligvis også være der.
Kort sagt, i sidste ende er vi nødt til at tænke i form af et virksomhedsdatablad, som for mange virksomheder vil omfatte mainframe. Og det datalag skal administreres proaktivt. Ellers vil de to ikke eksistere godt sammen. Jeg kan give bolden tilbage til dig Eric.
Eric Kavanagh: Igen, Tendü, jeg gjorde dig lige til præsentanten, så tag den væk.
Tendü Yogurtçu: Tak, Eric. Tak fordi jeg måtte komme. Hej allesammen. Jeg vil tale om Syncsort-oplevelsen med kunderne i forhold til, hvordan vi ser dataene som et aktiv i organisationen er jævnet fra mainframe til big data på analytiske platforme. Og jeg håber, at vi også får tid i slutningen af sessionen til at have spørgsmål fra publikum, for det er virkelig den mest værdifulde del af disse webcasts.
Bare for folk, der ikke ved, hvad Syncsort gør, er Syncsort en softwarevirksomhed. Vi har faktisk eksisteret over 40 år. Begyndt på mainframe-siden, og vores produkter spænder fra mainframe til Unix til big data platforme, inklusive Hadoop, Spark, Splunk, både på forudsætning og i skyen. Vores fokus har altid været på dataprodukter, databehandling og dataintegrationsprodukter.
Vores strategi med hensyn til big data og Hadoop har virkelig været at blive en del af økosystemet fra første dag. Som indehavere af leverandører, der virkelig har været fokuseret på databehandling med meget lette motorer, troede vi, at der var en stor mulighed for at deltage i, at Hadoop blev en databehandlingsplatform og være en del af denne næste generations datalagerarkitektur for organisationen. Vi har bidraget med open source Apache-projekter siden 2011, startende med MapReduce. Har været i top ti for Hadoop version 2 og deltaget faktisk i flere projekter, inklusive Spark-pakker, nogle af vores stik offentliggøres i Spark-pakker.
Vi udnytter vores meget lette databehandlingsmotor, som er fuldstændigt fladfilbaserede metadata, og som passer godt til de distribuerede filsystemer som Hadoop Distribueret filsystem. Og vi udnytter vores arv på mainframe, vores ekspertise med algoritmer, når vi lægger vores big data-produkter ud. Og vi samarbejder meget tæt med de store leverandører, de store spillere her inklusive Hortonworks, Cloudera, MapR, Splunk. Hortonworks annoncerede for nylig, at de vil videresælge vores produkt til ETL-onboarding med Hadoop. Med Dell og Cloudera har vi et meget tæt partnerskab, der også videresælger vores ETL-produkt som en del af deres big data-apparat. Og med Splunk faktisk, offentliggør vi en mainframe-telemetri og sikkerhedsdata i Splunk-dashboards. Vi har et tæt partnerskab.
Hvad er der i sindet for alle ledere på C-niveau? Det er virkelig, ”Hvordan kan jeg bruge mine datafordele?” Alle taler om big data. Alle taler om Hadoop, Spark, den næste computerplatform, som måske kan hjælpe mig med at skabe forretningsdygtighed og åbne nye transformative applikationer. Nye markedsmuligheder. Hver enkelt direktør tænker: "Hvad er min datastrategi, hvad er mit datainitiativ, og hvordan sikrer jeg mig, at jeg ikke forbliver bag min konkurrence, og at jeg stadig er på dette marked i de næste tre år?" Vi se dette, mens vi taler til vores kunder, mens vi taler til vores globale kundegrundlag, som du kan forestille dig, da vi har været i et stykke tid.
Når vi taler med alle disse organisationer, ser vi dette også i teknologibunken i forstyrrelsen, der skete med Hadoop. Det er virkelig for at imødekomme dette krav om data som et aktiv. Udnyttelse af alle dataaktiver, som en organisation har. Og vi har set virksomhedens datalagerarkitektur udvikle sig således, at Hadoop nu er det nye midtpunkt i den moderne dataarkitektur. Og de fleste af vores kunder, hvad enten det er finansielle tjenester, hvad enten det er forsikring, telekommunikation for detailhandlen, initiativerne er normalt enten finder vi Hadoop som en service eller data som en tjeneste. Fordi alle forsøger at stille dataaktiverne til rådighed for enten deres eksterne klienter eller interne klienter. Og i nogle af organisationerne ser vi initiativer som næsten en datamarked for deres kunder.
Og et af de første skridt til at opnå det er alt sammen fra oprettelse af en enterprise data hub. Nogle gange vil folk kalde det en datasø. Oprettelse af dette enterprise data hub er faktisk ikke så let, som det lyder, fordi det virkelig kræver adgang til og indsamling af praktisk talt alle data i virksomheden. Og disse data er nu fra alle de nye kilder som mobile sensorer såvel som ældre databaser, og de er i batch-tilstand og i streaming-tilstand. Dataintegration har dog altid været en udfordring, men med antallet og forskellige datakilder og de forskellige leveringsformer, hvad enten det er batch eller streaming i realtid, er det endnu mere udfordrende nu sammenlignet med for fem år siden, for ti år siden. Vi refererer nogle gange til det som "Det er ikke din fars ETL længere."
Så vi taler om de forskellige dataaktiver. Når virksomheder forsøger at give mening om de nye data, de data, de indsamler fra de mobile enheder, hvad enten sensorer i en bilproducent eller det er brugerdataene for et mobilt gamingfirma, er de ofte nødt til at henvise til de mest kritiske dataaktiver i virksomheden, som for eksempel er kundeoplysninger. Disse mest kritiske dataaktiver lever ofte på mainframe. Korrelering af mainframe-data med disse nye nye kilder, indsamlet i skyen, indsamlet via mobil, samlet på produktionslinjen for et japansk bilfirma eller internet af ting-applikationer, skal give mening om disse nye data ved at henvise til deres gamle datasæt. Og disse ældre datasæt findes ofte på mainframe.
Og hvis disse virksomheder ikke er i stand til det, ikke er i stand til at udnytte mainframe-dataene, er der en glip af muligheden. Derefter tapper dataene som en tjeneste eller benytter sig af alle virksomhedsdata ikke rigtig de mest kritiske aktiver i organisationen. Der er også en telemetri- og sikkerhedsdata, fordi stort set alle transaktionsdata lever på mainframe.
Forestil dig at gå til en hæveautomat, jeg tror, en af de deltagende sendte en besked til deltagerne her om at beskytte banksystemet, når du stryger dit kort over, at transaktionsdata stort set er globalt på mainframe. Og at sikre og indsamle sikkerhedsdata og telemetri-data fra mainframes og gøre dem tilgængelige via enten Splunk-dashboards eller andre, Spark, SQL, bliver mere kritisk nu end nogensinde på grund af datamængden og datamængden.
Færdighedssæt er en af de største udfordringer. Fordi du på den ene side har en hurtigt skiftende big data stack, du ved ikke, hvilket projekt der vil overleve, hvilket projekt ikke overlever, skal jeg ansætte Hive eller Pig-udviklere? Bør jeg investere i MapReduce eller Spark? Eller den næste ting, Flink, sagde nogen. Bør jeg investere i en af disse computerplatforme? På den ene side er det en udfordring at holde trit med det hurtigt skiftende økosystem, og på den anden side har du disse gamle datakilder. De nye dygtighedssæt stemmer ikke rigtig sammen, og du har muligvis et problem, fordi disse ressourcer muligvis faktisk går på pension. Der er et stort hul i form af kvalifikationssæt for mennesker, der forstår disse arvede dataklodser, og som forstår den nye teknologistakke.
Den anden udfordring er regeringsførelsen. Når du virkelig får adgang til alle virksomhedsdata på tværs af platforme, har vi kunder, der rejste bekymring for, at “Jeg vil ikke, at mine data skal lande. Jeg vil ikke have, at mine data kopieres flere steder, fordi jeg vil undgå de flere kopier så meget som muligt. Jeg vil have ende-til-ende-adgang uden at lande dem i midten der. ”At styre disse data bliver en udfordring. Og det andet stykke er, at hvis du får adgang til data, som flaskehalser, hvis du samler de fleste af dine data i skyen og får adgang til og henviser til ældre data, bliver netværksbåndbredden et problem, en klyngeplatform. Der er mange udfordringer med hensyn til at have dette big data-initiativ og avancerede analytiske platforme og alligevel udnytte alle virksomhedsdata.
Hvad Syncsort tilbyder er, vi omtales som "simpelthen det bedste" ikke fordi vi simpelthen er de bedste, men vores kunder refererer virkelig til os som simpelthen de bedste til at få adgang til og integrere mainframe-data. Vi understøtter alle dataformater fra mainframe og gør dem tilgængelige til big data-analyse. Uanset om det er på Hadoop eller Spark eller den næste computerplatform. Fordi vores produkter virkelig isolerer kompleksiteten af computerplatformen. Du er som udvikler potentielt ved at udvikle på en bærbar computer, med fokus på datapipeline og hvad er dataforberedelserne, trinene til at gøre disse data oprettet til analysen, den næste fase og tage den samme applikation i MapReduce eller tage det samme applikation i Spark.
Vi hjalp vores kunder med at gøre det, da YARN blev tilgængelig, og de måtte flytte deres applikationer fra MapReduce version 1 til YARN. Vi hjælper dem med at gøre det samme med Apache Spark. Vores produkt, ny udgave 9 kører også med Spark og leveres med en dynamisk optimering, der vil isolere disse applikationer til fremtidige computerrammer.
Så vi har adgang til mainframe-data, hvad enten det er VSAM-filer, uanset om det er DB2, eller om det er telemetri-data, som SMF-poster eller Log4j eller syslogs, der skal visualiseres gennem Splunk-dashboards. Og mens man gør det, fordi organisationen kan udnytte deres eksisterende datatekniker eller ETL-færdigheder, reduceres udviklingstiden markant. Faktisk med Dell og Cloudera var der en uafhængig benchmark sponsoreret, og den benchmark fokuserede på udviklingstid det tager, hvis du laver håndkodning eller bruger andre værktøjer såsom Syncsort, og det var ca. 60, 70 procent reduktion i udviklingstiden . Bridging af færdigheden sætter kløft mellem grupper, på tværs af disse datafilværter, og også disse datafilværter med hensyn til folket.
Normalt taler ikke big data-teamet, eller data-indtaget-teamet, eller det team, der har til opgave at udvikle disse data som en servicearkitektur, ikke nødvendigvis med mainframe-teamet. De ønsker at minimere denne interaktion næsten i mange af organisationerne. Ved at lukke dette hul er vi kommet frem. Og den vigtigste del er virkelig at sikre hele processen. For i virksomheden, når du håndterer denne form for følsomme data, er der mange krav.
I stærkt regulerede brancher som forsikring og bankvæsen spørger vores kunder, sagde de: ”Du tilbyder denne mainframe-datatilgang, og det er fantastisk. Kan du også tilbyde mig at fremstille dette EBCDIC-kodede postformat, der opbevares i det originale format, så jeg kan tilfredsstille mine revisionskrav? ”Så vi får Hadoop og Apache Spark til at forstå mainframe-data. Du kan opbevare dataene i deres originale postformat, udføre din forarbejdnings- og niveaudistributør computerplatform, og hvis du har brug for at sætte det tilbage, kan du vise, at posten ikke er ændret, og postformatet ikke ændres, kan du overholde lovgivningsmæssige krav .
Og de fleste af organisationerne, mens de opretter datahub eller datasø, prøver de også at gøre dette med et enkelt klik for at kunne kortlægge metadata fra hundreder af skemaer i en Oracle-database til Hive-tabeller eller ORC- eller parketfiler bliver nødvendigt. Vi sender værktøjer, og vi leverer værktøjer til at gøre dette til et-trins datatilgang, auto-genererende job eller dataforflytning og auto-genererende job for at gøre datakortlægningen.
Vi talte om forbindelsesdel, overholdelse, styring og databehandling. Og vores produkter er tilgængelige både på stedet og i skyen, hvilket gør det virkelig meget enkelt, fordi virksomhederne ikke behøver at tænke over, hvad der vil ske i det næste år eller to, hvis jeg beslutter at gå fuldstændigt i offentlig sky versus hybrid miljø, da nogle af klyngerne muligvis kører på stedet eller i skyen. Og vores produkter er tilgængelige både på Amazon Marketplace, på EC2, Elastic MapReduce og også til en Docker-container.
Bare til en slags indpakning, så vi har tid nok til spørgsmål og spørgsmål, det handler virkelig om at få adgang til, integrere og overholde datastyringen, men alligevel gøre alt dette enklere. Og mens vi gør dette enklere, "design en gang og implementer hvor som helst" i ægte forstand på grund af vores open source-bidrag, kører vores produkt indfødt i Hadoop-dataflyt og nativt med Spark, der isolerer organisationerne fra det hurtigt skiftende økosystem. Og leverer en enkelt datapipeline, en enkelt grænseflade, både til batch og streaming.
Og dette hjælper også organisationer undertiden med at evaluere disse rammer, fordi du måske faktisk ønsker at oprette applikationer og bare køre på MapReduce versus Spark og se for dig selv, ja, Spark har dette løfte og giver alt det fremskridt med iterative algoritmer, der fungerer til den bedste maskinlæring og forudsigelige analyseprogrammer fungerer med Spark, kan jeg også få min streaming og batch-arbejdsbelastning udført på denne computerramme? Du kan teste forskellige computerplatforme ved hjælp af vores produkter. Og den dynamiske optimering, uanset om du kører på en enkeltstående server, på din bærbare computer, i Google Cloud versus Apache Spark, er virkelig et stort forslag for vores kunder. Og det blev virkelig drevet af de udfordringer, de havde.
Jeg vil bare dække et af casestudierne. Dette er Guardian Life Insurance Company. Og Guardians initiativ var virkelig at centralisere deres dataaktiver og stille dem til rådighed for deres klienter, reducere dataforberedelsestiden og de sagde, at alle taler om dataforberedelse, der tager 80 procent af den samlede databehandlingsrørledning, og de sagde, at det faktisk tog ca. 75 til 80 procent for dem, og de ønskede at reducere dataforberedelsen, transformationstider, tid til marked for analyseprojekter. Opret den smidighed, når de tilføjer nye datakilder. Og gør den centraliserede datatilgang tilgængelig for alle deres klienter.
Deres løsning, inklusive Syncsort-produkter, er lige nu, de har en Amazon Marketplace lookalike datamarked, der understøttes af en datasø, som stort set er Hadoop, og NoSQL-database. Og de bruger vores produkter til at bringe alle dataaktiver til datasøen, inklusive DB2 på mainframe, inklusive VSAM-filer på mainframe, og databasens arvede datakilder såvel som de nye datakilder. Og som et resultat af dette har de centraliseret de genanvendelige dataaktiver, der er søgbare, tilgængelige og tilgængelige for deres klienter. Og de er virkelig i stand til at tilføje de nye datakilder og servicere deres klienter meget hurtigere og mere effektive end før. Og analyseinitiativerne udvikler sig endda mere på den forudsigelige side. Så jeg vil stoppe, og jeg håber, at dette var nyttigt, og hvis du har spørgsmål til mig om nogle af de relaterede emner, så er du velkommen.
Eric Kavanagh: Sure, og Tendü, jeg skal bare smide en ind. Jeg fik en kommentar fra et publikummedlem, der bare sagde: ”Jeg kan godt lide dette 'design en gang, indsætte et vilkårligt sted.'" Kan du slags grave i, hvordan det er sandt? Jeg mener, hvad har du gjort for at aktivere den slags smidighed og er der nogen skat? Som når vi for eksempel taler om virtualisering, er der altid lidt af en skat på ydelse. Nogle mennesker siger to procent, fem procent 10 procent. Hvad du har gjort for at aktivere designet en gang, implementere hvor som helst - hvordan gør du det, og er der nogen skat forbundet med det med hensyn til ydeevne?
Tendü Yogurtçu: Ja, tak. Nej, for i modsætning til nogle af de andre leverandører genererer vi ikke rigtig Hive eller Pig eller en anden kode, der ikke er hjemmehørende i vores motorer. Det var her vores open source-bidrag spillede en enorm rolle, fordi vi har arbejdet med Hadoop-leverandører, Cloudera, Hortonworks og MapR meget tæt, og på grund af vores open source-bidrag kører vores motor faktisk indfødt som en del af strømmen, som en del af Hadoop-strømmen, som en del af gnisten.
Hvad der også oversættes, vi har denne dynamiske optimering. Dette var noget, der kom som et resultat af, at vores kunder blev udfordret med computerrammer. Da de gik i produktion med nogle af applikationerne, kom de tilbage, sagde de: ”Jeg stabiliserer bare min Hadoop-klynge, stabiliserer på MapReduce YARN version 2, MapReduce version 2, og folk taler om, at MapReduce er død, Spark er den næste ting, og nogle mennesker siger, at Flink vil være den næste ting, hvordan skal jeg klare dette? ”
Og disse udfordringer blev virkelig så indlysende for os, vi investerede i at have denne dynamiske optimering, vi omtaler som intelligent udførelse. På kørselstidspunktet, når jobbet, når denne datapipeline leveres, baseret på klyngen, om det er Spark, om det er MapReduce eller en Linux-standalone-server, beslutter vi, hvordan vi kører dette job, naturligt i vores motor, som en del af det Hadoop eller gnist dataflow. Der er ingen faste omkostninger, fordi alt sker gennem denne dynamiske optimering, vi har, og alt er også gjort, fordi vores motor er så indbygget integreret på grund af vores open source-bidrag. Besvarer det dit spørgsmål?
Eric Kavanagh: Ja, det er godt. Og jeg vil kaste endnu et spørgsmål derovre, og så kan Dez, måske også vi trække dig og Robin ind. Jeg fik lige en sjove kommentar fra en af vores deltagere. Jeg læser det, fordi det virkelig er ret småt. Han skriver, "Det ser ud til, at i historien om ting, HET" - får det? Som IoT - "er det, at jo mere du prøver at 'forenkle' noget, der er virkelig komplekst, oftere end ikke, det enklere det ser ud til at gøre ting, der leveres mere hængende reb. Tænk databaseforespørgsel, eksplosion, flertråd osv. ”Kan du kommentere dette paradoks, som han refererer til? Enkelhed kontra kompleksitet, og hvad er der egentlig dyre under skindene?
Tendü Yogurtçu: Sure. Jeg synes, det er et meget gyldigt punkt. Når du forenkler tingene og udfører disse optimeringer, på en måde under dækkene, er der nogen, der behøver at tage den kompleksitet, hvad der skal ske, ikke? Hvis du lammer noget, eller hvis du beslutter, hvordan du kører et bestemt job med hensyn til computerrammen, er der naturligvis en del af jobbet, der skubbes, uanset om det er ved brugerens slutning, menukodning eller det er ved motoroptimering. Der er en del af det, ved at forenkle ved brugeroplevelsen er der en enorm fordel med hensyn til at kunne udnytte de færdigheder, der findes i virksomheden.
Og du kan slags afbøde det paradoks, afbøde den udfordring, "Ja, men jeg har ikke kontrol over alt, hvad der sker under dækslet, under hætten i den motor, " ved at udsætte ting for de mere avancerede brugere, hvis de vil have den slags kontrol. Ved også at investere i nogle af de forskellige servicetyper af ting. At kunne tilbyde mere operationelle metadata, mere operationelle data, som i eksemplet, som deltageren gav, til en SQL-forespørgsel såvel som med motoren i gang. Jeg håber det svarer.
Eric Kavanagh: Ja, det lyder godt. Dez, tag det væk.
Dez Blanchfield: Jeg er virkelig ivrig efter at få lidt mere indsigt i dit fodaftryk i open source-bidrag og rejsen, som du har taget fra din traditionelle, langvarige oplevelse i mainframe og den proprietære verden og derefter skiftet til at bidrage til open source, og hvordan det foregik. Og den anden ting, jeg er interesseret i at forstå, er det syn, du ser, at virksomheder, ikke kun IT-afdelinger, men virksomheder tager nu med hensyn til datahubber eller datasøer, som folk siger nu, og om de ser denne tendens til bare en enkelt, konsolideret datasø, eller om vi ser distribuerede datasøer, og folk bruger værktøjer til at sammensætte dem?
Tendü Yogurtçu: Sure. For den første var det en meget interessant rejse som indehaver af softwarevirksomhed, en af de første efter IBM. Dog igen, alt begyndte med, at vores evangelistkunder så på Hadoop. Vi havde datafirmaer som ComScore, de var en af de første, der vedtog Hadoop, fordi de indsamlede digitale data over hele kloden og ikke var i stand til at opbevare 90 dages data, medmindre de investerede en datavarehusboks på ti millioner dollars i deres miljø. De begyndte at se på Hadoop. Med det begyndte vi også at se på Hadoop.
Og da vi tog en beslutning og erkendte, at Hadoop virkelig vil være fremtidens dataplatform, kom vi også til forståelsen af, at vi ikke vil være i stand til at spille dette, et vellykket spil i dette, medmindre vi var en del af økosystemet. Og vi arbejdede meget tæt med Hadoop-leverandører, med Cloudera, Hortonworks, MapR osv. Vi begyndte virkelig at tale med dem, fordi partnerskab bliver meget vigtigt for at validere den værdi, en leverandør kan give, og sørger også for, at vi sammen kan gå til virksomheden og tilbyde noget mere meningsfuldt. Det krævede en masse relationsopbygning, fordi vi ikke var kendt af Apache open source-projekter, men vi havde stor støtte fra disse Hadoop-leverandører, må jeg sige.
Vi begyndte at arbejde sammen og kiggede på huben, hvordan vi kan skabe værdi uden endda vores indehaveren software i rummet. Det var vigtigt. Det handler ikke kun om at sætte nogle API'er, som dit produkt kan køre på, det er for at kunne sige, at jeg vil investere i dette, fordi jeg tror, Hadoop vil være en fremtidens platform, så ved at investere i de kilder, vi ønskede at lave sikker på, at det modnes og bliver virksomheds klar. Vi kan faktisk aktivere nogle af de brugssager, der ikke var tilgængelige før vores bidrag. Det vil gavne hele økosystemet, og vi kan udvikle disse partnerskaber meget tæt.
Det tog ganske lang tid. Vi begyndte at bidrage i 2011 og 2013, den 21. januar - jeg kan huske datoen, fordi den dato blev forpligtet for vores største bidrag, hvilket betød, at vi nu kan have vores produkter generelt tilgængelige fra det tidspunkt - det tog ganske lang tid at udvikle disse relationer, viser værdien, partnere bliver designpartnere med leverandørerne og med pendlerne i open source-samfundet. Men det var meget sjovt. Det var meget givende som et selskab for os at være en del af det økosystem og udvikle et stort partnerskab.
Det andet spørgsmål om datahub / datasø, tror jeg, når vi ser disse data som en serviceimplementering i de fleste tilfælde, ja, det kan være klynger, fysisk enkelt eller flere klynger, men det er mere konceptuelt end at blive det samme sted for alle data. Fordi vi i nogle organisationer ser store klyngedepositioner på stedet, men de har også klynger, for eksempel i den offentlige sky, fordi nogle af de data, der er indsamlet fra online sektioner, virkelig opbevares i skyen. Det er i stand til at have en enkelt datapipeline, som du faktisk kan udnytte begge disse, og bruge dem som et enkelt datahub, enkeltdatasø, bliver vigtigt. Ikke nødvendigvis bare det fysiske sted, men det at være datahub og datasø på tværs af klynger, på tværs af geografier og måske på præmis og sky vil være meget kritisk, synes jeg. Især fremad. I år begyndte vi at se flere og flere skyinstallationer. Det er fantastisk. Første halvår af dette år har vi hidtil set en masse skyudvidelser.
Eric Kavanagh: Okay, cool. Og Robin, har du spørgsmål? Jeg ved, at vi bare har et par minutter tilbage.
Robin Bloor: Okay, jeg kan stille et spørgsmål til hende. Den første ting, der opstod for mig, er, at der har været en masse spænding ved Kafka, og jeg var interesseret i din mening om Kafka, og hvordan du integrerer dig med den måde, folk bruger Kafka på?
Tendü Yogurtçu: Sure. Ja, Kafka bliver meget populær. Blandt vores kunder ser vi, at det at være slags datatransportlag og se, at dataene er en bus, stort set. For eksempel brugte en af vores kunder faktisk en form for konsumerende data, der skubbes ind i denne Kafka blandt flere, som tusinder af online-brugere og kunne klassificere det og skubbe igennem.
Igen er Kafka en databus til de forskellige forbrugere af disse data. Klassificere nogle avancerede brugere kontra ikke-så-avancerede brugere og gør noget andet fremad i den datapipeline. Hvordan vi integrerer med Kafka er dybest set, vores produkt DMX-h bliver en pålidelig forbruger, en meget effektiv, pålidelig forbruger for Kafka. Det kan læse dataene, og dette er ikke anderledes end at læse data fra nogen anden datakilde for os. Vi giver brugerne mulighed for at kontrollere vinduet enten med hensyn til det tidsbehov, de har, eller antallet af meddelelser, som de muligvis spiser fra Kafka-bussen. Og så kan vi også gøre berigelse af disse data, når de går gennem vores produkt og skubbes tilbage til Kafka. Vi har testet dette. Vi har benchmarket det på kundesite. Også certificeret af Confluent. Vi arbejder tæt sammen med Confluent fyre, og det er meget højtydende og let at bruge. Igen ændrer API'erne sig, men du behøver ikke at bekymre dig, fordi produktet virkelig behandler det som bare en anden datakilde, en streaming-datakilde. Det er ret sjovt at arbejde med vores produkt og Kafka, faktisk.
Robin Bloor: Okay, jeg har et andet spørgsmål, som bare er et generelt forretningsspørgsmål, men jeg har kendt Syncsort i lang tid, og du har altid haft omdømme og leveret ekstraordinær hurtig software til ETL og mainframe-verdenen. Er det sådan, at det meste af din virksomhed nu overføres til Hadoop? Er det tilfældet, at du på en eller anden måde spredt din virksomhed ret dramatisk fra mainframe-verdenen?
Tendü Yogurtçu: Vores mainframe-produkter kører stadig 50 procent af mainframes globalt. Så vi har en meget stærk mainframe-produktlinie ud over, hvad vi laver på big data og Hadoop-enden. Og vi er stadig i de fleste af IT-forenklings- eller optimeringsprojekterne, fordi der er en ende, som du vil være i stand til at udnytte dine mainframe-data i big data-multex-platforme og udnytte alle virksomhedsdata, men der er også meget kritiske transaktionsmæssige arbejdsmængder der fortsætter med at køre på mainframe, og vi tilbyder disse kunder måder til virkelig at gøre disse applikationer mere effektive, køre i zIIP-motoren, så de ikke bruger så meget behandlingscyklusser og MIPS, der gør dem omkostningseffektive.
Vi fortsætter med at investere i mainframe-produkterne og spiller faktisk ind i dette rum, hvor folk går fra mainframe big iron til big data og spænder over produktlinien også på tværs af disse platforme. Så vi flytter ikke nødvendigvis hele virksomheden til den ene side, vi fortsætter med at have en meget succesrig forretning på begge sider. Og opkøbene er også et stort fokus for os. Efterhånden som denne databehandlings- og databehandlingsplads til store dataplatformer udvikler sig, er vi også forpligtet til at foretage en hel del gratis opkøb.
Robin Bloor: Jeg kan vel ikke spørge dig, hvad de er, fordi du ikke ville have lov til at fortælle mig det. Jeg er interesseret i, om du har set mange implementeringer af Hadoop eller Spark faktisk på mainframe, eller om det er en meget sjælden ting.
Tendü Yogurtçu: Vi har ikke set noget. Der er mere spørgsmål om det. Jeg tror, Hadoop på mainframe ikke gav meget mening på grund af den slags kernestruktur. Men Spark på mainframe er ganske meningsfuldt, og Spark er virkelig meget godt med maskinlæring og forudsigelig analyse og det at kunne have nogle af disse applikationer med mainframe-data er virkelig, synes jeg, ganske meningsfuld. Vi har ikke set nogen gøre det endnu, men det er virkelig brugen, der kører disse ting. Hvis din brugssag som virksomhed mere bringer disse mainframe-data og integrerer sig med resten af datasættene i big data-platformen, er det en historie. Det kræver adgang til mainframe-data fra Bigtex Multex-platformen, fordi du usandsynligt vil bringe dine datasæt fra åbne systemer og kaldes tilbage til mainframe. Men hvis du har nogle mainframe-data, du bare vil udforske og udføre en lille smule af dataudforskningsopdagelse, anvende nogle avancerede AI og avancerede analyser, kan Spark muligvis være en god måde at gå på og køre på mainframe som det.
Eric Kavanagh: Og her er endnu et spørgsmål fra publikum, faktisk to mere. Jeg giver dig et spørgsmål om tag-team, så vil vi samle op. En deltager spørger: “Integrerer IBM dine open source-bidrag i dets offentlige cloud-økosystem, med andre ord Bluemix?” Og en anden deltager gjorde et rigtig godt punkt og bemærkede, at Syncsort er fantastisk til at holde stort jern i live for dem, der har allerede det, men hvis virksomheder opgiver nye mainframes til fordel for det, han kalder CE, skyer alt op, at det sandsynligvis vil falde, men bemærker, at I fyre virkelig er gode til at flytte data ved at omgå operativsystemer op til en gigabyte per sekund. Kan du tale om din kernestyrke, som han nævnte, og om IBM integrerer dine ting i Bluemix eller ej?
Tendü Yogurtçu: Med IBM er vi allerede partnere med IBM, og vi havde diskussioner om deres dataskydtjenester, der tilbyder produktet. Vores open source-bidrag er åbne for alle, der ønsker at udnytte dem. Nogle af mainframe-forbindelserne er også tilgængelige i Spark-pakker, så ikke kun IBM. Alle kan udnytte dem. I Bluemix har vi ikke gjort noget specifikt om det endnu. Og har du noget imod at gentage det andet spørgsmål?
Eric Kavanagh: Ja, det andet spørgsmål handlede om dit kerneområde for funktionalitet i årenes løb, som virkelig håndterede flaskehalse af ETL, og det er åbenlyst noget, som I stadig vil gøre som mainframes, ja, teoretisk holde sig væk, selvom Dez's punkt er stadig slags rocking og rullende derude. Men deltageren bemærkede netop, at Syncsort er meget god til at flytte data ved at omgå operativsystemer og op til en gigabyte et sekund. Kan du bare kommentere det?
Tendü Yogurtçu: Ja, virkelig en samlet ressourceeffektivitet har været vores styrke, og skalerbarheden og ydeevnen har været vores styrke. Vi går ikke på kompromis, forenkling har mange betydninger, vi går ikke på kompromis med dem. Da folk begyndte at tale om Hadoop i 2014, for eksempel, så mange af organisationerne ikke rigtig på udførelsen. De sagde: "Åh, hvis der sker noget, kan jeg tilføje et par par noder, og jeg har det godt, ydeevne er ikke mit krav."
Mens vi talte om at have den bedste ydelse, fordi vi allerede løb indfødte, havde vi ikke engang nogle af de oprindelige hikke, som Hive havde med flere MapReduce-job og omkostninger med at starte dem. Folk sagde til os, ”Åh, det er ikke min bekymring, så fortvivl ikke om det i øjeblikket.”
Da vi kom til 2015, er landskabet ændret, fordi nogle af vores kunder allerede overskred det lager, de havde i deres produktionsklynger. Det blev meget kritisk for dem at se, hvad Syncsort kan tilbyde. Hvis du tager nogle data fra en database eller mainframe og skriver til et parketformat i klyngerne, uanset om du lander og scene, og foretager en anden transformation eller bare gør inflight-transformationen og landede målfilformat, gjorde du en forskel, fordi du gemmer fra lagring, du sparer fra netværksbåndbredde, du sparer fra arbejdsmængden i klyngen, fordi du ikke kører ekstra job. De styrker, som vi spiller med hensyn til at være meget bevidste, vi føler ressourceeffektiviteten under vores hud, ser det ud til.
Sådan beskriver vi det. Det er kritisk for os. Vi tager det ikke for givet. Vi har aldrig taget det for givet, så vi vil fortsat være stærke med den gearing i Apache Spark eller den næste computerramme. Det vil fortsat være vores fokus. Og med hensyn til databehandlingsstykket og datatilgangsstykket er det bestemt en af vores styrker, og vi får adgang til DB2- eller VSAM-data på mainframes i sammenhæng med Hadoop eller Spark.
Eric Kavanagh: Det er en god måde at afslutte webcast, folkens. Tak så meget for din tid og opmærksomhed. Tak til dig, Tendü og Syncsort, for at du kom ind i briefing-rummet og trådte ind i runden, som de siger. En masse gode spørgsmål fra publikum. Det er et stadigt bevægende miljø derude, folkens. Vi arkiverer denne Hot Tech, som vi gør med alle de andre. Du kan finde os på insideanalysis.com og på techopedia.com. Normalt går det op om en dag. Og med det tager vi farvel, folkens. Mange tak. Vi taler snart. Pas på. Hej hej.
