Padronizações e dicas de ETL da DINAM:

Nomes WKF/Mapas/Seções:

i. Mapas devem começar com MPP e, a título de padronização, usar:

o Se processo de insert/insert e update:
o MPP_CARGA_NOME_DA_TABELA_TARGET;
o MPP_ATUALIZA_NOME_DA_TABELA_TARGET;
o Se precisar colocar o nome do campo que está atualizado, pode incluir no final:
MPP_ATUALIZA_NOME_DA_TABELA_TARGET_NOME_CAMPO.
o MPP_EXCLUI_NOME_DA_TABELA_TARGET;

o Se o target for um arquivo txt, usar MPP_CARGA_FF_NOME_ARQUIVO.

o Se o target for um xml, usar MPP_CARGA_XML_NOME_ARQUIVO.

o Se for um folder genérico, isto é, um folder que contenha os mapas de carga de vários ambientes (STG, TGT, WRK e
DDM), então deve-se acrescentar o tipo de esquema do banco para a tabela que está sendo carregada, como
MPP_CARGA_NOME_DA_TABELA_STG
Continuação de nomes WKF/Mapas/Seções:
ii. Os WKF devem começar com o nome WKF.

Padrão para STG/TGT/WRK:

o WKF_CARGA_XXX_YYY
o XXX = projeto, como CBL, SCR, SPI, DIC, IIB, COF, CIC, CBE, etc.
o YYY = banco de destino da tabela, como STG, TGT, WRK.
o Ex: WKF_CARGA_SPI_STG

Padrão para DDM:

o Se o requisitante quiser separar em FATOS e DIMENSÕES na DDM, então:

o WKF_CARGA_XXX_FATOS_DDM
o XXX = projeto, como CBL, SCR, SPI, DIC, IIB, COF, CIC, CBE, etc.
o WKF_CARGA_XXX_DIMENSOES_DDM
o XXX = projeto, como CBL, SCR, SPI, DIC, IIB, COF, CIC, CBE, etc.

Exceções a serem tratadas pontualmente:

o Se o requisitante quiser um WKF para carga do processo de uma tabela, então:

o WKF_CARGA_XXX_NOME_TABELA_TARGET_YYY, sendo que o nome da tabela target está sem o XXXTB
o XXX = projeto, como CBL, SCR, SPI, DIC, IIB, COF, CIC, CBE, etc.
o YYY = banco de destino da tabela, como STG, TGT, WRK ou DDM.
o Se o requisitante quiser um WKF por assunto, então:
o WKF_CARGA_XXX_ASSUNTO_YYY
o XXX = projeto, como CBL, SCR, SPI, DIC, IIB, COF, CIC, CBE, etc.
o ASSUNTO = CONTRATO, EVENTO, BAIXA, INCR (de carga incremental), TOT (de carga total).
o YYY = banco de destino da tabela, como STG, TGT, WRK ou DDM.
Continuação de nomes WKF/Mapas/Seções:
iii. As seções devem chamar s_NOME_DO_MAPA. Se reutilizarmos o mapa em vários WKFs, aí sim mudar o nome e este nome
deve ser colocado no documento sh (adiante mostrarei a configuração do sh).

iv. Nomes de sources ou targets:

i. Se for uma tabela, usa-se o nome de banco;
ii. Se for um arquivo txt, deve-se iniciar com FF_NOME_DOCUMENTO.
iii. Se for um XML, manter o nome importado pela definição do XML.
 (este quadro foi retirado de uma apresentação da equipe do teradata):

WRK DDM
STG/TGT Tabelas temporárias Dados para consumo dos
Transformações de dados usuários via view na ACC

o No ambiente STG, os dados são importados de outros ambientes (DB2, Sql Server, Arquivo txt, XML, CSV e etc)
e usualmente não há transformações de dados.
o Recomenda-se usar a mesma estrutura da tabela na origem.
o O Teradata utiliza uma arquitetura ELT e não ETL. Ou seja, extrai da origem e carrega no teradata o dado
original, depois é que as transformações dos dados são feitas dentro do teradata.

o O ambiente TGT armazena os dados históricos da STG, de acordo com a necessidade do processo de carga.

o No ambiente WRK, os dados são transformados.

o Recomenda-se a utilização deste ambiente para cargas com muitas etapas.
o Utiliza a WRK em processos de carga incremental.

o No ambiente DDM, armazenam-se os dados em modelos multidimensionais.

o A camada DDM é a camada final do fluxo. Nesta camada criam-se views ACCs, que é a base na qual as
aplicações MSTR, PowerBi e usuário final (via Teradata Assistant) acessarão.
Instruções para configuração do TPT (Teradata Parallel Transporter):

i. Utilizar em cargas de tabelas grandes, a partir de 1 milhão de linhas. (ou menos, caso a carga esteja lenta).
ii. O quadro abaixo mostra as estratégias de carga de cada TPT Operator (este quadro foi retirado de uma apresentação
da equipe do teradata):

ii. O TPT Load e Update bloqueiam a tabela durante a execução do processo, sendo desbloqueada ao final do processo. Se
houver uma falha na carga, a tabela permanecerá bloqueada:
• Se TPT Load, a mensagem de erro será “Tabela XXX is being Loaded”. Neste caso, a tabela será recriada pelo DBA
e os dados perdidos.
• Se TPT Update, a mensagem de erro será “Tabela XXX is being MLoaded”. A tabela não será recriada, mas haverá
a necessidade da intervenção do DBA para liberá-la.
• Em função desta necessidade de intervenção, nos dois casos, não deve ser usado este processo de carga para
tabelas em DDM.
• Para tabelas em TGT, o responsável da DINAM precisa avaliar o risco de perda da tabela e eventuais impactos do
bloqueio da tabela ao processo de carga de outras tabelas.
Instruções para configuração do TPT LOAD/UPDATE:

iii. Se um WKF contiver muitas seções com TPT Load, colocá-las sequencialmente, pois há um limite para a quantidade
simultâneas de seções rodando com TPT Load.

iv. Abaixo as configurações:

• $DBConnection_TD_TPT_LOAD=Teradata_PT_LOAD_PROD
• $DBConnection_TD_DW=TERADATA_PROD
• Se a opção de Truncate estiver habilitada, deve-se informar a conexão do banco relacional. Nos demais casos, isto não é
necessário.
 Instruções para configuração do TPT LOAD - Continuação

• Avaliar se é indicado habilitar o truncate.

• Indicar o esquema onde ficará a tabela work que depois será dropada pelo processo. Uma observação importante dos DBAs é
usar o esquema de WRK para esta tabela, em função do espaço necessário de carga.
• Padrão de nomes:
• WORK: nome da tabela que está sendo carregada e acrescentar o final “_WRK”. Isto facilitará a análise se houver erro na
carga. Por exemplo, se carga da tabela ENTRY_INCR, então acrescentar o final “_WRK”.
• ERROR: nome da tabela que está sendo carregada e acrescentar o final “_E1” e “_E2”.
• LOG: nome da tabela que está sendo carregada e acrescentar o final “_LOG”.
• Incluir o parâmetro de query band (que deve estar no arquivo de parâmetro. Isto facilitará o rastreamento do processo pelos
DBAs.
$Param_TPT_Query_Band=APP=PWC;LOADER=TPT;Table_Name=$Param_Target_Table_Name;PMFolderName=$PMFolderName;
PMWorkflowRunId=$PMWorkflowRunId;PMWorkflowName=$PMWorkflowName;PMSessionName=$PMSessionName;PMMappingN
ame=$PMMappingName;PMRepositoryUserName=$PMRepositoryUserName;StartTime=$$
$SessStartTime;UtilityDataSize=small;
• Avaliar se deve-se habilitar o INSERT, UPDATE ou DELETE.
Instruções para configuração do TPT LOAD - Continuação

• Indicar o esquema onde ficará a tabela de erro que depois será dropada pelo processo. A preferência para a tabela de
erro e log é o esquema de ERR.
• Habilitar, sempre, o “Drop Log/Error/Work Tables”.
Recomendações ao uso do Push Down

• Sempre que a leitura e escrita for em um banco do Teradata, recomenda-se usar o “Pushdown”, principalmente em cargas
de tabelas grandes, pois o ganho de performance é enorme.
i. Habilitar o “Pushdown” na aba Propriedades, em “Pushdown Optimization”, para FULL.
ii. Se o mapa tiver agregações, então precisa incluir o “AggregateTreatNullAsZero=NULL;“ na aba “Configuração de
Objeto/ Custom Properties”.
Recomendações ao uso do Push Down - Continuação

iii. Se a tabela que estiver sendo carregada contiver TimeSTAMP, pode ser necessário incluir os “Custom Properties”
abaixo:

TeradataV12TimestampCasting = Yes
TeradataV12Casting = Yes

iv. Para processos de update, necessário habilitar “Allow Temporary View for Pushdown”.
Objetivos dos Folders

• Usualmente, em um folder com final “_STG” devem ter mapas de leitura de arquivos, outros bancos de dados (como DB2,
adabas ou sql server) para carga em uma tabela no esquema STG do banco de dados Teradata.

• Agora, se um folder com final “_DDM”, usualmente são processos que carregam da WRK/STG ou TGT para o banco DDM.

Para as tabelas DDM/TGT:

• Não fazer nenhum Truncate ou Delete em tabela de produção sem autorização do responsável pelo sistema na Dinan.
Boas Práticas

• Sempre que possível, o sql deve vir do designer. Evitar alterações do sql no Work Flow Manager.
 Em casos de reutilização de mapas, recomenda-se incluir no final do sql uma observação (-- este sql está sendo alterado
no WKF e enumerar os motivos.

• PI - Primary Index:

 Esta é uma orientação para os demandantes da DINAM: sempre criar tabelas com tabelas PI, mesmo no banco STG.

 Necessário buscar uma PI adequada para garantir que a tabela esteja bem distribuída entre os “AMPs”. O teradata aloca
os dados uniformemente nas “AMP” disponíveis (288 “máquinas virtuais”).

 Isto melhora o skew da tabela e evita estouro de espaço, assim como melhora a performance da carga.

 O Skew é o desbalanceamento dos dados que foram distribuídos entre estes “AMPs”, quando inseridos na tabela.

 Por exemplo, se o PI de uma tabela for o sexo do cliente, então os dados da tabela toda serão distribuídos apenas em
dois “AMPs”: M e F.

 Se houver assimetria, boa parte da tabela está alocada em poucos “AMP” e isto acaba gerando o estouro.
Preparar sempre o processo para que seja possível fazer reprocessamentos (re-run pelos plantonistas, em caso de
erro do WKF):

• Garantir que a carga, se reprocessada, não cause duplicações de dados.

• A forma escolhida para isto é responsabilidade do desenvolvedor do processo.

• Necessidade de manter o melhor desempenho possível, com garantia de não duplicação dos dados.
Roteiro para os SCRIPTs e agendamentos no Control M:

1. Atenção à inclusão de Jobs que rodam alguma manutenção/geração de históricos que impactam o ambiente e a carga
noturna. Ao agendar um job no control-m, o responsável da DINAM deve estar ciente, para avaliar possíveis impactos.

2. Atenção para incluir corretamente a “Grupo Responsável“ pelo job, nem sempre é a DINAM/ETL. Se a demanda vier por uma
DINE, este job será de sua responsabilidade.

3. Ao incluir ou alterar qualquer job, não incluir o acionamento a plantonista.

 Deve-se deixar em "não acionar“;
 Se for necessário o acionamento, deve-se mandar um e-mail para DINAM/ETL com a justificativa da necessidade de
acionamento. A equipe analisará o caso e, se aprovado, incluirá o acionamento no Service Manager
 Adicionalmente, quarentena de 1 semana do job sem incidentes para solicitar acionamento via e-mail.
Se houver incidentes, prazo recomeça.

4. Quando abrir a MUD para inclusão de jog no control – m, usar como “Nome do Job” o mesmo nome do WKF. Isto facilitará no
tratamento de incidente. Atenção para as padronizações indicadas no primeiro slide. Adicionalmente, para que a equipe de
ETL receba os incidentes e possa trata-los adequadamente, deve-se mencionar na mud (em comentários) que se o job falhar,
abrir incidente, ficar “vermelho” no control m e enviar notificação por e-mail.

5. Ao incluir o documento .sh no folder, solicitar a DIPRO ou Klever que abra o arquivo, “dê” um enter, salve e depois abra
novamente e delete esta linha inserida. Isto porque, quando é a primeira vez que incluímos o documento sh, há algum “bug”
e isto gera incidentes. Isto é uma recomendação do própria DIPRO.
Roteiro para os SCRIPTs e agendamentos no Control M:

6. CAMINHO E O NOME DOS LOGS

o Para cada workflow e para cada sessão, informar o caminho e o nome dos log de acordo com o padrão:
- No workflow manager, na opção Workflows, na aba properties, os valores dos atributos devem seguir os padrões abaixo:
 Workflow Log File Name - idêntico ao nome do workflow com a extensão .log;
 Workflow Log File Directory - $PMWorkflowLogDir;
 No arquivo de parâmetros, precisa definir o $PMWorkflowLogDir apontando para o FOLDERDOPROJETO.
 Importante: o WKF deve apontar para o arquivo de parâmetro correto, no folder do projeto e não o arquivo de
parâmetro de outro WKF. Este problema já gerou um incidente.
- Na sessão, na aba properties, os valores dos atributos devem seguir os padrões abaixo:
 Session Log File Name - idêntico ao nome da sessão com a extensão .log;
 Session Log File Directory - $PMSessionLogDir;
 No arquivo de parâmetros, precisa definir o $PMSessionLogDir com o FOLDERDOPROJETO.

7. SCRIPT DO WORKFLOW - Para cada workflow que se deseja publicar, criar um script para acioná-lo.

 Este script será chamado pelo control-m no momento da execução do workflow.

arquivo deve seguir este padrão. Apenas os itens apontados em verde devem ser alterados. 0 COLOCAR FIGURA DO WKF

É fundamental que os nomes dos

logs no script estejam idênticos aos
das seções do WKF. Se isto não
acontecer, gerará incidente.

Veja que o control m buscará o

log com o nome do WKF... Por
isto, garantir que esteja correto
no WKF.

Deixar desta forma (como

parâmetro e não o nome do
WKF)
Exemplo de incidentes em função de problemas no documento .sh:

Primeiro, veja que o script

está apontando para o WKF
correto.
Mas, veremos no próximo
slide que o log do WKF está
apontando para outro arquivo
.log

Veja que está procurando o

log de um WKF e não de uma
sessão.
Exemplo de incidentes em função de problemas no documento .sh:

O arquivo .log deve ser o nome do WKF.

Documento .sh inconsistente:

Colocar os logs das sessões e não do WKF.