Árvore de páginas

01. Premissas

  • A implementação de alguns itens deste documento devem ser realizadas pelo responsável pela administração do banco de dados (DBA) do cliente.
  • O repositório é destinado a fornecer dados formatados para uso em ferramentas analíticas do tipo Data MiningData Discovery e outras que o cliente desejar.
  • Os Data Marts desenvolvidos pela TOTVS - Varejo Supermercados serão licenciados e ofertados para serem consumidos no ambiente de Data Warehouse.
  • As estruturas do modelo e seus objetos de banco de dados não devem ser alterados pelo cliente, ficando sujeito a penalizações contratuais.
  • O processo de extração, transformação e carga dos dados a partir do ERP TOTVS - Varejo Supermercados para o repositório será realizado integralmente por rotinas do próprio produto.
  • A manutenção e evolução do repositório acompanhará as eventuais mudanças que o ERP sofrer em sua estrutura ao longo de sua manutenção habitual.
  • A TOTVS - Varejo Supermercados reserva-se no direito de atualizar, modificar, incluir ou excluir informações deste documento a qualquer momento, sem aviso prévio. Na ocasião, verifique a disponibilidade de uma versão mais atual deste documento.

02. Requisitos Técnicos

Requisitos de Ambiente

O Data Warehouse foi projetado e desenvolvido para Oracle Database. Para instalação do produto será necessário a disponibilização de um ambiente Oracle compatível e homologado para criação do repositório. Não se restringe a virtualização do ambiente Oracle Database, desde que, os pré-requisitos e orientações da Oracle sejam completamente atendidos para este tipo de ambiente.

Existem dois cenários possíveis atualmente no qual fica a critério do cliente:

Ambiente Oracle compartilhado com ERP e Data Warehouse

Este cenário possibilita redução de custo ao compartilhar hardware e licença Oracle, sendo indicado apenas quando o repositório for destinado a integração com o Qlik (ou outra ferramenta com característica semelhante) e/ou a consultas de baixa frequência ou baixa demanda de processamento durante o horário produtivo do ERP.

Ambiente Oracle Dedicado ao Data Warehouse

Este cenário exige investimento em hardware e licença Oracle, sendo indicado quando o repositório for destinado a consultas frequentes ou com alta demanda de processamento, além da integração com o Qlik (ou outra ferramenta com característica semelhante).

O repositório poderá estar no mesmo servidor que hospeda o ERP TOTVS - Varejo Supermercados, desde que em owner diferente do owner utilizado no ERP (conforme pré-requisitos), podendo ser na mesma ou em instância separada. Porém, recomenda-se que o repositório de Data Warehouse esteja em ambiente separado do ERP TOTVS - Varejo Supermercados, uma vez que a carga de processamento no repositório do Data Warehouse pode vir a interferir no desempenho do ERP, ficando a critério do cliente e de seu Administrador de Banco de Dados (DBA) definir a melhor estrutura a ser utilizada de acordo com os recursos disponíveis e a intenção de utilização do ambiente.

Estando em ambientes distintos (servidor ou instância), o repositório do ERP deverá ter acesso e permissão de manipulação na base de dados do Data Warehouse por meio de DBLink com nome configurado como CONSINCODW. Se o repositório for hospedado na mesma instância Oracle do ERP, será necessário apenas conceder os devido privilégios de acesso.

A base de implantação pode ser baixada na Central de Downloads.


03. Requisitos de Instalação

Os requisitos descritos abaixo são obrigatórios para instalação do repositório do Data Warehouse.

  • Criar usuário de banco de dados CONSINCODW
  • Criar a tablespace TSD_CONSINCODW para armazenamento dos dados
  • Criar a tablespace TSI_CONSINCODW para armazenamento dos índices
  • Definir a tablespace padrão do usuário CONSINCODW como TSD_CONSINCODW
  • Conceder os seguintes privilégios ao usuário CONSINCODW:
    • Connect
    • Resource
    • Unlimited Tablespace
    • Create View
    • Select Any Dictionary (Permissão recomendada para análise de suporte)

Após a disponibilização do ambiente com os requisitos acima, será realizado a criação do repositório pela equipe TOTVS - Varejo Supermercados ou DBA do cliente.


04. Requisitos de Administração

As informações descritas neste item baseiam-se em boas práticas na administração do banco de dados Oracle para os produtos TOTVS - Varejo Supermercados. Em alguns cenários, as características de ambiente, de equipamento, de volumetria e do número de acessos simultâneos ao servidor, podem exigir recomendações específicas, inclusive da fabricante Oracle. Recomenda-se que a administração do banco de dados Oracle seja feita por empresa ou profissional especializado.

Recomendações e boas práticas

  • Criar políticas de coleta de estatísticas periódica para todo o schema CONSINCODW
  • Criar políticas de backup periódico para o banco de dados (Ref. Archive, Data Pump)
  • Utilizar o pacote Dbms_Stats para coleta de estatísticas
  • Manter Redo Logs em quantidades e tamanhos para um bom intervalo de switch (~15 min)
  • Definir Unlimited para regra Failed_Login_Attempts para o profile do usuário CONSINCODW
  • Definir Unlimited para a regra Password_Life_Time para o perfil do usuário CONSINCODW
  • Definir Unlimited para a regra Password_Lock_Time para o perfil do usuário CONSINCODW
  • Definir Unlimited para a regra Password_Grace_Time para o perfil do usuário CONSINCODW
  • Utilizar no máximo, 70% da memória RAM disponível no servidor para o Oracle
  • Definir valor para Job_Queue_Processes inferior ao valor de Cpu_Count
  • Aplicar todos os PatchSet Updates fornecidos pela Oracle para a release utilizada

05. Configurações de Carga

Carga Inicial

Deverá ser definido pelo cliente um período de histórico retroativo para a execução da carga inicial do repositório do Data Warehouse. Esta primeira carga inicial deverá ser mais demorada que as cargas diárias incrementais. A carga inicial será realizada com acompanhamento da equipe TOTVS - Varejo Supermercados, e posteriormente, ao final das execuções, haverá uma homologação dos dados gerados para verificação de consistências. Uma vez concluída a carga inicial e homologado os dados gerados no Data Warehouse, será então configurada a carga incremental diária.

Carga Diária Incremental

O processo de atualização do repositório do Data Warehouse será automático, e será executado de acordo com as parametrizações de intervalo pré-definidas pelo cliente. É necessário que estas parametrizações estejam em acordo com as regras de negócio do cliente e processos de encerramento diário do ERP, para que os dados sejam atualizados corretamente e fiquem consistentes no Data Warehouse.

Gerenciador de Carga do DW

O Gerenciador de Carga integrado ao módulo Gerencial do ERP TOTVS - Varejo Supermercados permite ao administrador do sistema realizar várias funções relacionadas a carga de dados do DW. Para maiores detalhes consulte a documentação do Gerenciador de Carga do DW


06. DER e Dicionário de Dados

Modelo DER

Consultar os anexos:

Dicionário de Dados

Consultar o anexo:


07. Planejamento de Capacidade

Tablespaces temporárias: Inicialmente recomendamos alocar um tamanho mínimo inicial de 6 GB para cada uma das tablespaces TEMP e UNDO na base DW. Deve ser monitorada a necessidade de crescimento e realocação de espaço para essas tablespaces. O espaço máximo consumido (marca d’água) varia conforme as características da base dos dados do cliente.

Tablespaces de dados e índices: Deve ser seguido o planejamento de capacidade. O ambiente do Data Warehouse varia de acordo com os Data Marts utilizados e também de acordo com as características do perfil de dados comerciais do cliente para cada uma das áreas implementadas. Para os Data Marts comerciais propostos até o momento, os principais fatores que influenciarão no volume de dados são:

  • SKU de produtos movimentados (fatos Venda e Compra)
  • SKU de produtos em estoque (fato Estoque)
  • Quantidade de lojas e/ou unidades de negócio (filiais e matriz)
  • Volume diário de documentos de entrada/saída (venda e compra)
  • Período de tempo definido para carga inicial e projeção de janela de tempo especificada para armazenamento em condições de uso em produção
  • Crescimento futuro das operações

Atualmente, a média de consumo de espaço é de 212 MB por empresa/mês, considerando todos os pacotes disponíveis atualmente e no nível mais detalhado, com base em 18.500 SKU (segmento Varejo).

Para exemplificar, se a empresa possuir 10 unidades e desejar importar 2 anos de histórico de movimentação (venda, compra e estoque) para o Data Warehouse, serão necessários atualmente 51 GB de espaço aproximado para carga inicial, mais o consumo mensal a ser gerado posteriormente, que neste caso seria de aproximadamente 2.1 GB/mês.

Para Carga Inicial:

• Sem Estoque: 92 MB x 10 Empresas x 24 Meses = 22 GB
• Com Estoque: 212 MB x 10 Empresas x 24 Meses = 51 GB

Consumo Mensal:

• Com Estoque: 212 MB x 10 Empresas = 2.1 GB

Considerar também:

  • A estrutura do DW TOTVS - Varejo Supermercados está sempre evoluindo e pode agregar novas versões que contemplem outros Data Marts fazendo esse consumo subir;
  • É possível configurar para desativar a carga de alguns fatos isoladamente se não forem utilizados;
  • Deve-se pensar em eventuais previsões de crescimento e expansão, tais como abertura de novas lojas ou unidades de negócio.
  • Numa eventual falta crítica de espaço, pode ser ir eliminando dados antigos do DW que não mais interessem, como saldos de estoques mais antigos ou agrupamentos mais atômicos de vendas mantendo apenas os mais agregados;

08. Considerações sobre Performance

A questão de performance de qualquer sistema computadorizado é sempre algo bastante complexo, pois depende do uso e das expectativas do usuário.

Para o caso do desempenho esperado do Data Warehouse TOTVS - Varejo Supermercados, podemos elencar várias questões que influenciam, tais como:

  • Capacidade de hardware e software instalada para o servidor de banco de dados;
  • Capacidade disponível no momento da utilização;
  • Concorrência simultânea de processamento e acesso de leitura e gravação no schema CONSINCODW e de outros schemas no mesmo servidor/instância;
  • Concorrência e velocidade de acessos de rede, seja local ou remota;
  • Tipo de ferramenta de visualização dos dados para consumo pelo usuário;
  • Dentre outros;

Cenários

Sobre a questão da escolha do tipo de estrutura de ambiente DW, temos as três opções de cenários:

  • A) na mesma instancia (outro schema/owner, mesma base de conexão)
  • B) em outra instancia (DBLink, outra base de conexão)
  • C) em outro servidor (DBLink, outra base de conexão)

Performance X Cenários

Sobre a questão de performance em cada cenário, temos vários momentos de uso:

  • 1) Performance na extração dos dados do ERP
  • 2) Performance na carga para o DW
  • 3) Performance no acesso aos dados do DW por ferramentas TOTVS - Varejo Supermercados
  • 4) Performance no acesso aos dados do DW por outras ferramentas
  • 5) Performance na visualização final dos dados pelo usuário por meio de ferramentas de terceiros

No momento 1, o trabalho é realizado dentro da base do ERP, portanto é indiferente da opção do ambiente não mudará nada. Este momento 1 é a extração diária de dados (ETL), que geralmente roda uma única vez por dia de madrugada, portanto, em teoria, não afetará os usuários diretamente.

No momento 2, que é a continuação do momento 1, também rodando uma vez ao dia (ETL), utilizando o cenário A, temos mais concorrência entre a gravação de tabelas da base ERP e a base DW, e nos demais cenários em tese há ganho de velocidade, porém esse processo roda uma única vez ao dia, então não faz tanta diferença na performance.

No momento 3 em diante já temos ações que dependem dos usuários, e aí quanto mais usuários houver e quanto mais acessarem os dados haverá mais impacto. O fato de estar a estrutura de DW separada do ERP já garante ganhos de performance significativos, eliminando a questão da concorrência de leitura e gravação com o ERP/OLTP e simplificando muito o esforço de consultas. No cenário A já temos esta melhoria de estrutura. Nos cenários B e C melhora um pouco mais, já que temos instancias separadas, onde se pode configurar as partes de memória e blocos do Oracle com configurações mais focadas em prover velocidade de acesso e menos em gravação, visando dar velocidade ao usuário, e no melhor dos mundos o cenário C, onde temos até uma máquina separada. No cenário B e C temos mais facilidade de backup separado também. A desvantagem desses cenários B e C é, obviamente, o custo, pois envolve ter mais uma licença de Oracle e mais um servidor no caso do cenário C, evitando o compartilhamento de recursos de hardware de memória e processamento dos cenários A e B.

No momento 4, vai depender de qual será a ferramenta a ser utilizada para disponibilizar as visualizações para os usuários. Existem algumas ferramentas que trabalham usando as tabelas de fonte de dados (no caso o DW) acessando-as quando precisam, tais como as Análises ABC da TOTVS - Varejo Supermercados. E existem outros tipos de ferramentas que “importam” os dados para uma base de dados interna fechada, que é mantida em memória quando o usuário abre, tais como o Qlik Sense, Tableau ou Microsoft Power Bi, por exemplo. Nestes casos, em teoria, não haveria vantagem nos cenários B e C, pois a carga feita pra dentro dessas ferramentas seria também um processo batch a ser rodado uma vez ao dia. Não gerando mais vantagem em termos os cenários B e C em relação ao A.

No momento 5, é o usuário acessando as análises por meio de ferramentas. Vai depender da ferramenta client. Se for por exemplo, um servidor Tableau ou Qlik Sense, neste caso depende exclusivamente do servidor desta ferramenta pois ele “importa” os dados para sua base interna e se “desliga” da fonte de dados (no caso o DW). Lembrando que essas ferramentas também tem custos elevados em licenças e hardware, exigindo bastante memória em seus servidores. Existem outras ferramentas que usam o banco de fonte de dados, neste caso, fica parecido com o caso do momento 4.


09. Sobre o uso do Oracle Express

Não é recomendado o uso da versão Express do Oracle para o DW TOTVS - Varejo Supermercados, pois esta versão do Oracle possui uma limitação de tamanho máximo da base de cerca de 12 GB de espaço, 2 GB de RAM e 2 CPUs, conforme a versão atual (parâmetros sujeitos a alterações).