Apple d'offre Composants cités hadoop, hdfs, hbase, kafka, flume, spark, hbase, avro, orc, sqoop, oozie
Connecteurs cités sgbd, SSAS, SSRS, excel, PowerBI, trigger db
Objectif
Est-ce que l'objectif est de TOUS les tester ? Si c'est le cas, pourquoi pas, mais quel est l'objectif à atteindre ? Quelle information actionnable souhaite-on avoir ? Voir la facilité de mise en place ? De la performance ?
Questions
Surprise : ORC, avro
Pourquoi parler de stockage column vs row ? C'est un détail d'implémentation, lié à la performance. Y a t-il des sujets particuliers lié a ce point ?
Pourquoi parler d'avro, et d'orc ? pourquoi pas parquet ? Historiquement hive travaille avec orc, mais intègre désormais parquet (twitter/criteo/salesforce)
La dernière version de spark utilise parquet pour améliorer son physical query plan avec parquet/orc... mais ce n'est pas gratuit !
Il faut également bien comprendre les avantages/inconvénients de ces formats de sérialization: perf, io, by row, by col, impact sur le GC, compression spécifiques, metadonnées etc. Attention aux objects très très hierarchiques.
Moins une surprise: Pig Pig ... pourquoi pas ... mais pourquoi ne pas utiliser directement scala/java ? Qui va faire ces scripts ? Si ce sont des devs -> scala, sinon ok pourquoi pas. Connaissez-vous spark notebook ? ou apache zeppelin qui font la mêle chose en mieux, et collaboratif et sur le web ?
Surprise : Oozie quand on a juste spark, oozie n'a pas vraiment de sens. Autant utiliser scala/java ou un vrai workflow manager.
J'en déduis que c'est disparate, et qu'ils ont lu (trop) rapidement l'écosystème...
Documentation:
Il faut faire très attention lors de ses recherches documentaire sur le web dans le monde hadoop quand à l'ordonnancement des technos. Il faut toujours replacer ces composants dans l'histoire pour éviter d'analyser des outils outdated, exemple pour hadoop
hadoop map reduce Reducer, Mapper et boiler plate fait en java, déploiement des jars -> c'est compliqué donc on créé HIVE : utilise un SQL-like qui produit les map reduces (hive sql) -> mais SQL n'est pas assez expressif donc on créé PIG : utilise PIG Latin qui permet de faire des foreach, user defined functions etc maintenant il faut coordonner les 3 mondes... en XML ! Enter oozie
Attention, il ne faut pas s'embarquer dans des outils qui sont là principalement pour traiter du legacy !
Mais c'est pas "grave", car désormais ces outils fonctionne également avec spark
Côté archi présentée
Ce n'est même pas une proposition, mais un générateur de discussion. Car il y a de multiples versions ! Avec ou sans flume, avec ou sans kafka etc. Sqoop ou pas. Spark peux faire tout... ou rien. Kafka peux remplacer flume ... et Spark également. Bref la stack doit être pilotée par le besoin !
Quid des données sur le temps ? Choix stockage by row ou by column ? Perf ? ? Sécurité ? Streaming ? Performance ? Stockage ? Temps ? Rétentions ? Migration de données ? Mise en place ? Test ? Anonymisation ? Machine learning ? Quid de l'infra ? Quid de la politique de sécurité des données ? Quid des politiques de rétentions ? Quid des stratégies de partitionement ? Sujet technique ... mais métier également. Cf l'ordonnancement des logs de kafka sur une plage donnée, pas sur de multiples plages. C'est également un sujet de perf. Quid des devs en place ? Quid du Scala ? Quid du moteur de distribution ? Yarn, Meso, Standalone ? Combien de devs vont l'utiliser ? Quid d'un bus de données existant ? -> si il existe -> kafka --> datalake et kafka donne le tempo au cluster Quid des migrations de données ? Schema free = schema later SAAS etc c'est bien, la stack ELK permet d'ajouter des fonctionnalités de type cube quasi gratuitement (hum, au détriment du stockage, mais bon c'est quasi gratuit )
Client finaux
Qui sont les utilisateurs finaux ? Ils ont leur reports Microsoft Reporting Services (SSRS) et leur cubes ok. Il ne faut pas révolutionner les habitudes, mais on peut proposer également de réaliser directement leurs requetes dans le cluster.... via une page web ! Enter spark-notebook : outil de collaboration/visualisation interactif pour créer des batch/streams. Un merveilleux moyen de préparer la transition.
Cela permet d'explorer collaborativement les data.... pour ensuite pourquoi pas intégrer ces résultats dans des rapport avec SSRS.
Notre expérience
cassandra - Concours USI - mongodb - elastic search - lucene - avro - parquet - DEA intelligence artificielle distribuée Moteur de valuation pour asset manager, traitement de centaines de GO de données pour produire 60 milliards de résultats réprésentant 200go en moins de 30 min. 150go de RAM, tuning GC, de serialization... On connait les archi distribuées, j'ai même fait un ORB en C en 1998. On a lu les divers papiers important dont ceux de Matei Zaharia créateur de spark.
Votre projet : Volumétrie de données + Tps + Intégration → on connaît. La persistance en nosql on connaît → Le vrai pb c’est le besoin métier donc la phase 2 et 5.