Casa Hardware Grande ferro, incontra grandi dati: liberare i dati del mainframe con hadoop e spark

Grande ferro, incontra grandi dati: liberare i dati del mainframe con hadoop e spark

Anonim

Di Techopedia Staff, 2 giugno 2016

Takeaway: l'ecosistema Hadoop viene utilizzato sui mainframe per elaborare i big data in modo rapido ed efficiente.

Al momento non sei collegato. Accedi o registrati per vedere il video.

Eric Kavanagh: Va bene signore e signori, sono le quattro in punto orientale di giovedì, e in questi giorni questo significa che è ovviamente tempo per Hot Technologies. Sì davvero, mi chiamo Eric Kavanagh. Sarò il tuo moderatore per il seminario web di oggi. È roba buona, gente, "Big Iron, Meet Big Data" - Adoro quel titolo - "Liberare i dati del mainframe con Hadoop e Spark". Parleremo di vecchi e nuovi. Wow! Copriamo lo spettro di tutto ciò di cui abbiamo parlato negli ultimi 50 anni di IT aziendale. Spark incontra il mainframe, lo adoro.

C'è un posto nel tuo veramente e abbastanza in me. L'anno è caldo. Parliamo di argomenti di tendenza in questa serie perché stiamo davvero cercando di aiutare le persone a comprendere determinate discipline, determinati spazi. Cosa significa, ad esempio, avere una piattaforma analitica? Cosa significa liberare i big data dai mainframe? Cosa significano tutte queste cose? Stiamo cercando di aiutarti a capire tipi specifici di tecnologie, dove si adattano al mix e come puoi farne uso.

Oggi abbiamo due analisti e poi ovviamente Tendü Yogurtçu di Syncsort. È una visionaria nel nostro spazio, molto contenta di averla online oggi, con il nostro Dez Blanchfield e il Dr. Robin Bloor. Dirò solo un paio di parole veloci. Uno è che, gente, giochi un ruolo importante in questo processo, quindi per favore non essere timido nel fare alcune buone domande. Vorremmo raggiungerli durante il componente Domande e risposte del webcast, che di solito è alla fine dello spettacolo. E tutto ciò che devo dire è che abbiamo molti buoni contenuti, quindi sono entusiasta di sentire cosa hanno da dire questi ragazzi. E con ciò, lo consegnerò a Dez Blanchfield. Dez, il pavimento è tuo, portalo via.

Dez Blanchfield: Grazie, Eric, e grazie a tutti per aver partecipato oggi. Quindi mi emoziono molto quando ho la possibilità di parlare di una delle mie cose preferite al mondo, i mainframe. In questi giorni non hanno molto amore. La mia opinione è che il mainframe fosse la piattaforma originale per big data. Alcuni sosterrebbero che al momento erano l'unico computer e questo è un punto giusto da chiarire, ma per oltre 60 anni ormai sono stati davvero la sala macchine di ciò che i big data sono diventati popolari negli ultimi tempi. E ti porterò in un piccolo viaggio sul perché credo che sia così.

Abbiamo visto un viaggio negli stack hardware tecnologici nel contesto dei mainframe spostarsi dall'immagine che vedi ora sullo schermo. Questo è un vecchio mainframe FACOM, uno dei miei preferiti. Ci siamo trasferiti nella grande fase del ferro, alla fine degli anni novanta e nel boom delle dot-com. Questo è il Sun Microsystems E10000. Questa cosa era un mostro assoluto con 96 CPU. Originariamente 64 ma poteva essere aggiornato a 96 CPU. Ogni CPU può eseguire 1.024 thread. Ogni thread potrebbe essere alla velocità di applicazione allo stesso tempo. Era solo mostruoso e in realtà alimentava il boom delle dot-com. Questi sono tutti i grandi unicorni come li chiamiamo, ora stiamo correndo, e non solo le grandi aziende, alcuni dei grandi siti Web.

E poi abbiamo finito con questo comune modello PC standard. Abbiamo appena messo insieme molte macchine economiche e abbiamo creato un cluster e abbiamo affrontato la grande sfida del ferro e ciò che è diventato grandi dati, in particolare sotto forma del progetto Hadoop che ha dato il via al motore di ricerca open source, Nutch. E abbiamo essenzialmente ricreato il mainframe e un sacco di piccole CPU incollate insieme e in grado di agire come L-percorsi e sotto forma di esecuzione di lavori separati o parti di lavori ed erano abbastanza efficaci in molti modi. Più economico se sei partito più piccolo, ma invariabilmente molti di questi grandi cluster sono diventati più costosi di un mainframe.

La mia opinione su queste cose è che nella corsa dal boom delle dot-com a quello che è diventato Web 2.0 e ora inseguono gli unicorni, abbiamo dimenticato che c'è questa piattaforma che sta ancora alimentando molti dei nostri più grandi sistemi mission-critical là fuori. Quando pensiamo a ciò che è in esecuzione sulle piattaforme mainframe là fuori. Sono soprattutto i big data, in particolare il cavallo di battaglia dei dati, ma sicuramente i big data. I sistemi aziendali e governativi tradizionali, in particolare quelli bancari, patrimoniali e assicurativi, li usiamo tutti i giorni.

Sistemi di prenotazione aerea e di gestione dei voli, in particolare la gestione dei voli in cui il tempo reale è fondamentale. Quasi ogni stato e governo federale in qualche momento ha avuto un mainframe e invariabilmente molti ne hanno ancora. Vendita al dettaglio e produzione. Alcuni dei vecchi software che sono appena stati in circolazione e non sono mai andati via. Continua solo a potenziare gli ambienti di produzione e sicuramente la vendita al dettaglio su vasta scala. Sistemi medici. Sistemi di difesa, sicuramente sistemi di difesa.

Durante le ultime due settimane ho letto molti articoli sul fatto che alcuni dei sistemi di controllo missilistici sono ancora in esecuzione su vecchi mainframe per i quali stanno lottando per trovare parti. Stanno scoprendo come passare a nuovi mainframe. Sistemi di trasporto e logistica. Questi potrebbero non sembrare argomenti sexy, ma questi sono gli argomenti che affrontiamo quotidianamente su tutta la linea. E alcuni ambienti di telecomunicazione molto grandi sono ancora gestiti su piattaforme mainframe.

Quando si pensa ai tipi di dati presenti, sono tutti mission-critical. Sono piattaforme davvero importanti e piattaforme che diamo per scontate ogni giorno e in molti modi rendono possibile la vita. Quindi, chi sta ancora usando un mainframe e chi sono tutte queste persone che si stanno aggrappando a queste grandi piattaforme e conservando tutti questi dati? Bene, come ho detto qui, credo che sia facile lasciarsi ingannare dal passaggio dei media dal grande ferro ai rack di comuni cluster standard o PC economici o macchine x86, nel pensare che il mainframe sia morto e andato via. Ma i dati dicono che il mainframe non è mai andato via e in effetti è qui per rimanere.

La ricerca che ho messo insieme qui nelle ultime due settimane ha dimostrato che il 70% delle imprese, in particolare le grandi imprese, i dati si trovano ancora su un mainframe di qualche forma. Il settantuno percento delle Fortune 500 gestisce ancora da qualche parte i principali sistemi aziendali su mainframe. In effetti, qui in Australia, abbiamo un numero di organizzazioni che hanno un data center nel mezzo di una città. È un vero e proprio computer sotterraneo in modo efficace, e il numero di mainframe che corre lì, fa ticchettare e fa felicemente il proprio lavoro. E pochissime persone sanno che camminando per le strade, proprio sotto i loro piedi in una parte particolare della città, c'è questo enorme data center pieno di mainframe. Novantadue su 100 banche in tutto il mondo, le prime 100 banche che sono, gestiscono ancora sistemi bancari su mainframe. Ventitre delle 25 principali catene di vendita al dettaglio in tutto il mondo utilizzano i mainframe per gestire i propri sistemi di gestione della vendita al dettaglio su piattaforme EIP e BI.

È interessante notare che 10 dei primi 10 assicuratori gestiscono ancora le loro piattaforme su mainframe e in realtà alimentano i loro servizi cloud su mainframe. Se stai utilizzando un'interfaccia web o un'app mobile da qualche parte in cui sia presente un middleware, l'interfaccia in realtà parla con qualcosa di veramente pesante e grosso nel back-end.

Ho trovato oltre 225 agenzie governative statali e locali in tutto il mondo in esecuzione su piattaforme mainframe. Sono sicuro che ci sono molte ragioni per questo. Forse non hanno il budget per prendere in considerazione il ferro nuovo, ma è un'enorme impronta di ambienti molto grandi in esecuzione su mainframe con alcuni dati molto critici. E come ho detto prima, la maggior parte delle nazioni gestisce ancora i propri sistemi di difesa chiave su mainframe. Sono sicuro che in molti modi stanno cercando di scendere lì ma eccoti.

Nel 2015 IDC ha condotto un sondaggio e 350 dei CIO intervistati hanno riferito di possedere ancora e gestire grandi quantità di ferro sotto forma di mainframe. E mi ha colpito il fatto che è probabilmente più che il numero di cluster Hadoop su larga scala attualmente in esecuzione in tutto il mondo in produzione - un piccolo stat interessante lì. Ho intenzione di andare avanti e convalidarlo, ma è stato un gran numero. Trecentocinquanta CIO hanno riferito di avere ancora uno o più mainframe in produzione.

L'anno scorso, 2015, IBM ci ha regalato il potente Z13, la tredicesima iterazione della sua piattaforma mainframe. I media si sono scatenati su questa cosa perché erano stupiti che IBM stesse ancora realizzando i mainframe. Quando hanno sollevato il cofano e hanno dato un'occhiata a ciò che era sotto la cosa, si sono resi conto che era effettivamente alla pari con quasi tutte le piattaforme moderne di cui ci eravamo eccitati sotto forma di big data, Hadoop e certamente i cluster. Questa cosa ha funzionato Spark e ora Hadoop in modo nativo. È possibile eseguire migliaia e migliaia di macchine Linux su di esso e sembrava e sembrava qualsiasi altro cluster. Era una macchina piuttosto sorprendente.

Un certo numero di organizzazioni ha preso queste cose e in effetti ho fatto alcuni dati su quante di queste macchine stanno prendendo. Ora ho avuto la visione che il terminale di testo 3270 sia stato sostituito da browser Web e app mobili da un po 'di tempo e ci sono molti dati che lo supportano. Penso che ora stiamo entrando in un'era in cui ci siamo resi conto che questi mainframe non stanno andando via e che ci sono una quantità sostanziale di dati su di essi. E quindi quello che stiamo facendo ora è semplicemente aggiungere ciò che chiamo strumenti di analisi standardizzati. Queste non sono app personalizzate. Queste sono cose su misura una tantum. Queste sono cose che puoi letteralmente acquistare semplicemente in una scatola confezionata di per sé e collegarle al tuo mainframe e fare alcune analisi.

Come ho detto prima, il mainframe è in circolazione da oltre 60 anni, in effetti. Quando pensiamo a quanto è lungo, è più lungo di quanto le carriere della maggior parte dei professionisti IT vivano. E in effetti probabilmente anche alcune delle loro vite. Nel 2002 IBM ha venduto 2.300 mainframe. Nel 2013 è cresciuto fino a 2.700 mainframe. Sono 2.700 le vendite di mainframe in un anno nel 2013. Non ho potuto ottenere dati precisi sul 2015, ma immagino che si stia avvicinando rapidamente alle 3.000 unità vendute all'anno nel 2015, 2013. E non vedo l'ora di poterlo confermare.

Con il rilascio di Z13, la tredicesima iterazione di una piattaforma mainframe, che penso costino circa 1, 2 o 1, 3 miliardi di dollari per svilupparsi da zero, IBM cioè, ecco una macchina che assomiglia e si sente proprio come qualsiasi altro cluster che abbiamo oggi e gestisce nativamente Hadoop e Spark. E può sicuramente essere collegato a da altri strumenti di analisi e big data o invariabilmente connesso a uno dei cluster Hadoop esistenti o nuovi. Ritengo che includere la piattaforma mainframe nella strategia per i big data sia un must. Ovviamente, se ne hai uno, hai molti dati e vuoi capire come ottenerli lì. E vengono lasciati raccogliere polvere in molti modi, mentalmente ed emotivamente per quanto riguarda il mondo degli affari, ma sono qui per restare.

La connettività e le interfacce di tutti i tuoi strumenti di analisi ai dati ospitati da mainframe dovrebbero essere una parte fondamentale della tua azienda e in particolare dei piani governativi per i big data. E invariabilmente ora il software li sta notando, osservandoli a lungo e rendendosi conto di cosa c'è dentro queste cose e connettendo le menti che iniziano a ottenere un po 'di intuizione e un po' di sensazione per ciò che è realmente sotto il cofano. E con ciò consegnerò il mio caro collega, il dottor Robin Bloor, e lui si aggiungerà a quel piccolo viaggio. Robin, portalo via.

Robin Bloor: Beh, grazie. Ok, da quando Dez ha cantato la canzone del mainframe, entrerò in quello che penso stia accadendo in termini di vecchio mondo mainframe e nuovo mondo Hadoop. Immagino che la grande domanda qui sia: come gestisci tutti quei dati? Non credo che il mainframe sia messo in discussione rispetto alla sua capacità di big data - la sua capacità di big data è estremamente, come ha sottolineato Dez, è estremamente capace. In realtà puoi mettere dei cluster Hadoop su di esso. Il punto in cui viene sfidato è in termini di ecosistema e ne parlerò in modo approfondito.

Ecco un po 'di posizionamento del mainframe. Ha un costo di ingresso elevato e ciò che è realmente accaduto in passato, dalla metà degli anni '90, quando la popolarità dei mainframe ha iniziato a calare, ha avuto la tendenza a perdere la sua fascia bassa, quelle persone che avevano acquistato mainframe economici e non era è davvero particolarmente economico per quelle persone. Ma più in alto nella fascia media e nella fascia alta del mainframe lo era ancora, e in realtà è evidente, un calcolo incredibilmente economico.

È stato, va detto, salvato da Linux perché Linux implementato su un mainframe ha ovviamente permesso di eseguire tutte le applicazioni Linux. Molte applicazioni Linux sono andate lì prima che i big data fossero persino una parola, o due parole, suppongo. In realtà è una piattaforma abbastanza eccellente per il cloud privato. Per questo motivo può partecipare alle distribuzioni di cloud ibrido. Uno dei problemi è che le competenze del mainframe sono scarse. Le competenze del mainframe esistenti in realtà invecchiano, nel senso che le persone lasciano l'industria per andare in pensione anno dopo anno e vengono semplicemente sostituite in termini di numero di persone. Quindi questo è un problema. Ma è ancora un calcolo economico.

L'area in cui è stata sfidata, ovviamente, è tutta questa faccenda di Hadoop. Questa è una foto di Doug Cutting con l'elefante Hadoop originale. L'ecosistema Hadoop è - e rimarrà - l'ecosistema dominante di big data. Offre un ridimensionamento migliore di quello che il mainframe può effettivamente ottenere ed è molto più economico come archivio dati. L'ecosistema Hadoop si sta evolvendo. Il modo migliore per pensare a questo è una volta che una particolare piattaforma hardware e l'ambiente operativo con essa diventa dominante, quindi l'ecosistema prende vita. E questo è successo con il mainframe IBM. Bene, in seguito è successo con il Digital VAX, è successo con i server Sun, è successo con Windows, è successo con Linux.

E quello che è successo è che Hadoop, a cui penso sempre, o mi piace pensare, come una specie di ambiente distribuito per i dati, l'ecosistema si sta evolvendo a un ritmo incredibile. Voglio dire, se hai appena menzionato i vari contributi impressionanti che sono open source, Spark, Flink, Kafka, Presto, e poi aggiungi alcuni di questi database, le funzionalità NoSQL e SQL che ora si trovano su Hadoop. Hadoop è l'ecosistema più attivo che esiste realmente là fuori, certamente nell'informatica aziendale. Ma se vuoi trattarlo come un database, al momento non ha alcun confronto con quello che tendo a pensare a veri e propri database, specialmente nello spazio del data warehouse. E questo spiega in una certa misura il successo di alcuni dei grandi database NoSQL che non funzionano su Hadoop come CouchDB e così via.

Come data lake ha un ecosistema molto più ricco di qualsiasi altra piattaforma e non sarà sostituito da quello. Il suo ecosistema non è solo l'ecosistema open source. Ora c'è un numero drammatico di membri del software che hanno prodotti fondamentalmente creati per Hadoop o che sono stati importati in Hadoop. E hanno appena creato un ecosistema che non c'è nulla che possa competere con esso in termini di ampiezza. Ciò significa che è diventata la piattaforma per l'innovazione dei big data. Ma a mio avviso è ancora immaturo e potremmo avere lunghe discussioni su ciò che è e non è, diciamo, operativamente maturo con Hadoop, ma penso che la maggior parte delle persone che guardano a questa particolare area siano ben consapevoli che Hadoop è decenni indietro rispetto al mainframe in termini di capacità operativa.

Il lago dei dati in evoluzione. Il data lake è una piattaforma per qualsiasi definizione e se pensate che ci sia un layer di dati nell'informatica aziendale ora è molto facile pensarlo in termini di database fissi più il data lake che costituisce il layer di dati. Le applicazioni di Data Lake sono molte e varie. Ho un diagramma qui che passa attraverso i vari dati che si contorcono le cose che devono essere fatte se si utilizza Hadoop come area di gestione temporanea o Hadoop e Spark come area di gestione temporanea. E hai tutto - lignaggio dei dati, pulizia dei dati, gestione dei metadati, scoperta dei metadati - può essere utilizzato per ETL stesso ma spesso richiede ETL per inserire i dati. Gestione dei dati master, definizioni aziendali dei dati, gestione dei servizi di cosa sta succedendo in Hadoop, gestione del ciclo di vita dei dati ed ETL fuori da Hadoop, e hai anche applicazioni di analisi diretta che puoi eseguire su Hadoop.

Ed è per questo che è diventato molto potente e dove è stato implementato e implementato con successo, normalmente ha almeno una raccolta di questo tipo di applicazioni in esecuzione su di esso. E la maggior parte di quelle applicazioni, in particolare quelle di cui sono stato informato, non sono disponibili sul mainframe in questo momento. Ma potresti eseguirli sul mainframe, su un cluster Hadoop che era in esecuzione in una partizione del mainframe.

Il data lake sta diventando, a mio avviso, l'area di gestione temporanea naturale per l'analisi rapida dei database e per la BI. Diventa il luogo in cui prendi i dati, siano essi dati aziendali o dati esterni, rovinandoli fino a quando, diciamo, non è abbastanza pulito da usare e ben strutturato da usare e poi lo trasmetti. E tutto questo è ancora agli inizi.

L'idea, secondo me, della coesistenza tra mainframe e Hadoop, la prima cosa è che è improbabile che le grandi aziende abbandonino il mainframe. In effetti, le indicazioni che ho visto di recente implicano che c'è un investimento crescente nel mainframe. Ma non ignoreranno neanche l'ecosistema Hadoop. Sto vedendo cifre del 60 percento delle grandi aziende che usano Hadoop anche se molte di loro sono in realtà solo prototipazione e sperimentazione.

L'enigma quindi è: "Come si fa a far convivere queste due cose?" Perché dovranno condividere i dati. I dati che vengono portati nel data lake devono essere trasferiti al mainframe. I dati che si trovano sul mainframe potrebbero dover andare nel data lake o attraverso il data lake per essere uniti ad altri dati. E succederà. Ciò significa che richiede un rapido trasferimento di dati / funzionalità ETL. È improbabile che i carichi di lavoro vengano condivisi in modo dinamico, diciamo, in un ambiente mainframe o con qualcosa in un ambiente Hadoop. Saranno dati condivisi. E la maggior parte dei dati risiederà inevitabilmente su Hadoop semplicemente perché è la piattaforma più economica. E probabilmente anche l'elaborazione analitica end-to-end risiederà lì.

In sintesi, alla fine dobbiamo pensare in termini di un livello di dati aziendali, che per molte aziende includerà il mainframe. E quel livello di dati deve essere gestito in modo proattivo. Altrimenti i due non coesisteranno bene. Posso restituirti la palla Eric.

Eric Kavanagh: Ancora una volta, Tendü ti ho appena fatto presentatore, quindi portalo via.

Tendü Yogurtçu: Grazie, Eric. Grazie per avermi Ciao a tutti. Parlerò dell'esperienza di Syncsort con i clienti in relazione al modo in cui vediamo i dati come una risorsa nell'organizzazione livellata dal mainframe ai big data su piattaforme di analisi. E spero che alla fine della sessione avremo anche il tempo di avere domande dal pubblico perché questa è davvero la parte più preziosa di questi webcast.

Solo per le persone che non sanno cosa fa Syncsort, Syncsort è una società di software. Siamo in giro da oltre 40 anni. Iniziato dal lato mainframe e i nostri prodotti spaziano dal mainframe a Unix alle piattaforme di big data, tra cui Hadoop, Spark, Splunk, sia on premise che nel cloud. La nostra attenzione è sempre stata rivolta ai prodotti di dati, elaborazione dei dati e prodotti di integrazione dei dati.

La nostra strategia per quanto riguarda i big data e Hadoop è stata davvero parte dell'ecosistema fin dal primo giorno. Come proprietari di fornitori che si sono concentrati davvero sull'elaborazione dei dati con motori molto leggeri, abbiamo pensato che ci fosse una grande opportunità di partecipare a Hadoop diventando una piattaforma di elaborazione dei dati e far parte di questa architettura di data warehouse di prossima generazione per l'organizzazione. Abbiamo contribuito ai progetti Apache open source dal 2011, a partire da MapReduce. Sono stati tra i primi dieci per Hadoop versione 2 e hanno partecipato a più progetti, inclusi pacchetti Spark, alcuni dei nostri connettori sono pubblicati in pacchetti Spark.

Sfruttiamo il nostro motore di elaborazione dei dati molto leggero, che è metadata completamente basato su file flat, e si adatta molto bene con i file system distribuiti come Hadoop Distributed File System. E sfruttiamo la nostra eredità sul mainframe, la nostra esperienza con gli algoritmi quando pubblichiamo i nostri prodotti per i big data. E collaboriamo a stretto contatto con i principali fornitori, i principali attori qui tra cui Hortonworks, Cloudera, MapR, Splunk. Hortonworks ha recentemente annunciato che rivenderanno il nostro prodotto per l'ETL a bordo con Hadoop. Con Dell e Cloudera abbiamo una partnership molto stretta che sta anche rivendendo il nostro prodotto ETL come parte del loro dispositivo per big data. E con Splunk in realtà, pubblichiamo una telemetria del mainframe e i dati di sicurezza nei dashboard di Splunk. Abbiamo una stretta collaborazione.

Cosa ha in mente ogni dirigente di livello C? È davvero, "Come posso attingere alle mie risorse di dati?" Tutti parlano di big data. Tutti parlano di Hadoop, Spark, la prossima piattaforma informatica che potrebbe aiutarmi a creare agilità aziendale e aprire nuove applicazioni trasformative. Nuove opportunità go-to-market. Ogni singolo dirigente pensa: "Qual è la mia strategia sui dati, qual è la mia iniziativa sui dati e come posso assicurarmi di non rimanere indietro rispetto alla concorrenza e di essere ancora in questo mercato nei prossimi tre anni?" guarda questo mentre parliamo con i nostri clienti, mentre parliamo con la nostra base di clienti globale, che è abbastanza grande, come puoi immaginare, dato che siamo in giro da un po '.

Mentre parliamo con tutte queste organizzazioni, vediamo anche questo nello stack tecnologico nella rottura che è avvenuta con Hadoop. È davvero al fine di soddisfare questa richiesta di dati come risorsa. Sfruttando tutte le risorse di dati di un'organizzazione. E abbiamo visto l'architettura del data warehouse aziendale evolversi in modo tale che Hadoop ora sia il nuovo fulcro della moderna architettura dati. E la maggior parte dei nostri clienti, sia che si tratti di servizi finanziari, sia che si tratti di assicurazioni, di servizi di telecomunicazioni al dettaglio, di solito le iniziative sono che troviamo Hadoop come servizio o dati come servizio. Perché tutti stanno cercando di rendere disponibili le risorse di dati per i propri clienti esterni o interni. E in alcune organizzazioni vediamo iniziative come quasi un mercato dei dati per i loro clienti.

E uno dei primi passi da compiere è quello di creare un hub dati aziendale. A volte la gente lo chiamerà un data lake. La creazione di questo hub di dati aziendali in realtà non è così semplice come sembra perché richiede davvero l'accesso e la raccolta praticamente di tutti i dati dell'azienda. E quei dati provengono ora da tutte le nuove fonti come sensori mobili e database legacy ed è in modalità batch e in modalità streaming. L'integrazione dei dati è sempre stata una sfida, tuttavia, con il numero e la varietà di fonti di dati e i diversi stili di consegna, siano essi batch o streaming in tempo reale, ora è ancora più impegnativo rispetto a cinque anni fa, dieci anni fa. A volte ci riferiamo ad esso come "Non è più l'ETL di tuo padre".

Quindi parliamo delle diverse risorse di dati. Dato che le aziende stanno cercando di dare un senso ai nuovi dati, i dati che raccolgono dai dispositivi mobili, siano essi i sensori in un produttore di auto o i dati dell'utente per un'azienda di giochi mobile, spesso devono fare riferimento alle risorse di dati più importanti in l'impresa, ad esempio le informazioni sui clienti. Queste risorse di dati più importanti spesso vivono sul mainframe. La correlazione dei dati del mainframe con queste nuove fonti emergenti, raccolte nel cloud, raccolte tramite dispositivi mobili, raccolte sulla linea di produzione di una casa automobilistica giapponese o applicazioni Internet of Things, deve dare un senso a questi nuovi dati facendo riferimento ai loro set di dati legacy. E questi set di dati legacy sono spesso sul mainframe.

E se queste aziende non sono in grado di farlo, non sono in grado di attingere ai dati del mainframe, allora c'è un'opportunità mancata. Quindi i dati come servizio o sfruttando tutti i dati aziendali non sfruttano realmente le risorse più importanti dell'organizzazione. C'è anche la parte dei dati di telemetria e di sicurezza perché praticamente tutti i dati transazionali vivono sul mainframe.

Immagina di andare a un bancomat, penso che uno dei partecipanti abbia inviato un messaggio ai partecipanti qui per proteggere il sistema bancario, quando si sta scorrendo la carta che i dati transazionali sono praticamente a livello globale sul mainframe. E proteggere e raccogliere i dati di sicurezza e i dati di telemetria dai mainframe e renderli disponibili tramite dashboard Splunk o altri, Spark, SQL, diventa ora più critico che mai, a causa del volume dei dati e della varietà dei dati.

Il set di abilità è una delle maggiori sfide. Perché da un lato hai uno stack di big data in rapida evoluzione, non sai quale progetto sopravviverà, quale progetto non sopravviverà, dovrei assumere sviluppatori Hive o Pig? Dovrei investire in MapReduce o Spark? O la prossima cosa, Flink, qualcuno ha detto. Dovrei investire in una di queste piattaforme di computer? Da un lato, tenere il passo con l'ecosistema in rapida evoluzione è una sfida e, dall'altro, si hanno queste origini dati legacy. I nuovi set di abilità non corrispondono davvero e potresti avere un problema perché quelle risorse potrebbero effettivamente andare in pensione. C'è un grande divario in termini di set di abilità di persone che comprendono quelle pile di dati legacy e che comprendono lo stack tecnologico emergente.

La seconda sfida è la governance. Quando si accede realmente a tutti i dati aziendali attraverso le piattaforme, abbiamo clienti che hanno sollevato dubbi sul fatto che “non voglio che i miei dati vengano trasferiti. Non voglio che i miei dati vengano copiati in più punti perché voglio evitare il più possibile le copie multiple. Voglio avere un accesso end-to-end senza atterrare nel mezzo lì. ”Governare questi dati diventa una sfida. E l'altro pezzo è che se si accede a dati che presentano colli di bottiglia, se si raccolgono la maggior parte dei dati nel cloud e si accede e si fa riferimento a dati legacy, la larghezza di banda della rete diventa un problema, una piattaforma cluster. Ci sono molte sfide in termini di avere questa iniziativa sui big data e piattaforme di analisi avanzate e sfruttare tutti i dati aziendali.

Ciò che Syncsort offre è che noi siamo definiti semplicemente "i migliori" non perché siamo semplicemente i migliori, ma i nostri clienti ci definiscono semplicemente i migliori nell'accesso e nell'integrazione dei dati del mainframe. Supportiamo tutti i formati di dati dal mainframe e li rendiamo disponibili per l'analisi dei big data. Che si tratti di Hadoop o Spark o della prossima piattaforma di computer. Perché i nostri prodotti isolano davvero le complessità della piattaforma informatica. Come sviluppatore, stai potenzialmente sviluppando su un laptop, ti stai concentrando sulla pipeline di dati e su quali sono i preparativi dei dati, i passaggi per rendere questi dati creati per l'analisi, la fase successiva e prendere la stessa applicazione in MapReduce o prenderla stessa applicazione in giro in Spark.

Abbiamo aiutato i nostri clienti a farlo quando YARN è diventato disponibile e hanno dovuto spostare le loro applicazioni da MapReduce versione 1 a YARN. Li stiamo aiutando a fare lo stesso con Apache Spark. Il nostro prodotto, la nuova versione 9 funziona anche con Spark e viene fornito con un'ottimizzazione dinamica che isolerà queste applicazioni per futuri framework di computer.

Quindi abbiamo accesso ai dati del mainframe, siano essi file VSAM, siano essi DB2 o siano dati di telemetria, come record SMF o Log4j o syslog, che devono essere visualizzati tramite dashboard Splunk. E mentre lo fa, poiché l'organizzazione può sfruttare il proprio ingegnere di dati esistente o set di competenze ETL, il tempo di sviluppo è significativamente ridotto. In effetti, con Dell e Cloudera, era stato sponsorizzato un benchmark indipendente e tale benchmark si concentrava sui tempi di sviluppo necessari se si esegue la codifica manuale o si utilizzano altri strumenti come Syncsort, con una riduzione del 60-70% dei tempi di sviluppo . Colmare le competenze crea divario tra i gruppi, attraverso quegli host di file di dati e anche quegli host di file di dati in termini di persone.

Di solito il team di big data, o il team di acquisizione dati, o il team incaricato di sviluppare questi dati come architettura di servizio, non parlano necessariamente con il team di mainframe. Vogliono minimizzare tale interazione quasi in molte organizzazioni. Colmando questo divario abbiamo avanzato. E la parte più importante è davvero proteggere l'intero processo. Perché nell'azienda quando si ha a che fare con questo tipo di dati sensibili ci sono molti requisiti.

In settori altamente regolamentati come quello assicurativo e bancario, i nostri clienti chiedono: "Offri questo accesso ai dati mainframe ed è fantastico. Puoi anche offrirmi di mantenere questo formato di record con codifica EBCDIC conservato nel suo formato originale in modo da poter soddisfare i miei requisiti di audit? ”Quindi facciamo capire a Hadoop e Apache Spark i dati del mainframe. È possibile conservare i dati nel formato di registrazione originale, eseguire la piattaforma di elaborazione e distribuzione dei livelli del computer e, se è necessario ripristinarli, è possibile mostrare che il record non è cambiato e il formato del record non è cambiato, è possibile soddisfare i requisiti normativi .

E la maggior parte delle organizzazioni, mentre stanno creando l'hub dati o il data lake, stanno anche provando a farlo con un solo clic per poter mappare i metadati da centinaia di schemi in un database Oracle a tabelle Hive o file ORC o Parquet diventa necessario. Forniamo strumenti e forniamo strumenti per rendere questo un accesso ai dati in una sola fase, la generazione automatica di lavori o lo spostamento dei dati e la generazione automatica di lavori per effettuare la mappatura dei dati.

Abbiamo parlato della parte relativa alla connettività, della conformità, della governance e del trattamento dei dati. E i nostri prodotti sono disponibili sia on premise che nel cloud, il che rende davvero molto semplice perché le aziende non hanno bisogno di pensare a cosa succederà nel prossimo anno o due se decido di andare completamente nel cloud pubblico rispetto all'ibrido ambiente, poiché alcuni cluster potrebbero essere in esecuzione in locale o nel cloud. E i nostri prodotti sono disponibili sia su Amazon Marketplace, su EC2, su Elastic MapReduce che su un container Docker.

Giusto per concludere, quindi abbiamo abbastanza tempo per le domande e risposte, si tratta davvero di accedere, integrare e rispettare la governance dei dati, rendendo tutto ancora più semplice. E mentre lo rende più semplice, "progettare una volta e distribuire ovunque" nel vero senso grazie ai nostri contributi open source, il nostro prodotto funziona nativamente nel flusso di dati Hadoop e nativamente con Spark, isolando le organizzazioni dall'ecosistema in rapida evoluzione. E fornendo un'unica pipeline di dati, un'unica interfaccia, sia per batch che per streaming.

E questo aiuta anche le organizzazioni a volte a valutare questi framework, perché potresti voler effettivamente creare applicazioni ed eseguire semplicemente MapReduce contro Spark e vedere di persona, sì, Spark ha questa promessa e fornisce tutto l'avanzamento degli algoritmi iterativi per il miglior machine learning e le applicazioni di analisi predittiva funzionano con Spark, posso anche fare in modo che i miei carichi di lavoro in streaming e batch vengano eseguiti su questo framework di computer? Puoi testare diverse piattaforme di computer utilizzando i nostri prodotti. E l'ottimizzazione dinamica sia che tu stia eseguendo su un server autonomo, sul tuo laptop, in Google Cloud rispetto ad Apache Spark, è davvero una proposta di grande valore per i nostri clienti. Ed è stato veramente guidato dalle sfide che hanno dovuto affrontare.

Tratterò solo uno dei casi studio. Questa è la compagnia di assicurazione sulla vita Guardian. E l'iniziativa di Guardian è stata davvero quella di centralizzare le proprie risorse di dati e renderle disponibili per i propri clienti, ridurre i tempi di preparazione dei dati e hanno affermato che tutti parlano di preparazione dei dati occupando l'80% dell'intera pipeline di elaborazione dei dati e hanno affermato che in realtà si stava verificando Dal 75 all'80% per loro e volevano ridurre la preparazione dei dati, i tempi di trasformazione, il time-to-market per i progetti di analisi. Crea quell'agilità mentre aggiungono nuove fonti di dati. E rendere disponibile l'accesso centralizzato ai dati per tutti i loro clienti.

La loro soluzione, inclusi i prodotti Syncsort, è in questo momento hanno un marketplace di dati simili a Amazon Marketplace supportato da un data lake, che è fondamentalmente Hadoop, e database NoSQL. Inoltre, utilizzano i nostri prodotti per portare tutte le risorse di dati nel data lake, incluso DB2 su mainframe, inclusi i file VSAM su mainframe, le origini dati legacy del database e le nuove origini dati. E di conseguenza hanno centralizzato le risorse di dati riutilizzabili che sono ricercabili, accessibili e disponibili per i loro clienti. E sono davvero in grado di aggiungere nuove fonti di dati e servire i loro clienti molto più velocemente ed efficientemente di prima. E anche le iniziative di analisi stanno progredendo ancora di più sul lato predittivo. Quindi farò una pausa e spero che questo sia stato utile e se avete domande per me su uno qualsiasi degli argomenti correlati, per favore, siete i benvenuti.

Eric Kavanagh: Certo, e Tendü, ne inserirò uno. Ho ricevuto un commento da un membro del pubblico che diceva semplicemente: "Mi piace questo design una volta, implementalo ovunque". Puoi approfondire come è vero? Voglio dire, cosa hai fatto per abilitare quel tipo di agilità e ci sono delle tasse? Come quando parliamo di virtualizzazione, ad esempio, c'è sempre un po 'di imposta sulle prestazioni. Alcune persone dicono il due percento, il cinque percento il 10 percento. Cosa hai fatto per abilitare il design una volta, implementarlo ovunque: come lo fai e c'è qualche imposta associata in termini di prestazioni?

Tendü Yogurtçu: Certo, grazie. No, perché a differenza di alcuni degli altri fornitori non generiamo realmente Hive o Pig o altri codici che non sono nativi dei nostri motori. È qui che i nostri contributi open source hanno avuto un ruolo enorme, poiché abbiamo lavorato a stretto contatto con i fornitori di Hadoop, Cloudera, Hortonworks e MapR e, grazie ai nostri contributi open source, il nostro motore funziona in modo nativo come parte del flusso, come parte del flusso Hadoop, come parte della Spark.

Ciò che si traduce anche, abbiamo questa ottimizzazione dinamica. Ciò è emerso in seguito alla sfida dei nostri clienti con i framework dei computer. Mentre stavano entrando in produzione con alcune applicazioni, sono tornati, hanno detto: "Sto solo stabilizzando il mio cluster Hadoop, stabilizzando su MapReduce YARN versione 2, MapReduce versione 2, e la gente sta parlando che MapReduce è morto, Spark è la prossima cosa, e alcune persone stanno dicendo che Flink sarà la prossima, come farò a farcela? ”

E quelle sfide sono diventate così ovvie per noi, abbiamo investito in questa ottimizzazione dinamica che chiamiamo esecuzione intelligente. In fase di esecuzione, quando il lavoro, quando viene inviata questa pipeline di dati, in base al cluster, sia Spark, sia MapReduce o un server autonomo Linux, decidiamo come eseguire questo lavoro, nativamente nel nostro motore, come parte di quello Flusso di dati Hadoop o Spark. Non ci sono spese generali perché tutto viene fatto attraverso questa ottimizzazione dinamica che abbiamo e tutto viene anche fatto perché il nostro motore è integrato in modo nativo a causa dei nostri contributi open source. Questo risponde alla tua domanda?

Eric Kavanagh: Sì, va bene. E voglio sollevare un'altra domanda laggiù, e poi Dez, forse tireremo anche te e Robin. Ho appena ricevuto un commento divertente da uno dei nostri partecipanti. Lo leggerò perché è davvero piuttosto conciso. Scrive: "Sembra che nella storia delle cose CALDE" - capito? Come l'IoT - "è che più si tenta di" semplificare "qualcosa di veramente complesso, il più delle volte più semplice sembra fare le cose, il viene fornita più corda per appendere. Pensa a query di database, esplosione, multi-threading, ecc. ”Puoi commentare questo paradosso a cui fa riferimento? Semplicità contro complessità, e in sostanza cosa sta succedendo sotto le copertine?

Tendü Yogurtçu: Sicuro. Penso che sia un punto molto valido. Quando stai semplificando le cose e stai facendo queste ottimizzazioni, in qualche modo sotto le coperte, qualcuno deve prendere quella complessità di ciò che deve accadere, giusto? Se stai paralizzando qualcosa o se stai decidendo come eseguire un determinato lavoro rispetto al framework del computer, ovviamente c'è una parte del lavoro che viene spinta sia che si tratti del lato utente, della codifica dei menu o dell'ottimizzazione del motore. C'è una parte di ciò, semplificando l'esperienza dell'utente c'è un enorme vantaggio in termini di essere in grado di sfruttare le competenze che esistono nell'azienda.

E puoi in qualche modo mitigare quel paradosso, mitigare quella sfida di "Sì, ma non ho il controllo su tutto ciò che sta accadendo sotto la copertura, sotto il cofano in quel motore", esponendo le cose agli utenti più avanzati se loro voglio avere quel tipo di controllo. Investendo anche in alcuni tipi di cose utili. Essere in grado di offrire più metadati operativi, più dati operativi, come nell'esempio fornito da questo partecipante, per una query SQL e con il motore in esecuzione. Spero che risponda.

Eric Kavanagh: Sì, suona bene. Dez, portalo via.

Dez Blanchfield: Sono davvero desideroso di ottenere un po 'più di comprensione della tua impronta nei contributi open source e nel viaggio che hai fatto dalla tua esperienza tradizionale di lunga data nel mainframe e nel mondo proprietario e poi il passaggio a contribuire all'open source e al modo in cui ciò è avvenuto. E l'altra cosa che mi piacerebbe capire è l'opinione che stai vedendo che le aziende, non solo i dipartimenti IT, ma le aziende ora stanno prendendo in considerazione gli hub di dati o i laghi di dati come dicono ora le persone e se vedono questa tendenza di solo un singolo data lake consolidato o se stiamo vedendo data lake distribuiti e le persone utilizzano strumenti per metterli insieme?

Tendü Yogurtçu: Sicuro. Per il primo, quello è stato un viaggio molto interessante, come società di software proprietario, uno dei primi dopo IBM. Tuttavia, ancora una volta, tutto è iniziato con i nostri clienti evangelisti che guardavano Hadoop. Avevamo società di dati come ComScore, erano tra le prime ad adottare Hadoop perché stavano raccogliendo dati digitali in tutto il mondo e non erano in grado di conservare i dati per 90 giorni a meno che non avessero investito nella loro scatola di dati da dieci milioni di dollari ambiente. Hanno iniziato a guardare Hadoop. Con ciò abbiamo iniziato anche a guardare Hadoop.

E quando abbiamo preso una decisione e riconosciuto che Hadoop sarà davvero la piattaforma di dati del futuro, siamo anche giunti alla conclusione che non saremo in grado di avere un ruolo in questo, un gioco di successo in questo, a meno che non facevano parte dell'ecosistema. E abbiamo lavorato a stretto contatto con i fornitori di Hadoop, con Cloudera, Hortonworks, MapR, ecc. Abbiamo iniziato davvero a parlare con loro perché la partnership diventa molto importante per convalidare il valore che un fornitore può offrire e anche assicurarci di poter andare insieme all'azienda e offrire qualcosa di più significativo. Richiedeva molta costruzione di relazioni perché non eravamo noti ai progetti open source di Apache, tuttavia, abbiamo avuto un grande supporto da parte di questi venditori Hadoop, devo dire.

Abbiamo iniziato a lavorare insieme e guardando all'hub, come possiamo apportare valore senza nemmeno il nostro software proprietario nello spazio. Questo è stato importante. Non si tratta solo di mettere alcune API su cui il tuo prodotto può funzionare, ma di poter dire che investirò in questo perché credo che Hadoop diventerà una piattaforma del futuro, quindi investendo nelle fonti che volevamo realizzare sicuro che matura e diventa pronto per l'impresa. Possiamo effettivamente abilitare alcuni dei casi d'uso che non erano disponibili prima dei nostri contributi. Ciò andrà a beneficio dell'intero ecosistema e possiamo sviluppare da vicino tali partenariati.

Ci è voluto un bel po 'di tempo. Abbiamo iniziato a contribuire nel 2011 e 2013, il 21 gennaio - ricordo la data perché quella data è stata impegnata il nostro più grande contributo, il che significa che ora possiamo avere i nostri prodotti generalmente disponibili da quel momento in poi - ci è voluto del tempo per sviluppare tali relazioni, mostra il valore, i partner diventano partner di progettazione con i venditori e con i committer nella comunità open source. Ma è stato molto divertente. Come azienda è stato molto gratificante far parte di quell'ecosistema e sviluppare una grande collaborazione.

La seconda domanda sull'hub dati / data lake, penso che quando vediamo questi dati come un'implementazione del servizio nella maggior parte dei casi, sì, potrebbero essere cluster, fisicamente singoli o più cluster, ma è più concettuale che diventare quel singolo posto per tutti i dati. Perché in alcune organizzazioni vediamo implementazioni di cluster di grandi dimensioni on premise, tuttavia hanno anche cluster, ad esempio, nel cloud pubblico perché alcuni dei dati raccolti dalle sezioni online sono davvero mantenuti nel cloud. È importante disporre di un'unica pipeline di dati che sia possibile sfruttare entrambi e utilizzarli come un singolo hub di dati, un singolo data lake, diventa importante. Non necessariamente solo il luogo fisico, ma avere quell'hub di dati e il data lake tra cluster, aree geografiche e forse on premise e cloud sarà molto critico, penso. Soprattutto andando avanti. Quest'anno abbiamo iniziato a vedere sempre più implementazioni cloud. È fantastico. La prima metà di quest'anno finora abbiamo visto molte implementazioni cloud.

Eric Kavanagh: Okay, fico. E Robin, hai qualche domanda? So che ci restano solo un paio di minuti.

Robin Bloor: Okay, posso farle una domanda. La prima cosa che mi è venuta in mente è che c'è stata molta eccitazione per Kafka e io ero interessato alla tua opinione su Kafka e su come ti integri con il modo in cui le persone usano Kafka?

Tendü Yogurtçu: Sicuro. Sì, Kafka sta diventando abbastanza popolare. Tra i nostri clienti vediamo che essere una specie di livello di trasporto dei dati e visto che i dati sono un bus, praticamente. Ad esempio, uno dei nostri clienti stava effettivamente utilizzando una specie di dati di consumo che sono stati inseriti in questo Kafka tra più, come migliaia di utenti online e in grado di classificarli e farcela.

Ancora una volta, Kafka è un bus dati per i diversi consumatori di questi dati. Classificare alcuni utenti avanzati rispetto a utenti non così avanzati e fare qualcosa di diverso andando avanti in quella pipeline di dati. Il modo in cui ci integriamo con Kafka è fondamentalmente, il nostro prodotto DMX-h diventa un consumatore affidabile, un consumatore altamente efficiente e affidabile per Kafka. Può leggere i dati e questo non è diverso dalla lettura dei dati da qualsiasi altra fonte di dati per noi. Offriamo agli utenti la possibilità di controllare la finestra in termini di tempo richiesto o numero di messaggi che potrebbero consumare dal bus Kafka. E poi possiamo anche arricchire questi dati mentre passano attraverso il nostro prodotto e vengono reinseriti in Kafka. Abbiamo provato questo. Lo abbiamo testato nel sito del cliente. Anche certificato da Confluent. Lavoriamo a stretto contatto con i ragazzi di Confluent ed è molto performante e facile da usare. Ancora una volta, le API cambiano, ma non devi preoccuparti perché il prodotto lo considera davvero solo come un'altra fonte di dati, una fonte di dati in streaming. È davvero divertente lavorare con il nostro prodotto e Kafka, in realtà.

Robin Bloor: Okay, ho un'altra domanda che è una specie di domanda commerciale generale, ma conosco Syncsort da molto tempo e hai sempre avuto la reputazione e fornito software straordinariamente veloce per ETL e il mondo dei mainframe. È il caso che la maggior parte della tua azienda sia ora trasferita su Hadoop? È il caso che in un modo o nell'altro tu abbia in qualche modo diffuso la tua attività in modo piuttosto drammatico dal mondo dei mainframe?

Tendü Yogurtçu: i nostri prodotti mainframe gestiscono ancora il 50 percento dei mainframe a livello globale. Quindi abbiamo una linea di prodotti mainframe molto forte, oltre a ciò che stiamo facendo sui big data e alla fine di Hadoop. E siamo ancora nella maggior parte dei progetti di semplificazione o ottimizzazione IT perché c'è un'estremità che si desidera poter attingere ai dati del mainframe nelle piattaforme Multex per big data e sfruttare tutti i dati aziendali, tuttavia ci sono anche carichi di lavoro transazionali molto critici che continua ancora a funzionare sul mainframe e offriamo a quei clienti i modi per rendere davvero più efficienti quelle applicazioni, funzionare nel motore zIIP in modo che non consumino tanti cicli di elaborazione e MIPS, rendendoli convenienti.

Continuiamo a investire nei prodotti mainframe e in realtà giochiamo in questo spazio in cui le persone passano dal mainframe big iron ai big data e abbracciano la linea di prodotti anche attraverso quelle piattaforme. Quindi non necessariamente spostiamo l'intera attività da una parte, continuiamo ad avere attività di grande successo da entrambe le parti. E le acquisizioni sono al centro anche per noi. Con l'evoluzione di questo spazio di gestione e elaborazione dei dati per le piattaforme di big data, ci impegniamo anche a fare alcune acquisizioni gratuite.

Robin Bloor: Beh, immagino di non poterti chiedere cosa sono perché non ti sarebbe permesso dirmelo. Mi interessa sapere se hai visto molte implementazioni di Hadoop o Spark sul mainframe o se è una cosa molto rara.

Tendü Yogurtçu: Non ne abbiamo visto nessuno. C'è più domanda a riguardo. Penso che Hadoop sul mainframe non abbia molto senso a causa del tipo di struttura centrale. Tuttavia Spark su mainframe è piuttosto significativo e Spark è davvero molto bravo con l'apprendimento automatico e l'analisi predittiva e essere in grado di avere alcune di quelle applicazioni con dati di mainframe è davvero, penso, abbastanza significativo. Non abbiamo ancora visto nessuno farlo, tuttavia è davvero il caso d'uso che guida queste cose. Se il tuo caso d'uso come azienda porta più quei dati mainframe e si integra con il resto dei set di dati nella piattaforma di big data, questa è una storia. Richiede l'accesso ai dati del mainframe dalla piattaforma Multex per big data perché è improbabile che porti i tuoi set di dati da sistemi aperti e richiamati al mainframe. Tuttavia, se si dispone di alcuni dati del mainframe che si desidera esplorare e fare solo un po 'di esplorazione dei dati, applicare un AI avanzato e analisi avanzate, Spark potrebbe essere un buon modo per andare ed eseguire sul mainframe in quel modo.

Eric Kavanagh: Ed ecco un'altra domanda del pubblico, in realtà altre due. Ti farò una domanda per il team di tag, quindi concluderemo. Un partecipante sta chiedendo: "IBM sta integrando i tuoi contributi open source sul suo ecosistema di cloud pubblico, in altre parole, Bluemix?" E un altro partecipante ha fatto davvero un buon punto, osservando che Syncsort è ottimo per mantenere vivo il ferro da stiro per coloro che ce l'ho già, ma se le aziende rinunciano a nuovi mainframe a favore di ciò che lui chiama CE, annulla tutto, ciò probabilmente diminuirà, ma nota che siete davvero bravi a spostare i dati bypassando i sistemi operativi fino a un gigabyte al secondo. Puoi in qualche modo parlare della tua forza principale, come ha detto, e se IBM sta integrando le tue cose in Bluemix?

Tendü Yogurtçu: Con IBM, siamo già partner di IBM e abbiamo discusso dei loro servizi di cloud dati che offrono il prodotto. I nostri contributi open source sono aperti a tutti coloro che vogliono sfruttarli. Parte della connettività mainframe è disponibile anche nei pacchetti Spark, quindi non solo IBM. Chiunque può sfruttare quelli. Nel Bluemix non abbiamo ancora fatto nulla di specifico. E ti dispiace ripetere la seconda domanda?

Eric Kavanagh: Sì, la seconda domanda riguardava la tua principale area di funzionalità nel corso degli anni, che stava davvero gestendo strozzature di ETL e ovviamente è qualcosa che voi ragazzi continuerete a fare come mainframe, beh, teoricamente state alla larga, anche se Dez il punto è ancora una sorta di dondolio e rotolamento là fuori. Ma il partecipante ha appena notato che Syncsort è molto bravo a spostare i dati bypassando i sistemi operativi e fino a un gigabyte al secondo. Puoi commentarlo?

Tendü Yogurtçu: Sì, l'efficienza delle risorse nel complesso è stata la nostra forza e la scalabilità e le prestazioni sono state la nostra forza. Non scendiamo a compromessi, semplificare ha molti significati, non scendiamo a compromessi da questi. Quando le persone hanno iniziato a parlare di Hadoop nel 2014, ad esempio, molte organizzazioni inizialmente non guardavano alle prestazioni. Stavano dicendo: "Oh, se succede qualcosa, posso aggiungere un altro paio di nodi e starò bene, le prestazioni non sono il mio requisito".

Mentre stavamo parlando di avere le migliori prestazioni perché stavamo già eseguendo in modo nativo, non avevamo nemmeno alcuni dei singhiozzi iniziali che Hive aveva con più lavori MapReduce e spese generali all'avvio. La gente ci diceva: "Oh, non è questa la mia preoccupazione, non preoccuparti al momento."

Quando siamo arrivati ​​al 2015 quel panorama è cambiato perché alcuni dei nostri clienti hanno già superato lo storage che avevano nei loro cluster di produzione. È diventato molto importante per loro vedere cosa può offrire Syncsort. Se stai prendendo alcuni dati da un database o mainframe e stai scrivendo in un formato Parquet nei cluster, se atterri e fai stage e fai un'altra trasformazione o fai semplicemente la trasformazione in volo e atterri il formato del file di destinazione, hai fatto la differenza perché stai salvando da archiviazione, si sta salvando dalla larghezza di banda della rete, si sta salvando dal carico di lavoro sul cluster perché non si eseguono lavori extra. Sembra che quei punti di forza che giochiamo in termini di consapevolezza, sentiamo l'efficienza delle risorse sotto la nostra pelle.

Ecco come lo descriviamo. È fondamentale per noi. Non lo diamo per scontato. Non l'abbiamo mai dato per scontato, quindi continueremo a essere forti con quella leva in Apache Spark o nel prossimo framework per computer. Quello continuerà a essere il nostro obiettivo. E in termini di movimento dei dati e accesso ai dati, sicuramente è uno dei nostri punti di forza e stiamo accedendo ai dati DB2 o VSAM sui mainframe nel contesto di Hadoop o Spark.

Eric Kavanagh: Beh, è ​​un ottimo modo per terminare il webcast, gente. Grazie mille per il tuo tempo e la tua attenzione. Grazie a te, Tendü e Syncsort, per essere entrati nella stanza del briefing e aver fatto il giro, come si suol dire. Molte grandi domande da parte del pubblico. È un ambiente in continuo movimento, gente. Archiveremo questa tecnologia avanzata come facciamo con tutti gli altri. Puoi trovarci su insideanalysis.com e su techopedia.com. Di solito sale in circa un giorno. E con questo, ti saluteremo, gente. Grazie mille. Ci sentiamo presto. Stai attento. Ciao ciao.

Grande ferro, incontra grandi dati: liberare i dati del mainframe con hadoop e spark