Voy a comentar algunas cosas chulas que he ido oyendo por ahí sobre el Desarrollo Ágil y el Test Driven Development. Un compañero, Alberto Rodríguez de Lema, dió una charla un día sobre este tema y tenía apuntadas algunas cosillas que creo que está bien comentar con vosotros.

Desarrollo Ágil

Aunque muchos de nosotros estaremos involucrados en desarrollos ágiles, utilizando Scrum o algún híbrido estoy seguro que no lo aplicamos al 100% como deberíamos. Me sorprendió mucho las recomendaciones que nos dió Alberto basada en su experiencia.

Una de las pegas del bodyshopping en España es el rango de tiempo en el que se deben desarrollar las aplicaciones. La calidad se ve afectada siempre por los tiempos, y los empleados somos incapaces de absorber técnicas que nos faciliten la vida y nos hagan ser más productivos. Normalmente tienes que dedicar tu tiempo libre a mejorar como profesional ya que la formación escasea. El problema además es que te acaban viendo como un enemigo, que no tienes ni idea de lo que haces porque las cosas no funcionan o no van lo suficientemente rápido. Muy lamentable pero real.

A continuación veremos algunas técnicas poco utilizadas por regla general pero que se utilizan en entornos especializados de desarrollo software y por lo tanto a algunos le sonará a chino o incluso lo verán una gilipollez (basado en hechos reales).

Pair Programming

Siempre que explico esto y que me gustaría utilizarlo me dicen: "es poco productivo". Parece ser que todavía seguimos empeñados en ver el desarrollo de software como si nos pusieramos a picar en una mina. El desarrollo de software es un ejercicio intelectual, para llegar a soluciones necesitamos atacar estos problemas de manera distinta.

Pair Programming consiste en juntar a dos personas con distinto nivel o conocimientos y ponerlas a desarrollar software. Para ello se utiliza normalmente la técnica Ping-Pong TDD, en la que una persona codifica y arregla fallos mientras la otra plantea pruebas. En pair programming se recomienda cambiar de pareja y en concreto Alberto nos dijo que lo hacían cada 2-3 días. Esto tiene pros y contras:

Las cosas buenas es que las personas del equipo si que eran realmente Multidisciplinares.

Las cosas malas es que las personas acababan medio locas por el cambio de contexto.

Integración continua

Las prisas hacen que no nos paremos a pensar pero ¿qué pasa si los cambios los ponemos en producción directamente habiendo hecho simplemente unit test? Seguramente petará. Poco o nada dedicamos a la integración continua y debería ser tan necesaria como un buen gestor de repositorios.

Alberto nos comentó que tenían una alarma que sonaba en toda la oficina cuando alguien subía algo y fallaba.

El perfil DevOps

Si tienes el privilegio de tener a una persona sólo de sistemas dentro de tu proyecto (cosa rara), verás que sufre algunos ataques al corazón de vez en cuando cuando tiene que trabajar en su día a día. Para ayudarle a que no tenga estos problemas, es recomendable que aprenda a como optimizar su trabajo utilizando técnicas de programación.

Test Driven Development

Los principios básicos de Test Driven Development son:

· Escribir nuevo código si tenemos primero un test que falla.

· Eliminar duplicación (conseguir un código lo más "bonito" posible)

Esto tiene unas implicaciones técnicas:

· Diseñar el código según escribimos nuestros tests: debemos encontrar un balance entre el diseño de UMLs y la realización de tests para que nos orienten por donde tenemos que ir.

· El entorno de desarrollo tiene que ser capaz de decirnos rápidamente el estado de nuestro código en todo momento (debe ser rápido o sino se deja de hacer pruebas, por lo que hay que diseñarlos para q sean lo más rápido posibles)

· Diseñar componentes altamente cohesivos y muy poco acoplados para conseguir probarlos fácilmente.

Ciclo de desarrollo en TDD

RED->GREEN->REFACTOR

· El objetivo es pintar el verde (según Alberto, en su equipo no te podías ir al baño si tenías un test en rojo XD). Digamos que hay que intentar que los tests siempre pasen a verde y no estén en rojo, después de eso puedes continuar.

· Esto conlleva una serie de ventajas:
- Cada pocos segundos se comprueba que el código hace lo que debería. Si algo va mal sólo hay unas pocas líneas de código que comprobar.
- Escribir test antes que el código nos centramos en interfaces más que en la implementación.
- Los tests se suben al repositorio con el código->se genera la documentación->luego cada programador ejecuta los tests en cada build.

Y hasta aquí el deleite. Aprendí mucho en esa sesión, pero lamentablemente no puedo poner en práctica estas cosas, ya que o el equipo no está institucionalizado o todo es con prisas y SIN formación. Como siempre digo, hay muchos más aspectos a destacar y por ello te animo a que comentes que crees que puede ser de utilidad a los equipos de desarrollo ágiles.

Nos vemos en la siguiente.

Hoy entramos en el tercer paradigma famosete en estos últimos años, en esto del #BigData : La arquitectura Lambda.

Arquitectura Half-life...ejem digo Lambda!!!

Aquí tenéis los anteriores post relacionados:

Aquí estamos otra semana más, comentando el curso de Ingeniería de Datos impartido en la Real Academia de Ingeniería.


Ya queda poco para terminar y por el momento estoy plenamente satisfecho con los profesores y el contenido. Como sabéis aquí hablo de BigData día si y día también e ir a estos cursos me acerca al pasado de los #datos. Los profesores son grandes experimentados en el tratamiento de información y me están ayudando a situar en el mapa el BigData y a establecer lo que nos depara en estos años a los ingenieros que nos dedicamos a tratar datos.

Mañana - Redes Neuronales, aprendizaje y adaptación por José R. Dorronsoro Ibero

La sesión comenzó con José hablando sobre Bigdata y cómo está generando mucho vaporware, pero a su vez muchas oportunidades.

Nos contó que los científicos de los 50 pensaban que acabaríamos creando cerebros artificiales pero que sin embargo vemos como hoy aún nos cuesta utilizar la abstracción de una simple neurona. Crear estructuras basadas en redes neuronales es muy compleja y el concepto ha ido dando forma hasta hoy día. En la sesión vimos los Perceptores Muti Capa, el Filtro Adaptativo, Descenso en gradiente...y muchos conceptos rarunos.

Por último nos contó en que consistía las Redes Neuronales Profundas, que ahora mismo son objeto de estudio por las grandes empresas que gestionan datos, así como ejemplos de aplicación.

Tarde - Conjunto de Máquinas por Aníbal Figueiras Vidal

Aníbal explicó la diferencia entre la inferencia humana y la inferencia máquina, y por qué somos complementarios.

Comentó muchísimos algoritmos para el aprendizaje de máquinas entre máquinas, hablando de Comités, Consorcios, Mezcla de Expertos, Boosting, "Negative Correlation Learning"...

Muy densa, pero Aníbal es un crack. Me quedo con su frase final:

"...las cosas se hacen mal. ¿Y cómo se deben hacer las cosas?: ¡Cómo dios manda!, ¿y cómo es cómo dios manda?: ¡CÓMO YO DIGO!"

La tercera sesión será práctica y veremos como aplicar toda esta teoría. Os espero en la próxima parada ;)

Seguimos con esta serie de "paradigmas" en el mundo #bigdata

Hoy voy a hablar algo sobre tratamiento de datos en Tiempo Real, que hay detrás de este concepto y algunas cosillas de las que me he ido desmitificando. Lets GO!


A continuación tenéis la lista de Post:

- Paradigmas BigData: El procesamiento Batch
- Paradigmas BigData: El procesamiento Real Time
- Paradigmas BigData: Arquitectura Lambda

Antes de comenzar dejar claro con qué queremos decir cuando hablamos de "Tiempo Real" en #bigdata :

Con Tiempo Real nos referimos al procesamiento en streaming de datos en tiempo muy pequeños que permiten su tratamiento analítico (o de parte de ellos).

Una vez dicho esto, si alguien os dice que eso se hace instantáneamente, dudad hermanos.

He tocado alguna de las tecnologías que voy a comentar hoy, que creo que representan bien el escenario tecnológico de tratamiento de datos en Tiempo Real, aunque por supuesto hay muchas mas.

Flume

Allá por el año 2010 se Cloudera presentó Flume, programa para tratamiento e ingesta de datos masivo. Esto daba la posibilidad de crear desarrollos complejos que permitieran el tratamiento de datos masivos creados en Tiempo Real.

En Real Time se utiliza en la etapa de Obtención de Datos (para conectarnos a fuentes de datos Online).

Su arquitectura es sencilla, pues tiene tres componentes principales, muy configurables:

Source: Fuente de origen de los datos
Channel: la vía por donde se tratarán los datos
Sink: persistencia/movimiento de los datos

Flume es sencillito apriori, el problema es cuando quieres utilizarlo para obtener datos de manera paralela (o multiplexada) y además te ves en la necesidad de crear tus propios Sinks, o tus propios interceptores. Entonces la cosa cambia y hay que dedicarle algo más de tiempo.

Muy recomendada como ayuda|compañero|alternativa a herramientas como Kettle.

Kafka

Sencillamente es un servicio de commit log, particionado, replicado y distribuido.

En su arquitectura encontramos que disponemos de un modelo Productor/Consumidor, cuyos mensajes se pueden categorizar en algo llamado topics y que funciona como si fuera un cluster.

Se suele utilizar como gestor de colas.

Se utiliza en la etapa de Almacenamiento de Datos.

Storm

Es un sistema de computación distribuida y escalable para procesamiento de datos en Tiempo Real y realiza en Tiempo Real, aquello que el Hadoop|Spark realizan en Procesamiento Batch.

Se compone de tres elementos, englobados en Topology (cada nodo contiene spouts y bolts, y entre ellos hay streams de datos):

Spout: fuente de datos en stream. Simplemente lee los datos de la fuente de origen y los emite a modo de stream.
Bolt: es la unidad de proceso. Lee datos de múltiples streams, permitiendo el tratamiento de los datos y posibilitando emitir de nuevo streams.
Stream: es una secuencia de tuplas sin límites. Las tuplas pueden contener objetos serializables.

En Storm, tenemos tres demonios principales:

Nimbus: sería como el JobTracker en Hadoop
Supervisor: el TaskTracker de Hadoop
Topology: el Job de Hadoop

Hay mucha magia negra con esto y haré algún post técnico en el futuro.

Utilizado en la etapa de Análisis de Datos.

Por tanto, tendríamos un ejemplo de tecnologías en Tiempo Real utilizando tecnologías #bigdata :

Imaginemos que queremos capturar el Log de una web y tratarlo en tiempo real. Una arquitectura sería la siguiente:

Flume (vamos obteniendo datos de diversas fuentes) > Kafka (encolamos) > Storm (analizamos)

Nos vemos en la próxima ;)

Era Programador y me dedicaba a hacer programas de escritorio. Estuve colaborando en cinco equipos distintos de trabajo, y la metodología que se seguía en todos se basaba en el modelo en cascada (o eso parecía , porque tampoco era muy conocedor por aquel entonces de estas cosas). Me quejé durante años de los efectos colaterales que esto tenía para las personas y para la industria, y de hecho fue uno de los motivos que me hizo retirarme al estudio de Ingeniería del Software, para solucionar todas esas incógnitas que me machacaban día a día.

En mi retirada se puso de moda el agilismo o lo "agile" y cuando salí al mercado laboral de repente la mayoría de las empresas tenían implantado Scrum o algún híbrido de origen desconocido, al menos en sus slogans publicitarios lo decían (he ahí el quid de la de cuestión).

Yo estoy encantado con que el mercado se haya dado cuenta de la importancia que tienen las personas cuando desarrollamos software y por tanto, implique cambios en los equipos de trabajo, el único problema que veo es que "lo marketiniano" engulle a lo "práctico" en el mundo real.

Creo sinceramente que para aplicar bien Scrum o cualquier otra metdología ágil, hace falta un conocimiento profundo de la materia por al menos un miembro del equipo, que haga de coach al resto. Por otra parte y no menos importante creo que hace falta que todos los miembros estén institucionalizados con este tipo de metodologías. Y...¿por qué creo eso?, porque para que haya caos en una sociedad, sólo hace falta que una persona se descontrole y que aplicado a los equipos de trabajo, hablamos de algo serio, que es llevar a buen puerto o al desastre los desarrollos software.

Ahora los equipos de desarrollo software tenemos otros problema, como que los miembros del equipo vean a esto una gilipollez, la falta de líderes dentro del equipo (suplantada por jefes encubiertos), malas comunicaciones producidas por falta de confianza, falta de documentación necesaria para poder trabajar, nada de comentarios en código (porque claro, ahora con la agilidad no hace falta poner comentarios en el código y de hecho mucho gurú ha ido adoctrinando diciendo que el código debe ser autoexplicativo y que los comentarios son innecesarios e incluso basura), etc.

Creo que sería conveniente decidir aplicar Scrum o cualquier otro tipo de metodologías, como un conjunto de buenas prácticas pero que si se va a usar, pienso que se debe usar correctamente por parte de todo el equipo.

Me acuerdo hace años de la figura|rol de "Software Configuration Manager" que ahora en los equipos ágiles no existe (se supone que está distribuido en el equipo y que al final se hace a marchas forzadas). Pues este rol lo se encargaba de cuidar de todo el desarrollo, desde la parte de documentación de estándares, calidad del código, pasos a producción... Vamos, que suplía un poco eso de la "calidad software". Ahora es que ni eso.

Por otra parte antes había jerarquías. Ahora es equipo multidisciplinar pero claro, sigue habiendo objetivos que cumplir. En equipos ágiles hacen falta líderes y no jefes, pero ante la falta de líderes se crean "Imperios Ágiles" donde o estás del lado del Imperio, o del Lado Rebelde.

En los equipos de desarrollo en los que participo, hablo de estas cosas y todos acabamos hablando de las cosas que he ido comentando.

Buenas compañeros digitales. Estoy asistiendo a un curso sobre Ingeniería de Datos, BigData que se imparte en la Real Academia de Ingeniería.

El curso está compuesto por tres sesiones y abarca temas sobre Minería de Datos, BigData, Machine Learning, etc y en definitiva damos un repaso a todo lo que tiene que ver sobre la gestión de los datos, que tan de moda está últimamente.

A mi me gusta crear contenidos de calidad, si bien es cierto que ando en mejora continua. Creo que gracias a este curso, voy a ser capaz de transmitir con mayor acierto todo esto de "los datos".

Sin entretenerme más comenzamos con un resumen del primer día:

Primera mitad de la Mañana - David Ríos - Introducción al curso

David Ríos ha sido profesor mío en el Máster de Sistemas de Información y nos habló de este curso, recomendándonos su asistencia si queríamos saber más sobre la actualidad y futuro en cuanto a los #datos. La sesión empezó hablando sobre #BigData y las distintas definiciones que andan pululando alrededor del planeta. Vimos de nuevo la mítica presentación de Dan Ariely sobre la relación metafórica entre el BigData y el sexo entre adolescentes. Nos contó que era para el lo más importante en un proyecto de datos, que hacía que hablásemos de el como #BigData y nos puso muchísimos ejemplos de proyectos en los que ha participado, haciéndonos un resumen y contándonos alguna batallita muy interesante.

Nos habló de lo importante que se está volviendo para las grandes empresas la predicción en tiempo real. Nos contó que durante el curso veríamos algunas técnicas y algoritmos que nos ayudarían en nuestros proyectos desde Redes Neuronales, Aprendizaje Basado en Reglas de Negocio hasta Redes Bayesianas.

Comentó los diferentes perfiles y etapas que podemos encontrar en los nuevos proyectos relacionados con datos y destacó la futura gran demanda de Ingenieros de Datos y Analistas de Datos.

Segunda mitad de la Mañana - Felipe Ortega - Procesamiento de datos: Infraestructura

Felipe es un gran experimentado en datos. Lleva muchísimos años tratando de gestionar grandes volúmenes de datos y a través de la charla que nos dió intentó transmitirnos su experiencia vital, nos dió consejos, y nos ofreció herramientas y pistas para no ahogarnos en mitad del #mardedatos

Repasó las distintas etapas que suele haber en proyectos #BigData (que para muchos profesionales no deja de ser #DataMining utilizando nuevas tecnologías) y dió muchísima importancia a tres cosas:

1- El equipo: debe haber personas de distintos perfiles:
    · Una persona de negocio: encargada de saber todo lo que tiene que ver sobre el área de negocio en el que se van a tratar los datos. Deben estar involucradas desde el principio hasta el final del proyecto y son una pieza fundamental, de manera que si estamos realizando un proyecto para un comercio de venta de neumáticos, debe haber una persona especializada en la gestión de ventas de neumáticos.

2- La obtención de los datos: como en todo proyecto de Data Mining, los datos son lo más importante. La limpieza (que no significa eliminar los datos erróneos, sino ver por qué están mal y arreglarlos) y el tratamiento de los datos consume hasta el 80% de un proyecto. Si ha esto le sumamos el componente tecnológico que tienen los proyectos #BigData , estamos ante proyectos que si se estiman mal en su inicio, pueden llevarnos a la ruina.

3- Replicabilidad: si estamos en entornos académicos, destacó la importancia de poder replicar las investigaciones. De nada vale hacer un proyecto genial, si luego no se puede utilizar en el Mundo Real, ya sea porque los datos tengan NDA o mil motivos más. Si vamos a publicar un paper, que sea 100% replicable.

También habló sobre Hadoop y su ecosistema (Pig, Hive, Hbase, Mahout), Spark, Shark, Cassandra, etc. y de sus pros, contras y cómo Spark va a ir ganando terreno en los próximos años frente a Hadoop.

Una charla excelente, de la que me he ido con unas cuantas ideas para crear posts en el futuro.

Por la tarde - Daniel Borrajo - Aprendizaje de Reglas de Negocio

Daniel Borrajo, profesor de la Universidad Carlos III de Madrid, nos inició al mundo del aprendizaje automático basado en reglas de negocio. La sesión fue muy práctica, proponiéndonos ejemplos para entender bien los distintos algoritmos. Comenzó contándonos que era "el aprendizaje basado en reglas de negocio" y por qué era tan importante para extraer información en las empresas y sus líneas de negocio.

Repasamos algunos algoritmos de aprendizaje, como el ID3 (y su problemática con el overfitting) y dedicó casi toda la tarde a hablarnos de algoritmos clasificadores capaces de ser entrenados.

Destacó que las redes neuronales para el aprendizaje automático están muy bien, pero que realmente su output es ilegible. Piensa que cuando estamos en negocio, lo mejor es comunicarnos en su propio idioma y nos recomendó utilizar WEKA (para la utilización de los algoritmos vistos en clase) y Prologic (para utilizar lógica que se adapte a nuestros casos de uso).

Me gustó mucho su clase y aún así, nos quedamos sin ver otros aspectos muy interesantes como el Modelado de Usuario, que consiste en sustituir a humanos por programas de aprendizaje automático (hay casos de intentona...y creo que los tiros en los próximos años van a ir por ahí).

Y terminó el curso. Ha sido un resumen de las ideas con las que me fui a dormir ese día, pero hay muchísimo más material, tanto que voy a necesitar estudiarlo con detenimiento en las próximas semanas.

Os iré contando, os espero en el próximo ;)!

Seguimos con la serie de Posts sobre Obtención de Datos. A continuación tenéis los links:

La Etapa de Obtención de Datos en BigData (I). Definición y Fuentes de Origen.
La Etapa de Obtención de Datos en BigData (II). Principales Retos.

¿Cuáles son los retos de esta etapa?

A continuación veréis algunos motivos por los que llega a consumir tanto tiempo/esfuerzo y por lo que debemos crear un buen análisis del panorama antes de meternos en agujeros oscuros.

Reto 1 - Técnicas que utilizaremos

Para fuentes de Tipo Online:
· Scraping: todo buen programador que se precie ha toqueteado alguna vez sistemas de extracción de datos de documentos, ya sea para leer sus metadatos o el contenido del cuerpo. Si se realiza de contenido web, estamos hablando de web scraping, y se utiliza para la generación de crawlers por ejemplo. Tengo por ahí una aplicación que hice para android hace un par de años llamada Amaizon, que hace hacía lo mismo que camelcamelcamel.com, pero en versión móvil (aunque bastante más cutre).

· API´s: conexióna través de servicios que proporcionan sus datos en formatos XML, JSON, YAML... Con sus limitaciones, como veremos más adelante.

Para fuentes de Tipo Offline:
· Módulos/Plugins: programaremos herramientas para la carga de datos de manera masiva y coherente en sistemas de almacenamiento NoSQL.

· Programas/Desarrollos especializados: utilizaremos programas para la carga masiva/tratamiento de datos como Flume, Kettle...

Reto 2 - La Representación de los Datos

Conocidas son mis excentricidades por los seguidores habituales de este blog y en esta línea expondré lo que creo que es vital para realizar con éxito el proyecto:

Teoría Pokemon

· La teoría Pokemon: Como bien sabrá el "sector friki" que me lee, los pokemon son criaturas que evolucionan y cambian su forma, pero realmente estaremos ante el mismo pokemon. Algo así sucede con la representación de datos. Para que os hagáis a la idea del ciclo de vida del tipo de dato que recogemos hasta que tenemos que introducir en la base de datos NoSQL:

Esto que parece una tontería, una obviedad y que haría enfurecer a media comunidad científica y académica si pensara plantear esto por cauces oficiales, es con frecuencia la causa más extendida de pérdida de tiempo dentro de equipo si las cosas no se hacen bien desde el principio.

Recordad que el Dataset que nos llegue también podrá estar mal representado a su vez en los sistemas de origen.

Reto 3 - Consolidad los Datos Obtenidos

Debemos asegurarnos que el Dataset (fuente de origen completa) que vamos a tratar esté consolidado correctamente. Lo mejor es contarlo mediante un ejemplo:

"En una de las mil millones de filas que tengamos en el DataSet, en uno de sus campos tipo fecha, encontramos un número, sólo, aburrido, molesto, agotador."

Esto suele suceder cuando nuestro Dataset de origen es un dump de tipo texto plano. A saber que ha pasado en el export. Sea como sea, nuestro deber es limpiarlo todo y dejar los campos bien representados.

Reto 4 - Movimiento de los Datos

Aunque obvio, por regla general se nos suele pasar desapercibido que "¡estamos manejando cantidades gigantescas de datos!", por lo que tenemos que cambiar nuestra manera de interaccionar con ellos y adaptarnos a esta nueva situación, con las tecnologías existentes.

Reto 5 - Velocidad de Ejecución

Una vez ya tenemos todo en su sitio, consolidado correctamente, ordenado etc, debemos realizar la carga. Para ello hay que estudiar que herramientas, tecnologías y métodos serán los más adecuados. Lo normal es generar conocimiento en el equipo mediante benchmarking.

Reto 6 - Vendor Lock-In

Las fuentes de origen si son sistemas privados, van a poner impedimentos para que se traslade toda su funcionalidad a otros sistemas en la mayoría de casos. Por ejemplo, si tratas con Oracle, agárrate los machos, porque vas a sufrir mucho para tener una réplica del sistema.

Este Post pertenece a la serie "La Etapa de Obtención de Datos en BigData". A continuación tenéis el listado:

La Etapa de Obtención de Datos en BigData (I). Definición y Fuentes de Origen.
La Etapa de Obtención de Datos en BigData (II). Principales Retos.

Cuando comencé en esto del #BigData, el "hype" que generó a mi alrededor todo lo que tenía que ver sobre procesamiento y/o almacenamiento de los datos, me llevó a pensar que lo más duro (o al menos lo más decisivo) cuando participase en este tipo de desarrollos, iba a tener que ver sobre cómo aplicar hadoop, spark, cassandra, hbase, etc.

Si estáis igual de "hypeados" que yo en aquel momento, siento cortaros el "royo marketiniano", pero la experiencia que más sacrificio nos ha supuesto al equipo y a mi como Desarrollador Software especializado en #BigData, ha sido lograr realizar cargas de datos masivas de una base de datos relacional, a una base de datos "no sólo" relacional con éxito, y aunque os parezca algo extraño en este post vamos a ver "el por qué".

La importancia de los Datos

A medida que he ido ganando experiencia a través de la participación en distintos proyectos, he cambiado sibilinamente de opinión, acabando por pensar que lo más importante que hay en un proyecto #BigData son los datos, cosa aparentemente obvia, pero veremos que en entornos de trabajo no es 100% así.

Todo gira entorno a los Datos. La matería prima de #BigData

Si vamos al esquema de las etapas clásicas que definen a los proyectos #BigData, encontramos:

Etapa 1 - Obtención de Datos
Etapa 2 - Preparación y Transformación de los Datos
Etapa 3 - Almacenamiento
Etapa 4 - Procesamiento
Etapa 5 - Visualización

Depende del proyecto podremos encontrar alguna más, dada la naturaleza de las tareas que debamos desempeñar según los requerimientos del cliente.

Si, la primera etapa es la de "Obtención de Datos". Pero...¿en qué consiste esta etapa?. Según mi experiencia, he propuesto una definición:

Una ETL a lo grande.

"Es la etapa en proyectos #BigData en la que se estudian los datos de una fuente origen, ya sea online u offline, se establecen mecanismos y procesos para su tratamiento, y son volcados de manera coherente en sistemas de almacenamiento NoSQL."

Pero, ¿qué es y qué significa realmente para los equipos la etapa de "Obtención de Datos" en la gran mayoría de casos?:

La respuesta os la puede dar José Felipe Ortega, Científico de Datos e Investigador de la Universidad Rey Juan Carlos:

Es una etapa crucial, necesaria y a menudo infravalorada.

¿Qué os puedo contar yo, dadas mis experiencias?:

Cómo dijeron en alguna escena de la película 300 (ahora que está tan de moda, os recomiendo el visionado de ese momento para que sepáis que se siente más o menos ):

No va a ser rápido, no te va a gustar y no soy tu Rey.

Bromas a parte, esta fase nos consume hasta el 30% del tiempo/esfuerzo del proyecto, sin embargo tendemos a creer que seremos capaces de superarla con escasos problemas...craso error.

Ocupación del Tiempo/Esfuerzo de la Obtención de Datos en un Proyecto

Las personas encargadas de llevar a buen puerto la Obtención de Datos, deben ser expertos (persona experimentada) en la manipulación, tratamiento e ingestión de datos, así como especialista en tecnologías de almacenamiento #BigData, avisados quedáis.

Fuentes de Origen. Importancia, tipos (online/offline) y opinión.

Importancia

Mirad, la composición de facto de estos desafíos es cómo vamos a ser capaces de dar una solución al mar de datos que tienen las empresas, y que no usan adecuadamente o tienen desaprovechados. Sus fuentes de datos serán nuestras fuentes de origen, y tendremos que tener especial cuidado cuando nos metamos a inspeccionarlos y analizarlos. Hay que hacer ver al cliente la importancia que tienen sus datos, realizar reuniones inception que sincronicen nuestras opiniones y conocimientos, y que les haga partícipes y responsables, dado que el éxito/fracaso del proyecto se verá afectado por la calidad, transparencia y rigor de sus datos.

Tipos (online/offline)

Tipos de Fuentes de Datos: Online(API..) vs Offline(Fuentes de Búsqueda...)

· Online: me refiero a las API´s(twitter es un ejemplo) que nos proporcionan clientes o servicios, y que iremos ingestando en "tiempo real" a nuestros sistemas de almacenamiento NoSQL.

· Offline: suelen ser Fuentes de Búsqueda, normalmente bases de datos relacionales "mastodónticas" o sistemas de ficheros "gigantescos".

Opinión

Aunque si bien es cierto que he tratado con ambos tipos, las offline son las que más he tratado. El análisis de las fuentes, por mucho tiempo que lleve, será siempre una inversión, una garantía y un seguro de vida del proyecto.

Hasta aquí el post de hoy ;)

¡Nos vemos en la siguiente entrega!