O papel fundamental da arquitetura de dados (em um mundo focado em analítica)

Há um ditado no exército: “Amadores discutem táticas, mas profissionais estudam logística.” Esse pensamento pode ser surpreendente para alguns à primeira vista, ao pensar sobre o brilhantismo de Lee em Chancellorsville, ou o gênio de Aníbal durante as Guerras Púnicas; no entanto, a história observa que nem Lee nem Aníbal venceram suas respectivas guerras. O principal motivo foi a logística: a capacidade de manter um exército abastecido com alimentos, roupas e armas, na hora certa e no lugar certo. Apesar das táticas brilhantes, foi a logística que finalmente decidiu a vitória. Em outras palavras, as táticas permitem que você faça o melhor uso dos recursos que você tem em campo, mas a logística permite que você esteja e permaneça em campo em primeiro lugar.

Gosto da analogia militar porque acredito que ela tem paralelos com a forma como as soluções baseadas em dados são frequentemente retratadas hoje em dia. O glamour das “táticas” — técnicas avançadas de IA, como aprendizado profundo, classificação de floresta aleatória, aumento de gradiente e assim por diante — regularmente ofusca a “logística” menos atraente das bases da arquitetura de dados que permitem essas técnicas avançadas.

O primeiro passo em uma discussão sobre arquitetura de dados é definir o que o conceito de “arquitetura de dados” abrange. Não é de surpreender que a resposta seja diferenciada: ela é complexa e multifacetada. Para ajudar a fundamentar a discussão, é útil começar pensando em termos da jornada dos dados de telemetria coletados. O diagrama abaixo mostra um pipeline de dados de alto nível, destacando os pontos de contato entre o pipeline e a base da arquitetura de dados.

A jornada de cada elemento de dados começa com sua criação, geralmente seguida por uma certa quantidade de pré-processamento antes de ser serializado e transmitido para um coletor/agregador de dados, normalmente residindo na nuvem. Em seguida, o próprio coletor de dados pode (após a desserialização e ingestão) executar algum processamento e enriquecimento adicionais antes de entregar os dados a um armazenamento de dados persistente e/ou alimentar um pipeline de análise de dados. Por fim, os resultados enriquecidos/analisados são disponibilizados para consumo humano usando uma plataforma de visualização e podem até mesmo ser consumidos por sistemas automatizados na forma de entradas de feedback para sistemas de circuito fechado de autoajuste ou autorremediação.

Com o contexto do pipeline de dados estabelecido, podemos agora retornar à questão de entender o que significa “arquitetura de dados”. A primeira resposta, no nível mais superficial, está focada na representação de dados e na sintaxe de serialização. Por exemplo, se um evento de dados contiver um campo de objeto intitulado "cliente", a visualização sintática determinará se esses dados são representados como uma string, um UUID inteiro ou outra coisa.

No entanto, se cavarmos um pouco mais fundo, uma segunda resposta é sobre algo mais do que mera sintaxe; é a preocupação com a semântica dos dados — ter uma interpretação bem definida e consistente do conteúdo dos dados. Mais uma vez, usando o campo ‘cliente’ como exemplo, suponha que a questão sintática foi respondida — que de fato o elemento de dados foi definido como um campo de string. Em seguida, a arquitetura de dados deve ser capaz de responder à questão de significado/interpretação: a semântica é do nome de uma pessoa individual ou é do nome de uma empresa? Se for o nome de uma pessoa, é <sobrenome> ou <primeiro nome> ou ambos?  Quando combinada com uma sintaxe uniforme, a semântica consistente permite que o pipeline de dados execute funções como filtragem e agregação de dados de forma genérica e robusta, com base em uma interpretação lógica coerente do conteúdo dos dados. Além disso, o armazenamento de dados também pode executar facilmente consultas de dados federados em diferentes instâncias de pipeline de criação de dados, desde que os dados criados sigam uma sintaxe e semântica consistentes.

Por fim, indo mais a fundo, em muitos casos é importante ter uma terceira capacidade na arquitetura de dados: um vocabulário para contextualizar a telemetria e raciocinar sobre os dados em si — o vocabulário de metadados. Isso é especialmente importante no contexto dos requisitos de governança de dados corporativos, seja para conformidade, auditoria ou mesmo para fluxos de trabalho internos que exigem uma compreensão holística dos dados gerenciados em um data warehouse. Os metadados geralmente vêm na forma de anotações nos dados, com as anotações seguindo o mesmo tipo de consistência sintática e semântica que os próprios dados. Por exemplo, campos de metadados provavelmente seriam usados para registrar a identidade da fonte de dados, o cronograma do processamento de dados para quaisquer dados coletados, para cumprir com o requisito legal de retenção de dados.

Outra maneira pela qual os campos de metadados podem ser usados no léxico de um esquema de descrição de dados é para raciocinar sobre aspectos dos próprios campos de dados, como a ordinalidade de um elemento de dados ou as sensibilidades de privacidade. Voltando ao nosso exemplo de campo de dados 'cliente' mais uma vez, as anotações de metadados no esquema de dados podem marcar o elemento de dados como exclusivo , enquanto anotações adicionais, no contexto de um fluxo de dados (como para transações de compra no varejo), podem marcar elementos de dados como obrigatórios e singleton — em outras palavras, os metadados seriam usados para dizer que o campo customerID deve ser exclusivo (utilizável como uma chave primária do banco de dados) e que cada evento de compra deve ter um, e exatamente um, customerID associado. A utilidade da totalidade dos recursos de metadados, dentro do contexto do pipeline de dados, é o fato de que eles podem ser aproveitados para adicionar anotações para conformidade de dados, fornecer léxico de enriquecimento de dados e permitir fluxos de trabalho de governança flexíveis para o data warehouse.

Então, em resumo, a resposta para a pergunta: “O que é Arquitetura de Dados?” é que se trata, no mínimo, de fornecer uma estrutura que permita consistência, tanto sintática quanto semântica, aos dados coletados. Além disso, uma arquitetura de dados robusta também deve abranger uma estratégia de metadados que seja poderosa o suficiente para não apenas especificar restrições sobre os dados, mas também incluir a capacidade de raciocinar sobre os dados em si. 

Quando considerada uma área de foco explícita e bem executada, uma arquitetura de dados é muito parecida com uma boa infraestrutura de logística militar. Assim como no contexto militar, ele fornece uma base que multiplica a eficiência e a robustez de todos os componentes dos sistemas que são construídos sobre ele, permitindo que aqueles sistemas mais visíveis sejam utilizados com o máximo efeito. No contexto de um sistema de processamento de dados, a base da arquitetura de dados fornece a base para modelos mais flexíveis e poderosos para governança de dados, compartilhamento de dados mais fácil entre fontes de dados usando um data warehouse robusto e uma abordagem mais responsiva para ingestão de novos feeds de dados para agilidade empresarial.