转自：数据治理系列-实战篇：数仓治理要做什么 - 知乎 (zhihu.com)

过去两年，除了日常的数据开发工作，笔者也积极牵头参与了数据治理的相关工作。

治理内容主要集中在数据仓库领域，旨在提高数据质量、可用性和可维护性。

接下来我将基于这段时间的数仓治理经历，展开讲述下数仓治理的相关内容，如有错漏请大家多多指出。

数据治理与数仓治理的关系

首先是数据治理与数仓治理的关系。

相信看到这篇文章的读者，或多或少会了解一点数据治理的内容，如果不了解的话，可以到网上搜索下相关文章，因为不是本文重点，这里就不展开了。

简单来说，数据治理是一个广泛的概念，是一种组织级的管理方法，旨在确保数据的高质量、合规性、安全性和可用性，以满足组织的业务需求和目标。

而数据仓库治理是数据治理的一个特定领域，它通常在更大范围的数据治理框架内运作，专注于治理数据仓库，旨在确保数据仓库的数据是准确、一致、可靠的，同时也满足合规性要求和安全标准。

为什么要对数仓进行治理

数据仓库在现代企业中扮演着至关重要的角色，用于支持数据驱动的决策和业务运营。

然而，数据仓库往往会面临难以使用，数据质量不佳、数据不一致以及性能不佳等各种问题。

为了应对这一系列的挑战，所以我们要对数据仓库进行治理，确保数据在企业中得到有效管理和利用

如何进行数仓治理

按照笔者的经验，对于数仓治理可以分为4步去进行：

1. 明确治理内容：
   1. 以季度或者半年为一个周期，挑选出当前周期打算开展的治理项目
   2. 进行项目调研。包括当前的痛点、治理的价值，治理的涉及人员、工作量，大概计划，技术方案、预估时长等
   3. 开展项目立项会，完善治理细节，讨论得出完整的治理计划（可逐个项目进行，也可多个项目同时进行，具体看实际情况）
2. 对历史问题进行治理
   1. 根据治理计划，逐步开展治理工作
3. 完善流程规范和开发规范
   1. 通过工具约束或者完善流程规范，避免历史问题重复出现
4. 常态化监控和治理
   1. 数据治理是一个长期性、常态化的工作，在完善工具和规范的同时，也需要进行监控，并定期进行治理。
   2. 不同的治理监控周期不同，比如指标监控，可能需要每小时甚至更高频率，而数据生命周期管理则可以一周甚至一个月进行一次监控和治理。

说明：

1. 数仓治理涵盖数仓的各个方面，比如数据资产、数据血缘、数据质量、任务质量、数据生命周期等。每家公司的数据情况和痛点不一样，所以应该根据实际情况，针对痛点去优先治理，而不是死板的按照某本书或某篇文章的治理计划死板的进行。
2. 治理项目和平时的业务项目一样，都需要讲究ROI（投入产出比），所以前期周期不应该拉太长，治理项目也应该挑选那种能立竿见影解决当前痛点的项目。只有先做出成效，后面才能得到支持，去磕那些周期长，出价值慢的治理项目。
3. 治理是一个长期性、常态化的活动，所以将历史问题治理完成后，治理的终点应该落在完善规范以及构建监控上。只用通过工具或规范去约束，才能使治理工作常态化进行下去。

数据仓库治理项目内容

接下来笔者将大体讲一下数仓治理都需要做那些项目，可能存在遗漏或缺失，请大家多多指出。

后续有机会笔者会单独写文章，记录一下当初开展这些治理项目的细节以及治理过程中遇到的问题。

流程规范治理

治理背景：

数据治理是一个长期性、常态化的活动，需要通过工具或流程去保障，因此流程规范的治理，应该是在开展其他治理工作的过程中，同步进行，不断完善流程规范。

治理项目：（这里仅列举部分例子）

1. 需求阶段（产品经理）：产品经理在接到业务需求时，应力求获取并了解业务场景（背景）、目标和实现价值。细节方面：
   1. 围绕指标体系进行：类似的指标口径应尽量拉取，新增指标应提供充足的理由。拉齐口径的重要性不必多说，不仅有利于数仓进行模型优化与合并，提高指标的复用，降低维护成本和资源消耗，也方便后面的数据质量监控治理的开展。
   2. 调度定频：应根据实际使用频率对调度定频，切忌一股脑提供高频调度的数据（如一周只看一次的就没必要设置为小时微批）
2. 设计阶段（数据开发）：设计环节的流程规范是数仓治理的重要一环，主要包括表设计和调度设计
   1. 表设计是指依据需求设计目标产出表、中间产出表。包含表名、表名解释、字段名、字段类型、字段注释等。
   2. 调度设计主要包括依赖设计，运行周期，数据流设计等
3. 开发阶段（数据开发）：开发环节主要包括代码开发和单元测试
   1. 代码开发：需要遵循一定的编码规范，编码规范这部分需要提前制定
   2. 单元测试：数据开发应根据单元测试手册进行自查，对规范性，代码质量，数据准确性等方面进行自查
4. 代码评审阶段（数据开发）：
   1. 设计和开发环节都有对应的规范需要遵循，任务发布前或代码评审环节需要对任务进行评审，确认各方面均符合要求
5. 验数阶段（数据产品、业务）：
   1. 研发完成数据开发，并完成初步自查后，应该交由数据产品和业务进行验数，因为他们对业务场景比较熟悉，更能发现数据是否存在异常。
   2. 注：如果是迭代任务，则开发和验收环节均在临时任务中完成，验收完成后再合并到正式项目中。
6. 发布阶段（数据开发）：
   1. 做好代码比对以及冒烟测试，均没问题后进行发布
   2. 应将变更内容通知到涉及的下游使用方
7. 运维阶段（数据开发，数据产品）：
   1. 值班同时需关心告警群中以下类型的告警：任务异常告警（任务失败、超时、或没有在预期时间执行等等），数据质量异常告警（行数异常波动、指标异常等等）。
   2. 对于这些类型的告警，值班的同事应及时处理，同步处理结果到群上，并记录到文档中
   3. 不同类型的告警按不同的方式进行处理。如：任务异常告警。查看日志，找出异常原因，及时修复；数据质量告警。确认是否为数仓问题，如果非数仓计算问题则流转给产品经理，由产品经理与业务方对接，看业务方是否进行了特殊的业务活动，或者进行了不正确的人工操作，导致数据异常波动。
8. 治理阶段（数据开发）：
   1. 除了上述运维阶段提到的告警，其余治理类的告警，通常固定时间告警（如周一早上），数据开发根据告警内容，对各自负责的内容进行治理

开发规范治理

治理背景：

数据治理是一个长期性、常态化的活动，需要通过工具或流程去保障，因此开发规范的治理，应该是在开展其他治理工作的过程中，同步进行，不断完善流程规范。

规范内容：（这里仅列举部分例子）

• ETL规范
  • 代码统一添加头注释（使用模板），需要包含表含义，表描述，创建与变更历史（时间、变更人、变更描述、变更需求链接）
  • 一个任务原则上只输出一个表，且任务名原则上要和目标表名一致
  • 任务应具备可重复性，即当天可重跑
  • 枚举类型的字段，要维护到枚举表中，方便后续监控新增枚举
• 建表规范
  • 必须设置主键
  • 必须有表注释和字段注释
  • 必须加任务计算时间，方便排查问题
  • 表名按规范命名（常规表、中间表、临时表、备份表、快照表等不同的命名规范）
  • 字段名、字段类型按规范设置
  • 视图信息要维护到视图字典表中
• SQL编写规范
  • 多写备注
  • 使用with语句代替子查询，临时表统一以使用“t_”开头
  • 多表连接时，字段名前面必须加上表别名，方便区分
  • 查询时不使用 select * 的操作
  • select 、join、where、from 等换行，每句一行
  • 字段、表、SQL子查询缩进4个空格（非tab）
• 调度与引用规范
  • 应用层应优先调用公共层数据，必须存在中间层数据，不允许应用层跨过中间层从ODS层重复加工数据
  • 视图必须使用调度程序进行封装，保持视图的可维护性与可管理性。
  • 任务链路深度不宜过大，总深度建议不超过 XX 层，同层深度建议不超过 XX 层
  • 避免应用层过度引用和依赖CDM层明细数据，需要针对性地建设好CDM公共汇总层。
  • 低层级如DWD、DWS，应避免不同数据域的耦合，尽量只是对应数据域下单个或多个业务过程的数据模型，多数据融合建议放在高层级如DM或ADS层（根据实际工作场景调整）
  • 任务调度时间按约定的调度规范设计（执行时间段、依赖配置、上下线流程等）

数据资产盘点

治理背景：

数据是企业的重要资产，也是数字经济的核心要素。随着数据量的增长，数据的获取、存储、分析和应用越来越复杂，因此需要对现有数据资产进行盘点，并对数据资产的变更进行记录，促进数据价值的而发现和创造。

治理项目：

1. 数据资产盘点：包括数仓中基础的库表信息（表名，表备注，表字段，表的存储空间等），以及任务信息（调度计划、运行耗时、内存消耗等），以及下游应用判断，如报表、接口、标签的信息（数量，名称，负责人、修改记录、使用频率和资源消耗等等）
2. 数据资产快照：完成数据资产的录入和盘点后，可以每天对数据资产进行快照或者拉链，用于后续了解数据资产变更情况

常态化治理：

1. 每周的资产变更情况：主要有几个用途，一个用于团队内部复盘，避免部分相似的模型和指标重复构建，同时也用于上线质量的监控，如上周对XX个任务进行了迭代，但其中YY个任务发生了明显的性能下降（耗时或内存消耗增加）；第二个作用是用于分享给使用方查看，如分析师常用的是数仓表或报表，把变更情况分享给他们有利于更好的实现指标的复用（实际情况中往往存在这样的情况，数仓以及有现车的指标汇总表，但下游却不知道，导致没有复用）

数据血缘治理

治理背景：

血缘管理是数据治理的一个重要环节，它描述了数据的来源和去向，是组织内使数据发挥价值的重要基础能力。数据血缘可以在迭代或排查异常时，帮助我们快速进行追踪，并准确定位问题

治理项目：

1. 数据血缘构建：根据自己所在的工作场景来构建。如果是Hive这种可以使用Altas；如果是云数据开发平台，那平台可能自带血缘功能；如果是自建的数据开发平台，需要整合血缘相关的组件或者自研血缘组件。血缘应尽可能完善，覆盖上游数据源、数据加工链路、下游报表、接口、标签等。
2. 过长加工链路治理：加工链路过长，大概率是数据模型过于复杂了，或者部分公共指标没有沉淀、没有复用。链路过深往往会导致加工迭代和问题排查过程变得复杂。应定期根据数据血缘，对过长的数据链路进行告警和优化，以降低以后迭代和维护的成本。
3. 反向依赖治理：这里的反向依赖指的是层级上的反向依赖或者血缘上的反向依赖。前者如：DWD依赖于DWS，DWS依赖于ADS；后者如：A->B->C->A 在开发过程中没仔细核查血缘的情况下，可能会不小心造成这种情况。反向依赖往往会导致加工过程变得混乱且不可控。

常态化治理：

在数据开发公共规范中，约定加工链路长度，约定不可进行反向依赖，开发过程中遵循开发规范。但这些内容在开发过程中往往容易忽略，所以建议构建自动任务，定期对链路过长、反向依赖的任务进行告警，统一监控出来并进行优化改造

数据来源治理

治理背景：

数据源是构建数仓的基石，数仓往往会集成来自不同的业务源，比如后端数据库，埋点采集，客户上报等来源的数据。应保障数仓数据源的唯一性，与上游数据源达成各种约定，并对数据源质量进行监控，是提高数仓数据质量有效的方法。

治理项目：

1. 数据源唯一：对重复的数据源进行清理，保证数据源的唯一性，避免同一个数据源的多处写入
2. 数据源约定：
   1. 创建、更新时间约定：正常来说，创建时间在记录新增后就不会再变，更新时间则是随每一次记录变更而变更。但实际情况下，创建时间被更新，更新时间没更新的情况并不少见。创建和更新时间的不规范操作，往往会导致数仓计算时出现各种问题。这种情况，最有效的方法就是尝试与后端研发、DBA等进行沟通并制定规范。
   2. 物理删除问题约定：无效数据的清理，建议是通过软删除，如增加is_delete字段判断数据的有效性，而不是简单的通过物理删除的方式进行清理。物理删除的方式往往会导致数据前后不一致，数据无法追溯等各种问题。
   3. 表结构变更约定：上游的表结构变更，如新增、删除，修改字段等，按理应该通知到下游，包括数仓团队，否则会导致数仓团队的同步任务或计算任务失败。对于表结构变更，可以尝试与后端研发、DBA沟通并制定规范，每次变更时通知订阅的团队
   4. 枚举值变更约定：后端往往会使用各种枚举来标识业务状态或类型，对于这类枚举对应的业务场景和状态，数仓是不知道的，需要后端开发团队通知，包括枚举的新增和修改。对于枚举值，可以尝试与后端研发、DBA沟通，由后端在业务系统中维护一张枚举值表，下游如数仓团队想使用的时候，同步此枚举表即可

常态化治理：

1. 表结构变更监控：就数仓团队而言，可以通过脚本，实现表结构变更的自动化监控，并自动修改同步任务以及自动修改数仓的表结构，遇到不能自动修改的，则跳过同步任务并进行告警。
2. 枚举值变更监控：就数仓团队而言，可以通过脚本，定期对表的枚举值进行扫描，并对新增枚举进行告警，及时去询问研发获取新枚举的含义
3. 数据源行数监控：对数据源的行数进行监控，主要作用有几个：1.当数据源行数进行剧烈波动时，进行告警；2.业务库表行数长期无变化（主要指事实表）或业务库表已下降为0好一段时间，大概率是此业务场景已关停或切换到新的库表记录，此类情况应及时跟进，比如替换新的库表或者是关停此业务场景的数仓任务（正常来说，业务场景关停或库表切换，应该由研发或产品通知数仓团队，但也可能存在数仓团队与后端团队信息不共通的情况，所以可以做个监控保底）

生命周期治理

治理背景：

随着业务活动的停止或变更，往往会存在已经无人维护、使用，但仍在运行的任务和报表。不仅浪费存储资源与计算资源，带来巨大的运维成本，还容易误导使用者。所以应该制定一套生命管理的流程，及时对无效的任务和报表进行归档，提高数据资产价值密度，降低资源消耗和运维成本。

治理项目：

1. 临时表治理：开发过过程中难免会产生各种临时表、测试表。人工清理完无效的中间表后，对数仓开发规范进行完善，约定中间表的命名规范，如临时表统一以tmp为后缀，测试表统一以test为后缀，备份表统一以bak为后缀，后缀后面可添加数字，如_bak20300101，表示此备份表2030年之前有效。构建定时任务，每周对临时表进行监控和清理（带有日期的临时表会等待过期后再清理）
2. 低频报表治理：定期统计报表近60天的访问次数，并将无访问或低访问次数的报表进行告警，和分析师沟通后对其归档（部分报表可能只服务于某一段时间的活动，或者此报表应用的业务场景此时已关停）
3. 低频数仓表治理：定期统计数仓表此表及其下游表，近60天的外部访问次数（外部访问指的是非数仓任务使用次数的外部使用，如即席查询，报表查询，接口查询），同样的，和使用方沟通后，无用则归档。为什么是本表及其下游的外部使用次数，比如一个维表，它平时几乎不会被直接用到，但却是下游各种汇总表的重要组成，这是就不能只看维表本身的使用次数，而是要综合它下游表的使用次数去看。

常态化治理：

1. 临时表自动下线：构建自动任务，每周自动删除过期的临时表，并对临近过期的中间表进行告警
2. 低频报表监控及下线：构建监控任务，每周对低频报表进行告警，与使用方沟通后进行归档（不可归档的手动查询一次，刷新次数）
3. 低频数仓表监控及下线：构建监控任务，每周对低频数仓表进行告警，确认无用后进行归档（不可归档的手动查询一次，刷新次数）

调度周期治理

治理背景：

关于任务的调度，可能存在以下三个问题：

1. 存在大量非必要的微批任务，导致集群的压力较大，影响到了那些必要的微批任务的正常运行
2. 天任务在半夜的调度计划不合理，未预留运维时段，或者计算时段内出现任务拥挤或者资源空余的情况，影响第二天任务的及时输出
3. 调度依赖设置存在问题，导致任务没有在预期时间内运行，或者拥挤在同一个时间段运行

治理项目：

1. 微批任务调度频率定频：根据表的使用频率，对任务进行初步的定频（如几天只使用一次的就没必要做成小时微批），并和下游使用方进行二次确认，对非必要的任务进行降频处理，从而保障必要的微批任务能够稳定且及时的输出。
2. 天任务调度周期治理：通常0点过后要预留1~2个小时的运维时间，接下来是离线同步任务，然后是计算任务的时间。计算任务可以按业务线，数据域、数据分层或任务类型（高IO？高内存？）等，约定各自的运行时间段，充分利用时间，避免任务拥挤或资源空闲。
3. 异常调度治理：根据调度计划和运行日志进行监控，监控是否存在实际运行时间与调度计划时间有较大偏差，甚至是没有运行的异常任务

常态化治理：

1. 对历史微批任务定频完成后，后续需求默认T+1，如果需要微批应提供充足理由（说明：如果资源比较充足、或者任务比较重要，按自己公司的节奏来即可，此治理只是为了减少非必要的资源消耗，实际情况要以满足业务需求优先）。
2. 天任务调度周期治理，将讨论出来的调度计划完善到“数据开发规范-调度规范”中，在对当前天任务在半夜的调度计划进行调整均衡后，后续对应的任务按约定在对应的时间段跑即可。也可构建任务对调度计划进行监控。
3. 异常调度监控，每天早上对半夜的任务进行监控，查看哪些任务因为异常配置导致没有在预期的计划时间段执行

数据服务治理

治理背景：

数仓的下游往往会存在多个下游服务，比如报表、接口、标签、邮件等，非必要情况下，同一个类型的服务应尽量简洁统一，并对下游服务的使用频率、耗时、性能等进行监控，同时在数仓进行迭代时应重复评估对下游的影响，并通知使用方

治理项目：

1. 报表系统迁移统一：统一数据报表的入口，避免出现多个报表系统，多个报表系统会增加数据口径不一致问题出现的可能性，也会增加维护成本。报表系统的统一不可避免的会对下游业务任务开展工作造成一定的影响，同时也会涉及口径的统一，需要充分和业务方进行沟通和梳理，这往往是一个周期较长，工作量较大的工作。
2. 慢报表优化治理：报表端复杂且查询缓慢的SQL，可能口径没拉齐，同一套指标采用不同的口径，导致反复计算而不能复用数仓现有指标；可能是存在部分常用的业务分析模型没有沉淀到数仓中，也可能是数仓的已经有指标，但报表层面没有进行很好的复用。不同的原因需要按不同的方式处理，如建立指标体系，拉齐口径；积极将分析模型沉淀到数仓；完善数仓的模型和指标文档，完善数仓数据字典，完善数仓迭代变更通知，让分析师能更好的使用数仓的资源。
3. 慢接口优化治理：和慢报表治理类似，对接口性能进行监控，及时优化慢接口
4. 数仓变更通知：对于数仓而言，邮件、报表、可视化平台都是下游，当我们在数仓中进行某些重构、优化操作的时候，应对他们发出通知。

常态化治理：

除报表系统迁移为一次性工作外，其余均需要进行常态化治理，如每周定期对慢报表和慢接口进行监控，及时进行优化改造。这个频率根据实际情况调整，如果部分慢接口可能会造成较大影响的，可以提高监控频率，或者改为触发式告警

任务质量治理

治理背景：

数据开发过程中，难免会产生耗时较长，或者内存消耗较高的任务，这部分任务会使得资源消耗增加，集群压力增大，导致整体链路的输出时间难以保障

治理项目：

1. 超时任务治理：根据实际工作环境，讨论出各频率（月、天、小时）任务的超时阈值，对超过阈值的任务进行监控告警，并开展治理工作，如优化任务逻辑，计算结果复用等。
2. 高内存消耗任务治理：根据实际工作环境，讨论出各频率（月、天、小时）任务的内存消耗阈值，对超过阈值的任务进行监控告警，并开展治理工作，如优化任务逻辑，计算结果复用等。
3. 超时链路治理：在完成大部分超时任务和长链路任务的治理后，接下来可以试着对链路层面进行监控和优化。

常态化治理：

构建自动任务，每周定期对上述质量不佳的任务进行告警，由负责此任务的开发去查看并优化

数据质量治理

治理背景：

数据开发过程中，难免会因为各种原因导致数据质量问题，如源头脏数据流入，计算逻辑有误，人为操作不当等。对于数据质量问题，往往是后知后觉，不能及时发现，直至下游数据应用时才发现问题。因此很有必要建立数据质量监控，及时发现数据质量问题，并进行分析处理。

治理项目：

1. 指标质量监控：梳理日常经营和分析中常用的核心指标，确定核心指标的监控规则，确定规则的责任人以及出现问题后的处理流程，形成闭环。上述内容都确定后，就可以进行规则的配置和监控的部署，定时监控、发现并处理潜在的数据质量问题。（这个项目难点一个在于确定指标和监控规则，第二个是形成问题闭环，避免出现告警后无人跟进的情况）
2. 行数监控：核心指标的监控需要对指标进行人工梳理，并人工制定监控规则，铺设监控的成本较高，难以覆盖所有报表。并且对大部分报表而言，其实不需要进行这么严格监控，只需要对行数的异常波动进行监控即可初步发现问题，这时就可以定期对数仓中表的行数进行统计，并与上一周期的行数进行环比，监控出异常波动的表。

常态化治理：

每小时对核心指标以及数仓表行数进行监控，若出现异常告警，首先用数据开发查看是否因为ETL过程异常导致的数据异常，是则修复并关闭告警，否则通知数据产品去找业务方确认是否进行特别的业务活动，导致数据异常波动。

数据安全治理

治理背景：

数据安全以及隐私数据的保护，是数据治理中的一个必要环节

治理项目：

1. 明确授权流程：需要确定一套数据授权的流程，指定审核和授权人员，做到数据授权可追溯和统计
2. 敏感数据脱敏：数仓中不应出现敏感信息，如电话、住址等隐私信息的明文数据