原文towardsdatascience.com/stop-overcomplicating-data-quality-4569fc6d35a4?sourcecollection_archive---------1-----------------------#2024-12-10三种零成本解决方案只需几个小时而非几个月https://medium.com/caiparryjones96?sourcepost_page---byline--4569fc6d35a4--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--4569fc6d35a4-------------------------------- Cai Parry-Jones·发布在 Towards Data Science ·阅读时长 8 分钟 ·2024 年 12 月 10 日–https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/4b570b710780faeea2899cb85facde86.png一个“数据质量”认证的管道。来源unsplash.com在我的职业生涯中数据质量相关的项目通常意味着重大变革。从治理流程到昂贵的工具再到 dbt 实施——数据质量项目似乎从不想做得小而简单。更重要的是使用这种方式修复数据质量问题通常会导致新问题。更复杂、更高的成本、更慢的数据项目发布……https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/3713bea14e131ad68e6fde839cda4e8f.png由作者使用 Google Sheets 创建但事实并非一定如此。虽然像 Google 和 Meta 这样的大公司由于其庞大的规模和复杂性需要广泛的数据质量框架但大多数组织可以通过更简单的方法实现优秀的数据质量。在本文中我们将探讨三种小型到中型数据项目可以用来快速提高数据质量的方法同时保持将复杂性降到最低新的成本为零。我们开始吧简短总结利用老派的数据库技巧如 ENUM 数据类型和列约束。为您的特定数据质量问题创建一个自定义仪表板。使用一个简单的 Python 脚本生成数据血统。利用老派的数据库技巧在过去的 10 到 15 年里我们见证了数据行业的巨大变化尤其是大数据、并行处理、云计算、数据仓库和新工具大量大量的新工具。因此为了腾出空间容纳所有这些新事物我们不得不告别一些东西。有一些积极的方面比如微软 Access但也有一些最多只能说是值得怀疑的比如传统的数据设计原则和数据质量及验证过程数据摄入时。后者将是本节的主题。首先什么是“数据质量和验证在摄入时”简单来说这意味着在数据进入表格之前对其进行检查。可以把它想象成夜店外的保安。替代方案是构建后再测试这意味着先将新数据放入表格中然后再检查它。构建后再测试是许多现代数据质量工具选择的方法包括最流行的dbt。Dbt 会首先运行整个数据转换管道只有在所有新数据就位后才会检查数据是否合格。当然在许多情况下这可能是最佳解决方案。例如如果业务愿意为速度而牺牲质量或者如果在生产表之前有一个 QA 表Netflix 称之为写入-审计-发布的话。然而仅使用这种数据质量方法的工程师可能错失了对其组织的巨大收益。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/46fe0562178bfdf861d61c21943b513c.png生成表格前后进行测试。由作者使用draw.io创建。测试后再构建比构建后再测试有两个主要优势。第一个优势是它确保下游表格中的数据始终符合预期的数据质量标准。这为下游用户提供了一定程度的可信度这种可信度通常是缺乏的。它还可以减轻负责数据管道的工程师的焦虑感。我记得当我曾经在一家公司负责一个关键财务管道时。遗憾的是这个管道非常容易出现数据质量问题而当时的解决方案是一个构建后再测试的系统每晚运行一次。这意味着我每天早上必须赶早去检查运行结果以免下游用户开始查看他们的数据。如果出现任何问题我就需要迅速修复问题或者发送一条羞耻的 Slack 消息通知业务部门数据有问题请耐心等待我修复。当然测试后再构建并不能完全解决这种焦虑问题。故事的转变从需要匆忙修复问题以避免下游用户看到不良数据变成了匆忙修复问题以避免下游用户看到过时数据。然而工程师的工作就是权衡不同解决方案的利弊。在这种情况下我知道对于业务和我的理智来说旧数据是两种恶性选择中的最佳方案。测试-然后构建的第二个好处是它通常比设置一个完整的 QA 区域更容易实现尤其是与为解决大多数数据质量问题而准备的“火箭筒打兔子”解决方案相比。你需要做的就是在创建表时包含数据质量标准。看看下面的 PostgreSQL 查询CREATE TYPE currency_code_type AS ENUM(USD,--United States DollarEUR,--EuroGBP,--British Pound SterlingJPY,--Japanese YenCAD,--Canadian DollarAUD,--Australian DollarCNY,--Chinese YuanINR,--Indian RupeeBRL,--Brazilian RealMXN--Mexican Peso);CREATE TYPE payment_status AS ENUM(pending,completed,failed,refunded,partially_refunded,disputed,canceled);CREATE TABLE daily_revenue(idINTEGER PRIMARY KEY,date DATE NOT NULL,revenue_source revenue_source_type NOT NULL,gross_amount NUMERIC(15,2)NOT NULL CHECK(gross_amount0),net_amount NUMERIC(15,2)NOT NULL CHECK(net_amount0),currency currency_code_type,transaction_count INTEGER NOT NULL CHECK(transaction_count0),notes TEXT,CHECK(net_amountgross_amount),CHECK(gross_amountprocessing_feestax_amount),CHECK(dateCURRENT_DATE),CONSTRAINT unique_daily_source UNIQUE(date,revenue_source));这 14 行代码将确保 daily_revenue 表强制执行以下标准id主键约束确保唯一性。date不能是未来日期通过 CHECK 约束。是与 revenue_source 的唯一约束的一部分。revenue_source不能为 NULL。是与 date 的唯一约束的一部分。必须是 revenue_source_type 枚举中的有效值。gross_amount不能为 NULL。必须大于或等于 0。必须大于或等于 processing_fees tax_amount。必须大于或等于 net_amount。精确的小数处理。net_amount不能为 NULL。必须大于或等于 0。必须小于或等于 gross_amount。精确的小数处理。currency必须是 currency_code_type 枚举中的有效值。transaction_count不能为 NULL。必须大于或等于 0。这很简单可靠。你能相信这些功能自 PostgreSQL 6.5 发布以来就已经可用吗……它发布于 1999 年当然没有免费的午餐。通过这种方式强制执行约束确实有其缺点。例如它使得表格的灵活性大大降低并且在更新表格时会降低性能。像往常一样在深入使用任何工具/技术/方法之前你需要像工程师一样思考。创建自定义仪表板我有一个忏悔要说。我曾经认为优秀的数据工程师不会使用仪表板工具来解决问题。我认为一个真正的工程师会查看日志、难以阅读的代码以及其他任何让他们看起来聪明的东西如果有人不小心瞥见他们的电脑屏幕的话。我当时真傻。事实证明如果有效地执行并有明确的目的它们可以非常有价值。此外大多数 BI 工具使得创建仪表板变得非常简单和快速而且不需要太多时间来学习该工具。回到我个人的管道经验。我曾经管理一个包含所有业务收入来源的每日汇总表。每个来源来自不同的收入提供者因此来自不同的系统。有些是通过 API 调用有些通过电子邮件还有些通过共享的 S3 桶。正如任何工程师所预期的那样这些来源有时会出现问题而由于它们来自第三方我无法在源头解决问题只能请求成功的机会非常有限。起初我只使用故障日志来确定需要修复的地方。问题在于优先级。一些故障需要迅速修复而另一些则不够重要不能因此打乱所有工作我们有些收入来源每天报告的收入只有几分钱。因此出现了一些小的数据质量问题的积累变得难以追踪。引入 Tableau。我创建了一个非常基础的仪表盘展示了过去 14 天按收入来源和日期的元数据。三个指标就是我所需要的一个绿色或红色的标记表示数据是否存在或缺失。数据的行数。数据的收入总和。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c52b8496ecc6364ad902401ced5c886e.png一个简单但有效的仪表盘。由作者使用Tableau创建这使得管道的数据质量管理变得更加轻松。不仅我能更快速地查看问题所在而且它足够用户友好其他人也能轻松阅读确保了责任的共享。实施仪表盘后业务方关于管道的错误工单几乎降到零我的中风风险也降低了。使用血缘图绘制您的数据简单的数据可观察性解决方案不仅限于仪表盘。数据血缘图可以帮助快速发现受坏数据影响的表格。然而实施起来也可能是一项庞大的任务。在我看来造成这一问题的首要原因是 dbt。这个开源工具的一个关键卖点就是它的数据血缘功能。但为了实现这一点您必须屈服于 dbt 的框架。这包括但不限于在所有 SQL 文件中实现Jinja3。为每个数据模型创建一个 YAML 文件。通过 YAML 文件添加源数据配置。设置开发和测试流程例如开发环境、版本控制、CI/CD。基础设施设置例如托管自己的服务器或购买托管版本(dbtCloud)。是的确实很多。但它不一定非得是这样。归根结底实现动态数据血缘图所需的就是一台扫描您的 SQL 文件的机器以及输出用户友好的血缘图的工具。得益于 Python这可以通过一个仅有 100 行代码的脚本来实现。如果你了解一些 Python 和 LLM 提示你应该能在一个小时内修改代码。或者已经有一个轻量级的开源 Python 工具叫做SQL-WatchPup它已经包含了代码。只要您拥有所有的 SQL 文件在 15 分钟的设置之后您就应该能够生成像这样的动态数据血缘图https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/2ce584894fa4dbecf310e22749ba9487.png示例数据血缘图输出。由作者使用SQL-WatchPup创建就这样。没有服务器托管费用。无需学习额外的编程语言。无需重构文件。只需在本地运行一个简单的 Python 脚本。结论说实话——我们都喜欢那些闪亮的新工具但有时最好的解决方案是那些老旧、不可酷、和/或不流行的工具。下次当你面临数据质量问题时先退后一步再考虑是否需要进行那次大规模的基础设施改造。问问自己一个简单的数据库约束、一个基础的仪表盘或者一个轻量级的 Python 脚本能解决问题吗你的理智会感谢你这么做你公司的预算也会感谢你。