A la mi-juillet, le livre « Entreprise Data Workflows with Cascading » fut publié chez O’Reilly. Son auteur Paco Nathan est le « data science director » de « Concurrent, Inc », l‘entreprise ayant rendu Cascading open source et encore principal moteur de son évolution. Par ce blog, nous vous avions déjà présenté Cascading , ainsi que Cascalog et relayé l’annonce concernant Lingual . La sortie de ce livre coïncide avec l’apparition d’un nouveau venu dans l’écosystème ( Pattern ) et fournit une vue compréhensible des challenges concernant le BigData dans le monde réel de l’entreprise. Il est illusoire de vouloir résumer ce livre sans plagier le livre en lui-même ou encore répéter les précédents articles de ce blog. On retiendra cependant deux points importants concernant l’optimisation et le data mining.
Concernant l’optimisation
Hadoop MapReduce fournit des primitives pour le traitement de large volumes de données. C’est une approche puissante mais insuffisante en terme d’abstraction. Et c’est pour cela que des solutions telles que Hive ou Pig sont apparues. Dans les deux cas, il s’agit de fournir un langage plus haut niveau décrivant le flot de données qui sera ensuite découpé en un graphe (DAG) de jobs MapReduce. Cascading se distingue par le fait qu’il s’agit « simplement » d’une API java exposant les primitives pour composer ce flot. Le nouveau langage plus abstrait est fourni par d’autres projets. Scalding utilise scala pour traduire de façon succincte et type-safe ces concepts qui sont loin de cohabiter gracieusement avec l’approche de Java. Et Cascalog utilise clojure pour fournir une abstraction supplémentaire en empruntant des principes de la programmation logique. Le découpage est donc différent, mais il reste pertinent de se poser la question de l’optimisation de ce flot. Comment peut on comparer sur ce point Pig, Hive et Cascading? C’est une question en soi complexe mais Paco Nathan explicite le status que vous avez sans doute découvert en utilisant ces différentes solutions.
1) L’optimisation de Cascading est plus simple que Pig ou Hive et fournit ainsi une prédictibilité nécessaire au monde de l’entreprise.
Cascading optimise le plan physique de la requête mais contrairement à Pig et Hive ne change pas son plan logique. Un exemple simple de ce principe est que lors du développement d’un job Cascading, le développeur va devoir spécifier lui-même le type de jointure à effectuer alors que pour Pig et Hive, le type peut être laissé au bon jugement de l’optimisateur. En soi, il semblerait que c’est un désavantage. Et clairement, si le développeur ne connait pas les volumétries qui doivent être gérées, cela peut conduire à des performances sous-optimales. Pour des requêtes ad-hoc, Pig et Hive sont donc des solutions plus adaptées car elles vont réduire le temps d’accès à l’information. Mais la construction de flot avec Cascading vise le monde de l’entreprise : c’est à dire des traitements récurrents sur des volumes connus où l’on souhaite être capable d’estimer l’évolution du temps traitement global. Cette simplicité, entraînant une prédictibilité, est donc un avantage selon le point de vue de l’auteur. La réalité est bien sûr plus mitigée que cela et tout va dépendre de votre cas d’utilisation, mais c’est un point important à connaître.
Concernant le data mining
Les algorithmes sont importants mais ce qui fait la différence est souvent le volume de données et non les algorithmes en eux-mêmes. Avec BigData, il est possible de découvrir les signaux faibles dans vos données et cela peut avoir un impact fort sur votre métier. La grande question est de savoir comment s’y prendre. Mahout est une libraire java connue fournissant des implémentations pour Hadoop d’algorithmes standards. Mais fondamentalement, cela signifie que pour juger de leur pertinence, il faut connaître Java mais Java est loin d’être le langage le plus maîtrisé par ceux ayant un certain recul sur l’utilisation des différents algorithmes. On parle actuellement beaucoup de DevOps. Pour des questions d’organisation, il est souvent plus simple de créer des silos de compétences. Paradoxalement, pour la réalisation d’un projet, on a besoin justement d’une synergie entre ces différents types de compétences et ces silos sont un désavantage. Un projet BigData inclut bien sûr des devs et des ops mais également des profils plus scientifiques. Comment faire pour travailler ensemble? Un élément de réponse est PMML.
2) Pattern fournit un moteur open source pour utiliser Hadoop avec PMML une description standardisée de modèles prédictifs, formant ainsi un pont nécessaire entre la recherche et l’exploitation.
PMML (ou Predictive Model Markup langage) est un format d’échange standardisé en XML pour décrire des modèles prédictifs. La dernière version 4.1 date de décembre 2011 et désormais PMML inclut également un traitement possible des données en entrée ou en sortie. PMML est développé par le Data Mining Group, les spécifications sont disponibles en ligne et de nombreux produits en ont un support partiel : InfoSphere Warehouse, KNIME, SQL Server, MicroStrategy, R, SAS, Teradata, Tibco, Weka / Pentaho… Si vous souhaitez en savoir plus, le livre PMML in Action est un bon compagnon. Cela dit le format reste du XML, bien qu’il soit lisible et éditable, son véritable intérêt est en tant que format d’échange. Toute la problématique actuelle est de savoir quels sont les algorithmes supportés par votre outil d’analyse et ceux supportés par le moteur d’exploitation (tel que Pattern), et savoir si en ne prenant que l’intersection vous ne passez pas à coté d’une opportunité. Pour cette raison, Mahout ne doit pas être écartée trop rapidement non plus.
Un livre sur Cascading et son écosystème
Le livre est clairement biaisé du fait de l’implication professionnelle de l’auteur (« data science director » de « Concurrent, Inc ») et il ne faut pas s’attendre à une comparaison objective des différentes alternatives existantes. On pourrait par exemple regretter qu’il n’y ait aucune mention de la suite. En effet, Google a également observé la nécessité de mettre en place un outil pour augmenter la productivité avec (leur) MapReduce. La publication FlumeJava décrit une partie de ce cheminement et énonce la démarche de MSCR fusion. Inspiré par cela, Cloudera a lancé Crunch qui est désormais un projet apache à part entière (TLP). Google a travaillé sur une surcouche scala à FlumeJava : Cascade. Et Crunch possède aussi maintenant sa surcouche scala avec Scrunch. En bref, Cascading n’est pas la seule solution pour décrire des flots MapReduce dans un véritable langage de programmation. Mais à la défense de l’auteur, le fait de ne pas mentionner cet historique l’empêche aussi de justifier le choix de Cascading : une communauté forte et une libraire éprouvée par le temps. En conclusion, une libraire définitivement à considérer.
« Entreprise Data Workflows with Cascading » n’est pas un livre détaillant les APIs, ni destiné à apprendre « Cascading en 21 jours », ni encore destiné à creuser les détails d’implémentations. Si c’est cela que vous chercher, l’ensemble de la documentation est en ligne. Ce livre es t le meilleur aperçu disponible actuellement de ce que peut apporter Cascading dans vos projets Hadoop. Et en soi, il devrait être une lecture obligatoire pour tout projet java partant de 0 dans l’univers Hadoop, et ce indépendamment du choix fait au final.