Uma miríade de abordagens diferentes para mover e mesclar dados que dão suporte a processos de negócios e tomada de decisão foram criadas ao longo dos anos. Cada uma com suas capacidades e benefícios virtuais únicos. Entender essas capacidades e como elas se relacionam com o resultado desejado da sua estratégia de dados é essencial para projetar um sistema ideal.
Diversas variáveis e requisitos devem ser considerados ao criar uma estratégia para manter todos os seus dados otimizados, acessíveis e integrados, incluindo:
O processamento em lote transfere dados em intervalos regulares ou em lotes. Esses padrões incluem Extract Transform Load (ETL), Extract Load Transform (ELT), Reverse ETL, Mirroring ou Replication e ferramentas Write-back.
ETL é a abordagem tradicional para mover dados. Os dados são extraídos de uma fonte de dados, transformados com base em regras de negócios e carregados em um banco de dados de destino. Essa abordagem pode ser muito segura, mas também inflexível. Essa rigidez exige que os conjuntos de dados sejam muito estruturados e documentados, o que torna as transformações complexas mais fáceis. Com bancos de dados de sistemas legados tipicamente muito estruturados e rígidos, ETL é uma boa opção para esses sistemas. Para construir esses processos, os desenvolvedores devem ter um conhecimento profundo de estrutura de dados e linguagens de programação.
ELT é semelhante a ETL, mas a transformação ocorre após carregá-la no banco de dados de destino. Essa abordagem mais contemporânea permite mais flexibilidade porque os dados brutos permanecem no banco de dados de destino após serem transformados. Consequentemente, as transformações podem ser executadas iterativamente ou retroativamente sem extrair dados da fonte de dados original, reduzindo os recursos necessários para extrair um novo conjunto de dados. ELT é mais adequado para conjuntos de dados mais extensos e menos estruturados, onde a manipulação de dados e as transformações podem ser executadas mais perto do usuário final.
ETL reverso é outro processo em lote, mas os dados fluem na direção oposta de um pipeline de ETL. Os dados são extraídos de um aplicativo operacional de terceiros e carregados em um banco de dados central. Essa abordagem permite que uma organização consolide uma versão de um conjunto de dados em um warehouse central e permite que aplicativos operacionais usem os mesmos dados que outros aplicativos ou análises podem estar usando. ETL reverso suporta uma "única fonte de verdade" para a organização.
O desafio é que o ETL reverso opera em lotes. Em organizações dinâmicas onde os dados mudam constantemente, grupos distintos podem usar versões diferentes dos mesmos dados devido a diferentes cronogramas de atualização. As estratégias de sincronização do ETL reverso também podem sobrecarregar os sistemas operacionais, pois grandes quantidades de dados são carregadas em sistemas operacionais de várias fontes. Isso pode levar a conflitos e versões de dados dos mesmos dados.
O espelhamento e a replicação salvam dados em um banco de dados separado sem nenhuma transformação e são frequentemente implementados para fazer backup de conjuntos de dados em caso de perda de dados. Eles também podem ser valiosos na otimização do gerenciamento de dados e na criação de um conjunto de dados persistente quando os dados estão em movimento. O espelhamento replica não apenas os dados, mas também toda a estrutura do banco de dados e o sistema de gerenciamento.
A replicação é um pouco diferente do espelhamento porque não copia o sistema de gerenciamento de banco de dados, apenas os dados. Acessar dados de vários sistemas é muito mais fácil com a replicação, pois um sistema de gerenciamento de banco de dados não os define.
O espelhamento é uma opção melhor para balanceamento de carga. Os bancos de dados de origem e copiados são idênticos, então os dados podem ser acessados de qualquer fonte facilmente. Recuperação de desastres e otimização do uso de recursos são casos de uso comuns para espelhamento. Ele também é adequado para capturar um instantâneo de dados em movimento. Por exemplo, dados virtualizados que são usados regularmente podem ser espelhados para um armazenamento de dados persistente.
Integrar e gerenciar dados em tempo real cria muitas complexidades, particularmente ao mesclar conjuntos de dados diversos. Com diferentes conjuntos de dados mudando constantemente, discrepâncias entre os dados de origem e mesclados sempre existirão. Dados em tempo real são mais aplicáveis em sistemas operacionais que rastreiam sensores ou dados financeiros.
CDC é um padrão baseado em eventos onde as alterações em um banco de dados são automaticamente refletidas em outro quando eventos definidos ocorrem. Esse padrão suporta fluxos de dados bidirecionais para que os bancos de dados de origem e destino possam trocar dados para garantir a sincronização. CDC é uma maneira muito mais eficiente de mover dados do que ETL, pois apenas os dados que mudam são transferidos para o banco de dados de destino, não o conjunto de dados inteiro.
O CDC funciona bem com bancos de dados ou aplicativos que não podem ser integrados. Os processos do CDC podem preparar dados em um banco de dados separado, e as alterações podem então ser compartilhadas dos dados preparados para bancos de dados de destino. Esse método requer a manutenção de uma fonte de dados dinâmica separada, criando complexidade excessiva e levando a um maior potencial para erros.
O streaming de dados envolve ingestão, processamento e movimentação constantes de dados para seu destino. Normalmente, isso significa dados de sensores de dados de serviços financeiros. Em muitos casos, o streaming é transformado a caminho de seu banco de dados de destino.
Embora o streaming de dados seja rápido, há algumas desvantagens. O streaming de dados está em constante movimento e tomando diferentes caminhos pela internet, portanto, garantir que os dados sejam processados na ordem correta não é garantido. Alguns dados podem chegar para serem processados depois de dados mais recentes, criando confusão sobre os dados mais precisos. A orquestração adequada precisa ser implementada para garantir que os dados sejam processados na ordem apropriada.
O streaming de dados também expõe o modelo de dados da fonte de dados para usuários downstream. Quando aplicativos downstream são conectados diretamente ao modelo de dados de origem, alterações nesse modelo causam estragos downstream.
Se os dados de streaming forem empacotados dentro de um produto de dados, os modelos de dados de origem interna podem ser mapeados para o modelo de dados de um produto de dados. Essa estrutura facilita o compartilhamento de dados com grupos externos.
Os recursos de write-back das ferramentas de BI front-end são outro método para fazer alterações em um banco de dados de origem. Esse padrão emergente permite que analistas que trabalham com ferramentas de BI incluam alterações no banco de dados de origem diretamente da ferramenta de BI. Essas alterações são imediatamente refletidas na fonte de dados e no trabalho dos analistas. Isso permite que o analista que tem o melhor entendimento dos dados ajuste ou corrija a fonte de dados original.
Os recursos de write-back também reduzem a dependência dos analistas de dados em planilhas do Excel, pois agora eles têm o poder de atualizar um banco de dados tão rapidamente quanto no Excel.
Os aplicativos SaaS geralmente compartilham dados por meio de APIs REST. Esses são processos diretos para extrair dados de um banco de dados de aplicativo. Por si só, as APIs não podem transformar dados, mas se executadas por meio de uma plataforma iPaaS, processos de transformação automatizados podem ser realizados nos dados antes de enviá-los ao aplicativo de destino.
APIs REST funcionam bem para trocas simples de dados entre um aplicativo ou dois, mas esse tipo de abordagem não escala bem. Se um aplicativo altera sua API, os aplicativos downstream podem quebrar.
A virtualização de dados é a prática de executar código que cria um novo conjunto de dados virtualizados extraídos de bancos de dados conectados. Esse novo conjunto de dados é criado toda vez que o código é executado, mas os dados são mantidos apenas pelo tempo necessário. Esse é o padrão que a plataforma Avrio usa para gerar conjuntos de dados para análise. Há vários benefícios em usar essa tecnologia para integração de dados:
Primeiro, a virtualização de dados separa o banco de dados e a estrutura subjacentes dos dados em si. Isso torna a virtualização de dados muito mais escalável e flexível.
Segundo, a virtualização de dados não cria uma cópia persistente do banco de dados. Como um novo conjunto de dados é criado a cada vez, o código é executado e os dados mais recentes são extraídos do banco de dados de origem. Essa abordagem evita conflitos entre várias versões dos mesmos dados. Os custos de armazenamento também podem ser minimizados.
Terceiro, conectores sofisticados, mecanismos de consulta federados e virtualização podem consultar, transformar e mesclar dados de vários bancos de dados de uma só vez. Com um repositório de metadados consolidado e um modelo de dados unificado em camadas, essa abordagem permite que analistas de dados extraiam dados de vários repositórios de dados como se fossem um único banco de dados.
Por fim, a virtualização de dados permite mais controle sobre seus dados. Como os dados estão se movendo por essa camada de virtualização, verificações de qualidade de dados podem ser executadas e controles de acesso granulares podem ser implementados.
Cada abordagem de integração e sincronização tem seus benefícios e desvantagens. Independentemente da sua abordagem, a atenção à governança, segurança e qualidade dos dados é primordial para uma arquitetura de dados saudável. Usar abordagens adequadas em conjunto em uma plataforma consolidada pode resultar em uma solução poderosa e flexível.
O núcleo da capacidade do Avrio é a virtualização de dados, que é usada para integrar dados para análise para criar um novo conjunto de dados cada vez que o código é executado. Quando dados persistentes são necessários, mas há mudanças regulares, o Avrio também apresenta recursos de CDC que espelharão apenas as mudanças no banco de dados de origem para o ambiente espelhado.
O Avrio também apresenta recursos de espelhamento para criar conjuntos de dados persistentes a partir de conjuntos de dados virtualizados. Quando os dados não mudam com frequência, mas são usados regularmente, o espelhamento pode reduzir o uso de recursos de largura de banda.
A plataforma Avrio permite acesso de terceiros a produtos de dados por meio de uma API. Essa camada front-end da Avrio também apresenta recursos de write-back para incorporar alterações feitas em uma ferramenta de BI com o banco de dados back-end conectado à plataforma Avrio.
Combinar vários padrões de integração e sincronização para atingir um resultado comercial faz sentido estratégico. Cada situação é diferente e requer capacidades únicas. A plataforma Avrio combina as tecnologias e padrões certos para tornar os dados acessíveis em vários silos de dados com produtos de dados self-service que têm governança e segurança integradas — projetados para a era da IA, análise rápida e melhor tomada de decisão.
A Avrio também se encaixa bem com suas ferramentas de integração e infraestrutura existentes. Se você estiver transmitindo dados para um data lake, a Avrio pode criar um produto de dados para capturar um instantâneo dos dados de streaming para análise. Se você construiu pipelines ETL que são bem estabelecidos e não mudam muito, a Avrio pode incorporar esses dados em um produto de dados que pode torná-los mais acessíveis e integrar conjuntos de dados de outros sistemas.