By Barr Môi-se, CEO and Co-founder of Monte Carlo & Ryan Kearns, Machine Learning Engineer at Monte Carlo

Trong loạt bài viết này, chúng tôi hướng dẫn cách bạn có thể tạo trình giám sát khả năng quan sát dữ liệu của riêng mình từ đầu, ánh xạ tới năm trụ cột chính của sức khỏe dữ liệu. Part I can be found tại đây.

Part II of this series was adapted from Barr Moses and Ryan Kearns’ O’Reilly training, Quản lý thời gian ngừng hoạt động của dữ liệu: Áp dụng khả năng quan sát cho đường ống dữ liệu của bạn, khóa học đầu tiên trong ngành về khả năng quan sát dữ liệu. Có sẵn các bài tập liên quan tại đâyvà mã thích ứng được hiển thị trong bài viết này có sẵn tại đây.

As the world’s appetite for data increases, robust data pipelines are all the more imperative. When data breaks — whether from schema changes, null values, duplication, or otherwise — data engineers need to know.

Most importantly, we need to assess the root cause of the breakage — and fast — before it affects downstream systems and consumers. We use “thời gian ngừng hoạt động dữ liệu” to refer to periods of time when data is missing, erroneous, or otherwise inaccurate. If you’re a data professional, you may be familiar with asking the following questions:

• Dữ liệu có được cập nhật không?
• Dữ liệu có đầy đủ không?
• Các trường có nằm trong phạm vi dự kiến ​​không?
• Tỷ lệ null cao hơn hay thấp hơn mức cần thiết?
• Lược đồ có thay đổi không?

To answer these questions in an effective way, we can take a page from the software engineer’s playbook: giám sát và quan sát.

To refresh your memory since Part I, we define khả năng quan sát dữ liệu như khả năng của tổ chức trong việc trả lời những câu hỏi này và đánh giá tình trạng hệ sinh thái dữ liệu của họ. Phản ánh các biến số chính về tình trạng dữ liệu, năm trụ cột của khả năng quan sát dữ liệu là:

• Tươi mát: dữ liệu của tôi có được cập nhật không? Có khoảng trống về thời gian mà dữ liệu của tôi chưa được cập nhật không?
• phân phát: dữ liệu của tôi ở cấp trường tốt đến mức nào? Dữ liệu của tôi có nằm trong phạm vi mong đợi không?
• Khối lượng: lượng dữ liệu của tôi có đáp ứng được ngưỡng mong đợi không?
• Schema: cấu trúc chính thức của hệ thống quản lý dữ liệu của tôi có thay đổi không?
• Lineage: nếu một số dữ liệu của tôi bị hỏng thì điều gì sẽ bị ảnh hưởng ở thượng nguồn và hạ nguồn? Các nguồn dữ liệu của tôi phụ thuộc vào nhau như thế nào?

In this article series, we’re interested in pulling back the curtain, and investigating what data observability looks like — trong mã.

In Phần I, we looked at the first two pillars, freshness and distribution, and showed how a little SQL code can operationalize these concepts. These are what we would call more “classic” anomaly detection problems — given a steady stream of data, does anything look out of whack? Good anomaly detection is certainly part of the data observability puzzle, but it’s not everything.

Equally important is bối cảnh. If an anomaly occurred, great. But where? What upstream pipelines may be the cause? What downstream dashboards will be affected? And has the formal structure of my data changed? Good data observability hinges on our ability to properly leverage metadata to answer these questions — and many others — so we can identify the root cause and fix the issue before it becomes a bigger problem.

In this article, we’ll look at the two data observability pillars designed to give us this critical context — kế hoạch và dòng. Once again, we’ll use lightweight tools like Jupyter and SQLite, so you can easily spin up our environment and try these exercises out yourself. Let’s get started.

Our Data Environment

 
Hướng dẫn này dựa trên Bài tập 2 và 3 của khóa học O'Reilly của chúng tôi, Quản lý thời gian ngừng hoạt động của dữ liệu. You’re welcome to try out these exercises on your own using a Jupyter Notebook and SQL. We’ll be going into more detail, including exercise 4, trong các bài viết trong tương lai.

Nếu bạn đọc Phần I of this series, you should be familiar with our data. As before, we’ll work with dữ liệu thiên văn giả about habitable exoplanets. We generated the dataset with Python, modeling data and anomalies off of real incidents I’ve come across in production environments. This dataset is entirely free to use, and the thư mục tiện ích trong kho chứa mã đã tạo dữ liệu, nếu bạn quan tâm.

I’m using SQLite 3.32.3, which should make the database accessible from either the command prompt or SQL files with minimal setup. The concepts extend to really any query language, and những triển khai này có thể được mở rộng sang MySQL, Snowflake và các môi trường cơ sở dữ liệu khác với những thay đổi tối thiểu.

Once again, we have our EXOPLANETS table:

$ sqlite3 EXOPLANETS.db
sqlite> PRAGMA TABLE_INFO(EXOPLANETS);
0 | _id | TEXT | 0 | | 0
1 | distance | REAL | 0 | | 0
2 | g | REAL | 0 | | 0
3 | orbital_period | REAL | 0 | | 0
4 | avg_temp | REAL | 0 | | 0
5 | date_added | TEXT | 0 | | 0

A database entry in EXOPLANETS contains the following information:

0. _id: Một UUID tương ứng với hành tinh.
1. distance: Khoảng cách tới Trái đất, tính bằng năm ánh sáng.
2. g: Surface gravity as a multiple of g, the gravitational force constant.
3. orbital_period: Độ dài của một chu kỳ quỹ đạo tính bằng ngày.
4. avg_temp: Nhiệt độ bề mặt trung bình tính bằng độ Kelvin.
5. date_added: Ngày hệ thống của chúng tôi phát hiện ra hành tinh này và tự động thêm nó vào cơ sở dữ liệu của chúng tôi.

Lưu ý rằng một hoặc nhiều distance, g, orbital_periodvà avg_temp có lẽ NULL cho một hành tinh nhất định do dữ liệu bị thiếu hoặc sai.

sqlite> SELECT * FROM EXOPLANETS LIMIT 5;

Lưu ý rằng bài tập này có hiệu lực hồi tố - chúng tôi đang xem xét dữ liệu lịch sử. Trong môi trường dữ liệu sản xuất, khả năng quan sát dữ liệu là thời gian thực và được áp dụng ở từng giai đoạn của vòng đời dữ liệu, do đó sẽ liên quan đến cách triển khai hơi khác so với những gì được thực hiện ở đây.

It looks like our oldest data is dated 2020–01–01 (ghi: most databases will not store timestamps for individual records, so our DATE_ADDED column is keeping track for us). Our newest data…

sqlite> SELECT DATE_ADDED FROM EXOPLANETS ORDER BY DATE_ADDED DESC LIMIT 1;
2020–07–18

… looks to be from 2020–07–18. Of course, this is the same table we used in the past article. If we want to explore the more context-laden pillars of schema and lineage, we’ll need to expand our environment.

Hiện nay, ngoài EXOPLANETS, we have a table called EXOPLANETS_EXTENDED, which is a superset of our past table. It’s useful to think of these as the same table at different moments in time. Thực tê la, EXOPLANETS_EXTENDED has data dating back to 2020–01–01…

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED ASC LIMIT 1;
2020–01–01

… but also contains data up to 2020–09–06, further than EXOPLANETS:

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED DESC LIMIT 1;
2020–09–06

Visualizing schema changes

 
Something else is different between these tables:

sqlite> PRAGMA TABLE_INFO(EXOPLANETS_EXTENDED);
0 | _ID | VARCHAR(16777216) | 1 | | 0
1 | DISTANCE | FLOAT | 0 | | 0
2 | G | FLOAT | 0 | | 0
3 | ORBITAL_PERIOD | FLOAT | 0 | | 0
4 | AVG_TEMP | FLOAT | 0 | | 0
5 | DATE_ADDED | TIMESTAMP_NTZ(6) | 1 | | 0
6 | ECCENTRICITY | FLOAT | 0 | | 0
7 | ATMOSPHERE | VARCHAR(16777216) | 0 | | 0

In addition to the 6 fields in EXOPLANETS, Các EXOPLANETS_EXTENDED table contains two additional fields:

6. eccentricity: Các orbital eccentricity of the planet about its host star.
7. atmosphere: the dominant chemical makeup of the planet’s atmosphere.

Note that like distance, g, orbital_periodvà avg_temp, cả hai eccentricity và atmosphere có lẽ NULL for a given planet as a result of missing or erroneous data. For example, rogue planets have undefined orbital eccentricity, and many planets don’t have atmospheres at all.

Note also that data is not backfilled, meaning data entries from the beginning of the table (data contained also in the EXOPLANETS table) will not have eccentricity and atmosphere information.

sqlite> SELECT ...> DATE_ADDED, ...> ECCENTRICITY, ...> ATMOSPHERE ...> FROM ...> EXOPLANETS_EXTENDED ...> ORDER BY ...> DATE_ADDED ASC ...> LIMIT 10;
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |

The addition of two fields is an example of a kế hoạch thay đổi — our data’s formal blueprint has been modified. Schema changes occur when an alteration is made to the structure of your data, and can be frustrating to manually debug. Schema changes can indicate any number of things about your data, including:

• The addition of new API endpoints
• Supposedly deprecated fields that are not yet… deprecated
• The addition or subtraction of columns, rows, or entire tables

In an ideal world, we’d like a record of this change, as it represents a vector for possible issues with our pipeline. Unfortunately, our database is not naturally configured to keep track of such changes. It has no versioning history.

We ran into this issue in Phần I when querying for the age of individual records, and added the DATE_ADDED column to cope. In this case, we’ll do something similar, except with the addition of an entire table:

sqlite> PRAGMA TABLE_INFO(EXOPLANETS_COLUMNS);
0 | DATE | TEXT | 0 | | 0
1 | COLUMNS | TEXT | 0 | | 0

Sản phẩm EXOPLANETS_COLUMNS table “versions” our schema by recording the columns in EXOPLANETS_EXTENDED at any given date. Looking at the very first and last entries, we see that the columns definitely changed at some point:

sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE ASC LIMIT 1;
2020–01–01 | [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0) ]sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE DESC LIMIT 1;
2020–09–06 | [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0), (6, ‘eccentricity’, ‘REAL’, 0, None, 0), (7, ‘atmosphere’, ‘TEXT’, 0, None, 0) ]

Now, returning to our original question: when, exactly, did the schema change? Since our column lists are indexed by dates, we can find the date of the change with a quick SQL script:

Here’s the data returned, which I’ve reformatted for legibility:

DATE: 2020–07–19
NEW_COLUMNS: [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0), (6, ‘eccentricity’, ‘REAL’, 0, None, 0), (7, ‘atmosphere’, ‘TEXT’, 0, None, 0) ]
PAST_COLUMNS: [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0) ]

With this query, we return the offending date: 2020–07–19. Like freshness and distribution observability, achieving schema observability follows a pattern: we identify the useful metadata that signals pipeline health, track it, and build detectors to alert us of potential issues. Supplying an additional table like EXOPLANETS_COLUMNS is one way to track schema, but there are many others. We encourage you to think about how you could implement a schema change detector for your own data pipeline!

Visualizing lineage

 
We’ve described lineage as the most holistic of the 5 pillars of data observability, and for good reason.

Lineage contextualizes incidents by telling us (1) which downstream sources may be impacted, and (2) which upstream sources may be the root cause. While it’s not intuitive to “visualize” lineage with SQL code, a quick example may illustrate how it can be useful.

For this, we’ll need to expand our data environment once again.

Introducing: HABITABLES

 
Let’s add another table to our database. So far, we’ve been recording data on exoplanets. Here’s one fun question to ask: how many of these planets may harbor life?

Sản phẩm HABITABLES table takes data from EXOPLANETS to help us answer that question:

sqlite> PRAGMA TABLE_INFO(HABITABLES);
0 | _id | TEXT | 0 | | 0
1 | perihelion | REAL | 0 | | 0
2 | aphelion | REAL | 0 | | 0
3 | atmosphere | TEXT | 0 | | 0
4 | habitability | REAL | 0 | | 0
5 | min_temp | REAL | 0 | | 0
6 | max_temp | REAL | 0 | | 0
7 | date_added | TEXT | 0 | | 0

Một mục trong HABITABLES chứa những thứ sau:

0. _id: Một UUID tương ứng với hành tinh.
1. perihelion: Các khoảng cách gần nhất to the celestial body during an orbital period.
2. aphelion: Các furthest distance to the celestial body during an orbital period.
3. atmosphere: The dominant chemical makeup of the planet’s atmosphere.
4. habitability: A real number between 0 and 1, indicating how likely the planet is to harbor life.
5. min_temp: The minimum temperature on the planet’s surface.
6. max_temp: The maximum temperature on the planet’s surface.
7. date_added: Ngày hệ thống của chúng tôi phát hiện ra hành tinh này và tự động thêm nó vào cơ sở dữ liệu của chúng tôi.

Like the columns in EXOPLANETS, values for perihelion, aphelion, atmosphere, min_tempvà max_temp are allowed to be NULL. Thực tê la, perihelion và aphelion sẽ được NULL bất cứ gì _id in EXOPLANETS Ở đâu eccentricity is NULL, since you use orbital eccentricity to calculate these metrics. This explains why these two fields are always NULL in our older data entries:

sqlite> SELECT * FROM HABITABLES LIMIT 5;

Vì vậy, chúng tôi biết rằng HABITABLES depends on the values in EXOPLANETS (or, equally, EXOPLANETS_EXTENDED), Và EXOPLANETS_COLUMNS does as well. A dependency graph of our database looks like this:

Hình ảnh lịch sự của Monte Carlo.

Very simple lineage information, but already useful. Let’s look at an anomaly in HABITABLES in the context of this graph, and see what we can learn.

Investigating an anomaly

 
When we have a key metric, like habitability in HABITABLES, we can assess the health of that metric in several ways. For a start, what is the average value of habitability for new data on a given day?

Looking at this data, we see that something is wrong. The average value for habitability is normally around 0.5, but it halves to around 0.25 later in the recorded data.

A distribution anomaly… but what caused it?

This is a clear distributional anomaly, but what exactly is going on? In other words, what is the gốc nguyên nhân of this anomaly?

Why don’t we look at the NULL rate for habitability, like we did in Phần I?

Fortunately, nothing looks out of character here:

But this doesn’t look promising as the cause of our issue. What if we looked at another distributional health metric, the rate of zero values?

Something seems evidently more amiss here:

Trong lịch sử, habitability was virtually never zero, but at later dates it spikes up to nearly 40% on average. This has the detected effect of lowering the field’s average value.

A distribution anomaly… but what caused it?

We can adapt one of the distribution detectors we built in Part I to get the first date of appreciable zero rates in the habitability cánh đồng:

I ran this query through the command line:

$ sqlite3 EXOPLANETS.db < queries/lineage/habitability-zero-rate-detector.sql
DATE_ADDED | HABITABILITY_ZERO_RATE | PREV_HABITABILITY_ZERO_RATE
2020–07–19 | 0.369047619047619 | 0.0

2020–07–19 was the first date the zero rate began showing anomalous results. Recall that this is the same day as the schema change detection in EXOPLANETS_EXTENDED. EXOPLANETS_EXTENDED is upstream from HABITABLES, so it’s very possible that these two incidents are related.

It is in this way that lineage information can help us identify the gốc nguyên nhân of incidents, and move quicker towards resolving them. Compare the two following explanations for this incident in HABITABLES:

1. On 2020–07–19, the zero rate of the habitability column in the HABITABLES table jumped from 0% to 37%.
2. On 2020–07–19, we began tracking two additional fields, eccentricity và atmosphere, Trong EXOPLANETS table. This had an adverse effect on the downstream table HABITABLES, often setting the fields min_temp và max_temp to extreme values whenever eccentricity không phải NULL. In turn, this caused the habitability field spike in zero rate, which we detected as an anomalous decrease in the average value.

Explanation (1) uses just the fact that an anomaly took place. Explanation (2) uses lineage, in terms of dependencies between both tables and fields, to put the incident in context and determine the root cause. Everything in (2) is actually correct, by the way, and I encourage you to mess around with the environment to understand for yourself what’s going on. While these are just simple examples, an engineer equipped with (2) would be faster to hiểu và giải quyết the underlying issue, and this is all owed to proper observability.

Cái gì tiếp theo?

 
Tracking schema changes and lineage can give you unprecedented visibility into the health and usage patterns of your data, providing vital contextual information about who, what, where, why, and how your data was used. In fact, schema and lineage are the two most important data observability pillars when it comes to understanding the downstream (and often real-world) implications of data downtime.

Để tóm tắt:

• Observing our data’s kế hoạch means understanding the formal structure of our data, and when and how it changes.
• Observing our data’s dòng means understanding the upstream and downstream dependencies in our pipeline, and putting isolated incidents in a larger context.
• Both of these pillars of khả năng quan sát dữ liệu involve tracking the proper metadata, and transforming our data in a way that makes anomalies understandable.
• Better observability means better understanding of why and how data breaks, reducing both time-to-detection and time-to-resolution.

We hope that this second installment of “Data Observability in Context” was useful.

Until Part III, here’s wishing you no data downtime!

Interested in learning more about Monte Carlo’s approach to data observability? Reach out to Ryan, Barr, và đội Monte Carlo.

 
Barr Môi-se là Giám đốc điều hành và Đồng sáng lập của Monte Carlo, một công ty chuyên quan sát dữ liệu. Trước đó, cô từng là Phó Giám đốc Điều hành tại Gainsight.

Ryan Kearns is a data and machine learning engineer at Monte Carlo and a rising senior at Stanford University.

Nguyên. Đăng lại với sự cho phép.

Liên quan:

• Khả năng quan sát dữ liệu: Xây dựng giám sát chất lượng dữ liệu bằng SQL
• Data Catalogs Are Dead; Long Live Data Discovery
• Làm sạch dữ liệu và đọc hiểu trong SQL