Existem muitas maneiras de analisar dados em tempo real. Na VTB, usamos a tecnologia Change Data Capture (CDC) implementada na ferramenta Oracle Golden Gate: a velocidade é muito importante para nós, mas gostaríamos de reduzir a quantidade de dados transmitidos e a carga na fonte. Embora o principal escopo dessa ferramenta seja a replicação do Oracle e do MS SQL, ao longo dos anos de trabalho com o CDC, acumulamos vários casos interessantes, como a migração de dados entre plataformas ou diferentes tipos de DBMS. Sob o corte, compartilharemos nossa experiência com o Golden Gate.
Por que precisamos do CDC (Change Data Capture)
O uso diário de cartões bancários é conhecido há muito tempo e as pessoas, em regra, não pensam que cada uso de um terminal de pagamento seja a transferência imediata de determinadas informações para o banco. Os volumes de dados estão aumentando e eu gostaria de processá-los o mais rápido possível, inclusive para enviar ofertas especiais em tempo real, porque, como eles dizem, uma boa colher para o jantar. E as ferramentas ETL tradicionais (extrair, transformar, carregar - extrair, transformar, carregar) não são tão boas no processamento de dados em tempo real. Aqui está um dos links fracos: quando os dados são obtidos das tabelas do sistema de origem, você precisa selecionar apenas novas linhas ou linhas com alterações. Essa abordagem carrega adicionalmente o sistema de origem e aumenta a quantidade de dados transmitidos.
O CDC captura as alterações dos logs do banco de dados em tempo real. Portanto, a fonte é carregada muito menos e a quantidade de dados transmitidos é reduzida. Com essa tecnologia, reduzimos a necessidade de recursos de computação para sistemas com um grande volume de alterações transacionais: afinal, para captura de dados, mesmo para os sistemas bancários mais carregados, 1-2 núcleos de processador na fonte são suficientes. E se estivéssemos introduzindo o ETL, teríamos que comprar capacidades do processador para ler dados em paralelo.
Há vários anos que usamos a tecnologia Oracle GoldenGate, a ferramenta CDC da Oracle, na VTB. Com sua ajuda, enchemos o armazém de dados operacionais e distribuímos as funções dos sistemas de informação em zonas "quentes" e "quentes". 90% do aplicativo OGG no cenário de TI do banco está carregando dados do Oracle e MS SQL, mas, exceto pela replicação, ele lida com outras tarefas perfeitamente. Vejamos alguns exemplos de nossa prática.
Caso 1. Relatórios online
Conhecemos o GoldenGate em 2013. Em seguida, em nosso complexo de processamento de cartões, as transações foram processadas simultaneamente e os relatórios elaborados. A carga OLTP foi combinada com a carga DWH / DSS e grandes amostras pesadas lavaram o cache da memória do banco de dados. Como resultado, transações rápidas tiveram que ir para o disco rígido, a velocidade dos serviços críticos de negócios estava caindo. Para descarregar o núcleo de processamento, levamos todos os procedimentos e relatórios que desenvolvemos para uma réplica "quente" no Oracle Exadata.
Como replicar dados usando o GoldenGate, descrevemos em detalhes
aqui . Em poucas palavras: para sistemas altamente carregados onde há mistura de diferentes tipos de cargas, os distribuímos para diferentes servidores OLTP e DWH / DSS e, para sincronização entre eles, usamos o GoldenGate. Esse padrão de destacar uma réplica "quente" foi útil em muitos outros casos. Por exemplo, usamos a mesma abordagem em nosso sistema antifraude - transferimos todos os relatórios para os sistemas Oracle Exadata integrados, replicamos os dados para eles usando o GoldenGate.
Não há sistemas sem falhas. Por exemplo, se um desenvolvedor alterar os dados no receptor, poderá ocorrer um erro de uso de dados e os processos do GoldenGate serão interrompidos. Para excluir dados fora de sincronia, usamos o Oracle GoldenGate Veridata como um árbitro independente. Essa ferramenta não apenas verifica dados entre fontes e receptores - o principal é que a Veridata elimina as diferenças. É importante que, quando lidamos com a replicação, a Veridata garanta uma comparação precisa dos dados e a detecção de registros perdidos. Temos um relatório completo com os resultados da comparação, que pode ser apresentado a colegas incrédulos.
Caso 2. Relatórios e preparação consolidados no armazenamento online
Um caso separado está associado à construção do armazenamento operacional. A dificuldade está no fato de que, além dos relatórios operacionais, estamos preparando dados para armazenamento corporativo (armazenamento temporário). Acontece que você precisa gerar relatórios operacionais com base em dados coletados de vários sistemas diferentes. E é mais conveniente fazer isso no nível do armazenamento online. Para obter dados em alta velocidade e com uma carga mínima de recursos, aplicamos novamente o GoldenGate.
Para comparação, vamos explicar como descobrimos o delta de alterações em alguns de nossos sistemas antes. Se o sistema em si não permitiu alocação delta ou alterou dados retroativamente, a tabela da fonte de 10 TB foi comparada com a tabela de 10 TB no receptor no dia anterior. Esses 10 TBs tiveram que ser capturados primeiro na fonte e a carga caiu não apenas no sistema de origem, CPU, memória, mas também na rede de dados, bem como no sistema envolvido na comparação. E tudo isso para encontrar o delta de novos dados em 0,01%!
O GoldenGate praticamente não carrega a fonte: o CDC apenas lê as revistas e produz um delta finalizado. Isso permite que você economize seriamente na infraestrutura. Não importa quem é o destinatário - um repositório tradicional baseado em produtos Oracle, MSSQL, Teradata ou apenas Hadoop.
Observe que, nesse caso, os bancos de dados Oracle foram usados como fonte e receptor. A solução se mostrou eficaz, agora estamos conectando todos os novos sistemas a um data warehouse on-line comum, e agora não é apenas a Oracle. Outra vantagem do GoldenGate é que ele é adequado para o download de dados da maioria dos bancos de dados usados no cenário de TI do banco.
Caso 3. Ofertas pessoais aos clientes em tempo real.
Já mencionamos a análise de streaming, ou seja, ofertas em tempo real (RTO) para clientes em tempo real. Camaradas seniores dizem que o sucesso nos negócios bancários depende diretamente de quão bem você conhece seu cliente e quão relevante você pode fazer uma oferta a ele. Em outras palavras, a probabilidade de o cliente tirar proveito da oferta do banco é inversamente proporcional à velocidade da resposta do banco às necessidades do cliente.
Como isso funciona? Por exemplo, um histórico de transações mostra que um cliente compra em uma loja de bebidas toda sexta-feira. O posicionamento geográfico o detecta em um shopping center, onde existe uma loja dessa rede, e por meio de um aplicativo móvel, enviamos a ele uma oferta pessoal de desconto para uma loja de delicatessen no mesmo shopping. Esse caso é o mais interessante para o banco, pois permite criar co-marcas e ofertas conjuntas. Os clientes podem ser indivíduos e organizações.
Existem peças offline e online. No primeiro, os clientes são pré-segmentados usando dados de todos os sistemas. Analistas e dados Os cientistas estudam comportamento, dados históricos e criam as chamadas armadilhas. O principal é capturar um evento significativo que pode ser rastreado por uma transação do adquirente, um aplicativo móvel ou outras fontes disponíveis. E esse evento já é processado por meio de análise de streaming e a decisão é tomada no momento com base nas armadilhas preparadas.
O objetivo do CDC GoldenGate é fornecer fluxo de dados de eventos em tempo real dos sistemas de origem para a plataforma analítica. A licença do GoldenGate for Big Data também inclui o Oracle Stream Analytics. Com sua ajuda, os cientistas de dados podem processar independentemente o fluxo de dados no Spark Streaming, desenvolvendo o aplicativo em um ambiente visual.
Caso 4. Contração operacional para novos tipos de fraude
Os sistemas antifraude são bastante fechados, e com razão: quanto menos pessoas se dedicam aos detalhes, maior a segurança. Eles fazem um ótimo trabalho ao lidar com casos padrão, mas às vezes surgem situações que não se encaixam nos scripts padrão. Portanto, é importante suplementar esses modelos com cenários não padronizados. Estamos constantemente desenvolvendo novos modelos baseados na correlação de eventos de vários sistemas: transações com cartão e moeda, localização, operações de sistemas de pagamento, ações em aplicativos móveis, monitoramento de redes sociais. Para alterar o modelo, você deve seguir os processos aceitos: solicitação de negócios, configuração de tarefas, passando o aplicativo por todos os estágios internos de implementação.
No ano passado, testamos o upload de dados usando o Oracle GoldenGate for Big Data dos sistemas tradicionais mais movimentados, onde havia muitas transações pequenas, e do nosso sistema antifraude ao cluster principal no Oracle Big Data Appliance. Tanto o Hadoop quanto o GoldenGate lidaram com a quantidade de dados transferidos - ficamos surpresos.
Terabytes por hora e outras descobertas
Nos últimos dois anos, com o GoldenGate, dobramos o volume de logs transferidos - até quase 1 TB por hora. Isso quase fecha nossas necessidades no momento. Infelizmente, há física em que nos deparamos. Mas, para aumentar a produtividade, o trabalho ativo está sendo realizado com a equipe de desenvolvimento GoldenGate, portanto, isso está longe do limite. Ao mesmo tempo, estamos assistindo e testando soluções CDC de outros fornecedores, mas não encontramos nenhum motivo para migrar do Oracle GoldenGate. No momento, essa tecnologia provou ser a mais madura das existentes no mercado.