Journal Data Warehouse

Posté par  . Licence CC By‑SA.
Étiquettes :
3
9
juil.
2017

Bonjour cher journal,

Je vous écris, car je vais devoir travailler à la rentrée sur la conception d'un data warehouse avec un ETL.

Malheureusement ma direction risque de m'imposer des outils propriétaires du type Redshift ou BigQuery pour la partie Data Warehouse.

J'ai recherché des livres sur le sujet pour les amener avec moi pendant mes vacances.

Hélas je ne trouve aucun livre récent.

J'ai trouvé un livre en Français de 2012 :
https://www.amazon.fr/gp/product/384179887X/ref=ox_sc_act_title_1?smid=A1X6FK5RDHNB96&psc=1

Mais qu'ils peuvent expédier d'ici 1 à 2 mois :(

Et j'ai trouvé un livre de 2013 sur Redshift :

http://shop.oreilly.com/product/9781782178088.do

Si vous avez de bons liens sur le sujet, des outils open sources pour montré à ma direction qu'il y'a des alternatives je suis preneur.

  • # Metriques

    Posté par  (site web personnel) . Évalué à 3.

    Quelle quantité de données à stocker ?
    Quelles fonctionnalités attendues ?
    Quelles perfs ?
    Quelle infra ?

    • [^] # Re: Metriques

      Posté par  . Évalué à 2.

      Quelle quantité de données à stocker ?

      Moins de 5 TO

      Quelles fonctionnalités attendues ?

      Pouvoir unifier et dédoublonner nos données provenant de différentes bases.
      Qualifier les données avant l'enregistrement dans le dataware house;
      Et ensuite, configurer un outil de BI.

      Quelles perfs ?

      Nous n'en sommes pas encore là.

      Quelle infra ?

      Idem nous n'avons pas encore fait des tests, mais la direction pousse pour que nous prenions une solution "cloud".

      Nous devrions commencer à la rentrée en testant plusieurs outils du marché.

      D'où ma recherche de livre sur le sujet.

      Je viens de trouver ce livre :
      http://livre.fnac.com/a10403563/Juvenal-Chokogoue-Hadoop

      Je vais aussi essayer de trouver de la documentation sur Redshift & Bigquery afin d'avoir des arguments pour que nous partions sur une solution open source.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 8.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Metriques

        Posté par  (site web personnel) . Évalué à -1.

        Comme dit au dessus, si, les perfs comptent. Un traitement "temps-reel" n'implique pas les mêmes contraintes que du batch offline.

        Ca depend ensuite de ce qu'on veut faire precisement, des évolutions previsibles, de la complexité à priori des traitements etc. Ex: si la taille de la base doit augmenter rapidement, il faut pouvoir faire grossir l'infrastructure sans tout chambouler.

        Donc comme d'hab, je dirai : tenter les solutions classiques et éprouvées, genre pas de trucs exotiques à la noSQL, et si ça bloque vraiment, envisager les Hadoop/Spark etc. Ce qui permet aussi de quantifier les besoins humains.

        Mes deux centimes

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Metriques

            Posté par  (site web personnel) . Évalué à 3.

            Oui.

            "Tenter" dans le sens : essayer avec les outils classiques et éprouvés. Passer à autre chose si les perfs bloquent.

            J'ai l'impression que les DSI veulent caser du Hadoop partout, par principe. Ce qui est idiot.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 3. Dernière modification le 10 juillet 2017 à 00:05.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Metriques

                Posté par  . Évalué à 3.

                le bon exemple est la dépêche sur gramalect AMHA que je trouve vraiment bonne et que j'ai lu intégralement \o/, tenant aboutissant, problème probable, solution possible, prévisionnel de financement etc … un vrai projet comme on aimerait en voir plus souvent. :)

              • [^] # Re: Metriques

                Posté par  . Évalué à 4.

                Un avantage du relationnel, même si ça n'a rien à voir avec le relationnel, ce sont les propriétés ACID, que beaucoup de monde attend quand tu traité des données et que tu n'as pas forcément avec du nosql. Et c'est pour cela que je pense que c'est une bonne base de départ.

                Après, ça n'empêche surtout pas de définir les besoins, mais vu qu'on parle d'analyse de données, au début, on connaît mal ses données, donc les besoins seront mal définis. Ceci parce qu'ils vont pouvoir être redéfinis en fonction de ce qui sera trouvé comme informations pertinentes dedans.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2.

                  Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Metriques

          Posté par  . Évalué à 3.

          genre pas de trucs exotiques à la noSQL

          En voilà une analyse de qualité.

          Mes deux centimes

          Encore un peu trop cher…

  • # Commentaire supprimé

    Posté par  . Évalué à -1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Tu mets la charrue avec les bœufs

      Posté par  . Évalué à -1.

      Promis dès que Grammalecte sort un plug-in pour Chromium je l'installe et je verrais s’il accepte les anglicismes ou si je suis obligé d'écrire "Entrepôt de données ;)"

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1. Dernière modification le 09 juillet 2017 à 14:20.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Tu mets la charrue avec les bœufs

          Posté par  . Évalué à 9. Dernière modification le 09 juillet 2017 à 14:51.

          Qui te dit que je viens d'un pays francophone ?

          Pour info je me trouve en Afrique et ma langue maternelle n'est pas le français ni l'anglais.
          Même si le Français est une langue parlée couramment dans le monde professionnel.

          Ensuite tout le monde peut faire des erreurs, c'est pour cela que des outils comme Grammaclecte existent.

          Tu me juges sur une erreur alors que j'essaye de faire attention à l'orthographe et à la grammaire avec pour le moment un outil propriétaire (Antidote).

          Malgré l'outil et mes efforts, des fautes restent.

          Je pense que ton type de commentaire n'encourage pas les personnes à contribuer à ce site et que cela baisse finalement l'objectif premier de ce site à partager des connaissances sur les logiciels libres.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -4. Dernière modification le 09 juillet 2017 à 15:10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Tu mets la charrue avec les bœufs

              Posté par  . Évalué à 0. Dernière modification le 09 juillet 2017 à 15:32.

              Salut,

              C'est l'extension du vendredi, donc je viens mettre mon grain de sel ou poivre.

              J'ai tiqué comme l'a fait alenvers. On connait ses outils, ou pas.

              Je tique aussi sur ce qu'il te propose : une moyenne.

              Fais un carré latin, ou un A/B testing. Ça plaira plus à tes managers.

              Matricule 23415

              • [^] # Re: Tu mets la charrue avec les bœufs

                Posté par  (site web personnel) . Évalué à 6.

                « J'ai tiqué comme l'a fait alenvers. On connait ses outils, ou pas. »

                Euh, est-ce que le sujet n'est justement pas la question de quelqu'un affirmant ne pas du tout connaître un outil et cherchant des conseils ? La faute d'orthographe dans le mot clef marquant soit une étourderie, soit le niveau d'avancement du projet et de la recherche. Inutile de polémiqué. ne lui faut-il pas visiblement de l'information concrète et accessible dans tous les sens de ce second terme ? C'est en bûchant qu'il deviendra bûcheron.

                « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à -3. Dernière modification le 10 juillet 2017 à 13:24.

                  Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Tu mets la charrue avec les bœufs

          Posté par  . Évalué à -1.

          Non mais sérieusement. Il faudrait quand même que tu saches écrire correctement le nom de ton domaine de travail sans un outil pour t'aider. Cela ne fait pas très sérieux.

          C'est quoi cette aggressivité? Mauvaise journée? Ta femme t'a quitté? Ton boss s'est énervé sur toi?

      • [^] # Re: Tu mets la charrue avec les bœufs

        Posté par  (site web personnel) . Évalué à 8.

        faudra vérifier si la bonne orthographe est

        datafoutoir

        ou

        datafootware

        :-)

        ウィズコロナ

    • [^] # Re: Tu mets la charrue avec les bœufs

      Posté par  (site web personnel) . Évalué à 4.

      Corrigé, merci.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Tu mets la charrue avec les bœufs

          Posté par  . Évalué à 3.

          C'est surtout qu'on ne comprend plus rien à la discussion qui a suivi.

          Ça, ce sont les sources. Le mouton que tu veux est dedans.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 3. Dernière modification le 15 juillet 2017 à 23:53.

            Ce commentaire a été supprimé par l’équipe de modération.

  • # Hadoop ?

    Posté par  . Évalué à 1.

    C'est open source et ça plaît aux managers, car ça permet de dire qu'on fait du Big data.

    • [^] # Re: Hadoop ?

      Posté par  . Évalué à -2.

      Salut,

      je vais devoir travailler à la rentrée sur la conception d'un data warehouse avec un ETL

      Hadoop s'occupe du stockage. Pas du reste.

      Matricule 23415

      • [^] # Re: Hadoop ?

        Posté par  (Mastodon) . Évalué à 5.

        Hadoop est un écosystème assez complet :

        Du stockage : fichiers, bases Nosql , etc
        Des moteurs et API de traitement de données y compris en sql, Machine learning,spatial, etc.
        Gouvernance de la données avec dictionnaire, metabase, lineage
        Sécurité/habilitations
        ETL intégré , batch ou flux
        Notebook

        Bref il s'occupe de tout , et oui il peut servir d’entrepôt de données pour du décisionnel : https://fr.hortonworks.com/solutions/edw-optimization/

        Maintenant si c'est pour 5 TO , Postgresql peut très bien le faire…

        • [^] # Re: Hadoop ?

          Posté par  . Évalué à 3.

          Maintenant si c'est pour 5 TO , Postgresql peut très bien le faire…

          Il faut faire attention à quoi si on veut mettre beaucoup de données dans Postgres? Que la taille des index tienne en mémoire vive, et c'est tout?

          • [^] # Re: Hadoop ?

            Posté par  (Mastodon) . Évalué à 3.

            Il faut faire attention à quoi si on veut mettre beaucoup de données dans Postgres? Que la taille des index tienne en mémoire vive, et c'est tout?

            C'est un minimum , mais il faut surtout faire attention à l'usage : combien d'utilisateurs concurrents et le style des requêtes (sur les colonnes, les lignes , non indexé..etc) si c'est pour du transactionnel avec beaucoup de modifications ou du requetage etc etc..

      • [^] # Re: Hadoop ?

        Posté par  . Évalué à 2. Dernière modification le 10 juillet 2017 à 14:08.

        Tu confonds Hadoop et HDFS.
        HDFS c'est du stockage.
        Hadoop, c'est plein d'outils qui collaborent.

    • [^] # Re: Hadoop ?

      Posté par  . Évalué à 2.

      C'est open source et ça plaît aux managers, car ça permet de dire qu'on fait du Big data.

      Pourquoi Hadoop et pas Spark ? Les domaines d'utilisations se recouvrent pas mal, non? Et Spark est plus rapide.

      • [^] # Re: Hadoop ?

        Posté par  . Évalué à 2.

        En fait, je pensais plutôt au stockage des données.

        Mais oui, Spark est à préconiser en tant que moteur de traitement sur Hadoop.

        • [^] # Re: Hadoop ?

          Posté par  (Mastodon) . Évalué à 2.

          Mais oui, Spark est à préconiser en tant que moteur de traitement sur Hadoop.

          Bien sûr ! , à noter que dans mon commentaire au dessus je n'ai cité que des fonctionnalités sans dire quelle brique technique.
          Le moteur de traitement de données (sql, streaming,machine learning..) ne peut être que Spark ;-)
          Aujourd'hui quand on parle d'Hadoop, et donc très souvent d'une distribution (Cloudera, Hortonworks) , on ne sépare plus Spark qui est intégré de base.

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 5. Dernière modification le 09 juillet 2017 à 22:01.

            Bien sûr ! , à noter que dans mon commentaire au dessus je n'ai cité que des fonctionnalités sans dire quelle brique technique.
            Le moteur de traitement de données (sql, streaming,machine learning..) ne peut être que Spark ;-)
            Aujourd'hui quand on parle d'Hadoop, et donc très souvent d'une distribution (Cloudera, Hortonworks) , on ne sépare plus Spark qui est intégré de base.

            Merci à tout les deux. Mais encore une question ;-)

            Comment on fait pour atteindre un bon niveau de maîtrise avec cette stack hadoop? Il faut suivre des formations? Lire des publications académique de recherche? Regarder les conférences sur youtube? Ou bien encore par bouche à oreille et tatonnement?

            • [^] # Re: Hadoop ?

              Posté par  . Évalué à 3.

              Je ne serais moins tranché que ckyl qui à du passer quelques nuits blanches pour être aussi négatif sur la techno :-)

              Pratiquant aussi professionnellement ces technos, je peux te confirmer que ça sent la peinture fraîche. Il faut parfois savoir être patient et choisir des chemins détournés… Mais le jeux de l'open source est plutôt bien joué casiement tout les projets sont repris par la fondation Apache, et surtout "chez moi ça marche" :-)

              Le mieux c'est de se faire la main avec les VM sandbox proposée par les distrib Hortonworks (fully open source si j'ai bien compris) et Cloudera (moins open source).

              Pour apprendre tout les noms d'oiseaux qui tourne autour de la plateforme, je recommande le livre blanc suivant (qui commence à dater) : http://www.octo.com/fr/publications/19-hadoop-feuille-de-route

              Il y a plein de conférences sur le sujet si tu cherches Hadoop summit / data works sur youtube (en anglais) ou des conférences de meetup parisien ou de devoxx.

              Ensuite, il faut bien définir ce que l'on veut faire, lire des docs, essayer de voir si c'est possible et réessayer, poster sur des Mailing list / stackoverflow et autre. C'est bien aussi d'aller dans des conférences sur le sujet pour échanger. Si ton entreprise a de l'argent, tu peux souscrire au support des distribs mais c'est pas donné (plusieurs milliers d'euros du node).

            • [^] # Re: Hadoop ?

              Posté par  . Évalué à 3.

              Salut,

              Le plus simple, pour moi, c'est de te créer un compte sur aws, et de te créer un petit cluster EMR avec Spark et Zeppelin. Ensuite tu vas sur le site de spark et tu fais le tuto en visant des ressources S3.
              Ça va te prendre 2h, couter environ 12 centimes, et tu pourras mettre ça sur ton cv.

              • [^] # Re: Hadoop ?

                Posté par  . Évalué à 6. Dernière modification le 11 juillet 2017 à 13:18.

                Ça va te prendre 2h, couter environ 12 centimes, et tu pourras mettre ça sur ton CV.

                Si c'est le critère pour mettre quelque chose sur ton CV tu peux t'attendre:

                1. soit à te faire recevoir comme tu le mérites en entretient
                2. soit à tomber dans une boite / projet constituée d'incompétents

                Vu l'état du marché, tu as de grandes chances d'arriver à 2. auquel tu apporteras ta contribution !

                • [^] # Re: Hadoop ?

                  Posté par  . Évalué à 1.

                  Il y avait une pointe de sarcasme, avec la même analyse que toi en arrière plan :)

              • [^] # Re: Hadoop ?

                Posté par  . Évalué à 2. Dernière modification le 11 juillet 2017 à 22:04.

                Le plus simple, pour moi, c'est de te créer un compte sur aws, et de te créer un petit cluster EMR avec Spark et Zeppelin. Ensuite tu vas sur le site de spark et tu fais le tuto en visant des ressources S3.
                Ça va te prendre 2h, couter environ 12 centimes, et tu pourras mettre ça sur ton cv.

                J'ai dû poser la question de façon trop naïve…

                Voilà où j'en suis: La prochaine fois que je veux approfondir une technologie semblable je lirais la mailing liste, je vais me documenter sur l'un ou l'autre algorithme de gestion de la mémoire et des accès concurrents qui ne vont pas manquer d'y être mentionnés, et puis essayer d'aller au contact avec d'autre gens qui s'intéressent au sujet. Mais il faut peut-être avoir déjà bien commencé pour pouvoir en tirer quelque chose.

                Mais ça, c'est aussi ce qu'on lit sur internet et quelqu'un qui n'est encore arrivé à rien peut aussi le dire. Comem moi. Alors j'avais envie de poser la question pour que quelqu'un qui a avancé là-dedans disent ce qu'il en pense.

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 6.

            Aujourd'hui quand on parle d'Hadoop, et donc très souvent d'une distribution (Cloudera, Hortonworks) , on ne sépare plus Spark qui est intégré de base.

            Hadoop et Spark c'est bien la meilleure façon de transformer un truc qui aurait du être simple et robuste en un projet qui coûte 10 à 100x plus cher qu'il n'aurait du, qui est toujours en vrac et que personne ne sait troubleshooter.

            Tout le monde en fait ou dit en faire. Personne ne maîtrise quoi que ce soit ni n'a la moindre idée de ce qu'il fait vraiment. Les perfs des solutions sont généralement à mourir de rire et les coût ops démentiels.

            Ce sont des stacks compliquées qui demandent une grosse expertise dans beaucoup de domaines. Si ce n'est pas votre cœur de métier n'y allez pas ça va sûrement mal se passer. Enfin ce n'est que mon avis non hype driven development de quelqu'un bosse dans l'ecosystème depuis qu'Hadoop a été promu top-level chez Apache…

            • [^] # Re: Hadoop ?

              Posté par  (Mastodon) . Évalué à 3.

              Voilà un avis bien tranché , qui se se respecte certainement d'après ton expérience mais qui est loin de la réalité.
              Des centaines d'entreprises utilisent au quotidien Hadoop/spark depuis plusieurs années (Facebook,linkedin, Arkéia crédit Mutuel, EDF,Mappy, etc etc.
              Pour traiter des petaoctets c'est juste fonctionnel..et un un coût bien moins élevé que des Terradata ou autre Oracle exadata.

              Bien sûr il y a une certaine complexité et on peut trouver des dizaines d’entreprises qui ont complètement raté leur mise en place, ils ont simplement mal été conseillés.

              Et je bosse aussi dans l’écosystème ..comme quoi on a tous des expériences différentes.

              • [^] # Re: Hadoop ?

                Posté par  . Évalué à 4. Dernière modification le 09 juillet 2017 à 23:31.

                Rappel: Si ce n'est pas votre cœur de métier n'y allez pas ça va sûrement mal se passer.

                Des centaines d'entreprises utilisent au quotidien Hadoop/spark depuis plusieurs années (Facebook,linkedin, Arkéia crédit Mutuel, EDF,Mappy, etc etc.

                Oui les boîtes qui ont les moyens et le besoin de jeter des dizaines de mecs compétents sur le problème s'en sortent. Ce n'est pas lié à la techno utilisée qui ferait des miracles c'est du aux compétences mises en œuvre. Si tu n'as pas en interne des mecs qui auraient pu écrire l'outil que tu utilises, qui peuvent patcher le merdier perpetuel qu'est l'écosystème Hadoop (et redéployer demain en prod), de designer, déployer et diagnostiquer des systèmes distribués compliqués et tout ce qui va avec. C'est une mauvaise idée d'y aller. Et ça correspond à 99.9{1,10}% des gens.

                Et je bosse aussi dans l’écosystème ..comme quoi on a tous des expériences différentes.

                Fais un tour sur les mailing list, stack overflow, les confs. Les mecs qui savent vaguement de quoi ils parlent sont l'exception. Le reste n'est que du "tombe en marche".

                • [^] # Re: Hadoop ?

                  Posté par  (Mastodon) . Évalué à 3.

                  Fais un tour sur les mailing list, stack overflow, les confs

                  Merci du conseil, je vais y penser ;-)

      • [^] # Re: Hadoop ?

        Posté par  . Évalué à 1.

        Tu confonds Hadoop et Hive.
        Hive est un moteur de requêtage MapReduce en mode disque.
        Spark en mode mémoire.
        Donc oui, Spark est plus rapide que Hive.

        • [^] # Re: Hadoop ?

          Posté par  . Évalué à 3.

          Puisque tu pars d'une feuille blanche, je te conseille de jeter un coup d’œil à l'architecture SMACK (pour Spark, Mesos, Akka, Cassandra, Kafka):
          https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/

          Tout dépend à quel point tes données sont "Big" ou "Fast" pour avoir vraiment besoin de se genre d'écosystème. Quoiqu'il en soit, mesos me semble en tout cas un très bon choix pour gérer la charge multi-machine (que ça soit pour y mettre du bigdata dessus ou un simple "container management system" via marathon).

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 1.

            Mouais, je trouve dommage de se passer de système de fichier distribué dans une stack dite big data.

            • [^] # Re: Hadoop ?

              Posté par  . Évalué à 1.

              Dans le cloud, s3 fait l'affaire, sans la galère de gérer un noeud hdfs persistant soi-même.

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 3.

            je te conseille de jeter un coup d’œil à l'architecture SMACK

            Hum, je n'ai pas forcément eu des bons retours sur l'utilisation de Spark avec Mesos (je précise que ça ate d'il y a 6 mois voire un peu plus).

            Sinon pour ses besoins, Hadoop m'a l'air un peu overkill, vu la faible quantité de données.

          • [^] # Re: Hadoop ?

            Posté par  (site web personnel) . Évalué à 2.

            sympa, mais on parle de 5To , donc peut être un peu lourd, non?

            ca fait un rouleau compresseur pour écraser une amide, et pour le coup ca fait rien, l amide est trop petite :)

            si tu met un hadoop (HDFS) il te faut au moins 2 serveurs (3 conseillé), ou alors tu squeeze la redondance.

            meme si globalement le choix d'une stack hadoop est plutôt pas mal, ensuite peut être que c ets un POC a 5To et qu ensuite ca sera 50To, et la effectivement, le passage a l échelle sera plutôt facile avec une stack hadoop.

            j utilise une stack bigtop, de apache.org. elle marche plutôt pas mal, et l setup est assez facile a prendre en main.

            • [^] # Re: Hadoop ?

              Posté par  . Évalué à -1.

              Si tu bosses sur aws, 5 To sur s3 c'est peanuts. Pas besoin d'un cluster hdfs.

              • [^] # Re: Hadoop ?

                Posté par  . Évalué à 4.

                Tiens ? Un commercial Amazon ?

                • [^] # Re: Hadoop ?

                  Posté par  . Évalué à 2. Dernière modification le 11 juillet 2017 à 15:43.

                  Non les commerciaux Amazon savent parfaitement que S3 est un object store et que HDFS est un file system (non POSIX et avec de nombreuses limitations).

                  Les deux n'offrent pas les mêmes garanties et n'ont donc pas la même utilité. Un object store étant beaucoup plus simple il est beaucoup plus facile de le scaler. La phrase Si tu bosses sur aws, 5 To sur s3 c'est peanuts. Pas besoin d'un cluster hdfs. est donc très étrange, je serais intéressé par une explication de texte.

                  • [^] # Re: Hadoop ?

                    Posté par  . Évalué à 4.

                    Non les commerciaux Amazon savent parfaitement que S3 est un object store et que HDFS est un file system (non POSIX et avec de nombreuses limitations).

                    Cen n'est pas parce qu'un commercial connait la vérité que c'est ce qu'il va te dire. Il faut toujours vérifier ce que te dit un commercial.

                    • [^] # Re: Hadoop ?

                      Posté par  . Évalué à 2.

                      Pas con, j'y penserais. T'as d'autres bon conseils du genre ? ;)

                  • [^] # Re: Hadoop ?

                    Posté par  . Évalué à 1.

                    Merci pour ta distinction entre hdfs et s3.
                    Dans la demande initiale, je ne vois pas spécialement de nécessiter du HDFS. Un object store, tel s3, pourrait peut être faire l'affaire et être très peu cher (en machine et en temps d'admin).
                    Peut être qu'hdfs apporte plein de choses mais selon le contexte, c'est peut être plein de choses dont on a pas besoin.

                • [^] # Re: Hadoop ?

                  Posté par  . Évalué à 0.

                  non juste un type qui veut potentiellement faire économiser du temps et du fric à des gens qui seraient peut être passés à côté de la version cloud toute prête et documentée.

        • [^] # Re: Hadoop ?

          Posté par  . Évalué à 2. Dernière modification le 10 juillet 2017 à 16:10.

          Tu confonds Hadoop et Hive.

          J'ai essayé de trouver d'où tu étais parti pour faire cette réponse et je n'ai pas pu trouver :)

          Hive est un moteur de requêtage MapReduce en mode disque.

          Non.

          "The Apache Hive™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax."

          Si on vulgarise beaucoup Hive c'est:

          • un metastore qui gère les db & tables
          • un compilateur qui transforme une requête SQL en un plan d'exécution
          • un moteur d'exécution qui va transformer le plan d'exécution en une serie d'opération
          • un driver qui est l'orchestrateur de tout ca

          Historiquement le moteur d'exécution par défaut est MapReduce, c'est a dire que le moteur d'exécution transforme le plan d'exécution en une série de jobs MR. Un MR Hadoop "bête et méchant" a pour lui deux inconvénients d'un point de vue perf:

          1. Le paradigme MR tire sa robustesse des checkpoints entre chaque phase. Par défaut Hadoop fait ça sur disque et quand les phases sont légères et nombreuses les IO deviennent le facteur nettement dominant.
          2. La soumission d'un job Hadoop MR est très lente (~10s), c'est "juste" un problème d'implémentation.

          Ça explique très certainement ton raccourci grossier, qui oubli aussi que ce que tu perds d'un côté tu le gagnes de l'autre (ex: espace d’adressage partagé et survivant entre traitements = Possibilités d'optimisations VS difficulté de gestion des ressources et instrumentation VS coûts ressources).

          Mais MR n'est qu'un moteur d'exécution comme un autre. Tu peux brancher le moteur d'exécution que tu veux, il existe aussi des moteurs au dessus de Tez et de Spark. Au cours d'une requête tu peux parfaitement t'affranchir d'aller toucher le disque si tu veux, à l'exception de la lecture des données d'entrées et de l'écriture des résultats.

          Si tu veux aussi éviter ces IO, comme tu le ferais avec des executors Spark peristant avec une RDD caché sur lequel tu fais de nombreuses requêtes SQL, tu peux aller voir LLAP. Rien de magique, tu ajoutes des démons qui survivent entre les requêtes et qui permettent de garder les données quelques part dans un espace d’adressage. Ça te permet supprimer des IO contre un coût de ressource plus important. Intéressant dans certains cas et pas dans d'autres.

          Les concepts sont toujours les mêmes et on les réimplémente à tous les niveaux de la stack.

          Spark en mode mémoire

          C'est un raccourci tellement grossier qu'il n'est absolument d'aucune utilité.

          Donc oui, Spark est plus rapide que Hive.

          Soupir.

          Le monde est malheureusement compliqué; tant sur le fait que de telles généralités sont toujours fausses que sur le fait que la latence d'une requête n'est qu'un ility parmi d'autres.

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 1.

            Pardon mais je réponds à qqun qui dit "Pourquoi Hadoop et pas Spark ?"
            Donc j'en suis pas à rentrer dans les détails que tu mentionnes par la suite.

        • [^] # Re: Hadoop ?

          Posté par  . Évalué à 1.

          Non, non je ne confond pas. En gros, Hadoop est un framework composé de trois modules :
          - HDFS : système de fichier distribué
          - Yarn : moteur de partage de ressources distribués (CPU et RAM) un peu comme Mesos
          - Map/Reduce : moteur de traitement distribué qui est de moins en moins utilisé car chaque étape génère une écriture disque et les perfs très faible à la différence de moteur d'exécution qui utilise plus la RAM comme Spark.

          Pour ce qui est de Hive c'est une surcouche SQL qui permet de faire rapidement des requêtes sur des données structurée stockée sur HDFS à l'aide moteur de traitement comme Map/Reduce et Spark.

          ps : je vulgarise, je défis les puristes de trouver les raccourcis que je prends dans mes explications.

        • [^] # Re: Hadoop ?

          Posté par  . Évalué à 2.

          Tu confonds Hadoop et Hive.
          Hive est un moteur de requêtage MapReduce en mode disque.

          On n'utilise jamais le MapReduce Hadoop directement? On passe toujours par une surcouche comme Hive?

          • [^] # Re: Hadoop ?

            Posté par  . Évalué à 1.

            On peut utiliser le M/R directement mais il faut enchaîner toi même les étapes de M/R la où pig et hive le font pour toi. Sans compter qu'ils peuvent utiliser tez ou spark comme moteur d’exécution sans avoir à tout réécrire.

  • # Kettle

    Posté par  (site web personnel) . Évalué à 2.

    C'est le meilleur ETL que l'on puisse trouvé. C'est open source.

    Il y a même pas à discuter ce point.

    • [^] # Re: Kettle

      Posté par  (Mastodon) . Évalué à 1.

      C'est le meilleur ETL que l'on puisse trouv~~é~~R. C'est open source.

      C'est le meilleur je ne discuterai pas , mais il y en a d'autres encore plus meilleurs ;-)
      https://kylo.io/
      C'est basé entre autre sur Nifi (l'ETL Apache Hadoop) et c'est Libre aussi.

      • [^] # Re: Kettle

        Posté par  (site web personnel) . Évalué à 1.

        il est peut-être pas mal ton ETL, je dis pas, mais j'ai l'impression qu'il fait tout sauf ETL (si j'ose dire)…

        Nous, on a environ 20 applications métiers, c'est le grand bordel comme j'aime, dans 5 filiales différentes et très peu de moyen (moi et 1 ou 2 stagiaires, c'est entrain de changé, mais ce n'est pas la question). Les données sont entreposées n'importe comment, elles ne sont pas jointes, avec des base de données toutes plus exotiques les unes que les autres, parfois pas de base SQL.

        Kettle fait des miracles dans ce cas. ça ne vaut évidement pas un développement spécifique, par contre, la simplicité de prise en main le rend accessible aux administrateurs (même ceux qui gèrent des PC sous Windows, si j'ose dire).

        Alors c'est vrai, la volumétrie est très faible, et une instance de Postgres suffit à tout centraliser, peut-être que lorsque la volumétrie est plus importante, il faut un workflow plus spécifique, réparti. Mais pour 95% et des bananes (si, j'ose dire!), mon Kettle il est top!

        • [^] # Re: Kettle

          Posté par  (Mastodon) . Évalué à 4.

          il est peut-être pas mal ton ETL, je dis pas, mais j'ai l'impression qu'il fait tout sauf ETL (si j'ose dire)…

          Si si il fait ETL aussi , même mieux : ELT , mais c'est vrai que c'est plus un dataflow qui est capable de prendre en charge aussi la partie datapréparation et découverte/analyse.

          Si tu regarde la vidéo tu vois les trois parties que sont Ingest qui correspond à la partie ETL , Prepare et discover.

          Mais je suis toujours d'accord avec toi Kettle est très bien tant qu'on reste sur des volumes raisonnables , ce qui est souvent le cas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.