Como compartilhar dados em uma organização

Question

Quais são algumas boas maneiras de uma organização compartilhar dados importantes entre vários departamentos e aplicações?

Para dar um exemplo, digamos que haja um aplicativo e banco de dados primário para gerenciar os dados do cliente.Existem dez outros aplicativos e bancos de dados na organização que leem esses dados e os relacionam com seus próprios dados.Atualmente esse compartilhamento de dados é feito através de uma mistura de links de banco de dados (BD), visualizações materializadas, gatilhos, tabelas intermediárias, recodificação de informações, serviços web, etc.

Existem outras boas abordagens para compartilhar dados?E como suas abordagens se comparam às acima no que diz respeito a questões como:

dados duplicados

processos de sincronização de dados propensos a erros

apertado vs.acoplamento fraco (reduzindo dependências/fragilidade/coordenação de teste)

simplificação arquitetônica

segurança

desempenho

interfaces bem definidas

outras preocupações relevantes?

Lembre-se de que os dados compartilhados do cliente são usados ​​de várias maneiras, desde consultas simples e de registro único até junções complexas, com vários predicados e várias classificações, com outros dados da organização armazenados em diferentes bancos de dados.

Obrigado pelas suas sugestões e conselhos...

Answer 1

Tenho certeza que você previu isso, "Depende".

Depende de tudo.E a solução para compartilhar dados do Cliente para o departamento A pode ser completamente diferente para compartilhar dados do Cliente com o departamento B.

Meu conceito favorito que surgiu ao longo dos anos é o conceito de “Consistência Eventual”.O termo veio da Amazon falando sobre sistemas distribuídos.

A premissa é que, embora o estado dos dados em uma empresa distribuída possa não ser perfeitamente consistente agora, “eventualmente” será.

Por exemplo, quando um registro de cliente é atualizado no sistema A, os dados do cliente do sistema B agora ficam obsoletos e não correspondem.Mas, “eventualmente”, o registro de A será enviado para B através de algum processo.Então, eventualmente, as duas instâncias irão corresponder.

Quando você trabalha com um único sistema, você não tem “EC”, mas sim atualizações instantâneas, uma única “fonte de verdade” e, normalmente, um mecanismo de bloqueio para lidar com condições de corrida e conflitos.

Quanto mais capazes suas operações forem capazes de trabalhar com dados “EC”, mais fácil será separar esses sistemas.Um exemplo simples é um Data Warehouse usado por vendas.Eles usam o DW para gerar seus relatórios diários, mas não os executam até o início da manhã e sempre analisam os dados de “ontem” (ou anteriores).Portanto, não há necessidade em tempo real de que o DW seja perfeitamente consistente com o sistema de operações diárias.É perfeitamente aceitável que um processo seja executado, digamos, no fechamento do expediente e se mova ao longo do dia, transações e atividades em massa, em uma operação de atualização grande e única.

Você pode ver como esse requisito pode resolver muitos problemas.Não há disputa pelos dados transacionais, não se preocupe, pois alguns dados de relatórios serão alterados no meio do acúmulo da estatística porque o relatório fez duas consultas separadas ao banco de dados ativo.Não há necessidade de conversas de alto detalhe sugarem o processamento da rede e da CPU, etc.durante o dia.

Agora, esse é um exemplo extremo, simplificado e muito grosseiro de CE.

Mas considere um sistema grande como o Google.Como consumidores de pesquisa, não temos ideia de quando ou quanto tempo leva para um resultado de pesquisa que o Google coleta aparecer em uma página de pesquisa.1ms?1s?10s?10 horas?É fácil imaginar como, se você acessar os servidores da Costa Oeste do Google, poderá muito bem obter um resultado de pesquisa diferente do que se acessasse os servidores da Costa Leste.Em nenhum momento esses dois casos são completamente consistentes.Mas, em grande medida, eles são em sua maioria consistentes.E para seu caso de uso, seus consumidores não são realmente afetados pelo atraso.

Considere o e-mail.A deseja enviar uma mensagem para B, mas no processo a mensagem é roteada pelos sistemas C, D e E.Cada sistema aceita a mensagem, assume total responsabilidade por ela e depois a transfere para outro.O remetente vê o e-mail seguir seu caminho.O receptor realmente não sente falta disso porque não necessariamente sabe que está chegando.Portanto, pode levar uma grande janela de tempo para que essa mensagem se mova pelo sistema sem que ninguém preocupado saiba ou se importe com a rapidez com que ela é.

Por outro lado, A poderia estar ao telefone com B.“Acabei de enviar, você já recebeu?Agora?Agora?Obtê-lo agora?"

Portanto, existe algum tipo de nível subjacente e implícito de desempenho e resposta.No final, "eventualmente", a caixa de saída de A corresponde à caixa de entrada de B.

Esses atrasos, a aceitação de dados desatualizados, sejam eles de um dia ou de 1 a 5 segundos, são o que controlam o acoplamento final de seus sistemas.Quanto mais flexível for esse requisito, mais flexível será o acoplamento e mais flexibilidade você terá à sua disposição em termos de design.

Isso se aplica aos núcleos da sua CPU.Aplicativos modernos, multicore e multithread, executados no mesmo sistema, podem ter visualizações diferentes dos "mesmos" dados, desatualizados apenas em microssegundos.Se o seu código pode funcionar corretamente com dados potencialmente inconsistentes entre si, feliz dia, ele segue em frente.Caso contrário, você precisa prestar atenção especial para garantir que seus dados sejam completamente consistentes, usando técnicas como qualificações de memória volátil ou construções de bloqueio, etc.Tudo isso, à sua maneira, custa desempenho.

Então, esta é a consideração básica.Todas as outras decisões começam aqui.Responder a isso pode lhe dizer como particionar aplicativos entre máquinas, quais recursos são compartilhados e como eles são compartilhados.Quais protocolos e técnicas estão disponíveis para mover os dados e quanto custará em termos de processamento para realizar a transferência.Replicação, balanceamento de carga, compartilhamentos de dados, etc.etc.Tudo baseado neste conceito.

Edite, em resposta ao primeiro comentário.

Correto, exatamente.O jogo aqui, por exemplo, se B não pode alterar os dados do cliente, qual é o problema com a alteração dos dados do cliente?Você pode “arriscar” que ele fique desatualizado por um curto período de tempo?Talvez os dados do seu cliente cheguem devagar o suficiente para que você possa replicá-los de A para B imediatamente.Digamos que o troco seja colocado em uma fila que, devido ao baixo volume, é coletada prontamente (<1s), mas mesmo assim estaria "fora de transação" com o troco original e, portanto, há uma pequena janela onde A teria dados que B não possui.

Agora a mente realmente começa a girar.O que acontece durante esses 1s de “lag”, qual é o pior cenário possível.E você pode projetar isso?Se você puder projetar em torno de um atraso de 1s, poderá conseguir projetar em torno de um atraso de 5s, 1m ou até mais.Quanto dos dados do cliente você realmente usa em B?Talvez B seja um sistema projetado para facilitar a separação de pedidos no estoque.É difícil imaginar que seja necessário algo mais do que simplesmente um ID de cliente e talvez um nome.Apenas algo para identificar grosseiramente a quem se destina o pedido enquanto ele está sendo montado.

O sistema de separação não precisa necessariamente imprimir todas as informações do cliente até o final do processo de separação, e até então o pedido pode ter passado para outro sistema que talvez seja mais atualizado, principalmente com informações de remessa, então no final das contas, o sistema de separação praticamente não precisa de nenhum dado do cliente.Na verdade, você pode INCORPORAR e desnormalizar as informações do cliente no pedido de separação, para que não haja necessidade ou expectativa de sincronização posterior.Contanto que o ID do cliente esteja correto (que nunca mudará de qualquer maneira) e o nome (que muda tão raramente que não vale a pena discutir), essa é a única referência real que você precisa, e todos os seus recibos de coleta estão perfeitamente precisos no momento de criação.

O truque é a mentalidade de desmembrar os sistemas e focar nos dados essenciais necessários para a tarefa.Os dados desnecessários não precisam ser replicados ou sincronizados.As pessoas se irritam com coisas como desnormalização e redução de dados, especialmente quando pertencem ao mundo da modelagem de dados relacionais.E com razão, deve ser considerado com cautela.Mas uma vez distribuído, você desnormalizou implicitamente.Caramba, você está copiando no atacado agora.Então, você pode muito bem ser mais esperto sobre isso.

Tudo isso pode ser mitigado por meio de procedimentos sólidos e compreensão completa do fluxo de trabalho.Identifique os riscos e elabore políticas e procedimentos para lidar com eles.

Mas a parte difícil é quebrar a cadeia para o banco de dados central no início e instruir as pessoas de que elas não podem "ter tudo", como esperam quando você tem um armazenamento de informações único, central e perfeito.

Answer 2

Definitivamente, esta não é uma resposta abrangente.Desculpe, pela minha longa postagem e espero que acrescente às reflexões que seriam apresentadas aqui.

Tenho algumas observações sobre alguns dos aspectos que você mencionou.

duplicate data

Pela minha experiência, isso geralmente é um efeito colateral da departamentalização ou especialização.Um departamento é pioneiro na coleta de determinados dados que são considerados úteis por outros grupos especializados.Como eles não têm acesso exclusivo a esses dados, pois estão misturados com outras coletas de dados, para utilizá-los, eles também passam a coletar/armazenar os dados, tornando-os inerentemente duplicados.Esse problema nunca desaparece e, assim como há um esforço contínuo para refatorar o código e remover duplicações, há uma necessidade de trazer continuamente dados duplicados para acesso, armazenamento e modificação centralizados.

well-defined interfaces

A maioria das interfaces é definida com boas intenções, tendo em mente outras restrições.No entanto, simplesmente temos o hábito de superar as restrições impostas pelas interfaces previamente definidas.Novamente um caso para refatoração contínua.

tight coupling vs loose coupling

Na verdade, a maioria dos softwares é afetada por esse problema.O forte acoplamento é geralmente o resultado de uma solução conveniente, dada a restrição de tempo que enfrentamos.O fraco acoplamento incorre num certo grau de complexidade que não gostamos quando queremos fazer as coisas.O mantra dos serviços da web já existe há vários anos e ainda estou para ver um bom exemplo de solução que alivie completamente a questão

architectural simplification

Para mim, esta é a chave para combater todos os problemas que você mencionou na sua pergunta.A história de SIP vs H.323 VoIP vem à minha mente.O SIP é muito simplificado e fácil de construir, enquanto o H.323, como um padrão típico de telecomunicações, tenta prever todos os problemas do planeta sobre VoIP e fornecer uma solução para eles.Resultado final, o SIP cresceu muito mais rapidamente.É uma pena ser uma solução compatível com H.323.Na verdade, a conformidade com o H.323 é uma indústria extremamente lucrativa.

On a few architectural fads that I have grown up to.

Com o passar dos anos, comecei a gostar da arquitetura REST por sua simplicidade.Ele fornece um acesso simples e exclusivo aos dados e fácil de construir aplicativos em torno deles.Já vi soluções empresariais sofrerem mais com duplicação, isolamento e acesso a dados do que qualquer outro problema, como desempenho, etc.REST para mim fornece uma panacéia para alguns desses males.

Answer 3

Para resolver vários desses problemas, gosto do conceito de "Data Hubs" centrais.Um Data Hub representa uma "fonte única de verdade" para uma entidade específica, mas armazena apenas IDs, nenhuma informação como nomes, etc.Na verdade, ele armazena apenas mapas de ID - por exemplo, eles mapeiam o ID do Cliente no sistema A, para o Número do Cliente no sistema B e para o Número do Cliente no sistema C.As interfaces entre os sistemas utilizam o hub para saber como relacionar as informações de um sistema com o outro.

É como uma tradução central;em vez de ter que escrever código específico para mapeamento de A->B, A->C e B->C, com seu aumento exponencial de frequência à medida que você adiciona mais sistemas, você só precisa converter de/para o hub:A->Hub, B->Hub, C->Hub, D->Hub, etc.