Stage de Aurélien Benoit - Telecom Nancy - [4/06/18 au 10/08/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter François-Xavier, André

Sujet

• Proposition de stage

Stage (Juin - Août 2018)

Juin

• Lundi 4,
  • Arrivée
  • Installation des logiciels : IntelliJ, Spark, Scala, Java
  • Suivi du tutoriel Spark (https://spark.apache.org/docs/latest/quick-start.html)
  • Installation d'Eclipse :IntelliJfonctionne mal avec Maven qui est conseillé par le tutoriel
  • Réinstallation de Java, Spark n'est pas compatible avec le jdk10
  • Suivi du tutoriel Spark RDD (https://spark.apache.org/docs/latest/rdd-programming-guide.html)
  • Configuration d'un workspace eclipse où le code java envoyé par mail fonctionne
  • Bilan :
    • Configuration de la machine pour travailler avec Spark en local
    • Découverte de spark
    • Configuration du bashrc
• Mardi 5,
  • Lecture du code envoyé par mail : cross match
  • Lecture d'une diapo correspondante au code (https://indico.in2p3.fr/event/13365/contributions/13956/attachments/11650/14368/Journees-Plateforme-Spark-CDS.pdf)
  • Ce que j'en ai compris
  • Fin du tutoriel Spark RDD
  • Installation de Cassandra
  • Test d'une bibliothèque qui permet de faire du Cassandra via Java : Achilles (http://doanduyhai.github.io/Achilles/)
  • J'ai rouvé un tutoriel qui permet de lier spark et cassandra directement, on change de bibliothèque. (https://zenika.developpez.com/tutoriels/nosql/integration-spark-cassandra/)
  • Les dépendances sont mal gérées, je tente de trouver des solutions. Si ça ne marche pas je passe à Scala.
  • Bilan
    • Installation de Cassandra en local réussie
    • Problèmes pour relier spark et cassandra en Java
• Mercredi 5,
  • Une solution au problème des dépendances a été trouvée
  • Un bug a été résolu, sans doute des conflits entre bibliothèques
  • Le pom.xml obtenu pour Maven, est disponible ici
  • La lecture/l'écriture de RDD spark à cassandra est comprise.
• Jeudi 6,
  • Ecriture des csv dans Cassandra
  • Utilisation de spark sql pour faire la jointure
  • Crétion du dépôt GitLab
• Vendredi 7,
  • Travail sur spark sql, tests, écriture du résultat dans cassandra, normalement fini
  • Normalement les partitions key de tables différents mais avec le même nom doivent fonctionner de la même façon, i.e les données doivent se ranger correctement sans modification. !! A vérifier quand le cluster sera disponible. source
• Lundi 11,
  • Première comparaison en local : lecture des données plus longues mais gain en jointure. Néanmoins le gain n'est pas rentable.
  • Code + clean
• Mardi 12,
  • Utilisation du kdtree avec cassandra
  • Tests
  • Réception du cluster, début lecture configuration du cluster cluster1
• Mercredi 13,
  • Suivi d'un tutoriel local cluster2
  • Début configuration du vrai cluster
• Jeudi 14
  • Fin configuration cluster3
  • Problèmes pour tester (les machines s'arrêtent => corruption de la base de données => remise en route et re configuration )
  • Début passage à scala pour tester joinWithCassandraTable (configuration de l'IDE difficile)
• Vendredi 15
  • Fin de la configuration de la machine pour Scala
  • Fin de l'écriture de la classe, performances plus mauvaises, il faut voir si il y a un gain en cluster
• Lundi 18
  • Le cluster n'est plus disponible
  • Réécriture de la classe SQL en scala pour faire une comparaison de performances => en régle générale Java obtient de meilleures performances
  • Nettoyage du code Java, recherche sur optimisation Cassandra-Spark
• Mardi 19
  • Optimisation finale Java, il faut maintenant effectuer des tests avec les clusters
  • Début lecture langage Rust
• Mercredi 20
  • Premiers tests en cluster
• Jeudi 21
  • Correction nécessaires pour lecture de gros fichiers
  • Un peu d'optimisation (API)
  • Réécriture code scala (utilisation de la fonction keyBy de l'API)
• Vendredi 22
  • Séminaire "machine learning"
  • Optimisation de la lecture des fichiers
  • Tests des classes scala et java en cluster => après optimisation, la classe scala utilisant keyBy se révèle largement meilleure.
• Lundi 25
  • Installation d'un cluster hadoop pour faire des comparaisons.
  • La salle des machines est occupée, je reprendrai l'installation plus tard.
  • Je continue le tutoriel rust
  • Aide du service info pour réinstaller les machines dans la bibliothèque (peut être que le problème de déconnection est réglé)
  • Test hdfs normal et kdtree
• Mardi 26
  • Paramètrage plus en détail de l'API (sur simbadXtyc, temps de 34 sec)
    • en ajoutant .config("spark.cassandra.output.batch.grouping.key", "none") on gagne 12 sec, surtout au niveau de la sauvegarde -> en effet on n'envoie plus clef par clef
    • j'ai ajouté la liste des autres paramètres dans le fichiers, même s'ils ont peu d'importance sur le résultat que l'on obtient, ils peuvent être crucials pour de plus grosses données
    • => 21-22 sec
  • Test du jar DSE pour bulk saving, configuration difficile, problèmes de comptabilité obscure pour le bulk saving (classe qui se sérialize mal)
    • J'ai tenté une installation totalement local avec les jars de DSE mais ça n'a pas corriger ce problème
• Mercredi 27 - jeudi 28
  • Lecture du livre de rust, début du codage kdtree
• Vendredi 29
  • Codage du kdtree en rust
  • Utilisation de test => pratique pour débuggué
  • Half_sort => reprise de l'algorithme
    • swap possible en rust grâce à la fonction array.swap(i,j)
    • do while grâce à while{ //do ; condition }{}
  • Creation
    • perte de temps, bug à cause d'une condition de fin mal écrite
    • à cause du borrowing on doit déclarer deux variables en plus, à voir si'l y a moyen de contourner ça pour changer le hi => nouvelle fonction change_hi()
    • factorisation de code (zero cost abstraction en rust)
  • Check
  • Display
    • Fonction récursive d'affichage pour aider au débug
• Lundi 2
  • Codage du kdtree en rust
  • KdBox => Implémentation de la classe java Box (mot clef déjà pris), permet de modéliser une kbox en l'associant à des coordonnées et à des points du kdtree
    • utilisation de box car des élèments ont des tailles variables (Vec<f64> notamment>
    • du cloenage de ci et là qui peuvent réaliser des pertes de performances, mais déjà présents en java
    • en général de la reprise du code java même si quelques tweaks sont obligatoires pour Rust (gestion de la mémoire et de l'unicité de l'ownership)
    • fonctions d'intersections
  • nn => Nearest neighbour
    • Retour dans une Option pour éviter une erreur de compilation ( le compilateur suspectait un retour nul impossible )
    • une fois l'algo compris ça passe
  • knn => K nearest neighbours
    • Nouvelle structure de données pour récupérer le résultat
    • M'a demandé pas mal de temps pour éviter le clonage des valeurs.
    • Mise en pratique des durées de vie
    • Implémentation de traits standards comme Ord ou Eq pour s'approcher du code Java
  • Beaucoup de tests
• Mardi 3
  • knn => utilisation de BinaryHeap pour optimiser la structure de donées annexe
  • corrections de bugs (pull_for et nn)
  • in_kdsphere => assez simple à écrire
  • in_kdbox => plus compliqué, j'avais une solution mais qui ne marche plus à cause de la généricité
  • généricité => nécessite de réecrire le code, assez rapide (40 minutes)

Juillet

• Mercredi 4
  • généricité => les from n'étaient pas gérés, il a fallu trouve la bonne combinaison, je galérai car j'utilisais from<String> alors que les types généraux ne le gère pas. La solution a été d'utilisé parse du trait str::FromStr
  • tuple => utilisation de maccros pour préparer au rescriptage, un peu difficile à prendre en main au vu de la syntaxe mais super puissant ( nécessite notions de grammaires ). Utilisation des tuples pour les coordonnées.
  • tests => meilleurs performances avec tuple
  • array => grâce aux maccros, il est aussi possible d'utiliser des tableaux à taille finie. Plus puissants et mieux adaptés que les tuples pour plusieurs raisons (syntaxe [i] donc pas de bidouillage avec le matching, pas besoins de la fonctionnalité des tuples à découper le résultat). Le recodage s'est fait rapidement grâce aux maccros.
• Jeudi 5
  • écriture des fichiers de tests de comparaisons de performances en rust et java + premiers tests
  • --release est primordial pour compiler un programme efficace en rust
• Vendredi 6
  • nn et create récursifs
• Lundi 9
  • knn récursif
  • en général, les fonctions récursives sont meilleures
  • comparaison java / rust normal, tuple, array
    • array meilleur que tuple
    • tuple meilleur que java
    • java meilleur que normal !
  • début réoptimisation/reformatage grâce à clippy
• Mardi 10
  • pas besoin d'utiliser des Box vers des Vec !
  • slices en paramètres
  • zip pas efficace -> nouvelle forme
  • test de -C target-cpu=native -> pas de changement visible
  • Début AstroKdtree
• Mercredi 11
  • half_sort ne trie pas les k premiers éléments !! Il met juste l'élémet médian à sa place et met les éléméents inférieurs à gauche dans un ordre random
  • knn et cone_search sont buggués
• Jeudi 12
  • knn et cone_search débuggués : problèmes d'ordre de variables -_-
  • bibliothèque finie et testée
  • rust en général 2x plus rapide que java
  • retour sur kdtree : &[f64] et Boxe<[f64] (performances équivalentes)
  • début recherche web assembly
• Vendredi 13
  • lecture du tutoriel (jeu de la vie)
  • début codage de l'application en wasm
    • utilisation de wasm-bindgen pour faciliter l'interfaçage rust-javascript
    • utilisation de node-js et de npm
• Lundi 16
  • Utilisation de la bibliothèque dans wasm ok
  • Tests des performances du cone_search
    • En fonction des navigateurs on est 2x moins performant qu'en Rust -> on est plus rapide-aussi rapide que Java dans le navigateur
  • Amélioration de astrokdtree : corrections de tests
  • Lecture de la partie concurrence/parallélisation du "Book".
  • Essai de réalisation d'un create multithreadé en utilisant les modules standards.
  • Problème les pointeurs doivents être statiques, ce qui se révèle presque impossible à faire
    • Une solution revient à utiliser un Mutex, mais cela revient à retirer l'avantage du multithreadé (chaque thread doit travailler sur un morceau du veceur original).
    • Une autre solution consiste à recopier les données : choix adopter pour aujourd'hui mais pas optimisé.
    • => Nécessité de travailler avec des crates
• Mardi 17
  • Utilisation de deux crates : crossbeam et rayon.
    • Crossbeam permet l'utilisation de pointeurs non statiques en prévenant le compilateur d'un scope après lequels les threads ont forcéments arrêtés.
    • Rayon permet de simplifier le multithreading sur des itérateurs en définissant un iterateur parallélisant.
  • Create et check multithreadés avec crossbeam.
  • nn multithreadé avec rayon (on fait un nn sur un vecteur, donc chaque thread fait un nn à la fois)
  • Recherche d'un meilleur algorithme de sélection. Codage de half_sort_v3
• Mercredi 18
  • Débuggage d'half_sort_v3, utilisation d'autres algorithmes.
  • Comparaison : half_sort_v3 est le meilleur (hybride trouvé sur stack overflow)
  • Début du codage d'AstroKdtreXYZ :
    • reformatage du code autour du trait Kdtree
    • reformatage du code autour du trait Source
    • Deux choix techniques pour AstroKdtree : sur la direction enum ou struct vide.
    • L'enum est un peu plus performante sur le nn et le knn
• Jeudi 19
  • AstroKdtree XYZ fonctionne
  • Documentation
• Vendredi 20
  • Simplification des calculs (h3 pour astrokdtree (nécessite une nouvelle struct Distance pour économiser le nombre de calculs à effectuer) et distance_square pour astrokdtreeXYZ)
  • Rédaction test (création de points dans un cone)
• Lundi 23
  • Tests et comparaisons entre AstroKdtreeXYZ et AstroKdtree
  • Application web : debut (bug dans le js corrigé le lendemain)
• Mardi 24
  • SmartAstroKdtreeXYZ (On trie sur XYZ en fonction de la taille de l'hyper boite concernée)
  • Application web fonctionnelle dans chromium (taille des fichiers csv tros gros dans Firefox)
  • De nouveaux des tests
• Mercredi 25
  • Résultats des tests précédu mardi faux ! Quelques erreurs dans le code. Je refait les tests.
    • Inversion entre ra et dec, une ligne à corriger
  • Lecture des documents sur cassandra et aws envoyé par André.
• Jeudi 26
  • Lecture de documentation sur cassandra, aws et spark.
  • Plusieurs choix disponibles pour le cluster
    • Spark sur aws elastic search et données sur aws s3
    • Spark sur aws elastic search et Cassandra sur aws ec2
    • Spark et Cassandra sur aws ec2
      • On a fait ce choix pour s'assurer que le comportement du cluster est bien celui demandé (localisation données-machines)
  • Réécriture de certaines parties du code scala
    • Au lieu de passer par map, on passe par into map values pour s'assurer la non réalisation deshuffle lors du map
      • Nécessite l'écriture d'une row factory
    • Optimisation des row factory en instanciant un row à la création de la row factory
• Vendredi 26
  • Installation du cluster cassandra sur aws grâce à Ansible
    • Beaucoup de configurations à automatiser
    • Inspiration de plusieurs documents qui ne sont pas à jours.
      • https://github.com/chbatey/ubuntu-ansible -> templates à réécrire car fausses
      • https://gist.github.com/avinash-mishra/e37d36d16fcee9f28d91446aeb5ba2e2 -> installation de cassandra à la main, ce que je veux
  • Beaucoup de problèmes rencontrés
    • Ouverture de ports
    • Lancement du Daemon à la main (utilisation de nohup)
    • Création du template de cassandra.yaml
  • Il en résulte que j'en connais beaucoup plus sur la configuration de cassandra qu'avant
• Lundi 30
  • Installation de Spark
  • Beaucoup de problèmes dans la configuration
    • Clés ssh interne -> modification des scripts sh de spark
    • Ouverture de nombreux ports (problèmes majeur : aws bloque la majorité des ports en entrée, il faut donc définir des ports constants pour les machines )
    • Fichiers de configurations à automatiser
  • Premiers tests les performances sont du même ordre de grandeur que ce que l'on avait sur le cluster local
  • Modification des fichiers pour optimiser le temps : résultats négligeables (voire plus mauvais par moments)
  • Rust : tests en échelle logarithmique
• Mardi 31
  • Paramétrage de cassandra le paramétrage de cassandra et spark pour essayer d'augmenter les performances
  • Tests spark/cassandra sur de plus gros fichiers (51g et 58g)
    • Très long à parser et à mettre dans la base de données -> Une après midi-di n'a pas été suffisante
    • Beaucoup d'érreurs sur la fin des importations

Août

• Mercredi 1 Aout
  • Début du travail sur kdtree dans les fichiers
  • Ecriture des traits nécessaires
    • Traduire du Java orienté objet super générique vers du Rust est assez dur
• Jeudi 2 Aout
  • Première implémentations simples puisque classes basiques (ce sont presque des Beans )
  • Début de l'écriture d'external sorter et de son implémentation : recquiert pas mal de classes
• Vendredi 3 Aout
  • Travail sur l'écriture/lecture dans les fichiers
    • Création/Destruction de fichiers temporaires
    • Ecriture de bits simples
• Lundi 6 Aout
  • Travail sur l'écriture/lecture dans les fichiers
  • Travail sur les itérateurs
• Mardi 7 - Mercredi 8 Aout
  • Travail sur efile et external sorter
• Jeudi 9 Aout
  • Travail sur KdTreeFile : block, block cache, box, navig
• Vendredi 10 Aout
  • Instanciation d'un KDTreeFile à partir d'un fichier
  • Début de l'écriture
  • Travail sur external sorter pour les kcomparable (adaptation à un kcomparator)

Liens

• ...

Versions testables

• ...

Documentation

• ...

Travail post stage éventuel

e passer par map, on passe par into

• ...

Liste des améliorations à envisager

• ...

Bugs connus

• ...

Liens