Adaltas

Nouveau regard sur les tests en Node.js avec Mocha, Should et Travis

2012-03-28T00:40:00+02:00

Suite à une demande, l’article ci-dessous est la traduction d’un précédent publié le 19 février 2012.

Aujourd’hui, j’ai finalement décidé de passer une peu de temps autour de Travis. Cette petite image verte en haut des pages d’accueil de projets GitHub m’intrigue de plus en plus ces derniers jours. En fait, pour être tout à fait honnête, ce n’est pas exactement ainsi que j’ai débuté ma soirée. Tout d’abord, après deux ans de bon et loyaux services, j’ai décidé d’abandonner Expresso pour donner une chance à Mocha. Et puisque je m’étais habitué aux quelques petites fonction dont Expresso enrichit le module assert, il m’a fallut y remédier, ce qui m’a conduit au module Should. Il me fut assez plaisant de voir comment ces deux derniers modules se complètent parfaitement l’un et l’autre, dans la plus pure tradition Unix: petit, puissant et bon citoyen.

Écrit par le même autheur qu’Expresso, Mocha est une alternative qui a pour objectif de le remplacer. Cette situation prévaut depuis plusieurs mois déjà mais je n’avais jamais trouvé un grand intérêt à passer dans le monde des tests de type BDD. BDD signifie Behavior Driven Development, soit le développement des tests en mettant en valeur les comportements. Ils s’opposent le plus souvent aux tests unitaires qui sont moins expressifs, et donc par la même moins verbeux. Par exemple le nom des tests sont exprimés comme des phrases entières. Le but est d’encourager la collaboration entres les développeurs et les personnes non techniques comme les intervenants business dans la conception de logiciels. Il existe sans doutes des projets et des cultures d’entreprises dans lesquels cela peut s’appliquer mais de mon expérience personnelle, il m’est impossible de faire participer mes clients dans l’expression des tests unitaires. Cucumber est probablement l’outils de BDD le plus populaire, ce fut l’un des premiers. Cet outil a ses inconditionnels mais j’ai toujours été bien trop fainéant par le passé pour sauter dans cet enfer. À en juger par les exemples, cela implique grossièrement l’apprentissage d’un nouveau langage juste pour écrire des tests. Cette impression est certainement mauvaise et il se peut toutefois que ce soit plus simple qu’il n’y paraisse.

Maintenant, regardons un peu comment s’utilise Mocha]mocha. L’API est relativement simple, principalement deux fonctions qui sont describe et it. Chacune prend un texte comme premier argument qui combinés ensemble forment une phrase visible à l’exécution des tests. Un exemple :

describe 'Mon test', ->

    it 'doit être synchronisé', () ->
        # do sth

    it 'doit être asynchronisé', (next) ->
        # do sth
        next()

Il est intéressant de noter comment Mocha découvre et vous laisse décider pour chaque test si celui doit tourner en mode synchrone ou non, vous permettant de mixer les deux modes et rendant vulgaire l’option serial -s d’Expresso. Il fait en effet appel à la propriété pas si populaire qu’est length attachée à toute fonction. Il y a aussi d’autres méthodes qui sont utiles lors de l’écriture de tests pour modifier la configuration, aider à la mise en place et nettoyer les tests. À titre d’illustration, voici un exemple inspiré des tests de mecano:

should = require 'should'
mecano = require 'mecano'
describe 'download', ->
    @beforeEach (next) ->
        mecano.mkdir scratch, next
    @afterEach (next) ->
        mecano.rm scratch, next
    it 'should deal with ftp scheme', (next) ->
        @timeout 10000
        mecano.download
            source: 'ftp://ftp.gnu.org/gnu/glibc/README.glibc'
            destination:  "#{scratch}/download_test"
        , (err, downloaded) ->
            should.not.exist err
            downloaded.should.eql 1
            next()

Les fonctions beforeEach et afterEach permettent l’exécution d’un code avant et après chacun des tests. La fonction timeout modifie la temps d’exécution maximale d’un test (par défaut 2 secondes).

Maintenant, introduisons l’utilisation de Should. Son principe comme toute librairie d’assertion est de détecter des valeurs incorrectes. Au début, le style d’API de type BDD peut sembler compliqué mais je l’ai tout de suite trouvé naturel et je n’ai pas dû lutter contre lui. En fait, c’est bien là l’essentiel de ce dont j’attend de ce type de librairie, ne pas avoir à ouvrir mon navigateur toutes les 5 minutes pour chercher comme utiliser ce satané API. Après 10 minutes d’utilisation, Should s’est avéré être simple, à la hauteur de ces ambitions et simplifie la lecture des tests, dû moins selon mon opinion.

Finalement, j’ai décidé de m’occuper de Travis et de ces images de statut. Obtenir une image en haut de la page d’accueil de mecano sur GitHub fut facile. La mise en place grâce à son intégration avec GitHub est aisée et pour un nouveau venu prend une 15 de minutes. Faire en sorte que cette petite image soit verte me pris plus de temps. Mecano prend un peu de libertés quand il déroule ses tests. Il a besoin d’être en ligne, GIT doit être installé et il a besoin de se connecter en SSH sur lui-même. Dès la première passe sur Travis, je fus agréablement surpris en constatant que seulement 5 tests ne passaient pas. La plupart de ces erreurs étaient ma faute et furent aussitôt fixés. Une autre erreur était dû à ce que différentes version de Node.js étaient testées mais Should n’est pas compatible avec la version “0.4”. Cela me laissait avec un dernier problème, préparé Travis de tel manière que le compte utilisateur pour faire un SSH sur lui-même sans mot de passe. A la fin, mon fichier “.travis.yml” de configuration fut le suivant:

language: node_js
node_js:
  - 0.6
  - 0.7
before_script:
  - "ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''"
  - "cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys"

Au cours de cet article, je n’ai pas fournis d’instruction sur l’installation et la configuration de ses librairies mais chacun des projets est extrêmement bien documenté. Merci aux auteurs pour leur travail.

HDFS and Hive storage - comparing file formats and compression methods

2012-03-13T21:50:00+01:00

A few days ago, we have conducted a test in order to compare various Hive file formats and compression methods. Among those file formats, some are native to HDFS and apply to all Hadoop users. The test suite is composed of similar Hive queries which create a table, eventually set a compression type and load the same dataset into the new table. Among all the queries, we tested the “sequence file”, “text file” and “RCFILE” formats and the “default”, “bz”, “gz”, “LZO” and “Snappy” compression codecs.

April 4th 2012: Answer to Huchev comment relative to LZ4.

Setup

The environment is a 20 nodes and 120 terabytes Hadoop cluster running Cloudera CDH3U3. The original dataset is a 1.33 Go folder with 80 compressed and unsplitable “bz2” files inside. The data inside is formatted as CSV for a total of about 125,000,000 lines.

Below is an example of a Hive Query importing data using a “RCFILE” format with “LZO” compression:

– Prepare
CREATE TABLE rc_lzo (
    client BIGINT, ctime INT, mtime INT,
    code STRING, value_1 INT, value_2 INT
) STORED AS RCFILE;
– Compression
SET hive.exec.compress.output=true;
SET mapred.output.compression.codec=com.hadoop.compression.lzo.LzoCodec;
– Import
INSERT OVERWRITE TABLE rc_lzo
SELECT * FROM (
    SELECT
        client, round(ctime / 1000), round(mtime / 1000),
        code, value_1, value_2
    FROM staging
) T;

Results

The table below are the results we obtained. The query columns describe the type of test. The query name starts with the file format followed by the compression codec. Both “block” and “record” compression types have been reported for the “sequence file” format and the “default” compression codec.

The “serdesf” family of queries makes use of a custom SerDe which encode each column in an shorter size when appropriate. In our use case, the code can be stored as 1 character (1 byte), the value_2 can be represented as the diff between itself and the value_1 (2 bytes). Overall, a line is stored as 16 bytes compared to 65 bytes originally.

The “bss” query uses the BinarySortableSerDe serialization which is a custom Hive Serde that we associated to the “sequence file” format.

The “b64” family of queries use the base64 package present in the Hive contrib project.

query	time	size
sf	2mn 3s	7.91 Go
sf_string	2mn 22s	8.72 Go
sf_df_block	2mn 17s	8.72 Go
sf_df_record	2mn 12s	7.32 Go
sf_bz	2h 43mn 24s	9.9 Go
sf_gz	2mn 29s	8.72 Go
sf_lzo	2mn 36s	8.80 Go
sf_snappy	3mn 55s	8.23 Go
tf	1mn 45s	6.44 Go
tf_bz	2mn 14s	1.12 Go
tf_df	2mn 16s	1.12 Go
tf_gz	48s	1.34 Go
tf_lzo	1mn 28s	2.41 Go
tf_snappy	1mn 2s	2.55 Go
rc	1mn 30s	5.78 Go
rc_df	5mn 15s	917.68 Mo
rc_gz	4mn 36s	917.80 Mo
rc_snappy	52s	1.85 Go
rc_lzo	38s	1.67 Go
serdesf	59s	3.63 Go
serdesf_df	1mn 27s	4.61 Go
serdesf_bz	3h 6mn 9s	9.63 Go
serdesf_gz	1mn 51s	6.02 Go
serdesf_snappy	1mn 35s	4.80 Go
bss	1mn 25s	5.73 Go
b64	2mn 5s	9.17 Go
b64_bz	21mn 15s	1.14 Go
b64_df	21mn 25s	1.14 Go
b64_gz	53s	1.62 Go
b64_snappy	59s	2.89 Go

Some notes

We wish we had run the tests on a larger input data set with a more common file format but cluster time is a scarce resource at the moment. As a result, the file sizes are probably representative but the speed results should be interpreted with care.

The speed reflects importing time only (with not so standard files as input) and not how fast those formats are against map/reduce jobs.

As part of the test, we also tested block type of compression on other type of codecs but they had no effect so we came to the conclusion that block type only apply to the default codec in sequence files.

We tried to run the serdesf test in a similar mode but using the RCFILE format instead of sequence file but the results are identical to the rc family of queries.

Interpretation

The “tf” query act as a reference since it stores our data in an uncompressed CSV format. It is kind of awkward to see that all the “sequence file” queries generate larger file size. This isn’t something we expected but maybe is it due to our high usage of the integer type.

In term of file size, the “RCFILE” format with the “default” and “gz” compression achieve the best results. The “base64” SerDe using “sequence file” with “bz” and “default” compression aren’t so far away. However, those “base64” results are slow enough to be bypassed.

In term of speed, the “RCFILE” formats with the “lzo” and “snappy” are very fast while preserving a high compression rate.

About LZ4

We didn’t test LZ4. From our understanding of HADOOP-7657, the support for LZ4 target Hadoop version 0.23.1, 0.24.0 and is not backported to our running Cloudera CDH3U3. If you are curious about LZ4, here’s an interesing article comparing LZ4 to Snappy. Also worth of interest is the in-memory benchmark of the fastest compressors.

Two Hive UDAF to convert an aggregation to a map

2012-03-06T01:30:00+01:00

I am publishing two new Hive UDAF to help with maps in Apache Hive. The source code is available on GitHub in two Java classes: “UDAFToMap” and “UDAFToOrderedMap” or you can download the jar file. The first function converts an aggregation into a map and is internally using a Java HashMap. The second function extends the first one. It converts an aggregation into an ordered map and is internally using a Java TreeMap.

API

As a reminder, an UDF stands for a User Defined Function and an UDAF stands for User Defined Aggregate Function. When an UDF is a custom scalar function on one or more column of a single row (for example the CONCAT function in SQL), an UDAF work on a aggregation of one or multiple columns (for example the MAX function in SQL).

MAP to_map(primitive, primitive_or_complex)
MAP to_ordered_map(primitive, primitive_or_complex)

Both function share the same API. They accept two arguments, first is the key and second is the value. Keys may be any primitive type. Values may be a primitive or a complex type. In Hive, primitive types are integer, boolean, floating point number, string, date and binary while complex types are structure, map and array.

Motivation

While working on time series in Hive, I created those functions out of the following needs:

Since UDF are much trivial to implement than UDAF, it is convenient to write and use a UDF which takes the result of a generic UDAF as its input, for example:
select MY_UDF( MY_UDAF(column_1, column_2) ) from my_table group by column_3.
The HBase structure we are modeling use keys to store customer identifiers and columns to store dates. Importing data from Hive to HBase could be done in two ways: with a select statement or with an complicated low-level bulk loading strategy. Using a select statement, since it is making usage of a map and since we couldn’t find any way to convert the result of an aggregation into a map, we had to insert on row per metering data which we suspect to be less efficient than inserting one row of multiple metering data for a single customer. Using a bulk loading strategy, we also faced the need to group our dataset into an ordered map to reflect to final layout of the HBase storage file format.
We are experimenting a custom HDFS file format integrated to Hive which internally need to group the metering data of a customer to optimize their storage. We first wrote an implementation which takes an ordered result set as its input. This work but is a much more complicated implementation. Also, because of the nature of HDFS and MapReduce, we had no guaranty that all the data of a single customer would be store in a same file which prevent us from a complete optimization. Once again, structuring the data as a map was a requirement.

Usage

Considering a source data set as follow made of 4 columns (customer id, timestamp, meter value, meter state):

195100,1199145600,607527807,B
185100,1199145600,775031942,A
195100,1199156400,607532682,B
185100,1199156400,775032584,A
195100,1199167200,607535485,B
185100,1199167200,775033200,A
195100,1199178000,582924326,C
185100,1199178000,775034241,A
195100,1199188800,582927007,C
185100,1199188800,775035698,A
195100,1199199600,582929212,C
185100,1199199600,775036891,A
195100,1199210400,582932070,C
185100,1199210400,775038268,A
195100,1199221200,582935353,B
185100,1199221200,775039703,A

The CSV source is imported into Hive with the next statements:

DROP TABLE source;
CREATE TABLE source (
    customer INT,
    emission INT,
    value INT,
    state STRING
)
ROW FORMAT DELIMITED
    FIELDS TERMINATED BY ','
    LINES TERMINATED BY '\n'
STORED AS TEXTFILE;
LOAD DATA LOCAL INPATH './sample/data.csv' OVERWRITE INTO TABLE source;

Now we can declare our two UDAF:

ADD JAR ./target/adaltas-hive-udf-0.0.1-SNAPSHOT.jar;

CREATE TEMPORARY FUNCTION to_map as 'com.adaltas.UDAFToMap';
CREATE TEMPORARY FUNCTION to_ordered_map as 'com.adaltas.UDAFToOrderedMap';

And we can finally used them with the following queries:

SELECT
    `customer`, to_map(from_unixtime(emission), array(value,state))
FROM `source`
GROUP BY `customer`;

SELECT
    `customer`, to_ordered_map(from_unixtime(emission), array(value,state))
FROM `source`
GROUP BY `customer`;

The output of the last select statement looks like:

185100  {
    "2008-01-01 01:00:00":["775031942","A"],
    "2008-01-01 04:00:00":["775032584","A"],
    "2008-01-01 07:00:00":["775033200","A"],
    "2008-01-01 10:00:00":["775034241","A"],
    "2008-01-01 13:00:00":["775035698","A"],
    "2008-01-01 16:00:00":["775036891","A"],
    "2008-01-01 19:00:00":["775038268","A"],
    "2008-01-01 22:00:00":["775039703","A"] }
195100  {
    "2008-01-01 01:00:00":["607527807","B"],
    "2008-01-01 04:00:00":["607532682","B"],
    "2008-01-01 07:00:00":["607535485","B"],
    "2008-01-01 10:00:00":["582924326","C"],
    "2008-01-01 13:00:00":["582927007","C"],
    "2008-01-01 16:00:00":["582929212","C"],
    "2008-01-01 19:00:00":["582932070","C"],
    "2008-01-01 22:00:00":["582935353","B"]}

If you have clone our GitHub repository, you can run the above sample with the command mvn install && hive -f sample/to_map.hive.

While writing this article, I also published a JIRA enhancement issue (HIVE-2843) proposing the integration of the source code into Hive. I’ll prepare the patch for its inclusion into Hive if the community express its interest.

Java versus JS fun, a quote from the Node.js mailing list

2012-02-23T18:52:00+01:00

I just read that one on the mailing list. I found it relevant enough to share it with those who did not subscribe to it:

First Lothar Pfeiler:

I still wonder, if it’s cool to have such a big discussion on how to convert a string into an integer, or if all the java developers laugh at us.

Then dolphin278:

They are busy with their spaceship-size configuration files, so we safe

A geek joke… but I fully backup that statement as a good caricature of the Java versus JS situation.

A fresh look at testing Node.js projects: Mocha, Should and Travis

2012-02-19T15:59:00+01:00

Today, I finally decided to spend some time around Travis. It’s been a weeks since that little green image on top of GitHub homepages has been buzzing me. Well, to be totally honest, this isn’t how I started my evening. First, after 2 years of good and faithfull service, I decided to drop Expresso and give a chance to Mocha. Because Expresso enriches the assert module with one or two functions which I became addicted to, I also had to find the same functionalities into another assertion library which lead me to testing Should. It is very pleasant to see those two working together, as in the Unix tradition: small, powerful and naturally integrated.

Written by the same author than Expresso, Mocha is meant to replace it. It’s been the case since quite a while but I’ve always been reluctant to jumping into BDD testing. BDD stands for Behavior Driven Development and is an alternative way to express your tests. For example, test names are expressed as a full sentence. Its goal is to encourage collaboration between developers, QA and non-technical or business participants in a software project. This is probably applicable in some workspaces but from a personal experience, it can’t expect our clients to participate in test coverage. Cucumber is probably the most popular BDD tool, it has its fans but I’ve been too lazy in the past to jump into BDD. Facing any sample, It feels like learning a new language to write tests. Probably it was a wrong impression and it might be much easier than I think.

Now let’s have a look at Mocha. the API is quite simple, mainly two functions which are describe and it. They both take a text as a first argument which combining together produce a sweet sentence during the run. An example:

describe 'My test', ->

    it 'should run synchronously', () ->
        # do sth

    it 'should run asynchronously', (next) ->
        # do sth
        next()

Notice how Mocha discover and let yet decide whether you wish to run your tests synchronously or not, even mixing the two modes. Behind the hood, it’s making use of the not so popular length property attached to a function. There are few additionnal methods that come handy to modify settings and to setup and cleanup your tests. For illustration purpose, here is an example inspired from the mecano test suite:

should = require 'should'
mecano = require 'mecano'
describe 'download', ->
    @beforeEach (next) ->
        mecano.mkdir scratch, next
    @afterEach (next) ->
        mecano.rm scratch, next
    it 'should deal with ftp scheme', (next) ->
        @timeout 10000
        mecano.download
            source: 'ftp://ftp.gnu.org/gnu/glibc/README.glibc'
            destination:  "#{scratch}/download_test"
        , (err, downloaded) ->
            should.not.exist err
            downloaded.should.eql 1
            next()

The functions beforeEach and afterEach allow code execution before and after each test. The function timeout modify the maximum execution time of a tests (by default 2 seconds).

Here, let’s introduce the usage of Should. Its purpose like any assertion library is to detect incorrect returned variable. At first, the BDD style API may look complicated but I found it natural and I didn’t have to fight against it. Well, I said it all. This is essentially what I’m expecting from such a library, not opening my browser to figure out how to use the API. After 10mn of usage, Should has proved to be easy, delivered its promises and enhance code readability (to my opinion).

Finally, I decided to deal with this Travis status. Getting the image popping up into the mecano GitHub page was easy. Travis setup and GitHub integration for a newbie took less that 15 minutes. To make it green took a little longer. Mecano is making a few assumptions when running its test. It must be online, have GIT installed and be able to SSH itself. It turns out I was positively surprise on the first run, only 5 tests when not passing. Most of them were my fault and I fixed them. Another one was Should usage of JavaScript which was incompatible with the one used by Node.js in version “0.4”. That left me with only one issue, setting up the Travis user account in such a way it can SSH itself without a password asked. In the end, my “.travis.yml” configuration file looks like:

language: node_js
node_js:
  - 0.6
  - 0.7
before_script:
  - "ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''"
  - "cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys"

During this presentation, I did not provide any instruction related to installation and configuration because each project is very well documented. Thanks to the author of those tools for their appreciable work.

Coffee script, how do I debug that damn js line?

2012-02-15T01:20:00+01:00

Update April 12th, 2012: Pull request adding error reporting to CoffeeScript with line mapping

Chances are that, if you code in CoffeeScript, you often find yourself facing a JavaScript exception telling you a problem occured on a specific line. Problem is that the line number in question in the one of the generated JavaScript, not your in CoffeeScript line number. Even worse, if you generate your JavaScript transparently, you wont have any JavaScript file to look into and the all process of finding where this error occored is even more frustrating.

Well, it seems like the future version of JavaScript could come to the rescue, but not before a few months. In the mean time, here’s a little of fun about writing a small Bash script that may save you some time.

We’ll call our script coffeep, an enhance version of coffee -p and it’s purpose is to print to the console the JavaScript code translated from your coffee file with line numbered. To make it even more useful, the script may take one or two additional arguments after the coffee file path to limit the printed lines to only the section which you wish to debug.

For example, coffeep myfile.coffee will output the generated JavaScript like coffee -p myfile.coffee would do, but with each line prefixed by its line number. Calling coffeep myfile.coffee 20 will print the line 20 as well as the 5 preceding lines and the 5 following lines. Calling coffeep myfile.coffee 20 30 will print the line 20 to 30.

This is certainly not rocket science but shall become part of your coffee swiss army knife. Leveraging cat -n which given some content passed through stdin prefix each line with its line number starting at 1, our first version of coffeep looks like:

#!/bin/bash
coffee -p $1 | cat -n

If you are not familiar with bash scripting, $1 stands for the first argument passed to coffeep, which in our case is our coffee file.

Now we’ll add two possible usages. If one argument is provided after the path, it is expected to be the JavaScript line number you wish to debug and we’ll output the preceding and following 5 lines. If two arguments are provided after the path, there are expected to be the first line and the last line to output.

#!/bin/bash
if [ $# -eq 1 ]
then
    coffee -p $1 | cat -n
elif [ $# -eq 2 ]; then
    head_count=$(($2+5))
    tail_count=11
    coffee -p $1 | cat -n | head -$head_count | tail -$tail_count
elif [ $# -eq 3 ]; then
    head_count=$(($2+$3))
    tail_count=$3
    coffee -p $1 | cat -n | head -$head_count | tail -$tail_count
fi

With some little arithmetic, we make use of head and tail to first limit the output to head_count first lines with head, and finally limit the output to tail_count last lines with tail.

Finally, for convenience, just copy/paste the following code into your terminal and it shall create an executable file named “coffeep” in “/usr/local/bin” (accessible from your $PATH, make sure to have the permission to modify this directory):

cat > /usr/local/bin/coffeep <<DELIM
#!/bin/bash
if [ $# -eq 1 ]
then
    coffee -p $1 | cat -n
elif [ $# -eq 2 ]; then
    head_count=$(($2+5))
    tail_count=11
    coffee -p $1 | cat -n | head -$head_count | tail -$tail_count
elif [ $# -eq 3 ]; then
    head_count=$(($2+$3))
    tail_count=$3
    coffee -p $1 | cat -n | head -$head_count | tail -$tail_count
fi
DELIM
chmod +x /usr/local/bin/coffeep

Announcing Mecano, a set of functions for system deployment

2012-02-12T22:40:00+01:00

We are releasing Node Mecano on GitHub which gather common functions used while deploying systems. The idea was to group those functions into a comprehensive library.

The code started when we wrote Heco as well as when we deployed a Hadoop cluster for one of our customer. It found inspiration in the Chef Resource API.

The functionalities are sill limited and there are obviously many potential improvements but we wanted to release the code early. We found it already very usefully and the API should be stable enough to integrate it into your own project.

The functions covered by Mecano are copy, download, execute, extract, git, ln, mkdir, remove and render. Their API is always the same. The first argument defines one or more command to run (an object or an array of objects) and the second one is a callback called on completion which tell you how many common where really run. For example, to copy 2 files, the code will look like:

mecano = require('mecano');
mecano.copy([
  { source: 'file_1', destination: 'dest_1' },
  { source: 'file_2', destination: 'dest_2' }
], (err, copied) ->
  console.log( 'Number of file copied: '+copied );

Calling the same command a second time and the value of copied will be “0” because no new file was copied.

The command share a set of common properties to conditionally run the command and validate its result. For example, the following command will only run if a specified file exists and will emit an error if the exit code isn’t the one provided.

mecano = require('mecano');
mecano.execute({
  cmd: 'whoami',
  if_exists: '/home/itsme',
  code: 0 // default exit code
}, (err, executed) ->
  console.log( 'Did the command run '+(executed?'yes':'no') );

Hope you’ll find it useful as well and don’t hesitate to provide us with feedback.

OS module on steroids with the SIGAR Node binding

2012-01-11T22:40:00+01:00

Today we are announcing the first release of the Node binding to the SIGAR library. Visit the project website or the source code repository on GitHub.

SIGAR is a cross platform interface for gathering system information. From the project website, such information include:

System memory, swap, cpu, load average, uptime, logins
Per-process memory, cpu, credential info, state, arguments, environment, open files
File system detection and metrics
Network interface detection, configuration info and metrics
TCP and UDP connection tables
Network route table

Please consult the SIGAR documentation for a complete list of supported operating systems, architectures and versions.

The current version is a complete binding of the SIGAR API. There are still however a few minor issues left due to our lack of C++ skills and SIGAR understanding. Please give us some help if you are a knowledgeable Node C++ binder or an experienced SIGAR user.

Here is an example returning CPU information:

var sigar = require('sigar');

var cpus = sigar().cpuList()
for(var i = 0; i < cpus.length; i++){
  console.log(cpus[i]);
}

Visit the Node SIGAR website for a complete view of the API.

Timeseries storage in Hadoop and Hive

2012-01-10T12:23:00+01:00

In the next few weeks, we will be exploring the storage and analytic of a large generated dataset. This dataset is composed of CRM tables associated to one timeserie table of about 7,000 billiard rows.

Before importing the dataset into Hive, we will be exploring different optimization options expected to impact speed and storage size.

Note, the following advantage and disadvantage of each optimization reflect our current understanding of Hadoop and Hive.

Hive partitioning

The distribution of the data files in HDFS under hierarchical directories.

Advantage:

With partition pruning, some queries may only need to read a subset of the files

Disadvantage:

Multiply the number of files managed by the namenode
A query may work against the partition thus requiring to traverse more files. For example a query which aggregates the data of a single customer over a year would be less efficient under a table partitioned by day.

Block size

Each file in HDFS is split under different chunks of fixed size to be distributed across the Hadoop cluster. This block size is by default set to 64M but could be increased to 126M or more.

Advantage:

Less work between M/R tasks

Disadvantage:

Decrease the potential load repartition with smaller files (think Hive partitioning)

Hive index

Maintain an index against a Hive table

Advantage:

Work on any columns with impacting the HDFS layout

Disadvantage:

Still slower than a natural file storing layout (think sorted Clustering)
Duplication of index for each Hive partition (might not be a problem)

Clustering

Dispatch data into a defined number of buckets (HDFS files) using a hash key on one or more columns and order the data.

Advantage:

Sampling

Advantages not yet implemented:

Bucket pruning when filtering on the bucket column
Take advantage of the sorted schema
Join optimization between two tables using the same column hash

Disadvantage:

Multiply the number of files managed by the namenode.

Native file formats

Text versus binary and row versus column layout. Hive offers TEXTFILE, SEQUENCEFILE and RCFILE.

Advantage:

RCFILE may benefit better file size and increase speed on joins
SEQUENCEFILE shall better handle map phase referencing multiple columns

Hive format

Best usage of Hive data type and experiment Hive data structure in the context of timeseries. For example, instead of storing one measure per row, we could store all the measure of a single customer in a Hive structure type of 144 elements for each day (one data every 10mn).

Advantage:

Drastically reduce the storage size (while increasing speed)

Disadvantage:

Increase queries complexity

Custom file formats

Leverage Hive SerDe to implement a custom layout. This is similar to the solution described above but pushed one step further.

Compression

Find the right equilibrium between IO and CPU usage by testing the various Codecs.

MR framework

Text various map and reduce tuning properties.

Preparation

Before we start we need:

a consequent cluster (around 20 nodes)
a simplified data schema
a medium sized data sets (around 1To)
a few representative queries

Cluster

Number of servers: 19 (waiting for 2 more)
Number of cpus: 320 logical thread
Number of disk: 124 * 1Go SATA 7200rpm
Number of rack: 2
Hadoop version: Cloudera 0.20.2-cdh3u2

Data schema

The original Hive database schema is:

CREATE DATABASE timeseries;
USE timeseries;
– Cities table
CREATE TABLE cities
(
    id_city BIGINT,
    fk_region INT,
    zipcode INT,
    name STRING
)
STORED AS SEQUENCEFILE;
– Client table
CREATE TABLE client
(
    id_client BIGINT,
    fk_city INT,
    lastname STRING
)
STORED AS SEQUENCEFILE;
– Metering table
CREATE TABLE metering
(
    fk_client BIGINT,
    date_emission INT,
    date_reception INT,
    type STRING,
    index INT,
    diff INT
)
PARTITIONED BY(date_emission_day STRING)
CLUSTERED BY(fk_client) SORTED BY(date_emission) INTO 32 BUCKETS
STORED AS SEQUENCEFILE;

How Node CSV parser may save your weekend

2011-12-13T21:50:00+01:00

Last Friday, an hour before the doors of my customer close for the weekend, a co-worker came to me. He just finished to export 9 CSV files from Oracle which he wanted to import into Greenplum such as our customer could start testing on Monday morning.

The problem as exposed was quite simple. He needed a quick solution (less than an hour, coding included) to transform all the date in the source CSV file into a format suitable for Greenplum. While Oracle exported dates in the form of ‘DD/MM/YYYY’, Greenplum was picky enough to expect dates in the form of ‘YYYY-MM-DD’.

Here are the files we needed to import:

-rw-r–r– 1 ingres ingres  41G 2011-12-09 18:23 a.csv
-rw-r–r– 1 ingres ingres 418M 2011-12-09 17:22 b.csv
-rw-r–r– 1 ingres ingres  45G 2011-12-09 18:26 c.csv
-rw-r–r– 1 ingres ingres 1,8G 2011-12-09 17:37 d.csv
-rw-r–r– 1 ingres ingres 896M 2011-12-09 17:33 e.csv
-rw-r–r– 1 ingres ingres 382M 2011-12-09 17:13 f.csv
-rw-r–r– 1 ingres ingres 7,6G 2011-12-09 18:09 g.csv
-rw-r–r– 1 ingres ingres 621M 2011-12-09 17:33 h.csv
-rw-r–r– 1 ingres ingres 3,1G 2011-12-09 17:46 i.csv

Among those files, two are larger than 45Gb.

Since generating new files would probably have taken too long, the first question asked was whether or not the Greenplum import command would accept stdin data through unix pipe, which question luckily answered to yes. So my first suggestion was to cat a file, pipe it to Awk which would reformat the date line by line and finally pipe it to the import tool. The command would look like:

cat a.csv | awk '…' | psql -p $port $database -c "COPY $table FROM STDIN WITH CSV;"

The solution seems workable. Problem, we are no Awk expert and I could not guaranty him an hour would be enough to write and test the command.

Considering how familiar I am with Node those days, I told him that writing a small JavaScript script which interact with stdin and stdout would be much more secure. This is when we though of using the CSV parser, the first library I wrote for Node a little more than a year ago.

We first had to configure the proxy and install Node on this server which took about 10mn. For this we used NVM. Then, we wrote the following JavaScript:

#!/usr/bin/env node
var csv = require('./csv');

csv()
.fromStream(process.stdin)
.toStream(process.stdout)
.transform(function(data, index){
    for(var i=0; i< data.length; i++){
        if(/(\d{2})\/(\d{2})\/(\d{2})/.test(data[i])){
            data[i] = data[i].replace(/(\d{2})\/(\d{2})\/(\d{2})/, "20$3-$2-$1");
        }
    }
    return data;
});

process.stdin.resume()

Note how the usage of the regular expression could have been optimized. But our goal wasn’t to speed the import process, only to make it run as soon as possible.

We alread had at our disposal a small bash script which could loop trough the CSV files and launch the Greenplum import command. We tweak it a bit such as the final version looked like:

#!/bin/bash
for csv in $(ls ~/export/*.csv)
do
        table=`echo $csv|cut -d'/' -f 5`;
        table=`echo $table|cut -d'.' -f 1`;
        table=`echo $table| sed 's/\(.*\)../\1/'`;
        cat $csv | transform.js | psql -p 5433 my_database -c "COPY $table FROM STDIN WITH CSV;"
done

Well, on Monday morning, the CSV parser handled the volume and all the CSV files were ingested by Greenplum.

Node intégré à la plateforme cloud Microsoft Azure

2011-12-10T17:50:00+01:00

Node est désormais un citoyen de premier ordre dans l’environnement cloud de Microsoft Azure au côté de .Net, Java et PHP. Cette intégration est la conséquence logique de l’implication de Microsoft dans le développement de Node il y a maintenant un an. A l’origine seulement disponible sur les plateformes de type Unix (Linux, OSX, …), la version 5 de Node fut principalement consacré au portage sur Windows sans impacter les performances de la version Unix.

Force est de constater que les performances ne se sont effectivement pas dégradées. A titre indicatif, notre générateur de séries temporelles développé pour EDF a doublé ses performance entre la version 0.4.11 et la version 0.6.1, essentiellement grâce à la monté en version du moteur Google V8.

Mais revenons à Microsoft. Il s’agit d’une nouvelle capitale. Personnellement, je ne suis pas intéressé par la possibilité de coder sur Windows, plateforme que je fuis comme la peste depuis une bonne douzaine d’années. Mais de nombreux programmeurs le sont. Il ne faut pas négliger l’importance de ceux-ci qui sont par légion. Certains sont Microsoft par amour, d’autre se sont fait imposer cette plateforme par leur entreprise. Outre les développeurs professionnels, il y a aussi une large quantité de hacker du dimanche qui bidouille avec plaisir leurs sites Internet, maniant avec plus ou moins de brio HTML, CSS et … Javascript après avoir téléchargé une version de WordPress, Drupal ou PrestaShop. Passé dans le côté obscure de la force était pour eux synonimes d’apprendre un nouveau langage, le plus souvent PHP. On peut sans risque anticiper que certains de ceux là auront plus de facilité à manipuler le Javascript déjà présent dans le chapeau des technologies du Web. De plus comparativement à WAMP, l’environnement Node est bien plus simple à installer. Pas de serveur web à paramétrer et, avec NPM, un gestionnaire de modules ultra simple.

La présence de Node au côté de .Net, Java et PHP est flatteuse. Pensez-y, Node n’a que 2 ans, c’est déjà un grand bébé. Autour de lui, le sénior du Web qu’est PHP, celui du monde de l’entreprise qu’est Java et l’enfant du boss qu’est .Net façonné à partir du Java. Rien des autres, les Python, Ruby, Erlang, Go, Perl, … Cette présence est aussi synonyme des 3 choses:

Node est une plateforme mature. Son moteur Google V8 est la fondation du navigateur du même nom. Il est installé par 200 millions d’utilisateurs, ce qui en fait le second navigateur en terme de popularité après Microsoft Explorer.
Node possède un large écosystème. La popularité de Node ces derniers mois ne s’est pas uniquement traduit sur GitHub, en devenant de deuxième projet le plus populaire sur GitHub devant Ruby on Rails, mais aussi par un large choix de modules.
Node est promit à un brillant avenir tant dans la communauté Web que dans le monde de l’entreprise.

Chef : configuration et deploiement automatisé de Clusters

2010-12-10T17:50:00+01:00

L’installation d’un cluster de plusieurs machines est consommateur de temps. La même procédure de mise en place des logiciels et de leurs paramétrages doit être répétées à l’identique. Au cours du temps, des mises à jours doivent être appliquées, certains logiciels doivent être supprimés quand d’autres sont ajoutés et au final, les systèmes divergent les uns des autres.

Pour répondre à ces problèmes, des logiciels gestion de configuration automatisent ces opérations. Un serveur s’installe et se paramètre en une seule commande en fonction des rôles qu’on souhaite lui alloué.

Finalement, avec Chef, la mise en place d’un système ce limite à 2 procédures:

Installer un système de base sans logiciels préinstallé, juste ssh
Lancer une commande indiquant l’adresse du serveur et ses rôles (par exemple “server, lamp”)

Deux outils Open Source se chamaillent le leadership sur ce secteur, Puppet et Chef. Le débat entre chacun est houleux, tous les deux étant finalement de qualité comparable et dotés d’un large éventail de configurations préétablies couvrant l’ensemble des besoins d’administration. Chef nous a paru légèrement plus flexible (paramétrage en Ruby au lieu d’un langage sur-mesure).

Parmi les fonctionnalités de Chef (et Puppet) :

Synchronisation automatique des nœuds avec l’état de la configuration
Support de plusieurs OS (spécialement Puppet)
Nombreuses configurations disponibles
Large communauté
Interface web agréable

Livres de recettes (Cookbooks)

Des cookbooks relatifs à Hadoop sont présents aux endroits suivants:

Opscode
hadoop::default : Installe le fichier apt du dépôt Cloudera et le paquet Hadoop
hadoop::conf_pseudo : démarre les services Hadoop
hadoop::doc : Installe le packet hadoop-doc
hadoop::hive : Installe le packet hive
hadoop::pig : Installe le packet pig
Conclusion, des fonctionnalités très limitées qui ne s’appliquent pas à l’installation complète d’un cluster Hadoop.
Runa
hadoop_for_hbase::default : Télécharge hadoop sur depuis le site du créateur (version configurable)
Conclusion: Aucune garantie sur la source, peut de choix sur les version, limite a hadoop et hbase.
Infochimps Cluster Chef
hadoop_cluster::default : Enregistre la source apt du dépôt Cloudera, crée un groupe et un utilisateur Unix hadoop, crée un supergroup Hadoop supergroup
Conclusion, sans doute le meilleur point de départ sur lequel s’appuiyer pour créer ses propres recettes.

Ressources externes:

Installation sous OSX en mode pseudo-distribué

2010-12-01T19:58:00+01:00

Le système d’exploitation choisi est OSX mais la procédure n’est pas si différente pour tout environnement Unix car l’essentiel des logiciels sont téléchargés depuis Internet, décompressés et paramétrés manuellement. Seuls quelques paquets sont installés par Macport mais ceux-ci sont aisément trouvables sur des outils équivalents comme Apt et Yum. Etant donné que les logiciels téléchargés sont en Java, il ne devrait pas y avoir de soucis quand à leur fonctionnement dans d’autres environnements.

Cette environnement est configuré en mode pseudo-distribué afin de simuler au mieux le comportement d’un cluster si un poste unique. Dans ce mode, chaque processus Java tourne dans sa propre JVM.

La procédure couvre l’installation des logiciels suivant:

Hadoop (common, hdfs, mapreduce)
Pig
HBase
Sqoop
Flume
Hue (Cloudera Desktop)

Choix des versions

L’installation des logiciels depuis les dépôts SVN s’est confrontée à un problème d’incompatibilité entre Hive qui requière la dernière version stable de Hadoop (2.20.2) et celle de Sqoop qui requière la version SVN de Hadoop. Pour cette raison, nous avons opté pour les versions distribuées par Cloudera. Basées sur des versions stables, elles incluent un grand nombre des patches présents dans les dépôts SVN et sont testés par certains des meilleurs experts de la communauté.

Toutefois, certaines fonctionnalités ne sont pas encore présentes des la distribution, c’est pourquoi certains d’entre nous utilisent aussi des versions compilées depuis les dépôts SVN. Les logiciels en question sont HBase et Hive et leur installation manuelle n’est pas couverte ci-dessous.

Installation

La procédure décrite part du postulat que XCode et MacPort sont déjà présent sur le système.

La distribution de Cloudera est CDH3beta2 qui n’est pas la plus récente mais le mécanisme est le même à condition de se rendre sur le site de Cloudera et de télécharger les versions les plus récentes. Dépendances MacPort

sudo port install wget p26-virtualenv libxml2 libxslt mysql5 mysql5-server  sqlite mysql
easyinstall simplejson

Mise en place de SSH

# You need to able to ssh yourself with requiring a password
# (using your public key)
# Next line only if "~/.ssh/id_rsa.pub" does not exists
ssh-keygen -C "my@email.com" -t rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
# you should now be able to issue "ssh localhost"
# without entering your password

Préparation du répertoire d’installation

 
# Replace {username}
sudo mkdir /opt/cloudera
sudo chown {username}:staff /opt/cloudera
cd /opt/cloudera

Téléchargement des paquets

wget http://archive.cloudera.com/cdh/3/hadoop-0.20.2+320.tar.gz
wget http://archive.cloudera.com/cdh/3/hive-0.5.0+20.tar.gz
wget http://archive.cloudera.com/cdh/3/pig-0.7.0+9.tar.gz
wget http://archive.cloudera.com/cdh/3/hbase-0.89.20100621+17.tar.gz
wget http://archive.cloudera.com/cdh/3/sqoop-1.0.0+3.tar.gz
wget http://archive.cloudera.com/cdh/3/flume-0.9.0+1.tar.gz
wget http://archive.cloudera.com/cdh/3/hue-common_0.9-2.tar.gz
wget http://archive.cloudera.com/cdh/3/zookeeper-3.3.1+10.tar.gz

Extraction des paquets

 
tar -xzf hadoop-0.20.2+320.tar.gz
tar -xzf hive-0.5.0+20.tar.gz
tar -xzf pig-0.7.0+9.tar.gz
tar -xzf hbase-0.89.20100621+17.tar.gz
tar -xzf sqoop-1.0.0+3.tar.gz
tar -xzf flume-0.9.0+1.tar.gz
tar -xzf hue-common_0.9-2.tar.gz
tar -xzf zookeeper-3.3.1+10.tar.gz
# Make symbolic links
ln -sf hadoop-0.20.2+320 hadoop
ln -sf hive-0.7.0-dev hive
ln -sf pig-0.7.0+9 pig
ln -sf hbase-0.89.20100621+17 hbase
ln -sf sqoop-1.0.0+3 sqoop
ln -sf flume-0.9.0+1 flume
ln -sf hue-common-0.9 hue
ln -sf zookeeper-3.3.1+10 zookeeper
# Clean up
rm -rf *.tar.gz

Configuration de l’environnement

echo "export JAVA_HOME=/Library/Java/Home" >> ~/.profile
echo "export HADOOP_HOME=/opt/cloudera/hadoop" >> ~/.profile
echo "export HIVE_HOME=/opt/cloudera/hive" >> ~/.profile
echo "export HIVE_CONF_DIR=/opt/cloudera/hive/conf" >> ~/.profile
echo "export PIG_HOME=/opt/cloudera/pig" >> ~/.profile
echo "export HBASE_HOME=/opt/cloudera/hbase" >> ~/.profile
echo "export FLUME_HOME=/opt/cloudera/flume" >> ~/.profile
echo "export SQOOP_HOME=/opt/cloudera/sqoop" >> ~/.profile
echo "export ZOOKEEPER_HOME=/opt/cloudera/zookeeper" >> ~/.profile
echo "export HUE_HOME=/opt/cloudera/hue" >> ~/.profile
echo "export PATH=\$HADOOP_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$HBASE_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$PIG_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$HIVE_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$FLUME_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$SQOOP_HOME/bin:\$PATH" >> ~/.profile
echo "export PATH=\$ZOOKEEPER_HOME/bin:\$PATH" >> ~/.profile
source ~/.profile

Configuration des logiciels

# Configure Hive
# Edit ./conf/hive-default.xml
# and modify the property 'javax.jdo.option.ConnectionURL'
# to 'jdbc:derby:;databaseName=/opt/cloudera/data/hive/metastore_db;create=true'
# Edit ./conf/hive-log4j.properties
# and modify the property 'hive.log.file'
# to '/opt/cloudera/data/hive/hive.log'
# (SVN only) modify property 'hive.stats.dbconnectionstring'
# to 'jdbc:derby:;databaseName=/opt/cloudera/data/hive_temp_stats;create=true'
# For mysql,
# modify 'javax.jdo.option.ConnectionURL'
# to 'jdbc:mysql://127.0.0.1/hive?createDatabaseIfNotExist=true'
# and 'javax.jdo.option.ConnectionDriverName'
# to 'com.mysql.jdbc.Driver'
# and 'javax.jdo.option.ConnectionUserName'
# to 'your_username'
# and 'javax.jdo.option.ConnectionPassword'
# to 'your_password'

# Configure Hue
# Note: from memory, you might also need mysql
sudo port install py26-setuptools
ln -sf /opt/local/bin/mysql_config5 /opt/local/bin/mysql_config
cd hue-common-0.9
make apps
# EDIT $HUE_HOME/desktop/conf/hue.ini and
# update the property "hadoop_home" from "/usr/lib/hadoop-0.20"
# to "/opt/cloudera/hadoop-0.20.2+320"

# Configure Hadoop
cd $HADOOP_HOME/lib
ln -s $HUE_HOME/desktop/libs/hadoop/java-lib/hue-plugins-0.9.jar
mv hadoop-0.20.2+320/conf hadoop-0.20.2+320/conf.bck
cp -rp hue/example-hadoop-confs/conf.pseudo-hue hadoop-0.20.2+320/conf
# Edit the file $HADOOP_HOME/conf/core-site.xml and replace
# the value "/var/lib/hadoop-0.20/cache/${user.name}" by
# "/opt/cloudera/data/cache/${user.name}"
# Edit the file $HADOOP_HOME/conf/hdfs-site.xml and replace
# the value "/var/lib/hadoop-0.20/cache/hadoop/dfs/name" by
# "/opt/cloudera/data/cache/${user.name}/dfs/name"
hadoop namenode -format

Utilisation

Démarrage des services

# Start Hadoop
start-all.sh
# Start HBase
start-hbase.sh
hbase-daemon.sh start rest
# Start Hue
cd $HUE_HOME
./build/env/bin/supervisor

Arrêt des services

 
# Start Hadoop
stop-all.sh
# Start HBase
hbase-daemon.sh stop rest
stop-hbase.sh

Administration

Si l’installation s’est déroulée sans encombre, les URLs suivantes devrait être disponibles:

Hadoop Map/Reduce Administration: http://localhost:50030
Hadoop File System Browser: http://localhost:50070
Hadoop Task Tracker Status: http://localhost:50060
Hue: http://localhost:8088

Stockage et traitement massif avec Hadoop

2010-11-26T00:40:00+01:00

Apache Hadoop est un système pour construire des infrastructures de stockage partagé et d’analyse adaptées à des volumes larges (plusieurs terabytes ou petabytes). Les clusters Hadoop sont utilisés par un large éventail de projets R&D pour un nombre croissant d’acteurs du web (Yahoo!, EBay, Facebook, LinkedIn, Twitter) et leur taille ne cesse d’augmenter. Yahoo! regroupe 45000 machines dont le plus large cluster reuni 4000 serveurs et stocke 40 PB tandis que Facebook a rapporter stocker 20 PB sur un même cluster HDFS (pour Hadoop Distributed File System).

Les dotcoms furent les premières sociétés à voir leur volume de données croître exponentiellement. Beaucoup ont fondé leur modèle économique sur le traitement de ces données. Autant Google que Facebook tirent l’essentiel de leur revenu de l’analyse de données à des fins publicitaires. Ne pouvant attendre les éditeurs traditionnels, ces sociétés ont lourdement investi dans le développement de nouveaux logiciels pour faire face à cette explosion tout en exploitant de nouveaux concepts. Aujourd’hui, grâce au model de l’Open Source, ces technologies sont présentes dans un grand nombres d’industries et deviennent un composant clé de plusieurs sociétés et services gouvernementaux.

Hadoop, l’implémentation Open Source de l’infrastructure Google, fait suite à la publication par Google de deux documents. Le premier, publié en 2003, décrit l’architecture de GFS (pour Google Distributed Filesystem). Le second, publié en 2004, introduit le paradigme Map-Reduce. A cet époque, Doug Cutting, aujourd’hui chez Cloudera, travaillait sur Nutch, un logiciel Open Source de la fondation Apache incluant un aspirateur Internet et un moteur de recherche. Les besoins en stockage et capacité de calcul de Nutch ont conduit à l’implémentation des travaux de Google en ce qui deviendra Hadoop.

Node HBase, client NodeJs pour Apache HBase

2010-11-01T00:40:00+01:00

HBase est la base de données de type “column familly” de l’écosystème Hadoop construit sur le modèle de Google BigTable. HBase peut accueillir de très larges volumes de données (de l’ordre du tera ou du peta) tout en maintenant une haute disponibilité et des temps de réponses rapides.

Adaltas a mis en ligne un client Node pour HBase qui utilise les webservices REST (aussi appelés Stargate) et le mode de transport JSON. L’intégration des services est complète et le code entièrement couvert par des tests unitaires.

De plus, j’ai contribué le patch activant la mise à jour des schémas permettant ainsi de modifier la structure et la configuration d’une table en utilisant les webservices.

Masson, build tool pour NodeJS

2010-10-05T00:40:00+02:00

Retrouvez Masson sur Github: http://github.com/wdavidw/node-masson

J’ai publié ces derniers jours plusieurs librairies pour Node. Je parlerai aujourd’hui de Masson, un projet similaire à Make, Ant ou encore Rake. Masson est donc un projet JavaScript pour l’environnement Node. Pour rappel, Node est basé sur le moteur V8 qui anime Google Chrome et fonctionnement de manière asynchronisé.

Description

Masson est une librairie permettant d’organiser et d’exécuter des tâches. Une tâche est une ou plusieurs actions regroupées ensemble et identifié par un nom, c’est-à-dire une clé. Chaque exécution de tâche peut dépendre de l’exécution antérieure d’autres tâches. Et puisque Node offre le bénéfice d’être asynchrone, l’API de Masson reflète ce model et il suffit d’appeler la fonction out pour marque la fin d’une tâche et continuer l’exécution du workflow.

Un rapide exemple

L’exemple ci-dessous crée 3 tâches. La première, ‘clean’, nettoie le code source; la seconde, ‘test’, teste le code source; la troisième, ‘build’, lance les deux tâches précédentes et crée une archive.

   var masson = require('masson');
  masson([{
      target: 'clean',
      callback: function(){
          /* do some cleaning */
          this.out();
      }
  },{
      target: 'test',
      callback: function(){
          /* do some testing */
          this.out();
      }
  },{
      target: 'build',
      depends: [ 'prepare', 'clean' ],
      callback: function(){
          /* do some archiving */
          this.out();
      }
  }],'build');

C’est simple et complet. A noter aussi les points suivants:

Masson fournit plusieurs APIs alternatifs
Les targets peuvent partager des arguments les unes avec les autres
Méchanisme d’évènements par extension de la class EventEmitter de Node
Intégration avec NPM (Node Package Manager)
100% Open Source (license MIT)

Présentation de MapReduce

2010-06-26T00:40:00+02:00

Les systèmes d’information ont de plus en plus de données à stocker et à traiter. Des entreprises comme Google, Facebook, Twitter mais encore bien d’autre stockent des quantités d’information astronomiques en provenance de leurs clients et doivent être en mesure de les servir par les meilleurs recommandation tout en assurant la pérennité de leurs systèmes.

MapReduce est un moyen de modéliser un programme pour traiter de large volume de donnée. Par large, on entend massif, par exemple de l’ordre du petabytes. Orginallement créer par Google et décrit en détails dans la publication ”MapReduce: Simplified Data Processing on Large Clusters” publiée en 2004, une implémentation Open Source existe au travers d’Hadoop et de son écosystème de la fondation Apache.

Une tâche MapReduce est constituée de 2 phases. Le développeur implémente une fonction “map” qui décompose une donnée en clé/valeur et une autre fonction “reduce” qui fusionne toutes les valeurs associées à une même clé. Combinées entre elles, ce paradigme permet d’exprimer un grand nombre de problématique.

Le grand avantage de cette méthode est ça faculté de décomposer un processus en plusieurs tâches distribuables sur un très grand nombre de machines normales. Par machines normales, on entend des serveurs dont le prix peut varier entre 3000 et 5000 euros. Pour prendre un exemple concret, en 2010, nous avons commandé des serveurs à 4500 € constitués de 2 processors AMD Optéron à 8 coeurs, 32 Go de RAM et 4 disques de 1T à 7500 tours. Deux machines à 2000 euros chacune auraient très bien pu faire l’affaire. Nous avons opté pour cette configuration à cause de l’économie de place engendrée.

Le traitement des données est réparti sur l’ensemble des serveurs du cluster sans pénalité d’échelle. Si vous données doublent, vous doublez le nombre de machines. Si vous avez besoins de plus de puissance de calcul, idem.

Pour le programmeur, le travail se limite à la création de tâches MapReduce qui sont facile à comprendre et à écrire. Le système se charge des détails dont le partitionnement des données, l’exécution et la coordination des tâches, la duplication des informations en cas de panne machine et la communication entre elles.

Je vais terminer cet article par un exemple en JavaScript pour illustrer le concept. Le but de l’exercice est de compter le nombre d’utilisateur pour un même code postal, partant de données CSV comprenant 3 utilisateurs avec leur nom et leur code postal comme champs.

Le fichier source (format CSV)

Hadoop,75006
Cassandra,75019
Hive,75006

La fonction “map” (en javascript) L’argument fournit, “value” correspond à une ligne de notre fichier source. Cette ligne est convertie sous forme d’array comprend 2 éléments: le nom de l’utilisateur et son code postal. Finalement, la fonction “emit” prend 2 arguments qui sont la clé à émettre et la valeur associée soit le code postal pour la clé et 1 pour signifier que ce code postal a été rencontré une fois.

    function map(row){
        row = row.split(',');
        this.emit(row[1],1);
    }

La fonction “reduce” (en Javascript) Les argument fournits sont une clé et les valuers associés à cette clé. Ils résultent de la fonction “map” appelée précédemment. L’argument “key” est donc un code postal et l’argument “values” une array de nombre. Attention toutefois, la function reduce peut être appelée plusieurs fois et son écriture doit prendre cela en compte. MapReduce étant destiné à de très larges volumes, values pourrait autrement prendre des proportions trop grandes. Ici, values est consituée de numéros “1” la première fois mais ce nombre sera différent si la méthode est appelée à nouveau.

    function reduce(key,values){
        return values.reduce(function(previous,current){ return previous + current })
    }

Le résultat final

75006, 2
75019, 1

Node.js, JavaScript côté serveur

2010-06-12T13:25:00+02:00

En attente du prochain grand language (NBL pour Next Big Language), cela fait maintenant 3 ans que je prédis à mes clients un bel avenir au JavaScript comme langue de programmation pour les applications serveurs. Mon argumentation se fondait essentiellement sur son esthétisme, sa simplicité et sa nature dynamique. Conçu en 1995 par Sun Microsystems (racheté par Oracle) et Netscape (racheté par AOL), son intégration dans les navigateurs Internet a largement diffusé le language mais ce n’est qu’à partir de 2004 au travers de la génération AJAX et d’applications Web telles que Gmail et Google Maps que le language a reçu ses lettres de noblesse et gagna l’attention des professionnels.

Malgré quelques efforts infructueux, son utilisation était cantonnée aux postes clients, c’est à dire aux navigateurs Internet dans lesquels il permet de dynamiser les pages Web. Depuis quelques années, des solutions sont apparues dans la communauté Open Source. Je pense notamment à Helma, d’un fonctionnement traditionnel au sein d’une machine virtuelle Java et donc aisément intégrable au large écosystème Java, mais aussi à des solutions plus innovantes comme Jaxer, dont la particularité et de créer un environnement de type navigateur (comme la manipulation du DOM) sur le serveur. De tous, c’est sans doute Narwhal qui me laissa la plus forte impression par son architecture simple et la modularité de l’interpréteur JavaScript.

Durant ces dernières années, j’ai suivi avec attention l’actualité autour des solutions serveurs, testant chacune d’entre elles et analysant leurs approches. Au vu du trafic généré par chaque article traitant du sujet, je m’aperçus à cette occasion que je n’étais pas isolé. Mais aucun des projets n’avait pu me convaincre d’abandonner ce mauvais garçon qu’est PHP. Jusqu’à il y a quelques mois avec l’apparition de NodeJs.

Revenons un peu en arrière. L’AJAX marqua l’importance et le besoin de performance des navigateurs et l’interpréteur JavaScript est une donnée essentielle des applications Internet dites riches (RIA pour Rich Internet Application). Les éditeurs Mozilla et Microsoft rejoint par Apple avec Safari et plus récemment Google avec Chrome se sont lancé dans une course à l’optimisation. Cette saine compétition a donné naissance à de nouvelles générations d’interpréteurs que sont TraceMonkey pour Firefox 3.6, SquirrelFish pour Safari 5, Carakan pour Opera et V8 pour Chrome. Longtemps à la traîne, même Microsoft se prend au jeu dans la version 9 d’Internet Explorer. Aujourd’hui, le JavaScript est sans nul doute le language concentrant l’essentiel des efforts de développement.

Mais il y a une autre raison pour laquelle JavaScript est rapide et un excellent choix côté serveur. Par nature, c’est un language orienté évènement en opposition aux serveurs orienté thread. Cette caractéristique du language vient de ses origines ou il était destiné à fonctionner à l’intérieur des navigateurs Internet et il était essentiel de supporter les évènements utilisateurs sans saturer l’ensemble du navigateur à chaque action. Traditionnellement, les applications serveurs sont écrites sous un mode thread dit bloquant. C’est le cas pour les applications PHP et CGI et l’essentiel des applications Python, Ruby ou Java.

Je vais essayer d’être aussi clair que possible. Lorsqu’un serveur reçoit une requête, par exemple l’envoi d’un formulaire, le serveur met à disposition une thread et lance l’application qui effectue ses opérations les une après les autres (connexion à une base de donnée afin de valider le nom et le mot passe de l’utilisateur, écriture dans un fichier de log,…) avant de finalement retourner la réponse au formulaire et de fermer la thread. Or le nombre de thread est limité et ces applications génèrent rapidement des erreurs lorsque celles-ci arrivent à saturation de la mémoire. Chaque thread est monopolisée jusqu’à la fin de l’ensemble des opérations. Ces opérations comme l’écriture d’un fichier prennent énormément de temps en comparaison de la vitesse d’un CPU et ce n’est que pur gâchis. Pour les applications avec de forts volumes de trafic, chaque requête doit être codée pour être la plus courte possible. Contrairement, dans un environnement évènementiel, ces mêmes opérations sont dites non bloquantes car en attendant de requêter sur une base de donnée ou d’écrire dans un fichier, le serveur peut continuer à effectuer d’autres taches dans une même thread.

L’absence d’alternative non bloquante peut même devenir handicapante pour certains scénarios tels que le téléchargement de fichiers volumineux, le regroupement de résultats en provenance de plusieurs backends et, non des moindres, le support du protocole Bayeux (Comet) ouvrant les voix du HTTP push.

Partant du postulat que l’essentiel du temps des applications serveurs est dépensé à attendre les résultats des opérations I/O (accès réseaux vers bases de données, lecture et écriture sur le système de fichier,…), la programmation évènementiel est particulièrement adaptée à l’environnement serveur. Twisted en Python et EventMachine en Ruby répondent à cette problématique mais aucun ne bénéficie de la force d’un language intégrant nativement ces fonctionnalités.

Revenons à Node. Décrit par son auteur comme une excellente fondation au développement d’applications Web, il est basé sur le moteur JavaScript V8 développé, utilisé et open-sourcé par Google pour son navigateur Chrome. Celui-ci est l’un des plus rapide du marché (pour ne pas dire le plus rapide) et s’améliore à chaque nouvelle version. Tout dans le développement de Node est construit et optimisé dans une optique évènementielle ce qui réduit considérablement les possibilités d’écrire une application lente parce que faisant appel à des opérations I/O bloquantes. Rapidement, la communauté Open Source a reconnut le potentiel de cette plateforme et un riche éco système se construit autour comprenant drivers (CouchDB, MongoDB, Redis,…), libraries (Haml, Sass, Expresso, …) et frameworks (Connect, Express, …).

Pour le compte d’un client, j’ai prototypé une application et la prise en main est rapide, simple et intuitive. Le code est élégant, court et lisible. Tout ce que j’attendais des promesses du JavaScript côté serveur. Pour la réalisation du proto et malgré la jeunesse de l’écosystème, je n’ai eu à manquer de rien. Voir cela m’a permis d’utiliser des concepts empruntés des univers Ruby et Python qui font défaut à celui de PHP (une pensée particulière pour SASS). Pour ceux familiers dans le développement d’applications clients riches en JavaScript, la transition sera quasiment instantanée.

Pour résumer Node en quelques phrases:

JavaScript est fait pour l’évènementiel: la programmation par callback est familière aux développeurs d’applications AJAX et, pour se faire, la syntaxe des fonctions anonymes et le support des closures est adapté et élégant.
Node est construit sur Javascript: de part sa présence dans les navigateurs, c’est peut-être le language le plus programmé au monde et bénéficie de 15 ans d’expérience.
Node se stabilise: l’API de Node gagne en maturité et est proche de se finaliser.
Node a un écosystème: de nombreuses librairies sont disponibles, toutes en Open Source, de nouvelles apparaissent et toutes partagent une bonne qualité de réalisation.
Node est simple et petit: la documentation se promène d’un seul regard et permet de rapidement connaitre ses fonctionnalités.
Node est rapide: le moteur V8 et l’architecture non bloquante en font l’une des architectures les plus puissante du marché, spécialement pour les requêtes longues et intensives en I/O.