Updated: Feb 25
The data management landscape has dramatically changed over the last decade with the evolution and massive adoption of BigData, ML/AI, ever-increasing number of data sources, and volumes. Ensuring high quality and completeness of data is critical for driving valuable business decisions for enterprises. Yet statistics show that 87% of machine learning projects don’t make it into production and data engineers spend 80% of their time cleaning the data.
Around 5-8 years ago, enterprises had started seeing similar patterns around cloud infrastructure. Organizations were investing heavily in cloud architecture with low returns on their investments. There was a lack of monitoring and minimal predictability about the anomalies and service failures. This need gave birth to the evolution of Cloud Infrastructure Observability.
Running SaaS operations at an ever-growing scale and the need for efficiency and reliability put the focus on observability products, and today, there are several major players in this space like Splunk, DataDog, NewRelic, Dynatrace. I have noticed various interpretations of what Observability is, but recently it has converged into three key concept pillars. In the world of Cloud Infrastructure Observability, these pillars are metrics, traces, and logs and they try to answer the following questions:
Initially, the first pillar was addressed by metrics monitoring tools, the second one by tracing, and the third one by logs. The observability area is very dynamic and experiencing explosive growth, so we see many new tools emerging and addressing the needs of each pillar.
However, data problems are hidden from these tools and even when all the metrics, traces, and logs look normal for a data pipeline, it still can produce garbage data. It is a significant problem for the businesses, which leads not only to constant escalation mode and burnout of data engineers who are troubleshooting discrepancies in the reports but also hurts business big time.
Hence a similar concept of observability has now emerged in data management for data quality use cases. More and more companies realize they need to focus on addressing the data issues or what is sometimes referred to as “data downtime.” It is not surprising to see the growing interest in Data Observability.
Just like Cloud Observability, Data Observability Suites are trying to get answers to the same three questions. However, there is no established consensus on the naming. Let me offer my take on the Data Observability pillars:
Given the complexity of the domain, I anticipate a wide range of tools being introduced for each pillar, far greater than what we saw for Cloud Observability.
So what is Data Observability in the end? In short, it is a new discipline, which is trying to fill the gaps where traditional data management systems like data quality, data profiling, lineage are falling short to help data engineers achieve operational excellence and deliver business results.
#dataquality #dataobservability #dataops
Cloud migration and integration projects rely on good quality data to meet their objectives. However, traditional technologies have...
Maxim Lukichev, Telmai CTO shares his experience on architecting data systems, in session with DataTalksClub Data architectures for...