Archivo de la etiqueta: python

Big Data: la posición más difícil de cubrir en España

17 marzo, 2018 Álex Rayón 104 comentarios

El pasado 7 de marzo, Cinco Días, publicaba esta noticia: «Big data, el perfil más difícil de cubrir en España«. Según el artículo y sus fuentes, las profesiones asociadas con las tecnologías de Big Data son las más difíciles de cubrir. Su fuente principal es el informe EPYCE 2017: Posiciones y Competencias más demandadas, elaborado por EAE Business School junto con la Asociación Española de Directores de Recursos Humanos (AEDRH), la CEOE, el Foro Inserta de la Fundación Once y Human Age Institute.

Posiciones más difíciles de cubrir en España (Fuente: Cinco Días)

En un blog como éste, donde hablamos tanto del paradigma del Big Data y sus múltiples implicaciones en nuestras sociedades, naturalmente, no podíamos dejar sin sacar esta noticia. Llevamos años ya formando perfiles de Big Data en nuestros Programas de Big Data en Bilbao, Donostia y Madrid.

El informe original contiene aún más información. Aspecto que recomiendo revisar, para que se entienda bien no solo la metodología, sino los contenidos (datos) analizados. Miren por ejemplo esta gráfico que adjunto:

Con un nivel de detalle mayor, lo que vemos es que no solo la parte tecnológica (que siempre está en el top de los ranking de bajo desempleo), sino también la ciencia de datos (que son nuestras dos patas fundamentales en nuestros programas), son las más demandadas. En general, hay numerosas profesiones técnicas demandadas en todo el ranking y el informe. Lo cual nos viene a confirmar que efectivamente estamos viviendo una transformación tecnológica y digital en múltiples planos.

Lo que parece que viene a confirmar este informe es que estamos viviendo cierta brecha entre los perfiles que demandan las empresas y lo que realmente se dispone luego en el mercado de trabajo. Parece real esa velocidad a la que se está efectuando esta transformación digital de la sociedad, que está provocando que muchos perfiles no puedan seguirla, y no les dé tiempo a actualizar sus competencias y habilidades. El Big Data, la revolución de los datos, parece que ha venido para quedarse.

No obstante, en relación a todo esto, creo que cabría introducir tres elementos de reflexión. A buen seguro, a cualquier lector o lectora de estas estadísticas, le interesará conocer qué hay más allá de estas gráficas. Básicamente, porque la gestión de expectativas laborales en los programas formativos, creo que debe caracterizarse por la honestidad, para que luego no produzca frustraciones. Estos tres puntos son: (1) Descripción de «supermanes» y «superwomanes» en los puestos de trabajo de las empresas; (2) el concepto «experiencia» en las organizaciones; (3) el talento cuesta dinero.

En relación al (1), darse una vuelta por Linkedin suele ser muy ilustrativo a estos efectos. Las empresas, cuando buscan perfiles «de Big Data» (así en genérico y abstracto), suelen hacerlo solicitando muchas habilidades y competencias que me parece difícil que lo cubra una misma persona: conocimientos de programación (R, Python, Java, etc.), conocimiento de los frameworks de procesamiento de grandes volúmenes de datos y sus componentes (Spark y Hadoop, y ya de paso Storm, Hive, Sqoop, etc.), que sepa administrar un clúster Hadoop, que sepa cómo diseñar una arquitectura de Big Data eficiente y óptima, etc. Una persona que en definitiva, dé soporte a todo el proceso de un proyecto de Big Data, desde el inicio hasta el final. Este enfoque es bastante complicado de cubrir: para una persona manejar todo eso es realmente complicado, dado que no solo los códigos de pensamiento, sino también las habilidades, no suelen estar relacionadas.

En cuanto al (2), que se pida para estos puestos experiencia, me parece un poco temeroso. Estamos hablando de un paradigma que irrumpe con fuerza en 2013. Por lo que estar pidiendo experiencias de más de 2-3-4 años, es literalmente imposible de cubrir. Y menos en España donde todavía no hay tantas realidades en proyectos de Big Data como se cree. ¿Quizás la falta de cobertura de vacantes tenga que ver precisamente con esta situación? Por ello sería bueno saber realmente qué es lo que no están encontrando: ¿el puesto necesario? ¿el puesto definido por las empresas? ¿las expectativas mal gestionadas? Quizás sería bueno, y los empleadores bien saben que siempre les digo, que la formación es un buen mecanismo para poder prescindir de este factor de experiencia. Ahora mismo estamos colaborando con importantes empresas y organizaciones que están formando a varios perfiles a la vez porque son conocedores del límite de la experiencia del que hablamos.

Por último, en cuanto al (3). Hay una expresión inglesa que me gusta rescatar cuando hablo de esto: «You get what you pay«. Una expresión muy común también últimamente en el sector tecnológico. No podemos pretender pagar salarios bajos y que luego tengamos esos supermanes y superwomanes que decía anteriormente. Tenemos que ser coherente con ello. Nuestro conocimiento tecnológico, el talento técnico que formamos en España, está muy bien valorado en muchos lugares de Europa (Dublin, Londres, Berlín, etc.) y el mundo (San Francisco, New York, Boston, etc.). Es normal que en muchas ocasiones este talento se quiera ir al extranjero. ¿Pudiera estar aquí también parte de la explicación de la dificultad para cubrir puestos?

Un algoritmo que escribe texto y nos entretiene

25 enero, 2017 Álex Rayón 1 comentario

Quizás ya hayan leído alguna noticia al respecto. Suelen ser noticias bastante «trágicas» o «extremas». Que, como siempre, difícilmente llegará a darse. Aunque sí marcan tendencia, y sobre todo generan conversación. Me refiero a noticias que hablan de software, de algoritmos, que escriben por sí solos noticias, artículos de deporte o incluso sentencias o textos de defensa de acusados. IBM Watson, incluso ha creado ya un trailer:

Este tipo de piezas de software, están dando un paso más allá, y están empezando a entrar en el mundo del entretenimiento. En cierto modo, ese trailer creado por IBM Watson no deja de ser una primera aproximación a cómo tratar de crear contenido que nos pueda entretener a los humanos. Pero, creado, de manera automática. Es decir, sin dedicar tiempo de creatividad y entendimiento del cerebro humano para ello. Esto sí que es nuevo. Hasta la fecha habíamos tratado de aproximarnos a ello, pero no conseguido.

Y dado que el mercado del entretenimiento es muy jugoso, ya hay mucha gente haciendo cosas. En este artículo, podéis ver como Max Deutsch, utilizando un modelo de LSTM Recurrent Neural Network (algoritmo de aprendizaje cognitivo), y empleando como datos de entrada los textos de los primeros cuatro libros de Harry Potter, fue capaz de producir un nuevo capítulo. El capítulo lo pueden encontrar en el enlace que ponía antes. Hizo lo mismo para producir un capítulo de la serie Silicon Valley de HBO o para guiones para Expediente X. Twitter, para mucho del texto automático que genera (sí, mucho del que leeis), emplea cadenas de Markov. Es decir, empleando los textos que se mueven en dicha red, analiza qué palabras son más probables de aparecer de seguido a otras en el material fuente. El escritor/autor, poco tiene que decir. Las cadenas de Markov hacen todo por él o ella.

Prueben ustedes mismos. Navegando un poco por la red, he encontrado en GitHub este algoritmo creado por Jamie Brew, escrito en Python, y que permite entrenar modelos a partir de textos que le demos. Si quisiéramos crear cuentos para nuestros hijos, podéis introducir en la carpeta de textos aquellos con los que queráis que el software aprenda sus estructuras, para que sea capaz, a partir de ellas, de construir nuevas historias.

Código en Github de Jamie Brew para producir textos (Fuente: https://github.com/jbrew/pt-voicebox)

Este algoritmo me ha llamado la atención porque utiliza un enfoque híbrido algoritmo + humano. Por eso mismo decía al comienzo del artículo que suele ser difícil quedarse en un extremo o en otro. Brew visualiza estos algoritmos como un soporte a la creación humana. Que es, por cierto, como creo que más valor cogen estos algoritmos. En lugar de generar directamente las palabras, sugiere una lista de palabras, para que el creador elija la que más le gusta. Este modelo, en cierto modo no deja de ser diferente a cómo funcionamos los que escribimos o creamos en la vida real. Que nos quedamos pensando cuál es la mejor opción a seguir mientras vamos escribiendo. Es decir, es un proceso gradual que se nutre de pasos anteriores. Como las cadenas de Markov, que por eso son tan buen apoyo.

Este modelo de aproximación híbrido me gusta porque no hace un «commodity» la creatividad humana. Algo nos tiene que quedar a nosotros 🙂 Y, de hecho, ese «momento Eureka» que solemos tener al crear, es difícil de automatizar en un software. En un algoritmo. Por eso mismo, un modelo en el que en lugar de externalizar la creatividad, tenemos un algoritmo que nos ayuda en la parte más mecánica (darnos un conjunto de «mejores» alternativas a elegir para ir creando las diferentes piezas del puzzle final). Siempre habrá un humano por detrás, una mano artística.

De esta manera, no vemos el mundo de la inteligencia artificial, de los modelos como algo que compite contra nosotros. Que es lo que llevo diciendo mucho tiempo. Básicamente, porque esos discursos catastróficos o triunfalistas, ya digo serán luego difíciles de ser implementados. El software es una herramienta que empleamos para hacer mejor nuestro trabajo. Para crearlo, necesitamos saber muchas cosas (tecnología, estadística, enfoque a aplicación -negocio-). Pero la creatividad, de momento, no hemos conseguido externalizarla. Y si queremos hacer cosas de calidad, es probable que ese monopolio artístico siga siendo del ser humano.

¿Qué lenguaje debemos utilizar para Data Science?

16 octubre, 2016 Álex Rayón 3 comentarios

En este blog, ya hemos hablado con anterioridad de diferentes herramientas para emprender proyectos de analítica. Fue en esta entrada, comparando más allá a nivel de herramienta, cuando comparábamos R, Python y SAS, que son sobre las que pivotamos en nuestros Programas de Big Data.

El mundo de la analítica está avanzando a la velocidad de la luz, por lo que es importante que escribamos artículos volviendo a esa pregunta original sobre ¿Qué lenguaje utilizar para Data Science? No es una pregunta sencilla, porque las opciones existentes no son pocas.

La pregunta se vuelve más complicada aún en contextos como el nuestro. Tenemos que enseñar y aprender desde cero la disciplina de Data Science. Y una pregunta muy recurrente de parte de nuestros alumnos de Bilbao, Donostia y Madrid, es, ¿por qué lenguaje empieza para arrancar en este mundo del Big Data?

Son muchas los lenguajes que ofrecen las capacidades para ejecutar operaciones de análisis de datos de una manera más eficiente que los lenguajes tradicionales (C++, C, Java, etc.). Entre ellos, destacan algunos sospechosos habituales, y otros que están emergiendo con fuerza: R, Python, MATLAB, Octave y Julia. Éste es el menú en el que tenemos que elegir; decisión, como suele pasar con estas cuestiones, no sencilla. Dejo fuera de esta comparación soluciones analíticas como SAS, Stata o Excel, básicamente, porque no están orientadas a nivel de «lenguaje de programación», sino a nivel de herramientas.

En esta entrada, y para poder encontrar un ganador, se han comparado los lenguajes en varias dimensiones: velocidad de ejecución, curva de aprendizaje requerida, capacidades de ejecutar acciones de analítica de datos, soporte a la visualización, entornos de desarrollo, facilidad de integración con otros lenguajes/aplicaciones y las oportunidades de trabajo existentes.

Obviamente, debemos notar que las calificaciones otorgadas en cada dimensión son la opinión de Siva Prasad, la persona que lo ha elaborado. Por lo tanto, creo que no debemos tampoco sacar conclusiones exclusivamente de ello. Creo que lo más ilustrativo del caso es fijarse en que en función de cuál sea el objetivo y la necesidad concreta, hay diferentes opciones que explorar.

Lo que sí me parece igualmente interesante, son la utilidad que puede tener en función del punto en el que cada uno se encuentre. El autor, en su entrada, destaca que:

If you are a graduate student, it’s good to start with Python

Si somos estudiantes de Grado, que estamos arrancando, sugiere emplear Python.

If you are a research scholar, good to start with R and explore Octave

Si estamos por la vía de la investigación/doctorado, sugiere el empleo de R y/o Octave.

If you are an employee, I suggest to master both Python and R

Si eres una persona ya trabajando en la industria, parece que las mejores apuestas pasan por Python y R.

If you are tech enthusiast and love exploring/learning new things, you can learn Julia

Si eres un entusiasta tecnológica y te gusta explorar/aprender nuevas cosas, métete con Julia (yo, estoy en esta etapa, haciendo modelos de optimización con Julia, que es realmente potente e interesante).

If the data needs to try several different algorithms, choose R

Si necesitamos probar diferentes algoritmos para tratar el conjunto de nuestros datos, prueba con R.

If you need to use data structures and integrate with external applications, use Python

Si tenemos que utilizar muchas estructuras de datos e integrar los mismos con aplicaciones externas, probemos con Python.

Para gustos están los colores. En definitiva, que no consideremos esto como conclusiones a escribir en un libro. Pero sí por lo menos, para orientarnos, y tener primeras aproximaciones a la ciencia de datos, Data Science, así como las opciones que abre cada uno de ellos. Disfruten de todos ellos 🙂

R vs. Python para el análisis de datos en proyectos de Big Data

27 marzo, 2016 Álex Rayón 7 comentarios

Cuando abrimos este blog, dedicamos una entrada a comparar diferentes herramientas analíticas. En su día, hablamos de SAS, R y Python, mostrando la experiencia que tenía en el manejo de las tres de nuestro profesor Pedro Gómez. Desde entonces, han aparecido varias noticias y reflexiones comparando especialmente dos de ellas: R y Python. DataCamp publicó hace unos meses la infografía que ponemos al final de este artículo comparando ambas.

El análisis de datos, obviamente, es una parte nuclear de cualquier proyecto de Big Data. El análisis de los diferentes flujos de datos y su combinación para obtener nuevos patrones, tendencias, estructuras, etc. se puede realizar con diferentes herramientas y lenguajes de programación. La elección de estas últimas es una cuestión en muchas ocasiones de gustos, de preferencias, pero también en otras ocasiones, objeto de detallados análisis.

La infografía que hoy nos acompaña agrega múltiples fuentes que comparan R y Python. Por eso mismo, nos ha resultado interesante para compartir con vosotros. Compara ambos lenguajes desde una perspectiva de la Ciencia de Datos, o Data Science, disciplina que ya describimos en una entrada anterior. Las debilidades y fortalezas que se muestran, así como sus ventajas y desventajas, puede ayudaros a la hora de seleccionar el mejor lenguaje de programación para vuestro problema dado. Y es que, como solemos decir, cada proyecto, cada problema, cada contexto de empresa, es diferente, por lo que dar sugerencias absolutas suele resultar complicado.

Dado que suele ser un factor bastante determinante, de entre las múltiples características para la toma de decisión, cabe destacar que ambos lenguajes gozan de una amplia comunidad de desarrollo. En este sentido, ninguna diferencia. Quizás lo que mejor caracteriza a cada uno de los lenguajes, es la frase que destacan los que elaboraran la infografía:

“Python is often praised for being a general-purpose language with an easy-to-understand syntax and R’s functionality is developed with statisticians in mind, thereby giving it field-specific advantages such as great features for data visualization”

Os dejamos con la infografía para que podáis por vuestra seguir conociendo mejor cada uno de los dos: R vs. Python o Python vs. R. Seguiremos de cerca la evolución de ambos.

Eligiendo una herramienta de Analítica: SAS, R o Python

23 octubre, 2015 Álex Rayón 14 comentarios

(Artículo escrito por Pedro Gómez Tejerina, profesional del sector financiero, y profesor de nuestro Programa de Big Data y Business Intelligence)

Probablemente si estás leyendo este blog tengas un problema analítico que quieras resolver con datos. Es posible también que tengas unos conocimientos de estadística que quieras poner en práctica, así que es hora de elegir una herramienta analítica. Así que vamos a intentar orientaros en la elección, aunque las tres herramientas de analítica nos van a permitir hacer en general los mismos análisis:

Conocimientos previos de programación. Si sabes programar y vienes de un entorno web, probablemente Python sea el más fácil de aprender. Es un lenguaje más generalista que los otros dos y solamente tendrás que aprender el uso de las librerías para hacer análisis de datos (Pandas, Numpy, Scipy, etc.). Si no es el caso y lo tuyo no es programar, SAS es más fácil de aprender que R, que es el lenguaje más diferente de los tres, dado su origen académico-estadístico.
Herramientas User Friendly y GUI: Tanto SAS (SAS Enterprise Guide, SAS Enterprise Miner, SAS Visual Analytics) como R (Rattle, RStudio, Rcommander) tienen buenas interfaces visuales que pueden resolver problemas analíticos sin tener la necesidad de programar. Python dispone de menos (Orange), aunque dispone de una buena herramienta de enseñanza: los notebooks.
Coste de las herramientas. SAS es un software comercial y bastante caro. Además el uso de cada una de sus capacidades se vende por paquetes, así que el coste total como herramienta analítica es muy caro. La parte buena es que tienes un soporte. Por el contrario, tanto R como Python son gratuitos, si bien es cierto que empresas como Revolution Analytics ofrecen soporte, formación y su propia distribución de R con un coste bastante inferior a SAS. Normalmente sólo las grandes empresas (bancos, compañías telefónicas, cadenas de alimentación, INE, etc.) disponen de SAS debido a su coste.
Estabilidad de la herramienta. Al ser un software comercial, en SAS no hay problemas de compatibilidad de versiones. R al tener un origen académico ofrece distintas librerías para hacer un mismo trabajo y no todas funcionan en versiones anteriores de R. Para evitar estos problemas en una gran empresa recomendaría utilizar alguna distribución comercial de Revolution Analytics por ejemplo.
Volumen de datos. Las única diferencia es que SAS almacena los datos en tu ordenador en vez de en memoria (R), si bien es cierto que las 3 tienen conexiones con Hadoop y las herramientas de Big Data.
Capacidad de innovación. Si necesitas utilizar las últimas técnicas estadísticas o de Machine Learning SAS no es tu amigo. Es un software comercial que para garantizar la estabilidad de uso entre versiones retrasa la incorporación de nuevas técnicas. Aquí el líder es R seguido de Python.

Conclusión: no es fácil quedarse con una herramienta de analítica y las personas que trabajamos en grandes compañías estamos habituados a trabajar con varias. SAS ofrece soluciones integradoras a un coste elevado. R tiene muchas capacidades de innovación debido a su origen y Python tiene la ventaja de ser un lenguaje de programación generalista que además puede servir para hacer Data Mining o Machine Learning. La elección dependerá de lo que estés dispuesto a pagar y tus necesidades específicas. Yo tengo la suerte o desgracia de trabajar en una gran empresa, así que dispongo de las 3.

Tendencias en lo que a demanda de perfiles con conocimiento de R, SAS y Python se refiere (Fuente: http://www.statsblogs.com/2013/12/06/sas-is-abandoned-by-the-market-for-advanced-analytics/)

Más información en:

http://www.analyticsvidhya.com/blog/2014/03/sas-vs-vs-python-tool-learn/
http://blog.datacamp.com/r-or-python-for-data-analysis/

Deusto Data