Académique Documents
Professionnel Documents
Culture Documents
Nota: para acceder a los links debe estar dentro de la Red LATAM
5. TABLAS ............................................................................................................................ 11
6. VISTAS .............................................................................................................................. 22
7. MACROS ........................................................................................................................... 22
8. FUNCIONES ..................................................................................................................... 23
El siguiente documento tiene por objetivo indicar los estndares y mejores prcticas para los
desarrollos en la plataforma Teradata versin 14 en adelante. Estos lineamientos son una
referencia respecto a la construccin de objetos de base de datos, procedimientos y mejores
prcticas a la hora de enfrentar un buen desarrollo en TDT, el cual es aplicable a Proyectos
tradicionales y Business Intelligence relacionados con Datawarehouse para LATAM Airlines Group.
En consecuencia, las reas de validacin y calidad podrn usar las recomendaciones que se
proponen en el documento, con el objetivo de adaptarlas al proceso de certificacin y poder
mitigar los problemas de perfomance futuros y otros inconvenientes post produccin.
2. ARQUITECTURA DE REFERENCIA
La siguiente figura muestra la arquitectura de referencia que define los lineamientos para el EDW
implementado en Teradata.
Layer 2: Capa de Integracin de Datos: Corresponde a la ODS donde se encuentran las bases WRK
y ODS, cuyo modelo normalizado o desnormalizado que almacena el data warehouse del
negocio. Esta base debe responder en forma dinmica a las necesidades de data para
gestin de la compaa y permita construir diferentes datamarts.
El objetivo del data warehouse corporativo es fomentar la reutilizacin y minimizar costos y el uso
de recursos aprovechando los procesos de carga y las bases de datos que genera y usa la
compaa para la gestin.
En este apartado se define las bases de datos con las que cuenta un proyecto. Cada una de ellas
tiene un objetivo y ciertos permisos que facilitan la carga y la explotacin de la base de datos
Nombre DB corresponde al Nombre Corto del Proyecto. Para las bases existentes, Ej: BIFUEL,
GPNR, GMIDT, etc. Para un Enterprise Data Warehouse, la base tendr las siglas EDW.
Las Bases de Datos principales para EDW son: _FDM, _ODS, _LOG, _STG.
Cada una de las bases de datos tiene un propsito especfico y permisos los cuales se detallan en
la siguiente tabla.
Para los scripts de creacin de modelos que se realizar en la primera oportunidad de paso a
beta y produccin sern aceptadas todas las instrucciones (create, drop, insert, etc) para los
procesos de carga. Sin embargo, en los procesos de carga sistemtica no deben existir scripts
con instrucciones de Create, Alter y/o Drop en los mbitos _FDM u _ODS. Esto ser controlado
en paso a beta.
5. TABLAS
La definicin LATAM para la creacin de tablas busca aplicar mejores prcticas para
optimizar las bases de datos. Para ms detalles de la estructura general de sintaxis para
creacin de tablas en Teradata se puede ver en el anexo 18.1 de este documento.
A continuacin se presenta un ejemplo de una estructura tpica de la creacin de una Tabla
en Teradata para LATAM, que recoge mejores prcticas para mejorar y optimizar el uso de
recursos.
En otro script, debe colectar estadsticas al menos de los campos PI de las tablas fsicas.
Este script ser utilizado por los administradores y no deben ser usadas por los procesos
del proyecto. (Ver apartado 9 para ms detalle).
GROUP BY TotalRows
No debe permitir valores nulos o vacos en los campos que formarn parte del PI. Al
momento de definir una tabla, se debe agregar Not Null a los campos del PI.
Mtodo de
Fortalezas Debilidades
acceso
Es el mtodo ms eficiente, cuando la declaracin SQL Ninguno, mientras la(s) columna(s) sean se
ndice nico contiene el valor del ndice primario. bien escogidas.
primario No requiere un archivo contenido en la base de datos
UPI cuando el nmero de filas retornadas es pequeo
Provee un acceso eficiente cuando la declaracin SQL Requiere costo adicional para INSERT, UPDATE,
contiene los valores de USI, y no se especifica valores de MERGE y DELETE
ndice nico
ndices primarios.
secundario
No requiere un archivo contenido en la base de datos para Se sugiere su uso principalmente para
USI
un SELECT. explotacin de datos. Para las cargas es
afectado en performance.
Provee un acceso eficiente cuando el nmero de filas por Requiere costo adicional para INSERT, UPDATE,
ndice no nico
valor en la tabla es pequea. MERGE y DELETE
secundario
Puede requerir un archivo contenido en la base de datos.
NUSI
Algunas restricciones:
No se debe crear tablas de cola como NoPI
No se debe crear tablas de errores como NoPI
No se deben crear tablas NoPI tipo SET, slo deben ser MULTISET.
Tablas NoPI no deben tener permanent journal.
SQL UPDATE no pueden realizar update a tablas NoPI.
Beneficios:
Una table de tipo NoPI reduce el skew en tablas intermedias de ETL las cuales
no tienen un PI natural.
Las cargas (insert - TPTLoad (FastLoad) y/o TPump) a Tablas de Staging tipo NoPI
son ms rpidas.
Para ms detalles refirase a documentacin oficial Teradata en NoPI
Para las actividades de anlisis de compresin se debe usar MVC que permite obtener
los DDL de los modelos con las compresiones sugeridas. Se puede aplicar posterior a un
anlisis.
Si algn proyecto o modelo requiere usar una o ambas capacidades, deber ser
fundamentado y aprobado por Arquitectura.
Las tablas voltiles se deben identificar en el nombre con el prefijo VLTL. Por ejemplo:
VLTL_ DET_CLIENTESLAN. No requiere fecha porque su vigencia caduca al
finalizar la sesin del usuario.
7. MACROS
Las macros se utilizan para ejecutar un conjunto de tareas repetibles. Las macros son
objetos de base de datos y por lo tanto pertenecen a un usuario o base de datos
especificada en su creacin. Una macro puede ser ejecutada por usuario, BTEQ o por
otra macro. Sin embargo, las macros ejecutadas por otra no se permitirn.
8. FUNCIONES
En Teradata podemos encontrar funciones estndares y definidas por el usuario. Se
aceptar utilizar las funciones estndares y no se aceptar funciones definidas por el
usuario.
Por ejemplo:
Estndar de Desarrollo TERADATA Pgina 23 de 43
Plataforma Teradata Fecha de Publicacin: 2-12-2014
Arquitectura Corporativa LATAM Fecha de Actualizacin: 18-05-2016
Caso 1 (no ptimo):
SELECT rut, nombre FROM bd.pasajeros WHERE rut IN (SELECT rut FROM bd.viajes);
Estimed time: 30 min.
Caso 2:
SELECT pax.rut, pax.nombre FROM bd.pasajeros pax inner join bd.viajes vjs
ON pax.rut = vjs.rut;
Estimed time: 2 min.
Es muy importante saber que en Teradata existen muchas formas de realizar una misma
consulta sin perder los resultados. Los tiempos de espera son dramticamente distintos
entre una buena y mala consulta, es importante que cada Query que se desarrolle sea
visualizada utilizando Explain.
Si un Query demora demasiado favor revisarlo y no volver a reintentar su ejecucin sin
antes haber analizado su plan de ejecucin.
Tomar en cuenta tambin que para un buen desarrollo, primero las mquinas de desarrollo
y beta, deben ser lo ms parecido a su ambiente productivo. El optimizador se comporta
distinto si las versiones de motor Teradata son distintas entre ambientes, o bien, si en
produccin las tablas poseen ms datos que en ambientes de desarrollo y testing.
Intentar siempre utilizar el signo igual (=), cuando se requiere filtrar algn campo de la
tabla esta sean siempre los que forman parte de UPI / NUPI.
Para la Coleccin:
COLLECT STATISTICS
COLUMN (o_orderdatetime,
o_orderkey)
,COLUMN o_orderdatetime
,INDEX o_orderkey
ON Orders;
Ejemplo:
Se debe colectar Estadsticas de tablas temporales y voltiles al menos de los campos PI, las
que deben ser calculadas en los procesos segn corresponda (bteq o scripts).
Se recomienda generar y actualizar estadsticas en campos que son de alta modificacin
como lo pueden ser campos fecha, nmeros de vuelos, etc.
Se debe calendarizar las actualizaciones de las estadsticas. Si las estadsticas no son
actualizadas, los queries pueden tener un mal performance (Tarea que corresponde a DBA).
Durante la construccin y explotacin de una base de datos, se recomienda preparar planes
de estadsticas. Para ello, con el utilitario SQL Assistant o Teradata Studio Express, se debe
usar el comando DIAGNOSTIC HELPSTATS ON FOR SESSION;, de esta forma, obtener
recomendaciones del motor y adems evaluar la variabilidad de los datos en las tablas.
11.1. BTEQ
Es un utilitario basada en herramientas va comando que permite al usuario conectarse a
base de datos Teradata. Provee una interaccin en lnea o batch que permite al usuario
ejecutar sentencias SQL para las operaciones de datos.
Cuando se requiere incluir informacin que reside en archivos fuera de Teradata se puede
hacer utilizando el protocolo MULTILOAD . Si los tiempos de respuesta no son los esperados
utilizar protocolos FASTEXPORT o FASTLOAD a una tabla de paso y luego integrar la
informacin al Teradata con un Insert Select.
En los casos en que se debe realizar un update, es recomendable no usar la instruccin
update ya que los procesos son altos. Adems, se debe considerar que los rollback en
Teradata son bastante costosos en lo que se refiere a tiempo y uso de recursos. En ese caso,
el lugar de update se deber borrar los registros e insertarlos con los valores nuevos.
Si el proceso requiere eliminar registros, mejor hacer una copia utilizando la sentencia
insert select de los datos que no sern borrados en otra tabla. Renombrar la tabla original,
verificar que el insert select haya copiado los registros esperados. Restaurar los permisos
grant de la tabla si corresponde. Realizar un drop table de la tabla original.
Nunca abortar un proceso que lleva mucho tiempo en ejecucin ya que los rollbacks son
costosos en Teradata, sobre todo en los pasos de Merge.
Fechas se debe utilizar DATE. No utilizar CHAR, a no ser que sea estrictamente necesario.
Para esto se solicitar justificacin.
Siempre utilice el mismo formato de campos para valores iguales de distintos modelos,
sobre todo si se piensa interactuar con otros modelos.
Extender el modelo de industria (DataWarehouse), esto facilita la integracin de la
informacin y evita modelos con objetivos similares, agregaciones innecesarias o bien
informacin duplicada.
Ejemplo:
Select <<field(s)>> from example.table_X group by <<field(s)>> order by <<field(s)>>;
El uso de Select distinct (a) from example.table_X order by XX ; este tipo de consultas
es menos eficiente en el motor teradata y por lo tanto no son recomendadas.
Para estos casos tambin se puede utilizar el procedimiento que posee Teradata para
dicha funcin:
Exec sysdba.istableempty (nombre base de datos, nombre_Tabla);
Las consultas deben tener los campos nombrados en la estructura select. Esto garantiza
que los procesos de carga y explotacin no fallen.
Por ejemplo
Select <<campo(s)>> From <<Tabla(s)>>;
Siempre debe utilizar locking for Access en las vistas o en consultas que hacen referencias a
tablas fsicas directamente de esta manera se evitan los bloqueos y mejoran el
performance del motor. Recuerde que el motor asume que los registros no estn siendo
modificados.
Nunca utilice un select * from <table> para revisar informacin. Realice la misma sentencia
pero utilizando el top 100 como mximo. Ejemplo: Select top 100 * from <table>.
FORMATO.
Para los campos fechas y a fin mejorar la lectura de estos, siempre deben crearse con
formato. (Ej. YYYY-MM-DD).
Se recomienda no utilizar definiciones de creacin de tablas que se importen de otros
motores sin una revisin del cdigo segn estas recomendaciones.
Desde la versin 13.10 los campos CHAR y VARCHAR tambin pueden ser comprimidos, por
lo tanto no es necesario restricciones a estos tipos de datos. En relacin a PI de tipo char o
varchar no hay diferencia para el clculo del algoritmo de distribucin.
El uso de Varchar es recomendado si el largo del dato es variable o es null ya que usar
mejor los espacios en el disco que un char.
Se debe tener en consideracin que un campo varchar siempre usara 2 bytes adicionales
para la cabecera. Esto ltimo no es una restriccin de facto.
Los campos CHAR o VARCHAR siempre debe definirlos como CHARACTER SET LATIN NOT
CASESPECIFIC.
Tablas Temporales
Se permitir definir tablas temporales con Set o Multiset, debe tener en consideracin que
la carga sea vlida para el objetivo de negocio o para registros nicos completos.
Nunca use Primary Index(PI) por defecto.
Si los datos soportan, use UPI. Es una mala prctica definir como NUPI un ndice que puede
ser nico. Esto ltimo tiene implicancias negativas en el rendimiento.
Nunca elija un PI con el que sea imposible realizar Join.
Los tipos de datos TIME o TIMESTAMP no hacen un buen PI ya que es casi imposible
conocer sus valores exactos. Si tiene que hacer Join entre varias tablas, debe elegir el PI
que permita esa accin y que distribuya bien con skewfactor menor a 10.
Siempre debe revisar las tablas existentes antes de crear una nueva.
Sin duda es ineficiente crear tablas con idnticos contenidos. Incluso en los casos donde se
necesita slo un subconjunto de los datos existentes, no tiene sentido crear una tabla
nueva y copiar estos datos en ella. Una vista (VIEW) es todo lo que se requiere. Estas
medidas mejorarn el rendimiento general.
Defina NOT NULL siempre que sea posible
Si una columna nunca puede tener un valor NULL, defnala como NOT NULL, incluso si no
es una columna ndice. El performance del sistema mejorar.
Evitar datos nulos o vacos en campos que se utilizaran de filtros.
Nunca Actualice las columnas PI bien definidas.
Teradata se basa en el valor del PI para determinar en qu VPROC residir una fila de
datos. Si cambia el valor del PI, la fila tendr que ser trasladado a otro VPROC. Los cambios
masivos en los valores de PI resultarn en reubicaciones masivas de datos, que son muy
costosos para el rendimiento de TDT.
La mejor eleccin de PI
La mejor eleccin de PI son columnas de tipo de dato: SMALLINT or INTEGER. Sin embargo,
no es una restriccin del motor usar char o varchar como PI.
Tambin es recomendado usar PI donde las columnas sean de tipo char lo ms corta
posible.
Este tipo de sentencias tiene un mal performance y podra bloquear el row hash del
diccionario de datos. Por lo tanto siempre debe primero crear la tabla con sus PI y
posteriormente realizar insert/select.
Nunca use insert/select dentro de la sentencia de creacin de tablas
Se debe verificar la consistencia de los tipos de datos en todas las tablas del modelo.
Para el caso de interactuar con Datastage u otro ETL debe seguir las recomendaciones
indicadas por el vendor en conformidad con Teradata.
Estndar de Desarrollo TERADATA Pgina 34 de 43
Plataforma Teradata Fecha de Publicacin: 2-12-2014
Arquitectura Corporativa LATAM Fecha de Actualizacin: 18-05-2016
16. ESTANDAR DE GENERACIN DE USUARIOS.
El estndar de usuarios en Teradata es el siguiente:
usr_o_proy usuario de operacin para realizar la carga de datos.
usr_m_proy usuario de explotacin desde MSTR.
usr_p_proceso usuario de explotacin exclusivo para procesos que deben ser
identificados por reas productivas. No es de uso general. Slo PROD y ARQ definen
qu procesos deben usar este tipo de usuario.
Username: Nombre usuario: usuario con autorizacin, generalmente de CdN que
puede acceder a las vistas mediante un cliente como sql assisstant o teradata studio.
Una tabla Columnar es solo otro tipo de tabla que puede ser accesada por una
consulta. Una query simple puede accesar mltiples tipos de tablas.
Para ms detalles ver en la documentacin de Teradata CP.
Los Operadores Teradata Parallel Transporter (TPT) juegan un rol vital en la alta velocidad
o mejoras de performance para la extraccin y carga de datos en forma nativa con
Teradata. Adems de la interfaz con la base de datos Teradata, algunos de los operadores
de Teradata PT proporcionan acceso a fuentes externas tales como archivos, DBMS
compatibles con ODBC y middleware orientado a mensajes.
Operadores de productores leen datos de un origen y envan los datos a los streams o
flujos de datos TPT. Los flujos de datos son buffers de memoria en que permiten que
los datos se transmitan de un operador de productor a un operador de los
consumidores, sin almacenar los datos en el disco. TPT proporciona los siguientes
operadores productores:
Operador Export: Utiliza multiplea sesiones del protocolo Teradata FastExport para extraer un gran
volume de datos a alta velocidad desde una o ms tablas en Teradata.
Operador Selector SQL: usa una sola session de Teradata SQL para extraer poco volume de datos
desde una tabla en Teradata. El operador selector SQL tiene dos caractersticas que no estan
disponibles en el operador de export. Puede extraer datos en field mode (i.e. columnas en
formato VARCHAR) y pasa los datos al Operador conector de datos con el fin de tener los datos
escritos en formato delimitado a un archivo externo. El operador Selector SQL puede extraer datos
de tipo LOB.
Operador Data Connector: como un operador productor, este operador lee dato en paralelo
desde multiples fuentes tales como archivos, pipes nombrados, mdulos de acceso y sistemas de
cola de mensajes.
Operador FastLoad INMOD Adapter: Lee datos desde cualquier rutina de tipo FastLoad INMOD.
Las rutinas INMOD son escritas por los usuarios y preprocesan los datos antes de que el dato sea
pasado al adaptados FastLoad INMOD.
Operadores Standalone realizan funciones nicas que no implican el envo o recepcin de datos a TPT
streams. TPT provee los siguientes operadores standalone:
Operador DDL: Enva requerimientos SQL requests a Teradata para realizar operaciones de configuracin
antes de ejecutar tareas de carga o de exportacin. Por ejemplo, antes de cargar datos usando
operadores de carga Load operator usa el operador DDL para enviar un requerimiento de DROP
TABLE y CREATE TABLE para asegurar que la tabla destino est vaca.
Operador OS Command: Enva commandos al OS. Estos son peligrosos ya qye envan instrucciones al
sistema operativo, iniciar ejecutables o shell scripts. Este tipo de comandos no es permitido para los
desarrollos en LATAM.
Operador Load: Es un operador standalone. Este operador enva un requerimiento a Teradata para
aplicar los datos en la tabla destino. Por ejemplo, cuando no hay mas datos en el paso de stage, usa el
operador Load operator como un operador standalone para aplicar los datos que ya estn en la tabla de
destino.
Operador Update operator: Es un operador standalone, este operador realiza la tarea Delete task a una
nica tabla en Teradata. La tarea Delete realiza el borrado ms rpido que usar una sola instruccin
DELETE de SQL cuando se deben eliminar un gran porcentaje de filas de una tabla, como por ejemplo, la
eliminacin de todas las filas con una fecha de la transaccin antes de una fecha determinada.
Los operadores personalizados son operadores desarrollados por el usuario operators. Esta debe ser escrita
en lenguajes de programacin C o C++. Este tipo de desarrollos no estn permitidos para los proyectos en
LATAM.
Grupos de columnas que aparecen a menudo junto con predicados de igualdad. Estas estadsticas se
utilizan para estimar sobre una tabla.
Grupos de columnas usadas para unin o agregaciones, donde hay una dependencia o algn grado
de correlacin entre ellas. Si no se recolectan estadsicas multicolumnas, el optimizador asume una
completa independencia entre los valores de las columnas. Mientras ms haya combinacin de los
valores reales correlacionados, mayor ser el valor de la recoleccin de estadsticas de varias
columnas en esta situacin.
Cuando se recogen mltiples estadsticas sobre una tabla por primera vez, el grupo de todas las
estadsticas con las mismas opciones utilizando en una sola peticin.
Despus de la primera vez que se colectan estadsticas, recoger todas las estadsticas se actualizan
en una tabla en una sentencia, y si todos estn siendo renovados, vuelva a recoger a nivel de tabla.
No confe en las estadsticas de resumen copiadas o transferidas de las estadsticas de resumen de
estadsticas
No confe en resumen o particin de estadsticas copiadas o transferidas entre tablas dentro de un
sistema o a travs de l. Recolectarlos nativamente. Esto asegura que los cambios a la configuracin
y otros detalles internos (por ejemplo cuando se dispone de particiones internas) estn disponibles
para el optimizador.
Estndar de Desarrollo TERADATA Pgina 42 de 43
Plataforma Teradata Fecha de Publicacin: 2-12-2014
Arquitectura Corporativa LATAM Fecha de Actualizacin: 18-05-2016
Recolectar las estadsticas de resumen a nivel de tabla despus de los eventos de carga de datos con
el fin de proporcionar al optimizador recuentos de fila de tabla actuales y otros detalles. Esta
operacin se ejecuta muy rpidamente y es compatible con las extrapolaciones ms eficaces de
estadsticas que no eran capaces de ser recolectado despus de las actualizaciones.
No haga drop y luego recolecte estadsticas. Como registro histrico, las estadsticas se pierden
cuando son eliminadas ya que es menos probable que el optimizador se salte la coleccin de
estadsticas o el muestreo.
Para ms detalles de collecting statistics para Teradata Database 14.10, ver el orange book
titulado: Teradata Database 14.10 Statistics Enhancements by Rama Krishna Korlapati.
3. Documentos Teradata
http://www.info.teradata.com/
4. Teradata Columnar
http://developer.teradata.com/blog/paulsinclair/2011/09/teradata-columnar
http://developer.teradata.com/database/training/rows-versus-columns-why-not-both
7. Recomendaciones a NoPI
https://developer.teradata.com/database/articles/say-yes-to-no-primary-index-no-pi-tables