拿什么拯救你，数据质量？

一

为什么谈数据质量？

随着4G LTE技术的深度应用及移动互联网的不断发展，用户对移动网络的依赖度越来越高，同时对网络质量和性能的要求也越来越高，对于网管系统要求更全面分析用户感知、更深层次挖掘网络隐患、更实时发现故障和质量下降、更准确预测用户投诉行为、更快速解决故障和质量问题。而强大的网管系统从移动网络设备中采集和提取与业务相关的各类数据，从而提供各种IT应用及数据支撑。

统一采集平台在OSS 2.0首次提出，将各专业网中的NE/EMC/EMS作为一个大的设备资源池，采集的数据由统一采集平台提供，避免了多应用系统重复采集、数据孤岛等情况存在，各应用系统不再分散采集网管数据。统一采集平台则是网管数据的唯一来源，其数据质量直接影响到上层各应用系统的数据分析和监控运维等功能。

二

什么是数据质量？

数据质量通常可在以下几个方面衡量和评价：

准确性：数据在系统中的值与真实值相比的符合情况，数据应符合业务规则和统计口径。常见数据准确性问题如：

1.与实际情况不符：数据来源存在错误，难以通过规范进行判断与约束；

2. 与业务规范不符：在数据的采集、使用、管理、维护过程中，业务规范缺乏或执行不力，导致数据缺乏准确性。

完整性：数据的完备程度。常见数据完整性问题如：

1. 系统已设定字段，但在实际业务操作中并未完整采集该字段数据，导致数据缺失或不完整；或者设备漏采、采集延时都会造成完整性异常。

2. 系统未设定字段：存在数据需求，但未在系统中设定对应的取数字段。

一致性：系统内外部数据源之间的数据一致程度，数据是否遵循了统一的规范，数据集合是否保持了统一的格式。

及时性：数据在采集、传送、处理等环节快速支持应用的程度，考察数据的时间特性对应用的满足程度，是否按照规定的数据更新时间要求对数据进行更新等。及时性关系到系统能否在规定的时间内获取到系统需要的特定时间产生的数据，以完成系统功能。

可用性：用来衡量数据项整合和应用的可用程度。常见可用性问题如：

1. 缺乏应用功能，没有相关的数据处理、加工规则或数据模型的应用功能，不易获取目标数据；

2. 缺乏整合共享，数据分散，不易有效整合和共享。统一采集平台的数据质量问题集中在“完整 性、及时性”，从上层应用反馈的问题如缺数问题、告警丢数问题，都反映出采集过程出现采集缺失、采集不完整或者延时等情况。

三

数据质量问题在什么情况下出现？

为了研究数据质量问题，我们对统一采集平台进行了深度访谈和调研，从数据采集、处理、传送流程，以及日常运维、故障分析经验等各个维度进行了全方位调研和分析。

统一采集平台实际按照专业网分为两套系统---统一采集平台（数据网）和统一采集平台（话音网）。两套系统的技术架构、业务流程都截然不同。

统一采集平台采集数据包括告警数据、性能数据、资源数据，由于数据类型的特性，采集流程也对应有所不同。其中告警数据的采集分为实时采集和定时同步，而性能数据和资源数据只有定时采集。

告警数据的实时采集，A厂商采用与OMC设备socket长连接的方式接收告警数据，B厂商通过SNMP TRAP协议主动通知告警数据。无论采用哪种方式，缺数问题主要集中在设备侧和采集侧的通讯环节，设备侧和采集侧之间的通讯受网络环境影响较大，告警数据的丢失很难完全避免，也难以被发现。

资源数据和性能数据的定时同步，A厂商的数据要经过OMC设备、同步机、采集机、管理机、入库机、数据库等一系列设备的处理，期间要进行同步、采集、解析、计算、入库、汇总等一系列数据处理操作。而B厂商的数据要经过采集适配器、文件服务器、处理适配器、数据库等，期间也要进行采集、解析、计算、入库等一系列数据处理操作。尽管A厂商和B厂商的操作略有不同，但可以发现两者的流程链长，处理过程复杂，缺数问题可能发生在整个链条中的每一环，导致定位具体缺数环节显得十分困难。

四

数据质量问题可以被发现吗？

统一采集平台的运维人员在分析故障原因时，一方面会利用平台的自监控功能去分析可能存在的原因，另一方面是借助日志来确定判断故障发生的原因。整个运维过程十分依赖于运维人员的经验，看哪份日志、看日志的先后顺序、日志看什么内容、哪些是关键内容，如何关联考虑，处理故障的速度取决于运维人员的熟练程度和经验丰富程度。从这里，可以看到日志是一个有效的突破口，因此我们思考是否可以对运维人员的日志分析过程进行提炼，从而设计一个可以替代人力去发现问题、定位问题的方法。在找到牵一发而动全身的妙招之前，我们先拿到了两个厂商的日志。

首先，观察A厂商的日志，每份日志的信息量都很大，基本将能记录的内容都记录下来了，事无巨细，信息齐全，但重要信息也淹没其中；不同日志的格式不统一，日志的内容也大多流水帐；将所有日志放到一起分析，自然难以进行全局关联分析。

观察B厂商的日志，单一日志的信息量明显比A厂商少很多，只对每个步骤的结果进行记录，减少很多非必要信息的日志输出；日志格式也比较规范，便于解析处理；但其暴露一个非常大的问题，输出过于强化设计，类似数据库表索引的思路，日志中大量使用ID信息，无法直接从日志上读懂具体的含义，需要再通过数据库去各种查询映射，对运维人员来说是非常不方便。

综合来说，无论是A还是B厂商的日志，当前的日志仅能看到单一环节的日志信息，日志没有集中化处理，不能将不同的日志关联起来一起分析，无法看到整个过程的全貌。尽管采用了日志记录，但各种不足导致其作用非常有限。

五

拿什么拯救你，数据质量？

前面铺垫了这么多，大家自然都明白了我们拯救数据质量的秘密武器就是这么简单，唯有日志。

面对我们目前采集平台的众多特点，那是不是拿到日志，就可以一劳永逸地解决数据质量问题吗？事情往往不是那么简单：

1、首先，设备多样化、流程差异化、格式个性化，如何解决，难道要定制化解决吗？大家都会说要统一，那如何统一？

2、其次，采集平台发展已经很多年，成熟而复杂，接入的设备不计其数，环节众多，各种计算、各种指标浩如烟海，各种自监控手段也是不少，但一说到数据质量，人人都语重心长地说那是一个大坑。请问怎么跳坑才能出来？

3、最后，世界变化很快，网络规模日趋庞大，数据持续海量，各种IT技术火爆，大数据、人工智能技术的声音振聋发聩，那是不是采用这些IT技术就能披荆斩棘，一招定乾坤？

思考再思考，讨论再讨论，结合业务的调研，结合数据的理解，结合IT的经验，结合大家的建议，我们给出了最终的方案--端到端的统一日志。

“不以规矩，不成方圆”, 我们首先要做的就是统一。前后参与二十余人，历时两个多月，不统一目标，不统一思路，结果是可以预见的。此事需要大家一起使劲，共同思考。然后就是统一模型，日志模型唯有统一规范，才能发挥最大效能。本着求同存异的思路，历经艰辛，我们最终统一了采集日志的流程和环节，以及模型的字段等。

前面问到了如何出坑，开个玩笑，地球人都知道先系个绳子就好。是的，我想最开始建设采集平台时，日志数据是可以检索的，但随着规模增大，以前似乎连续的数据已经变得稀疏而离散。只有设计相应的绳索,才能将数据关联起来。所以，设计这个关联的Key非常重要，事实上我们花了大量时间去思考和论证。

尽管从事IT行业快二十年，我并不认为IT技术是解决数据质量问题的银弹。IT技术说到底主要是数据结构和算法，是需要慎重的思考和设计。对日志来说，数据结构即数据模型的设计，需要做到简单直接，减少不必要的开销，比如解析、传输等等。

归纳一下，日志需要体现以下几点：

1、首先，体现可读性。日志不必要还通过人的经验去数据库查来查去，要一眼就能读出问题什么时间发生、发生在哪里、发生了什么，这样机器处理同样也会高效；

2、其次，体现关联性。万物互联，数据的产生离不开当下所在的环境，主机、进程、软件模块为什么不能简单直接地扯上关系呢；

3、最后，体现业务性。日志数据不应该仅仅是用于数据质量问题定位分析这么一个场景，可以考虑更多的价值，日志的生成可以直接带上业务标签或信息。模型设计建议思考这部分内容，当然也是带来更多的挑战。

最后，经过这么多思考和资源投入，最终数据质量的日志长什么模样，还是那四个字：大道至简。统一日志的设计分为三部分:时间（Time）+来源（Source）+数据（Data），也就是我们常说的When+Where+What。

其中时间（Time）顾名思义就是打日志的时间；来源（Source）指信息来源，可以从不同维度考虑，大到主机，小到进程，包括主机名、IP地址、进程名等等，粒度根据不同环节而定；数据（Data）不求全但求精，要记录每个环节的关键信息和处理结果，通过唯一ID串联全流程。业务信息包括环节描述、操作描述、操作对象、操作结果、成功信息、失败信息等。

数据质量日志模型规范发布的那一天，大家都如释重负，我想这是一个新的开始，未来还有更多挑战。伙伴们，一起加油！

本期嘉宾

本期嘉宾 |王锐广东移动网管支撑领域技术架构专家，江湖人称五哥，Oracle OCM, 超过十五年的IT领域经验，曾浪迹知名外企，一直在求索，涉猎开发、架构、需求、运维、优化、管理等，目前爱好PaaS和AI等新技术挑战。

你可能还喜欢