Por Techopedia Staff, 2 de junho de 2016
Resumo: O ecossistema Hadoop está sendo usado nos mainframes para processar big data com rapidez e eficiência.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Ok, senhoras e senhores, são quatro horas da manhã no leste de uma quinta-feira, e hoje em dia isso significa que é hora do Hot Technologies. Sim, de fato, meu nome é Eric Kavanagh. Serei seu moderador no seminário on-line de hoje. É uma coisa boa, pessoal, “Big Iron, Conheça Big Data” - eu simplesmente amo esse título - “Liberando dados de mainframe com Hadoop e Spark”. Vamos falar sobre velhos e novos. Uau! Estamos cobrindo o espectro de tudo o que falamos nos últimos 50 anos de TI corporativa. Spark encontra mainframe, eu adoro isso.
Há um ponto sobre o seu verdadeiramente e o suficiente sobre mim. O ano está quente. Falamos sobre tópicos importantes desta série, porque estamos realmente tentando ajudar as pessoas a entender certas disciplinas, certos espaços. O que significa, por exemplo, ter uma plataforma analítica? O que significa liberar big data dos mainframes? O que tudo isso significa? Estamos tentando ajudá-lo a entender tipos específicos de tecnologias, onde elas se encaixam no mix e como você pode usá-las.
Hoje temos dois analistas e, claro, Tendü Yogurtçu, da Syncsort. Ela é uma visionária em nosso espaço, muito satisfeita em tê-la online hoje, com nossos próprios Dez Blanchfield e Dr. Robin Bloor. Vou dizer apenas algumas palavras rápidas. Uma é que, pessoal, você desempenha um papel importante nesse processo, portanto, não tenha vergonha de fazer algumas boas perguntas. Gostaríamos de falar com eles durante o componente de perguntas e respostas do webcast, que geralmente ocorre no final do programa. E tudo o que tenho a dizer é que temos um bom conteúdo, então estou animado para ouvir o que esses garotos têm a dizer. E com isso, vou entregá-lo a Dez Blanchfield. Dez, o chão é seu, leve-o embora.
Dez Blanchfield: Obrigado, Eric, e obrigado a todos por participarem hoje. Por isso, fico bastante empolgado quando tenho a chance de falar sobre uma das minhas coisas favoritas do mundo, os mainframes. Eles não têm muito amor hoje em dia. Minha opinião é que o mainframe era a plataforma original de big data. Alguns argumentam que eles eram o único computador na época e esse é um argumento justo a se fazer, mas há mais de 60 anos eles realmente foram realmente a sala de máquinas do que o big data tem sido popular ultimamente. E eu vou levá-lo em uma pequena jornada sobre por que acredito que é esse o caso.
Vimos uma jornada nas pilhas de hardware de tecnologia no contexto dos mainframes mudar da imagem que você vê na tela agora. Este é um antigo mainframe da FACOM, um dos meus favoritos. Passamos para a grande fase do ferro, o final dos anos 90 e o boom das pontocom. Este é o Sun Microsystems E10000. Essa coisa era um monstro absoluto em 96 CPUs. Originalmente 64, mas poderia ser atualizado em 96 CPUs. Cada CPU pode executar 1.024 threads. Cada encadeamento pode estar na taxa de aplicação ao mesmo tempo. Era monstruoso e realmente impulsionou o boom das pontocom. São todos os grandes unicórnios como os chamamos, agora estamos rodando, e não apenas as grandes empresas, alguns dos grandes sites.
E então acabamos com esse modelo comum de PC de prateleira. Acabamos de amarrar muitas máquinas baratas, criamos um cluster e abordamos o grande desafio do ferro e o que se tornou big data, especialmente na forma do projeto Hadoop que deu origem ao mecanismo de pesquisa de código aberto, Nutch. E basicamente recriamos o mainframe e muitas pequenas CPUs sendo coladas e capazes de agir como caminhos L e na forma de executar trabalhos separados ou partes de trabalhos, e eles foram bastante eficazes de várias maneiras. Mais barato se você começar com menos, mas invariavelmente muitos desses grandes grupos ficaram mais caros que um mainframe.
Meu ponto de vista sobre essas coisas é que, na corrida do boom das pontocom para o que se tornou a Web 2.0 e agora perseguindo unicórnios, esquecemos que ainda existe essa plataforma que alimenta muitos de nossos maiores sistemas de missão crítica por aí. Quando pensamos sobre o que está sendo executado nas plataformas de mainframe por aí. É muito o big data, particularmente o burro de carga de dados, mas certamente o big data. Sistemas tradicionais de empresas e governos, como bancos e gerenciamento de patrimônio e seguros, em particular, todos nós usamos todos os dias.
Sistemas de reservas de companhias aéreas e de gerenciamento de voo, particularmente gerenciamento de voo onde o tempo real é crítico. Quase todos os governos estaduais e federais já tiveram um mainframe e, invariavelmente, muitos ainda os possuem. Varejo e fabricação. Alguns dos softwares antigos que existem e nunca foram embora. Apenas continua a alimentar os ambientes de fabricação e, certamente, o varejo em grande escala. Sistemas médicos. Sistemas de defesa, certamente sistemas de defesa.
Nas últimas semanas, li muitos artigos sobre o fato de que alguns dos sistemas de controle de mísseis ainda estão sendo executados em mainframes antigos para os quais estão lutando para encontrar peças. Eles estão tentando descobrir como atualizar para novos mainframes. Sistemas de transporte e logística. Estes podem não parecer os tópicos mais sexy, mas são os tópicos com os quais lidamos diariamente diariamente. E alguns ambientes de telecomunicações muito grandes ainda são executados em plataformas de mainframe.
Quando você pensa nos tipos de dados que existem, eles são todos de missão crítica. São plataformas realmente importantes e plataformas que tomamos como garantidas todos os dias e, de várias maneiras, tornam a vida possível. Então, quem ainda está usando um mainframe e quem são todas essas pessoas que estão segurando essas grandes plataformas e mantendo todos esses dados? Bem, como eu disse aqui, acredito que é fácil ser enganado pela mudança da mídia de ferro grande para prateleiras de conjuntos comuns ou PCs baratos ou máquinas x86, para pensar que o mainframe morreu e desapareceu. Mas os dados dizem que o mainframe nunca foi embora e, de fato, chegou para ficar.
A pesquisa que reuni aqui nas últimas duas semanas mostrou que 70% dos dados das empresas, especialmente as grandes, ainda residem em um mainframe de alguma forma. Setenta e um por cento das empresas da Fortune 500 ainda executam sistemas de negócios principais em mainframes em algum lugar. De fato, aqui na Austrália, temos várias organizações que têm um data center no meio de uma cidade. É um computador subterrâneo real de forma eficaz, e o número de mainframes apenas rodando por lá, funcionando e felizmente fazendo seu trabalho. E muito poucas pessoas sabem que andando pelas ruas, bem debaixo de seus pés, em uma parte específica da cidade, há um enorme data center cheio de mainframes. Noventa e dois dos 100 bancos do mundo, ou seja, os 100 principais bancos, ainda operam sistemas bancários em mainframes. Vinte e três das 25 principais redes de varejo do mundo usam mainframes para ainda executar seus sistemas de gerenciamento de varejo nas plataformas EIP e BI.
Curiosamente, 10 das 10 principais seguradoras ainda executam suas plataformas em mainframe e, na verdade, elas ativam seus serviços de nuvem em mainframe. Se você estiver usando uma interface da Web ou um aplicativo móvel em algum lugar em que haja uma interface de middleware, isso realmente conversará com algo realmente pesado e grande no back-end.
Eu encontrei mais de 225 agências governamentais estaduais e locais em todo o mundo executando em plataformas de mainframe ainda. Tenho certeza de que há muitas razões para isso. Talvez eles não tenham o orçamento para considerar o novo ferro, mas isso representa uma enorme presença de ambientes muito grandes em execução no mainframe com alguns dados muito críticos. E, como mencionei anteriormente, a maioria das nações ainda opera seus principais sistemas de defesa em mainframe. Tenho certeza de que, de muitas maneiras, eles estão tentando sair de lá, mas lá está você.
Em 2015, a IDC realizou uma pesquisa e 350 dos CIOs pesquisados relataram que ainda possuíam e gerenciavam grandes ferros sob a forma de mainframes. E me ocorreu que é provável que seja mais do que o número de clusters Hadoop em larga escala atualmente em execução em todo o mundo na produção - uma pequena estatística interessante lá. Vou prosseguir e validar isso, mas foi um grande número. Trezentos e cinquenta CIOs relataram que ainda têm um ou mais mainframes em produção.
No ano passado, 2015, a IBM nos deu o poderoso Z13, a 13ª iteração de sua plataforma de mainframe. A mídia enlouqueceu com isso, porque ficou espantada com o fato de a IBM ainda estar fabricando mainframes. Quando levantaram o capô e deram uma olhada no que estava por trás disso, eles perceberam que na verdade era parecido com quase todas as plataformas modernas que estávamos entusiasmadas na forma de big data, Hadoop e certamente os clusters. Essa coisa rodava o Spark e agora o Hadoop nativamente. Você podia rodar milhares e milhares de máquinas Linux nele e parecia e parecia com qualquer outro cluster. Era uma máquina bastante surpreendente.
Várias organizações adotaram essas coisas e, na verdade, eu fiz alguns dados sobre quantas dessas máquinas estão usando. Agora eu tenho a visão de que o terminal de texto 3270 foi substituído por navegadores da Web e aplicativos móveis por algum tempo e há muitos dados que suportam isso. Acho que agora estamos entrando em uma era em que percebemos que esses mainframes não estão desaparecendo e há uma quantidade substancial de dados sobre eles. Então, o que estamos fazendo agora é simplesmente adicionar o que chamo de ferramentas analíticas prontas para uso. Esses não são aplicativos personalizados. São coisas que são feitas sob medida. Essas são as coisas que você pode literalmente comprar em uma caixa empacotada por si só, conectar seu mainframe e fazer algumas análises.
Como eu disse antes, o mainframe existe há mais de 60 anos, na verdade. Quando pensamos em quanto tempo isso é, é mais longo do que a maioria das carreiras dos profissionais de TI. E, de fato, provavelmente algumas de suas vidas, até. Em 2002, a IBM vendeu 2.300 mainframes. Em 2013, esse número cresceu para 2.700 mainframes. São 2.700 vendas de mainframes em um ano em 2013. Não consegui obter dados precisos sobre 2015, mas imagino que esteja rapidamente se aproximando das 3.000 unidades vendidas por ano em 2015, 2013. E espero poder confirmar isso.
Com o lançamento do Z13, a 13ª iteração de uma plataforma de mainframe, que acho que custou em torno de 1, 2 ou 1, 3 bilhão de dólares para serem desenvolvidos a partir do zero, isto é, IBM, aqui está uma máquina que se parece com qualquer outro cluster que temos hoje e roda nativamente o Hadoop e o Spark. E certamente pode ser conectado a partir de outras ferramentas de análise e big data ou, invariavelmente, conectado a um dos seus clusters Hadoop existentes ou novos. Tenho uma opinião de que incluir a plataforma de mainframe em sua estratégia de big data é uma obrigação. Obviamente, se você tiver um, possui muitos dados e deseja descobrir como obtê-los. E eles estão sendo deixados para coletar poeira de várias maneiras, mental e emocionalmente até o mundo dos negócios, mas estão aqui para ficar.
A conectividade e as interfaces de todas as suas ferramentas de análise aos dados hospedados em mainframe devem ser uma parte essencial da sua empresa e, em particular, dos planos governamentais de big data. E, invariavelmente, agora o software os percebe, dando uma boa olhada neles e percebendo o que está dentro dessas coisas e conectando mentes que começam a ter um pouco de insight e um pouco de percepção do que está realmente por trás. E com isso vou entregar ao meu querido colega, Dr. Robin Bloor, e ele contribuirá para essa pequena jornada. Robin, leve embora.
Robin Bloor: Bem, obrigado. Ok, desde que Dez cantou a música do mainframe, irei abordar o que acho que está acontecendo em termos do antigo mundo do mainframe e do novo mundo do Hadoop. Eu acho que a grande questão aqui é, como você gerencia todos esses dados? Não é minha opinião que o mainframe esteja sendo desafiado em relação à sua capacidade de big data - sua capacidade de big data é extremamente, como Dez apontou, é extremamente capaz. Na verdade, você pode colocar clusters do Hadoop nele. Onde está sendo desafiado é em termos de ecossistema e eu vou elaborar um pouco sobre isso.
Aqui está um posicionamento de mainframe. Ele tem um alto custo de entrada e o que realmente aconteceu no passado, desde meados da década de 90, quando a popularidade dos mainframes começou a diminuir, tendia a perder seu ponto baixo, aquelas pessoas que compraram mainframes baratos e não é realmente particularmente econômico para essas pessoas. Mas, na verdade, na faixa intermediária e na faixa alta do mainframe, ele ainda era e, comprovadamente, é uma computação incrivelmente barata.
Deve-se dizer que foi resgatado pelo Linux porque o Linux implementado em um mainframe tornou possível, é claro, executar todos os aplicativos Linux. Muitos aplicativos Linux foram para lá antes que o big data fosse sequer uma palavra, ou duas palavras, suponho. Na verdade, é uma plataforma excelente para nuvem privada. Por isso, ele pode participar de implantações de nuvem híbrida. Um dos problemas é que as habilidades de mainframe são escassas. As habilidades de mainframe existentes realmente estão envelhecendo no sentido de que as pessoas deixam a indústria para a aposentadoria ano após ano e estão apenas sendo substituídas em termos de número de pessoas. Então isso é um problema. Mas ainda é uma computação barata.
A área em que foi desafiada, é claro, é toda essa coisa do Hadoop. Essa é uma foto de Doug Cutting com o elefante Hadoop original. O ecossistema do Hadoop é - e continuará sendo - o ecossistema dominante de big data. Oferece melhor escalabilidade do que o mainframe pode realmente alcançar e é um custo mais baixo como armazenamento de dados por um longo caminho. O ecossistema do Hadoop está evoluindo. A melhor maneira de pensar sobre isso é uma vez que uma plataforma de hardware específica e o ambiente operacional com ela se torna dominante, então o ecossistema ganha vida. E isso aconteceu com o mainframe da IBM. Bem, depois aconteceu com o VAX Digital, aconteceu com os servidores da Sun, aconteceu com o Windows, aconteceu com o Linux.
E o que aconteceu é que o Hadoop, que eu sempre penso, ou gosto de pensar, como uma espécie de ambiente distribuído para dados, o ecossistema está evoluindo a um ritmo incrível. Quero dizer, se você mencionar as várias contribuições impressionantes de código aberto, Spark, Flink, Kafka, Presto, e depois adicionar alguns dos bancos de dados, os recursos NoSQL e SQL que agora estão no Hadoop. O Hadoop é o ecossistema mais ativo que realmente existe, certamente na computação corporativa. Mas se você deseja tratá-lo como um banco de dados, no momento, não há nenhuma comparação no momento com o que costumo pensar como bancos de dados reais, especialmente no espaço do armazém de dados. E isso explica, em certa medida, o sucesso de vários grandes bancos de dados NoSQL que não são executados no Hadoop como o CouchDB e assim por diante.
Como um data lake, ele tem um ecossistema muito mais rico do que qualquer outra plataforma e não será deslocado disso. Seu ecossistema não é apenas o ecossistema de código aberto. Agora, há um número dramático de membros de software que possuem produtos basicamente criados para o Hadoop ou que foram importados para o Hadoop. E eles acabaram de criar um ecossistema em que não há nada que possa competir com ele em termos de amplitude. E isso significa que realmente se tornou a plataforma para inovação em big data. Mas, na minha opinião, ainda é imaturo e poderíamos ter longas discussões sobre o que é e o que não é, digamos, operacionalmente maduro com o Hadoop, mas acho que a maioria das pessoas que está olhando para essa área em particular sabe que o Hadoop está décadas atrás do mainframe em termos de capacidade operacional.
O lago de dados em evolução. O data lake é uma plataforma para qualquer definição e, se você pensa que existe uma camada de dados na computação corporativa, é muito fácil pensar nisso em termos de bancos de dados fixos e do data lake que compõe a camada de dados. As aplicações de data lake são muitas e variadas. Eu tenho um diagrama aqui que analisa as várias tarefas de organização de dados que precisam ser feitas se você usar o Hadoop como uma área de preparação ou o Hadoop e Spark como uma área de preparação. E você tem tudo - linhagem de dados, limpeza de dados, gerenciamento de metadados, descoberta de metadados - pode ser usado para o próprio ETL, mas geralmente exige que o ETL traga os dados. Gerenciamento de dados mestre, definições de negócios, gerenciamento de serviços de o que está acontecendo no Hadoop, gerenciamento de dados do ciclo de vida e ETL fora do Hadoop, além de aplicativos de análise direta que você pode executar no Hadoop.
E é por isso que se tornou muito poderoso e onde foi implementado e implementado com êxito, normalmente ele possui pelo menos uma coleção desses tipos de aplicativos em execução. E a maioria desses aplicativos, principalmente os que foram informados, não estão disponíveis no mainframe no momento. Mas você pode executá-los no mainframe, em um cluster Hadoop que está sendo executado em uma partição do mainframe.
O data lake está se tornando, na minha opinião, a área de preparação natural para análises rápidas de bancos de dados e para BI. Torna-se o local onde você coleta os dados, sejam dados corporativos ou dados externos, mexe com eles até que, digamos, seja limpo o suficiente para usar e bem estruturado para usá-lo e depois repassá-lo. E tudo isso ainda está em sua infância.
A ideia, na minha opinião, de coexistência de mainframe / Hadoop, a primeira coisa é que as grandes empresas dificilmente abandonarão o mainframe. De fato, as indicações que vi recentemente implicam que há um aumento no investimento no mainframe. Mas eles também não vão ignorar o ecossistema do Hadoop. Estou vendo números de 60% das grandes empresas que usam o Hadoop, mesmo que muitas delas sejam apenas prototipagem e experimentação.
O enigma é: "Como você coexiste essas duas coisas?", Porque elas precisam compartilhar dados. Dados que são trazidos para o data lake precisam ser transferidos para o mainframe. Os dados que estão no mainframe podem precisar ir para o data lake ou através do data lake para serem associados a outros dados. E isso vai acontecer. E isso significa que requer capacidade rápida de transferência de dados / ETL. É improvável que as cargas de trabalho sejam compartilhadas dinamicamente, digamos, em um ambiente de mainframe ou com algo em um ambiente Hadoop. Serão dados compartilhados. E a maioria dos dados residirá inevitavelmente no Hadoop simplesmente porque é a plataforma de menor custo para ele. E o processamento analítico de ponta a ponta provavelmente também residirá lá.
Em resumo, em última análise, precisamos pensar em termos de uma camada de dados corporativos, que para muitas empresas incluirá o mainframe. E essa camada de dados precisa ser gerenciada proativamente. Caso contrário, os dois não coexistirão bem. Eu posso passar a bola de volta para você, Eric.
Eric Kavanagh: Novamente, Tendü, acabei de te tornar o apresentador, então leve embora.
Tendü Yogurtçu: Obrigado, Eric. Obrigado por me receber. Oi pessoal. Falarei sobre a experiência da Syncsort com os clientes em relação à forma como vemos os dados como um ativo na organização que é nivelado do mainframe para o big data nas plataformas de análise. E espero que também tenhamos tempo no final da sessão para receber perguntas do público, porque essa é realmente a parte mais valiosa desses webcasts.
Apenas para pessoas que não sabem o que o Syncsort faz, o Syncsort é uma empresa de software. Nós já existimos há mais de 40 anos. Iniciados no lado do mainframe, nossos produtos abrangem do mainframe ao Unix e as plataformas de big data, incluindo Hadoop, Spark, Splunk, tanto no local quanto na nuvem. Nosso foco sempre foi em produtos de dados, processamento de dados e produtos de integração de dados.
Nossa estratégia em relação ao big data e ao Hadoop realmente se tornou parte do ecossistema desde o primeiro dia. Como proprietários de fornecedores que foram realmente focados no processamento de dados com mecanismos muito leves, pensamos que havia uma grande oportunidade de participar do Hadoop, tornando-se uma plataforma de processamento de dados e fazer parte dessa arquitetura de data warehouse de próxima geração para a organização. Desde 2011, colaboramos com os projetos Apache de código aberto, começando com o MapReduce. Estiveram entre os dez primeiros no Hadoop Versão 2 e participaram de vários projetos, inclusive pacotes Spark, alguns de nossos conectores são publicados nos pacotes Spark.
Aproveitamos nosso mecanismo de processamento de dados muito leve, que é metadados completamente baseados em arquivos simples e fica muito bem com os sistemas de arquivos distribuídos, como o Hadoop Distributed File System. E alavancamos nossa herança no mainframe, nossa experiência com algoritmos ao lançar nossos produtos de big data. E temos uma parceria muito próxima com os principais fornecedores e principais players aqui, incluindo Hortonworks, Cloudera, MapR, Splunk. A Hortonworks anunciou recentemente que revenderá nosso produto para integração ETL com o Hadoop. Com a Dell e a Cloudera, temos uma parceria muito estreita que também revende nosso produto ETL como parte de seu dispositivo de big data. Na verdade, com o Splunk, publicamos dados de telemetria e segurança de mainframe nos painéis do Splunk. Temos uma parceria estreita.
O que está em mente de todo executivo de nível C? É realmente: "Como utilizo meus ativos de dados?" Todo mundo está falando sobre big data. Todo mundo está falando sobre o Hadoop, Spark, a próxima plataforma de computador que pode me ajudar a criar agilidade nos negócios e abrir novos aplicativos transformadores. Novas oportunidades de entrada no mercado. Todo executivo está pensando: "Qual é a minha estratégia de dados, qual é a minha iniciativa de dados e como me certifico de não ficar atrás da concorrência e de que ainda estou neste mercado nos próximos três anos?" veja isso enquanto falamos com nossos clientes, como falamos com nossa base de clientes global, que é bastante grande, como você pode imaginar, já que estamos no mercado há algum tempo.
À medida que conversamos com todas essas organizações, também vemos isso na pilha de tecnologias na interrupção que ocorreu com o Hadoop. É realmente para satisfazer essa demanda de dados como um ativo. Aproveitando todos os ativos de dados que uma organização possui. E vimos a arquitetura do data warehouse corporativo evoluir de tal forma que o Hadoop agora é a nova peça central da arquitetura de dados moderna. E a maioria de nossos clientes, sejam serviços financeiros, seguros, empresas de varejo, as iniciativas geralmente são: o Hadoop como serviço ou dados como serviço. Porque todo mundo está tentando disponibilizar os ativos de dados para seus clientes externos ou internos. E em algumas organizações, vemos iniciativas como quase um mercado de dados para seus clientes.
E uma das primeiras etapas para conseguir isso é criar um hub de dados corporativos. Às vezes, as pessoas chamam de lago de dados. Criar esse hub de dados corporativo não é tão fácil quanto parece, porque realmente requer acesso e coleta de praticamente todos os dados da empresa. E esses dados agora são de todas as novas fontes, como sensores móveis, bem como bancos de dados herdados, e estão no modo batch e no modo streaming. A integração de dados sempre foi um desafio, no entanto, com o número e a variedade de fontes de dados e os diferentes estilos de entrega, seja em lote ou streaming em tempo real, é ainda mais desafiador agora em comparação com cinco anos atrás, dez anos atrás. Às vezes nos referimos a ele como "Não é mais o ETL do seu pai".
Então, falamos sobre os diferentes ativos de dados. Como as empresas estão tentando entender os novos dados, os dados que coletam dos dispositivos móveis, sejam os sensores de um fabricante de automóveis ou os dados de usuários de uma empresa de jogos móveis, geralmente precisam fazer referência aos ativos de dados mais críticos em a empresa, que são informações do cliente, por exemplo. Esses ativos de dados mais críticos geralmente residem no mainframe. A correlação de dados de mainframe com essas novas fontes emergentes, coletadas na nuvem, coletadas através de dispositivos móveis, coletadas na linha de fabricação de uma empresa japonesa de automóveis ou aplicativos de Internet das coisas, precisam entender esses novos dados, referenciando seus conjuntos de dados legados. E esses conjuntos de dados herdados geralmente estão no mainframe.
E se essas empresas não conseguem fazer isso, não conseguem acessar os dados do mainframe, então há uma oportunidade perdida. Em seguida, os dados como um serviço ou o aproveitamento de todos os dados da empresa não estão realmente explorando os ativos mais críticos da organização. Há também a parte de dados de telemetria e segurança, porque praticamente todos os dados transacionais residem no mainframe.
Imagine que você vai a um caixa eletrônico, acho que um dos participantes enviou uma mensagem aos participantes aqui para proteger o sistema bancário, quando você está passando o cartão, informando que os dados transacionais são praticamente globais no mainframe. Proteger e coletar os dados de segurança e os dados de telemetria dos mainframes e disponibilizá-los por meio de painéis Splunk ou outros, Spark, SQL, se torna mais crítico agora do que nunca, devido ao volume dos dados e à variedade dos dados.
Conjuntos de habilidades são um dos maiores desafios. Como, por um lado, você tem uma pilha de big data que muda rapidamente, não sabe qual projeto sobreviverá, qual projeto não sobreviverá, devo contratar desenvolvedores Hive ou Pig? Devo investir no MapReduce ou Spark? Ou a próxima coisa, Flink, alguém disse. Devo investir em uma dessas plataformas de computador? Por um lado, acompanhar o ecossistema em rápida mudança é um desafio e, por outro lado, você tem essas fontes de dados herdadas. Os novos conjuntos de habilidades realmente não correspondem e você pode ter um problema porque esses recursos podem estar realmente se aposentando. Há uma grande lacuna em termos de conjuntos de habilidades de pessoas que entendem essas pilhas de dados herdadas e que entendem a pilha de tecnologia emergente.
O segundo desafio é a governança. Quando você realmente acessa todos os dados da empresa em várias plataformas, temos clientes que levantaram preocupações de que: “Eu não quero que meus dados cheguem. Não quero que meus dados sejam copiados em vários lugares, pois quero evitar o máximo possível de várias cópias. Quero ter acesso de ponta a ponta sem colocá-lo no meio. ”Governar esses dados se torna um desafio. E a outra parte é que, se você estiver acessando dados com gargalos, se estiver coletando a maioria dos dados na nuvem e acessando e referenciando dados herdados, a largura de banda da rede se tornará um problema, uma plataforma de cluster. Existem muitos desafios em termos de iniciativa de big data e plataformas avançadas de análise, além de alavancar todos os dados corporativos.
O que o Syncsort oferece é que somos chamados de "simplesmente os melhores", não porque somos simplesmente os melhores, mas nossos clientes realmente se referem a nós como os melhores para acessar e integrar dados de mainframe. Suportamos todos os formatos de dados do mainframe e os disponibilizamos para a análise de big data. Seja no Hadoop ou Spark ou na próxima plataforma de computador. Porque nossos produtos realmente isolam as complexidades da plataforma de computador. Você é, como desenvolvedor, potencialmente desenvolvendo em um laptop, concentrando-se no pipeline de dados e em quais são as preparações de dados, as etapas para criar esses dados para a análise, a próxima fase e o mesmo aplicativo no MapReduce. mesma aplicação no Spark.
Ajudamos nossos clientes a fazer isso quando o YARN ficou disponível e eles tiveram que mover seus aplicativos do MapReduce versão 1 para o YARN. Estamos ajudando-os a fazer o mesmo com o Apache Spark. Nosso produto, a nova versão 9, também está em execução com o Spark e é fornecida com uma otimização dinâmica que isolará esses aplicativos para futuras estruturas de computadores.
Portanto, temos acesso a dados de mainframe, sejam arquivos VSAM, DB2 ou dados de telemetria, como registros SMF ou Log4j ou syslogs, que precisam ser visualizados nos painéis do Splunk. E enquanto isso, como a organização pode alavancar seus engenheiros de dados ou conjuntos de habilidades ETL existentes, o tempo de desenvolvimento é reduzido significativamente. De fato, com a Dell e a Cloudera, havia um benchmark independente patrocinado, e esse benchmark focado no tempo de desenvolvimento que leva, se você estiver fazendo codificação manual ou usando outras ferramentas como a Syncsort, e houve uma redução de cerca de 60% a 70% no tempo de desenvolvimento . Fazer a ponte entre os conjuntos de habilidades entre grupos, entre os hosts de arquivos de dados e também com os hosts de arquivos de dados.
Geralmente, a equipe de big data, a equipe de ingestão de dados ou a equipe encarregada de desenvolver esses dados como uma arquitetura de serviço não necessariamente falam com a equipe de mainframe. Eles querem minimizar essa interação quase em muitas das organizações. Fechando essa lacuna, avançamos. E a parte mais importante é realmente proteger todo o processo. Porque na empresa, quando você lida com esse tipo de dados confidenciais, existem muitos requisitos.
Em setores altamente regulamentados, como seguros e bancos, nossos clientes perguntam, eles disseram: “Você oferece acesso a dados de mainframe e isso é ótimo. Você também pode me oferecer para que esse formato de registro codificado em EBCDIC seja mantido em seu formato original para que eu possa satisfazer meus requisitos de auditoria? ”Assim, fazemos o Hadoop e o Apache Spark entenderem os dados do mainframe. Você pode manter os dados em seu formato de registro original, fazer o processamento e a plataforma do computador do distribuidor de níveis e, se precisar colocar isso de volta, pode mostrar que o registro não foi alterado e o formato do registro não foi alterado, pode cumprir os requisitos regulamentares .
E a maioria das organizações, ao criar o hub de dados ou o data lake, também está tentando fazer isso com um único clique para poder mapear metadados de centenas de esquemas em um banco de dados Oracle para tabelas Hive ou arquivos ORC ou Parquet torna-se necessário. Nós enviamos ferramentas e fornecemos ferramentas para torná-lo um acesso a dados em uma etapa, trabalhos gerados automaticamente ou a movimentação de dados e trabalhos gerados automaticamente para fazer o mapeamento de dados.
Falamos sobre a parte da conectividade, a conformidade, a governança e o processamento de dados. E nossos produtos estão disponíveis tanto no local quanto na nuvem, o que torna realmente muito simples, porque as empresas não precisam pensar no que acontecerá nos próximos dois anos se eu decidir ir completamente em nuvem pública versus híbrida ambiente, pois alguns clusters podem estar em execução no local ou na nuvem. E nossos produtos estão disponíveis no Amazon Marketplace, no EC2, no Elastic MapReduce e também em um contêiner Docker.
Apenas para finalizar, para termos tempo suficiente para as perguntas e respostas, trata-se realmente de acessar, integrar e cumprir com a governança de dados, e ainda simplificar tudo isso. E, ao mesmo tempo em que simplificamos isso, “projete uma vez e implante em qualquer lugar” em um verdadeiro sentido, devido às nossas contribuições de código aberto, nosso produto é executado nativamente no fluxo de dados do Hadoop e no Spark, isolando as organizações do ecossistema em rápida mudança. E fornecendo um único pipeline de dados, uma única interface, para lote e streaming.
E isso também ajuda as organizações a avaliar essas estruturas, porque você pode realmente criar aplicativos e apenas rodar no MapReduce versus Spark e ver por si mesmo, sim, o Spark tem essa promessa e fornece todo o avanço nos algoritmos iterativos para o melhor aprendizado de máquina e os aplicativos de análise preditiva funcionam com o Spark, também posso executar minhas cargas de trabalho de streaming e lote nesta estrutura de computador? Você pode testar diferentes plataformas de computador usando nossos produtos. E a otimização dinâmica, esteja você executando em um servidor autônomo, em seu laptop, no Google Cloud versus Apache Spark, é realmente uma grande proposta de valor para nossos clientes. E foi realmente motivado pelos desafios que eles tiveram.
Vou cobrir apenas um dos estudos de caso. Esta é a Guardian Life Insurance Company. E a iniciativa do Guardian foi realmente centralizar seus ativos de dados e disponibilizá-los para seus clientes, reduzir o tempo de preparação de dados e eles disseram que todo mundo fala sobre a preparação de dados, ocupando 80% do pipeline de processamento de dados em geral e disseram que, na verdade, estava levando cerca de 75 a 80% para eles e eles queriam reduzir a preparação de dados, o tempo de transformação e o tempo de colocação no mercado para projetos de análise. Crie essa agilidade à medida que adicionam novas fontes de dados. E disponibilize esse acesso centralizado aos dados para todos os seus clientes.
Sua solução, incluindo os produtos Syncsort, é que agora eles têm um mercado de dados parecido com o Amazon Marketplace suportado por um data lake, que é basicamente o banco de dados Hadoop e NoSQL. E eles usam nossos produtos para trazer todos os ativos de dados para o data lake, incluindo o DB2 no mainframe, incluindo arquivos VSAM no mainframe e as fontes de dados herdadas do banco de dados, bem como as novas fontes de dados. E, como resultado, eles centralizaram os ativos de dados reutilizáveis, pesquisáveis, acessíveis e disponíveis para seus clientes. E eles são realmente capazes de adicionar as novas fontes de dados e atender seus clientes com muito mais rapidez e eficiência do que antes. E as iniciativas de análise também estão progredindo mais no lado preditivo. Então, farei uma pausa e espero que isso tenha sido útil. Se você tiver alguma dúvida para mim sobre algum dos tópicos relacionados, por favor, seja bem-vindo.
Eric Kavanagh: Claro, e Tendü, eu vou apenas inserir um. Recebi um comentário de um membro da platéia dizendo: “Gosto desse 'design uma vez, implemente em qualquer lugar'.” Você pode se interessar em como isso é verdade? Quero dizer, o que você fez para permitir esse tipo de agilidade e existe algum imposto? Como quando falamos de virtualização, por exemplo, sempre há um pouco de imposto sobre o desempenho. Algumas pessoas dizem dois por cento, cinco por cento e 10 por cento. O que você fez para habilitar o design uma vez, implantar em qualquer lugar - como você faz isso e há algum imposto associado a ele em termos de desempenho?
Tendü Yogurtçu: Claro, obrigado. Não, porque, diferentemente de outros fornecedores, na verdade, não geramos Hive ou Pig ou algum outro código que não é nativo de nossos mecanismos. É aqui que nossas contribuições de código aberto desempenharam um grande papel, porque trabalhamos com os fornecedores do Hadoop, Cloudera, Hortonworks e MapR muito de perto e, devido às nossas contribuições de código aberto, nosso mecanismo na verdade está funcionando nativamente como parte do fluxo, como parte do fluxo do Hadoop, como parte do Spark.
O que isso traduz também, temos essa otimização dinâmica. Isso foi resultado de nossos clientes serem desafiados com estruturas de computador. Quando eles entraram em produção com alguns dos aplicativos, eles retornaram e disseram: “Estou apenas estabilizando meu cluster Hadoop, estabilizando no MapReduce YARN Versão 2, MapReduce Versão 2 e as pessoas estão falando que o MapReduce está morto, o Spark está a próxima coisa, e algumas pessoas estão dizendo que o Flink será a próxima, como vou lidar com isso? ”
E esses desafios realmente se tornaram tão óbvios para nós, que investimos em ter essa otimização dinâmica que chamamos de execução inteligente. No tempo de execução, quando o trabalho, quando esse pipeline de dados é enviado, com base no cluster, seja Spark, MapReduce ou um servidor independente Linux, decidimos como executar esse trabalho, nativamente em nosso mecanismo, como parte desse Fluxo de dados do Hadoop ou Spark. Não há sobrecarga porque tudo é feito por meio dessa otimização dinâmica que temos e tudo também é feito porque nosso mecanismo é tão nativamente integrado por causa de nossas contribuições de código aberto. Isso responde à sua pergunta?
Eric Kavanagh: Sim, isso é bom. E eu quero fazer mais uma pergunta por lá, e depois Dez, talvez nós puxemos você e Robin também. Acabei de receber um comentário hilário de um de nossos participantes. Vou ler porque é realmente bastante conciso. Ele escreve: "Parece que na história das coisas QUENTES" - entendeu? Como a IoT - "é que quanto mais você tenta" simplificar "algo realmente complexo, mais frequentemente do que não é o mais simples que parece fazer as coisas, mais corda pendurada é fornecida. Pense em consulta ao banco de dados, explosão, multi-threading etc. ”Você pode comentar sobre esse paradoxo que ele está referenciando? Simplicidade versus complexidade, e basicamente o que realmente está acontecendo por baixo das capas?
Tendü Yogurtçu: Claro. Eu acho que esse é um ponto muito válido. Quando você está simplificando as coisas e fazendo essas otimizações, de certa forma, alguém precisa entender a complexidade do que precisa acontecer, certo? Se você está paralisando algo ou está decidindo como executar um trabalho específico em relação à estrutura do computador, obviamente há uma parte do trabalho que está sendo executada, seja no final do usuário, na codificação de menus ou na otimização do mecanismo. Há uma parte disso: ao simplificar a experiência do usuário, há um enorme benefício em termos de poder aproveitar os conjuntos de habilidades existentes na empresa.
E você pode atenuar esse paradoxo, atenuar o desafio de "Sim, mas eu não tenho controle sobre tudo o que está acontecendo nos bastidores, nos bastidores desse mecanismo", expondo as coisas aos usuários mais avançados, se eles quer ter esse tipo de controle. Investindo também em alguns tipos de serviços. Ser capaz de oferecer mais metadados operacionais, mais dados operacionais, como no exemplo que esse participante forneceu, para uma consulta SQL e também com o mecanismo em execução. Espero que isso responda.
Eric Kavanagh: Sim, isso parece bom. Dez, leve embora.
Dez Blanchfield: Estou realmente interessado em conhecer um pouco mais sua presença nas contribuições de código aberto e na jornada que você fez da sua experiência tradicional de longa data no mainframe e no mundo proprietário e depois na mudança para contribuindo para o código aberto e como isso aconteceu. E a outra coisa que estou interessado em entender é a visão que você vê das empresas, não apenas dos departamentos de TI, mas agora as empresas estão adotando em relação aos hubs ou lagos de dados, como as pessoas estão dizendo agora e se veem essa tendência de apenas um único lago de dados consolidado ou se estamos vendo lagos de dados distribuídos e as pessoas estão usando ferramentas para montá-los?
Tendü Yogurtçu: Claro. Para a primeira, foi uma jornada muito interessante, como empresa proprietária de software, uma das primeiras após a IBM. No entanto, novamente, tudo começou com nossos clientes evangelistas olhando para o Hadoop. Tínhamos empresas de dados como a ComScore, elas foram uma das primeiras a adotar o Hadoop porque estavam coletando dados digitais em todo o mundo e não conseguiam manter 90 dias de dados, a menos que investissem uma caixa de dez milhões de dólares em seu meio Ambiente. Eles começaram a olhar para o Hadoop. Com isso, começamos também a olhar para o Hadoop.
E quando tomamos uma decisão e reconhecemos que o Hadoop realmente será a plataforma de dados do futuro, também chegamos ao entendimento de que não seremos capazes de fazer uma jogada nisso, uma jogada de sucesso nisso, a menos que faziam parte do ecossistema. E estávamos trabalhando em estreita colaboração com os fornecedores do Hadoop, com Cloudera, Hortonworks, MapR, etc. Começamos a conversar com eles porque a parceria se torna muito importante para validar o valor que um fornecedor pode trazer e também garante que possamos ir juntos à empresa e oferecer algo mais significativo. Isso exigiu muita construção de relações, porque não éramos conhecidos pelos projetos de código aberto Apache, no entanto, tivemos grande apoio desses fornecedores do Hadoop, devo dizer.
Começamos a trabalhar juntos e a olhar para o hub, como podemos agregar valor sem o nosso software proprietário no espaço. Isso foi importante. Não se trata apenas de colocar algumas APIs nas quais seu produto pode ser executado, é para poder dizer que vou investir nisso porque acredito que o Hadoop será uma plataforma do futuro, investindo nas fontes que queríamos criar Certifique-se de que amadurece e se torna pronto para a empresa. Na verdade, podemos ativar alguns dos casos de uso que não estavam disponíveis antes de nossas contribuições. Isso beneficiará todo o ecossistema e podemos desenvolver essas parcerias muito de perto.
Demorou bastante tempo. Começamos a contribuir em 2011 e 21 de janeiro de 2013 - lembro-me da data em que essa data foi comprometida com a nossa maior contribuição, o que significava que agora podemos ter nossos produtos geralmente disponíveis a partir desse momento - levou algum tempo para desenvolver essas relações, mostre o valor, os parceiros se tornam parceiros de design com os fornecedores e com os committers na comunidade de código aberto. Mas foi muito divertido. Como empresa, foi muito gratificante fazer parte desse ecossistema e desenvolver uma ótima parceria.
A segunda pergunta sobre o data hub / data lake, acho que quando vemos esses dados como uma implementação de serviço na maioria dos casos, sim, podem ser clusters, fisicamente únicos ou múltiplos, mas é mais conceitual do que se tornar esse único local para todos os dados. Como em algumas organizações vemos grandes implantações de cluster no local, elas também têm clusters, por exemplo, na nuvem pública, porque alguns dos dados coletados das seções on-line são realmente mantidos na nuvem. É possível ter um único pipeline de dados que você pode aproveitar de ambos, e usá-los como um único hub de dados, um único data lake, se torna importante. Não necessariamente apenas o local físico, mas ter esse hub de dados e data lake em clusters, geografias e talvez nas premissas e na nuvem será muito crítico, eu acho. Especialmente avançando. Este ano, começamos a ver cada vez mais implantações na nuvem. É incrível. No primeiro semestre deste ano, vimos muitas implantações na nuvem.
Eric Kavanagh: Ok, legal. E Robin, você tem alguma pergunta? Sei que ainda temos alguns minutos.
Robin Bloor: Ok, posso fazer uma pergunta a ela. A primeira coisa que me ocorreu é que houve muita empolgação com Kafka e eu estava interessado em sua opinião sobre Kafka e como você se integra à maneira como as pessoas estão usando Kafka?
Tendü Yogurtçu: Claro. Sim, Kafka está se tornando bastante popular. Entre os nossos clientes, vemos que sendo o tipo de camada de transporte de dados e visualizando que os dados são um barramento, basicamente. Por exemplo, um de nossos clientes realmente estava usando um tipo de dado consumido que é enviado para esse Kafka entre vários, como milhares de usuários on-line, e é capaz de classificá-lo e enviá-lo.
Novamente, Kafka é um barramento de dados para os diferentes consumidores desses dados. Classifique alguns usuários avançados versus usuários não tão avançados e faça algo diferente avançando nesse pipeline de dados. Como nos integramos ao Kafka é basicamente, nosso produto DMX-h se torna um consumidor confiável, um consumidor altamente eficiente e confiável para o Kafka. Ele pode ler os dados e isso não é diferente de ler dados de qualquer outra fonte de dados para nós. Damos aos usuários a capacidade de controlar a janela em termos de tempo que eles têm ou do número de mensagens que eles podem estar consumindo no barramento Kafka. E também podemos enriquecer esses dados à medida que eles passam pelo nosso produto e retornam ao Kafka. Nós testamos isso. Nós o comparamos no site do cliente. Também certificado pela Confluent. Trabalhamos em estreita colaboração com os funcionários da Confluent e é de alto desempenho e fácil de usar. Mais uma vez, as APIs mudam, mas você não precisa se preocupar porque o produto realmente trata isso como apenas outra fonte de dados, uma fonte de dados de streaming. É muito divertido trabalhar com nosso produto e com Kafka, na verdade.
Robin Bloor: Ok. Eu tenho outra pergunta que é apenas uma questão geral de negócios, mas conheço a Syncsort há muito tempo e você sempre teve a reputação e entregou um software extraordinariamente rápido para o ETL e o mundo do mainframe. É o caso de a maioria dos seus negócios agora estar sendo transferida para o Hadoop? É o caso de que, de uma maneira ou de outra, você meio que difundiu seus negócios de maneira bastante dramática no mundo do mainframe?
Tendü Yogurtçu: Nossos produtos de mainframe ainda estão executando 50% dos mainframes em todo o mundo. Portanto, temos uma linha de produtos de mainframe muito forte, além do que estamos fazendo no big data e no final do Hadoop. E ainda estamos na maioria dos projetos de simplificação ou otimização de TI, porque há uma extremidade em que você deseja poder acessar seus dados de mainframe nas plataformas Multex de big data e aproveitar todos os dados corporativos; no entanto, também existem cargas de trabalho transacionais muito críticas isso ainda continua sendo executado no mainframe e oferecemos a esses clientes as maneiras de realmente tornar esses aplicativos mais eficientes, executados no mecanismo zIIP para que eles não consumam tantos ciclos de processamento e MIPS, o que os torna rentáveis.
Continuamos a investir nos produtos de mainframe e, na verdade, entramos nesse espaço em que as pessoas vão do big ferro do mainframe ao big data e abrangem a linha de produtos também nessas plataformas. Portanto, não mudamos necessariamente todo o negócio para um lado, continuamos a ter negócios de muito sucesso nos dois lados. E as aquisições são um grande foco para nós também. À medida que esse espaço de gerenciamento e processamento de dados para as plataformas de big data evolui, também estamos comprometidos em fazer algumas aquisições complementares.
Robin Bloor: Bem, acho que não posso perguntar o que são, porque você não teria permissão para me dizer. Estou interessado em saber se você viu muitas implementações do Hadoop ou Spark realmente no mainframe ou se isso é algo muito raro.
Tendü Yogurtçu: Não vimos nenhum. Há mais perguntas sobre isso. Eu acho que o Hadoop no mainframe não fazia muito sentido por causa do tipo de estrutura principal. No entanto, o Spark no mainframe é bastante significativo e o Spark realmente é muito bom com o aprendizado de máquina e a análise preditiva, e ser capaz de ter alguns desses aplicativos com dados de mainframe é, na minha opinião, bastante significativo. Ainda não vimos ninguém fazendo isso, no entanto, é realmente o caso de uso que impulsiona essas coisas. Se o seu caso de uso como empresa está trazendo mais esses dados de mainframe e se integrando ao restante dos conjuntos de dados na plataforma de big data, essa é uma história. É necessário acessar os dados do mainframe a partir da plataforma Multex de big data, porque é improvável que você traga seus conjuntos de dados de sistemas abertos e chame de volta ao mainframe. No entanto, se você tiver alguns dados de mainframe que deseja apenas explorar e fazer um pouco de descoberta de exploração de dados, aplicar alguma IA avançada e análises avançadas, o Spark pode ser um bom caminho a percorrer e executar no mainframe dessa maneira.
Eric Kavanagh: E aqui está mais uma pergunta da platéia, na verdade mais duas. Vou fazer uma pergunta para a equipe de tag e concluiremos. Um participante está perguntando: “A IBM está integrando suas contribuições de código-fonte aberto ao seu ecossistema de nuvem pública, em outras palavras, o Bluemix?” E outro participante fez uma observação muito boa, observando que o Syncsort é ótimo para manter grande ferro vivo para aqueles que já o possui, mas se as empresas renunciarem a novos mainframes em favor do que ele chama de CE, obscurecerão tudo, isso provavelmente diminuirá, mas observa que vocês são realmente bons em mover dados ignorando sistemas operacionais de até um gigabyte por segundo. Você pode falar sobre sua força principal, como ele mencionou, e se a IBM está ou não integrando suas coisas no Bluemix?
Tendü Yogurtçu: Com a IBM, já somos parceiros da IBM e discutimos seus serviços de nuvem de dados que oferecem o produto. Nossas contribuições de código aberto são abertas a todos que desejam aproveitá-las. Parte da conectividade do mainframe também está disponível nos pacotes Spark, portanto não apenas na IBM. Qualquer um pode aproveitar isso. No Bluemix, ainda não fizemos nada específico. E você se importa de repetir a segunda pergunta?
Eric Kavanagh: Sim, a segunda pergunta foi sobre sua principal área de funcionalidade ao longo dos anos, que realmente estava lidando com gargalos de ETL e, obviamente, isso é algo que vocês ainda farão como mainframes, bem, teoricamente, fiquem longe, embora Dez ponto ainda está meio que balançando e rolando por aí. Mas o participante apenas observou que o Syncsort é muito bom em mover dados ignorando os sistemas operacionais e até um gigabyte por segundo. Você pode apenas comentar sobre isso?
Tendü Yogurtçu: Sim, essa eficiência de recursos realmente geral tem sido a nossa força e a escalabilidade e desempenho, a nossa força. Não estamos comprometendo, simplificar tem muitos significados, não comprometemos esses. Quando as pessoas começaram a falar sobre o Hadoop em 2014, por exemplo, muitas das organizações não estavam realmente olhando para o desempenho inicialmente. Eles estavam dizendo: "Oh, se algo acontecer, eu posso adicionar outros nós e eu ficarei bem, o desempenho não é meu requisito".
Enquanto conversávamos sobre ter o melhor desempenho, porque já estávamos executando nativamente, não estávamos nem tendo alguns dos soluços iniciais que o Hive teve com vários trabalhos do MapReduce e despesas gerais ao iniciá-los. As pessoas estavam nos dizendo: "Oh, essa não é minha preocupação, não se preocupe com isso no momento."
Quando chegamos a 2015, esse cenário mudou porque alguns de nossos clientes já excederam o armazenamento que tinham em seus clusters de produção. Tornou-se muito crítico para eles ver o que o Syncsort pode oferecer. Se você estiver obtendo alguns dados de um banco de dados ou mainframe e gravando em um formato Parquet nos clusters, se você pousa e prepara e realiza outra transformação ou apenas a transformação a bordo e o formato de arquivo de destino pousado, fez a diferença porque você está salvando de armazenamento, você está economizando com a largura de banda da rede, economizando com a carga de trabalho no cluster porque não está executando trabalhos extras. Aqueles pontos fortes que jogamos em termos de ser muito consciente, sentimos a eficiência dos recursos sob nossa pele, ao que parece.
É assim que a descrevemos. É crítico para nós. Nós não tomamos isso como garantido. Como nunca tínhamos como certo, continuaremos fortes com essa alavancagem no Apache Spark ou na próxima estrutura de computador. Esse continuará sendo o nosso foco. E em termos da parte de movimentação de dados e parte de acesso a dados, definitivamente é um dos nossos pontos fortes e estamos acessando dados do DB2 ou VSAM nos mainframes no contexto do Hadoop ou Spark.
Eric Kavanagh: Bem, essa é uma ótima maneira de terminar o webcast, pessoal. Muito obrigado pelo seu tempo e atenção. Obrigado a você, Tendü e Syncsort, por terem entrado na sala de reuniões e entrado na rodada, como eles dizem. Muitas ótimas perguntas da platéia. É um ambiente sempre em movimento por aí, pessoal. Arquivaremos esta Hot Tech como fazemos com todas as outras. Você pode encontrar-nos em insideanalysis.com e techopedia.com. Geralmente sobe em cerca de um dia. E com isso, vamos dizer adeus, pessoal. Muito obrigado. Falaremos com você em breve. Cuidar. Tchau tchau.
