Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Facultad de Ingeniería
Carrera de Ingeniería de Sistemas e Informática
INDICE DE CONTENIDO
Sostenimiento ................................................................................................................ 65
3.4.1 Sostenimiento de data base ................................................................................ 65
3.4.2 Sostenimiento de servidores .............................................................................. 65
4
INDICE DE FIGURAS
INDICE DE TABLAS
INTRODUCCION
se originan a través del invento tecnológico de sus productos y servicios digitales, donde
los canales con mayor afluencia son Internet y el móvil que se ha hecho el medio natural
de actuar recíprocamente con el banco, que de ser olvidado para ir físicamente a una rama.
Por esta razón, el sector tradicional bancario tiene que aprovechar como una
ventaja competitiva la cantidad gran cantidad de datos disponibles en sus sistemas, en tal
debido al crecimiento exponencial de los datos el banco Interbancario opto para usar
que ha hecho posible de automatizar una gran parte de procesos manuales e integra
sistemas de fuentes diferentes con datos a gran escala, sin embargo el volumen de datos ha
infraestructura, lo cual tiene como efecto una reducción alta en la capacidad de respuesta
crecimiento exponencial de datos, sin embargo, los sistemas tradicionales que son usados
por eso que el concepto de Big Data surge, caracterizado por el volumen grande de datos,
su variabilidad y la velocidad que estos son generados, en este sentido es necesario tener
llevado a evaluar las opciones para pasar de las instrumentos de ETL tradicionales a la
nueva tecnología de código abierto de bajo costo que utiliza el paradigma Map Reduce
(M / R) esto promete el tratamiento aún más rápido y también puede tomar datos a tiempo
real.
9
ASPECTOS GENERALES
1.3.1 Alcance
es DATASTAGE v6 IMB.
MARKETING.
1.3.2 Limitaciones
1.4 Justificación
de hechos, lo que permitirá realizar la migración del DataMart que tiene como
La herramienta ETL que actualmente se utiliza para hacer la migración entre ambos
motores y la generación de DataMart es Data Stage - IMB V9, donde los subprocesos
Generación de Archivo Plano: Se genera un archivo plano que volcara los datos de
en formato.TXT.
Carga de Datos: Una vez que se genere el archivo plano será cargado en el motor
El tiempo promedio para migrar los datos de la tabla entre generación del plano
y la carga de datos es de 8 hrs.
15
datos no se podrá abastecer con sus sistemas tradicionales por ende es necesario
almacenamiento datos a gran escala, lo que permitirá ser considerados como una
La relación con el sujeto que está siendo considerado fue repasada por un
este archivo, sirviendo como una referencia para la creación del informe de
desahogo profesional:
Edd Wilder James en el año 2012 es parte del equipo de TensorFlow en Google)
utilizar el componente Sqoop por la trasferencia de data entre Hadoop y las bases
de datos transaccionales.
17
MARCO TEÓRICO
Fundamento teórico
Juan Camargo. (2014) A nivel de negocio se ignora la importancia que existe en los
datos de alto volumen, hoy en día las empresas no utilizan la información que tienen
Ohlhorst, Frank J. (2012) El término BIG DATA es definido como una situación en que
los juegos de datos han cultivado a enormes tamaños que tecnologías convencionales de
crecimiento del juego de datos. En otras palabras, el juego de datos ha crecido tanto, que
sea difícil de poder y aún más difícil conseguir el valor de ello. Las dificultades principales
datos. (2)
18
manejo de volúmenes grandes de datos, además ser altamente escalable y soporta fallos
análisis de los datos que son demasiado grandes o complejos para sistemas de
en una mano que esto es un sistema que facilita una alta adaptabilidad tolerante
a fallos y altamente escalable. De otra parte, Hadoop necesita que los problemas
exportar datos a Hadoop y otras bases de datos, lo que permite ser más factible
Apache Flume (2013). Los Ángeles: Apache Software Foundation. Sitio Web:
http://flume.apache.org/
24
Hive. Es uno de los componentes nativos creado para facilitar las consultas al
Grandes es el camino del cual las cantidades grandes de datos son organizadas
donde terabytes está implicado y aún peta los octetos de información con la
la trasferencia de los datos para tener acceso a los datos estáticos y así
decisiones. (8)
El concepto NoSQL, es requerido para dar una solución con los problemas
Para detallar sobre las bases de datos NoSQL, las características siguientes
variedad. (8)
MARCO CONCEPTUAL
de registro.
estructurados.
2.12 Clúster
2.13 Hadoop
2.14 Hbase
2.15 HDFS
fallos.
Es el lenguaje para la data base relacionada. "Se relaciona con una consulta
data abierta, como existen diferentes motores de bases de datos que han
2.17 MapReduce
tuples, la segunda tarea se refiere a reducir el trabajo, la toma de los datos de salida
2.18 MapReduce
Forma parte de la simbología dentro una base de datos, permite encontrar relaciones
" E-R " es necesario para corresponder a la arquitectura de datos de un sistema bajo
un esquema conceptual.
32
MARCO METODOLOGICO
2.19 SCRUM
Definición
rápido que permite a un proyecto ser evaluado rápidamente. Todo inicia con una reunión
de compañeros, que es por qué esto formula las ideas de la visión del proyecto. Después,
,3raEdición.
33
Composición de SCRUM
,3raEdición.
34
son modificados para encontrar las exigencias del proyecto u organización que lo
utiliza, los principios que no son abiertos pueden ser modificados, y deben ser
A. Control de proceso
Esto enfoca en la filosofía de Scrum basada en las tres ideas principales
B. Auto-organización
Está enfocado en trabajadores, que generan valor cuando ellos se
C. Colaboración
Se basa en reducir las actividades más importantes del trabajo en grupo
su finalización.
35
F. Desarrollo Iterativo
Esto enfoca en el mejoramiento y la creación de los productos que
continuación:
A.-Organización
El propietario del producto: Es responsable de alcanzar el valor del
negocio para el proyecto. Este papel además es responsable del armado de las
exigencias de cliente.
Estas guías de papel, facilitan y enseñan buenas prácticas de Scrum a todo aquellos
complicados en el proyecto.
36
B.-Justificación
Es de vital importancia para la firma el hacer una evaluación pertinente del
respectiva viabilidad.
C.- Calidad
Es definido como la capacidad del resultado o para identificar los criterios
D.-Cambios
Las personas que pertenecen al equipo de proyecto comprendan el
desarrollo de procesos Scrum sean diseñados para alejarse del cambio. Las
entidades deberían maximizar las ventajas que son sacadas de los cambios, y
E.-Riesgo
Es definido como un acontecimiento o el grupo de los acontecimientos no
esperados que impactan con los objetivos del proyecto y puedan aportar a su éxito
o fracaso.
,3raEdición.
39
,3raEdición.
40
MARCO LEGAL
que tiene como origen el motor de Oracle hacia la plataforma Hadoop, antes de
Ruta: /data/prod/IBKProjects/BD_MigracionOracle/Log
Ruta: /data/prod/IBKProjects/BD_MigracionOracle/Shell
Utilizaremos Nifi para poder orquestar todo el flujo de datos a migrar, para ello es
Jar
Utils
Orquestador
La aplicación fue java y scala la cual permitirá orquestar todo el flujo de carga
Ruta: /data/prod/IBKProjects/DataHubNifi/Jar
Ruta: /data/prod/IBKProjects/DataHubNifi/Orquestador
Cada tabla a migrar tendrá un TDHC que permitirá cargar los datos hacia
Teradata. Los TDHC son cadenas de conexión que permitirán conectarse a
teradata.
Dentro del archivo se creará una carpeta LOG, la cual almacenará los eventos de carga
hacia Teradata.
Servidores
Name Node:
Data Node:
Desarrollo y QA (Edge):
Memoria 252.
TABLA 6: TABLERO_CONTROL_HIVE
CAMPOS DESCRIPCION
OWNER ESQUEMA DE DATA BASE
TABLE_NAME NOMBRE DE TABLA A MIGRAR
CAMPO_PARTICIONADO NOMBRE DEL CAMPO PARTICIONADO
FECHA_CARGA FECHA DE CARGA
TIPO DE FRECUENCIA DE CARGA : "DIARIA", "MENSUAL",
TIPO_CARGA "SEMANAL"
CARGO_TABLA ESTADO DEL PROCESO: "ACTIVO" "INACTIVO"
FECHA_EJECUCION FECHADO DE EJECUCIÓN DEL PROCESO
TABLA 7: LOADLOG_PROCESS_HADOOP
CAMPOS DESCRIPCION
IDLOAD NUMERO CORRELATIVO
OWNER ESQUEMA
TABLE_NAME NOMBRE DE TABLA EJECUTADA EN LA TABLA DE CONFIGURACIÓN
FECHA_CARGA FECHA DE CARGA
DATE_PROCESS FECHA DE EJECUCIÓN DEL PROCESO
RESULT_SQOOP RESULTADOS DE LA EJECUCIÓN DEL SQOOP: "SUCCESS" Y "FAILED"
RESULT_INSERT RESULTADOS DE LA EJECUCIÓN DEL INSERT: "SUCCESS" Y "FAILED"
OBSERVATION RESUMEN DE LA EJECUCIÓN DEL PROCESO SQOOP O INSERT
51
TABLA 8: TABLE_CONTROL_TDCH
CAMPOS DESCRIPCION
SCHEMA_HIVE_ORIGEN NOMBRE DEL ESQUEMA EN HIVE
NAME_TABLE_HIVE_ORIGEN NOMBRE DE LA TABLA EN HIVE
SCHEMA_TDT NOMBRE DEL ESQUEMA DESTINO EN TERADATA
NAME_TABLE_TDT NOMBRE DE LA TABLA DESTINO EN TERADATA
HDFS_TABLE RUTA LOGICA HDFS
FIELD_ORIGEN NOMBRE DE CAMPO PARTICIONADO EN ORACLE
FORMAT_FIELD TIPO DE DATO PARTICIONADO EN ORACLE
PARTITION_HIVE NOMBRE DE CAMPO PARTICIONADO EN HIVE
FORMAT_PARTITION TIPO DE DATO PARTICIONADO EN HIVE
FEC_HIVE FECHA DE CARGA EN HIVE
FORMAT_FEC_HIVE FORMATO DE LA FECHA "YYYMMDD"; "YYYMM"
STATUS ESTADO DEL PROCESO: "ACTIVO" "INACTIVO"
TYPE_LOAD TIPO DE CARGA: "REPROCESO", "INCREMENTAL"
TIPO DE FRECUENCIA DE CARGA : "DIARIA", "MENSUAL",
FREQUENCY "SEMANAL"
FIELD_HIVE_EXPORT NOMBRE DE LOS CAMPOS A MIGRAR
FIELD_TDT_EXPORT NOMBRE Y TIPOS DE DATOS POR CAMPO
TABLA 9: DELIVERYLOG_PROCESS
CAMPOS DESCRIPCION
IDLOAD CORRELATIVO CONCATENADO CON ELNOMBRE DETABLA
SCHEMA_TDT NOMBRE DEL ESQUEMA TERADATA
NAME_TABLE_TDT NOMBRE DE LA TABLA DESTINO TERADATA
FEC_HIVE FECHA DE CARGA EN HIVE
DATE_PROCESS FECHA DE EJECUCIÓN DEL PROCESO EN TERADATA
RESULT_PROCESS RESULTADOS DE LA EJECUCIÓN BTQ: "SUCCESS" Y "FAILED"
OBSERVATION RESUMEN DE LA EJECUCIÓN DEL PROCESO
52
Desarrollo Metodológico
3.2.1 Visión
3.2.2 Organización
53
54
Como usuario necesito que se genere Se desarrollará módulo de registro de log de carga
la campaña de “Propensión de a Teradata. 7
Fuga de clientes” con los productos:
Como usuario necesito que se genere Se realizará la construcción de cada una de las
la campaña de “Propensión de tablas a migrar en el HDFS que soporte la carga de 7
Fuga de clientes” con los productos: datos.
Se desarrollará orquestador que permita la carga de
3 tablas de Hadoop hacia Teradata. 7
Se construirá árbol de carpetas en área EDGE. 7 2
a) Pre-Retención Se orquestará los procesos de carga de datos en 9
b) Retención NIFI hacia Teradata cada vez que este activo en el
tablero de control.
57
Televenta (TLV).
Asesor de Banca Personal Se creará tablero de control que permita registrar 7
(ABP). las tablas a migrar de Hadoop hacia Teradata.
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Como usuario necesito que se genere Se desarrollará Scripts que permitan la extracción
la campaña de Propensión de Fuga y carga de datos a Teradata. (Sqoop Export) 9
de clientes” con los productos:
Nro
Hist Actividades Resultados Resultados
Positivos Negativos
Se identificará tablas de Oracle a Migrar.
Se desarrollará tablero de control que permita registrar El equipo de QA
las tablas a migrar de Oracle hacia Teradata. logro identificar
Se desarrollará tablero de registro de logs para el que en el mapeo
monitoreo y soporte a la aplicación. de tablas a Ninguna.
1 Se desarrollará orquestado de los procesos de carga de migrar, faltaba 1
datos en NIFI hacia Hadoop. de las tablas que
Se desarrollará el modulo que permita registrar a forman parte del
detalle un archivo log de carga a Hadoop. modelo de datos.
Se desarrollará módulo de registro de log de carga a
Teradata. El equipo de QA Problemas por
Se desarrollará Scripts para la extracción y carga de logro identificar parte del área de
datos a Hadoop de la estructura de datos y la inserción que en una de las TI del banco con
de los mismos. (Sqoop Import) tablas a migrar el respecto a la
2 Se desarrollará Scripts de la estructura de datos y la volumen de datos inestabilidad del
inserción de los mismos que permitan la carga en ORACLE no ambiente de
histórica de datos en Hadoop. (Hive) era el mismo que DESARROLLO.
Se realizará la construcción de cada ruta lógica en el en TERADATA.
HDFS que soporte la carga de datos.
Se realizará la construcción de cada una de las tablas
a migrar en el HDFS que soporte la carga de datos. Se logró realizar
Se desarrollará orquestador que permita la carga de la migración a
tablas de Hadoop hacia Teradata. Hadoop de los
Se construirá árbol de carpetas en área EDGE. datos ya se
Se orquestará los procesos de carga de datos en NIFI cuenta con Ninguna.
3 hacia Teradata cada vez que este activo en el tablero información
de control. histórica para
Se creará tablero de control que permita registrar las poder
tablas a migrar de Hadoop hacia Teradata. disponibilizarla
en TERADATA.
Se desarrollará Scripts que permitan la extracción y
carga de datos a Teradata. (Sqoop Export) Se logró La base de datos
Se desarrollará Scripts en Teradata de la estructura de disponibilizar la TERADATA no
tablas a migrar que soporten la carga de datos desde información en tenía instalado el
Hadoop. TERADATA de driver para
Se desarrollará modulo que permita registrar todo el forma conectarse con
4 log de carga que escribe de Hadoop hacia Teradata en satisfactoria, se Hadoop, se tuvo
cada ejecución. cumplió con que realizar la
Se construirá Shell que permita asignar permisos a los garantizar la instalación para
diferentes usuarios que utilicen la utilización. integrar y poder exportar
Se ejecutara casos de prueba para garantizar la confianza en los los datos hacia
integridad de los datos. datos migrados. TERADATA.
59
Nro
Hist Actividades Resultados Resultados
Positivas Negativas
Se identificará tablas de Oracle a Migrar.
Se desarrollará tablero de control que permita El equipo de QA
registrar las tablas a migrar de Oracle hacia logro identificar
Teradata. que en una de las
Se desarrollará tablero de registro de logs para el tablas a migrar no Ninguna.
1 monitoreo y soporte a la aplicación. estaba viajando 4
Se desarrollará orquestado de los procesos de carga conceptos
de datos en NIFI hacia Hadoop. correspondientes
Se desarrollará el modulo que permita registrar a al catálogo de
detalle un archivo log de carga a Hadoop. producto.
Se desarrollará módulo de registro de log de carga
a Teradata. El equipo de
Se desarrollará Scripts para la extracción y carga desarrollo logro
de datos a Hadoop de la estructura de datos y la identificar que la
inserción de los mismos. (Sqoop Import) propiedad de
2 Se desarrollará Scripts de la estructura de datos y la compresión Ninguna.
inserción de los mismos que permitan la carga PARQUET en
histórica de datos en Hadoop. (Hive) Hadoop redujo el
Se realizará la construcción de cada ruta lógica en almacenamiento
el HDFS que soporte la carga de datos. en un 80%.
Se realizará la construcción de cada una de las
tablas a migrar en el HDFS que soporte la carga de El equipo de
datos. desarrollo logro
Se desarrollará orquestador que permita la carga de optimizar el
tablas de Hadoop hacia Teradata. procesamiento de
Se construirá árbol de carpetas en área EDGE. datos en HIVE a Ninguna.
3 Se orquestará los procesos de carga de datos en nivel de CPUs y la
NIFI hacia Teradata cada vez que este activo en el memoria RAM
tablero de control. utilizando de
Se creará tablero de control que permita registrar forma eficiente los
las tablas a migrar de Hadoop hacia Teradata. recursos
computacionales.
Se desarrollará Scripts que permitan la extracción y
carga de datos a Teradata. (Sqoop Export) El equipo de QA
Se desarrollará Scripts en Teradata de la estructura logro identificar
de tablas a migrar que soporten la carga de datos que al cargar la
desde Hadoop. información a
Se desarrollará modulo que permita registrar todo TERADATA Ninguna.
4 el log de carga que escribe de Hadoop hacia ciertas columnas
Teradata en cada ejecución. estaban viajando
Se construirá Shell que permita asignar permisos a con caracteres
los diferentes usuarios que utilicen la utilización. extraños.
Se ejecutara casos de prueba para garantizar la
integridad de los datos.
60
Nro
Sprint Puntos de Mejora
Se deberá contar con un recurso que pueda asumir con responsabilidad ante
la ausencia de algún recurso de manera que no se impacte la planificación.
Definir un horario fijo para los Dailys a fin que no se vean impactadas otras
actividades.
3.2.2 Tiempos
Utilización
Sostenimiento
operativos.
CAPITULO 4
RESULTADOS
4.1. Resultados
Se obtuvo la evidencia del histórico de Jobs de ejecución del proceso ETL de DATA STAGE v9, donde
tal como muestra la imagen el tiempo para generar un archivo plano es de 03 Hrs 43 Min y para cargar
el archivo plano hacia Teradata 04 Hrs 38 Min en comparación del sistema Big Data que tiene una
duración total de 02 Hrs y 06 Min.
En resumen, con la implementación del sistema de migración BIG DATA mejoramos el proceso de
migración de 8 Hrs a de 2 Hrs con respecto al sistema tradicional de integración de datos.
67
4.2. Presupuesto
4.2.1 Gestión de Costos
El total de la inversión contiene el desarrollo y la Implementación. Los tiempos estimados
para el proyecto son los siguientes:
Horas Dias
TIEMPO DEL
PROYECTO 480 60
ya que el cálculo del NPV que esto presenta es la S/. 3,133.85. Esta cifra
Tabla 6: Curva S
71
CONCLUSIONES
1. Al realizar la ingesta de datos con Apache Sqoop a Hadoop, se pudo centralizar todos
compañía.
2. Al realizar el procesamiento de datos con Apache Hive, permitirá realizar consultas SQL
al HDFS con el fin de poder explotar la data almacenada en forma de archivo plano en
3. En base a las evidencias obtenidas por el histórico de LOGS, hubo una mejora
completo de la migración.
72
BIBLIOGRAFÍAS
1. Juan José Camargo Vega. (2014). Knowing the Big Data. 2018, de Universidad
Pedagógica y Tecnológica de Colombia Sitio web:
http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S0121-
11292015000100006
2. Ohlhorst, Frank J. (2012). Turning Big Data into Big Money.. 2018, de SAS Sitio
web: https://www.sas.com/storefront/aux/en/spbdabm/65113_excerpt.pdf
3. T. Olavsrud (2012), Big Data Causes Concern and Big Confusion.2018, Sitio
web:http://www.cio.com/article/700804/Big_Data_Causes_Concern_and_Big_C
onfusion?page=2&taxonomyId=3002
4. José Ruiz. (2016). Clasificación de tráfico de red usando Hadoop y GPUs. 2019,
de Universidad Nacional de Entre Ríos Sitio web:
http://sedici.unlp.edu.ar/handle/10915/52630
5. Gary Reyes. (2016). Evaluación del marco de trabajo Hadoop y Power View en
la Visualización de Trayectorias GPS Vehicular. 2019, de Universidad de
Guayaquil (UG) Sitio web: https://www.researchgate.net/publication/304065564
6. David López García. (2012). Analysis of the possibilities of use of Big Data in
organizations. 2019, de Universidad de Cantabria Sitio web:
https://repositorio.unican.es/xmlui/bitstream/handle/10902/4528/TFM%20-
%20David%20L%C3%B3pez%20Garc%C3%ADaS.pdf?sequence=1&isAllowe
d=y
7. Rodríguez, Francisco. (2015). Herramientas para Big Data : entorno Hadoop..
2019, de Universidad Politécnica de Cartagena Sitio web:
http://repositorio.upct.es/bitstream/handle/10317/4402/tfg482.pdf?sequence=1&
isAllowed=y
8. Luis F. Tabares. (2014). Big Data Analytics: Oportunidades, Retos y Tendencias.
2019, de Universidad de San Buenaventura Cali Sitio web:
https://s3.amazonaws.com/academia.edu.documents/38520697/Tabares_Hernan
dez_2014-
big_data_analytics_FINAL.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53U
L3A&Expires=1547339495&Signature=s5%2FrN5yoLLrnJ6ofTxRBFul3vFw%
3D&response-content-
disposition=inline%3B%20filename%3DBig_Data_Analytics_Oportunidades_R
etos_y.pdf
73
ANEXOS
Gestión de la Calidad
74
Identificación de Riesgos