Dans le sillage d'Hana, Cloudera propose en mode open source Kudu, une base colonne permettant d'exécuter des requêtes analytiques en mode SQL.
Mais elle permet aussi d'insérer, de modifier et de lire des données en mode random, ce qui évite de multiplier les bases NoSql si vous travaillez sur des données structurées.
Il s'agit d'un système de stockage de données disponible à partir d'API Java et C++, mais aussi interrogeable à partir d'Impala et de Spark.
La version 1.0 est désormais disponible => ready for production. Cependant, effectuer encore un POC avant de vous lancer.
Pour aller plus loin: Kudu, the white paper
Comme pour Hana, l'objectif final d'une telle base est d'effectuer de l'analytique temps réel et non plus d'avoir un délai entre l'ingestion des données et la production de reportings.
mercredi 28 décembre 2016
dimanche 25 septembre 2016
Data science
Un article qui illustre très bien comment construire un outil de prédiction en utilisant Kafka, Spark ( streaming, mlib ), Kudu et Impala :
Building a prediction engine
Building a prediction engine
lundi 8 août 2016
Impala
Impala est un outil disponible sur la plate-forme Cloudera; il permet d'exécuter des requêtes analytiques au-dessus d'HDFS avec comme cible une concurrence d'accès de quelques dizaines d'utilisateurs. Vous pouvez envisager quelques centaines d'utilisateurs, mais là, il vous faudra au moins quelques dizaines de noeuds pour bien amortir la charge.
Quelques présentations pour bien appréhender cette nouvelle génération d'optimiseur multi-noeud au-dessus d'un système distribué de fichiers comme HDFS :
- How Impala works.
- How to tune Impala.
- Impala's analysis by G.Rahn.
Quelques présentations pour bien appréhender cette nouvelle génération d'optimiseur multi-noeud au-dessus d'un système distribué de fichiers comme HDFS :
- How Impala works.
- How to tune Impala.
- Impala's analysis by G.Rahn.
samedi 9 avril 2016
Spark
Hadoop est la base d'un date lake avec son système de fichier distribué, HDFS. Pour info, il en existe d'autres comme CEPH ( open source ) ou GPFS ( IBM ). Il serait aussi intéressant de voir d'où forke celui de Scality dans la mesure où il est capable de traiter un nombre très considérable de vidéos.
Au dessus de ce shared data storage, d'autres moteurs peuvent être envisagés pour accélérer les traitements sur les données. Parmi ceux-là, j'ai été frappé par l'émergence et l'adoption ultra-rapide de Spark, un moteur parallèle in-memory disposant d'une API intéressante sur les RDD et d'options variées et multiples ( dataframes, streaming, machine learning ). Pour info, IBM est un gros contributeur de Spark.
Pour découvrir ce logiciel, j'ai lu le livre des "guys" de Databricks: Learning Spark.
En attendant l'opportunité de plonger dedans ...
Au dessus de ce shared data storage, d'autres moteurs peuvent être envisagés pour accélérer les traitements sur les données. Parmi ceux-là, j'ai été frappé par l'émergence et l'adoption ultra-rapide de Spark, un moteur parallèle in-memory disposant d'une API intéressante sur les RDD et d'options variées et multiples ( dataframes, streaming, machine learning ). Pour info, IBM est un gros contributeur de Spark.
Pour découvrir ce logiciel, j'ai lu le livre des "guys" de Databricks: Learning Spark.
En attendant l'opportunité de plonger dedans ...
Hadoop: architecture
Depuis sa création, Hadoop repose sur un modèle où chaque noeud du cluster est identique et où la scalabilité qui tend vers la linéarité est assurée par l'ajout de noeuds. Un noeud repose sur le principe de la colocalité des données et des traitements ce qui permet de soulager le réseau, élément primordial à la naissance de cette technologie. Enfin, il est préconisé comme pour les bases NoSQL d'installer le cluster sur du "bare metal", c'est à dire du dédié à l'opposé du virtuel.
Cependant, comme depuis sa naissance, l'IT a énormément évolué depuis plus de 10 ans et en particulier, les réseaux ont effectué un bond technologique ( Ethernet à 40 Gbs et Infiniband à 56 Gbs ). De plus, les grands comptes ont investi considérablement dans la virtualisation de leur infrastructure au détriment du dédié pour rationaliser leur coût et être capable d'offrir un provisioning beaucoup plus souple.
Vu ces évolutions, de nouvelles architectures Hadoop sont en train d'émerger. La première consiste à virtualiser l'architecture Hadoop. Pour les environnements bas ( développement, recette utilisateur, ... ), le pas est déjà franchi depuis quelques années. Reste à faire évoluer les environnements de production. Pour ce faire, les master nodes ( name nodes, admin nodes, appli nodes, edge nodes, ... ) sont complètement virtualisés, accès disque compris ( SAN ). Reste à préserver la colocalité des traitements et des données pour les data nodes, d'où un accès en mode DAS ou équivalent. Dans ce registre, VMware a fait de considérables travaux sur le sujet et propose désormais une alternative crédible au dédié : VMware big data. En particulier, je vous conseille la lecture du REX chez Skyscape.
Sur ce type d'architecture, le revers de la médaille est la perte de la haute disponibilité fournie par VMware au niveau des data nodes, les disques étant locaux. Il reste aux vendeurs de baies de disques de trouver des alternatives crédibles en terme d'HDFS et de sortir de leur modèle actuel privilégiant l'IOPS ( bases SQL en mode transactionnel ) à la bande passante ( clusters Hadoop en mode batch brassant de grandes quantités de données ). La solution d'EMC, Isilon, est déjà dans la liste des architectures certifiées par Cloudera et Adobe l'a mise en oeuvre.
Mais allons plus loin et considérant maintenant les progrès de la couche réseau. On peut alors envisager séparer la couche compute ( map-reduce ) de la couche storage ( hdfs ). Cela permettrait d'une part de pouvoir créer des pools de noeuds de type compute ( map-reduce, hive, spark, ... ) avec des configurations adaptées ( introduction possible de la GPU ) et non uniformes et d'autre part, de pouvoir spécialiser les noeuds de type storage en données chaudes/froides et ainsi de provisionner du disque magnétique, du SSD ou encore du disque flash en fonction du degré temporel de la donnée.
Dans ce domaine, HP a effectué un gros travail en laboratoire avec sa solution BDRA. Reste à l'éprouver dans le monde réel ...
Cependant, comme depuis sa naissance, l'IT a énormément évolué depuis plus de 10 ans et en particulier, les réseaux ont effectué un bond technologique ( Ethernet à 40 Gbs et Infiniband à 56 Gbs ). De plus, les grands comptes ont investi considérablement dans la virtualisation de leur infrastructure au détriment du dédié pour rationaliser leur coût et être capable d'offrir un provisioning beaucoup plus souple.
Vu ces évolutions, de nouvelles architectures Hadoop sont en train d'émerger. La première consiste à virtualiser l'architecture Hadoop. Pour les environnements bas ( développement, recette utilisateur, ... ), le pas est déjà franchi depuis quelques années. Reste à faire évoluer les environnements de production. Pour ce faire, les master nodes ( name nodes, admin nodes, appli nodes, edge nodes, ... ) sont complètement virtualisés, accès disque compris ( SAN ). Reste à préserver la colocalité des traitements et des données pour les data nodes, d'où un accès en mode DAS ou équivalent. Dans ce registre, VMware a fait de considérables travaux sur le sujet et propose désormais une alternative crédible au dédié : VMware big data. En particulier, je vous conseille la lecture du REX chez Skyscape.
Sur ce type d'architecture, le revers de la médaille est la perte de la haute disponibilité fournie par VMware au niveau des data nodes, les disques étant locaux. Il reste aux vendeurs de baies de disques de trouver des alternatives crédibles en terme d'HDFS et de sortir de leur modèle actuel privilégiant l'IOPS ( bases SQL en mode transactionnel ) à la bande passante ( clusters Hadoop en mode batch brassant de grandes quantités de données ). La solution d'EMC, Isilon, est déjà dans la liste des architectures certifiées par Cloudera et Adobe l'a mise en oeuvre.
Mais allons plus loin et considérant maintenant les progrès de la couche réseau. On peut alors envisager séparer la couche compute ( map-reduce ) de la couche storage ( hdfs ). Cela permettrait d'une part de pouvoir créer des pools de noeuds de type compute ( map-reduce, hive, spark, ... ) avec des configurations adaptées ( introduction possible de la GPU ) et non uniformes et d'autre part, de pouvoir spécialiser les noeuds de type storage en données chaudes/froides et ainsi de provisionner du disque magnétique, du SSD ou encore du disque flash en fonction du degré temporel de la donnée.
Dans ce domaine, HP a effectué un gros travail en laboratoire avec sa solution BDRA. Reste à l'éprouver dans le monde réel ...
samedi 2 janvier 2016
Hive
Dernièrement, j'ai créé une VM linux sous VirtualBox avec l'idée de faire du devops en full linux. Pour ce faire, j'ai choisi Ubuntu 14.04 LTS, une distribution que j'utilise souvent pour tester des produits et KDE pour pouvoir disposer d'un environnement de développement confortable. Pour ce dernier, j'ai choisi intellij et non eclipse, choix personnel.
Comme cadre de travail, j'ai opté pour la construction d'un environnement big data de type batch, d'où Hadoop et Hive. Par la suite, j'ajouterai Spark, produit auquel je crois beaucoup après avoir lu le livre écrit par les "guys" de Databricks, avec en finalité l'IA qui se démocratise sous la forme du machine learning -> mlib. On pourrait aussi envisager une VM de type temps réel ( bases nosql, bases in-memory, moteur de recherche, ... ). Bref, de quoi s'amuser !
Hive est une surcouche SQL qui a pour but de faciliter le travail des développeurs Java; ils ont ainsi accès à HDFS via une grammaire SQL déjà très complète. Pour du small big data, cela permet d'écrire rapidement des batchs sans connaissance préalable d'Hadoop et de map-reduce. Cependant, Hive étant un compilateur map-reduce, il est plus raisonnable de les former à ces techniques afin par la suite de pouvoir affronter du middle ou du vrai big data. En effet, certaines requêtes en mode sql "normal" peuvent être fortement déconseillées en mode hadoop, par exemple un order by.
A l'origine, Hive est optimisé pour les lectures et les insertions en mode bulk. En effet, les lectures peuvent être parallélisées via la fonction map qui permet de lire des blocs hdfs sur plusieurs noeuds de manière parallélisée. Quant aux insertions en mode bulk ( penser buckets ), elles vous permettent de remplir les blocs HDFS ( blocs de plusieurs centaines MB et non blocs de 8 ko comme pour une base oracle ).
Depuis peu, on peut faire des mises à jour ( update, delete ). Pourquoi pas, mais faites le en mode bulk, sinon vous risquez d'allouer des blocs HDFS pour pas grand chose. De plus, n'oubliez pas que vous allez lancer un job map-reduce par derrière ! Enfin, vous allez créer des blocs hdfs de type delta merge dans HDFS. Et pour finir, si vous persistez à faire des mises à jour unitaires, j'espère que les perfs vous arrêteront définitivement.
Des solutions plus récentes comme Tez ou Impala permettent d'accélérer le mode batch. Pour ma part, je vous conseille d'aller plutôt étudier Spark. A vous, in fine, de choisir en fonction de votre besoin ... et de vos contraintes.
Pour vous aider à découvrir Hadoop et Hive, j'ai mis qqes notes dans le répertoire hive dans google drive. Comme Hue n'est pas disponible pour Ubuntu, j'ai configuré Squirrel pour avoir l'équivalent d'un requêteur sql.
Pour le metadata hive, j'ai choisi Derby,mais dans un environnement de production, il faut opter pour une base sql afin de pouvoir traiter plusieurs connexions à un instant t.
Comme cadre de travail, j'ai opté pour la construction d'un environnement big data de type batch, d'où Hadoop et Hive. Par la suite, j'ajouterai Spark, produit auquel je crois beaucoup après avoir lu le livre écrit par les "guys" de Databricks, avec en finalité l'IA qui se démocratise sous la forme du machine learning -> mlib. On pourrait aussi envisager une VM de type temps réel ( bases nosql, bases in-memory, moteur de recherche, ... ). Bref, de quoi s'amuser !
Hive est une surcouche SQL qui a pour but de faciliter le travail des développeurs Java; ils ont ainsi accès à HDFS via une grammaire SQL déjà très complète. Pour du small big data, cela permet d'écrire rapidement des batchs sans connaissance préalable d'Hadoop et de map-reduce. Cependant, Hive étant un compilateur map-reduce, il est plus raisonnable de les former à ces techniques afin par la suite de pouvoir affronter du middle ou du vrai big data. En effet, certaines requêtes en mode sql "normal" peuvent être fortement déconseillées en mode hadoop, par exemple un order by.
A l'origine, Hive est optimisé pour les lectures et les insertions en mode bulk. En effet, les lectures peuvent être parallélisées via la fonction map qui permet de lire des blocs hdfs sur plusieurs noeuds de manière parallélisée. Quant aux insertions en mode bulk ( penser buckets ), elles vous permettent de remplir les blocs HDFS ( blocs de plusieurs centaines MB et non blocs de 8 ko comme pour une base oracle ).
Depuis peu, on peut faire des mises à jour ( update, delete ). Pourquoi pas, mais faites le en mode bulk, sinon vous risquez d'allouer des blocs HDFS pour pas grand chose. De plus, n'oubliez pas que vous allez lancer un job map-reduce par derrière ! Enfin, vous allez créer des blocs hdfs de type delta merge dans HDFS. Et pour finir, si vous persistez à faire des mises à jour unitaires, j'espère que les perfs vous arrêteront définitivement.
Des solutions plus récentes comme Tez ou Impala permettent d'accélérer le mode batch. Pour ma part, je vous conseille d'aller plutôt étudier Spark. A vous, in fine, de choisir en fonction de votre besoin ... et de vos contraintes.
Pour vous aider à découvrir Hadoop et Hive, j'ai mis qqes notes dans le répertoire hive dans google drive. Comme Hue n'est pas disponible pour Ubuntu, j'ai configuré Squirrel pour avoir l'équivalent d'un requêteur sql.
Pour le metadata hive, j'ai choisi Derby,mais dans un environnement de production, il faut opter pour une base sql afin de pouvoir traiter plusieurs connexions à un instant t.
Inscription à :
Articles (Atom)
