O que é um produto de dados?
Cada aplicação cria e armazena dados temporariamente ou permanentemente. Muitas aplicações também criam e guardam dados para fins de gestão operacional, como o registo de erros e a monitorização do estado de funcionamento. As equipas de dados centralizadas utilizam processos ETL para consumir e processar os dados que estas aplicações produzem. Muitas vezes, as equipas de operações de aplicações têm fluxos de processamento de dados adicionais para aspetos como o estado de funcionamento da aplicação e a monitorização do estado do KPI.
A abordagem tradicional de uma cascata de equipas e responsabilidades na integração de dados não é a ideal. Pode originar lacunas de conhecimento, problemas de propriedade e conflitos de comunicação que afetam a qualidade, a linha cronológica e o valor dos seus dados para os utilizadores finais. As equipas de aplicações são responsáveis pelo desempenho e sucesso da aplicação. No seu trabalho, precisam de fazer alterações aos processos a jusante pertencentes a outras equipas, mas estas alterações muitas vezes não correm de acordo com o plano. Por exemplo, poderá descobrir que uma alteração a montante secundária altera drasticamente a tendência de um KPI. Estes tipos de problemas de dados podem afetar a sua capacidade de tomar decisões críticas.
A abordagem da malha de dados impede estes problemas ao adotar o conceito de dados como um produto. Os proprietários de aplicações e as equipas de aplicações tratam os dados como um produto totalmente contido pelo qual são responsáveis, em vez de um subproduto de algum processo que outros gerem. Tanto as aplicações como os dados analíticos que servem tarefas estão nas áreas de responsabilidade do domínio.
Os produtos de dados são criados especificamente para consumo analítico. Definiram e acordaram formas, interfaces de consumo e ciclos de manutenção e atualização, todos documentados.
Os produtos de dados são ativos/conjuntos de dados de dados de domínio processados partilhados com processos a jusante através de interfaces num SLO. Salvo necessidade em contrário, os seus dados não processados devem ser processados, moldados, limpos, agregados e normalizados para cumprir os padrões de qualidade acordados antes de os disponibilizar para consumo.
As secções seguintes descrevem características comuns que os bons produtos de dados têm.
Características do produto de dados
Os produtos de dados bem concebidos são:
Detetável, compreensível e fidedigno: As equipas de domínio proporcionam capacidade de deteção e compreensão ao partilhar e atualizar informações sobre cada produto de dados, os respetivos dados, o respetivo significado, o formato da forma dos seus dados e o respetivo ciclo de atualização. Comunicam as alterações nos dados ou na forma aos consumidores a jusante em tempo útil. As interfaces garantem a fiabilidade ao fornecer compatibilidade com retrocompatibilidade limitada ao tempo para formas de produtos de dados.
Endereçável, acessível nativamente e seguro: Os processos definidos para localizar e obter acesso a cada produto de dados proporcionam endereçabilidade. Estão em vigor as medidas de segurança necessárias para diferentes requisitos de acesso. A mentalidade de propriedade do domínio de dados muda de dados de manutenção de porta para servir dados com precauções de segurança bem definidas. As interfaces de acesso oferecidas estão bem documentadas e podem variar em diferentes tecnologias. As interfaces mais utilizadas para produtos de dados acessíveis nativamente incluem APIs, utilizadores de bases de dados, tabelas ou vistas e ficheiros com direitos de acesso necessários.
Interoperável, verdadeiro e valioso: Os dados fornecem interoperabilidade ao seguir padrões comuns definidos, como os mesmos valores que têm sempre o mesmo nome e tipo de dados. Por exemplo, uma coluna que contenha dados de identificação de clientes pode ser intitulada CustomerID em todos os produtos de dados e os respetivos dados podem ser sempre um número inteiro ou utilizar snake_case ou camelCase em todas as instâncias. Os produtos de dados fornecem valor aos clientes e também podem ser utilizados como origens a montante para novos produtos de dados nos mesmos domínios ou em diferentes domínios. No entanto, não pode simplesmente transportar e copiar o mesmo produto de dados em vários locais. Cada produto de dados proveniente de um produto de dados anterior deve fornecer novos valores e informações aos consumidores a jusante. Os produtos de dados também têm de fornecer sempre dados verdadeiros e não erróneos.
Os produtos de dados bem concebidos e bem conservados e as respetivas interfaces ajudam as organizações a evitar duplicar dados e podem ajudar a criar uma única origem nativa de verdade.
Recomendações de design de produtos de dados
Para cumprir os requisitos de serviço de produtos de dados, as suas equipas de domínio têm de adquirir um novo conjunto de competências e utilizar novas ferramentas e plataformas.
Equipar totalmente as suas equipas de aplicações de domínio para criar as aplicações de dados e produzir ou servir produtos de dados. As suas equipas podem criar produtos de dados com uma pilha de tecnologia familiar. Também podem preferir ter a sua própria instância do Spark ou motor de pipeline, se possível. Por exemplo, um domínio grande que serve muitos produtos de dados pode decidir processar e servir produtos de dados a partir do seu próprio Azure Synapse Analytics. Organizações mais pequenas e domínios mais pequenos de grandes empresas podem decidir desenvolver e executar as respetivas aplicações de dados numa plataforma partilhada, como um Azure Data Factory localizado centralmente, o Azure Synapse Analytics ou o Azure Databricks.
Certifique-se de que os seus produtos de dados têm as características comuns descritas neste artigo, que o repositório de linhagem reflete a linhagem da aplicação de dados e que a implementação e o acesso são regidos.
Documentação de Orientação do Produto de Dados e da Aplicação de Dados para o Azure
Pode posicionar todas as abordagens possíveis para o ambiente da aplicação de dados nas zonas de destino de dados do Azure se as equipas de aplicações de domínio utilizarem uma plataforma partilhada e um conjunto de serviços.
Pode encontrar três modelos de padrão de aplicação de dados diferentes para zonas de destino de dados do Azure em produtos de dados de análise à escala da cloud no Azure – Aplicações de dados de exemplo.