<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Data Quality on Boyang Yue</title><link>http://blog.boyangyue.com/tags/data-quality/</link><description>Recent content in Data Quality on Boyang Yue</description><generator>Hugo</generator><language>en-us</language><copyright>A Good Year Ahead</copyright><lastBuildDate>Mon, 07 Oct 2024 10:00:00 +0900</lastBuildDate><atom:link href="http://blog.boyangyue.com/tags/data-quality/index.xml" rel="self" type="application/rss+xml"/><item><title>Asserting, Observing, and Owning Data Quality</title><link>http://blog.boyangyue.com/2024/10/asserting-observing-and-owning-data-quality/</link><pubDate>Mon, 07 Oct 2024 10:00:00 +0900</pubDate><guid>http://blog.boyangyue.com/2024/10/asserting-observing-and-owning-data-quality/</guid><description>&lt;p&gt;A nightly pipeline can pass every check it runs and still hand a dashboard the wrong number. The schema matches, no required column is null, row counts fall inside their usual band, and the revenue total is quietly wrong anyway, because an upstream service changed what one field means while leaving its type and shape untouched. The checks were green. The data was not correct.&lt;/p&gt;
&lt;p&gt;Running checks is not the same as having data worth trusting, and the distance between the two is seldom one missing rule that a longer list would have caught. It is more often a matter of framing. A validation suite is a model of how data can go wrong, and a suite can be diligent, extensive, and green while modeling the wrong failures. Three different concerns travel under the single name data quality, and they are easiest to keep apart by what it takes to check each one.&lt;/p&gt;</description></item></channel></rss>