Casos de uso de produtos de dados

  • Versão de lançamento: Australia
  • Atualizado 30 de mar. de 2026
  • 3 min. de leitura

    • Explore cenários comuns para publicar produtos de dados e saiba qual padrão atende aos seus dados e às necessidades dos seus consumidores.

    Um produto de dados é criado em uma ou mais interfaces de dados, cada uma das quais determina como os dados de origem são acessados e combinados. O tipo de interface de dados correto depende de onde seus dados residem, como eles são estruturados e o que os consumidores querem fazer com eles.

    A equipe de análise de fidelidade de uma empresa de viagens está vendo uma tendência clara: Os membros Gold Star estão voando menos. A questão central que impulsiona a investigação é: Em quais rotas os membros Gold reservam menos reservas e isso está piorando? Os dados residem no Snowflake: Segmentos de voo, razão de pontos e perfis de membros. Nenhum analista tem acesso direto ao depósito e os dados são confidenciais demais para serem exportados. A equipe precisa de uma maneira de consultar dados do Snowflake em tempo real na ServiceNow, com controles de acesso que eles possam gerenciar.

    A equipe divide a investigação em quatro perguntas específicas, cada uma respondida por uma interface de dados dedicada:

    • Quais rotas geram a maior atividade de acúmulo de pontos?
    • Quantos membros Gold exclusivos fizeram reservas em cada rota no último trimestre?
    • Que rotas estão vendo declínio no volume de reservas ao longo do tempo?
    • Quantos membros Gold de longa duração estão inativos no momento?

    Acompanhamento de tendências de reserva em rotas e classes de cabine

    Para acompanhar o volume de reservas ao longo do tempo, a equipe precisa de rota, mês e classe de cabine. Todos esses dados residem em uma única tabela do Snowflake, FLIGHT_SEGMENTS. Uma interface de dados de tabela única sobre FLIGHT_SEGMENTS expõe os dados brutos do segmento, e o painel Análise da plataforma aplica filtros de data e classificações de rota superior no momento da consulta. Manter a interface de finalidade geral significa que os mesmos dados podem alimentar vários widgets do painel sem recriá-los para cada um. Configuração da interface de dados mostrando conexão de tabela única com flight_segments no Snowflake com 11 colunas verificadas.

    Identificar membros de longa permanência que ficaram quietos

    Tudo o que é necessário para responder à pergunta do membro inativo (nível de fidelidade, duração do tempo de serviço, status ativo ou inativo) reside em MEMBER_PROFILE. Uma interface de tabela única filtra membros Gold com cinco ou mais anos de permanência e status inativo. Essa interface alimenta o widget de KPI mostrando 10 membros Gold inativos de alta senioridade e o gráfico de entrega detalhado por aeroporto central.

    Configuração da interface de dados mostrando conexão de tabela única com member_profile no Snowflake com 8 colunas verificadas.

    Ganhos de pontos de conexão com as rotas onde eles acontecem

    Saber quais rotas geram a maior atividade de acúmulo de pontos requer a conexão de duas tabelas. As transações de pontos vivem em POINTS_LEDGER, mas as informações de rota (origem, destino) residem em FLIGHT_SEGMENTS. As duas tabelas compartilham um booking_id. Uma interface de dados de JUNÇÃO os vincula nessa chave, filtra somente transações de GANHO e produz um resultado fixo mostrando o total de pontos ganhos por rota. O analista que consulta o painel vê uma tabela; a lógica de junção é invisível para ele. Configuração da interface de dados mostrando a junção entre as tabelas flight_segments e points_ledger com um total de 18 colunas.

    Medição do compromisso do membro Gold rota por rota

    A quarta pergunta, quantos membros Gold estão reservando cada rota, requer dados de voo de conexão com os dados do membro. FLIGHT_SEGMENTS contém os registros de rota e reserva; MEMBER_PROFILE contém o nível de fidelidade. Uma interface DE JUNÇÃO vincula as duas tabelas, filtra o nível GOLD e retorna a contagem de membros exclusivos e o total de reservas por rota no trimestre anterior. Configuração da interface de dados mostrando a junção entre as tabelas member_profile e flight_segments com um total de 18 colunas.

    O resultado: Painel do Travel Pulse

    O Administrador de dados empacota todas as quatro interfaces de dados em um único produto de dados. O administrador publica-o no Catálogo de dados. O analista de fidelidade, que não tem acesso ao depósito, descobre o produto, solicita acesso e cria o painel do Travel Pulse na Análise da plataforma. Cada widget consulta uma interface diretamente em relação aos dados do Snowflake em tempo real. Nenhum dado é copiado, extraído ou replicado. Painel do Travel Pulse na Análise da plataforma que mostra tendências de reserva, classificações de rotas e análise de membros Gold.

    Estendendo o padrão: Combinando dados de várias fontes

    Posteriormente, a equipe precisar incluir dados de reserva de uma companhia aérea parceira, poderá usar uma interface de dados DO SINDICATO. Os dados do parceiro são armazenados em uma tabela separada do Snowflake com o mesmo esquema de FLIGHT_SEGMENTS. Uma interface de dados de UNIÃO empilha ambas as tabelas em uma única exibição consultável. Os consumidores consultam um conjunto de dados unificado. Nenhuma mudança de interface existente.

    Esse padrão se encaixa sempre que o mesmo tipo de registro é rastreado em vários sistemas. Registros como reservas, pedidos, transações ou eventos podem ser divididos por região, período de tempo ou unidade de negócios. A necessidade de relatar é cobrir todos eles de uma só vez.