Dans le contexte des bases de données et des systèmes de stockage, une transaction est une opération traitée comme une seule unité de travail, qui aboutit entièrement ou pas du tout, et laisse le système de stockage dans un état cohérent. Pour prendre un exemple classique, lorsque vous retirez de l'argent de votre compte bancaire, il s'agit d'une transaction. Soit l'argent a été débité de votre compte bancaire, soit il y est encore. Il n'y a pas d'état intermédiaire.

L'acronyme ACID désigne les quatre propriétés clés qui définissent une transaction : atomicité, cohérence, isolement et durabilité. Si une opération de base de données présente ces propriétés ACID, elle peut être qualifiée de transaction ACID. Les systèmes de stockage de données qui appliquent ce type d'opérations sont appelés « systèmes transactionnels ». Avec les transactions ACID, chaque lecture, écriture ou modification d'une table présente les caractéristiques suivantes :
Les transactions ACID garantissent un degré maximal de fiabilité et d'intégrité des données. Grâce à cela, vos données ne risquent jamais de se trouver dans un état incohérent parce qu'une opération n'a pas entièrement abouti. Par exemple, sans les transactions ACID, si vous écrivez des données dans une table et qu'une coupure de courant se produit, il se peut qu'une partie seulement de vos données soit enregistrée. Votre base de données se retrouve alors dans un état incohérent qu'il sera très difficile – et très long – à rectifier.

Les transactions ACID sont depuis longtemps l'un des atouts les plus enviés des data warehouses. Mais avec Delta Lake, elles sont désormais à la portée des data lakes. Elles permettent aux utilisateurs d'obtenir des vues cohérentes même quand de nouvelles données sont inscrites dans la table en temps réel. En effet, chaque écriture correspond à une transaction isolée et consignée dans un journal de transactions ordonné. [Delta Lake applique le plus haut niveau d'isolement possible (isolement sérialisable) pour que les lectures et les écritures portant sur une même table soient cohérentes et fiables.] En implémentant les transactions ACID, Delta Lake apporte une réponse concrète à plusieurs critiques émises à l'encontre de l'architecture Lambda : sa complexité, les vues incorrectes des données, le travail et le traitement nécessaires après les inévitables défaillances des pipelines Lambda. Les utilisateurs sont libres d'effectuer plusieurs transactions simultanées sur leurs données. En cas d'erreur au niveau d'une source de données ou d'un flux, Delta Lake annule l'exécution de la transaction pour préserver l'intégrité des données. La beauté des transactions ACID réside dans le fait que les utilisateurs peuvent faire confiance aux données stockées dans Delta Lake. Un data analyst qui utilise des tables Delta Lake pour effectuer des opérations ETL sur ses données et créer des dashboards peut compter sur la fiabilité les KPI qu'il observe : ils représentent bien l'état réel des données. Un ingénieur en machine learning qui réalise des tâches d'ingénierie de fonctionnalités à l'aide de tables Delta Lake peut être 100 % certain que les transformations et les agrégations sont réalisées exactement comme prévu ou pas du tout, auquel cas il en sera informé. Savoir que le modèle mental que vous avez de vos données est le reflet exact de leur véritable état sous-jacent représente un atout inestimable.
