Partilhar via


O que é um produto de dados?

Cada aplicativo cria e armazena dados temporária ou permanentemente. Muitos aplicativos também criam e salvam dados para fins de gerenciamento operacional, como registro de erros e monitoramento de integridade. Para consumir e processar os dados que esses aplicativos produzem, as equipes de dados centralizadas usam processos de extração, transformação e carregamento (ETL). As equipes de operação de aplicativos geralmente têm outros fluxos de processamento de dados para dados, como dados de integridade do aplicativo e dados de monitoramento de status de KPI.

Para a integração de dados, uma abordagem tradicional em cascata, na qual as equipes seguem uma ordem específica de fases, não é ideal. Isso pode levar a lacunas de conhecimento, problemas de propriedade e conflitos de comunicação que afetam a qualidade, a atualidade e o valor dos dados para os usuários. As equipes de aplicativos são responsáveis pelo desempenho e sucesso dos aplicativos. Quando usam uma abordagem em cascata, fazem alterações nos processos downstream que outras equipes possuem. Por vezes, estas alterações podem afetar outras áreas. Por exemplo, uma pequena alteração a montante pode alterar drasticamente a tendência de um KPI. Esses conflitos podem afetar sua capacidade de tomar decisões críticas.

Dados como produto

Para evitar esses problemas, a abordagem de malha de dados adota o conceito de dados como um produto. Os proprietários de aplicativos e as equipes de aplicativos tratam os dados como um produto totalmente contido pelo qual são responsáveis, em vez de um subproduto do processo de outra equipe. Tanto os aplicativos quanto as tarefas de serviço de dados analíticos estão dentro das áreas de responsabilidade do domínio.

Os produtos de dados são criados especificamente para consumo analítico. Eles definiram e concordaram com formas, interfaces de consumo e ciclos de manutenção e atualização, todos documentados.

Produtos de dados são ativos de dados de domínio processados ou conjuntos de dados que você pode compartilhar com processos downstream por meio de interfaces em um objetivo de nível de serviço. A menos que seja necessário de outra forma, você deve processar, moldar, limpar, agregar e normalizar seus dados brutos para atender aos padrões de qualidade acordados antes de disponibilizá-los para uso.

As seções a seguir descrevem as características comuns de bons produtos de dados.

Características do produto de dados

Certifique-se de que seus produtos de dados sejam:

  • Detetável, compreensível e confiável. Para fornecer capacidade de descoberta e clareza, compartilhe e atualize informações sobre cada produto de dados, seus dados, seu significado, o formato da forma de seus dados e seu ciclo de atualização. Comunicar alterações de dados ou alterações de forma aos utilizadores finais de forma oportuna. Para garantir a fiabilidade, as interfaces fornecem compatibilidade retroativa limitada no tempo para estruturas de produtos de dados.

  • Endereçável, acessível nativamente e seguro. Para fornecer endereçabilidade, crie processos definidos para localizar e obter acesso a cada produto de dados. Implementar medidas de segurança para vários requisitos de acesso. Mude a sua mentalidade de propriedade de domínio de dados de controlo de acesso para facilitar o acesso aos dados com medidas de segurança bem definidas. Interfaces de acesso bem documentadas podem variar entre diferentes tecnologias. As interfaces comumente usadas para produtos de dados acessíveis nativamente incluem APIs, usuários de banco de dados, tabelas ou exibições e arquivos com direitos de acesso necessários.

  • Interoperável, verdadeiro e valioso. Para fornecer interoperabilidade, certifique-se de que seus dados sigam padrões comuns definidos, como valores que tenham o mesmo nome e tipo de dados. Por exemplo, você pode nomear uma coluna que contém dados de identificação do cliente CustomerID em cada produto de dados, e seus dados podem sempre ser um inteiro. Os produtos de dados fornecem valor aos clientes e você pode usá-los como fontes upstream para novos produtos de dados no mesmo domínio ou em domínios diferentes. Mas você não pode simplesmente carregar e copiar o mesmo produto de dados em vários lugares. Cada produto de dados proveniente de um produto de dados anterior deve fornecer novo valor e informações aos consumidores a jusante. Os produtos de dados também devem fornecer dados verdadeiros e precisos.

Use produtos de dados bem projetados e bem mantidos e suas interfaces para ajudar a evitar a duplicação de dados e criar uma única fonte nativa de verdade.

Recomendações de design de produtos de dados

Para atender aos requisitos de atendimento de produtos de dados, suas equipes de domínio devem adquirir um novo conjunto de habilidades e usar novas ferramentas e plataformas.

Para criar os aplicativos de dados e produzir ou servir produtos de dados, equipe totalmente suas equipes de aplicativos de domínio. As suas equipas podem usar um stack tecnológico familiar para criar produtos de dados. Eles também podem preferir ter sua própria instância do Spark ou mecanismo de pipeline. Por exemplo, um domínio grande que serve muitos produtos de dados pode processar e servir produtos de dados a partir da sua própria instância do Azure Synapse Analytics. Organizações menores e domínios menores de grandes organizações podem desenvolver e executar seus aplicativos de dados em uma plataforma compartilhada, como uma instância do Azure Data Factory localizada centralmente, Azure Synapse Analytics ou Azure Databricks.

Certifique-se de que seus produtos de dados tenham as características comuns descritas neste artigo, que seu repositório de linhagem reflita sua linhagem de aplicativos de dados e que você controle sua implementação e acesso.

O diagrama a seguir mostra um exemplo de layout lógico de aplicativo de dados em um domínio e zona de destino.

Diagrama que mostra um possível layout lógico do aplicativo de dados em um domínio e zona de destino.

Próximo passo