OpenAnalytics (gratis)

El Suceso

Los Implicados

El Impacto

Los Daños Colaterales

La Importancia

Mi opinión

Soy Developer/Coder/Hacker/Programador...

Hace poco estuve en las oficinas de Plain Concepts en Bilbao, estuve con el equipo y hablamos de algunas cosas interesantes sobre temas de #software y sobre todo de #bigdata

Hubo un momento en la charla que empezamos a hablar de la programación y comenté mi experiencia. Hace unos ocho años cuando empecé a trabajar en el mundo de la informática, aunque existían aplicaciones para móviles, ni si quiera se les llama Apps, simplemente eran programas para PDAs o para móviles. En mi caso era programador, y así fui para la sociedad durante cuatro años. Entenderéis a que me refiero con ese "así fui para la sociedad" en unos instantes.

Entré a estudiar el Grado en Ingeniería del Software pero al volver al mundo laboral y buscar ofertas de trabajo de programador , ya no existían apenas ofertas, entonces lo que se llevaba era el término desarrollador.

Y ahí entró mi dilema, porque aunque yo me considero Ingeniero del Software, una de mis habilidades es la programación, pero "el desarrollo" a secas no lo entiendo. He reflexionado varias veces, pensando que se refieren a los tipos hipsters que programan en startups, como el Zuckerberg ese. Ni idea, el caso es que ahora me llamaban desarrollador o arquitecto y cosas raras de ese estilo. Tanto es así, que en una empresa he sido "Desarrollador BigData", creo que más absurdo no podía ser el título del puesto (bueno, "Arquitecto BigData" se le acerca).

El caso es que buscando por internet he visto a blogeros(1,2,3,4) a stackoverflow(que este hilo no dista de alguno de forocoches), gente que hace videos (1,2), foros en los que se desvaría (1,2,3), artículos que intentan explicarlo (1) , todos ellos hablando del tema y me he encontrado con que fuera están aún más segmentados, ¡también existen los coders, los hackers, etc!. Total que ahora tenemos a programadores que ahora se les llama desarrolladores, y a gente que ha sido una u otra cosa y se les denomina coders y a los de seguridad hackers, pero si encima son "buenos" son hackers éticos, buff...¡pero vaya lío!.

Y digo yo, ¿no tiramos todos líneas al final?. Es decir, al final crear software es escribir ficheros con una lógica en su interior. Esta lógica se programa para que realice tareas redundantes, automatizadas y que nos haga la vida más sencilla y salgan productos con diversos fines.

¿Es por un motivo diferenciador económico?, ¿evolución genética de algunos seres humanos?, ¿a caso la palabra programmer/programador estaba muy mal vista?...

Yo me considero Ingeniero del Software, pero cuando toco código para lo que sea me considero programador y ahí se acabó la cosa. Quizás es viejunez (que puede ser), pero en mi opinión creo que es lo más sensato.

Para finalizar, si eres coder, developer o el carajo que te hayan dicho que eres:

"In nomine patris et filii et spiritus sancti", por el poder que me concede Eternia, te renombro a tu estado original: programador/a.

* "Arquitecto BigData" : me he quedado a medio gas antes, pero otro día tocamos el palo de los "arquitectos de algo"(de qué? de edificios VPO? O_o ) o "científicos de algo"(pero que ciencia estudian? el cosmos? O_o ), que eso es otro jardín "mu rico".

La pregunta

Esta es una pregunta controvertida. Recuerdo que Javier Garzás nos la formuló en clase de Procesos Software (hace 3 años ya...) y hubo todo tipo de respuestas.

En esa clase nos dijo los errores que cometíamos al aproximarnos a esa metáfora, que en principio encajaba con el modelo en cascada. También habló de los sobrecostes que estábamos pagando por comparar un esfuerzo físico con un esfuerzo intelectual. Era una buena introducción para meternos con el agilismo.

El caso es que salí convencido de clase (y quien no va a salir convencido de una clase de Javier...) y pasó el tiempo.

Mi experiencia

Pasó el tiempo y estuve de becario en i+d en Big Data en una empresa especializada en Business Intelligence y vi que ellos si que aproximaban en muchas ocasiones a esa metáfora (la de construir edificios) sus desarrollos con mucha inteligencia, esfuerzo y sacrificio.

Después entre en una empresa con el eslogan de "la empresa ágil" y utilizamos metodologías ágiles para gestionar los proyectos y productos. No acababa de funcionar bien pero se hizo lo mejor que se pudo.

Desde entonces en cada sitio al que he ido, he tenido ese día presente en mi memoria y he estado preguntándome cada poco tiempo esa pregunta, reflexionando e intentando ponerme desde cada punto de vista.

Opinión

En mi opinión, en el mundo real existen problemas al rechazar de facto la metáfora de la construcción de edificios con el desarrollo software. Ya me he topado con equipos con baja formación (y ganas) de utilizar debidamente las metodologías ágiles (a todos los niveles, no sólo Scrum sino también XP o TDD/BDD).

Esto llevaba a tener Sprints que en realidad eran mini-cascadas pero con todos los problemas de no llevar debidamente un modelo en cascada: no tener un buen documento de requisitos, el no tener definido los roles, no saber que plan de gestión de software se va a llevar, etc.

Creo que hay mucha gente que sigue al pié de la letra la metáfora, otra tanta que no se la plantea y otra tanta que la rechaza, pero yo después de tenerlo tan presente creo que depende del proyecto, las personas que hay dentro del mismo y los tiempos, puede hacer que tener esa metáfora a nivel de grupo sea positivo o negativo.

A mi me es muy útil tener presente esta metáfora, porque me hace plantearme problemas que de otro modo no vería.

Y tu, ¿qué opinas?.

He cambiado de trabajo en estas últimas semanas y ha vuelto a cambiar gran parte de mi vida. He estado pensando estos últimos días sobre qué me he llevado de esta última experiencia.

Me llevo muchas cosas y por supuesto en diferentes sentidos, como conocimiento, oportunidad de colaborar con personas con experiencia en muchos campos, orientación profesional, etc. Pero sin lugar a dudas la que más me ha dejado huella es la de los compañeros de verdad.

Más allá de las estrellas que hay en los equipos, de los super-técnicos o de aquellos que son muy majos y agradables, lo que más me ha marcado es aquella gente que cuando las cosas no estaban a mi favor, allí estaban conmigo, apoyándome y tendiéndome su mano en todo lo que podían, creyendo siempre en mi potencial.

Mi motivo de cambio ha sido estrictamente profesional para poder crecer y ser mejor cada día, ya que sentía un estancamiento por diversos motivos. Ahora y con unas semanas de por medio veo que no sólo he hecho bien, sino que me siento en la obligación de contar mi experiencia a través del blog y hacer que cambies, estés en la empresa en la que estés y si es que te encuentras en una situación parecida.

Y, ¿a quién me refiero con los compañeros de verdad?:

· Los compañeros de verdad son aquellos que desde el primer día ven en ti lo que eres y lo que puedes llegar a ser.

· Los compañeros de verdad no te tienen miedo.

· Los compañeros de verdad comparten tus victorias, pero sobre hacen que te recuperes cuanto antes de tus derrotas.

· Los compañeros de verdad son los que aunque no te vaya bien en un proyecto, están ahí para tenderte una vía optativa y están dispuestos a hablar con quien sea para cambiar tu rumbo.

· Los compañeros de verdad no son con los que tomas el café, son los que luchan contigo aunque no estén en tu mismo equipo, y ¿cómo se hace eso?, prestándote ayuda en cualquier momento.

· Los compañeros de verdad, y quiero reiterarme, son aquellos que aunque sean "arquitectos" o "CEOs" o "JEFES LÍDERES SUPREMOS DEL MUNDO" se sientan contigo para resolver un problema en el te has atascado y se ponen contigo las horas que hagan falta sin hablarte mal o a disgusto.

· Los compañeros de verdad no son tus amigos o tus enemigos, son tus compañeros.

Esos son los compañeros de verdad.

Ha pasado un año desde que publiqué un post sobre qué era para mi "Big Data", que fue la inauguración oficial de la sección de Big Data, que además ha dado pie al podcast Bigdateando y a muchas otras iniciativas como posts, participaciones en eventos (como OpenAnalitycs), etc y creo que ha llegado la hora de sentarme, reflexionar, sintetizar y contar de nuevo...realmente, ¿Qué es Big Data?

Mi trayectoria laboral

Durante este tiempo he trabajado en tres empresas (Stratebi, Paradigma Tecnológico y Stratio) y he conocido a muchos perfiles, tanto "desarrolladores", "arquitectos", "consultores", "CEO", "CTO", "Gente de Negocio" todo con la coletilla "Big Data". He participado en varios proyectos, unos encargados de gestionar grandes cantidades de datos, otros en visualización de datos, en I+D y en Documentación de Arquitecturas Big Data.

Perfiles que he conocido

Los perfiles que se han incorporado al mundo Big Data son muy variados.

· Por la parte de Ingeniería de Datos:
Para mi los que más importancia han cobrado han sido los de aquellas personas que estaban especializados en el mundo de los datos (bussiness intelligence, dataminning, etc) y que han sido capaces de aprender nuevas formas de hacer las cosas para dar solución a los problemas de tipo "Big Data". No es de extrañar que en las grandes corporaciones dediquen recursos de su departamento de BI a innovar y probar el compendio de tecnologías que rodean a Big Data. También he visto mucho perfil especializado en sistemas distribuidos, que han visto una buena oportunidad para especializarse en bases de datos NoSQL (aunque son pocos).

· Por la parte de Científico de Datos:
He conocido a varias personas que eran especialistas en tecnologías tipo R, Python (con librerías Machine Learning) etc que también han visto una gran oportunidad para explorar herramientas como Spark MLlib, Weka, rHadoop, SparkR, ... Tanto es así que me hice un curso en el que se veían Redes Neuronales, Redes Bayesianas, Machine Learning, Aprendizaje automático ...

· Perfiles Ingenieriles:
Muchas personas que son Arquitectos Java han visto una gran oportunidad para generar productos entorno a las tecnologías Big Data, participando en productos middleware como Stratio o Lambdoop. También gente que venía del mundo Cloud Computing, tipo AWS.

La verdad que no he conocido muchos entusiastas que quisieran aportar un extra, aunque si que es cierto que va aumentando el número de Meet Ups, conferencias, eventos, etc.

Pero realmente, ¿Qué es BigData?

Hay varios tipos de problemas que considero BigData:
1. Problemas con Sistemas Heredados: requieren la realización de una ETL o una ELT con Hadoop o una tecnología Batch Processing similar con MapReduce (Spark, EMR,..). De estos he estado en un proyecto y son muy complejos, ya que si no posees a un especialista de BI en tu equipo que sepa como tratar datos, puede que la migración (la ingesta/obtención) se convierta en todo un infierno.
2. API´s: me encuentro en uno actualmente. Big Data es tener la posibilidad de tratar datos con todo tipo de estructuras y de todo tipo de fuentes, como bien os he dado la chapa en el blog. Pues cuando tienes que extraer información valiosa de esto, se necesita un perfil especializado en múltiples tecnologías, que se deben adecuar a cada proyecto. Por otra parte hay que almacenarlos a modo de histórico. Es decir, un Consultor Big Data Analítico con gran experiencia que lleve este tipo de proyectos.
3. Extracción de patrones, comportamiento...machine learning: problemas con la extracción de información de una plataforma BigData con el objetivo de, por ejemplo, saber que libro te gusta a ti en función de que libro me gusta a mi. Para esto hay tecnologías, algoritmos, etc que ayudan en esta tarea.

Visto esto, podríamos considerar Big Data a un conjunto de problemas relacionados con los datos, ya sea por incapacidad en la extracción de información en volumen, variedad o velocidad, que hasta hace unos años eran muy difíciles de implementar en el mundo real. Visto esto, decir que los que trabajamos con Big Data hoy en España realmente, somos una minoría. De hecho no vas a encontrar tutoriales en castellano en casi ningún lado de instalación de Apache Ambari, y es la punta del iceberg.

El futuro próximo

Se van a necesitar más perfiles especializados en este tipo de tecnologías. No hace falta crear una carrera "Ingeniero Big Data", simplemente hay que especializarse en datos:

· Se necesita (y cada vez más), estadistas que manejen R|Mathlab perfectamente y que a su vez tengan elevados conocimientos informáticos para instalar distribuciones o colaborar en equipos de desarrollo en un lenguaje de programación dado (algo realmente complicado de encontrar).

· Por otra parte se necesitan especialistas en tecnologías orientados a ETLs & Visualización pero con tecnologías relacionadas con Big Data.

· Por último y no hay que olvidar, se van a necesitar personas especialistas en tratamiento (mantenimiento y desarrollo) de grandes volúmenes de datos a nivel de agregación mediante batch processing o de Real Time (Kafka, Storm...) (y las decenas de tecnologías de las que disponemos).

El año que viene haré otro posts y veremos como cambia el panorama. De momento bienvenid@ a aquel que desee adentrarse en este mundo, se lo va a pasar pipa si es un knowmad.

Si tenéis alguna duda, aquí estoy ;)

La instalación y configuracion de Hadoop fue uno de los primeros quebraderos de cabeza a los que tenía que enfrentarse la comunidad cuando quería realizar pruebas.

Han surgido diversos proyectos que pretenden automatizar la instalación de Hadoop y su ecosistema a través de distintas herramientas, managers, administradores, etc. De hecho es uno de los principales puntos fuertes que tienen los Middlewares como Cloudera.

En esta línea surge el proyecto Apache Ambari, que busca facilitarnos la tarea de instalación de Hadoop.

Resumen de Ambari

Con Apache Ambari vamos a poder:

· Proporcionar un Cluster Hadoop
  - Proporciona un instalador (wizard) paso a paso para instalar los servicios de Hadoop a distintos Hosts.
  - Permite configurar los servicios del Cluster Hadoop
· Administrar un Cluster Hadoop
  - Permite iniciar, parar y reconfigurar los servicios de Hadoop
· Monitorizar un Cluster Hadoop
  - Proporciona un dashboard para la monitorización de la salud y el estado de los nodos del Cluster Hadoop
  - Tenemos Glanglia para recolectar métricas
  - Nos ayuda en la instalación de Nagios, para alertarnos y enviarnos emails cuando sea necesario...

· Además tiene una rica API Rest por si queremos hacer algún desarrollo propio.

Soporte de sistemas operativos

· Soportados actualmente:
  - RHEL
  - CentOS 5 y 6
  - OEL
  - SLES

· Próximamente:
  - Ubuntu aún no

Yo voy a utilizar tres máquinas virtuales CentOs 6.5 64 bits para hacer este post. Para ello puedes descargar la imagen desde aquí:

http://ftp.cixug.es/CentOS/6.5/isos/x86_64/CentOS-6.5-x86_64-minimal.iso

Nota: no os olvidéis de poner el adaptador de red a "modo puente" y seleccionar la interfaz de red que tenga internet (wifi, ethernet...).

Instalación - Común a todos los servidores

sudo su

setenforce 0

vi /etc/selinux/config -> SELINUX=disabled

/etc/init.d/iptables stop

Muy importante:

vi /etc/hosts -> introducir una nueva línea: <ip> <nombre_hosts> <nombre_hosts>

Se quedaría algo así:

ssh-keygen

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

yum install openssl

yum install wget

Instalación - Ambari Manager - sólo en el servidor del manager:

ssh root@{hostname_del_nodo}

Esto desde el manager a cada uno de los nodos y desde cada uno de los nodos al servidor del manager:

ssh-copy-id root@{hostname_del_servidor|nodo}

Esto solo en el manager:

cd /etc/yum.repos.d/

wget http://public-repo-1.hortonworks.com/ambari/centos6/1.x/updates/1.5.1/ambari.repo

yum install ambari-server

ambari-server setup

Seguimos las opciones recomendadas (las que vienen entre paréntesis).

ambari-server start

Vamos a nuestra dirección ip del ambari-server en el navegador apuntando al puerto 8080.

Pasos del Instalador
1. Introducimos de nombre y contraseña: admin 


2. Introducimos el nombre del clúster
 3. Seleccionamos la distribución de Hadoop que queremos instalar (esto afectará a las versiones de otras aplicaciones compatibles con Hadoop)
 4. Introducimos los hostnames
 5. Una vez instalado le damos a "next" (es posible que haya algún warning. Verificarlo porque a veces son bugs reconocidos por la comunidad):
 6. Le damos a "Ok" a la confirmación
 7. Seleccionamos las aplicaciones que queramos instalar
 8. Asignamos los nodos (leed que significa que sean "clients")
 9. Le damos a deploy
10. Aparecerá el instalador

 11. Una vez completado le damos "Complete"


Más adelante tengo pensado hacer una serie de Screencast sobre Spark, Cassandra, Hadoop, Instaladores, etc.

Espero que os sea de mucha utilidad. Si tenéis cualquier duda, comentad en este mismo post.

Ayer día 22 de mayo de 2014 asistí como espectador y como ponente a uno de los eventos más importantes sobre datos de España, el OpenAnalytics.

En principio iba a asistir como espectador a ver a José Hernández de Isthsari (único partner de DataStax en España), al ponente de MongoDB, Jorge Úbero de bigdata4success.com que nos hablaría sobre datos geospaciales en Big Data y Santiago B. de Synergic Partners (Hadoop + R).

Ignacio Bustillo, Director de OpenAnalytics y Bussiness Analytics Consultant de Stratebi, se puso en contacto conmigo porque el ponente de MongoDb se había confundido de fecha y no podía dar la charla. Me parecía una buena oportunidad para que la comunidad conociera Spark de viva voz de un técnico y en menos de dos días lo preparé.

· El evento

Medialab-prado.es es un espacio genial para compartir conocimiento, los medios técnicos son perfectos y los responsables nos tendieron la mano desde el minuto cero.

La sala es muy grande (unas 200 personas asistieron y había espacio para 100 más por lo menos), había conexión wifi y las sillas eran cómodas.

Para próximos eventos si que es cierto que es recomendable que haya una parte de Networking, a través de un bar concertado o de una sala con algo para picar :P

· La organización

· La entrevista de Autentia

· Las charlas

Cassandra - DataStax - Isthari

Santiago Basaldúa

Mi charla de Spark

· Los amigos

Instalación, configuración de Hadoop 1.0.4 en Pseudo-distribuido.

A petición de un lector del blog escribo este post consistente en descargar, instalar y configurar en pseudo-distribuido Hadoop 1.0.4, la versión compatible con Spark 0.9.1 y así poder seguir trabajando los tutoriales de Spark.

Requisitos Previos

· Ubuntu 12.04 en adelante
· Oracle JDK 7

Descargar & Instalar

Es muy sencillo. Simplemente hay que irse a las versiones anteriores de Hadoop (ya que la más reciente es la 2.4.0 y no nos interesa para utilizar con Spark) y buscamos la versión 1.0.4. Después seleccionamos la versión de descargarnos el binario tar.gz y listo.

Para ahorraros el tiempo sólo tenéis que descargar Hadoop 1.0.4 desde aquí.

Configurar en Pseudo-Distribuido

1. Abrimos un terminal y mostramos el nombre de nuestra máquina mediante el siguiente comando:

hostname

Lo copiamos en el portapapeles / en un sitio que podamos copiarlo posteriormente. Lo llamaré en adelante [TU_HOSTNAME].

2. En la carpeta conf del directorio de hadoop-1.0.4 vamos a modificar los archivos:
· core-site.xml: opciones de configuración del sistema de hadoop.
· hadoop-env.sh: configuración de las variables de entorno de hadoop.
· hdfs-site.xml: configuración de HDFS.
· mapred-site.xml: configuración todo lo relacionado con map-reduce (jobtracker,tasktrackers...).
· masters: lugar donde irán nuestros nodos maestros.
· slaves: lugar donde irán nuestros nodos slaves. Como la instalación es pseudodistribuida, pondremos tanto en el fichero masters como en el slaves [TU_HOSTNAME].

Core-site.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
     <property>
         <name>fs.default.name</name>
         <value>hdfs://[TU_HOSTNAME]:9000</value>
     </property>
</configuration>

Hadoop-env.sh

Hdfs-site.xml

Sustituimos por:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
     <property>
         <name>dfs.replication</name>
         <value>1</value>
     </property>
</configuration>

Mapred-site.xml

Sustituimos por:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
     <property>
         <name>mapred.job.tracker</name>
         <value>[TU_HOSTNAME]:9001</value>
     </property>
</configuration>

Masters

Sustituir por:

[TU_HOSTNAME]

Slaves

Sustituir por:

[TU_HOSTNAME]

Por último, comunicación ssh:

Antes de continuar tenemos que saber que para que haya comunicación entre el maestro de Hadoop y los esclavos tenemos que tener como dicen por ahí "passwordless" entre ellos. Si queremos conectarnos entre localhost y localhost tendremos que superar esta barrera:

1. Generamos la clave privada, para ello ejecutamos en el terminal:

ssh-keygen

Nota: presionad enter hasta que deje de preguntar. Por defecto se guardará en el directorio ~/.ssh con nombre id_rsa.pub

2. Esta clave la copiamos como parte pública a ~/.ssh/authorized_keys. Primero instalamos OpenSsh-server si no lo tenemos instalado:

sudo apt-get install openssh-server

ssh-copy-id [TU_NOMBRE_USUARIO]@[HOSTNAME_DE_TU_MÁQUINA]

Ejemplo:

ssh parallels@parallels-Parallels-Virtual-Platform

Escribimos yes y si vamos a la carpeta ~/.ssh, veremos que se ha generado un fichero llamado authorized_keys.

Iniciar/Parar el cluster

Bienvenid@s al cuarto capítulo sobre Apache Spark.



Daremos un repaso al API de Spark, utilizaremos el Shell Interactivo para ver sus componentes clave y veremos en que consisten los principales conceptos básicos para poder escribir programas eficientemente. Aviso que hoy no nos vamos a meter en Eclipse todavía, pero en el siguiente ya si que haremos los primeros programas. Necesitaremos Maven por si queréis ir pensando en instalarlo.

Recomiendo que sigáis los posts anteriores y que dejéis instalado Spark en Standalone para poder seguir los pasos que aquí mencionaré.

Este post pertenece a la serie de Spark:


Sin más que decir por mi parte, comenzamos.

Resumen de los tres primeros posts

A alto nivel podríamos decir que las aplicaciones Spark consisten en un Driver Program que ejecuta la función principal que el usuario haya creado y que a su vez ejecuta varias operaciones paralelas en el cluster.

Primera abstracción importante: RDD

Los RDDs son una colección de elementos particionados a lo largo de los nodos del cluster con los que se puede operar en paralelo. Los RDDs se pueden crear a partir de un archivo del sistema de ficheros de Hadoop (o de cualquier otro archivo soportado por el sistema de Hadoop), o de una colección de Scala existente a través del driver program, pudiendo realizar transformaciones sobre los mismos. Los usuarios además, pueden decir a Spark que persista un RDD en memoria, permitiendo reusar eficientemente las operaciones que se realizan en paralelo. Por último, los RDD  se recuperan automágimanete de los fallos en los nodos (recordemos el "lineage").

Segunda abstracción importante: Variables compartidas

Requisitos previos

Shell interactivo

Cómo paralelizar colecciones

Cómo utilizar los Datasets de Hadoop

Operaciones con RDDs

Transformations

Actions

Persistencia de los RDD

Y la pregunta sería: ¿Cuál Storage Level elijo?

Variables compartidas

Variables Broadcast

Variables Accumulators

Alguna cosa más