数据管理 | 数据规划真的可行吗

0 评论 2683 浏览 5 收藏 10 分钟

通常来讲,数据规划可能包括两个层面的规划,一个是表层面的规划,一个是字段层面的规划。那么对于元数据,我们可以规划些什么?数据规划是否可行呢?这篇文章里,作者谈了谈他的看法,一起来看一下。

元数据是大数据平台的一个基础,大数据平台是以元数据为中心进行构建的。一个大数据平台能够把元数据管理好,那么这个平台就成功了一半。那么对于元数据我们能够规划些什么,是否可行?

一、数据规划的时候都规划什么

数据的规划都规划些什么,具体来分的话大概包括两个层面的规划,一个是表层面的,一个是字段层面的。

二、表层面的规划

表层面的规划涉及到数据仓库设计了。会包括了数据仓库分层、业务线划分。

1. 数据仓库分层

对于数据仓库的分层也就是我们在数据仓库领域中常常听到的ODS、DWD、DWS等等层级了。

在一般建表过程中,只需要在表名称之前增加前缀来区分不同层级即可。但是在大数据平台上,我们还希望增加一个类似分层的标签,来区分表分别属于什么层级。

如果使用的是向导式的建表过程,可以直接在建表过程中,增加数仓分层的选择,这样在建表过程中就确定表所属数仓分层。如果是脚本式建的表,就需要表创建完成之后,再进行一次维护,因为在脚本式的文本编辑框中,是没有办法标记,表属于什么分层的。

当然,除非表的分层和底层存储的数据库具有逻辑关系,即不同的数据仓库分层,即是不同的数据库(好像大部分实际情况也是这个样子的)。

2. 业务分层

一张表除了需要确定是什么数据仓库分层的,还需要确定是什么业务域的。一个数据仓库一般是汇总多个业务线数据,这些业务线中有的业务域重叠,有的是独有的。这就需要按照实际的业务情况进行划分。如果说数据仓库的分层是一个技术问题,业务域的划分就是一个业务+技术的问题了。需要对业务足够熟悉,又能知道把这些业务怎么进行技术表达,做到不重不漏。

在表上进行业务域的打标签,和进行数仓分层基本类型,如果向导式的可以直接在创建过程中进行打标。如果是脚本式,则需要再维护一次了。

三、表层面的规划,可行吗

回到上面的问题,数据规划可行吗?个人认为在表层面的规划是可行的,也是有必要的。有了这些数仓分层、业务域划分,就能够很好的找到数据,或者后续对不同的层进行治理,审视。

💡 个人感觉在大数据领域更多的是一个经验领域,每个人都有自己的认识,各种名词也都不能完全统一,各种理解也会有各自的角度,这里更多的是从自己的实际工作理解出发,后续可能随着工作接触不同层面,理解也会变化。

四、字段层面的规划

另一个层面的规划,字段层面的规划,这个层面的规划是否能够可行呢?又有哪些可以在字段层面进行规划呢?

数据指标

数据指标的使用,首选需要数据指标的统一。

数据指标的统一,在有一个系统支持之前,一般使用一张excel表进行管理,使用一个表格统一需要的指标口径,这种情况下可能小范围统一是可行的,如一个项目组,以为一个项目组内的信息拉齐很简单。如果要更大范围,变成全公司、全集团级别的指标对齐,就不能单单依赖Excel了。而是有一套系统,有指标的创建、审核、发布、下线等流程。

有了统一的数据指标,但是最终可以在两种场景下使用。一种是建模场景下的数据指标,一种是OLAP场景下的数据指标。这里的数据字段级别的规划,主要是在建模场景下的数据指标规划。

🔑 数据指标使用,个人划分为建模场景下的数据指标使用和OLAP场景下的数据指标使用。这两种场景多少有些细微的类似,但是又多少有些细微的区别,也说不好这样分有没有道理,先暂且这么记录吧。

如果有了全公司统一的指标口径之后,在建模场景下能在哪里使用。个人认为只能在图形化向导式创建元数据过程中使用。在向导式创建元数据的时候,将字段名由输入框,变成下拉选择形式,只能选择已经发布的指标来创建表,而不能随便输入任意字段。这样就能够从元数据层面上确保所有类似含义的指标在名称上、口径上是一致的,不会出现相同含义字段不一致的问题。

但是,这种向导形式,在实际的数据开发过程中是否适用,是不是能够强力的推广图形建模,而将SQL语句形式禁止掉。个人认为可能并不是特别可行。这必然会拖慢研发效率,在实际中不一定能推广开。

五、数据标准

这里只说下数据标准的使用,暂时不说数据标准的确定,后续会单独写下确定数据标准。数据标准里通常还会包含码表的部分,就统一称为数据标准,不做单独的区分。

如果确定了标准,最终在哪里使用呢?个人感觉都是在向导式的创建元数据中后,去选择一个数据标准,也就是将这个数据标准和这个字段进行一个关系的绑定。绑定关系确立之后能做什么?

如果是进行质量的校验,把不符合标准的数据过滤出来,又和数据质量有关了。如果不和数据质量有关,那确定了标准之后,那然后呢?就好像没有什么然后了。所以一直也没有想清楚,数据标准在创建元数据过程中起到一个什么样的定位,还需要再学习下。

🔑 个人没有接触过工业领域的数据标准,感觉工业领域对于这种数据长度、精度等数据标准的应用场景可能会更多些。

六、字段层面的规划可行吗

字段类的规划在实际中能够跑的通吗?说实话,目前没有看到过跑通的案例。两方面原因吧。

一方面,不管的数据指标还是数据标准,字段级的规划都需要图形界面支持,也就是向导式来创建元数据,这样创建元数据的形式需要一行一行添加,字段多的情况下,需要设置的内容太多了,研发人员也不一定会接受。

另一方面,就是大部分公司都已经有了一定的基础了,也就是有历史的数据,在这种场景下可以称之为历史包袱了,没有办法说把所有的都调一遍。

七、存在即合理?

如果按照存在即是合理的理解,只能是自己还没有遇到过具体的业务使用场景。数据指标如何使用,数据标准如何使用,这个还需要继续深入研究下。

但是有一个有趣的点。就是各个云厂商好像又都有这个模块,不知道是他们想清楚了怎么用,还是因为有了这个模块在竞标功能项上不丢分,至于是不是能用起来,就不是云厂商的事情了。

据传Dataphine能够将字段层面的规划用起来,因为使用Dataphine的一个前提是,从头开始,从规划、建模、开发。如果在流程上严格的做到建表向导化,也是可行的。据说这个也是为啥阿里既有Dataworks又有Dataphine的原因。Dataworks面向的就是有历史包袱,Dataphine重头再来。当前也可能仅仅因为人力资源过于丰富了。

本文由 @数据小吏 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!