永远在路上的数据质量管理

       13年入行大数据开始，从热点技术，到架构、再到技术体系、算法应用、线上产品运维，方方面面做了很多事情。经过几年的实战经验，对数据应用类系统“70%的精力在ETL”有了切身的体会：对任何期望通过数据指导或者数据驱动的业务而言，最重要的、最核心的竞争力还是数据质量。抛开准确性、完整性、一致性、实效性谈数据业务，无异于沙地起厦，一句空话。所以，数据质量管理应该是数据团队的核心工作，可以说其是生命线也不为过。

        管理是一件很细碎的活，管理要求流程化、规范化，对具有浪漫主义情怀的新派互联网工程师来说，确实不是一件有意思的事情，这里推荐一本工具书《数据质量征途》，其中有一段话做了非常切实的描述：

每一个组织都希望自己拥有高质量的数据，但是常常不知道如何实现这个目标。一类常见的做法是开发一个新系统来取代旧系统，然而常常会在实施之后立即后悔。这是因为公司实施此类方案时，总是重建一套全新的系统，却很少在第一时间考虑原系统存在困难的真正原因--数据质量问题。比如信息系统部门往往热衷于使用最新的技术，开发更流行或更常见的软、硬件解决方案，我们将这种方法称为系统驱动型解决方案。此时，公司采取的方案的真实目标退化为开发新系统，而非修正数据质量问题以提供高质量的数据。显然，这种舍本逐末的新系统非但不能解决原有问题，而且很有可能加剧数据质量问题。即使某个解决方案偶尔会有成效，通常真正造成问题的原因却更容易被掩盖或进一步隐藏。

        多数的数据从业者应该都会对这段话的产生共鸣。数据质量的管理问题，与软件质量、项目质量的管理本质一样，市面上无数的项目管理的理论和书籍，从来没有谁提出可用依靠技术升级来解决项目质量问题，或许技术能够提升项目管理的效率，但是一味追求技术无疑是舍本逐末。指导软件系统开发过程管理的方法论有CMMI、Scrum等，在数据质量管理领域，实际上近年来也已经有成体系的方法论了，比如同属CMMI Institute旗下的Data Management Maturity (DMM)， 以及国内官方正在推的《数据能力成熟度评价模型》，由中国电子技术标准化研究院牵头，拉了一些企业、银行在制定推广，倾向于敏捷的也有Linstedt和Inmon推的Data Vault，有兴趣的同学可以自行搜索研究。当然，所有这些理论、方法、模型都承认数据质量管理是一个过程，只要业务还在运转，数据质量相关的工作就必须要继续。

        对中小型公司，特别是互联网行业的团队而言，考虑到项目周期、成本、投资回报、人员流动等各种因素，要照搬上述的大部头理论并不实际。不过如果期望能够对数据质量进行管理并持续改进，工作的核心原则应该是一致的：

灌输持续管理的态度；建立数据应用业务模型，明确数据质量的指标，包括：准确性、完整性、全面性、一致性、实效性等等；通过工作不断优化上述指标；

        这里首先提到态度，有两层意思：

        1、需要在公司层面认识到数据质量管理很重要。实际上目前多数公司要明确认识到这一点并不容易，在进入大数据时代之前，数据只是多数公司的附属产物，数据分析更多的倾向于战略、政策等宏观层面，公司领导层对数据工作的印象更多的是一周或者一个月一次的周报、月报，这种情境下业务人员对指标浮动的容忍度比较高，因为“采样”、“概率”、“趋势”这些概念深入人心，人们会倾向于认可某些环节出问题会影响数据质量，只要处理得当并合理控制，就不会影响最终的统计结果和决策。大数据技术的推动，使得大部分公司全面使用数据构建BI系统成为现实，这时，数据应用业务就已经具体而微了，例如广告投放、进销存、ROI经营等都对数据的准确性、实效性要求极高，各级业务人员对数据变化的敏感度显著提高，显然数据质量管理的级别就必须要提升到相应的标准，仍然把数据当做附属产品会带来相当负面的影响。

       2、要有持续管理的认知。这里需要谈一下数据团队与业务系统研发团队在开发工作上的区别，传统的业务系统研发，是从产品经理手中拿到产品需求，在一个迭代周期内不倾向于更改需求，下一个版本的需求有它的排期和计划，这个套路已经玩的很深并且着实有效。但是数据团队的工作显然还没有实践出这样的工作模式，除了明确的数据产品需求外，数据团队更多的是需要承接随机分析、业务变化引起的不可预知的数据变化、数据源版本变化、人工填报错误排查，以及相应的数据修复等工作，也就是大名鼎鼎的“70%在ETL”原理。显然数据团队的很多工作是无法提前计划的（或者说绝大部分公司还无法提供这么大的财力去支持数据团队做所有数据源的需求管理、版本控制、测试），这样的特质使得数据质量管理更需要连续性，而非周期性。

        一言以蔽之，就是：“数据质量管理永远在路上”，只有认真的思考并且明确这样的态度，才能明确技术架构、组织结构、管理体系的设计原则，并持续改进。一些需要考虑的重要原则包括：

       1、任何数据质量问题，不能寄希望于“毕其功于一役”，而是应当换而考虑针对数据源和目标数据集建立起“监控、反馈、自助纠错”的自动化流程，并不断添加规则进行优化，以最小化人工排查修复的工作量为目标。

       2、数据团队的组织中，需要明确具有带“数据治理”职能的岗位，例如ETL工程师、数据仓库工程师等。对数据治理职能的工作考核，一定要考虑采用明确的数据质量优化目标作为KPI，否则容易导致工作过于发散无目标，沦为“分析师助理”、“数据系统管理员”。

       3、工作中需要面对无计划的持续变化，并且需求点细碎而不复杂。对小团队而言，在技术选型、系统架构、数据架构乃至库表设计等方面，需要重点考虑稳定和非稳定业务内容的分离，非稳定业务的实现方式应支持快速开发、易于修改。

       4、正视反复修正等枯燥工作带来的团队成员心态问题并做有效管理，实际如果认识到这个问题，解决并不困难。