O termo “estrutura de dados” é amplamente utilizado na indústria de tecnologia, mas sua definição e implementação podem variar. Estou vendo isso entre os fornecedores: a BT falou sobre sua estrutura de dados em um evento de analistas no outono passado; Enquanto isso, no armazenamento, a NetApp vem reposicionando sua marca como infraestrutura inteligente, mas já usou esse termo anteriormente. O fornecedor de plataforma de aplicativos Appian tem um produto Data Fabric, e o provedor de banco de dados MongoDB tem falado sobre Data Fabric e ideias semelhantes.
Basicamente, a Estrutura de Dados é uma arquitetura unificada que abstrai e integra fontes de dados diferentes para criar uma camada de dados contínua. O princípio é criar uma camada de sincronização unificada entre fontes de dados e cargas de trabalho diferentes que precisam acessar os dados (seus aplicativos, cargas de trabalho e, cada vez mais, algoritmos de inteligência artificial ou mecanismos de aprendizagem).
Existem muitas razões para tal cobertura. Os data fabrics atuam como uma camada de integração comum, conectando fontes de dados diferentes ou adicionando funcionalidades avançadas para facilitar o acesso a aplicativos, cargas de trabalho e modelos, como permitir o acesso a essas fontes de dados enquanto mantém os dados sincronizados.
Até agora tudo bem. No entanto, o desafio reside na lacuna entre os princípios das estruturas de dados e a sua implementação prática. As pessoas usam esse termo para significar coisas diferentes. De volta aos nossos quatro exemplos:
- A BT define a estrutura de dados como cobertura em nível de rede, projetada para otimizar a transmissão de dados em longas distâncias.
- A explicação da NetApp (mesmo usando o termo infraestrutura de dados inteligente) enfatiza a eficiência do armazenamento e o gerenciamento centralizado.
- A Appian posiciona seu produto Data Fabric como uma ferramenta para unificar dados na camada de aplicação, permitindo desenvolvimento e personalização mais rápidos de ferramentas voltadas para o usuário.
- O MongoDB (e outros provedores de soluções de dados estruturados) consideram os princípios de estrutura de dados no contexto da infraestrutura de gerenciamento de dados.
Como podemos superar isso? Uma resposta é aceitar que podemos abordar o problema de vários ângulos. Você pode discutir conceitualmente a estrutura das fontes – reconhecendo a necessidade de reunir as fontes – sem ir muito longe. Você não precisa de uma “superestrutura” geral que cubra tudo. Em vez disso, concentre-se nos dados específicos que você precisa gerenciar.
Se olharmos algumas décadas atrás, podemos ver semelhanças com os princípios da arquitetura orientada a serviços, que visam dissociar a prestação de serviços dos sistemas de banco de dados. Naquela época, discutimos as diferenças entre serviços, processos e dados. O mesmo se aplica agora: você pode solicitar como serviço ou solicitar dados como serviço, concentrando-se no que a carga de trabalho exige. Criar, ler, atualizar e excluir ainda é o serviço de dados mais simples!
Também me lembro das origens da aceleração de rede, que usava cache para acelerar a transferência de dados, salvando uma versão local dos dados em vez de acessar repetidamente a fonte. Os negócios da Akamai se concentram na transmissão eficiente e de longa distância de conteúdo não estruturado, como músicas e filmes.
Isto não quer dizer que as estruturas de dados estejam reinventando a roda. Tecnicamente estamos num mundo diferente (baseado na nuvem); além disso, trazem novos aspectos, especialmente gerenciamento de metadados, rastreamento de linhagem, conformidade e recursos de segurança. Eles são especialmente importantes para cargas de trabalho de IA, onde a governança, a qualidade e a procedência dos dados impactam diretamente o desempenho e a confiabilidade do modelo.
Se você está pensando em implantar uma estrutura de material, o melhor lugar para começar é pensar sobre para que você deseja que o material seja utilizado. Isso não apenas ajuda você a entender qual estrutura de perfil pode ser mais apropriada, mas também ajuda a evitar as armadilhas de tentar gerenciar todos os perfis do mundo. Em vez disso, você pode priorizar os subconjuntos de dados mais valiosos e considerar qual estrutura hierárquica de dados melhor atende às suas necessidades:
- camada de rede: consolide dados em ambientes multinuvem, locais e de borda.
- nível de infraestrutura: se seus dados estiverem centralizados em um provedor de armazenamento, concentre-se nas camadas de armazenamento para servir um conjunto consistente de dados.
- nível de aplicação: Agregue diferentes conjuntos de dados para um aplicativo ou plataforma específica.
Por exemplo, no caso da BT, encontraram valor interno na utilização da sua estrutura de dados para integrar dados de múltiplas fontes. Isto reduz a duplicação e ajuda a agilizar as operações, tornando o gerenciamento de dados mais eficiente. É claramente uma ferramenta útil para consolidar silos e melhorar a racionalização de aplicações.
Finalmente, as estruturas de dados não são uma solução única e que sirva para todos. É uma camada de conceitos estratégicos, apoiados por produtos e recursos, que você pode aplicar onde fizer mais sentido para aumentar a flexibilidade e melhorar a entrega de dados. A arquitetura de implantação não é um exercício do tipo “configure e esqueça”: ela requer um esforço contínuo para definir o escopo, implantar e manter – não apenas o software em si, mas também a configuração e integração de fontes de dados.
Embora as estruturas de dados possam existir conceitualmente em vários locais, é importante não duplicar desnecessariamente os esforços de entrega. Portanto, quer você reúna dados por meio da rede, da infraestrutura ou no nível do aplicativo, o princípio é o mesmo: use-os onde melhor atender às suas necessidades e permita que cresçam com os dados que servem.
A postagem Desmistificando Data Fabrics – Preenchendo a lacuna entre fontes de dados e cargas de trabalho apareceu pela primeira vez no Gigaom.
