数据的可观察性和. 数据测试:你需要知道的一切

您已经测试了数据. 你也需要数据的可观察性吗?

在过去的十年里,抵御坏数据的第一道也是唯一的防线就是测试. 

这类似于软件工程师在将错误代码推向生产之前使用单元测试来识别错误代码, 数据工程师将利用测试来检测和防止潜在的数据质量问题进一步恶化. 这种方法(大部分)是好的,直到 现代数据工作流 公司开始吸收如此多的数据以至于单点故障已经不可行了.

在软件工程的世界里, 没有程序员会在不进行测试的情况下将代码部署到生产环境中. 类似地,没有工程师会在没有持续监视和可观察性的情况下运行产品代码.

既然分析数据为这些软件应用提供了动力——更不用说更广泛业务的决策和战略——为什么推荐一个正规滚球网站不把同样的努力应用到推荐一个正规滚球网站的数据管道上呢?

数据在不断变化, 使用不可靠数据的后果比不准确的仪表盘或报告要严重得多. 即使是数据质量上看似最微不足道的错误,也可能在未来演变成更大的问题.

最近, 一位FinTech客户(推荐一个正规滚球网站称她为Maria)解释了一个货币兑换错误是如何导致收入和工程时间的重大损失的,她的团队直到几天后才发现这个错误.

Maria和她的团队认为他们已经准备好了所有适当的测试来防止数据停机——直到他们没有. 发生了什么事?

在任何数据系统中都有 两种类型的数据质量问题:你能预测的(已知的未知)和你不能(未知的未知). 而Maria和她的团队已经进行了数百次测试,以捕获一组离散的已知未知数, 他们没有一个明确的方法来解释未知的未知,或者随着公司数据生态系统的发展,添加新的测试来解释已知的未知. 

等玛丽亚解决这个问题时,损害已经造成了. 

事实是,已知的未知和未知的未知需要两种不同的方法 测试数据可观测性. 以下是它们的不同之处,以及一些最好的团队在大规模处理数据质量方面的做法: 

什么时候测试数据? 

在数据进入生产数据管道之前发现数据质量问题的最常见方法之一是测试数据. 与测试, 数据工程师可以验证他们的组织对数据的假设,并编写逻辑来防止问题顺流而下. 

数据测试 是必须帮助捕捉特定的吗, 已知的问题出现在您的数据管道中,当新的数据或代码破坏了您的原始假设时,将向您发出警告.

一些最常见的数据质量测试包括:

  • 空值 -任何值都是未知的(NULL),不应该有?
  • 体积 -你的数据到了吗? 如果是,你得到的是太多还是太少?
  • 分布 —是在期望/要求范围内的数值?
  • 独特性 -是任何重复的值在您的唯一的ID字段?
  • 已知的不变量 利润总是收入和成本之间的差额吗? 

数据测试非常类似于软件工程师如何使用测试来提醒他们很容易理解的问题,这些问题可能会发生在他们的应用程序上. 

但是,数据测试是否足以保持在破损数据管道的顶部?

与软件类似,数据是企业成功的基础. 因此,它需要在任何时候都是可靠和值得信赖的. 以同样的方式 站点可靠性工程师(SREs) 管理应用程序停机,这是数据工程师需要关注的问题 减少停机时间数据.

同样,单元和集成测试不足以确保软件的可靠性, 单靠数据测试无法解决数据可靠性问题.

需要有一种方法来提醒您可能不会发生的问题(未知的未知), 随着你的公司吸收更多的数据, 问题,你 可以 测试你是否能神奇地克隆自己. 仍然, 即使您可以克隆自己——使您编写测试的能力加倍——这是否会是对您时间的一种很好的利用呢?

可能不是. 需要有一种方法来覆盖所有的基础,即使是在运动中. 

什么时候应该使用数据可观察性? 

即使是最全面的测试套件也不能解释整个堆栈中可能出现的任何和所有问题——而不仅仅是特定测试所涵盖的部分. 既要考虑未知的未知数,又要跟上数据管道中不断增长的已知未知数的数量, 你需要投资于可观察性, 太. 

为了保证高 数据的可靠性,您的数据质量方法必须对您的数据管道具有端到端可见性. 比如DevOps可观察性解决方案(i.e., Datadog New Relic), 数据可观测性 使用自动监控、警报和分类来识别和评估数据质量问题.

可观察性涵盖的数据质量问题的一些例子包括: 

  • 没有更新的查看器仪表板或报表, 这些陈旧的数据会在几个月的时间里不被人注意,直到一个企业主管在季度末访问数据时发现数据是错误的.
  • 组织代码库的一个小变化,导致API停止收集数据,而这些数据支持Tableau仪表盘中的一个关键字段.
  • JSON模式的意外更改,一夜之间将50,000行变成500,000行.
  • 您的ETL(或ELT)发生了意外更改,导致一些测试无法运行, 这会导致数据质量问题,而这些问题会在几天内被忽视.
  • 多年来一直是管道一部分的测试,但是最近没有更新以反映当前的业务逻辑.
在与数百个数据团队交谈后,通过经验,我发现大约80%的数据问题不能仅通过测试来解决. 图片由蒙特卡罗提供. 

如果测试您的数据捕获20%的数据质量问题, 另外80%是由数据的可观察性决定的. 数据可观察性还可以帮助团队识别“为什么”?,即使这个问题与数据本身无关.


数据可观察性与数据测试的区别有四个方面

数据可观测性 数据测试可以帮助你完成同样的目标——可靠的数据. 这两个 测试和可观测性 是很重要的, 这两种方法是相辅相成的, 但是每一种方法在保证数据质量方面都是不同的. 

以下是可观察性不同于数据测试的4种关键方法:

1)端到端覆盖

现代数据环境非常复杂, 对于大多数数据团队来说, 在许多情况下,创建和维护高覆盖率的健壮测试套件是不可能的,也是不可取的.

由于数据的复杂性, 数据工程师不可能在开发过程中预测到所有的可能性. 测试不足之处, 可观察性填补了这一空白, 为整个数据堆栈提供一个额外的可见层. 

2)可伸缩性

写作, 维护, 为了适应业务的需要而删除测试可能具有挑战性, 特别是随着数据团队的增长和公司跨多个领域分发数据. 推荐一个正规滚球网站从数据工程师那里听到的一个共同的主题是在他们的数据生态系统中扩展数据测试的复杂性.

如果您不断地回到您的数据管道,并为现有管道添加测试覆盖率, 对于数据团队的成员来说,这可能是一笔巨大的投资. 

和, 当关于数据管道的关键知识掌握在数据团队的少数成员手中时, 追溯处理债务测试将成为一件麻烦事,并导致资源和精力的转移,而这些资源和精力本可以花在能起到推动作用的项目上.

可观察性可以帮助缓解跨管道扩展数据可靠性所带来的一些挑战. 通过使用基于ml的方法从过去的数据中学习并监视新的传入数据, 数据团队可以获得对现有数据管道的可见性,而不需要多少投资. 具有设置自定义监视器的能力, 您的团队还可以确保覆盖独特的业务案例和关键资产, 太.

3)根本原因 & 影响分析

测试可以帮助在数据进入生产之前捕获问题. 但是,即使是最健壮的测试也不能捕捉到可能出现的所有问题——数据停机仍然会发生. 当它发生的时候, 可观察性使团队能够更快更容易地解决发生在数据生命周期每个阶段的问题.

因为数据可观察性包括端到端沿袭性, 当数据了, 数据工程师可以快速识别上游和下游的依赖关系. 这使得 根本原因分析 快得多, 并帮助团队成员主动通知受影响的业务用户,并在他们解决问题时让他们处于循环中. 

4)节约时间和资源

数据工程师面临的最突出的挑战之一是速度——而且他们经常牺牲质量来实现速度. 你的数据团队在时间和资源上已经很有限了, 为你的首席营销官数周以来一直在烦你的关键报告收集数据,不能再等了. 当然,有很多测试 应该 在转换数据之前设置,但是没有足够的时间. 

数据可观察性可以作为防范坏数据的保单,并加快团队部署新管道的速度. 它不仅涵盖了那些未知的未知,而且还帮助您捕获与数据相关的已知问题. 

那么,两者你都需要吗?

无论您的测试套件有多好, 除非你的数据是静态的, 指望单靠测试就能将您从数据停机中拯救出来是完全不可行的. 这需要编写新的测试, 更新现有的测试和阈值, 随着数据堆栈的发展,弃用旧的测试,即使对于最优秀的团队来说也是乏味的. 

而数据测试可以用于较小的管道, 它不能很好地跨分布式数据系统扩展. 以满足新常态的需要, 数据团队必须同时依赖于测试和端到端可观察性. 

采用这种双管齐下的方法来提高数据质量, 你对停机时间的防御变得更强了.  


有兴趣了解更多关于数据可观察性如何补充您的测试的信息? 接触 斯科特·奥利里可以玩滚球的正规app团队的其他成员.