近日Gartner公司发布了《Use Data Modeling for Better Architectures and Business Outcomes》主要探讨了数据建模在技术简化和自动化背景下的重要性、应用场景、方法论以及面临的挑战和解决方案。我们一起来学习一下这篇研究，理解数据建模如何成为企业优化架构和提升业务成果的关键工具。
核心观点
-
数据建模的重要性：数据建模是企业信息架构的基础，支持广泛的技术和业务倡议，如数据质量、数据血统和数据治理。它不仅对数据库架构有深远影响，还渗透到许多现代数据架构的其他方面。
-
数据建模的分类：数据模型可以根据应用堆栈的不同层次、数据管道的不同区域以及软件开发生命周期的不同阶段进行分类。这种分类有助于理解不同场景下的数据建模需求和方法。
-
技术简化与数据建模的关系：尽管技术简化和自动化（如生成式AI）可能减少某些数据建模任务的复杂性，但在数据治理和需求收集等场景中，手动数据建模的需求反而增加。
-
概念建模的重要性：随着物理建模的简化，概念建模变得更加重要，因为它帮助理解业务数据，且概念模型的细节有助于用户审查和反馈。
-
数据建模的加速技术：报告讨论了数据建模的加速技术，如数据仓库自动化、数据库架构的逆向工程和自动元数据发现与分析，指出这些技术的优劣。
问题背景
-
数据建模的挑战：数据建模面临着技术更新快、工具覆盖不全、模型通用性与特定需求之间的矛盾等问题。例如，没有工具支持纯粹的概念数据建模并自动生成各种逻辑模型。
-
数据建模的误区：一些常见的错误观念，如认为概念模型只需包含实体和关系而无需属性，或通过泛化来加速建模，实际上会损害模型的可用性和准确性。
-
数据管道的多样性：数据管道的不同区域（如事务系统、分析生态系统、报告特定模型）需要不同类型的数据模型，这增加了数据建模的复杂性。
-
架构模式的影响：不同的架构模式（如数据即产品架构、微服务架构、逻辑数据仓储）对数据建模有不同的要求和影响。
解决方案
-
适应现代工具的物理设计实践：数据建模应利用现代数据管理工具的高级功能，如高范式关系型数据库管理系统、NoSQL数据库、星型架构等。
-
分离解决方案设计与问题描述：在需求收集阶段，避免使用技术导向的符号和方法，以免将问题定义与解决方案设计混为一谈。
-
创建适当的详细概念模型：避免过度设计或细节不足，平衡模型的详细程度以满足不同消费者的需求。
-
咨询多个主题专家：为了实现企业范围的数据模型共识，需要从多个部门和用户基础中获取意见，避免“数据的地方性观点”。
-
利用数据建模加速技术：合理利用数据仓库自动化、数据库架构的逆向工程和自动元数据发现与分析等技术来加速数据建模过程。
详细解读
-
数据建模的基础作用：数据建模最初是为了满足数据库设计的需求，但现在已经扩展到包括数据库（关系型和非关系型）、数据集成解决方案、运行时模型（如软件服务之间传递的消息模型）、最终用户可见的数据集市和数据呈现层等多种技术工件的设计。此外，数据建模还用于表达和达成业务数据的共识，为数据治理、数据质量、数据隐私和安全、业务数据词汇表等非技术性工件奠定基础。
-
数据模型的分类框架：报告提出了一个分类框架，将数据模型分为三种方式：应用堆栈的不同层次、数据管道的不同区域、软件开发生命周期的不同阶段。这种分类有助于理解和组织各种数据模型的用途和设计方法。
-
应用堆栈中的数据模型：在应用堆栈的不同层次中，数据模型服务于不同的目的，因此具有不同的结构和设计范式。例如，持久层关注长期数据存储，处理层关注运行时数据结构，API层和消息层则关注数据的接口和传输格式。
-
数据管道中的数据模型：数据管道的不同区域（如事务系统、分析生态系统、报告特定模型）需要不同类型的数据模型。事务系统通常需要高范式的关系模型以最小化冗余和最大化吞吐量，而分析生态系统则可以利用实际数据来设计数据模型，考虑数据的优化、摄取机制和不同消费者的需求。
-
数据湖中的数据建模：数据湖包含结构化、半结构化和非结构化数据，且通常划分为不同的区域（如原始区、策展区、聚合区）。每个区域需要不同的数据建模方法。结构化数据适合使用实体关系图、UML类图等进行建模，半结构化数据适合使用XML和JSON等层次化符号，而非结构化数据则可以通过对其元数据进行建模来增加价值。
-
软件开发生命周期中的数据建模：数据建模理论区分了概念、逻辑和物理三个阶段的数据建模。概念数据建模关注组织重视的数据类别，逻辑数据建模开始考虑特定技术的构建块，而物理数据建模则详细描述解决方案，涉及特定技术的构建块和设计决策。
-
数据建模的加速技术：报告讨论了数据建模的加速技术，如数据仓库自动化、数据库架构的逆向工程和自动元数据发现与分析。这些技术有助于加速数据建模过程，但也有其局限性，如自动生成的模型可能不够详细或需要人工审核。
-
数据建模的优缺点：数据建模的优势包括区分问题定义、解决方案设计和实施，支持模型驱动的开发，以及为企业计划提供基础。然而，当前建模实践存在工具覆盖不全、模型通用性与特定需求之间的矛盾等问题。
-
数据建模的指导原则：报告提供了一系列指导原则，如创建适当详细的模型、避免泛化、包括属性、尽快交付有用的模型、咨询多个主题专家、管理数据的地方性观点、让用户控制等。
-
数据建模的未来方向：报告指出，尽管生成式AI（GenAI）在数据建模中的应用尚处于初级阶段，但它显示出一定的潜力。对于简单数据模型，GenAI可以生成可用的模型，但对于复杂模型，仍需更高级的方法和专业人员的仔细审查。
典型应用场景：
应用中的数据模型（Data Models Along the Application Stack）
-
持久层（The Persistence Layer） ：
-
目的 ：主要目的是长期存储数据，可能长达数十年。其额外目的取决于多种因素，如数据的基本结构（是表格且稳定的、表格且演化的、网络 / 图形的、多维的等）以及所处数据管道区域（支持事务系统还是分析用例）。
-
建模特点 ：对于事务系统，通常需要设计成高范式的关系模型，以最小化数据冗余，确保数据的快速、可靠记录；而对于分析用例，可能会根据具体需求进行适当的数据模型调整，如为了优化特定查询性能而进行的适度反范式设计。
-
-
处理层（The Processing Layer） ：
-
目的 ：关注于运行时数据结构的设计，以支持对数据的运行时操作，如软件工程师使用统一建模语言（UML）类图来建模运行时数据结构。
-
建模特点 ：虽然运行时数据结构的建模通常由软件工程师而非数据建模师完成，但其重要性不容忽视。UML 类图等符号用于表示运行时数据结构，需注意其复杂性以及与概念数据建模和数据库设计的差异。
-
-
API 层（The API Layer） ：
-
目的 ：在微服务等架构中，数据模型可能仅通过 API 呈现，将数据控制的负担从业务逻辑层转移到应用层。
-
建模特点 ：这种模式下，API 设计需考虑数据的一致性和完整性，可能需要 API 编程人员重新实现传统数据库管理系统提供的数据一致性功能，或在一定程度上容忍较低的一致性。
-
-
消息层（The Messaging Layer） ：
-
目的 ：侧重于对处理过程所消耗或产生的数据进行建模，主要区别在于消息层的数据模型以可序列化的文件格式（如 XML 模式或 JSON 格式）表达。
-
建模特点 ：消息层的建模与 API 层建模在数据架构中感觉不同，XML 模式与关系数据库模式有诸多相似之处，数据建模工具也支持从实体关系图拖放创建 XML 模式。
-
数据和分析管道中的数据模型（Data Models Along the Data and Analytics Pipeline）
-
事务系统（Transactional Systems） ：
-
目的 ：支持操作性和事务性系统，用于自动化业务交易，如员工入职、支付处理、会议安排等。
-
建模特点 ：需要最小化数据冗余、最大化吞吐量或响应时间，物理数据模型通常表现为高范式关系模型，有时也会根据特定高频操作需求进行反范式设计以优化性能。此外，由于事务系统通常专注于特定领域，有时会从供应商处购买，因此在购买前需通过详细的需求模型来表达数据要求。
-
-
分析生态系统（The Analytical Ecosystem） ：
-
目的 ：为数据分析提供支持，数据来自现有的上游系统，数据建模可利用实际数据进行设计。
-
建模特点 ：需考虑在数据存在之前的理解问题，此时要借助语言学和数据可视化技术收集需求，而非依赖于对现有数据的操作。还需关注分析工作负载的优化，如传统上选择适合分析处理引擎的模型范式（如星型模型）。同时，要支持数据的摄取，设计良好的摄取机制，必要时可采用数据仓库建模技术。
-
-
报告特定模型（Report-Specific Models） ：
-
目的 ：服务于从数据中提取业务洞察的人员或自动应用，这些洞察可能来自传统商业智能（BI）报告和仪表板、机器学习模型等数据科学工件，或满足监管机构等外部方要求的报告。
-
建模特点 ：需要将数据呈现为下游可消费的形式，考虑不同消费者对数据组织的偏好，以及不同技术水平的分析师的需求。例如，专业分析师和自助分析师对数据模型清晰度的需求不同，数据建模师应根据受众特点调整模型设计。
-
数据湖中的数据建模（A Note on Modeling in Data Lakes）
-
结构化、半结构化和非结构化数据（Structured, Semistructured and Unstructured Data） ：
-
目的 ：数据湖可容纳多种类型的数据，不同的数据类型需要不同的建模方法。
-
建模特点 ：结构化数据适合使用实体关系图、UML 类图等建模技术；半结构化数据适合使用 XML 和 JSON 等层次化符号进行建模；非结构化数据本身不易直接进行数据建模，但可通过对其元数据进行建模来增加价值。
-
-
数据湖的区域（Zones of a Data Lake） ：
-
目的 ：数据湖通常划分为不同的区域，如原始区、策展区、聚合区和事务区，每个区域的数据特性和用途不同，需要不同的数据建模方法。
-
建模特点 ：原始区的数据保持原始状态，建模较少；策展区对数据进行整合、清理和丰富，建模需考虑数据的质量和一致性；聚合区提供分析就绪的数据集，建模要满足分析消费者的需求；事务区支持事务性工作负载，需考虑数据分布策略和性能优化。
-
软件开发生命周期中的数据模型（Data Models During the Software Development Life Cycle (SDLC)）
-
概念数据建模（Conceptual Data Modeling） ：
-
目的 ：表达组织所重视的数据类别，为后续的逻辑和物理数据建模奠定基础。
-
建模特点 ：概念数据模型应包含实体、属性、关系和标识符等元素，以全面描述业务数据类别，且应避免包含技术细节，以便业务专家能够理解和做出决策。
-
-
-
逻辑数据建模（Logical Data Modeling） ：
-
目的 ：基于概念数据模型，结合特定技术的构建块，设计出能够实现业务需求的技术数据模型。
-
建模特点 ：逻辑数据模型会根据所选技术范式（如关系型、面向对象、图数据库等）的不同，表现出显著差异。例如，概念实体可能被表示为 SQL 表、XML 实体、UML 类等。
-
-
物理数据建模（Physical Data Modeling） ：
-
目的 ：详细描述解决方案，使用特定技术的构建块，并反映由性能和效率驱动的设计决策。
-
建模特点 ：物理数据模型会具体到所使用的数据库管理系统（DBMS）等技术细节，如关系数据库的物理数据模型会指定用于实现索引的数据结构，以加速查询性能。
-
这份报告为数据架构师、数据建模师和相关技术专业人士提供了全面而深入的数据建模指南，帮助他们在不断变化的技术环境中优化数据建模实践，以支持更好的架构决策和业务成果。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
