O Automatizado, Nenhum código Pilha de dados
Saiba como Astera O Data Stack pode simplificar e agilizar o gerenciamento de dados da sua empresa.
Sessão de perguntas e respostas com Paul Kellett sobre pipelines de dados automatizados
Pipelines de dados automatizados servem como espinha dorsal de um ecossistema totalmente orientado por dados. Eles permitem que as empresas extraiam dados de fontes distintas, apliquem transformações e realizem o processo de integração de maneira eficiente, confiável e rápida. Mais empresas estão optando pela automação do data warehouse para melhorar a análise de dados e competir de forma mais estratégica.
Lançamos recentemente Astera DW Builder, uma plataforma de automação de data warehouse de ponta a ponta que fornece um ambiente iterativo e sem código para projetar, desenvolver e implantar pipelines de dados em velocidades sem precedentes.
Para educar as empresas modernas sobre o pipeline de autorregulação de dados, hospedamos um seminário on-line ao vivo intitulado - Proteja seu data warehouse para o futuro com pipelines de dados autorreguláveis em novembro 2nd, onde tivemos uma oportunidade incrível de conversar com Paul Kellett. Ele tem mais de 25 anos de experiência trabalhando em projetos de inteligência de negócios de nível empresarial para organizações.
Em nossa sessão de perguntas e respostas, obtivemos alguns insights valiosos sobre a construção de pipelines de dados automatizados de alta qualidade, processos de armazenamento de dados modernos, armazenamento de dados em nuvem e muito mais.
Afnan: Os armazéns de dados modernos processam grandes volumes de dados. Você recomendaria as melhores práticas que as pessoas deveriam usar para construir pipelines de dados que podem entregar efetivamente essas grandes quantidades de dados para seu data warehouse?
Paulo: Sim, mas também acrescentaria que não se trata apenas do volume de dados. É a variedade de fontes, a variedade de formatos das fontes e o fato de que, se você está particularmente em qualquer ambiente corporativo, está frequentemente acessando dezenas de sistemas - eles estão em constante estado de mudança. Portanto, o tipo de dados que você está recebendo geralmente muda.
Esses sistemas não param - as empresas inovam e mudam, então você está vendo vários problemas aqui. Você precisa obtê-lo de forma confiável; você precisa [processar dados] de maneira robusta [com] o mínimo de intervenções possível. Historicamente, as pessoas podem construir uma série de extrações de seus sistemas de origem, elas estarão fazendo soluções do tipo ponto a ponto onde você pode ter vários mecanismos diferentes para receber os dados. Eu diria, tente ter [um] mecanismo padrão constante [e] você terá um único tipo de prática.
Você precisa então implementar ferramentas adequadas para essas coisas. Portanto, evite tanto quanto possível soluções artesanais ou ponto a ponto. O que vemos em muitos data warehouses históricos é que há várias soluções feitas à mão sob medida para obter os dados do Sistema 'A' e um diferente do 'Sistema B'. Eles acabam essencialmente com problemas de qualidade e robustez, e também acabam com problemas de manutenção e tendem a se adaptar bem lentamente às mudanças.
Então, é um golpe triplo em termos de fazer isso. Você quer usar coisas que fazem o trabalho pesado para você. Você não quer repetir coisas padrão como tratamento de erros. Você precisa que seja simples, fácil, robusto, consistente e padrão. Meu último ponto sobre essa questão seria tentar, se possível, puxar os dados dos sistemas de origem, em vez de tê-los fornecidos a você como uma extração.
Afnan: Pipelines de dados e ETL são basicamente um conceito que tem sido sinônimo de armazenamento de dados desde o início da tecnologia. Então, como você acha que o ELT e o pipelining de dados evoluíram na era do big data? Que tipo de inovação você acha que poderia reduzir o custo e a complexidade do ETL tradicional?
Paulo: Muitos dos custos, historicamente, provêm provavelmente de duas áreas principais: uma, de muitas soluções feitas à mão, que são bastante caras e limitadas. Além disso - e não estou chegando às ferramentas ELT aqui, mas - elas têm sido grandes [e] caras. Eles exigem recursos especializados e própria infraestrutura, hardware, servidor e plataformas dedicados, e [exigem] recursos [que] são difíceis de obter.
Portanto, o que estamos vendo agora é uma mudança para tornar esses tipos de processos mais fáceis. Então, ao invés de ter que descobrir o que você vai conseguir, eles vão e fazem um mapa para você automaticamente. É muito mais clicar e apontar do que historicamente. Portanto, estamos percebendo que isso está essencialmente reduzindo a necessidade e [permite] muito mais codificação e movimentação.
Afnan: Um dos principais requisitos que estamos vendo surgir com frequência é que mais organizações desejam criar pipelines de ELT agora, em vez dos pipelines ETL tradicionais. Então, o que você acha dessa abordagem? Você acha que poderia funcionar para todas as organizações? ou há certas coisas que as organizações precisam ter em mente antes de optar pelo ELT em vez do ETL?
Paulo: Em primeiro lugar, nunca existe uma solução que funcione para tudo. Existem casos em que o ETL é bastante adequado; na verdade, preferido. Mas o que estamos vendo é que o ponto de partida preferido hoje em dia provavelmente seria o ELT. O software e as arquiteturas do banco de dados melhoraram substancialmente. Uma das necessidades do ELT histórico tem sido a incapacidade do banco de dados de processar os grandes volumes de transformações exigidas nas escalas de tempo. Eles podem realizar um grande número de casos de uso.
Eu pessoalmente mudei para o ELT. Não me lembro da última vez que fiz ELT - deve ter sido há pelo menos dez anos. Sua principal motivação seria o componente de bem-estar. Você simplificou sua solução. Você tem menos uma plataforma para dar errado e colocar [bem como] menos um conjunto de plataformas de teste para passar. Então, você abandonou sua complexidade.
Você também tem custo, visto que não tem essas plataformas para fazer isso, então as coisas que estavam gerando a necessidade disso essencialmente diminuíram. Se eu estivesse procurando hoje em um ambiente Greenfields, assumiria que meu ponto de partida seria o ELT e então me afastaria dele se eu achasse necessário devido a algumas circunstâncias especiais.
Afnan: Como você pode garantir que possui os dados corretos em seu data warehouse? e que ambos estão sendo combinados, consolidados e transformados de uma maneira que se adapte aos seus requisitos de relatórios e análises?
Paulo: Portanto, em primeiro lugar, você não pode realmente obter dados corretos garantidos. A razão para isso é que você depende dos dados que os sistemas de origem fornecem e, como qualquer pessoa que trabalhou na área irá testemunhar, eles frequentemente fornecerão dados incorretos ou inconsistentes ou os dados têm problemas quando apresentados de uma maneira diferente - [ ele] fornece a posição errada.
Mas o que você pode fazer é tentar dar a melhor imagem possível dos dados da melhor maneira possível. Você não deveria estar se preparando dizendo que forneceremos dados perfeitos porque isso não acontece. Felizmente, [não] é tão importante porque geralmente você está falando de análises e se trata de entender o volume de dados, portanto, não é necessariamente um problema se você gerenciá-lo corretamente.
Se você quiser obter os melhores dados possíveis, eu recomendaria algumas táticas, uma delas seria [coletar] em excesso. Se tomarmos o exemplo, digamos, transações de vendas, você será solicitado a fornecer relatórios de vendas ou análise de vendas e alguém descobrirá que você precisa dos campos A, B e C dessas duas tabelas e, em seguida, [campos] desta e desta e isso e você obterá os dados necessários para resolver o problema.
Em geral, meu conselho é, se você precisar de informações de vendas, pegue a transação de vendas inteira [e] todos os dados associados. Além disso, leve-o da forma menos transformada possível. Não corra o risco de essencialmente em uma transformação ou alguma derivação dos dados inserir seus próprios erros de tradução. Traga isso para o seu data warehouse e faça-o lá.
Eu também procuraria construir alguns ciclos de feedback, de modo que tivesse maneiras de fazer verificações de alto nível. Digamos que eu tenha os dados que espero obter, normalmente usando relatórios confiáveis ou dados dos sistemas de origem e comparando-os com algo semelhante no que você obtém à medida que avança.
É importante entender o que é bom o suficiente para o negócio. Por exemplo, historicamente, as transações contábeis devem ser perfeitas e dentro de centavos, mas se suas transações de vendas aumentarem um pouco, isso não será o fim do mundo. Então, eu usaria coisas assim também. Existem truques e técnicas padrão, como formatação de dados padrão e remoção de espaços como uma vírgula. Decida-se que você vai fazer isso e fazê-los [de uma] maneira padrão.
Afnan: Quando você está falando sobre coletar todos esses dados de diferentes fontes. Você estará lidando com vários pipelines de dados, e todos esses pipelines obviamente terão diferentes latências e interdependências de dados. Então, quais você acha que são os elementos essenciais para basicamente orquestrar esses pipelines?
Paulo: Existem técnicas de modelagem bastante padronizadas testadas em modelagem de dimensionamento usadas lá fora. Kimball [é] um ótimo lugar para começar a examinar o tipo de conselho e técnicas de design que eles deram. Eles são muito adequados para construir seu data warehouse de maneira que seus dados sejam consistentes e apresentem um formato comum conforme você avança.
Eles vão lidar com coisas como falta de informação, então se você não tem XYZ vindo de uma fonte particular, se você não sabe a definição do produto, então você sabe que tem técnicas padrão como eu irei criar um produto de domínio então em pelo menos meu relatório de vendas soma o produto. Posso não saber as informações do produto, mas saberei que tenho informações sobre um produto chamado frete. Não sei mais sobre esse produto, mas é tudo que sei.
A segunda coisa é que você precisa direcionar a maneira como processa suas informações do conteúdo dos dados [metadados], não como os dados são processados ou acessados. Então, é coisas como se na segunda-feira, você estivesse recebendo as transações de domingo, não presuma que você está recebendo as transações de domingo. Elimine todas as datas dentro dos dados. Portanto, sempre tente pegar o máximo de datas possível com os dados, para que você saiba o que está acontecendo e, dessa forma, você pode comparar as coisas novamente.
Então, você obterá algumas inconsistências entre os sistemas, especialmente [quando você] tem dezenas de sistemas entregando ao seu data warehouse, invariavelmente, um deles ficará inativo em algum momento, um deles estará disponível. [e] isso vai acontecer com frequência. Para esse fim, apresente o que está faltando como parte de sua solução, não apenas apresente e deixe claro e óbvio que não temos os dados de inventário de segunda-feira para [digamos] o centro de distribuição 27.
Lide com isso como parte de seu processamento; esses seriam os meus principais comentários. Portanto, use os dados para conduzi-lo; Kimball é o rei e certifique-se de que a empresa saiba quando você conseguir coisas que não apareceram.
Afnan: O armazenamento de dados em nuvem está ganhando muito peso, especialmente este ano, temos ouvido falar sobre isso em todo o lugar. Então, o que você acha que são algumas considerações que as equipes de dados corporativos precisam ter em mente quando estão construindo pipelines de dados especificamente para um data warehouse em nuvem?
Paulo: Ok, então vou assumir que, quando estamos falando [sobre] o serviço de nuvem adquirido, em termos de hospedagem e gerenciamento de sua infraestrutura de data warehouse. Portanto, de uma perspectiva técnica, não há muita diferença em ir para a nuvem.
[As] principais diferenças técnicas são que você está obviamente na Internet, por assim dizer, e pode estar movendo grandes volumes de dados, então é preciso pensar muito em como mover esses grandes dados volumes ao redor. Seus sistemas de origem e sua infraestrutura hospedada em nuvem - de uma perspectiva de rede - estão próximos o suficiente um do outro para que você possa mover essas coisas? Além disso, eles são robustos o suficiente entre seus vários sistemas para que você tenha confiabilidade, novamente, nos dados.
O outro elemento a ser examinado frequentemente é com as soluções de armazenamento de dados. Existem elementos do tipo painel, e os elementos do tipo painel frequentemente apresentam uma rapidez de adequação reativa. Eles precisam reagir rapidamente aos usuários em termos de você clicar aqui e ir para a próxima configuração.
A latência importa. Se o tempo de ping entre os usuários e a infraestrutura em nuvem for baixo, isso pode fazer com que seus painéis pareçam ruins, embora não sejam. A maioria das considerações seria em torno comercial, regulamentar ou de infraestrutura. Quando você está indo para a nuvem, normalmente está escolhendo um fornecedor. Então, agora você não depende da tecnologia. Você depende de um fornecedor para ter seus sistemas funcionando.
É muito mais sobre medir o fornecedor e suas habilidades do que a tecnologia. Algumas das possíveis questões regulatórias são que - se eu olhar aqui onde estou baseado - você basicamente não tem permissão para tirar do país dados de saúde como exemplo sem permissão especial, porque esses dados são pessoais e existem regras sobre o que você fazer com os dados pessoais.
Da mesma forma, você tem alguma segurança de dados que precisa ser verificada, pois agora você é responsável por cuidar de seus dados para terceiros. Na verdade, eles provavelmente serão melhores em segurança de dados do que você porque isso faz parte da vida deles, mas você ainda precisa verificar isso. E, na verdade, eu diria que essa é provavelmente uma das áreas onde você pode descansar um pouco mais facilmente.
Uma das coisas sobre a mudança para a nuvem é que você obtém muito mais capacidade [em termos de] sua capacidade de adaptação. [Há um] número de casos em que estive com clientes e, essencialmente, seu data warehouse foi configurado na arquitetura de 10 anos que está rangendo lentamente, [com] as cargas diárias chegando cada vez mais tarde pela manhã. [Então], você não receberá seus relatórios até o meio-dia, mas a tarefa de mudança tem sido incrivelmente difícil.
Eles tiveram todos os tipos de problemas relacionados à tentativa de recrutar e possuir recursos capazes de fazer esse tipo de trabalho, de modo que você possa revelar muito desse problema para outra pessoa. Não faça isso para fins de custo, porque geralmente custará semelhante; mesmo que o modelo de custo seja diferente, você está comprando mais [e] melhorando. Essas seriam algumas das considerações para mudar para a nuvem.
Afnan: Onde você acha que a automação se encaixa em tudo isso? [Usando] automação e orquestração, como você acha que pode tornar todo o processo de construção e manutenção de seus pipelines de dados mais eficiente?
Paulo: Em primeiro lugar, tanto quanto possível, evite soluções ponto a ponto, pois tem algo que faz o trabalho pesado para você. Então, você quer algo que esteja fazendo o monitoramento para você. Freqüentemente, essas cargas acontecem no meio da noite. Você deseja um tipo padrão de habilidades de tipo automatizado, como ser capaz de reiniciar a partir de um determinado ponto no tempo, pular pontos, todo esse tipo de controle de trabalho e coisas do tipo gerenciamento de trabalho.
Você quer algo que seja essencialmente fácil de construir. Quanto mais fácil for colocá-los [o sistema] juntos, mais dados você obterá. Quanto mais rápido você obtê-los e [menos] erros que você terá ao trazer esses dados, maior será a probabilidade de você fazer isso da maneira [como] a empresa deseja.
Quer dizer, por outro lado, frequentemente comento que somos nosso pior inimigo. Se tivermos sucesso em uma solução de business intelligence, normalmente sabemos disso porque estamos completamente sobrecarregados com a demanda. Ok, então você tem que ser capaz de fazer essas coisas da maneira mais fácil possível para lidar com essa demanda.
Historicamente, o custo de mover [e] criar data warehouses tem sido da ordem de sessenta por cento, talvez até dois terços, dependendo de suas escalas de tempo no lado do ELT. Então, você realmente quer ter certeza de que tem algo que faça muitas das tarefas repetíveis, tanto quanto possível para você da maneira mais simples possível, porque é uma quantidade tão grande do que pode ser um custo bastante significativo.
Astera DW Builder: Plataforma de Data Warehouse Automatizada
Astera O DW Builder é uma solução de data warehouse de ponta a ponta que permite desenvolver pipelines de dados automatizados em um ambiente sem código. A plataforma unificada vem com arquitetura orientada por metadados e agiliza seus processos de projeto e engenharia para fornecer uma visão precisa e relevante para facilitar uma melhor tomada de decisão.
As empresas podem criar pipelines de dados autorreguláveis, aproveitando os recursos avançados de ETL e ELT, como orquestração de fluxo de trabalho integrado e componentes de agendamento de trabalho de Astera Construtor DW. Experimente Astera DW Builder hoje para descobrir como pode agregar valor à sua organização.
