Insider Insights sobre desenvolvimento de data warehouse moderno com James Serra

Com o Lançamento oficial de nossa solução de data warehousing de ponta a ponta Astera DW Builder, apresentamos um caminho muito mais rápido e ágil para projetar e implantar data warehouses. Mas isso é apenas o começo, estamos planejando algumas adições e atualizações importantes para o produto ao longo do próximo ano que irão agregar valor exclusivo para qualquer organização que procura contornar os problemas que vêm com o desenvolvimento de data warehouse tradicional.

Para nossa terceira entrevista nesta série, decidimos sentar com alguém que construiu sua carreira sendo capaz de identificar, antecipar e resolver com sucesso esses desafios enquanto liderava projetos de armazenamento de dados para a Microsoft e, atualmente, Ernst & Young. Como um dos principais líderes de pensamento neste espaço, James Serra abordou uma variedade de tópicos de BI e arquiteturas de dados a big data e análises em seu popular blog e em palestras em todo o mundo.

Nesta entrevista, conversamos com James sobre alguns dos insights que ele obteve durante seu tempo no setor, a evolução das arquiteturas de dados na era do big data e como será o futuro do data warehouse.

 

Você poderia me contar um pouco sobre seu envolvimento com o armazenamento de dados? Quando você começou a trabalhar neste espaço e que tipo de papel você desempenhou no processo de desenvolvimento ao longo dos anos? 

Comecei muitos, muitos anos atrás, com bancos de dados nos anos 80. O foco inicial era no Microsoft SQL Server, primeiro o SQL Server 1.0 e depois o OS 2.0 em 1989, eu acho que era. Portanto, esses eram bancos de dados mais transacionais com muitas atualizações, inserções e exclusões.

Talvez 20 anos atrás, comecei a me envolver com armazenamento de dados. Eu trabalhava como DBA em uma empresa e eles tinham a tarefa de construir um data warehouse. Na época, eu sabia muito pouco sobre a tecnologia, mas o data warehouse foi construído no SQL Server, então me envolvi no processo. Essa foi uma das minhas primeiras experiências na criação de um verdadeiro data warehouse, ou seja, puxando dados de todas essas fontes diferentes e criando relatórios de BI em cima disso.

Desde então, tive muitos empregos diferentes - fui um consultor trabalhando em muitos tipos diferentes de bancos de dados, sempre no reino da Microsoft, começando com o SQL Server e depois o Azure surgiu, depois houve o Banco de Dados SQL, o SQL Data Warehouse e agora Sinapse, que tenho usado quase exclusivamente nos últimos anos.

 

Obviamente, você tem uma vasta experiência na criação de arquiteturas de dados com a Microsoft e agora na EY. O que você diria que são os casos de uso mais comuns para armazenamento de dados? Em outras palavras, por que essas empresas desejam construir um data warehouse?

Acima de tudo, as empresas desejam tomar melhores decisões de negócios. Para fazer isso, eles precisam ter todos os dados possíveis. Portanto, em vez de tentar acessar cada um de seus bancos de dados operacionais individualmente e criar relatórios, eles podem obter mais valor se juntarem todos os dados.  

Por exemplo, digamos que eles tenham informações do cliente armazenadas em um sistema CRM, depois tenham informações de suporte ao cliente armazenadas separadamente em outro sistema, outra plataforma para gerenciar informações de vendas e algum sistema ERP que também contenha informações do cliente. Eles têm esses dados armazenados separadamente e, é claro, desejam coletá-los e usá-los para identificar tendências históricas para que possam encontrar razões para coisas como o fato de os clientes não estarem comprando em certas áreas do país. Com um data warehouse, eles podem entrar, cavar mais fundo e descobrir o que está acontecendo.

Mais recentemente, não se trata apenas de tendências históricas, mas também de olhar para o futuro. É aqui que a IA e o aprendizado de máquina entram. Hoje, as empresas não querem apenas ver onde já estiveram, mas também para onde estão indo , é por isso que a análise preditiva está se tornando um grande sucesso. Portanto, se pegarmos as informações do cliente anteriores e dissermos que queremos usá-las, preveja as chances de um cliente sair. Um modelo de aprendizado de máquina pode ser capaz de estimar 70% de chance de o cliente sair com base em todos os dados coletados. Agora, você, como tomador de decisões, pode tomar medidas proativas e fazer algo para evitar isso, como enviar um cupom para garantir sua fidelidade.  

Fundamentalmente, é realmente a coleta de todos esses dados que permite que o usuário final / analista gere relatórios e, em seguida, divida e divida os resultados para permitir as melhores decisões de negócios.

 

Obviamente, vimos um aumento bastante significativo no volume e na variedade de dados que circulam pelas empresas na última década. Como você vê o chamado data warehouse tradicional evoluindo para lidar com esses requisitos?

Então, em primeiro lugar, eu definiria big data não apenas como o tamanho dos dados, mas o tipo e a velocidade dos dados. Muitos clientes com os quais trabalhei estão lidando com terabytes de dados que estão tentando consumir. Mas eles também têm o desafio de lidar com dados em todos os tipos de formatos, incluindo Parquet, CSV, JSON, bem como dados que podem querer consumir em tempo real de feeds de mídia social como o Twitter, eles também podem querer extrair alguns dados de IoT lá.

Agora, você tem o desafio de todos os tipos de três velocidades e tamanhos de dados. Embora tenham surgido na última meia dúzia de anos ou mais sistemas que podem lidar com big data como o Azure Synapse na plataforma Microsoft, por exemplo, ainda há uma série de outras ferramentas necessárias para construir um data warehouse moderno. Essas ferramentas lidam com a variedade, o volume e o tamanho dos dados. Hoje em dia, eles podem manipular qualquer combinação de dados, extraí-los, ajustá-los, limpá-los e controlá-los antes de gerar relatórios.

 

Qual é a sua opinião sobre o data lake? Ele tem um lugar no sistema de BI moderno? Complementa o data warehouse ou é uma alternativa viável?

Eles são definitivamente complementares. Quando os data lakes começaram a ser usados ​​há cerca de dez anos, eles estavam no Hadoop e a ideia por trás deles era que não podíamos capturar big data de forma eficaz devido ao seu tamanho, dados semiestruturados ou não relacionais também não realmente se encaixam bem em um banco de dados relacional. Portanto, decidimos colocá-lo no data lake e consultá-lo lá. Essa se tornou a zona de aterrissagem para todos os tipos de dados não relacionais, enquanto os dados relacionais ainda eram armazenados em um banco de dados.

Obviamente, a maioria das organizações deseja combinar os dois tipos de dados, portanto, os dados não relacionais / semiestruturados no data lake precisam ser movidos para o banco de dados. Embora, no início, houvesse tentativas de colocar tudo no data lake, o que levou a uma série de problemas.

Então, o resultado disso é que percebemos que sempre precisaríamos de um banco de dados relacional. Com o tempo, esse pensamento evoluiu e agora entendemos que você precisa ter um data lake ao lado do banco de dados relacional e que cada um tem seus próprios pontos fortes.

Podemos ver um data lake como sendo capaz de manipular dados, não importa o tamanho ou o tipo, mas ele tem algumas limitações. O data lake não é bom para consultas extremamente rápidas, não é ótimo para os tipos de segurança que você deseja de sua arquitetura de dados - como segurança de baixo nível ou segurança de nível de coluna, também pode ser mais difícil para o seu fim médio. usuário pode consultar dados em um data lake porque é schema-on-read, o que significa que é apenas uma pasta de arquivos glorificada, você pode colocar qualquer tipo de dados lá e isso pode tornar difícil tentar retirá-los se você não fizer isso t ter as habilidades técnicas necessárias. É aí que um banco de dados relacional entra em ação, porque alguém na TI fará o trabalho de colocar os dados junto com os metadados, então fica muito mais fácil para o usuário final consultá-los. Portanto, se você for de um data lake para um banco de dados relacional e de 3NF para um esquema em estrela, os usuários finais podem agora realizar BI de autoatendimento, porque podem simplesmente arrastar campos do banco de dados e criar relatórios ou consultas a partir dele.

Agora, ferramentas como o Azure Synapse vieram e tornaram muito mais fácil consultar dados, seja em um data lake ou em um banco de dados relacional com SQL regular, e ambos têm seus prós e contras. No final das contas, a ideia é pegar dados de todas essas fontes, movê-los e fazer algum trabalho para prepará-los, o que pode envolver custos extras, mas no final, você obterá dados formatados de uma forma que seja muito mais fácil para a maioria dos usuários finais. Enquanto isso, você ainda pode ter o data lake para cientistas de dados e usuários avançados consultar, mas para a maioria dos usuários, você vai querer ter um banco de dados relacional disponível.  

 

Qual seria o aspecto mais crítico para o desenvolvimento do data warehouse? É a modelagem de dados? Carregando dados para o data warehouse? Garantindo que o data warehouse esteja acessível para suas plataformas de BI?

Todos esses aspectos são extremamente importantes, mas a governança de dados é realmente o principal thread em toda a construção de um data warehouse. Isso é para garantir que os dados sejam precisos, corretos e constituam uma única fonte da verdade para a organização. Porque a pior coisa que pode acontecer é que você faça todo esse trabalho para construir um data warehouse e gerar um relatório, então, na primeira vez que um usuário final vê, ele diz que os dados não são precisos ou estão incorretos. Imediatamente, você perdeu a confiança deles no sistema. Portanto, você realmente precisa ter certeza de que os dados são administrados de maneira adequada. Isso significa limpá-los e controlá-los adequadamente e todas as coisas que vêm junto com a governança de dados.

Quase tão importante, senão mais, é a segurança. Hoje em dia, existem tantas informações de identificação pessoal que poderiam chegar a um data warehouse, e se você não tiver o tipo certo de segurança lá, as pessoas podem começar a ver dados que não deveriam. Podem ser informações pessoais, números de vendas ou outras coisas que podem causar muitos problemas, especialmente se esses dados forem extraídos de sua empresa. Agora você está na primeira página do Wall Street Journal com uma violação. Então essa é a outra grande coisa é a segurança. Portanto, eu diria que esses dois devem ser os principais em sua mente ao construir um data warehouse.

Nos últimos anos, houve um grande impulso para começar a mover data warehouses para a nuvem em plataformas como Azure Synapse, Google BigQuery ou Amazon Redshift. Qual é a sua opinião sobre as vantagens da implantação da nuvem? Você ainda recomendaria manter os bancos de dados locais em alguns casos?

Tenho dificuldade em ver uma solução que deva estar no local, mas existem casos muito raros em que essa seja uma solução viável. Costumava ser, na Microsoft, por exemplo, quando entrei pela primeira vez 7 anos atrás, onde eu tinha muitas conversas sobre nuvem vs. local, mas nos últimos anos tem sido extremamente raro alguém querer falar sobre o último como uma opção possível.

As raras exceções são se a empresa estiver em um local que não tenha acesso à Internet, como, por exemplo, uma mina ou uma plataforma no mar. Ou se eles estão lidando com dados que precisam de tempos de resposta de milissegundos quando se trata de consultas e coisas assim, porque pode haver um pouco de latência para a nuvem. Mas fora disso, todo mundo tem, está ou vai para a nuvem por vários motivos sobre os quais eu poderia passar meia hora falando.

É importante notar que o custo nem sempre está na vanguarda dessa mudança, são outras coisas, como ter os recursos mais recentes de um produto, ou provavelmente o maior benefício que é a capacidade de começar a trabalhar rapidamente. Com um data warehouse na nuvem, posso ir para o Azure, por exemplo, e ter um banco de dados pronto em minutos, enquanto no local pode levar dias, senão semanas, senão meses para obter um banco de dados em um servidor. Portanto, não me lembro da última vez que conheci um cliente que também recomendei no local. Claro, pode haver alguns casos de uso como mencionei acima, mas esses são poucos e distantes entre si.

 

Então, eu vi você escrever um pouco sobre Reverse ETL nos últimos anos. Se você pudesse apenas resumir o conceito e falar um pouco sobre os benefícios que você acha que essa abordagem traz?

Sim, este é um conceito muito novo. Portanto, algumas empresas podem ter dados de clientes em uma dúzia de sistemas de origem diferentes, especialmente se for uma grande empresa. Digamos que eles puxem todos esses dados do cliente, os limpem e os dominem (ou seja, criando registros dourados) porque pode haver várias cópias do cliente com grafias diferentes. Eles também podem complementar os dados do cliente de um sistema com diferentes tipos de dados de outros sistemas, como obter dados do cliente de um sistema CRM e adicionar informações de tíquete de suporte dos clientes.

Então, vamos supor que todos esses dados estejam agora no data warehouse e eu tenha feito todo esse trabalho para criar uma visão unificada do cliente. Bem, agora, o problema é que a limpeza foi feita no nível do data warehouse, mas os sistemas de origem de onde os dados foram retirados ainda não foram limpos. Com o ETL reverso, a ideia é que agora posso canalizar os dados do data warehouse de volta para o sistema de origem e corrigir os registros do cliente. Esse é um dos motivos pelos quais vejo o ETL reverso se tornar algo popular, porque você está fazendo todo esse trabalho no data warehouse que pode ser aplicado aos sistemas de origem para corrigi-los.

O outro grande benefício do ETL reverso é que se eu puxar todos esses dados para um data warehouse e criar relatórios de BI sobre isso e dizer que é um visão do cliente, bem, posso ter muitos vendedores que estão acostumados com esses outros sistemas operacionais, ou seja, um sistema de CRM em que eles já examinam os dados dos clientes e que já gostam de usar. Agora, você está pedindo a eles que vão a um data warehouse e usem um sistema diferente, um relatório diferente, para ver os mesmos clientes. Então, por que não reverter o ETL e pegar esses dados do data warehouse e copiá-los para o sistema operacional. Os analistas podem então usar os dados no sistema com o qual estão mais familiarizados. Portanto, eles não precisam ir para o data warehouse.

Esta é outra área em que vejo o ETL reverso ser muito popular. Faça o trabalho em um data warehouse, mas depois coloque os dados em um sistema operacional onde os usuários finais se sintam mais confortáveis.

 

Se você estivesse procurando uma solução de armazenamento de dados para um cliente, quais seriam alguns dos principais recursos que você gostaria que ela tivesse?

Usei várias ferramentas de automação de data warehouse ao longo dos anos, com vários níveis de sucesso. Alguns deles têm sido realmente úteis, mas os que considero mais eficazes são aqueles que não são muito proprietários e podem fornecer automação que torna a construção de soluções mais rápida, é aí que eles podem ser extremamente valiosos.

Quando você pondera a questão de Build vs Buy de iniciar projetos completamente do zero, eu sempre recomendo primeiro procurar por algo que já foi construído e ver se isso o ajudará. Agora, isso poderia ser um modelo de dados comum ou uma ferramenta para automação de data warehouse que construirá rapidamente o data warehouse para você. Se a solução puder fazer isso usando tecnologia comum, ou seja, se essa ferramenta de automação criar um data warehouse para você, você ainda poderá usar o data warehouse sem ser forçado a usar a ferramenta de terceiros, então você está no caminho certo.

Por exemplo, a solução de automação de data warehouse pode fazer interface com um software ETL específico para criar pipelines e, depois de criar esses pipelines, você mesmo pode atualizá-los sem passar pela ferramenta DWA. Agora, digamos que ele esteja usando um produto Microsoft para essa tarefa, a ferramenta DWA pode não acompanhar as atualizações do produto ETL, então digamos que o software obtenha novos recursos, então a ferramenta de armazenamento de dados pode levar algum tempo para aproveitar esses recursos que, é claro limita a funcionalidade de sua solução. Há também a questão dos conjuntos de habilidades. Se você estiver usando uma ferramenta de automação de data warehouse em sua empresa, talvez seja necessário contratar pessoas que já tenham essa experiência em ferramentas de terceiros para levar o projeto adiante.

No geral, acho que as ferramentas de DWA são especialmente úteis para empresas que são novas em data warehousing e não têm as melhores práticas ou padrões, e também não têm uma grande equipe para construir sua própria configuração. Eles podem ir e obter alguns resultados rápidos e uma espécie de atalho do processo usando uma ferramenta pronta para acelerar o desenvolvimento.

 

O que você acha do conceito de data warehouse ágil? Basicamente, essa ideia de que o data warehouse é um processo, não um objetivo final, e que a iteração está no centro de qualquer sistema de BI eficaz?

Quando eu estava na Microsoft, os clientes geralmente viam isso como uma tecnologia, as pessoas e o lado do processo eram algo que eles procuravam lidar com eles próprios. Claro, é importante ter todos esses elementos no lugar. Quer falemos sobre a criação de um centro de excelência para governança de dados, quer falemos sobre DataOps. Como construir um aplicativo é muito diferente de construir um data warehouse, é por isso que faço a distinção entre DevOps e DataOps.

Em um data warehouse, você está lidando com muitos sistemas. Você poderia ser atualizando um modelo em um data warehouse, para um pipeline de ETL, para relatórios. Portanto, todas essas coisas devem ser coordenadas e é aí que o DataOps entra em jogo e isso é extremamente importante. Vejo muitas empresas, e a EY é uma delas em particular, que têm esse gigantesco data warehouse construído e precisam seguir um tipo de processo DataOps para garantir que o produto seja usado tanto internamente quanto fora da empresa , também que ele não quebra sempre que um novo recurso ou correção de bug é colocado nele.

Portanto, as pessoas e os processos às vezes são a parte mais difícil, enquanto a tecnologia pode ser relativamente fácil. Portanto, você precisa ter certeza de ter todos esses elementos no lugar para garantir que a solução final seja o mais livre de bugs possível e fornecer, como mencionei antes, precisão nos dados.

Finalmente, para onde você vê o data warehouse se dirigindo no futuro? Que grandes avanços (se houver) você prevê neste espaço?

Bem, tocando nisso - acho que haverá um foco muito maior na IA e na parte do aprendizado de máquina em particular. O desafio quando você está construindo um data warehouse é coletar dados, limpá-los e, em seguida, colocá-los em algum lugar, seja um data lake ou banco de dados relacional. Para os clientes, a coleta de todos esses dados pode levar meses, senão anos. E a cereja do bolo torna-se o relato disso, onde você está usando algo como o PowerBI para fatiar e dividir conjuntos de dados. No momento, é onde muitos clientes ainda estão, no processo de coleta de seus dados.

A maior parte do trabalho neste espaço segue uma abordagem híbrida porque muitas empresas têm fontes de dados na nuvem, mas muitos sistemas ainda estão no local e precisam puxar todos eles para a nuvem, que tem seus próprios desafios . Depois de coletar todos os dados, você pode fazer um relatório deles e obter algumas soluções muito rapidamente.

A próxima etapa é fazer aprendizado de máquina e criar modelos que podem ser treinados usando os dados na nuvem. Muitos clientes ainda não chegaram lá, eles ainda estão no estágio de coleta tentando obter dados no data warehouse. Portanto, o grande impulso será os clientes verem os benefícios dos modelos de ML na criação de análises preditivas para coisas como rotatividade de clientes ou quando uma peça vai falhar (os dados do dispositivo IoT se tornaram muito populares para esse tipo de manutenção preditiva). Mas, novamente, é um salto muito grande para chegar lá, porque você precisará de cientistas de dados e dos produtos necessários. Claro, as soluções percorreram um longo caminho com o aprendizado de máquina automatizado para tornar essa parte mais fácil, mas lixo no lixo ainda se aplica - você ainda precisa de alguém que entenda os conceitos de ciência de dados lá.

Então, acho que nos próximos 2 anos, você verá uma grande quantidade de trabalho realizado para construir esses modelos de aprendizado de máquina para obter ainda mais valor dos dados do que dos relatórios históricos.

Uma solução ponta a ponta para o desenvolvimento de data warehouse moderno

Astera O DW Builder oferece uma plataforma unificada que os usuários podem aproveitar para agilizar todos os aspectos de seu processo de desenvolvimento, desde a coleta inicial, limpeza de dados até a criação de modelos de dados prontos para relatórios que são adequados aos seus requisitos de governança de dados e, claro, a implantação do seu data warehouse na nuvem.

Com o ADWB, você não precisa depender de uma pilha de tecnologia complexa ou de recursos técnicos experientes para levar sua implementação aos limites. O produto oferece uma interface intuitiva de arrastar e soltar, suporta iteração rápida e funciona igualmente bem com uma variedade de sistemas de origem e destino. Entre em contato com nossa equipe para começar com Astera DW Builder hoje.