|0x00 质量VS效率

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

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

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

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

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

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

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

|0x01 数据质量体系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|0x02 数据效率体系

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

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

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

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

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

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

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

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

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

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

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

|0xFF 数据质量与开发效率的平衡

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

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

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

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

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

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

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

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

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

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