Convention de commit

Des conventions de commit  ?

Convention de code : OK

Convention de commit : pourquoi ?

Raison simple :

  • éviter les commit <blank>
  • éviter les commit « je sais pas quoi mettre »

Les commit on aussi un autre rôle fondamental : si il sont bien écrits ils permettent de générer automatiquement (Eclipse et Aptana le permettent par exemple) les changelog de votre application.

Convention

Voici la convention que j’utilise.
Elle est très fortement inspirée de la convention Angular2

[<User>] [<Project (with major version)>] <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Les types :

  • feat (feature)
  • fix (bug fix)
  • docs (documentation)
  • asset : ajout/maj statics, libs js externe, framework css externe …
  • style (formatting, missing semi colons, …)
  • refactor
  • test

    Scope :

  • DAO
  • Service
  • Tools
  • UI
  • API

Pourquoi ajouter le User alors qu’il est déjà géré par le système de gestion de source (TFS, Git, SVN) ?

Dans mon cas j’ai ajouté le user car sur le projet actuelle je me retrouve

  • avec un problème de restriction de licence : donc 2 user sur le même compte
  • à commiter parfois sur le PC d’un collègue

 

Spark DataFrame vs RDD : petit bench appliqué à la recherche d’occurrences de mots.

Interogation

La littérature (exemple ici) nous indique que les DataFrame Spark sont bien plus rapide que les RDD.

Intuitivement une surcouche (DataFrame est une surcouche de RDD) est moins rapide que son entité mère.

DataFrame utilise l’optimiseur Catalyze afin d’optimiser, compiler, ré-organiser… les actions du DataFrame et peux ainsi améliorer les performance par rapport à RDD.

Cette optimisation est-elle toujours viable ?

Je me suis posé la question sur des domaines non adaptés à la structure des DataFrame.

Le DataFrame est une matrice : structure très adapté à la description de mesure multi-variables (et donc aux traitement de statistique et de machine learning)

Que se passe-t-il sur des traitements non orienté matrice ?

Domaine de test

Je me suis donc penché sur une source non structurée : un ensemble de simple fichier texte (une dizaine de romans bien épais dans le style « guerre et paix ») pour valider (ou non) l’optimisation de DataFrame par rapport à RDD.

Intuitivement RDD semble plus proche (car orienté données plus brute que DataFrame) de ce type de donné et plus simple à manipuler : on peut abuser des fonctions lambda avec RDD tandis que DataFrame pousse à utiliser les méthodes de son API.

Jeux de test

Il suffit de télécharger un gros livre, roman, encyclopédie… en format texte (UTF8) sur Internet : il en existe des centaines en domaine public.

Source

Préparation : import, context, variables d’environnement..


import os, time


os.environ['SPARK_HOME'] = '/home/lde/spark-2.0.0-bin-hadoop2.7'
os.environ['PYSPARK_PYTHON']='python3'


from pyspark import SparkContext
from pyspark.sql import SQLContext
from  pyspark.sql.functions import length
from pyspark.sql.functions import split, explode


sc = SparkContext("local", "Simple App")
sqlContext = SQLContext(sc)
dataFile = "./data_book/*.txt"

RDD


textFile = sc.textFile(dataFile)
start=time.time()
rd1=textFile.flatMap(lambda x: x.split(" ")) \
          .map(lambda word : (word.lower(),1)) \
          .reduceByKey(lambda a,b : a+b) \
          .filter(lambda v : v[1]>50) \
          .filter(lambda v : len(v[0])>5) \
          .coun()
stop=time.time()
print("RDD : ",int(1000*(stop-start)))

DataFrame


df=sqlContext.read.text(dataFile) 
start=time.time()
df1=(df
      .select(explode(split(df.value," ")).alias("word"))
      .groupBy("word")
      .count()    
      .withColumnRenamed("count","wordCount")
      .filter(length("word")>5)
    ).cache()
df2=(df1
      .filter(df1.wordCount>50)
      .orderBy(df1.word.desc())
      .count()
)

Le source du DataFrame contient la création de 2 Dataframe alors que la création du RDD n'en demande qu'un.

Je rédigerai un article sur ce point ainsi que sur les problème de nommage de colonnes générées qui sont, à mon sens, assez maladroit et facteur de bug.

Bench

On lance (boucle) 10 itérations de test. Les temps sont exprimés en millisecondes.

          |  1    |  2   |  3   |  4   |  5   |  6   |  7   |  8   |  9   |  10  | 
RDD       | 10320 | 7320 | 7184 | 7387 | 7509 | 7146 | 7186 | 6836 | 7533 | 7496 |
DataFrame | 17737 | 9671 | 7982 | 7767 | 7585 | 7667 | 7185 | 7002 | 7092 | 6693 |

Remarques :

  • La première itération est bien plus longe à traiter que les suivante
    • Lié à l'environnement de test ?
      • Source éxécuté via l'EDI Spyder
    • Problématique sachant qu'en BigData le but est de lancer 1 fois un (gros) processus et non de l'itérer (hormis Spark Streaming mais je ne vais pas parler d'un domaine que je ne maîtrise pas encore)
  • Le DataFrame donne des résultats moins performants que le RDD (pour ce cas précis)

Conclusion

  • Le DataFrame n'est peut être pas adapté à tous les type de données, en particulier les données non structurées.
  • Je me suis peut être fourvoyé dans mon bench : en effet je suis un "junior" en Spark
  • Réflexion :
    • Tester un modèle hydride
      • RDD pour l'ETL des données non structurées, puis DataFrame pour la partie traitement métier.

N'hésitez pas à commenter, proposer des alternatives à ce code 🙂

Biographe :

Ubuntu 16.04 et problème de connexion SSH par clef

Mise à jour d’une de mes machines vers Ubuntu  16.04  et depuis impossible de se connecter en SSH via clef.

Mon système me demande irrémédiablement le mot de passe du serveur.

Après une petite recherche sur le net il s’avère que Ubuntu 16.04 a besoin que sa clef publique soit dans le fichier ~/.ssh/authorized_keys

Hors les fichiers générés par ssh_keygen sont placé en ~/.ssh/id_rsa.pub ou ~/.ssh/id_dsa.pub

Un simple mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys   (ou id_dsa.pub) fera tout rentrer dans l’ordre.

 

[Projet Favela] Monter un cluster Linux : matériel utilisé.

Suite à mon article précédent : [Projet Favela] Monter un cluster Linux : le matériel je vais détailler l’ensemble du matériel utilsié pour monter mon cluster.

Favela est un cluster composé de 5 RaspberryPi.

On a donc besoin de composant pour alimenter, mettre en réseau et stocker(il n’existe pas de baie pour ce type de matériel on va devoir bricoler)  5 RaspberryPi.

 

Partie informatique

Mon budget : 161.02€

Budget « plein tarif » (avec des RaspberryPi 2 à 37.90€) : 275.52€

Budget « plein tarif » (avec des RaspberryPi 3 à €) :311.52€

Ce matériel suffit à assembler votre cluster, mais voire 5 cartes mère traîner sur un bureau, des câbles dans tous les sens…  ce n’est pas très pro ni pratique.
J’ai donc (comme de nombreux autre) opté pour des logo afin d’assembler mon cluster.

Partie stockage

Budget : 60€

Budget total

Mon budget total : 220€

Budget Total RaspberryPi 2 : 335€

Budget Total RaspberryPi 3 : 371€

Alternative

Et si on se montait un mini cluster avec des RaspberryPi Zero ?

Je vais vous rédiger un mini article ou je compare les performances RPI1B+ vs RPI0 avec Redis

 

[Projet Favela] Monter un cluster Linux : le matériel

Pour mes besoins d’auto-formation en BigData (et aussi car j’adore mon métier) j’ai décidé de me monter un cluster de test BigData.

Ce projet n’aurait pu naitre sans l’émergence des « cartes de développement » (RaspberryPi et suivants).

Architecture du cluster.

favela

Le cluster est composé de 5 machines : c’est le nombre minima (à mon goût) pour réaliser un grand nombre de test/maquettes.

  • 1 client.
    • Point d’entrée au cluster tant en local mais surtout depuis l’extérieur de mon LAN
      • SSH est le seul port ouvert et seule cette cette machines est exposée au net
    • En charge des backup des jeux de données des maquettes
    • Monitoring (température, charge processeur…) des « travailleurs » : le maître et les 3 esclaves
  • 1 maître
    • En charge de répartir la charge, les data… entre les 3 esclave
  • 3 esclaves
    • En charge de gérer les data, se répliquer, répondre aux requêtes …

Type de matériel

Comme énoncé plus haut les carte de développement sont adaptées à ce type de maquettes pour plusieurs raisons

  • le prix : maximum 50€ pour un noeud (carte mère+stockage)
  • la place : le cluster (photos à venir) tient sur 40cmx40cmx25cm
  • la consommation électrique < 10Watt à vu de nez (mériterait quelques mesures)
  • le bruit : aucun bruit à l’opposé des serveur traditionnels.

Pour toutes ces raisons les cartes de développement ont été retenue face aux solutions traditionnelles.

Choix RaspberryPi

Il existe des concurrents (OrangePi, BananaPi, ODroid…) au RaspberryPi.
Certains sont plus puissants, possèdent de meilleur composants (processeur, carte réseau gigabit)…

J’ai pourtant fait le choix du Raspberry Pi. Voici les raisons :

  • Une parfaite intégration logicielle/matérielle
    • La distribution Raspbian « colle » au plus près (pas faux non plus pour la version Ubuntu Server)  des cartes RasberryPi.
    • Un bon matériel ne vaut que si il est propulsé par un bon logiciel.
  • Facilité d’achat
    • On peut acheter des carte en France (et en Angleterre), aucun problème de stock, livraison rapide
    • Sauf pour le RaspberryPi Zero qui est en rupture de stock permanent mais il n’est pas utilisé dans ce cluster
  • Suivit dans le temps et rétro-compatibilité de cartes
    • Malgré l’arrivé de nouvelles cartes les anciennes sont toujours disponibles à la vente ce qui permet de faire évoluer son cluster dans les mois (années) à venir avec un matériel homogène
    • La rétro-compatibilité permet de faire tourner toutes les cartes (quelques soit l’ancienneté ou la puissance) avec le même OS : Rasbian
      • Attention pour Ubuntru server seul les RaspberryPi 2 et 3 sont utilisable
        • Du au fait que Ubuntu Server ne fonctionne qu’à partir de la V7 du processeur ARM.

Un cluster  »maquette’ ou viable en prod

Un tel type de cluster semble adapté à la formation, le maquettage… mais qu’en est-il de l’utilisation en production ?

  • Les performance sont elles adaptées
  • Pour quel type d’application, service, architecture un cluster Raspberry Pi est il viable ?

Pour l’instant je n’ai pas de réponse, elles viendront au fur et à mesure des tests et maquettages.

Le budget

  • Pour ma part mon cluster ne m’a coûté qu’environ 250€
    •  J’ai pu trouver 5 RaspberryPi 1 B+ à 15€ TTC ce qui a fortement baissé le prix du cluster
  • A plein tarif comptez environ 400€ pour un cluster 5 machines.

A venir

  • Listing complet du matériel utilisé pour monter le cluster.
  • Photo du cluster
  • Article « Et si le RaspberryPi Zero était un bon candidat pour un cluster ? »
  • Redis : bench sur RaspberryPi 1, 2 et Zero

RaspberryPI 2 et 3 : sortie de 4 distro Ubuntu.

A peine sorti le RaspberryPi 3 et voila 4 distrib pour RaspberryPi 2 et 3 proposées :

Ces distribution en sont pas compatibles RaspberryPi 1 (compatible à partie du ARM V7, le 1 est en V6).

Un seul Download par disto donc  pas de portage (aucune trace dans le changelog) 64bits : juste (et c’est déjà énorme vu les délais) une adaptation aux nouveaux hardware (wifi et BlueTooth) du RaspberryPi3.

CURL : Uploader un fichier en ligne de commande vers un serveur WebDav

Cas d’utilisation.

Devoir travailler sur une plateforme OpenWRT ne possédant pas de client SSH.

Comment faire pour récupérer des fichier de cette cible ?

Une solution – si CURL est présent sur la cible – consiste à :

  • Installer un serveur WebDAV ‘basique’ (sans authentification)
    • nb : penser à rédiger un article sur ce thème
  • Uploader les fichiers – de la cible vers le serveur – via CURL

Pour uploader un fichier sur notre serveur WebDAV


curl -T myFile.sh http://10.10.254.120/myRepo/myFile.sh

Screen : Incompatibilité du partage de terminal sur des serveur multi-réseau ?

Cas d’étude vécu aujourd’hui.

2 développeur (dont moi) travaillant chacun sur un réseau local distinct.
Besoin de travailler ensemble sur une maquette présente sur un Raspberry Pi.

J’opte alors pour screen et surtout pour son option de partage de terminal  offrant la capacité de travailler à plusieurs sur un même terminal.

Un un réseau local aucun problème pour partager un terminal.

Mais impossible de partager (-x) et même de lister (-r) les terminaux créés – sur un réseau A – à partir d’un réseau B (voir schéma).

screen

 

Fort dommage 🙁

Si vous avez la moindre idée pour contrer cette limitation n’hésitez pas à me contacter.

 

 

[Update] Installer (et exploiter) Docker sur des architectures « non supportées » (Raspbian/Intel 32 bits)

[Update] Docker natif sur la dernière version de Jessie

Suite au dernier Update de Raspbian  (Release date: 2016-02-09) docker s’installe d’un simple apt-get install docker.io

Limitations constatées (par rapport à la version Hypriot) :

Disparition du -f pour le build

Impossible de spécifier le Dockerfile de cette manière

<code>

docker build -t favela/lampbase:1.0.0   -f ./lampbase.dockerFile   .

</code>

Obliger de créer un fichier Dockerfile (avec un D majuscule) et de la copier dans un répertoire (ex : lampbase)

<code>

docker build   -t favela/lampbase:1.0.0  ./lampbase/

</code>

Un simple docker pull resin/rpi-raspbian:jessie plante (trove pas le endpoint) : je repars donc sur la version Hypriot.


 

Docker ne supporte que les architectures 64 bits.

Cela est fort dommage car cela nous prive de nombreuses target de test et/ou d’exploitation.

Heureusement il existe des initiatives pour porter Docker vers des architectures autres :

Debian Intel  32 bits


apt-get update

apt-get install docker.io

Plus qu’à tester (en root) avec un « docker ps  »

Raspbian (Raspberry Pi)

  • La team Hypriot a réalisé un formidable travail de portage de docker sur Raspbian.
  • Téléchargez le .deb à l’adresse suivante partie « Hypriot Docker Debian Packages for Raspberry Pi »
  • Puis un simple

dpkg -i package_name.deb

 

Et cela fonctionne même sur un simple Raspberry Pi Zero !

PS : je n’ai testé que sur Debian Jessie pas sur Wheezy.

PS2 : le service docker n’est pas lancé au boot,  pensez à le lancer avant vos tests.


service docker start &amp;amp;amp;amp;&amp;amp;amp;amp; service docker status

Ubuntu ARM



apt-get install docker.io 

 

Attention au bon choix de vos machines docker

  • Attention : les images Docker récupérées sur le hub docker sont en majorité des images Intel 64bits : donc incompatibles avec nos target de test.
  • Pensez à bien vérifier la compatibilité de vos images.

Des test à la Prod

  • Si vos dockerfiles sont bien écris , le passage d’une plate-forme de test à une prod 64 bits ne devrait pas poser de problème (en restanbt sur le même type de distribution évidement, par exemple d’une Raspbian à une Debian) : seul le FROM devra être changé.