01  质量VS效率

我一直有一个观点：“数据模型设计的是商业模式，是产品逻辑；数据结果反映的是业务实操，是实际现状。”

数据开发的效率，是如何尽快的将产品设计、业务过程，转换为数据模型；数据开发的质量，则是如何尽快的将数据加工过程中的问题，识别出来。向业务交付的内容，是开发的内容；而如果开发的时候，忽略质量的问题，虽然交付的时候不会有感知，但往往会在排查问题阶段，把这些时间加倍的补偿回来。

很多时候，开发同学会觉得，做这么多质量工作是“无效”的，因为很多问题，并不需要数据同学对业务有太深入的了解，如果发现了，会觉得业务就这么设置的，跟我有啥关系；如果没发现，那就是开发工期太紧张了，我做不过来。

比如，按照规定，我们要向1万用户发放优惠券，但因为人群选择错了，导致发出去了10万张优惠券；再比如，商品绑定错了货品，或者是发货发错了，但大家的第一想法是数据算错了。这些情况的出现，导致数据和业务出现一些对立的情绪。

但幸运的是，数据质量问题的排查，要远比业务系统问题的排查，容易不少，因为我们有章可循。

所以，如何在保证开发速度的情况下，做好质量保障，是一个很重要的问题。效率和质量，哪个都不能放弃，是数据开发的两条生命线。

本文我们分开讲讲，质量体系的事情，效率体系的事情，以及两者如何兼顾平衡。

02  数据质量体系

数据的作用可以从三个比较宏观的维度来描述，一个是丰富、一个是准确、一个是及时。丰富的数据可以为业务提供更多可以描述业务的方法，准确的数据意味着交付结果及分析结论是可靠的，及时的是数据代表我们面对市场变化所能够做出的反应时间。因此，数据质量的体系，要以保障这三条为主。

从这个角度来讲，我们能够总结出一些常见的数据问题，而这些都是我们需要关注的。

首先是唯一性，也就是常讲的“主键唯一”，公共层的表主键必须唯一，例如订单表中的订单号、仓库表中的仓库编码，等等；如果是DWS层，那么统计的维度也是要唯一的，例如商品 + sku的统计表中，这两个ID的组合结果就要唯一。

其次是异常值，最常见的异常值是“空值”，如果一个字段的取值都是空，那么就需要考虑废弃该字段；同时，还有一些比较常见的场景，比如支付金额一般情况下不能是负值，这些都考验开发对于业务的熟练掌握程度；

再次是格式类型，比如日期的格式是否都是yyyyMMdd，再比如身份证号是不是有不符合位数的情况，不一而足；

最后是波动性，对于GMV、商品数这种全局性的指标，如果波动太大那么出现问题的可能性就很大。

所以平时就要从各个数据的关键环节，与业务或者服务端、客户端一起，解决这些问题。

在业务侧，要规范运营的操作，比如该填写的信息没有写，商品名称没有录入；或者是填写的信息存在问题，比如把小二的信息填错了。

在工程侧，问题产生的可能性最多，比如订单号记录重复了、数据精度转换时出错、数据存在空格导致与null产生差异，等等。

在消费侧，同步任务重启导致数据重复，或者是某些数据库任务挂掉导致少同步数据，都可能造成数据缺失或者重复。

通常情况下，不论是哪个环节发现了问题，都要及时的止损，因为把错误数据放给了下游，导致大范围的数据问题、数据重新刷新的成本，都是不可承受的。

当然，我们保障数据质量的方法，也都大同小异，主要包括：

数据规范：有道是“无规矩不成方圆”，规范并不是方便小二开发的，而是为了方便其他人阅读和接手代码的，排查问题时能够更快的定位，因此是团队必须遵守的规范；

项目文档：大多数时候，仅仅通过看代码，我们是无法还原这么设计的意图，因此整理下项目文档，记录背景、需求的详情，以及建模的思考过程与流程图，也是团队要强制的内容；

DQC：为每一个关键任务，加上基本的数据校验，如主键唯一、数据字段空值校验，等等，这也是任务自测的关键环节；

自动化测试：很多测试部门会写好任务回归用例，常见的一些问题会总结成自动化的任务，能够有效识别一些不常见的错误。

以上，就是数据质量体系的常见内容。

03 数据效率体系

数据开发讲求产出，不光要有“量”的结果，也要有“质”的思考。如果一味的做基础工作，被替代的可能性非常高。

因此，我们非常希望业务来提需求，因为这样才能贴近业务去走，体现个人或者团队的价值；但同时，我们又希望更快的交付这些需求，这样才能有时间，来把解决问题的过程或者方法，总结并沉淀下来。

开发的效率的提升方法，大体有四种：一是借助基础平台提供的工具，二是凭借完善的公共层，三是良好的业务Sense，四是多方顺利的合作模式。

先讲一下基础平台提供的工具，大数据的发展，从早期的靠工程师手动搭建集群、手动运维，发展到后来CDH这种有完善管理功能的集群，再发展到以阿里云为代表的完善商业化方案，工具提供的生产力已经不同于往日。因此，市面上的岗位，也从早期的“大数据开发”，逐步的过渡到了“数据仓库”，再到如今的“数据技术”，本质还是用数据来做需求开发，但其本质内核已经发生了比较大的变化。可以说，正是因为工具的不断完善，使得开发从偏后台的职能，走向了前台业务的职能。

在这个基础上，SQL开发有工作台、数据分析有在线文档、运维有监控平台、元数据有数据地图、任务执行有像海豚调度这种完善的工具、数据库有TiDB这种融合了OLAP和OLTP的工具、实时开发Flink统一天下。可以讲，数据开发如何使用好工具，已经成为了提升开发效率的不二法宝。

再讲一下完善的公共层，公共层是互联网数据仓库的核心理念，将复杂的业务由专门的团队，统一进行管理和建模，降低了下游理解数据、使用数据的难度。因此，不论团队规模有多大、数据团队的发展到了怎样的一个阶段，把公共层做好，都是一件非常有必要的事情。

按照分层理论，公共层是DWD/DIM/DWS三者的统称，也正好反映了Kimball所提出的一致性维度+一致**实。因此，公共层也是最考验建模水平的阶段，它是解决业务复杂性、保障准确性的最重要基石。

其次讲一下良好的业务Sense，因为建模所反映的是业务应有的逻辑，但它不代表业务想看到的逻辑，比如在电商场景中，优惠券的发放是一件比较复杂的事情，各种优惠策略可以设置的很灵活。但因为策略设置的很灵活，因此公共层不太可能把运营的玩法记录清楚，只是记录发生了什么事情。因此，当你想从应用层建模的时候，会发现每年的玩法都在变，每年的模型都要改了重新做。最重要的是，如果没有贴近业务，一不留神，数据没按照玩法算，结果就是错的，会被人追问数据准确性问题。

这其实也是关系到开发效率的核心因素，即你能不能准确理解业务的意图，因为不会所有的需求都写的一清二楚，很多逻辑还是需要自己来做判断。

最后说一下多方顺利的合作模式，虽然SQL开发是效率最高的交付语言了，但很多基础性的工作，少不了和其他部门打交道，比如OLAP引擎、比如前端页面、比如报表工具、比如工程业务逻辑，等等。因此，很多项目是否能够如期完工，就需要看与其他团队的配合情况了。

做过项目管理的同学都清楚，项目工期取决于最长关键路径，但互联网业务的现状，往往决定了服务端在跨团队合作中，是起到主导作用的，因此尤其要注意两者的合作关系。

04 数据质量与开发效率的平衡

因为绩效的压力，我们需要高效率的做开发；又因为数据质量/数据安全/业务投诉这种悬在头上的达摩克斯之剑，我们又不能忽视繁琐的质量保障工作，怎么办？

笔者的看法，我们有两个突破口，来解决这个问题。首先，将质量问题控制在某个层次上，也就是抓问题抓主要矛盾，其次，要有熟练的上手流程，避免重复性的说教工作。

将质量问题控制在某个层次上。这其实要分两个情况，一个是团队能够有正常的排期研发流程；另一个是野蛮成长，追求竞争的机制。

对于正常排期的研发流程，建议在流程前加入模型评审的环节，流程后加入测试的环节。对于大多数的问题，模型评审能够解决设计混乱的问题，而测试可以有效把低级问题消灭掉。再配合自测使用的DQC，基本上95%以上的问题，都可以解决掉。这种正常研发排期的环节，对数据质量问题往往是控制的比较好的。

对于追求竞争的机制，那么公共层的设计就很重要，默认情况下，100%的表要覆盖DQC监控，同时每个表也要配合三个以上的DQC规则。因为ADS开发节奏都很快，而且需求往往是变动性非常大的，今天改逻辑明天再改这种的，那么确保公共层是正确的的，阻断大部分的问题，就很重要。

熟练的上手流程。其实数据开发不像工程，任务通常都是以表的形式存在，而且团队会跨业务线进行开发工作，这些情况下，阅读他人的代码、熟悉他人的业务，就成了习以为常的事情。很多团队总是出问题，大体上集中在两个阶段，一个是老人带新人阶段，新人不懂坑有哪些；一个是业务交接的阶段，不熟悉业务，会导致一些看似逻辑正确的改动，引起了某些业务上的逻辑缺陷。

从这个角度看，作为数据开发，不厌其烦的整理文档、Review模型、汇报业务线情况，都是一些非常有必要的事情。一方面可以帮助团队其他同学了解业务，另一方面也为需求开发的背景和设计思路，留下比较充足的参考资料。从这个角度看，提供参考的规范与文档定期Review，这件事情在工作中的占比，可以达到30%以上。

最后，我们还需要注意一点，就是要有与业务直接对话的通道，以培养业务Sense。比如，业务操作的规范性、一些常见的业务问题总结。

尽管我们是偏后台的数据团队，但我们要走到前台，就要有一种宣讲、同步机制。这并不是故意扩大影响力，而是确实有必要的。我们要讲清楚数据背后的逻辑、数据计算的口径、数据工具使用的方法，等等。尤其要讲清楚，我们能做什么、不能做什么，有一套成熟的应对方法，以解释很多情况下数据与经验有偏差的原因，并把这些差异呈现出来。

双方理解一致了，很多质量问题，也就迎刃而解了。

祝大家工作994，生活工作两balance。

-END-