O termo “tecido de dados” é usado em toda a indústria de tecnologia, mas sua definição e implementação podem variar. Eu vi isso em todos os fornecedores: no outono do ano passado, a British Telecom (BT) falou sobre seu tecido de dados em um evento de analista; Enquanto isso, em armazenamento, o NetApp vem reorientando sua marca para a infraestrutura inteligente, mas estava usando o termo anteriormente. O fornecedor da plataforma de aplicativos Appian possui um produto de tecido de dados, e o provedor de banco de dados MongoDB também tem falado sobre tecidos de dados e idéias semelhantes.
Em sua essência, um tecido de dados é uma arquitetura unificada que abstrair e integra fontes de dados díspares para criar uma camada de dados perfeita. O princípio é criar uma camada unificada e sincronizada entre fontes de dados díspares e as cargas de trabalho que precisam de acesso a dados – seus aplicativos, cargas de trabalho e, cada vez mais, seus algoritmos de IA ou mecanismos de aprendizado.
Existem muitas razões para querer essa sobreposição. O tecido de dados atua como uma camada de integração generalizada, conectando -se a diferentes fontes de dados ou adicionando recursos avançados para facilitar o acesso a aplicativos, cargas de trabalho e modelos, como permitir o acesso a essas fontes, mantendo -os sincronizados.
Até agora tudo bem. O desafio, no entanto, é que temos uma lacuna entre o princípio de um tecido de dados e sua implementação real. As pessoas estão usando o termo para representar coisas diferentes. Para retornar aos nossos quatro exemplos:
- O BT define o tecido de dados como uma sobreposição de nível de rede projetada para otimizar a transmissão de dados em longas distâncias.
- A interpretação do NetApp (mesmo com o termo infraestrutura de dados inteligentes) enfatiza a eficiência do armazenamento e o gerenciamento centralizado.
- Appian posiciona seu produto de tecido de dados como uma ferramenta para unificar dados na camada de aplicativos, permitindo o desenvolvimento e a personalização mais rápidos das ferramentas voltadas para o usuário.
- MongoDB (e outros provedores de solução de dados estruturados) consideram os princípios de tecido de dados no contexto da infraestrutura de gerenciamento de dados.
Como cortamos tudo isso? Uma resposta é aceitar que podemos abordá -lo de vários ângulos. Você pode falar sobre o tecido de dados conceitualmente – reconhecendo a necessidade de reunir fontes de dados – mas sem ultrapassar. Você não precisa de um “Uber-Fabric” universal que cobre absolutamente tudo. Em vez disso, concentre -se nos dados específicos que você precisa gerenciar.
Se rebobinarmos algumas décadas, podemos ver semelhanças com os princípios da arquitetura orientada a serviços, que procurou desacoplar a provisão de serviços dos sistemas de banco de dados. Naquela época, discutimos a diferença entre serviços, processos e dados. O mesmo se aplica agora: você pode solicitar um serviço ou solicitar dados como serviço, com foco no que é necessário para sua carga de trabalho. Criar, ler, atualizar e excluir continuam sendo os mais diretos dos serviços de dados!
Também me lembro das origens da aceleração da rede, que usaria o cache para acelerar as transferências de dados, mantendo as versões de dados localmente, em vez de acessar repetidamente a fonte. A Akamai construiu seus negócios sobre como transferir conteúdo não estruturado, como música e filmes com eficiência e a longas distâncias.
Isso não sugere que os tecidos de dados estejam reinventando a roda. Estamos em um mundo diferente (baseado em nuvem) tecnologicamente; Além disso, eles trazem novos aspectos, principalmente em torno de gerenciamento de metadados, rastreamento de linhagem, recursos de conformidade e segurança. Eles são especialmente críticos para as cargas de trabalho de IA, onde a governança de dados, a qualidade e a proveniência afetam diretamente o desempenho do modelo e a confiabilidade.
Se você está pensando em implantar um tecido de dados, o melhor ponto de partida é pensar no que deseja os dados. Isso não apenas ajudará a orientá -lo para que tipo de tecido de dados pode ser o mais apropriado, mas essa abordagem também ajuda a evitar a armadilha de tentar gerenciar todos os dados do mundo. Em vez disso, você pode priorizar o subconjunto de dados mais valioso e considerar qual nível de tecido de dados funciona melhor para suas necessidades:
- Nível de rede: Para integrar dados em ambientes multi-nuvem, local e borda.
- Nível de infraestrutura: Se seus dados forem centralizados com um fornecedor de armazenamento, concentre -se na camada de armazenamento para servir pools de dados coerentes.
- Nível de aplicação: Reunir conjuntos de dados díspares para aplicativos ou plataformas específicas.
Por exemplo, no caso da BT, eles encontraram valor interno no uso de seus tecidos de dados para consolidar dados de várias fontes. Isso reduz a duplicação e ajuda a simplificar as operações, tornando o gerenciamento de dados mais eficiente. É claramente uma ferramenta útil para consolidar silos e melhorar a racionalização do aplicativo.
No final, o tecido de dados não é uma solução monolítica e de tamanho único. É uma camada conceitual estratégica, apoiada por produtos e recursos, que você pode aplicar onde faz mais sentido adicionar flexibilidade e melhorar a entrega de dados. O tecido de implantação não é um exercício “Defina e esqueça”: requer esforço contínuo para escopo, implantar e manter – não apenas o próprio software, mas também a configuração e integração de fontes de dados.
Embora um tecido de dados possa existir conceitualmente em vários lugares, é importante não replicar os esforços de entrega desnecessariamente. Portanto, se você está reunindo dados em toda a rede, dentro da infraestrutura ou no nível do aplicativo, os princípios permanecem os mesmos: use -os onde for mais apropriado para suas necessidades e permita que ele evolua com os dados que atende.
