数据治理方案

1. 为什么要做数据治理

​ 随着移动互联网的兴起，线下商业活动逐渐开始向线上化发展，数据的产生速度有了极大的提升。越来越多的公司开始认识到数据的重要性，并将其打造成为公司的核心资产，从而驱动业务的发展。在数据相关的领域中，“数据治理”这个话题近两年尤为火热，很多公司特别是大型互联网公司都在做一些数据治理的规划和动作。

​ 为什么要做数据治理？因为在数据产生、采集、加工、存储、应用到销毁的全过程中，每个环节都可能会引入各种质量、效率或安全相关的问题。在公司早期的发展阶段，这些数据问题对公司发展的影响并不是很大，公司对问题的容忍度相对也比较高。但是，随着业务的发展，公司在利用数据资产创造价值的同时，对数据质量和稳定性要求也有所提升。此外，当数据积累得越来越多，公司对数据精细化运营程度的要求也随之提高，会逐渐发现有很多问题需要治理。

​ 同时，在数据开发的过程中也会不断引入一些问题，而数据治理就是要不断消除引入的这些问题，保障数据准确、全面和完整，为业务创造价值，同时严格管理数据的权限，避免数据泄露带来的业务风险。因此，数据治理是数字时代很多公司一项非常重要的核心能力

2. 需要治理哪些问题

​ 数据治理是一项需要长期被关注的复杂工程，这项工程通过建立一个满足企业需求的数据决策体系，在数据资产管理过程中行使权力、管控和决策等活动，并涉及到组织、流程、管理制度和技术体系等多个方面。一般而言，数据治理的治理内容主要包括下面几个部分：

• 质量问题：这是最重要的问题，很多公司的数据部门启动数据治理的大背景就是数据质量存在问题，比如数仓的及时性、准确性、规范性，以及数据应用指标的逻辑一致性问题等。
• 成本问题：互联网行业数据膨胀速度非常快，大型互联网公司在大数据基础设施上的成本投入占比非常高，而且随着数据量的增加，成本也将继续攀升。
• 效率问题：在数据开发和数据管理过程中都会遇到一些影响效率的问题，很多时候是靠“盲目”地堆人力在做。
• 安全问题：业务部门特别关注用户数据，一旦泄露，对业务的影响非常之大，甚至能左右整个业务的生死。
• 标准问题：当公司业务部门比较多的时候，各业务部门、开发团队的数据标准不一致，数据打通和整合过程中都会出现很多问题。

3.目前数据现状

1. 建立数据开发全链路的标准规范，提高数据质量，通过系统化手段管理指标口径，保障数据一致性。
2. 控制大数据成本，避免大数据机器成本膨胀对业务营收带来的影响，合理控制数据的生命周期，避免数据重复建设，减少数据冗余，及时归档和清理冷数据。
3. 管理数据的使用安全，建立完善的数据安全审批流程和使用规范，确保数据被合理地使用，避免因用户数据泄露带来的安全风险和商业损失。
4. 提高数据工程师的开发和运维效率，减少他们数据运营时间的投入，提高数据运营的自动化和系统化程度

4.怎么做数据治理

4.1 数据治理策略

​ 数据治理方案需要覆盖数据生命周期的全链路，我们把数据治理的内容划分为几大部分：组织、标准规范、技术、衡量指标。整体数据治理的实现路径是以标准化的规范和组织保障为前提，通过做技术体系整体保证数据治理策略的实现。同时，搭建数据治理的衡量体系，随时观测和监控数据治理的效果，保障数据治理长期向好的方向发展。

4.2 标准化和组织保障

我们要制定一个全链路的数据标准，从数据采集、数仓开发、指标管理到数据生命周期管理，全链路建立标准，在标准化建立过程中要组建业务部门，信息部门及高层领导组成的的数据治理管理委员会。

4.2.1 标准化

数据标准化包括三个方面：一是标准制定；二是标准执行；三是在标准制定和执行过程中的组织保障，比如怎么让标准能在数据技术部门、业务部门和相关商业分析部门达成统一。

从标准制定上，我们要制定一套覆盖数据生产到使用全链路的数据标准方法，从数据采集、数仓开发、指标管理到数据生命周期管理都建立了相应环节的标准化的研发规范，数据从接入到消亡整个生命周期全部实现了标准化。

4.2.2 组织保障

根据目前蜀海数据管理分散的现状，需要专门建立一个联合业务部门和技术部门中与数据最相关的团队成立了数据治理管理委员会，再通过委员会去推动相关各方去协同数据治理的相关工作。

数据管理委员会：负责数据治理策略、目标、流程和标准的制定，并推动所有相关团队达成认知一致。

业务数据产品组：负责数据标准、需求对接流程、指标统一管理、数据安全控制以及业务方各部门的协调推动工作。

技术数据开发组：负责数据仓库、数据产品、数据质量、数据安全和数据工具的技术实现，以及技术团队各个部门的协调推动工作。

5.技术系统

数据治理涉及的范围非常广，需要协作的团队也很多，除了需要通过组织和流程来保障治理行动正常开展，我们需要考虑通过技术系统化和自动化的方式进一步提效，让系统代替人工。下面我们将从数据质量、数据成本、数据安全和运营效率等几个方向，来逐一介绍技术实现方案。

3.1 数据质量

数据质量是影响数据价值最重要的因素，高质量的数据给带来准确的数据分析，错误的数据会把业务引导到错误的方向。数据质量涉及范围较广，在数据链路的每一个环节都有可能出现数据质量问题，业务现阶段的主要质量问题包括：

• 数仓规范性差，数仓架构无统一的强制规范执行约束，数仓历史冗余数据严重。
• 应用层数据属于“烟囱式”建设，指标在多个任务中生产，无法保证数据的一致性。
• 数据下游应用的数据使用无法把控，数据准确较差，接口稳定性无法得到保障。
• 业务方对多个数据产品的指标逻辑无统一的定义，各个产品中数据不能直接对标。

数据组的治理数据质量方案覆盖了数据生命周期的各个环节，下面将介绍一下整体的技术架构。

• 统一数仓规范建模（One Model）：通过统一数仓规范建模系统化保障数仓规范执行，做到业务数仓规范标准化，并及时监控和删除重复和过期的数据。
• 统一指标逻辑管理（One Logic）：通过业务内统一的指标定义和使用，并系统化管理指标逻辑，数据应用层的数据指标逻辑都从指标管理系统中获取，保障所有产品中的指标逻辑一致。
• 统一数据服务（One Service）：通过建设统一的数据服务接口层，解耦数据逻辑和接口服务，当数据逻辑发生变化后不影响接口数据准确性，同时监控接口的调用，掌握数据的使用情况。
• 统一用户产品入口（One Portal）：分用户整合数据产品入口，使同一场景下数据逻辑和使用方式相同，用户没有数据不一致的困惑。

5.1 统一数仓规范建模（One Model）

​ 数仓管理方面主要解决以下几个问题：

• 数据规范性较差，不同时间的数仓规范不同，数仓规范的执行审核需要较多的人力。
• 数据不一致问题多，同一指标在多个ETL中生产，数据更新同步也不及时。
• 历史数据冗余严重，数据存储方式较多，业务方查询不知道该用哪个数据。

数据团队主要通过数仓规范化制定、数仓分层架构和数仓规范化系统来解决上述问题，下面是我们的具体解决方案

5.1.1 制定标准-数仓规范

做好数仓规范化最基本的前提是要制定一系列标准化的规范，并推动组内同学执行。标准化的适用性、全面性和可执行性直接影响到规范的执行效果。数仓规范主要从3个方面制定数据标准化：

• 数仓建模规范，数仓建设最基础的规范，包括分层、命名、码值、指标定义、分层依赖等维度。
• 主数据管理规范，数仓各个主题的数据只有一份，团队共建复用，不能重复开发。
• 数据使用规范，在查询数据时优先查询主题层，不再提供明细层和ODS层的查询访问入口。

5.1.2 工具保障-数仓规范化开发系统

在执行数据规范化的过程中，我们发现团队中每个人对规范的理解不一致，很可能造成数据规范不统一，审核人在审核上线任务时需要考虑规范的全部规则，审批需要投入的人力较多。在这样的流程下，数据规范性无法从根源上进行控制，因此需要建设数据规范化的工具，通过系统保障规范的一致性。我们需要设计开发数仓规范化开发工具，改工具主要包括3个功能模块：标准化规范、配置化开发和规则化验证。

标准化规范：制定业务数据仓库的标准规范并配置在系统中，包括架构分层、字段管理、词根管理、公共维度和码值管理等，在ETL开发时通过统一的数仓规范开发，通过配置化实现数仓的命名、分层和码值，保障数仓长期的规范性

配置化开发：系统化保障工程师在开发ETL过程中遵守数仓规范，数仓规范化工具可以用配置化的方式生成数据加工任务模板，模板中包含数据模型的基础信息，研发同学只需要在任务模板中开发数据生产逻辑。

规则化验证：跟进数据仓库底层元数据和标准化配置信息，定期扫描数仓的规范性情况，判断出不符合数仓规范的任务和高相似度的数据表。

5.2 统一指标逻辑管理

业务使用数据的第一步是搭建业务指标体系，业务的目标和策略的执行情况需要通过指标来分析，指标体系的合理性和指标数据的质量直接影响到业务决策，指标的重要性不言而喻。我们通过系统化地管理数据指标，从根源上解决指标口径一致性问题，主要从以下3个方向入手：

• 指标定义规范化
• 指标管理系统化
• 数据查询智能化

目前数据指标开发存在的问题及指标体系构建：

我们现在数据指标管理一期已经上线，可以将系统使用起来

5.2.1 指标定义规范化

此处主要从指标的生成和管理上做好规范，确保业务同学和研发人员对指标体系管理的认知一致，确保指标的新建、更改和使用都按照规范执行。我们通过下面2个方向来实现指标定义的规范统一。

• 业务指标体系的规范化：我们在业务线内统一了指标体系规范，指标分为原子指标、计算指标和复合指标，通过使用这3类指标支持业务的数据分析需求，业务未来新增指标也要按照这个标准分类。
• 指标的管理规范化：我们与商业分析团队一起梳理业务指标逻辑标准和录入流程，通过制定指标的新增和变更规范，解决由指标管理流程引起的质量问题，使得指标定义、系统录入、指标认证和使用各个环节都有严格的流程管控，经由业务侧数据产品经理、业务侧数据治数据管理员和数据工程师共同审批，确保标准规范的落地执行。

5.2.2 指标管理系统化

物理数据表管理：数据表管理的信息主要包括表的基础元数据信息、表类型（维表或事实表）、表的推荐度、描述信息和样例数据等。数据表管理主要是面向数据开发同学，通过维护数据表信息，为数据模型和指标管理提供数据基础支持。

数据模型管理：是对物理数据表的模型构建，通过一个物理模型可以查询到指标和相关的维度数据。数据模型可以是星型模型或宽表，星型模型中维护多个数据表的关联方式、关联字段、维度表包含字段和模型的ER图等信息。

指标管理：主要包括2部分的内容，指标的业务信息和技术信息。

• 业务信息：为了保障业务的指标信息准确且统一，指标的业务信息需要数据产品经理与商业分析团队讨论确定后录入，录入后需要指标所属数据主题的负责人审批后才能上线。
• 技术信息：技术信息主要包括指标对应的物理模型以及指标的计算逻辑，技术信息的填写需要数据工程师配置。技术信息配置后会在系统里生成技术元数据，指标管理系统通过技术元数据生成数据查询语句，提供给下游应用。

5.2.3 指标查询智能化

在指标管理系统中创建指标时，我们要系统化管理指标与数仓物理模型的关联关系和取数逻辑，通过数据物理模型获得指标对应的字段和可以关联的维度，以此把指标解析为数据查询SQL语句，通过数据查询引擎执行生产的SQL，智能化获得指标数据。

5.2.4 数据指标开发流程

​ 数据指标的开发要严格按照流程进行，下面是我参考行业及我们实际现状，初步制定的一个流程，供参考。

5.3 统一数据服务（One Service)

数据仓库对外提供数据的需求越来越多，除了管理层、分析师和产品运营同学使用数据产品和报表外，数据还需要提供到各个业务系统中使用。常用的提供数据的方式主要包括同步数据表、提供SQL和为下游服务开发定制化API接口等方式，但存在以下几个方面的问题：

• 数据一致性无法保障，当数据指标逻辑更改时，业务系统不能及时调整，导致不同业务系统的数据不一致。
• 数据同步到业务系统后，我们就无法管控数据的使用方式，也不能监控到数据是否被其他下游使用的情况。
• 数据开发效率比较低，数据服务稳定性比较差，数据工程师开发一个定制化API接口需要几天时间，各个接口服务单独维护，服务稳定性也比较差。

设计开发统一数据API服务平台，通过开发可配置的数据接口服务平台实现数据对外的灵活提供，并实现对数据服务的下游使用及性能的可监控。统一的数据服务平台解决了几个比较关键的问题：

• 数据逻辑统一收口：数据服务接口和数据逻辑解耦，当数仓更改和数据指标逻辑变更后下游无感知。
• 数据服务的更好管控：研发同学能够了解到数据被哪些下游使用、调用了多少次和数据服务是否稳定等信息。
• 开发效率大幅提升，服务稳定性大幅提高：通过统一服务平台可以在1小时内完成一个接口的配置化开发，与此同时，接口稳定性统一运维，服务稳定性有了很好的保障。

5.4 数据成本

大数据的主要成本构成有3大部分，计算资源、存储资源和日志采集资源，其中计算资源和存储占总成本超过90%，我们的数据成本治理主要是针对大数据计算和存储这两个部分。

大数据成本优化方案

• 计算资源
  • 无效任务清理，通过任务生产出来数据的使用情况判断是否为无效任务，通过下线无效任务，减少任务执行使用的计算资源。
  • 超长任务优化，经过任务的计算资源使用数据可以发现，某几个大任务在执行时会占用大部分的计算资源，导致其他任务执行时间变长，或者占用配置外的弹性计算资源，导致计算成本增加。数据组会统计和监控每天任务的执行情况，发现执行时间长（超过2个小时）或者占用资源多的任务会及时进行优化。
  • 分散利用计算资源，数仓的夜间批处理任务使用计算资源的实际一般都集中在早晨2点到上午10点前，这就导致在一天中只有三分之一的资源被充分利用，而且这段时间内通常资源都是不够用的，需要使用平台提供的配置外弹性资源。而其他时间段的计算资源闲置，对资源有较大的浪费。为了把全天的资源都有效地利用起来，我们会把一些对就绪时间不敏感的任务（比如算法挖掘、用户标签、数据回刷等）放到10点之后，把配置的计算资源充分利用起来。
  • 租户拆分和整合统一管理，提高资源池总量和资源总体的使用率。
• 存储资源
  • 数仓架构优化和重构：通过统一数仓建模规范，把相似或相同模型进行整合和去重，确保每个主题数据只保留一份。
  • 数据存储压缩：在数据仓库建设初期，很多Hive表的存储格式是txt，通过压缩为ORC格式可以减少大量的存储空间。
  • 冷数据处理：把数据分为冷、热两大类数据，通过每天对全部数仓表扫描识别出冷数据，发给数据负责人及时处理。
  • 数据生命周期控制：按照数仓分层的应用场景配置数据的生命周期，明细数仓层保留的全部历史数据，主题层保留5年数据，应用层保留1～3年数据。通过数据生命周期控制，极大地减少了数据存储成本。
• 日志采集资源
  • 下线冷数据的上游日志数据收集任务，数据收集费用主要来自两类数据，业务系统数据库的Log同步和后台日志数据收集，通过对收集数据的使用情况监控，及时下线下游无应用的数据收集任务。

5.5 数据安全

数据资产对业务来说既是价值，也是风险。数据安全作为业务部门“事关生死”的核心工作，在技术架构上会从数据产生到数据应用各个环节进行控制，保障数据应用事前有控制、事中有监控和事后有审计。数据安全控制从业务系统开始对用户高敏感数据加密，在数仓进行分级和脱敏，在应用层做密文数据权限和密钥权限的双重保障，管控用户相关的高敏感数据，按照三层系统控制加五个使用原则实现如下：

6.衡量指标

业务部门在业务发展初级就会建立指标体系，并使用数据指标对各个业务过程做精细化的分析，衡量业务目标的达成情况和行动的执行程度。数据治理也需要一套成熟稳定的衡量指标体系，对数据体系做到长期、稳定和可量化的衡量。我们通过制定体系化的数据衡量指标体系，来及时监测数据治理过程中哪些部分做的好，哪些部分还有问题。

4.1 衡量指标建设

为了能够不重不漏地把指标都建立起来，我们从2个方面进行考虑：

• 技术分类，按照数据团队关注的问题和目标，把数据治理的指标体系分成质量、成本、安全、易用性和效率这5大类。
• 数据流环节，分别从数据的采集、生产、存储、指标管理、应用和销毁等环节监控关注的指标。

4.2 衡量指标保障数据治理

根据PDCA（即是计划(Plan)、实施(Do)、检查(Check)、行动(Action)）原则，将数据治理作为日常的运营项目做起来，底层依赖数据指标体系进行监控，之上从发现问题到提出优化方案，然后跟进处理，再到日常监控，构成一个完整的循环。