Snowflake veut lui aussi faire de PostgreSQL un lakehouse ouvert

Combiner les capacités de Postgres, de DuckDB et d’Iceberg

Les extensions pg_lake s’intègrent à PostgreSQL pour gérer « la planification des requêtes, les périmètres des transactions et l’orchestration générale des exécutions ».

Sous le capot, un serveur DuckDB (nommé pgduck_server) est utilisé pour externaliser les scans et les traitements parallèles. DuckDB est un moteur analytique orienté colonnes (OLAP) open source. Il est réputé pour gérer des requêtes complexes à partir de grandes bases de données.

Le projet s’appuie sur le protocole TCP de PostgreSQL pour interconnecter PostgreSQL et DuckDB.

 « Toute personne disposant de Postgres et souhaitant la transformer en interface pour gérer un lac ouvert avec des tables Iceberg pourra le faire à sa guise », promet Christian Kleinerman, vice-président directeur du produit chez Snowflake, lors d’une conférence de presse en ligne.

C’était une des fonctionnalités au cœur de Crunchy Bridge for Analytics, dont le développement a commencé au début de l’année 2024. Un moyen de simplifier la jonction entre les données opérationnelles et analytiques. Ces fonctionnalités sont ensuite devenues le cœur de l’offre Crunchy Data Warehouse, avant que Snowflake acquière la société.

Pour rappel, ce n’est pas dans la nature de PostgreSQL que de traiter des charges de travail analytiques. C’est, à l’origine, une base de données transactionnelle.

« L’industrie des bases de données est divisée en deux grandes factions : les systèmes OLTP et OLAP. Elles ne se parlent pas trop, mais elles sont d’accord sur la gestion de transactions et l’usage de SQL », résume Marco Slot, ingénieur logiciel principal chez Snowflake (ex-Crunchy Data) lors d’un événement Microsoft Developer. « Les systèmes OLTP comme PostgreSQL prennent en charge de grande quantité de transactions telles des petites mises à jour, des changements ligne à ligne, de petites sélections, etc., à une faible latence et à haut débit », poursuit-il. « Les systèmes OLAP se concentrent sur le scan à haute vitesse d’un grand volume de données en une seule requête. C’est un autre problème d’optimisation ».

Outre la différence d’orientation du format de stockage (en ligne pour les systèmes OLTP, en colonne pour les systèmes OLAP), les systèmes analytiques modernes, dont Databricks, Snowflake et DuckDB s’appuient sur des moteurs d’exécution vectorisée. Ceux-là permettent de traiter des données en lot plutôt que ligne par ligne. « Le moteur de requêtes prend un vecteur de valeurs – un lot de valeurs – et les expressions sont implémentées comme des boucles », explique Marco Slot. « Ils font la même comparaison sur toutes les valeurs du vecteur. Et le résultat peut être un nouveau vecteur avec, par exemple, les index des lignes qui correspondent aux filtres de la requête ».

Au lieu de changer d’expression constamment, ici le traitement en batch abaisse le nombre d’appels de fonctions, le processeur peut mieux prédire la suite de l’exécution, le cache CPU est utilisé à bon escient, tandis que les instructions SIMD des processeurs permettent de traiter plusieurs valeurs en une seule requête.

« En couplant cela à la parallélisation, les bases de données OLAP dotées d’un tel moteur peuvent être 10, voire plus de 100 fois plus rapides que PostgreSQL pour des requêtes analytiques », estime l’ingénieur principal.

Or, il n’est pas simple de bâtir un moteur à exécution vectorisée. De plus, « d’autres composants de Postgres ne sont pas optimisés pour l’analytique », ajoute Marco Slot.

D’où l’usage du « superpouvoir » de PostgreSQL : les extensions. « Il y a quelques années, ce n’était pas une base de données vectorielle, mais maintenant nous avons pg_vector. Ce n’était pas une base de données distribuée, mais le projet Citus a changé la donne », illustre l’ingénieur principal. « De la même manière, nous pouvons faire de Postgres une bonne base de données analytique à travers les extensions ».

En tant que moteur d’exécution vectorisée embarquée, DuckDB était considéré comme le plus adapté à cette tâche. « La licence est similaire, il cible une seule machine, son dialecte SQL est dérivé de PostgreSQL et il a aussi des extensions », justifie Marco Slot.

Rapprocher PostgreSQL des lakehouse, une initiative commune à l’écosystème Data

Christian Kleinerman envisage que les développeurs utilisent cette extension dans le cadre de développement d’applications. « Je pense que l’un des cas d’usage le plus courant consiste pour les développeurs à créer des applications avec Postgres, puis à effectuer un ETL ou à copier les données à des fins d’analyse dans une plateforme de données telle que Snowflake ou, de plus en plus, dans un lac de données ouvert, avec S3 Table sur AWS ou avec Iceberg, sur Microsoft OneLake », indique-t-il, dans un briefing avec la presse. « C’est ce que permet PG Lake. […] Nous avons pensé que c’était plus important que Snowflake et que Snowflake Postgres. D’où la libération du projet ».

Ce n’est pas le premier projet du genre. À travers MotherDuck, l’éditeur DuckDB propose une implémentation différente. Il embarque directement une instance de son moteur dans PostgreSQL. Il faut également noter que Databricks a mis la main au début du mois d’octobre sur Mooncake Labs, une startup basée à San Francisco. Celle-ci a développé pg_mooncake, une extension open source permettant de créer un miroir inversé de tables Postgres dans un format orienté colonne Apache Iceberg. Les données sont ingérées avec sa technologie moonlink et traitées avec… DuckDB.

À la croisée des changements de paradigme

Il y a quelques limitations. La première étant qu’il n’est pas encore possible d’utiliser de catalogue externe à PostgreSQL pour Iceberg dans le cas de pg_lake. Databricks, Cloudera, Dremio, Snowflake et d’autres utilisent désormais des catalogues de métadonnées externes comme Hive, Polaris ou Unity. Cette gestion de la gouvernance des tables Iceberg (et leur contrôle) n’est pas encore standard. 

Néanmoins, les experts du milieu décrivent deux phénomènes qui convergent. Après la naissance des lakehouse – qui combinent les capacités des entrepôts et des lacs de données – la frontière entre la base et le lac de données s’effacerait, selon Manish K., architecte Big Data chez Accenture.

« DuckDB a prouvé que nous pouvons exécuter des analyses sérieuses directement sur des fichiers », écrit Manish K. sur LinkedIn. « pg_lake et pg_mooncake ont prouvé que Postgres peut parler [le langage] des tables de style Iceberg dans un espace de stockage objet. Les services Postgres cloud-first (calcul/stockage découplé, branchable, élastique) ressemble désormais à un lakehouse sur le plan architectural », ajoute-t-il. « Le schéma est donc clair : la base de données se déplace là où se trouve déjà le lac ». Et d’utiliser l’expression « lakebase ».

Bhairav Metha, directeur data science chez JPMorganChase, voit un autre changement. Alors que les systèmes translytiques sont jusqu’à présent majoritairement propriétaires, ils pourraient demain s’appuyer sur un projet open source : PostgreSQL.

« Nous n’y sommes peut-être pas encore tout à fait – l’OLAP et l’OLTP répondent encore à des objectifs d’optimisation distincts – mais la trajectoire est claire », avance-t-il. « Postgres pourrait bientôt gérer 90 % des charges de travail modernes sans avoir besoin d’un entrepôt ou d’un Lakehouse séparé ».