什么是数据仓库图？

数据仓库图是对数据仓库架构的可视化展示，描绘了数据如何从源系统出发，经由各个层级，最终到达分析工具的过程。数据仓库图显示各组件之间的交互方式，例如提取、转换、加载（ETL）流程、存储系统、数据集市，以及分析和 AI 应用。数据仓库图有助于组织设计、追踪并向技术人员及非技术人员展示其数据仓库架构。

数据仓库图描绘了数据仓库的结构、操作和最终用途。从工程团队到业务决策者，任何与数据仓库交互的团队都可以使用数据仓库图来更好地了解数据在组织中的流动方式。

架构规划和设计

数据仓库图有助于支持数据仓库的规划和实施流程。使用数据仓库图可以确保所有参与构建的工程师拥有相同的愿景和目标，而不需要从零开始或临时构建数据仓库。它绘制了关键组件，例如数据来源、数据流经的处理步骤、任何依赖关系以及集成点。

提前尽可能多地了解数据处理流程有助于降低实施和运营阶段的风险。

利益相关者沟通

尽管数据仓库图可以包含技术文档，但它可以将抽象的数据流转化为易于理解的可视化表示。通过向利益相关者（尤其是那些没有技术背景的利益相关者）展示这种可视化方式，您可以清晰地传达数据仓库的工作原理、它与哪些系统集成以及为什么需要它。

文档和知识转移

您可以随着时间的推移不断添加和完善数据仓库图，并对所做的更改及其原因进行版本化文档记录。当需要转移有关数据仓库结构及其与数据系统其他部分互连方式的知识时，拥有最新的图表及其历史记录有助于系统工作人员进行培训。

系统优化和故障排除

将数据仓库逻辑映射为图表格式，可让您精确地追踪数据在整个组织中的数据血统。如果您遇到性能问题，可以检查图表的不同层，例如，查看冗余转换或故障点的位置。可视化参考可以帮助工程师在进行故障排除和缓解错误时更准确地进行调查。

数据仓库图表有多种类型，每种类型都包含特定形式的信息。

逻辑架构图

逻辑数据仓库架构是指关于数据如何在系统中流动的技术细节。逻辑数据仓库图表不包含有关实施技术或组件背后具体技术的详细信息。相反，它侧重于描述使系统能够正常运行的各个要素，包括数据源、转换流程、数据管理系统、数据集成工具、云数据仓库以及整体数据架构。

物理架构图

物理架构图是实用性图表，用于描述数据仓库的基础设施与技术。设计人员会利用数据流图来展示数据在 ETL 管道及各关联组件间的流动过程。此外，他们还会使用实体关系图（ERD）来定义数据仓库内数据的实际结构，涵盖数据结构、主键及外键等内容。

物理架构图的作用在于补充逻辑架构图中未包含的所有细节。该图应包含服务器模型、容器、数据库配置等信息，以帮助数据架构师明确具体的实施需求。

概念架构图

尽管技术细节较少，但概念架构图提供了结构层面的宏观概览。它不涉及具体的实施细节，而是侧重于关键组件之间的关系以及数据流转的整体结构。当需要向非技术利益相关者阐述构建数据仓库的必要性，或从层级视角解释其工作原理时，通常会使用概念架构图。

数据仓库架构图由多个组件构成，旨在展示数据仓库的整体架构。

数据来源和数据管理

数据来源是指进入系统的原始数据的来源。这些来源可以涵盖操作型数据库、API、云应用程序、SaaS 应用及其他来源。数据来源包含传入的业务数据；这些数据在进入分析、AI 和商业智能（BI）工具之前，需要经过转换处理。

ETL 层

ETL（提取、转换、加载）层负责数据集成：从源头提取数据，通过转换对数据进行丰富、清洗和标准化，最后将其加载到存储系统中。梳理这一过程及信息在 ETL 管道中的实际流向有助于确保整个流程中的数据质量保持一致。

暂存区

暂存区是数据在数据管道传输过程中进行临时存储的区域。在加载到数据仓库之前，原始数据通常先在此处进行处理。这种数据隔离方式允许在不影响流程中其他数据流的情况下进行转换和验证。如果在此阶段出现错误，由于数据处于隔离状态，可以轻松进行回滚操作。

数据仓库核心

数据仓库核心是存储所有已集成、已清洗及历史数据的主体仓库。优化该组件有助于支持企业制定长期分析策略所需的各类当前及历史数据。

数据集市

数据集市是针对特定用途或团队的数据仓库子集。它们通过围绕特定用例组织仓库数据来改善数据访问体验，避免了在单一数据来源中检索数据可能带来的复杂与繁琐。企业也可能使用操作型数据存储来实现类似的数据集成和存储目标。

表示层

表示层是业务用户与数据交互的接口，通常包含仪表板、报表、数据挖掘工具及其他下游系统。该层可抽象底层工具的复杂性，以提供易于使用且直观的自助式应用程序。

元数据存储库

元数据存储库用于存储所有数据文档架构、数据模型、数据血统和转换规则。元数据对于数据治理至关重要，因此，详细规划和定义该组件对于确保符合监管要求具有重要意义。

在为现代数据仓库绘制架构图时，企业可以选择多种不同的模式来最佳地呈现设计方案。

Kimball 架构

Kimball 数据模型采用自下而上的系统构建方式，优先考虑具体的用例或业务流程。该模型根据特定业务用户的需求，首先规划数据集市。随后，模型从这一底层向上构建一个连贯的分析系统，负责向这些数据集市提供数据。该系统的构建与集成非常简单，利用“一致性维度”在多个数据集市间实现数据交付。

Inmon 架构

Inmon 系统采用自上而下的方法，规划中央数据仓库的设计。这是一种面向主题的模型，即围绕客户、订单、产品等核心业务实体来组织数据。它将来自业务运营系统的数据以规范化结构集成到模型中，然后再将数据分发到下游的数据集市以生成报表。该模型提供了统一的数据质量标准，但需要进行更详尽的逻辑设计。

数据保管库架构

数据保管库架构将数据分为三个组件：中心、链接和卫星。中心代表核心业务概念，链接表示这些概念之间的关系，卫星则包含有关中心的详细信息或属性。这种区分方式允许您将进入系统的原始数据以极少的转换步骤加载到数据保管库中。在此结构下，业务规则和报表结构应用于下游环节；这意味着即使下游的数据分析方式发生变化，核心模型依然保持稳定。

用于数据处理的 Lambda 架构与 Kappa 架构

Lambda 架构是结合两条并行处理路径的数据处理模式。其中第一条路径是批处理层，负责处理海量的历史数据。第二条路径是速度层，负责处理实时数据。绘制这些架构有助于描绘数据系统如何在同时需要实时见解和历史见解的情况下运作。

相比之下，Kappa 架构则完全专注于流式传输数据管道。与将批处理层和实时层划分为不同处理流的 Lambda 架构不同，Kappa 架构中的各类数据均作为连续流进行处理。对于批处理需求，它通过重放历史信息将其视为数据流来处理。Kappa 架构更为简单，且最适用于事件驱动型系统。

在创建数据仓库图时，应考虑以下细节。

受众和目的

根据图表的受众，选择合适的详细程度至关重要。例如，技术人员或负责实施数据仓库的工程师需要物理模型和逻辑模型。而对于非技术业务利益相关者，只需查看概念模型以获取宏观概览即可。

详细程度

物理架构图和逻辑架构图所需的详细程度截然不同。在创建模型时，应根据目标受众确定所需的详细程度，从而在过程中节省时间。在产品移交等场景下，则需要投入时间，尽可能详尽地描述系统细节。在数据仓库构建流程的早期阶段进行这项工作，有助于确保对系统的描述尽可能准确。

符号标注标准

尽可能使用统一的符号标注，以确保组织内的所有人都能理解您创建的模型。全公司范围内的统一性可确保所有数据模型都易于理解，并能在不同团队间进行复用。

可扩展性表示

数据仓库图表还应展示如何扩展各个组件。这同样适用于为优化处理或数据存储而进行的特定调整，例如在图表中引入数据湖或灵活的数据存储层。

安全性与合规性层

您可以在图表中概括展示用于保护数据仓库的各种访问控制系统或安全技术。了解贵公司如何管理数据访问有助于确保在部署系统之前，所有敏感数据都已得到妥善保护。

数据血统

记录跨业务的数据血统能展示数据如何从源头流向业务系统。它提供清晰的数据流向图，有助于追踪数据集在公司内部的传输过程。

转换逻辑和处理流程

尽管转换逻辑通常只包含在逻辑架构图中，但明确这些逻辑有助于团队在部署或优化阶段更好地集成您的系统。

性能注意事项

对于性能关键型组件或可能出现瓶颈的环节，您可以在图表中进行更详细的标注。随后，您可以针对潜在问题提前制定优化方案或缓解策略。

版本控制

在图表管理中采用版本控制，可确保您始终拥有图表备份及过往草稿，以便在系统变更后进行回溯或参考。版本控制有助于展示数据仓库架构随时间推移的演变过程。一旦发生重大错误，您可以对比不同版本间的更改情况，从而辅助故障排查。

AWS 提供一系列解决方案来帮助您构建、可视化和管理数据仓库：

• Amazon Redshift 是一款统一、开放且安全的数据仓库，支持大规模现代数据分析。Redshift 与下一代 Amazon SageMaker 无缝集成，帮助您利用其强大的 SQL 分析功能来分析 Amazon SageMaker 中各个湖仓的统一数据。
• AWS Glue 能够发现、准备并整合各种规模的数据。Glue 让您可以连接到 100 多个不同的来源，在集中式数据目录中管理您的数据，并以可视化方式创建、运行和监控数据管道，进而将数据加载到数据湖、数据仓库和湖仓中。
• AWS Lake Formation 是一项服务，可用于集中管理、保护和共享用于分析和机器学习的数据。

立即创建免费账户，开始在 AWS 使用数据仓库功能。