1. 现代数据仓库
1.1. 每天，各个组织都必须梳理海量数据，以获取深刻见解、做出决策并推动业务增长
1.2. 融合了关系数据仓库的结构化优势和数据湖的灵活性优势
1.3. 处于我们快速发展的数据生态系统的核心位置，使各组织能够利用所需信息来实现创新并参与竞争
1.4. 数据不仅仅是数字，更是通往成功的动力源泉
2. 现代数据仓库架构
2.1. 医疗保健、金融、零售和技术在内的许多行业的组织都认识到，需要一种更加灵活、可扩展的数据存储和分析方法
- 2.1.1. RDW已不足以应对大数据带来的挑战，而MDW则提供了RDW和数据湖的灵活集成
2.2. RDW遵循自顶向下原则
-
2.2.1. 在进行任何数据加载（写入模式）之前，需要进行大量的准备工作来建立一个仓库
-
2.2.2. 使分析人员能够深入研究描述性分析（揭示发生了什么）和诊断性分析（探究发生的原因），从而生成历史报告
2.3. 数据湖的定义是自底向上的理念
-
2.3.1. 开始利用数据（读时模式）所需的前期工作最少，因此可以快速部署机器学习模型，探索预测性分析（预测将要发生的事情）和指导性分析（提出解决方案，实现预期结果）
-
2.3.2. 在MDW架构中，数据湖不仅仅是保存大量信息和训练ML模型的存储库，它还是一个动态组件，负责数据转换和其他目的
2.4. MDW架构的一个基本特征是，至少有一部分数据必须复制到RDW
- 2.4.1. 如果没有这种复制，它将是一个数据湖-房屋架构
2.5. 微软推出了Azure Synapse Analytics，亚马逊推出了Redshift，谷歌推出了BigQuery和Snowflake
- 2.5.1. 关键企业的出现彻底改变了企业访问和利用数据的方式
2.6. 对于数据量不大的客户来说，MDW仍然很受欢迎，至少在数据湖能像RDW一样运行良好之前，MDW可能会一直如此
2.7. 仍有一些公司在构建云解决方案时根本不使用数据湖，主要是针对公司拥有少量数据并从没有数据湖的内部部署解决方案迁移而来的使用案例
-
2.7.1. 公司必须绝对确定数据仓库不会有太大的增长
-
2.7.2. 如果数据量很小，那么为RDW选择一个比大规模并行处理(MPP)解决方案更便宜的多处理(SMP)解决方案也许是可行的
2.8. 阶段
-
2.8.1. 第1步：数据收集
-
2.8.1.1. MDW可以处理几乎任何类型的数据，数据可以来自内部和云端的多种来源
-
2.8.1.2. 数据的大小、速度和类型可能各不相同
-
2.8.1.3. 非结构化、半结构化或关系数据
-
2.8.1.4. 可能是批量数据，也可能是实时流数据
-
2.8.1.5. 可能是小文件，也可能是大文件
-
2.8.1.6. 对于数据收集阶段，需要预先确定提取数据的频率，以及使用增量还是完全提取
-
2.8.1.6.1. 如果需传输大文件，而带宽较小，可能需要每天多次分小块上传数据，而不是每天一次上传一大块数据
-
2.8.2. 第2步：存储
-
2.8.2.1. 数据收集完成，就会进入一个数据湖，其中包含不同层，终端用户无论身在何处（只要能访问云）都可以访问这些数据
-
2.8.2.2. 每个云提供商都提供无限量的数据湖存储，而且成本相对非常低廉
-
2.8.2.3. 数据湖具有高可用性和强大的灾难恢复功能，以及多种安全性和加密性
-
-
2.8.3. 第3步：转换
-
2.8.3.1. 数据湖的精髓是它是一个存储中心
-
2.8.3.2. MDW的重大优势是其在存储数据（在湖中）和处理数据（使用计算力）有清晰界限
-
2.8.3.3. 二者分开，为从云提供商和其他来源的计算工具提供了自由选择
-
2.8.3.4. 计算工具从符合层中提取文件，转换数据（丰富和清理数据），并将其存储到数据湖的清理层中
-
2.8.3.5. 计算工具从丰富层中提取文件，并执行更多转换以提高性能或方便使用，然后将其写入数据湖中的展示层
-
-
2.8.4. 第4步：建模
-
2.8.4.1. 直接从数据湖中的数据进行报告可能会很慢、不安全，而且会让终端用户感到困惑
-
2.8.4.2. 可将数据湖中的全部或部分数据复制到关系数据仓库中
-
2.8.4.2.1. 意味着将为关系数据仓库中的数据创建一个关系模型，该模型通常采用第三范式
-
2.8.4.3. 可考虑将数据复制到RDW中的星型模式中
-
2.8.5. 第5步：可视化
-
2.8.5.1. 一旦数据以易于理解的格式存入RDW，业务用户就可以使用熟悉的工具对其进行分析，创建报告和仪表板等
-
2.8.5.2. 在可视化阶段，业务用户不必到RDW获取所有数据，他们可以访问数据湖中尚未复制到RDW的数据
-
-
2.8.6. 阶段代表了数据的生命周期，即最初收集、安全存储、完善可用、建模以获得洞察力，以及最终可视化以方便解释和决策
2.9. 数据科学家可以使用MDW中的数据进行机器学习来训练并构建模型
2.10. 并非所有源数据都必须复制到数据湖
-
2.10.1. 在云中构建的新项目，将数据从源数据直接复制到RDW，绕过数据湖会更快，特别是对于结构化（关系型）源数据
-
2.10.2. 从关系数据库中提取数据，将其复制到数据湖（丢失数据的宝贵元数据，如数据类型、约束和外键），然后再将其导入到另一个关系数据库（数据仓库）中，这可能会耗费大量工作
2.11. 不使用数据湖，有很多将关系数据库数据复制到RDW的很多ETL包
- 2.11.1. 随着时间的推移，可以修改所有ETL包以使用数据湖
2.12. 绕过数据湖的源数据会错过数据湖的一些优势，特别是备份数据，以防需要重新运行ETL包
-
2.12.1. 绕过数据湖也会给RDW带来不必要的压力，因为RDW要负责数据清理
-
2.12.2. 使用数据湖的人会发现数据丢失，从而使数据湖无法成为唯一的真相来源
2.13. 当数据在MDW中复制并通过数据湖移动到RDW时，数据会改变格式，变得越来越易于使用
- 2.13.1. 有助于提供用户友好的自助式商业智能，终端用户只需将字段从列表拖到工作区，而无须连接任何表格，就能创建报告
2.14. 在MDW中，数据湖用于暂存和准备数据，而RDW则用于服务、安全性和合规性
2.15. 数据湖
-
2.15.1. 在数据湖中，数据科学家和高级用户拥有专门的访问权，尤其是那些拥有高级技能的用户，这是由于复杂的文件夹文件结构和独立的元数据
-
2.15.2. 数据湖可能难以浏览、访问，为此可能需要更复杂的工具
-
2.15.3. 数据湖的功能可扩展到批量处理和实时处理，前者是对数据进行批量转换，后者则是流数据的着陆点
-
2.15.4. 还用于提炼和清理数据，提供一个平台，根据需要使用尽可能多的计算能力，并有多种计算选项可供选择
- 2.15.4.1. 还可容纳ELT工作量
-
2.15.5. 数据湖是存储旧数据或备份数据的地方，而不是将其保存在RDW中
-
2.15.6. 是从数据仓库本身备份数据的地方
-
2.15.7. 用户可以在数据湖中轻松创建用于沙箱目的的数据副本，允许其他人使用和操作数据
-
2.15.8. 提供了一个查看和探索数据的机会，如果不确定要对数据提出什么问题，可以在将数据复制到数据仓库之前评估其价值
-
2.15.9. 有助于快速报告和访问数据，特别是因为数据湖采用读时模式，因此数据可以快速加载
2.16. 关系数据仓库
-
2.16.1. 将RDW作为非技术人员访问数据的场所，尤其是当他们习惯了使用关系数据库时
-
2.16.2. 数据库延迟低，查询速度更快，尤其是在使用MPP技术的情况下
-
2.16.3. 可以处理大量的表连接和复杂的查询。由于MPP技术提供的快速性能，它们非常适合运行交互式临时查询
-
2.16.4. 非常适合运行交互式临时查询
-
2.16.5. 提供了大量支持工具，由于它比数据湖历史更长久，所以有更多的工具可用
-
2.16.6. RDW具有精确到毫秒的卓越性能，因此可以针对RDW运行仪表盘
-
2.16.7. 数据上的强制元数据层需要更多的前期工作，但却使自助式商业智能变得更加容易
3. MDW架构的优点
3.1. 多个数据源集成
- 3.1.1. MDW可以处理来自各种来源（包括RDW和数据湖）的结构化和非结构化数据，提供全面的信息视图
3.2. 可扩展性
- 3.2.1. 与业务同步增长，可轻松扩展以处理增加的数据负载
3.3. 实时数据分析
- 3.3.1. 促进实时分析，使企业能够基于当前数据及时做出决策
3.4. 改善的性能
- 3.4.1. 通过利用先进技术和优化数据处理，多功能数据中心可提供更快的查询性能和见解检索
3.5. 灵活性
- 3.5.1. 在数据建模方面，MDW具备灵活性：既可进行传统的结构化查询，也可进行大数据处理
3.6. 增强的安全性
- 3.6.1. 采取了强有力的安全措施来保护敏感数据
4. MDW架构的缺点
4.1. 复杂性
- 4.1.1. 实施和管理一个MDW可能很复杂，尤其是在混合了不同类型数据存储和处理的混合架构
4.2. 成本
-
4.2.1. 初始安装、后续维护和扩展的成本可能很高，尤其是对中小型企业而言
-
4.2.2. 存储和创建多个数据副本（RDW和数据湖）的额外数据管道也会产生额外费用
4.3. 技能要求
- 4.3.1. 要充分发挥MDW的最大潜能，需要专业知识和技能，从而增加招聘难度或额外的培训成本
4.4. 潜在的数据孤岛
- 4.4.1. 如果没有适当的集成和治理，MDW可能会导致数据孤岛，或者信息变得孤立，难以在整个组织内访问
4.5. 合规挑战
- 4.5.1. 在处理各种数据类型和数据源的环境中满足合规性要求，是管理MDW的一项挑战
4.6. 供应商依赖性
- 4.6.1. 如果使用基于云的MDW服务，可能意味着要依赖特定的供应商，这可能会导致潜在的锁定并限制未来的灵活性
5. MDW的阶梯型架构
5.1. 构建MDW是一个重要而漫长的艰巨任务，需要在技术、人力和时间投入大量资金
5.2. 代表着数据管理的发展，其中集成、可访问性、安全性和可扩展性至关重要
5.3. 全面运行MDW的阶梯方案过程，确保组织能同时从数据中获取价值，并对保持商业需求的敏捷响应
5.4. 不仅仅是临时修复，而是战略转移的重要部分
5.5. 增强型EDW
-
5.5.1. 通常适用于长期使用大型内部部署EDW的公司，它们希望从数据中获得价值
-
5.5.2. 存储空间、计算能力、数据加载维护窗口时间或对半结构化数据的一般支持不足，其EDW无法处理"大数据"
-
5.5.3. 在云端创建数据湖，并将大数据复制进去。用户可从数据湖查询、生成报告，但主要数据保留在EDW中
-
5.5.4. 优势
-
5.5.4.1. 加大了数据容量和灵活性
-
5.5.4.2. 具有可扩展性和成本效益，在保持现有结构的同时为创新分析创造了机会
-
5.5.4.3. 提供了一种与业务增长和连续性相一致的平衡方法
-
-
5.5.5. 挑战
-
5.5.5.1. 需要将EDW中的数据与数据湖中的数据结合起来，就必须将EDW中的数据复制到数据湖中
-
5.5.5.2. 现有的查询工具在数据湖中可能无法继续工作
-
5.5.5.3. 需要一种新的计算形式来清理数据湖中的数据，这可能会很昂贵，而且需要新的技能组合
-
5.5.5.4. 无法转嫁EDW的全部工作量
-
-
5.5.6. 可以作为将内部部署EDW迁移到云的分阶段方法的开端
-
5.5.7. 数据从源系统首先迁移到数据湖，如有需要，再迁移到云中的新RDW，这是真正的MDW的一部分
5.6. 临时数据湖加EDW
-
5.6.1. 在公司已有EDW需要合并大数据，但传输数据需花费很多时间的情况下，通常使用临时数据与EDW
-
5.6.2. 通过卸载数据来降低EDW维护窗
-
5.6.3. 该架构使用了一个数据湖，但仅仅将其作为临时存储区和提炼区
-
5.6.3.1. 不用于查询或报告
-
5.6.3.2. 有限的范围意味着数据湖的整合速度更快
-
5.6.3.3. 可以将EDW数据复制到数据湖中，加以完善后再移回EDW
-
-
5.6.4. 优势
-
5.6.4.1. 可将数据处理移至数据湖，减轻对EDW的压力并提高整体性能
-
5.6.4.2. 在数据湖上使用其他类型的计算可提供更快的速度和功能，从而灵活处理大数据
-
5.6.4.3. 一种具有成本效益的解决方案，可在不中断现有EDW操作的情况下纳入大型数据集，是一种灵活、可扩展的方法
-
-
5.6.5. 挑战
- 5.6.5.1. 你在使用数据湖，但该架构未体现出数据湖的全部优势
-
5.6.6. 通过简单修改，该架构就能转换为完整的MDW，因此它是一个很好的跳板
5.7. 一体化
-
5.7.1. 通常由初创或小型商业组织采用，该类型组织追求效率高的数据处理
-
5.7.2. 数据湖进行了所有的报告和查询
-
5.7.2.1. 没有RDW参与
-
5.7.2.2. 一体化极度绑定数据湖架构
-
-
5.7.3. 优势
- 5.7.3.1. 易于实现且成效迅速，对于希望快速取得进展的技术团队来说尤其具有吸引力
5.7.3.1.1. 快速构建原型或者获得具体的短期目标
5.7.3.1.2. 倾向集成平台的技术专家们的更优选项- 5.7.3.2. 通过将报告和查询整合到数据湖中，可以简化架构，从而降低维护和集成的复杂性
-
5.7.4. 挑战
- 5.7.4.1. 没有RDW参与，需在性能、安全性、参照完整性或用户友好性方面做出权衡
-
5.7.5. 对于某些公司和类似数据湖中的数据仅供科学家使用的用例中，只使用数据湖的方法可能没有问题
- 5.7.5.1. 要使其进阶成MDW，就需要增加RDW