Consideraciones procesos ETL en entornos Big Data: Caso Hadoop
En el presente post pretendemos mostrar la problemática que con frecuencia encontramos en los procesos de extracción, validación y carga de datos en los entornos Big Data. Un proceso ETL tradicional, extrae datos desde múltiples fuentes origen, después los valida, normaliza, realiza determinadas transformaciones y vuelca los mismos en un entorno datawarehouse para su posterior análisis. Cuando en los datos fuentes, tenemos volúmenes altos, una frecuencia de actualización alta en origen o bien son datos no estructurados, estos procesos ETL suelen tener problemas..
El mercado actual vive un cambio de lo antiguo a lo nuevo. Por un lado, tenemos empresas actuales que operan con soluciones instaladas. Sus soluciones han de modernizarse para que puedan aprovechar las ventajas que ofrecen las nuevas tecnologías, y garantizar, a su vez, que mantienen las cualidades que resultaron atractivas para el cliente en primer lugar..
Ya está aquí el nuevo sorteo de Dataprix! Conseguir uno de los 3 ejemplares del libro 'Big Data Analytics with R and Hadoop' es muy fácil! En este post explicamos como!
En principio un concepto como el Big Data, puede parecer que es un traje que le queda demasiado grande a una pyme. El Big Data se define como la capacidad para recopilar y analizar las enormes cantidades de datos que el mundo genera actualmente, y aquí también las empresas, consumidores, máquinas con las que interactúan..
Los triggers o desencadenadores son disparadores que saltan cuando realizamos la acción o evento al que van asociados. En MS SQL Server, además de los triggers clásicos relacionados con acciones DML (insert, update, delete) que se ejecutan en su lugar (instead of) y después (after triggers), desde SQL Server 2008 (por lo menos) existe otro tipo que son los triggers asociados a acciones que se producen por consultas DDL. Este segundo tipo de trigger está más pensado para labores administrativas como la propia auditoria, para el control de cierto tipo de operaciones e incluso evitar esos cambios.
Por el motivo que sea, un día puede que cambiamos de trabajo o de funciones dentro de nuestra empresa y de repente heredemos un entorno de base de datos Microsoft SQL Server con un servidor o clúster de bases de datos para que nos encarguemos de él. Antes de empezar a cambiar cosas, es totalmente necesario conocer el uso que se hace de la base de datos, la criticidad de las aplicaciones que la usan, las dependencias entre ellas etc... A continuación una lista de las primeras cuatro tareas que podríamos llevar a cabo para empezar a hacerlo nuestro.
En el post anterior explicaba como examinar el registro de transacciones de una base de datos para ver poder ver el detalle de los cambios realizados en la misma, ya sean consultas DML como DDL. En este post se explica como usar la misma herramienta en otro caso práctico para poder detectar en que momento se han borrado unos datos y como recuperarlos haciendo una restauración point-in_time de la base de datos para poder copiarlos de nuevo.