Uma lacuna principal era que o data lake era construído e mantido por uma equipe separada de engenharia ou análise, que não entendia os dados tão profundamente quanto as equipes de origem. Normalmente, havia várias cópias ou versões ligeiramente modificadas dos mesmos dados circulando, juntamente com problemas de precisão e integridade. Cada erro nos dados exigiria diversas discussões e, eventualmente, levaria de volta à equipe de origem para corrigir o problema. Qualquer nova coluna adicionada às tabelas de origem exigiria ajustes nos fluxos de trabalho de várias equipes antes que os dados finalmente chegassem às equipes de análise. Essas lacunas entre as equipes de origem e de análise levaram a atrasos na implementação e até mesmo à perda de dados. As equipes começaram a ter reservas quanto a colocar seus dados em um data lake centralizado.
A arquitetura de malha de dados prometeu resolver esses problemas. Uma abordagem totalmente oposta a um data lake, uma malha de dados dá à equipe de origem a propriedade dos dados e a responsabilidade de distribuir o conjunto de dados. Outras equipes acessam os dados diretamente do sistema de origem, em vez de um data lake centralizado. A malha de dados foi projetada para ser tudo o que o sistema de data lake não era. Não há fluxos de trabalho separados para migração. Menos verificações de integridade de dados. Maior precisão, menos duplicação de dados e tempo de resposta mais rápido em problemas de dados. Acima de tudo, como cada conjunto de dados é mantido pela equipa que melhor o conhece, os consumidores dos dados podem estar muito mais confiantes na sua qualidade.
Por que os usuários perderam a fé na malha de dados
Mas a empolgação em torno da malha de dados não durou. Muitos usuários ficaram frustrados. Abaixo da superfície, quase todos os gargalos entre provedores e consumidores de dados tornaram-se um desafio de implementação. O fato é que a abordagem da malha de dados não é uma mudança feita uma vez, mas um compromisso de longo prazo para preparar um esquema de dados de uma determinada maneira. Embora cada equipe de origem possua seu conjunto de dados, ela deve manter um esquema que permita que os sistemas downstream leiam os dados, em vez de replicá-los. No entanto, uma falta geral de formação e adesão da liderança levou a um planeamento de esquema inadequado, o que, por sua vez, levou a que várias equipas executassem ações semelhantes nos mesmos dados, resultando na duplicação de dados e esforços e no aumento dos custos de computação.
