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