Telmai monitors any source in data pipelines, but how do we do it?
Abstract
Telmai is designed to monitor data at any pipeline step, be it a source or a destination. And it does it at scale and with low latency. Our system is built upon architectural blocks which significantly differ from a typical homegrown system designed to monitor SQL databases/engines. Telmai, on the other hand, uses distributed compute via Spark and is highly optimized for monitoring data at a large scale.
This blog highlights some architectural decisions that helped us achieve scale, versatility, and efficiency.
Data monitoring requirements
Over the last decades, companies have embraced many new technologies in the data ecosystem for two reasons: to uncover newer use cases (revenue) or lower cost.
The former heavily depends on the reliability of the data, and the latter is always a consideration for everyone evaluating the tools that support the use case.
So when we were designing Telmai, the critical consideration was to build a system that is a step ahead in speed, scale, and costs required for these new data use cases. In this blog, we’d like to share some of the architectural decisions we went with.
Our requirements for building a robust monitoring system came down to:
- Shifting data monitoring to the left, in other words finding issues closest to their source in order to reduce MTTD and MTTR (mean time to detect and resolve)
- Scale and workload isolation to be able to support vastly increased number and size of data sources to be analyzed
- Performance - finding problems timely to fit in the strict time windows for remediation activities
- Deployment flexibility to ensure versatility of data sources and the fact data is not suppose to leave the clients security perimeter
- Cost efficiency to avoid incurring high infrastructure costs for monitoring, be it ingress/egress or compute.
So with all these considerations we outlined two options: building Telmai by connecting directly to a Data warehouse/SQL engine and running SQL queries to calculate the metrics, or using an external processing engine, like Spark, to perform all the calculations to generate the metrics.
There were pros and cons to both. While the SQL one works well for monitoring Data warehouse or BI tools, for our requirements the Spark option felt more compelling and below you can learn why so.
Shifting data monitoring to the left
This means quickly plugging into any source that can contribute to data issues. In other words, read anything - various file formats (parquet, CSV, JSON, archives, etc.), multiple databases like HBase, Cassandra, SSTables, subscription topics, ex. Kafka or even Spark dataframes while data is still being processed with Spark-based ETL.
When data comes from such a diverse group of sources, it's a problem by itself to first extract and then load data into a system. The data warehouse was restrictive as it often fails the load jobs during schema validation. It requires additional efforts and transformation jobs to run before loading the data, introduces additional delays and failure points, and defeats the purpose of monitoring as early (i.e., leftmost) as possible. So if we wanted our clients to shift their monitoring to the left, we had to choose an architecture that would support this easily.
Scale
When monitoring is shifted to the left, it means more sources to be analyzed and much more data in general. This data is often raw that hasn't had any cleanup/aggregations. Doing this without creating a bottleneck in the pipeline was a critical consideration for us. Spark offers a great help here, as it allows the launch of many auto-scaling clusters to work in parallel, ensuring the system's excellent overall throughput. Such flexibility was hard to achieve even with managed data warehouses.
Pipeline performance
Calculating metrics is compute-intensive. And monitoring requires a lot of them. Each attribute requires running numerous aggregations to understand various value distributions, completeness, mean frequency, values ranges, standard deviations, etc. This gets even more complicated when multivalued attributes are present, and the size gets to a terabyte and petabyte scale.
Having hundreds of attributes and calculating dozens of metrics for every attribute will require thousands of queries(or jobs). Each analytical SQL engine has a significant overhead for every query due to planning, which can quickly get out of hand in real-life situations.
By having a deeper control over the execution flow with Spark, we can utilize a highly-optimized logic for very wide (a large number of attributes and metrics) datasets and avoid bottlenecks with the general-purpose SQL approach. Transforming data into a very long skinny (key-value) representation allows us to run with a constant number of analytics jobs and not be affected by many metrics, which comes very handy with an exploding number of custom metrics and attributes to monitor.
Deployment flexibility
We knew our clients needed deployment flexibility for data security.
The use of Spark as a processing engine allowed for decoupling data extraction and processing, bringing both closer to the monitored data. That means running processing anywhere in the network topology, for example, via EMR clusters in the same or peered VPC to where monitored HBase or Cassandra clusters are. It eliminates unnecessary security vulnerabilities and challenging questions from infosec teams.
In short, Spark helps us to enable SaaS via public or private cloud options and extend coverage for on-prem Spark/Hadoop setups.
Cost considerations and budgeting
Being a decoupled processing infrastructure, Spark was our choice to help us cleanly separate workloads, avoid unnecessary load on DL and DW engines, and quickly control and isolate monitoring costs from other business-driven initiatives.
Summary
To securely monitor any step in the data pipeline at scale without compromising product features, we needed to future-proof our architecture. We relied heavily on distributed compute architecture via Spark to achieve our architectural goal.
Data profiling helps organizations understand their data, identify issues and discrepancies, and improve data quality. It is an essential part of any data-related project and without it data quality could impact critical business decisions, customer trust, sales and financial opportunities.
To get started, there are four main steps in building a complete and ongoing data profiling process:
We'll explore each of these steps in detail and discuss how they contribute to the overall goal of ensuring accurate and reliable data. Before we get started, let's remind ourself of what is data profiling.
1. Data Collection
Start with data collection. Gather data from various sources and extract it into a single location for analysis. If you have multiple sources, choose a centralized data profiling tool (see our recommendation in the conclusion) that can easily connect and analyze all your data without having you do any prep work.
2. Discovery & Analysis
Now that you have collected your data for analysis, it's time to investigate it. Depending on your use case, you may need structure discovery, content discovery, relationship discovery, or all three. If data content or structure discovery is important for your use case, make sure that you collect and profile your data in its entirety and do not use samples as it will skew your results.
Use visualizations to make your discovery and analysis more understandable. It is much easier to see outliers and anomalies in your data using graphs than in a table format.
3. Documenting the Findings
Create a report or documentation outlining the results of the data profiling process, including any issues or discrepancies found.
Use this step to establish data quality rules that you may not have been aware of. For example, a United States ZIP code of 94061 could have accidentally been typed in as 94 061 with a space in the middle. Documenting this issue could help you establish new rules for the next time you profile the data.
4. Data Quality Monitoring
Now that you know what you have, the next step is to make sure you correct these issues. This may be something that you can correct or something that you need to flag for upstream data owners to fix.
After your data profiling is done and the system goes live, your data quality assurance work is not done – in fact, it's just getting started.
Data constantly changes. If unchecked, data quality defects will continue to occur, both as a result of system and user behavior changes.
Build a platform that can measure and monitor data quality on an ongoing basis.
Take Advantage of Data Observability Tools
Automated tools can help you save time and resources and ensure accuracy in the process.
Unfortunately, traditional data profiling tools offered by legacy ETL and database vendors are complex and require data engineering and technical skills. They also only handle data that is structured and ready for analysis. Semi-structured data sets, nested data formats, blob storage types, or streaming data do not have a place in those solutions.
Today organizations that deal with complex data types or large amounts of data are looking for a newer, more scalable solution.
That’s where a data observability tool like Telmai comes in. Telmai is built to handle the complexity that data profiling projects are faced with today. Some advantages include centralized profiling for all data types, a low-code no-code interface, ML insights, easy integration, and scale and performance.
Data Observability
Data Quality
Leverages ML and statistical analysis to learn from the data and identify potential issues, and can also validate data against predefined rules
Uses predefined metrics from a known set of policies to understand the health of the data
Detects, investigates the root cause of issues, and helps remediate
Detects and helps remediate.
Examples: continuous monitoring, alerting on anomalies or drifts, and operationalizing the findings into data flows
Examples: data validation, data cleansing, data standardization
Low-code / no-code to accelerate time to value and lower cost
Ongoing maintenance, tweaking, and testing data quality rules adds to its costs
Enables both business and technical teams to participate in data quality and monitoring initiatives
Designed mainly for technical teams who can implement ETL workflows or open source data validation software
Start your data observibility today
Connect your data and start generating a baseline in less than 10 minutes.
No sales call needed
Start your data observability today
Connect your data and start generating a baseline in less than 10 minutes.
