Contente
Fonte: Jakub Jirsak / Dreamstime.com
Leve embora:
O anfitrião Eric Kavanagh discute a análise de big data com especialistas do setor.
Eric: Senhoras e Senhores Deputados, é o fim do ano de 2014 - pelo menos, quase. É o nosso último webcast do ano, pessoal! Bem-vindo ao TechWise! Sim, de fato! Meu nome é Eric Kavanagh. Serei seu moderador de um webcast incrível, pessoal. Estou muito, muito empolgado. Temos dois analistas incríveis online e duas grandes empresas - inovadores reais em todo esse ecossistema de big data. E falaremos sobre a chave para a análise de big data é entender a diferença. Então, vamos seguir em frente, pessoal.
Temos vários apresentadores. Como você pode ver, existe o seu verdadeiramente no topo. Mike Ferguson está telefonando desde o Reino Unido, onde teve que obter privilégios especiais para permanecer em seu prédio até tarde. É tarde para ele. Temos o Dr. Robin Bloor, nosso analista-chefe aqui no Bloor Group. E teremos George Corugedo, CEO e cofundador da RedPoint Global, e Keith Renison, arquiteto de soluções sênior do SAS Institute. Essas são empresas fantásticas, pessoal. São empresas realmente inovadoras. E vamos explorar algumas das coisas boas do que está acontecendo por aí agora no mundo inteiro do big data. E, convenhamos, os pequenos dados não desapareceram. E para isso, deixe-me dar meu resumo executivo aqui.
Portanto, há uma antiga expressão francesa: "Quanto mais as coisas mudam, mais elas permanecem iguais". E vamos encarar alguns fatos aqui: o big data não vai resolver os problemas dos pequenos dados. Os pequenos dados corporativos ainda estão por aí. Ainda está em todo lugar. É o combustível das operações para a economia da informação atual. E o big data oferece um complemento para os chamados pequenos dados corporativos, mas não substitui os pequenos. Ainda vai estar por aí. Gosto de muitas coisas sobre big data, especialmente coisas como dados gerados por máquina.
E hoje, provavelmente falaremos um pouco sobre dados de mídia social, que também são coisas muito poderosas. E se você pensar, por exemplo, em como as redes sociais mudaram os negócios, pense em três sites rápidos aqui: LinkedIn e. Pense no fato de que cinco anos atrás, ninguém estava fazendo esse tipo de coisa. é uma força absoluta hoje em dia. , é claro, é enorme. É gigantesco. E então, o LinkedIn é o padrão de fato para redes e comunicações corporativas. Esses sites são enormes e, para poder aproveitar os dados que estão neles, eles reviverão algumas funcionalidades que mudam o jogo. Isso realmente fará muito bem para muitas organizações - pelo menos as que tiram vantagem disso.
Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
Você não pode melhorar suas habilidades de programação quando ninguém se importa com a qualidade do software.
Então, governança - governança ainda é importante. Novamente, o big data não anula a necessidade de governança. Francamente, há uma nova necessidade de se concentrar em como governar o mundo do big data. Como você garante que seus procedimentos e políticas estejam em vigor; que as pessoas certas estão tendo acesso aos dados certos; que você tem contatos, sua linhagem está envolvida aqui? Você realmente sabe de onde vêm os dados, o que aconteceu com eles. E tudo isso está mudando.
Estou francamente impressionado com o que vi por todo o mundo aproveitando o ecossistema Hadoop, que é, obviamente, muito mais que armazenamento em termos de funcionalidade. O Hadoop também é um mecanismo computacional. E a empresa precisa descobrir como aproveitar esse poder computacional, essa capacidade de processamento paralelo. Eles vão fazer coisas muito, muito legais. Vamos aprender sobre isso hoje.
A outra coisa a mencionar, isso é algo que o Dr. Bloor falou no passado recente, é que a onda de inovação não acabou. Então, vimos muita atenção, é claro, no Hadoop. Já vimos empresas como Cloudera e Hortonworks, realmente fazendo algumas ondas. E eles estão desenvolvendo parcerias com, bem, empresas de plantão hoje, francamente. E eles estão desenvolvendo parcerias com muitas pessoas. Mas a onda de inovação não acabou. Existem mais projetos saindo da Apache Foundation que estão mudando não apenas o ponto final, se você quiser - os aplicativos que as pessoas usam - mas a própria infraestrutura.
Portanto, todo esse desenvolvimento do YARN - outro negociador de recursos - é realmente como um sistema operacional para big data. E é um grande, grande negócio. Então, vamos aprender como isso muda as coisas também. Então, apenas alguns conselhos óbvios aqui, desconfie de contratos longos daqui para frente, você sabe, contratos de cinco, dez anos serão a onda, o caminho que me parece. Você vai querer evitar o aprisionamento a todo custo. Nós vamos aprender sobre tudo isso hoje.
Então, nosso primeiro analista falando hoje - nosso primeiro palestrante de todo o programa é Mike Ferguson, telefonando do Reino Unido. Com isso, vou entregar as chaves para você, Mike, e deixar você levá-las embora. Mike Ferguson, o andar é seu.
Mike, você está aí? Você pode estar mudo. Eu não o ouço. Talvez tenhamos que ligar de volta para ele. E vamos pular direto para os slides de Robin Bloor. Robin, vou destacar o pobre Mike Ferguson aqui. Eu vou por um segundo.
É você, Mike? Você pode nos ouvir? Nah. Acho que vamos ter que ir em frente e ir com Robin primeiro. Então, espere um segundo, pessoal. Vou puxar alguns links para os slides aqui em alguns minutos também. Então, com isso, deixe-me entregar as chaves para Robin Bloor. Robin, você pode ir primeiro em vez de Mike, e eu ligo para Mike em um segundo.
Robin: Ok.
Eric: Espere, Rob. Deixe-me ir em frente e pegue seu slide aqui, Rob. Vai demorar um segundo.
Robin: Ok.
Eric: Sim. Você pode falar sobre o que estamos lidando aqui, em termos de governança. Eu sei que você vai falar sobre governança. Isso geralmente é pensado no caso de pequenos dados corporativos. Então agora, eu tenho o slide, Robin. Não mexa nada. E aqui está você. O chão é seu. Leve embora.
Robin: Ok. Sim. Quero dizer, bem, nós meio que combinamos de antemão que Mike falaria sobre o lado analítico e eu falarei sobre o lado da governança. Até certo ponto, a governança segue as análises no sentido de que você está realizando o material de big data e o motivo pelo qual você monta todo o software para fazer as análises é onde está o valor.
Há um problema. E a questão é que, você sabe, os dados precisam ser organizados. Os dados devem ser empacotados. Os dados devem ser reunidos e gerenciados de maneira a permitir que a análise ocorra com total confiança - acho que é a palavra. Então, pensei em falar sobre o lado da governança da equação. Eu acho que, na verdade, a coisa a dizer é que, você sabe, a governança já era um problema. A governança já era um problema e começa a se tornar um problema em todo o jogo do data warehouse.
O que realmente aconteceu é que se transformou em um problema muito maior. E o motivo pelo qual ele se transformou em um problema muito maior, além de mais dados, mas quero dizer, esses são os motivos, na verdade. O número de fontes de dados aumentou drasticamente. Anteriormente, as fontes de dados que possuímos eram em geral definidas por qualquer coisa que alimentasse o data warehouse. O data warehouse normalmente seria alimentado pelos sistemas RTP. É possível um pouco de dados externos, não muito.
Agora, fomos para um mundo em que, você sabe, um mercado de dados está surgindo agora e, portanto, haverá negociação de dados. Você já tem várias fontes diferentes de dados de streaming que você pode realmente trazer para a organização. Temos dados de mídia social que os retiraram, por conta própria, por assim dizer. Quero dizer, muito do valor nos sites de mídia social é, na verdade, a informação que eles agregam e, portanto, podem disponibilizar para as pessoas.
Também descobrimos, como se eles já existissem. Já tínhamos esses arquivos de log, você sabe, no advento do Splunk. E logo, ficou óbvio que há valor em um arquivo de log. Portanto, havia dados dentro da organização que eram - que poderíamos chamar de novas fontes de dados e fontes externas. Então, isso é uma coisa. E isso realmente significa que, você sabe, sejam quais forem as regras de gerenciamento de dados que tínhamos implantado antes, elas terão que ser, de uma maneira ou de outra, estendidas e continuarão sendo necessárias para realmente governar o dados. Mas agora estamos começando a nos reunir de uma maneira ou de outra.
E descendo esta lista, temos streaming e a velocidade de chegada dos dados. Acho que uma das razões da popularidade do Hadoop é que ele pode ser usado para capturar muitos dados. Ele também pode ingerir velocidade dos dados, pois se você não precisar usá-los imediatamente, é um ambiente paralelo agradável e enorme. Mas você também tem o fato de que há uma boa quantidade de análises de streaming em andamento agora. Antes, eram apenas os setores bancários que estavam interessados em aplicativos de streaming, mas agora se tornaram globais. E todo mundo está olhando para aplicativos de streaming de uma maneira ou de outra, mais ou menos, um meio potencial de extrair valor dos dados e fazer análises para a organização.
Temos os dados não estruturados. A estatística, geralmente parte dos únicos 10% dos dados do mundo, estava em bancos de dados relacionais. Agora, uma das principais razões para isso foi na verdade não estruturada, e foi - boa parte disso estava lá na Web, mas praticamente espalhada por vários sites. Esses dados provaram ser também analisáveis, também utilizáveis. E com o advento da tecnologia da Symantec, que está gradualmente se infiltrando na situação, está se tornando cada vez mais.Portanto, é necessário reunir e gerenciar dados não estruturados, o que significa que é muito maior do que era antes. Temos dados sociais que eu já mencionei, mas o ponto principal, o ponto principal, é que ele provavelmente precisa de limpeza.
Temos dados da Internet das Coisas. Esse é um tipo de situação diferente. É provável que haja muito disso, mas muito disso terá que permanecer distribuído em algum lugar perto do local em que é executado. Mas você também vai querer, de uma forma ou de outra, extraí-lo para fazer as análises dentro da organização nos dados. Então, isso acrescentou mais um fator. E esses dados serão estruturados de maneira diferente, porque provavelmente - eles provavelmente serão formatados em JSON ou XML, para que se declarem. E não apenas, de uma maneira ou de outra, que estamos realmente puxando dados e sendo capazes de fazer um tipo de esquema ao ler essa parte específica dos dados.
Temos a questão da proveniência, e essa é uma questão de análise. Os resultados de qualquer análise da qual você está realizando dados não podem, se você preferir, ser aprovados, considerados válidos, a menos que você conheça a origem dos dados. Quero dizer, isso é apenas profissionalismo em termos de atividade dos cientistas de dados. Mas você sabe, para obter a proveniência dos dados, isso significa que realmente precisamos governar os dados e manter uma nota em sua linhagem.
Temos a questão do poder e dos paralelos do computador, e o que tudo isso faz é acelerar tudo. O problema é que, obviamente, certos processos que implementamos podem ser muito lentos para todo o resto. Portanto, há possivelmente incompatibilidades em termos de velocidade.
Temos o advento do aprendizado de máquina. O aprendizado de máquina tem realmente o efeito de tornar a análise um jogo diferente do que era antes. Mas você só pode usá-lo se tiver o poder.
Chegamos ao fato de novas cargas de trabalho analíticas. Temos um mundo paralelo e alguns algoritmos analíticos precisam ser executados em paralelo para obter o máximo efeito. E, portanto, o problema é realmente determinar como você, de uma maneira ou de outra, empurra os dados e os disponibiliza, se estiverem disponíveis. E onde você realmente executa as cargas de trabalho analíticas, porque você pode fazer isso no banco de dados. Portanto, você pode fazê-lo em aplicativos analíticos.
Portanto, há toda uma série de desafios de governança. O que fizemos este ano - a pesquisa que fizemos este ano foi realmente em torno da arquitetura de big data. E quando realmente tentamos generalizá-lo, a conclusão a que chegamos - o diagrama que criamos parecia muito com isso.
Não vou entrar nisso, especialmente porque Mike fará uma quantidade razoável de arquitetura de dados para análise. Mas o que eu realmente gosto que as pessoas se concentrem é nessa área inferior, onde estamos, de uma maneira ou de outra, reunindo dados. Temos algo que eu gostaria de referir é a refinaria de dados ou o hub de processamento de dados. E é aí que a governança ocorre. Então, se focarmos, parece que sim. Você sabe, ele está sendo alimentado por dados de fontes internas e externas. O hub deve, em teoria, receber todos os dados que estão sendo gerados. Ele deve ser transmitido e gerenciado como é transmitido se você precisar fazer análises e transmitir dados e depois ser transmitido ao hub. Ou então, tudo entra no hub. E há várias coisas que estão acontecendo - que estão acontecendo no hub. E você não pode ter uma certa quantidade de análises e SQL em andamento no hub. Mas você também precisa da virtualização de dados em cada célula para enviar dados para outras áreas. Mas antes que isso aconteça, você precisa, de uma maneira ou de outra, refinar a preparação dos dados. Você pode chamá-lo de preparação de dados. É muito maior que isso. Essas são as coisas que acho que incluem.
Temos um gerenciamento de sistema e gerenciamento de serviços, em certo sentido, que essa é a maior parte da camada de dados; então, na verdade, temos que aplicar todos os sistemas que gerenciam o esforço de gerenciamento de sistema operacional que tradicionalmente fazemos em praticamente todos os sistemas operacionais. Mas também precisamos, de uma forma ou de outra, monitorar outras coisas acontecendo para garantir que esses vários níveis de serviço sejam atendidos, porque é provável que haja níveis de serviço definidos ou qualquer tipo de análise como sendo acionada, ou dados de BI são sendo acionado.
Precisamos de monitoramento e gerenciamento de desempenho. Qualquer outra coisa, precisamos disso para saber que recursos adicionais de computador precisaremos alocar em vários momentos. Mas também, uma quantidade enorme de carga de trabalho está aqui, de fato, bastante complexa e competindo entre si por recursos. Há algo bastante sofisticado que precisa ser feito nessa área.
Agora, temos o ciclo de vida dos dados de uma maneira que nunca tivemos antes. O acordo aqui realmente está acima e além de qualquer outra coisa, que não coletamos dados e os descartamos antes. Nós tendíamos a coletar dados de que precisávamos e provavelmente os mantíamos, e depois arquivamos. Mas muito do que faremos daqui para frente é explorar dados. E se você não quiser os dados, vamos escondê-los. Portanto, os ciclos de vida dos dados são diferentes, dependendo da situação, mas também serão uma agregação muito maior de dados. Portanto, você sabe, de onde veio um agregado, qual é o ... qual é a fonte de agregação, e assim por diante. Isso é tudo necessário.
A linhagem de dados empresta naturalmente. Sem ele, você precisa conhecer os problemas, então os dados ... Temos que saber que os dados são válidos, mas com a confiabilidade que eles realmente são.
Também temos mapeamento de dados, porque muitos deles serão, de uma maneira ou de outra. E isto é, se você preferir, isso se relaciona até certo ponto no MDM. Agora é muito mais complicado agora, porque quando você tem muitos dados definidos pelo JSON ou com base em nosso esquema XML na leitura, precisará, de uma forma ou de outra, ter uma atividade muito ativa. atividade de mapeamento de dados em andamento.
Há uma situação de gerenciamento de metadados que é mais do que MDM, porque é necessário, de uma maneira ou de outra, criar o que eu gostaria de pensar agora como uma espécie de armazém de metadados de tudo o que você tem interesse. descoberta, porque alguns dos dados não terão necessariamente seus metadados declarados, e queremos usá-los imediatamente. E depois, há a limpeza de dados, que é uma coisa enorme, como uma série de coisas que se pode fazer lá. E também há segurança de dados. Todos esses dados devem ser protegidos para um nível aceitável, e isso pode até significar em certos casos - por exemplo, criptografar muitos valores.
Portanto, toda essa carga de trabalho é realmente o império da governança. Tudo isso, de uma maneira ou de outra, deve ocorrer ao mesmo tempo ou antes, toda a nossa atividade analítica. Esse é um grande número de aplicativos coordenados. É um sistema por si só. E então, aqueles que não o fizerem em vários momentos sofrerão com a falta dela à medida que avançam, porque muitas dessas coisas não são realmente opcionais. Você acaba aumentando apenas a entropia se não as fizer.
Então, em termos de análise de dados e governança, o que eu diria é que, realmente, uma mão lava a outra. Sem governança, o analytics e o BI não tropeçam com o tempo. E sem análises e BI, não haveria muita necessidade de governar os dados de qualquer maneira. Então, as duas coisas realmente andam de mãos dadas. Como se costuma dizer no Oriente Médio, "uma mão lava a outra". E isso é tudo o que tenho a dizer. Espero - espero que agora tenhamos Mike de volta.
Eric: Nós fazemos. Mike, presumo que você esteja lá. Vou empurrar seu slide para cima.
Mike: eu sou. Ok, você pode me ouvir?
Eric: Sim, eu posso te ouvir. Você parece maravilhoso. Então, deixe-me apresentar ... Lá vai você. E agora você é o apresentador. Leve embora.
Mike: Tudo bem, obrigado! Bom dia, boa tarde, boa noite a todos vocês por aí. Perdoe o soluço no começo. Por alguma razão, fiquei mudo e posso ver todo mundo, mas eles não conseguiram me ouvir.
Tudo bem. Então, o que eu quero fazer rapidamente é falar sobre o ecossistema analítico de big data. Se você quiser me fazer perguntas, eu diria que, nesta sessão ou mais tarde, você pode me encontrar nos meus detalhes de contato aqui. Como eu disse, no meio da noite aqui no Reino Unido.
Bem, deixe-me entender o que eu quero falar. Claramente, nos últimos anos, vimos o surgimento de todos os tipos de dados recém-encontrados que as empresas agora desejam analisar - tudo, desde dados de fluxo de cliques a entender comportamentos on-line, dados de mídia social que Eric estava falando no início do programa aqui. Acho que Robin mencionou JSON, BSON, XML - portanto, dados semiestruturados que são autoexplicativos. Obviamente, também temos muitas outras coisas - tudo, desde dados não estruturados, registros de infraestrutura de TI, dados de sensores. Todas essas fontes de dados relativamente novas pelas quais as empresas se interessaram agora porque contêm informações valiosas que podem potencialmente aprofundar o que sabemos.
Então, isso basicamente significa que o cenário analítico foi além do data warehousing tradicional. Ainda estruturamos os dados no mundo de uma combinação de dados estruturados e multi-estruturados, onde os dados multi-estruturados podem vir de dentro ou de fora da empresa em muitos casos. E como resultado desses novos tipos de dados e novas necessidades de análise, vimos o surgimento de novas cargas de trabalho analíticas - tudo, desde a análise de dados em movimento, que meio que vira a arquitetura tradicional de data warehousing, um pouco, onde , nos círculos tradicionais, integre dados, limpe, transforme, armazene e analise. Mas, analisando os dados em movimento, estamos capturando os dados, integrando-os, preparando-os através da análise e armazenando-os. Portanto, há análises em andamento sobre os dados antes de serem armazenados em qualquer lugar.
Fazemos análises complexas de dados estruturados, talvez para desenvolvimento de modelos, desenvolvimento estatístico e preditivo de modelos, que não são novidade para algumas pessoas em um espaço tradicional de data warehousing. Temos análises exploratórias de dados no modelo. Essa é a quantidade de dados estruturados lá. Temos novas cargas de trabalho na forma de análise de gráficos que, para meus clientes em serviços financeiros, incluem coisas como fraude. Também inclui segurança cibernética. Inclui redes sociais, é claro, entendendo influenciadores e coisas assim por lá. Eu mesmo dominei isso em gestão, tem alguns anos de análise gráfica.
Temos a otimização ou o descarregamento do processamento de ETL do data warehouse, que é mais um tipo de caso de uso de TI, o CIO pode financiar. E até mesmo arquivar dados e data warehouses para mantê-lo online em coisas como o Hadoop. Portanto, todas essas novas cargas de trabalho analíticas adicionaram novas plataformas, novas plataformas de armazenamento ao cenário analítico. Portanto, em vez de apenas ter data warehouses e data marts tradicionais, o que temos agora é o Hadoop. Temos bancos de dados NoSQL, como bancos de dados gráficos, que são frequentemente usados para cargas de trabalho analíticas. Obviamente, agora podemos fazer a análise gráfica no próprio Hadoop, bem como nos DBMSs do gráfico NoSQL. Temos análises de streaming que Robin mencionou. E temos - se você quiser - construção de modelos, talvez também em dispositivos de armazenamento de dados analíticos. Mas tudo isso complicou o cenário analítico, sendo necessárias agora várias plataformas. E acho que o desafio de, para qualquer empresa com front office ou back office, ou finanças, compras, RH e algum tipo de operação, é descobrir quais projetos analíticos estão associados a uma cena tradicional de data warehousing. E quando você souber que os projetos analíticos estão associados a essas novas plataformas de big data e onde executar, você sabe qual carga de trabalho analítica, mas para não perder de vista os negócios no sentido em que é - você verá agora que é uma combinação de grandes projetos analíticos de dados e projetos tradicionais de armazenamento de big data que, juntos, são necessários para fortalecer-se no interior do cliente ou nas operações, no risco, nas finanças ou na sustentabilidade. E, portanto, queremos que tudo isso esteja alinhado às nossas prioridades estratégicas de negócios, para que continuemos no caminho para, você sabe, empurrar as agulhas que precisam ser empurradas, para melhorar o desempenho dos negócios, reduzir custos, para reduzir riscos, etc., para a nossa empresa como um todo. Portanto, não é que um substitua o outro por big data e tradicional. Os dois estão sendo usados juntos. E isso muda drasticamente a arquitetura, você sabe.
Então, o que tenho aqui é uma arquitetura relativamente nova que usarei com meus clientes. E assim, como você pode ver agora no fundo, uma vasta gama de fontes de dados, não apenas mais estruturada. Alguns deles estão transmitindo dados ao vivo, como sensores, como dados de mercado, esse tipo de coisa. Pode até ser dados ao vivo de fluxo de cliques. Pode ser dados de transmissão de vídeo ao vivo. Portanto, não precisava ser estruturado. Portanto, podemos realizar o processamento de fluxo desses dados para executar ações automáticas em tempo real, e quaisquer dados de interesse podem ser filtrados e passados para as ferramentas de gerenciamento de informações corporativas que podem ser usadas para preencher os armazenamentos de dados analíticos. A menos que você possa ver aqui, agora temos os bancos de dados tradicionais de data warehouse, Hadoop e NoSQL. Também temos o gerenciamento de dados mestre no mix. E isso coloca mais pressão em todo o conjunto de ferramentas de gerenciamento de dados, não apenas para preencher esses repositórios de dados, mas para mover dados entre eles.
Além disso, temos que simplificar as ferramentas de acesso. Não podemos simplesmente nos voltar para o usuário e dizer: "obtenha todos esses armazenamentos de dados, mantenha essas APIs - o seu problema". O que você precisa fazer é simplificar o acesso. E assim, nas linhas pontilhadas, você verá que a virtualização e a otimização de dados escondem a complexidade do armazenamento múltiplo de dados, tentam facilitar o acesso dos usuários finais. E, é claro, há uma variedade de ferramentas no topo, você sabe - tudo, desde as ferramentas tradicionais de BI que começaram no início do data warehousing, movendo-se gradualmente para a esquerda do gráfico para se conectar aos Hadoops e, em seguida, bancos de dados NoSQL do mundo.
Temos pesquisas para obter uma nova concessão da vida, especialmente para os dados estruturados e não estruturados do corpo, que geralmente são armazenados no Hadoop. Temos aplicativos analíticos personalizados para serem executados em uma plataforma Hadoop com o MapReduce, portanto, a estrutura Spark, por exemplo. Temos ferramentas de análise de gráficos para, você sabe, se concentrar em cargas de trabalho muito específicas lá. Portanto, uma variedade de ferramentas e os fluxos de dados também são mais complexos. Não é mais apenas uma rua de mão única no data warehouse. Agora são dados mestre, é claro.
Temos novas fontes de dados chegando, sendo capturadas no NoSQL, você sabe, armazenamentos de dados como MongoDB, como Cassandra, como HBase. Temos dados sendo trazidos diretamente para o Hadoop para análise e preparação de dados. Recebemos novas idéias do Hadoop e dos data warehouses. Temos um arquivo saindo dos data warehouses no Hadoop. Agora, temos feeds de dados para, você sabe, todos os bancos de dados NoSQL e data marts também. Então, o que você pode ver aqui é que há muito mais atividade acontecendo no gerenciamento de dados. E isso significa que está colocando o software de gerenciamento de dados sob considerável pressão. Não é mais apenas uma rua de mão única. É uma movimentação de dados bidirecional. Há muito mais atividades acontecendo e, portanto, a escalabilidade é importante na frente da ferramenta de gerenciamento de dados e na fonte de dados.
Portanto, este gráfico remonta à arquitetura que mencionei há pouco. Ele mostra as diferentes cargas de trabalho analíticas em execução em diferentes partes dessa arquitetura. No canto inferior esquerdo, há streaming em tempo real, processamento de stream em dados provenientes de, você sabe, qualquer tipo de armazenamento de dados ao vivo. Temos análises de classe acontecendo nos bancos de dados de gráficos NoSQL. Isso também pode acontecer no Hadoop. Com a estrutura Spark, por exemplo, e o GraphX lá, temos análises investigativas e a refinaria de dados que Robin estava falando sobre acontecer no Hadoop. Ainda temos cargas de trabalho tradicionais em andamento e data warehousing, você sabe, usuários avançados construindo modelos estatísticos e preditivos, talvez em dispositivos de data warehouse. E ainda estamos tentando simplificar o acesso a tudo isso para facilitar aos usuários finais.
Portanto, o sucesso de toda essa configuração é mais do que apenas o lado analítico. Você sabe, podemos colocar as plataformas analíticas no lugar, mas se não podemos capturar e ingerir dados de alta velocidade e alto volume, na escala, não há muito sentido. Você sabe, não tenho nada para analisar. E assim, o sucesso da análise de big data exige que os sistemas operacionais sejam ampliados. Isso significa que, para poder suportar novas transações, você sabe, atinge picos. Você sabe, qualquer dado não transacional sendo capturado pode haver novas taxas de chegada taxas de chegada muito, muito altas em dados de alta velocidade, como sensores ou qualquer ingestão. Temos que ser capazes de atender a tudo isso - ser capaz de capturar esse tipo de dados e trazê-lo para análise. Também temos que escalar as próprias análises, simplificar o acesso aos dados que já mencionei. E então, amarre isso. Você sabe, precisamos refinar esses sistemas operacionais para dar um loop fechado.
Portanto, dimensionar o lado operacional da casa para capturar dados leva ao mundo do banco de dados NoSQL. Quero dizer, aqui você vê cinco categorias de banco de dados NoSQL. Essa categoria será modelada apenas como uma combinação dos outros quatro acima. Em geral, você sabe, seus valores-chave, documentos armazenados e bancos de dados da família de colunas - os três primeiros lá - que são usados para o tipo de dados transacionais e não transacionais.
Alguns desses bancos de dados suportam como propriedades; alguns deles não. Mas, no entanto, estamos vendo a introdução deles para dimensionar esses tipos de aplicativos. E assim, por exemplo, à medida que nos afastamos de apenas funcionários entrando em transações nos teclados para agora clientes e massas usando novos dispositivos para poder fazer isso. Vimos um grande aumento no número de transações sendo inseridas nas empresas. E assim, precisamos escalar aplicativos transacionais para fazer isso.
Agora, de um modo geral, isso pode ser feito nos bancos de dados NewSQL como um banco de dados relacional como o NuoDB e o VoltDB mostrado aqui. Ou alguns dos bancos de dados NoSQL que talvez suportem propriedades ACID que possam garantir o processamento de transações podem estar em jogo. Isso também se aplica a dados não transacionais, como dados do carrinho de compras antes de uma transação, antes que as pessoas comprem coisas, dados do sensor, como eu perco uma leitura do sensor entre centenas de milhões de leituras do sensor. Não é grande coisa. Cliques, você sabe, no mundo do fluxo de cliques - se eu usar um clique, não é grande coisa.Então, você sabe, não precisamos necessariamente ter propriedades ACID lá, e muitas vezes é aí que os bancos de dados NoSQL entram em jogo, estava lá - essa capacidade de executar um processamento muito alto e correto em escala para capturar esses novos tipos de dados.
Ao mesmo tempo, queremos que a análise seja dimensionada. E assim, puxar os dados dos armazenamentos de dados para as plataformas analíticas não será mais invadido porque os dados são grandes demais. O que realmente queremos é enviar as análises de outra maneira, para o data warehouse corporativo no Hadoop, para o processamento de fluxo para poder enviar as análises para os dados. No entanto, apenas porque alguém diz que está na análise de banco de dados ou na análise do Hadoop não significa necessariamente que a análise é executada em paralelo. E, francamente, se você vai investir nessas novas tecnologias escalonáveis massivamente paralelas, como o Hadoop, como os dispositivos de data warehouse e outros enfeites, como os mecanismos de processamento de fluxo em cluster, precisamos que as análises sejam executadas em paralelo.
Então, isso é apenas o check-out. Você sabe, se tivermos análises para ajudar a prever coisas para clientes, operações, riscos, etc., queremos que eles sejam executados em paralelo, não apenas na plataforma. Nós queremos os dois. E é porque, você sabe, a tecnologia também é como essas novas ferramentas de descoberta visual, como o SAS. Na verdade, é um dos nossos patrocinadores aqui.
Uma coisa que as pessoas querem é pelo menos explorar aquelas no Hadoop e depois na análise de banco de dados. E queremos que eles sejam executados em paralelo para oferecer o desempenho necessário em volumes tão altos de dados. Ao mesmo tempo, estamos tentando simplificar o acesso a tudo isso. E assim, o SQL agora está de volta à agenda. Você sabe, o SQL é - o SQL no Hadoop está quente no momento. Estou acompanhando-o em 19 iniciativas SQL e Hadoop no momento. Além disso, você pode ver que podemos obter esses dados de várias maneiras, para acessar diretamente o SQL no próprio Hadoop, podemos passar o SQL a um índice de pesquisa. Dessa forma, como, você sabe, alguns dos fornecedores de pesquisa desse espaço, podemos ter acesso SQL a bancos de dados relacionais analíticos que possuem tabelas do Excel no Hadoop.
Agora podemos ter acesso SQL a um servidor de virtualização de dados que, por sua vez, pode ser conectado a um data warehouse no Hadoop. Ainda estou começando a ver o surgimento do acesso SQL a dados de transmissão ao vivo. Portanto, o acesso do SQL a tudo isso está crescendo rapidamente. E parte do desafio é justamente porque o acesso ao SQL está sendo comercializado por aí. A questão é: o SQL pode lidar com dados complexos? E isso não é necessariamente simples. Existem todos os tipos de complicações aqui, incluindo o fato de que os dados JSON podem ser aninhados. Podemos ter registros variantes de esquema. Portanto, o primeiro registro possui um esquema. O segundo registro tem um esquema diferente. Essas coisas são muito diferentes do que acontece em um mundo relacional.
Portanto, precisamos fazer perguntas sobre que tipo de dados estamos tentando analisar e quais são os tipos de características analíticas. É, você sabe, o painel que você deseja fazer? É aprendizado de máquina? É análise gráfica? Você pode fazer isso a partir do SQL? Você sabe, isso é invocável do SQL? Quantos usuários simultâneos conseguimos fazer isso? Você sabe, temos centenas de usuários simultâneos. Isso é possível em dados complexos? Você sabe, todas essas coisas são questões-chave. Então, eu meio que fiz uma lista de alguns aqui que acho que você deveria considerar. Você sabe, que tipo de formato de arquivo? De que tipo de dados estamos falando? Que tipo de funções analíticas podemos chamar do SQL para obter dados complexos? E o tipo de funções é executado em paralelo. Quero dizer, eles precisam ser executados em paralelo, se conseguirmos escalar isso. E posso associar dados no Hadoop hoje fora dele, você sabe, ou isso não é possível? E o que farei com todos esses tipos diferentes de cargas de trabalho de consulta?
E como veremos, pelo que vi, há muitas diferenças na distribuição do SQL e do Hadoop. Estes são todos os que eu estou rastreando. E, a propósito, isso é puro SQL no Hadoop. Isso nem inclui a virtualização de dados neste momento. E assim, muito por aí e muito espaço para consolidação, o que acho que vai acontecer no próximo ano, dezoito meses ou mais. Mas isso também abre outra coisa: eu posso ter vários mecanismos SQL potencialmente nos mesmos dados no Hadoop. E isso é algo que você não pode fazer em relação.
Obviamente, isso significa que você precisa saber que tipo de carga de trabalho de consulta estou executando? Devo executar isso em lote em uma iniciativa específica do SQL on Hadoop? Devo executar cargas de trabalho de consulta interativa por meio de outra iniciativa SQL no Hadoop, etc., para saber a qual conectar? Idealmente, é claro, não devemos fazer isso. Deveríamos fazer uma pergunta sobre isso. Você sabe, alguns otimizadores descobrem a melhor maneira de fazer isso. Mas ainda não estamos totalmente lá, na minha opinião.
No entanto, também a virtualização de dados, que mencionei anteriormente, tem um papel muito importante para simplificar o acesso a vários armazenamentos de dados. E se criarmos novas idéias sobre o Hadoop, é certamente plausível associarmos esses dados a dados e os data warehouses tradicionais por meio da virtualização de dados, por exemplo, sem necessariamente mover os dados do Hadoop para os data warehouses tradicionais. Claro, você pode fazer isso também. Também é plausível se eu arquivar dados do data warehouse tradicional no Hadoop. Ainda posso falar sobre isso e associá-lo às coisas que estão em nosso data warehouse para virtualização de dados. Então, para mim, acho que a virtualização de dados tem um grande futuro nessa arquitetura geral e simplifica o acesso a todos esses armazenamentos de dados.
E para não esquecer que, quando criamos esses novos insights, seja em sistemas relacionais ou NoSQL, ainda queremos levar esses insights de volta às nossas operações, para que possamos maximizar o valor do que descobrimos, para que possamos alavancar isso para decisões mais eficazes e oportunas nesse ambiente para otimizar nossos negócios.
Então, para concluir, o que estou vendo é que precisamos de novas fontes de dados emergentes. Temos novas plataformas em uma arquitetura mais complicada, se você preferir, para lidar com isso. E o Hadoop se tornou muito, muito importante, o suficiente para a preparação de dados para nossas caixas de areia líquidas, para consulta de arquivamento, arquivamento do data warehouse, gerenciamento de dados abrindo suas asas para ir além do data warehouse e gerenciar dados em todas essas plataformas, além de novas ferramentas capaz de analisar e acessar dados nesses ambientes, de poder ter tecnologias escalonáveis para obter melhor ingestão de dados e dimensionar as análises empurrando-as para dentro das plataformas para torná-las mais paralelas. E, esperançosamente, também para simplificar o acesso a tudo isso através do SQL emergente que chega por cima. Então, dá uma idéia do tipo de onde estamos indo. Então, com isso, voltarei a, acho, Eric agora, é?
Eric: Ok, isso é fantástico. E pessoal, devo dizer, entre o que você acabou de receber de Robin e Mike, provavelmente é tão abrangente e conciso na visão geral de toda a paisagem, quanto você encontrará em qualquer lugar. Deixe-me ir em frente e colocar na fila George Corugedo primeiro. E aí está. Deixe-me levar isso por um segundo rápido. Tudo bem, George, estou prestes a entregar as chaves para você e levá-las embora. O chão é seu.
George: Ótimo! Muito obrigado, Eric, e obrigado, Rob e Mike. Essa foi uma ótima informação e muita coisa que concordamos. Então, voltando à discussão de Robin, porque, você sabe, não é coincidência o RedPoint estar aqui e o SAS estar aqui. Como o RedPoint, nós realmente focamos no lado dos dados, na governança, no processamento dos dados e na preparação para o uso em análises. Então, deixe-me ver esses dois slides. E realmente fale e entenda o ponto de Robin sobre o MDM e como é importante e quão útil, acho - e pensamos - o Hadoop pode estar no mundo do MDM e da qualidade dos dados.
Sabe, Robin estava falando um pouco sobre como isso está relacionado ao mundo do data warehouse corporativo e eu venho - você sabe, passei vários anos na Accenture. E o interessante foi quantas vezes tivemos que entrar nas empresas e tentar descobrir o que fazer com o data warehouse que basicamente havia sido abandonado. E muito disso aconteceu porque a equipe do data warehouse realmente não alinhou sua construção aos usuários corporativos ou aos consumidores dos dados. Ou demorou tanto que, no momento em que eles criaram a coisa, o uso ou a lógica dos negócios evoluíram.
E uma das coisas que eu acho que é, estou muito empolgado, com a ideia de usar o Hadoop para gerenciamento de dados mestre, qualidade e preparação de dados, é o fato de que você sempre pode voltar aos dados atômicos em um Lago de dados Hadoop ou reservatório de dados, repositório de dados, hub ou qualquer que seja o formato de buzz que você deseja usar. Mas como você sempre mantém esses dados atômicos, sempre tem a oportunidade de se realinhar com os usuários de negócios. Porque, como analista - porque eu realmente comecei minha carreira como estatístico - você sabe, nada é pior do que, você sabe, os data warehouses da empresa são maravilhosos para conduzir os relatórios, mas se você deseja fazer análises realmente preditivas, elas são realmente não é tão útil, porque o que você realmente deseja são os dados comportamentais granulares que de alguma forma foram resumidos e agregados no data warehouse. Portanto, acho que esse é realmente um recurso importante, e acho que não concordo com Robin, porque deixaria os dados no data lake ou no hub de dados o maior tempo possível, porque, desde que o os dados estão lá e são limpos, você pode vê-los de uma direção, de outra direção. Você pode mesclá-lo com outros dados. Você sempre tem a oportunidade de voltar e se reestruturar e, em seguida, se realinhar com uma unidade de negócios e com a necessidade que essa unidade possa ter.
Uma das outras coisas interessantes sobre isso é que, por ser uma plataforma computacional tão poderosa, grande parte da carga de trabalho de que falamos, vemos tudo chegando diretamente ao Hadoop. E enquanto, eu acho, Mike estava falando sobre todas as diferentes tecnologias existentes no mundo - neste tipo de ecossistema de big data, pensamos que o Hadoop é realmente o cavalo de batalha para fazer essa escala em grande escala em processamento computacionalmente intensivo que dados mestre e qualidade dos dados exigem. Como se você pode fazê-lo lá, você sabe, apenas a simples economia de mover dados de seus bancos de dados caros e para bancos de dados econômicos, isso está realmente impulsionando muito da adoção agora em grandes empresas.
Agora, é claro, existem alguns desafios, certo? Existem desafios em torno das tecnologias. Muitos deles são muito imaturos. Eu diria, você sabe, eu não sei quantas, mas várias das tecnologias mencionadas por Mike ainda estão em lançamentos de ponto zero, certo? Portanto, essas tecnologias são muito jovens, muito imaturas, ainda baseadas em código. E isso realmente cria um desafio para as empresas. E realmente nos concentramos em resolver problemas em nível empresarial. E assim, pensamos que deve haver uma maneira diferente, e é isso que propomos é uma maneira diferente de abordar algumas das coisas usando algumas dessas tecnologias muito recentes.
E então, e então a outra questão interessante aqui, que foi mencionada anteriormente, ou seja, quando você tem dados que está capturando em um ambiente Hadoop de qualquer tipo, você sabe, geralmente é esquema na leitura e não na gravação com algumas exceções. E essa leitura, muito está sendo feita por estatísticos. E assim, os estatísticos precisam ter ferramentas que lhes permitam estruturar adequadamente os dados para fins analíticos, porque no final do dia, para tornar os dados úteis, eles precisam ser estruturados de alguma forma para ver alguns ou responder a uma pergunta ou pergunta. uma empresa, algum tipo de empresa, cria valor comercial.
Então, onde entramos é que temos uma aplicação mestre de gerenciamento e chave mestre de qualidade de dados EPL, ELT muito ampla e madura. Está no mercado há muitos, muitos anos. E possui toda a funcionalidade ou grande parte da funcionalidade listada por Robin nesse gráfico circular - tudo, desde a captura pura de dados brutos em toda uma variedade de formatos e estruturas XML e outras informações, até a capacidade de fazer toda a limpeza, o conclusão dos dados, correção dos dados, bits do núcleo geoespacial dos dados. Isso é algo que está se tornando cada vez mais importante nos dias de hoje com a Internet das Coisas. Você sabe, há geografia associada a grande parte do que fazemos ou a grande parte desses dados. E assim, toda a análise, a tokenização, a limpeza, a correção, a formatação, a estruturação etc., tudo isso é feito em nossa plataforma.
E então, e talvez, pensemos mais importante é a ideia de desduplicação. Você sabe, no centro, se você olhar para qualquer definição de gerenciamento de dados mestre, o principal é a desduplicação. É capaz de identificar entidades em diferentes fontes de dados e, em seguida, criar um registro mestre para essa entidade. E essa entidade poderia ser uma pessoa. A entidade pode fazer parte de um avião, por exemplo. A entidade pode ser um alimento como fizemos para um de nossos clientes do health club. Criamos um banco de dados mestre de alimentos para eles. Portanto, quaisquer que sejam as entidades com as quais estamos trabalhando - e, é claro, cada vez mais, existem pessoas e proxies para suas identidades, que são coisas como identificadores ou contas sociais, quaisquer dispositivos associados a pessoas, coisas como carros e telefones e qualquer outra coisa que você possa imaginar.
Sabe, estamos trabalhando com um cliente que coloca todos os tipos de sensores em roupas esportivas. Portanto, os dados estão vindo de todas as direções. E de uma maneira ou de outra, é um reflexo ou representação da entidade principal. E, cada vez mais, são as pessoas e a capacidade de identificar os relacionamentos entre todas essas fontes de dados e como elas se relacionam com a entidade principal, além de poder rastrear essa entidade principal ao longo do tempo, para que você possa analisar e entender as mudanças entre essa entidade. e todos os outros elementos que estão nas representações dessa entidade, uma análise realmente crítica para as análises a longo prazo e longitudinal das pessoas, por exemplo. E esse é realmente um dos benefícios realmente importantes que, acredito, o big data pode nos trazer, é uma compreensão muito melhor das pessoas e, a longo prazo, além de entender os con e como as pessoas estão se comportando quando estão se comportando com quais dispositivos, etc. .
Então, deixe-me passar por aqui rapidamente. Eric mencionou YARN. Você sabe, eu passo isso apenas por um segundo, porque enquanto o YARN - as pessoas falam sobre o YARN. Ainda acho que ainda há muita ignorância sobre o YARN. E realmente não muita gente - ainda há muitos mal-entendidos sobre o YARN. E o fato é que, se seu aplicativo foi arquitetado da maneira correta e você possui o nível ou paralelização adequados em sua arquitetura de aplicativos, você pode aproveitar o YARN para usar o Hadoop como sua plataforma de dimensionamento. E foi exatamente isso que fizemos.
Você sabe, novamente, apenas para apontar algumas das definições em torno do YARN. Para nós, o que realmente é o YARN nos permitiu que nós e outras organizações nos tornássemos colegas do MapReduce e Spark e de todas as outras ferramentas disponíveis. Mas o fato é que nossos aplicativos direcionam código otimizado diretamente para o YARN no Hadoop. E há um comentário realmente interessante que Mike mencionou, porque, você sabe, a pergunta sobre análises e nossas análises, apenas porque elas estão no cluster, elas estão realmente funcionando paralelamente? Você pode fazer a mesma pergunta sobre muitas das ferramentas de qualidade de dados existentes.
Na maior parte do dia, as ferramentas de qualidade que estão por aí precisam retirar os dados ou inserir códigos. E, em muitos casos, é um único fluxo de dados que está sendo processado devido à maneira como você precisa compare registros, às vezes em atividades com qualidade de dados. E o fato é que, como estamos utilizando o YARN, conseguimos realmente tirar proveito da paralelização.
E apenas para fornecer uma visão geral rápida, porque outro comentário é feito sobre a importância de poder expandir bancos de dados tradicionais, novos bancos de dados, etc., implementamos ou instalamos fora do cluster. E colocamos nossos binários diretamente no gerenciador de recursos, YARN. E isso e, em seguida, o YARN o distribui entre os nós no cluster. E o que isso faz é que o YARN - permitimos que o YARN gerencie e faça seu trabalho, que é descobrir onde estão os dados e levar o trabalho para os dados, o código para os dados e não mover os dados. Quando você ouve as ferramentas de qualidade dos dados e elas estão lhe dizendo que a melhor prática é mover os dados para fora do Hadoop, corra por toda a vida, porque não é desse jeito. Você quer levar o trabalho para os dados. E é isso que o YARN faz primeiro. Leva nossos binários para os nós em que os dados residem.
E também porque estamos fora do cluster, também podemos acessar todos os bancos de dados relacionais e tradicionais, para que possamos ter trabalhos 100% de servidor cliente em um banco de dados tradicional, 100% Hadoop ou trabalhos híbridos que atravessam o servidor cliente Hadoop , Oracle, Teradata - o que você quiser e tudo no mesmo trabalho, porque essa implementação pode acessar os dois lados do mundo.
E então, voltando a toda a idéia da criação das ferramentas, veja aqui, isso é apenas uma representação simples. E o que estamos tentando fazer é simplificar o mundo. E a maneira como fazemos isso é trazendo um conjunto muito amplo de funcionalidades ao redor do HDFS para torná-lo ... E não é porque estamos tentando eliminar todas as tecnologias inovadoras por aí. Apenas as empresas precisam de estabilidade e não gostam de soluções baseadas em código. E, portanto, o que estamos tentando fazer é proporcionar às empresas um ambiente de aplicativos familiar, repetível e consistente, que lhes permita criar e processar dados de uma maneira muito previsível.
Rapidamente, esse é o tipo de impacto que obtemos com nosso aplicativo. Você vê MapReduce vs. Pig vs. RedPoint - nenhuma linha de código no RedPoint. Seis horas de desenvolvimento no MapReduce, três horas de desenvolvimento no Pig e 15 minutos de desenvolvimento no RedPoint. E é aí que realmente temos um grande impacto. O tempo de processamento também é mais rápido, mas o tempo das pessoas, o tempo de produtividade das pessoas aumenta significativamente.
E no meu slide final aqui, quero voltar a essa ideia, porque essa é a nossa opinião sobre o uso de um data lake ou um hub de dados ou uma refinaria de dados como o ponto central da ingestão. Não poderia concordar mais com essa ideia. E atualmente estamos discutindo com muitos diretores de dados dos principais bancos globais, e essa é a arquitetura de sua escolha.A ingestão de dados de todas as fontes faz o processamento da qualidade dos dados e o gerenciamento dos dados principais dentro do data lake e, em seguida, envia os dados para onde eles precisam ir para dar suporte a aplicativos, para dar suporte ao BI, qualquer que seja. E então, se você tiver análises em BI, elas poderão ser executadas diretamente dentro do data lake, onde melhor, isso pode começar imediatamente. Mas muito a bordo com essa idéia. Essa topologia aqui é a que estamos descobrindo que está ganhando muita força no mercado. E é isso.
Eric: Ok, bom. Vamos seguir por aqui. Eu vou em frente e entrego para Keith. Keith, você tem cerca de 10, 12 minutos para agitar a casa aqui. Nós demoramos um pouco nesses shows. E anunciamos 70 minutos para este. Portanto, vá em frente e clique em qualquer lugar desse slide, use a seta para baixo e remova-a.
Keith: Claro. Não tem problema, Eric. Eu agradeço. Vou seguir em frente e abordar apenas algumas questões sobre o SAS, depois vou entrar nas arquiteturas de tecnologia de onde o SAS se cruza com o mundo do big data. Há muito o que explicar em todas essas coisas. Poderíamos passar horas analisando detalhadamente, mas dez minutos - você deve ser capaz de sair com apenas um breve entendimento de onde o SAS levou as tecnologias de análise, gerenciamento de dados e inteligência de negócios para esse mundo de big data.
Primeiro, apenas um pouco sobre o SAS. Se você não conhece esta organização, nos últimos 38 anos realizamos análises avançadas, inteligência de negócios e gerenciamento de dados com não apenas big data, mas também dados e riqueza de dados pequenos nos últimos 38 anos. Temos um número enorme de clientes, cerca de 75.000 locais em todo o mundo, trabalhando com algumas das principais organizações existentes. Somos uma organização privada com cerca de 13.000 funcionários e US $ 3 bilhões em receita. E, na verdade, acho que a parte importante é que tradicionalmente temos um histórico antigo de reinvestir quantias significativas de nossa receita de volta em nossa organização de P&D, o que realmente levou a suportar muitas dessas incríveis tecnologias e plataformas que você ' vou ver hoje.
Então, eu vou pular direto para esses diagramas de arquitetura realmente assustadores. Trabalharemos da esquerda para a direita nos meus slides. Então, há coisas familiares que você verá dentro desta plataforma. No lado esquerdo, todas as fontes de dados que estamos falando sobre a inserção nessas plataformas de big data. E então, você tem essa plataforma de big data.
Acabei de colocar a palavra Hadoop no topo, porque, em última análise, os exemplos que vou dar hoje são especificamente sobre todas as tecnologias em que nos cruzamos com essas plataformas de big data. Por acaso, o Hadoop é um dos locais em que temos algumas das opções de implantação mais robustas, mas também nos cruzamos bastante e desenvolvemos muitas dessas tecnologias há algum tempo com alguns de nossos outros parceiros de data warehouse corporativos, como Teradata, Oracle, Pivotal e similares. Portanto, não posso entrar em grandes detalhes sobre todas as diferentes tecnologias suportadas em qual plataforma, mas tenha certeza de que todas as que descrevo hoje são na maior parte tudo o que o Hadoop e uma grande quantidade delas se cruzam com outros parceiros de tecnologia que temos. Então, temos uma plataforma tão grande ali.
No próximo, à direita, temos o SAS LASR Analytic Server. Agora, isso é essencialmente um paralelo massivo no servidor de aplicativos analíticos de memória. Ficaríamos claros que não é um banco de dados na memória. É realmente projetado desde o início. Não é o mecanismo de consulta, mas foi projetado para atender solicitações analíticas em grande escala de maneira massivamente paralela. Então, esses são os principais aplicativos de serviço que você vê lá no lado direito.
Abordaremos um pouco mais sobre como as pessoas implantam essas coisas. Mas, essencialmente, o aplicativo - você vê lá - o primeiro, é nossa análise de alto desempenho do SAS. Vai ser assim - estou usando muita da nossa tecnologia e plataformas existentes, como o Enterprise Miner ou apenas um SAS, e não apenas fazendo multithreading com alguns desses algoritmos que incorporamos nas ferramentas para as quais fizemos anos, mas também para paralelamente massivamente. Portanto, para mover os dados dessa plataforma de big data para o espaço de memória para o LASR Analytic Server, para que possamos executar algoritmos analíticos - você sabe, muito do novo aprendizado de máquina, redes neurais, regressões aleatórias de floresta, esses tipos de coisas - novamente, os dados guardados na memória. Portanto, livrar-se desse gargalo de paradigma do MapReduce em que somos arquivados nessas plataformas, não é dessa maneira que você deseja fazer o trabalho analítico. Portanto, queremos poder levantar os dados uma vez no espaço da memória e iterá-los, às vezes milhares de vezes. Então, esse é o conceito de usar esse servidor LASR analítico de alto desempenho.
Nós também - os outros aplicativos abaixo, a análise visual, que nos permitem persistir esses dados na memória e atender uma população maior nos mesmos dados. Assim, permitindo que as pessoas façam exploração de big data. Portanto, antes de fazermos o trabalho de desenvolvimento do modelo, estamos explorando dados, entendendo-os, executando correlações, realizando ou tendendo árvores de decisão - esses tipos de coisas - mas de uma maneira muito visual e interativa nos dados que estão na memória plataforma. Isso também atende à nossa comunidade de BI, na medida em que possui uma base muito ampla de usuários que podem acessar essa plataforma para fazer os tipos padrão de gravação que você vê - que praticamente qualquer fornecedor de BI sabe.
O próximo passo, passamos para o serviço. E para ajudar nossos estatísticos e nosso pessoal de análise a fazer esse tipo de modelagem ad-hoc com dados armazenados na memória, removidos da análise visual e da exploração em nosso aplicativo de estatística visual. Essa é uma oportunidade para as pessoas aproveitarem, para não executar estatísticas em lotes que costumavam iterar, executar os modelos e ver os resultados. Então, isso pode executar o modelo, veja os resultados. Isso é para arrastar e soltar visualmente a modelagem estatística interativa. Portanto, isso ajuda nossos estatísticos e nossos cientistas de dados a realizar grande parte desse trabalho inicial de estatística visual exploratória.
E então, não esquecemos nossos codificadores - o pessoal que realmente deseja ter, é capaz de descascar as camadas da interface oposta, é escrever aplicativos e escrever sua própria base de código no SAS. E essas são as nossas estatísticas na memória do Hadoop. E essa é a - essencialmente a camada de código que nos permitiu interagir com o servidor Analytic LASR para emitir comandos diretamente e personalizar esses aplicativos com base em nossa solicitação. Essa é a peça analítica.
Como essas coisas são criadas ... Opa, desculpe pessoal. Aqui vamos nós.
Então, existem algumas maneiras pelas quais fazemos isso. Uma é fazer isso com big data - nesse caso, com o Hadoop. E é aí que temos o SAS LASR Analytic Server em execução em um cluster separado de máquinas que são otimizadas para análises críticas. Isso está aninhado de forma agradável e próximo à plataforma de big data, permitindo escalá-lo separadamente da plataforma de big data. Então, vemos pessoas fazendo isso quando não querem ter o que eu caracterizo como software vampiro corroendo cada um dos nós em seu cluster Hadoop. E eles não necessariamente escalam a plataforma de big data apropriada para realizar análises pesadas na memória. Portanto, você pode ter 120 nós do cluster Hadoop, mas eles podem ter 16 nós de servidores analíticos projetados para executar esse tipo de trabalho.
Ainda podemos manter esse paralelismo da plataforma de big data para puxar os dados para a memória. Portanto, é realmente um SAS usando com a plataforma Hadoop. Um modelo de nomeação diferente então é dizer, bem, também podemos usar essa plataforma de commodities e empurrá-la - basicamente, execute o Analytic LASR Server nas plataformas Hadoop. Então, é aí que estamos ... você está operando dentro da plataforma de big data. Também são alguns de nossos outros fornecedores de eletrodomésticos. Então, isso nos permitiu usar essencialmente essa plataforma de commodities para fazer esse trabalho.
Vemos isso com mais frequência em coisas como análises de alto desempenho, em que é um tipo de execução analítica de uso único ou uso único, mais orientado a lotes onde você está - você não deseja necessariamente consumir o espaço de memória no Hadoop plataforma. Somos muito flexíveis nesse tipo de modelo de implantação, definitivamente trabalhando com o YARN em muitos desses casos, para garantir que estamos jogando clusters agradáveis.
Ok, então esse é o mundo analítico, só para ficar claro lá com o aplicativo analítico. Mas mencionei que o SAS, no início, também é uma plataforma de gerenciamento de dados. E há coisas que são apropriadas para empurrar a lógica para essa plataforma, onde apropriado. Portanto, existem algumas maneiras pelas quais fazemos isso. Um deles é no mundo da integração de dados, fazer o trabalho de transformação de dados em dados pode não fazer sentido retirá-lo, como já ouvimos antes, executando rotinas de qualidade de dados que são importantes. Definitivamente, queremos inserir coisas como rotinas de qualidade de dados nessa plataforma. E então, coisas como pontuação de modelo. Então, eu desenvolvi meu modelo. Não quero reescrever isso no MapReduce e dificultar e consumir muito tempo refazer esse trabalho na plataforma de banco de dados nativa.
Portanto, se você observar, por exemplo, nosso acelerador de pontuação para o Hadoop, que nos permite pegar um modelo e empurrar a lógica matemática do SAS para a plataforma Hadoop e executá-la lá, usando o paralelismo que está dentro dessa plataforma de big data. Em seguida, temos nosso acelerador de código para várias plataformas, incluindo o Hadoop, e isso nos permite executar essencialmente o código de etapa de dados SAS dentro da plataforma de uma maneira massivamente paralela - fazendo com que a transformação de dados funcione na plataforma. Além disso, nosso acelerador de qualidade de dados SAS, que nos permite ter uma base de conhecimento de qualidade, capaz de fazer coisas como correspondência de gênero, código de correspondência de padronização - todas as diferentes coisas de qualidade de dados que você já ouviu hoje.
E então, última peça, há o Data Loader. Sabemos que nossos usuários de negócios precisarão não precisar escrever código, fazer a transformação de dados funcionar nessas plataformas de big data. O Data Loader é uma boa interface gráfica WYSIWYG que nos permite agrupar essas outras tecnologias. É como um assistente passo a passo, digamos, executar uma consulta Hive ou executar uma rotina de qualidade de dados e não precisar escrever código nesse caso.
A última coisa que mencionarei é esta peça da frente. Temos - como mencionei antes - um enorme pé SAS no mundo. E isso, não podemos apenas necessariamente fazer com que todas as plataformas que estão lá fora estejam neste espaço imediatamente. Portanto, definitivamente temos uma base de usuários que precisa obter dados nessas plataformas de big data, como obter dados do Teradata e colocá-los novamente no Hadoop, e vice-versa. Executando os modelos, eu já sei executar em meus servidores SAS, mas preciso obter dados que agora estão sendo colocados na plataforma Hadoop. Portanto, existe esse outro pequeno ícone chamado "de" e que nos permite conectar usando nossos mecanismos de acesso SAS - mecanismos de acesso ao Hadoop, Cloudera em Pola, Teradata, Greenplum e ... E a lista continua. Isso nos permite usar nossas plataformas SAS maduras existentes, que já estão em vigor para obter dados dessas plataformas, fazer o trabalho que precisamos realizar, empurrar os resultados de volta para essas áreas.
A última coisa que mencionarei é que todas essas tecnologias que você vê são governadas pelos mesmos metadados comuns padrão. Então, falamos sobre obter o trabalho de transformação, a regra da qualidade dos dados em funcionamento, movê-lo para a memória para poder fazer análises, modelar o desenvolvimento na pontuação. Temos todo o estilo de vida analítico, o ciclo de vida sendo governado por metadados comuns, governança, segurança e todas as coisas sobre as quais falamos hoje mais cedo.
Então, apenas uma recapitulação, existem realmente essas três grandes coisas para levar lá. Uma é que podemos tratar a plataforma de dados como qualquer outra fonte de dados, retirando-a e enviando-a quando for apropriado e conveniente. Podemos trabalhar com essas plataformas de big data, listando dados em uma plataforma analítica avançada de memória criada especificamente para esse fim. Então, esse é o servidor LASR.
E, finalmente, podemos trabalhar diretamente nessas plataformas de big data, aproveitando seus recursos de processamento distributivo sem mover os dados.
Eric: Bem, isso é uma coisa fantástica, pessoal. Sim, isso é ótimo! Então, vamos nos aprofundar em algumas perguntas. Normalmente, passamos cerca de 70 minutos ou um pouco mais nesses eventos. Então, vejo que ainda temos um ótimo público sentado lá fora. George, acho que vou fazer nossa primeira pergunta para você. Se você fala sobre colocar seu som binário no Hadoop, acho que parece que você realmente otimizou o fluxo de trabalho computacional. E essa é a chave para poder fazer esses tipos de governança de dados em tempo real, conquistas no estilo de qualidade de dados, porque esse é o valor que você deseja obter, certo? Se você não deseja voltar ao velho mundo do MDM, onde é muito complicado e consome muito tempo, e você realmente precisa forçar as pessoas a agir de determinadas maneiras, o que quase nunca funciona. E então, o que você fez foi condensar o ciclo do que era. Vamos chamar de dias, semanas, às vezes até meses para segundos, certo? É isso que está acontecendo?
George: Isso é exatamente certo, porque a escala que obtemos e o desempenho que obtemos de um cluster é realmente impressionante em termos de, apenas, você sabe, eu sempre estou um pouco hesitante em relação aos benchmarks. Mas apenas pela ordem de grandeza, quando rodaríamos um bilhão e 1,2 bilhões de registros e faríamos uma padronização completa de endereços - digo máquinas HP de gama média - seriam necessários, tipo, oito máquinas processadoras, você sabe , 2 GB de RAM por núcleo, você levaria 20 horas para ser executado. Agora, podemos fazer isso em cerca de oito minutos em um cluster de 12 nós. E assim, a escala do processamento que podemos fazer agora é tão radicalmente diferente que - e combina muito bem com a ideia de que você tem todos esses dados à sua disposição. Portanto, não é tão arriscado fazer o processamento. Se você fez errado, você pode refazê-lo. Você tem tempo, você sabe. Realmente mudou a escala disso, onde, você sabe, esses tipos de riscos realmente se tornaram verdadeiros problemas de negócios para as pessoas quando elas estavam tentando operar soluções MDM. Você precisa ter 30 pessoas no exterior fazendo governança de dados e tudo mais. E assim, você ainda precisa ter um pouco disso, mas a velocidade e a escala em que você pode processá-lo agora realmente oferece muito mais espaço para respirar.
Eric: Sim, esse é um ponto muito, muito bom. Eu amo esse comentário. Então, você tem tempo para refazê-lo novamente. Isso é fantástico.
George: Sim.
Eric: Bem, isso muda a dinâmica, certo? Isso muda a maneira como você pensa sobre o que vai tentar. Quero dizer, lembro disso há 18 anos na indústria de efeitos especiais, porque eu tinha um cliente que estava naquele espaço. E você pressionava os botões para renderizá-lo e voltava para casa. E você volta, talvez no sábado à tarde, para ver como estava indo. Mas se você entendeu errado, isso foi muito, muito, muito doloroso. E agora, não é nem um pouco - nem chega a ser tão doloroso, para que você tenha a oportunidade de experimentar mais coisas. Eu tenho que dizer, acho que esse é um ponto muito, muito bom.
George: Isso é exatamente correto. Sim, e você explode sua perna extra. Você sabe, você trabalha no meio do caminho nos velhos tempos e, se falhar, você estragou o seu SOS. É isso aí.
Eric: Certo. E você está com um grande problema, sim. Está certo.
George: Isso mesmo. Está certo.
Eric: Keith, deixe-me jogar um para você. Lembro-me de fazer uma entrevista com o seu CIL, Keith Collins, acredito que em 2011, talvez. E ele falou muito sobre a direção que o SAS estava tomando especificamente no que diz respeito ao trabalho com os clientes para incorporar as análises derivadas do SAS nos sistemas operacionais. E, é claro, ouvimos Mike Ferguson falar sobre a importância de lembrar. A idéia aqui é que você deseja vincular essas coisas às suas operações. Você não deseja análise no vácuo, desconectada da empresa. Isso não tem valor algum.
Se você deseja uma análise que possa impactar e otimizar diretamente as operações. E se eu olhar para trás - e devo dizer, achei uma boa ideia naquela época -, parece uma ideia muito, muito inteligente em retrospecto. E acho que é uma vantagem real que vocês têm. E, é claro, esse grande legado, essa enorme base de instalação e o fato de você ter se concentrado em incorporar essas análises em sistemas operacionais, o que significa que agora - e com certeza, será necessário algum trabalho - tenho certeza de que você ' estive trabalhando nisso bastante. Mas agora, você pode aproveitar todas essas novas inovações e realmente está em condições de operacionalizar todas essas coisas com seus clientes. É uma avaliação justa?
Keith: Sim, com certeza. O conceito é que você obtém essa ideia de design de decisão ou ciências da decisão que, até certo ponto, é algo exploratório e científico. A menos que você possa fazer engenharia no processo para realmente ... Se você pensa em desenvolver um carro, você tem designers que fazem esse carro bonito, mas só quando os engenheiros implementam esse plano e produzem um produto viável antes de você pode realmente colocar as coisas no lugar, e isso é essencialmente o que o SAS fez. Ele mesclou as decisões - processo de design de decisão e processo de engenharia de decisão, de modo que, quando você fala sobre os aceleradores, especificamente sobre os aceleradores de pontuação, você sabe, se você adota um modelo que desenvolveu e é capaz de promovê-lo para Teradata ou enviá-lo para Oracle ou Hadoop, com tempo de inatividade zero para o desenvolvimento do modelo, para implantar o modelo. Isso é fundamental, porque os modelos degradam com o tempo, a precisão desses modelos. Portanto, quanto mais tempo você leva para colocar e colocar em produção, isso é perda de precisão do modelo.
E então, a outra parte é: você deseja monitorar e gerenciar esse processo ao longo do tempo. Você deseja descontinuar os modelos quando eles ficarem antigos e imprecisos. Você quer analisar, verificar a precisão deles ao longo do tempo e reconstruí-los. E, portanto, também temos ferramentas de gerenciamento de modelo que realmente acompanham os metadados em torno do processo modelado. E as pessoas disseram que modelar, você sabe, esse tipo de conceito é como uma fábrica de modelos, ou o que você quiser chamar. O importante é colocar metadados e gerenciamento em processo e é aí que as três grandes coisas que atingimos - ajudamos as pessoas a ganhar dinheiro, economizar e mantê-las fora da cadeia.
Eric: Esse último também é bem grande. Eu estou procurando evitar tudo isso. Então, vamos falar sobre ...Estou fazendo uma pergunta final, talvez vocês dois possam dar um salto nisso. A heterogeneidade do nosso mundo só aumentará, ao que me parece. Acho que definitivamente veremos uma cristalização em ambientes de nuvem híbrida. Mas, no entanto, você verá muitos dos principais participantes. A IBM não vai a lugar nenhum. O Oracle não vai a lugar nenhum. O SAP não vai a lugar nenhum. E há muitos outros fornecedores envolvidos neste jogo.
Além disso, no lado operacional, onde você tem literalmente milhares e milhares de tipos diferentes de aplicativos. E eu ouvi - a maioria de vocês fala sobre isso, mas acho que vocês dois concordariam com o que eu venho dizendo. Vimos essa tendência agora em termos de apenas poder computacional em mecanismos analíticos, arquitetura. As empresas vêm conversando há anos sobre a possibilidade de explorar os outros mecanismos existentes e atender a uma espécie de ponto de orquestração. E eu acho, George, eu jogarei para você primeiro. Parece-me que é algo que não vai mudar. Teremos esse ambiente heterogêneo, o que significa que existem coisas como CRM em tempo real, qualidade e governança de dados. Como fornecedor, você precisará interagir com todas essas ferramentas diferentes. E é isso que os clientes vão querer. Eles não vão querer algo que faça bem com essas ferramentas e que não seja tão bom com essas ferramentas. Eles vão querer a Suíça do MDM e CRM, certo?
George: Isso mesmo. E é interessante, porque adotamos isso muito. Parte disso é a história que tivemos no espaço. E, obviamente, já estávamos trabalhando em todos os outros bancos de dados, os Teradatas e as partes do mundo. E então, você fez - no processo de implementação, especificamente da maneira que fizemos, apenas para isso - você ter essa abrangência em todos esses vários bancos de dados. Uma das coisas que acho interessante é que temos alguns clientes que estão empenhados em eliminar todos os bancos de dados relacionais. E isso é interessante. Sabe, tudo bem. É interessante. Mas não vejo isso realmente acontecendo em grande escala empresarial. Não vejo isso acontecendo há muito tempo. Então, acho que o híbrido está aqui há um bom tempo e do outro lado de nosso aplicativo, onde temos nossa plataforma de mensagens em nossa plataforma de gerenciamento de campanhas. Na verdade, nós o projetamos especificamente. Agora, lançamos uma versão que faz isso e que pode se conectar agora ao ambiente de dados híbrido e consultar o Hadoop, ou consultar qualquer banco de dados, qualquer banco de dados analítico. Então, acho que é apenas a onda do futuro. E eu concordo que a virtualização certamente desempenhará um grande papel nisso, mas estamos apenas - vamos direto aos dados de todos os nossos aplicativos.
Eric: Ok, ótimo. E, Keith, vou jogar para você. O que você acha do mundo heterogêneo que enfrentamos ao agir como uma espécie de pé?
Keith: Sim, é realmente fascinante. Acho que o que descobrimos mais - não apenas no lado das coisas de gerenciamento de dados -, mas o que é realmente fascinante agora é a natureza de código aberto da base de análise. Então, vemos organizações como, ou tecnologias como Spark, e pessoas usando Python e R e todas essas outras tecnologias de código aberto. Eu acho que poderia ser interpretado como uma espécie de conflito ou uma ameaça até certo ponto. Mas a realidade é que temos alguns elogios maravilhosos com todas essas tecnologias de código aberto. Quero dizer, por um lado, estamos operando em plataformas de código aberto, pelo amor de Deus.
Mas também, como poder integrar, por exemplo, um modelo R em um paradigma SAS, permite que você use o melhor dos dois mundos, certo? Assim, sabemos que algumas das coisas experimentais no mundo acadêmico e parte do trabalho de desenvolvimento de modelos são extraordinárias e super úteis no processo de desenvolvimento de modelos. Mas também, se você puder emparelhar isso com um tipo de ferramenta de classe de produção, ele realiza muita limpeza e qualidade, além de verificar e garantir que os dados cedidos ao modelo sejam, eles foram preparados adequadamente para que não falhem. em execução. E então, ser capaz de fazer coisas como modelos campeões desafiadores com modelos de código aberto. Essas são as coisas que estamos buscando ativar e como parte desse ecossistema realmente heterogêneo de todas essas tecnologias. Sim, então é mais - para nós, é mais sobre abraçar essas tecnologias e procurar elogios.
Eric: Bem, isso tem sido fantástico, pessoal. Ficamos um pouco mais tempo aqui, mas gostaríamos de conseguir o maior número possível de perguntas. Hoje, encaminharemos o arquivo de perguntas e respostas para nossos apresentadores. Portanto, se alguma pergunta que você fez não foi respondida, garantiremos que ela seja respondida. E pessoal, isso termina em 2014. Atenciosamente, na DM Radio amanhã e na próxima semana, e tudo está pronto e é um feriado.
Muito obrigado a todos pelo seu tempo e atenção, por acompanhar todos esses maravilhosos webcasts. Temos um ótimo ano marcado para 2015. E falaremos com vocês em breve, pessoal. Obrigado novamente. Bem cuidar. Tchau tchau.