Olá queridos amigos.
Hoje, quero compartilhar uma história de vida sobre como o armazenamento DWH foi organizado no Tele2 antes da introdução do QCD (EDW).
Entrei no departamento de TI da Tele2 em 2012 no departamento de sistemas de relatórios. Naquela época, o repositório DWH já estava criado na empresa, no qual muitos processos de geração de relatórios e mais já estavam girando.
Um pouco sobre a pilha técnica usada naquele momento. Para armazenamento, o banco de dados Oracle foi utilizado com uma capacidade de servidor de 60 a 100 Tb T4-4 com 1 TB de operação. Dados de várias fontes foram baixados lá. Mas as principais eram 4 bases de cobrança da Oracle, que eram essencialmente uma plataforma de cobrança. E havia um departamento que estava envolvido no suporte a esses bancos de dados e na prestação de serviços. A separação dessas bases foi por macrorregiões. Razão: os volumes são muito grandes. Ou seja, se um assinante ligar, digamos, de um cartão SIM de Moscou, o custo da chamada será calculado na cobrança correspondente.
O hardware de ponta sempre foi para os bancos de dados de cobrança e os recursos foram alocados aos sistemas restantes de acordo com o princípio residual. Geralmente para DWH, o servidor sempre ficava um pouco mais fraco. I.e. o faturamento possui um hardware T5-4 e, em seguida, o DWH possui uma herança T4-4.
Mas esses recursos sempre foram suficientes para cobrir as tarefas atuais e reduzir os relatórios. Os dados do faturamento foram baixados via DB-link. Os processos ETL clássicos foram configurados quando downloads noturnos de dados aconteciam com pequenas conversões (por exemplo, adicionando chaves substitutas). O ETL era de 2 tipos: carga total para pequenos volumes e incremental para tabelas grandes, como, por exemplo, detalhes de chamadas, cobranças, pagamentos etc. Havia também uma fonte tão grande como arquivos de texto que baixam informações de chamadas e tráfego da Internet de switches e estações base. Os dados são baixados como arquivos de texto usando os carregadores do Oracle sql loader. O incremento para a base era geralmente de 10 a 20 GB por dia.
Tabelas de particionamento, índices, otimização de planos de consulta e dicas sobre DWH precisavam ser usadas constantemente. Não houve um dia sem sessões de suspensão ou reprodução prolongada nas quais foi necessário entrar no plano de solicitações.
A estrutura de armazenamento DWH no Tele2 antes da introdução do EDW.
Além disso, uma das principais tarefas da DWH era gerar demonstrações financeiras mensais (ETFs). Foi considerado no servidor DWH por 4 dias inteiros devido aos grandes volumes. Para imaginar o que é, direi que este é um pacote Oracle de 5 mil linhas de código PL / SQL com lógica complexa ornamentada e tudo isso é minimizado em dinâmica. E, em seguida, o relatório é carregado no FTP ou em um compartilhamento de rede na forma de arquivos CSV. E tudo isso sem o uso de soluções in a box. I.e. funcionalidade escrita à mão, otimizada e automatizada ao longo dos anos.
Mas o banco de dados DWH foi usado não apenas para fornecer relatórios regulares, mas também como um armazenamento operacional. Por exemplo, girou em torno do processo de fornecer informações diferentes aos assinantes de uma conta pessoal no site da Tele2.
Também vale a pena mencionar separadamente o sistema Oracle Application Express (APEX), que possui um local especial para geração de relatórios. O APEX é um ambiente para o rápido desenvolvimento de interfaces WEB, seja para gerar relatórios ou para configurar um processo de negócios. Nele, foi criada, manualmente, a funcionalidade escrita "Upload de relatório", onde os usuários podiam criar um relatório para si. I.e. uma pessoa entra, seleciona um conjunto de campos para seu relatório, se desejar, pode extrair a fonte como um arquivo excel e, em seguida, recebe um relatório para o correio na forma de um arquivo csv arquivado. E dentro do DWH, um grande número de procedimentos e funções PL / SQL são gravados, que eram essencialmente um gerador de script interno para relatórios. Além disso, essa ferramenta era tão popular na empresa que, durante 8 anos, mais de meio milhão de relatórios com graus variados de importância foram gerados nela.
O APEX também desenvolveu muitas outras coisas interessantes. Por exemplo, funcionalidade escrita à mão para fluxo de trabalho e sistema de automação de marketing. No primeiro, a equipe endossou os documentos. Em segundo lugar, o departamento de marketing realizou vários eventos para os clientes. Por exemplo, ele realizou distribuição massiva de SMS para assinantes sobre novas tarifas e serviços. E tudo isso passou pelo DWH e houve integração com o canal SMS.
Além disso, alguns sistemas de relatórios, como o Crostal Reports e o IBM Lotus, se conectam ao DWH por meio de arquivos RPT.
No diagrama anexado acima, você pode ver a estrutura do repositório DWH antigo e o fluxo de dados para 2012. Com a estrutura atual, não há nada a fazer.
Tudo isso funcionou com mais ou menos sucesso até o momento em que a empresa percebeu que os relatórios não eram mais suficientes e decidiu introduzir QCD, sistemas de BI e BigData.
Em geral, havia muitas coisas interessantes. Talvez eu me debruce sobre isso. Até breve.