说到数据质量，大多数技术人员熟悉的一句格言是“垃圾进，垃圾出”，然而直到今天，大部分组织似乎满足于这个现状。哈佛商业评论的一份调查显示，仅有3%的组织其数据符合基本的质量标准。这让人有些担忧。如果你计划增加人工智能与机器学习的使用来自动化一些决策，然而你的数据不够好的话，那么你的一系列行为不可避免的要做出妥协。难怪一些高级IT决策者会把数据质量作为一个优先考虑的事情。
有一个忧虑是数据质量计划会变成一项永远也做不完的任务——无尽的努力却收效甚微。但是事情不必如此。巨大数据质量的改进可以通过把我们日常软件开发中使用的原则运用到数据的方式来实现。
丰饶的数据：是土壤而非燃料
我们常听说数据是新燃料的说法，但是这种类比很无力。拥有大量数据并不能使你富有。许多与我们共事的客户有丰富的数据，可是他们也需要努力去数据中获取有意义的值。
与其把数据看做燃料，我们更愿意把它认为是土壤——你若投入时间和精力去培养，你就会有所回报。这就是数据质量的来源。即使数据质量不是你计划主要驱动力，通过制定工作方式的例行方面，你做的这些小的投资在长期也会有所回报。
最近，我在为一个大型的跨国公司客户做事，他们想要提升其线上商店的效能：更好地了解客户付款转换漏斗，以便能够发现不完整旅程中的任何重要模式。
这些人有大量的用户行为数据：他们捕获你在浏览商店时的每次点击或输入，从按钮点击开始到购买商品，再到你阅读商品描述时滚动鼠标或者敲击的数目。这里有PB级匿名用户的行为数据，并且每天都在以TB级几百倍的速度增长。
我们已经跟客户谈了顾客（消费者）购物之旅的事情，以及他们通过商店所能得到的快乐路径。可是当我查看数据去找例子以验证我的理解时，我不断的碰到预期情况并没有发生的情形：顾客们所经过的路径，我们不能恰当的理解。那是大数据的挑战之一：你发现你的边界情形实际上发生的相当频繁。
我们的问题是尝试想办法来改进这个网店，现在我们需要弄明白这些边界情况。顾客为什么会做出意想不到的决定而终止购买？我们所看到的这个不寻常的行为是个bug吗？或是因为我们漏掉了一个重要的信息？我们是否捕获到了错误的信息？
为了调查它，我们没有只是查看用户点击，我们还查看了在整个过程中，在不同的点所触发的所有的后端流程日志。我们实际上通过尝试去理解数据，返回有bug的服务端和前端工程师那儿，做了大量的质保工作。他们也注意到了这些小事儿，但他们并不理解这些修复带来的正面的影响。
一旦前后端工程师看到了这些小的数据问题带来的累积效果，他们热衷于去修复它们。然而理想的情形是，期望你在投入生产前修复好这些系统。
培养你的数据
你可能认为数据质量是重要的，可是它于你每天的工作是隔离的，单独存在的——比如这里有一个数据质量部门来负责在某个点看护数据质量。这里我们可以向QA实践如何在广阔的软件开发领域向前演进学习：我们也习惯于拥有单独的QA部门，但是敏捷和精进思考可以帮助我们把质量引进到软件开发的流程。
然而如果你在考虑丰富的数据，关心质量来真正的交付强有力的洞察，你会开始领悟到你需要距离数据源更近些去培养它：把数据质量作为做任何事的完整的一部分来对待。
并不是说你要搞定所有的数据质量问题。但是如果你仅仅修复数据下游，你将永远没时间去修复数据源，并且之后会耗费你更多，因为越来越多的消费者必然会面临同样的问题。更糟的是，他们将开始在下游消费“清洁数据”而不是真实的数据源。这就是通常说的反模式：来自于企业数据仓库系统的聚合数据被用来作为交易系统的输入，而且交易系统不得不经历修复早期数据质量问题的痛。
所以我们说要把数据质量当做日常工作的一部分是什么意思呢？我们可以与软件开发实践并行，从两个视角来看：预生产时我们的行为，还有一旦我们上线了我们的行为。
预生产时，如果你真的在乎培养数据，你会发现有问题，你停下来把它修复好以便不给接下来的路产生羁绊。
你大可以把测试数据质量看做你在考虑测试你的代码。
一般情况你会有一堆测试来判定你的代码是否工作。对数据而言，给你期望产生的事件一个发布模式，并且知道这些事件是如何流向的，我们认为这都是有用的。这要求你对数据去执行一些基本的sanity检查，确保你不会产出与模式不符的数据。还可以添加模式演化测试与发布到你的部署管线上，确保变更向后向前的兼容性。
有时这个流程很像功能测试。例如，我期望某个元素看起来像个日期。所以我们可以断言数据的格式是正确的，还有它在有效的日期范围内 —— 如果你拿到了19世纪00年代的销售数据，你很有可能会有数据质量问题。
但是想要停下来这件事对于生产系统来说工作的并不好。
你不能总是停掉生产系统来去修复一个数据质量问题。
我从一个客户那儿习得这个教训，客户正在构建一个产品，它需要从政府那儿获取数据。我们在消费一个数据，并把有趣的信息展现给顾客 —— 并且我们跟客户一起工作来构建这个产品。
那意味着我们必须要对来自外部的供给数据做出各种假设。但是我们能用这些数据命中问题：有时字段丢失了，或者数据不够合理。并且这些假设打破了我们的产品特性。
为了弄懂发生了什么，我们开始对数据的假设写些测试，用以建立某种模式来分解我们的系统。当构建这些测试时，我们发现越来越多的数据质量问题。结果是，我们把这些测试合并到我们的数据获取的管线。因此每天客户都会给我们新的转储数据，并且我们开始对这些数据跑我们的测试。
这里我们面临的问题是我们能识别出那些可能打破产品的事儿，但是停止数据管线去修复它们就会意味着产品会显示过时的信息。
这就是为什么我开始质问因为产品问题而停下来的想法。相反，我们可以获取那些好的数据，而仅仅是标识出那些错误的东西用以作为后续的事情。
这个方法跟软件开发实践中生产上的质量保证很相似：观察和监视成为了较为可取的方法。你可以设定阈值去定义你的正常期望值，仅仅在超出阈值获得警告的时候采取行动。然而在预生产上，你可能想要尽可能的接近完美，一旦你到了生产，你就可以看到什么级别的质量是可接受的，并且随着你学到更多的数据流向而自适应调节。
坚持改变
尽管我固执的认为我们可以从查看软件开发的最佳实践中改进数据质量学到许多，它并不意味着解决问题是容易的。许多我们的客户没有合适的结构来实现这种类型的实践。所以这个进入的成本是需要事先投资的。
靠高级决策者的一个单一的数据质量程式计划去解决你的问题，那也是不可能的。相反，数据质量需要成为开发流程的一部分，所以不论是生产数据的还是消费数据的，你要让你的团队成为那些一直在考虑数据质量的一批。
这些对于许多组织来说都是较大的变化。如果你想要培养和使用数据来赋能你的生意，我们认为这是必经之路。