Sessão de perguntas e respostas ao vivo com James Serra sobre automação do design de data warehouse

Lançamos nossa plataforma de automação de data warehouse (DWA) de última geração, Astera Construtor de DW que acelera e simplifica o desenvolvimento do data warehouse. É uma solução orientada por metadados unificada que permite às organizações projetar, desenvolver e implantar data warehouses de nível empresarial em poucos dias.

Recentemente, hospedamos um webinar onde tivemos a oportunidade de nos conectar com James Serra. James é um renomado líder de pensamento no uso e aplicação de Big Data e análises avançadas. Ele atualmente trabalha para a EY como líder de arquitetura de plataforma de dados e anteriormente trabalhou na Microsoft por sete anos como arquiteto de soluções especializado em big data e data warehouse.

Em nossa última discussão, conversamos com James para obter alguns insights sobre desenvolvimento de data warehouse moderno. Nesta sessão de perguntas e respostas ao vivo, investigamos o conceito de automação do design do data warehouse.

O que você acha do conceito de modelo de dados corporativos? Você acha que é hora de partir dessa ideia de preparar todos os seus requisitos antecipadamente e passar para um ciclo de desenvolvimento? Se não, como você mudaria dessa abordagem para um estilo mais iterativo de armazenamento de dados?

Acho que a maioria dos clientes mudou desse tipo de abordagem em cascata, onde passam muito tempo reunindo requisitos. Eles mudaram para um tipo de desenvolvimento ágil em cascata, e muito disso tem a ver com as ferramentas que surgiram recentemente. Se você olhar para algo como ferramentas de business intelligence, descobri que os clientes agora estão usando essa ferramenta para definir os requisitos de negócios, em vez de alguém da TI ir até um cliente dizendo: “Ok, qual é o seu requisito? Vamos derrubar, vamos construir alguma coisa ”, volte e descubra que está errado, e continue esse ciclo. Eles agora dizem: “Ei, vá usar o protótipo e vamos usá-lo como requisitos de negócios”.

As modernas ferramentas de relatórios ETL permitem que você crie protótipos e crie esses requisitos facilmente. E se não, geralmente é “Ei, precisamos de uma vitória rápida. Vamos começar a construir algo e mostrar o valor do que construímos e deixar as pessoas e os usuários finais entusiasmados. ” Muito tempo, [ajuda] desbloqueia orçamentos, e então você também está trazendo esses usuários finais logo no início, então você sente que eles fazem parte do que você está construindo lá, e então eles podem conseguir algo de valor, então você escolhe algo que pode fazer no curto prazo e que tem muito valor, e então você sai com isso.

Agora, eu sempre digo que você quer manter seu objetivo final em mente. É como construir uma cidade que você vai dividir em cidades. Você pode criar um projeto para esta cidade com todas as cidades de lá. Então você vai, constrói uma cidade e constrói uma em cima da outra. Você não vai construir a coisa toda e abri-la lá.

Portanto, você [deve] ter uma visão de longo prazo de onde quer chegar, mas você obtém ganhos rápidos desde o início.         

O que você acha dos cofres de dados? Você acha que isso vai ultrapassar a modelagem dimensional tão logo seja a técnica preferida, ou tudo tem seu lugar? 

Direi que não há como o cofre de dados assumir o controle da modelagem dimensional. Ele existe há mais de 20 anos e tem um ótimo caso de uso. Eu encontro clientes que precisam fazer muito rastreamento histórico e auditoria usando o cofre de dados, mas não há muitos daqueles casos de uso que exigem algo tão, digamos, sofisticado quanto o cofre de dados lá.

Então, acho que tem o seu lugar. Mas vejo 99 por cento dos clientes usando um tipo de esquema em estrela junto com uma terceira forma normal ali, e muito disso depende [se] você obtém o desempenho de que precisa em uma terceira forma normal. Se eu entrar em uma dúzia ou mais de mesas, posso conseguir esse desempenho e irei para um esquema em estrela. É uma camada extra de detalhes, mas você obtém muitos benefícios por ter essa camada extra lá.

Além disso, ajuda quando você está analisando o BI de autoatendimento. Se eu não tiver um esquema em estrela, devo saber a relação entre todas essas tabelas, o que pode ser muito difícil para o usuário final. Normalmente, você tem uma pessoa na empresa que sabe juntar tudo e depende dessa pessoa.

Em vez disso, você cria esse esquema em estrela e, em seguida, ele se torna um BI autosserviço. Eu poderia simplesmente ir para uma ferramenta de relatório e simplesmente arrastar os campos para o formulário e criá-lo sem ter que entender como os relacionamentos funcionam por causa do esquema em estrela. Então, isso dá a você, então há um grande motivo para o esquema em estrela, e eu diria que provavelmente 75 por cento das empresas que vejo usarão um esquema em estrela em cima de uma terceira forma normal.

Falando um pouco sobre essa perspectiva de modelagem dimensional de modelagem de dados, qual você acha que é o papel que os metadados têm de desempenhar? Você acha que uma estrutura orientada por metadados pode beneficiar o design do data warehouse? E se sim, como?   

Tenho visto um grande esforço ultimamente na criação de catálogos de dados para clientes. A ideia por trás disso é que eles estão coletando muitos dados e você deseja evitar a duplicação de dados.

Estamos fazendo isso na EY em grande escala porque eles estão trazendo todos esses dados de terceiros. Pode custar literalmente dezenas de milhões de dólares de terceiros, e você não quer que alguém saia e obtenha uma licença porque não percebeu que os dados já estavam lá.

Então, vamos criar um catálogo de metadados e vamos criar uma ferramenta de descoberta de dados em um mercado onde qualquer usuário final pode dizer, “Ei, eu preciso criar algo usando este tipo específico de dados. Eu me pergunto se nós temos isso. Vamos ao catálogo e ver se ele está lá. ” Nós [agora] podemos obter acesso instantâneo a esses dados e evitar a duplicação.

Além disso, uma grande novidade com os clientes é a linhagem. “Consegui esse valor n neste cálculo. Como chegamos lá? De onde veio isso aí? Quero ter certeza de que está certo. ” Então, eles voltam e olham. A linhagem de metadados é importante quando você deseja ter certeza de que está construindo um esquema e que o esquema também é metadado.

Então, isso é outra coisa que eu acho que você vai começar a ver com um empurrão de pessoas catalogando não apenas os dados, mas os conjuntos de dados. Acho que você verá que mais integração com catálogos de dados é “Ei, é só que pode ser legal o suficiente para que eu possa ver que temos dados de clientes e dados de produtos, mas talvez alguém já tenha construído esse conjunto de dados. Talvez alguém já tenha construído um relatório e painel sobre isso, e posso ir e usá-lo rapidamente em vez de reinventar a roda. ”

Então, metadados são tão importantes agora e sem eles, quando temos essa proliferação de dados e - em alguns casos - temos dados em um data lake que não tem seus próprios metadados dentro dele, [então] temos que criar que [metadados]. Então, você precisa desse produto, uma solução que vai combinar tudo isso, de modo que torne muito mais fácil para as pessoas descobrirem os dados.

Estamos obviamente vivendo na era do big data. Como você acha que a explosão na variedade de volume e velocidade impactou o arco de dados?

Sim. É mais desafiador porque agora você precisa pensar no tamanho dos dados. E [por exemplo,] eu tenho que criar um modelo, ele pode não funcionar se eu não fizer isso corretamente. Portanto, ele adiciona muito mais importância para garantir que o design esteja correto. E também, a governança de dados é uma grande parte disso.

[Suponha que] os dados entrem em um modelo. Como posso ter certeza de que ele está limpo e estou juntando os dados corretamente? O maior motivo que vejo para o fracasso de projetos de big data warehouse não é o tempo suficiente em governança de dados.

Eles vêm com um conjunto de dados e você apenas diz: “Ótimo, vou usar este conjunto de dados” e, em seguida, “Espere um minuto! Esses dados estão errados. ” Se essa é sua primeira impressão, você perdeu a confiança logo no início. Eles não vão confiar em nada que você apareça, então você tem que gastar muito tempo antes de validar esses dados, certificando-se de que o conjunto de dados está correto.

Traga os usuários logo no início, diga a eles que você está testando essas coisas e certifique-se de que é válido. É uma maneira de fazer isso. Mas é extremamente importante ganhar a confiança deles ao desenvolver essas soluções, portanto, certifique-se de ter tempo suficiente para a governança de dados.

O que você acha da afirmação de que um modelo robusto de esquema de data warehouse verificado é igual a uma arquitetura geral de data warehouse de alta qualidade?

Eu concordaria com isso. Novamente, se a governança de dados estiver em vigor, isso envolve mais do que apenas tecnologia, e eu tive muitas discussões com clientes [sobre como] você [pode] ter a melhor tecnologia do mundo, mas você realmente precisa para ter as pessoas e o processo no lugar.

Precisamos dessa governança de dados, talvez um centro de excelência, reuniões para decidir quem é o proprietário dos dados e um processo de verificação para limpar os dados. Se limparmos os dados e os data warehouses, também os levaremos de volta ao sistema de origem - todas essas coisas precisam ser discutidas lá.

Então, é tão importante ter as pessoas certas e as habilidades certas, o que é muito desafiador, especialmente agora que vimos recentemente uma escassez de talentos lá e encontrar pessoas com essas habilidades é um desafio, mas há exemplos suficientes lá você pode ir e ver como as pessoas configuram suas empresas e seus grupos e as pessoas no processo para esse tipo de solução que estamos construindo e tentar seguir essas melhores práticas.

Dada a tecnologia MPP e armazenamento colunar, você vê uma tendência de usar o modelo OBT de uma grande tabela para relatórios e análises em cima de um modelo dimensional?

Bem, um MPP, para aqueles que não sabem, isso é processamento paralelo múltiplo. Então, a ideia é que eu posso fazer consultas que podem levar horas para rodar como um SMP [Symmetric Multi-Processing] ou uma solução típica e colocá-lo no sistema MPP, e ele vai rodar de 20 a 100 vezes mais rápido lá. Ele poderia fazer isso com a terceira tabela de forma normal. Ele pode fazer isso ainda melhor com um esquema em estrela, mas tenho visto resultados tremendos para muitos dados, mesmo com muitas junções diferentes.

Então, a coisa boa sobre a tecnologia MPP é que você não precisa ir a extremos para desnormalizar esses dados. Minha conclusão é que você quase sempre deseja ir para o esquema em estrela por vários motivos, e a ideia de que precisa desta grande mesa, você não precisa - com a tecnologia MPP - na maioria dos casos.

Alguns produtos de terceiros exigiam que você fizesse isso - ou, sob a cobertura, estamos fazendo isso - por causa dos problemas de desempenho. Mas, como a tecnologia avançou muito, é raro encontrar um cliente que se esforce tanto para criar uma mesa grande. Em vez disso, eles usam o esquema em estrela.

Que papel a automação realmente deve desempenhar? E que tipo de vantagens você acha que as empresas podem ver com o uso de uma solução desenvolvida especificamente para conduzir sua verificação de modelagem de dados e outros processos?

Eu adoro atalhos. Então, quando conversei com os clientes, foi: “Bem, espere um minuto aqui! Do que você está falando… acho que provavelmente você poderia usar algumas ferramentas de automação e produtos de terceiros aqui. Sim, há uma despesa extra, mas a economia de tempo e a precisão que você pode obter podem valer a pena, então sim, eu sou totalmente a favor dessas ferramentas de terceiros.

Claro, existem compensações. Você tem que obter o conjunto de habilidades, então, se você não sabe, tem que aprender. E é uma ferramenta de automação que requer essa ferramenta de automação o tempo todo ou está apenas criando o código que você pode pegar e usar? Porque se você sempre tiver que usar essa ferramenta, pode haver alguns desafios com ela.

Como o produto, é baseado em atualizações de seus recursos, [o software de automação de data warehouse [tem] que atualizá-lo também, ou talvez você não consiga usar todos os recursos. Então, você tem que olhar bem de perto. Mas existem tantas ferramentas boas por aí agora que atalho esse processo que fornece a automação.

Especialmente na maioria dos casos, o que os clientes estão construindo não é tão diferente do que milhares de outros clientes construíram. Então, sim, existe uma ferramenta de automação para isso. É muito raro você estar construindo algo tão único ou em tal escala que uma ferramenta de terceiros não ajudaria.

Ainda mais, se você estiver em algum setor popular como saúde, finanças, bancos ou varejo - todos eles têm cenários muito repetíveis para os quais você pode usar uma ferramenta de automação.

Há alguma palavra de despedida que você queira nos deixar?

Eu sempre digo, se você nunca trilhou esse caminho antes e está construindo uma solução real, chame alguns especialistas, encontre algumas pessoas. Novamente, é difícil encontrar o talento agora, mas encontre alguma empresa de consultoria ou uma empresa terceirizada que já tenha trilhado esse caminho antes, no início do processo.

Porque isso é o que eu faço, em minha função na EY como líder de arquitetura [eu sei] que você precisa tomar algumas decisões realmente importantes no início e se você tomar essas decisões erradas no futuro, pode acabar custando muito tempo e dinheiro.

Portanto, encontre pessoas que possam ajudá-lo a tomar as decisões corretas desde o início, porque todos os projetos que vi falharam - pode ser [por] uma peça, pessoas ou processo - é raro que a tecnologia seja ruim. É que você escolheu a tecnologia errada. Você queria algum banco de dados relacional e tenta fazê-lo funcionar onde uma solução NoSQL, por exemplo, seria muito melhor.

Portanto, obtenha muita ajuda desde o início para tomar essas grandes decisões importantes e entenda o que está por vir na estrada, no futuro e os mapas de muitos produtos. Se você estiver usando um produto específico, certifique-se de saber o que está em desenvolvimento nos próximos três a seis meses.

Esses projetos levam muito tempo para serem construídos e você não quer chegar em alguns meses, e também outras empresas dizem: "Temos este novo produto e um novo recurso", e você diz: "Oh, deveria nós sabemos sobre isso? ” e digo isso porque muito do meu papel no meu trabalho era garantir que as pessoas fossem informadas sobre o que estava por vir.

Porque os projetos de data warehouse são caminhos longos, e leva seis meses ou anos para que você os construa. Nunca acaba, na verdade, mas muitas dessas grandes decisões vão acontecer logo no início, e você precisa conhecer esse roteiro, então essas seriam minhas palavras de despedida.

Automatizando o Design de Data Warehouse usando Astera Construtor de DW

Astera O DW Builder é uma solução de data warehouse automatizada de ponta a ponta que permite às empresas ir desde a origem até os insights na velocidade da luz. A plataforma ágil orientada por metadados permite que as empresas integrem dados dispersos em um sistema de BI ágil e criem um gateway centralizado para realizar análises em escala corporativa.

Astera O DW Builder oferece um ambiente de desenvolvimento integrado de código zero para construir seu data warehouse em um nível lógico. A solução fornece um ambiente de desenvolvimento integrado que automatiza todas as tarefas padrão de modelagem de dados até a implantação de seu data warehouse. Para um teste inicial de Astera Construtor DW, clique aqui.