Il y a souvent des difficultés dans la communication entre les équipes d’exploitation et les équipes
de développement. Les enjeux ne sont pas les mêmes: les uns ont pour mission de stabiliser
le système, les autres au contraire de le faire évoluer. Ces incompréhensions sont encore plus
fortes avec les équipes BI, car les bases BI ont des besoins très différents des applications traditionnelles.
En expliquant ces différences, j’espère amener à une meilleure compréhension entre
les équipes. C’est aussi l’occasion de parler des technologies récentes qui adressent les besoins
BI: Exadata, In-Memory, réplication temps réel,…
BigData_TP1: Initiation à Hadoop et Map-ReduceLilia Sfaxi
Pour accéder aux fichiers nécessaires pour faire ce TP, visitez: https://drive.google.com/folderview?id=0Bz7DokLRQvx7M2JWZEt1VHdwSE0&usp=sharing
Pour plus de contenu, Visitez http://liliasfaxi.wix.com/liliasfaxi !
Pour accéder aux fichiers nécessaires pour faire ce TP, visitez: https://drive.google.com/folderview?id=0Bz7DokLRQvx7M2JWZEt1VHdwSE0&usp=sharing
Pour plus de contenu, Visitez http://liliasfaxi.wix.com/liliasfaxi !
MapReduce: Traitement de données distribué à grande échelle simplifiéMathieu Dumoulin
Présentation qui reprend les éléments principaux de l'article fondamental sur MapReduce de Dean et Ghemawat de 2004: MapReduce: simplified data processing on large clusters
Spark, ou comment traiter des données à la vitesse de l'éclairAlexis Seigneurin
Spark fait partie de la nouvelle génération de frameworks de manipulation de données basés sur Hadoop. L’outil utilise agressivement la mémoire pour offrir des temps de traitement jusqu’à 100 fois plus rapides qu'Hadoop. Dans cette session, nous découvrirons les principes de traitement de données (notamment MapReduce) et les options mises à disposition pour monter un cluster (Zookeper, Mesos…). Nous ferons un point sur les différents modules proposés par le framework, et notamment sur Spark Streaming pour le traitement de données en flux continu.
Présentation jouée chez Ippon le 11 décembre 2014.
Venez découvrir les méthodes, outils et best practices utilisés par les experts du Support Microsoft pour identifier et corrigier les problèmes de performances sur SQL Serveur ou tout simplement en optimiser les performances. Cette session présentée par nos spécialistes au Support SQL Serveur en France, sera pour vous une occasion unique de les rencontrer ! Avec environ 50% de contenu original pour cesTechdays, nous aborderons entre autre la gestion des index, du columns store ou encore de la compression, nous vous présenterons également les outils utilisés et la manière de les utiliser.
Big Data : Hadoop
- Généralité
- Architecture HDFS
- Algorithme MapRduce
- Architecture YARN
- Hadoop v3.x vs Hadoopv2.x
Cours Big Data - Chap2 - GI3 - ENIS
Performing or not performing that is the question ! Comment diagnostiquer les problèmes de performance, les bonnes pratiques. Configurations, trace flags, indexes, statistiques…
Speakers : Yanick Mezui (Microsoft), Frederic Pichaut (Microsoft)
BigData_TP1: Initiation à Hadoop et Map-ReduceLilia Sfaxi
Pour accéder aux fichiers nécessaires pour faire ce TP, visitez: https://drive.google.com/folderview?id=0Bz7DokLRQvx7M2JWZEt1VHdwSE0&usp=sharing
Pour plus de contenu, Visitez http://liliasfaxi.wix.com/liliasfaxi !
Pour accéder aux fichiers nécessaires pour faire ce TP, visitez: https://drive.google.com/folderview?id=0Bz7DokLRQvx7M2JWZEt1VHdwSE0&usp=sharing
Pour plus de contenu, Visitez http://liliasfaxi.wix.com/liliasfaxi !
MapReduce: Traitement de données distribué à grande échelle simplifiéMathieu Dumoulin
Présentation qui reprend les éléments principaux de l'article fondamental sur MapReduce de Dean et Ghemawat de 2004: MapReduce: simplified data processing on large clusters
Spark, ou comment traiter des données à la vitesse de l'éclairAlexis Seigneurin
Spark fait partie de la nouvelle génération de frameworks de manipulation de données basés sur Hadoop. L’outil utilise agressivement la mémoire pour offrir des temps de traitement jusqu’à 100 fois plus rapides qu'Hadoop. Dans cette session, nous découvrirons les principes de traitement de données (notamment MapReduce) et les options mises à disposition pour monter un cluster (Zookeper, Mesos…). Nous ferons un point sur les différents modules proposés par le framework, et notamment sur Spark Streaming pour le traitement de données en flux continu.
Présentation jouée chez Ippon le 11 décembre 2014.
Venez découvrir les méthodes, outils et best practices utilisés par les experts du Support Microsoft pour identifier et corrigier les problèmes de performances sur SQL Serveur ou tout simplement en optimiser les performances. Cette session présentée par nos spécialistes au Support SQL Serveur en France, sera pour vous une occasion unique de les rencontrer ! Avec environ 50% de contenu original pour cesTechdays, nous aborderons entre autre la gestion des index, du columns store ou encore de la compression, nous vous présenterons également les outils utilisés et la manière de les utiliser.
Big Data : Hadoop
- Généralité
- Architecture HDFS
- Algorithme MapRduce
- Architecture YARN
- Hadoop v3.x vs Hadoopv2.x
Cours Big Data - Chap2 - GI3 - ENIS
Performing or not performing that is the question ! Comment diagnostiquer les problèmes de performance, les bonnes pratiques. Configurations, trace flags, indexes, statistiques…
Speakers : Yanick Mezui (Microsoft), Frederic Pichaut (Microsoft)
Utiliser Hadoop en perl avec HadoopStreamingDavid Morel
How to use the HadoopStreaming class to work in Hadoop using perl (or any language, actually)
Presentation made for the French Perl Workshop 2012 in Strastbourg.
Rapide introduction à Hadoop lors du lancement du Casablanca Hadoop & Big Data Meetup.
En partenariat avec Hortonworks
http://www.meetup.com/Casablanca-Hadoop-et-Big-Data-Meetup
Cette étude porte sur la brique Spark SQL de la plateforme Apache Spark.
L'objectif est de présenter les concepts et les fonctionnalités de spark SQL.
Les points abordés sont :
- Architecture
- API de Spark SQL
- Opérations sur DataFrames/DataSets
- Opérations relatives au nettoyage de données
- Opérations de conversion (DataFrame, DataSet, Collection, RDD)
- Opérations relationnelles
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureMicrosoft
L'algorithme Map/Reduce et sa mise en oeuvre avec Apache Hadoop permettent de gérer de très grands volumes de données non structurées. Microsoft adopte Haddop sur Windows et Windows Azure. Venez voir comment.
Annexe du cours Big Data
- Annexe A : Etapes d’un projet Big Data
- Annexe B : Schéma général de l’Algorithme MapReduce
- Annexe C : OpenStack & Hadoop
- Annexe D : Mahout
Hug france - Administration Hadoop et retour d’expérience BI avec Impala, lim...Modern Data Stack France
Hadoop User Group du lundi 6 oct 2014:
Talk #3: Administration Hadoop et retour d’expérience BI avec Impala, limites et recommandations par Abed Ajraou et Cherif Tifrani de Solocal (Pages Jaunes).
The document discusses various data modification operations and how much redo is generated for each. It shows that inserts, deletes, updates, and DML on indexed tables can generate significant redo, while direct path inserts on NOLOGGING tables can minimize redo generation. The document also explains why some redo is always needed even for temporary changes, to support functions like media recovery and standby databases.
Utiliser Hadoop en perl avec HadoopStreamingDavid Morel
How to use the HadoopStreaming class to work in Hadoop using perl (or any language, actually)
Presentation made for the French Perl Workshop 2012 in Strastbourg.
Rapide introduction à Hadoop lors du lancement du Casablanca Hadoop & Big Data Meetup.
En partenariat avec Hortonworks
http://www.meetup.com/Casablanca-Hadoop-et-Big-Data-Meetup
Cette étude porte sur la brique Spark SQL de la plateforme Apache Spark.
L'objectif est de présenter les concepts et les fonctionnalités de spark SQL.
Les points abordés sont :
- Architecture
- API de Spark SQL
- Opérations sur DataFrames/DataSets
- Opérations relatives au nettoyage de données
- Opérations de conversion (DataFrame, DataSet, Collection, RDD)
- Opérations relationnelles
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureMicrosoft
L'algorithme Map/Reduce et sa mise en oeuvre avec Apache Hadoop permettent de gérer de très grands volumes de données non structurées. Microsoft adopte Haddop sur Windows et Windows Azure. Venez voir comment.
Annexe du cours Big Data
- Annexe A : Etapes d’un projet Big Data
- Annexe B : Schéma général de l’Algorithme MapReduce
- Annexe C : OpenStack & Hadoop
- Annexe D : Mahout
Hug france - Administration Hadoop et retour d’expérience BI avec Impala, lim...Modern Data Stack France
Hadoop User Group du lundi 6 oct 2014:
Talk #3: Administration Hadoop et retour d’expérience BI avec Impala, limites et recommandations par Abed Ajraou et Cherif Tifrani de Solocal (Pages Jaunes).
The document discusses various data modification operations and how much redo is generated for each. It shows that inserts, deletes, updates, and DML on indexed tables can generate significant redo, while direct path inserts on NOLOGGING tables can minimize redo generation. The document also explains why some redo is always needed even for temporary changes, to support functions like media recovery and standby databases.
CBO choice between Index and Full Scan: the good, the bad and the ugly param...Franck Pachot
Usually, the conclusion comes at the end. But here I will clearly show my goal: I wish I will never see the optimizer_index_cost_adj parameters again. Especially when going to 12c where Adaptive Join can be completely fooled because of it. Choosing between index access and full table scan is a key point when optimizing a query, and historically the CBO came with several ways to influence that choice. But on some system, the workarounds have accumulated one on top of the other – biasing completely the CBO estimations. And we see nested loops on huge number of rows because of those false estimations.
Oracle In-Memory option to improve analytic queries
In-Memory is now the trend for database editors. But they do not implement in-memory storage for the same reason nor the same architecture. Oracle In-Memory option directly addresses BI reporting. Oracle has always favored an hybrid approach where we can query the OLTP database (from Oracle 6 the reads do not block the writes) and the In-Memory approach follows the same philosophy: run efficient analytic queries on OLTP databases. Their first approach to columnar storage was bitmap indexes in 8i, which were very efficient to support ad-hoc queries but not compatible with an OLTP workload. Then came the Exadata SmartScan and Hybrid Columnar Compression that was still addressing datawarehouses load and reporting.
The 12c In-Memory option now gives columnar and in-memory efficiency directly on the OLTP database, without changing any design or code. A demo will show how this option can be used.
The document summarizes how SQL Plan Directives in Oracle 12c can help address issues caused by cardinality misestimation in the optimizer. It provides an example where the optimizer underestimates the number of rows returned by a query on a table due to not having statistics on correlated columns. In 12c, a SQL Plan Directive is automatically generated after the first execution to capture this misestimation. On subsequent queries, the directive can be used to provide more accurate cardinality estimates through automatic reoptimization or dynamic sampling.
This document discusses Oracle table lock modes, including:
- There are 6 lock modes including share (S) and exclusive (X) that have multiple names like row share (RS) and row exclusive (RX).
- Locks can be acquired at the table level (TM locks) or row level (TX locks). TM locks can be in row share/exclusive modes.
- Share locks allow concurrent access while exclusive locks prevent it. Understanding these lock types helps explain Oracle's lock compatibility matrix.
Testing Delphix: easy data virtualizationFranck Pachot
The document summarizes the author's testing of the Delphix data virtualization software. Some key points:
- Delphix allows users to easily provision virtual copies of database sources on demand for tasks like testing, development, and disaster recovery.
- It works by maintaining incremental snapshots of source databases and virtualizing the data access. Copies can be provisioned in minutes and rewound to past points in time.
- The author demonstrated provisioning a copy of an Oracle database using Delphix and found the process very simple. Delphix integrates deeply with databases.
- Use cases include giving databases to each tester/developer, enabling continuous integration testing, creating QA environments with real
Oracle Parallel Distribution and 12c Adaptive PlansFranck Pachot
Parallel Distribution and 12c Adaptive Plans
In the previous newsletter we have seen how 12c can defer the choice of the join method to the first execution. We considered only serial execution plans. But besides join method, the cardinality estimation is a key decision for parallel distribution when joining in parallel query. Ever seen a parallel query consuming huge tempfile space because a large table is broadcasted to lot of parallel processes? This is the point addressed by Adaptive Parallel Distribution.
Once again, that new feature is a good occasion to look at the different distribution methods.
Exadata X3 in action: Measuring Smart Scan efficiency with AWRFranck Pachot
Exadata comes with new statistics and wait events that can be used to measure the efficiency of its main features (Smart
Scan offloading, Storage Indexes, Hybrid Columnar Compression and Smart Flash Cache).
The goal of this article is not to compare Exadata with any other platforms, but rather to help understand the few basic
statistics that we must know in order to evaluate if Exadata is a good solution for a specific workload, and how to
measure that the Exadata features are well used.
We will cover those few statistics from the ‘Timed events’ and ‘System Statistics’ sections of the AWR report.
Oracle Join Methods and 12c Adaptive PlansFranck Pachot
Join Methods and 12c Adaptive Plans
In its quest to improve cardinality estimation, 12c has introduced Adaptive Execution Plans which deals with the cardinalities that are difficult to estimate before execution. Ever seen a hanging query because a nested loop join is running on millions of rows?
This is the point addressed by Adaptive Joins. But that new feature is also a good occasion to look at the four possible join methods available for years.
12cR2 Single-Tenant: Multitenant Features for All EditionsFranck Pachot
Multitenant architecture is available even without Oracle's multitenant option. In this session take a look at the overhead and the 12.2 new features so that you can choose among single-tenant or non-container databases. These features include agility in data movement, easy flashback, and fast upgrade.
Reading AWR or Statspack Report - Straight to the GoalFranck Pachot
The document discusses the benefits of meditation for reducing stress and anxiety. Regular meditation practice can help calm the mind and body by lowering heart rate and blood pressure. Studies have shown that meditating for just 10-20 minutes per day can have significant positive impacts on both mental and physical health over time.
LIVRE BLANC
« LA GESTION, CONVERSION, IMPRESSION, PUBLICATION ET DISTRIBUTION DOCUMENTAIRE SAP »
L’archivage de documents est un point essentiel pour le bon fonctionnement d’un grand nombre d’entreprises. En effet, celles-ci doivent s’assurer que les documents soient accessibles pour une population d’utilisateurs, et ce d’une manière optimisée et sécurisée. Ces documents sont également bien souvent liés à des processus opérationnels de l’entreprise (les achats, la fabrication, la maintenance, etc.).
Les utilisateurs de l’ERP SAP, maîtrisent l’ensemble des données de leur entreprise grâce aux différents modules métiers. Bien souvent, la donnée seule n’est pas suffisante pour la mise en œuvre de processus opérationnels, certains documents sont indispensables pour la réalisation de certaines tâches(opérations de fabrication, de maintenances…) ou certains échanges (avec les clients, les fournisseurs….)
Nous vous proposons de découvrir les réponses à ces impératifs de gestion et de distribution documentaire dans l’environnement SAP. En effet, mySAPTM PLM dispose de l’ensemble des fonctionnalités permettant une gestion des archives adaptée aux besoins opérationnels de votre entreprise...
Big Data ou comment retrouver une aiguille dans une botte de foinPALO IT
Un parc informatique d’un millier de machines génère de nombreux Terra Octets de logs. Comment parvenir à y retrouver une information pertinente et comment valoriser les informations contenues dans ces logs ?
Au programme :
- La centralisation des logs : back to basics;
- Cas pratiques : détection d’attaques DoS et refacturation sur plateforme mutualisée;
- Une grille Hadoop : en quoi ça consiste ?
Converteo renouvelle son panorama sur les opportunités liées à une infrastructure Data-Lakes. Cette technologie a démontré ses capacités d’exploitation et de valorisation des datas des entreprises et, dans un contexte de mise en conformité RGPD, révèle encore plus son agilité.
Mieux comprendre le Data-Lake :
Littéralement traduit par lac de données, il s’agit d’un espace de stockage permettant le traitement d’informations de plusieurs sources et ce, de manière quasi illimitée et en un temps record.
Le Data-Lake est donc une réelle opportunité et doit être considéré en amont de toute démarche data-driven, que ce soit dans le domaine :
- Du marketing : pour alimenter des campagnes, choisir un lieu d’implantation d’un nouveau magasin ;
- De l’expérience client : pour personnaliser une offre, recommander les produits adéquats ;
- De la business Intelligence : pour créer une vision 360° de ses clients, piloter la pression publicitaire ;
- De la performance opérationnelle : pour réduire ses coûts informatiques, adapter ses ressources en fonction de l’activité.
Infrastructure flexible, elle permet donc un large champ d’analyse qualitative avec des données activables à tout moment en fonction des besoins business.
Synchroniser ses applications (plus) simplementgplanchat
Lors du PHP Tour 2017 Nantes, nous avions vu la présentation du composant akeneo/batch. Revenons sur 3 ans supplémentaires d'usage, de réflexions et de refactorisation qui ont abouti à la création d'un framework spécialisé.
Dans des environnement de plus en plus interconnectés, de plus en plus hétéroclites, nous voyons apparaitre l'usage des PWA, la généralisation des API et des tâches en files d'attentes asynchrones. Là où les solutions pour interroger des petits volumes de données dans des bases distantes commencent à atteindre une certaine maturité.
Où en sommes-nous sur les synchronisations en grand volume et aux formats de données hétéroclites ?
Le Big Data offre la capacité de traiter des volumes de données conséquents à l’aide d’architectures techniques nouvelles, comment les utilisateurs traditionnels (datamanager, datasteward, dataminers) accèderont et traiteront les données dans ces nouvelles architectures ?
La deuxième partie sur le cours Business Intelligence et Data warehouse.
Si vous avez des questions, des remarques ou des propositions afin d’améliorer le contenu et la qualité de ce cours, n' hésitez pas à me contacter via mon email:
pr.azizdarouichi@gmail.com.
Bonne lecture.
A. DAROUICHI
Tout ce que vous devez savoir sur les meilleures pratiques autour d'Exchange 2013... Des thèmes aussi divers que "comment virtualiser au mieux un serveur Exchange 2013" à "Que faire de mes dossiers partagés et que deviennent t'ils dans Exchange 2013". Tout ce qu'il y a à savoir expliqu par nos meilleurs experts Microsoft sur le sujet.
Speaker : Guy Groeneveld (Microsoft), Stefan Plizga (Microsoft), Raquel Municio (Microsoft France), Lionel Constantin (Microsoft France)
Gab17 lyon - La BI traditionnelle est une histoire du passée. Impacts de la r...AZUG FR
Global Azure Bootcam Lyon, France 2017 - La BI traditionnelle est une histoire du passée. Impacts de la révolution Cloud Azure sur la BI data en général, by Ihor Leontiev et Loris Andaloro
OSA02 - Pas de transactionnel haute performance sans un couple machine logici...Nicolas Desachy
Ressources cloisonnées et dépourvues de flexibilité ? Goulots d\’étranglement au niveau des performances ? Temps d\’arrêt inacceptables ? Coûts et complexité liés à l\’évolutivité ? Tâches de gestion manuelles très longues ? L’explosion des données et la croissance des transactions augmente la demande de systèmes éprouvés et capables de garantir l\’intégrité, les performances et la flexibilité tout en permettant de réaliser des économies. Si ces questions vous interpellent, cet atelier est pour vous. Vous y découvrirez les dernières nouveautés en terme de systèmes transactionnels IBM et les raisons pour lesquelles de nombreux clients migrent vers ces systèmes.
En prime : les premiers retours d’expérience de portage vers IBM DB2 9.7
Dictionnaire des termes techniques de la business intelligence v6pformosa
La Business Intelligence est une source, d'acronymes et de concepts, incroyable. J'ai ici essayé de regrouper les définitions et les approches qui définissent au mieux le décisionnel. Avec pour but d'en faciliter sa compréhension par le plus grand nombre.
Similaire à Les bases BI sont-elles différentes? (20)
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...Horgix
This is the slide deck of a talk by Alexis "Horgix" Chotard and Laurentiu Capatina presented at the MongoDB Paris User Group in June 2024 about the feedback on how PayFit move away from a monolithic hell of a self-hosted MongoDB cluster to managed alternatives. Pitch below.
March 15, 2023, 6:59 AM: a MongoDB cluster collapses. Tough luck, this cluster contains 95% of user data and is absolutely vital for even minimal operation of our application. To worsen matters, this cluster is 7 years behind on versions, is not scalable, and barely observable. Furthermore, even the data model would quickly raise eyebrows: applications communicating with each other by reading/writing in the same MongoDB documents, documents reaching the maximum limit of 16MiB with hundreds of levels of nesting, and so forth. The incident will last several days and result in the loss of many users. We've seen better scenarios.
Let's explore how PayFit found itself in this hellish situation and, more importantly, how we managed to overcome it!
On the agenda: technical stabilization, untangling data models, breaking apart a Single Point of Failure (SPOF) into several elements with a more restricted blast radius, transitioning to managed services, improving internal accesses, regaining control over risky operations, and ultimately, approaching a technical migration when it impacts all development teams.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
Les bases BI sont-elles différentes?
1. DOAG/SOUG News – édition numéro 5 pour la Romandie 3
Les bases BI sont-elles différentes?
Franck Pachot, dbi-services
Il y a souvent des difficultés dans la communication entre les équipes d’exploitation et les équipes
de développement. Les enjeux ne sont pas les mêmes: les uns ont pour mission de stabiliser
le système, les autres au contraire de le faire évoluer. Ces incompréhensions sont encore plus
fortes avec les équipes BI, car les bases BI ont des besoins très différents des applications tradi-
tionnelles. En expliquant ces différences, j’espère amener à une meilleure compréhension entre
les équipes. C’est aussi l’occasion de parler des technologies récentes qui adressent les besoins
BI: Exadata, In-Memory, réplication temps réel,…
Business Intelligence
C’est le nom qu’on utilise aujourd’hui, et il peut paraître
pompeux. Les premières bases BI sur lesquelles j’ai travail-
lé – en 1996 – nous les appelions modestement ‘infocen-
tre’. Il s’agissait simplement de récupérer des informations
venant des différentes bases opérationnelles. Ces bases
étaient interrogées par un outil permettant à l’utilisateur de
construire des requêtes à la demande (Business Objects),
il fallait donc charger les données dans un modèle adapté
à cela. Dès qu’on a ouvert cette possibilité aux utilisateurs,
les besoins se sont multipliés: besoins de plus de données,
de plus d’historique, etc. Les besoins de reporting adressés
d’habitude par les applications ont aussi été transférés sur
ces projets, du fait de la simplicité des outils.
On a très vite appelé ça ‘entrepôt de données’ (data-
warehouse) vu la consolidation de toutes les données de
l’entreprise. Puis ‘systèmes d’aide à la décision’ (DSS – Decisi-
on Support System) ou décisionnel, vu les nouveaux groupes
d’utilisateurs. Lorsque les outils ont intégré de plus en plus
cette aide à la décision, on a commencé à parler de Business
Intelligence. On parle aussi de requêtes analytiques.
Volumes de données
Ce qui caractérise en premier lieu les bases datawarehouse,
c’est leur volume. Les informations viennent de tout le sys-
tème d’information, sont historisées, sont souvent stockées
plusieurs fois pour différents besoins de reporting, sont dé-
normalisées pour éviter de refaire plusieurs fois les mêmes
jointures. En 8i, Oracle a introduit dans sa documentation
un volume ‘Data Warehousing Guide’ qui a très vite été réa-
ménagé pour se scinder en deux, les fonctionnalités liées
au volume (vues matérialisées, parallel query, partitioning)
sont décrites dans le VLDB – Very Large Database – Guide.
Beaucoup de ces notions sont devenues courantes
aujourd’hui. On partitionne les tables, si on est en Enter-
prise Edition avec option partitioning. On met en place des
technologies de backup adaptées à ces volumes (snapshots
offerts par le stockage). Les DBA sont habitués à administ-
rer des bases de plusieurs TB (terabytes).
Tablespace TEMP
Mais il y a d’autres points qui sont plus difficiles à accep-
ter pour les DBA. Lorsque l’équipe BI demande d’agrandir le
tablespace TEMP, on négocie la taille en GB. Mais pour un
datawarehouse, c’est trop faible. Le tablespace temporaire
sert à faire plusieurs passes pour les tris et jointures qui ne
logent pas en mémoire. Si on a seulement 200 MB de don-
nées à trier, on n’a pas besoin de tempfiles pour ça. On doit
pouvoir le faire en PGA. En datawarehouse, on manipule de
dizaines de GB. Lorsqu’on fait un gros chargement de don-
nées, on va reconstruire les index. Il faudra pouvoir trier les
données indexées. On va compter en dizaines de GB, voire
centaine.
Quelle taille de TEMP est raisonnable? Regardez le plus
gros index, regardez la plus grosse table de dimension, re-
gardez la plus grosse partition des tables de faits, et ça vous
donnera une idée. Vous aurez besoin de faire des tris, join-
ture par table de hachage, de mettre en buffer, sur ces vo-
lumes, et vous voulez le faire en une passe.
Evidemment, si vous partitionnez les tables et n’avez que
des ‘local index’, vous limitez le volume nécessaire. Pensez
à partitionner sur les mêmes colonnes les tables de faits qui
vont participer à une jointure. Le ‘partition wise join’ permet
de limiter la taille du hash area nécessaire.
Par contre, les chargements du datawarehouse, et
peut-être certains reportings, vont faire du parallel query.
N’oubliez pas que vous aurez besoin de beaucoup plus de
TEMP pour deux raisons : plus de session en parallèle et
plus de buffering entre opérations.
Cependant, n’allez pas augmenter le tablespace TEMP dès
qu’il y a une requête qui se plante. C’est parfois le symptôme
d’un mauvais plan d’exécution. Lorsqu’une requête se plan-
2. 4 www.soug.ch
te pour cette raison, il faut aller voir son plan d’exécution. Si
vous avez Tuning Pack, alors SQL Monitoring permet de voir
le volume de TEMP en temps réel, directement dans le plan
d’exécution. Sinon, c’est les V$SQL_WORKAREA.
PGA aggregate target
Bien sûr, avant de remplir le TEMP, il faut utiliser au ma-
ximum la mémoire. En datawarehouse, on n’a pas besoin
d’une grosse SGA. On ne s’attend pas à garder les tables en
buffer cache, sauf peut-être les petites dimensions, et les
index bitmap. On n’a pas besoin d’une grande shared pool,
sauf si on a un ETL écrit en pl/sql.
Donc il faut affecter un maximum de mémoire aux ses-
sions pour la PGA. Si vous êtes en AMM (MEMORY_TAR-
GET) ces zones vont s’adapter en fonction du besoin. Mais
lorsque la mémoire se compte en dizaine de GB, il faut pré-
férer l’utilisation des hugepages, et on doit définir explicite-
ment SGA_TARGET et PGA_AGGREGATE_TARGET
De toute façon, la gestion automatique des workareas,
avec PGA_AGGREGATE TARGET, est une fonctionnalité faite
pour l’OLTP. Il s’agit de répartir la mémoire aux différentes
sessions. Le chargement datawarehouse (inserts en direct-
path, rebuild d’index, etc) va souvent se faire en une seule
session. Alors si vous n’êtes pas en parallel query, les tailles
de workarea calculées par PGA_AGGREGATE TARGET vont
être trop petites.
La solution, c’est ALTER SESSION SET WORKAREA_SIZE_
POLICY=MANUAL et définir manuellement une SORT_AREA_
SIZE assez grande. Non, ce n’est pas un retour à la préhis-
toire. C’est juste que si vous avez une seule session, et que
vous êtes le seul sur la machine, alors vous voulez utiliser
toutes les ressources.
DDL
Et oui, les bonnes pratiques de l’OLTP ne s’appliquent pas
au datawarehouse. Si faire du DDL en OLTP (drop/create/
alter) doit être prohibé, il est tout à fait normal d’en voir
passer lors du chargement quotidien du datawarehouse.
Là encore, il faut garder à l’esprit que lors du chargement
du datawarehouse il n’y a pas d’autres utilisateurs. Pas de
problème si tous les curseurs sont invalidés. Ce qu’on veut
c’est optimiser ce chargement. Si cette idée vous gêne, alors
vous devez considérer le chargement quotidien comme si
c’était une release applicative, avec une reprise de données.
La base n’est pas ouverte aux utilisateurs et on essaie de
leur mettre en place au plus vite la nouvelle version.
Donc les opérations réservées à l’administration de
la base deviennent des opérations courantes en data-
warehouse, et automatiques. Il va falloir l’accepter, et don-
ner les privilèges nécessaires à l’équipe BI. En général la
base est dédiée, et on conseille de modulariser les tables
en plusieurs schemas, alors on peut même devoir accepter
des droits ‘ANY’.
Et c’est votre intérêt en tant que DBA. Vous ne voulez
probablement pas voir passer des milliards de delete/insert
sur la base toutes les nuits? Alors il faut donner les moyens
de travailler sur des gros volumes de données. RMAN du-
plicate, transportable tablespace, snapshot standby,… il est
tout à fait possible de les programmer toutes les nuits pour
alimenter l’ODS. Les ETL sont fait pour gérer les centaines
de flux et règles métiers. Pas pour le chargement massif.
Et attention, cette automatisation, ce n’est pas de simp-
les scripts qui déroulent les commandes. La disponibilité et
la cohérence des données dépendent de leur bon fonction-
nement. Cette automatisation est un réel développement:
versioning, tests, monitoring, évolution. Alors qui doit le fai-
re? Très souvent, ce sont les DBA qui font un script vite fait
et qu’ils fournissent à l’équipe BI. Et plus personne ne veut
le maintenir ensuite. Les DBA n’ont pas le temps ni les outils
pour faire du développement. L’équipe BI n’a pas les droits,
environnements de test, ni les connaissances des fonction-
nalités DBA.
Quelle que soit l’équipe à laquelle il est rattaché, il faut
avoir un DBA applicatif pour faire et maintenir ce travail.
Avec toutes les connaissances de DBA et la possibilité de
travailler en mode projet, guidé par le besoin métier.
Bind variables
Puisqu’on en est à oublier les bonnes pratiques du tran-
sactionnel, soyons clairs: pas de bind variables en data-
warehouse. On ne veut pas partager les curseurs. Au con-
traire, on veut que chaque requête s’exécute avec le plan
d’exécution idéal pour les paramètres spécifiques. Un re-
porting couvrant une journée d’activité ne doit pas partager
le même plan que le rapport annuel. Peu importe si on pas-
se quelques dizaines de millisecondes de plus à chercher le
meilleur plan d’exécution : on ne lance pas 1000 requêtes
par seconde comme en transactionnel. Si ces millisecondes
permettent d’avoir en rapport en 5 secondes au lieu de 20
minutes, alors c’est le mode optimal.
Ce qui veut aussi dire qu’il faut fournir un maximum de
statistiques à l’optimiseur : histogrammes, extended sta-
tistics, global statistics, etc. Les plans d’exécution sont be-
aucoup plus complexes dès qu’on fait du reporting, de
l’analytique. Il y a plus de tables, plus de jointures, des
selectivités très différentes. Il faut que les estimations de
l’optimiseur soient correctes sans quoi il partira sur une
plan d’exécution qui peut durer des heures.
Et puisqu’on parle de statistiques: vous devez arrêter le
job de collecte automatique qui va tourner à 22 heures si
vous avez gardé le paramétrage par défaut. A 22 heures,
vous allez tomber sur des tables vides en cours de charge-
ment. Avoir une estimation de cardinalité à zéro ligne est
bien pire que de ne pas avoir de statistiques. Si vous voyez
un plan d’exécution avec cardinalité estimée à 1, alors il y a
probablement ce genre de problème. Les tables vidées et
rechargées, on collecte les statistiques à la fin du charge-
ment, avec dbms_stats. Pour être sûr que le job automa-
tique n’y touche pas, on les verrouille avec lock_table_stats,
puis le gather_table_stats se fait avec force=>true.
3. DOAG/SOUG News – édition numéro 5 pour la Romandie 5
Paramétrage
Et puisqu’on est dans l’optimiseur, le niveau de dynamic
sampling doit être au moins 4 sur une base BI. On veut des
estimations précises et dès qu’une clause where est un peu
complexe, les statistiques statiques ne peuvent faire qu’une
mauvaise approximation. Il n’y a que le dynamic sampling
qui peut déterminer précisément la sélectivité d’un prédicat
complexe. En 12c le choix du niveau de dynamic sampling
peut être adaptif. C’est intéressant pour les quelques re-
quêtes analytiques qu’on fait sur une base OLTP, mais en BI,
on veut des performances dès la première exécution d’une
requête. Et le Adaptive Dynamic Sampling de la 12c est en-
core nouveau et pose parfois quelques problèmes.
Enfin, on sait tous que sur une application transaction-
nelle les performances sont critiques. Mais si vous doutez
de l’importance des temps de réponse en BI, n’oubliez pas
que vos directeurs n’iront jamais faire des saisies de masse
dans votre ERP. Par contre, s’ils doivent attendre une heure
un tableau de bord, ils n’auront pas une bonne image de la
performance de l’IT…
Environnements de développement
Comme pour toute application informatique, on a besoin
d’environnements pour développer et tester avant de mett-
re en production. Mais il y a là encore une différence où les
normes définies doivent être adaptées à la BI.
En BI, inutile d’avoir un environnement de développe-
ment avec un faible volume. On ne développe pas des tran-
sactions. On développe des données. Le modèle, le charge-
ment, le contrôle, et l’interrogation doit être adaptée aux
données. Donc on a besoin d’un environnement de même
volume que la production, et avec les données de produc-
tion, alimenté avec les données de production. C’est là qu’on
met au point une nouvelle version de datawarehouse.
Ensuite, il y a peu d’intérêt d’avoir une copie de la prod.
Si l’équipe BI doit vérifier quelque chose en production,
alors autant accéder directement à la prod. En OLTP on a
peur de se retrouver avec des requêtes qui prennent tou-
tes les ressources. Mais en BI, la base est prévue pour ça,
c’est l’activité normale. Au sujet de la sécurité des données,
je ne vois pas comment l’équipe BI peut travailler sur une
base sur laquelle on aura fait du data masking. Tout le tra-
vail dépend des données. Et de toute façon, on ne devrait
pas trouver des données sensibles détaillées dans une base
BI. On stocke des dimensions et des mesures, pas des nu-
méros de carte de crédit.
Modélisation
Le modèle physique de données est complètement diffé-
rent de celui d’une application OLTP. Une base OLTP est op-
timisée pour les transactions: normalisation, jointures, ac-
cès par index, optimisation du buffer cache.
Une base BI est optimisée pour la consultation. On ne
va pas refaire les jointures à chaque interrogation. On la
fait une seule fois lors du chargement et on essaie de sto-
cker tous les faits dans une table. C’est l’idée du modèle di-
mensionnel, souvent appelé ‘étoile’ car on a table de faits
qui référence un certain nombre de dimensions. La table de
fait ayant beaucoup de lignes, on essaie d’optimiser la taille
des lignes: normalisation, compression, etc. Les tables de
dimensions sont souvent plus petites et peuvent donc avoir
beaucoup de colonnes : dénormalisation, redondance, etc.
La particularité, c’est qu’on ne fait plus de mises à jour
une fois que c’est chargé. On peut alors utiliser des struc-
tures qu’on évite à tout prix en OLTP mais qui ont tout leur
sens ici: les bitmap index. C’est une approche colonne. Com-
me les requêtes vont plutôt s’intéresser à beaucoup de lig-
nes filtrées sur quelques colonnes, alors on indexe chaque
colonne. Et l’avantage du bitmap index, c’est qu’on peut les
combiner ensuite pour n’aller voir que les lignes qui nous
intéressent dans la table de fait.
C’est aussi la raison pour laquelle en terme de paramétra-
ge, on va définir STAR_TRANSFORMATION_ENABLED=TRUE
car cette transformation va permettre justement d’utiliser
de manière optimale ces index, en faisant un range scan sur
chaque colonne.
Parce qu’elles ne font que grossir, et qu’elles contiennent
un historique, les tables de fait sont partitionnées par range
sur la date la plus significative (le requêtes font en sorte de
filtrer sur cette date). Si vous n’avez pas l’option partition-
nement, il est possible de faire des tables différentes et les
requêtes se feront sur une vue ‘union all’.
Requêtes
Les requêtes qu’on voir passer sur une base BI sont mons-
trueuses, et ne sont clairement pas optimales. Ce n’est pas
une raison pour évoquer une incompétence des dévelop-
peurs: ce ne sont pas eux qui font les requêtes.
Les requêtes sont générées par des outils, à partir de ce
que choisit l’utilisateur. On n’y peut rien. On ne peut pas de-
mander à une personne de l’IT de faire une requête à la de-
mande à chaque besoin de sortir un rapport. La seule mar-
ge de manœuvre, c’est le modèle de données. Le challenge,
c’est d’offrir un modèle de données qui permet de faire tou-
tes les requêtes possibles, en garantissant que toutes ces
requêtes qu’on ne connaît pas d’avance seront performan-
tes et donneront un résultat pertinent.
Je ne dis pas ça pour accepter n’importe quoi sur vos ser-
veurs. Mais il est clair que certaines requêtes liront beau-
coup plus de lignes que nécessaires. Et lorsque c’est le cas,
l’optimisation ne consiste pas à ré-écrire une requêtes, mais à
repenser complètement le design des quelques tables utilisées.
Et donc, comme on ne contrôle pas ces requêtes, le DBA
doit mettre en place de quoi contrôler l’utilisation des res-
sources : resource manager, instance caging, statement
queuing, etc.
Parallel query
Si vous êtes en Enterprise Edition, vous avez la possibilité de
faire du parallel query. Et vous devez le faire pour du data-
4. 6 www.soug.ch
warehouse. Combien avez-vous de CPU? Vous payez des li-
cences Oracle pour tous les cores. Alors utilisez les tous. Le
chargement quotidien doit utiliser toutes les ressources de
la machine puisqu’il n’y a rien d’autre qui tourne en même
temps. N’oubliez-pas que pour faire des inserts en paral-
lèle, il faut l’activer au niveau de la session (ALTER SESSI-
ON ENABLE PARALLEL DML). Et si vous avez plus de cores
que d’utilisateurs qui lancent des requêtes en même temps,
alors pourquoi ne pas tout utiliser? En 12c le Auto DOP fon-
ctionne mieux qu’en 11g. Il est difficile de prévoir combien
de requêtes vont tourner en même temps, alors c’est bien
de laisser l’instance décider du degré de parallélisme.
Enterprise Edition, Exadata, In-Memory
Si vous regardez les nouvelles fonctionnalités qui sont ar-
rivées depuis Oracle 7 vous verrez que la plupart concernent
le datawarehouse. Oracle 7 était déjà presque parfait pour
le transactionnel. C’est l’arrivée des datawarehouse, de
l’analytique sur des gros volumes (Big Data), qui ont motivé
la plupart des évolutions. Avant il n’y avait que Teradata,
avec ses serveurs massivement parallèles, qui pouvait trai-
ter des volumes impressionnants. Sur Oracle sont venu le
partitionnement, les transportable tablespaces, pour pou-
voir continuer à administrer ces volumes qui augmentent.
Regardez toutes les nouveautés de l’optimiseur depuis le
CBO: c’est pour ces requêtes analytiques générées. Les re-
quêtes qu’on écrit pour l’OLTP n’ont pas besoin d’un opti-
miseur intelligent et adaptif. Parlez-en aux éditeurs d’ERP
qui regrettent le RBO et essaie de faire la même chose en
recommandant des valeurs extrêmes pour OPTIMIZER_IN-
DEX_COST_ADJ.
Exadata, même si aujourd’hui on peut le considérer com-
me une solution pour consolider toutes les bases de don-
nées, n’avait qu’un but au départ: enlever le bottleneck de la
bande passante i/o des full table scans des datawarehouse.
SmartScan applique la where clause de ces full scans en
amont de la CPU du serveur de base de données.
L’option In-Memory aujourd’hui est faite pour les bases
OLTP (pas besoin d’index bitmap ni de modèle en étoile
pour les requêtes analytiques) pour faire du reporting des-
sus. C’est pour faire de la BI sans avoir une base BI.
On ne peut donc pas ignorer les besoins spécifiques de
la BI car c’est ça qui évolue le plus aujourd’hui.
Réplication
Le besoin qui se fait de plus en plus sentir aujourd’hui, c’est
le besoin de reporting temps-réel. Fini la base à J-1, on a
besoin d’analyser et de prendre des décisions sur les don-
nées actuelles. Il faut alors trouver une alternative au char-
gement quotidien. C’est la réplication.
Il y a deux types de réplication : physique et logique.
La réplication physique temps réel, c’est possible avec
une standby en real-time apply : la standby continue à ap-
pliquer le redo reçu de la primaire, mais elle est ouverte en
read-only pour le reporting. Il faut être en Enterprise Edition
avec l’option Active Data Guard pour ça. Le seul inconvéni-
ent de la réplication physique, c’est qu’on a une base iden-
tique à la primaire. On ne peut pas garder plus d’historique,
on ne peut pas partitionner ou indexer différemment.
Ce n’est pas encore possible en 12.1 mais on l’attend
pour la 12.2 : la possibilité d’activer In-Memory sur une
standby en Active Data Guard. Financièrement, c’est un cu-
mul d’options, mais la fonctionnalité n’a pas d’équivalent :
avec In-Memory, plus besoin de rajouter des index dédiés
au reporting. On a une base complètement isolée de la pro-
duction, avec les mêmes données, et disponible pour not-
re BI. Comme on ne doit plus développer et maintenir une
base BI, les économies réalisées peuvent justifier l’achat de
l’option.
L’autre solution, c’est la réplication logique. Oracle Gol-
den Gate ou Dbvisit replicate. Dbvisit replicate est une so-
lution simple à mettre en œuvre, et permet de travailler en
mode incrémental (mode audit) utile lorsqu’on doit ensu-
ite envoyer les données dans un modèle de données très
différent (normalisé, compressé, etc). Oracle Golden Gate a
l’avantage d’inclure Active Data Gard, donc on peut avoir à
la fois une réplication physique et logique, pour couvrir les
deux besoins différents.
Conclusion
L’idée de cet article est très ancienne, et me vient à l’esprit
chaque fois que je fais l’intermédiaire entre les équipes BI
et l’équipe DBA. Les besoins BI ont évolués très vite ces der-
nières années et nous devons faire évoluer l’administration
de ces bases. Le risque si on ne le fait pas, alors la BI devra
se tourner vers d’autres technologies, qui sont très promet-
teuses (Hadoop) mais n’ont pas encore la maturité de nos
bases relationnelles.
Franck Pachot
franck.pachot@dbi-services.com
Franck Pachot est consultant, formateur, et technology
leader Oracle à dbi services, Oracle ACE et OCM 11g.