首先,我要阐明一个观点,数据的正确和数据的合理在我看起来是不同的,原始数据的值和数据中台数据的值一模一样,数据在所有人眼中肯定都是正确的,而数据的合理则需要满足三个条件:第一我知道数据是合理的;第二我可以说服别人这个数据是对的;第三数据是有事实可以验证的.

而数据的合理,我认为是比数据的正确是要重要的,也只有合理的数据培养出来的产物才应该是正确的,比如我今天下单了一笔一万元的货物,但是在我下单后,货物的价格发生了变动,数据的回流存在一定延迟,所以在业务系统中一万元的货物购买了一百件商品价格为一百三十元的货物,这就涉及到源数据质量了.

源数据质量

从库同步导致问题,数据延迟导致问题,业务员手工调整数据导致问题,源系统的稳定性永远是悲观的,至少我没有办法信任任何一个接入数据中台的数据源,他们总是会出现各种奇奇怪怪的问题.

最离谱的是前不久我发现某个系统在融合其他已经废弃的系统数据的时候,根据某个映射表做的关联,但二者除了用户id相同,其他数据完全不一致,这样的数据,说他是正确的吗?那必定是正确的,毕竟旧的系统已经废弃,不可能有人再去验证,唯一能够提供佐证的只有接手的业务系统.

面对这种情况,在拉不通双方的情况下,我采取的方式是拆解用户其他信息进行关联,调整中台维表的数据来减少改动和确定数据大致正确,至于说不对的,对不起,数据开发是万万不能的.

上面说源数据我们应该秉持悲观的态度,所以我们就需要用最苛刻的要求面对源数据,从有无数据到数据合理,每一个字段都应该是清晰的,如果是含糊的,在模型开发中,字段含义的不确定性会进一步增加,而集成层使用的时候,最后的情况可能是好的,但结果一定是偏离的.

当然,如果你的公司是金融行业,那当我没有说,金融行业大部分数据都是井井有条的,再加上国家的法规,数据的可靠性比其他行业要好很多.

中间结构

中间结构其实就是模型设计,数据标准的重要性,做数据开发的朋友应该都应该有了解,单一个字段出现的时候,背后所包含的意思和字段中数据一样重要.

上面说到数据合理的三个条件,对于第三点,这里就可以得到体现,当你要验证某个字段中数据是否正确的时候,需要看下游的使用,上游的验证,但是过一段时间后你就会发现,你的下游在使用的时候会遇到各种奇奇怪怪的问题.

再举个🌰,字段名称假设叫实付金额,最开始设计的时候,源系统的实付是不包含运费的,有一天,某个源系统包含了,也进来了,下游使用的时候不需要运费,减去了运费,忽然有一天,实付金额里面又没有包含税费,下游又认为税费是实付,想让模型层在实付计算的时候加上税费,但是另外一个下游有意见了,他们认为实付金额不包含税费,之后就开始扯皮.

而你此刻就好像诸葛亮,隔岸观火,这样自然是很好,但火迟早会烧到你的身上,毕竟干活的是你,有着时间,摸鱼<・)))><<他不香?所以你只要提前写好,你认为实付金额是"用户在进行本次交易的时候,由用户实际支付的钱"就好,当集市看到的时候,他们就会意识到这个字段里包含的数据是什么,不会找你.

当需要验证数据合理的时候,源系统也有个实付金额,但是你的实付是加了运费的,含义明确,最终比对结果才会更快更准.

个人决策

这里我叫个人决策,其实是开发过程中的个人决定,是否取值,是否关联,大小表问题,调优问题,这些问题其实都是个人决策,大部分开发技术水准其实相差不大,不会的,查资料也可以解决,无非就是慢和快.

但决定数据合理与否的其实还是每个人的决策,甚至细化一点可以说是个人的心情.

程序员口中的"屎山",其实大数据开发经常面对,PB级的数据寻找问题,肉眼看过一百行,我感觉还可以,看到一千行,我心情不是很美丽,看到一万行,我想骂人;同一份数据不同维度,第一次查,第二次查,第N次查,我陷入了无穷的折磨.

这个时候其实应该梳理自己的做法,一件事情陷入重复,就需要冷静自己是不是对的,保持自己的思考严谨,心情平稳才可以有较为正确的决策,越慌乱越开心,数据的情况就会越容易出现波动.

请记住,要想有合理的数据,需要用严谨的想法,充实的数据结构和苛刻的态度对待你面前两份看起来一模一样的数据!