“implementaciÓn de un sistema de bigrepositorio.utp.edu.pe/bitstream/utp/1944/1/carlos... ·...
TRANSCRIPT
1
Facultad de Ingeniería
Carrera de Ingeniería de Sistemas e Informática
“IMPLEMENTACIÓN DE UN SISTEMA DE BIG
DATA APLICADO A LA MIGRACION DE DATOS
BAJO LA DISTRIBUCION CLOUDERA CON
APACHE HADOOP, EN EL BANCO INTERBANK”
Autor: Carlos Linares Berrocal
Para obtener el Título Profesional de Ingeniero de Sistemas e
Informática
Asesor: Ing. Pedro Molina Velarde
Lima – Mayo 2019
2
INDICE DE CONTENIDO
INDICE DE FIGURAS .................................................................................................. 4
INDICE DE TABLAS .................................................................................................... 5
INTRODUCCION .......................................................................................................... 6
ASPECTOS GENERALES ........................................................................................... 8
1.1. Definición del Problema .................................................................................... 8
1.1.1. Descripción del Problema .................................................................................. 8
1.2. Definición de objetivos ...................................................................................... 9
1.2.1. Objetivo general ................................................................................................. 9
1.2.2. Objetivos específicos ......................................................................................... 9
1.3. Alcances y limitaciones ....................................................................................... 10
1.3.1 Alcance ............................................................................................................. 10
1.3.2 Limitaciones ...................................................................................................... 11
1.4 Justificación ..................................................................................................... 12
1.5 Estado del Arte ................................................................................................. 14
MARCO TEÓRICO ..................................................................................................... 16
2.1 Definición de Big Data .................................................................................... 16
2.2 ¿Qué es Hadoop? ............................................................................................. 17
2.3 Arquetipo Big Data .......................................................................................... 18
2.5 Ecosistema Hadoop .......................................................................................... 19
2.6 Proceso MapReduce......................................................................................... 20
2.7 Arquetipo HDFS .............................................................................................. 21
2.8 Componentes Hadoop ...................................................................................... 22
2.8 Tipos de carga de trabajo ................................................................................. 23
2.9 Principales diferencias entre las Metodologías Ágiles y Cascada ................... 26
MARCO CONCEPTUAL ............................................................................................ 27
2.8 Data base ............................................................................................................... 27
2.9 Bases de datos NoSQL .......................................................................................... 27
2.10 Big Data .............................................................................................................. 27
2.11 Big Transaction Data ....................................................................................... 28
2.12 Clúster .............................................................................................................. 28
2.13 Hadoop ............................................................................................................. 28
3
2.14 Hbase ............................................................................................................... 29
2.15 HDFS ............................................................................................................... 29
2.16 Lenguaje SQL .................................................................................................. 29
2.17 MapReduce ...................................................................................................... 30
2.18 Modelo de datos entidad/relación ....................................................................... 30
MARCO METODOLOGICO ..................................................................................... 31
2.19 SCRUM .............................................................................................................. 34
MARCO LEGAL .......................................................................................................... 43
2.20 Leyes Aplicadas al Proyecto ................................................................................ 43
3.1 DESARROLLO DE LA APLICACIÓN ......................................................... 44
3.1.1 Requisitos Funcionales ...................................................................................... 44
3.1.2 Requisitos No Funcionales ................................................................................ 48
3.1.3 Diseño de Estructurales...................................................................................... 49
3.1.4 Modelo Dimensional .......................................................................................... 51
3.1.5 Arquitectura del Sistema de Migración ............................................................. 52
3.1.6 Estructura Conceptual del Sistema de Migración ............................................. 53
3.1.7 Estructura Tecnología del Sistema de Migración .............................................. 54
3.1.8 Capas del Data Lake .......................................................................................... 54
3.1.9 Diccionario de datos .......................................................................................... 55
DESARROLLO METODOLOGICO ........................................................................ 57
3.2.1 Visión ................................................................................................................. 57
3.2.2 Organización ...................................................................................................... 57
3.2.3 Historia de usuario ............................................................................................. 59
3.2.4 Tiempos .............................................................................................................. 60
UTILIZACIÓN ............................................................................................................. 61
3.3.1 Tablero de control Oracle a Hadoop .................................................................. 61
3.3.2 Tablero de registro de Log de carga de Oracle a Hadoop .................................. 61
3.3.3 Orquestador de Procesos NIFI ........................................................................... 62
3.3.4 Servidor de Archivos ( Edge ) ........................................................................... 63
3.3.5 Tablero de control Hadoop a Teradata .............................................................. 64
3.3.6 Tablero de registro de Log de carga de Hadoop a Teradata .............................. 64
Sostenimiento ................................................................................................................ 65
3.4.1 Sostenimiento de data base ................................................................................ 65
3.4.2 Sostenimiento de servidores .............................................................................. 65
4
3.4.3 Sostenimiento de servidor de aplicaciones ........................................................ 65
CAPITULO 4 ................................................................................................................ 66
RESULTADOS ............................................................................................................. 66
4.1. Resultados ........................................................................................................ 66
4.2. Presupuesto ...................................................................................................... 66
4.2.1 Gestión de Costos ............................................................................................ 66
CONCLUSIONES ........................................................................................................ 72
BIBLIOGRAFÍAS ........................................................................................................ 73
ANEXOS ....................................................................................................................... 74
Work Breakdown Structure (WBS) ........................................................................... 74
Gestión de la Calidad ................................................................................................. 74
Identificación de Riesgos ........................................................................................... 75
5
INDICE DE FIGURAS
Figura 1: Árbol del Problema
Figura 2: Diagrama de flujo generación de campañas
Figura 3: Proceso ETL de Migración de Datos
Figura 4. Arquetipo genérico de Big Data
Figura 5. Ecosistema Big Data
Figura 6. Proceso MapReduce
Figura 7. Arquetipo HDFS
Figura 8. Flujo de datos
Figura 9. Visión general de flujo de Scrum
Figura 10. Composición de SCRUM
Figura 11. Estructura de la organización SCRUM
6
INDICE DE TABLAS
Tabla 1. Atributos del Big Data
Tabla 2. Principales diferencias entre las Metodologías Ágiles y Cascada
Tabla 3. Procesos fundamentales de Scrum
Tabla 4. Comparación de Scrum con la Gestión tradicional
Tabla 5. Leyes Aplicadas al Proyecto según la constitución del Perú
Tabla 6. Tablero de control Oracle - TABLERO_CONTROL_HIVE
Tabla 7. Tablero Log Oracle - LOADLOG_PROCESS_HADOOP
Tabla 8. Tablero de control Teradata - TABLE_CONTROL_TDCH
Tabla 9. Tablero Log Teradata - DELIVERYLOG_PROCESS
7
INTRODUCCION
En la actualidad sector financiero está experimentando importantes cambios que
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.
En este contexto, la banca tradicional debe de transformarse en digital por estrategias
innovadoras de enfoque al cliente y la oferta la atención personalizada.
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
sentido la gestión de datos a gran volumen puede hacerse un procedimiento complejo,
debido al crecimiento exponencial de los datos el banco Interbancario opto para usar
instrumentos ETL que permiten la integración y el orden de gestión de data base,
evaluaremos la herramienta Data Stage – versión 7 desarrollado por la compañía IBM,
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
alcanzado un nivel donde estos pasos aumentan el funcionamiento y el coste de
infraestructura, lo cual tiene como efecto una reducción alta en la capacidad de respuesta
del negocio por lo tanto esto no trabajaría de manera eficiente.
8
La tendencia global se refiere a la era de transformación digital que implica el
crecimiento exponencial de datos, sin embargo, los sistemas tradicionales que son usados
en entidades no lo apoyan ya que ellos sólo trabajan con la información estructurada, es
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
una plataforma tecnológica que facilita la administración y tareas de seguridad en un
ecosistema de nivel alto en el tratamiento y el almacenaje de información, esto nos ha
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.1. Definición del Problema
1.1.1. Descripción del Problema
Debido al crecimiento exponencial de los datos en Interbank se está
presentando inconvenientes para la gestión y almacenamiento de datos a gran
escala lo que está generando un incremento en costos operativos y de
infraestructura, por esa razón es necesario poder contar con una
plataforma tecnológica que pueda soportar las tareas de registros y
procesamiento en un ecosistema escalable y de alta disponibilidad.
Figura 1: Árbol del Problema
Nota: Elaborado por el autor del informe.
10
1.2. Definición de objetivos
1.2.1. Objetivo general
Implementar un sistema de migración de datos que permita la optimización de
tiempos en el procesamiento de los datos, un ahorro en costos a nivel de
infraestructura, además de gestionar el crecimiento exponencial de los datos con
el fin de garantizar la escalabilidad y alta disponibilidad del sistema.
1.2.2. Objetivos específicos
Realizar la ingesta de datos a Hadoop con Apache Sqoop.
Realizar el procesamiento de datos en Hadoop con Apache Hive.
Evidenciar tiempos de ejecución entre las 2 soluciones, Apache Hadoop
vs ETL Tradicional.
.
11
1.3. Alcances y limitaciones
1.3.1 Alcance
El alcance del proyecto abarcara la fase de migración de datos entre los
motores de bases de datos, Fuente: ORACLE y Destino: TERADATA.
La herramienta que se utiliza actualmente para hacer la migración de datos
es DATASTAGE v6 IMB.
La fuente a migrar será el DATAMART correspondiente al área de
MARKETING.
Figura 2: Diagrama de flujo generación de campañas
Nota: Elaborado por el autor del informe.
12
1.3.2 Limitaciones
Cuando se desarrolló el proyecto las limitaciones siguientes fueron presentadas:
Falta de permisos de escritura y lectura en las bases de datos ORACLE y
TERADATA, además de la herramienta de integración de datos Data
Stage donde se almacenan los procesos ETL a migrar.
Desconocimiento del negocio de los procesos ETL a migrar.
La integración con otras aplicaciones que consuman el contenido
disponible en la data base de destino (TERADATA) no está contemplado
dentro del proyecto.
Por políticas internas del banco la información que se almacenará en
Hadoop será On Premise.
13
1.4 Justificación
Se desea implementar un sistema de migración de datos bajo la plataforma Hadoop
que permitirá mejorar tiempos en procesamiento y almacenamiento de datos, además
reducción de costos a nivel de infraestructura.
La fuente de datos que utilizaremos será el DataMart de Marketing quien
internamente es un modelo dimensional de datos conformado dimensiones y una tabla
de hechos, lo que permitirá realizar la migración del DataMart que tiene como
objetivo generar las campañas de Tarjeta de créditos y Compra Deuda Activa.
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
que forman parte del proceso de migración se dividen en 2 partes:
14
Generación de Archivo Plano: Se genera un archivo plano que volcara los datos de
la tabla IN_BASE_42K_VIGENTE proveniente de las fuentes de datos en ORACLE
en formato.TXT.
Carga de Datos: Una vez que se genere el archivo plano será cargado en el motor
De data base TERADATA.
PROCESO ETL - MIGRACION DE DATOS
Figura 3: Proceso ETL de Migración de Datos
Nota: Elaborado por el autor del informe.
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
Finalmente se llegó a la conclusión que debido al crecimiento exponencial de los
datos no se podrá abastecer con sus sistemas tradicionales por ende es necesario
la implementación de una plataforma que permita dar soporte, gestión y
almacenamiento datos a gran escala, lo que permitirá ser considerados como una
empresa DATA DRIVEN apalancando la toma de decisiones en hechos reales
provenientes de fuentes internas y externas a la empresa, además de optimizar
tiempos a nivel de procesos y costos en infraestructura.
1.5 Estado del Arte
La relación con el sujeto que está siendo considerado fue repasada por un
fondo claramente relacionado con el asunto de investigación presentado en
este archivo, sirviendo como una referencia para la creación del informe de
desahogo profesional:
Antecedente 1: Según (GALEANO, 2017) en su Tesis de nombre “PROTOTIPO
DE LABORATORIO HADOOP PARA ANÁLISIS BIG DATA EN LA
INSTITUCIÓN UNIVERSITARIA POLITÉCNICO GRAN
COLOMBIANO”, hace mención de la plataforma Hadoop puede hacer el análisis
y registros de información Big Data, además de servir como guía o referencia
para aprender a montar un ambiente Hadoop.
Antecedente 2: Según (Shiqi Wu, 2015) en su Tesis de nombre “BIG DATA
PROCESSING WITH HADOOP”, hace la mención de Apache Hadoop, como
una tecnología abierta de proyecto y distribuida informática de la fuente
16
bajo una plataforma de ordenador simple y centralizada por reduciendo el coste
de hardware, además de las características de tecnología de tratamiento de datos
distribuidos ha cambiado la industria entera.
Antecedente 3: En el trabajo de investigación “¿What is big data?” realizado por
Edd Wilder James en el año 2012 es parte del equipo de TensorFlow en Google)
se detalla del valor de Big Data en una organización.
Antecedente 4: Según la guía oficial “Sqoop User (v1.4.2)” realizado por
compañía Apache Software Fundation en el año 2012, se detalla la forma como
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
almacenada de forma adecuada con el fin de poderla analizar y posteriormente apalancar
la toma de decisiones. Es importante destacar la importancia de los datos y el alto
crecimiento en el volumen, velocidad y variabilidad. Debido al cambio radical en los
datos y al gran avance a nivel tecnológico de la información. Es importante que las
empresas independientemente de su tamaño cambien el modo en el que ellos puedan
manejar datos y lo convierten en el conocimiento útil en sus tareas diarias. (1)
2.1 Definición de Big Data
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
la información. Es más necesario manejar el tamaño del juego de datos o la escala y el
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
son la adquisición, el almacenaje, la búsqueda, el cambio, Analytics y la visualización de
datos. (2)
18
Tabla 1. Atributos del Big Data
UNIVERSITY OF AMSTERDAM. (2013) Defining the Big Data
Architecture Framework. Ámsterdam, Sitio Web:
http://bigdatawg.nist.gov/_uploadfiles/M0055_v1_ 7606723276.pdf
2.2 ¿Qué es Hadoop?
T. Olavsrud (2012) Apache Hadoop es una plataforma open que permite el
funcionamiento de aplicaciones intensivas de datos distribuidos dentro de un clúster,
contiene una infinidad de componentes nativos de la misma plataforma que permite el
manejo de volúmenes grandes de datos, además ser altamente escalable y soporta fallos
del sistema. (3)
19
2.3 Arquetipo Big Data
Una estructura de Big Data es diseñada para manejar la ingestión, procesando y
análisis de los datos que son demasiado grandes o complejos para sistemas de
data base tradicionales.
Figura 4. Arquetipo genérico de Big Data
MICROSOFT (2017). Big data architecture style. Sitio web:
https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/big-data
20
2.5 Ecosistema Hadoop
José Ruiz. (2016). Plataforma creada para el tratamiento distribuido de datos
con gran volumen distribuido de forma paralela con la ayuda de los
componentes MapReduce y YARN. Se diseñó para descubrir y gestionar fallos
en la capa de utilización. (4)
Hadoop cuenta con dos partes centrales, su servidor de archivos (HDFS) el
algoritmo utilizado para particionar los datos (MapReduce). (4)
Figura 5. Ecosistema Big Data
Universidad Nacional de Entre Ríos (2016), Sitio Web:
http://sedici.unlp.edu.ar/bitstream/handle/10915/52766/Documento_completo.p
df?sequence=1&isAllowed=y
21
2.6 Proceso MapReduce
MapReduce. Es un programa que ejecuta un algoritmo interno que
permite particionar los datos y ejecutarlos de forma paralela en cada nodo
del clúster. La entrada al modelo dicho es un juego de llave / los pares de
valor y la salida son otro juego de llave / pares de valor. (5)
Figura 6. Proceso MapReduce
IBM (2013). ¿Qué es Big Data? Sitio Web: http://www.ibm.com/ developerworks/ssa/local/im/que-es-big-data/index.html
22
2.7 Arquetipo HDFS
El sistema de archivos distribuidos de Hadoop, fue creado para gestionar y
almacenar la información en Hadoop. Las dos ideas principales de HDFS están
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
que tratan de ser solucionados impliquen un número grande de datos. HDFS
debe garantizar un alto rendimiento de datos para Hadoop. (5)
Figura 7. Arquetipo HDFS
JAVA4 (2014) Introducción a Big Data y Hadoop. Sitio Web:
http://java4developers.com/2014/introduccion-a-big-data-y-hadoop/
23
2.8 Componentes Hadoop
Sqoop. Es uno de los componentes más utilizados de Hadoop el cual permite
realizar la ingesta de datos hacia el HDFS fue creado especialmente para
ejecutar procesos BATCH, sus principales caracterizas son importar y
exportar datos a Hadoop y otras bases de datos, lo que permite ser más factible
al momento de automatizar las partes que conforman el proceso completo.
Además de utilizar MapReduce para ejecutar una operación en paralelo, así
como la tolerancia de fallos. (6)
Flume. Es un componente nativo de Hadoop utilizados para capturar datos a
tiempo real, trabaja de forma distribuida su principal función es extraer y
mover grandes cantidades de datos de forma eficiente. En ese sentido
mantiene una estructura sencilla y digerible. (7)
Figura 8. Flujo de datos
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
sistema de ficheros HDFS en el lenguaje tradicional SQL lo cual hace mas
flexible su usabilidad. En tal sentido el usuario podrá explorar sus datos y
estructúralos, analizarlo y luego convertirse en conocimiento para aplicarlo al
negocio de forma más sencilla. (7)
Presentamos las características que presentan de Hive:
Cientos de usuarios simultáneamente puede consultar los datos
que usan una lengua común para usuarios SQL.
Tiempo de respuesta óptimos.
JDBC y puentes ODBC, utilizados para la extracción de datos.
2.8 Tipos de carga de trabajo
Las soluciones de Big Data generalmente implican uno o más de los
siguientes tipos de carga de trabajo:
Gestión de datos. La gestión de datos permite desarrollar y la ejecutar
estructuras, políticas y procedimientos para manejar los requerimientos
correspondientes al ciclo de vida de la información de forma eficiente. Esto
es un acercamiento de manejar los datos de un sistema por su ciclo de vida,
de su creación hasta el momento ellos es eliminado. La dirección de datos
Grandes es el camino del cual las cantidades grandes de datos son organizadas
y manejadas, tanto datos no estructurados como estructurada para crear
estrategias para ayudar con la manipulación de datos de crecimiento rápido,
25
donde terabytes está implicado y aún peta los octetos de información con la
variedad de tipos. (8)
Tiempo real de procesamiento. Proceso que permite automatizar el flujo de
datos para apalancar la toma de decisiones, en tal sentido se puede aprovechar
la trasferencia de los datos para tener acceso a los datos estáticos y así
responder preguntas con un análisis de forma dinámica. Los sistemas que
realizan el tratamiento de datos estructurados como no estructurados, así
como video e imágenes. (8)
Análisis de datos: Se basa en el análisis de datos aplicando estadísticas y
matemáticas con el fin de encontrar patrones, correlaciones ocultadas y
tendencias, lo que permite generar valor al negocio para mejorar la toma de
decisiones. (8)
Bases de datos NoSQL.
El concepto NoSQL, es requerido para dar una solución con los problemas
levantados encima, dando a una posibilidad de dirigir el modo de información
directiva de un modo diferente que era el caso haciendo. (8)
Para detallar sobre las bases de datos NoSQL, las características siguientes
pueden ser tenidas en cuenta:
26
Distribuido. NoSQL Los sistemas de la data base suelen ser
distribuidos en muchos equipos que trabajan en grupos para otorgar
clientes a la base. Los datos se distribuyen en máquinas diversas de gran
variedad. (8)
Adaptabilidad Horizontal. Los suelen ser añadidos de manera
dinámicas sin inactividad en los efectos lineales en el registro y por eso
logran las capacidades. (8)
Construido para volúmenes grandes. Los NoSQL pueden almacenar
alto volumen de datos de manera óptima. (8)
Modelos de datos No emparentados. Los modelos, aunque no son
atados varían. Permite trabajar con moldes complejos y no tan robustos
como un modelo relacional. (8)
27
2.9 Diferencias entre la Metodología Cascada y Metodología Ágil
Tabla 2. Principales diferencias entre las Metodologías Ágiles y Cascada
Metodología Ágil (2015), Sitio Web:
//openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC06
12memoria.pdf
28
MARCO CONCEPTUAL
Las definiciones mencionadas son importantes para entender el
contenido de las partes tratadas en el desarrollo del informe.
2.8 Data base
Es un banco de datos es un grupo de datos que persisten en un mismo contexto y
acumulados de manera sistemática para usarlo luego.
2.9 Bases de datos NoSQL
La base de datos NoSQL simboliza una evolución en la estructura de empleo de
negocio, son diseñados para proporcionar registros de datos confiables, escalables
y disponibles por un grupo de sistemas configurables que funcionan como nodos
de registro.
2.10 Big Data
Una Big Data es el progreso de la tecnológica que ha mejorado el nuevo enfoque
de la comprensión de datos en sistemas y genera nuevas decisiones en las
entidades que suelen manejar enormes cantidades de información estructuradas,
como no estructuradas y semiestructuradas) que de otro modo se tornaría difícil
por la gran cantidad de tiempo y costo para genera un análisis.
29
2.11 Big Transaction Data
Son datos que se utilizan en los registros de facturación, en el detalle de las
llamadas (CDR) de telecomunicaciones, etc. Esta información transaccional
está disponible en formatos tantos semiestructurados como no también en los
estructurados.
2.12 Clúster
Según Strauch, el enfoque para la particionar de la información que limita la
relación hacia los clientes que deben de gestionar un conjunto de servidores de
bases de datos a diferencia de un único servidor.
2.13 Hadoop
Es una forma para poder desarrollar códigos abiertos y puede desarrollar el
procesamiento de un grupo enorme de información de manera tal que luego
de ser distribuida se puede procesar en diferentes grupos de información en
una pc con la utilización de la programación
30
2.14 Hbase
Es un sistema para almacenar datos de forma no es relacional no necesita un
Clúster independiente ya puede conectarse en el mismo Clúster de Hadoop.
Es una base de datos open source, que garantiza el procesamiento de forma
distribuida y altamente escalable para almacenar información a tiempo real.
2.15 HDFS
Es un sistema para los registros. Fue hecho de acuerdo al sistema de archivos
de Google (GFS). HDFS optimiza grandes cantidades de información que van
y vienen en ficheros con lectura y escritura de lenguaje de programación. Sus
diseños reducen la E / S en el sistema. La escalabilidad y la disponibilidad son
cosas importantes, gracias una la replicación de la data y la tolerancia en sus
fallos.
2.16 Lenguaje SQL
Es el lenguaje para la data base relacionada. "Se relaciona con una consulta
declarativa, SQL está formalizada por el Instituto el-Americano de Estándares
Nacionales (ANSI) y Organización Internacional de Normalización (ISO)
desde 1986 y ha sufrido muchas variaciones. Se relacionada con la base de
data abierta, como existen diferentes motores de bases de datos que han
adaptado dicho lenguaje de forma estándar.
31
2.17 MapReduce
Se le dice el corazón de hadoop, esto es el paradigma de programa que permite a
la adaptabilidad por unos cientos de millas y servidores en un racimo hadoop. El
término MapReduce actualmente se refiere a dos tareas diferentes a los programas
en hadoop controlado, el primer es el trabajo de mapa, que es un grupo de datos y
las respuestas en el otro; donde los elementos individuales son estropeados en
tuples, la segunda tarea se refiere a reducir el trabajo, la toma de los datos de salida
del trabajo de mapa como introducido y la combinación del tuples atrás a un
pequeño grupo de tuples.
2.18 MapReduce
Esto es un modelo para una comunicación de protocolo en la cual un dispositivo o
el proceso (sabido como el amo) controlan uno o varios otros dispositivos o
procesos (sabido como esclavos). Una vez el amo / la relación de esclavo es
establecida, la dirección de control es siempre del maestro al esclavo.
2.18 Modelo de datos entidad/relación
Forma parte de la simbología dentro una base de datos, permite encontrar relaciones
entre las diferentes entidades de un modelo de datos. El modelo relacional entidad
" E-R " es necesario para corresponder a la arquitectura de datos de un sistema bajo
un esquema conceptual.
32
MARCO METODOLOGICO
Para el desarrollo de software se utilizó la metodología siguiente metodología:
2.19 SCRUM
Definición
Es uno de los modos flexibles más comunes un entorno adaptable, iterativo y
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,
el empresario produce una lista priorizada de exigencias de negocio en forma de una
Historia de Usuario. En el inicio de cada sprint se realiza la planificación de sprint que se
encuentra en el cual historias de usuario prioritarias son consideradas para la inclusión en
el sprint. Un sprint por lo general dura entre una y seis semanas.
Figura 10. Visión general de flujo de Scrum.
Scrum Framework (2017) El Cuerpo de Conocimiento de Scrum (GuíaSBOK™)
,3raEdición.
33
Composición de SCRUM
Las tres áreas en las que se divide son:
Figura 11. Composición de SCRUM
Scrum Framework (2017) El Cuerpo de Conocimiento de Scrum (GuíaSBOK™)
,3raEdición.
34
1. LOS PRINCIPIOS DE SCRUM.
Ellos son aplicados en algún proyecto u organización y tiene que ser
respetados para garantizar el empleo apropiado de Scrum. Los procesos de Scrum
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
aplicados como descrito en el marco.
El cuidado de los principios intactos y utilización de manera apropiada
permite obtener la confiabilidad del usuario en un marco de Scrum en cuanto a
alcanzar los objetivos del proyecto, el detalle a continuación:
A. Control de proceso
Esto enfoca en la filosofía de Scrum basada en las tres ideas principales
sobre la transparencia, inspeccionar y el adaptar.
B. Auto-organización
Está enfocado en trabajadores, que generan valor cuando ellos se
organizan, que causan compromiso y responsabilidad.
C. Colaboración
Se basa en reducir las actividades más importantes del trabajo en grupo
como son: el conocimiento, articulación y apropiación.
D. Priorización basada en valor
Se basa en el valor de la organización, a partir del inicio del proyecto hasta
su finalización.
35
E. Asignación de un bloque de tiempo
Esto enfoca en la descripción del tiempo en el cual es considerado una
restricción restrictiva en la Scrum, cuales elementos del bloque de tiempo de
Scrum incluyen el sprint, reuniones diariamente permanentes, sprint que planifica
reuniones, y reuniones de revisión de sprint.
F. Desarrollo Iterativo
Esto enfoca en el mejoramiento y la creación de los productos que
encuentran necesidades de cliente. Y esto también perfila el responsable del
propietario del resultado y la compañía relacionada con la construcción iterativo.
2. LOS ASPECTOS DE SCRUM.
Esto enfoca en las exigencias de la organización que puede ser modificada.
El aspecto de organización también dirige proyectos y carteras. El detalle a
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.
El Scrum Master: Facilita el aseguramiento del equipo de Scrum y es
dotado con un entorno de permiso para completar el proyecto satisfactoriamente.
Estas guías de papel, facilitan y enseñan buenas prácticas de Scrum a todo aquellos
complicados en el proyecto.
36
El equipo Scrum: Grupo de gente responsable del entendimiento de las
exigencias especificadas por el dueño del resultado y la creación del proyecto.
B.-Justificación
Es de vital importancia para la firma el hacer una evaluación pertinente del
negocio antes de iniciar el proyecto. Va a ayudar a las personas participantes que
son claves a ser más responsables de la toma de decisiones de acuerdo a la
necesidad de cambio en la organización sobre un ofrecimiento de nuevo producto
o un nuevo servicio, también comprende la justificación del proyecto con su
respectiva viabilidad.
C.- Calidad
Es definido como la capacidad del resultado o para identificar los criterios
de aceptación y generar valor al negocio que el cliente espera.
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
reducen al mínimo para no generar un impacto negativo.
37
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.
3. LOS PROCESOS DE SCRUM
Asignan tareas detalladas y a lo largo de la vida de un proyecto. En su
totalidad hay 19 procesos importantes de Scrum fundamentales que se ejecutan
en todos los proyectos. Y se agrupan en 5 fases.
Figura 12. Estructura de la organización Scrum
Nota: Scrum Framework (2017) El Cuerpo de Conocimiento de Scrum
(GuíaSBOK™) ,3raEdición.
38
Tabla 3. Procesos fundamentales de Scrum
Nota: Scrum Framework (2017) El Cuerpo de Conocimiento de Scrum (GuíaSBOK™)
,3raEdición.
39
Tabla 4. Comparación de Scrum con la Gestión tradicional
Nota: Scrum Framework (2017) El Cuerpo de Conocimiento de Scrum (GuíaSBOK™)
,3raEdición.
40
MARCO LEGAL
2.20 Leyes Aplicadas al Proyecto
Tabla 5. Leyes Aplicadas al Proyecto según la constitución del Perú
41
3.1 DESARROLLO DE LA APLICACIÓN
3.1.1 Requisitos Funcionales
Migración Oracle a Hadoop
En esta primera fase se realizará la ingesta de datos del DataMart de Marketing
que tiene como origen el motor de Oracle hacia la plataforma Hadoop, antes de
realizar la migración es necesario seguir los siguientes pasos:
Configuración en Base de datos Oracle:
El sistema requiere la creación de un usuario con permisos de lectura y
escritura a la base de datos Oracle que contiene la tabla de configuración
del framework de carga de Oracle a Hadoop.
Es necesario que el usuario tenga asignados permisos de lectura y
escritura sobre el tablero de configuración de Oracle para matricular las tablas
que desee migrar hacia Teradata.
El sistema requiere que el usuario registre la tabla a migrar en el tablero
de configuración.
Es necesario que el usuario registre la tabla y la fecha de carga en el
tablero de configuración de Oracle.
42
Configuración área Edge:
El sistema requiere la creación de la carpeta principal
“BD_MigracionOracle” y las subcarpetas:
LOG: Tendrá información sobre la ingesta tanto para el Sqoop y la Insert,
permitirá identificar algún error que pueda ocurrir en la carga.
SHELL: Se guardará las Shell de carga stage e insert.
PROPERTIES: Almacenara las cadenas de conexión a Oracle.
El sistema requiere la creación de un nuevo usuario que tenga asignado
permisos de escritura y lectura en la carpeta LOG.
Ruta: /data/prod/IBKProjects/BD_MigracionOracle/Log
El sistema requiere la creación de una Shell en Linux que permita la
carga al área Stage de Hadoop.
Es necesario crear una Shell donde invocaremos a Sqoop de Hadoop
con el fin de extraer y cargar los datos en el área Stage en Hadoop.
El sistema requiere la creación de una Shell en Linux que permita la
carga histórica en Hadoop.
Para cargar la información de forma histórica es necesario crear la
estructura de tabla en Hadoop y una Shell donde internamente llamaremos al
componente Hive en Hadoop con el fin de cargar la información a un esquema
según el origen de la tabla.
43
El sistema requiere que se deposite los 2 scripts generados en UNX.
Para realizar la migración de forma automática es necesario depositar
los scripts antes de activar el proceso de migración.
Ruta: /data/prod/IBKProjects/BD_MigracionOracle/Shell
Configuración área Nifi:
Utilizaremos Nifi para poder orquestar todo el flujo de datos a migrar, para ello es
necesario realizar los siguientes pasos:
El sistema requiere la creación de la carpeta principal “DataHubNifi” y
las subcarpetas:
Jar
Utils
Orquestador
Jar: Se encontrará la aplicación que permitirá orquestar todo el proceso
de migración a Hadoop.
Utils: Se encontrará el TDCH que permitirá la carga a Teradata.
El sistema requiere que se copie el archivo “LoadToHadoop.jar”:
La aplicación fue java y scala la cual permitirá orquestar todo el flujo de carga
de datos entre los diferentes motores.
Ruta: /data/prod/IBKProjects/DataHubNifi/Jar
El sistema requiere que se copie el MigraciónOra.nf
El archivo tample.nf permitirá realizar la orquestación de todos los
subprocesos para la migración de datos.
Ruta: /data/prod/IBKProjects/DataHubNifi/Orquestador
El sistema requiere que se copie los TDCH en la carpeta utils.
44
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.
Migración de Hadoop a Teradata
En la segunda fase se realizará la migración de datos de Hadoop hacia Teradata,
para ello es necesario realizar los siguientes pasos:
El sistema requiere que se cree la carpeta “BDLoadHadoop”
Dentro del archivo se creará una carpeta LOG, la cual almacenará los eventos de carga
hacia Teradata.
Ruta: /data/prod/IBKProjects/ BDLoadHadoop/Log
El sistema requiere que el usuario tenga permisos de lectura y escritura a la
base de datos Teradata que contiene la tabla de configuración del framework.
Para realizar la migración de datos necesariamente se debe de contar con
un usuario y password registrados en la base de datos de los trabajadores.
El sistema requiere que el usuario registre la tabla a migrar en el tablero de
configuración.
Es necesario que el usuario registre la tabla y la fecha de carga en el tablero de
configuración de Teradata.
45
3.1.2 Requisitos No Funcionales
Servidores
Los servidores deben ser localizados en un centro de datos con las
condiciones de calidad requeridas.
Configuración del Clúster en Hadoop
Name Node:
1 Servidores HP ProLiant DL360 Gen9.
Dos Procesadores Intel Xeon E5-2650v4 2.2GHz con 12 núcleos c/u.
Memoria 252 GB.
Fuentes de alimentación redundante 800 W.
Disco Duro: 100 TB.
Data Node:
3 Servidores HP ProLiant DL360 Gen9.
Dos Procesadores Intel Xeon E5-2650v4 2.2GHz con 12 núcleos c/u.
Memoria 252 GB.
Fuentes de alimentación redundante 800 W.
Disco Duro: 120 TB.
Desarrollo y QA (Edge):
Servidor HP ProLiant DL360 Gen9.
Dos Procesadores Intel Xeon E5-2650v4 2.2GHz con 12 núcleos c/u.
Memoria 252.
Fuentes de alimentación redundante 800 W.
[Disco Duro: 180 TB].
46
3.1.3 Modelo Dimensional
Figura 16. Modelo Dimensional Datamart Marketing
47
3.1.4 Arquitectura del Sistema de Migración
Figura 17. Diagrama del sistema de migración
Nota: Elaborado por el autor del informe.
A continuación, se detalla el flujo de la estructura Big data para la ejecución de
la utilización que permitirá la Migración:
a) El usuario deberá activar en el tablero de control la tabla a migrar.
b) Nifi se encarga escuchara la actividad de la tabla registrada en el tablero de control de
Oracle que se encuentra en Activo para que posteriormente llame a la Shell de carga
hacia Hadoop y en paralelo registrar el log a nivel de tabla y archivo plano.
c) Se inicia la ingesta de datos ejecutando la Shell de STG e INSERT.
d) Se inactiva la tabla a migrar en el tablero Oracle.
e) Se inicia BTQ en Teradata que permitirá “Activar” la tabla registrada en el tablero en
Teradata.
i) Nifi se encarga de escuchar la actividad de la tabla registrada en el tablero de control
de Teradata que se encuentra en Activo para que posteriormente llame a la Shell de
carga hacia Teradata y en paralelo registrar el log a nivel de tabla y archivo plano.
j) Se inactiva la tabla a migrada a Teradata en el tablero de control de Teradata.
48
3.1.5 Arquitectura Conceptual del Sistema de Migración
Figura 18. Estructura Conceptual del Sistema de Migración
La estructura tecnológica que se utilizará en el proyecto será aplicada en base a las
capas de desarrollo de un data lake:
Fuentes: los datos que utilizaremos serán estructurados obtenidos de la data base
ORACLE.
Ingesta: se utilizarán solo los componentes de la plataforma Hadoop, Sqoop
y Hive.
Registros: Los datos será almacenados de forma BATCH en HDFS Hadoop.
Procesamiento: Para el procesamiento se utilizará el gestor de recursos YARN
y MapReduce.
Explotación: Se utilizará la herramienta analítica Teradata Áster.
Gobierno y Seguridad: Podremos administrar el Clúster con YARN y NIFI para
orquestar los procesos, además para la administración de accesos se utilizará CCI.
49
3.1.6 Arquitectura Tecnología del Sistema de Migración
Figura 19. Estructura Tecnología del Sistema de Migración
3.1.7 Capas del Data Lake
Edge Universal Smart
Figura 20. Capas del Data Lake
50
3.1.8 Diccionario de datos
A) DATA BASE: ORACLE
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_CARGA TIPO DE FRECUENCIA DE CARGA : "DIARIA", "MENSUAL",
"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
B) DATA BASE: TERADATA
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"
FREQUENCY TIPO DE FRECUENCIA DE CARGA : "DIARIA", "MENSUAL",
"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
Se implementará un sistema de big data para la migración de datos con lo
cual se buscará reducir tiempos en ejecución de procesos por lo que nos
anticiparemos a la toma de decisiones con respecto a la competencia.
3.2.2 Organización
53
54
3.2.3 Historias de usuario
Historias de usuario correspondiente al SPRINT 1, campaña: Tarjetas de Crédito.
N° Historias de Usuario Actividades Horas Prioridad
1
Como usuario necesito que se genere la
campaña de “Tarjeta de Crédito” con
los productos:
a) Convenios
b) Tasa
Que distribuirán en los siguientes canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se identificará tablas de Oracle a Migrar.
8
2
Se desarrollará tablero de control que
permita registrar las tablas a migrar de
Oracle hacia Teradata.
9
Se desarrollará tablero de registro de logs
para el monitoreo y soporte a la aplicación.
6
Se desarrollará orquestado de los procesos
de carga de datos en NIFI hacia Hadoop.
8
Se desarrollará el modulo que permita
registrar a detalle un archivo log de carga a
Hadoop.
4
Como usuario necesito que se genere la
campaña de “Tarjeta de Crédito” con
los productos:
a) Exoneración de membresía
b) Incremento de Linea
Que distribuirán en los siguientes canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se desarrollará módulo de registro de log de
carga a Teradata.
9
Se desarrollará Scripts para la extracción y
carga de datos a Hadoop de la estructura de
datos y la inserción de los mismos. (Sqoop
Import)
8
2
Se desarrollará Scripts de la estructura de
datos y la inserción de los mismos que
permitan la carga histórica de datos en
Hadoop. (Hive)
8
1
Se realizará la construcción de cada ruta
lógica en el HDFS que soporte la carga de
datos.
8
3
Como usuario necesito que se genere la
campaña de “Tarjeta de Crédito” con
los productos:
a) Pre-Retención
b) Retención
Que distribuirán en los siguientes canales:
Se realizará la construcción de cada una de
las tablas a migrar en el HDFS que soporte
la carga de datos.
7
3
Se desarrollará orquestador que permita la
carga de tablas de Hadoop hacia Teradata.
7
Se construirá árbol de carpetas en área
EDGE.
7
Se orquestará los procesos de carga de datos
en NIFI hacia Teradata cada vez que este
9
55
3
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
activo en el tablero de control.
Se creará tablero de control que permita
registrar las tablas a migrar de Hadoop hacia
Teradata.
7
4
Como usuario necesito que se genere la
campaña de “Tarjeta de Crédito” con
los productos:
a) Regular de Tarjeta Crédito
b) Segunda tarjeta
c) Préstamos
Que distribuirán en los siguientes canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se desarrollará Scripts que permitan la
extracción y carga de datos a Teradata.
(Sqoop Export)
9
4
Se desarrollará Scripts en Teradata de la
estructura de tablas a migrar que soporten la
carga de datos desde Hadoop.
8
Se desarrollará modulo que permita
registrar todo el log de carga que escribe de
Hadoop hacia Teradata en cada ejecución.
5
Se construirá Shell que permita asignar
permisos a los diferentes usuarios que
utilicen la utilización.
4
Se ejecutara casos de prueba para
garantizar la integridad de los datos.
2
56
Historias de usuario correspondiente al SPRINT 2, campaña: Propensión de Fuga de clientes.
N° Historias de Usuario Actividades Horas Prioridad
1
Como usuario necesito que se genere
la campaña de “Propensión de
Fuga de clientes” con los productos:
a) Sbs
b) Sunat
Que distribuirán en los siguientes
canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se identificará tablas de Oracle a Migrar.
10
1
Se desarrollará tablero de control que permita
registrar las tablas a migrar de Oracle hacia
Teradata.
9
Se desarrollará tablero de registro de logs para el
monitoreo y soporte a la aplicación.
5
Se desarrollará orquestado de los procesos de
carga de datos en NIFI hacia Hadoop.
9
Se desarrollará el modulo que permita registrar a
detalle un archivo log de carga a Hadoop.
6
2
Como usuario necesito que se genere
la campaña de “Propensión de
Fuga de clientes” con los productos:
a) Calificación de Cliente
b) Incremento de Linea
Que distribuirán en los siguientes
canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se desarrollará módulo de registro de log de carga
a Teradata.
7
3
Se desarrollará Scripts para la extracción y carga de
datos a Hadoop de la estructura de datos y la
inserción de los mismos. (Sqoop Import)
8
Se desarrollará Scripts de la estructura de datos y la
inserción de los mismos que permitan la carga
histórica de datos en Hadoop. (Hive)
7
Se realizará la construcción de cada ruta lógica en
el HDFS que soporte la carga de datos.
7
3
Como usuario necesito que se genere
la campaña de “Propensión de
Fuga de clientes” con los productos:
a) Pre-Retención
b) Retención
Se realizará la construcción de cada una de las
tablas a migrar en el HDFS que soporte la carga de
datos.
7
2
Se desarrollará orquestador que permita la carga de
tablas de Hadoop hacia Teradata.
7
Se construirá árbol de carpetas en área EDGE. 7
Se orquestará los procesos de carga de datos en
NIFI hacia Teradata cada vez que este activo en el
tablero de control.
9
57
Que distribuirán en los siguientes
canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se creará tablero de control que permita registrar
las tablas a migrar de Hadoop hacia Teradata.
7
4
Como usuario necesito que se genere
la campaña de Propensión de Fuga
de clientes” con los productos:
a) Regular de Tarjeta Crédito
b) Préstamos
Que distribuirán en los siguientes
canales:
Televenta (TLV).
Asesor de Banca Personal
(ABP).
Gerente de Tienda (GT).
Red de Tienda (Bolsa)
Facebook.
HTML.
SMS.
Se desarrollará Scripts que permitan la extracción
y carga de datos a Teradata. (Sqoop Export)
9
4
Se desarrollará Scripts en Teradata de la estructura
de tablas a migrar que soporten la carga de datos
desde Hadoop.
8
Se desarrollará modulo que permita registrar todo
el log de carga que escribe de Hadoop hacia
Teradata en cada ejecución.
8
Se construirá Shell que permita asignar permisos a
los diferentes usuarios que utilicen la utilización.
4
Se ejecutara casos de prueba para garantizar la
integridad de los datos.
5
58
3.2.1 Review Meeting
Revisión del SPRINT 1, el detalle a continuación:
Nro
Hist
Actividades
Resultados
Positivos
Resultados
Negativos
1
Se identificará tablas de Oracle a Migrar.
Se desarrollará tablero de control que permita registrar las tablas a migrar de Oracle hacia Teradata.
Se desarrollará tablero de registro de logs para el monitoreo y soporte a la aplicación.
Se desarrollará orquestado de los procesos de carga de
datos en NIFI hacia Hadoop.
Se desarrollará el modulo que permita registrar a
detalle un archivo log de carga a Hadoop.
El equipo de QA
logro identificar
que en el mapeo
de tablas a
migrar, faltaba 1
de las tablas que
forman parte del
modelo de datos.
Ninguna.
2
Se desarrollará módulo de registro de log de carga a
Teradata.
Se desarrollará Scripts para la extracción y carga de
datos a Hadoop de la estructura de datos y la inserción
de los mismos. (Sqoop Import)
Se desarrollará Scripts de la estructura de datos y la
inserción de los mismos que permitan la carga
histórica de datos en Hadoop. (Hive)
Se realizará la construcción de cada ruta lógica en el
HDFS que soporte la carga de datos.
El equipo de QA
logro identificar
que en una de las
tablas a migrar el
volumen de datos
en ORACLE no
era el mismo que
en TERADATA.
Problemas por
parte del área de
TI del banco con
respecto a la
inestabilidad del
ambiente de
DESARROLLO.
3
Se realizará la construcción de cada una de las tablas
a migrar en el HDFS que soporte la carga de datos.
Se desarrollará orquestador que permita la carga de
tablas de Hadoop hacia Teradata.
Se construirá árbol de carpetas en área EDGE.
Se orquestará los procesos de carga de datos en NIFI
hacia Teradata cada vez que este activo en el tablero
de control.
Se creará tablero de control que permita registrar las tablas a migrar de Hadoop hacia Teradata.
Se logró realizar
la migración a
Hadoop de los
datos ya se
cuenta con
información
histórica para
poder
disponibilizarla
en TERADATA.
Ninguna.
4
Se desarrollará Scripts que permitan la extracción y
carga de datos a Teradata. (Sqoop Export)
Se desarrollará Scripts en Teradata de la estructura de
tablas a migrar que soporten la carga de datos desde
Hadoop.
Se desarrollará modulo que permita registrar todo el log de carga que escribe de Hadoop hacia Teradata en
cada ejecución.
Se construirá Shell que permita asignar permisos a los
diferentes usuarios que utilicen la utilización.
Se ejecutara casos de prueba para garantizar la
integridad de los datos.
Se logró
disponibilizar la
información en
TERADATA de
forma
satisfactoria, se
cumplió con
garantizar la
integrar y
confianza en los
datos migrados.
La base de datos
TERADATA no
tenía instalado el
driver para
conectarse con
Hadoop, se tuvo
que realizar la
instalación para
poder exportar
los datos hacia
TERADATA.
59
Revisión del SPRINT 2, el detalle a continuación:
Nro
Hist
Actividades
Resultados
Positivas
Resultados
Negativas
1
Se identificará tablas de Oracle a Migrar.
Se desarrollará tablero de control que permita
registrar las tablas a migrar de Oracle hacia Teradata.
Se desarrollará tablero de registro de logs para el monitoreo y soporte a la aplicación.
Se desarrollará orquestado de los procesos de carga
de datos en NIFI hacia Hadoop.
Se desarrollará el modulo que permita registrar a
detalle un archivo log de carga a Hadoop.
El equipo de QA
logro identificar
que en una de las
tablas a migrar no
estaba viajando 4
conceptos
correspondientes
al catálogo de
producto.
Ninguna.
2
Se desarrollará módulo de registro de log de carga
a Teradata.
Se desarrollará Scripts para la extracción y carga de datos a Hadoop de la estructura de datos y la
inserción de los mismos. (Sqoop Import)
Se desarrollará Scripts de la estructura de datos y la inserción de los mismos que permitan la carga
histórica de datos en Hadoop. (Hive)
Se realizará la construcción de cada ruta lógica en
el HDFS que soporte la carga de datos.
El equipo de
desarrollo logro
identificar que la
propiedad de
compresión
PARQUET en
Hadoop redujo el
almacenamiento
en un 80%.
Ninguna.
3
Se realizará la construcción de cada una de las
tablas a migrar en el HDFS que soporte la carga de
datos.
Se desarrollará orquestador que permita la carga de
tablas de Hadoop hacia Teradata.
Se construirá árbol de carpetas en área EDGE.
Se orquestará los procesos de carga de datos en NIFI hacia Teradata cada vez que este activo en el tablero de control.
Se creará tablero de control que permita registrar las tablas a migrar de Hadoop hacia Teradata.
El equipo de
desarrollo logro
optimizar el
procesamiento de
datos en HIVE a
nivel de CPUs y la
memoria RAM
utilizando de
forma eficiente los
recursos computacionales.
Ninguna.
4
Se desarrollará Scripts que permitan la extracción y
carga de datos a Teradata. (Sqoop Export)
Se desarrollará Scripts en Teradata de la estructura
de tablas a migrar que soporten la carga de datos
desde Hadoop.
Se desarrollará modulo que permita registrar todo
el log de carga que escribe de Hadoop hacia Teradata en cada ejecución.
Se construirá Shell que permita asignar permisos a los diferentes usuarios que utilicen la utilización.
Se ejecutara casos de prueba para garantizar la
integridad de los datos.
El equipo de QA
logro identificar
que al cargar la
información a
TERADATA
ciertas columnas
estaban viajando
con caracteres
extraños.
Ninguna.
60
3.2.1 Retrospective Meeting
Nro
Sprint
Puntos de Mejora
1
El equipo de Desarrollo, tendrá que mejorar el proceso de identificación de tablas
que forman parte del modelo de datos.
El Product Owner, deberá definir correctamente las historias de Usuario y sobre
todo antes de iniciar con la construcción.
El equipo de Desarrollo, tendrá que mejorar la comunicación con los demás
miembros del equipo SCRUM.
El equipo de Desarrollo, tendrá que aplicar buenas prácticas para mejorar los
procesos existentes de forma eficientes a nivel de procesamiento de datos.
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.
El QA o tester debe estar presente en las especificaciones o reuniones que realice
el PO con el Team developers a fin de facilitar las pruebas.
Se deben identificar y mapear los temas que generen algún bloqueo o
impedimentos.
Definir un horario fijo para los Dailys a fin que no se vean impactadas otras
actividades.
2
Se realizará la mejora a nivel de administración de Clúster, utilizando un patrón
de colas en ejecución de procesos en Hadoop lo cual permitirá la ejecución de
procesos de forma paralela.
Se realizará la mejora a nivel de Script con Sqoop, ya que se identificó que en la
ingesta de datos se estaba tomando como SPLIT a campos que no son Numéricos
y que se repiten en más de una vez.
El equipo de Desarrollo, tendrá que mejorar en la construcción scripts para el
procesamiento de datos en HIVE, en un primer momento se utilizaba formato
ORC para las tablas y ahora se utilizara PARQUET debido a que permite que el
proceso sea más eficiente a nivel de procesamiento y compresión en un 80%.
Es necesario contar con un administrador del Cluster, ya que en la ingesta de datos
se quedaron varios procesos pegados y se necesitó poder matar los procesos para
seguir con el poblamiento de datos al DATALAKE.
Contar con la disponibilidad de los servidores cuando se realicen ejecuciones que
demandan tiempos prolongados de procesamiento
61
3.2.2 Tiempos
En promedio va a tomar unas 8 horas al día.
Utilización
3.3.1 Tablero de control Oracle a Hadoop
3.3.2 Tablero de registro de Log de carga de Oracle a Hadoop
62
3.3.3 Orquestador de Procesos NIFI
Carga Oracle a Hadoop y Hadoop Teradata
--master yarn --conf "spark.local.dir=/data/prod/log" --conf
"spark.executor.extraJavaOptions=-Djava.io.tmpdir=/data/prod/log" --conf
"spark.driver.extraJavaOptions=-Djava.io.tmpdir=/data/prod/log" --class
bigdata.hilos.LoadHadoop
/data/prod/IBKProjects/BDLoadHadoop/jar/LoadToHadoop.jar
63
3.3.4 Servidor de Archivos ( Edge )
64
3.3.5 Tablero de control Hadoop a Teradata
3.3.6 Tablero de registro de Log de carga de Hadoop a Teradata
65
Sostenimiento
3.4.1 Sostenimiento de data base
Con actualizaciones periódicas mensuales será manejado para verificar la
estadística de los objetos contenidos en la base de datos, de este modo el
empleo óptimo de los datos bajos será controlado.
Son proyectos Semanales de reserva será hecho.
3.4.2 Sostenimiento de servidores
Se tiene que hacer el escaneo de los discos duros.
Se tendrán que realizar los planes para actualizar los sistemas
operativos.
Se va a verificar a la semana todas las configuraciones
3.4.3 Sostenimiento de servidor de aplicaciones
Todas las semanas se tendrá que limpiar los log..
66
CAPITULO 4
RESULTADOS
4.1. Resultados
Evidencias Obtenidas del Histórico de JOBS en Data Stage - V9
Evidencias Obtenidas del Histórico de Logs de Carga Hadoop
Análisis comparativo de tiempos de herramientas de migración de datos
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
4.2.2.1 Presupuesto (Flujo Caja)
Tabla 2: Matriz de costos de Hardware
Tabla 3: Matriz de costos de Software
68
4.2.2.2 Costo de Recursos del Proyecto
Tabla 4: Matriz de costos por Recursos
Tabla 5: Presupuesto del proyecto
4.2.2.3 Beneficiarios del proyecto
Tabla 7: Matriz de beneficiarios de proyecto
69
4.2.2.4 Descripción Análisis de Retorno
En la actualidad el área de Sistemas es la encarga de hacer el proceso
de migración de datos del DataMart de Marketing en ORACLE hacia
TERADATA, el tiempo promedio de trabajo invertido es de 5 días en donde
se realizan actividades de coordinación, validación y carga de datos,
distribuida entre los recursos indicados en la matriz de análisis de retorno,
la inversión total de nuestro proyecto es 69,330.07 y el coste total de los
beneficiarios tiene 24,558.33, según el análisis de la curva de S esto
recuperará la inversión en el proyecto en el tercer mes. Finalmente, según el
análisis de vuelta de la inversión del proyecto, su viabilidad es determinada,
ya que el cálculo del NPV que esto presenta es la S/. 3,133.85. Esta cifra
sustenta la viabilidad del proyecto, por lo que se recomienda su ejecución.
Tabla 8: Matriz de análisis de retorno
70
4.2.2.5 Diagrama de Gantt
Figura 4: Diagrama de Gantt
4.2.2.5 Curvas (Costo Vs Tiempo)
Tabla 6: Curva S
71
CONCLUSIONES
1. Al realizar la ingesta de datos con Apache Sqoop a Hadoop, se pudo centralizar todos
los datos provenientes de la fuente de datos ORACLE depositados en nuestro DATA
LAKE, lo que permitirá no solo trabajar con información estructurada si no también
semiestructurados y no estructurada con el fin de potenciar la toma de decisiones en la
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
el servidor de archivos de Hadoop.
3. En base a las evidencias obtenidas por el histórico de LOGS, hubo una mejora
significativa en el proceso de migración de datos con un ahorro en 6 horas en el flujo
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
Work Breakdown Structure (WBS)
Gestión de la Calidad
74
Identificación de Riesgos
1.3.5 Organigrama de la Empresa
75
1.3.5 Organigrama del Proyecto