1 数据治理的背景
在数据建设过程中，业务人员和数据开发人员在日常使用数据的过程中还是能感受到一些痛点的，主要的表现：
第一，数据资产缺乏盘点。当前核心系统的主要数据已经采集到数据仓库，但是在日常的业务分析中经常需要向业务系统了解需要用到的数据在哪里。总得来看对数据资产还是缺乏整体盘点，公司主要有哪些数据，都分布在哪些系统中，哪些数据已经采集到数仓，哪些还没有入库，还有待进一步梳理。
第二，数据标准化建设不足。数据标准会贯穿数据管理的全流程，虽然我们制定了一系列规范文档、制度文档、流程文档等，但有了标准并不代表数据标准化已经落实了，像指标数据的标准化、主数据的标准化等方面还需要进一步的提升。
第三，数据质量问题。数据质量是数据的生命线，差的数据质量严重影响数据分析的结论，有的可能对决策产生误导，如脏数据、维度数据缺失或变更等一系列问题，都需要进行治理，比如扫描信息缺失，导致运单路由轨迹不准确；数据维度值变化，统计某个渠道业务量陡增或骤降。
第四，数据模型待完善。目前已经建设了一批公共宽表，但是随着业务发展，有些时候业务方需求比较急，开发直接从基础明细表取数，导致宽表复用度降低；为了追求开发效率，团队内部也存在烟囱式开发现象，导致一些 ST 层共有逻辑没有下沉。
第五，数据安全问题。公司还会积累大量客户的地址、姓名、电话等信息，这些信息都需要进行有效的安全管理。此外，国家也出台了《数据安全法》、《个人信息保护法》等法律法规，需要我们做好数据分级分类和对数据合规安全的访问，同时保障数据保密性、完整性和可用性。
而数据开发人员如何解决以上问题成为关键，也是数据治理工作的核心。
2 数据治理期望实现的目标数据治理的范围非常广，贯穿数仓的整个生命周期，从数据产生->数据接入->数据存储->数据处理->数据输出->数据展示，每个阶段都需要质量治理，评价维度包括完整性、规范性、一致性、准确性、唯一性、关联性等。
最终，数据治理工作最主要期望能够实现的目标是：
1. 提升数据质量
2. 解决数据孤岛问题，实现数据汇聚联接
3. 掌握数据资产现状
4. 保障数据安全合规
5. 逐渐释放业务价值，如在降本增效、提升客户满意度等方面发挥作用
3 数据治理体系数据治理体系包括数据模型治理（规范治理、复用度治理）、架构治理（数据分层治理、数据流向治理）、元数据治理、数据安全治理、数据生命周期治理、数据质量管理以及数据体系治理等内容。
3.1 数据模型治理大部分行业的数据都具备如下特征：
l 数据生命周期比较长
核心业务过程生命周期短则 1 天，长则 3-5 天，异常过程可能会更长。财务类周期结算长，涉及政策财经类数据计算回刷时间 1～3 个月；
l 业务流程复杂
核心业务过程从业务流程起始点到业务流程终点，流程较为复杂；
l 对象多数据大
数据由不同业务对象等多角色产生，且非常依赖他们操作的规范性；
l 数据精细化运营
当前各大行业竞争都非常激烈，在此背景下更需要精细化运营，因此对数据依赖非常强。公司通过数据化运营进行成本管控，运单时效管控，服务质量管控，已成为公司日常运营常态，因此对数据准确性，时效性要求很高。
同时，随着业务持续发展，项目也在快速迭代。数据建设不规范等方面的原因导致了复用性不高、时效不稳定等，自然而然也会引起资源危机等问题。
为此可以制定了一整套的方案，主要包括三方面
第一，制定规范。制定诸如开发规范、分层使用规范，并严格要求各类数据开发和使用团队遵守；
第二，过程管控。以需求为驱动，将设计、开发、上线等数据建设各个阶段进行过程管控；
第三，模型分级。根据应用的重要程度来反推、梳理哪些是重要的模型和应用，将重要性高的模型和应用纳入重点治理范围，重点关注他们的复用性、实效性。
3.1.1 规范治理规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，统一按照最详细、可落地的方法进行规范建设。
3.1.1.1词根规范词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
普通词根：描述事物的最小单元体，如：交易-trade。
专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。
3.1.1.2表命名规范通用规范
l 表名、字段名采用一个下划线分隔词根（示例：clienttype->client_type）。
l 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
l 表名、字段名需以字母为开头。
l 表名、字段名最长不超过64个英文字符。
l 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。
l 在表名自定义部分禁止采用非标准的缩写。
l 表命名规则:表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾，如下图所示：
统一的表命名规范
3.1.1.3指标命名规范结合指标的特性以及词根管理规范，将指标进行结构化处理。
l 基础指标词根，即所有指标必须包含以下基础词根：
l 业务修饰词，用于描述业务场景的词汇，例如trade-交易。
l 日期修饰词，用于修饰业务发生的时间区间。
l 聚合修饰词，对结果进行聚集操作。
l 基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额-trade_amt。
l 派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt。
l 普通指标命名规范，与字段命名规范一致，由词汇转换即可以。
3.1.2 复用度治理复用度治理方面，主要包括三块：
第一，流程规范的制定。我们会制定相关规范来要求数据参与者都遵守。通过制定规范，应用开发团队和数仓团队进行分工，且在业务需求评审环节要求数仓团队介入，可以更早地评估是否需要设计相关模型来支持应用团队的数据开发；
第二，过程线上管控。在数据使用、模型设计、任务上线等环节都进行线上管控，由leader审批把关；
第三，核心数据识别。最主要是识别出四类核心数据，最主要关注核心模型和核心应用，并对这类数据我们重点关注、重点保障，优先保障其核心链路上数据的准确性和及时性。
在数据复用度治理方面还需要关注时效、引用度、需求响应及时性之间的平衡问题。我们不能为了提高模型的复用度就任意的增加维度、指标，否则可能会导致下游应用产出障碍的问题。也不能说某个指标下游引用不多就增加到宽表中来，一定要考虑平衡性的问题。
除此之外，我们还需要考虑响应的及时性。在流程上我们希望尽量做到规范，希望应用层都引用模型、宽表的数据。在实际工作中，有时为了保证“业务需求第一”的原则，有可能允许应用层先从明细层取数进行开发，模型同步进行迭代优化，后续再让应用层把需求切换回来。
3.2 架构治理3.2.1 数据分层优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长，一般的分层架构如下：
但是在对数仓分层架构做治理的过程中，同时也要结合公司业务场景和组织架构合理涉及数仓分层架构，才能保证数仓分层架构能够匹配公司业务发展，更好地赋能业务。
3.2.2 数据流向稳定业务按照标准的数据流向进行开发，即ODS-->DWD-->DWA-->APP。非稳定业务或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP两个模型数据流。在保障了数据链路的合理性之后，又在此基础上确认了模型分层引用原则：
正常流向：ODS>DWD->DWT->DWA->APP，当出现ODS >DWD->DWA->APP这种关系时，说明主题域未覆盖全。应将DWD数据落到DWT中，对于使用频度非常低的表允许DWD->DWA。尽量避免出现DWA宽表中使用DWD又使用（该DWD所归属主题域）DWT的表。同一主题域内对于DWT生成DWT的表，原则上要尽量避免，否则会影响ETL的效率。DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。禁止出现反向依赖，例如DWT的表依赖DWA的表。
3.3 元数据治理我们的数仓中有上万张表，无论是对数据开发者还是业务使用方，都会面临无从下手的情况。他们在日常使用过程中的痛点最主要可以归纳为有什么、在哪里、怎么用三类。
比如一个运单，有收件人、发件人、运载轨迹、费用等各种信息，但具体有哪些表就不是很清楚了。在实际的工作中，分析师也经常会问有没有哪块的数据，在哪里之类等等。哪怕是找到表之后，也会疑惑数据是如何加工的，如果要用的话有哪些限制条件等等问题。
基于对现状的梳理及现阶段要对元数据信息管理的目标。
元数据可分为技术元数据和业务元数据：
技术元数据为开发和管理数据仓库的IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。
常见的技术元数据有：
存储元数据：如表、字段、分区等信息。
运行元数据：如大数据平台上所有作业运行等信息：类似于 Hive Job 日志，包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间，执行引擎等。
数据开发平台中数据同步、计算任务、任务调度等信息：包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
数据质量和运维相关元数据：如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。
业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
常见的业务元数据有维度及属性(包括维度编码，字段类型，创建人，创建时间，状态等)、业务过程、指标(包含指标名称,指标编码，业务口径，指标类型，责任人，创建时间，状态，sql等)，安全等级，计算逻辑等的规范化定义，用于更好地管理和使用数据。数据应用元数据，如数据报表、数据产品等的配置和运行元数据。
元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。
元数据治理主要解决三个问题：
通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；
基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；
通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。
3.4 数据安全治理数据安全是企业数据建设必不可少的一环，我们的数据都存储在大大小小的磁盘中，对外提供不同程度的查询和计算服务。
需要定时对数据进行核查、敏感字段加密、访问权限控制，确保数据能够被安全地使用。
围绕数据安全标准，首先要有数据的分级、分类标准，确保数据在上线前有着准确的密级。第二，针对数据使用方，要有明确的角色授权标准，通过分级分类和角色授权，来保障重要数据拿不走。第三，针对敏感数据，要有隐私管理标准，保障敏感数据的安全存储，即使未授权用户绕过权限管理拿到敏感数据，也要确保其看不懂。第四，通过制定审计标准，为后续的审计提供审计依据，确保数据走不脱。
3.5 数据生命周期治理任何事物都具有一定的生命周期，数据也不例外。从数据的产生、加工、使用乃至消亡都应该有一个科学的管理办法，将极少或者不再使用的数据从系统中剥离出来，并通过核实的存储设备进行保留，不仅能够提高系统的运行效率，更好的服务客户，还能大幅度减少因为数据长期保存带来的储存成本。数据生命周期一般包含在线阶段、归档阶段（有时还会进一步划分为在线归档阶段和离线归档阶段）、销毁阶段三大阶段，管理内容包括建立合理的数据类别，针对不同类别的数据制定各个阶段的保留时间、存储介质、清理规则和方式、注意事项等。
从上图数据生命周期中各参数间的关系中我们可以了解到，数据生命周期管理可以使得高价值数据的查询效率大幅提升，而且高价格的存储介质的采购量也可以减少很多；但是随着数据的使用程度的下降，数据被逐渐归档，查询时间也慢慢的变长；最后随着数据的使用频率和价值基本没有了之后，就可以逐渐销毁了。
3.6 数据质量治理对于数据质量的监控，主要包括三个环节：
第一，结合数据质量衡量的六个维度及日常工作中发现的数据质量问题，配置相关规则。
第二，在数据加工的各个环节设置检查点，比如从 ODS 到 DW，从 DW 到 DM 等环节。如在 ODS 的检查点设置中，可能会包括数据源抽取记录的检查；在基础层会有空值、编码值、一致性、重复性等问题的检查 。
第三，输出异常结果，进行告警处理。
看一个具体的监控案例。当用数据质量监控平台对一张表进行监控时，我们可以选择配置相关规则，可以直接采用预置的规则模版，也可以自定义规则。也可以设置检查规则的属性，比如是强规则还是弱规则，此外对告警的属性也可以进行设置。规则配置完成以后在实际检测过程中，如果某个检测规则违反了强规则，则其会阻断下游任务的执行。
告警升级机制方面，强规则一般会提供电话告警。如果说由于疏忽或其他情况导致任务负责人未及时处理，那么会升级到leader来推进问题的解决。
告警信息是点对点，我们对告警信息会进行聚合，形成质量全貌信息。比如每天早上来上班，我就可以打开质量全貌信息，看一下当天执行了多少检查规则，有多少是有问题的。如果有问题可以继续分辨哪些是真有问题，哪些是没问题，有问题的是否已经解决。如果检查规则设置不合理，我们会进行优化，逐渐使得告警规则更准确，形成质量监控全面、准确的闭环。
第一，结合数据质量衡量的六个维度及日常工作中发现的数据质量问题，配置相关规则。
第二，在数据加工的各个环节设置检查点，比如从 ODS 到 DW，从 DW 到 DM 等环节。如在 ODS 的检查点设置中，可能会包括数据源抽取记录的检查；在基础层会有空值、编码值、一致性、重复性等问题的检查 。
第三，输出异常结果，进行告警处理。
看一个具体的监控案例。当用数据质量监控平台对一张表进行监控时，我们可以选择配置相关规则，可以直接采用预置的规则模版，也可以自定义规则。也可以设置检查规则的属性，比如是强规则还是弱规则，此外对告警的属性也可以进行设置。规则配置完成以后在实际检测过程中，如果某个检测规则违反了强规则，则其会阻断下游任务的执行。
告警升级机制方面，强规则一般会提供电话告警。如果说由于疏忽或其他情况导致任务负责人未及时处理，那么会升级到leader来推进问题的解决。
告警信息是点对点，我们对告警信息会进行聚合，形成质量全貌信息。比如每天早上来上班，我就可以打开质量全貌信息，看一下当天执行了多少检查规则，有多少是有问题的。如果有问题可以继续分辨哪些是真有问题，哪些是没问题，有问题的是否已经解决。如果检查规则设置不合理，我们会进行优化，逐渐使得告警规则更准确，形成质量监控全面、准确的闭环。
还有一些深层次的数据质量问题可能通过我们常规的检查手段并不一定能发现，这时就需要借助下游数据使用来解决，一般我们会结合业务专题分析推动数据治理。在专题分析过程中，可能会发现种种数据质量问题，比如数据未线上化、数据采集不完整等。