Os tipos de dados empresariais

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

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

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

Um registo de cliente. Uma lista de países. Uma encomenda. A definição de um campo. Cinco anos de totais de vendas. Quatro milhões de fotografias de entrega. Tudo isto são dados, mas, em termos de arquitetura, não são a mesma coisa. Mudam de forma diferente, crescem de forma diferente, são usados de forma diferente e têm donos diferentes, e não deveriam viver automaticamente no mesmo lugar. Por isso, quando alguém diz «precisamos destes dados no Salesforce», a minha pergunta seguinte é: que tipo de dado é este? A resposta começa a dizer-me o que fazer com ele.

Comece pelo tipo, não pelo objeto

Como gente de Salesforce, traduzimos requisitos em estruturas quase de imediato: cliente, Conta; fotografia, Ficheiro; estado, lista de opções. A dada altura isso é útil. Ao nível da empresa, primeiro quero saber com que tipo de informação estou a lidar. Há muitas formas de a classificar (o corpo de conhecimento da DAMA é a referência padrão), e acho úteis seis tipos: 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 duradouras à volta das quais um negócio funciona: clientes, produtos, preços, colaboradores, fornecedores, locais, ativos. Numa org de vendas do Salesforce, isso são as suas Contas e Contactos, os seus produtos e os seus catálogos de preços. Na Steve Trucking, um Parceiro retalhista é dado mestre. A Keystone não é um evento; é uma organização com a qual a Steve Trucking tem uma relação contínua. Os nove centros de distribuição também são dados mestres.

Os dados mestres sobrevivem às transações que os usam: um Parceiro retalhista pode ter milhões de entregas. Por isso 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 se tornam clientes. Uma plataforma de MDM pode ser dona da identidade empresarial de um cliente montada a partir de vários sistemas. O capítulo 6, Dados mestres e identidade, vai a fundo. Por agora, reconheça a forma.

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

Os 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, estados. Os estados de entrega da Steve Trucking (agendada, carregada, saiu para entrega, a chegar, 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 retalhista envia D, alguém tem de definir o que cada um significa e como se mapeiam. Os dados de referência são onde se escondem os pressupostos de integração.

Dados transacionais: o que aconteceu

Os dados transacionais registam atividade: uma encomenda feita, um pagamento efetuado, uma entrega concluída, um caso aberto. Na mesma org de vendas, isso são cotações e linhas de cotação, encomendas e itens de encomenda, 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 suas atualizações de estado também: umas oito por entrega, portanto oito milhões de mudanças de estado por ano, num negócio que cresce 30% ao ano.

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

Metadados: dados sobre os dados

Tem andado a trabalhar com metadados ao longo de todo o curso: a definição de um objeto, o tipo de um campo, a sua descrição, as suas relações. A empresa inteira tem isto: 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 significam são metadados. 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 retalhista nos últimos cinco anos?» não é uma transação. É uma pergunta analítica, respondida derivando dados novos de milhões de entregas: percentagem de pontualidade, taxa de danos, receita por parceiro, qualidade das instalações, tendências das equipas. E é outro trabalho. O expedidor que pergunta «qual é a próxima paragem do camião 217?» não precisa de varrer cinco anos de histórico. A direção 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 facto de o Salesforce conseguir armazenar algo não torna a plataforma operacional o lugar para correr todas as análises 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 fotografias de entrega: umas quatro por entrega, mais com instalações, quatro a cinco milhões por ano. Uma fotografia não é só mais um campo. É grande, pode mostrar o interior da casa de alguém, tem as suas próprias regras de retenção, e é procurada de outra forma, quando é procurada.

Este tipo importa mais a cada ano, porque a IA consegue agora fazer coisas úteis com informação que antes ficava fora do modelo estruturado. Uma transcrição é um dado. Um manual em PDF é um dado. Uma fotografia de instalação é um 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 a fazer com ele. Aqui importam três cargas de trabalho, e confundi-las dá má arquitetura.

Operacional: fazer o negócio funcionar. Um expedidor atualiza uma entrega, uma equipa conclui uma paragem, um agente abre um caso. Muitas leituras e gravações pequenas: encontre isto, atualize aquilo, mostre-me as paragens de hoje. Isto é OLTP, processamento de transações online, e o Salesforce é muito bom nisto; é onde vivem administradores e programadores.

Analítica: entender o negócio. Todas as entregas de cinco anos, agrupadas por parceiro e CD, comparadas ano a ano, cruzadas com as finanças. Agora estamos a varrer e a agregar. Isto é OLAP, processamento analítico online, e é para isso que os data warehouses, os lakehouses e as plataformas de análise são construídos. Dito de forma simples: a org gere o negócio; os data warehouses e os data lakes analisam-no. Um erro clássico é pôr esta carga de trabalho na plataforma operacional e ficar surpreendido à 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 isto em Projetar para a 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 estado, leituras de sensores. Os camiões da Steve Trucking enviam cerca de 200 mil leituras de GPS por dia. O expedidor quer saber onde está o camião 217 agora. O Salesforce precisa de guardar cada leitura minuto a minuto de cada camião? Talvez não. «Onde 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 precisa de se mover?

Depois vem a latência. Nas aulas digo assim: tempo real é esperar à porta até alguém voltar. 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 tratar de outra coisa; quando ela volta, pouco depois, trata do assunto. Isso é assíncrono. E depois há o lote (batch): ninguém sai pela porta um de cada vez. Os dados esperam e movem-se em grupo, num horário programado: de hora a hora, de poucas em poucas horas ou diariamente. Há muitas situações em que o lote é suficiente, e algumas em que não é. Saber qual é qual é o trabalho. Estes três não são só termos de integração; são escolhas de arquitetura.

Pegue na integração comum com o ERP. É criado um produto novo no ERP às 11h. Vendas precisa mesmo de o vender até ao meio-dia? Já vi as duas respostas. Alguns clientes querem o produto o mais depressa possível; outros dizem: se ainda não vos enviámos esse SKU, não podemos esperar que já o vendam. Por isso, os produtos costumam ser diários, às vezes mais rápido. Clientes, no mínimo diariamente; já vi de hora a hora e, em casos extremos, quase em tempo real. As encomendas são diferentes: o processamento tem de começar, por isso quase em tempo real. O vendedor fecha o negócio e segue em frente, e a encomenda chega ao ERP em segundos ou num ou dois minutos. Não há uma única latência certa para «dados empresariais». Pergunte de que o negócio realmente precisa, e não faça tudo em tempo real só porque soa impressionante. O tempo real tem um custo.

As quatro perguntas por trás das categorias

Não precisa de andar por aí a anunciar «isto é um dado transacional!» A classificação existe para desencadear quatro perguntas sobre cada conjunto de dados importante:

• Quem é o dono? Que sistema tem autoridade? Divido isto em três: onde é o dado criado, onde é editado e onde é referenciado? O capítulo 6 aprofunda isto (Criado, editado, referenciado, e com que rapidez?).
• Com que rapidez muda? Uma vez por ano, todos os dias, dezenas a centenas de vezes por segundo?
• Quão grande fica? Dez registos, dez mil, dez milhões, dez mil milhões?
• Qual é o ciclo de vida? Vive para sempre, é arquivado, tem de ser eliminado, perde valor com o tempo?

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

Um negócio produz todos os tipos

Na Steve Trucking, o Parceiro retalhista é dado mestre; o vocabulário de estados é 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 fotografia da instalação é não estruturada; e o feed de GPS é streaming. Tudo isto são «dados da Steve Trucking». Nada disto significa que pertença à mesma base de dados. Essa é a viragem.

Além do exame: o que a IA muda. Para responder a uma pergunta, um agente pode precisar de um registo estruturado de cliente, de uma transação recente, de um manual em PDF, de uma transcrição de atendimento e de telemetria ao vivo. Os dados não estruturados e de streaming tornam-se partes de primeira classe da arquitetura mesmo quando não pertencem à base de dados do CRM, e o arquiteto continua a precisar de 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 sua carga de trabalho é operacional, analítica, de streaming ou uma mistura.
• Com que rapidez muda, e com que rapidez outros sistemas precisam realmente de ver a mudança.
• Como o volume e o ciclo de vida definem onde vive e durante quanto tempo.
• Se o Salesforce deve ser dono dele, guardar uma cópia, referenciá-lo, ou deixá-lo num lugar mais adequado à carga de trabalho.

Quando alguém lhe entregar um requisito, não salte para que objeto, que campo, que 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 a tentar 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 serem 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), secção 4 (volumes).