From Data to Value: Understanding Data Management Through a Real World Use Case [Full Book]

[email protected]

8A4F2C91B7E03D6A...

ES12 3456 7890 1234

D91B70E4A62C8F15...

Password123!

$argon2id$v=19$m=65536,t=3,p=4$...

| 学生电子邮件地址 | ```
[email protected]

| 学生全名       | ```
Lucía García

| 学生家庭地址   | ```
Calle Mayor 24, Madrid

| 学生出生日期   | ```
18/04/2001

| 内部学生标识符 | ```
STU-45821

脱敏、伪匿名化和匿名化在某些实现中存在重叠，但它们不能互换。单独的脱敏并不能保证数据集是匿名的。伪匿名化用代码替换标识符，同时保留将这些代码重新连接到个人所需的信息。由于重新识别仍然可能，伪匿名化数据仍然是个人数据，需要保护。匿名化需要将识别风险降低到人们不再通过合理可能的方式被识别的程度。

在这种情况下，数据管理员决定哪些数据应被隐藏以及原因，而安全团队和数据工程团队则在底层实现这些决策。

### 隐私控制

前面的技术有助于防止未经授权的访问。隐私控制则解决另一个问题：组织是否有处理个人数据的有效目的和适当规则。

隐私设计（Privacy by Design）和默认隐私（Privacy by Default）原则从一开始就将隐私作为系统的一部分，并设置隐私保护的默认值。一个基本控制是数据最小化，这意味着只收集实现目的所需的必要信息。例如，注册表单不应要求完整的医疗历史，除非特定服务和合法目的证明其必要性。

其他控制适用于数据的用途及其保留时间。因此在使用案例中，学生的个人数据不应保留超过必要时间，或未经授权用于其他目的（如个性化营销活动）。

在欧洲，GDPR 设立了指导这些控制措施的原则和要求。组织还必须识别其在每个运营地区适用的规则。当适用时，数据保护官（DPO）负责监督和提供合规建议，而数据所有者、隐私专家、安全团队和系统设计者则将这些要求转化为实际的控制措施。

### 审计与合规

组织必须能够证明其控制措施和政策有效。独立审计会审查现有证据，并测试控制措施是否按预期运行。合规性涵盖持续满足内部政策、标准、合同义务和适用法规的工作。

日志是审计证据的重要来源。它们可以记录谁访问了数据、何时访问、从哪个系统访问以及采取了什么操作。团队会保护这些记录免受篡改，并根据风险、法律需求和成本，在规定期限内保留这些记录。安全信息和事件管理（SIEM）平台会集中来自不同系统的事件，并能对异常行为生成警报。

例如，如果一位教师偶尔查看其课程中学生的记录，这种行为可能是合法的。但如果他们在夜间从另一个国家下载与自己无关的数百份学生记录，应向安全团队发出警报以调查该事件。

审计可能会分析日志，测试身份是否拥有过多权限，并审查团队如何应用加密和其他控制措施。独立审查员和职责分离有助于防止同一管理员同时控制系统并管理用于评估其行为的证据。

涉及的角色包括首席信息安全官（CISO）、数据保护官（DPO）、数据所有者、数据管理员以及合规和审计团队。总之，安全和隐私要求了解数据的存在情况、限制使用数据的人员范围、通过控制措施保护数据，并保留所有这些措施正确执行的证据。

### 安全运营（SecOps）

数据安全是一项持续性工作。除了政策和加密机制外，SecOps（安全运营）将人员、流程和技术结合起来，实现持续防御。

SecOps 团队负责监控系统、检测威胁、调查警报并应对事件。他们试图在早期降低风险，同时保持对仍可能发生事件的应对和恢复能力。

在大学环境中，SecOps 团队负责实时监督数字生态系统。例如，如果 SIEM 因教师在夜间下载数百份学术记录或从事其他类似可疑活动而生成警报，SecOps 分析师将收到通知，评估风险并采取行动，例如临时阻止访问作为预防措施。

SecOps 团队还可能协调虚拟校园和其他系统的漏洞扫描和修复工作，以便在攻击者利用这些漏洞之前解决弱点。

在 SecOps 中，关键角色包括 SecOps 工程师和安全分析师，他们与首席信息安全官（CISO）合作定义和实施防御策略。这些专业人士依赖 SIEM 平台集中事件信息，并使用 SOAR（安全编排、自动化和响应）工具对常见威胁进行自动化响应。

## 数据架构

一旦明确数据决策者及其保护方式，仍需组织存储、传输和处理数据的系统。

数据架构设计满足这些需求的结构。当组织定义数据目标后，架构将展示系统如何存储、传输、保护和分析数据。

这种能力将业务目标与技术实现连接。它超越了选择数据库或绘制数据流管道的范畴：设计需明确组织所需的数据、数据所在位置、数据之间的关联以及数据的流动方式。该工作可产出数据模型、流程图、标准及其他架构决策。

在此用例中，候选人在注册时可能在网页表单中输入家庭地址。这些数据随后可能发送至招生系统，并用于向地理API发起查询以计算到校园的距离。此外，这些数据还可与其他系统（如课程表系统）中的数据结合，用于验证是否符合申请交通服务的资格。

在此场景中，数据架构负责设计完整数据旅程的实现方式。

设计不良的架构可能以多种方式失效。系统可能错误交换数据或停止通信，中断用户服务。即使没有直接故障，团队可能不必要的重复数据，增加成本并使集成更加困难。良好的架构可降低这些风险并明确权衡取舍。

企业数据架构师维护组织整体视角，而数据架构师和解决方案架构师则将其适配至特定解决方案。数据建模师、数据工程师、数据管理员、数据所有者及安全专家则贡献设计细节并协助将架构落地实施。

简单来说，架构师设计并记录解决方案，工程师和开发人员负责实现，而数据所有者和数据管理员则明确数据的含义、规则和责任。

### 企业数据架构

数据架构最广泛的层次是企业数据架构，即组织整体视角下数据应如何组织、连接和治理。

在大学中，企业架构提供系统协调方式的全面视图，明确每个系统应承担的职责以及系统间信息交换的方式。

例如，候选人完成流程的网页应用必须与招生系统或存储相关信息的数据库正确连接。该数据库或系统还可支持其他内部系统的运行，这些系统专门用于根据隐私政策分析数据或其部分数据。

此工作由企业数据架构师主导，CDO（首席数据官）提供支持，确保架构与数据战略保持一致，其他角色如应用架构师或安全架构师也参与其中。此外，数据所有者验证架构是否满足其领域的需求。

### 数据领域

数据领域是组织架构的重要组成部分。并非所有数据描述业务的相同部分，因此团队将相关概念分组，以使数据更易于组织、理解和治理。

数据域是一个包含相关组织概念和数据的逻辑区域。大学可能会为学生、教职员工、财务和流动性等定义数据域。通过这种方式对数据进行分组，可以更清晰地表达其含义，并帮助组织为每个数据域指定数据所有者。

此外，数据域并非与其他域完全隔离，因为数据通常需要上下文关联，即使它属于不同的域。例如，交通服务可能需要来自流动性域的数据，以及另一个域中课程表的信息。

每个受管理的数据域都应指定一个具有适当决策权限的数据所有者。数据架构师帮助设计域边界和关系，团队可以将这些内容表示为概念模型，并在数据目录中进行文档记录。

### 数据流

一旦明确了数据域和系统，团队将设计数据在它们之间流动的方式。数据流记录了数据源、涉及的系统和流程、应用的转换以及最终的存储或消费点。

可以以多个层次描述数据流。高层级的图表可能显示数据从一个域流向另一个域。实现视图会命名涉及的系统，而更详细的设计则可以展示每个消费者所需的字段、接口和转换。

在大学录取候选人的过程中，主要流程可能如下：

- 候选人访问注册门户并填写个人、学术和联系方式等信息的表格。

- 注册门户验证必填字段和数据格式。然后，它通过API将申请发送到招生系统。

- 招生系统创建候选人的档案，并将身份证件、学历证书和证明文件等存储在文档数据库中。

- 当申请获得批准后，招生系统生成录取通知，候选人通过注册门户查看并接受该通知。

- 门户会查询学术管理系统以显示课程、时间表和可用名额，允许候选人选择选项并确认注册。

- 支付系统将交易发送到外部支付网关。网关返回支付状态，例如已授权、已拒绝或待处理。大学仅存储交易及其结果的参考信息。

- 如果支付成功，学术管理系统创建最终注册，并将候选人的档案转换为学生档案。

- 接下来，系统更新身份平台、虚拟校园和计费系统。学生收到其凭证、付款收据和注册确认信息。

- 最后，必要数据可以被去标识化，并通过数据管道发送到分析平台，在该平台中计算并显示申请、录取、付款和注册的统计信息，并在仪表板上展示。

一些数据流动需要接近实时的响应，尤其是在交通服务中，而其他数据流动可以在稍后以批量方式运行。数据流应明确说明这些时间要求。

数据架构师负责设计流程并决定哪些组件参与，而数据工程师负责实施。但安全架构师也会参与，他们在流程中审查数据保护措施，数据所有者则授权不同领域之间的数据交换。最后，需要强调数据血缘工具在维护、监控和审计流程中的重要性。

### 操作数据架构

架构中的系统服务于不同目的。区分日常运行系统和主要用于分析的系统是有用的。

第一类系统构成操作数据架构。该领域涵盖维持组织日常运行的系统。联机事务处理（OLTP）系统处理频繁的运营事务，并使用有助于保持数据完整性和一致性的控制机制。

大学的操作架构可能包括虚拟校园、应用服务和数据库。门户通常会使用应用或服务层，而不是直接向用户的浏览器提供数据库访问权限。这些组件支持日常数据的捕获和管理，而不是进行长期的历史分析。

也就是说，操作数据库可以作为授权的数据源，例如了解注册状态的当前情况。然而，它并不是最适合持续运行多年活动的复杂查询以生成统计数据的地方，因为这些操作可能会消耗日常运营所需的资源。因此，用于研究趋势、比较项目或创建仪表板的数据由架构的另一部分处理，这部分将在后面解释。

对于这类信息，通常使用关系型数据库如PostgreSQL或MySQL。但应根据操作量、预期可用性、现有基础设施以及其他要求（如最大响应延迟）选择具体技术。

解决方案架构师或数据架构师设计操作架构，软件工程师构建应用组件，数据工程师则帮助定义和实现它们之间的数据交换。

### 分析数据架构

虽然操作架构处理日常活动，但分析数据架构支持历史数据的集成、聚合和研究。其系统帮助团队创建报告、发现模式，并为AI模型准备数据，而不会对操作服务造成不必要的分析负载。

在大学中，这种架构可用于整合课程表、出勤率和预算数据，使分析师能够计算每个硕士项目的月度支出或不同时间段学生出勤率的变化。同样，数据科学家可以使用历史数据来估算未来交通服务的需求。

典型的分析流程使用ETL或ELT（我们将在下面详细讨论）从多个来源获取数据。团队随后在将数据加载到专用系统（如数据仓库）之前或之后对其进行转换。结果为商业智能工具和机器学习工作流提供了合适的数据，而不会与虚拟校园直接竞争相同的运营资源。

在这一领域，数据架构师或分析架构师负责设计架构中的分析组件。同时，分析工程师和数据工程师设计数据处理流程，为数据分析师或数据科学家准备分析数据。

### 云与混合数据架构

架构还决定了组件的运行位置：在云端、本地部署，或两者兼有。云数据架构利用云计算、存储、数据库和分析服务。这些服务可以简化扩展性并减少对物理硬件的管理需求，但组织仍需配置安全措施、控制成本并治理数据。

另一方面，混合数据架构将本地系统与云服务结合。当组织希望保留现有应用在自己的数据中心，但又想利用云的弹性或分析服务时，这种方案较为常见。

为理解混合架构的动机，以大学为例，学术系统和包含记录与支付信息的数据库可能最初保留在内部基础设施中，以防止第三方访问这些数据。但一些经过脱敏的数据可以发送到云分析平台，以获取虚拟校园使用情况或学术指标的统计信息。

然而，将部分数据保留在本地并不自动保证更高的安全性，正如使用云服务也不意味着必然失去控制。决策应考虑数据敏感性、延迟、可用性、可扩展性以及每种解决方案的总体成本。

在此设计中，企业数据架构师和数据架构师参与其中，云架构师也参与其中，云架构师专门研究云服务，以在架构中正确使用它们。

网络工程师、云工程师和数据工程师也参与其实施，而数据保护官（DPO）和数据所有者必须审查哪些数据可以离开内部基础设施以及其用途等问题。

## 数据建模与设计

数据架构定义了哪些系统管理数据以及它们如何交换数据。数据建模与设计则具体说明这些系统如何表示信息。它确定对组织重要的概念，并描述它们的属性、关系和规则。

数据模型是对现实部分的简化表示。它为人们提供了一个共享的结构，便于理解并后续实施。例如，在创建大学数据库之前，团队需要定义候选人、学生、硕士课程和注册等概念，明确每个概念所需的信息以及它们之间的关系。

团队通常在三个层次上描述设计：

- 包含主要业务概念的概念模型，
- 不依赖特定技术而增加细节的逻辑模型，
- 与特定平台中的结构映射的物理模型。

随着团队对需求了解的深入，每个模型都可以不断发展。

数据建模师负责主导设计，并与数据架构师协作，将其融入更广泛的架构中。数据所有者、数据管理员、业务分析师和领域专家明确概念和规则的含义。数据库管理员（DBA）、数据工程师和软件工程师则参与物理设计和实现。

### 概念数据模型

概念数据模型为组织的数据提供了高层视图。它展示了主要的业务概念及其关系，而不涉及存储或格式等技术细节。

例如，如上图所示，在大学中，概念模型会包含候选人、学生、课程或注册等概念。（请注意，这是为了帮助您更好地理解概念模型而绘制的草图，并非用于实际生产的图表。）

在此层次上，只需说明每个概念的含义及其与其他概念之间的关系，例如学生申请注册或注册包含一组课程。目标是让技术团队和学术领导者在设计具体解决方案之前，对同一现实达成共识。

该模型通常通过与数据所有者、数据管理员、业务分析师和领域专家的访谈或研讨会来开发，这些人员由于任务性质通常不具备很强的技术背景。在此过程中，数据建模师或数据架构师会创建模型图，并验证这些概念是否与业务术语表一致。

### 逻辑数据模型

逻辑模型在概念模型的基础上进行更详细的展开，同时保持与特定技术的独立性。它定义了实体、属性、标识符、关系、基数和其他业务约束。

例如，学生实体可能具有ID、姓名、电子邮件和地址等属性。学生可以注册多门课程，而一门课程可以有多个学生。这种多对多关系可以在逻辑层面通过一个名为注册的中间实体来表示，该实体可能包含日期、状态或学年等属性。

人们通常将逻辑模型与关系型数据库相关联，但逻辑模型不一定使用这种范式。可以将其视为一种与技术无关的信息及其连接的规范，尽管不同范式以不同方式表示实体和关系。

这些关系模型可以进一步优化。例如，在关系型数据库中，其逻辑模型可以通过规范化来减少重复和错误依赖。但在其他范式或解决方案中，流程会截然不同。如前所述，该模型的设计由数据建模师与数据架构师协作完成。

### 物理数据模型

物理数据模型将逻辑设计映射到特定技术。例如，在关系型数据库中，它会将逻辑实体和关系转换为表、列、键、约束、分区以及索引等低级结构，这些结构通常使用B树。

在大学中，学生记录可能存储在关系表中。数据库管理系统决定如何存储表本身，而团队可以在选定的列上创建索引（通常是B树索引），以加快常见查询的速度。

可想而知，相同的逻辑模型可以生成不同的物理模型。例如，学术系统可以使用PostgreSQL或MySQL实现。因此，物理设计必须考虑预期使用的数据库管理系统、数据量、查询模式、安全性、可用性和运营成本，以提供有效的解决方案。

在此设计阶段，数据建模师或数据库设计师、数据架构师和数据工程师主要与软件工程师协作，共同实现解决方案。

### 实体-关系建模

实体-关系图是表示关系概念的常用方式。根据包含的细节程度，它们可以支持概念模型或逻辑模型。实体通常用矩形表示，而线条则表示关系、基数和可选性。

例如，一个学生可以有多个注册记录，而每个注册记录只属于一个学生。相比之下，Student（学生）和Course（课程）之间的关系是多对多的，因为一个学生可以同时注册多门课程。

还需要识别键来区分实体的每个实例，并维护其关系的完整性，以及其他在此处不太相关的细节。

如果你感兴趣，可以在这里阅读我之前书籍中关于数据库设计的更多内容。

### 维度建模

另一个特别适用于数据仓库和分析系统的有用方法是维度模型。这些模型围绕事实和维度组织数据。事实记录可衡量的事件，而维度提供用于分析这些事实的上下文。

例如，在运输服务中，你可能会有一个名为Trip（行程）的事实表，其中包含每段完成旅程的行，记录诸如成本、距离和持续时间等度量值。但与将旅行者数据存储在同一个表中不同，它会与其他表示维度（如Student（学生）、Date（日期）或Transportation Provider（运输提供商））的表相关联。因此，事实表建模行程的存在，而其他维度表则包含每次行程的具体数据，如人员或运输提供商，从而形成一种称为星型模式的结构。

这种模型主要用于简化分析查询，并允许从不同“视角”研究同一事实。例如，大学可以通过按月、学生或提供商计算行程总成本，而无需构建过于复杂的查询。

### 数据模型治理

数据模型也需要治理，以确保其保持一致、最新并与实现保持一致。团队应维护概念设计、逻辑设计和物理设计之间的联系，因为每个设计都会发生变化。

一旦团队批准了一个模型，实现应遵循它或通过受控变更进行更新。预期模式与实际模式之间的意外差异通常称为模式漂移。

例如，大学的模型可能定义了一个数值年龄字段，而实现却将其存储为文本。这种差异看起来可能很小，但如果下游系统依赖约定的类型，可能会导致系统失败。团队应检测并控制模式变更，以确保模型、合同和实现保持一致。

数据治理委员会或架构审查委员会可能会审查重要的模型变更。数据所有者确认设计反映了业务规则，而数据库和工程团队则通过受控流程实施已批准的变更。

## 数据存储与操作

数据模型指导实现存储数据的系统，使数据能够持久化并提供给应用程序和其他系统使用。团队需要选择合适的存储技术，在需要时保持数据的可访问性，并以可接受的性能水平运行系统。

数据存储与操作涵盖了存储系统在其整个生命周期中的设计、实现和操作。这包括选择数据库、文件系统和对象存储，然后进行维护、监控和优化。正如你将看到的，数据库并不是所有类型数据的最佳存储方式。

数据架构决定了组织需要哪些系统以及它们如何通信。数据建模规定了它们如何表示信息。数据存储与操作将这些设计转化为实际的存储系统。例如，物理模型可能说明Student实体映射到带有student_id字段B树索引的PostgreSQL表。本节重点介绍如何实现和操作此类设计。

数据存储的主要目标是保持系统的可用性、完整性，并确保良好的性能。为了实现这些目标，组织不应始终使用单一技术来存储所有数据，因为例如注册信息或课程视频的数据结构、使用方式和需求差异很大。因此，同一组织通常会结合使用不同的存储系统。

| 需求 | 示例数据 | 最常见的系统 | 示例技术 |
|------|----------|--------------|----------|
| 记录当前运营状态 | 学生、注册信息、支付和交通请求 | 操作型数据库 | PostgreSQL、MySQL、SQL Server、Oracle Database 或 MongoDB |
| 存储大型文档和内容 | 学术证书、支持文件、材料和视频 | 文件存储或对象存储 | NFS、SMB、Amazon S3、Azure Blob Storage、Google Cloud Storage 或 MinIO |
| 分析集成和历史信息 | 月度出行成本和出勤趋势 | 数据仓库 | Snowflake、BigQuery、Amazon Redshift、Azure Synapse Analytics 或 Teradata |
| 存储用于高级分析的数据 | 原始提供商文件、事件和虚拟校园日志 | 数据湖或湖仓一体架构 | 对象存储、Parquet、Delta Lake、Apache Iceberg、Spark 或 Trino |

团队应根据预期的数据量、访问模式、敏感性、可用性、成本和其他需求来选择技术。每增加一种技术都会增加运营复杂性，因此每种技术都应解决实际问题。

数据库管理员负责创建、配置、保护、调优和维护数据库。存储管理员管理底层存储，而站点可靠性工程师和平台团队则监控服务并响应可靠性事件。具体的工作分工取决于平台和组织的架构。

### 数据库

数据库是应用程序可以存储、修改和查询的有组织的数据集合。数据库管理系统（DBMS）是管理数据库并提供查询、并发、安全、恢复和管理服务的软件。PostgreSQL就是一个DBMS。大学的学术数据库将是由PostgreSQL服务器或服务管理的特定数据库。

运营系统通常需要事务支持，尤其是在注册和支付等流程中。事务将相关操作组合成一个逻辑单元。ACID属性（原子性、一致性、隔离性和持久性）描述了帮助应用程序在发生故障和并发访问时保持有效状态的保证。

例如，在进行支付操作时，需要在多个与用户资金交换相关的位置修改数据。因此，事务的原子性可以确保所有这些修改同时生效，如果其中任何一步失败，系统会回滚以保持之前的状态。

数据库设计在数据模型、规模、一致性、延迟和访问模式之间需要做出不同取舍。正因如此，才存在多种数据库范式：

| 范式         | 特点                                                                 | 使用场景示例                                                                 | 技术示例                          |
|--------------|----------------------------------------------------------------------|------------------------------------------------------------------------------|-----------------------------------|
| 关系型       | 将数据组织到关联表中，使用预定义模式，支持键、约束和事务                       | 管理学生、课程、注册信息、发票和交通请求等，当关系和完整性要求较高时             | PostgreSQL、MySQL、SQL Server、Oracle Database |
| 文档型       | 将信息分组为文档（通常类似JSON格式），可包含嵌套结构并能更灵活地演化           | 存储来自多个提供方的表单数据，当它们提交的字段不完全一致时                       | MongoDB、Couchbase                |
| 键值型       | 通过唯一键检索值，优先支持简单快速的访问模式                                 | 维护门户会话、临时结果或高频查询的缓存                                           | Redis、Amazon DynamoDB          |
| 图形型       | 通过节点和关系表示数据，可高效遍历复杂连接                                   | 分析学生、课程、讲师、交通路线或服务之间依赖关系等                               | Neo4j、Amazon Neptune、ArangoDB |

这只是几种数据库范式的示例。大学可以使用PostgreSQL作为学术系统，通过表和关系管理学生、注册信息和课程记录。对于特定路线或网络分析，图形型数据库可以将位置表示为节点，连接表示为边。运营中的出租车服务本身可能仍使用关系型或其他事务型存储，具体取决于其访问模式。

数据架构师和数据建模师会根据工程师提供的输入，选择数据库范式并进行设计。系统上线后由数据库管理员负责维护。在此之前，数据库工程师会实现物理模型，创建实例、模式、表和其他必要元素以支持后续环境运行。软件工程师则开发访问这些数据库并执行查询的应用程序。

### 文件和对象存储

并非所有数据都适合存储在数据库中。大学需要管理学位证书、身份文件和大型文件（如课堂录音）。虽然数据库管理系统可以存储二进制内容，但文件或对象存储通常能为这些资产提供更合适的访问方式、扩展性和成本特性。

**文件存储**通过目录组织文件，并通过路径和协议（如NFS或SMB）进行访问。团队可以通过网络附加存储（NAS）系统或云服务（如Amazon EFS或Azure Files）实现该功能。

**对象存储**将内容作为带有标识符和元数据的对象存储，通常存放在存储桶或容器中。其命名空间和访问模型与挂载的分层文件系统不同，即使工具显示类似文件夹的前缀。Amazon S3、Azure Blob Storage和Google Cloud Storage等服务可以存储大量文档、图像和视频。

主要区别在于访问模型。文件存储的表现形式类似于共享文件系统，而应用程序通常通过 API 使用对象键和元数据访问对象存储。

例如，大学可以使用文件存储将每个学生的注册信息和证书等行政文件保存在共享文件夹中。这样，授权人员可以像在传统文件系统中一样管理这些文件。

另一方面，它也可以使用对象存储在存储桶中存储大量课程录像、图片和多媒体资料。系统无需通过文件夹导航定位视频，而是可以直接通过其标识符或通过元数据过滤来检索。

负责配置和操作这些系统的角色主要是存储管理员、云工程师和平台工程师，而软件工程师则负责从其他应用程序实现对这些系统的访问。

### 数据仓库

操作型数据库通常针对当前事务和应用程序查询进行优化，而不是针对多年整合历史的重复分析。复杂的分析工作负载也可能与使用相同资源的应用程序竞争。因此，组织通常会将合适的数据复制到独立的数据仓库中。

数据仓库是一个分析型存储库，它从多个来源集成数据，并将其组织用于可重复的分析、报告和仪表板。这些系统支持在线分析处理（OLAP）工作负载，可以扫描和聚合大量记录，这与操作型应用中常见的在线事务处理（OLTP）工作负载形成对比。

这种差异通常会影响存储设计。许多数据仓库使用列式存储，因为分析查询可能需要跨大量行扫描少量列。例如，计算按日期划分的出租车行程总费用时，引擎可能只需要费用和日期列。

许多操作型关系数据库使用行式存储，因为它可以高效地检索或修改完整记录。这些是常见的模式，而非普遍规则。具体产品可以支持多种存储格式。

在实际应用中，大学可能拥有一个数据库和一个数据管道，数据会定期从中提取并插入到数据仓库中。在那里，可以应用之前提到的维度数据模型来分析数据，使分析师能够回答诸如以下问题：

- 某门课程每位学生的平均月成本是多少？
- 在特定时期内，面对面参与度发生了怎样的变化？
- 上个月有多少学生注册？

重要的是要理解数据仓库不会取代数据库。相反，它是一个专注于数据分析的辅助系统。用于这些系统的可用技术包括 Snowflake、Google BigQuery 或 Amazon Redshift 等云平台。

与这些系统合作的角色包括数据架构师或分析架构师，他们设计分析平台，而数据工程师则设计用于提取和加载数据的管道。

数据仓库管理员或平台工程师负责管理性能、权限、可靠性和成本。数据分析师和商业智能专业人员可以查询受控的分析数据，而不会更改操作型源记录。

### 数据湖和湖屋

传统数据仓库采用预定义的模式，对已知或预期的分析需求进行数据组织。

但实际情况并非总是如此，因为组织可能还需要保留原始文件、半结构化数据、日志、图像或事件，这些数据的未来用途尚未完全明确。

针对这些情况，我们可以使用数据湖，它是一种设计用于以原始格式或经过最小转换方式存储大量数据的存储库。

数据湖同样支持分析和数据处理需求，但它在数据摄入时可以保留结构化、半结构化和非结构化数据，且转换次数更少。它通常与“读时结构”相关联，即查询或处理任务会应用部分结构，而传统数据仓库通常在加载经过整理的数据之前使用“写时结构”。

“读时结构”并不会消除对元数据、安全、质量和治理的需求。缺乏这些要素，数据湖可能会演变成“数据沼泽”。

为了理解数据湖中信息的组织方式，在大学的用例中，数据可以根据其就绪程度分层处理。

- 在系统特定区域，数据可以以原始格式（如CSV或JSON文件）保存，未经修改。这允许在后续发现转换错误或需要其他类型分析时重新处理信息。

- 在另一区域，数据可能采用不同格式，或使用相同格式但经过特定转换，例如删除无效记录或标准化计量单位。

- 在精选区域，团队可以进一步应用质量检查和转换，直到数据满足仪表板需求，并预计算选定统计信息。

这种分层方式并不意味着所有原始数据都会无限期保留，因为必须遵守隐私、安全和保留政策。

例如，大学可能在录取过程中临时存储候选人的提交文件。但如果候选人被拒绝且已过足够时间，大学必须删除这些文件，即使已生成衍生的匿名数据用于录取过程的统计分析。

湖仓一体架构为数据湖常用的灵活存储增加了事务处理、模式强制和表管理等能力。它可以让多个分析工作负载共享同一数据基础，尽管并不能消除使用专用系统的所有原因。

构建湖仓一体架构所使用的部分技术包括Delta Lake、Apache Iceberg和Apache Hudi。这些技术定义了通常存储在Amazon S3、Azure Blob Storage或Google Cloud Storage等服务上的数据格式，并使用Apache Spark、Databricks或Trino等工具进行处理。

在大学的案例中，湖仓一体架构可用于集中存储学生数据、注册信息、出勤记录和出租车行程。这样，大学可以安全地更新这些数据，并直接用于生成报告，例如每月交通费用或上课学生人数，而无需依赖独立系统。

最后，负责设计和实现这些系统中从不同来源进行数据摄取的是数据工程师。另一方面，平台工程师管理基础设施，而分析工程师与数据科学家一起使用数据进行相关分析和研究。

### 备份与恢复

即使设计良好的存储系统也可能因硬件故障、软件缺陷、数据损坏、人为错误或攻击导致数据丢失。这就是为什么在生产环境中备份与恢复至关重要。

备份是为应对数据丢失或损坏场景而保留的可恢复数据副本。只有当组织保护备份、验证备份并测试恢复过程时，备份才有价值。常见机制包括：

- **完整备份**：复制整个数据集。例如，大学可以每周对注册数据库进行完整备份。虽然这简化了恢复过程，但需要更多时间和存储空间。

- **增量备份**：仅保存自上次备份以来的更改。在完成月度完整备份后，可以每天仅复制修改后的注册信息。这减少了数据量，但恢复可能需要多个关联的备份副本。

- **快照**：捕获存储系统在某一时间点的状态。根据技术实现，快照可能共享底层存储，而非独立副本。例如，大学在进行重大学术系统变更前可以创建快照，同时仍保留其他独立备份以提供更强保护。

- **日志备份**：依赖变更日志的备份方式，允许在数据意外删除时将数据库恢复到之前的某个时间点。它更精确，但需要维护完整的日志序列。

- **复制**：维护整个系统的副本，主系统发生故障时可由副本接管。例如，备用数据库可以继续提供注册门户服务，从而提高可用性。但复制可能同时复制删除操作或错误，因此不能替代备份。

恢复策略通常围绕两个目标展开。**恢复点目标（RPO）** 表示可容忍的最大数据丢失时间范围，而 **恢复时间目标（RTO）** 则说明在影响变得不可接受之前，服务恢复可能需要的时间。

例如，大学可能在注册期间假设将注册数据库的 RPO 设为 5 分钟，RTO 设为 1 小时。这意味着在发生严重故障时，他们希望最多丢失 5 分钟的操作数据，并在 1 小时内恢复服务。相比之下，如果已发布的视频集合在其他位置存在耐久副本，可能允许更慢的恢复。

在设计备份解决方案时，一个广为人知的最佳实践是 **3-2-1 规则**，即保留重要信息的三个副本，使用至少两种存储介质或技术，并将其中一个副本异地保存。但应根据组织的具体需求定制解决方案。

数据所有者和业务领导者负责识别关键流程并确定可接受的数据丢失或中断范围。在技术层面，数据库管理员（DBA）负责实施和验证数据库恢复机制。此外，存储管理员和云/平台工程师管理存储并自动化备份，而站点可靠性工程师（SRE）则监控并执行测试，确保恢复功能按预期工作。

### 保留与归档

组织不应无限期保留所有数据。这样做会增加成本、使数据发现变得复杂，并放大数据泄露的影响。

保留策略应明确数据的活跃时间、归档时间以及删除或匿名化的时间。该策略需反映业务需求、合同义务、法律要求和适用的法律保留规定。

在此背景下，需要区分两个概念：

- **归档**：存储不再频繁使用但必须保持可访问的信息。例如，前学生的记录可能会被转移到成本较低的归档存储中，以便在申请证书时可能需要验证其存在性时使用。

- **保留**：定义数据的保存时长及期限结束后如何处理。例如，被拒绝申请者的个人和学术文件可能需要保留到录取流程和申诉期结束。之后这些文件将被删除，但大学可能会保留匿名的申请数量统计数据。

数据所有者、记录管理员、法律顾问和隐私专家共同制定保留期限。法律保留可以暂时暂停与调查或诉讼相关的信息的正常处理。因此，组织需要有书面理由决定保留或删除数据，而不仅仅基于数据是否看似有用。

随后，数据管理员对数据进行分类，DBA、存储管理员或云工程师实施相关策略。作为一种有趣的技术，一次写入多次读取（WORM）存储常用于必须保持不可更改的记录。

### 性能与可用性

存储和保护的信息必须在服务需要时可用，并满足约定的性能目标。性能描述响应时间、吞吐量等特性，而可用性衡量预期服务是否可被使用。

如果系统响应过慢，即使技术上正常运行也可能无法使用。系统在线时可能运行很快，但因频繁停机也可能无法满足可用性目标。团队需要同时管理这两个特性。

可提升存储系统性能的一些技术包括：

- 在确保索引本身的空间成本合理的情况下，对频繁查询的字段创建索引。

- 分析最频繁的查询或工作负载，尝试优化DBMS生成的查询计划。

- 尽可能引入缓存，特别是在需要多次使用结果时。

性能优化取决于系统和工作负载。增加硬件无法解决所有问题，因为软件设计同样重要。例如，不必要的流水线转换即使不导致停机，也会增加执行时间和成本。

另一方面，冗余常用于提升可用性。本质上，如果存在相同服务器或系统的副本，所有副本同时失效的可能性降低，从而避免终端用户无法使用服务。

可通过故障转移机制管理副本的存在，例如当PostgreSQL实例停止工作时，可自动且对终端用户透明地将流量重定向到另一个副本。

在大学注册系统的例子中，注册截止日前的最后几天，可能有数千名学生同时访问门户。为了保持良好的性能，请求会被分配到多台服务器上，避免任何单台服务器过载，并减少等待时间。此外，数据库可以设置副本，这样当一个实例发生故障时，另一个实例可以自动接管。

通过这种方式，系统在高需求期间仍能保持快速响应，并且在发生意外故障时仍能保持可用性。

为了衡量组织的性能和可用性目标，可观测性尤为重要。这包括生成指标、日志和统计信息，并使用Prometheus和Grafana等工具进行管理，以监控系统并在任何时间点检查其可用性和性能。

存储系统的分析和优化通常由DBA执行，但某些软件工程师和数据工程师也可能参与其中，通过优化数据管道来改进不同系统之间交换信息的方式。关于可用性，SRE（站点可靠性工程师）、平台工程师和云工程师会自动化部署、监控、扩展，并实施故障转移机制。

## 文档与内容管理

到目前为止，我们已经处理了多种类型的数据：表中的结构化记录、如JSON的半结构化数据，以及如扫描件、图片、视频和自由文本等非结构化内容。

文档可能包含结构化元数据和非结构化内容的混合，因此需要专门的管理方法。

文档通常不遵循严格的行和列结构，但仍然可以包含元数据，如标题、作者、类型、日期或标签。某些数字格式还包含内部层级结构。例如，JSON文档使用命名字段和嵌套对象：

许多数字文件会将内容与描述性元数据（如标题、作者或创建日期）结合在一起。这些元数据使内容更容易被识别、组织、保护和检索。文档与内容管理提供了实现这一目标的流程和系统。

在组织规模上，仅仅将文件放入文件夹是不够的。团队需要对文档进行分类、描述其内容、控制访问权限、跟踪版本和保留策略，并能够后续查找。基本的文件系统或数据库可以作为解决方案的一部分，但文档或内容平台会增加组织所需的管理功能。

例如，大学系统中一份文档的旅程可能如下：

- 候选人的学术记录通过表单、电子邮件或任何等效方式捕获。

- 它被索引并添加元数据以提供上下文。

- 它被存储在适当的存储库中。

- 经授权的用户和系统可以在适用的控制下访问或共享它。例如，招生分析师可以查询已批准的提取字段，统计在特定领域有先前学习经历的候选人数量，而无需手动打开每份证书。

- 最后，根据适用的政策，它会被删除或保留。

### 非结构化数据

组织管理的数据中，重要的一部分包含非结构化信息。这意味着，如上所述，其内容并未以清晰可识别且可直接查询的字段进行严格结构化。例如，PDF格式的动机信、扫描的文凭图像或合同可能包含难以结构化的信息。

文档可能包含特定于格式的元数据，如标题或创建日期。这有助于识别文件，但很少能完整描述文件内容。正文可能包含自由文本、图像、表格或其他内容，系统在回答详细查询前必须提取或索引这些内容。

为了对这些信息进行查询，系统会索引这些内容，或应用光学字符识别（OCR）、自然语言处理或智能文档处理等技术。

例如，如果大学想了解有多少申请人在进入硕士项目前修过相关数学课程，必须首先从学术证书中提取这些信息，进行标准化处理，并将其存储在可查询字段中。从文档中提取数据时，应保留与原始文档的链接，以便后续验证来源。

提取有用内容后，系统可以将其以优化搜索的结构进行索引。索引可能以字段或键值对的形式表示文档，例如候选人标识符、文档类型、所修课程和学科领域。

例如，上面展示了索引文档可能的形态。原始文件可能是候选人的学术证书，但对系统而言，它是一个包含这些信息的JSON字典，意味着文档的内部内容以分层结构组织。

以这种方式表示文档，使查询操作变得容易得多，因为可以导航并访问如“score”这样的字段，查看候选人在其他大学修读各门课程的成绩。

### 文档捕获

第一个操作步骤是文档捕获，即控制文档进入组织系统的流程。

在这些流程中，需要考虑待捕获文档的格式，因为它们不总是数字文件。通常，它们可能是提交给行政机构的纸质文件，然后需要进行数字化并上传到系统。

无论如何，假设数字化文档已到达数据管理系统，适当的捕获应至少执行以下操作：

- 验证文件格式和大小，并确保其不包含恶意软件。
- 为其分配标识符和基本元数据，如来源和接收日期，以及数字指纹（如哈希值）以检测文件变更。
- 保留原始文件，并在必要时提取其内容的可用表示形式。

如果文档是通过扫描获得的，其文本将以像素形式呈现，而不是直接可搜索的字符。OCR（光学字符识别）将可见文本转换为机器可读文本。更先进的智能文档处理（IDP）系统还可以通过规则和机器学习模型对文档进行分类，并提取字段、表格和布局。

例如，候选人可能通过手机上传一张用其他语言书写的文凭照片。捕获过程会检测语言，使用OCR提取所有对应文本，并将文件与申请关联，以便后续审核时能够确认文件归属。

### 文档分类

捕获后，系统可能需要对文档进行分类，以确定其类型并应用相应的流程、访问规则和保留策略。人们可以手动完成此操作，或者软件可以通过规则和机器学习辅助分类。

在某些工作流程中，大学可能允许用户附加证书、报告和其他支持文件。系统不能依赖文件名或假设所有上传文件都是安全的。它必须验证文件，根据安全策略扫描文件，并在进一步处理前识别文档类型。

仅凭文件名并不可靠：A.pdf 可能包含任何内容。分类会将文件归类为组织定义的文档类型之一，并确定下一步处理流程。团队可以自动化处理低风险案例，而将不确定或影响重大的案例转交给人员审核。

### 内容存储

在捕获和分类后，组织会存储原始文档及其元数据。对象或文件存储通常保存二进制文件，而像 MongoDB、Couchbase 或 Amazon DocumentDB 这样的文档数据库可能保存灵活的元数据或提取后的内容。正确的组合取决于访问、保留、搜索和扩展需求。

其他替代方案包括使用文档管理系统（DMS）或具有企业内容管理（ECM）功能的平台。这些文档存储库内部基于文件或对象存储，但提供了单个存储桶或文件夹无法提供的附加功能，例如高级元数据管理。最后，值得一提的是内容管理系统（CMS），它们专为在网站上创建和发布内容而设计。

### 搜索与检索

只有在授权用户和系统能够在需要时找到文档时，文档才有价值。在存储和索引后，平台可能支持以下几种搜索方法：

- 元数据搜索：通过字段（如 document_type = Academic Certificate）进行筛选。
- 全文搜索：在提取的文本中查找单词或短语，并对匹配文档进行排序。
- 语义搜索：根据含义检索文档，即使文档中没有包含查询中的确切词语。

例如，授权员工可以使用“合同”或某人的姓名作为关键词搜索特定教师的雇佣合同，即使他们不记得确切的文件名。此外，通过类似 Google 的语义搜索，他们还可以根据文档内容的含义定位该文档或其他任何文档。

### 记录管理

并非所有文档具有相同的价值或生命周期。团队可能会快速丢弃草稿，而某些活动或决策的正式证据则必须作为记录保存。记录管理在整个所需生命周期内控制这些记录。

与草稿不同，记录是一种必须保存并保持真实、完整和受保护的正式文件。例如，录取通知书的草稿可以被丢弃，而学生接受并签署的录取通知书则成为正式记录。

每种类型的记录都有相应的保存期限，规定必须保留的时间以及之后应采取的措施。如果存在调查或法律程序，可能会施加法律保留，暂时中止其处理。在大学中，官方课程记录或最终学术成绩单可能被视为记录。

总体而言，文档管理中最常见的技术和角色可以总结如下：

文档阶段

关键技术

角色

捕获

Azure AI Document Intelligence、Google Document AI、Amazon Textract、Tesseract OCR

软件和集成工程师

实现捕获流程，而

机器学习工程师

设计数据提取模型。

存储

OpenText Content Management、MongoDB

信息架构师

设计逻辑内容结构，而

平台工程师和ECM/DMS管理员

实施和运营存储系统。

索引和搜索

Elasticsearch、OpenSearch、Apache Solr

设计索引策略，而

搜索和软件工程师

实现搜索引擎和查询。

保留和维护

Microsoft Purview Records Management、Amazon S3 Object Lock

记录管理员、数据所有者和DPO

定义政策、规则和合规要求，而

安全与合规团队

实施安全机制并进行审计。

## 参考数据和主数据管理

组织在许多流程和系统中会重复使用某些数据。同一名学生可能出现在招生平台、虚拟校园和计费平台中。如果每个系统以不同的方式表示该人，很快就会出现重复和矛盾。

参考数据和主数据管理协调这些共享数据，使系统能够使用一致且可信的值。

首先，需要区分以下内容：

- 主数据：这描述了一个对多个流程相关且共享的实体。例如，学生Amélie Dubois的记录。

- 参考数据：这些是在主数据分类或组织中的允许值。例如，APPROVED可以表示已接受的入学申请状态，而申请人的记录被视为主数据。

目标不是将每一份数据强制放入一个数据库中。而是识别可信的值和记录系统，定义谁负责维护它们，并将正确的表示分发给每个使用者。

### 主数据

主数据代表核心实体，如人、组织、地点或产品。在大学中，它可能包括学生、教职员工和课程。可信的学生记录可能包含全局标识符、姓名和选定的联系方式属性，而敏感的支付信息则保留在需要它们的系统中。

但支付信息不会在所有涉及这些数据的流程中使用。这就是为什么授权数据需要分发到每个系统，使整个组织对数据有统一的视图，即使数据的使用方式不同。

### 参考数据

参考数据提供用于分类或组织其他数据的受控值。例如，大学可能允许交通请求具有状态 PENDING（待处理）、APPROVED（已批准）或 REJECTED（已拒绝）。如果应用程序使用不同的术语表示相同的状态，集成和报告将变得不可靠。这些经过批准的状态值即为参考数据。

这些值通常很少更改，但并非不可更改。例如，可能需要向分类中添加新的值，如 CANCELLED（已取消）。

要进行此类修改，数据管理员（Data Steward）会记录其含义，而对应数据领域的数据所有者（Data Owner）会批准更改。随后，集成工程师（Integration Engineers）负责将新值分发给使用该值的系统。

### 黄金记录

一个实体的信息通常会出现在多个系统中，每个系统仅存储其所需的部分信息。主数据管理（MDM）平台可以将选定的可信属性整合为一个统一视图，称为黄金记录（Golden Record）。其目标是提供一个受控且实用的表示方式，而非复制组织持有的所有信息。

例如，大学可能有一个招生系统，其中存储了学生个人信息（如姓名 Amelie Dubois），而他们的支付信息则存储在专门处理支付的系统中。在确认这些信息属于同一人后，可以将它们关联起来，为学生提供单一视图。

黄金记录并非自动完美或永久确定。它是在当前匹配和生存规则下可获得的最佳可信视图。

### 实体解析

要构建该视图，平台必须确定哪些记录指向同一现实世界实体。这项任务称为实体解析（Entity Resolution）。

例如，名为 Amélie Dubois 和 A. Dubois 的记录可能指向同一人，也可能指向不同的人。解析过程可以比较授权属性（如电子邮件、电话号码或出生日期），并应用确定性规则或概率匹配。由于错误匹配和遗漏匹配可能造成损害，团队应审查不确定的情况，并提供更正决策的方式。

该任务由 MDM 工程师（MDM Engineer）负责，而数据质量分析师（Data Quality Analyst）与数据管理员（Data Steward）一起分析并监督结果。该功能通过 MDM 平台内置的功能、AWS Entity Resolution 等服务或 Splink 等记录链接库实现。

### 去重

推动实体解析需求的另一个问题是重复数据的存在。例如，候选人可能使用一个电子邮件地址在虚拟校园注册，之后又使用另一个电子邮件地址申请入学。如果确认这两条记录属于同一人，应在每个具体场景中适当处理。

去重（Deduplication）是这一过程的名称，它涉及使用实体解析（Entity Resolution）来检测和管理重复记录，目的是防止这些记录被当作独立实体处理。常见方法包括链接（linking），它保留记录在原始系统中并创建它们标识符之间的对应关系。另一种方法是合并（merging），它生成一个整合记录，类似于黄金记录（Golden Record）。

在此过程中，职责被分配给多个角色。数据所有者（Data Owner）设定指导去重过程的标准，主数据工程师（MDM Engineer）在平台上实现这些标准，而数据质量分析师（Data Quality Analyst）与数据管理员（Data Steward）共同监督该过程的结果。

### 幸存者规则（Survivorship Rules）

当多个源记录指向同一实体时，主数据管理（MDM）流程必须决定在黄金记录中每个属性使用哪个值。

之前我们以学生姓名Amélie Dubois和A. Dubois为例，这些值可能出现在多个记录中。因此，在创建黄金记录时，需要决定保留哪一个。

为此，有幸存者规则（Survivorship Rules），正如其名称所示，这些规则基于所涉及的数据来确定如何解决这些情况。

这些标准由数据所有者（Data Owner）制定，数据管理员（Data Steward）监督流程及其应用，而主数据工程师（MDM Engineer）在平台上实现这些规则。

## 元数据管理（Metadata Management）

在上一节中，文档元数据帮助我们识别文件并描述其类型或创建日期等细节。但元数据的应用远不止于文档。

元数据是描述其他数据的数据。数字42本身是模糊的。列名如“age”、单位、定义和时间戳可以告诉你它代表什么以及如何解释它。

在组织层面，元数据需要专门的管理。元数据管理（Metadata Management）收集、连接、维护并发布元数据，使人员和系统能够正确查找和使用数据。

目标是使数据易于理解，并支持治理、质量、安全和发现。人们手动创建一些元数据，而扫描器和集成工具可以从系统和文件中收集技术或操作元数据。元数据仓库（metadata repository）连接这些描述，数据目录（data catalog）则向用户公开这些信息。

首席数据官（CDO）和数据治理委员会（Data Governance Council）可以制定元数据战略和治理模型。元数据管理员（Metadata Manager）或元数据工程师（Metadata Engineer）操作平台，而数据所有者（Data Owner）和数据管理员（Data Steward）维护定义、所有权和其他领域元数据。

### 业务元数据（Business Metadata）

元数据不仅包括列名和文件属性。业务元数据（Business Metadata）用组织的语言和规则来解释数据。

它包括文档定义、业务规则、所有权和使用限制。例如，大学可能将“注册学生”（Enrolled Student）定义为至少有一门活跃课程注册的学生，然后具体说明“活跃”（active）的含义。该定义即为业务元数据。

用于生成该定义的知识由业务分析师（Business Analyst）提供，他们与数据管理员（Data Steward）合作，将其转化为清晰且一致的定义。

### 技术元数据（Technical Metadata）

技术元数据（Technical Metadata）描述系统如何表示数据及其存储位置。它包括模式（schema）、数据类型、表和列名、路径、文件格式、键和接口。

例如，在目录中，它可能表明学生的地址数据位于某个表属性中，是文本类型且不允许空值。所有这些信息都属于元数据，因为它描述了数据的位置及其表现形式。

在此层面，数据架构师或数据建模师通常定义数据的表现形式，以便数据工程师、分析工程师和数据库管理员能够处理其具体实现。

### 操作元数据

操作元数据记录系统在处理或使用数据时发生的情况。它可能包括作业的开始和结束时间、行数、查询活动、数据新鲜度、状态和失败情况。

例如，在大学中，可能会记录注册请求流水线在凌晨6点运行，处理了543名学生，并在20秒内成功完成。

此类元数据通常从Apache Airflow等调度器、应用程序日志和云平台中获取，这些系统由数据工程师和数据运维或平台专业人员操作，他们监控这些执行过程。

### 数据目录

数据目录是用于整合这些元数据类型的主要系统之一。

数据目录是组织数据资产的可搜索清单。它通常存储元数据和源系统的引用，而不是复制所有底层数据。其主要目的是发现和理解数据，尽管一些目录也支持访问请求和治理工作流程。

例如，如果分析师要查找过去6个月的注册记录，目录应表明哪些数据库或存储系统包含这些信息，谁负责管理这些数据，以及其他元数据如存储系统的名称或表名，以及访问规则。

目前最知名的商业解决方案包括Collibra、Alation和Microsoft Purview，这些通常部署在AWS Glue Data Catalog和Google Cloud Knowledge Catalog等云生态系统中。平台由元数据管理员或元数据工程师管理，他们负责维护该平台。

### 业务术语表

业务术语表是一个受控词汇表，用于定义组织概念的官方含义。它不应与数据字典混淆：字典描述特定系统的表和列，而术语表定义可能在多个系统中实现的业务概念。

例如，“已完成行程”这一术语可能指已到达目的地且账单已验证的行程。此定义可防止移动部门在行程结束时就认为行程完成，而财务部门仅在收到发票时才视为完成。该术语应包含其定义、同义词、规则、相关概念、负责人、管理员和审批状态。

业务专家或业务分析师提出术语，数据管理员审核其清晰度和潜在冲突，数据负责人批准其使用。术语表可以以简单文档的形式开始，但随着其发展，应将其纳入数据目录，以将每个术语与其列、规则、报告和策略相关联。

### 数据血缘

数据血缘描述数据的来源、移动路径、经过哪些转换以及被哪些系统消费。

在大学场景中，数据血缘可以展示地址如何通过应用程序进入系统，传递到地理API，生成路线距离，并参与移动资格决策。随后的独立操作流程可能仅向运输提供商共享最低限度的行程细节。这些元数据帮助团队评估变更影响、调查错误，并展示结果的生成过程。

数据工程师、分析工程师和元数据工程师通过dbt、OpenLineage或Apache Atlas等工具帮助捕获血缘关系。自动化可以从支持的系统中收集血缘信息，并生成从数据源到仪表板的可视化路径，但团队仍需验证信息缺口、语义定义以及手动实施的流程。

### 元数据标准

元数据也需要标准、质量控制和治理规范。元数据标准定义了团队如何记录、表示和交换元数据。

目标是帮助人员和系统统一地定位、理解、集成和交换数据。ISO-8601是日期和时间的数据表示标准。在组织内部，snake_case可能是元数据命名规范，而定义的JSON Schema可以规范工具交换元数据的方式。

最值得关注的外部标准包括用于元数据注册的ISO/IEC 11179系列，以及用于描述各类数字资源的Dublin Core。应用这些标准的责任落在数据架构师和元数据管理员身上，由他们选择适用标准。

### 元数据质量

与其它数据一样，元数据应满足准确性、完整性、一致性及新鲜度的定义标准。

低质量的元数据可能破坏治理和处理流程，因为用户可能错误解读原本正确的数据。例如，如果目录显示距离以公里为单位，而系统实际存储的是米，下游计算结果可能出错。

团队可通过完整性、有效性、一致性及新鲜度检查来衡量元数据质量。血缘关系则帮助他们识别不良定义或缺失字段可能影响的下游资产。元数据管理员、数据管理员和数据质量分析师可能共同承担这项工作。

### 元数据治理

元数据治理定义了谁有权创建、批准、修改和退役元数据。元数据具有自身的生命周期，受控流程可防止未经适当审核的定义在生产环境中随意变更。

例如，如果数据分析师提议将"到校园距离"的概念描述从公里改为米，他们不能直接修改该定义。治理要求该提案首先提交给数据管理员，确保新表述清晰且与术语表其余部分保持一致，然后由对应的数据负责人验证。

只有在完成此审批流程后，元数据才会在生产环境中正式更新，防止不受控的变更引发不必要的故障。

尽管责任通常由数据管理员和数据负责人承担，但这一职责分配并非普遍适用。在高管层面，首席数据官（CDO）和数据治理委员会制定指导组织治理实施的总体政策。

## 数据集成与互操作性

大多数组织不会将所有数据存储在一个系统中。他们使用多个系统来完成不同的任务，因此这些系统需要可靠的方式来交换和整合信息。

数据集成与互操作性正是为了解决这一需求。互操作性意味着系统可以交换数据并一致地解释数据，而集成则将数据连接或整合以实现特定用途。

由于每个系统仅持有部分信息，数据集成会从不同来源收集或虚拟连接信息，以提供消费者所需的视图。

目标是让正确的数据在正确的时间、格式和位置可用。其中一个要求是延迟：数据被创建或请求后到对消费者可用之间的延迟。门户可能需要在几秒内获取当前出租车可用信息，而月度成本仪表板可以在夜间刷新。集成还必须具备安全性、可观测性和可审计性。

例如，大学系统必须就“到校园的距离”这一指标的含义和单位达成一致，或声明可靠的转换方式。如果没有这种共享协议，以公里为单位的数值可能被误认为是米，从而导致严重错误。

一旦确保互操作性，数据就可以被整合以生成仪表板等成果。在大学场景中，可以从不同系统获取数据，例如包含交通服务记录的数据库和支付平台，最终生成显示该服务在一段时间内成本统计的仪表板。

数据架构师定义互操作性原则和共享模式。数据工程师和集成工程师设计并构建数据摄入、映射和交换流程。平台工程、DataOps 和 SRE 团队协助部署、监控和恢复支持服务。

### 数据摄入

数据摄入将数据从源系统移动到目标环境进行存储或处理。目标环境可能临时或永久保存数据。

数据源可以包括数据库、API、文件、应用程序和事件流。目标可以包括运营系统、队列、数据仓库、数据湖和其他平台。在推送模式下，源系统发送数据，而在拉取模式下，目标或连接器请求数据。

还需要指出，根据数据是插入系统还是直接从源系统查询，不同类型的集成存在区别。

一种类型是物理集成，其中数据通过 ETL 或 ELT 流程提取并存储在公共目标中。例如，大学可以使用 Apache Airflow、Apache Spark 或 Azure Data Factory 每晚将差旅和支付记录加载到数据仓库中，以便后续生成成本仪表板。

另一方面，虚拟集成允许在不将信息存储到目标环境的情况下查询不同源，就像这些源构成了一个统一的查询系统。通过使用 Denodo 等技术，大学可以在单个查询中将差旅数据库和支付平台合并，从而获得整合后的数据。

虚拟集成通常不会持久化单独的汇总副本，尽管查询引擎可能会临时缓存或处理数据。相比之下，数据摄入会主动将数据移动到另一个环境，后续可能进行进一步的转换。

例如，大学可能希望分析免费出租车服务是否确实提高了线下课程的出勤率。为此，它需要整合记录出行日志和学生出勤情况的数据源，这些数据很可能存储在不同的系统中。在此过程中，会查询这些数据源，并将数据导入数据仓库进行分析。

用于数据导入的技术包括 Apache NiFi 和 Kafka Connect，以及 AWS 数据库迁移服务或 Azure 数据工厂等工具。选择哪种技术取决于数据源、目标系统、数据量、更新频率、安全性和互操作性需求。数据工程师通常会与相关数据源和平台团队合作，设计并实现导入流程。

### 批量集成

在确定数据源和目标系统后，团队需要决定导入和处理的运行时间。这取决于消费者对数据新鲜度的需求。

在批量集成中，系统按照计划或触发条件定期收集和处理记录批次。当消费者不需要实时结果时，这种方法通常更简单且成本更低，但团队仍需管理批量处理可能对源系统和目标系统造成的集中负载。

例如，大学可能每天晚上将已完成的行程和支付信息加载到数据仓库中，以更新交通服务成本仪表板。该过程会提取数据，临时存储在暂存区，应用必要的转换，然后加载到目标系统。如果更新频率较高，这些批次被称为微批次，因为它们包含的数据量较少，但处理流程与批量处理完全相同。

这种类型的集成通常使用 Apache Airflow、Apache Spark、AWS Glue 或 Azure 数据工厂等技术实现，主要由数据工程师负责。此外，数据运维或平台工程专业人员会监督和监控集成流程的运行。

### 流式集成

当消费者需要更低的延迟时，流式集成会持续处理事件，或在源系统生成事件后立即处理。与等待大规模计划批次不同，生产者会发布事件，这些事件在到达时立即进入导入和处理流程。

例如，运输公司可能会实时发布事件，表明行程已被请求、接受、开始、完成或取消，从而使学生门户能够立即更新。

这些事件通常通过 Apache Kafka、Apache Pulsar 或 Amazon Kinesis 等平台进行分发，而 Apache Flink 或 Spark Structured Streaming 则用于过滤、转换、聚合并最终集成这些事件。

在此过程中，数据工程师仍然是最重要的角色，但随着需求的增加，专门负责流式处理的流式工程师角色也逐渐出现，他们能够确保这些流程以必要的低延迟运行。

https://docs.databricks.com/aws/en/data-engineering/batch-vs-streaming

### 基于 API 的集成

内部和外部系统通常通过 API 而非直接数据库访问来暴露数据或操作。

应用程序编程接口（API）是一种契约，通过这种契约，一个系统可以暴露选定的数据或操作，而无需透露其内部实现。可以将其视为一组定义好的调用或资源，其他软件可以使用这些接口。

大学可能会将文本地址发送到地理 API 以获取坐标。当学生申请交通服务时，内部 API 可以接受经过身份验证的学生标识符，并返回资格结果，而无需暴露底层的学术记录。

一些数据平台提供受控查询 API，但公共服务应避免接受来自客户端的无限制 SQL。API 合约应仅暴露消费者被授权使用的操作和数据。

从技术角度看，最常见的实践是通过 HTTP 协议使用 API，以 JSON 格式交换数据并遵循 REST 风格，尽管也存在 gRPC、GraphQL 或 SOAP 等替代方案。无论实现技术如何，API 必须明确定义其合约，这可以通过 OpenAPI 或 AsyncAPI 进行文档化。

API 通常由后端工程师或 API 工程师设计和实现，而集成方案则由集成架构师设计，无论数据源是否通过 API 访问。

### ETL 和 ELT

如果聚焦于数据摄入过程，数据必须从源系统提取并插入到另一个系统中。但目标系统通常与源系统的模式不同。每个源系统以特定方式组织数据以解决特定问题，而目标系统则以不同方式结构化数据，主要是因为它需要整合来自多个源的信息。

例如，数据源可能存储包含部分学生信息（姓名、出生日期、电子邮件）的记录，而目标系统（集成目标）可能存储包含这些信息以及每位学生支付数据的记录，可能还会修改某些字段（姓名、年龄、卡号）。这意味着学生记录需要进行转换，例如从出生日期计算年龄。

实际集成通常需要更多转换，因为源系统和目标系统的结构存在差异。这种边界并非总是严格：团队可能在流程的多个阶段对数据进行转换，以实现兼容性、质量提升、隐私保护、数据丰富化或后续分析。

总结来说，此处提到的转换构成了众所周知的抽取、转换和加载（ETL）。本质上，这是一个包含一系列步骤的过程：从源系统中选择并提取数据，将其转换为符合目标数据模型的格式，然后加载到目标系统。

在之前的示例中，唯一需要的步骤是将出生日期转换为年龄（假设其他字段的数据类型已匹配）。

当需要在数据进入目标系统前严格控制信息时，ETL 是合适的选择。但还有一种抽取、加载和转换（ELT）方式，它先将数据加载到目标系统，然后再进行转换。这种方法在云数据仓库和湖仓一体架构中很常见，因为它可以保留原始版本并支持多种用途的复用。

例如，通过 ELT，大学可以将授权的学生记录和原始供应商交易参考信息加载到受保护的数据湖中，然后再应用分析转换。不应因为数据层是“原始”就复制完整卡号或绕过安全检查。保留类似源数据的形式可以支持重新处理，但保留策略、最小化原则和访问控制政策仍然适用。

Teams can implement these processes with Apache Spark, AWS Glue, and Azure Data Factory. Data Engineers usually design the end-to-end flow, while Analytics Engineers often define transformations inside the analytical platform.

### 数据交换标准

As you've just seen, the differences between source and destination models require transformations.

To reduce the number of transformations needed for integration, there are Data Exchange Standards, which are common rules about the structure, format, and meaning of the data. Their goal is to encourage, whenever possible, the use of a "unique" or common structure so that all systems structure the data as similarly as possible, avoiding transformations when exchanged.

For example, the university could define an exchange model with fields such as (student_id, name, date_of_birth, email), along with their formats and semantics. If a consumer needs age, the contract should define the date on which it's calculated so the value doesn't become ambiguous. Data Exchange Standards don't have to dictate internal storage. They define the representation used at the boundary.

These rules can be grouped into what's known as a Canonical Data Model, documented with OpenAPI or AsyncAPI, among other tools. The responsibility for their definition falls on a Data Architect or Data Modeler, while a Data Engineer or Integration Engineer is the one who ultimately implements the application of these rules in various systems.

### 模式管理

Many systems use a schema that defines field names, types, and constraints. A student record might begin as (name, date_of_birth, email) and later gain a phone field. Schemas therefore evolve as requirements change.

Schema Management versions and governs those changes so producers and consumers can coordinate safely. Compatibility policies state which changes a system can accept without breaking existing data or consumers.

Here, we can make a distinction between backward compatibility and forward compatibility. Backward compatibility refers to the ability of a system using a new schema to correctly read or process data saved or emitted with an old schema. Forward compatibility refers to the ability of a system to use an old schema to read, process (or at least safely ignore) data saved or emitted with a new schema without causing errors. In this context, the ideal is to achieve complete compatibility in both directions.

Teams can express schemas with JSON Schema, Apache Avro, Protocol Buffers, and similar technologies, then version compatible formats in Confluent Schema Registry or AWS Glue Schema Registry. Data Architects and Data Modelers define the shared approach with the engineers who produce and consume the data.

## 数据质量

Integration can combine data from several sources, but a technically successful integration doesn't guarantee useful results. The output may still contain missing values, incomplete records, contradictions, or duplicates that affect its intended use.

Data Quality is the capability that measures and improves whether data is fit for purpose, in other words, suitable for its intended use.

Quality isn't an absolute label that makes data perfect for every situation. It depends on the intended use. A city of residence may be enough for aggregate demographic statistics but not enough to arrange a pickup. Data should meet measurable requirements for the task at hand.

通常，维护数据质量的责任并不落在某一个人身上。通常，数据质量经理与数据所有者共同评估哪些数据对组织最为关键，潜在错误的影响以及可接受的质量水平。

随后，数据质量分析师会实际分析和监控数据以确保其质量，而数据工程师和开发团队则实施必要的流程以达到所需的质量。这些人不使用特定技术来管理数据质量，而是依赖其他技术如 SQL。

### 数据质量维度

数据质量是通过数据质量维度这一可衡量属性来体现的，这些维度是数据的可观测特征。每个维度针对数据的不同问题，可以适用于单个数据项或整个记录：

- **准确性**：检查数据是否正确反映现实。例如：如果学生地址与其实际地址一致，则该地址是准确的，否则无法正确反映现实。

- **完整性**：检查特定用途所需的所有数据是否都已存在。例如：假设注册表单要求提供姓名、姓氏和电话号码，而用户未提供电话号码或该数据丢失，若最终完成注册，记录将不完整，因为电话字段将为空。

- **唯一性**：确保数据或记录不会重复出现。例如：当学生注册大学时，数据库应只包含一条包含其数据的记录，除非设计原因需要重复，否则不应存在重复记录。

- **一致性**：确保数据的不同表示方式之间不相互矛盾。例如：如果学生邮箱或电话号码必须在多个系统中出现，其值必须一致。同一学生不能在一处显示一个邮箱，而在其他地方显示不同的邮箱，这将不一致。

- **及时性**：检查数据是否在需要时及时更新并可用。例如：当学生请求出租车时，他们应能立即获取其实时位置数据，该数据需以低延迟及时更新并可用。

- **有效性**：确保数据符合定义的类型、格式、范围和约束。例如：如果注册请求状态只能是 ACCEPTED 或 REJECTED，那么该字段值不能不同，且必须以定义的格式存储。否则，将不符合定义的约束和业务规则。

这些维度相互关联，实践中某些维度可能对数据使用更为关键。例如，当学生请求出租车时，及时性至关重要，因为他们期望立即看到实时位置信息。同时，唯一性对财务数据尤为重要，因为支付记录不能重复，否则将是特别严重的错误。

### 数据剖析

数据剖析帮助团队了解数据集的当前状态。它检查数据结构和内容，计算统计信息，并寻找模式或异常。剖析结果可能报告空值百分比、唯一值数量、最小和最大值、类型模式以及字段之间的关系。

例如，如果大学维护一个包含学生个人信息的表格，可以检查姓名是否存储在文本字段而非数字字段中，或者是否没有任何记录的字段为空，以及其他更复杂的检查。

在关系型数据库中，也可以分析列与表之间的关系，从而验证所有注册信息是否与现有人员和科目相关联，否则数据将变得不完整且不一致。

仅靠剖析无法判断数据是否符合特定用途。一个字段中的空值可能是缺陷，而在另一个字段中可能是有效的。因此，数据质量分析师需要与数据管理员和领域专家一起解读剖析结果，并根据平台和数据量使用SQL、pandas或Apache Spark等工具进行分析。

### 数据质量规则

数据质量规则将要求转化为具体、可衡量的条件。它们帮助团队检测数据是否适合预期用途，并决定下一步该怎么做。

剖析揭示了数据的现状，而规则则定义了可接受数据应具备的特征。例如：

- 学生的联系邮箱不能为空，且必须符合组织接受的邮箱格式。

- 到校园的距离必须是大于零的小数。

- 同一次出租车行程不能被重复记录。学生的费用可能为零，但提供方的成本必须记录在授权的财务系统中，以便大学管理预算。

实际上，这些规则被视为一种元数据，因此需要相应地进行文档记录和版本管理。数据管理员和数据所有者根据业务判断设计和验证规则，而数据质量分析师和数据工程师则将它们转化为可执行的检查。最后，规则需要以适当的技术形式表达，例如查询语言（SQL、Cypher等）。

### 数据验证

数据验证执行规则以判断数据是否符合既定要求。与剖析探索数据当前状态不同，验证通过显式条件比较值和记录。

报名表可能需要学生的姓名，但API和数据库仍需验证它，因为客户端检查可能被绕过，数据在传输过程中可能会失败。关系型数据库可以通过NOT NULL、UNIQUE、CHECK、外键和其他控制条件强制执行约束。应用程序和流水线检查可以处理跨系统或需要更多上下文的规则。

数据质量分析师帮助定义和评估这些检查，而数据工程师、软件工程师、分析工程师和数据库专家则在合适的层级上实现它们。

### 数据清理

验证可能显示所有记录都符合规则。当某些记录不符合时，团队需要定义应对措施：拒绝、隔离、修正、丰富或记录例外情况并接受。

数据清理检测并修正已知缺陷，使数据满足其要求。正确的转换方式取决于字段、规则以及团队是否能安全地确定正确值。例如：

- 为避免不一致，规则可能规定名称不应以空格开头或结尾。因此，如果出现像“ Chloé Moreau ”这样的名称，规则会判定数据不符合要求，并可通过删除多余空格来恢复其质量。

- 另一条规则可能要求所有日期使用YYYY-MM-DD格式。因此，如果出现“15/09/2025”这样的日期，数据将不符合规则，但可以转换为“2025-09-15”以符合定义的格式。

根据数据、规则和问题的性质，某些转换可以自动执行，而其他转换可能需要更多监督才能正确完成。例如，名称中的空格可以轻松检测并删除，但其他问题可能更复杂，需要人工处理。

数据工程师、分析工程师、应用团队或运维人员可能执行数据清洗，而数据质量分析师和数据管理员负责验证方法。该过程应保留足够的可追溯性，以说明发生了什么变化以及原因。清理症状并不能替代修复缺陷的根源。

### 数据质量监控

验证不应仅在数据首次进入系统时发生。数据质量监控会随时间推移运行相关规则和测量，存储结果，并在质量下降时向团队发出警报。

例如，大学可以安排每天夜间自动执行学生数据的质量规则。系统将检查地址完整性、校园距离非负性以及有效日期格式等条件。这些结果可以存储并在仪表板上显示，从而检测到更新后负距离值突然增加等趋势。这样，负责变更的团队可以快速识别并纠正问题根源。

这些定期评估通常由数据工程师和DataOps团队使用AWS Glue Data Quality、Microsoft Purview等技术执行。

### 问题管理

当出现质量问题时，问题管理会记录、优先处理、调查并解决问题。优先级取决于对人员、决策、合规性和业务流程的影响，而不仅仅是坏行数的数量。

例如，如果由于某些错误，所有距离值突然显示为负数且学生被拒绝使用交通服务，这会影响用户体验，如果学生因此无法参加重要考试，后果可能更严重。因此，必须尽快处理问题。

通常，该管理流程遵循以下阶段：

- **注册与分类**：当规则被违反时，事件会被记录，包括其严重程度和负责受影响规则或数据领域的责任人。
- **遏制**：根据质量损失的严重程度或影响，采取措施防止影响发生。例如，如果某条规则规定支付记录不能重复，且检测到重复时，措施可能是暂时阻止所有支付，直到问题解决。
- **分析**：使用数据血缘追踪来调试流程并定位问题根源。
- **修正**：一旦确定原因，问题将被修正，并重新执行规则以验证和记录解决方案。

如果出现重复的支付记录，数据质量分析师可能会检测并协调问题，数据负责人设定业务优先级，数据工程师或应用团队修复技术原因。财务和合规团队可能也需要验证修正结果。

总之，质量维度定义了对特定用例重要的方面。数据剖析显示当前状态，规则明确预期，验证测试这些预期，清洗处理适当的修正，监控检测变化。当问题进入生产环境时，问题管理协调响应。

## 数据工程

我们已经讨论了存储、交换、保护和验证数据的系统。现在我们可以探讨团队如何在实际中构建连接这些系统的数据采集流程、管道和转换过程。

数据工程负责设计、构建和运营用于收集和准备数据的流程和组件。它将数据从一个或多个来源转移到人们和应用程序需要使用的系统中，包括数据仓库和数据湖等平台。

数据工程涉及架构、存储、集成和质量等多个领域，但它并不取代这些学科。这种交叉性就是为什么数据工程师在许多早期章节中都有出现的原因。

实现方式可能小到一个定时执行的SQL转换，也可能大到一个分布式流式处理管道。无论哪种情况，数据工程都会管理依赖关系，自动化重复性工作，测试变更并监控执行过程。

目标是让其他专业人士能够使用可信的数据，而无需重新构建从每个源头返回的完整路径。

例如，假设大学希望为管理层创建一个仪表板，用于分析交通服务的月度成本。要做到这一点，仅仅查询单一数据库是不够的，因为旅行数据可能存储在一个数据库中，而成本或支付信息可能由交通公司保管。

此外，每个数据源的更新频率不同，且使用各自的模式，因此数据工程在此处的作用是构建一个流程，执行以下步骤：

- 从每个数据源提取数据。
- 通过规则验证数据质量。
- 应用所需的转换，包括清除缺陷和标准化日期、单位和标识符。
- 将数据插入目标系统，如数据仓库、数据湖或其他类似系统。
- 插入后，可能需要根据后续使用需求进行聚合或处理。

数据工程师与数据架构师、数据管理员和数据质量分析师一起设计并实施这些流程。他们共同确保解决方案满足技术和组织需求。分析工程师、数据分析师、数据科学家、应用程序及其他使用者会利用这些结果。

如果基础设施足够庞大，数据平台工程师、DevOps工程师和站点可靠性工程师（SRE）等其他专业人员也可能参与其中，协助其运行。

### 数据管道

数据管道是一系列自动化任务，用于将数据从一个或多个来源传输并处理到一个或多个目标。一个任务可能读取、验证、转换、路由或写入数据，然后将结果传递给另一个任务。

在大学中，一个管道可能提取授权的交易参考、行程记录和注册数据，将其转换为通用的目标模式，然后加载到数据仓库中。分析师可以使用这些经过整理的数据生成报告和仪表板。

管道可以以批处理模式或流式处理模式运行。全量加载会读取整个选定的数据集，而增量加载则处理自已知时间点以来新增或修改的记录。一个重要的设计特性是幂等性：安全地重复相同的输入或运行不应产生意外的重复或不一致的结果。

其他重要特性包括可扩展性，确保大量数据不会影响执行可行性，以及可追溯性，用于了解执行时间和产生的结果。

数据管道通常由数据工程师设计和实现，但有时集成工程师或分析工程师也会协助，具体取决于数据的最终用途。

实现所使用的技术会根据基础设施的不同而有很大差异。一个管道可能包含SPARQL或SQL查询，用Python、Apache Spark或Apache Flink进行的转换，甚至使用Google Cloud Dataflow等云服务。

### 管道编排

在定义管道的任务、输入、输出、来源和目标后，需要协调它们的依赖关系。这种协调称为编排。

例如，想象一个管道，首先获取学生和旅行数据，然后获取支付数据，这些数据需要插入到一个仅接受同时包含支付信息和学生个人数据的记录的数据仓库中。根据这些要求，在插入之前必须先获取所有来源的数据，因为需要将它们结合起来。但在其他管道中，可能不需要这样，每个来源的信息可以在获取时立即插入。

管道中的这些依赖关系通常用有向无环图（DAG）表示，其中每个节点是一个任务，每条连接表示一个依赖关系。它也可以作为编排软件的内部数据结构，精确决定任务何时准备好执行，以及根据执行结果应该发生什么。

最常用的编排技术包括Apache Airflow、Dagster和Prefect，以及Azure Data Factory、AWS Step Functions或Google Cloud Composer等云服务。

### 数据转换

许多管道任务会转换数据的结构、表示或内容，以便后续消费者使用。

转换可以很简单，例如将公里转换为米，将日期标准化为通用格式，或重命名字段。其他转换可能更复杂，遵循更抽象的业务规则，例如将出租车路线与学术时间表关联，以自动验证行程是否与必修的线下课程冲突，从而检测服务的不当使用或任何问题。一些转换还可能涉及过滤、删除重复项或聚合数据。

当执行数据转换时，数据会从刚刚从源获取的状态转变为可使用状态。在这里，我们可以根据数据经历的转换程度建立分类：

- 原始数据：数据保持接近源的表示形式。例如，供应商提供的日期字符串为05/03/2026，其日/月顺序必须在文档中明确说明。

- 中间数据：数据经过验证和标准化，以便进一步处理。一旦明确源含义，日期可能变为明确的ISO值2026-03-05。

- 精炼数据：在此阶段，数据被丰富、与其他数据结合，并被认为已准备好最终使用。例如，假设之前的日期对应一次行程，它可以与其他数据结合，创建包含支付信息的行程记录。

转换的重点是将原始数据转换为中间数据和精炼数据。技术上，实现方式取决于涉及的系统和公司决策，通常使用Python、R、SQL等语言，或Apache Spark等框架。

流水线还可以检查数据源可用性、验证数据质量、管理审批流程并发送通知。工作流自动化会按照所需顺序协调这些操作，从而避免重复性工作依赖人工逐一执行每一步。

区分流水线和工作流非常重要。流水线描述数据的路径及其转换过程。而工作流则包含不直接转换数据但对执行流水线至关重要的任务。

例如，当大学从运输公司接收文件时，工作流可以验证其格式、监控流水线执行并更新数据血缘工具。

但自动化工作流并不总是意味着完全消除人工干预。例如，可以设置规则来检测源数据中是否出现不应存在的个人数据。如果该规则检测到个人数据，数据管理员（Data Steward）将介入以批准更改或拒绝并采取适当措施。

最后，工作流通过Apache Airflow、Dagster或Prefect等编排工具，结合CI/CD系统和事件管理工具来实现。

### 数据测试

在自动化执行流水线时，即使无法完全消除人工监督，大部分流程仍可能在实现过程中出现错误。即使实现完美，也可能出现影响数据并导致流水线任务失败的错误。

数据测试同时检查转换代码和流水线中的数据流动，使团队能够在影响数据消费者之前发现缺陷。

测试套件应涵盖代码、模式、数据、依赖项和基础设施可能失败的现实场景。数据测试和数据质量规则有重叠，但团队可能因不同原因使用它们。

质量规则表达业务或适配性要求，而流水线测试可能验证技术前提条件或预期转换。同一检查可能同时满足两种需求。

常见测试类型包括：

- 单元测试：验证在特定输入和预期输出条件下转换代码的正确性。例如，如果转换将距离从公里转换为米，可以使用输入18、4、6和输出18000、4000、6000进行测试。

- 模式测试：对数据执行以确保其结构和格式适合特定任务。例如，当接收到学生年龄存储为数字42时，模式测试将验证该数据是否为整数类型。

- 集成测试：检查架构或系统的各个组件是否能按预期交互。例如，集成测试可能验证大学的数据仓库能否从学术数据库接收数据。

- 端到端测试：执行整个流水线以确保在初始数据条件下结果正确。

- 对账测试：跨阶段比较计数、总计或控制值。如果记录的过滤器应保留100个输入记录中的50个，测试将验证输出计数和排除原因。

- 性能测试：鉴于某些流水线的复杂性，性能测试用于评估其执行是否在特定时间和可用资源内可行。

在大学中，部署流水线之前，可以使用包含虚构信息的合成数据集（synthetic datasets）进行测试。通过这种方式，可以执行所有类型的测试，验证任务是否正确执行、数据在每次转换后是否具有预期属性，并确保整个过程在指定时间内完成。

测试技术与流水线同步发展。Python转换可以使用pytest进行测试，而SQL可以支持对账和模式检查。数据工程师负责大部分流水线测试，平台或DevOps工程师则协助将其集成到自动化交付和运行环境中。

### 数据版本控制

由于业务需求变化、数据源变更或其他原因，数据流水线通常会发生变化。因此，记录流水线随时间变化的历史记录至关重要，这使我们能够追踪其演变过程直至特定时间点，主要目的是便于错误调试。

数据版本控制保留了用于重现结果所需资产的历史记录。根据具体用例，这可能包括转换代码、模式、配置、参考数据、模型输入以及数据集本身的快照或版本。

例如，假设一份报告显示某个月份出租车费用为10,000美元，但后续检查时系统显示同一月份的金额为8,000美元。这种差异可能是由于错误，也可能是计算该费用所用政策发生了变化，例如不再统计取消行程。

要确定这种情况是否为错误，版本控制可以访问涉及该计算的流水线的早期版本，查看该数据是如何得出的。

团队通常使用Git管理代码、配置和基于文本的模式。Apache Iceberg、Delta Lake和Apache Hudi等表格式可以为支持的表保留数据快照和变更历史。可重复性可能需要两者结合使用。

### 数据平台运营

流水线实现并完成版本控制后，需要基础设施来运行，这指的是可以部署在大学服务器或云环境中的硬件。它可能需要数据存储、转换所需的计算能力、协调任务的编排器，以及确保数据和流程安全的专用系统。这些组件共同构成了数据平台（Data Platform），即流水线和其他流程执行的技术环境。

平台本身需要管理和维护，因为它不是完全自主运行的系统，需要监督。这种管理过程称为数据平台运营，包含一系列任务，旨在确保平台能够安全、稳定、高效地执行流水线。

一些最基本的任务包括：

- 资源的配置和扩展：配置数据库和平台组件在任意时间点所需的机器数量。

- 环境管理和隔离：为测试、开发和生产环境创建专用环境，后者为终端用户提供服务。

- 权限管理：为每个专业人员确定权限以执行任务，防止安全漏洞。

- 成本控制和优化：监控资源消耗以避免超支，目标是用最小的消耗提供服务。

例如，一个计算出租车使用月度成本的管道可能需要连接到运输公司的 API，转换数据并将其存储在数据仓库中。

为实现这一目标，平台必须提供必要的计算资源来执行转换、存储数据并允许与 API 的安全连接。因此，正确的平台管理对于确保管道正常运行至关重要。

数据平台工程师通常负责这项工作，并了解平台运行的服务，如 AWS、Azure、Google Cloud、Databricks 或 Snowflake。Docker 可以打包适合的工作负载，当复杂度合理时，Kubernetes 可以编排容器，而 Terraform 可以通过代码定义基础设施。基础设施即代码提高了可重复性，但它并不能自动实现服务在云提供商之间的可移植性。

### 数据可观测性

即使每个任务都报告成功，数据平台仍可能以微妙的方式失败。数据可观测性帮助团队了解数据及其生成系统的健康状况，从而使他们能够检测、调查并减少故障的影响。

可观测性允许你通过系统产生的信号推断其状态。在数据场景中，这些信号包括数据的新鲜度、体积、模式、分布、质量结果、血缘关系、任务状态、日志、指标和追踪信息。

监控检查已知条件，例如任务是否完成，新鲜度或体积是否在预期范围内。基础设施信号（如 CPU 和内存）可以帮助解释故障，而数据层面的信号则显示消费者是否收到了正确的输出。

例如，如果数据管道只生成几十条记录而不是预期的几百条，监控可以检测到结果的变化。它还可以显示同一时间点获得的其他相关指标，例如参与管道任务的每个任务的 CPU 使用情况，帮助你检测是否有任务失败并防止数据传播到最终端。

为了使可观测性指导行动，团队可以为相关属性定义服务级别指标（SLI），并为预期水平定义服务级别目标（SLO）。例如，SLI 可能衡量最新出勤数据的年龄，而 SLO 可能规定 99% 的每日更新必须在早上 7:00 前可用。当管道有风险无法满足这一承诺时，警报会通知团队。

可观测性领域最知名的工具是 Prometheus 和 Grafana，它们常用于收集和可视化指标。还有 OpenTelemetry 用于管理遥测数据和日志，以及 OpenLineage 用于实时监控数据血缘关系。

在此场景中，数据工程师可能负责实现适当的可观测性机制。但并非总是独自完成，因为 SRE、平台工程师或 DataOps 团队也可能参与维护这些机制。

### 数据契约

可观测性有助于检测诸如任务失败、数据过时、异常数据量和意外模式变更等错误。例如，如果出租车提供商在未通知的情况下将地理坐标从数字更改为文本，即使网络连接仍然正常，下游流程也可能失败。

数据契约通过使生产者和消费者之间的期望明确化来降低这种风险。它们定义数据的结构和特性，以及团队如何沟通和版本化变更。可观测性仍然会在运行时验证契约。

更具体地说，数据契约可以定义模式、类型、格式、语义、质量规则、所有权、交付频率、延迟和变更管理预期。

例如，运输公司可能同意每次行程事件包含（trip_id、student_reference、provider_vehicle_id、price、origin、destination）。契约可以定义价格以欧元表示，坐标作为数值的纬度/经度对，对student_reference设置隐私限制，并要求不兼容变更时需要更新契约版本。

此外，契约不仅仅是文档。会实施检查以验证合规性，确保任何变更（出于安全考虑）不会影响数据管道，因为变更可能会影响可用性和安全性。

要定义数据契约，数据模式通常用JSON Schema、Apache Avro、Protocol Buffers或类似技术表示，尽管也会使用诸如开放数据契约标准（ODCS）等标准。

契约由组织内的数据工程师和分析工程师开发和审查，他们与其他公司专业人员（如了解其数据源生成数据的软件工程师）协调。在更高层次上，数据所有者和数据管理员参与验证数据的语义、质量和使用条件。

### DataOps

数据工程涉及许多人和组件。即使今天运行良好的管道，如果团队不协调对数据源、契约、代码、基础设施和质量规则的变更，也可能变得不可靠。

DataOps 是一种改进协作和交付流程的方法。其目标是缩短从业务需求到可信数据的路径，同时保持质量、安全性和可追溯性。

DataOps 不是一种特定技术。它是一套实践，例如代码版本控制、自动化测试、通过受控环境审查和部署变更，以及监控生产管道。它将敏捷交付和软件运维的理念适应到数据相关问题中。

例如，假设大学开始与一家新出租车公司合作。第一步可能是创建数据契约，定义数据交付的条件。然后，数据工程师会通过连接器实现所有必要的软件以获取数据，并将其存储在Git中。

此外，在生产环境中部署之前，应进行数据和代码测试以确保功能正常。最后，部署后会通过数据提取量、数据质量、延迟等指标进行监控。

数据工程师、分析工程师、数据管理员、数据所有者、平台工程师、SRE和消费者都参与DataOps。这些实践只有在生成、运营和使用数据的人共同承担可靠交付的责任时才能有效。

技术上，DataOps依赖我们之前讨论的工具，如Git用于版本控制，CI/CD工具用于自动化测试和部署等。但其价值不来自特定工具，而是来自在使用这些工具时采用最佳实践。

这些想法中的许多都源自DevOps。尽管如此，DataOps将其适应到数据工作中，纳入了质量、语义、血缘关系以及生产者和消费者之间关系等特定方面。

### DevOps

正如我刚才提到的，DataOps 借鉴了 DevOps 的理念。DevOps 指的是一套最佳实践，旨在协调软件开发与系统部署，目标是确保变更能够以自动化且可靠的方式进行测试、部署和维护。

其主要实践之一是持续集成（CI），即把每次代码变更集成到代码库中，从而自动执行测试。接下来是持续交付或持续部署（CD），它允许变更以受控方式在不同环境中自动部署。最后是基础设施即代码（IaC），它通过编程方式定义基础设施组件，便于在各种云平台或服务器上进行版本管理和部署。

例如，当数据工程师修改从出租车公司提取数据的连接器时，变更会被保存到 Git 中，CI 系统会自动运行相关测试。如果测试通过，软件的新版本将被构建并在测试环境中自动部署，继续验证其功能，直到最终部署到生产环境。

常见的技术包括 GitHub Actions、GitLab CI/CD 或 Jenkins，用于自动化测试和部署。Docker 也常用于打包软件，而 Terraform 或 OpenTofu 则用于定义基础设施。当系统规模和复杂度增加时，Kubernetes 也可用于容器管理。

DevOps 工程师、平台工程师和 SRE（站点可靠性工程师）负责实施和维护这些机制，而数据工程师则利用它们部署自己的数据管道。主要区别在于，DevOps 专注于软件和基础设施的交付与运维，而 DataOps 还会检查数据相关的特定方面，如数据质量、语义、血缘关系和可用性。

## 数据仓库与商业智能

组织通过数据管道捕获、整合和转换数据，然后将其存储在针对特定工作负载选择的系统中。操作型数据库支持应用程序和事务，这些是维持日常服务运行所必需的。

分析通常需要整合的历史数据、稳定的定义以及能够扫描大量记录的查询。专门的平台如数据仓库和数据湖支持这类工作。数据仓库与商业智能使受管控的分析数据可供探索者使用，并将分析结果应用于决策。

这两个概念密切相关。数据仓库涵盖数据仓库的设计和使用，它从多个来源整合历史数据，以支持可重复的分析工作负载。

操作型和分析型工作负载有不同的优先级和访问模式。一些平台同时支持两者，但团队在隔离性、性能、数据新鲜度、一致性及成本方面仍需权衡取舍。将工作负载分离通常可以保护日常运营，并为分析师提供专为查询设计的模型。

商业智能（BI）涵盖用于查询、分析和呈现数据以支持决策的实践与技术。数据仓库通常为 BI 提供受管控的分析基础，尽管 BI 工具也可以使用其他数据源。

例如，一所大学可能在数据仓库中整合差旅和财务数据。分析师可以比较供应商成本、使用情况、出勤率和预算，以评估交通福利的可持续性并估算短期支出。

此外，为了进行这些数据分析、构建仪表板并最终做出决策，数据需要具备高质量、受到保护，并且具有完善的血缘关系。这些方面的任何问题都可能影响决策制定。

### 分析数据存储

分析工作负载通常会扫描长时间段、连接多个数据源并聚合大量记录。专为操作性事务设计的存储可能并非反复执行这些操作的最佳选择。

分析数据存储专为分析查询、转换和聚合而设计。它们仍然需要安全性和一致性控制，但其性能优先级通常更倾向于对大规模数据集进行扫描和计算，而非高频的行级事务。

分析数据存储的最典型代表是数据仓库，它以稳定且可扩展的方式存储数据，使得相同的分析过程可以随着时间推移在数据量不断增加的情况下重复进行。

但这并非唯一选择，因为数据湖也面向此类用途，而数据集市则提供了一个更小规模的分析环境（通常是仓库中数据的子集），专门用于满足特定部门或业务领域的需求。

例如，大学可以创建一个包含移动性指标和有限财务背景信息的数据集市，用于分析服务成本，而无需暴露与学生相关的无关细节。团队应像对待其他任何分析资产一样，将数据集市连接到血缘关系、安全控制、质量控制和审计控制。

用于实现这些系统的最常用平台包括 Snowflake、Google BigQuery、Amazon Redshift、Microsoft Fabric 数据仓库和 Databricks SQL。这些系统的架构设计和实现由分析架构师或数据架构师负责，而数据工程师负责维护为这些系统提供信息的数据管道，分析工程师则处理数据摄入后所需的转换，以促进后续分析。

在管理和维护层面，有数据仓库管理员或平台工程师负责监控性能、管理权限和平台成本。

### 事实与维度

分析数据存储可能保留源数据或将其组织成模型，具体取决于平台和层级。数据湖通常在早期区域保留源格式，而经过整理的层级和数据仓库则应用更明确的模式。

一种常见的分析方法是之前提到的维度建模。它将信息组织为事实和维度。事实记录一个事件，例如一次出行，而维度则为过滤、分组和比较提供上下文。

一个特别重要的设计选择是粒度（或称粒度级别）：事实表中一行数据具体代表什么。团队应在选择维度和度量之前定义粒度，以确保后续的聚合操作仍然有效。

例如，出行事实表的粒度可能为“一次完成的出行”。如果一名学生在同一天进行了两次出行，表中将存储两行，每行包含其各自的费用、距离、时长和日期键。大学可以按月汇总这些行。不应将月度总计行添加到同一事实表中，因为它们的粒度不同，会导致重复计数。

一旦确定了粒度，维度的选择应基于描述事实和预期分析查询的上下文。一个实用的识别方法是通过询问每个事实涉及的“谁”、“什么”、“何时”、“何地”和“如何”。例如，如果每行代表一次出行，可以使用学生、日期、提供商、出发地和目的地等维度，每个维度对这次出行都有唯一值。

这些维度将允许分析出行发生的地理区域、哪家运输公司出行次数更多或更少等。通过这种方式，可以纳入提供有用分析视角的维度。

这种数据建模由分析工程师或数据建模师与数据管家等领域专家共同完成。随后，数据工程师会实施数据摄入和转换，以将数据适配到每个系统的特定最终模型。

### 指标与关键绩效指标

在维度模型中，事实可以被视为由值组成的行，称为度量。这些度量有助于理解事件随时间发生的情况，但数据分析通常旨在回答涉及特定时间段内所有事件的问题。

团队将度量组合成可重复的指标，如总计、比率、平均值和百分位数。当指标与重要目标相关联并能显示组织是否达成目标时，它就成为关键绩效指标（KPI）。以下是一些示例：

| 概念 | 含义 | 示例 |
|------|------|------|
| 度量 | 在事实中记录的值 | 一次出行花费18欧元 |
| 指标 | 对一组度量的可重复计算 | 月度运输成本 = 当月完成出行成本的总和 |
| KPI | 与业务目标相关联的指标 | 月度移动预算消耗，假设目标是不超出分配预算 |

显然，并非所有指标都始终是KPI。例如，代表一个月内出行总次数的指标可用于描述运输服务使用情况，但只有当业务目标涉及量化该出行次数时，它才会成为KPI。

KPI通常用于仪表板和可视化中，尽管它们通常不会单独出现。在这方面，当收集多个KPI的当前值并与既定目标进行比较时，这种收集被称为记分卡。

尽管这两个概念相关，但记分卡和仪表板有不同的目的。记分卡旨在确定目标是否达成，而仪表板有助于理解组织当前的情况及其原因。

同一指标可能出现在仪表板、记分卡、报告和API中，因此团队需要可重复使用的定义。其文档应包括：

- 名称、目的和业务负责人。
- 计算指标结果值的公式、数据来源及其粒度。
- 单位、时间段、时区和指标值更新频率。
- 过滤器和包含规则，例如从计算中排除取消的出行。
- 如果是KPI，需记录其产生的目标。

在此，指标和KPI主要由业务负责人、数据负责人和数据管家等角色定义。另一方面，它们的实际实施由分析工程师和BI开发人员完成，最终结果由数据分析师等专业人士使用。

### 语义层

正如我之前提到的，指标的文档记录是为了确保其含义和计算方法被充分理解。但这并不能保证所有系统都完全遵循这些文档。

例如，月度成本可能被计算为排除已取消的行程，而另一个系统可能意外地包含这些行程。在这两种情况下，同一个指标名称被用于产生不同结果的指标。

语义层通过在存储数据和使用工具之间集中可重复使用的业务定义来解决这个问题。它呈现诸如行程（Trip）、学生（Student）或课程（Course）等概念，而不是要求每个用户从表和连接中直接重建逻辑。

这样，构成每个指标的公式和过滤规则是在语义层上实现的，而不是每个分析师在数据库、数据仓库或相应系统上编写自己的代码。该层充当一个中介，将用业务友好语言表达的指标计算转换为特定系统执行该计算所需的代码，从而便于未来指标的修改和在不同系统之间的移植。

例如，在数据仓库中，可能存在一个行程事实表、一个日期维度表，以及每个事实表中的成本度量。在此情况下，语义层会定义诸如行程和成本等概念的存在，这些概念的计算以某种方式映射到用于实现每个系统的技术上。

在这种情况下，“每月总成本”指标的计算可以在语义层上定义，语义层会将其内部转换为SQL操作或相应技术，以按月对行程进行分组并汇总分组事实的成本度量。

指标文档与语义层中实现的主要区别在于，文档指定了指标是什么以及其正式计算方式，而在语义层中，这种规范被转换为特定技术中的操作，以允许计算。

因此，多个仪表板或报告可以重复使用语义层上定义的相同逻辑，因为有时需要在不同系统中的数据上执行计算。

用于实现语义层的技术包括Power BI语义模型、LookML、dbt语义层和Cube。分析工程师和BI开发人员通常在业务负责人和分析师的输入下构建和维护这些定义。

### 报表与仪表板

在将分析数据存储系统部署到生产环境并定义了一些指标或KPI后，下一步是创建面向终端用户、专业人员或高管的商业智能产品，以展示分析结果。

最常见的产品是报表和仪表板，尽管它们并非唯一的选择，因为分析结果也可能导致决策过程的可视化或文档化，例如。

让我们更深入地了解它们各自的定义和区别：

报表是针对特定主题和时间段呈现详细且结构化信息的文档。它可能包含图表、指标和解释。报表可以定期以静态格式（如PDF）生成，也可以是交互式的，允许用户筛选或操作所呈现的信息。

例如，一所大学可能会准备一份月度报告，按服务提供商分解交通服务成本，显示取消的行程、使用该服务的学生人数等信息。

另一方面，仪表盘是一种将最相关指标和关键绩效指标（KPIs）集中展示的视图，用于监控某种情况。它通常包含图表和可视化元素，更新频率通常高于报告。

例如，管理层面的仪表盘可以显示已消耗的预算、注册学生人数以及出勤趋势，如果是交互式仪表盘，还可以按培训项目筛选结果。

在创建仪表盘时有一些最佳实践需要遵循，以确保其实用性。例如，应只显示少数几个指标，并且这些指标必须真正与仪表盘的目的相关。此外，选择可视化方式不仅仅是装饰性考虑，因为图表应帮助人们理解所呈现的信息，并且在设计上应遵循最佳实践。

一般来说，当你需要定期监控一组少量指标并快速发现变化或偏差时，会使用仪表盘。当你需要深入探讨某个主题时，会使用报告。尽管这两种产品可以相互补充，但使用场景不同。

例如，管理部门可能使用仪表盘发现交通费用增加，然后查阅月度报告以确定是哪些服务提供商、路线或时间段导致了费用增加。

在创建这些产品时，最常用的工具包括 Microsoft Power BI、Tableau、Looker、Apache Superset 和 Metabase。这些工具主要由 BI 开发人员使用，但 BI 管理员也会参与管理构建这些产品的协作空间。最后，BI 分析人员会解读这些结果，并在某些情况下与 BI 开发人员一起开发报告或仪表盘。

### 自助式分析

数据分析过程会生成如仪表盘或报告等产品，这些产品以特定目的结构化呈现信息。但有时可能需要修改这些目的。

例如，财务部门可能有一个专门用于监控大学分配给出租车服务整体预算的仪表盘。然而，某个硕士项目的负责人可能需要将交通数据与该项目的出勤记录进行交叉比对，以判断该服务是否带来任何好处，这是一个原始仪表盘未解决的特定需求。

协调员可以要求技术团队修改仪表盘，但每个小问题都会进入开发队列。自助式分析允许授权用户探索受控数据并创建合适的分析，而无需在每个步骤都依赖技术专家。

这种方法依赖于我们之前提到的元素，例如用于维护指标的语义层、允许快速定位可用信息的数据目录，以及标准化业务概念含义的业务术语表。这些元素被团队成员用于独立构建自己的可视化和报告，但由于现有的隐私政策，他们可能无法访问所有类型的信息。这就是为什么该过程被称为“受控自助式分析”。

例如，如果仪表板显示运输费用增加，硕士项目的协调员可以使用语义层为其项目的数据定义过滤器。这样，语义层将确保使用官方的成本定义，而权限设置将阻止访问其他项目的数据或不必要的个人信息。

最后需要指出的是，原始仪表板并不总是被修改。相反，协调员会创建一个包含其更改的新仪表板。

在实践中，这种方案的可行性是分析工程师、BI开发人员和BI管理员协同工作的结果。主要的终端用户是数据分析师、业务分析师和业务经理，他们消费并利用这一能力。

## 大数据

数据生命周期贯穿于系统和管道的基础设施中。数据进入、移动、存储、处理，最终到达操作或分析消费者。

对于中等规模的工作负载，相对简单的架构可能就能满足性能、可靠性和成本目标。然而，随着组织的发展，可能需要存储更多数据、更频繁地处理事件，并支持更多样化的格式和使用场景。

最初运行在单一机器上的数据库可能首先通过增加CPU、内存或存储实现垂直扩展。在某些时候，工作负载或弹性需求可能需要在多台机器上进行水平扩展，但这种增加的复杂性应解决明确的需求。

大数据处理的是数据集和数据流，其体量、速度、多样性或组合超出了特定组织传统工具的实用极限。挑战不仅仅是“大量行数”。它是在该规模下满足所需的处理时间、可靠性和成本。

在思考大数据时，你可能会想象有一个明确的阈值，超过该阈值的数据集就被视为大数据。但事实并非如此，因为阈值取决于当前基础设施、目标速度、团队愿意承担的管理成本以及信息结构的多样性。

只有在评估当前基础设施是否未能满足性能、可靠性或成本要求后，团队才应采用大数据解决方案。分布式架构可能有所帮助，但它也会增加运营复杂性，因此其好处必须能够证明其合理性。

例如，由于学院或在线课程的扩展，一所大学的学生人数可能从1000人增长到10万人。如果发生这种情况，数据库必须支持存储所有个人数据，以及与虚拟校园等各类服务和平台交互时生成的数据，同时保持服务可用性和质量不受影响。

大数据在更大规模上利用了许多数据管理能力。大数据工程师通常是专注于分布式存储和处理的数据工程师，他们与设计解决方案的数据架构师以及操作该方案的数据平台工程师合作。

### 3V：体量、速度和多样性

大数据没有统一的阈值，但体量（Volume）、速度（Velocity）和多样性（Variety）这3V提供了一个有用的参考框架。它们并不是每个项目都必须满足的三个条件。它们描述了可能使当前基础设施更难处理工作负载的压力。

数据量（Volume）指的是必须存储和处理的总数据量。在此处的第一个挑战是数据会占用存储空间，因此在数据量足够大时，某些系统可能无法处理所有数据。此外，随着数据量增加，各种管理流程也会变慢，因为所有数据都必须经过管道或其他类似流程。

- 示例：数据量可以与学生产生的数据量相关联，这意味着学生人数越多，需要支持的数据量就越大。每个学生都会生成登录事件等数据，如果数据量很高，这些数据必须被存储和处理，会占用大量存储空间并消耗大量计算资源。

速度（Velocity）指的是数据到达、变化以及必须对消费者可用的速度。

- 示例：运输服务的出租车必须每隔几秒就通信其位置和状态，以便学生可以实时查看可用出租车及其是否靠近自己的位置。因此，数据必须尽快可用，以确保良好的用户体验。

多样性（Variety），如前所述，描述了数据的性质或多样性，例如数据所呈现的结构、格式和含义。

- 示例：学术数据库可以使用关系范式以表格形式存储注册信息和学生信息，而虚拟校园则以半结构化的JSON文档形式生成日志，或者使用图数据库以图结构表示学生、司机和位置之间的信息，以优化交通路线。

数据量会影响存储、传输和处理成本。团队可能在分配工作负载之前优化数据模型、分区、查询或保留策略。当单台机器无法经济或可靠地满足需求时，水平扩展成为一种选择。

并非所有数据都需要实时处理。实时行程状态更新可能需要几秒钟，而历史学费支付报告可以按每日计划刷新。所需的延迟应来自用户和业务需求，而不是出于让所有数据管道都实时化的愿望。

最后，多样性是数据最重要的属性之一，因为它决定了组织内数据集的异构性。由于这些多样化的数据以不同的结构、格式和表示方式存储，因此需要针对每种多样性采用特定的技术，以确保高效且可行的管理。

这些通常是归因于大数据的属性。但同样重要的是要强调其他重要属性，例如真实性（Veracity），它指的是数据的可靠性，或价值（Value）等。

### 大数据架构

当3V（数据量、速度、多样性）超出“传统”解决方案的容量时，有几种方法可以增加基础设施的容量以满足这些需求。但首先，定义基础设施是什么是有用的。

基础设施是指组织的应用程序和数据系统运行的计算、存储、网络和基础软件资源的集合。

架构描述了组件如何使用这些基础设施来满足需求。它定义了系统运行的位置、存储和处理如何分布，以及数据从源到消费者的路径。

因此，如果3V（数据量、速度和多样性）影响现有解决方案的可行性，可能需要修改其架构。如前所述，应对数据量或速度增加的一种方法是垂直扩展。这涉及提升硬件，为每台机器提供更多资源。但这种方法无法无限扩展，因此存在水平扩展。通过增加更多机器，将存储和处理任务分布到多台设备上。

提高速度的另一种方式是通过多台机器并行执行流程，这种技术称为大规模并行处理（Massively Parallel Processing，简称MPP）。

有许多方法可以提升基础设施的能力，尤其是在处理更多数据和提高速度方面。然而，管理更多种类的数据通常是一个挑战，除非有成熟的一般性技术，但分布式的架构可以提供帮助。

为了更好地理解架构的组成，可以将其视为一系列层级，每一层包含特定组件，这些组件共同构成了数据在组织内部生命周期中的传输路径。

| 层级 | 功能 | 来源 |
|------|------|------|
| 数据源头 | 数据获取或生成的源头 | 出租车公司API和支付平台 |
| | | REST API、PostgreSQL、物联网传感器 |
| 数据摄入 | 将数据从源头传输到平台 | 接收虚拟校园事件和供应商行程更新 |
| | | Apache Kafka、Apache Airflow |
| 持久化存储 | 保留事件、文件和经过整理的分析表 | Amazon S3、Google Cloud Storage |
| 数据处理 | 根据数据用途清洗和转换数据 | 在数据管道中删除重复的行程记录 |
| | | Apache Spark、Apache Flink |
| 数据服务 | 提供信息查询接口 | 数据仓库暴露整合的行程信息及关联成本 |
| | | Snowflake、Google BigQuery |
| 数据消费 | 用于决策或其他用途的信息使用 | 展示运输服务月度成本的仪表盘 |
| | | Power BI、Tableau、Jupyter |

架构的另一个重要方面是各层级必须实现安全机制、数据血缘追踪和可观测性，同时确保数据隐私。

想象一名学生通过虚拟校园请求出租车服务。架构必须保护并追踪该事件。流式处理可以在几秒钟内更新门户上的行程状态，而后续的批量处理则会整合相关记录用于成本分析。

这种速度差异是调整架构的另一种方式，使某些关键功能具备所需的速度，或者让不需要实时处理的分析流程能够处理更大规模的数据。

最后，架构由数据架构师或大数据架构师设计，并由数据工程师、流式处理工程师或软件工程师实施。其维护工作由数据平台工程师、云工程师和SRE（站点可靠性工程师）负责。

### 大数据存储与处理

在架构设计完成后，其组件将被实现，其中一些组件专门用于在所需规模上存储和处理数据。一方面，存储负责保持数据的持久性、安全性和可访问性；另一方面，处理则利用计算资源对数据进行转换和分析。

大学可能需要保留授权的虚拟校园事件、出勤记录和行程信息数年，这会带来巨大的存储需求。其处理需求可能更具波动性，在报告期或大型学术活动期间会出现高峰。

通过将存储与处理分离，如果我们关注能够用于基础设施中数据存储的系统，可能会遇到以下情况：

- 分布式数据库：这些数据库部署在多台机器上运行，使用如Cassandra或DynamoDB等技术。

- 对象存储：这些系统专门用于以独立对象的形式存储大量数据，使用如Amazon S3、Azure Blob Storage、Google Cloud Storage或MinIO等技术。

- 搜索引擎：这些系统专门用于快速索引和查询日志、文本及其他类型的半结构化信息，使用如Elasticsearch或OpenSearch等技术。

- 分布式文件系统：这些系统通过HDFS或CephFS等技术将文件存储并分布在多台机器上。

另一方面，基础设施中的数据处理可以根据采用的方法进行区分，这取决于数据量和处理速度：

- 批处理：在此模式下，数据随时间积累并定期批量处理。例如，可以使用Apache Spark实现，它允许将转换和清理等任务分布到多台机器上执行。

- 流处理：在此模式下，管道起点生成或到达的所有数据都会被持续处理，适用于需要实时结果的场景。此类场景中使用的技术包括Apache Flink或Spark Structured Streaming。

- 分布式查询和处理：这允许通过在多台机器上并行执行操作来分析大量数据。最常见的接口是SQL，由Trino或Spark SQL等工具使用。除了SQL，这些系统通常还提供Python、Java或Scala等语言的API以及DataFrame等抽象，为实现复杂转换或自定义逻辑提供更大的灵活性。

以架构示例来看，大学可以使用Kafka接收虚拟校园或运输公司生成的事件，而Flink可以处理这些事件，实时更新应用程序中每个行程的状态，供终端用户查询。随后，通过Spark将这些数据转换后集成到数据仓库中，并使用SQL进行查询。

实际上，负责实现和优化这些存储与处理系统的中心角色是大数据工程师或专业数据工程师。为此，他们使用如Cassandra、Amazon S3或HDFS等技术，决定如何使用Spark实现任务，并确保性能达标。

另一方面，数据平台工程师、云工程师和SRE（站点可靠性工程师）负责处理基础架构，确保其稳定性、可用性和弹性。

### 大数据分析

在大数据领域，除了存储大量多样化数据并在通常需要高速且实时的处理速度下进行处理外，还必须将数据转化为信息、知识，最终转化为价值。这意味着处理主要指对数据执行的转换操作，以实现存储、清理或维护其质量。

但处理也应用于存储后，用于计算统计信息并一般性分析数据。这就是大数据分析的职责，该领域专门通过应用于大量数据的分析过程，将数据转化为信息、知识和价值。

当工作负载的规模或流量特征需要分布式或其他专用基础设施来满足目标时，分析属于大数据场景。它不需要高级机器学习，仅使用可扩展的云平台本身并不能使小型分析成为“大数据”。

基于这一技术基础，您可以根据需要执行的分析类型，采用几种基本的分析方法：

- **描述性分析**：专注于应用探索数据的技术以了解发生了什么。例如，它可以计算已进行的行程数量、成本以及每月使用服务的学生人数。
- **诊断性分析**：在此，分析旨在理解结果发生的原因。在大学中，它可以用于研究哪些供应商的时间段与运输服务成本的增加相关。
- **预测性分析**：利用历史数据进行推断并尝试预测未来可能发生的情况。例如，它可以预测下学期将收到多少入学申请。
- **规范性分析**：将分析结果转化为建议。例如，在这种情况下，它可以建议如何优化出租车车队的分布并重新分配月度预算，以确保为尽可能多的学生提供服务覆盖。

在大数据环境中，分析可以按批次或流式处理执行，具体取决于每个过程的需求。例如，使用 Apache Spark 可以定期计算出租车行程成本和班级出勤率的变化，而使用 Flink 可以实时分析行程，如果需求超过一定数量则生成警报。

要使分析过程真正有用，首先要定义通过获得的知识要回答的问题以及预期增加的价值，即通过结果做出的决策。然后选择并准备必要的数据，确保其质量足以进行分析。执行后，结果通过仪表板、报告、警报、API 或预测模型发布。

还需要注意的是，拥有更大的数据量并不总是能保证“更好”的结论或更高的价值。例如，如果使用出租车服务的学生出勤率更高，不能直接得出交通是原因的结论，因为这些学生可能正在参加更多的线下课程或存在其他差异。

因此，除了处理大量信息外，正确解释结果也至关重要。在此特定情况下，问题是相关性并不总是意味着因果关系，但这并不是分析中可能出现的唯一问题。

数据工程师构建和维护管道和分析环境。数据分析师使用 SQL、Trino、Spark SQL、Power BI、Tableau 等工具进行各种分析，通常包括描述性和诊断性分析。数据科学家使用 Python、R、Jupyter、Spark 或 MLlib 进行统计建模、实验、预测和优化。

BI 开发人员将受控指标和分析转化为报告和仪表板。机器学习工程师帮助训练、部署和操作模型。领域专家、数据所有者和数据管理员帮助团队负责任地解释和使用结果。

## 分析与数据科学

组织通过分析数据来理解现状、支持决策、验证想法和构建模型。这是他们将数据转化为知识和价值的主要方式之一。

分析与数据科学是相互交叉、互补的领域。分析通常聚焦于通过描述性、诊断性、预测性或规范性方法回答明确的问题。在大学场景中，分析师可能会研究过去一个月的出勤率，并调查哪些变化与下降趋势相关。

数据科学则常通过统计学、机器学习、计算和领域知识处理定义不明确或模型密集型的问题。它可能用于解释模式、估算影响、划分观测对象或进行预测。大学可以利用它来预测未来六个月的交通需求。

在实践中，两者都通过数据实现目标，且具体边界因组织而异。两者都需要受控、适用、高质量的数据，并明确了解其结果将支持的决策。

分析应从明确的问题开始。大学可能会询问交通服务是否提高了出勤率，或下周学生将请求多少次乘车。前者需要严谨的因果设计，后者则需要预测或预测模型。

在明确问题后，会建立一个涵盖从问题到最终分析产品（如仪表板、报告或对决策有贡献的知识）的完整流程。

在此过程中，通常会构建一个分析数据集作为后续分析的来源。然后，通过探索该数据集来理解数据、进行数学建模或执行数据转换。换句话说，分析过程从应用适合业务问题需求的技术开始。

最后，如果需要训练机器学习模型，会进行特定的转换以准备数据集进行训练，使其达到模型就绪状态。训练完成后，结果通过报告、API或通过在基础设施中部署模型进行预测等方式交付。

在此过程中，多个角色协同合作，例如数据分析师通过分析回答业务问题，数据科学家则提出假设并开发模型来描述数据或进行预测。分析工程师专注于构建分析数据集，而数据工程师则构建提供这些数据集的管道和基础设施。

此外，当需要将机器学习模型集成到应用程序中时，机器学习工程师也会参与其中。

### 分析数据集

分析数据集是为特定分析准备的。它不是随机文件的集合：它具有已知的模式、粒度、人口统计、时间段、质量标准和血缘关系。团队选择数据是因为其与问题相关，而不是包含所有可用字段。

在大学案例中，为了研究出租车服务是否改善出勤率，可以构建一个包含已使用或未使用出租车服务学生的行程记录和出勤率的数据集，从而比较他们的出勤统计数据。

另一方面，为了预测交通需求，构建另一个数据集会更加合适，该数据集应整合旅行历史记录与课程表、学术日历或天气状况等信息。因此，尽管两个数据集可能复用部分数据源，但它们的结构、粒度和质量规则会有所不同，因为每个数据集都必须针对特定的业务问题进行设计。

数据集应该如何构建，是数据分析师或数据科学家的职责，而数据转换和其他构建过程的实现则由分析工程师负责。但如果需要整合多个数据源，数据工程师将负责处理该任务，正如我们之前所看到的。

这些数据集通常以数据仓库、数据湖中的表格形式，或以Apache Parquet等列式文件的形式进行存储。

### 探索性数据分析

大多数分析都会包含探索性数据分析（EDA），因为在分析初期，你很少能完全理解一个新数据集。

在团队得出结论或构建模型之前，EDA会检查数据集的分布、模式、关系和异常值。它还会审查数据类型、缺失值、重复值、质量限制以及可能的偏见来源。

关于探索性分析技术，描述性统计和可视化创建通常是关键。例如，数据分析师可能会展示每天支付的注册人数，比较使用的支付方式，并分析更多事件发生的时间。通过这种方式，他们可以发现是否有任何参与交易的支付平台或银行在某个时间点导致了注册支付问题。

他们还可能观察到提前支付的学生取得更好学术成绩的现象，但这种相关性并不能证明提前支付是主要原因。尽管如此，探索性分析的作用是生成这种假设并检测可能的替代解释，但本身并不能确认因果关系。

探索性数据分析由数据分析师和数据科学家共同执行，但方式不同，分析师侧重于诊断问题，而科学家则探索数据以决定如何建模。

他们用于探索的技术种类繁多，从使用SQL查询数据集，到使用Jupyter Notebook更方便地记录Python代码，再到使用Python库如pandas、NumPy、SciPy、Matplotlib和Seaborn。其他支持数据探索的语言还包括R、Julia和Scala。

### 特征工程

在完成数据探索后，通常会根据特定目的对数据进行转换，以提高其可用性。如果我们把数据视为一组记录，每条记录在一系列称为特征的属性中取值，那么这些特征有时可能对训练机器学习模型或理解数据更有用或更无用。

例如，如果我们有以（姓名、电子邮件、1）形式表示的学生记录，那么一个固定值为1的特征除非有某种合理的现实原因始终取值1，否则对分析没有帮助。在这种情况下，理想的做法是移除该特征，只保留最有用的特征。

特征工程通过转换或推导模型输入，使其能够有效代表问题。常用技术包括对尺度敏感算法的归一化或标准化处理、对缺失值的数据填补、类别编码以及离散化处理。每个选择都应基于业务含义、模型类型和评估计划，而非固定配方。

例如，假设某大学希望预测学生是否能完成硕士课程。为此，他们拥有一个包含课堂出勤率、成绩和虚拟校园访问次数等特征的分析数据集，这些数据将用于训练预测模型。

对于对特征尺度敏感的模型，归一化可能有所帮助。因为成绩范围在0到10之间，而门户访问次数可能达到数千。最小-最大缩放可以将它们映射到[0,1]区间，尽管其他算法或缩放方法可能更适用。

团队还必须排除预测时无法获取的信息。如果某个特征直接或间接揭示了结果，数据泄露会使评估结果看起来不切实际。

这些转换通常由数据科学家、分析工程师、数据工程师或机器学习工程师执行。这些角色主要使用SQL、Apache Spark或Python等技术完成转换，尽管并非仅限于这些工具。

### 实验

许多分析都在检验假设。如果团队认为某个特征无法提升模型表现，可以明确表述这一观点，并通过实验比较包含和不包含该特征的模型训练效果。

实验通过改变数据集、方法或训练过程的可控部分来验证假设。这项工作具有迭代性：一次实验结果可能推翻原有假设，或为下一次实验提出更优的问题。

在该领域，需要区分两种具有不同目的的实验类型。首先是分析性实验，它基于已收集的数据进行，重点比较特征、模型类型和训练技术，以确定哪种组合最能回答业务问题。

例如，为了预测学生是否能完成硕士课程，大学可能首先使用仅包含成绩和出勤率的简单模型。随后，他们可以进行另一项实验，纳入虚拟校园登录次数或尝试不同算法。

这样就能判断该变更是否真正提升了预测能力，还是仅仅增加了模型复杂度。

此外，该模型应使用训练数据以外的数据进行评估。否则，模型可能会“作弊”，在训练数据上表现良好，却无法“泛化”到实际数据中实现相同性能。

受控实验引入某种变化，并将接受该变化的实验组与未接受变化的对照组进行结果比较。在可行且符合伦理的前提下，随机分配有助于使两组保持可比性。

例如，若要判断出租车服务是否能提高出勤率，大学可在符合伦理和法律的前提下，逐步向一小部分学生推出该服务。此处的假设是该服务能提高出勤率，通过对比使用该服务的学生与未使用学生的数据（如课堂出勤率百分比等指标），分析处理数据与对照数据来验证假设。

实验应具有可重复性。团队可通过 Git 对代码和配置进行版本管理，而 MLflow 等平台可记录运行过程、参数、指标和相关文件。

数据科学家通常与数据分析师和领域专家共同制定假设并设计模型实验。机器学习工程师可能协助构建在生产规模下可靠稳定的训练和评估流程。

### 模型可用数据

分析数据集通常已准备好进行分析，但并非总是如此。若目标是训练机器学习模型进行预测，数据集需满足额外条件。

训练模型时，数据需达到模型可用标准：即已针对所选算法、评估设计和生产使用进行准备。监督学习数据集需要记录目标变量以学习结果。无监督方法无需标签即可运行，因此模型可用要求取决于具体任务。

例如，若要预测学生是否会退出硕士项目，历史训练记录需要包含结果标签（如学生参考编号、注册科目、退学状态）。团队应排除姓名等直接标识符作为模型特征，除非有正当理由，同时需审查预测结果是否公平且适合使用。

团队还需根据评估设计将数据划分为训练集、验证集和最终测试集。在开发模型时不得使用预留的测试数据进行决策，之后用该测试集对未见过的案例进行性能评估。对于基于时间的预测，划分也应遵循时间顺序。

最后，模型可用还意味着数据能代表模型需要学习的目标概念。例如，若仅用退学学生数据训练预测硕士项目退学的模型，该模型可能无法学习到不退学的模式，导致数据集不具代表性。

因此，确保数据集达到模型可用标准是数据工程师、数据科学家和机器学习工程师的共同责任。

### 分析产品交付

只有当分析结果以可用形式传递给合适的人或系统时，分析才能创造价值。例如，若大学使用模型识别异常考试行为，应将输出视为授权人工审核的信号，而非证明违规的证据。

分析产品交付为每项结果提供合适的使用渠道。该渠道可能是报告、仪表板、警报、文件、API 或嵌入应用程序的预测。

例如，大学可通过报告或仪表板交付出勤分析。一个经过严格管理的预测退学风险模型，可能通过内部 API 向授权支持团队发送有限警报，团队在提供帮助前会先审查背景信息。渠道和控制措施应与预期用途和潜在影响相匹配。

分析产品交付的相关实践包括定义结果的使用者、更新频率和质量指标。这些内容会与数据源和其他方面一起进行文档记录，同时对交付机制进行监控。

在示例中，一个包含出勤分析的仪表板将由校长办公室和硕士协调员作为使用者，每月更新一次新数据。同时，退学预测模型会通过API将警报发送给学术官员，即使该官员通过应用程序访问它。

交付由数据产品负责人或产品经理协调，而由分析工程师、软件工程师或BI开发人员等专业人员组成的技术团队则负责实现所有结果交付机制。

## 数据产品

分析结果并不自动成为产品。数据产品将受管控的数据与定义使用者使用的方式以及一个保持其长期实用性的运营模型相结合。

它可能以数据集、API、仪表板或其他接口的形式存在。单独的仪表板或文件并不一定构成数据产品：它需要明确的目的、已知的使用者、所有权、文档记录以及定义的质量和服务预期。

在我们关注的用例中，大学可以创建一个“流动性资格数据产品”。它将仅结合用于交通福利所需的批准注册、面对面日程、距离和资格属性。API可以将资格决定及其生效日期返回到学生门户，而一个单独的受管控数据集可以提供聚合的服务指标。

保持该产品的聚焦性可以避免向不需要完整学生档案的使用者暴露完整的学生信息。

### 产品特性

在此背景下，管理数据产品应像管理商业产品一样进行，因此需要定义其使用者和负责人，并确保其质量和可用性。

但在数据领域，任何产品都有一些基本特性：

- 可发现性：必须通过数据目录或适当的工具进行访问。

- 可理解性：数据模式、语义以及所有有助于理解与可追溯性的方面（如血缘关系）必须进行文档记录。

- 可靠性：质量与可用性需根据明确的预期进行衡量，并在产品未能达到预期时进行监控和响应处理。

- 安全性：实施访问控制，并最大限度减少个人数据的暴露。

- 互操作性：数据应能够与其他系统集成并正确运行。

- 稳定性：这意味着数据的模式、属性或消费方式不应频繁更改。

数据契约可以正式化产品接口的重要部分，如模式、语义、质量规则和更新频率。产品还需要有关所有权、访问权限、支持、生命周期和使用者预期的文档记录。

### 所有权和生命周期

没有单一角色单独构建数据产品。数据产品负责人与使用者合作，定义需求，并根据预期价值设定目标。

在技术层面，有数据工程师、分析工程师或平台工程师等角色，他们负责存储和分析数据的基础设施，生成成为产品的结果。

生命周期包括识别消费者需求、定义产品及其合同、构建和发布产品、监控服务和数据质量、改进产品，最终退役产品。

采用是成功的一个标志，但仅靠这一点并不足够。产品应帮助消费者实现有价值的成果，同时保持质量、可用性、安全性和可持续的运营成本。

## 数据管理组织

我们已经讨论了众多能力、技术和角色。数据管理组织定义了这些人员如何协作、如何在生命周期中做出决策以及如何解决问题。

其运营模型分配了权限和责任，设立了论坛和工作流程，并为团队提供了一致的问题解决方式和价值交付方式。

### 运营模型

运营模型组织决策和交付流程。在集中式模型中，一个数据团队负责大部分工作。这可以提高一致性，但该团队可能与领域知识脱节，或成为瓶颈。

另一种运营模型是分散式模型，其中每个部门或组织领域自行管理其领域的数据，这提高了自主性，但增加了数据不一致和数据孤岛的风险，使全局决策更加困难。

数据孤岛指的是信息被隔离在某个领域或系统中，使其他组织部分难以访问或获取这些信息。

许多组织采用混合或联邦模型，旨在结合两种方法的优势。在此模型中，每个领域对其数据保持一定程度的自主权，并负责其质量、文档和使用，而中央单位则制定需在整个组织中遵守的治理原则、标准和政策。

例如，大学的混合组织模型可能由首席数据官（CDO）领导的中央数据管理办公室负责，而学术活动、财务或移动性等不同领域则拥有自己的数据所有者、数据管理员和技术团队。如果多个领域需要协作，数据治理委员会可协助相关协作的决策。

### 角色与协作

在此背景下，主要角色已有所提及。但关于它们之间的协作，关键在于明确并记录各自的职责。这可以通过文档、RACI矩阵、数据合同、治理章程或设置工作流程等方式进行规范化。

为实现有效协调，会使用Git仓库进行协作版本管理、数据目录、类似Jira的平台进行沟通以及可观测性工具。但技术手段无法替代权限分配、沟通和明确职责的必要性。

## 数据管理成熟度

不同组织在应用这些能力的一致性上存在差异。数据管理成熟度描述了实践的嵌入程度、衡量方式、治理方式以及与组织目标的对齐程度。

例如，成熟度较低的组织会根据临时需求，以孤立和临时的方式管理数据。随着成熟度提升，流程和管理实践开始被记录，从而实现标准化、受控和自动化。在最高成熟度阶段，组织会采用受控的管理方法，通过质量指标、审计和正式的风险管理来控制管理策略。

成熟度不仅关注技术层面，还关注协调人员、明确其职责以及使用工具的能力，以实现与组织战略一致的可持续成果。

### 成熟度等级

一个典型的成熟度模型包含以下等级：

- 等级0 – 无能力：没有组织化的数据管理实践，行动完全根据当前情况临时决定。

- 等级1 – 初始阶段：管理职责分配给特定专业人员，但对个人行动或协作方式缺乏控制。

- 等级2 – 受控阶段：流程、角色和工具开始被记录，以促进管理任务的复制和自动化。

- 等级3 – 定义阶段：政策和标准在组织内被统一规范化，确保所有团队以协调且可扩展的方式工作。

- 等级4 – 可衡量阶段：通过审计和指标更深入地控制管理，评估绩效并主动降低风险。

- 等级5 – 优化阶段：团队利用指标、反馈和适当自动化持续改进管理，提前解决可能影响用户的问题。

### 评估与路线图

要确定组织的成熟度等级并提升其水平，团队可以使用**数据管理成熟度评估**（Data Management Maturity Assessment）。

该过程首先定义需要评估的数据领域和管理能力。随后收集证据，分析这些能力所达到的成熟度水平，检查文档内容、遵循的政策等。

通过与目标成熟度等级对比，制定路线图以实现目标，具体步骤会因组织当前水平和具体情况而显著不同。

该过程由首席数据官（CDO）或数据治理办公室（Data Governance Office）主导，数据所有者（Data Owners）、数据管理员（Data Stewards）和技术团队参与其中。

例如，在大学中，如果学生服务资格审查完全依赖人工操作且依赖特定个人的知识，那么移动性领域（Mobility domain）将处于等级1。在等级2阶段，职责将被明确分配，开始记录资格定义的文档，并实现基础验证的自动化。

在等级3阶段，数据产品可以统一规则下访问选定的移动性信息。在等级4阶段，仪表板可以跟踪质量、可用性、使用情况、成本、公平性和事件。在等级5阶段，团队会在适当场景下自动化低风险工作，保留对关键资格决策的人工复核和申诉路径，并通过指标和用户反馈持续改进服务。

但目标不一定是所有能力都达到等级5。大学可能要求在保护个人数据的安全性和质量能力方面达到高成熟度，而对不涉及个人数据的课堂使用实验性分析，可能设定较低的目标。

## 结论

在整个本书中，我们将数据管理视为一组协调一致的能力，这些能力帮助组织在其数据生命周期中捕获、整合、保护、理解并利用数据。

更广泛的大学生态系统展示了真实组织的规模，而我们的招生、学术活动和交通示例则使这些联系更加具体。即使是一个受控的交通福利，所需的内容远不止一个数据库：它需要治理、质量、隐私、整合、可靠的运营和细致的分析。

数据不会自动产生价值。当人们为其提供上下文、保护数据、将其提供给合适的使用者，并将其与实际目标连接时，数据才会变得有用。技术是手段，而非目标。数据库、管道、仪表盘、模型和数据产品只有在解决真实需求时才有意义。

阅读更多文章。

如果这篇文章对你有帮助，请分享它。

免费学习编程。freeCodeCamp 的开源课程已帮助超过 40,000 人成为开发者。立即开始

ADVERTISEMENT