Compartilhar 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 log 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 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 pontualidade e o valor de seus dados para os usuários. As equipes de aplicativo são responsáveis pelo desempenho e sucesso do aplicativo. Quando eles usam uma abordagem em cascata, eles fazem alterações nos processos downstream que outras equipes possuem. Às vezes, essas mudanças podem afetar outras áreas. Por exemplo, uma pequena alteração upstream 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 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. As tarefas de aplicativos e 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 estabeleceram formas, interfaces de consumo e ciclos de manutenção e atualização, todos documentados.

Os 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, formatar, 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 de produto de dados

Certifique-se de que seus produtos de dados sejam:

  • Detectá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 de forma de seus dados e seu ciclo de atualização. Comunique as alterações de dados ou as alterações de forma aos consumidores downstream em tempo hábil. Para garantir a confiabilidade, as interfaces fornecem compatibilidade com versões anteriores limitadas por tempo para formas de produtos de dados.

  • Endereçável, acessível nativamente e seguro. Para fornecer endereçamento, crie processos definidos para localizar e obter acesso a cada produto de dados. Implemente medidas de segurança para vários requisitos de acesso. Mude sua mentalidade de propriedade de domínio de dados de dados para fornecer dados com precauções 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 número 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 novos valores e informações aos consumidores downstream. 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 para produtos de dados

Para atender aos requisitos de serviço de produtos de dados, as 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 fornecer produtos de dados, equipe totalmente suas equipes de aplicativos de domínio. Suas equipes podem usar uma pilha de tecnologia 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 atende a muitos produtos de dados pode processar e fornecer produtos de dados de 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, do Azure Synapse Analytics ou do Azure Databricks localizada centralmente.

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 aplicativo de dados e que você controle sua implementação e acesso.

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

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

Diretrizes de produto de dados e aplicativo de dados para o Azure

Você pode posicionar abordagens para seu ambiente de aplicativo de dados nas zonas de destino de dados do Azure se suas equipes de aplicativo de domínio usarem uma plataforma compartilhada e um conjunto compartilhado de serviços.

Diagrama que mostra o grupo de recursos data-application-rg do Contexto de Aplicativos de Dados e o grupo de recursos shared-application-rg do Contexto de Serviços Principais.

Para modelos de padrão de aplicativo de dados para zonas de destino de dados do Azure, consulte Aplicativos de dados de exemplo.

Próxima etapa