Professional Documents
Culture Documents
Patrn de Diseo
ELT
Arquitectura Corporativa LATAM
Versin 1.0 - 08/01/2015
Versin 1.4 06/07/2015
Descripcin
Autor
Construccin del documento Sergio Vergara
para TERADATA
Fecha
201501-12
1.1
201501-21
1.2
Nueva
organizacin
Documento.
1.3
15-062015
1.4
06-072015
10-052015
Revisado por
Gloria Appelgren
Vincent Beghin
Sergio Vergara
(TDT)
Gloria Appelgren
Salvador Jofr
Guillermo
Ordenes
Vincent Beghin
Vincent Beghin
Cristian Yaez
Salvador Jofr
Guillermo
Ordenes
Vincent Beghin
Pgina 1 de 33
ndice de Contenidos
1.
INTRODUCCIN ................................................................................................................. 4
2.
ALCANCE ........................................................................................................................... 4
3.
TERADATA ......................................................................................................................... 5
3.1.
INTRODUCCIN TDT......................................................................................................... 5
3.2.
3.3.
3.3.1.
3.3.2.
3.4.
3.4.1.
3.4.2.
3.5.
3.6.
3.7.
BTEQ Carga ODS (Insert desde tabla temporal a Tabla final ODS). .......................... 16
4.
ORACLE ........................................................................................................................... 18
4.1.
4.2.
4.3.
4.4.
DETALLE TEMPLATE...................................................................................................... 18
4.4.1.
4.4.2.
4.4.3.
4.4.4.
4.5.
4.5.1.
4.5.2.
4.6.
5.
5.1.
5.2.
Pgina 2 de 33
6.
7.
Nota: para acceder a los links debe estar dentro de la Red LAN
Pgina 3 de 33
1. INTRODUCCIN
El siguiente documento tiene por objetivo indicar los patrones de diseo para la extraccin,
carga y transformacin (ELT) para el Datawarehouse en TERADATA, mediante la utilizacin del
protocolo de carga Teradata Parallel Transporter (TPT) y BTEQ. Y adems, establecer las
definiciones orientadas a la optimizacin de cargas masivas en Bases de Datos Oracle mediante
SQL*Loader.
2. ALCANCE
Este documento incorpora el estndar y template de desarrollo para aplicaciones con TPT,
BTEQ en el caso de Teradata y SQL*Loader en caso de Oracle. Contempla las definiciones de
los parmetros requeridos para realizar cargas o exportaciones masivas en los sistemas
Teradata y Oracle.
El documento se separa en definiciones para TERADATA y ORACLE en el contexto ELT.
El documento finaliza con los escenarios de uso, configuraciones de directorios para rea
landing y diagramas de control de procesos.
Pgina 4 de 33
Teradata
(Aplica desde TDT Versin 14.10 en adelante)
3. TERADATA
3.1. INTRODUCCIN TDT
El siguiente documento tiene por objetivo indicar los patrones de diseo para la extraccin,
carga y transformacin (ELT) orientada a la carga ptima de Datawarehouse asociado al
proyecto World Class BI (WBCI), en TERADATA, mediante la utilizacin del protocolo de carga
Teradata Parallel Transporter (TPT).
3.2. ALCANCE TDT
Este documento posee como alcance el poder entregar un template de desarrollo para
procesos TPT, Bteq y con la definicin de los parmetros bases a tener en consideracin, pero
no posee como alcance la arquitectura definitiva a utilizar en el proyecto WCBI, ni el diseo de
los procesos que puedan invocar dichas TPT. Esto debe ser revisado en base a la definicin
funcional del Warehouse, por ejemplo validar si puede poseer reproceso, vigencia,
severidades, etc.
3.3. DETALLE TEMPLATE TDT
3.3.1. Archivo de entrada delimitado |
El patrn de adquisicin ser implementado mediante la utilizacin del protocolo LOAD
mediante un Job TPT, y a travs de BTEQ para la carga sobre la tabla histrica del proceso.
El template TPT, permite ser reutilizado como base para la creacin de los procesos TPT, y
posee un ejemplo de cmo leer un archivo fuente delimitado por el caracter |, y
cargando la informacin sobre una tabla destino en Staging.
En dicho proceso las tablas de work, log y error, sern creadas en base al parmetro
PRMU_NOMBRE_TABLA que debe ser informado en la invocacin del proceso, dicho
parmetro es el nombre de la tabla destino, la cual ser eliminada, al igual que sus tablas
de trabajo, log y error, al momento de la ejecucin, y ser creada en el mismo proceso, por
lo que se debe indicar la estructura.
Pgina 5 de 33
Por cada nuevo proceso TPT, se debe crear un nuevo archivo TPT en base al template,
cuya nomenclatura para el nombre es:
TPT_LOAD_ AcrnimoORIGEN _DATABASE _TABLE _DELIM.tptload
Ejemplo: TPT_LOAD_FBIP_WCBI_RESERVAS_DELIM.tptload
Cambiar el nombre del Job por un proceso nico sobre la definicin DEFINE JOB
Ejemplo: DEFINE JOB load_TEST
En este nuevo archivo TPT, se debe modificar la definicin de la estructura del archivo
fuente DEFINE SCHEMA esquemaLectura
Ejemplo de valores a cambiar:
DEFINE SCHEMA esquemaLectura
(
CAMPOID VARCHAR(260)
CAMPOVALOR VARCHAR(100)
Pgina 6 de 33
Pgina 7 de 33
Parametro
PRMF_TERA_HOST
Observacion
IP/DNS maquina Teradata
Usuario Teradata de conexin con
PRMF_TERA_USER_STG
permisos de carga en Staging
Clave Usuario Teradata de conexin
PRMF_TERA_PASS_STG
con permisos de carga en Staging
PRMF_TERA_DB_STG
Nombre base de datos Staging
PRMF_TERA_DB_TMP
Nombre base de datos Temporal
Cantidad mxima sesiones a utilizar
PRMF_MAX_SESSION
por el protocolo de carga
Cantidad mnima sesiones a utilizar
PRMF_MIN_SESSION
por el protocolo de carga
Cantidad de Horas que podr el
proceso esperar en casos de full uso
PRMF_TENACITY
de sesiones
Cada cuanto minutos el proceso
PRMF_SLEEP
revisara si se liberaron sesiones
Directorio para almacenar archivos
PRMF_DIR_ERROR
de error
Directorio para almacenar archivos
PRMF_DIR_LOG
de LOG
PRMF_PATH_DAT
Directorio con informacion fuente
Cantidad instancias de lectura de
PRMF_INSTANCIA_LECTURA fuente
PRMF_INSTANCIA_CARGA
Cantidad instancias de carga
Cantidad mxima sesiones a utilizar
por el protocolo de carga con TPT,
Multiload, FastLoad (usr_o_*). Este
est controlado por los 30
concurrentes en TASM. Para
identificar small/mdium/large
identificarlo en QueryBand. Ms de
5 no garantiza una mejora
PRMF_MAX_SESSION
significativa en los procesos.
Cantidad mnima sesiones a utilizar
PRMF_MIN_SESSION
por el protocolo de carga
Cantidad de Horas que podr el
proceso esperar en casos de full uso
PRMF_TENACITY
de sesiones
Cada cuanto minutos el proceso
PRMF_SLEEP
revisara si se liberaron sesiones
Ejemplo
57.228.128.8
Usr_o_stg
XXXXX
ODS_STG
ODS_TMP
5
1
4
6
'/export/home/dsacsmlg/TPT/ERR/'
'/export/home/dsacsmlg/TPT/LOG/'
'/export/home/dsacsmlg/TPT/DAT/'
5
2
1-5
1
0-4
1-6
Pgina 8 de 33
Formato Ejecucin
Ejemplo:
tbuild -f /export/home/dsacsmlg/TPT/SHL/TPT_LOAD_ESTANDAR_STG_DELIM.tptload -v
/export/home/dsacsmlg/TPT/CNF/config.ini -u "PRMU_NOMBRE_TABLA='TEST',
PRMU_FILE_INPUT=' DETALLE.TXT'" TEST
Adicionalmente se debe:
Pgina 9 de 33
Pgina 10 de 33
tbuild -f /export/home/dsacsmlg/TPT/SHL/TPT_LOAD_ESTANDAR_STG_DELIM.tptload -v
/export/home/dsacsmlg/TPT/CNF/config.ini -u "PRMU_TB_INPUT='TEST',
PRMU_FILE_INPUT='DETALLE.TXT'" TEST
Para este caso se utiliz como input archivo DETALLE.TXT, el cual est delimitado por el
carcter | y posee 18 registros, y fue cargado en la tabla destino LOGM.TEST.
Pgina 11 de 33
Muestra de datos:
Para este caso se utiliz como input archivo 4M051814.DAT el cual posee un formato de
largo fijo de 40 caracteres y contiene 23491 registros, y fue cargado en la tabla destino
LOGM. TEST_VAR.
Pgina 12 de 33
Muestra de datos:
Parmetros BTEQ
Descripcin
Nombre de Base Tabla Origen
Nombre de la Tabla Origen
Nombre de Base Tabla Destino
Nombre de la Tabla Destino
Servidor Teradata
Usuario Teradata
Password Teradata
Ejemplo ejecucin:
sh /export/home/dsacsmlg/TPT/SHL/BTEQ_INSERT_HIST_TEST.bteq WCBI_STG TEST
WCBI_HIST TEST 57.228.128.8 gappelgren password >>
/export/home/dsacsmlg/TPT/LOG/log_insert_historico.log
Pgina 13 de 33
Muestra de log:
Muestra de Datos:
Pgina 14 de 33
Ejemplo ejecucin:
sh /export/home/dsacsmlg/TPT/SHL/BTEQ_REGLA_NEG_TEST.bteq WCBI_STG WCBI_TMP
WCBI_ODS WCBI_FDM 57.228.128.8 gappelgren xxxxx 001 >>
/export/home/dsacsmlg/TPT/LOG/log_regla_negocio.log
Muestra de log:
Pgina 15 de 33
Muestra de Datos
3.7. BTEQ Carga ODS (Insert desde tabla temporal a Tabla final ODS).
El template BTEQ BTEQ_LOAD_WCBI_TB_TEST.bteq tiene como objeto generar la base de
los procesos genricos de carga ODS, en donde se toma la informacin desde una tabla
ubicada esquema TMP, la cual fue creada en la BTEQ de negocio concatenando el prefijo,
el cual debe ser nico por tabla, de modo de asegurar que no se repita la tabla temporal.
Se inserta su data en el esquema ODS. La estructura de ambas tablas debe ser idntica de
modo de asegurar mejor performance.
Parmetros necesarios para la ejecucin de la BTEQ:
Posicin
$1
$2
$3
$4
$5
$6
$7
Parmetros BTEQ
Descripcin
Nombre de Base Tabla TMP
Nombre de la Tabla Origen TMP
Nombre de Base Tabla Destino ODS
Nombre de la Tabla Destino ODS
Servidor Teradata
Usuario Teradata
Password Teradata
Ejemplo ejecucin:
Pgina 16 de 33
Muestra de log:
Muestra de datos:
Pgina 17 de 33
Oracle
(Aplica desde Oracle Versin 8 en adelante)
4. ORACLE
4.1. INTRODUCCIN Oracle
El siguiente documento tiene por objetivo indicar los patrones de diseo para la extraccin,
carga y transformacin (ELT) orientada a la carga en ORACLE, mediante la utilizacin del
utilitario de carga Oracle SQL*Loader.
4.2. ALCANCE Oracle
Este documento posee como alcance disponer de template de desarrollo para procesos de
carga de datos en ORACLE mediante SQL*Loader, con la definicin de los parmetros bases
que se deben considerar en los proyectos. No est en el alcance la definicin funcional de la
base de datos, por ejemplo validar si puede poseer reproceso, vigencia, severidades, etc.
4.3. Formato de archivos
El formato de los archivos debe ser UNIX con fin de lnea LF (Line Feed).
4.4. DETALLE TEMPLATE
4.4.1. Archivo de entrada delimitado
El patrn de adquisicin ser implementado mediante la utilizacin del utilitario
Oracle SQL*Loader para la carga sobre la tabla histrica del proceso.
Este template, permite ser reutilizado como base para la creacin de los procesos
SQL*Loader, y posee un ejemplo de cmo leer un archivo fuente de largo variable,
que puede estar delimitado por cualquier caracter (por ejemplo: pipe | punto y
coma ; coma , etc.) y ser utilizado para realizar la carga de la informacin sobre
una tabla destino.
Pgina 18 de 33
Por cada nuevo proceso de carga, se debe crear un nuevo archivo en base al
template, modificando su nombre en base a la nomenclatura:
SQL_LOAD_ + AcrnimoORIGEN +OWNER + SYNONYM + _DELIM.load
El archivo de texto que contiene datos no debe poseer nombres de las columnas.
En la excepcin que el archivo tenga nombres de columnas en la primera lnea,
entonces se debe especificar que el proceso no la considere, es decir que la
salte. La opcin SKIP indica la cantidad de lneas que deben ser excluidas antes de
comenzar a cargar los datos, lo cual se logra con la sentencia SKIP. Ejemplo:
OPTIONS (SKIP=1)
Para indicar el archivo de datos a cargar, se debe utilizar la sentencia DATA segn
lo siguiente:
DATA= [ruta completa archivo + nombre archivo]
Ejemplo: DATA= /app/[Negocio]/[srv*]/DATA/archivo.dat
Pgina 19 de 33
Pgina 20 de 33
Por cada nuevo proceso de carga, se debe crear un nuevo archivo en base al template,
modificando su nombre en base a la nomenclatura:
SQL_LOAD_ + AcrnimoORIGEN + OWNER + SYNONYM + _LARGO_FIJO.load
Para cada campo, se debe indicar el comienzo y fin del mismo, es decir, el primer y el
ltimo byte que componen el valor del campo.
El archivo control preparado para archivos de ancho fijo es:
SQL_LOAD_TNC_JURO_FARE_LARGO_FIJO.load
Pgina 21 de 33
SILENT
ERRORS
Observacion
Usuario, password e instancia a la que se desea
conectar, el formato es user/pass@instance
Suprime mensajes que normalmente aparecen
por pantalla durante la ejecucin.
Opciones:
HEADER - Suppresses the SQL*Loader header.
Header messages still appear in the log file.
FEEDBACK - Suppresses the "commit point
reached" feedback messages.
ERRORS - Suppresses the data error messages in
the log file that occur when a record generates an
Oracle error that causes it to be written to the
bad file. A count of rejected records still appears.
DISCARDS - Suppresses the messages in the log
file for each record written to the discard file.
PARTITIONS - Disables writing the per-partition
statistics to the log file during a direct load of a
partitioned table.
ALL - Implements all of the suppression
Cantidad mxima de errores permitidos antes de
abortar la operacin.
Ejemplo
scott/tiger@orcl
SILENT=(feedback)
50
Pgina 22 de 33
La Shell debe devolver los cdigos de retorno del proceso. Para SQL*Loader son:
0= Success
1= Fail (error de sintaxis, error del SO, de conectividad o propio de la BD)
2= Warning (algunos o todos los registros rechazados o descartados, o la carga se
interrumpi)
3= Fatal
Ejemplo de ejecucin:
sqlldr parfile=SQL_CONFIG.par control=SQL_LOAD_ESTANDAR_DELIM.load data=archivo.dat
Para este caso se utiliz como input archivo /tmp/data/archivo.dat, el cual est delimitado
por el carcter | y posee 50.000 registros y fue cargado en la tabla destino
TMP_TAM_RNU_REC_SMALL.
Pgina 23 de 33
Muestra de datos:
Pgina 24 de 33
Pgina 25 de 33
Para este caso se utiliz como input archivo de largo fijo /.. /archivo.dat, el cual posee 101
registros (incluyendo los nombres de las columnas), y fue cargado en la tabla destino
TMP_TAM_RNU_REC_SMALL.
Muestra de datos:
Pgina 26 de 33
Pgina 27 de 33
reconstruir los ndices al finalizar la carga, y si hay varias hebras de ejecucin se debe adems
utilizar SKIP_INDEX_MAINTENANCE ya que en caso contrario el proceso abortar debido a que cada
hilo de ejecucin intentar reconstruir los ndices.
SKIP_INDEX_MAINTENANCE: El parmetro SKIP_INDEX_MAINTENANCE=true le indica a
SQL*Loader que no intente reconstruir los ndices finalizada la carga. Est asociado con Parallel y se
debe considerar una reconstruccin de ndices independiente del SQL*Loader una vez que finalicen
ok todos los hilos de carga.
SKIP_UNUSABLE_INDEXES: si la tabla tiene marcado los ndices como no usables SQL*Loader no
realiza la carga, por lo que se requiere agregar el parmetro SKIP_UNUSABLE_INDEXES=true para
que no realice dicha validacin.
Pgina 28 de 33
Figura 2. Diagrama de Secuencia para cargas de ORACLE con SQL*LOADER, escenario Puro/Directo
Pgina 29 de 33
La siguiente tabla muestra qu tecnologa y cul ser su rol en este contexto de cargas de
datos masivas:
Patrn ELT
Arquitectura
Referencia
Definiciones
LNG
STG
TDT
ORACLE
N/A
N/A
X
X: Inicia
llamada a
Shell y
Recibe el
estado de
la carga
Pgina 30 de 33
Figura 4. Diagrama de Secuencia para cargas de ORACLE con SQL*LOADER, escenario MIXTO
Pgina 31 de 33
LNG
STG
ODS
FDM
LANDING. rea
(FileSystem) en la que se
dejan los archivos que
alimentar el STG
TDT
ORACLE
SFTP-Monitor
SFTP-Monitor
X
Ejecuta scripts
Devuelve
respuesta a
Scheduler
X
x - Inicia
llamada a
ETL y
Recibe el
estado
X
Ejecuta scripts
Procedimiento Devuelve
Almacenado
respuesta a
(SP)
Scheduler
x - Inicia
llamada a
ETL y
Recibe el
estado
Procedimiento
Almacenado
(SP)
x
x - Inicia
llamada a
ETL y
Recibe el
estado
SQL*Loader
Pgina 32 de 33
1) LANDING CORE: slo para el escenario donde no se usa infraestructura ETL en mquinas
llamadas BASH
a. /app/[Negocio]/[srv*]/DATA dejar el archivos (slo para el escenario donde no
se usa infraestructura ETL)
b. Para la Shell: /app/[Negocio]/[srv*]/SHL Shell de ejecucin SQL*Loader
2) LANDING en Mquina Pentaho debe usar los directorios estndares:
a. /PHDATA/[PROYECTO]/DAT dejar el archivos
b. /PHAPP/[PROYECTO]/SHL Shell de ejecucin SQL*Loader
3) LANDING en Mquina DataStage debe usar los directorios estndares :
a. /DSDATA/DS[PROYECTO]/DAT dejar el archivos
b. /DSAPP/DS[PROYECTO]/SHL Shell de ejecucin SQL*Loader
Ejemplo:
En DATASTAGE los archivos para usar SQL*LOADER y cargar ORACLE deben quedar en
/ DSDATA/RAC/DAT
Usuarios. Datastage: ds*user_Proy que tiene permisos full sobre sus directorios.
Debe tener en variables de ambiente el path del directorio donde ejecute sqlldr.
Usuario: Base de Datos ORACLE: srv_* que permite realizar la conexin a la base de datos
Usuario del Sistema en el ambiente Unix: dsadmin
Variables de ambiente:
ORACLE_HOME=/opt/oracle/app/oracle/product/11.2.x.x/client
PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin
7. RESOLUCIN DE CONTROVERSIAS
El rea de arquitectura empresarial, es responsable de la construccin y publicacin de este
documento, por lo que es la ltima instancia a cargo de resolver las controversias que se produzcan
por concepto de:
Interpretacin del documento.
Usos tecnolgicos que vayan ms all del espritu de este documento.
Documentacin o normativa considerada obsoleta.
Pgina 33 de 33