parte_31.txt

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 9 de datos recopila y almacena datos de diferentes fu entes; desde las propias bases de datos transaccionales de la organización, hasta informaci ón de las redes sociales o recopiladas por dispositivos inteligentes. Pero además,...

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 9 de datos recopila y almacena datos de diferentes fu entes; desde las propias bases de datos transaccionales de la organización, hasta informaci ón de las redes sociales o recopiladas por dispositivos inteligentes. Pero además, este almace namiento se realiza con una orientación clara hacia el análisis y explotación de los datos que co ntiene, con lo que su utilidad proyecta la necesidad de definir su arquitectura. 2.1. Modelo multidimensional El modelo multidimensional es el más comúnmente uti lizado para diseñar almacenes de datos. En este modelo, el concepto central es el hecho . Un hecho pues es un dato o concepto lógico de interés para la organización. Ejemplos de hechos se rían las ventas, el personal de la organización, o la reputación de una entidad o persona en redes s ociales. Un hecho se caracteriza por sus atributos , que definen cantidades mensurables sobre aspectos del hecho. Tomando en cuenta el ejemplo de una venta, algunos de sus atributos serí an el importe, la cantidad de productos vendidos, los clientes que compraron, los comercial es involucrados o los territorios afectados. Los atributos aportan medidas cuantitativas al hecho qu e definen. Cada uno de estos atributos se puede detallar o agregar en función de las dimensiones que se le definan. Por ejemplo, dimensiones asociadas a la venta serían el tiempo e n que se efectúa la misma (a diferentes niveles de agregación como pueda ser el día, la semana, el mes, el trimestre o el año), el lugar de la venta (de nuevo a diferente nivel de agregación como ciud ad, región o país), el comercial que la hizo (agregando por ejemplo por territorios), o los artí culos vendidos (agregando por categoría), etcétera. En la siguiente imagen vemos un ejemplo d e modelo multidimensional del hecho venta. En la Figura 2 vemos el hecho venta, con los atribu tos importe y cantidad. Estos atributos cuantitativos, se pueden agregar y desagregar por l as dimensiones tiempo, lugar, producto y/o comercial, de modo que se pueda responder a pregunt as como ¿cuánto ha vendido cada comercial en cada territorio, distribuido por importe y/o por cantidad?, ¿qué productos son los más vendidos, distribuidos por territorio y/o por trimestre?, ¿cu áles son los productos preferidos por los clientes de cada territorio, donde el PIB se encuentre en un de terminado rango?, ¿cuáles son los territorios donde más vende cada comercial, teniendo en cuenta únicamente los territorios no rurales?, o cualquier combinación de atributos y dimensiones. L a representación gráfica de un modelo multidimensional de tres dimensiones se asemeja a u n cubo, por lo que a los modelos multidimensionales se les suele denominar hipercubos de información. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 10 TEMARIO OPOSICIONES COIICV | TEMA 36 Figura 2: Modelo multidimensional de la venta. Fuen te: Elaboración propia Se puede apreciar que el modelo multidimensional de fine los hechos en forma de estrellas , con el hecho en el centro y las dimensiones en las puntas de la estrella. Existe conceptualmente dos tipos de estrella: la estrella simple , cuando las dimensiones sólo permiten un camino de agregación o el copo de nieve , cuando hay caminos alternativos para agregar y de sagregar por una dimensión (como en el caso del tiempo en el ejemplo mostrado) . 2.2. Datamart En el modelo multidimensional definimos los ámbitos de interés de la organización como estrellas, donde el hecho es el nodo central y de él parten la s diferentes dimensiones. Un almacén de datos estará pues compuesto de diferentes estrellas defin iendo cada uno de los hechos –ámbitos de la organización– que se desee modelar. Por ejemplo, v entas, personal, reputación, etcétera. Cada una de estas estrellas es lo que de manera gen eralizada en la literatura se denomina datamart . Se entiende pues que un almacén de datos almacena un conjunto de datamarts modelando hechos con sus propios atributos y dimens iones, y facilitando así las operaciones de análisis y explotación de los mismos. 2.3. Data lake El término data lake fue utilizado por primera vez por director técnico de Pentaho James Dixon para contrastarlo al término datamart común a los a lmacenes de datos. Es conocida su cita “ If you Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 11 think of a datamart as a store of bottled watter – cleansed and packaged and structured for easy consumption– the data lake is a large body of wate r in a more natural state. The contents of the data lake strem in from a source to fill the lake, and various users of the lake can come to examine, dive in, or take samples ” (Dixon, 2015). En las palabras de Dixon se apreci a la principal diferencia entre datamart, que como vimos es un conjunto de he chos estructurados en modo de estrella que definen mediante sus atributos y dimensiones la rea lidad de la organización que se desea analizar, y el data lake, como almacén no estructurado donde pueden cohabitar tanto datos estructurados como los datamarts, como información en bruto, sin procesar, para poder ser transformada y utilizada en cualquier momento, o incluso almacenar de nuevo el resultado de dicho proceso en el mismo data lake. Es decir, un data lake podrá conte ner datos estructurados como bases de datos relacionales, semiestructurados como ficheros csv, xml o json, datos desestructurados como emails, tuits o artículos de prensa, y datos binari os como fotografías, ejecutables o de cualquier otro tipo, todo ello de manera centralizada y acces ible. La Tabla I muestra las diferencias principales entre almacén de datos (o conjunto de d atamarts) y data lake: Tabla I: Datamart vs. Data lake. Fuente: Tamara Dul l (SAS) DATAMART DATA LAKE DATOS ESTRUCTURADOS, PROCESADOS ESTRUCTURADOS, SEMIESTRUCTURADOS, NO ESTRUCTURADOS, BRUTOS PROCESAMIENTO ESQUEMA A LA ESCRITURA ESQUEMA A LA LECTURA ALMACENAMIENTO ELEVADO COSTE PARA GRANDES VOLÚMENES DISEÑADO PARA BAJO COSTE AGILIDAD BAJA ALTA SEGURIDAD MADURA MADURANDO USUARIOS PROFESIONALES, NEGOCIOS CIENTÍFICOS, ANALISTAS Uno de los sistemas más conocidos y utilizados para crear data lakes es el sistema de ficheros distribuido de Apache Hadoop (HDFS, Hadoop Distribu ted File Systems), aunque en la actualidad muchas organizaciones están haciendo uso de reposit orios distribuidos como Amazon S3 para la creación de sus propios data lakes. 2.4. Mantenimiento del almacén de datos. ETL Tras el diseño e implementación del almacén de dato s llega el momento de rellenarlo con los datos provenientes de las distintas fuentes. Además, este proceso de relleno se deberá realizar en más de una ocasión, puesto que el almacén de datos tien e como principal misión proporcionar una visión histórica a los que toman las decisiones par a que puedan realizar sus análisis. Esta visión histórica dependerá del momento de la decisión, y s e deberá actualizar periódicamente para incorporar los últimos cambios ocurridos en las fue ntes de datos: por ejemplo, las últimas ventas Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 12 TEMARIO OPOSICIONES COIICV | TEMA 36 realizadas, las últimas conversaciones en la red o las últimas medidas de los sensores. El proceso de rellenar el almacén de datos se denomina ETL (de sus siglas en inglés Extraction , Transformation , Load ) y se conforma en las tres fases que le dan nombre : • Extracción : Es el proceso encargado de, a partir de las disti ntas fuentes de datos definidas, extraer los datos necesarios para su alm acenamiento en el almacén. Este proceso típicamente consistirá en consultas SQL a l a base de datos transaccional, procesos dump de datos, accesos vía API a fuentes de datos como redes sociales, portales open data o similares, procesos de wrapping y/o scrapping de páginas web, digitalización y reconocimiento óptico de caractere s ( OCR ) de documentos escritos, etcétera. Por lo general, el resultado bruto de la extracción de fuentes de datos se almacenará en un repositorio intermedio, sobre el q ue realizar la siguiente fase de limpieza y transformación, para su correcta adecuación al al macén de datos. Este repositorio intermedio puede ser una base de datos relacional o un sistema de ficheros cualquiera, lo que mejor se adapte al proceso. • Transformación : Es el proceso encargado de, a partir de los datos brutos obtenidos de las diferentes fuentes externas, limpiarlos, ordenarlos y estructurarlos para adecuarlos al modelo definido en el almacén de datos ( datamarts ). En esta fase se eliminarán datos redundantes, se realizará una estandarización de fo rmatos (e.g. fechas, divisas, etc.), se tratarán los datos nulos –por ejemplo, eliminándol os o sustituyéndolos por comodines–, se normalizarán los datos inconsistentes entre fuentes , según su veracidad y/o confianza en la fuente, y se podrán crear los metadatos, índices y claves necesarios para una mejor organización. • Carga : Es el proceso por el cual, a partir de los datos limpios y preparados del almacenamiento intermedio, se crean los diferentes datamarts y se rellenan con la información adecuada. En esta fase se debe tener en consideración el orden de carga de los datos, cuáles dependen de cuáles, asegurar la c onsistencia e integridad de los datos y, si es necesario, se crearán los índices correspondi entes a los hechos y las dimensiones que se podrán explotar. El proceso ETL se debe diseñar de manera específica para el almacén de datos y las fuentes de información definidas. Es la fase más costosa de la creación y explotación de un almacén de datos, y la más sensible, ya que de su calidad va a depend er la calidad del resultado. Aunque existen herramientas que asisten en el proceso de creación de ETL, es el equipo encargado del almacén de datos quien deberá definir y desarrollar los res pectivos módulos de extracción, transformación y carga. 3. Arquitectura OLAP El procesamiento analítico en tiempo real (OLAP, On-Line Analytical Processing ) requiere de operaciones en modo consulta para agregar y cruzar gran cantidad de información con el objetivo de generar conocimiento a partir de los datos trans accionales. Su objetivo, por lo tanto, es ayudar Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 13 a la toma de decisiones mediante la aportación de c onocimiento, generalmente a modo de informes. Ejemplos de estos informes podrían ser la s ventas por comercial y territorio, el tiempo medio en la lista de espera de las diferentes espec ialidades de un hospital o la cantidad de menciones por temática y destinatario en una red so cial. La principal diferencia con el procesamiento transa ccional en tiempo real (OLTP, On-Line Transactional Processing ), es que este último consiste en todo tipo de tran sacciones y no únicamente consultas. Es el trabajo principal de lo s sistemas de información cuando registran, actualizan o eliminan información detallada de las diferentes transacciones de la organización. Por ejemplo, cuando se introduce una factura, un pedido , un paciente o un diagnóstico. Es el trabajo diario para el que se ha diseñado el sistema de inf ormación. OLAP sin embargo se centra en operaciones de consulta que, en ocasiones, son cost osas por los cruces de información requeridos. Aplicar pues procesamiento analítico so bre bases de datos transaccionales suele provocar dos tipos de problemas: • El primero es que las bases de datos transaccionale s no están diseñadas ni estructuradas para las consultas que se desea realizar en el proc eso analítico. Esto va a incrementar la dificultad en las consultas por tener que seguir la estructura transaccional (claves únicas y foráneas, tablas de unión n a n, tablas de normaliz ación, etc), y no la estructura lógica de los datos modelados. Por ejemplo, si se desea obten er agregados de productos más vendidos, importes de venta por territorio y comerc ial, o similares, las consultas a realizar incluirían un conjunto elevado de tablas con sus re laciones. • Además, consultas complejas como las descritas van a requerir de un tiempo de proceso elevado, pues en ocasiones, se va a tener que recor rer todas las filas de una tabla para efectuar los agregados (totales por comercial y ter ritorio). Esto, que en un sistema dedicado resultaría costoso, si se realiza contra e l propio sistema transaccional puede ocasionar una merma en su rendimiento o incluso el fallo total del sistema. Tabla II: OLTP vs OLAP. Fuente: Blog Inteligencia d e Negocio OLTP OLAP OPTIMIZADAS PARA EL REGISTRO DE DATOS OPTIMIZADAS PARA LA CONSULTA DATOS AL DETALLE DATOS AGREGADOS NORMALIZACIÓN, REDUCCIÓN DE ESPACIO REDUNDANCIA, ESPACIO EXTRA PARA OPTIMIZAR LA RESPUESTA A CONSUTLAS TABLAS Y RELACIONES DATAMARTS: HECHOS Y DIMENSIONES Es por ello que para efectuar análisis de datos en tiempo real se recomienda la utilización de los almacenes de datos, tal y como vimos en el apartado anterior. Estos almacenes de datos van a permitir acceder en modo consulta de una manera efi ciente y van a permitir realizar las operaciones analíticas necesarias para extraer cono cimiento. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 14 TEMARIO OPOSICIONES COIICV | TEMA 36 3.1. Operadores OLAP Los operadores OLAP van a permitir la explotación a vanzada de los almacenes de datos. Los operadores más importantes son los siguientes: • Drill : Permite desglosar los datos a partir de una o más dimensiones. Es decir, permiten entrar a mayor nivel de detalle de los mismos. Por ejemplo, a partir de las ventas de una empresa, agregadas para verlas por comercial y terr itorio, permitiría entrar a detalle territorial bajando de un nivel de agregación super ior como es el país, a un nivel de detalle mayor como es la distribución por ciudad. • Roll : Permite realizar la operación contraria, es decir , agregar los datos a partir de una o más dimensiones. Por ejemplo, a partir de las venta s por comercial y territorio, poder agregar la distribución por ciudades para ver los r esultados a nivel de país, un nivel de agregación superior al anterior. • Slice & Dice : Permite seleccionar y proyectar datos, concretame nte slice permite seleccionar un subconjunto de los datos, y dice proyectarlo en una nueva vista. Por ejemplo, dada la distribución por comercial y terri torio, permitiría seleccionar un subconjunto de los comerciales y de los territorios y ver como resultado solo su cruce. • Pivot : Permite la reorientación de las dimensiones, camb iando filas por columnas, y recalculando el valor de las celdas. Siguiendo con el ejemplo, se podría cambiar de una vista de distribución de ventas por territorio agre gando por comercial y trimestre, a una vista de distribución de ventas por comercial, agre gando por territorio y trimestre. Una de las principales características de los opera dores OLAP es que se realizan en tiempo real y no requieren generar un nuevo informe (una nueva co nsulta SQL, una nueva hoja Excel, etc.), ya que tras aplicarlo, automáticamente se recalculan l os valores de las celdas y se dispone de la nueva información. Un aspecto importante relativo a l rendimiento tendrá que ver con la implementación que haga el almacén de datos de la a rquitectura OLAP. 3.2. Implementaciones OLAP Dependiendo del modo en que se implementen físicame nte los sistemas de base de datos que dan soporte al almacén de datos, se distingue entre: • Sistemas ROLAP (Relational OLAP): el almacén de datos se construy e sobre una base de datos relacional. Su principal ventaja es que se pu ede aprovechar la infraestructura de bases de datos relacionales de la organización y su s características, como la utilización de consultas SQL. Esto permite reducir costes de impla ntación y formación del personal. Sin embargo, debido a las propias restricciones de los modelos relacionales, para modelar un datamart con tecnología ROLAP se hace necesario el uso de tres tipos de tablas: las tablas copo de nieve, que almacenan los datos de cada una de las dimensiones a cada uno de los posibles niveles de agregación, las tablas de h echos, que almacenan la información de Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 15 cada elemento de la vida real que se quiera modelar con claves foráneas a cada una de las tablas copo de nieve, para poder agregar y desa gregar por cada posible dimensión, y las tablas estrella, que son tablas por cada atribu to de los objetos de las tablas de hechos, con claves foráneas a las tablas de copo de nieve c on un atributo por cada nivel de agregación para dicha dimensión. Como es de suponer , esto aumenta artificialmente el espacio requerido para modelar el problema. Ejemplo s de sistemas ROLAP son Microstrategy, Informix Metacube y Oracle Discovere r. • Sistemas MOLAP (Multidimensional OLAP): el almacén de datos se co nstruye sobre estructuras basadas en matrices multidimensionales. Su principal ventaja es la correspondencia entre el nivel lógico y el nivel fí sico, lo que hace que sean por lo general más eficientes. Sin embargo, sus principales inconv enientes derivan de esta mayor especialización, como que requieren sistemas especí ficos, o la necesidad de mayor espacio físico debido a la mayor desnormalización d e los datos, ya que se ajustan al mundo real sin pensar en restricciones de normaliza ción como se imponen en los sistemas relacionales. Además, esto último que propicia la v entaja de que existe una correspondencia más directa entre el mundo real y e l sistema que lo modela, también hace que en caso de que el problema varíe se deba efectu ar una reestructuración del sistema mayor que en un sistema ROLAP. Ejemplos de sistemas MOLAP son Oracle Express e Hyperion Enterprise. • Sistemas híbridos HOLAP (Hybrid OLAP), que combinan ambas tecnologías. Se puede encontrar una comparación entre servidores OLAP en la siguiente página de la Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_OLAP_Se rvers . 4. Minería de datos En (Clark y Boswell, 2000) se define la minería de datos como el proceso de extraer conocimiento útil y comprensible, previamente desconocido, desde grandes cantidades de datos almacenados en distintos formatos. De dicha definición se despr enden algunos hechos a considerar: • El resultado de la minería de datos debe ser conocimiento nuevo . • Dicho conocimiento debe ser inteligible y susceptible de generar valor para la toma de decisiones. Que el conocimiento deba ser inteligibl e no significa que el modelo de aprendizaje lo sea; por ejemplo, una red neuronal e s opaca en cuanto a su funcionamiento, pero su resultado puede aportar conocimiento para d eterminar el riesgo de una operación bursátil. • La entrada del proceso es una gran cantidad de datos en diversos formatos, a partir de los cuales se deberá extraer el conocimiento. Este punto es una de las bases que enlaza a la minería de datos con el big data . Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019