1. 大数据存储框架
1.1 定义
- 数据库（Database）：数据库是按照数据结构来组织、存储和管理数据的仓库，是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。
- 数据仓库（Data Warehouse）：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。
- 数据集市（Data Mart）：数据集市是一个小型的、面向特定主题或部门的数据仓库，通常用于满足特定用户群体的分析需求。
- 数据网格（DataMesh）：数据网格数据网格的本质是一种去中心化的社会技术方法，旨在帮助组织更好地管理和利用分散在不同系统和应用程序中的数据资产。它强调将数据资产转化为可重用、可组合、可交互的数据元素，以支持组织内部和跨组织的业务创新和数字化转型。
- 数据湖（Data Lake）：数据湖是一个存储各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本以及用于报告、可视化、分析和机器学习等任务的转换数据。
- 数据湖仓（Data Lakehouse）：数据湖仓是一个结合了数据湖和数据仓库优点的存储架构，旨在提供一个既能存储原始数据又能进行高效分析的环境。
1.2 数据存储框架的应用场景
| 应用场景 | 示例 | |
|---|---|---|
| 数据库 | 广泛应用于各种需要存储、检索和管理数据的系统中，如：客户关系管理（CRM）、企业资源规划（ERP）、电子商务网站等 | 客户关系管理（CRM）：行使用数据库来存储客户的账户信息、交易记录等；电商网站使用数据库来存储商品信息、用户购物车内容、订单数据等 |
| 数据仓库 | 主要用于支持企业的决策分析，如：市场分析、客户分析、业务过程优化 | 电信公司使用数据仓库来存储和分析客户的通话记录、数据使用情况等，以便制定更精准的营销策略或优化网络布局 |
| 数据集市 | 适用于需要快速响应特定查询或分析需求的部门或项目团队 | 一个销售部门可能会建立自己的数据集市，其中包含与销售业绩、客户信息和市场活动相关的数据，以便销售团队能够快速地进行销售分析和预测 |
| 数据网格 | 适用于企业中数据分布广泛且数据需求多样化，需要打破数据孤岛，实现数据共享和协同工作的场景。如：跨部门的数据协作、企业与外部合作伙伴的数据共享等。 | 一家大型制造企业，其研发部门、生产部门、销售部门和售后服务部门各自拥有大量数据。通过数据网格，研发部门可以获取销售部门关于市场需求和客户反馈的数据，以优化产品设计；生产部门可以结合研发部门的新技术信息和销售部门的预测数据，合理安排生产计划；销售部门可以了解到研发部门的产品更新进展和生产部门的库存情况，从而制定更精准的销售策略。 |
| 数据湖 | 适用于需要存储和处理大量多样化数据的环境，尤其是当数据的结构和用途在存储时不明确的情况下 | 一个大型互联网公司可能会使用数据湖来存储用户行为日志、社交媒体帖子、图片和视频等，便于后续数据挖掘等。 |
| 数据湖仓 | 适用于那些既需要灵活的数据存储和处理能力，又需要高性能分析查询的企业 | 一个大型金融机构可能会采用数据湖仓架构来存储和处理大量的交易数据、客户信息和市场数据，同时支持实时风险分析、投资组合优化等高性能分析查询 |
2. 数据仓库基础知识
数据存储结构：非结构化、半结构化、结构化数据
| 定义 | 示例 | 常见场景 | 特点 | |
|---|---|---|---|---|
| 结构化数据 | 结构化数据是指可以使用关系型数据库表示和存储的数据，通常以二维表的形式呈现。 | 数字、符号等 | 二维表,包含属性和元组。例如，成绩单是属性，而90分作为对应的元组。 | - 数据以行为单位，每行数据表示一个实体的信息，且每行的属性是相同的。 - 存储和排列有一定的规律，便于查询和修改等操作。 |
| 半结构化数据 | 半结构化数据既有数据又有结构，但结构不是严格固定的，不完全符合关系型数据的规范。 | XML、JSON等 | Web数据、日志文件、配置文件等场景 | 数据的结构可能在不同的记录中有所变化，但仍具有一定的可解析性和组织性。 |
| 非结构化数据 | 非结构化数据是指没有固定结构和格式的数据，通常无法以关系型数据库的形式进行存储和表示。 | 文本、图像、音频、视频等 | 社交媒体内容、电子邮件、文档、多媒体文件等 | - 非结构化数据不适合使用传统的关系型数据库进行存储和管理。 - 非结构化数据的分析和处理需要采用特定的技术和工具，如自然语言处理、图像处理、音频处理等。 |
2.1 数据仓库基本概念
概念：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
- 主题性：数据仓库是面向主题组织数据的，而不是面向事务处理。它围绕企业的关键业务主题进行数据组织，例如客户、销售、产品、财务等。
- 操作型数据库的数据是面向事务处理任务，而数据仓库的数据是按照一定的主题域进行组织。
- 主题的划分需要根据企业的业务需求和战略目标来确定。例如，一个零售企业可能会将数据划分为“客户主题”（包括客户基本信息、购买行为等）、“销售主题”（包括销售订单、销售额等）、“产品主题”（包括产品信息、库存情况等）。
- 集成性：数据仓库中的数据是从多个数据源抽取、转换、清洗后集成在一起的，这些数据源可能包括企业内部的事务处理系统、外部数据源等。
- 稳定性：数据仓库中的数据是相对稳定的，一旦加载到数据仓库中，数据通常不会被频繁修改。
- 因为数据仓库主要目的是为决策分析提供数据，所涉及的操作主要是数据査询，一旦某个数据存入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，修改和删除操作很少，通常只需要定期的加载、刷新来更新数据，而不是实时更新。
- 时变性（反映历史变化）：数据仓库中的数据是随时间变化的，数据仓库能够记录数据在不同时间点的状态，便于进行历史数据分析和趋势预测。
定位：承接各种数据源，通过采集、建（数据资产/模型建设）、管（数据管理/数据服务）、用（如何利用数据为下游创建价值）的方式实现下游需求内容为数据分析、运营、风控等业务提供数据支撑。
2.2 数据仓库分层
- 为什么要进行数仓分层？
- 清晰数据结构：数仓每一层都有对应的作用，方便在使用时更好定位与了解
- 数据血缘追踪：清晰知道表/任务上下游，方便排查问题，知道下游哪个模块在使用，提升开发效率及后期管理维护
- 减少重复开发：完善数仓好中间层，减少后期不必要的开发，从而减少资源消耗，保障口径、数据统一
- 把复杂问题简单化：将复杂任务拆解成多个步骤来完成，每一层处理单一步骤，当数据问题出现时候，只需从问题起点开始修复
- 数仓分层
- ODS（接入层）全称Operational Data Store，ODS层是最接近数据源的一层，从数据源（api、数据库等）将数据同步数仓中，中间不做任何处理操作
- DWD（明细层）全称Data Warehouse Detail，是数仓明细数据层，对ODS层的数据进行关联，清洗，维度退化（将维度表中维度数据放入明细表中），转换，主题域建设等操作
- DWM（轻度汇总层）全称Data WareHouse Middle，轻度汇总层数据仓库中DWD层和DWS层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂指标前置处理），提升公共指标的复用性，减少重复加工
- DWS（汇总层）全称Data WareHouse Servce，按照主题域、颗粒度（例如买家、卖家）划分，按照周期粒度、维度聚合形成指标较多的宽表，用于提供后续的业务查询，数据应用，最重要一点需要在DWS层完成指标口径统一及沉淀
- ADS（应用层）全称Applacation data service，按照应用域，颗粒度划分（例如买家、卖家）划分，按照应用主题将对应数据标签补充至应用层，最终形成用户画像及专项应用
2.3 数据仓库建模方法论
详解数据建模方法、模型、规范、流程、架构、分层和工具-CSDN博客
2.3.1 数据模型的概念和分类
概念：数据特征的抽象，通常包括数据结构、数据操作、数据约束。
分类：概念模型（ER图）、逻辑模型、物理模型（面向计算机）
| 概念数据模型 | 逻辑数据模型 | 物理数据模型 | |
|---|---|---|---|
| 目的 | 描述业务实体及其之间的关系，不涉及具体的数据库技术或实现细节。 | 在概念模型的基础上进一步细化，包括更多的细节如主键、外键、索引等，但仍然独立于任何特定的数据库管理系统(DBMS)。 | 基于逻辑模型，具体化到选定的DBMS上，考虑性能优化、存储结构等因素。 |
| 主要关注点 | 业务规则、实体、属性及它们之间的关系 | 确保数据完整性和一致性，同时考虑数据如何被组织和访问 | 表结构、字段类型、索引、分区策略等技术细节 |
| 工具 | ER图（实体-关系图）是最常用的工具之一 | 增强版的ER图或其他逻辑模型表示法 | 数据库设计工具，直接生成用于创建数据库的SQL脚本 |
2.3.2 数仓建模方法论
数据仓库建模方法论可分为：维度建模、范式建模、Data Vault模型、Anchor模型。其中，维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
- 维度建模：维度建模Ralph Kimball提出，从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。
- 星型模型，主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
- 雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于Hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
- 星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。
- 范式建模：实体关系（ER）模型，采用 ER 模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。
- 3NF（三范式）：
- 第一范式：每个属性都不可再分（确保每列保持原子性）；
- 第二范式：非主字段都完全依赖于主键（确保表中的每列都和主键相关）；
- 第三范式：非主键字段不能依赖于其他非主键字段（确保每列都和主键列直接相关,而不是间接相关）
- 3NF（三范式）：
- Data Vault模型：Data Vault 是 Dan Linstedt 发起创建的一种模型，它是 ER 模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。
- Anchor模型：Anchor 对 Data Vault 模型做了进一步规范化处理， Lars Ronnback 的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF ，基本变成了 K-V 结构化模型。
| 维度建模 | 范式建模 | Data Vault模型 | Anchor模型 | |
|---|---|---|---|---|
| 目的 | 旨在优化查询性能，支持快速的数据分析 | 通过消除数据冗余来确保数据的一致性和完整性 | 提供一种灵活的方法来处理历史数据和变化的数据，同时保持数据的完整性和一致性 | 进一步减少数据冗余并提高灵活性，适用于需要高度可扩展性的环境 |
| 结构 | 基于星型模式或雪花模式构建，包括事实表（存储度量值）和维度表（描述上下文信息） | 遵循数据库规范化原则，特别是第三范式，即所有非主键属性都必须直接依赖于主键，并且避免传递依赖 | 由中心表（Hub）、链接表（Link）和卫星表（Satellite）组成。Hubs表示业务实体，Links表示实体间的关系，Satellites存储与实体相关的详细信息和变化历史 | 类似于Data Vault，但更加细化。它将不变的部分（如标识符）分离出来作为“锚点”，而变动的部分则存储在独立的表中。 |
| 优点 | - 高效的查询性能，特别适合OLAP（联机分析处理）操作。 - 易于理解和使用，对于业务用户友好。 | - 数据冗余低，维护成本相对较低。 - 支持事务处理系统中的高效插入、更新和删除操作。 | - 支持数据的历史追踪，允许对数据变更进行审计。 - 灵活性高，易于扩展 | - 极低的数据冗余，非常高的灵活性。 - 支持细粒度的数据变更管理。 |
| 缺点 | - 数据冗余较高，可能导致更新异常。 - 不适合频繁的数据变更。 | - 对于复杂的查询和数据分析，可能需要进行多次表连接，影响性能。 | - 结构较为复杂，学习曲线陡峭。 - 查询性能可能不如维度模型。 | - 设计和实现更为复杂。 - 可能导致大量的小表，增加了管理和维护的难度。 |
2.3.3 比对
| 三范式建模 | 维度建模 | |
|---|---|---|
| 角度不同 | 三范式严格遵循每一范式内容，按照范式内容建模 | kimball建模（维度维度），按照多个维度进行分析，更多按照星形模型 |
| 出发点不同 | 3NF建模（三范式建模），考虑自上而下建模（这里的上指的是上游数据源，先拥有dw层再往上进行设计，瀑布模型，不易于后期扩展） | kimball建模（维度维度），考虑自下而上建模（这里的下指的是数据集市），先拥有数据集市来设计dw层，敏捷模型，易于扩展易于后期维护及使用） |
| 模型精度 | 三范式模型由于没有分层概念冗余低数据精度高 | kimball建模（维度维度），由于多层建设导致冗余高数据精度低 |
| 星型模型 | 雪花模型 | |
|---|---|---|
| 概念 | 因为数据的冗余所以很多查询不需要做外部连接，因此一般情况下效率比雪花模型高，设计与实现比较简单 | 由于去除了冗余，有些统计就需要通过表的连接才能产生，所以效率不一定有星型模型高。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率 |
| 特点 | 1. 只需要确定主键 2. 不需要在外部进行连接，大大提高性能实现高度并行化 3. 容易理解，只需要看关联条件和血缘关系就能确定模型 | 1. 需要主外键来确立管理 2. 雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低，不能并行化 3. 过多的连接使得开发和后期维护都增大难度 |
3. 数据仓库VS其他存储框架
3.1 数据仓库VS数据库
| 区别 | 数据库OLTP | 数据仓库OLAP |
|---|---|---|
| 处理方式 | 在线事务处理方式 | 在线分析处理方式 |
| 应用场景 | 日常事务处理 | 面向分析决策 |
| 数据结构 | 关系模型（ER模型）以业务流程为参考，面向应用的设计 | 维度模型（雪花模型、星型模型）以业务主题为参考，面向主题的设计 |
| 数据量级 | 相对较小，只存储当前数据 | 相对较大，存储历史数据+当前数据 |
| 数据特点 | 最新、细节、二维、分立 | 历史、聚集、多维、集成 |
| 实时性要求 | 实时性要求高 | 实时性要求相对较小 |
| 操作类型 | 支持频繁的增删改查操作 | 查询为主，可添加、无删除、无变更操作 |
| 设计理论 | 遵循三范式、避免冗余 | 违范式、适当冗余 |
| 处理量 | 频繁、小批次、高并发、低延迟 | 非频繁、大批量、高吞吐、有延迟 |
| 度量 | 事务吞吐量 | 查询吞吐量、响应时间 |
3.2 数据仓库VS数据集市
数据仓库（Data Warehouse）是一个用于整个企业的存储库，包含来自不同业务、系统和部门的集成数据。它基于整个企业的数据模型建立，面向企业范围内的主题。
数据集市（Data Mart）是一个面向特定业务领域或功能单元的主题化数据存储库。它通常是部门级的，为某个局部范围内的管理人员提供决策支持。
| 区别 | 数据仓库 | 数据集市 |
|---|---|---|
| 适用范围 | 整个企业 | 特定部门或功能单元 |
| 数据来源 | 来自不同业务、系统和部门的集成数据 | 可从数据仓库获取，或来自各生产系统 |
| 数据规模 | 较大（企业级） | 相对较小（部门级） |
| 主题 | 面向企业主题，与整个企业运营相关， 如：如销售、客户、供应链等。 | 面向部门主题，与特定业务或功能单元相关的， 如销售业绩、市场营销、财务等。 |
| 目标 | 未整个企业各部门提供决策支持 | 为特定部门提供决策支持 |
| 功能 | 提供企业范围内的数据分析和报告 | 提供部门级的数据分析和报告 |
3.3 数据仓库VS数据网格
数据网格到底是什么，它真的能替代数据仓库和数据湖吗？-CSDN博客
数据网格（DataMesh）是一个新兴的概念，旨在帮助组织更好地管理和利用分散在不同系统和应用程序中的数据资产。它强调将数据资产转化为可重用、可组合、可交互的数据元素，以支持组织内部和跨组织的业务创新和数字化转型。
特点：
- 分布式架构：数据不是集中存储在一个地方，而是分布在企业的各个领域或部门中。
- 领域所有权：每个业务领域对其生成的数据负有直接责任，包括数据的质量、治理和安全。
- 自助服务：通过标准化的接口和协议，使数据消费者能够方便地发现和使用数据产品，无需深入了解底层数据结构。
- 联合治理：尽管数据是分散的，但整个企业需要遵循一套共同的数据标准和协议，以确保数据的一致性和互操作性。
| 数据仓库 | 数据网格 | |
|---|---|---|
| 架构 | 集中式架构，数据集成到一个中心存储中 | 分布式架构，数据存储在不同的领域团队中，通过标准化的规则和语法进行连接和交互 |
| 数据所有权 | 由企业专门团队负责管理和维护 | 数据的所有权归于创建它的业务领域，每个团队可以自主管理和拥有自己的数据。 |
| 数据冗余性和业务对齐 | 数据仓库通常会合并和整合数据，以消除冗余并满足业务需求 | 数据网格允许数据在不同的领域团队之间存在冗余，以满足各自的业务需求 |
| 目标 | 数据仓库旨在提供一个一致、可信赖的数据源，用于企业的决策支持和分析 | 数据网格旨在通过领域团队拥有的数据产品，实现更快速的洞察和分析，并推动数据驱动的决策制定 |
3.4 数据仓库VS数据湖
数据湖是一个存储大规模、多样化数据的组织方法，可以存储结构化、非结构化和半结构化的数据，是一个大型、灵活的数据存储仓库，可以将企业的所有数据源整合起来。
| 数据仓库 | 数据湖 | |
|---|---|---|
| 数据存储 | 结构化数据 | 结构化、半结构化、非结构化数据 |
| 数据处理 | 经过清洗和处理的数据 | 原始数据，不需要预处理，后续根据需要进行处理 |
| 数据目的 | 支持商业智能和分析 | 支持探索性分析与机器学习 |
| 使用对象 | 商业分析师和业务用户，用于快速生成报告和决策制定 | 数据科学家和工程师，用于复杂模型训练和算法开发 |
| 数据访问 | SQL查询 | 多种工具和技术，如Hadoop、Spark等 |
| 数据处理速度 | 高性能，适合历史数据分析 | 高灵活度，适合实时和流式数据分析 |
| 数据架构 | 星型模型或雪花模型 | 没有特定的数据架构 |
| 成本与可扩展性 | 高成本，需要预定义模式和规划，在处理大数据集时更高成本和复杂性，可扩展性低 | 低成本，可以存储各种类型数据，且易于扩展 |
3.5 数据仓库VS数据湖仓
湖仓一体是一个全新的开放式数据架构，将数据仓库的数据结构和管理功能与数据湖的低成本存储和灵活性相结合，不仅保留了数据湖的特点，如存储非结构化数据和半结构化数据，还可以支持事务、数据治理和数据模型化等功能数据仓库所具备的特点。
| 数据仓库 | 湖仓一体 | |
|---|---|---|
| 数据存储方式 | 结构化数据 | 结构化、半结构化、非结构化数据 |
| 数据处理方式 | 批量处理 | 批量处理和实时处理 |
| 数据集成 | 集成的 | 非集成的 |
| 数据模型 | 事实和维度模型 | 没有明确的数据模型 |
| 更新频率 | 周期性更新 | 实时更新 |
| 数据安全性 | 严格的访问控制 | 灵活的访问控制 |
| 数据处理技术 | ETL工具和SQL | 大数据处理工具与技术 |
| 使用用户 | 决策者和分析师 | 决策者、分析师和数据科学家 |
| 数据仓库 | 数据湖 | 湖仓一体 | |
|---|---|---|---|
| 数据存储 | 结构化数据 | 结构化、半结构化、非结构化数据 | 结构化、半结构化、非结构化数据 |
| 目的 | 数据分析和商业智能（BI） | 机器学习（ML）和人工智能（AI）负载 | 数据分析和机器学习 |
| 费用 | 存储昂贵又耗时 | 存储具有成本效益、灵活性和快速性 | 存储具有成本效益、灵活性和快速性 |
| ACID合规性 | 符合ACID，确保最高水平的完整性 | 非ACID合规性，更新和删除较复杂 | 符合ACID，确保多方同时读取或写入数据的一致性 |
六种存储结构比对汇总
| 数据库 | 数据仓库 | 数据集市 | 数据网格 | 数据湖 | 湖仓一体 | |
|---|---|---|---|---|---|---|
| 定义 | 用于存储相关数据 | 存储历史数据、支持数据分析 | 针对特定业务部门的数据子集 | 数据的自治和共享 | 存储原始数据的大型存储库 | 集成数据仓库和数据湖 |
| 用途 | OLTP | OLAP | 特定业务部门的数据分析和决策支持 | 跨组织和团队的数据分享和协作 | 灵活的数据分析和探索 | 原始数据探索和历史数据分析 |
| 数据类型 | 结构化、非结构化、关系型、非关系型 | 结构化 | 结构化 | 结构化、半结构化、非结构化数据 | 结构化、半结构化、非结构化数据 | 结构化、半结构化、非结构化数据 |
| 数据处理 | 实时事务数据处理 | 提取-转换-加载（ETL） | 针对特定需求的数据提取和整合 | 数据所有者自洽，分布式数据共享 | 原始数据存储，按需处理和分析 | 原始数据探索和历史数据分析 |
| 查询 | SQL查询 | SQL查询 | SQL查询 | 分布式数据查询和共享 | 按需处理和分析 | 原始数据探索和历史数据分 |
| 数据组织 | 表、索引、键、视图、数据类型 | 表、索引、键、视图、数据类型 | 表、索引、键、视图、数据类型 | 分布式数据组织和架构 | 灵活的数据组织 | 灵活的数据组织 |
| 数据共享 | 有限的共享能力 | 针对特定用户和部门的共享 | 针对特定业务部门的共享 | 强调数据自治和共享 | 强调跨组织和跨团队共享 | 结合数据仓库和数据湖的共享能力 |
| 数据分析 | 实时事务数据分析 | 历史数据分析和商业智能 | 特定业务部门的数据分析和决策支持 | 跨组织和跨团队的数据分析和协作 | 灵活的数据分析和探索 | 原始数据探索和历史数据分析 |
参考链接
https://blog.csdn.net/giszz/article/details/135634301
https://blog.csdn.net/ttyy1112/article/details/145682207
https://blog.csdn.net/lzhlizihang/article/details/144091421
https://devpress.csdn.net/cloud-native/64be23e9bc2c435cdd54a97a.html
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
