Os tipos de dados corporativos

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 2 de 6 do capítulo Entendendo os dados corporativos, capítulo 4 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Salesforce é um sistema entre muitos · Próximo: Os sistemas ao redor do Salesforce

A pergunta que este módulo responde: Que tipos de dados uma empresa guarda, e por que eles pertencem a lugares diferentes?

Um registro de cliente. Uma lista de países. Um pedido. A definição de um campo. Cinco anos de totais de vendas. Quatro milhões de fotos de entrega. Tudo isso é dado, mas, em termos de arquitetura, não é a mesma coisa. Muda de forma diferente, cresce de forma diferente, é usado de forma diferente e tem donos diferentes, e não deveria viver automaticamente no mesmo lugar. Então, quando alguém diz “precisamos destes dados no Salesforce”, minha próxima pergunta é: que tipo de dado é este? A resposta começa a me dizer o que fazer com ele.

Comece pelo tipo, não pelo objeto

Como gente de Salesforce, traduzimos requisitos em estruturas quase na hora: cliente, Conta; foto, Arquivo; status, lista de opções. Em algum momento isso é útil. No nível da empresa, primeiro quero saber com que tipo de informação estou lidando. Há muitas formas de classificá-la (o corpo de conhecimento da DAMA é a referência padrão), e acho seis tipos úteis: mestres, de referência, transacionais, metadados, analíticos e não estruturados. As categorias não são a arquitetura. São uma forma de fazer perguntas melhores.

Dados mestres: as coisas que o negócio conhece

Os dados mestres descrevem as coisas duráveis em torno das quais um negócio funciona: clientes, produtos, preços, funcionários, fornecedores, locais, ativos. Numa org de vendas do Salesforce, isso são as suas Contas e Contatos, os seus produtos e os seus catálogos de preços. Na Steve Trucking, um Parceiro varejista é dado mestre. A Keystone não é um evento; é uma organização com a qual a Steve Trucking tem um relacionamento contínuo. Os nove centros de distribuição também são dados mestres.

Os dados mestres sobrevivem às transações que os usam: um Parceiro varejista pode ter milhões de entregas. Então a primeira pergunta sobre eles é sempre quem é o dono? Pode não ser o Salesforce. O ERP pode ser dono dos produtos. O Salesforce pode ser dono dos prospects enquanto o ERP passa a ter autoridade quando eles viram clientes. Uma plataforma de MDM pode ser dona da identidade corporativa de um cliente montada a partir de vários sistemas. O capítulo 6, Dados mestres e identidade, vai fundo. Por enquanto, reconheça a forma.

Dados de referência: o vocabulário que o negócio compartilha

Dados de referência são o vocabulário controlado usado para classificar outros dados: códigos de país, moedas, categorias de produto, códigos de motivo, status. Os status de entrega da Steve Trucking (agendada, carregada, saiu para entrega, chegando, entregue, instalada, exceção, devolvida) são dados de referência. Não são entregas; são as palavras usadas para descrever as entregas.

Parecem pequenos e inofensivos, muitas vezes uma lista de opções com oito valores. Não confunda pequeno com sem importância. Se o Salesforce diz Delivered, o ERP diz Complete e um Parceiro varejista manda D, alguém precisa definir o que cada um significa e como se mapeiam. Os dados de referência são onde as suposições de integração se escondem.

Dados transacionais: o que aconteceu

Dados transacionais registram atividade: um pedido feito, um pagamento realizado, uma entrega concluída, um caso aberto. Na mesma org de vendas, isso são cotações e linhas de cotação, pedidos e itens de pedido, pagamentos: cada um aponta de volta para um cliente e um produto. O milhão de entregas por ano da Steve Trucking é transacional, e as atualizações de status delas também: umas oito por entrega, então oito milhões de mudanças de status por ano, num negócio que cresce 30% ao ano.

É uma curva de crescimento completamente diferente da dos dados mestres. Três Parceiros varejistas no topo; milhões de linhas embaixo. É aqui que o Número de Zeros do Steve importa: você não pode olhar para Parceiro varejista → Entrega → Status e dar o mesmo peso a cada caixa. Com dados transacionais penso imediatamente em volume, velocidade, retenção, histórico, arquivamento, integração, e em como as pessoas realmente precisam encontrá-los. A Parte 2 passa bastante tempo aí.

Metadados: dados sobre os dados

Você vem trabalhando com metadados o curso todo: a definição de um objeto, o tipo de um campo, sua descrição, seus relacionamentos. A empresa inteira tem isso: esquemas de data warehouse, mapeamentos de integração, catálogos de dados, contratos de API e, para cada campo, um dono, um nível de sensibilidade, uma definição, uma linhagem e uma regra de retenção. Os valores são dados; a descrição do que eles significam é metadado. Como disse o capítulo 3, Flag2__c não diz nada a ninguém, e isso importa mais agora que a IA lê os metadados para descobrir o que os dados significam.

Dados analíticos: dados que fizemos a partir de outros dados

“Qual é a nossa taxa de pontualidade por Parceiro varejista nos últimos cinco anos?” não é uma transação. É uma pergunta analítica, respondida derivando dados novos de milhões de entregas: percentual de pontualidade, taxa de avarias, receita por parceiro, qualidade das instalações, tendências das equipes. E é outro trabalho. O despachante que pergunta “qual é a próxima parada do caminhão 217?” não precisa varrer cinco anos de histórico. A liderança que compara cinco anos de pontualidade por região precisa. É por isso que os dados analíticos normalmente vivem num data warehouse, num lakehouse ou numa plataforma de análise feita para esse trabalho. O fato de o Salesforce conseguir armazenar algo não torna a plataforma operacional o lugar para rodar toda análise sobre isso.

Dados não estruturados: o que não cabe em linhas

Documentos, PDFs, imagens, áudio, vídeo, e-mails, transcrições, artigos de conhecimento. Na Steve Trucking, as fotos de entrega: umas quatro por entrega, mais com instalações, quatro a cinco milhões por ano. Uma foto não é só mais um campo. Ela é grande, pode mostrar o interior da casa de alguém, tem suas próprias regras de retenção, e é buscada de outro jeito, quando é buscada.

Este tipo importa mais a cada ano, porque a IA agora consegue fazer coisas úteis com informação que antes ficava fora do modelo estruturado. Uma transcrição é dado. Um manual em PDF é dado. Uma foto de instalação é dado. Isso não significa que pertença ao núcleo do Salesforce. Significa que pertence ao panorama.

Click to enlarge

Seis tipos, quatro perguntas cada. As respostas mudam de um tipo para outro, e esse é o ponto.

O tipo é só metade da pergunta: a carga de trabalho

Saber que tipo de dado temos não basta. Também quero saber o que estamos fazendo com ele. Três cargas de trabalho importam aqui, e confundi-las faz arquitetura ruim.

Operacional: tocar o negócio. Um despachante atualiza uma entrega, uma equipe conclui uma parada, um atendente abre um caso. Muitas leituras e gravações pequenas: encontre isto, atualize aquilo, me mostre as paradas de hoje. Isso é OLTP, processamento de transações online, e o Salesforce é muito bom nisso; é onde administradores e desenvolvedores vivem.

Analítica: entender o negócio. Todas as entregas de cinco anos, agrupadas por parceiro e CD, comparadas ano a ano, cruzadas com o financeiro. Agora estamos varrendo e agregando. Isso é OLAP, processamento analítico online, e é para isso que data warehouses, lakehouses e plataformas de análise são construídos. Dito de forma simples: a org opera o negócio; data warehouses e data lakes o analisam. Um erro clássico é colocar essa carga de trabalho na plataforma operacional e se surpreender à medida que os zeros crescem. Se alguém quer varrer quantidades enormes de histórico repetidamente, não trate isso como “só mais um relatório”. Pergunte se é a plataforma certa. A Parte 2 volta a isso em Projetando para escala (coming soon) (não transforme o núcleo no seu data warehouse), e a Parte 3 mostra como as estruturas analíticas são construídas em Além do relacional (coming soon).

Streaming: dados em movimento. Eventos, telemetria, mudanças de status, leituras de sensores. Os caminhões da Steve Trucking enviam cerca de 200 mil leituras de GPS por dia. O despachante quer saber onde o caminhão 217 está agora. O Salesforce precisa guardar cada leitura minuto a minuto de cada caminhão? Talvez não. “Onde ele está agora?” e “quais foram as tendências de eficiência das rotas no último trimestre?” vêm da mesma fonte e levam a decisões de armazenamento completamente diferentes.

Com que rapidez ele precisa se mover?

Depois vem a latência. Em aula digo assim: tempo real é esperar na porta até alguém voltar. Você manda a pessoa sair e fica ali, porque não pode continuar até ela voltar. Isso é síncrono. Quase em tempo real é vê-la sair e ir cuidar de outra coisa; quando ela volta, pouco depois, você lida com isso. Isso é assíncrono. E depois há o lote (batch): ninguém sai pela porta um de cada vez. Os dados esperam e se movem em grupo, num horário programado: de hora em hora, a cada poucas horas ou diariamente. Há muitas situações em que o lote é suficiente, e algumas em que não é. Saber qual é qual é o trabalho. Esses três não são só termos de integração; são escolhas de arquitetura.

Pegue a integração comum com o ERP. Um produto novo é criado no ERP às 11h. Vendas precisa mesmo vendê-lo até o meio-dia? Já vi as duas respostas. Alguns clientes querem o produto o quanto antes; outros dizem: se ainda não enviamos esse SKU para vocês, não podemos esperar que vocês já o vendam. Então produtos costumam ser diários, às vezes mais rápido. Clientes, no mínimo diariamente; já vi de hora em hora e, em casos extremos, quase em tempo real. Pedidos são diferentes: o atendimento precisa começar, então quase em tempo real. O vendedor fecha o negócio e segue em frente, e o pedido chega ao ERP em segundos ou em um ou dois minutos. Não há uma latência certa única para “dados corporativos”. Pergunte do que o negócio realmente precisa, e não faça tudo em tempo real porque soa impressionante. O tempo real tem um custo.

As quatro perguntas por trás das categorias

Você não precisa sair por aí anunciando “isto é dado transacional!” A classificação existe para disparar quatro perguntas sobre cada conjunto de dados importante:

• Quem é o dono? Qual sistema tem autoridade? Eu divido isso em três: onde o dado é criado, onde é editado e onde é referenciado? O capítulo 6 se aprofunda nisso (Criado, editado, referenciado, e com que rapidez?).
• Com que rapidez muda? Uma vez por ano, todo dia, dezenas a centenas de vezes por segundo?
• Quão grande fica? Dez registros, dez mil, dez milhões, dez bilhões?
• Qual é o ciclo de vida? Vive para sempre, é arquivado, precisa ser excluído, perde valor com o tempo?

Essas quatro me dizem muito mais do que “o Salesforce consegue armazenar isto?” E elas juntam o que já aprendemos: propriedade, ciclo de vida, o Número de Zeros, onde os dados vivem.

Um negócio produz todos os tipos

Na Steve Trucking, o Parceiro varejista é dado mestre; o vocabulário de status é dado de referência; cada entrega é transacional; as definições dos seus campos são metadados; o scorecard de pontualidade de cinco anos é analítico; a foto da instalação é não estruturada; e o feed de GPS é streaming. Tudo isso é “dado da Steve Trucking”. Nada disso significa que pertence ao mesmo banco de dados. Essa é a virada.

Além do exame: o que a IA muda. Para responder a uma pergunta, um agente pode precisar de um registro estruturado de cliente, de uma transação recente, de um manual em PDF, de uma transcrição de atendimento e de telemetria ao vivo. Dados não estruturados e de streaming viram partes de primeira classe da arquitetura mesmo quando não pertencem ao banco de dados do CRM, e o arquiteto ainda precisa saber quem é dono de cada fonte, quão atual ela é, e se o agente deve confiar nela.

O que um arquiteto decide aqui

• Que tipo de dado é cada conjunto de dados importante, e quem é o dono.
• Se a carga de trabalho dele é operacional, analítica, de streaming ou uma mistura.
• Com que rapidez ele muda, e com que rapidez outros sistemas realmente precisam ver a mudança.
• Como o volume e o ciclo de vida definem onde ele vive e por quanto tempo.
• Se o Salesforce deve ser dono dele, guardar uma cópia, referenciá-lo, ou deixá-lo em algum lugar mais adequado à carga de trabalho.

Quando alguém lhe entregar um requisito, não pule para qual objeto, qual campo, qual API. Primeiro pergunte que tipo de dado é, quem é o dono, com que rapidez muda, quão grande fica, quanto tempo vive, e o que estamos tentando fazer com ele. Uma Conta, um evento de entrega, um agregado de cinco anos e uma fotografia podem todos importar para o mesmo negócio sem ser o mesmo problema de arquitetura.

Para saber mais

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2ª edição (2017): a referência padrão para categorias de dados e gestão de dados.
• O briefing da Steve Trucking (em inglês), seção 4 (volumes).