Dans le monde de l'entreprise, il y a eu une satiété avec des systèmes frontaux, des bus de données et d'autres systèmes classiques qui ont été mis en œuvre par tout le monde au cours des 10 à 15 dernières années. Mais il y a un segment, qui jusqu'à récemment était dans le statut de "tout le monde veut, mais personne ne sait ce que c'est." Et c'est le Big Data. Sonne magnifiquement, promu par les meilleures entreprises occidentales - comment ne pas devenir une friandise?
Mais alors que la plupart regardent et demandent, certaines entreprises ont commencé à implémenter activement des solutions basées sur cette pile technologique dans leur paysage informatique. Un rôle important à cet égard a été joué par l'émergence de distributions commerciales Apache Hadoop, dont les développeurs fournissent un support technique à leurs clients. Sentant le besoin d'une telle solution, un de nos clients a décidé d'organiser un entrepôt de données distribué dans le concept Data Lake basé sur Apache Hadoop.
Objectifs du projet
Tout d'abord, optimisez le travail du département de gestion des risques. Avant de commencer les travaux, un département entier était engagé dans le calcul des facteurs de risque de crédit (FCR), et tous les calculs ont été effectués manuellement. Le recalcul a pris environ un mois à chaque fois, et les données sur lesquelles il était basé ont eu le temps de devenir obsolètes. Par conséquent, les tâches de la solution comprenaient le chargement quotidien du delta de données dans le référentiel, le recalcul du FCD et la construction de data marts dans l'outil BI (la fonctionnalité SpagoBI était suffisante pour cette tâche) pour les visualiser.
Deuxièmement, fournir des outils d'exploration de données hautes performances aux employés de banque impliqués dans la science des données. Ces outils, tels que Jupyter et Apache Zeppelin, peuvent être installés localement et peuvent également être utilisés pour explorer des données et créer des modèles. Mais leur intégration avec le cluster Cloudera permet d'utiliser les ressources matérielles des nœuds système les plus productifs pour les calculs, ce qui accélère les tâches d'analyse de données par dizaines, voire centaines de fois.
Le rack Oracle Big Data Appliance a été choisi comme solution matérielle cible, de sorte que la distribution Clachede d'Apache Hadoop a été prise comme base. Le rack voyageait depuis un certain temps et, pour accélérer le processus, des serveurs dans le cloud privé du client ont été alloués à ce projet. La solution est raisonnable, mais il y avait un certain nombre de problèmes, dont je parlerai ci-dessous.
Les tâches suivantes ont été planifiées dans le cadre du projet:
- Déployez le CDH de Cloudera (distribution de Cloudera incluant Apache Hadoop) et les services supplémentaires nécessaires au travail.
- Configurez le logiciel installé.
- Mettre en place une intégration continue pour accélérer le processus de développement (sera couvert dans un article séparé).
- Installez des outils de BI pour créer des outils de création de rapports et de découverte de données pour assurer le travail du centre de données (sera couvert dans un article séparé).
- Développer des applications pour télécharger les données nécessaires depuis les systèmes finaux, ainsi que leur mise à jour régulière.
- Développer des formulaires de reporting pour visualiser les données dans un outil BI.
Ce n'est pas la première année que Neoflex développe et implémente des systèmes basés sur Apache Hadoop et a même son propre produit pour le développement visuel des processus ETL - Neoflex Datagram. Pendant longtemps, j'ai voulu participer à l'un des projets de cette classe et j'ai été heureux d'administrer ce système. L'expérience s'est avérée très précieuse et motivante pour approfondir le sujet, alors je m'empresse de la partager avec vous. J'espère que ce sera intéressant.
Les ressources
Avant de commencer l'installation, il est recommandé de préparer tout ce dont vous avez besoin.
La quantité et la puissance du fer dépendent directement du nombre et des supports à déployer. À des fins de développement, vous pouvez installer tous les composants sur au moins une machine virtuelle fragile, mais cette approche n'est pas la bienvenue.
Au stade de pilotage du projet et de développement actif, lorsque le nombre d'utilisateurs du système était minimal, un seul environnement principal était suffisant - cela a permis d'accélérer en réduisant le temps de chargement des données depuis les systèmes finaux (la procédure la plus fréquente et la plus longue pour développer des entrepôts de données). Maintenant que le système s'est stabilisé, nous sommes arrivés à une configuration avec trois environnements: test, préprod et prod (principal).
Dans un cloud privé, des serveurs ont été alloués pour organiser 2 environnements - le principal et le test. Les spécifications des supports sont indiquées dans le tableau ci-dessous:
| Rendez-vous | La quantité | vCPU | vRAM, Gb | Disques, Go |
|---|
| Environnement principal, services Cloudera | 3 | 8 | 64 | 2 200 |
| Environnement principal, HDFS | 3 | 22 | 288 | 5000 |
| Environnement de base, outils de découverte de données | 1 | 16 | 128 | 2200 |
| Environnement de test, services Cloudera | 1 | 8 | 64 | 2200 |
| Environnement de test, HDFS | 2 | 22 | 256 | 4000 |
| Environnement de base, outils de découverte de données | 1 | 16 | 128 | 2200 |
| Ci | 2 | 6 | 48 | 1000 |
Plus tard, l'environnement principal a migré vers Oracle BDA et les serveurs ont été utilisés pour organiser l'environnement préprod.
La décision de migration était justifiée - les ressources allouées aux serveurs HDFS manquaient objectivement. Les goulots d'étranglement étaient des disques minuscules (qu'est-ce que 5 To pour les Big Data?) Et des processeurs insuffisamment puissants, qui étaient chargés de manière stable à 95% pendant le travail régulier des tâches de chargement des données. Avec d'autres serveurs, la situation est inverse - presque tout le temps, ils sont inactifs et leurs ressources pourraient être utilisées de manière très avantageuse sur d'autres projets.
Avec les logiciels, les choses n'étaient pas faciles - du fait que le développement se faisait dans un cloud privé sans accès à Internet, tous les fichiers devaient être transférés via le service de sécurité et uniquement par accord. À cet égard, j'ai dû précharger toutes les distributions, packages et dépendances nécessaires.
La définition de keepcache = 1 dans le fichier /etc/yum.conf (RHEL 7.3 a été utilisé comme système d'exploitation) a beaucoup aidé dans cette tâche difficile - l'installation du logiciel nécessaire sur une machine avec accès réseau est beaucoup plus facile que de le télécharger manuellement à partir des référentiels avec les dépendances;)
Ce que vous devez déployer:
- Oracle JDK (pas de Java n'importe oĂą).
- Une base de données pour stocker les informations créées et utilisées par les services CDH (par exemple, Hive Metastore). Dans notre cas, PostgreSQL version 9.2.18 a été installé, mais n'importe lequel des services Cloudera pris en charge peut être utilisé (la liste diffère pour les différentes versions de la distribution, voir la section Exigences et versions prises en charge du site officiel). Ici, il convient de noter que le choix de la base de données n'a pas été entièrement réussi - Oracle BDA est livré avec la base de données MySQL (l'un de leurs produits, qui leur est allé avec l'achat de Sun) et il serait plus logique d'utiliser une base de données similaire pour d'autres environnements, ce qui simplifierait le processus de migration. Il est recommandé de choisir une distribution basée sur la solution matérielle cible.
- DĂ©mon Chrony pour la synchronisation de l'heure sur les serveurs.
- Serveur Cloudera Manager.
- DĂ©mons Cloudera Manager.
Préparation pour l'installation
Avant de commencer l'installation de CDH, un certain nombre de travaux préparatoires doivent être effectués. Une partie est utile lors de l'installation, l'autre simplifiera le fonctionnement.
Installation et configuration du système d'exploitation
Tout d'abord, cela vaut la peine de préparer les machines virtuelles (et réelles) qui hébergeront le système: installez la version prise en charge sur chacune d'elles (la liste diffère pour les différentes versions de la distribution, voir la section «Configuration requise et versions prises en charge» du site officiel), attribuez les noms d'hôtes sont des noms compréhensibles (par exemple, <system_name> master1,2,3 ..., <system_name> slave1,2,3 ...), ainsi que des disques de marquage pour le stockage de fichiers et les fichiers temporaires créés pendant le fonctionnement du système.
Les recommandations de balisage sont les suivantes:
- Sur les serveurs avec HDFS, créez un volume d'au moins 500 Go pour les fichiers créés par YARN au cours des tâches et placez-le dans le répertoire / yarn (où ce volume doit être monté après l'installation de CDH). Un petit volume (environ 100 Go) devrait être alloué au système d'exploitation, aux services Cloudera, aux journaux et à d'autres installations. Tout l'espace libre qui restera après ces manipulations doit être combiné en un seul grand volume et monté dans le répertoire / dfs avant de charger les données dans le stockage. HDFS stocke les données sous forme de blocs plutôt petits et il vaut mieux ne pas recommencer leur transfert. De plus, pour la commodité d'ajouter des disques plus tard, il est recommandé d'utiliser LVM - il sera plus facile d'étendre le stockage (surtout quand il devient vraiment GRAND).
- Sur les serveurs avec les services Cloudera, vous pouvez monter tout l'espace disponible dans le répertoire racine - il ne devrait y avoir aucun problème avec de gros volumes de fichiers, surtout si vous nettoyez régulièrement les journaux. La seule exception est le serveur avec la base de données, que les services Cloudera utilisent pour leurs besoins - sur ce serveur, il est logique de marquer un volume séparé sous le répertoire dans lequel les fichiers de cette base de données sont stockés (cela dépendra de la distribution sélectionnée). Les services écrivent assez modérément et 500 Go devraient être plus que suffisants. Pour des raisons de sécurité, vous pouvez également utiliser LVM.
Configuration du serveur http et installation hors ligne des packages yum et CDH
Le logiciel étant installé sans accès à Internet, pour simplifier l'installation des packages, il est recommandé de surélever le serveur HTTP et de l'utiliser pour créer un référentiel local accessible sur le réseau. Vous pouvez installer tous les logiciels localement en utilisant, par exemple, rpm, mais avec un grand nombre de serveurs et l'apparence de plusieurs environnements, il est pratique d'avoir un seul référentiel à partir duquel vous pouvez installer des packages sans avoir à les transférer manuellement d'une machine à l'autre.
L'installation a été effectuée sur le système d'exploitation Red Hat 7.3, par conséquent, l'article contiendra des commandes spécifiques à celui-ci et à d'autres systèmes d'exploitation basés sur CentOS. Lorsqu'il est installé sur d'autres systèmes d'exploitation, la séquence sera similaire, seuls les gestionnaires de packages différeront.
Afin de ne pas Ă©crire partout sudo, nous supposons que l'installation est Ă partir de la racine.
Voici ce que vous devez faire:
1. La machine sur laquelle le serveur HTTP et les distributions seront situés est sélectionnée.
2. Sur une machine avec un système d'exploitation similaire, mais connecté à Internet, définissez l'indicateur keepcache = 1 dans le fichier /etc/yum.conf et httpd avec toutes les dépendances est installé:
yum install httpd
Si cette commande ne fonctionne pas, vous devez ajouter à la liste des référentiels yum un référentiel contenant ces packages, par exemple, celui-ci est
centos.excellmedia.net/7/os/x86_64 :
echo -e "\n[centos.excellmedia.net]\nname=excellmedia\nbaseurl=http://centos.excellmedia.net/7/os/x86_64/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/excell.repo
Après cela, en
utilisant la commande
yum repolist ,
nous vérifions que le référentiel est resserré - un référentiel ajouté devrait apparaître dans la liste des référentiels (repo id - centos.excellmedia.net; nom du référentiel - excellmedia).
VĂ©rifiez maintenant que yum a vu les packages dont nous avons besoin:
yum list | grep httpd
Si la sortie contient les packages nécessaires, vous pouvez les installer avec la commande ci-dessus.
3. Pour créer le référentiel yum, nous avons besoin du package createrepo. Il se trouve également dans le référentiel ci-dessus et est défini de la même manière:
yum install createrepo
4. Comme je l'ai déjà dit, les services CDH nécessitent une base de données pour fonctionner. Installez PostgreSQL à ces fins:
yum install postgresql-server
5. L'une des conditions préalables au bon fonctionnement de CDH est la synchronisation de l'heure sur tous les serveurs inclus dans le cluster. À ces fins, le package
chronyd est
utilisé (sur les OS où je devais déployer CDH, il était installé par défaut). Vérifiez sa disponibilité:
chronyd -v
S'il n'est pas installé, installez:
yum install chrony
S'il est installé, téléchargez simplement:
yumdownloader --destdir=/var/cache/yum/x86_64/7Server/<repo id>/packages chrony
6. En même temps, téléchargez immédiatement les packages nécessaires à l'installation de CDH. Ils sont disponibles sur
archive.cloudera.com -
archive.cloudera.com/cm <version principale de CDH> / <nom de votre système d'exploitation> / <version de votre système d'exploitation> / x86_64 / cm / <version complète de CDH> / RPMS / x86_64 /. Vous pouvez télécharger des packages manuellement (cloudera-manager-server et cloudera-manager-daemons), ou ajouter un référentiel par analogie et les installer:
yum install cloudera-manager-daemons cloudera-manager-server
7. Après l'installation, les packages et leurs dépendances sont mis en cache dans le dossier / var / cache / yum / x86_64 / 7Server / \ <repo id \> / packages. Nous les transférons sur la machine sélectionnée pour le serveur HTTP et les distributions, et installons:
rpm -ivh < >
8. Exécutez httpd, rendez-le visible à partir d'autres hôtes de notre cluster et ajoutez-le également à la liste des services qui démarrent automatiquement après le chargement:
systemctl start httpd systemctl enable httpd systemctl stop firewalld
9. Nous avons maintenant un serveur HTTP fonctionnel. Son répertoire de travail est
/ var / www / html . Créez-y 2 dossiers - un pour le référentiel yum, l'autre pour les analyseurs Cloudera (plus à ce sujet plus tard):
cd /var/www/html mkdir yum_repo parcels
10. Pour les services de Cloudera, nous avons besoin de
Java . Toutes les machines nécessitent l'installation de la même version du JDK; Cloudera recommande le Hot Spot d'Oracle. Téléchargez le package de distribution sur le site officiel (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) et transférez-le dans le dossier
yum_repo .
11. Créez le référentiel yum dans le dossier yum_repo à l'aide de l'utilitaire createrepo afin que le package JDK soit disponible pour l'installation à partir des machines du cluster:
createrepo -v /var/www/html/yum_repo/
12. Après avoir créé notre référentiel local sur chacun des hôtes, vous devez ajouter sa description, similaire au paragraphe 2:
echo -e "\n[yum.local.repo]\nname=yum_repo\nbaseurl=http://< httpd>/yum_repo/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/yum_repo.repo
Vous pouvez également effectuer des vérifications similaires au paragraphe 2.
13. JDK est disponible, installez:
yum install jdk1.8.0_161.x86_64
Pour utiliser Java, vous devez définir la variable JAVA_HOME. Je vous recommande de l'exporter immédiatement après l'installation, ainsi que de l'écrire dans les
fichiers / etc / environment et
/ etc / default / bigtop-utils afin qu'il soit automatiquement exporté après le redémarrage des serveurs et que son emplacement soit fourni aux services CDH:
export JAVA_HOME=/usr/java/jdk1.8.0_161 echo "JAVA_HOME=/usr/java/jdk1.8.0_161" >> /etc/environment export JAVA_HOME=/usr/java/jdk1.8.0_144 >> /etc/default/bigtop-utils
14. De la même manière, installez chronyd sur toutes les machines du cluster (sauf s'il est bien sûr absent):
yum install chrony
15. SĂ©lectionnez l'hĂ´te sur lequel PostgreSQL fonctionnera et installez-le:
yum install postgresql-server
16. De même, sélectionnez l'hôte sur lequel Cloudera Manager s'exécutera et installez-le:
yum install cloudera-manager-daemons cloudera-manager-server
17. Les packages sont installés, vous pouvez commencer à configurer le logiciel avant l'installation.
Ajout:
Pendant le développement et le fonctionnement du système, vous devrez ajouter des packages au référentiel yum pour les installer sur les hôtes du cluster (par exemple, la distribution Anaconda). Pour ce faire, en plus de transférer les fichiers dans le dossier yum_repo, vous devez effectuer les actions suivantes:
Configuration du logiciel auxiliaire
Il est temps de configurer PostgreSQL et de créer des bases de données pour nos futurs services. Ces paramètres sont pertinents pour CDH version 5.12.1, lors de l'installation d'autres versions de la distribution, il est recommandé de lire la section "Cloudera Manager et Managed Service Datastores" sur le site officiel.
Pour commencer, initialisons la base de données:
postgresql-setup initdb
Maintenant, nous configurons l'interaction réseau avec la base de données. Dans le fichier
/var/lib/pgsql/data/pg_hba.conf de la section des connexions locales IPv4, remplacez la méthode de l'adresse 127.0.0.1/32 par la méthode md5, ajoutez la méthode d'approbation et ajoutez le sous-réseau de cluster avec la méthode d'approbation :
vi /var/lib/pgsql/data/pg_hba.conf pg_hba.conf:
Ensuite, nous apporterons quelques ajustements au fichier /var/lib/pgsql/data/postgres.conf (je ne donnerai que les lignes qui doivent être modifiées ou vérifiées pour la conformité:
vi /var/lib/pgsql/data/postgres.conf postgres.conf: ----------------------------------------------------------------------- listen_addresses = '*' max_connections = 100 shared_buffers = 256MB checkpoint_segments = 16 checkpoint_completion_target = 0.9 logging_collector = on log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 0 log_timezone = 'W-SU' datestyle = 'iso, mdy' timezone = 'W-SU' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' -----------------------------------------------------------------------
Une fois la configuration terminée, vous devez créer des bases de données (pour ceux qui sont plus proches de la terminologie Oracle - schémas) pour les services que nous installerons. Dans notre cas, les services suivants ont été installés: Cloudera Management Service, HDFS, Hive, Hue, Impala, Oozie, Yarn et ZooKeeper. Parmi ceux-ci, Hive, Hue et Oozie ont besoin de bases de données et 2 bases sont nécessaires pour les besoins des services Cloudera - une pour le serveur Cloudera Manager, l'autre pour le gestionnaire de rapports, qui fait partie du service de gestion Cloudera. Lancez PostgreSQL et ajoutez-le au chargement automatique:
systemctl start postgresql systemctl enable postgresql
Nous pouvons maintenant nous connecter et créer les bases de données nécessaires:
sudo -u postgres psql > CREATE ROLE scm LOGIN PASSWORD '<password>'; > CREATE DATABASE scm OWNER scm ENCODING 'UTF8'; # Cloudera Manager > CREATE ROLE rman LOGIN PASSWORD '<password>'; > CREATE DATABASE rman OWNER rman ENCODING 'UTF8'; # > CREATE ROLE hive LOGIN PASSWORD '<password>'; > CREATE DATABASE metastore OWNER hive ENCODING 'UTF8'; # Hive Metastore > ALTER DATABASE metastore SET standard_conforming_strings = off; # PostgreSQL 8.2.23 > CREATE ROLE hue_u LOGIN PASSWORD '<password>'; > CREATE DATABASE hue_d OWNER hue_u ENCODING 'UTF8'; # Hue > CREATE ROLE oozie LOGIN ENCRYPTED PASSWORD '<password>' NOSUPERUSER INHERIT CREATEDB NOCREATEROLE; > CREATE DATABASE "oozie" WITH OWNER = oozie ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1; # Oozie : > \q
Pour les autres services, les bases de données sont créées de la même manière.
N'oubliez pas d'exécuter le script pour préparer la base de données du serveur Cloudera Manager, en lui passant les données d'entrée pour vous connecter à la base de données créée pour lui:
. /usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm <password>
Création d'un référentiel avec des fichiers CDH
Cloudera propose 2 façons d'installer CDH - à l'aide de packages et à l'aide de parcelles. La première option consiste à télécharger un ensemble de packages avec les services des versions requises et leur installation ultérieure. Cette méthode offre une grande flexibilité dans la configuration du cluster, mais Cloudera ne garantit pas leur compatibilité. Par conséquent, la deuxième version de l'installation utilisant des parsels est plus populaire - des ensembles préformés de packages de versions compatibles. Les dernières versions sont disponibles sur le lien suivant: archive.cloudera.com/cdh5/parcels/latest . Plus tôt, on peut trouver un niveau supérieur. En plus du parsel de CDH, vous devez télécharger manifest.json à partir du même répertoire de référentiel.
Pour utiliser les fonctionnalités développées, nous avions également besoin de Spark 2.2, qui n'est pas inclus dans le colis CDH (la première version de ce service y est disponible). Pour l'installer, vous devez télécharger un colis séparé avec ce service et le manifest.json correspondant, également disponible dans l'archive Cloudera .
Après avoir chargé les parsels et manifest.json, vous devez les transférer dans les dossiers appropriés de notre référentiel. Créez des dossiers séparés pour les fichiers CDH et Spark:
cd /var/www/html/parcels mkdir cdh spark
Transférez les fichiers parsels et manifest.json dans les dossiers créés. Pour les rendre disponibles pour l'installation sur le réseau, nous émettons le dossier d'autorisations d'accès correspondant avec des parsels:
chmod -R ugo+rX /var/www/html/parcels
Vous pouvez commencer Ă installer CDH, dont je parlerai dans le prochain post.