Estándar de Desarrollo Plataforma Teradata v.4.2-Publicado

LATAM AIRLINES GROUP

Estándar de Desarrollo Plataforma Teradata (Aplica desde TDT Versión 14.10 en adelante)

Arquitectura Corporativa LATAM 22/12/2014 Última Actualización: 18/05/2016

Documento - Versión 4.2

CONTROL DE LAS MODIFICACIONES Versión 1.0

Descripción Construcción del documento

Autor Juan Pablo Morales

Fecha 200902-19

Se incorporan 2 nuevos ítems y 0 definiciones.

Juan Pablo Morales

200903-09

Corrección, 2 ejemplo con alias nemotécnico . y ajustes 1 de formato. menores

Guillermo Ordenes

201305-16

Incorporación 2 de mejores prácticas . 2 Usuarios, Vistas Incorporación y corrección de Ambientes, Particiones, Tipos de Tablas y su operación, aplicación de estadísticas y otros

Gloria Appelgren

201401-14

Gloria Appelgren

201402-25

2.0

Incorporación de links y modificaciones de sintaxis. Configuraciones y otros.

Gloria Appelgren

201405-23

Guillermo Ordenes Hector Saavedra

3.0

Incorporación de observaciones y mejores prácticas

Gloria Appelgren

201406-15

TDT

Gloria Appelgren

201409-30

TDT Guillermo Ordenes Vincent Beghin Elitsoft

Hector Saavedra

Revisado por

201403-11

Cambio de orden de Temas 4.0

Arquitectura de Referencia BI para EDW corporativo. Modificación de Modelos de Base de Datos – Estructura de Data Warehouse Corporativo – EDW. Incorporación de nuevas funcionalidades TDT v14.10 de DB Columnar. Mejores prácticas de Teradata Parallel Tranport. Extensión de los Operadores TPT Recomendación para la

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 1 de 43

Recolección de estadísticas 4.1

DB Extra para “casos de uso” en los que se requiera extracciones de datos desde TDT a otros sistemas.

Gloria Appelgren

201603-15

Lorena Vivanco Vincent Beghin Guillermo Ordenes

4.2

Gloria Appelgren Modificaciones a PI de tipo Char o Varchar, Modificaciones a reglas de Tablas volátiles y temporales, Cálculo de Estadísticas y responsabilidades, uso de vistas DBC, uso de NOPI y otros.

201603-15

Guillermo Ordenes Vincent Beghin

Links importantes de documentación complementaria: 1. Estándar de Manejo de Históricos: EMH 2. Estándar de Construcción Objetos DB: ECODB 3. Estándar de Construcción de Sentencias SQL: ESQL 4. Validación MDC en Detalle: VMDC 5. Estándar de Construcción BTEQ. EBTEQ 6. Estándar DataStage. EDST 7. Políticas de Procesamiento DataStage: PPDST 8. Estándar Pentaho. EPTHO 9. Políticas de la Plataforma Teradata. PPTT 10. Estándares de Desarrollo Plataforma Teradata. EDPTT

Nota: para acceder a los links debe estar dentro de la Red LATAM

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 2 de 43

Índice de Contenidos 1.

INTRODUCCIÓN ................................................................................................................. 5

2.

ARQUITECTURA DE REFERENCIA ................................................................................. 5

3.

DISTRIBUCIÓN DE ESTRUCTURA DE BASE DE DATOS .............................................. 6

3.1.

DISTRIBUCIÓN DATABASE GENERAL ........................................................................... 6

3.2.

DATABASE PARA EXTRACCIONES .............................................................................. 10

4.

DEFINICIONES SOBRE EL USO CORRECTO DE TERADATA .................................... 10

5.

TABLAS ............................................................................................................................ 11

5.1.

CREACIÓN DE TABLAS .................................................................................................. 11

5.2.

ORDEN DE SCRIPT DE CREACIÓN DE TABLAS INICIALES ...................................... 12

5.3.

ORDEN DE SCRIPT DE TRASVASIJE TABLAS ............................................................ 13

5.4.

PRIMARY INDEX DE TABLAS ........................................................................................ 13

5.4.1.

VALIDACIÓN DE DISTRIBUCIÓN DE DATOS ......................................................... 14

5.4.2.

VALIDACIÓN DE SKEW FACTOR ............................................................................ 14

5.5.

TABLAS DE TIPO NOPI ................................................................................................... 16

5.6.

SET VERSUS MULTISET ................................................................................................. 17

5.7.

COMPRESIÓN DE TABLAS ............................................................................................ 17

5.8.

PARTICIONAMIENTO DE TABLAS ................................................................................ 19

5.9.

FALLBACK Y JOURNALIST ........................................................................................... 20

5.10.

JOINS DE TABLAS .......................................................................................................... 20

5.11.

TABLAS TEMPORALES Y VOLÁTILES ......................................................................... 21

5.12.

ALTER TABLE .................................................................................................................. 21

6.

VISTAS .............................................................................................................................. 22

7.

MACROS ........................................................................................................................... 22

8.

FUNCIONES ..................................................................................................................... 23

9.

EXPLAIN Y VISUAL EXPLAIN ......................................................................................... 23

10.

COLLECT STATISTICS.................................................................................................... 25

11.

PROCESOS DE CARGA – FRAMEWORK DE ETL/ELT ................................................ 28

11.1.

BTEQ ................................................................................................................................. 28

11.2.

TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 28

12.

CALIDAD DE DATOS ....................................................................................................... 29

13.

MEJORES PRÁCTICAS TDT ........................................................................................... 30

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 3 de 43

14.

USO Y ACCESO DBC ...................................................................................................... 33

15.

CONFIGURACIÓN CORRECTA DEL ODBC .................................................................. 33

16.

ESTANDAR DE GENERACIÓN DE USUARIOS. ............................................................ 35

17.

NOMENCLATURA DE TABLAS Y CAMPOS DIMENSIONALES................................... 35

18.

ANEXOS ........................................................................................................................... 36

18.1.

FORMATO GENERAL. SINTAXIS DE CREACIÓN DE TABLAS ................................... 36

18.2.

INDEX WIZARD ................................................................................................................ 37

18.3.

SPOOL FANTASMA ......................................................................................................... 37

18.4.

USO DE DATA BLOCK SIZE ........................................................................................... 37

18.5.

TERADATA COLUMNAR ................................................................................................. 38

18.6.

CONJUNTO DE COMANDOS BTEQ ............................................................................... 39

18.7.

TERADATA PARALLEL TRANSPORTER (TPT) ............................................................ 39

18.7.1.

OPERADORES PRODUCTORES ............................................................................. 40

18.7.2.

OPERADORES CONSUMIDORES............................................................................ 41

18.7.3.

OPERADORES STANDALONE ................................................................................ 41

18.7.4.

OPERADORES PERSONALIZADOS ........................................................................ 42

18.8.

COLLECT STATS ............................................................................................................. 42

18.9.

LINK DE UTILIDAD .......................................................................................................... 43

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 4 de 43

1. INTRODUCCIÓN El siguiente documento tiene por objetivo indicar los estándares y mejores prácticas para los desarrollos en la plataforma Teradata versión 14 en adelante. Estos lineamientos son una referencia respecto a la construcción de objetos de base de datos, procedimientos y mejores prácticas 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 validación y calidad podrán usar las recomendaciones que se proponen en el documento, con el objetivo de adaptarlas al proceso de certificación y poder mitigar los problemas de perfomance futuros y otros inconvenientes post producción. 2. ARQUITECTURA DE REFERENCIA En este apartado se muestra la arquitectura de referencia para un Enterprise Data Warehouse (EDW), que todo proyecto de Gestión en LATAM Airlines Group, deberá considerar al momento de implementar en Teradata. Este lineamiento sigue las mejores prácticas de Teradata. La siguiente figura muestra la arquitectura de referencia que define los lineamientos para el EDW implementado en Teradata.

Figura 1. Arquitectura de Referencia BI – Enterprise Data Warehouse en Teradata

Las tres capas en Teradata corresponden a: Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 5 de 43

Layer 1:

Capa de Adquisición correspondiente a las bases Temporales, de Staging y Raw Históricos. Es la primera etapa de carga de datos al motor DB.

Layer 2:

Capa de Integración 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 dinámica a las necesidades de data para gestión de la compañía y permita construir diferentes datamarts.

Layer 3:

Corresponde a la capa de acceso y a la base FDM, donde se encuentran la base dimensional final y las vistas a tablas o de negocio que se requieren para explotar la base dimensional. Por lo tanto se encuentran los datamarts, vistas analíticas o de minería que sean requeridas por el negocio.

El objetivo del data warehouse corporativo es fomentar la reutilización y minimizar costos y el uso de recursos aprovechando los procesos de carga y las bases de datos que genera y usa la compañía para la gestión. 3. DISTRIBUCIÓN DE ESTRUCTURA DE BASE DE DATOS 3.1. DISTRIBUCIÓN DATABASE GENERAL 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 explotación 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.

Figura 2. Modelo lógico y físico para la división en Bases de Datos en Teradata

Cada una de las bases de datos tiene un propósito específico y permisos los cuales se detallan en la siguiente tabla. Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 6 de 43

Nombre de DB y Ámbito

Descripción

1._FDM

En esta base “Final Dimensional Model” - se encuentra el modelo dimensional final de los proyectos en el que se encuentran las tablas de modelos estrella o copo de nieve. Estos deben ser explotados a través de vistas que se detallan en los puntos 2 y 3 de esta tabla. Es la base en la que se encuentra las vistas a tablas VT (view table) del proyecto correspondiente a la capa de ACCESO. Los usuarios o clientes pueden acceder para explotar las Tablas de la base de datos de _FDM. Vistas a Tablas: sus nombres deben seguir la nomenclatura de las tablas. Para identificarlas, todas las consultas deberán llevar el prefijo de la base. Es la base en la que se encuentra las vistas de negocio del proyecto correspondiente a la capa Semántica. Se puede acceder para explotar la base de datos de _FDM. Esto se debe realizar a partir de las _VT y no directamente a las tablas del _FDM. Vistas de Negocio: sus nombres deben seguir la nomenclatura de las tablas. Para identificarlas, todas las consultas deberán llevar el prefijo de la base. Es la base en la que se incorporan tablas de trabajo, previas a la carga del modelo final o intermedia entre STG y ODS.

Ej EDW_FDM

2._VT Ej: EDW_VT

3._VW: Ej: EDW_VW

4._WRK Ej: EDW_WRK 5._ODS Ej: EDW_ODS

Es la base dinámica en la que se encuentra una ODS (Operational Data Store), correspondiente a un modelo normalizado. Contiene las

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

Permisos de usuario para carga de datos (usr_o_....) Desa/Beta/Prod Insert Update Select Delete

Permiso usuario explotación (usr_m_...) o (userid) Desa/Beta/Prod

Select

N/A

N/A

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Select

N/A

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Create Drop Insert Update Select Delete Insert Update Select Delete

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

N/A

N/A

Página 7 de 43

6._VTODS Ej: EDW_VTODS 7._VWODS Ej: EDW_VWODS

8._LOG Ej: EDW_LOG 9._VTLOG Ej: EDW_VTLOG 9.1_VWLOG Ej: EDW_VWLOG

10._STG Ej: EDW_STG

11._VTSTG Ej: EDW_VTSTG 12._VWSTG

tablas fundamentales del negocio que permitan construir los diferentes modelos dimensionales para _FDM. También es posible mantener las tablas agregadas, fact y Lookup de manera que no sea necesario replicar las tablas en el FDM, sino que sean accesadas a través de vistas. Es la base que contiene las vistas a tablas del modelo en _ODS. Corresponde a la capa de acceso a _ODS.

Select

N/A

Es la base que contiene las vistas de negocio que permiten esmascarar semánticamente la _ODS. Las vistas deben ser creadas apuntando a vistas de _VTODS. Nunca directo a las tablas. Es la base que contiene el log de negocio. Su objetivo es dar visibilidad a CdN o Negocio para evaluar los indicadores.

Select

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq) N/A

Insert Update Select Delete

N/A

Es la base correspondiente a la capa de acceso a las tablas del log de negocio del punto 8.

Select

N/A

Es la base correspondiente a la capa semántica a las Vistas de LOG. _VTLOG acceso a tablas con loocking for Access. _VW se construyen utilizando las _VT. Es la base que almacena las tablas RAW Data y corresponde a la etapa de Staging de la carga de datos. Esta debe actualizarse de acuerdo al periodo requerido por el negocio (diario, mensual o anual) Corresponde a la base que contendrá vistas a tablas de la base _STG. Está enfocada exclusivamente para las cargas de la base ODS y permite evitar los bloqueos de tablas. Corresponde a la base que contendrá vistas de negocio y

Select

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq) N/A

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Select a usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq.

Create Drop Insert Update Select Delete

N/A

Select

N/A Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Select

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

N/A Página 8 de 43

Ej: EDW_ VWSTG 13._TMP Ej: EDW_TMP

14._HIS Ej: EDW_HIS

15._VTHIS Ej: EDW_HIS

16.MCP_FDM (modelo dimensional) MCP_ODS (modelo operacional – 3FN) MCP_STG (sólo si es necesario para cargas de archivos externos) 17.- MCP_VT

18.- MCP_VW

que apunta a la base _VTSTG. Está enfocada exclusivamente para las cargas de la base ODS y evitar los bloqueos de tablas. Es la base en la que se incorporan tablas temporales y que se pueden borrar estructuras y datos. Advertencia: Administración podrá borrar sin necesidad de solicitar permisos. Corresponde a la base Histórica de los Staging. Sólo debe almacenar lo que estipule el DWH. Se debe administrar de manera que sólo esté disponible lo que se usará en el lapso de 1 año calendario. Corresponde a la base que contendrá vistas a tablas de la base _HIS. Está enfocada exclusivamente para las cargas de Históricos del Staging y busca optimizar los tiempos de carga en caso de requerir datos históricos. Se deba aplicar la política de manejo de históricos vigente. Es la base en la que se incluyen las tablas de Log para el control de todos los proyecto. Esta base es centralizada y entrega info de control de malla para todos los procesos de carga de Teradata en todas las capas (adquisición, integración y explotación). Es la base en la que se incluyen las vistas a la base MCP_FDM o MCP_ODS para control de carga de todos los proyecto pero que permita ser utilizado desde MSTR. Es la base en la que se incluyen las vistas de negocio a la base MCP_VT para control de carga de todos los proyecto pero que permita ser utilizado desde MSTR.

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq) Create Drop Insert Update Select Delete

N/A

Select Update Delete

N/A

Select

N/A

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Insert Update Select

N/A

Select

N/A

Select (sólo usuarios Microstrategy, Administradores de Sistemas, CdN, Mantto y Arq)

Select (sólo usuarios Microstrategy y Administradores de Sistemas) Select

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

N/A Select (sólo usuarios Microstrategy y Administradores de Sistemas)

Página 9 de 43

19.- MCP_SP

Corresponde a la base con los stored procedure exclusivos para el modelo de control de procesos centralizado.

exec

N/A

Para los scripts de “creación de modelos” que se realizar en la primera oportunidad de paso a beta y producción serán aceptadas todas las instrucciones (create, drop, insert, etc) para los procesos de carga. Sin embargo, en los procesos de carga sistemática 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. 3.2. DATABASE PARA EXTRACCIONES Sólo en el caso de uso de “extracciones de datos” desde Teradata, que involucran procesos temporales y que prepararán archivos de salida para otros sistemas externos a Teradata. Se dispone de una base de datos centralizada y compartida que tiene como raíz una DB denominada EXTRA para este tipo de requerimientos. Cada proyecto deberá gestionar una BD nueva dependiente de EXTRA y una BD de vistas con la estructura como se muestra en el ejemplo. Con lo anterior se garantiza la no interferencia con otros proyectos y recursos independientes. La nomenclatura definida es: [Dirección]_[Negocio o CdN]_ [Proyecto] Estructura de Ejemplo: >> EXTRA  MKT_CU_HUB o MKT_CU_HUB_WRK  MKT_CU_HUB_VTWRK La BD tendrá una cuenta de proceso. En este caso será de extracción ídem a las de procesos de carga (usuario “usr_o”) con permisos de lectura a los modelos a consumir, permisos de insert/update/drop sobre la base de trabajo y un spool adecuado para resolver las extracciones. No podrán tener una cuenta de tipo “usr_m”. El tamaño de la BD propia debe se establecerá en 200 GB como límite máximo para este tipo de iniciativas. Sin embargo, se deberá estudiar cada caso y definir el tamaño requerido con las áreas indicadas. El responsable o proyecto deberá asegurar que las consultas que requiera realizar a bases existentes en Teradata estén optimizadas. 4. DEFINICIONES SOBRE EL USO CORRECTO DE TERADATA La plataforma TERADATA es en esencia un motor de bases de datos relacional orientado al procesamiento de grandes volúmenes de datos para la gestión y el análisis. Es por ello que en LATAM esta plataforma está orientada al DataWarehouse Corporativo. Por lo tanto el uso Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 10 de 43

operacional de la plataforma TERADATA no será aceptado, excepto para el ámbito de integración de datos. 5. TABLAS 5.1. CREACIÓN DE TABLAS La creación de tabla es una de las actividades más relevantes para un buen desarrollo en la plataforma TDT. Una mala definición de tabla puede ocasionar serios problemas al desempeño al motor. La mejor definición de una tabla depende de una serie de características y objetivos. Algunas preguntas típicas que ayudan a modelar y definir en forma más precisa una tabla. 1. ¿Cuál es el Primary Index de cada tabla? ¿Puede ser NOPI? 2. ¿Se debe usar la(s) columna(s) Primary Key como Primary Index? 3. ¿Cuándo debiera ser Non-Unique Primary Index? ¿Qué consecuencias trae esto? 4. ¿Necesitará Secondary Indexes? Si es así, ¿Qué Tipo? ¿Qué columna(s)? 5. ¿Debemos / Podemos permitir filas duplicadas? 6. ¿Qué tipo de datos debiera usar? ¿Qué atributos? 7. ¿Podemos / debemos comprimir? ¿Valores literales? ¿Tabla completa? 8. ¿Qué restricciones se deben definir? ¿Qué costos y consecuencias tiene eso? 9. ¿Se debe generar valores partir de otros campos? 10. ¿Puede/debe particionarse una tabla? 11. ¿Debemos realizar drop a las tablas al final de la sesión en áreas temporales? La definición LATAM para la creación de tablas busca aplicar mejores prácticas para optimizar las bases de datos. Para más detalles de la estructura general de sintaxis para creación de tablas en Teradata se puede ver en el anexo 18.1 de este documento. A continuación se presenta un ejemplo de una estructura típica de la creación de una Tabla en Teradata para LATAM, que recoge mejores prácticas para mejorar y optimizar el uso de recursos. CREATE TABLE ., NO FALLBACK, NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT ( , ……… ) PRIMARY INDEX _() ( BETWEEN DATE EACH INTERVAL ) ; COMMENT ON TABLE TABLE_NAME AS Ejemplo:'Tabla para registrar las transacciones de prueba.'; COMMENT ON COLUMN TABLE_NAME.FIELD_1 IS 'Identificador de los eventos’; COMMENT ON COLUMN TABLE_NAME.FIELD_2 IS 'Indicador de vigencia de los eventos. S=Si; N=No’;

Estándar de Desarrollo Plataforma Teradata Arquitectura Corporativa LATAM

TERADATA Fecha de Publicación: 2-12-2014 Fecha de Actualización: 18-05-2016

Página 11 de 43

Dónde:  >: De preferencia use multiset si es posible, para más detalles ver apartado 3.3 sobre uso de SET/MULTISET  es el nombre de los campos de la tabla, cuya nomenclatura está definida en el documento “Estándar de Construcción Objetos DB” (ECODB).  corresponde al tipo de dato de un campo. Para más detalles puede hacer uso del siguiente link TDT-DataType  PRIMARY INDEX. Se refiere al Índice Primario que debe ser definido por cada tabla, con el objetivo de obtener una buena distribución de datos en la plataforma. Para más detalle ver apartado 3.2.  . Corresponde al nombre de la base de datos en la que debe crear la o las tablas. 