Mas isso nos leva ao nosso quinto problema, que são conjuntos de dados semelhantes, mas diferentes. Por que há múltiplos? Qual devo usar? Esse conjunto de dados ainda é mantido ou é um conjunto de dados zumbi que ainda é atualizado regularmente, mas sem ninguém supervisionando? O problema chega ao auge quando você tem cálculos importantes que discordam entre si, devido à dependência de conjuntos de dados que deveriam ser idênticos, mas não são. Fornecer relatórios, painéis ou métricas conflitantes aos clientes resultará em perda de confiança e, no pior cenário, perda de negócios e até mesmo ação legal.
Mesmo se você resolver todos esses problemas — reduzindo latência, reduzindo custos, removendo pipelines e conjuntos de dados duplicados e eliminando o trabalho de break-fix — você ainda não forneceu nada que as operações possam usar. Elas ainda estão por conta própria, a montante de seus ETLs, porque todo o trabalho de limpeza, estruturação, remodelação e distribuição só é realmente útil para aqueles no espaço de análise de dados.
Mudança para a esquerda para uma arquitetura de dados sem cabeça
Construir uma arquitetura de dados headless requer uma reformulação de como circulamos, compartilhamos e gerenciamos dados em nossas organizações — uma mudança para a esquerda. Extraímos o trabalho ETL->bronze->prata do downstream e o colocamos no upstream dentro de nossos produtos de dados, muito mais perto da fonte.
