培养数据意识，从数据口径字典开始

上个月将修改好的metabase报表上线了，意识到数据口径字典的统一标准化的重要性是从一个需求发布到正式环境出问题开始的。这个需求上线后，发现某张统计表和明细表的数据数对不上，这时候需要测试协助去找出对不上的某几条数据，再一遍遍去找到问题-修改-重新发版。

这一切的源头，是产品对于数据定义和取数的不规范导致的。所以通过整理数据口径字典这个需求，希望理解为什么要做，怎么做以及怎么维护，从而去培养基础的数据意识。

一、 为什么做数据字典-why

第一个是实际场景需要的原因。在不同的数据报表中出现相同的数据名，但是定义不一致；在不同的数据报表中出现不同的数据名，但是定义一致。所以会导致在导出数据时会因出现相同数据名但定义不同而产生的数据不匹配现象。

第二个是业务数据规范的原因。由于我们公司的业务数据较多，如果将不同的业务数据糅合在一张表里存储，会造成数据的冗余、表关联的数量增多而出现关联出错的误操作、修改某几个数据时要同时处理多张表等问题。

因此我需要从整理数据口径字典开始，去为转介绍宽表做铺垫。把相同业务的所有数据放在同一张表中，目的在于提高数据提取的效率，便于后续迭代。

二、怎么做数据字典-how

数据口径字典整理的重点，我梳理主要有以下四点。

• 数据口径和定义的重新规整，数据名和定义尽量做到清晰、明确、易懂，数据呈现格式也需记录；
• 数据口径的原定义取数逻辑和现定义取数逻辑的记录，让后续开发和产品查找有迹可循；
• 确认数据口径定义是否与业务方达成一致，避免歧义
• 需涵盖尽可能多的相关业务数据，规整不同类别，形成一本可查询的字典

三、转介绍数据口径字典-what

以具体的转介绍业务，总结是如何建立数据口径字典的。

1. 梳理现有业务报表中和转介绍口径相关的口径，根据优先级提需求记录开发取数

第一步是对于业务场景熟悉了解的方法，通过整理已有数据口径，可以快速了解现有业务包含什么内容，也是应届生熟悉业务快速上手的一个好方法。

记录已有口径（包括原数据口径、原定义、格式、），并记录开发取数（记录的是实际数据库的哪张表的哪个数值以及文字描述记录），目的是在于后续为新口径记录开发取数时，开发同事可知道当时实际取数来源，提高效率。

2. 给转介绍数据口径重新命名和定义

业务线。先要明确现有这个业务主要分哪几大类，业务线是作为数据口径字典的最大维度。

数据口径名称。在整理时是认为名称越清楚越好。具体什么是清楚的名称，需要根据具体业务来描述。举一个例子，「学员正式课报名时间」。第一反应是：这个学员指的是什么学员？什么样的行为叫做报名？正式课有分首付和全付，这里是哪种？。因此这个口径名称就是不贴合业务，容易让业务方产生误解并导致数据不准确的名称。因此根据具体业务，需要做具体维度划分。

数据定义。在清楚的数据口径基础上，定义基本上是对数据口径的详细描述，以及补充现有业务对该维度数据的规则。需要注意是（如下图），一个是：每个数据口径都是存在于metabase报表中的，需明确这个报表是统计表还是明细表，以便给后续产品和开发知道是获取某个字段还是统计某些字段。另一个是：对于数据口径A与数据口径B是有关联的，需要在通用定义后备注详细定义。

3.  和业务方确认口径和定义无误后，即可开发记录新定义的取数了

在这过程中开发可能会不断询问关于数据口径的定义，到底要哪个数值；取得是哪张表；可能会出现什么情况是自己之前没有考虑到的，这样的过程也能帮助我更深理解数据口径的定义和其中逻辑。

4. 校验

完成取数后的校验也是很重要的。可能由于数据口径的复杂程度，关联表数量的多少和操作过程中的规范性，导致数据口径存在取数错误的情况，因此我通过校验明细表和统计表的相同一项数据口径来确认是否存在取数错误。

四、日后维护数据字典

随着业务的发展，日后数据口径可能会发生更改或新增。因此在整理转介绍数据口径字典的同时，我给出了相应的口径规范说明，方便日后维护数据字典。

总结

通过以上步骤，已交付了转介绍数据字典，也在这个过程中更熟悉了转介绍业务以及培养了基础的数据意识。数据口径字典校验完成后，还需要经过内部同事的沟通，确认后才能作为业务宽表供公司同事实际场景应用。但是从这次的整理来看，认为一个好的数据口径字典，应该是从维度慢慢往下拆分，根据具体业务搭建框架，做到详细具体，像一本真正字典一样，应有尽有。

本文作者 @莫琳

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！