Av Techopedia Staff, 2. juni 2016
Takeaway: Hadoop-økosystemet brukes på stormaskiner for å behandle big data raskt og effektivt.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, mine damer og herrer, klokka er fire øst på en torsdag, og i disse dager betyr det selvfølgelig at det er tid for Hot Technologies. Ja, jeg heter Eric Kavanagh. Jeg vil være din moderator for dagens webseminar. Det er gode ting, folkens, “Big Iron, Meet Big Data” - Jeg bare elsker den overskriften - “Liberating Mainframe Data with Hadoop and Spark.” Vi skal snakke om gamle møter nye. Wow! Vi dekker spekteret av alt vi har snakket om i løpet av de siste 50 årene med IT-selskap. Spark møter mainframe, jeg elsker det.
Det er et sted om deg virkelig og nok om meg. Året er varmt. Vi snakker om varme temaer i denne serien fordi vi virkelig prøver å hjelpe folk til å forstå bestemte fagområder, bestemte områder. Hva betyr det å for eksempel ha en analytisk plattform? Hva betyr det å frigjøre big data fra mainframes? Hva betyr alt dette? Vi prøver å hjelpe deg med å forstå spesifikke typer teknologier, hvor de passer inn i blandingen og hvordan du kan bruke dem.
Vi har to analytikere i dag og da selvfølgelig Tendü Yogurtçu fra Syncsort. Hun er en visjonær i vårt rom, veldig glad for å ha henne online i dag, med vår egen Dez Blanchfield og Dr. Robin Bloor. Jeg sier bare et par kjappe ord. Det ene er at folk spiller en stor rolle i denne prosessen, så vær ikke sjenert med å stille noen gode spørsmål. Vi vil gjerne komme til dem under spørsmål og svar på webcasten, som vanligvis er på slutten av showet. Og alt jeg må si er at vi har mye bra innhold, så jeg er spent på å høre hva disse guttene har å si. Og med det skal jeg overlevere det til Dez Blanchfield. Dez, gulvet er ditt, ta det bort.
Dez Blanchfield: Takk, Eric, og takk alle for deltakelsen i dag. Så jeg blir ganske spent når jeg får en sjanse til å snakke om en av mine favoritt ting i verden, mainframes. De får ikke mye kjærlighet i disse dager. Mitt syn er mainframe var den opprinnelige big data-plattformen. Noen vil hevde at de var den eneste datamaskinen den gangen, og det er et rimelig poeng å gjøre, men i over 60 år nå har de virkelig vært maskinrommet til det store data har vært populært for sent. Og jeg skal ta deg med på en liten reise på hvorfor jeg tror det er tilfelle.
Vi har sett en reise i teknologimaskinvarestablene i forbindelse med stormaskiner skifte fra bildet du ser på skjermen nå. Dette er en gammel FACOM mainframe, en av favorittene mine. Vi har beveget oss gjennom den store jernfasen, sent på nittitallet og dot-com-boom. Dette er Sun Microsystems E10000. Denne tingen var et absolutt monster på 96 prosessorer. Opprinnelig 64, men det kan oppgraderes på 96 prosessorer. Hver CPU kunne kjøre 1.024 tråder. Hver tråd kan være på påføringshastighet samtidig. Det var bare uhyrlig og den drev faktisk dot-com-boom. Dette er alle de store enhjørningene som vi kaller dem, nå kjører vi, og ikke bare de store bedriftene, noen av de store nettstedene.
Og så endte vi opp med denne vanlige PC-modellen utenom sokkelen. Vi bare festet mange billige maskiner sammen, og vi opprettet en klynge, og vi nærmet oss den store jernutfordringen og det som ble big data, spesielt i form av Hadoop-prosjektet som stammer fra open source-søkemotoren, Nutch. Og vi gjenskapt hovedrammen og mange små CPUer som ble limt sammen og kunne fungere som L-baner og i form av å kjøre separate jobber eller deler av jobber, og de var ganske effektive på mange måter. Billigere hvis du startet mindre, men alltid har mange av disse store klyngene blitt dyrere enn en hovedramme.
Mitt syn på disse tingene er at i hastverket fra dot-com-boomet til det som ble Web 2.0, og som nå jager enhjørninger, har vi glemt at det er denne plattformen som fremdeles driver mange av våre største misjonskritiske systemer der ute. Når vi tenker på hva som kjører på stormaskinplattformene der ute. Det er veldig mye big data, spesielt data arbeidshesten, men absolutt big data. Tradisjonelle virksomhets- og regjeringssystemer som bank- og formuesforvaltning og forsikring, bruker vi alle hver dag.
Luftfartsbooking og flystyringssystemer, spesielt flystyring der sanntid er kritisk. Nesten hver stat og føderal regjering har på et tidspunkt hatt en hovedramme, og alltid har mange fortsatt dem. Detaljhandel og produksjon. Noe av den gamle programvaren som nettopp har eksistert og aldri har gått bort. Fortsetter bare til kraftproduserende miljøer og absolutt detaljhandel i skala. Medisinske systemer. Forsvarssystemer, absolutt forsvarssystemer.
I løpet av de siste ukene har jeg lest mange artikler om det faktum at noen av rakettkontrollsystemene fremdeles kjører på gamle stormaskiner de sliter med å finne deler til. De finner ut hvordan du kan oppgradere til nye mainframes. Transport- og logistikksystemer. Dette høres kanskje ikke ut som de sexy temaene, men dette er temaene vi behandler daglig på tvers av linjene. Og noen veldig store telekommunikasjonsmiljøer kjøres fortsatt på stormaskinplattformer.
Når du tenker på hvilke typer data som er der, er de alle oppdragskritiske. Det er veldig viktige plattformer og plattformer vi tar for gitt hver dag og på mange måter gjør livet mulig. Så hvem bruker fremdeles en stordamme og hvem er alle disse menneskene som holder fast på disse store plattformene og har alle disse dataene? Vel, som jeg sa her, jeg tror det er lett å la seg lure av medienes skifte fra stort jern til stativer av vanlige klynger eller billige PC-er eller x86-maskiner, til å tenke at hovedrammen døde og gikk bort. Men dataene sier at stordammen aldri gikk bort, og at den faktisk er her for å bli.
Forskningen jeg har satt sammen her de siste par ukene, har vist at 70 prosent av data fra foretaket, spesielt store foretak, fremdeles ligger på en hovedramme av en eller annen form. Sytti prosent av Fortune 500-tallet kjører fortsatt kjernevirksomhetssystemer på mainframes et sted. Faktisk, her i Australia, har vi en rekke organisasjoner som har et datasenter midt i en by. Det er en faktisk underjordisk datamaskin effektivt, og antall stormaskiner som bare kjører der, tikker og gjør jobben sin lykkelig. Og veldig få mennesker vet at det å gå rundt i gatene, rett under føttene i en bestemt del av byen, er dette enorme datasenteret fylt med stordammer. Nittito av 100 av bankene rundt om i verden, de 100 beste bankene som er, driver fremdeles banksystemer på stormaskiner. Tjuetre av de 25 største detaljhandlekjedene rundt om i verden bruker stormaskiner for fortsatt å drive detaljstyringssystemer i EIP og BI-plattformer.
Interessant nok driver 10 av de 10 beste forsikringsselskapene fortsatt plattformene sine på mainframe, og de driver faktisk sine skytjenester på mainframe. Hvis du bruker et webgrensesnitt eller en mobilapp et sted det er mellomvare et grensesnitt er, som faktisk snakker med noe veldig tungt og stort i bakenden.
Jeg fant over 225 statlige og lokale myndigheter over hele verden som kjører på stormaskinplattformer. Jeg er sikker på at det er mye grunn til det. Kanskje de ikke har budsjett til å vurdere nytt jern, men det er et enormt fotavtrykk av veldig store miljøer som kjører på mainframe med noen veldig kritiske data. Og som jeg nevnte tidligere, de fleste nasjoner kjører fremdeles sine sentrale forsvarssystemer på mainframe. Jeg er sikker på at på mange måter de prøver å komme seg dit, men dit du går.
I 2015 gjennomførte IDC en undersøkelse, og 350 av de spurte CIOene rapporterte at de fremdeles eide og administrerte stort jern i form av stordammer. Og det slo meg at det sannsynligvis er mer enn antallet store Hadoop-klynger som for tiden kjører over hele verden i produksjon - en interessant liten stat der. Jeg kommer til å gå foran og validere det, men det var et stort tall. Tre hundre femti CIOs rapporterte at de fortsatt har en eller flere hovedrammer.
I fjor, 2015, ga IBM oss den mektige Z13, den 13. iterasjonen av deres mainframe-plattform. Mediene gikk vill på dette fordi de ble forbløffet over at IBM fortsatt lager mainframes. Da de løftet hetten og så på hva som var under tingen, skjønte de at det faktisk var på nivå med nesten alle moderne plattformer som vi hadde blitt begeistret for i form av big data, Hadoop og absolutt klyngene. Denne tingen kjørte Spark og nå Hadoop innfødt. Du kan kjøre tusenvis av tusenvis av Linux-maskiner på det, og det så ut og føltes som enhver annen klynge. Det var ganske utrolig maskin.
En rekke organisasjoner tok opp disse tingene, og faktisk gjorde jeg noen data om hvor mange av disse maskinene som tar opp. Nå har jeg hatt den oppfatningen at 3270 tekstterminal har blitt erstattet av nettlesere og mobilapper i noen tid, og det er rikelig med data som støtter det. Jeg tror at nå går vi inn i en epoke hvor vi har innsett at disse hovedbildene ikke forsvinner, og det er en betydelig mengde data om dem. Og det vi gjør nå er ganske enkelt å legge til det jeg kaller analyseverktøy utenfor hylla. Dette er ikke spesialbyggede apper. Dette er ting som er skreddersydde engangsforhold. Dette er ting du bokstavelig talt bare kan kjøpe i en pakke i seg selv og koble deg til mainframe og gjøre noen analyser.
Som jeg sa før, faktisk stod hovedrammen i over 60 år. Når vi tenker på hvor lang tid det er, er det lengre enn de fleste levende IT-profesjonelle karrierer faktisk spenner over. Og faktisk sannsynligvis noen av livene deres, til og med. I 2002 solgte IBM 2300 mainframes. I 2013 vokste det til 2700 mainframes. Det er 2.700 salg av mainframes på ett år i 2013. Jeg kunne ikke få nøyaktige data om 2015, men jeg ser for meg at det raskt kommer nær de 3000 solgte enhetene i året i 2013, 2013. Og jeg ser frem til å kunne bekrefte det.
Med utgivelsen av Z13, den 13. iterasjonen av en hovedramme-plattform, som jeg tror kostet dem rundt 1, 2 eller 1, 3 milliarder dollar å utvikle seg fra bunnen av, IBM, det vil si, her er en maskin som ser ut og føles akkurat som enhver annen klynge som vi har i dag, og driver innfødt Hadoop og Spark. Og kan sikkert kobles til fra andre analyse- og big data-verktøy eller alltid være koblet til en av dine eksisterende eller nye Hadoop-klynger. Jeg har denne oppfatningen at å inkludere stormaskinplattformen i big data-strategien er et must. Selvfølgelig, hvis du har en, har du mye data, og du vil finne ut hvordan du kan få det derfra. Og de får lov til å samle støv på mange måter, mentalt og følelsesmessig så langt næringslivet går, men de er her for å bli.
Tilkoblingsmuligheter og grensesnitt for alle analyseverktøyene dine til mainframe-vert data skal være en sentral del av bedriften og spesielt regjeringen av store dataplaner. Og alltid legger merke til at programvare legger merke til dem, tar en god titt på dem og innser hva som er inni disse tingene og forbinder sinn som begynner å få litt innsikt og litt følelse av hva som faktisk er under panseret. Og med det skal jeg overlate til min kjære kollega, Dr. Robin Bloor, og han vil legge til den lille reisen. Robin, ta den bort.
Robin Bloor: Tusen takk. Ok, siden Dez har sunget sangen til mainframe, skal jeg gå inn på hva jeg tror skjer i form av den gamle mainframe-verdenen og den nye Hadoop-verdenen. Jeg antar at det store spørsmålet her er, hvordan håndterer du alle dataene? Det er ikke min mening at mainframe blir utfordret med hensyn til big data-evnen - dens big data-evne er ekstremt, som Dez har påpekt, den er ekstremt dyktig. Faktisk kan du sette Hadoop-klynger på det. Hvor det blir utfordret er i form av dets økosystem, og jeg vil litt utdype det.
Her er noen mainframe-posisjonering. Det har en høy oppføringskostnad, og hva som faktisk har skjedd i det siste, siden midten av 90-tallet, da populariteten til stormaskinene begynte å synke, hadde det en tendens til å ha mistet den lave enden, de menneskene som hadde kjøpt billige mainframes og det var ikke Det er egentlig ikke spesielt økonomisk for disse menneskene. Men høyere opp faktisk i mellomområdet og høye rekkevidden for stordammen det fremdeles var, og det er tydeligvis faktisk utrolig billig databehandling.
Det ble, må det sies, reddet av Linux fordi Linux implementert på en mainframe gjorde det selvfølgelig mulig å kjøre alle Linux-applikasjoner. Mange Linux-applikasjoner gikk dit før big data til og med var et ord, eller to ord antar jeg. Det er faktisk en ganske utmerket plattform for privat sky. På grunn av det kan den delta i hybrid sky-distribusjoner. Et av problemene er at mainframe ferdigheter er mangelvare. Mainframe-ferdighetene som eksisterer er faktisk aldring i den forstand at folk forlater bransjen for pensjonisttilværelse år etter år, og at de bare blir byttet ut med tanke på antall personer. Så det er et problem. Men det er fremdeles billig databehandling.
Området der det selvfølgelig er blitt utfordret, er hele Hadoop. Det er et bilde av Doug Cutting med den originale Hadoop-elefanten. Hadoop-økosystemet er - og det kommer til å forbli - det dominerende big data-økosystemet. Det gir bedre skala ut enn mainframe faktisk kan oppnå, og det er lavere kostnader som en datalager på en lang måte. Hadoop-økosystemet er i utvikling. Den beste måten å tenke på dette på er en gang en bestemt maskinvareplattform og driftsmiljøet med det blir dominerende, da blir økosystemet bare levende. Og det skjedde med IBMs hovedramme. Vel, senere skjedde med Digital VAX, skjedde med Suns servere, skjedde med Windows, skjedde med Linux.
Og det som skjedde er at Hadoop, som jeg alltid tenker på, eller liker å tenke på, som et slags distribuert miljø for data, økosystemet utvikler seg til en utrolig hastighet. Jeg mener at hvis du bare nevner de forskjellige imponerende bidragene som er åpen kildekode, Spark, Flink, Kafka, Presto, og så legger du til at noen av databasene, NoSQL og SQL-funksjonene som nå sitter på Hadoop. Hadoop er det mest aktive økosystemet som faktisk eksisterer der ute, absolutt innen bedriftens databehandling. Men hvis du ønsker å behandle den som en database, bærer den bare ingen sammenligning for øyeblikket med det jeg pleier å tenke på som ekte databaser, spesielt på datalagerområdet. Og det forklarer til en viss grad suksessen til en rekke av de store NoSQL-databasene som ikke kjører på Hadoop som CouchDB og så videre.
Som en datasjø har den et langt rikere økosystem enn noen annen plattform, og det kommer ikke til å bli fortrengt fra det. Økosystemet er ikke bare åpen kildekode. Det er nå et dramatisk antall programvaremedlemmer som har produkter som er fundamentalt bygget for Hadoop eller som er importert til Hadoop. Og de har nettopp opprettet et økosystem som det ikke er noe som kan konkurrere med det når det gjelder bredden. Og det betyr virkelig at det har blitt plattformen for innovasjon av big data. Men etter min mening er det fremdeles umoden, og vi kan ha lange diskusjoner om hva som er og ikke er, la oss si, operativt modent med Hadoop, men jeg tror de fleste som ser på dette spesielle området, er godt klar over at Hadoop ligger flere tiår bak mainframe når det gjelder driftsevne.
Den utviklende datasjøen. Datasjøen er en plattform av enhver definisjon, og hvis du tenker på å være et datalag i bedriftsdataark, er det veldig enkelt å tenke på det når det gjelder de faste databasene pluss datasjøen som utgjør datasjiktet. Data Lake applikasjoner er mange og varierte. Jeg har fått et diagram her som bare går gjennom de forskjellige datavridende tingene som må gjøres hvis du bruker Hadoop som iscenesettelsesområde eller Hadoop og Spark som iscenesettelsesområde. Og du har det hele - datelinje, datarensing, metadatastyring, oppdagelse av metadata - det kan brukes til ETL selv, men krever ofte at ETL tar dataene inn. Master data management, forretningsdefinisjoner av data, service management of hva som skjer i Hadoop, livssyklusstyring av data og ETL ut av Hadoop, og du har også direkte analyseprogrammer som du kan kjøre på Hadoop.
Og det er derfor det har blitt veldig kraftig og der det er implementert og implementert vellykket, normalt har det i det minste en samling av disse typer applikasjoner som kjører på toppen av det. Og de fleste av disse applikasjonene, spesielt de som jeg har blitt orientert om, er de bare ikke tilgjengelige på hovedrammen akkurat nå. Men du kan kjøre dem på mainframe, på en Hadoop-klynge som kjørte i en partisjon av mainframe.
Datasjøen blir etter min mening det naturlige iscenesettelsesområdet for rask databaseanalyse og for BI. Det blir stedet der du tar inn dataene, enten det er bedriftsdata eller eksterne data, roter deg med dem til det er, la oss si, rent nok til å bruke og godt strukturert for å bruke og så videreformidler du det. Og alt dette er fremdeles i sin spede begynnelse.
Ideen, etter min mening, om mainframe / Hadoop-sameksistens, den første tingen er at det er lite sannsynlig at store selskaper vil forlate mainframe. Faktisk tyder indikasjonene på at jeg nylig har sett at det er en økende investering i stormaskin. Men de kommer ikke til å ignorere Hadoop-økosystemet heller. Jeg ser tall på 60 prosent av store selskaper som bruker Hadoop, selv om mange av dem bare prototyper og eksperimenterer.
Forstyrrelsen er da, "Hvordan får du disse to tingene til å eksistere sammen?" Fordi de trenger å dele data. Data som blir ført inn i datasjøen de trenger for å overføre til mainframe. Data som er på hovedrammen, kan trenge å gå til datasjøen eller gjennom datasjøen for å bli knyttet til andre data. Og det kommer til å skje. Og det betyr at det krever rask dataoverføring / ETL-evne. Det er lite sannsynlig at arbeidsmengder vil bli delt dynamisk i, la oss si, et stormaskinmiljø eller med noe i et Hadoop-miljø. Det blir data som deles. Og flertallet av data kommer uunngåelig til å ligge på Hadoop ganske enkelt fordi det er den laveste kostnadsplattformen for det. Og den endelige-til-ende analytiske behandlingen vil sannsynligvis ligge der også.
Oppsummert, til syvende og sist må vi tenke i form av et bedriftsdatasjikt, som for mange selskaper vil inkludere hovedrammen. Og det datalaget må administreres proaktivt. Ellers vil de to ikke eksistere godt. Jeg kan gi ballen tilbake til deg Eric.
Eric Kavanagh: Igjen, Tendü, jeg har nettopp gjort deg til programleder, så ta den bort.
Tendü Yogurtçu: Takk, Eric. Takk for at jeg fikk komme. Hei alle sammen. Jeg vil snakke om Syncsort-opplevelsen med kundene i forhold til hvordan vi ser dataene som et aktivum i organisasjonen er jevnet fra mainframe til big data på analyseplattformer. Og jeg håper at vi også får tid på slutten av økten til å ha spørsmål fra publikum, for det er virkelig den mest verdifulle delen av disse websendingene.
Bare for folk som ikke vet hva Syncsort gjør, er Syncsort et programvareselskap. Vi har eksistert i over 40 år. Startet på mainframe-siden, og produktene våre spenner fra mainframe til Unix til big data-plattformer, inkludert Hadoop, Spark, Splunk, både på premiss og i skyen. Vårt fokus har alltid vært på produktprodukter, databehandlingsprodukter og dataintegrasjonsprodukter.
Strategien vår med hensyn til big data og Hadoop har virkelig vært å bli en del av økosystemet fra første dag. Som innehavere av leverandører som virkelig har vært fokusert på databehandling med veldig lette motorer, trodde vi at det var en stor mulighet til å delta i at Hadoop ble en databehandlingsplattform og være en del av denne neste generasjons datavarehusarkitektur for organisasjonen. Vi har vært en bidragsyter til open source Apache-prosjektene siden 2011, med MapReduce. Har vært i topp ti for Hadoop versjon 2, og deltatt faktisk i flere prosjekter, inkludert Spark-pakker, noen av kontaktene våre er publisert i Spark-pakker.
Vi utnytter vår veldig lette databehandlingsmotor som er helt flat-filbaserte metadata, og passer veldig godt med de distribuerte filsystemene som Hadoop Distribuerte filsystem. Og vi utnytter arven vår på stordammen, vår ekspertise med algoritmer når vi legger ut big data-produktene våre. Og vi samarbeider veldig tett med de store leverandørene, de store aktørene her inkludert Hortonworks, Cloudera, MapR, Splunk. Hortonworks kunngjorde nylig at de vil selge vårt produkt for ETL ombord med Hadoop. Med Dell og Cloudera har vi et veldig nært samarbeid som også videreselger ETL-produktet vårt som en del av deres store dataapparat. Og med Splunk faktisk, publiserer vi en hovedramme-telemetri og sikkerhetsdata i Splunk-dashbord. Vi har et nært partnerskap.
Hva er det i tankene til alle ledere på C-nivå? Det er egentlig, "Hvordan bruker jeg dataene mine?" Alle snakker om big data. Alle snakker om Hadoop, Spark, den neste datamaskinplattformen som kan hjelpe meg med å skape forretningsdyktighet og åpne for nye transformative applikasjoner. Nye markedsmuligheter. Hver eneste utøvende tenker: "Hva er datastrategien min, hva er datainitiativet mitt, og hvordan sørger jeg for at jeg ikke holder meg bak konkurransen, og at jeg fremdeles er i dette markedet i løpet av de neste tre årene?" se dette mens vi snakker med kundene våre, mens vi snakker med vår globale kundemasse, som du kan forestille deg, siden vi har eksistert en stund.
Når vi snakker med alle disse organisasjonene, ser vi dette også i teknologibunken i forstyrrelsen som skjedde med Hadoop. Det er virkelig for å tilfredsstille dette kravet om data som en eiendel. Utnytte alle dataene en organisasjon har. Og vi har sett bedriftens datavarehusarkitektur utvikle seg slik at Hadoop nå er det nye midtpunktet i den moderne dataarkitekturen. Og de fleste av kundene våre, enten det er finansielle tjenester, enten det er forsikring, detaljhandelstelement, initiativene er vanligvis enten vi finner Hadoop som en tjeneste eller data som en tjeneste. Fordi alle prøver å gjøre dataene tilgjengelige for enten deres eksterne kunder eller interne kunder. Og i noen av organisasjonene ser vi initiativer som nesten en datamarked for sine kunder.
Og et av de første trinnene for å oppnå det, er alt fra å opprette et enterprise data hub. Noen ganger vil folk kalle det en datasjø. Det er faktisk ikke så enkelt å opprette dette enterprise-datahubet, fordi det virkelig krever tilgang til og samling av praktisk talt alle data i bedriften. Og at data nå kommer fra alle de nye kildene som mobile sensorer så vel som gamle databaser, og de er i batchmodus og i streamingmodus. Dataintegrering har alltid vært en utfordring, men med antall og mangfoldighet av datakilder og de forskjellige leveringsstiler, enten det er batch eller streaming i sanntid, er det enda mer utfordrende nå sammenlignet med for fem år siden, for ti år siden. Noen ganger refererer vi til det som "Det er ikke farens ETL lenger."
Så vi snakker om de forskjellige dataverdiene. Ettersom foretak prøver å gi mening om de nye dataene, dataene de samler inn fra mobile enheter, enten sensorer i en bilprodusent eller det er brukerdata for et mobilt spillselskap, trenger de ofte å henvise til de mest kritiske dataverdiene i bedriften, som for eksempel er kundeinformasjon. Disse mest kritiske dataelementene lever ofte på mainframe. Korrelering av mainframe-data med disse nye kildene, samlet i skyen, samlet via mobil, samlet på produksjonslinjen til et japansk bilfirma, eller internett for ting-applikasjoner, må gi mening om disse nye dataene ved å henvise til sine gamle datasett. Og de gamle datasettene er ofte på hovedrammen.
Og hvis disse selskapene ikke er i stand til det, ikke klarer å benytte meg av mainframe-dataene, er det en glipp av muligheten. Da tappes ikke dataene som en tjeneste, eller utnytte alle bedriftsdataene til de mest kritiske eiendelene i organisasjonen. Det er også en del av telemetri- og sikkerhetsdataene fordi ganske mye all transaksjonsdata lever på stordammen.
Se for deg at du går til en minibank, jeg tror en av de fremmøtte sendte en melding til deltakerne her om å beskytte banksystemet, når du sveiper kortet ditt om at transaksjonsdata er stort sett globalt på hovedrammen. Og å sikre og samle inn sikkerhetsdata og telemetri-data fra mainframes og gjøre dem tilgjengelige gjennom enten Splunk-dashboards eller andre, Spark, SQL, blir mer kritisk nå enn noen gang på grunn av datamengden og mangfoldigheten av dataene.
Ferdighetssett er en av de største utfordringene. Fordi du på den ene siden har en raskt skiftende big data stack, du vet ikke hvilket prosjekt som skal overleve, hvilket prosjekt ikke kommer til å overleve, skal jeg ansette Hive eller Pig-utviklere? Bør jeg investere i MapReduce eller Spark? Eller neste ting, Flink, sa noen. Bør jeg investere i en av disse dataplattformene? På den ene siden er det en utfordring å holde følge med det raskt skiftende økosystemet, og på den andre siden har du disse gamle datakildene. De nye ferdighetssettene stemmer ikke egentlig, og du kan ha et problem fordi disse ressursene faktisk går av med pensjon. Det er et stort gap når det gjelder ferdighetene til mennesker som forstår de gamle datasettene og som forstår den nye teknologibunken.
Den andre utfordringen er styringen. Når du virkelig får tilgang til alle bedriftsdataene på tvers av plattformer, har vi kunder som reiste bekymring for at: "Jeg vil ikke at dataene mine skal lande. Jeg vil ikke at dataene mine skal kopieres flere steder fordi jeg vil unngå flere kopier så mye som mulig. Jeg ønsker å ha ende-til-ende-tilgang uten å lande den i midten der. ”Å styre disse dataene blir en utfordring. Og den andre delen er at hvis du får tilgang til data som flaskehalser, hvis du samler mesteparten av dataene dine i skyen og får tilgang til og refererer til gamle data, blir nettverksbåndbredden et problem, en klyngeplattform. Det er mange utfordringer med tanke på å ha dette big data-initiativet og avanserte analyseplattformer og likevel utnytte alle bedriftsdataene.
Hva Syncsort tilbyr er, vi blir referert til som “ganske enkelt de beste” ikke fordi vi ganske enkelt er de beste, men kundene våre omtaler oss virkelig som de beste til å få tilgang til og integrere mainframe-data. Vi støtter alle dataformatene fra mainframe og gjør dem tilgjengelige for big data analytics. Enten det er på Hadoop eller Spark eller neste datamaskinplattform. Fordi produktene våre virkelig isolerer kompleksiteten til datamaskinplattformen. Du er som utvikler, potensielt utviklende på en bærbar datamaskin, med fokus på datapipeline og hva er dataforberedelsene, trinnene for å gjøre disse dataene opprettet for analysen, neste fase og ta den samme applikasjonen i MapReduce eller ta det samme applikasjon rundt i Spark.
Vi hjalp kundene våre med å gjøre det da YARN ble tilgjengelig og de måtte flytte applikasjonene sine fra MapReduce versjon 1 til YARN. Vi hjelper dem med å gjøre det samme med Apache Spark. Produktet vårt, den nye utgaven 9, kjører også med Spark og leveres med en dynamisk optimalisering som vil isolere disse applikasjonene for fremtidige datamaskinrammer.
Så vi har tilgang til mainframe-data, enten det er VSAM-filer, enten det er DB2, eller om det er telemetri-data, som SMF-poster eller Log4j eller syslogs, som må visualiseres gjennom Splunk-dashboards. Og mens du gjør det, fordi organisasjonen kan utnytte sine eksisterende dataingeniører eller ETL ferdighetssett, reduseres utviklingstiden betydelig. Faktisk med Dell og Cloudera var det en uavhengig benchmark sponset, og den målestokken fokuserte på utviklingstid det tar hvis du gjør håndkoding eller bruker andre verktøy som Syncsort, og det var omtrent 60, 70 prosent reduksjon i utviklingstiden . Å bygge bro mellom ferdighetene setter gap mellom grupper, på tvers av disse datafilvertene, og også de datafilvertene i forhold til folket.
Vanligvis snakker ikke big data-teamet, eller datainntaksteamet, eller teamet som har til oppgave å utvikle disse dataene som en tjenestearkitektur, nødvendigvis med hovedramteamet. De ønsker å minimere det samspillet nesten i mange av organisasjonene. Ved å lukke dette gapet har vi avansert. Og den viktigste delen er virkelig å sikre hele prosessen. For i bedriften når du har å gjøre med denne typen sensitive data, er det mange krav.
I sterkt regulerte bransjer som forsikring og banktjenester spør kundene våre, sa de: “Du tilbyr denne stormaskinens datatilgang, og det er flott. Kan du også tilby meg å lage dette EBCDIC-kodede postformatet som oppbevares i det opprinnelige formatet slik at jeg kan tilfredsstille revisjonskravene mine? ”Så vi får Hadoop og Apache Spark til å forstå stordramme-data. Du kan oppbevare dataene i det opprinnelige postformatet, utføre databehandlingsplattformen for behandlings- og nivånivåer, og hvis du trenger å sette det tilbake kan du vise at posten ikke er endret og postformatet ikke er endret, kan du overholde forskriftskravene .
Og de fleste av organisasjonene, mens de lager datahuben eller datasjøen, prøver de også å gjøre dette med et enkelt klikk for å kunne kartlegge metadata fra hundrevis av skjemaer i en Oracle-database til Hive-tabeller eller ORC- eller parkettfiler blir nødvendig. Vi sender verktøy og vi leverer verktøy for å gjøre dette til et trinns datatilgang, automatisk generering av jobber eller databevegelsen, og automatisk generering av jobber for å gjøre datakartleggingen.
Vi snakket om tilkoblingsdelen, samsvar, styring og databehandling. Og produktene våre er tilgjengelige både på stedet og i skyen, noe som gjør det virkelig veldig enkelt fordi selskapene ikke trenger å tenke på hva som kommer til å skje i løpet av det neste året eller to hvis jeg bestemmer meg for å gå fullstendig i offentlig sky kontra hybrid miljø, ettersom noen av klyngene kanskje kjører på premiss eller i skyen. Og produktene våre er tilgjengelige både på Amazon Marketplace, på EC2, Elastic MapReduce og også i en Docker-container.
Bare for å pakke sammen, så vi har nok tid til spørsmål og svar, det handler egentlig om å få tilgang til, integrere og overholde datastyringen, men likevel gjøre alt dette enklere. Og mens vi gjør dette enklere, "design en gang og distribuer hvor som helst" i ekte forstand på grunn av våre åpen kildekodebidrag, kjører produktet vårt innfødt i Hadoop-datastrømmen og med Spark, isolerer organisasjonene fra det raskt skiftende økosystemet. Og gir en enkelt datapipeline, et enkelt grensesnitt, både for batch og streaming.
Og dette hjelper også organisasjoner noen ganger med å evaluere disse rammene, fordi du kanskje vil lage applikasjoner og bare kjøre på MapReduce versus Spark og se selv, ja, Spark har dette løftet og gir all fremgangen til iterative algoritmer som fungerer for best maskinlæring og prediktive analyseprogrammer fungerer med Spark, kan jeg også få strømmen og batch-arbeidsmengdene mine gjort på dette datarammet? Du kan teste forskjellige datamaskinplattformer ved å bruke våre produkter. Og den dynamiske optimaliseringen om du kjører på en frittstående server, på den bærbare datamaskinen din, i Google Cloud kontra Apache Spark, er virkelig et stort forslag for våre kunder. Og det ble virkelig drevet av utfordringene de hadde.
Jeg vil bare dekke en av casestudiene. Dette er Guardian Life Insurance Company. Og Guardians initiativ var virkelig å sentralisere dataene sine og gjøre den tilgjengelig for sine klienter, redusere dataforberedelsestiden og de sa at alle snakker om dataforberedelse som tar 80 prosent av den totale databehandlingsrørledningen, og de sa at det faktisk tok ca. 75 til 80 prosent for dem, og de ønsket å redusere dataforberedelsen, transformasjonstider, tid til marked for analyseprosjekter. Lag den smidigheten når de legger til nye datakilder. Og gjør den sentraliserte datatilgangen tilgjengelig for alle kundene sine.
Løsningen deres, inkludert Syncsort-produkter, er akkurat nå. De har en Amazon Marketplace-lookalike datamarked, støttet av en datasjø, som i utgangspunktet er Hadoop, og NoSQL-database. Og de bruker produktene våre for å bringe alle dataene til datasjøen, inkludert DB2 på mainframe, inkludert VSAM-filer på mainframe, og databasens gamle datakilder så vel som de nye datakildene. Og som et resultat av det har de sentralisert gjenbrukbare dataene som er søkbare, tilgjengelige og tilgjengelige for sine klienter. Og de er virkelig i stand til å legge til de nye datakildene og betjene kundene sine mye raskere og mer effektivt enn før. Og analysetiltakene utvikler seg enda mer på den prediktive siden. Så jeg vil ta en pause, og jeg håper dette var nyttig, og hvis du har spørsmål til meg om noen av de relaterte emnene, er du velkommen.
Eric Kavanagh: Jada, og Tendü, jeg vil bare kaste en inn. Jeg fikk en kommentar fra et publikummedlem som bare sa: "Jeg liker dette 'designet en gang, distribuer hvor som helst.'" Kan du på en måte grave i hvordan det er sant? Jeg mener, hva har du gjort for å muliggjøre den slags smidighet og er det noen skatt? Som når vi for eksempel snakker om virtualisering, er det alltid litt av avgiftsskatten. Noen mennesker sier to prosent, fem prosent 10 prosent. Hva du har gjort for å aktivere designen en gang, distribuer hvor som helst - hvordan gjør du det og er det noen skatt knyttet til det når det gjelder ytelse?
Tendü Yogurtçu: Visst, takk. Nei, for i motsetning til noen av de andre leverandørene genererer vi ikke egentlig Hive eller Pig eller noen annen kode som ikke er hjemmehørende i våre motorer. Det er her våre kilder med åpen kildekode spilte en enorm rolle, fordi vi har jobbet med Hadoop-leverandører, Cloudera, Hortonworks og MapR veldig tett, og på grunn av våre åpen kildekodebidrag, kjører motoren vår faktisk som en del av flyten, som en del av Hadoop-strømmen, som en del av Spark.
Det som også oversettes, vi har denne dynamiske optimaliseringen. Dette var noe som kom som et resultat av at kundene våre ble utfordret med datamaskinrammer. Mens de kom i produksjon med noen av applikasjonene, kom de tilbake, de sa: “Jeg stabiliserer bare Hadoop-klyngen min, stabiliserer på MapReduce YARN versjon 2, MapReduce versjon 2, og folk snakker om at MapReduce er død, Spark er den neste tingen, og noen mennesker sier at Flink vil være den neste tingen, hvordan skal jeg takle dette? ”
Og disse utfordringene ble virkelig så åpenbare for oss, vi investerte i å ha denne dynamiske optimaliseringen vi omtaler som intelligent gjennomføring. På kjøretid, når jobben, når denne datapipeline leveres, basert på klyngen, enten det er Spark, om det er MapReduce eller en Linux-frittstående server, bestemmer vi hvordan vi skal kjøre denne jobben, naturlig i vår motor, som en del av det Hadoop eller Spark dataflyt. Det er ingen overhead fordi alt gjøres gjennom denne dynamiske optimaliseringen vi har, og alt er også gjort fordi motoren vår er så naturlig integrert på grunn av våre bidrag med åpen kildekode. Svarer det på spørsmålet ditt?
Eric Kavanagh: Ja, det er bra. Og jeg vil kaste opp et spørsmål til der borte, og så kan Dez, kanskje vi trekker deg og Robin også inn. Jeg fikk nettopp en morsom kommentar fra en av de fremmøtte. Jeg skal lese det fordi det egentlig er ganske lite. Han skriver: "Det ser ut som om historien til tingenes HOT" - får du det? Som IoT - "er at jo mer du prøver å 'forenkle' noe som er veldig komplekst, oftere enn ikke det enklere det ser ut til å gjøre ting, jo mer mer hengende tau leveres. Tenk databaseforespørsel, eksplosjon, flertråd, osv. ”Kan du kommentere dette paradokset han refererer til? Enkelhet kontra kompleksitet, og hva skjer egentlig under dekslene?
Tendü Yogurtçu: Visst. Jeg tror det er et veldig gyldig poeng. Når du forenkler ting og gjør disse optimaliseringene, på en måte under dekslene, må noen ta den kompleksiteten av hva som må skje, ikke sant? Hvis du lammer noe, eller hvis du bestemmer deg for hvordan du kjører en bestemt jobb med hensyn til datamaskinens rammeverk, er det tydeligvis en del av jobben som blir presset enten det er ved brukersiden, menykodingen eller det er på motoroptimaliseringen. Det er en del av det, ved å forenkle brukeropplevelsen, er det en stor fordel med tanke på å kunne utnytte ferdighetssett som finnes i bedriften.
Og du kan på en måte dempe det paradokset, avbøte utfordringen med: "Ja, men jeg har ikke kontroll over alt som skjer under dekselet, under panseret i den motoren, " ved å utsette ting for de mer avanserte brukerne hvis de vil ha den slags kontroll. Ved også å investere i noen av de forskjellige tingene som kan brukes. Å kunne tilby mer operative metadata, mer driftsdata, som i eksemplet som deltakeren ga, for et SQL-spørsmål så vel som med motoren i gang. Jeg håper det svarer.
Eric Kavanagh: Ja, det høres bra ut. Desember, ta den bort.
Dez Blanchfield: Jeg er virkelig opptatt av å få litt mer innsikt i fotavtrykket ditt i åpen kildekodebidragene og reisen du har tatt fra din tradisjonelle, langvarige opplevelse innen stormaskin og den proprietære verdenen og deretter skiftet til bidra til åpen kildekode og hvordan det foregikk. Og den andre tingen jeg er opptatt av å forstå, er synet du ser på at bedrifter, ikke bare IT-avdelinger, men bedrifter nå tar hensyn til datahubber eller datasjøer som folk sier nå, og om de ser denne trenden med bare en enkelt, konsolidert datasjø eller om vi ser distribuerte datasjøer og folk bruker verktøy for å sette dem sammen?
Tendü Yogurtçu: Visst. For den første var det en veldig interessant reise, som en programvareselskap som var eier, en av de første etter IBM. Imidlertid startet alt igjen med at våre evangelistkunder så på Hadoop. Vi hadde dataselskaper som ComScore, de var en av de første som tok i bruk Hadoop fordi de samlet inn digitale data over hele kloden og ikke klarte å beholde 90 dager med data med mindre de investerte en datavarehusboks på ti millioner dollar i miljø. De begynte å se på Hadoop. Med det begynte vi også å se på Hadoop.
Og da vi tok en beslutning og erkjente at Hadoop virkelig kommer til å være fremtidens dataplattform, kom vi også til forståelsen av at vi ikke vil være i stand til å spille i dette, et vellykket skuespill i dette, med mindre vi var en del av økosystemet. Og vi jobbet veldig tett med Hadoop-leverandører, med Cloudera, Hortonworks, MapR, etc. Vi begynte virkelig å snakke med dem fordi partnerskap blir veldig viktig for å validere verdien en leverandør kan gi, og sørger også for at vi sammen kan gå til bedriften og tilbyr noe mer meningsfylt. Det krevde mye relasjonsbygging fordi vi ikke var kjent for Apache open source-prosjekter, men vi hadde stor støtte fra disse Hadoop-leverandørene, må jeg si.
Vi begynte å jobbe sammen og se på navet, hvordan vi kan gi verdi uten engang eierprodusenten vår i rommet. Det var viktig. Det handler ikke bare om å sette noen APIer som produktet ditt kan kjøre på, det er for å kunne si at jeg vil investere i dette fordi jeg tror Hadoop kommer til å bli en fremtidens plattform, så ved å investere i kildene vi ønsket å lage at den modnes og blir bedriftsklar. Vi kan faktisk aktivere noen av brukstilfellene som ikke var tilgjengelige før bidragene våre. Det vil komme hele økosystemet til gode, og vi kan utvikle disse partnerskapene veldig tett.
Det tok ganske mye tid. Vi begynte å bidra i 2011, og 2013, 21. januar - jeg husker datoen fordi den datoen vårt største bidrag ble forpliktet, noe som betydde at vi nå kan ha våre produkter generelt tilgjengelig fra det tidspunktet - det tok ganske lang tid å utvikle disse relasjonene, viser verdien, partnere blir designpartnere med leverandørene og med pendlerne i open source-samfunnet. Men det var veldig gøy. Det var veldig givende som et selskap for oss å være en del av det økosystemet og utvikle et flott partnerskap.
Det andre spørsmålet om datahub / data lake, tror jeg når vi ser disse dataene som en tjenesteimplementering i de fleste tilfeller, ja, det kan være klynger, fysisk enkelt eller flere klynger, men det er mer konseptuelt enn å bli det ene stedet for alle dataene. Fordi vi i noen organisasjoner ser store klyngedeposisjoner på stedet, men de har også klynger, for eksempel i den offentlige skyen fordi noen av dataene som er samlet inn fra online seksjoner, virkelig holdes i skyen. Det er å kunne ha en enkelt datapipeline som du faktisk kan utnytte begge disse, og bruke dem som et enkelt datahub, enkeltdatasjø, blir viktig. Ikke nødvendigvis bare det fysiske stedet, men å ha datahub og datasjø på tvers av klynger, på tvers av geografier og kanskje på premiss og sky, kommer til å bli veldig kritisk, tror jeg. Spesielt fremover. I år begynte vi å se mer og mer skyutplasseringer. Det er fantastisk. Første halvår i år så langt har vi sett mye skyutplasseringer.
Eric Kavanagh: Ok, kult. Og Robin, har du noen spørsmål? Jeg vet at vi bare har et par minutter igjen.
Robin Bloor: Ok, jeg kan stille henne et spørsmål. Det første som skjedde med meg er at det har vært mye spenning rundt Kafka og jeg var interessert i din mening om Kafka og hvordan du integrerer deg med måten folk bruker Kafka på?
Tendü Yogurtçu: Visst. Ja, Kafka blir ganske populær. Blant kundene våre ser vi at det å være slags datatransportlag og se at dataene er en buss, stort sett. For eksempel brukte en av våre kunder faktisk en slags konsumerende data som ble presset inn i denne Kafka blant flere, som tusenvis av online brukere og som kunne klassifisere det og presse gjennom.
Igjen er Kafka en databuss til de forskjellige forbrukerne av disse dataene. Klassifiser noen avanserte brukere kontra ikke-så avanserte brukere og gjør noe annet fremover i den datapipeline. Hvordan vi integrerer med Kafka er i utgangspunktet, produktet DMX-h blir en pålitelig forbruker, en svært effektiv og pålitelig forbruker for Kafka. Den kan lese dataene, og dette er ikke annerledes enn å lese data fra noen annen datakilde for oss. Vi gir brukerne muligheten til å kontrollere vinduet enten i forhold til tidskravet de har eller antall meldinger de kan konsumere fra Kafka-bussen. Og så kan vi også gjøre berikelse av disse dataene når de går gjennom produktet vårt og skyves tilbake til Kafka. Vi har testet dette. Vi har benchmarket det på kundesiden. Også sertifisert av Confluent. Vi jobber tett med Confluent-gutta, og de er veldig gode resultater og enkle å bruke. Igjen, der APIer endres, men du trenger ikke å bekymre deg fordi produktet virkelig behandler det som bare en annen datakilde, en streaming datakilde. Det er ganske gøy å jobbe med vårt produkt og Kafka, faktisk.
Robin Bloor: Ok, jeg har et annet spørsmål som bare er et generelt forretningsspørsmål, men jeg har kjent Syncsort i lang tid, og du har alltid hatt rykte og levert ekstra hurtig programvare for ETL og mainframe-verdenen. Er det slik at mesteparten av virksomheten din nå blir overført til Hadoop? Er det slik at du på en eller annen måte har spredt virksomheten din ganske dramatisk fra stormaskinens verden?
Tendü Yogurtçu: Våre hovedrammeprodukter kjører fremdeles 50 prosent av hovedbildene globalt. Så vi har en veldig sterk hovedramme-produktlinje i tillegg til hva vi gjør på big data og Hadoop-enden. Og vi er fremdeles i de fleste av IT-forenklings- eller optimaliseringsprosjektene fordi det er en ende som du ønsker å kunne benytte deg av mainframe-dataene i big data-multex-plattformene og utnytte alle bedriftsdata, men det er også svært kritiske arbeidsmengder som fremdeles fortsetter å kjøre på stormaskin, og vi tilbyr disse kundene måtene å virkelig gjøre disse applikasjonene mer effektive, kjøre i zIIP-motoren slik at de ikke bruker så mye behandlingssykluser og MIPS, og gjør dem kostnadseffektive.
Vi fortsetter å investere i mainframe-produktene og spiller faktisk inn i dette rommet der folk går fra mainframe big iron til big data og spenner over produktlinjen også på tvers av disse plattformene. Så vi flytter ikke nødvendigvis hele virksomheten til den ene siden, vi fortsetter å ha meget vellykket virksomhet på begge sider. Og anskaffelsene er et stort fokus også for oss. Etter hvert som denne databehandlingen og databehandlingsområdet for big data-plattformene utvikler seg, er vi også opptatt av å gjøre ganske mange gratis anskaffelser.
Robin Bloor: Vel, jeg kan ikke spørre deg hva de er fordi du ikke hadde lov til å fortelle meg det. Jeg er interessert i om du har sett mange implementeringer av Hadoop eller Spark faktisk på mainframe eller om det er en veldig sjelden ting.
Tendü Yogurtçu: Vi har ikke sett noen. Det er mer spørsmål om det. Jeg tror Hadoop på mainframe ikke ga mye mening på grunn av typen kjernestruktur. Imidlertid er Spark på mainframe ganske meningsfylt, og Spark er virkelig veldig bra med maskinlæringen og prediktiv analyse og det å kunne ha noen av disse applikasjonene med mainframe-data er egentlig, synes jeg, ganske meningsfylt. Vi har ikke sett noen gjøre det ennå, men det er virkelig bruksaken som driver disse tingene. Hvis din brukssak som selskap mer tar med den stordatamyndata og integrerer seg med resten av datasettene i big data-plattformen, er det en historie. Det krever tilgang til mainframe-dataene fra big data Multex-plattformen fordi det er usannsynlig at du vil ta med deg datasettene fra åpne systemer og ringes tilbake til mainframe. Imidlertid, hvis du har noen mainframe-data som du bare vil utforske og gjøre en liten bit av datautforskningsfunn, kan du bruke noen avanserte AI og avanserte analyser, så kan Spark være en god måte å gå og kjøre på mainframe som det.
Eric Kavanagh: Og her er enda et spørsmål fra publikum, faktisk to til. Jeg gir deg et spørsmål om tag-teamet, så pakker vi opp. En deltaker spør: "Integrerer IBM dine open source-bidrag i det offentlige skyøkosystemet, med andre ord Bluemix?" Og en annen deltaker gjorde et veldig godt poeng og la merke til at Syncsort er flott for å holde liv i store jern for de som har allerede det, men hvis selskaper går fra nye hovedrammer til fordel for det han kaller CE, skyer alt, at det sannsynligvis vil avta, men bemerker at dere virkelig er flinke til å flytte data ved å omgå operativsystemer opp til en gigabyte per sekund. Kan du snakke om kjernestyrken din, som han nevnte, og om IBM integrerer tingene dine i Bluemix eller ikke?
Tendü Yogurtçu: Med IBM er vi allerede samarbeidspartnere med IBM, og vi hadde diskusjoner for deres dataskytjenester som tilbyr produktet. Våre bidrag med åpen kildekode er åpne for alle som ønsker å utnytte dem. Noe av mainframe-tilkoblingen er også tilgjengelig i Spark-pakker, så ikke bare IBM. Hvem som helst kan utnytte dem. I Bluemix har vi ikke gjort noe spesifikt om det ennå. Og har du noe imot å gjenta det andre spørsmålet?
Eric Kavanagh: Ja, det andre spørsmålet handlet om ditt kjerneområde for funksjonalitet gjennom tidene, som virkelig håndterte flaskehalser av ETL, og det er åpenbart noe som dere fremdeles kommer til å gjøre som mainframes, vel, teoretisk sett holde deg unna, selv om Dez's poenget er fremdeles slags rocking og rulling der ute. Men deltakeren bemerket nettopp at Syncsort er veldig flink til å flytte data ved å omgå operativsystemer og opp til en gigabyte i sekundet. Kan du bare kommentere det?
Tendü Yogurtçu: Ja, virkelig ressurseffektivitet har vært vår styrke, og skalerbarheten og ytelsen har vært vår styrke. Vi går ikke på akkord, forenkling har mange betydninger, vi går ikke på akkord med disse. Da folk for eksempel begynte å snakke om Hadoop i 2014, var det for eksempel mange av organisasjonene som ikke så veldig på prestasjoner i utgangspunktet. De sa: "Åh, hvis noe skjer, kan jeg legge til et par par noder, og jeg vil ha det bra, ytelse er ikke mitt krav."
Mens vi snakket om å ha den beste ytelsen fordi vi allerede kjørte innfødte, hadde vi ikke engang noen av de første hikkene som Hive hadde med flere MapReduce-jobber og overheads med å starte dem. Folk sa til oss: "Det er ikke min bekymring, ikke bekymre deg for det for øyeblikket."
Da vi kom til 2015 har landskapet endret seg fordi noen av kundene våre allerede overskred lagringene de hadde i sine produksjonsgrupper. Det ble veldig kritisk for dem å se hva Syncsort kan tilby. Hvis du tar noen data fra en database eller mainframe og skriver til et parkettformat i klyngene, enten du lander og scener og gjør en annen transformasjon eller bare gjør inflight-transformasjonen og målfilfilformatet, gjorde du en forskjell fordi du sparer fra lagring, du sparer fra nettverksbåndbredden, du sparer fra arbeidsmengden på klyngen fordi du ikke kjører ekstrajobber. De styrkene vi spiller når det gjelder å være veldig bevisste, vi føler ressurseffektiviteten under huden vår, ser det ut til.
Slik beskriver vi det. Det er kritisk for oss. Vi tar det ikke for gitt. Vi tok det aldri for gitt, så vi vil fortsette å være sterke med den innflytelsen i Apache Spark eller neste datamaskinramme. Det vil fortsatt være vårt fokus. Og når det gjelder databevegelsesstykket og datatilgangsstykket, er det definitivt en av styrkene våre, og vi får tilgang til DB2- eller VSAM-data på stormaskinene i sammenheng med Hadoop eller Spark.
Eric Kavanagh: Det er en flott måte å avslutte webcasten, folkens. Tusen takk for din tid og oppmerksomhet. Takk til deg, Tendü og Syncsort, for at du kom inn i briefingsrommet og gikk inn i runden, som de sier. Mange gode spørsmål fra publikum. Det er et stadig rørende miljø der ute, folkens. Vi arkiverer denne Hot Tech som vi gjør med alle de andre. Du finner oss på insideanalysis.com og på techopedia.com. Vanligvis går det opp om en dag. Og med det skal vi ta farvel, folkens. Tusen takk. Vi snakker snart. Ha det fint. Ha det.
