Le data lineage et l’usage des données pour transformer un système : simplifications / migrations

  The strengths and limitations of Data Mesh architectures est ? Data Mesh, what is it? Treat data as a product Data Mesh refers to a massive data processing system with a decentralized architecture. This architecture is on the rise, especially in large companies operating in highly competitive fields The architecture is subdivided into “domains” managed by a responsible team enjoying true independence. These data domains are made interoperable with APIs. The idea is to have segmented data, ready to use! It's a bit of an update of "datamarts", but in self-service, and whose management is distributed. Data ownership is thus federated to generate value to enable faster value creation and learning cycles. “Federation” of ownership often makes sense because the business value can be better defined, prioritized and iterated by the Business Unit (=domain) with the required requirement. What is the nuance between a Data Lake vs a Data Warehouse vs the Data Mesh? The Data Lake: a

  Les forces et les l imites des architectures Data Mesh. est ? Le Data Mesh, qu’est-ce que c’est ? Traiter les données comme un produit  Le Data Mesh fait référence à un système de traitement de données massive avec une architecture décentralisée. Cette architecture a le vent en poupe, en particulier dans les entreprises importantes opérant dans des domaines fortement concurrentiels. L’architecture est subdivisée en « domaines » gérés par une équipe en responsabilité jouissant d’une véritable indépendance . Ces domaines de donnée sont rendus interopérables avec des APIs. L’idée est d’avoir des données segmentée, prêtes à emploi ! C’est un peu une actualisation des "datamarts", mais en self-service, et dont la gestion est distribuée. La propriété des données est ainsi fédérée pour générer de la valeur afin de permettre des cycles de création de valeur et d'apprentissage plus rapides. La « fédération » de la propriété est souvent logique car la valeur métier peut être mi

  SQL and its many dialects                                                                  There are many database systems that rely on SQL. To name only the well-known ones: PostgreSQL, MySQL, MS SQL Server, Oracle, SQLite - And Cloud-specific: BigQuery, Redshift, Azure SQL, etc. And therefore, there are many variations of SQL, which we will call “dialects” 😊. The SQL language (and its dialects) is constantly evolving. This adaptability, this plasticity, and this simplicity are important elements of the success of SQL. This also explains its longevity (“since 1974”).   SQL, a language for everyone!                                                                     Usually, programming languages are supposed to be used for programming purposes only, but SQL is proof to the contrary: it can be used by members of the marketing or sales team via a few queries to do analysis. SQL is also useful for the financial sector, as it is essential for navigating often countless data. As a resul

Le SQL et ses nombreux dialectes                                                                    Il existe de nombreux système de bases de données qui reposent sur le SQL.  Pour ne citer que les connus : PostgreSQL, MySQL, MS SQL Server, Oracle, SQLite - Et spécifiques Cloud :  BigQuery, Redshift, Azure SQL, etc. Et par conséquent, il existe de nombreuses déclinaisons du SQL, que nous appellerons « dialectes »  😊 . Le langage SQL (et ses dialectes) ne cesse d'évoluer. Cette adaptabilité, cette plasticité, et cette simplicité sont des éléments importants du succès du SQL. Ça explique aussi sa longévité (« since 1974 »).   Le SQL, un langage pour tous !                                                                         Habituellement, les langages de programmation sont supposés être utilisés à des fins de …programmation uniquement, mais le SQL est la preuve du contraire : il peut être utilisé par les membres de l'équipe marketing ou commerciale via quelques req

Executive summary Dans la plupart des entreprises, les données empruntent des routes tortueuses depuis les systèmes sources jusqu’à leur usage finaux. La faute à une multiplication des technologies, à une inflation incontrôlable des volumétries. Les équipes data s’échinent à extraire, ingérer, déplacer, nettoyer, intégrer, agréger les données pour pouvoir adresser les use cases du business. Mécaniquement, se créent des « pipelines de données » qui deviennent vite inefficaces et sujets aux erreurs : les données sont traitées par différentes technologies, sautent de système en système, elles sont répliquées à l’infini, ou encore oubliées dans un coin. Les réutilisations de données, et la factorisation des process sont l’exception. Aussi, le business attend des temps infinis ses réponses, pourtant urgentes. La dataOps promet de rationaliser le processus de création, de modification et de gestion des pipelines de données, au service d’une véritable data governance. Son objec