O componente ETL do armazém de dados frequentemente fica à sombra do próprio armazém e recebe menos atenção do que o banco de dados principal ou os componentes front-end, como BI e relatórios. No entanto, do ponto de vista mecânico de preenchimento do armazém com dados, o ETL desempenha um papel fundamental e requer tanta atenção dos administradores quanto os outros componentes. Meu nome é Alexandre, atualmente administro o ETL na Rostelecom, e neste artigo tentarei compartilhar um pouco sobre o que um administrador de um dos sistemas ETL mais conhecidos em um grande armazém de dados da Rostelecom enfrenta.
Se os respeitáveis leitores já estão familiarizados com o nosso projeto de armazém de dados e com o produto Informatica PowerCenter, podem ir diretamente para a próxima seção.
Há alguns anos, na Rostelecom, surgiu e começou a se concretizar a ideia de um armazém de dados corporativo unificado. Vários armazéns, que resolviam tarefas específicas, já tinham sido criados, mas o número de cenários aumentava, os custos de manutenção também cresciam, e ficou claro que o futuro estava na centralização. Arquitetonicamente, esse armazém é constituído por várias camadas, implementado em Hadoop e GreenPlum, bancos de dados auxiliares, mecanismos ETL e BI.
Devido ao grande número de fontes de dados geograficamente distribuídas e heterogêneas, foi criado um mecanismo especial de extração de dados, cuja operação é controlada pelo Informatica. Como resultado, pacotes de dados são entregues na área de interface do Hadoop, após o que começam os processos de carregamento de dados pelas camadas do armazém, em Hadoop e GreenPlum, que são geridos por um mecanismo de controle ETL, implementado no Informatica. Assim, o sistema Informatica é um dos elementos-chave que asseguram o funcionamento do armazém.
Mais detalhes sobre nosso armazém serão abordados em uma das próximas postagens.
Informatica PowerCenter / Big Data Management é atualmente considerado o software líder na área de ferramentas de integração de dados. Este é um produto da empresa americana Informatica, uma das principais empresas de ETL (Extract Transform Load), gestão de qualidade de dados, MDM (Master Data Management), ILM (Information Lifecycle Management) e outros.
O PowerCenter que utilizamos é um servidor de aplicações integrado Tomcat, onde os próprios aplicativos Informatica operam, implementando seus serviços.
Domínio, basicamente, é a base para todo o resto, dentro do domínio operam serviços, usuários e componentes GRID.
Console do Administrador, uma ferramenta web de gerenciamento e monitoramento, além do cliente Informatica Developer, que é a principal ferramenta para interação com o produto.
MRS, Serviço de Repositório de Modelos, um repositório de metadados, atua como uma camada entre o banco de dados onde os metadados são fisicamente armazenados e o cliente Informatica Developer, onde o desenvolvimento ocorre. Os repositórios armazenam tanto a descrição dos dados quanto outras informações, incluindo para vários outros serviços Informatica, como programação de execuções de tarefas (Schedules) ou dados de monitoramento, assim como conjuntos de parâmetros de aplicativos, permitindo, em particular, usar o mesmo aplicativo para trabalhar com diferentes fontes e destinatários de dados.
DIS, Serviço de Integração de Dados, é o serviço onde ocorrem os principais processos funcionais, onde os aplicativos operam e são realmente executados Workflows (descrições da sequência de mappings e suas interações) e Mappings (transformações, blocos onde as próprias transformações e processamento de dados ocorrem).
Configuração do GRID – basicamente, uma maneira de construir um complexo usando vários servidores, onde a carga acionada pela DIS é distribuída entre os nós (ou seja, servidores que fazem parte do domínio). Nesse caso, além da distribuição da carga na DIS através de uma camada adicional de abstração GRID, que combina vários nós, onde a DIS opera em vez de em um único nó específico, também podem ser criados instâncias de MRS adicionais. Pode-se até implementar alta disponibilidade, onde acessos externos podem ser feitos através de nós de reserva em caso de falha do principal. Por enquanto, desistimos dessa configuração.
Informatica PowerCenter, de forma esquemática
Nos primeiros estágios de operação na cadeia de suprimento de dados, surgiram regularmente problemas, parte deles devido ao funcionamento instável da Informatica na época. Eu pretendo compartilhar alguns dos momentos memoráveis dessa saga – a adaptação à Informatica 10.
O antigo logotipo da Informatica
A área de responsabilidade da nossa equipe também inclui outros ambientes Informatica, que têm suas especificidades devido a diferentes cargas, mas, por enquanto, vou me lembrar especificamente de como a Informatica evoluiu como um componente ETL do próprio armazenamento de dados.
Como isso aconteceu
Em 2016, quando assumimos a responsabilidade pela operação da Informatica, ela já havia alcançado a versão 10.0, e para colegas com uma mentalidade otimista que tomaram a decisão de utilizar um produto com uma versão menor que .0, parecia óbvio — era necessário usar a nova versão! Do ponto de vista de recursos de hardware, tudo estava ótimo naquele momento.
Desde a primavera de 2016, a operação da Informatica foi responsabilidade de um contratado, e, segundo relatos de alguns usuários do sistema, "ela funcionava algumas vezes por semana". É preciso esclarecer que o armazenamento estava, de fato, na fase de PoC, não havia administradores na equipe e o sistema caía frequentemente por várias razões, após o que o engenheiro do contratado o reiniciava.
No outono, a equipe ganhou três administradores, que dividiram entre si as áreas de responsabilidade, e começou a se estabelecer um funcionamento normal na operação dos sistemas do projeto, incluindo a Informatica. É importante mencionar que este produto não é amplamente difundido e não possui uma grande comunidade, onde se possam encontrar respostas para quaisquer perguntas e resolver qualquer problema. Portanto, foi extremamente importante contar com suporte técnico completo de um parceiro russo da Informatica, que ajudou a corrigir todos os nossos erros e os problemas da ainda jovem Informatica 10.
A primeira coisa que tivemos que fazer para os desenvolvedores da nossa equipe e do contratado foi estabilizar a operação da própria Informatica, garantindo a funcionalidade do console web de administração (Informatica Administrator).
Assim, frequentemente encontramos desenvolvedores da Informatica.
Deixando de lado o próprio processo de investigação das causas, a principal razão das quedas foi o esquema de interação do software Informatica com o banco de dados do repositório, que estava em um servidor relativamente distante, do ponto de vista do panorama de rede. Isso causava atrasos e interrompia o funcionamento dos mecanismos que garantem o controle do estado do domínio Informatica. Após algum ajuste no banco de dados e alterações nas configurações do Informatica, tornando-o mais tolerante a atrasos do banco de dados, e, finalmente, a atualização da versão do Informatica para 10.1 e a transferência do banco de dados de um servidor anterior para um servidor localizado mais perto do Informatica, o problema deixou de ser relevante, e desde então não observamos quedas dessa natureza.
Uma das tentativas de fazer o Informatica Monitor funcionar
A situação com o console de administração também era crítica. Como o desenvolvimento estava ativo diretamente em um ambiente supostamente produtivo, os colegas frequentemente precisavam analisar o funcionamento dos mappings e workflow 'em tempo real'. No novo Informatica, no Data Integration Service, não há uma ferramenta separada para esse tipo de monitoramento, mas na web-console de administração surgiu uma seção de monitoramento (Informatica Administrator Monitor), onde é possível observar o funcionamento das aplicações, workflow e mappings, execuções, logs. Periodicamente, o console tornava-se completamente inacessível, ou as informações sobre os processos atuais no DIS deixavam de ser atualizadas, ou ocorriam erros ao carregar as páginas.
Ajuste dos parâmetros java para estabilizar o funcionamento
A correção do problema foi feita de várias maneiras, realizando experimentos com a alteração de parâmetros, coletando logs, jstack, que foram enviados ao suporte, paralelamente a uma intensa busca no Google e apenas observação.
Em primeiro lugar, foi criado um MRS separado para monitoramento, que, como se descobriu mais tarde, é um dos principais consumidores de recursos em nossos ambientes, já que as execuções dos mappings ocorrem de forma muito intensa. Foram ajustados os parâmetros relacionados ao java heap e uma série de outros.
Como resultado, na próxima atualização do Informatica 10.1.1, conseguimos estabilizar o funcionamento do console e do monitor, os desenvolvedores começaram a trabalhar de forma mais eficiente, e os processos regulares tornaram-se cada vez mais regulares.
A experiência da interação entre desenvolvimento e administração pode ser interessante. A questão da compreensão mútua de como tudo funciona, o que pode e o que não pode ser feito, é sempre importante ao usar sistemas complexos. Por isso, é recomendável treinar primeiro a equipe de administradores sobre como gerenciar o software, e a equipe de desenvolvedores sobre como escrever código e desenhar processos no sistema, para então deixá-los trabalhar juntos em busca de resultados. Isso é realmente importante quando o tempo não é um recurso infinito. Muitos problemas podem ser resolvidos mesmo por tentativa e erro, mas às vezes alguns requerem conhecimentos pré-requisitos — nosso caso confirma a importância de entender essa axioma.
Por exemplo, ao tentar ativar a versionamento no MRS (como acabou se revelando, era necessária uma versão diferente do SVN), após um tempo, percebemos com preocupação que o tempo de reinício do sistema havia aumentado para várias dezenas de minutos. Ao identificar a causa do atraso na inicialização e desativar a versionamento, a situação foi restaurada.
Um dos obstáculos notáveis relacionados ao Informatica foi a batalha épica com os crescentes fluxos de java. Chegou o momento da replicação, ou seja, expandir os processos estabelecidos para um grande número de sistemas fontes. No entanto, notamos que nem todos os processos em 10.1.1 estavam funcionando bem, e após algum tempo o DIS se tornava inoperante. Centenas de milhares de fluxos eram descobertos, com um aumento especialmente acentuado durante o procedimento de implantação de aplicações. Às vezes, era necessário reiniciar várias vezes ao dia para recuperar a funcionalidade.
Aqui, precisamos agradecer ao suporte, pois os problemas foram relativamente rapidamente localizados e corrigidos com a ajuda do EBF (Emergency Bug Fix) – após isso, todos sentiram que a ferramenta realmente funcionava.
Ainda assim, funciona!
No momento em que começamos a trabalhar no modo direcionado, o Informatica se apresentava da seguinte forma. Versão do Informatica 10.1.1HF1 (HF1 é HotFix1, a versão do fornecedor proveniente do conjunto de EBFs) com EBFs adicionais instalados, corrigindo nossos problemas de escalabilidade e alguns outros, em um dos três servidores que compunham o GRID, 20 núcleos x86_64 e armazenamento em um enorme e lento array de discos locais — isto é configuração do servidor para o cluster Hadoop. Em outro servidor idêntico, há o banco de dados Oracle com o qual trabalham tanto o domínio Informatica quanto o mecanismo de controle ETL. Tudo isso é monitorado por ferramentas padrão utilizadas pela equipe (Zabbix + Grafana), de ambos os lados — tanto a Informatica com seus serviços, quanto os processos de carga que estão sendo executados. Atualmente, tanto o desempenho quanto a estabilidade do funcionamento, desconsiderando fatores externos, dependem das configurações que limitam a carga.
Separadamente, vale mencionar o GRID. O ambiente foi construído em três nós, com a possibilidade de balanceamento de carga. No entanto, durante os testes, foi descoberto que, devido a problemas de interação entre as instâncias de nossas aplicações em execução, essa configuração não estava funcionando conforme o esperado, e temporariamente decidimos abandonar esse esquema, removendo dois dos três nós do domínio. No entanto, o esquema em si permaneceu o mesmo, e agora é exatamente um serviço GRID, mas reduzido a um único nó.
No momento, permanece a dificuldade relacionada à queda de desempenho durante a limpeza regular do esquema do monitor — quando processos estão sendo executados simultaneamente no CHNN e ocorre a limpeza, podem surgir falhas no funcionamento do mecanismo de controle ETL. Isso está sendo resolvido de maneira 'provisória' — com a limpeza manual do esquema do monitor, perdendo todos os dados anteriores. Isso não é muito crítico para a produção, em condições normais de funcionamento, mas ainda se está buscando uma solução adequada.
Dessa mesma situação decorre mais um problema — às vezes ocorrem múltiplas execuções do nosso mecanismo de controle.
Execuções múltiplas do aplicativo, levando à falha do mecanismo
Durante a execução programada em momentos de alta carga no sistema, às vezes ocorrem situações que levam à falha do mecanismo. Até agora, o problema é corrigido manualmente, e busca-se uma solução permanente.
De forma geral, pode-se resumir que, sob carga alta, é essencial fornecer recursos adequados, tanto em termos de hardware para o próprio Informatica quanto para seu repositório de banco de dados, além de garantir configurações otimizadas para ambos. Ademais, permanece em aberto a questão sobre qual esquema de alocação de banco de dados é melhor — em um host separado ou no mesmo onde o software Informatica opera. Por um lado, em um único servidor fica mais barato, e a sobrecarga de comunicação de rede é praticamente eliminada; por outro lado, a carga do banco de dados se soma à carga do Informatica.
Como em qualquer produto sério, o Informatica também apresenta momentos curiosos.
Uma vez, ao analisar um incidente, percebi que nos logs do MRS o tempo dos eventos estava anotado de forma estranha.
Dualidade temporal nos logs do MRS "por design"
Acontece que os carimbos de data e hora são registrados no formato de 12 horas, sem a indicação de AM/PM, ou seja, antes ou depois do meio-dia. Foi até aberta uma solicitação sobre isso e recebemos uma resposta oficial — era assim que estava previsto; os carimbos no log do MRS são, de fato, registrados exatamente nesse formato. Portanto, por vezes, há um certo mistério em relação ao momento em que ocorre algum erro...
Aspirar pelo melhor
Hoje, o Informatica é uma ferramenta bastante estável, conveniente para administradores e usuários, e extremamente poderosa em termos de recursos e potencial atuais. Ele excede em muito nossas necessidades funcionais e, de fato, está sendo utilizado no projeto de uma maneira que não é nem típica nem caracteristica. As dificuldades estão, em parte, relacionadas a como os mecanismos funcionam — a especificidade está em que, em um curto período, um grande número de threads é acionado, que atualizam intensivamente os parâmetros e interagem com o repositório de banco de dados, enquanto os recursos de hardware do servidor são praticamente totalmente utilizados pela CPU.
Agora estamos prestes a fazer a transição para o Informatica 10.2.1 ou 10.2.2, nas quais alguns mecanismos internos foram reestruturados, e o suporte promete resolver vários problemas de desempenho e funcionamento que atualmente enfrentamos. E do ponto de vista de hardware, esperamos servidores com uma configuração ideal para nós, considerando a margem para o futuro próximo em virtude do crescimento e desenvolvimento do armazenamento.
Naturalmente, haverá testes, verificação de compatibilidade e, possivelmente, mudanças arquitetônicas na parte do HA GRID. O desenvolvimento dentro da Informatica continuará, uma vez que, a curto prazo, não podemos implementar uma substituição para o sistema.
E aqueles que, no futuro, serão responsáveis por este sistema, certamente conseguirão levá-lo aos níveis necessários de confiabilidade e desempenho exigidos pelos clientes.
O artigo foi preparado pela equipe de gerenciamento de dados da "Rostelecom".
Logotipo atual da Informatica
Fonte: habr.com
