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 ...
samedi 9 avril 2016
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.
mercredi 16 décembre 2015
Création d'un cluster hadoop 8 noeuds
Dernièrement, dans un data lab, j'ai créé un cluster hadoop à 8 noeuds, 3 noeuds pour gérer la haute disponibilité du namenode et 5 noeuds pour les data. Ce cluster a été construit sur une architecture de type commodity hardware, 8 PC dont la configuration est la suivante: 4 threads, 32 GB RAM et qqes TB de disque magnétique. L'OS installé est Ubuntu ( 12.04 pour les master nodes, un ancien cluster Cassandra reconverti et 14.04 pour les data nodes ). En production, pour rappel, chaque noeud doit être configuré de manière identique. Quant aux JVM, elles se basent sur openjdk-7-jre.
Pour ce faire, je me suis basé sur les liens suivants:
- Installation d'un cluster hadoop sans ha sur Ubuntu;
- Installation d'un cluster hadoop en mode ha;
- HDFS haute disponibilité: howto.
Comme toute installation a toujours son lot de surprises, en particulier sur un environnement expérimental, voici le répertoire google drive où j'ai mis mes notes sur l'installation ainsi que les fichiers de configuration hadoop.
Pour ce faire, je me suis basé sur les liens suivants:
- Installation d'un cluster hadoop sans ha sur Ubuntu;
- Installation d'un cluster hadoop en mode ha;
- HDFS haute disponibilité: howto.
Comme toute installation a toujours son lot de surprises, en particulier sur un environnement expérimental, voici le répertoire google drive où j'ai mis mes notes sur l'installation ainsi que les fichiers de configuration hadoop.
Par la suite, j'ai fait qqes tests de map-reduce sur un wordcount perso et le cluster a parfaitement bien répondu. Quelques screenshots sont disponibles dans le répertoire de partage.
mercredi 11 novembre 2015
Hadoop
Après avoir travaillé sur les bases nosql, je m'intéresse désormais à la notion de socle big data, c'est à dire à une architecture big data de type cloudera ou hortonworks. La base de cette architecture est constituée par hadoop, un système de fichiers distribué sur plusieurs noeuds. Pour éviter d'écrire du map/reduce en natif, vous disposez pour faire du batch d'outils comme Hive, Tez, Impala ou encore Spark pour les plus innovants.
Pour vous initier à tous ces nouveaux concepts, je vous conseille de lire comme point de départ Hadoop: The Definitive Guide de Tom White, un ouvrage d'une grande pédagogie.
Bien entendu, une telle plate-forme ne traite pas que le partie batch et vous disposez d'autres outils pour exposer des services comme des bases nosql, des moteurs de recherche ou même du machine learning sous forme de data lab.
Pour vous initier à tous ces nouveaux concepts, je vous conseille de lire comme point de départ Hadoop: The Definitive Guide de Tom White, un ouvrage d'une grande pédagogie.
Bien entendu, une telle plate-forme ne traite pas que le partie batch et vous disposez d'autres outils pour exposer des services comme des bases nosql, des moteurs de recherche ou même du machine learning sous forme de data lab.
Tables temporaires
Jusqu’à la 11g, les tables
temporaires en mode commit preserve rows sont à manier avec précaution. Si vous
vous contentez de les utiliser pour stocker quelques calculs intermédiaires,
vous n’aurez pas de problèmes car un full scan fera bien l’affaire.
En revanche, si des tables
temporaires sont utilisées dans un batch suite par exemple à une migration de
Sybase vers Oracle, vous risquez alors de faire face à des problèmes de performance
une fois une certaine volumétrie atteinte.
En effet, si une même requête au
sens sql_id est utilisée plusieurs fois, un dynamic sampling souvent
insuffisant sera utilisé pour collecter quelques statistiques afin d’élaborer
un plan d’exécution lors de la création du curseur dans le shared pool. De
plus, si cette requête est utilisée plusieurs fois par d’autres sessions, ce
même plan d’exécution sera appliqué alors que le jeu de données risque d’être
fort différent en volumétrie et en nature des données.
Pour éviter des performances dégradées
et aléatoires, deux solutions peuvent être mises en oeuvre :
1) Utilisation d’un hint pour forcer le dynamic sampling à 6, voire plus si nécessaire ;
2) Forcer le hard parsing à chaque exécution de requête (http://ahmedaangour.blogspot.fr/2011/07/forcer-un-hard-parse.html) pour obtenir un plan d’exécution adapté à chaque jeu de données.
1) Utilisation d’un hint pour forcer le dynamic sampling à 6, voire plus si nécessaire ;
2) Forcer le hard parsing à chaque exécution de requête (http://ahmedaangour.blogspot.fr/2011/07/forcer-un-hard-parse.html) pour obtenir un plan d’exécution adapté à chaque jeu de données.
A partir de la 12c, la
possibilité de collecter des statistiques au niveau de chaque session (https://oracle-base.com/articles/12c/session-private-statistics-for-global-temporary-tables-12cr1)
change la donne.
vendredi 26 juin 2015
Inscription à :
Articles (Atom)
