评估标准的四个方面

Posted 2023-04-13

评估标准首要包括四个方面，完整性、共同性、精确性、及时性。评估数据是否抵达预期设定的质量要求，就可以通过这四个方面来进行判别。

完整性

完整性指的是数据信息是否存在缺失的情况，数据缺失的情况可能是整个数据记载缺失，也可能是数据中某个字段信息的记载缺失。不完整的数据所能学习的价值就会大大下降，也是数据质量最为基本的一项评估标准。

数据质量的完整性比较简单去评估，一般我们可以通过数据计算中的记载值和仅有值进行评估。例如，网站日志日访问量就是一个记载值，往常的日访问量在 1000 左右，突然某一天降到100了，需求查看一下数据是否存在缺失了。再例如，网站计算地域分布情况的每一个区域名就是一个仅有值，我国包括了32个省和直辖 市，如果计算得到的仅有值小于32，则可以判别数据有可能存在缺失。

共同性

共同性是指数据是否遵从了共同的标准，数据集结是否坚持了共同的格式。

数据质量的共同性首要体现在数据记载的标准和数据是否符合逻辑。标准指的是，一项数据存在它特定的格式，例如手机号码必定是13位的数字，IP地址必定 是由 4个0到255间的数字加上”.”组成的。逻辑指的是，多项数据间存在着固定的逻辑关系，例如PV必定是大于等于UV的，跳出率必定是在0到1之间的。

一般的数据都有着标准的编码规矩，关于数据记载的共同性查验是较为简单的，只需符合标准编码规矩即可，例如区域类的标准编码格式为“北京”而不是“北京市”，我们只需将相应的仅有值映射到标准的仅有值上就可以了。

精确性

精确性是指数据记载的信息是否存在失常或差错。和共同性不一样，存在精确性问题的数据不只是只是规矩上的不共同。最为常见的数据精确性差错就如乱码。其次，失常的大或许小的数据也是不符合条件的数据。

数据质量的精确性可能存在于单个记载，也可能存在于整个数据集，例如数量级记载差错。这类差错则可以运用最大值和最小值的计算量去审理。

一般数据都符合正态分布的规矩，如果一些占比少的数据存在问题，则可以通过比较其他数量少的数据比例，来做出判别。

当然如果计算的数据失常并不明显，但仍然存在着差错，这类值的查看是最为困难的，需求通过凌乱的计算分析对比找到蛛丝马迹，这儿可以凭仗一些数据分析东西，那么具体的数据修改方法就不在这儿介绍了。

及时性

及时性是指数据从发作到可以查看的时间间隔，也叫数据的延时时长。及时性关于数据分析本身要求并不高，但如果数据分析周期加上数据建立的时间过长，就可能导致分析得出的结论失去了学习意义。 参考技术A 数据评估质量？评估标准四个方面完整性、共同性、精确性、及时性

一言分享
2018年06月13日
数据质量是保证数据应用的基本，它的评估标准首要包括四个方面，完整性、共同性、精确性、及时性。评估数据是否抵达预期设定的质量要求，就可以通过这四个方面来进行判别。

完整性

完整性指的是数据信息是否存在缺失的情况，数据缺失的情况可能是整个数据记载缺失，也可能是数据中某个字段信息的记载缺失。不完整的数据所能学习的价值就会大大下降，也是数据质量最为基本的一项评估标准。

数据质量的完整性比较简单去评估，一般我们可以通过数据计算中的记载值和仅有值进行评估。例如，网站日志日访问量就是一个记载值，往常的日访问量在 1000 左右，突然某一天降到100了，需求查看一下数据是否存在缺失了。再例如，网站计算地域分布情况的每一个区域名就是一个仅有值，我国包括了32个省和直辖 市，如果计算得到的仅有值小于32，则可以判别数据有可能存在缺失。

共同性

共同性是指数据是否遵从了共同的标准，数据集结是否坚持了共同的格式。

数据质量的共同性首要体现在数据记载的标准和数据是否符合逻辑。标准指的是，一项数据存在它特定的格式，例如手机号码必定是13位的数字，IP地址必定 是由 4个0到255间的数字加上”.”组成的。逻辑指的是，多项数据间存在着固定的逻辑关系，例如PV必定是大于等于UV的，跳出率必定是在0到1之间的。

一般的数据都有着标准的编码规矩，关于数据记载的共同性查验是较为简单的，只需符合标准编码规矩即可，例如区域类的标准编码格式为“北京”而不是“北京市”，我们只需将相应的仅有值映射到标准的仅有值上就可以了。

精确性

精确性是指数据记载的信息是否存在失常或差错。和共同性不一样，存在精确性问题的数据不只是只是规矩上的不共同。最为常见的数据精确性差错就如乱码。其次，失常的大或许小的数据也是不符合条件的数据。

数据质量的精确性可能存在于单个记载，也可能存在于整个数据集，例如数量级记载差错。这类差错则可以运用最大值和最小值的计算量去审理。

一般数据都符合正态分布的规矩，如果一些占比少的数据存在问题，则可以通过比较其他数量少的数据比例，来做出判别。

当然如果计算的数据失常并不明显，但仍然存在着差错，这类值的查看是最为困难的，需求通过凌乱的计算分析对比找到蛛丝马迹，这儿可以凭仗一些数据分析东西，那么具体的数据修改方法就不在这儿介绍了。

及时性

及时性是指数据从发作到可以查看的时间间隔，也叫数据的延时时长。及时性关于数据分析本身要求并不高，但如果数据分析周期加上数据建立的时间过长，就可能导致分析得出的结论失去了学习意义。

做架构的四个思路

很多在一线做coding工作多年的程序员朋友好像对「架构」有着一股特殊的情感。

一方面是自己长期在一线的各种项目中coding，好像除了业务代码以外，「架构」就是体现在项目中用到的一些框架。而且每个项目里用到的框架好像还都差不多，都是spring、redis什么的。觉得做架构并不是什么难事。

另一方面是，看着身边的那些架构师们拿着比自己高得多的薪水，而且讲起架构背后的“所以然”来又头头是道，觉得「架构」又是一门看得到、近在眼前，但是自己又摸不着的能力。

如果你对架构感兴趣，希望未来能有机会做架构，那么请继续往下看。

Z哥我有幸做过5年的架构工作，其中4年是一线实操的主导者。所以来分享一些我在实战中“多么痛的领悟”后的经验，和大家交流交流。

首先，架构肯定不是简单的依样画葫芦，别人在用redis，我也用redis，别人在用Nacos，我也用。

会用一个工具其实并不难。如果只是会用的话，这背后最直接的一个问题就是，你没有自己的思考过程，比如：

• 为什么用这个工具来作为你架构设计的一部分？

• 它是否是满足必要条件下的最优解？

• ……

架构思维的核心其实就是这个思考的过程，架构设计的本质是思考后的结果，具体的工具、技术只是这个结果的一部分而已。

如果你没有掌握合理的架构思维，其实让你做好几年架构工作也没什么太大意义。因为工具再好，也不代表你能造出好房子。

根据我这些年的经验，我在做架构的过程中，提炼出了四个思路。我平时就是通过这些思路来指导我的思考方向的，如果你也有什么好的思路，欢迎留言与我和大家一起分享。

/01  架构是不断演进的/

不要老想着一步到位，哪怕不考虑成本问题，也是不可能一步到位的，除非你能预料到眼前这个项目在未来的发展周期，直至其死亡。很显然，这是不可能的。（有这个能力用来炒股不香么～）

在我看来，一个系统架构要具备良好的演进能力，需要做到两点。

第一点，就是本身设计上的「可扩展性」。这个词看起来很抽象，其实落地的时候你只要记住一句话：“链接”处的设计决定扩展性。

而一般来说，我们软件里涉及到“链接”的地方主要就2个。一个是外部链接（系统与系统之间），一个是内部链接（系统内的模块与模块之间）。前者主要是通过网络来进行连接，所以通信协议的选择上需要尽可能的普适、通用，这样才能更有利于后续的迭代演进。而后者主要是代码层面的链接，在这类链接点上尽可能的使用Interface而不是具体的Class。

除了必要的提高扩展性的工作之外，特别重要却又容易被忽略的一点就是「可观测性」。

只有当一个架构的关键指标可以被观测，你才能更好的把控演进的方向，而不是拍脑袋决定。并且在每一次迭代完成后，通过观测系统可以判断这次迭代的效果是否符合预期。

常见的属于“观测系统”的工作是，单元测试、自动化测试、监控系统、代码检测工具等等。

/02 「分」是为了更好的治理/

在分布式系统中，涉及到「分」的概念有很多，「横向拆分」、「纵向拆分」、「一主多从」、「双主多从」、「多主多从」。每一种概念你都能在网上轻易地搜到解释。

但是所谓的「分治」不是简单的将系统随便拆分一下，还要考虑拆分之后的治理成本。所以，你得明白当前面临的问题特点是什么，基于这个特点去选择合适的拆分方案，而不是上来就怼一个多主多从，最好的方案不一定最适合你。

治理成本中除了直接的维护成本外，还有一个容易被忽略的隐性成本就是「合」的成本。

一个大系统内的任何数据、子系统都不是孤立存在的，否则他们就没有存在的价值。因此，耦合或多或少都存在。所以，在「分」的时候同时要考虑好有哪些「合」的场景，针对这些场景做好预案。最常见的应对方案是，多冗余一份数据，确保最终一致性即可。

我之前接触过的一个典型的反面案例是，两个子系统在架构上是自治的，但是他们之间的耦合也不少，两个系统中大量充斥着调用另一个子系统的Rpc请求，然后在自己系统内进行数据合并，并返回给上游。在这样的架构设计之下，这两个子系统成了“命运共同体”，基本上一边出问题，另一边也会出问题。

所以，「分治」不仅有「分」还要考虑「治」。

/03  让系统不宕机/

让系统不宕机是做架构要全力坚守的底线。如果说做架构是设计高楼大厦的话，那么再高大上的高楼，如果坍塌了啥也不是。所以，一定把底线守住。

/04  用领域思维建模/

每位程序员都知道什么叫「面向对象」。但是很多人的开发方式其实是“伪面向对象”的，为什么这么说呢？因为面向对象最重要的工作是建模，而他们却是在建数据表，然后用大量面向过程的代码编写软件。

随着最近几年的DDD大火，领域思维逐渐被大家所了解，它就是一个可以非常棒地指导我们建模的思路。不但可以指导宏观层面的模块划分，还可以指导具体的Class设计。为什么这么说呢？因为领域思维强调的是，将业务含义充分体现在模型中，建立所谓的「充血模型」。所以通过领域思维做的建模不单单有数据属性，还有业务模型的行为以及约束等，任何具有业务含义的概念都要在代码中体现。如此一来，架构工作中的「分」的部分基本上直接给搞定了。剩下主要考虑「合」的问题以及具体的技术选型就好了。

DDD的具体应用就不展开说了，内容太多，能写一个系列文章。当然也没必要写，因为这事已经有人做得很棒了，直接看Vaughn Vernon的《实现领域驱动设计》就好。不管你是初学DDD还是想熟练运用DDD，看这本书都是最适合的，没有之一。如果你想进一步深入DDD背后的思想原理，那么可以读一下Eric Evans的《领域驱动设计——软件核心复杂性应对之道》。好了，总结一下分别是，

1. 架构是不断演进的

2. 「分」是为了更好的治理

3. 让系统不宕机

4. 用领域思维建模

不敢说这几个思路一定能帮助你设计出多么牛逼的架构，但至少应该是合格的。希望对你有所帮助。掌握了合理的思路后，做架构这件，看起来简单，做起来也简单。