Big Data y Hadoop van de la mano

El mercado del almacenamiento y procesamiento de grandes volúmenes de datos está directamente ligado a Hadoop, un framework open-source que pertenece a la fundaciónApache.

Con el fin de facilitar la configuración e instalación de Hadoop, existen diversas distribuciones, tales como Cloudera o Hortonworks entre otras.

Cloudera vs Hortonworks

La distribución de Cloudera (CDH) fue la primera en aparecer en el mercado, combinando Big Data y Hadoop. CDH no solo incluye el núcleo de Hadoop (HDFS, MapReduce…) sino que también integra diversos proyectos de Apache (HBase, Mahout, Pig, Hive, etc.). CDH es 100% open-source, y cuenta con una interfaz gráfica propietaria, Cloudera Manager, para la administración y gestión de los nodos del clúster Hadoop. La descarga es totalmente gratuita. No obstante, también cuenta con una versión empresarial, que incluye una interfaz más sofisticada. Cloudera recientemente ha estrechado vínculos tanto con IBM como conOracle. En la siguiente ilustración, se muestra la arquitectura de la distribución CDH:

Distribución Cloudera: CDH, vía: http://www.cloudera.com

Otra alternativa al Big Data y Hadoop es Hortonworks. A diferencia de Cloudera, Hortonworks es una de las distribuciones más recientes de Hadoop (HDP). Al igual que CDH, HDP es totalmente open-source, incluye las herramientas que forman el núcleo de Hadoop, y por supuesto también incorpora diferentes proyectos open-source de Apache. Para más detalles, la siguiente ilustración muestra la arquitectura de HDP:

 

Distribución Hortonworks: HDP, vía: http://hortonworks.com

 

Una de las diferencias más notables respecto a Cloudera es la integración de Apache Ambari como herramienta de gestión y administración del clúster. A diferencia del Cloudera Manager, Apache Ambari no es propietario.  Sin embargo, el nivel de madurez de la herramienta de gestión de Cloudera es superior a la de Hortonworks. Como partners más cercanos, cuenta con Microsoft e Informatica.

Considerando la importancia de las tecnologías Big Data y Hadoop, el grupo de Telemática de Mondragon Unibertsitatea está inmerso en el desarrollo de dichas tecnologías con el fin de mejorar la eficiencia energética en procesos industriales.

Hadoop tiene ya una intensa historia, y sólo acaba de nacer. No en vano, supo hacer suyo el lema de "divide y vencerás" como ingeniosa y casi milagrosa solución a un problema que parecía irresoluble: gracias a una solución basada en un sistema de archivos distribuidos, consiguió procesar tremendas cantidades de datos que crecían exponencialmente, hasta convertirse en un ecosistema que engloba distintos productos de gran popularidad que hoy se utilizan para almacenar, procesar y analizar datos masivos.

Mucho ha llovido desde sus inicios como diseño a la medida de las necesidades de Google, y ahora son muchos los sectores y situaciones tecnológicas en las que Hadoop puede ser realmente útil para un sinfín de usos, entre otros la inteligencia empresarial (BI), el almacenamiento e integración de datos.

Implementado a partir del código abierto Apache Hadoop o mediante packs que ofrecen muy distintos distribuidores, se trata de un sistema que se puede implementar sobre hardware a un precio comparativamente más bajo que otras plataformas Data Warehouse (DW).

Un menor coste

Al estar basado en un gran número de pequeños ordenadores, cada uno de ellos procesa una parte de la información pero actúan de forma coordinada. De este modo, el resultado es una ventaja comparativa sin competencia: funciona como un ordenador de enormes dimensiones.

Son numerosas sus ventajas con respecto a los sistemas clásicos en almacentamiento y procesamiento de datos pues, al no depender de la cara infraestructura de éstos, permite abaratar costes gracias al uso de servidores estándar, con la posibilidad de ampliarse sin límite.

Dar valor a los grandes datos

El bajo coste, su rápido retorno de la inversión, su robustez, tolerancia a fallos y su ampliación sin límites hace posible una nueva BI basada en el los grandes datos. Con Hadoop, el océano de datos de Big Data es asible. Se abre, pues, una nueva era. Como llegó a decir Leonardo da Vinci, más que una época de cambios, estamos ante un cambio de época pues, sin duda, Big Data y Hadoop representan un gran hito para empresas, organizaciones y sociedad, con un impacto tremendo en todos los órdenes de la sociedad.

Liberar la carga de los DW

Otra ventaja definitiva, su capacidad para adaptarse a los entornos tradicionales de DW, compuestos por datos estructurados y relacionales. ayudando a obtener valor de BI supliendo esta carencia. A esto hay que añadir la posibilidad de "descargar el mayor número posible de tareas en HDFS y otras tecnologías Hadoop, pues son menos caras, con el resultado de liberar los recursos de DW para cargas de trabajo en las que pueden ofrecen un rendimiento superior", apunta Philip Russorn, director de investigación de Gestión de Datos en The Data Warehousing Institute (TDWI).

Russorn también subraya la importancia de los usos menos conocidos para Hadoop, entre otros la gestión de "datos que proceden de dispositivos de detección, las aplicaciones de análisis avanzado más antiguas que necesitan grandes muestras de datos, ya sea la segmentación de las bases de clientes, la detección del fraude o el análisis del riesgo", concluye. 

Mucho se habla este año de alternativas a Hadoop para manejar datos masivos. Sin duda la que más espectación está levantando es el proyecto Apache Spark, cuyos seguidores crecen como la espuma. ¿Desplazará Spark al otrora omnipresente Hadoop?

Vamos a hacer una revisión, tomando información entre otras* del sitio oficial de Apache Spark. Recomiendo encarecidamente revisar los enlaces que incluyo abajo si queréis ahondar en aspectos técnicos, pues se han hecho algunos estudios muy completos ya acerca de Spark.

Originalmente desarrollado como un proyecto de investigación en AMPLab de la UC Berkeley, el proyecto ha alcanzado el estatus de la incubadora de Apache en junio de 2013. Se trata de un framework de computación distribuida open source.

Databricks, la empresa fundada para apoyar Spark recaudó recientemente $ 14M del VC Andreessen Horowitz. A su vez Cloudera ha decidido apoyar plenamente Spark. Para muchos esta plataforma híbrida es la próxima Big Thing.

Cuál es la mejora?

• Rapidez: Spark es capaz de ejecutar los trabajos por lotes de procesamiento de entre 10 a 100 veces más rápido que el motor MapReduce acuerdo con Cloudera, principalmente mediante la reducción del número de escrituras y lecturas de disco.
• Real time batch procesing: En lugar de simplemente procesar un lote de datos almacenados, como es el caso de MapReduce, Spark también puede manipular los datos en tiempo real utilizando Spark Streaming.
  Esta capacidad permite que las aplicaciones pasen datos a través de una función de software – por ejemplo, para llevar a cabo análisis al mismo tiempo que los datos son recogidos.
• Alta tolerancia a fallos: En lugar de la persistencia o la existencia de checkpoints en resultados intermedios, Spark recuerda la secuencia de operaciones que llevó a un determinado conjunto de datos. Así que cuando falla un nodo, Spark reconstruye el conjunto de datos basado en la información almacenada. Esto proporciona una cierta estabilidad que permite que no se caida todo un proceso cuando aparecen fallos en alguno de los nodos.
• Facilidad de uso: La implementación tanto de stream como de batch processing en la parte superior de Spark podría eliminar gran parte de la complejidad que las organizaciones se están encontrando en las abstracciones de MapReduce, y permitirá simplificar el despliegue, mantenimiento y desarrollo de aplicaciones.
• Conectividad, multiplataforma: Un conjunto de APIs para el motor de ejecución de Spark están disponibles en Java, Python y Scala, lo que permite a los desarrolladores escribir aplicaciones que se pueden ejecutar en la parte superior de Spark en estos idiomas. Spark puede interactuar con los datos en el HDFS (Sistema de archivos de Hadoop), la base de datos HBase Hadoop, el almacén de datos Cassandra y varias otras capas de almacenamiento.

In-Memory: la próxima revolución del Big Data nos viene a la memoria

Spark está diseñado para ejecutarse por defecto en memoria, por lo que los desarrolladores pueden escribir algoritmos iterativos sin escribir un conjunto de resultados después de cada pasada. Esto permite un alto rendimiento en la analítica avanzada, mediante técnicas como la regresión logística.

Es un sistema 100% compatible con Hadoop2.0 y su interconexión es a través de YARN

Los datos con ruido y otros desafíos a los que se enfrenta Big Data

En savoir plus sur http://www.siliconweek.es/noticias/los-datos-con-ruido-y-otros-desafios-los-que-se-enfrenta-big-data-68373#XU6DRxiEIitM28bP.99

How To Get Started with Cascading and Hadoop on Hortonworks Data Platform

The power of a well-crafted speech is indisputable, for words matter—they inspire to act. And so is the power of a well-designed Software Development Kit (SDK), for high-level abstractions and logical constructs in a programming language matter—they simplify to write code.

In 2007, when Chris Wensel, the author of Cascading Java API, was evaluating Hadoop, he had a couple of prescient insights. First, he observed that finding Java developers to write Enterprise Big Data applications in MapReduce will be difficult and convincing developers to write directly to the MapReduce API was a potential blocker. Second, MapReduce is based on functional programing elements.

With these two insights, Wensel  designed the Java Cascading Framework, with the sole purpose of enabling developers to write Enterprise big data applications without the know-how of the underlying Hadoop complexity and without coding directly to the MapReduce API. Instead, he implemented high-level logical constructs, such as Taps, Pipes, Sources, Sinks, and Flows, as Java classes to design, develop, and deploy large-scale big data-driven pipelines.

Sources, Sinks, Traps, Flows, and Pipes == Big Data Application

 At the core of most data-driven applications is a data pipeline through which data flows, originating from Taps and Sources (ingestion) and ending in a Sink (retention) while undergoing transformation along a pipeline (Pipes, Traps, and Flows). And should something fail, a Trap (exception) must handle it. In the big data parlance, these are aspects of ETL operations.

The Cascading SDK embodies these plumbing metaphors and provides equivalent high-level Java constructs and classes to implement your sources, sinks, traps, flows, and pipes. These constructs enable a Java developer eschew writing MapReduce jobs directly and design his or her data flow easily as a data-driven journey: flowing from a source and tap, traversing data preparation and traps, undergoing transformation, and, finally, ending up into a sink for user consumption.

Now, I would be remiss without showing the WordCount example, the equivalent of the Hadoop Hello World, to illustrate how these constructs translate into MapReduce jobs, without understanding the underlying complexity of the Hadoop ecosystem. That simplicity is an immediate and immense draw for a Java developer to write data-driven Enterprise applications at scale on top of the underlying Hortonworks Data Platform (HDP 2.1). And the beauty of this simplicity is that your entire data-driven application can be compiled as a jar file, a single unit of execution, and deployed onto the Hadoop cluster.

So let’s explore the wordcount example, which can be visualized as a pattern of data flowing through a pipeline under going transformation, beginning from a source (Document Collection) and ending into a sink (Word Count).

In a single file, Main.java, I can code my data pipeline into a MapReduce program using Cascade’s high-level constructs and Java classes. For example, below is a complete source listing for the above transformation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

 package impatient;
 
import java.util.Properties;
 
import cascading.flow.Flow;
import cascading.flow.FlowDef;
import cascading.flow.hadoop.HadoopFlowConnector;
import cascading.operation.aggregator.Count;
import cascading.operation.regex.RegexFilter;
import cascading.operation.regex.RegexSplitGenerator;
import cascading.pipe.Each;
import cascading.pipe.Every;
import cascading.pipe.GroupBy;
import cascading.pipe.Pipe;
import cascading.property.AppProps;
import cascading.scheme.Scheme;
import cascading.scheme.hadoop.TextDelimited;
import cascading.tap.Tap;
import cascading.tap.hadoop.Hfs;
import cascading.tuple.Fields;
 
public class Main {
  public static void main( String[] args )
    {
	    String docPath = args[ 0 ];
	    String wcPath = args[ 1 ];
 
	    Properties properties = new Properties();
	    AppProps.setApplicationJarClass( properties, Main.class );
	    HadoopFlowConnector flowConnector = new HadoopFlowConnector( properties );
 
	    // create source and sink taps
	    Tap docTap = new Hfs( new TextDelimited( true, "\t" ), docPath );
	    Tap wcTap =  new Hfs( new TextDelimited( true, "\t" ), wcPath );
 
	    // specify a regex operation to split the "document" text lines into a token stream
	    Fields token = new Fields( "token" );
	    Fields text = new Fields( "text" );
	    RegexSplitGenerator splitter = new RegexSplitGenerator( token, "[ \\[\\]\\(\\),.]" );
	    // only returns "token"
	    Pipe docPipe = new Each( "token", text, splitter, Fields.RESULTS );
 
	    // determine the word counts
	    Pipe wcPipe = new Pipe( "wc", docPipe );
	    wcPipe = new GroupBy( wcPipe, token );
	    wcPipe = new Every( wcPipe, Fields.ALL, new Count(), Fields.ALL );
 
	    // connect the taps, pipes, etc., into a flow
	    FlowDef flowDef = FlowDef.flowDef()
	     .setName( "wc" )
	     .addSource( docPipe, docTap )
	     .addTailSink( wcPipe, wcTap );
 
	    // write a DOT file and run the flow
	    Flow wcFlow = flowConnector.connect( flowDef );
	    wcFlow.writeDOT( "dot/wc.dot" );
	    wcFlow.complete();
    }
  }

First, we create a Source (docTap) and a Sink (wcTap) with two constructors, new Hfs(…). The RegexSplitGenerator() class defines the semantics for a Tokenizer (see diagram above).

Second, we create two Pipe(s), one for the tokens and the other for word count. To the word count Pipe, we attach aggregate semantics how we want our tokens to be grouped by using a Java construct GroupBy.

Once we have two Pipes, we connect them into a Flow by defining a FlowDef and using the HadoopFlowConnector.

And finally, we connect the pipes and run the flow. The result of this execution is a MapReduce job that runs on HDP. (The dot file is a by-product and maps the flow; it’s a good debugging tool to visualize the flow.)

Note that nowhere in the code is there any reference to mappers and reducers’ interface. Nor is there any indication of how the underlying code is translated into mappers and reducers and submitted to Tez or YARN.

As UNIX Bourne shell commands are building blocks to a script developer, so are the Cascading Java classes for a Java developer—they provide higher-level functional blocks to build an application; they hide the underlying complexity.

For example, a command strung together as “cat document.tweets | wc -w | tee -a wordcount.out” is essentially a data flow, similar to the one above. A developer understands the high-level utility of the commands, but is shielded from how the underlying UNIX operating system translates the commands into a series of forks(), execs(), joins(), and dups() and how it joins relative stdin and stdout of one program to another.

In a similar way, the Cascading Java building blocks are translated into MapReduce programs and submitted to the underlying big data operating system, YARN, to handle any parallelism and resource management on the cluster. Why force the developer to code directly to MapReduce Java interface when you can abstract it with building blocks, when you can simplify to write code easily?

What Now?

The output of  this program run is shown below. Note how the MapReduce jobs are submitted as a client to YARN.

Even though the example presented above is simple, the propositions from which the Cascading SDK was designed—high-level Java abstractions to shield the underlying complexity, functional programming nature of MapReduce programs, and inherent data flows in data-driven big data applications—demonstrate the simplicity and the ability to easily develop data-driven applications and deploy them at scale on HDP while taking advantage of underlying Tez and YARN.

As John Maeda said, “Simplicity is about living life with more enjoyment and less pain,” so why not embrace programming frameworks that deliver that promise—more enjoyment, easy coding, increase in productivity, and less pain.

What’s Next?

Associated with The Cascading SDK are other projects such as Lingual, Scalding, Cascalog, and Pattern. Together, they provide a comprehensive data application framework to design and develop Enterprise data-driven applications at scale on top of HDP 2.1.

To dabble your feet and whet your appetite, you can peruse Cascading’s tutorials on each of these projects.

For hands-on experience on HDP 2.1 Sandbox for the above example, which is derived from part 2 of the Cascading’s Impatient series, you can follow this tutorial.

http://hortonworks.com/blog/cascading-hadoop-big-data-whatever/

New in CDH 5.3: Transparent Encryption in HDFS

http://blog.cloudera.com/blog/2015/01/new-in-cdh-5-3-transparent-encryption-in-hdfs/

El big data ha movido 441 millones de euros en España durante 2014

La investigación de mercados o el big data ha movido en España 441 millones de euros el año pasado. Esta es la cifra neta registrada en el ‘Estudio sobre la Investigación de Mercados 2014’, elaborado por AEDEMO (Asociación Española de Estudios de Mercado, Marketing y Opinión), Aneimo (Asociación de Empresas de Investigación de Mercados y Opinión) y Esomar (Sociedad Europea de Opinión e Investigación de Mercados).

Esta cifra neta de negocio, señala el informe, es un ‘tímido crecimiento del 0,7%’ pero que ‘sabe a éxito después de unos años marcados por la recesión’. El sector de la investigación es cada vez más digital y cada vez la tecnología ocupa un papel más protagonista. Los datos indican que la recogida de datos por medios electrónicos, automáticos y online supone ya la mitad del total mercado (49,9%). En consecuencia, disminuyen el resto de métodos (postal, telefónico, presencial).

http://prnoticias.com/marketing/20142319-big-data-millones-espana