From OLTP & OLAP to HTAP and LTAP: The Evolution Toward a Lakehouse-Native Data Architecture

 I am still second-reading Designing Data-Intensive Applications, and recently came across HTAP. It immediately made me think about hashtag

#Databricks announcement of hashtag
#LTAP and how it fits into the evolution from databases to the Lakehouse.

The story starts with two very different workloads:
- OLTP, Online Transaction Processing, runs operational applications.
Handling workloads require low latency, high concurrency and reliable transactions (recording payments...).

- OLAP, Online Analytical Processing, helps organizations understand what is happening across large volumes of data (reporting, ML...).

Traditionally, these workloads were separated.
Operational data lived in transactional databases and was later "copied" into analytical systems.

🔴 hashtag
#HTAP, Hybrid Transactional/Analytical Processing, then emerged to bring these two worlds closer together.
HTAP is not one specific implementation. The common objective is to support transactional and analytical processing within a unified system while making fresher operational data available for analysis.

In parallel, another architectural evolution was taking place.
The hashtag
#Lakehouse brought data warehouse capabilities to open data stored in the lake. As a common foundation for data engineering, ML , AI.

However, operational applications still typically depended on a separate transactional database.
Data therefore continued to move between the operational database and the Lakehouse.

💡This context helped me understand Databricks hashtag
#LTAP, Lake Transactional/Analytical Processing.
Databricks describes LTAP as a Lakehouse-native architecture in which transactional and analytical workloads are "unified" around the lake storage layer.
A Postgres-compatible engine remains specialized for low-latency transactional workloads, while Lakehouse engines remain specialized for analytics, ML and AI.

💡The important distinction is not simply that HTAP uses one engine while LTAP uses multiple engines. Some HTAP architectures use specialized engines and shared storage.

❗The more meaningful distinction is where the common data foundation resides!
HTAP represents the broader architectural goal of combining transactional and analytical processing within a unified system.
LTAP approaches that goal through the Lakehouse, with open lake storage as the common foundation and independently scalable engines optimized for each workload.
This is what makes the architecture particularly interesting to me!
💡The progression I now see is:
OLTP: process the business.
OLAP: analyze the business.
HTAP: bring transactional and analytical processing into a unified system.
Lakehouse: establish an open, governed foundation for analytical data, ML and AI.
LTAP: extend the Lakehouse foundation to support both operational and analytical processing through specialized engines.

#EPAM #databricks #LTAP Srinivasa Rao Kattuboina Satish Gunisetty Manjunatha K Senthilkumar Kandasamy Gobinath Velusamy Vikas Kumar

https://www.linkedin.com/feed/update/urn:li:activity:7488779307339874304/