7.1 数据战略与治理

概述与动机

数据战略是你有意识地将数据视为一种资产来对待的计划：数据如何被生产、描述、拥有、保护、共享和使用，以创造价值。数据治理则是让这一战略变为现实的操作系统：那些能让数据长期保持可信、合规的角色、政策、标准和控制措施。在小型团队中，这些问题往往是隐性的，只存在于少数几位工程师的脑海中。而到了大型开发组织、企业和政府机构的规模，这种非正式的做法就会崩溃。数百个团队生产成千上万张数据表，几十个系统都声称自己持有”真正”的客户记录，而没有人能自信地说清楚董事会材料或公开报告中哪个数字才是正确的。

对大型团队而言，数据治理不佳所带来的代价并非抽象空谈。在 GDPR（欧盟《通用数据保护条例》）、HIPAA（美国《健康保险流通与责任法案》）等监管制度以及行业专属规则之下，监管机构期望你能够证明对个人、财务和健康数据具有可验证的血缘追溯和控制能力。企业会因指标误报、审计失败和重复建设的数据平台而面临直接的财务风险。政府机构还背负着记录保留、信息公开获取、公共问责和公民公平对待等方面的额外义务。在所有这些场景中，无法信任的数据比没有数据还要糟糕，因为它会驱动人们做出自信满满、却是错误的决策。

推动规模化组织进步的理念很简单：把数据当作产品来对待。数据不应只是应用程序运行产生的废气式副产品，每一个重要的数据集都应该有一位所有者、一份文档化的接口、质量保证，以及被当作客户对待的消费者。本章将这种产品思维与经典的治理学科结合起来讨论：数据管理、数据编目、主数据管理和数据质量。本章还将讨论决定哪种模式适合你的团队的组织选择：数据网格（data mesh）（去中心化、按领域拥有并以产品形式发布的数据）、数据湖仓一体（在灵活的数据湖之上叠加类似数据仓库的管理和治理层），以及数据仓库（一个受治理的、集中存放已建模、可查询数据的存储）。

另见： 第 4.5 章（隐私与数据保护）、第 7.2 章（数据工程）以及第 4.6 章（合规与治理）。

核心原则

数据是带有所有者的持久资产，而不是应用程序的一次性副产品。
每一个重要的数据集都有一位指定的、负责任的所有者和一份文档化的契约。
治理是为了让数据能被可信地使用，而不是一道只会说”不”的官僚关卡。
每一个关键业务实体都应该只有一个权威数据来源。
质量、隐私和血缘应当在设计阶段就被内置，而不是事后再去检查。
数据的消费者是客户，他们的需求塑造着这个”产品”。
只要可能，就应将政策编码并自动强制执行，而不是寄望于人们的自觉。
随着组织规模的增长，联邦式所有权比单一的中央团队更具可扩展性。

建议

把数据当作产品对待

为每一个重要的数据集指定一位产品所有者，由其对该数据集的适用性负责。一个”数据产品”应该有一个名称、一份文档化的模式（schema）、一段对其含义和来源的说明、一个明确的刷新节奏，以及公开发布的质量预期。你的消费者应该能够发现它、理解它，并依赖它使用，而无需向生产方团队提出任何问题。要像对待软件 API 一样对待它，运用同样的纪律：版本管理、弃用通知、变更日志和向后兼容性。

建立数据契约和 SLA

数据契约是生产方与消费方之间明确的、可通过机器检查的协议。它涵盖模式、语义、新鲜度、数据量和允许的变更范围。在流水线中强制执行契约，使上游的破坏性变更能在源头就快速失败，而不是在几周后悄悄破坏下游的报表。将契约与服务水平协议和目标结合使用。例如：“客户维度表每天 06:00 前完成刷新，99.5% 的日子能达标，且业务主键为空值的比例低于 0.1%。“要公开发布这些指标，并对违反行为设置告警。

建立数据管理体系和治理运营模式

将问责与执行分开。数据所有者（通常是业务负责人）对某个领域负责。数据管理员（主题专家）维护定义、解决质量问题并审批访问权限。一个轻量级的数据治理委员会负责制定跨领域的标准并裁决争议。要保持这一模式的联邦制特征：由一个中央赋能团队提供工具、标准和指导，而各领域团队则拥有自己的数据。这样既能避免完全集中化带来的瓶颈，也能避免完全没有治理带来的混乱。

投资建设数据目录和血缘追溯

一个可搜索的数据目录，是通往你整个数据资产的大门。它应当包含业务术语表、技术模式、所有权、敏感度分级、质量评分，以及从源系统经过转换到仪表盘的端到端血缘信息。要自动化元数据的采集，而不是依赖很快就会过时的人工文档。血缘信息对影响分析、事件响应、审计，以及诸如数据主体访问和删除请求之类的监管要求都至关重要。

主数据管理与单一可信来源

对于核心实体（客户、公民、产品、供应商、员工），要使用主数据管理，将重复和相互冲突的记录协调整合为一条黄金记录。根据数据枢纽所需的权威程度，选择合适的架构（注册型、整合型、共存型或集中型）。要明确定义匹配和存续规则，并使其可被审计。单一可信来源可以防止财务、销售和运营各自报出不同营收数字这一经典失败场景。

从多个维度衡量数据质量

沿着若干命名维度来管理数据质量：准确性、完整性、一致性、及时性、有效性和唯一性。为流水线配备自动化测试和持续的数据可观测性（新鲜度、数据量、模式漂移和分布检查），从而在消费者受到影响之前就发现异常。要像对待生产环境故障一样对待数据事件，包括检测、分诊、根因分析和事后总结。

分类、保护并控制访问

按敏感程度对数据进行分类，并施加相应比例的控制措施：加密、脱敏、令牌化、行级和列级安全性，以及定期审查的最小权限访问。要维护一套既满足数据最小化要求、又符合记录保留法律的保留与删除计划。在政府场景中，应有意识地统筹协调透明义务与隐私保护，而不是逐案处理。

权衡：利与弊

方案	优点	缺点	最适合的场景
中央化治理团队	标准一致，问责清晰	容易成为瓶颈，与各业务领域脱节	规模较小或受严格监管的组织
联邦式治理	可扩展，具备领域专业知识，所有权明确	需要强大的工具支撑和文化基础	拥有多个业务领域的大型企业
数据仓库	成熟、受治理、SQL 性能优良	结构僵化，处理非结构化数据成本高	以商业智能为主、负载稳定的场景
数据湖仓一体	灵活、统一，可处理各类数据类型	工具生态尚不成熟，治理投入较大	分析与机器学习混合的场景
数据网格	领域自主拥有，能够随组织扩展	成熟度门槛高，协调成本大	规模非常大、高度去中心化的组织

治理始终是在速度与信任之间做权衡。轻量级治理能让团队快速推进，直到一次审计、一次数据泄露，或一次令人难堪的错误报告，迫使组织付出昂贵的代价来清算。重度治理能保护信任，但可能扼杀实验精神，并把团队推向影子系统。持久的解决之道是把治理编码为自动化的、自助式的护栏，使合规路径同时也是最省力的路径。从架构上看，数据仓库更适合受治理的简单场景，数据网格更适合组织规模的扩展，而湖仓一体则介于二者之间。正确的选择更多取决于你的组织结构，而不是任何技术基准。

与团队讨论的问题

哪种数据架构（仓库、湖仓一体还是网格）真正适合你组织的结构，你们是否诚实地面对每一种架构所要求的成熟度门槛？ 权衡表说明了一点：这个选择应当跟随组织结构，而不是跟随基准测试（）数据仓库适合稳定的、以商业智能为主的负载，湖仓一体能处理分析与机器学习的混合场景，而数据网格能在众多自治领域之间扩展，但要求很高的成熟度和强大的工具支撑。对于拥有几十个业务领域的大型企业或政府机构而言，在尚未具备自助式平台和治理文化之前就贸然转向数据网格，只会制造出一场披着”去中心化”外衣的混乱。带上具体的信号：有多少个领域在生产数据、中央团队是否已经成为瓶颈，以及各领域团队是否具备拥有”产品”所需的技能和动力。如果你目前还缺乏联邦式的工具支撑，诚实的答案可能是：现在先采用受治理的仓库或湖仓一体，网格留到以后再说。选择你的团队真正能够运作起来的模式，再投资建设下一种模式所需要的成熟度。
今天你能否端到端地满足一个删除请求，你的血缘信息是否能证明一条个人记录的每一份副本去向何方？ 在 GDPR 及类似制度下，数据主体的删除或访问请求是有硬性期限的法律义务，而如果数据被大量复制却没有血缘记录，就根本不可能满足这一要求。大型团队常常把数据扇出到数据集市、提取文件、缓存和电子表格中，因此真正的问题不在于你能否删除原始数据，而在于你能否追溯并触达每一份副本。带上证据：挑选一位真实的客户或公民，尝试列举出他们的数据存在于哪些地方。如果你做不到，这个缺口既是合规风险，也是一个数据泄露波及范围的问题。这个答案应当推动你投资建设自动化的血缘追溯，并对不受控的复制行为施加更严格的控制，因为合规路径必须在请求到来之前就已建成。
你们的治理究竟是最省力的路径，还是一道人们会绕开的关卡？能证明这一点的影子系统在哪里？ 本章给出的持久答案是把治理编码为自动化的、自助式的护栏，使合规路径同时也是最快的路径，因为繁重的人工治理会把团队推向影子电子表格和不受治理的副本。对企业和政府机构而言，数据泄露、错误数字和审计失败恰恰诞生于这些影子系统，原因正是没有人在监督它们。带上一份具体清单：哪些团队保留着自己的副本、哪些报表绕开了数据目录，以及人们在哪些地方抱怨”官方流程太慢了”。每一个影子系统都是一个信号，说明走受治理的路径的成本高于绕过它。要解决的是这种摩擦本身，而不是再出台一份政策，从而让使用经过认证的数据和契约真正比绕开它们更省力。
哪个关键业务实体最需要一个单一权威数据来源，今天由谁（具体姓名）对其黄金记录负责？ 主数据管理的存在，就是为了阻止财务、销售和运营各自报出不同的客户信息或不同的营收数字，而在规模化场景下，缺少一个权威来源，会让每一个跨领域的数字都变成一场争论。相互制约的因素在于：这个数据枢纽需要多高的权威性（注册型、整合型、共存型还是完全中心化），以及你愿意构建和审计多少匹配与存续逻辑（）更重的枢纽成本更高，但也能解决更多冲突。带上出现频率最高的实体（客户、公民、产品、供应商、员工）、每个实体分别有多少个系统声称持有”真正的”记录，以及你们目前使用的匹配规则（如果有的话）。对于一家银行或一个国家级机构而言，要明确指出问责所有者和存续规则，因为当监管机构从一份公开报告追溯某个数字的来源时，会问”是谁决定哪一条重复记录胜出的”，而”没有人决定”这样的答案是经不起审计的。
在消费者发现某个关键数据集已经出问题之前，你怎么知道它是可用的？ 在不成熟的数据体系中，质量问题往往是由仪表盘崩溃的分析师或董事会数字出错的高管发现的，而这是代价最高昂的发现方式。这里的张力在于：为质量投入检测手段（测试、新鲜度和数据量检查、按准确性、完整性和有效性等命名维度进行的分布和模式漂移监控）的成本，与你所预防的事故成本之间的权衡，而团队常常因为故障在酿成灾难之前始终不可见而投入不足。带上最近三次数据事件、它们是如何被发现的，以及在被人发现之前运行了多久，再加上你们目前真正发布并加以告警的质量 SLA。对于企业和政府报告而言，要将每一个关键数据产品与明确的质量阈值绑定，并像对待生产环境故障一样，用分诊和事后总结来处理质量违规事件，因为监管申报或公开统计数据中的一个错误数字，其法律和声誉代价将远远超过监控本身的开支。
你们的治理是真正的联邦式领域所有权，还是一个被问责、却并不理解其所治理数据的中央团队？ 本章的论点是：具备中央赋能的联邦式所有权，能够在纯粹中心化会造成瓶颈、纯粹去中心化会陷入混乱的地方实现扩展，然而许多组织声称自己实行了联邦制，实际上仍由一个小型中央团队名义上对数千张它毫无领域知识的表负责。这里存在真实的相互制约：中央团队能带来一致性和单一的问责对象，而领域所有权能带来专业知识和责任感，但也要求业务负责人接受他们可能并不想要的责任。带上一份诚实的对照表：谁在名义上负责，谁实际上在为你们最重要的领域维护定义、解决质量问题，以及数据管理员是否拥有该角色所需的权力和时间。在大型企业或机构中，要检查所有权是否落在既具备领域知识、又有权说”不”的人身上，因为一个被赋予给没有实权的中央团队的治理职责，只会产生无人遵守的政策，以及一个什么都裁决不了的委员会。

行业视角

初创企业。 速度和生存压倒流程。为每个核心数据集指定一位所有者，让一个存储成为诸如”活跃客户”这类实体的单一可信来源，完全跳过数据目录、委员会和数据网格。为你的少数几张关键表写一份一页纸的契约（模式、刷新时间、一条质量预期），就能在一个下午内终结”谁的数字才对”这类争论。善用你的数据仓库中已经内置的治理能力，而不是去养一个你负担不起的职能团队。

小型企业。 在没有专职数据专家、预算又紧张的情况下，把治理当作数据卫生习惯，而不是一个平台项目：清楚你持有哪些个人数据、存放在哪里，以及谁有权限接触它们。优先选择开箱即用就提供血缘追溯、访问控制和保留管理的托管数据仓库或商业智能工具，这样你购买的是已经嵌入到你正在使用的工具中的治理能力，而不必自己去构建它。把任何定制化的数据流水线，都留给那一个真正驱动业务的数据集。

企业。 在跨越众多团队的规模化场景下，工作重点是”联邦式所有权加中央赋能”：一份配有自动化血缘追溯的共享数据目录、强制执行的数据契约、核心实体的主数据，以及对照基线衡量的质量 SLA。要将治理编码为自助式护栏，使合规路径同时也是最快的路径，并把数据当作一个由指定所有者管理的产品组合来管理。这样审计人员就能把任何一个数字从报表一路追溯回源头，各团队也不会再重复造出同样的流水线和定义。

政府。 采购规则、透明度和公共问责塑造着每一项决策。要把公开发布的各项指标当作数据产品来对待，配有文档化的方法论、带版本号的发布，以及质量关卡，并有意识地统筹协调信息公开和开放数据义务与隐私保护和数据最小化，而不是逐案处理。在供应商合同中要求数据可移植性和血缘信息披露，以避免被供应商锁定，维护一套经得起审查的保留与删除计划，并让一个数据管理委员会统一持有共享定义，使”家庭”或”失业”这类术语在各部门之间含义一致。

示例

初创企业。 一家种子期的 SaaS 公司发现，它的计费电子表格、销售工具和产品数据库各自报出不同的客户数量，没有人能说清哪个数字对于投资者更新报告而言是正确的。这个四人团队为每个核心数据集指定了一位所有者，让数据仓库成为”活跃客户”这一实体的单一可信来源，并写了一份一页纸的契约，描述模式和每日刷新时间。这只花了一个下午，却终结了每周关于该相信哪个数字的争论。

企业。 一家跨国银行将其零售、贷款和财富管理各部门中数十条相互冲突的客户记录，整合进了一个配备存续规则和黄金记录的主数据管理枢纽。每个领域都发布了配有契约和新鲜度 SLA 的数据产品，并呈现在一个带有血缘信息的中央目录中。监管报告的耗时大幅下降，因为审计人员现在可以把任何数字从报表一路追溯回源头。该银行还借此淘汰了几个冗余的报表平台。

政府。 某国家统计机构把自己发布的各项指标当作数据产品来对待，配有文档化的方法论、带版本号的发布，以及严格的质量关卡。一个数据管理委员会统筹各部门之间的定义，使”失业”或”家庭”这类术语在各处含义一致。分级和受控访问保护了受访者的机密性，同时一个公开的数据目录支撑了透明度和信息公开义务。

商业理由：动机、投资回报率与总拥有成本

数据治理的动机，大体上一半是降低风险，一半是创造价值。在风险方面，可避免的成本包括监管罚款、数据泄露责任、审计失败，以及发布错误数字带来的声誉损害。在价值方面，可信、可被发现的数据能加速每一项下游的分析和机器学习工作，减少重复建设的流水线，并缩短从提出问题到得到答案的时间。

采纳这套体系的成本是真实存在的：数据目录和质量工具、数据管理员和所有者投入的时间，以及让”所有权”真正落地所需的组织变革。要将总拥有成本与不采纳这套体系的代价相权衡，而后者通常更高，只是被隐藏了起来。如果不加以衡量，这种代价就会表现为：分析师把大部分时间花在寻找和清洗数据上、各团队反复重建同样的流水线，以及高管依据没有人能够辩护的数字做决策。向领导层论证时，要用他们的语言来表达：治理能把数据从一项下行风险无上限的负债，转变为一项回报可以复利增长的资产，而这也是可信人工智能的先决条件。从痛点和监管风险敞口最大的地方入手，这样你才能尽快展示出成果。

反模式与陷阱

由委员会主导却毫无自动化的治理，只会产生无人遵守的政策。
一次性对所有数据编目，而不是先编目真正重要的数据集。
主数据项目贪大求全，却始终产不出一条黄金记录。
把数据质量当作一次性清理，而不是持续的可观测性工作。
把所有权分配给缺乏领域知识或权力的中央团队。
契约只写在维基页面上，却没有在流水线中强制执行。
大量复制数据却没有血缘记录，使删除请求根本无法满足。
买了个工具就号称有了战略；没有运营模式配合的工具注定失败。

成熟度模型

初始：数据没有文档记录，也没有所有者，处理方式临时且被动。各团队之间的定义相互冲突。质量问题是由消费者在报表崩溃时发现的。不存在数据目录或血缘追溯。
发展：基本实践已经出现，但在各团队之间并不一致。部分数据集有所有者和文档，存在一份不完整的数据目录。质量检查是人工的、被动的。已经写出了一份治理政策，但执行得薄弱且不均衡。
标准化：所有权、契约和 SLA 在整个组织范围内都有文档记录并得到强制执行。关键数据产品都有指定的所有者；一份带自动化血缘追溯的数据目录覆盖了主要领域；核心实体已建立主数据；治理是联邦式的，配有中央赋能，并被一致地应用，而不是各团队各自为政。
管理：整个数据资产对照基线被度量和管控。质量维度（准确性、完整性、及时性、有效性、唯一性）对照已发布的 SLA 目标被跟踪；契约违反率、血缘和目录覆盖率、新鲜度以及满足一次删除请求所需的时间都在仪表盘上报告；可观测性会对模式漂移和数据量异常发出告警；事件会经过分诊、根因分析和事后总结；访问和放行/拦截决策依据的是对照基线的指标，而非主观意见。
协同：治理在整个组织范围内被持续改进并深度融合。“数据即产品”在各领域已成为常态；契约得到自动强制执行，破坏性变更会快速失败；自助式护栏将政策编码其中；质量和血缘信息为主动的风险管理提供支撑；定义在整个企业范围内受到信任，并支撑受监管的报告和人工智能应用。组织会定期重新平衡所有权、淘汰冗余平台，并随着业务和监管的变化调整治理方式。

讨论思路

你的哪个业务实体最迫切需要一个单一可信来源？它今天为什么如此碎片化？
在哪些地方，强制执行的数据契约本可以防止最近发生的一次事件？
你的组织在结构上适合联邦式所有权，还是现阶段更适合中心化？
你们如何在政府透明度义务与隐私保护和数据最小化之间取得平衡？
你的分析师们把百分之多少的时间花在寻找和清洗数据上？如果能减半，这份价值有多大？
你最重要的数据集由谁（具体姓名）负责？他们自己知道这一点吗？

关键要点

把数据当作带有所有者、契约和 SLA 的产品来对待，而不是应用程序运行产生的废气。
配有中央赋能的联邦式治理，比纯粹的中心化更具可扩展性。
带有自动化血缘追溯的数据目录，是通往可信数据资产的大门。
通过主数据管理，为核心实体建立单一可信来源。
沿着若干命名维度，借助可观测性和事件响应持续管理数据质量。
将治理编码为自动化护栏，使合规路径成为最省力的路径。
根据你的组织实际情况来选择数据仓库、湖仓一体还是数据网格，而不是跟风炒作。

参考文献与延伸阅读

DAMA International，《DAMA-DMBOK：数据管理知识体系》。
Zhamak Dehghani，《Data Mesh: Delivering Data-Driven Value at Scale》。
Ralph Kimball 与 Margy Ross，《The Data Warehouse Toolkit》。
Piethein Strengholt，《Data Management at Scale》。
David Loshin，《Master Data Management》。
Chad Sanderson 及其同事关于数据契约的著述。
ISO/IEC 38505，《数据治理》。
ISO 8000，《数据质量》标准系列。