这是新欣小驿的第 20 篇文章
数据开发的一部分工作是围绕数据仓库完成数据集成、数据加工、数据应用等数据清洗加工处理。而数据治理,贯穿数据开发整个生命周期。做好数据开发,也必须关注数据治理任务,数据治理效果好了,才能保证数据开发的高质量数据,才能有效支撑业务。
因此,数据治理的一个主要目标是,提高数据质量。而这一过程,包括发现数据质量问题、定量数据质量评价指标、制定数据质量提升计划、开发数据质量监控任务、推广数据质量治理工作落地和运维全生命周期。
本文对数据治理庞大知识体系的核心要素做基本整理,包括数据治理的基本定义、数据治理的思想共识、元数据、数据标准等。同时以数据开发的视角,结合实际开发经验,总结开发过程中应关注哪些数据质量问题,及为提高数据质量可以做哪些数据治理工作。
数据治理不是一个轻松的工作,相反,它是一个长久持续性的工作。既然实施数据治理的成本不低,那数据治理成果带来的价值究竟有多高,值得去做这样一个工作呢?
带着这个问题,我们继续往下看。
首先我们明确一下数据治理的定义。在Google Cloud中,给出的定义是:
数据治理(Data Governance)是指为确保数据安全、私有、准确、可用和易用所执行的所有操作。它包括人们必须采取的行动、必须遵循的流程以及在整个数据生命周期中为其提供支持的技术。
由此可见,数据治理的目的是保证数据安全、私有、准确、可用、易用。也就是,数据治理能为数据使用监管、数据应用质量、及数据资产管理提供保证。
如前所述,数据治理是一个长久的工作,数据治理实施之前必须先达成一些思想共识,对一些关键问题得先思考,明确。
以下是罗列的一些数据治理思想共识:
数据治理不是个人的责任,需要组织和制度流程来管理。
数据治理围绕企业或组织已有的数据资源展开,具体实施工作前,必须盘点清楚已有数据资产。
数据治理不只是技术人员的职责,更需要业务人员牵头推动。
数据治理不是求大求全,需要抓住核心业务核心问题。
数据治理工作成果不易体现,应让管理者对数据问题、治理成效可感知。
数据治理需要建立发现问题、修正问题、避免问题、追究问题的周期闭环,完善治理推广和运维工作。
基于以上对数据治理的初步认识,我们可以进一步深入了解数据治理实施过程中2个重要的要素:元数据和数据标准。
元数据(Meta-data)是描述数据的数据。一般分为业务元数据、技术元数据、管理元数据。举个例子,统计指标对指标口径的文字描述定义就是业务元数据,用SQL 语句实现指标计算的语句就是技术元数据,对指标的状态、负责人、开放状态就是管理元数据。
为什么元数据对于数据治理十分重要?
前文说过,数据治理的基础是摸清数据家底,知道已经有哪些数据资源。这就需要元数据来实现。元数据是发现数据问题、管理数据资产的基础。元数据可以来自数据生产、数据接入、数据加工、数据应用的各个环节。
以一个离线数据仓库为例,可采集并管理的元数据包括数据仓库已接入数源信息、已建设表资源、已开发任务资源、任务之间的血缘依赖、任务的运行实例信息等基础元数据信息。此外,对于数仓支撑的指标体系,指标定义业务口径、指标编码、指标所属业务模块、指标开发责任人、指标状态等也涵盖众多元数据信息。
元数据可以涵盖字段可以很多,如何确定数据治理需要的必要字段信息,可以根据数据治理的目标、策略、度量(OSM模型)来确定。对于元数据信息的采集管理,可以基于相关工具也可借助爬虫技术实现。
基于元数据,可以搭建一套数仓的数据资产地图,涵盖存储使用分布、表数目、各主题表数目、表数据量、表之间血缘关系、指标所在表名、及各种指标在时间维度下的变化趋势。有了这份“数据地图”,查找数据、分析数据变化趋势就非常清晰了。
同样,元数据信息也能助力数据质量提升。可以是主键唯一性校验、数据波动率监控、字段空值率分析、异常代码值发现、及数据产出及时性分析等。
为了体现数据血缘对数据治理的价值,可以通过搭建可视化分析平台或工具,如BI 工具,将一些核心数据治理的指标可视化,体现治理行动和治理效果。
(图片来自pxhere)
数据标准(Data Standard)是指保障数据定义和使用的一致性、准确性和完整性的规范性约束。
数据标准是一种对业务数据化的规范性约束,目的是保障数据使用一致性、保障数据准确性。
对于一张数据库表,数据标准定义字段命名规则、字段类型、字段长度、字段格式、枚举值。对一个数据仓库,数据标准可以涵盖分层理论、表命名规则、数据开发规范等。标准的核心目的,是保证数据一致性,从来源、使用、理解、管理,让数据使用成本更低、使用更有效。
通常,数据不一致或脏数据产生的原因是,数据来源多个系统而彼此有不同的定义规则,或者数据加工过程没有统一规范使得运维成本提高,或者数据定义存在歧义使得每个人理解存在偏差。
数据标准制定流程一般是,标准规划、标准编制、标准评审发布、标准落地执行、标准维护。
并非所有数据都需要建立标准,通常只对核心数据定义标准,如高频使用、业务关键字段、数据应用有使用需求的字段。一旦标准发布,对标准实施落地也需考量系统实际情况,对一些历史任务按标准实施是否影响面过大,代价过高。
标准的落地实施,是为了保证未来新进入的数据有较高的数据质量,对历史数据做到尽可能加工清洗、对当前数据采取评估方法、依据,定位问题再修正问题。
基于自己2年多的数据开发经验,一般完成一个项目所需数据,需要完成几个步骤,包括业务调研、数据调研、数据建模、数据清洗加工、应用服务支撑、数据质量校验、任务运维及使用反馈和迭代。对于每个步骤,基本都需要了解业务、分析数据,关注数据质量,最后才能真正实现数据业务化。
一个项目从需求评审开始,产品介绍待建设应用功能点,数据方确定业务数据可行性,前后端分析功能模块实现可行性。项目就此开始,但评审只是初步认识,还无法真正感受到需求实现的难易程度。
作为数据开发人员,不怕表数目多,就担心表关联关系复杂,难以梳理清楚业务关系。当某个业务功能涉及多个业务流程、各业务流程间关系也并非一一对应,而是一对多甚至多对多,那么数据清洗难度相对较大、数据量级也相应膨胀,同样的验证数据质量难度也增加。
面对业务关系复杂的数据需求开发,有没有行之可效的方法呢?
(图片来自pxhere)
有一些核心的原则可以参照,能尽量避免较大数据质量问题发生。
回归业务,借助图形将业务流程可视化。
以支撑业务功能实现为目标,梳理清楚开发流程,保证效率。
核心业务加工逻辑同产品多沟通、仔细确认。
借助数据质量校验脚本、工具辅助验证数据质量。
确定哪些数据问题是加工过程产生、哪些是因为数源如此。
一般,从梳理原型图各模块数据需求开始,定义目标表结构(主键、字段、表之间关联字段)。再基于此,确定有无可直接复用的模型表,若无,需基于维度建模完成基础表,若有,则可在确定所有字段后,根据业务要求完成标签加工、指标计算、必要业务字段需求。
对于一些复杂的标签,涉及多个业务过程,需同产品一起确认加工逻辑,避免后续验收返工。基本数据清洗、加工完成后,对业务主键定义、唯一性及核心业务字段空值率需要再次验证,避免因重复数据导致数据膨胀、或取错数据、或过高空值率影响功能查询。
当确定任务最终版本后,还需关注每日产生数据量级,是否需增量更新,及数据产出及时性,是否会影响最新值查询。可借助数据开发平台的数据质量功能,配置质量校验规则,避免因重大数据质量问题影响功能使用。当功能发布上线后,用户使用后的一些问题点的记录,及后续评估能否进一步优化。至此,才算是从业务数据化、数据业务化的一个完整闭环。
数据开发岗位的职责是,辅助业务人员让业务数据化,实现数据业务化。一切工作都是为了服务业务,提高业务增长。因此,作为数据开发人员,应当对数据敏感,应用技术和经验,保障数据质量,提供安全、准确、易用的数据,这也是数据治理的目标。
联系客服