Perguntas e respostas com Barry Devlin sobre pipelines de dados automatizados

Os pipelines de dados automatizados são uma peça crucial do quebra-cabeça do data warehouse. Eles permitem que as empresas modernas mantenham dados precisos e de alta qualidade que alimentam suas iniciativas de BI e análises. Recentemente lançamos Astera DW Builder, um construtor de data warehouse robusto que acelera radicalmente a construção, orquestração e gerenciamento de pipelines de dados para permitir decisões mais rápidas baseadas em dados.

Astera Os pipelines de dados autorreguláveis ​​do DW Builder permitem que você preencha perfeitamente o seu data warehouse com dados de toda a empresa. Usando as funcionalidades automatizadas de ETL e ELT do produto, você pode cobrir a jornada de dados desde a origem até os insights com o mínimo de esforço manual.

Recentemente, tivemos a oportunidade de conversar com Barry Devlin, uma autoridade máxima em todos os aspectos de armazenamento de dados, desde as melhores práticas de inteligência de negócios até big data e muito mais. Aqui estão alguns dos insights que Barry forneceu sobre as principais considerações para pipelining de dados no EDW moderno.

Os armazéns de dados modernos processam grandes volumes de dados. Quando se trata de construir pipelines de dados que podem fornecer ativamente essas grandes quantidades de dados, há alguma prática recomendada que você recomende?

Bem, antes de falar sobre as melhores práticas, gostaria de fazer uma boa prática antecipadamente que é definir e elaborar algumas das frases que usaremos aqui. [Isso] porque, no momento, existem muitos significados diferentes para palavras e frases-chave no mercado.

Então, primeiro, pipelines de dados, muitas pessoas usam essa frase para significar um caminho integrado completo desde os dados de origem até as ferramentas usadas pelo empresário. Vejo que o uso do termo é menos focado naquele caminho completo da sopa para nozes, mas sim na possibilidade de um pipeline mais curto entre, digamos, diferentes componentes como uma instância SAP e um fluxo de cliques de um site para um data warehouse empresarial. Acredito que essa é uma abordagem melhor e com mais chances de sucesso.  

Em segundo lugar, há a questão do que queremos dizer quando falamos de data warehouse. Porque existem muitas abordagens contrastantes. Então, na maioria dos casos, quando digo data warehouse, quero dizer uma estrutura de duas camadas que consiste em um data warehouse empresarial, um EDW e uma forma normal vagamente terceira - ou mais provavelmente hoje, modelo de cofre de dados - alimentando vários data marts, muitos dos quais podem ser de natureza dimensional. E isso não exclui outras estruturas, a maioria das quais é uma simplificação dessa abordagem de duas camadas.

Finalmente, usarei a frase "preparação de dados ou informações" para cobrir todos os tipos de processamento, como ETL, ELT, streaming, automação de data warehouse e até virtualização de dados, porque todos esses últimos termos são instâncias específicas de preparação de dados e informações ou o abordagens técnicas para isso.

Tendo dito isso desde o início, deixe-me falar sobre as melhores práticas sobre as quais você me perguntou e vou me limitar a três, mas há muitas mais.

Portanto, em primeiro lugar, eu diria ferramentas e automação abrangentes e fáceis de usar - e isso é bastante óbvio. A preparação de dados [preparação] é a parte mais cara de um data warehouse. Portanto, formar equipes de programadores para construir várias soluções sob medida, inconsistentes e impossíveis de manter, é, ou deveria ser, uma coisa do passado. Esse é o ponto um.

A segunda melhor prática é: acertar a fase de design envolvendo o negócio de forma próxima e contínua no processo. Isso significa iterativo, abordagens de desenvolvimento ágil [isto é] menos na entrega de aplicativos de negócios, mas mais na entrega de partes úteis do escopo de informações do data warehouse.

E em terceiro lugar, eu diria gerenciamento de manutenção e mudança. Essas são características-chave que muitas vezes são negligenciadas. Portanto, concentre-se em garantir que as atualizações e a manutenção sejam consideradas antecipadamente e coloque em prática um processo que esteja intimamente ligado ao design e construção iniciais.

Portanto, voltando ao meu primeiro ponto, ferramentas e automação desempenham um papel central em fazer isso acontecer. Portanto, existem três práticas recomendadas que considero muito importantes nesta área.

Desenvolva e implemente data warehouses de alto volume

Tente agora!

ETL tem sido sinônimo de armazenamento de dados desde o início da tecnologia. Como esse processo evoluiu na era dos chamados big data que temos agora? Que tipo de inovação você está vendo que pode reduzir o custo e a complexidade do ETL tradicional?

Acredito que sempre temos que aprender com a história. A preparação de dados, em minha opinião, tem evoluído aos trancos e barrancos, com frequentes retrocessos. Por exemplo, recentemente os lagos de dados iniciais e o data warehouse baseado em nuvem foram frequentemente preenchidos por meio de scripts e soluções programáticas semelhantes no Hadoop. Isso foi uma grande decepção para mim.

É bom ver agora um novo foco nas ferramentas automatizadas. A tendência de longo prazo tem sido amplamente de soluções feitas à mão e sob medida para o uso de ETL - e mais recentemente de ferramentas ELT. Isso foi complementado por uma mudança da entrega em lote de dados para uma variedade de abordagens de entrega incremental à medida que os volumes de dados aumentam e os negócios exigem cada vez mais informações oportunas.

Antigamente, o ETL era composto por sistemas operacionais, muitas vezes antiquados em termos de design, com muitos códigos misteriosos. Compreender as complexidades, bem como as regras de negócios profundas que eram obsoletas, mas ainda estavam no sistema, era um requisito fundamental para um programador de ETL.

E então havia a demanda absoluta para limitar o impacto sobre os sistemas operacionais, [em termos de] seu design e desempenho. Os engenheiros de ETL precisavam ser profundamente especialistas nas misteriosas estruturas e no conteúdo desses sistemas de origem legados.

A boa notícia agora é que os sistemas operacionais costumam ser mais bem projetados, mais modernos e, às vezes, baseados na nuvem. Portanto, há menos necessidade de lidar com sistemas misteriosos e mais foco em design inovador e sistemas de destino. Claro, [isso] reduz os custos e a complexidade da preparação de dados.

No entanto, fontes de dados externas, como a Internet das coisas (IoT), geram novas necessidades, tanto em termos de oportunidade de dados quanto dos tipos de análises envolvidas. Portanto, do lado técnico, também temos que considerar abordagens de streaming versus carregamento em lote ou replicação.

Fontes menos arcaicas também permitem uma mudança de transformações personalizadas e codificadas à mão para uma abordagem mais baseada em um modelo ou metadados para a preparação de informações, que é realmente o cerne da automação do data warehouse.

Você mencionou algumas vezes que o ELT é uma abordagem mais recente que está sendo adotada. Como você vê isso em relação ao ETL? Essas abordagens são complementares ou há um tipo de coisa versus acontecendo aqui?

Acho que há muitas perguntas em torno disso, mas, primeiro, gostaria apenas de dizer algo que acho que ETL foi uma escolha de terminologia realmente infeliz nos primeiros dias. Extrair, transformar e carregar - porque concentra a atenção na sequência de ações, em vez do processo geral, por isso prefiro usar o termo dados ou preparação de informações.

A ordem ou localização das etapas é menos importante para mim do que como realmente as executamos. Esperançosamente, de alguma forma orientada por metadados. Portanto, é importante notar também que a transformação é a etapa mais complexa e importante do processo e entender onde ela acontece acaba sendo uma consideração chave do design.

Então, dito isso e de volta à sua pergunta. ELT - extrair, carregar e transformar - significa simplesmente que a transformação ocorre no ambiente de destino usando o poder de computação [das] abordagens, como um banco de dados relacional encontrado lá. Isso é bom? Sim. Majoritariamente.

A transformação no sistema de origem, talvez devesse ser chamada de transformar, extrair e carregar [TEL], sempre é feita em algum grau, mas historicamente foi mantida no mínimo absoluto para reduzir o impacto do sistema de origem. A transformação em um sistema intermediário - ETL - era então uma escolha óbvia, minimizando os impactos nos sistemas de origem e destino.

No entanto, os sistemas de destino, especialmente na nuvem, têm pouca ou nenhuma restrição de desempenho e o SGBD relacional de destino tem boas habilidades de transformação, então ELT faz muito sentido, e sim, eu acho que eles são complementares e particularmente uma abordagem que combina ETL e ELT parece para mim, seja o mais flexível e poderoso, especialmente se houver alguma inteligência e automação na escolha de quando e em que circunstâncias a função é enviada do servidor ETL [ou seja,] onde é definida pela primeira vez e executada no sistema de destino. Então, absolutamente! Não é uma questão de escolher entre os dois. Acho que os dois podem coexistir, e acho que essa é uma abordagem muito boa.

Como você garante que os dados corretos sejam trazidos para o seu data warehouse, que são combinados e transformados de maneira ideal para se adequar aos requisitos de relatórios e análises? Quais são algumas dicas que você daria às organizações que buscam garantir a qualidade dos dados em seu data warehouse empresarial?

Oh, são ótimas perguntas. Quer dizer, a qualidade é fundamental para todas as formas de tomada de decisão com base em dados ou, eu diria, em informações mais adequadas. Portanto, a primeira coisa para mim é sempre um trabalho de modelagem de dados ou informações minucioso e de qualidade. Eu sei que algumas pessoas vão levantar as mãos e dizer: “Oh, muito lento [e] muito caro. Vamos fazer o esquema na leitura ”. Mas, honestamente, não acho que haja outra maneira de obter dados altamente consistentes em seu warehouse além da modelagem antecipada.

Então, isso é muito importante, e acho que essa modelagem pode e deve ser feita em estágios - uma abordagem ágil em estágios. Esse é um tópico enorme e provavelmente para outro dia. Eu sei que muitas organizações optaram por uma abordagem de data warehouse totalmente dimensional e que pode ser ideal para empresas de médio porte.

Mas para empresas maiores, um armazenamento consistente de dados centrais reconciliados e EDW é geralmente preferível para criar e manter dados e informações de qualidade ideal. E, finalmente - além da modelagem, empregar uma equipe de modelagem boa e flexível é provavelmente o próximo aspecto mais importante da implementação de um ambiente de preparação de dados de primeira classe.

Especialmente, em organizações de médio porte, eu sugeriria que uma abordagem de automação de data warehouse é provavelmente a melhor em termos de qualidade e custo, porque normalmente isso inclui a etapa de modelagem no processo de avanço.

[Diga] esta arquitetura que você tem foi construída. Você tem vários pipelines de dados provenientes de uma variedade de sistemas de origem. Você mencionou sistemas operacionais, obviamente, fluxos de IoT, talvez, [então] há muitas possibilidades quando você está falando sobre a empresa moderna. Você tem diferentes latências de dados trabalhando aqui e interdependências em muitos casos. Orquestrar tudo isso é obviamente uma tarefa difícil. O que você diria que são os elementos essenciais para obter essa parte da equação correta?

Bem, primeiro, gostaria de dizer que sempre lidamos com vários pipelines de dados provenientes de vários sistemas de origem com diferentes latências e interdependências de dados, como você mencionou - certamente, em grandes empresas com as quais já trabalhei.

Acho que o aspecto mais importante hoje, e você mencionou, é que estamos procurando ingerir e analisar grandes quantidades de dados brutos e, muitas vezes, esses dados sujos - e não se sabe o quão sujos são - da web e da internet de coisas. E esses dados têm características muito diferentes dos dados do sistema operacional que eu chamo de dados mediados por processo, ou PMD para abreviar, que eram as principais fontes de dados até, digamos, 10 anos atrás.

Portanto, dada a diferença na qualidade dos dados, eu diria que tentar colocar todos esses novos dados no mesmo data warehouse que seu PMD é um erro. Você precisa de vários pilares de processamento de dados. Expliquei tudo isso no meu livro “Desinteligência Empresarial”, Então se você quiser mergulhar mais fundo lá, faça-o. Alguns desses pilares serão data warehouses tradicionais, outros serão mais como data lakes, mas todos, é claro, serão alimentados com pipelines de dados, conforme defini anteriormente na entrevista.

Portanto, a chave para que tudo funcione bem, é claro, é garantir que os dados nesses pilares estejam bem interconectados, relacionados e reconciliados, ao contrário do que vimos em silos de dados tradicionais e o que você chama de orquestração entre os pipelines de dados é um componente-chave para fazer isso acontecer.

Agora, isso nos traz de volta à modelagem, mas também aos metadados, porque um elemento essencial na orquestração de todos esses pipelines são os metadados. Agora eu prefiro chamá-lo de informação de configuração de contexto, ou CSI, porque essa palavra 'meta' está sendo um pouco abusada atualmente, até mesmo o Facebook a adotou.

Portanto, esse tipo de informação de configuração de contexto é o que está contido e mencionado na Arquitetura de Tecido de Dados do Gartner e é realmente essa ideia de ser ativo e mantido ativamente e mantido internamente consistente e alinhado com as mudanças de negócios, muitas vezes o Gartner sugere que você precise usar IA [artificial inteligência] para fazer isso.

Então, ter essa ideia de metadados ativos envolvidos é muito importante. Minha opinião é que estamos muito longe disso hoje, mas realmente temos que nos concentrar nisso porque acho que realmente fará todo o sistema funcionar ou se desintegrará.

Portanto, falando sobre o data warehouse real e onde ele é construído. Obviamente, a nuvem parece ser para onde todos estão levando seus sistemas de BI hoje em dia. Quais são algumas considerações que as equipes de dados corporativos devem ter em mente ao criar um pipeline de dados para essas plataformas?

Sim, quero dizer, todo mundo está falando sobre nuvem. Em termos arquitetônicos, minha visão é que a nuvem é simplesmente [que é] outro pool de armazenamento, embora enorme e altamente distribuído, e se suas ferramentas de preparação de dados suportam origens e destinos de nuvem, você está pronto para ir, certo? Bem, eu diria que não.

É a natureza distribuída da nuvem que você deve primeiro e sempre manter em mente. O gerenciamento de dados era muito mais simples, eu sempre digo, quando todos os seus dados estavam em um único mainframe. Mas cópias de dados são a ruína da governança de dados e quanto mais lugares e quanto mais distantes essas cópias estiverem, mais difícil se torna o desafio. Portanto, a nuvem permite e - até certo ponto - promove a duplicação de dados, alguns deles [são] amplamente invisíveis.

Portanto, meu primeiro conselho em termos de nuvem é fortalecer suas equipes de governança e gerenciamento de dados, porque eles realmente serão necessários. A segunda consideração é o que é chamado de gravidade dos dados. De onde vêm os dados?

Se vier do local, haverá custos para colocá-lo na nuvem. [E] se vier da nuvem, geralmente é mais eficaz mantê-lo lá.

É claro que a maioria das empresas hoje possui dados de ambas as fontes, portanto, não há uma única resposta correta sobre onde armazenar e processar seus dados. Mas claramente há pressão para colocá-lo na nuvem, geralmente por motivos financeiros. Mas aqui está o problema - o principal aqui é ficar de olho nos custos relativos de processamento de armazenamento e transporte de dados, e acho que é esse último que pode te surpreender, especialmente quando estamos falando sobre preparação de dados e pipelines de dados .

Então, passando aqui para a pergunta final e acho que é aquela que temos evitado e mencionado de maneiras diferentes e em algumas respostas anteriores, mas apenas para obter uma estimativa aproximada de onde você acha que a automação se encaixa em tudo isso? Como isso pode tornar o processo de construção e manutenção de pipelines de dados mais eficiente?

Sim, acho que você está certo. Tudo agora aponta para a automação. Como já disse, sou um grande defensor da automação na preparação de dados e informações. Dito isso, sou profundamente cauteloso em relação à automação em outras áreas, especialmente onde decisões que afetam vidas estão sendo tomadas e acho que devemos ter cuidado com a automação.

Mas voltando à preparação de dados, acho que qualquer coisa que reduza o custo do que é efetivamente apenas encanamento é muito bem-vindo. E a automação deve ser aplicada em todas as fases do processo, sempre que possível - desde a especificação inicial e design até as operações diárias e por todo o caminho até a manutenção contínua e gerenciamento de mudanças.

Esse é um escopo muito amplo e amplo do que precisaríamos fazer e do que precisamos automatizar. Só não faço uma ressalva, você sabe, com base em meus longos anos de experiência e é que a automação tende a empurrá-lo para funções de transformação predefinidas, e elas são ótimas! Mas a capacidade de criar transformações personalizadas exclusivas para seu próprio ambiente costuma ser a chave para o sucesso interno das ferramentas de preparação de dados.

Essas necessidades podem ser de apenas cinco por cento ou menos do que as transformações [predefinidas], mas sua importância é frequentemente subestimada porque muitas vezes são as transformações mais importantes do ponto de vista do negócio.

Em minha opinião, as ferramentas de automação de data warehouse precisam permitir que essas rotinas de transformação muito específicas sejam desenvolvidas e incorporadas ao fluxo de trabalho. Dito isso, a automação oferece a oportunidade de reduzir ou eliminar as partes repetitivas e comuns do processo de preparação de dados. E as ferramentas de automação do data warehouse também aumentam os aspectos humanos do processo.

Estou pensando aqui sobre definição de requisitos, construção de consenso, gerenciamento de mudanças e assim por diante. Nesse sentido, o DWA é um pouco como a inteligência artificial, pois contém aspectos tanto de automação quanto de aumento. Então, acho que é um aspecto particularmente importante sobre o que precisamos pensar.

Como pensamento final, sempre achei que a automação de data warehouse como ETL foi uma escolha infeliz de nome para esta classe de ferramentas, porque essas ferramentas fazem mais do que automação, como acabei de dizer, e podem e devem se aplicar a uma ampla gama mais ampla de sistemas de armazenamento e gerenciamento de dados do que apenas data warehouses.

Todas as partes do nome têm suas fraquezas. Então, qual deve ser o nome? Eu realmente não sei, a menos que você queira tentar chamá-lo de canivete suíço do gerenciamento de dados e acho que é provavelmente um bom lugar para parar.

Automatize seus pipelines de dados sem escrever nenhum código

Descobrir como

Astera DW Builder: automatize seus pipelines de dados

Astera O DW Builder é uma solução de armazenamento de dados unificada que permite construir uma arquitetura de pipeline de dados baseada em metadados. A plataforma ponta a ponta oferece um ambiente de código zero para desenvolver seu data warehouse em um nível lógico e automatizar seus processos de design e engenharia para obter percepções valiosas que satisfaçam seus requisitos de inteligência de negócios.

A solução ágil e automatizada vem com os melhores recursos de ETL e ELT da classe, incluindo orquestração de fluxo de trabalho integrada e componentes de agendamento de trabalho, para construir pipelines de dados autorreguláveis. Tire Astera DW Builder para um test drive para saber como isso pode ajudar a fornecer dados precisos e confiáveis ​​para o seu BI e arquitetura de relatórios.