读数据架构知识体系指南09设计方法

1. 设计方法

1.1. 数据设计和数据建模是一对容易混淆的概念

1.2. 数据设计看作在建造一座城市

• 1.2.1. 涉及决定建筑物的位置、连接城市不同部分的道路以及交通流量的规划

1.3. 数据建模更像是在设计单个建筑物

• 1.3.1. 涉及决定房间的布局、房间如何连接以及每个房间的用途

2. 联机事务处理与联机分析处理

2.1. OLTP

• 2.1.1. 联机事务处理

• 2.1.2. 是一种信息系统或应用程序，用于在实时环境中处理在线的创建、读取、更新和删除(CRUD)事务

• 2.1.3. 旨在支持高并发性，这意味着可以同时处理大量事务

• 2.1.4. 通常使用关系模型​，并进行了低延迟优化，这意味着可以非常快地处理事务

• 2.1.5. 例子包括销售点应用程序、电子商务网站和在线银行解决方案

• 2.1.6. 使用各种数据库管理系统(DBMS)来存储和管理数据，例如Microsoft SQL Server和Oracle

• 2.1.7. 可以将联机事务处理视为实现运营数据的技术

2.2. OLAP

• 2.2.1. 联机分析处理

• 2.2.2. 用于数据分析和报告，以支持商业智能和制定决策

• 2.2.3. 优化了快速查询性能，允许终端用户通过报告和仪表盘对数据进行多维切片和数据挖掘，速度比使用OLTP系统快得多

• 2.2.4. “一次写入，多次读取”​

• 2.2.5. 多个OLTP数据库被用作数据源，这些数据源被导入数据仓库中，然后再导入OLAP数据

• 2.2.6. 一个OLAP数据库通常由一个或多个OLAP立方体（OLAP cube）组成

• 2.2.7. OLAP数据库和数据仓库是相关但不相同的概念，通常一起使

• 2.2.7.1. 提供了一种分析数据仓库(DW)中存储的数据的方式，这种方式比在包含大量数据的数据仓库上执行传统SQL查询更灵活且交互性更强

• 2.2.8. 将联机分析处理/表格和数据仓库视为实现分析数据的技术

2.3. OLAP立方体

• 2.3.1. OLAP立方体是数据预先整合的地方，即数据已经在某些维度进行了汇总和分组，终端用户可以从多个维度和细节层次快速访问它，而无须等待长时间运行的查询完成

• 2.3.2. 创建OLAP立方体通常涉及使用多维模型，该模型使用星型模式或雪花型模式来表示数据

• 2.3.3. 多维模型和表格数据模型通常被视为语义层或模型，这意味着它们在数据仓库的架构上提供了一个抽象层

3. 运营数据和分析数据

3.1. 两种类型的数据对于有效的业务管理都是必不可少的，它们相互补充，为组织的运营和绩效提供了完整视图

3.2. 运营数据

• 3.2.1. 用于管理日常运营和流程的*实时数据

• 3.2.2. 由联机事务处理系统捕获、存储和处理。可以使用它来获取业务当前状态的“快照”​，以确保运营平稳、高效地运行。运营数据量通常很大，有助于快速决策

• 3.2.3. 用于实时监控和控制业务流程

3.3. 分析数据

• 3.3.1. 来源于对操作数据的收集和转换

• 3.3.2. 由联机分析处理/表格系统和数据仓库维护和使用的数据的*历史视图

• 3.3.3. 分析数据通常提供比运营数据时间范围更长的数据视图，通常数据量较小，并且通常是经过整合和汇总的

• 3.3.4. 数据通常以批处理的方式被摄取，并且需要比运营数据更多的处理时间

• 3.3.5. 用于获取见解并为较长时期内的决策提供信息

4. 对称多处理和大规模并行处理

4.1. 早期的关系数据库使用了对称多处理(SMP)设计，即计算机处理由共享磁盘和内存的多个处理器完成，所有处理器都位于同一台服务器中

4.2. 随着20世纪90年代数据仓库的兴起并且数据库开始摄入大量数据，性能问题变得日益突出

4.3. 在MPP设计中，数据库有多台服务器组成，每台服务器都有多个处理器，并且每个处理器都有自己的内存和磁盘

• 4.3.1. 允许通过添加更多服务器来“横向扩展”(scale out)，而不是“纵向扩展”

4.4. 大规模并行处理服务器将数据库中的部分数据分配到每个服务器的磁盘上，而对称多处理数据库则将所有数据保存在一个磁盘上

4.5. 大规模并行处理中，查询被发送到一个控制节点（也称为名称节点）​，该节点将每个查询拆分成多个子查询，并将这些子查询发送到各台服务器（称为计算节点或工作节点）​

4.6. SMP和MPP数据库最初是作为本地解决方案出现的，这些解决方案至今仍然很普遍，但现在在云中也有许多等效的解决方案

5. Lambda架构

5.1. Lambda架构是一种数据处理架构，旨在通过同时使用批处理和实时流处理方法来处理海量数据，其核心思想是通过批处理获取全面且准确的历史数据视图，并在延迟、吞吐量、扩展性和容错性之间取得平衡，同时利用实时流处理提供在线数据的实时视图

5.2. 通过将传统的批处理系统与流式消费工具相结合，弥合了“单一事实来源”和现在备受追捧的“我要立即获得”实时解决方案之间的沟壑，从而满足两种需求

5.3. 如果需要构建一个能够同时处理批处理和实时数据并提供单一统一视图的分布式系统，Lambda架构是一个值得考虑的选择

• 5.3.1. 如推荐引擎和欺诈检测系统

• 5.3.2. 如果需要支持有状态处理或处理大量实时数据，建议考虑其他架构

5.4. 关键原则

• 5.4.1. 双数据模型

• 5.4.1.1. 一个模型用于批处理（批处理层）​，另一个模型用于实时处理（流处理层）​

• 5.4.1.2. 使得系统能够同时处理批数据和实时数据，并以可扩展和容错的方式执行这两种类型的数据处理

• 5.4.2. 统一视图

• 5.4.2.1. 使用单一的统一视图（称为展示层/表示层）向最终用户呈现批处理和实时处理的结果

• 5.4.3. 解耦处理层

• 5.4.3.1. 将批处理和实时处理层解耦，因此它们可以独立扩展，并且可以单独开发和维护，从而提供了灵活性并简化了开发过程

5.5. 缺点

• 5.5.1. 复杂性

• 5.5.1.1. 包含双数据模型和单一的统一视图

• 5.5.1.2. 相比其他架构，Lambda架构的实现和维护可能更加复杂

• 5.5.2. 实时处理能力有限

• 5.5.2.1. 设计目的在于同时进行批处理和实时处理，但在处理大量实时数据时，效率可能比不上专门为实时处理而设计的Kappa架构

• 5.5.3. 对有状态处理的支持有限

• 5.5.3.1. 设计的目的是用于无状态处理，可能不太适合需要在多个事件之间维护状态的应用

6. Kappa架构

6.1. Kappa架构专门设计用于处理实时数据

6.2. Kappa架构是构建分布式系统的绝佳选择，特别是那些需要实时处理大量数据、具备可扩展性、容错性和低延迟的系统

6.3. 关键原则

• 6.3.1. 实时处理

• 6.3.1.1. 被设计用于实时处理，这意味着事件会在收到时立即被处理，而不是稍后进行批处理

• 6.3.1.2. 减少了延迟，并使系统能够快速响应不断变化的条件

• 6.3.2. 单一事件流

• 6.3.2.1. 使用单一事件流来存储流经系统的所有数据

• 6.3.2.2. 数据可以轻松分布在多个节点上，因此这种设计使得系统易于扩展且具有容错性

• 6.3.3. 无状态处理

• 6.3.3.1. 所有处理都是无状态的

• 6.3.3.2. 意味着每个事件都是独立处理的，不依赖于之前事件的状态

• 6.3.3.3. 使得系统更容易扩展，因为无须在多个节点之间维护状态

6.4. 缺点

• 6.4.1. 复杂性

• 6.4.1.1. 涉及单一事件流和无状态处理，这可能比其他架构更复杂，实现和维护起来也更困难

• 6.4.2. 有限的批处理

• 6.4.2.1. 旨在实时处理数据，不太适合对历史数据进行批量处理

• 6.4.3. 对即席查询的支持有限

• 6.4.3.1. 旨在实时处理数据，因此可能不太适合需要处理大量历史数据的即席查询

7. 混合持久化和多种数据存储

7.1. 混合持久化是指在单个应用程序或系统中根据数据的使用方式，使用多种数据存储技术来存储不同类型的数据

7.2. 不同类型的数据最好存储在不同的数据存储中

7.3. 混合持久化就是为特定的用例选择最合适的工具

7.4. 多语言编程指的是，在一个应用程序使用混合编程语言来利用不同编程语言在解决不同问题时的优势

7.5. 多种数据存储是指一个组织或企业内使用多种数据存储

• 7.5.1. 每种数据存储都针对特定类型的数据或用例进行了优化

• 7.5.2. 允许组织为不同的项目或业务部门使用不同的数据存储，而不是在整个组织中采用一刀切的数据存储

7.6. 设计方法可以为每种类型的数据使用最合适的工具

7.7. 设计方法增加了复杂性的代价，因为每种数据存储解决方案都意味着需要学习一项新技术，但其带来的好处将是值得的