从数据到价值：通过一个实际应用案例来理解数据管理[完整书籍]

数据验证

数据验证通过执行相关规则来判断数据是否符合既定要求。与仅用于分析数据当前状态的流程不同，数据验证会将数据值与明确的条件进行对比。

注册表单可能会要求填写学生的姓名，但API和数据库仍需对其进行验证，因为客户端进行的检查可能被绕过，而且数据在传输过程中也可能会出现问题。关系型数据库可以通过NOT NULL、UNIQUE、CHECK约束以及外键等机制来确保数据的合法性。应用程序和数据处理流程中的检查则可以处理那些涉及多个系统或需要更多背景信息的验证规则。

数据质量分析师负责定义并评估这些验证规则，而数据工程师、软件工程师、分析工程师及数据库专家则会将这些规则应用到相应的层级中。

数据清洗

验证过程可能会显示所有记录都符合规则要求；但当有记录不符合规则时，团队需要制定明确的处理措施：拒绝这些记录、将其隔离、进行修正、补充相关信息，或者在记录中注明异常情况后仍接受它们。

数据清洗的作用是检测并纠正已知的数据缺陷，从而使数据符合使用要求。具体的数据处理方式取决于数据的类型、相关的规则，以及团队是否能够安全地确定正确的处理结果。例如：

• 为避免出现不一致的情况，某条规则可能会规定姓名中不能包含开头或结尾的空格。因此，如果出现像' Chloé Moreau '这样的姓名，该规则就会判定这些数据不符合要求，此时可以通过删除多余的空格来修复这个问题，从而恢复数据的准确性。

• 另一条规则可能要求所有日期都必须采用YYYY-MM-DD这种格式。因此，如果出现像'15/09/2025'这样的日期格式，数据就不符合规则要求，但可以通过将其转换为'2025-09-15'来使其符合规定的格式。

根据数据的类型、相关规则以及所存在的问题，有些数据处理操作可以自动完成，而有些则可能需要人工干预才能确保其正确性。例如，姓名中的空格很容易被检测出来并删除，但其他一些问题可能会更加复杂，需要手动进行处理。

数据工程师、分析工程师、应用程序开发团队或运维人员都可以负责数据的清洗工作，而数据质量分析师和数据管理员则会对这些清洗方法进行审核。整个数据处理过程必须保留足够的可追溯性，以便能够解释哪些内容发生了变化以及变化的原因。仅仅消除表面问题并不能从根本上解决数据质量问题。

数据质量监控

数据验证不应仅在数据首次进入系统时进行。数据质量监控会定期运行相关的规则和检测流程，存储检测结果，并在数据质量下降时及时提醒相关团队采取行动。

这些定期评估是使用AWS Glue Data Quality或Microsoft Purview等技术来进行的，而这些技术都是由数据工程师和DataOps团队负责维护的。

问题管理

当出现质量问题的时候，问题管理会记录该问题、确定其优先级、进行调查并最终解决它。问题的优先级取决于它对人们、决策过程、合规性以及业务流程的影响，而不仅仅取决于错误数据的数量。

例如，如果由于某些错误导致所有距离数值都显示为负数，从而导致学生无法使用交通服务，那么这就会影响用户体验；而如果某个学生因此无法参加重要的考试，后果可能会更加严重。因此，问题必须尽快得到解决。

一般来说，问题管理会遵循以下步骤进行：

1. 记录与分类：当有规则被违反时，就会对该事件进行记录，包括其严重程度以及负责处理相关规则或数据域的人员。

2. 控制问题的进一步发展：根据质量问题的严重程度或影响范围，会采取相应的措施来防止问题进一步恶化。例如，如果某条规则规定支付记录不得重复，而检测到了重复记录，那么可能会暂时阻止所有支付操作，直到问题得到解决。

3. 分析问题原因：会通过数据追溯机制来排查问题产生的原因。

4. 进行纠正：一旦找出了问题的原因，就会对其进行纠正，并重新执行相关规则，以验证纠正措施是否有效，并将整个解决过程记录下来。

如果出现了重复的支付记录，数据质量分析师会负责发现并协调处理这个问题；数据所有者会确定问题的优先级，而数据工程师或应用程序团队则会解决其中的技术问题。财务和合规部门也可能需要对纠正措施进行验证。

简而言之，质量标准决定了某个使用场景中哪些因素是重要的；数据分析可以了解当前的数据状况；规则能够明确各项要求；验证机制可以确认这些要求是否得到满足；数据清洗步骤可以针对存在的问题进行适当的调整；而监控系统则能及时发现任何变化。当问题真正影响到生产环境时，问题管理流程就会协调各方资源来应对这些问题。

数据工程

我们之前已经讨论过那些用于存储、交换、保护及验证数据的系统。现在，我们可以来看看各团队是如何在实际工作中构建数据采集流程、数据处理管道以及实现这些系统之间的连接的。

数据工程致力于设计、构建并运维那些用于收集及处理数据的流程与系统组件。它的作用是将数据从一个或多个数据源传输到人们或各种应用程序所需要的系统中，这些系统包括数据仓库和数据湖等平台。

数据工程涉及架构设计、数据存储、系统集成以及数据质量保障等方面，但它并不会取代这些领域的相关工作。正是由于这种交叉性，数据工程师在之前的许多章节中都被提及过。

数据工程的实现范围可以从简单的SQL查询任务延伸到复杂的分布式流处理管道。无论哪种情况，数据工程都会负责管理各种依赖关系、自动化重复性工作、测试变更内容，并监控整个流程的执行过程。

其目标在于让其他专业人士能够使用可靠的数据，而无需重新从各个数据源获取信息。

例如，假设某所大学想要为管理层创建一个仪表板，以便分析每月的交通服务成本。为此，仅仅查询一个数据库是远远不够的——因为出行相关数据可能存储在一个数据库中，而费用或支付信息则可能保存在交通服务提供商的系统中。

此外，各个数据源的更新频率各不相同，且它们使用的数据结构也各不相同。因此，在这种情况下，数据工程的作用就是构建一套流程，来完成以下这些步骤：

1. 从每个数据源中提取所需数据。
2. 通过规则验证数据的准确性。

3. 进行必要的

   数据转换操作，包括修复数据错误、统一日期格式、单位以及标识符等。

4. 将处理后的数据

   插入目标系统，如数据仓库或数据湖等。

5. 在数据插入目标系统后，可能还需要对它们进行

   汇总或进一步处理，以便后续使用。

数据工程师会与数据架构师、数据管理员以及数据质量分析师一起设计并实施这些流程。他们共同努力，确保最终方案能够满足技术及组织方面的要求。分析工程师、数据分析师、数据科学家以及其他用户都会使用这些处理后的数据。

如果基础设施的规模足够大，那么数据平台工程师、DevOps工程师以及站点可靠性工程师等也会参与其中，协助维护系统的正常运行。

数据管道

数据管道是一系列自动化任务的组合，它负责将数据从一个或多个数据源传输并处理后，存储到一个或多个目标系统中。其中某个任务可能会读取数据、验证其准确性、对数据进行转换、确定数据传输路径，或者将处理结果传递给下一个任务。

数据管道可以以批量模式或流式模式运行。全量加载会读取所有选定的数据集，而增量加载则只会处理自某个已知时间点之后新增或发生变更的记录。其中一个非常重要的设计特性是幂等性：安全地重复执行相同的操作不应会导致不必要的数据重复或结果不一致的问题。

其他重要的特性还包括可扩展性——这意味着即使处理大量数据，也不会影响系统的正常运行；同时，还需要具备可追溯性，以便了解数据处理的具体时间以及产生的结果。

数据管道通常由数据工程师设计并实现，但根据数据的最终用途，集成工程师或分析工程师也可能参与其中。

用于实现数据管道的技术种类繁多，具体取决于所使用的基础设施。这些技术可能包括使用SPARQL或SQL进行查询、利用Python、Apache Spark或Apache Flink进行数据转换，甚至还会借助Google Cloud Dataflow等云服务来完成相关任务。

管道编排

在定义了数据管道的任务、输入源、输出结果以及数据来源和目标之后，接下来就需要协调这些组件之间的依赖关系。这种协调工作就是管道编排。

举个例子，假设某个数据管道需要先获取学生的信息和旅行记录，然后再收集支付数据，而这些数据最终都需要被插入到一个只接受同时包含支付信息和学生个人信息的记录的数据仓库中。在这种情况下，在进行数据插入之前，必须先从所有来源获取完整的数据，因为这些数据需要被合并处理。而在其他一些数据管道中，可能可以在数据刚被获取到时就立即将其插入数据库中。

数据管道中的这些依赖关系通常用有向无环图来表示，其中每个节点代表一个任务，而每条连接线则表示它们之间的依赖关系。这种数据结构还可以帮助编排软件精确地判断某个任务何时可以执行，以及根据其执行结果应该采取什么行动。

目前最常用的管道编排技术包括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这样的框架。

工作流程自动化

数据处理管道还可以检查数据的来源是否可用、验证数据的质量、管理审批流程，并发送通知。工作流程自动化能够按所需的顺序协调这些操作，从而确保重复性的工作不会依赖于有人手动执行每一道步骤。

需要明确的是，数据处理管道与工作流程是不同的。数据处理管道描述了数据的传输路径及其转换过程；而工作流程则包括那些并不直接修改数据、但对数据处理的顺利进行至关重要的任务。

例如，当大学从运输公司收到一份文件时，工作流程可以验证该文件的格式，监控数据处理的整个过程，并更新相关的数据追溯工具。

不过，自动化工作流程并不意味着完全消除人工干预。比如，可以设置规则来检测源数据中是否出现了本不应出现的个人信息。如果系统检测到这类信息，数据管理员就需要介入，决定是批准这些变更还是拒绝它们，并采取相应的措施。

最后，工作流程通常是借助Apache Airflow、Dagster或Prefect这样的工具来实现的，同时还会结合CI/CD系统和事件管理工具一起使用。

数据测试

在自动化执行数据处理管道时，即使没有完全消除人工监督的需要，整个流程中仍会存在出现错误的可能性。即便实施得非常完美，也依然有可能发生影响数据质量或导致任务失败的问题。

数据测试旨在检查转换代码以及通过数据处理管道传输的数据本身，这样团队就能在这些问题影响到最终用户之前及时发现并加以解决。

测试套件应当涵盖代码、数据结构、数据本身、依赖关系以及基础设施可能出现的各种真实故障情况。数据测试与数据质量规则存在重叠，但团队可能会出于不同的原因来应用这些规则。

质量规则体现了业务需求或系统性能要求，而流程测试则用于验证某些技术前提条件或预期的处理结果。同样的检查措施可以同时满足这两种目的。

常见的测试类型包括：

• 单元测试：这类测试用于确认在给定输入条件下，相关代码能否产生正确的输出结果。例如，如果某个转换函数负责将距离从公里转换为米，那么就可以用18、4、6这些数值作为输入进行测试，预期输出结果应为18000、4000、6000。

• 数据结构测试：这类测试用于确认数据的格式和结构是否适合特定用途。例如，当接收到存储为整数42的学生年龄信息时，数据结构测试会验证该数据确实属于整数类型。

• 集成测试：这类测试用于确认系统中的各个组件能否按预期进行交互。例如，集成测试可以验证大学的数据库是否能够从学术管理系统中获取数据。

• 端到端测试：这类测试会执行整个处理流程，以确保最终结果在给定初始数据的情况下是正确的。

• 一致性测试：这类测试用于比较不同处理阶段中的计数值、总数或控制参数是否一致。例如，如果某个规则规定应保留100条输入记录中的50条，那么测试就会同时验证输出结果的数量以及被排除在外的记录的原因。

• 性能测试：鉴于某些处理流程的复杂性，性能测试用于评估其在指定时间内、使用现有资源的情况下是否能够顺利完成。

在大学环境中，在部署任何处理流程之前，可以创建包含虚构信息的数据集（即合成数据集）用于测试。通过这种方式，就可以执行所有这些类型的测试，从而确保各项任务都能正确完成，数据在每次转换后都能保持预期的格式和属性，并且整个流程也能在规定的时间内结束。

测试技术的实施与具体的处理流程密切相关。例如，使用Python编写的转换脚本可以采用pytest进行测试，而SQL则适用于一致性测试和数据结构验证。数据工程师通常负责编写大部分流程测试代码，而平台工程师或DevOps工程师则会帮助将这些测试集成到自动化部署环境和运行时环境中。

数据版本控制

由于业务需求的变化、数据源的更新或其他原因，数据管道通常会发生变更。因此，记录数据管道随时间的发展历程至关重要，这样就能追溯其变化过程，尤其是有助于排查故障。

数据版本控制能够保存生成特定结果所需的所有资源的历史记录。根据具体的应用场景，这些资源可能包括转换代码、数据结构、配置信息、参考数据、模型输入数据，以及数据集本身的快照或不同版本。

举个例子，假设某份报告显示某个月花费了10,000美元用于打车，但后来核实后发现实际上这个数字是8,000美元。这种差异可能是由于计算错误，或是用于成本核算的规则发生了变化（比如不再将取消的行程计入费用中）。

为了确定这种情况是否属于错误，通过版本控制可以查看参与该计算的数据管道的早期版本，从而了解数据是如何被计算出来的。

团队通常会使用Git来管理代码、配置文件以及基于文本的数据结构。而像Apache Iceberg、Delta Lake和Apache Hudi这样的表格存储技术，则能够为支持这些技术的表格保存数据快照及变更历史记录。在某些情况下，同时使用这两种工具才能确保数据处理的可重复性。

数据平台运维

一旦数据管道被创建并进行了版本控制，就需要相应的基础设施来运行它们——这些硬件可以安装在大学服务器上，也可以部署在云端。通常还需要存储空间来保存数据，计算资源用于数据转换处理，调度系统用于协调各项任务，此外还需要专门的系统来保障数据和流程的安全性。所有这些组件共同构成了数据平台，也就是执行数据管道及其他业务流程的技术环境。

数据平台本身也需要进行管理和维护，因为它并非完全自主运行的系统，而是需要人工监管的。这种管理活动被称为数据平台运维，它包括一系列旨在确保平台能够安全、稳定、高效地运行数据管道的任务。

其中一些最基础的任务包括：

• 资源配置与扩展：需要为数据库和平台各组件配置所需的硬件资源数量。

• 环境管理与隔离：会为测试、开发和生产环境分别创建独立的系统环境，其中生产环境会向最终用户提供服务。

• 权限控制：为每位工作人员设定合适的操作权限，以防止安全漏洞的发生。

• 成本控制与优化：监控资源使用情况，避免过度支出，力求以最少的资源消耗来实现所需的服务功能。

例如，一个用于计算出租车月使用成本的流程可能需要连接交通公司的API，对数据进行处理，然后将其存储在数据仓库中。

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

通常由数据平台工程师来负责这项工作，他们需要了解平台所依赖的各种服务，比如AWS、Azure、Google Cloud、Databricks或Snowflake等。Docker可用于打包合适的工作负载，Kubernetes可以在复杂情况下对容器进行调度管理，而Terraform则可以实现基础设施的代码化定义。虽然这种代码化方式可以提高工作的可重复性，但它并不能确保服务能够在不同的云服务提供商之间自动迁移。

数据可观测性

即使所有任务都报告成功，数据平台也可能会以隐蔽的方式出现故障。数据可观测性能够帮助团队了解数据的状况以及生成这些数据的系统的运行状态，从而及时发现并处理故障，减少其带来的影响。

可观测性允许我们根据系统产生的各种信号来推断其当前的状态。在数据处理的背景下，这些信号包括数据的更新频率、数据量、数据结构、分布情况、质量结果、数据来源等信息，以及任务的状态、日志记录、各项指标和追踪信息等。

监控机制会检查一些已知的条件，比如某个任务是否已经完成，数据的更新频率或数量是否在预期范围内。基础设施相关的信号（如CPU使用率和内存占用量）有助于分析故障原因，而数据层面的信号则能说明最终接收方是否得到了正确的数据结果。

例如，如果一个数据处理流程本应生成数百条记录，但实际上只产生了几十条，监控系统就能及时发现这种异常。此外，它还能显示在相同时间点获取的其他相关指标信息，比如参与该流程的各个任务的CPU使用情况，从而帮助判断是否存在任务失败的情况，防止错误数据继续被处理。

为了让可观测性结果能够为实际操作提供指导，团队可以为相关的性能指标定义服务水平指标(SLI)，并为期望达到的目标设定服务水平目标(SLO)。例如，SLI可以用来衡量最新数据的生成时间间隔，而SLO则可能规定每天有99%的更新内容必须在早上7点之前准备好。当系统运行情况接近这些目标时，警报机制会及时提醒团队。

在可观测性领域，Prometheus和Grafana是应用最为广泛的技术工具，它们主要用于收集和可视化各种指标数据。此外，OpenTelemetry用于管理遥测数据和日志记录，而OpenLineage则能够实时追踪数据的来源路径。

在这种情况下，数据工程师可能会负责实施相应的可观测性机制。不过，这项工作并不总是由他们单独完成，因为SRE团队、平台工程师或数据运营团队也可能会参与其中，共同维护这些机制的正常运行。

数据契约

可观测性有助于检测各种错误，例如任务失败、数据过期、数据量异常以及模式变更未预见等情况。例如，如果某出租车服务提供商在未经通知的情况下将地理坐标从数字形式改为文本形式，那么即使网络连接仍然正常，下游流程也可能会出错。

数据契约通过明确规定生产方与消费方之间的期望值，从而降低这类风险。它们定义了数据的结构与特征，同时也规定了各团队之间如何进行沟通以及版本变更该如何处理。可观测性机制仍能确保这些契约在实际运行过程中得到遵守。

更具体地说，数据契约可以明确规定数据的模式、类型、格式、语义规则、质量标准、所有权信息、交付频率、延迟时间以及变更管理的相关要求。

例如，某运输公司可能会约定，每条行程记录应包含(trip_id, student_reference, provider_vehicle_id, price, origin, destination)这些字段。契约可以规定price应以欧元为单位进行表示，坐标信息应为数值形式的纬度/经度对，同时为student_reference设置隐私保护限制，并且当数据结构发生不兼容的变更时，必须使用新的契约版本。

需要强调的是，数据契约并不仅仅是一种文档形式。还会通过相应的检查机制来验证各项规定是否得到遵守，这样就能确保任何变更都不会影响到数据处理流程——因为变更既可能影响数据的可用性，也可能威胁其安全性。

为了制定数据契约，人们通常会使用JSON Schema、Apache Avro、Protocol Buffers之类的技术来描述数据结构；当然，开放数据契约标准这类标准也同样会被采用。

数据契约的制定和审核工作通常由企业内部的数据工程师和分析工程师来完成，他们会与其他公司的专家进行协作，比如那些了解自身数据来源特性的软件工程师。在更高层面上，数据所有者及数据管理员也会参与其中，以确保数据的语义正确性、质量标准以及使用规范得到满足。

数据运营

数据工程涉及众多人员与各个组成部分。即使当前的系统目前运行正常，但如果各团队在修改数据来源、契约内容、代码、基础设施或质量规则时缺乏协调，系统也可能会变得不可靠。

数据运营是一种旨在提升这种协作效率与交付流程的方法。它的目标是在保证数据质量、安全性和可追溯性的前提下，缩短从业务需求产生到获得可靠数据的整个过程。

数据运营并不是一种特定的技术工具，而是一系列实践方法，包括对代码进行版本控制、自动化测试、在受控环境中审核并部署变更内容，以及监控生产流程等。这些方法借鉴了敏捷开发与软件运维领域的理念，并将其应用于数据管理领域。

例如，假设某所大学开始与一家新的出租车公司合作。第一步可能是制定一份规定数据交付相关条件的数据合同。随后，数据工程师会使用相应的工具通过连接器获取这些数据，并将其存储在Git中。

另外，在将相关系统投入实际应用之前，还需要进行数据和代码测试，以确保其功能正常。部署完成后，还需要通过数据量、数据质量以及响应延迟等指标来监控系统的运行情况。

数据工程师、分析工程师、数据管理员、数据负责人、平台工程师、运维人员以及数据使用者共同参与了DataOps的实施。只有当那些负责数据的生成、操作和使用的人员能够共同承担确保数据可靠交付的责任时，这些实践才能真正发挥作用。

DevOps

正如我刚才提到的，DataOps借鉴了DevOps中的诸多理念。DevOps是一系列最佳实践的集合，这些实践有助于协调软件的开发与系统的部署工作，其最终目标就是确保各项变更能够以自动化且可靠的方式得到测试、部署和维护。

常用的技术包括 GitHub Actions、GitLab CI/CD 或 Jenkins，这些工具可用于自动化测试和部署流程。Docker 也被广泛用于软件打包，而 Terraform 或 OpenTofu 则用于定义基础设施架构。当系统的规模和复杂性要求时，Kubernetes 也可以用来管理容器。

DevOps工程师、平台工程师以及系统运维工程师负责实施和维护这些技术机制，而数据工程师则利用它们来部署自己的数据处理流程。两者之间的主要区别在于：DevOps更侧重于软件和基础设施的交付与运营管理，而 DataOps还会关注数据的质量、语义、来源追溯性以及可用性等特定方面。

数据仓库与商业智能

企业会通过各种数据处理流程来收集、整合并转换数据，然后将其存储在适合特定工作负载要求的系统中。操作型数据库则为维持日常业务运转所需的应用程序和交易提供支持。

数据分析通常需要整合历史数据、使用稳定的数据定义，并执行能够扫描大量记录的查询操作。数据仓库和数据湖等专用平台正好能满足这些需求。数据仓库与商业智能使人们能够获取经过规范管理的分析数据，从而利用这些数据来做出决策。

这两个概念是相互关联的。数据仓库指的是用于整合来自不同来源的历史数据，以便进行重复性分析工作的系统设计及应用。

操作型数据分析与分析型数据分析在工作优先级和数据访问方式上存在差异。虽然有些平台能够同时支持这两种类型的数据处理需求，但团队在面对性能、数据更新频率、数据一致性以及成本等方面的权衡时，仍需做出选择。将这两类数据处理任务分开处理，通常有助于保障日常业务的正常运行，并让分析人员能够使用专为他们的查询需求设计的分析模型。

商业智能涉及用于数据查询、分析及呈现的各种实践和技术，这些技术为决策制定提供了支持。虽然商业智能工具也可以使用其他数据来源，但数据仓库往往能为商业智能分析提供规范化的数据基础。

例如，一所大学可能会在数据仓库中整合学生的出行数据和财务数据。分析人员可以通过对比不同供应商的服务成本、使用情况、出席率以及预算等信息，来评估该校提供的交通服务是否具有可持续性，并估算短期内的相关支出成本。

分析数据存储系统

分析型工作负载通常需要扫描较长的时间跨度，整合来自多个来源的数据，并对大量记录进行汇总处理。专为操作事务设计的存储系统可能并不适合用于执行这类重复性操作。

分析数据存储系统就是专门为分析查询、数据转换及汇总操作而设计的。这些系统同样需要具备安全性控制机制和数据一致性保障措施，但其性能优化方向通常更侧重于在大型数据集上执行扫描和计算任务，而非处理高频发生的行级事务。

分析数据存储系统最典型的代表就是数据仓库——它能够以稳定且可扩展的方式存储数据，从而确保即使在数据量不断增加的情况下，也能重复使用相同的分析流程。

不过，这并不是唯一的解决方案。数据湖也同样适用于这类用途，而数据集市则提供了规模较小的分析环境（通常只是数据仓库中的一部分数据），专门用于满足特定部门或业务领域的需求。

例如，一所大学可以创建一个数据集市，其中存储与学生出行情况相关的信息以及分析服务成本所需的有限财务数据，同时确保不会泄露学生的其他私人信息。这个数据集市应该像其他分析资源一样，配备相应的血缘关系追踪机制、安全控制措施、质量保障体系及审计功能。

目前最常用于实现这些系统的平台包括Snowflake、Google BigQuery、Amazon Redshift、Microsoft Fabric Data Warehouse以及Databricks SQL。这些平台的設计与实施工作由分析架构师或数据架构师负责；数据工程师则负责维护为这些系统提供数据的信息管道；而分析开发人员则会处理数据入库后的转换操作，以便后续的分析工作能够顺利进行。

在管理和维护层面，还有数据仓库管理员或平台工程师负责监控系统的运行性能、管理用户权限以及控制相关平台的成本开支。

基本概念与技术细节

根据所使用的平台和层次结构的不同，分析数据存储系统可能会以原始数据的形式保存信息，也可能会将其组织成特定的数据模型。数据湖通常会在早期阶段保留原始数据格式，而经过整理的数据层或数据仓库则会采用更为结构化的数据库模式。

一种常见的分析方法是前面提到过的维度建模。这种方法会将信息分为事实数据和维度数据两类：事实数据用于记录具体的事件，而维度数据则为过滤、分组和比较操作提供必要的背景信息。

一个特别重要的设计决策是粒度，也就是事实表中每一行所代表的具体含义。团队在选择维度与度量指标之前，就应该明确这一概念，这样才能确保后续的数据聚合操作能够准确进行。

例如，行程事实表的粒度可能是“一次完成的行程”。如果某学生在同一天进行了两次行程，那么该事实表就会记录下两条记录，每条记录都会包含费用、距离、耗时以及日期等信息。学校可以按月份对这些记录进行求和分析；但绝对不能在同一事实表中添加反映“月度总计”信息的记录，因为这些记录的粒度不同，会导致数据重复计算。

一旦确定了粒度，接下来就应该根据描述事实内容的背景信息以及预期要执行的分析需求来选择相应的维度。一个实用的判断方法就是思考：对于每一条事实记录来说，涉及的是谁、发生了什么、在何时何地发生的、又是如何发生的？例如，如果每一行记录都代表一次行程，那么就可以选择“学生”“日期”“交通服务提供者”“出发地”和“目的地”等维度，因为这些维度都能为该行程提供独特的信息。

通过这些维度，我们可以分析行程发生的地理位置、哪些交通公司提供的服务更受欢迎等等。这样，所选择的维度就能为我们分析事实数据提供有用的视角。

这种数据建模工作通常由分析工程师或数据模型设计师与领域专家（如数据管理员）共同完成。之后，数据工程师会负责实现数据导入及转换操作，使数据能够适配到每个系统的具体最终数据模型中。

指标与关键绩效指标

在维度模型中，事实记录可以被视作由数值组成的行，这些数值被称为度量指标。这些度量指标有助于我们了解某段时间内特定事件的发展情况，但数据分析的目的通常是为了回答涉及某一时间段内所有事件的问题。

团队会将各种度量指标合并成可重复计算的指标，比如总数、比率、平均值和百分位数等。当某个指标与重要的业务目标相关联，并且能够帮助我们判断组织是否实现了这一目标时，它就变成了关键绩效指标。以下是一些例子：

概念	含义	示例
度量指标	记录在事实数据中的数值	某次行程的费用为18欧元
指标	针对一组度量指标进行重复计算得出的结果	月度交通费用 = 当月所有已完成行程的费用之和
关键绩效指标	与业务目标相关联的指标	月度移动出行预算消耗情况，其目标是确保不超过分配的预算额度

显而易见，并非所有的指标都属于关键绩效指标。例如，某个用于反映某个月内出行次数的指标，虽然有助于了解交通服务的使用情况，但只有当存在需要量化这一出行次数的业务目标时，它才会被视作关键绩效指标。

关键绩效指标通常会被用于数据看板和可视化展示中，不过它们一般不会单独出现。当将多个关键绩效指标及其当前数值收集起来，并与既定目标进行对比时，这种汇总方式就被称为“记分卡”。

尽管这两个概念之间存在关联，但记分卡与数据看板的作用是不同的：记分卡的目的是用来判断各项目标是否已经实现，而数据看板则有助于了解组织当前正在发生什么以及原因何在。

同一个指标可能会同时出现在数据看板、记分卡、报告以及应用程序接口中，因此团队需要为这一指标制定一个可重复使用的定义。其文档应包含以下内容：

• 该指标的名称、用途以及负责它的业务部门。

• 用于计算该指标数值的公式、数据来源及其详细程度。

• 该指标的值所使用的单位、统计的时间周期、时区，以及数据更新的频率。

• 相关的过滤规则，比如是否在计算过程中排除被取消的行程。

• 如果这是一个关键绩效指标，还需要记录制定这一指标的具体业务目标。

实际上，指标和关键绩效指标的定义工作主要由业务负责人、数据所有者以及数据管理员来完成；而它们的具体实施工作则由分析工程师和商业智能开发人员负责；最终，这些指标的结果会被数据分析师等其他专业人士所使用。

语义层

正如我之前所说，对各种指标进行文档化记录的目的是为了确保人们能够准确理解它们的含义及计算方法。然而，这并不能保证所有系统都会严格遵守这些文档规定。

例如，某个系统在计算月度成本时可能会排除被取消的行程，而另一个系统却可能不小心将它们包含在内。在这两种情况下，虽然使用的是同一个“指标名称”，但计算结果却截然不同。

语义层这一概念正是为了解决这类问题而提出的。它通过将可重复使用的业务定义集中存储在数据存储系统与数据使用工具之间，使得人们无需再直接从数据库表结构中推导出各种计算逻辑。例如，“行程”“学生”或“课程”这样的概念就可以被直接使用，而无需每个数据使用者都重新编写相应的计算代码。

这样一来，构成各个指标的计算公式和过滤规则就被统一地存储在语义层中，而不是由不同的分析师在数据库、数据仓库或其他系统中分别编写代码来实现。这种机制起到了中介作用：它能够将用业务语言表达的指标计算逻辑转化为特定系统所需的执行代码，从而便于日后对指标进行修改，同时也便于在不同系统之间实现数据共享与迁移。

例如，在数据仓库中，可能会存在一个“行程”事实表、一个“日期”维度，以及每个事实记录中的成本数值。在这里，语义层会定义诸如“行程”和“成本”这样的概念，而这些概念的计算方式会被以某种方式“映射”到用于实现各个系统的具体技术上。

在这种情况下，“每月总成本”这一指标的计算可以在语义层中进行定义；系统内部会将这一定义转化为SQL操作或相应的技术手段，从而按月份对行程进行分组，并汇总各组数据中的成本数值。

指标的定义与其在语义层中的实现方式之间的主要区别在于：指标的定义仅说明了该指标是什么以及其计算方法，而在语义层中，这些定义会被转化成特定技术能够执行的操作步骤。

因此，多个仪表板或报告都可以重用在语义层中定义的相同逻辑，因为有时需要对不同系统中的数据进行处理和分析。

用于实现语义层的工具包括Power BI语义模型、LookML、dbt语义层以及Cube等。分析工程师和BI开发人员通常会在业务负责人和分析师的参与下构建并维护这些定义。

报告与仪表板

在将“分析数据存储”系统投入实际使用并确定了一些指标或关键绩效指标之后，下一步就是创建能够向最终用户、专业人士或高管展示分析结果的商业智能产品。

最常见的这类产品就是报告和仪表板，不过它们并不是唯一的形式——分析结果还可以被用来生成可视化图表，或者用于记录决策过程等内容。

让我们进一步了解这两种产品的区别：

报告是一种详细、有条理地呈现特定主题和时间段内信息的文档。它可能包含图表、指标以及解释性文字。报告可以定期以PDF等静态格式生成，也可以设计成交互式形式，让用户能够筛选或操作其中展示的数据。

例如，一所大学可能会编制一份月度报告，其中会按服务提供者划分交通服务的成本，同时列出被取消的行程、使用该服务的学生人数等信息。

仪表板则是一种汇集了最相关指标和关键绩效指标的视图，用于实时监控某种情况。仪表板通常包含图表等视觉元素，这些内容的更新频率通常比报告更高。

例如，行政管理部门使用的仪表板可以显示已消耗的预算、注册学生的数量以及出勤趋势；如果该仪表板是交互式的，用户还可以根据培训项目来筛选相关数据。

在创建仪表板时，有一些最佳实践可以遵循，以确保这些仪表板能够发挥实际作用。例如，你应该只展示少数几个指标，并且这些指标必须与仪表板的用途密切相关。此外，选择合适的可视化方式并不仅仅是为了美观，这些图表应当能够帮助人们理解所呈现的信息，其设计也必须符合相关最佳实践。

一般来说，当需要定期监控一小部分指标并迅速发现其中的变化或偏差时，就会使用仪表板；而当你需要对某个主题进行更深入的分析时，则会使用报告。不过，这两种工具其实可以相互补充。

例如，管理部门可以使用仪表板来监测运输费用的增加情况，然后通过查阅月度报告来确定是哪些供应商、路线或时间段导致了这一现象。

在创建这类工具时，最常用的技术包括Microsoft Power BI、Tableau、Looker、Apache Superset和Metabase。这些技术主要由商业智能开发人员使用，不过商业智能管理员也会参与管理这些工具的开发环境。最终，商业智能分析师可以解读这些分析结果，在某些情况下，他们也会与商业智能开发人员一起合作编写报告或设计仪表板。

自助式分析

数据分析过程会生成诸如仪表板或报告之类的工具，这些工具会以结构化的方式呈现特定信息。但有时，人们可能需要对这些工具的用途进行修改。

例如，财务部门可能会创建一个专门用于监控学校为出租车服务分配的预算的仪表板，但某个硕士项目的负责人可能需要将这些交通数据与该培训项目的出勤记录进行对比分析，以确定这项服务是否真的带来了好处——这种特定的需求是原始仪表板所无法满足的。

协调人可以要求技术团队修改仪表板，但这样一来，每一个小改动都可能进入开发流程。而自助式分析则允许授权用户自主探索受管控的数据，并创建合适的分析报告，而无需在每一步都依赖技术专家的帮助。

这种做法依赖于我们之前讨论过的一些要素，比如用于存储各项指标的语义层、能够帮助用户快速查找所需信息的数据目录，以及用于统一商业概念含义的业务术语表。这些工具被团队成员们用来独立创建可视化图表和报告，不过由于现有的隐私政策限制，他们可能无法访问所有类型的数据。正因为如此，这种分析方式才被称为“受管理的自助式分析”。

例如，如果某个仪表板显示运输费用有所增加，负责协调工作的主管可以使用语义层为该项目的数据设置筛选条件。这样，语义层就能确保使用官方规定的成本计算标准，同时权限设置也能防止访问其他项目的数据或不必要的个人信息。

需要指出的是，原始的仪表板并不会被直接修改，而是由协调者根据需要进行更新，创建新的仪表板。

在实际应用中，这种方法的可行性主要得益于分析工程师、商业智能开发人员和商业智能管理员之间的紧密协作。最终使用这一功能的用户主要是数据分析师、业务分析师以及企业管理人员。

大数据

数据生命周期会贯穿一系列系统和流程。数据首先被输入系统，然后进行传输、存储和处理，最终到达需要使用这些数据的部门或个人手中。

对于工作量适中的情况，相对简单的架构往往能够满足性能、可靠性及成本方面的要求。然而，随着组织规模的扩大，可能就需要存储更多的数据，更频繁地处理各种事件，并支持更多种类型的 数据格式和应用场景。

最初在单台机器上运行的数据库，可以通过增加CPU、内存或存储空间来实现纵向扩展。当工作负载或系统容错需求达到一定程度时，就需要通过多台机器进行横向扩展，不过这种复杂性的增加必须是出于实际需要的考虑。

大数据指的是那些数据量巨大、处理速度快、种类繁多，或者其组合方式超出了传统工具所能处理的范围的数据集。挑战并不在于数据量的庞大，而在于如何在这样的规模下保证处理速度、可靠性和成本控制。

在讨论大数据时，人们可能会认为存在一个明确的界限，超过这个界限的数据就属于大数据。但实际上，并非如此，因为这个界限取决于当前的基础设施、目标处理速度、团队为管理这些数据愿意承担的成本，以及数据结构的复杂性等因素。

只有当现有基础设施无法满足组织在性能、可靠性或成本方面的要求时，才应该考虑采用大数据解决方案。虽然分布式架构可能会带来一些好处，但也会增加运营管理的复杂性，因此这些好处必须能够证明采取这种方案的必要性。

例如，一所大学由于院系规模的扩大或引入在线课程，其学生人数可能会从1000人增加到10万人。在这种情况下，数据库必须能够存储所有这些学生的个人信息，以及他们在使用虚拟校园等各种服务与平台时所产生的数据，而且存储速度必须足够快，以确保服务的可用性和质量不会受到影响。

大数据需要在更大规模上运用各种数据管理技术。大数据工程师通常是指那些专门从事分布式存储与处理工作的数据工程师。他们与负责设计解决方案的数据架构师以及负责运营数据平台的工程师们共同协作。

三大特征：数据量、处理速度和数据多样性

虽然并没有一个统一的标准来界定什么是大数据，但“数据量”、“处理速度”和“数据多样性”这三个要素为人们提供了有用的参考依据。这些并不是每个项目都必须满足的条件，而是指那些会使得现有基础设施难以应对的数据挑战。

数据量指的是需要被存储和处理的总数据量。这里面临的首要问题是：数据会占用大量的存储空间，因此当数据量过大时，某些系统可能无法有效处理这些数据。此外，随着数据量的增加，各种管理流程也会变得效率更低，因为所有数据都需要经过相应的处理流程才能被存储或使用。

• 举例：以学生产生的数据为例：学生人数越多，需要存储和处理的数据量也就越大。每个学生都会生成诸如登录记录之类的数据，如果数据量过大，这些数据就会占用大量的存储空间，并消耗大量的计算资源。

处理速度指的是数据到达、发生变化以及被用户获取的速度。

• 举例：对于打车服务来说，系统必须每隔几秒钟就更新一次车辆的位置和状态信息，这样用户才能实时了解到附近有哪些可用的出租车。因此，确保数据能够快速被获取对于提供良好的用户体验至关重要。

数据多样性指的是数据的种类、结构或格式的复杂性。例如，学术数据库可能使用关系型数据库模型来存储学生信息，而虚拟校园则可能会用半结构化的JSON文档来记录各种数据；还有一些基于图结构的数据库，它们会利用图表来表示学生、司机和地点之间的关系，从而优化交通路线规划。

• 举例：学术数据库可以使用关系型模型将学生的注册信息和个人信息存储在表格中，而虚拟校园则可能使用半结构化的JSON文档来记录各种活动日志；图结构数据库则可以通过图表来展示学生、司机和地点之间的关系，从而帮助优化交通路线。

数据量的增加会直接影响存储、传输和处理成本。因此，在分配数据处理任务之前，团队可以对数据模型、数据分区方式、查询逻辑或数据保留策略进行优化。当单台计算机的性能无法满足需求时，水平扩展就成了一个可行的解决方案。

并非所有数据都需要实时处理。实时的行程状态更新可能只需要几秒钟的时间，而历史学费支付记录则可以按每日固定的时间间隔进行更新。所需的延迟时长应当由用户需求和业务实际需要来决定，而不是出于将所有数据处理流程都设置为实时的考虑。

最后，数据的多样性是其最重要的特性之一，因为这种多样性决定了组织内部数据集的复杂性。由于存在结构、格式及表现形式各异的数据，因此针对每种不同类型的数据，采取特定的处理技术就显得十分必要，这样才能确保对这些数据的高效管理。

这些通常被认为是大数据所具备的特性。但同样重要的是，也要关注其他重要的特性，比如数据的真实性，即数据的可靠性；以及数据的价值等其他方面。

大数据架构

当“三大数据特征”超出了“传统”解决方案的处理能力时，就有几种方法可以提升基础设施的能力以满足这些需求。但首先，有必要明确什么是基础设施。

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

架构则描述了各组成部分是如何利用这些基础设施来满足特定需求的。它规定了系统运行所在的地点，存储与处理任务是如何分布的，以及数据从生成点到最终被使用的过程中所经过的路径。

因此，如果“三大数据特征”使得现有的解决方案无法正常运作，那么可能就需要对它的架构进行修改。如前所述，应对数据量增加或处理速度提升的一种方法是垂直扩展，即通过升级硬件为每台机器提供更多资源。但这种扩展方式存在极限，因此才有了水平扩展这一概念——通过增加更多的机器来分散存储和处理任务。

另一种提高处理速度的方法是在多台机器上并行执行各种处理流程，这就是所谓的大规模并行处理技术。

有很多方法可以提升基础设施的能力，尤其是在需要以更快的速度处理更多数据的情况下。然而，对于种类繁多的数据而言，如果没有成熟的通用处理技术，对其进行有效管理往往是一项挑战，尽管数据分布策略在一定程度上可以帮助缓解这一问题。

要更好地理解什么是架构，可以将它想象成由多个层次构成的系统，其中每一层都包含某些特定的组成部分，而这些部分共同决定了数据在组织内部整个生命周期中所经过的路径。

层次	功能	示例	使用的技术
数据来源	数据的获取或生成地点	出租车公司的API及支付平台	REST API、PostgreSQL、物联网传感器
数据导入	将数据从来源处传输到平台上	接收校园活动信息以及提供者的行程更新	Apache Kafka、Apache Airflow
数据存储	持久化存储数据	保存各类事件记录、文件以及经过整理的分析数据表	Amazon S3、Google Cloud Storage
数据处理	根据数据用途对数据进行清洗和转换	在数据流程中删除重复的行程记录	Apache Spark、Apache Flink
信息展示	提供可供查询的信息	数据仓库会呈现整合后的行程信息及相关费用	Snowflake、Google BigQuery
数据应用	利用这些信息进行决策或实现其他用途	仪表盘可显示交通服务的月度费用情况	Power BI、Tableau、Jupyter

任何架构的另一个重要方面在于，其各个层级都必须实施安全性、数据追溯机制以及可观测性措施，同时还要确保数据的隐私性。

想象一下，有学生通过虚拟校园系统叫了一辆出租车。此时，该架构必须能够保护这一操作并对其进行追踪。通过流处理方式，可以在几秒钟内更新门户网站上的行程状态；而之后再通过批处理流程来整理相关数据，以便进行成本分析。

这种处理速度上的差异，正是调整架构的一种方式——这样就能确保某些关键功能具备所需的处理速度，同时也能让那些不需要实时处理的分析任务能够处理更大的数据量。

最终，架构是由数据架构师或大数据架构师设计的，而数据工程师、流处理工程师或软件工程师则负责将其实现。其维护工作则由数据平台工程师、云工程师以及系统运维人员来完成。

大数据存储与处理

在设计好架构之后，就需要将其各个组成部分付诸实施，其中一些组件专门用于以所需规模存储和处理数据。一方面，存储系统的作用是确保数据的持久性、安全性以及可访问性；另一方面，处理系统则利用计算资源对数据进行转换与分析。

大学可能会将经过授权的虚拟校园事件记录、出勤信息以及行程数据保存数年之久，因此这就产生了巨大的存储需求。而数据处理的需求则可能变化较大，在报告期或重大学术活动期间，处理量会达到高峰。

通过将存储功能与处理功能分开来看，如果我们需要设计用于在基础设施中存储数据的系统，那么可能会遇到以下几种解决方案：

• 分布式数据库：这类数据库被部署在多台机器上运行，所使用的技术包括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来执行相关任务，并确保系统具备足够的性能。

另一方面，数据平台工程师、云工程师以及运维工程师则负责维护基础设施的稳定性、可用性及弹性。

大数据分析

在大数据领域，除了需要存储海量且种类繁多的数据，并以极高的速度进行实时处理外，这些数据还必须被转化为信息、知识，最终产生实际价值。因此，数据处理主要指的是对数据进行各种转换操作，以便于存储、清理数据或保持其质量。

不过，在数据存储之后，还会进一步运用处理技术来计算统计结果或分析数据本身。这就是大数据分析的作用——这一领域专门致力于通过分析大量数据，将信息转化为实际价值。

只有当数据分析的工作量规模或数据流动特性需要借助分布式架构或其他专业基础设施才能完成时，这种分析才属于大数据范畴。进行数据分析并不一定需要先进的机器学习技术，而且仅仅使用可扩展的云平台，并不能使一项普通的分析任务变成“大数据分析”项目。

基于这样的技术基础，根据具体的分析需求，你可以采用以下几种基本的分析方法：

• 描述性分析：这类分析侧重于运用各种技术来探究数据，从而了解已经发生的情况。例如，可以通过这些分析手段计算出共进行了多少次旅行、这些旅行的总成本是多少，以及每个月有多少名学生使用了这项服务。

• 诊断性分析：这种分析的目的是弄清楚某个结果产生的原因。在大学环境中，可以利用这类分析来研究哪些供应商提供的时间段会导致交通服务成本的增加。

• 预测性分析：通过分析历史数据，可以对未来可能发生的情况进行预测。例如，可以预估下学期会收到多少份入学申请。

• 规范性分析：这类分析会将分析结果转化为具体的建议或方案。比如，在优化出租车队列分配或重新安排月度预算时，这类分析就能提供有价值的参考意见，从而确保尽可能多的学生能够享受到相关服务。

在大数据环境中，分析可以根据各个流程的需求，采用批量处理或流式处理的方式来进行。例如，使用Apache Spark可以定期计算出租车费用的变化情况以及课堂出勤率；而使用Flink则可以对实时发生的交易数据进行分析，一旦需求量超过某个阈值，就能立即发出警报。 要想让分析过程真正发挥作用，首先需要明确通过这些分析想要得到的答案，以及预期能够因此产生的价值，也就是这些分析结果将用于做出哪些决策。接下来，就需要挑选并准备所需的数据，确保其质量足以满足分析需求。分析完成后，结果可以通过仪表板、报告、警报、API或预测模型等方式进行呈现。 需要注意的是，数据量越大，并不总能带来“更准确”的结论或更多的价值。例如，如果使用出租车服务的学生出勤率更高，也不能直接据此认为交通便利是导致这一现象的原因，因为这些学生可能本来就参加了更多面对面的课程，或者存在其他差异。 因此，除了要处理海量信息之外，正确解读分析结果也同样至关重要。在这个例子中，我们需要明白：相关性并不总是意味着因果关系，但这也不是分析过程中唯一可能出现的问题。 数据工程师负责构建和维护数据分析流程及环境；数据分析师则使用SQL、Trino、Spark SQL、Power BI、Tableau等工具进行各种分析工作，这些分析通常具有描述性或诊断性性质；数据科学家则利用Python、R、Jupyter、Spark或MLlib等工具来进行统计建模、实验验证、预测分析及优化工作。 商业智能开发人员会将经过处理的指标和分析结果转化为报告或仪表板；机器学习工程师则负责模型的训练、部署和运行管理；领域专家、数据所有者及数据管理员则会协助团队负责任地解读和使用这些分析结果。

分析科学与数据科学

各组织通过数据分析来了解当前的情况、支持决策制定、验证各种想法，并建立相应的模型。这是他们将数据转化为知识与价值的主要途径之一。

分析技术与数据科学是相互交叉、相辅相成的领域。分析技术通常侧重于运用描述性、诊断性、预测性或规范性的方法来回答特定的问题。在大学里，分析师可能会研究过去一个月内的出勤情况，进而探究哪些变化与成绩下降之间存在关联。

数据科学通常通过统计学、机器学习、计算方法以及领域知识来处理那些定义不明确或需要依赖复杂模型来解决的问题。它能够揭示数据中的规律、估算各种效应、对观测数据进行分类，或者进行预测分析。例如，大学可以利用这些技术来预测未来六个月的交通需求。

实际上，数据分析和数据挖掘都是利用数据来实现特定目标的，而两者之间的界限往往因组织而异。无论是数据分析还是数据挖掘，都需要使用规范、高质量的数据，并且要清楚地了解这些分析结果将用于支持哪些决策。

任何分析工作都应从明确的问题开始。大学可能会想知道：提供交通便利是否真的能提高学生的出勤率，又或者下周学生们会请求多少次乘车服务。对于第一个问题，需要设计严谨的因果分析模型；而对于第二个问题，则需要运用预测模型来得到答案。

在明确了分析目标之后，接下来就需要制定一套完整的分析流程，这个流程涵盖了从问题提出到最终生成分析结果的全部环节——无论是制作数据看板、编写报告，还是形成有助于决策的知识体系。

在这个分析过程中，通常会首先构建一个分析数据集，作为后续分析的基础。然后会对这个数据集进行深入研究，以便了解其中的数据特征、用数学模型对数据进行建模，或者对其进行必要的处理。换句话说，分析工作总是从选择适合具体业务需求的技术方法开始的。 如果需要训练机器学习模型，还需要对数据集进行特定的预处理，以确保其能够被用于模型训练，从而被认为是“适合模型训练”的数据集。训练完成后，分析结果可以通过报告、应用程序编程接口（API）的形式呈现出来，或者直接将训练好的模型部署到实际应用系统中来进行预测等操作。 在这个过程中，不同的角色会共同协作：数据分析师负责解决与数据分析相关的问题；数据科学家则负责提出假设并开发模型来解释数据或进行预测；分析工程师专注于构建分析数据集，而数据工程师则负责搭建提供这些数据集所需的基础设施和数据处理流程。 当需要将机器学习模型集成到某个应用程序中时，机器学习工程师也会参与其中。

分析数据集

分析数据集是为特定的分析目的而专门准备的数据集合。它并不是随意收集的各种文件，而是具有明确的结构、数据粒度、样本规模、时间范围、质量标准以及数据来源等信息。团队会根据分析需求有选择地提取相关数据，而不是简单地包含所有可用的字段。 以大学为例，如果想研究出租车服务是否有助于提高学生的出勤率，就可以构建一个数据集，其中包含那些使用过出租车服务和没有使用过出租车服务的学生的出行记录以及他们的出勤情况，这样就能对比这两组学生的出勤数据了。

另一方面，如果要预测交通需求，那么构建一个将出行历史与课程安排、教学日历或天气状况相结合的新数据集会更为合适。因此，尽管这两组数据可能会重用一些数据来源，但它们的结构、详细程度以及质量标准会有所不同，因为每一组数据都必须根据特定的业务需求来进行设计。

数据集的设计工作应由数据分析师或数据科学家负责，而进行数据转换及其他构建数据集所需流程的工作则由分析工程师来完成。不过，如果需要整合来自多个来源的数据，那么数据工程师就会承担这项任务，正如我们前面所提到的那样。

这些数据集通常会以表格的形式存储在数据仓库或数据湖中，或者以Apache Parquet这类列式文件的形式存在。

探索性数据分析

大多数分析工作都会包含探索性数据分析，因为刚开始时，人们很少能完全理解一个新的数据集。

在团队得出结论或建立模型之前，探索性数据分析会先研究数据集的分布情况、存在哪些模式、各种数据之间有什么关联，以及哪些数值是不正常的。此外，它还会检查数据的类型、缺失值的情况、重复数据的存在，分析数据的质量问题，以及可能存在的偏差来源。

在探索性数据分析的技术手段中，描述性统计分析和制作可视化图表通常是关键步骤。例如，数据分析师可以统计每天有多少人完成了缴费操作，比较不同的支付方式，分析在哪些时间段内缴费事件发生得更加频繁。通过这些分析，他们可以发现其中某些支付平台或银行是否在某个环节导致了缴费问题。

他们还可能会观察到一些现象，比如那些提前完成缴费的学生往往取得了更好的学习成绩，但这种相关性并不能证明提前缴费就是导致这一结果的根本原因。不过，探索性数据分析确实有助于提出这样的假设，并找出其他可能的解释因素，但它本身并不能确定因果关系是否成立。

无论是数据分析师还是数据科学家都会进行探索性数据分析，只不过他们的分析方法有所不同：分析师们主要是通过分析来发现问题，而数据科学家则通过探索数据来决定该如何对数据进行建模。

他们用于探索性数据分析的工具非常多样，从用于查询数据集的SQL语言，到便于记录Python代码的Jupyter笔记本，再到pandas、NumPy、SciPy、Matplotlib和Seaborn等Python库。R、Julia或Scala等其他编程语言也同样可用于数据探索。

特征工程

在分析数据之后，通常会根据具体的使用目的对数据进行相应的处理，以使其更具实用性。如果我们将数据视为一组记录，而每条记录都包含一系列被称为“特征”的属性值，那么这些特征在用于训练机器学习模型或帮助理解数据时，其作用可能会有所不同。 例如，如果我们拥有的学生记录格式为“（姓名、电子邮件、1）”，那么其中那个值为1的特征，除非它具有某种实际意义且始终取值为1，否则对分析来说并没有任何帮助。在这种情况下，最好删除这个特征，只保留那些真正有用的特征。 “特征工程”这一技术旨在对模型输入数据进行处理或转换，使其能够更有效地反映问题实质。常用的方法包括：对于那些对数据规模敏感的算法，可以使用“规范化”或“标准化”来调整数据的范围；对于存在缺失值的字段，可以采用“数据填充”技术来补充这些值；此外，还需要对分类变量进行编码处理，并将连续型数据离散化。在选择具体的处理方法时，应始终考虑业务需求、模型类型以及评估方案，而不是盲目遵循某种固定的流程。 举个例子，假设某所大学想要预测学生是否能够完成硕士学业。为此，他们收集了一组分析数据，其中包含学生的出勤情况、成绩以及访问虚拟校园的次数等特征信息，这些数据随后将被用来训练机器学习模型来进行预测。 对于那些对特征数值范围敏感的模型来说，“规范化”处理可能会非常有用。因为成绩的范围通常是0到10分，而访问次数的范围可能高达数千次，通过规范化处理，可以将这些数据的范围统一调整到[0, 1]区间内，从而使得模型能够更准确地进行预测。当然，也有可能有其他更适合的算法或方法来处理这类数据。 团队还需要剔除那些在预测时无法获取的信息。如果某个特征能够直接或间接地预判结果，那么使用这种特征进行预测可能会导致评估结果显得不真实、过于理想化。 这些数据转换工作通常由“数据科学家”、“分析工程师”、“数据工程师”或“机器学习工程师”来负责完成。他们会使用SQL、Apache Spark或Python等技术来进行这些操作，不过也有可能使用其他工具或方法。 ## 实验验证 许多数据分析过程实际上都是在测试某种假设。如果团队认为某个特征对模型的效果没有提升，他们可以明确地提出这一观点，并通过实验来比较在包含该特征与不包含该特征的模型之间的差异。

实验是指通过改变数据集中的某些受控部分、所使用的方法或训练流程，来验证某种假设。这种研究方式是迭代性的：一次实验的结果可能会否定最初的设想，或者为下一次实验提供新的方向或问题。

在这个领域，区分两种目的不同的实验类型是非常重要的。首先，有一种是分析性实验，这种实验是在已经收集到的数据上进行的，其目的是通过比较各种特征、模型类型以及训练方法，来确定哪种组合才能最好地解决实际业务问题。

例如，如果想要预测某位学生是否能够完成硕士学业，学校可以先使用仅包含成绩和出勤情况的简单模型进行测试；然后，他们可以尝试加入虚拟校园登录次数这样的因素，或者换用不同的算法来进行实验。

通过这种方式，就可以判断这种改变究竟是真正提升了模型的预测能力，还是仅仅增加了模型的复杂性而已。

另外，这种模型必须使用在训练过程中未曾使用过的数据来进行评估。否则，该模型可能会“投机取巧”——在训练数据上表现良好，但在实际应用中却无法取得同样的效果。

对照实验则会引入某种变化，并比较接受这种变化的实验组与未接受改变的对照组之间的实验结果。在条件允许且符合伦理规范的情况下，随机分配样本有助于确保两组之间的可比性。

比如，如果想验证某项出租车服务是否能够提高学生的出勤率，学校可以在符合伦理和法律规定的前提下，先在一小部分学生中逐步推行这项服务。然后，通过分析接受该服务的学生与未接受服务的学生的数据，比如出勤课程的比例等指标，来验证这一假设是否成立。

实验结果必须是可复现的。开发团队可以使用Git来管理代码和配置文件，而像MLflow这样的工具则可以记录实验运行的详细信息，包括参数设置、评估结果等各种数据。

数据科学家通常会与数据分析师以及领域专家一起制定假设并设计实验方案；而机器学习工程师则可以帮助确保这些训练和评估流程在大规模应用环境中能够稳定运行。

适合模型训练的数据

虽然分析性数据集往往已经可以直接用于分析，但实际情况并非总是如此。如果目标是利用这些数据来训练机器学习模型并进行预测，那么这些数据就必须满足额外的要求。

要想训练出一个有效的模型，数据必须适合模型训练——也就是说，这些数据必须能够适应所选算法、评估方法以及实际应用环境。对于监督学习来说，数据集中需要包含记录实验结果的目标变量；而对于无标签的数据集而言，是否适合模型训练则取决于具体的应用场景。

例如，如果想要预测某位学生是否会放弃硕士学业，那么历史训练数据中就需要包含诸如(学生编号, 报名课程, 是否退学)这样的标签信息。团队在将数据用于模型构建时，应尽量避免使用姓名等可以直接识别个人身份的信息，同时也要仔细评估所提出的预测方法是否公平、合理。

根据评估要求，该团队还会将数据分为用于训练、验证和最终测试的部分。在开发模型时，他们不会使用被保留下来的测试数据来做出决策，而是利用这些测试数据来客观地评估模型在处理未见过的数据时的表现。对于基于时间的预测任务，数据的分割方式也必须遵循时间顺序。

最后，所谓“模型可用”，也意味着这些数据能够真实反映我们希望模型学习的目标现象。例如，如果我们仅使用那些已经退学的人的数据来训练一个预测模型，那么这个模型很可能无法掌握那些能够判断某人是否会退学的规律，因此这样的数据集就不具备代表性。

因此，确保数据集具备模型使用的条件是数据工程师、数据科学家以及机器学习工程师的职责所在。

分析型产品的交付

只有当分析结果以人们可以使用的形式传递给目标受众或系统时，它才能真正创造价值。例如，如果一所大学使用模型来检测异常的考试行为，那么它应该将模型的输出视为需要人工审核的信号，而不是证明某人存在不当行为的证据。

分析型产品的交付会为每种分析结果提供合适的呈现方式。这种呈现形式可能是报告、仪表盘、警报信息、文件、API，或是嵌入在应用程序中的预测功能。

例如，学校可以通过报告或仪表盘来展示考勤分析结果。而一个用于评估学生退学风险的模型，则可以通过内部API向授权的支持团队发送警报信息，这些团队会在提供帮助之前先了解具体情况。所选择的呈现方式及其控制机制必须与数据的预期用途和可能产生的影响相匹配。

在分析型产品的交付过程中，需要明确结果的使用者、更新频率以及质量评估标准。所有这些细节都需要被记录下来，同时还要对数据来源及其他相关方面进行管理，并且要持续监控各种交付机制的运行情况。

以考勤分析为例，如果使用仪表盘来展示分析结果，那么校长办公室和硕士项目的负责人就会成为这些结果的接收者，而且数据会每月更新一次。而退学预测模型则会通过API将警报信息发送给学术事务官员，即使这些官员是通过应用程序来获取这些信息的。

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

数据产品

分析结果本身并不等同于数据产品。一个数据产品会将相关数据整理成一种结构，同时明确指定目标用户群体及其使用方式，并通过相应的运营模式确保这些数据长期保持其价值。

数据产品可以表现为数据集、API、仪表盘或其他形式。但仅仅是一个仪表盘或文件本身并不一定属于数据产品——它需要具备明确的用途、特定的使用者、明确的归属关系、详细的文档说明，以及明确的质量和服务标准。

以我们的具体应用场景为例，大学可以创建一个交通优惠资格数据产品。这个产品只会包含那些被批准参加相关计划的学生信息、他们的面授课程安排、是否属于远程学习人群等信息，这些信息正是申请交通优惠所必需的。通过API，可以将学生的资格审核结果及其生效日期发送到学生门户网站；而另一个专门的数据集则可以提供各种服务指标的汇总数据。

采取这种精简设计的方式，可以避免将学生的完整个人信息提供给那些并不需要这些信息的用户。

产品特性

在这种情况下，管理数据产品应该与管理商业产品一样进行，因此必须明确产品的目标用户群体以及负责其运营的部门，并确保产品的质量与可用性。

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

• 可被发现：数据产品必须能够通过数据目录或相应的工具被查询到。

• 易于理解：数据的结构、含义以及所有有助于人们理解这些数据的信息，比如数据的来源等，都必须有明确的文档记录。

• 可靠性：数据的产品质量与可用性必须根据明确的标准来衡量；当产品未能达到这些标准时，也必须有相应的监控机制和应对措施。

• 安全性：必须实施访问控制措施，同时尽量减少个人信息的泄露风险。

• 互操作性：数据应该能够被其他系统集成，并能在这些系统中正常使用。

• 稳定性：

  数据的结构、属性或使用方式都不应频繁发生变化。

数据契约能够明确产品接口中的关键要素，例如数据结构、语义规则、质量标准以及更新频率。此外，该产品还需要相关的文档来规定所有权、访问权限、技术支持、生命周期以及用户的期望值。

所有权与生命周期

没有任何一个角色能够单独完成数据产品的开发工作。数据产品负责人需要与用户进行沟通，明确需求，并根据预期价值设定目标。

从技术层面来看，数据工程师、分析工程师或平台工程师等人员会负责构建用于存储和分析数据的基础设施，进而生成最终的产品成果。

数据产品的生命周期包括：识别用户需求、定义产品及其相关契约、进行产品的开发与发布、监控服务质量和数据质量、不断对其进行优化，最后在适当的时候停止其使用。

产品的被采用程度是衡量其成功与否的一个指标，但仅仅这一点还不够。产品必须能够帮助用户取得实际的价值，并同时保证其质量、可用性、安全性以及可持续的运营成本。

数据管理组织结构

我们已经讨论了许多功能、技术以及相关角色。而数据管理组织结构则决定了这些人员如何协同工作、如何做出决策，以及在产品的整个生命周期中如何解决各种问题。

其运作模式会明确各项职责和权限，规定相应的沟通渠道和工作流程，从而确保各个团队能够以一致的方式解决问题并创造价值。

运作模式

运作模式有助于规范决策过程和成果的交付方式。在集中式运作模式下，通常由一个数据团队负责所有相关工作。这种模式可以提高一致性，但该团队可能会脱离实际业务需求，从而成为发展的瓶颈。

另一种运作模式是分散式运作模式，在这种模式下，组织的各个部门或业务单元分别负责管理各自领域的数据。虽然这种方式能够提高自主性，但也容易导致数据不一致或出现“数据孤岛”现象，进而增加全局决策的难度。

“数据孤岛”指的是那些被孤立在特定区域或系统中的信息，其他部门很难获取这些信息。

许多组织会采用混合式或联合式运作模式，这种模式试图结合两种模式的优点。在这种模式下，各个业务单元可以在一定程度上自主管理自己的数据，并负责保证数据的质量、编写相关文档以及确定数据的用途；而中央机构则会制定必须在整个组织范围内遵守的治理原则、标准和政策。

例如，一所大学采用的混合组织模式可能会设立一个由首席数据官领导的中央数据管理办公室，而学术活动、财务或移动管理等不同领域则会各自配备数据负责人、数据管理员和技术团队。当多个领域需要协作时，数据治理委员会可以协助制定与这种协作相关的决策。

角色与协作

在这种情况下，主要涉及的角色已经提到过。但就它们之间的协作而言，明确界定并记录这些角色的职责至关重要。这可以通过编写文档、使用RACI矩阵等工具、签订数据管理合同、制定治理章程，或建立工作流程等方式来实现。

为了确保有效的协调，人们会使用Git仓库等技术来协作处理各类工作，利用数据目录和Jira这样的沟通平台，还会运用可观测性工具。然而，技术并不能替代对权威、沟通以及明确职责的需求。

数据管理成熟度

不同组织在应用这些能力时的一致性程度各不相同。数据管理成熟度指的是各项实践在组织中的落实情况、衡量方式、治理机制，以及它们与组织目标的契合程度。

例如，一个成熟度较低的组织可能会根据具体需求采取孤立且临时的措施来管理数据。随着成熟度的提高，各种流程和管理实践会逐渐被记录下来并实现标准化、规范化，同时也会得到适当的自动化处理。在最高成熟度阶段，组织会采用系统化的管理方法，通过质量指标、审计和正式的风险管理机制来把控各项管理工作。

数据管理成熟度不仅关注技术层面，还强调协调人员、明确职责以及运用适当工具，从而确保各项工作能够与组织的战略目标保持一致，并取得可持续的成果。

成熟度等级

有一种常用的成熟度评估模型，它将成熟度划分为以下几个等级：

• 0级 – 无能力：组织没有系统化的数据管理实践，各项操作都是根据当前的需求临时决定的。

• 1级 – 初始阶段：虽然会指定专人负责数据管理工作，但无法对个人的行为或协作方式进行有效管控。

• 2级 – 有组织的管理：开始对相关流程、角色和工具进行记录，以便于复制和管理工作的自动化。

• 3级 – 规范化：政策和标准在整个组织范围内得到统一制定，确保所有团队能够以协调一致且可扩展的方式开展工作。

• 4级 – 可量化评估：通过审计和各项指标对管理工作进行深入监控，以便评估绩效并主动防范风险。

• 5级 – 最优化：团队会利用各种测量数据、反馈信息以及适当的自动化手段，不断改进管理流程，并在问题影响用户之前将其解决。

评估与发展路线图

为了确定组织在数据管理方面的成熟度并进一步提升这一水平，您的团队可以使用数据管理成熟度评估工具。

该流程首先需要明确哪些数据领域和管理能力需要被评估。随后会收集相关证据，分析这些能力目前的成熟程度，包括现有文档内容、所遵循的政策等。

通过将实际状况与目标成熟度进行对比，就可以制定出实现这一目标的发展路线图，其中的具体步骤会根据不同组织的情况及其当前水平而有所差异。

这个流程通常由CDO或数据治理办公室牵头推进，数据负责人、数据管理员以及技术团队也会参与其中。

例如，在大学环境中，如果学生是否具备使用某项服务的资格需要通过人工审核，并且这种审核依赖于特定人员的知识，那么相关数据管理能力的成熟度就可以被认定为1级。当达到2级时，就会明确各项职责，开始制定关于资格认定标准的文档，同时一些基本的验证流程也会实现自动化。

到了3级，各种数据产品就可以在统一的规则下提供对指定信息的访问服务；4级时，可以通过仪表盘来监控服务的质量、可用性、使用情况、成本以及公平性等方面；5级时，团队会在适合的情况下自动处理低风险任务，而对于那些需要人工审核或上诉的决策，则会保留相应的人为干预机制，并通过各项指标和用户反馈不断优化服务。

不过，并不是所有能力都必须达到5级。对于一所大学来说，保护个人数据的安全性与质量可能属于优先考虑的重点；而针对课堂使用情况进行的分析，由于不涉及个人数据，其目标成熟度就可以适当降低。

结论

在本书中，我们将数据管理视为一套协调统一的能力体系，这套体系能够帮助组织在其数据的整个生命周期内完成数据的捕获、整合、保护、理解与利用等工作。

大学这个更大的生态系统展示了真实组织的规模，而我们通过招生、学术活动以及交通管理等案例，使这些概念变得更加具体和易于理解。事实上，即便是像交通管理这样的应用领域，也需要远远超出数据库所能提供的功能——它还需要数据治理机制、质量保障措施、隐私保护体系、高效的数据整合能力、可靠的运营流程，以及细致的分析分析能力。

数据本身并不会自动产生价值。只有当人们为数据赋予具体的意义、保护这些数据、确保它们能够被合适的用户所使用，并将它们与实际的目标联系起来时，数据才会变得有用。技术只是实现这一目标的手段，而非最终目的。数据库、数据处理流程、仪表盘、模型以及各种数据产品，只有在它们真正解决了某种实际需求时，才具有意义。