Archivo de la etiqueta: etl

Tecnologías de ingesta de datos en proyectos «Big Data» en tiempo real

11 comentarios

Cuando hablamos de las etapas que componían un proyecto de Big Data, y sus diferentes paradigmas para afrontarlo, una cuestión que cité fue la siguiente:

Si antes decíamos que un proyecto “Big Data” consta de cuatro etapas –(1) Ingestión; (2) Procesamiento; (3) Almacenamiento y (4) Servicio-, con este enfoque, nada más ser “ingestados”, son transferidos a su procesamiento. Esto, además, se hace de manera continua. En lugar de tener que procesar “grandes cantidades”, son, en todo momento, procesadas “pequeñas cantidades”.

Hadoop, que marcó un hito para procesar datos en batch, dejaba paso a Spark, como plataforma de referencia para el análisis de grandes cantidades de datos en tiempo real. Y para que Spark traiga las ventajas que solemos citar (100 vez más rápido en memoria y hasta 10 veces más en disco que Hadoop y su paradigma MapReduce), necesitamos sistemas ágiles de «alimentación de datos». Es decir, de ingesta de datos.

Es el proceso por el cual los datos que se obtienen en tiempo real van siendo capturados temporalmente para un posterior procesamiento. Ese momento «posterior» es prácticamente instantáneo a efectos de escala temporal. Esto se está produciendo mucho, por ejemplo, en el mundo de los sensores y el  IoT (Internet of Things). No podemos lanzar alarmas en tiempo real si no contamos con una arquitectura como esta. Muchos sectores son ya los que están migrando a estas arquitecturas de ingesta de datos en un mundo en tiempo real.

Y es que el «tiempo real», el streaming, comienza ya desde la etapa de ingestión de datos. Tenemos que conectarnos a fuentes de datos en tiempo real, como decíamos, para permitir su procesamiento instantéano. En la era del Business Intelligence, e incluso en la era del «Big Data batch», los ETL eran los que permitían hacer estas cosas. Hemos hablado ya de su importancia. Sin embargo, son herramientas que en tiempo real, no ofrecen el rendimiento esperado, por lo que necesitamos alternativas.

ETL vs Spark (fuente: http://image.slidesharecdn.com/k2ionstoica-151028153637-lva1-app6892/95/spark-summit-eu-2015-revolutionizing-big-data-in-the-enterprise-with-spark-10-638.jpg?cb=1469144488)
ETL vs Spark (fuente: http://image.slidesharecdn.com/k2ionstoica-151028153637-lva1-app6892/95/spark-summit-eu-2015-revolutionizing-big-data-in-the-enterprise-with-spark-10-638.jpg?cb=1469144488)

Estas son el tipo de cosas que permiten hacer Spark y Storm, cuyo paradigma en tiempo real ya comentamos en su día. Aparecen, junto a ellos, una serie de tecnologías y herramientas que permiten implementar y dar sentido a todo este funcionamiento:

  • Flume: herramienta para la ingesta de datos en entornos de tiempo real. Tiene tres componentes principales: Source (fuente de datos), Channel (el canal por el que se tratarán los datos) y Sink (persistencia de los datos). Para entornos de exigencias en términos de velocidad de respuesta, es una muy buena alternativa a herramientas ETL tradicionales.
  • Kafka: sistema de almacenamiento distribuido y replicado. Muy rápido y ágil en lecturas y escrituras. Funciona como un servicio de mensajería y fue creado por Linkedin para responder a sus necesidades (por eso insisto tanto en que nunca estaríamos hablando de “Big Data” sin las herramientas que Internet y sus grandes plataformas ha traído). Unifica procesamiento OFF y ON, por lo que suma las ventajas de ambos sistemas (batch y real time). Es un sistema distribuido de colas, el más conocido actualmente, pero existen otros como RabbitMQ, y soluciones en la cloud como AWS Kinesis.
  • Sistemas de procesamiento de logs, donde podemos encontrar tecnologías como LogStash, Chukwa y Fluentd.

Con estas principales tecnologías en el menú, LogStash y Flume, se han convertido en las dos principales soluciones Open Source para lo que podríamos bautizar como «ETL en tiempo real». Es decir, para la necesidad de recoger datos en tiempo real. La ingesta de datos como etapa de un proyecto de Big Data.

Y, de este modo, nacen «packs tecnológicos» alternativos al ETL como es EFK, acrónimo de Elastic Search + Flume + Kibana. Se trata de una plataforma para procesar datos en tiempo real, tanto estructurados como no estructurados. Todo ello, con tecnologías Open Source, lo que podría venir a animar a  muchas empresas que lean esta noticia, y entiendan el valor que tiene esto para sus seguras necesidades (cada vez más) en tiempo real.

  • Elastic Search: motor de búsqueda, orientado a documentos, basado en Apache Lucene.
  • Flume: ejcución de procesos de extracción, transformación y carga de datos de manera eficiente.
  • Kibana: dashboards en tiempo real, procesando y aprovechando los datos en tiempo real indexados vía Elastich Search.

Con todo esto, quedarían esquemas tecnológicamente muy enriquecidos y útiles para necesidades de negocio como el que se presenta a continuación:

Proyectos Big Data en tiempo real (Fuente: http://www.slideshare.net/Stratio/meetup-es-efk)
Proyectos Big Data en tiempo real (Fuente: http://www.slideshare.net/Stratio/meetup-es-efk)

Como podéis apreciar, en estos ecosistemas, los ETL ya no cumplen la función que han venido desempeñando históricamente. Su rendimiento en tiempo real es realmente bajo. Por lo que tenemos que dar un paso más allá. E introducir nuevas tecnologías de ingestión de datos. Kakfa, Flume, Elastic Search, etc., son esas tecnologías. Si tu empresa está empezando a tener problemas con el datamart tradicional, o si la base de datos ya no da mucho más de sí, quizás en este ecosistema tecnológico tengamos la solución.

Nosotros, en nuestro Programa de Big Data, todo esto lo vemos durante 25 horas, montando una arquitectura en tiempo real que dé respuesta a las necesidades de empresas que cada vez necesitan más esto. Las tecnologías de ingesta de datos al servicio de las necesidades de negocios en tiempo real.

Del «Big Data» al «Data Capital»: aprovechando el valor de los datos con un data lake

1 comentario

Hay dos grandes formas de entender esta era del Big Data: como una evolución del Business Intelligence -herramientas que extraen inteligencia de la información de una compañía y sobre ésta elaboran algunas predicciones-, o como una disrupción. La primera consideración, suele descartarla.

El Business Intelligence, se significó en una época en la que eran los datawarehouse la norma. Es decir, grandes almacenes de datos, estructurados, con una administración rígida. No solo ya desde la óptica del almacenamiento del dato es diferente su consideración, sino también desde la mirada de procesamiento de datos. El BI tenía un marcado carácter descriptivo. En esta nueva era del Big Data, creo que la predicción es la norma y lo que todo el mundo quiere hacer. Adelantarse al futuro, pero de una manera más informada y evidenciada. Es decir, asentándose en la mayor cantidad de información posible.

Y esto, claro, como hemos comentado muchas veces, es más posible que nunca antes en la historia, por la gran cantidad de datos existentes. Pero, son datos, que muchas veces, no podemos estructurar (la lógica seguida por los datawarehouse). Son datos, además, que muchas veces, no se pueden «juntar» con otros; es mejor mantenerlos por separado, y luego ya tratar de juntarlos en tiempo de procesamiento para la extracción de valor.

Fuente: http://2.bp.blogspot.com/-dfr85pnA6R0/VtRjMG1rrUI/AAAAAAAAAHA/xsv2qhPtLIo/s302/Francisco%2BJavier%2BCervigon%2BRuckauer.jpg
Fuente: http://2.bp.blogspot.com/-dfr85pnA6R0/VtRjMG1rrUI/AAAAAAAAAHA/xsv2qhPtLIo/s302/Francisco%2BJavier%2BCervigon%2BRuckauer.jpg

Esta lógica, va un paso más allá dentro del paradigma del Big Data. Supone considerar el dato como otro activo más. Es más, supone considerar el dato como el activo más crítico de la organización. Y así, disponer de un «data capital», como otro activo más de la organización, que permita ser luego capitalizado y activado para su puesta en valor en la organización. Es decir, el almacenamiento en bruto de datos, puede ser interesante, sin mayor orden, estructura ni criterio de clasificación.

El problema es que en este momento, la mayor parte de las empresas (tanto grandes, medianas como pequeñas), está aún en la fase inicial: recopilan la información y la almacenan. Pero todavía no saben muy bien qué se puede hacer con ella. Por ello mismo, ya hay algunos que empiezan a considerar que en este estadío, en el que todavía las organizaciones no saben muy bien qué hacer, pero sí que disponen de datos, es fundametal articular una estrategia de almacenamiento de datos con sentido.

Y aquí, emerge con fuerza el concepto de «data lake». Como se puede ver en la siguiente representación gráfica, se trata de un repositorio de datos estructurados y no estructurados, sin ningún preprocesamiento, guardando los datos en bruto, y sin esquema. A los que venimos originariamente de la administración de bases de datos y sus esquemas rígidos, un concepto, un paradigma, sustantivamente diferente. Al carecer de esquema, añadir nuevos datos, será relativamente fácil.

Fuente: Microsoft
Fuente: Microsoft

Se trata, en definitiva, de proveer a las empresas de un mecanismo de almacenamiento de datos sin mayor compromiso. Ya veremos en qué momento se nos ocurre qué hacer. El problema que veníamos arrastrando, es que los sistemas de esquemas de datos, en muchas ocasiones, condicionaban luego lo que poder hacer con los datos. Porque ya representaban «algo».

Con esta explicación, se puede entender por qué esta era del Big Data, es para mí un paso más allá del Business Intelligence. En la era del BI, todos los datos que recogíamos (estructurados y no estructurados), los ordenábamos y clasificábamos según el esquema. En un data lake, también recogemos todos los datos, pero no los alteramos, limpiamos o manipulamos. Su valor queda bruto, y ya veremos en su día qué hacer con ello.

Sin alterar la «materia prima» y dejarla en bruto, dejamos abierto el campo de explotación. Y estas opciones, tan prometedoras para muchas empresas, es lo que está haciendo que cada vez más empresas me pregunten por los data lakes. Es algo que para la capitalización del dato dentro de las organizaciones, se alinea muy bien. Ya veremos algún día qué preguntas hacerles a los datos. Todavía no lo sabemos, pero no nos importa. Sabemos que esos datos tendrán valor.

Por todo esto, ya hay muchos profesionales del Big Data que dicen de cambiar el paradigma ETL (Extract, Transform, Load, del que ya hablé aquí) por ELT (Extract, Load, Transform). Es decir, ya transformaremos después, no antes, lo que suele restringir mucha las opciones de lo que podremos hacer. Los data lakes, precisamente adoptan ese rol de almacén de datos «neutro», en el que no condicionamos luego lo que se podrá hacer. Y por eso, las herramientas ELT (que no son nuevas, por otro lado), también pudieran vivir un renacimiento.

Para cerrar, una imagen muy representativa de la idea trasladada hoy.

Data Lake vs Data Warehouse (Fuente: http://www.martinsights.com/wp-content/uploads/sites/8/2014/09/Data-lake-vs-Data-warehouse.jpg)
Data Lake vs Data Warehouse (Fuente: http://www.martinsights.com/wp-content/uploads/sites/8/2014/09/Data-lake-vs-Data-warehouse.jpg)

 

El Big Data en los Papeles de Panamá

4 comentarios

No creo que a estas alturas, a usted, estimado lector de cualquier parte del mundo del que lea esto, le tenga que contar nada sobre los «Papeles de Panamá». Unos documentos filtrados, en el que se dice la mayor filtración periodística de toda la historia. En el contenido de los mismos se puede encontrar a personas de todo el mundo aprovechando los paraísos fiscales para ocultar su dinero en el pago de impuestos. Nada que la ética no pueda explicar por si sola les voy a contar.

Pero de lo que se ha hablado menos es de cómo se produce. Como quizás también sepan, todo se produce a partir de la extracción de unos documentos de dos sitios web de la empresa Mossack Fonseca: la web que sirve como descripción de sus servicios -un WordPress- y un portal interno de clientes donde se podía compartir información sensible de todos ellos -un Drupal-. Uno, lo primero que podría pensar s que entonces la «culpa» es de la falta de seguridad tecnológica. Y efectivamente, al parecer, la falta de actualización del portal interno y un plugin de WordPress habrían expuesto toda esa documentación.

Pero, una vez obtenidos los documentos, hay que analizarlos para extraer inteligencia de los mismos. Vamos, un proyecto de Big Data, en definitiva, porque la cantidad documental de la que estamos hablando es realmente grande (2.6 terabytes, y 11,5 millones de documentos -Wikileaks, para que se hagan a la idea, fueron 1,7 GB «solo»-). El Big Data en los Papeles de Panamá ha jugado un papel nuclear.

La escala de los
La escala de los «Papeles de Panamá» (Fuente: http://www.alternet.org/files/screen_shot_2016-04-04_at_12.01.06_pm.png)

Lo interesante del caso para la temática de este blog es la parte que viene después de la obtención de la «puerta de entrada a los datos». Un proyecto de Big Data, literal:

  • Fuentes de datos: la heterogeneidad -una de las famosas 5 Vs- de las fuentes de datos es muy importante: cinco millones de emails, tres millones de ficheros de bases de datos, dos millones de PDFs, un millón de imágenes, más de 320.000 documentos de texto y 2.242 archivos de otro tipo no clasificados. Un reto de extracción de las fuentes de datos importante.
  • Integración de datos: para poder procesar esta heterogeneidad de las fuentes de datos, es preciso integrar todos estos datos en un mismo modelo de datos. Y claro, mientras hay documentos medianamente sencillos para ello (las bases de datos o los documentos de texto e emails por ejemplo -gracias a tecnologías de procesamiento de lenguaje natural-), tenemos también grandes retos como los PDF y las imágenes: deben primero pasarse a un formato de caracteres para luego poder disponerse para su explotación. Ya hablamos en este blog de la aportacióin de las herramientas ETL en ello.
  • Gestión de la calidad de los datos: hay que tener en cuenta que como «filtración» que es, los datos, obviamente, no están preparados para su explotación. Entre el mar de datos, muchos son totalmente irrelevantes y no hacen más que aportar una mala calidad a los datos de entrada. Esto, ya dijimos, era crítico de solucionar ex-ante.
  • Procesamiento de los datos para la extracción de inteligencia: una vez que los datos están preparados, se deben procesar, en este caso, buscando relaciones entre entidades y acciones. Para ello, estructurar anteriormente la información de una manera que permita navegar entre la información de manera ágil y eficiente, resulta clave. Y por ello, se procesó la información estructurada en grafas, que además de tener un buen rendimiento, permite extraer mucha inteligencia. Ya hablamos de ello.
  • Visualización de datos, obtención de inteligencia: la visualización analítica, eficiente e inteligente de datos es la que permite sacar conclusiones y tomar decisiones de manera ágil.  También lo comentamos. Para ello, es preciso visualizar los datos de una manera apropiada para obtener inteligencia de los mismos.
  • Y por debajo de todas estas etapas, una infraestructura tecnológica realmente potente: para poder hacerlo a una velocidad medianamente razonable se emplearon hasta 30 servidores en paralelo. Y, sobre estos servidores, mucho software de «Big Data», tal y como detalló Mar Cabra -responsable del área de Investigación y Datos del consorcio de periodistas ICIJ, que estaba a la cabeza de esta investigación. Incluye una lista de Software Libre y también propietario, que cedieron licencias por la causa, que ha sido adaptado por el propio consorcio para sus labores de Investigación.
    • Neo4j, tecnología que vemos en nuestro Programa de Big Data y Business Intelligence, fue la base datos de nueva generación (ya hablé de ella en otro artículo), donde se almacenaron las relaciones y coincidencias entre los documentos. Esta tecología, como ya expliqué, permite modelar la información a partir de conexiones entre entidades,  lo cual facilita mucho poder luego estudiar estos flujos de datos para detectar e inferir conocimiento. Aquí lo describe la propia empresa.
    • Nuix, un software de gestión documental, que permite indexar y categorizar información rápida y ágilmente. Aquí la noticia de ellos mismos hablando sobre el caso.
    • Con Apache Solr y Apache Tika, se puso a disposición de la búsqueda y recuperación la información contenida en los documentos de manera centralizada. Es la parte más relacionada con la integración de datos. Aquí explicado.
    • Linkurious,  la herramienta para trazar y visualizar los vínculos de la documentación obtenida por temas y sujetos de investigación. Aquí lo describen ellos mismos.

Obviamente, como solemos decir, la tecnología, por muy buena que sea, no descubre por sí sola. Por un lado, alguien debe hacerle las preguntas más acertadas, y en segundo lugar, alguien tiene que entender los resultados que nos devuelve. Ahí está la formidable labor realizada por los periodistas. Sin conocer el contexto bien, es difícil hacer un proyecto de Big Data de este calibre. Por ello, el futuro del periodismo con un importante soporte en datos y tecnologías que le permita acelerar su proceso de investigación se me antoja cada vez más cercano.

El «Big Data», como paradigma habilitante que es, permite cambiar las reglas de juego de diferentes sectores de actividad. En este caso, hemos visto cómo ayudó al caso de los «Papeles de Panamá». Y es que este método de trabajo que hemos visto (extracción, integración, depuración, procesamiento y visualización), con el apoyo de las mejores tecnologías para ello, ha venido para quedarse. El Big Data en los papeles de Panamá ha sido un paradigma muy habilitante.

Herramientas ETL y su relevancia en la cadena de valor del dato

6 comentarios

El proceso de Extracción (E), Transformación (T) y Carga (L, de Load en Inglés) -ETL- consume entre el 60% y el 80% del tiempo de un proyecto de Business Intelligence. Suelo empezar con este dato siempre a hablar de las herramientas ETL por la importancia que tienen dentro de cualquier proyecto de manejo de datos. Tal es así, que podemos afirmar que proceso clave en la vida de todo proyecto y que por lo tanto debemos conocer. Y éste es el objetivo de este artículo.

La cadena de valor de un proyecto de Business Intelligence la podemos representar de la siguiente manera:

Cadena de valor de un proyecto de BI (Fuente: http://www.intechopen.com/books/supply-chain-management-new-perspectives/intelligent-value-chain-networks-business-intelligence-and-other-ict-tools-and-technologies-in-suppl)
Cadena de valor de un proyecto de BI (Fuente: http://www.intechopen.com/books/supply-chain-management-new-perspectives/intelligent-value-chain-networks-business-intelligence-and-other-ict-tools-and-technologies-in-suppl)

Hecha la representación gráfica, es entendible ya el valor que aporta una herramienta ETL. Como vemos, es la recoge todos los datos de las diferentes fuentes de datos (un ERP, CRM, hojas de cálculo sueltas, una base de datos SQL, un archivo JSON de una BBDD NoSQL orientada a documentos, etc.), y ejecuta las siguientes acciones (principales, y entre otras):

  • Validar los datos
  • Limpiar los datos
  • Transformar los datos
  • Agregar los datos
  • Cargar los datos

Esto, tradiocionalmente se ha venido realizando con código a medida. Lo que se puede entender, ha traído muchos problemas desde la óptica del mantenimiento de dicho código y la colaboración dentro de un equipo de trabajo. Lo que vamos a ver en este artículo es la importancia de estas acciones y qué significan. Por resumirlo mucho, un proceso de datos cualquiera comienza en el origen de datos, continúa con la intervención de una herramienta ETL, y concluye en el destino de los datos que posteriormente va a ser explotada, representada en pantalla, etc.

¿Y por qué la importancia de una herramienta ETL? Básicamente, ejecutamos las acciones de validar, limpiar, transformar, etc. datos para minimizar los fallos que en etapas posteriores del proceso de datos pudieran darse (existencia de campos o valores nulos, tablas de referencia inexistentes, caídas del suministro eléctrico, etc.).

Este parte del proceso consume una parte significativa de todo el proceso (como decíamos al comienzo), por ello requiere recursos, estrategia, habilidades especializadas y tecnologías. Y aquí es donde necesitamos una herramienta ETL que nos ayude en todo ello. ¿Y qué herramientas ETL tenemos a nuestra disposición? Pues desde los fabricantes habituales (SAS, Informatica, SAP, Talend, Information Builders, IBM, Oracle, Microsoft, etc.), hasta herramientas con un coste menor (e incluso abiertas) como Pentaho Kettle, Talend y RapidMiner. En nuestro Programa de Big Data y Business Intelligence, utilizamos mucho tanto SAS como Pentaho Kettle (especialmente esta última), por lo que ayuda a los estudiantes a integrar, depurar la calidad, etc. de los datos que disponen. A continuación os dejamos una comparación entre herramientas:

Comparación Talend vs. Pentaho Kettle
Comparación Talend vs. Pentaho Kettle

¿Y qué hacemos con el proceso y las herramientas ETL en nuestro programa? Varias acciones, para hacer conscientes al estudiante sobre lo que puede aportar estas herramientas a sus proyectos. A continuación destacamos 5 subprocesos, que son los que se ejecutarían dentro de la herramienta:

  1. Extracción: recuperación de los datos físicamente de las distintas fuentes de información. Probamos a extrar desde una base de datos de un ERP, CRM, etc., hasta una hoja de cálculo, una BBDD documental como un JSOn, etc. En este momento disponemos de los datos en bruto. ¿Problemas que nos podemos encontrar al acceder a los datos para extraerlos? Básicamente se refieren a que provienen de distintas fuentes (la V de Variedad), BBDD, plataformas tecnológicas, protocolos de comunicaciones, juegos de caracteres y tipos de datos.
  2. Limpieza: recuperación de los datos en bruto, para, posteriormente: comprobar su calidad, eliminar los duplicados y, cuando es posible, corrige los valores erróneos y completar los valores vacíos. Es decir se transforman los datos -siempre que sea posible- para reducir los errores de carga. En este momento disponemos de datos limpios y de alta calidad. ¿Problemas?ausencia de valores, campos que tienen distintas utilidades, valores crípticos, vulneración de las reglas de negocio, identificadores que no son únicos, etc. La limpieza de datos, en consecuencia, se divide en distintas etapas, que debemos trabajar para dejar los datos bien trabajados y limpios.
    • Depurar los valores (parsing)
    • Corregir (correcting)
    • Estandarizar (standardizing)
    • Relacionar (matching)
    • Consolidar (consolidating)
  3. Transformación: este proceso recupera los datos limpios y de alta calidad y los estructura y resume en los distintos modelos de análisis. El resultado de este proceso es la obtención de datos limpios, consistentes y útiles. La transformación de los datos se hace partiendo de los datos una vez “limpios” (la etapa 2 de este proceso)(. Transformamos los datos de acuerdo con las reglas de negocio y los estándares que han sido establecidos por el equipo de trabajo. La transformación incluye: cambios de formato, sustitución de códigos, valores derivados y agregados, etc.
  4. Integración: Este proceso valida que los datos que cargamos en el datawarehouse o la BBDD de destino (antes de pasar a su procesamiento) son consistentes con las definiciones y formatos del datawarehouse; los integra en los distintos modelos de las distintas áreas de negocio que hemos definido en el mismo.
  5. Actualización: Este proceso es el que nos permite añadir los nuevos datos al datawarehouse o base de datos de destino.

Para concluir este artículo, os dejamos la presentación de una de las sesiones de nuestro Programa de Big Data y Business Intelligence. En esta sesión, hablamos de los competidores y productos de mercado ETL.