尧图网站建设 
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架构的一个基本特征是至少有一部分数据必须复制到RDW2.4.1. 如果没有这种复制它将是一个数据湖-房屋架构2.5. 微软推出了Azure Synapse Analytics亚马逊推出了Redshift谷歌推出了BigQuery和Snowflake2.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. 增强型EDW5.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. 临时数据湖加EDW5.6.1. 在公司已有EDW需要合并大数据但传输数据需花费很多时间的情况下通常使用临时数据与EDW5.6.2. 通过卸载数据来降低EDW维护窗5.6.3. 该架构使用了一个数据湖但仅仅将其作为临时存储区和提炼区5.6.3.1. 不用于查询或报告5.6.3.2. 有限的范围意味着数据湖的整合速度更快5.6.3.3. 可以将EDW数据复制到数据湖中加以完善后再移回EDW5.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 读数据架构知识体系指南13现代数据仓库
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架构的一个基本特征是至少有一部分数据必须复制到RDW2.4.1. 如果没有这种复制它将是一个数据湖-房屋架构2.5. 微软推出了Azure Synapse Analytics亚马逊推出了Redshift谷歌推出了BigQuery和Snowflake2.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. 增强型EDW5.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. 临时数据湖加EDW5.6.1. 在公司已有EDW需要合并大数据但传输数据需花费很多时间的情况下通常使用临时数据与EDW5.6.2. 通过卸载数据来降低EDW维护窗5.6.3. 该架构使用了一个数据湖但仅仅将其作为临时存储区和提炼区5.6.3.1. 不用于查询或报告5.6.3.2. 有限的范围意味着数据湖的整合速度更快5.6.3.3. 可以将EDW数据复制到数据湖中加以完善后再移回EDW5.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