1.1. 数据认证是指在数据资产满足关于数据质量、可观测性、权责分配、问题解决和沟通等公司内共同遵守的SLA后，批准它们被用于整个组织的过程

1.2. 数据认证为人员、框架和技术构建了关键流程，使其与核心业务政策保持一致

1.3. 数据认证的要求会因业务需求、数据工程团队的能力和数据可用性的不同而有所差异

1.4. 特性

1.4.1. 自动化的质量检查，包括数据的新鲜度、容量、模式和分布

1.4.2. 明确定义正常运行时间的交付SLA

1.4.3. 负责调查数据警报的数据所有者

1.4.4. 将警报传达到Slack频道中（或通过电子邮件发送）

1.4.5. 设置针对宕机的信息沟通流程

2.1. 数据认证流程通常在多个领域采用一致的方法，来提高其可扩展性

2.2. 步骤

2.2.1. 扩展数据可观测性的能力

2.2.1.1. 实现数据可观测性（即组织全面了解系统内数据健康状况的能力）是数据认证流程的首要步骤

2.2.1.2. 需要了解当前的系统性能以建立基准指标

2.2.1.3. 需要一个系统性的端到端方案来主动对数据事件进行发现、预警和分流

2.2.1.4. 由可观测性驱动的数据事件仪表板能够自动呈现异常情况、模式变更、被删除的表以及违规情况

2.2.1.5. 如果数据管道中的任何部分出现故障（这是迟早的事），你将是第一个知道的人

2.2.1.6. 了解哪些系统和数据集总是引发最糟糕或最频繁的下游问题，能够帮助你编写有效的数据SLA

2.2.2. 确定数据所有者

2.2.2.1. 每个被认证的数据资产都应该有一个负责人，负责从摄取层到分析层的整个生命周期

2.2.3. 了解什么是“好”的数据

2.2.3.1. 制定KPI

2.2.3.1.1. 新鲜度

2.2.3.1.1.1. 数据在每天早上8点刷新

2.2.3.1.1.1.1. 适用于CEO或其他主要高管在早上8:30查看仪表板的情况

>   2.2.3.1.1.2. 数据永远不会超过Xh不更新>  2.2.3.1.2. 分布  >   2.2.3.1.2.1. X列永远不会为空值  >   2.2.3.1.2.2. Y列的值永远都是唯一的  >   2.2.3.1.2.3. X字段总是大于等于Y字段>  2.2.3.1.3. 容量  >   2.2.3.1.3.1. X表的大小永远不会减少>  2.2.3.1.4. 模式  >   2.2.3.1.4.1. 该表中的任何字段都不会被删除>  2.2.3.1.5. 沿袭  >   2.2.3.1.5.1. 填充X表的数据100%都将与上游来源和下游摄取相映射，并包括相关的元数据>  2.2.3.1.6. 数据宕机时间（或可用性）  >   2.2.3.1.6.1. 数据事件的数量乘以（检测所需时间+解决所需时间）  >   2.2.3.1.6.2. 衡量数据宕机时间的各个部分的SLA可以更具体地指导行动>  2.2.3.1.7. 查询速度>  2.2.3.1.8. 数据摄取  >   2.2.3.1.8.1. 每天早上5点从合作伙伴Y那里接收数据  >   2.2.3.1.8.2. 非常适合让外部合作伙伴最终负责

2.2.4. 为最重要的数据集设置清晰的SLA、SLO和SLI

2.2.4.1. SLA必须要具体，可以通过SLO和SLI进行评估，并且可以实现

2.2.4.2. SLA不仅描述了协议规定的服务标准，还规定了各方之间的关系

2.2.4.3. SLA概述了在正常运营以及发生问题时各方的责任

2.2.4.3.1. SLA中包括了团队在未能达成SLA时应该如何响应

2.2.4.4. 团队应当趁早并经常与利益相关方保持协同，以了解什么才是“好”的数据

2.2.4.5. 利益相关方既包括数据团队，也包括团队外的业务部门

2.2.4.6. 好的SLA需要根据业务运营的实际情况和用户对数据的使用方式来制定

2.2.4.7. 不要试图做到一劳永逸

2.2.4.7.1. 大多数客户都是先实施其数据认证程序以确保有所进展，然后再在第二波行动中清理旧的资产

2.2.4.7.2. 首先认证最关键的表和数据集，也就是那些对业务增值最多、查询活动最多、用户数量或上下游依赖关系最多的表和数据集

2.2.5. 制定沟通和事件管理流程

2.2.5.1. 考虑如何向整个组织通报重大事故也是非常重要的

2.2.6. 确定数据认证机制

2.2.6.1. 为利益相关方进行认证并呈现经过批准的数据资产了

2.2.6.2. 采用去中心化的认证流程

2.2.6.2.1. 认证流程旨在帮助团队加速并扩大规模

2.2.6.3. 数据团队应当适当地标记、搜索并利用数据表，使用数据发现解决方案这一自主开发的工具或其他形式的数据目录

2.2.7. 培训数据团队和下游用户

2.2.7.1. 仅仅把数据表标记为“已认证”并不能保证分析师们会严格遵守规定

2.2.7.2. 数据团队需要接受培训来学习适当的工作流程，而必要时这些流程会被强制执行

2.2.7.3. 对警报和通知的级别进行微调也都非常重要

2.2.7.4. 偶尔收到不需要对其采取行动的警报是有益的

2.2.7.5. 对于某个人来说是“意料之中”的行为可能对另一个团队成员甚至另一个领域的成员来说仍是重要的新消息

2.2.7.6. 警报疲劳也是真实存在的

2.2.7.6.1. 团队因疲劳而开始忽视警报信息，那么你可以通过调整监控系统或对通信渠道进行分流来优化警报方案，从而更好地展示最重要的信息

2.3. 数据工程师将数据表标记为认证通过，并与数据集的所有者一起将其展示在数据仓库中，然后分析师就可以提取数据，并在他们的仪表板中进行使用

2.4. 为了更好地应对数据质量在文化层面与组织层面的障碍，现代数据团队可以优先采用能够发挥其业务强项和需求的团队结构

3.1. 数据领导者们的任务之一就是要扩大团队的规模，并且要快速地完成这项任务

3.2. 为数据团队确定合适的汇报结构

3.2.1. 随着数据需求的增加，集中式数据团队会造成效率瓶颈，而分散式数据团队则会导致重复工作和流程的复杂性

3.3. 以分散式数据运营支持超级增长

3.4. 即使拥有了技术层面上准确的数据，在建立整个公司范围内的数据可观测性和对数据的信任时，数据分析师、技术领导者和下游利益相关者之间的良好沟通也是至关重要的

3.5. 专注于寻找最适合公司业务需求的方案，而业务需求很可能随时间推移而改变

3.6. 雇用数据综合专家而不是专门人才

3.6.1. 有一个例外

3.6.1.1. 应当聘用的专家是数据工程师

3.6.1.2. 数据团队常常因缺乏创建并维护ETL管道所需的技术支持而束手无策，同时也无法确保其底层的数据基础设施能够根据公司的分析需求进行扩展

3.6.2. 从第一天起就优先构建多样化的数据团队

3.6.2.1. 团队多样化的好处是不言而喻的，但当你为团队的长期成功建立基础时，你需要尽早开始招募拥有不同经验和背景的候选人

3.6.2.2. 与管理层和人力资源团队合作编写工作描述，使其对不同的经验和背景都具有包容性

3.6.2.3. 组建多元化的招聘小组，即使小组成员并不来自数据团队也没关系

3.6.2.4. 广泛招募候选人，即使他们并不拥有传统意义上的数据类头衔或职位

3.6.2.5. 实施一个完全不考虑性别和种族因素的招聘流程，只根据候选人的资格和经验进行筛选

3.6.2.6. 在创业后期才开始构建多元化的团队可能会更加困难，因为来自多元化背景的人们会更想加入背景多元化的团队

3.7. 过度沟通反而是改变管理模式的关键

3.7.1. 雇用沟通能力强的人才，一切都会变得更容易

3.8. 不要过度看重“单一真相来源”

3.8.1. “单一真相来源”或“黄金数据”是一个非常强大的概念，而这是有道理的

3.8.2. 努力实现评估指标的协同和始终如一的干净数据可以帮助公司对数据产生信任，并相信数据在指引他们朝着正确的方向前进

3.8.3. 二八定律才是关键

3.8.3.1. 数据常常是杂乱无序的，很少会完美无缺

3.8.3.2. 如果你优先考虑对数据健康状况进行端到端的观察，而非精细入微的控制，那么你的工作效率就能够大幅提高

4.1. 以一种能够为组织带来价值和影响的方式对数据进行解读、编纂和沟通的能力

4.2. 好的数据素养战略会利用自助式工具并培训非技术团队成员，来增加数据的可访问性和可操作性，并获得公司内部自顶向下的认可和自底向上的采用

4.3. 要实现“数据流利性”，数据经理们应当兼顾数据素养的推广并对利益相关方就数据质量的价值进行培训，因为这两者都很重要

4.4. 在长期可持续地实施数据质量计划并保证数据团队取得成功的过程中，最大的障碍是缺乏文档记录

4.4.1. 太多的团队依赖于口口相传而非落实到文字上的知识和过时的维基页面来追踪数据，这根本不能实现规模化地运作，也不是一个可持续发展的方案

4.5. 缺乏关于数据和元数据的健壮信息是数据团队的主要痛点之一

4.5.1. 数据目录

4.5.2. 数据库管理系统

4.5.3. 数据建模工具

4.5.4. 运营分析仪表板

5.1. 数据治理指的是在组织内外对数据进行管理的过程，它也是许多数据领导者们的头等大事，特别是GDPR、CCPA、IPO、COVID-19或者任何其他缩略语

5.2. 数据治理是保障数据的有效性、可用性、来源和安全性的过程

5.3. 数据治理之所以声名狼藉，主要是因为传统的方法无法满足基于云端的数据栈需求

5.4. 优先考虑数据目录

5.4.1. 数据目录一直被数据团队用于存储并编纂关于数据使用及其位置的元数据

5.4.2. 手工数据目录和元数据管理平台曾经一度是数据治理的默认方法

5.4.3. 随着数据系统的演变，我们发现这些方法已经无法跟上数据增长和跨领域数据分布的步伐

5.4.3.1. 内部解决方案

5.4.3.1.1. 内部解决方案的最大优点是，能够通过提取团队最需要的数据字段，快速创建定制化的仪表板

5.4.3.2. 第三方工具

5.4.3.2.1. 在过去，数据目录一向是手动、分散地进行管理的，而这通常需要不同分析师和数据科学团队之间的重复工作

5.4.3.3. 开源技术

5.4.3.3.1. 数据发现和元数据引擎Amundsen

5.4.3.3.2. Apache Atlas

5.4.3.3.3. Magda

5.4.3.3.4. CKAN

5.5. 实施数据治理

5.5.1. 填补治理漏洞是一项艰巨的任务，没有对公司实际访问数据资产的全部了解，就无法优先解决治理漏洞问题

5.5.2. 数据沿袭和可观测性有助于填补这些漏洞

5.5.3. 数据的可访问性和安全性也是数据治理的重要功能组成部分，特别是对于使用分布式分析团队模式或敏感的第三方信息的企业

5.5.4. 数据治理也是一种文化上的转变

6.1. 让领导层对数据质量最终负责

6.2. 设定数据质量的KPI

6.2.1. 避免在数据质量的评估上用力过猛

6.2.2. 简单的措施才是好用的

6.3. 带头实施数据治理计划

6.4. 自动化数据沿袭与数据治理工具

6.4.1. 随着关于数据访问和应用的管理措施的日益严格，以手动方式监控数据质量来进行数据治理已经不能满足需求了

6.4.2. 手动数据质量监控不仅烦琐耗时，其技术水平也在创新程度方面落后于数据栈的其他部分

6.4.3. 采用能够对数据质量问题进行快速验证、监控和预警的自动化工具，来取代手动的解决方案

6.5. 创建沟通计划

6.5.1. 制定一个健壮而全面的项目级别沟通计划，来帮助领导层了解项目进展，让利益相关方与计划保持同步，并让数据监管者了解其工作任务

6.5.2. 好的沟通计划是双向的，可以让所有相关人员都了解重要可交付目标的情况

6.5.3. 数据质量战略的目标是：确保全公司的所有团队都能有信心使用可靠的数据

6.5.4. 对于数据方面的一切任务，从扩展高效的数据团队到构建优秀的数据平台，一个健壮而全面的数据质量战略都能起到决定性的作用

7.1. 将数据视为软件产品并认真对待

7.2. 组建一个能在源头上优先考虑数据质量的数据团队

7.3. 以数据素养为首要目标

7.4. 采用能够大规模实施数据治理的流程和技术

7.5. 越来越多的公司正在聘用数据可靠性工程师、数据可观测性专家和数据素养官来带头开展这些数据质量计划，让数据工程师和分析师们能够更轻松地在日常工作中使用数据质量的最佳实践