在本书的第二部分中，你学习了关系型数据仓库（RDW）和数据湖，这两个是数据管理领域的关键组成部分。现在，让我们来考虑现代商业的繁荣世界。每天，组织都必须筛选大量数据以获得见解、做出决策并推动增长。想象一下，一家城市超市从传统数据库转向现代数据仓库（MDW）。经理们现在可以访问实时库存数据，预测购物趋势，并简化顾客的购物体验。这就是MDW的威力所在。它融合了RDWs的结构和数据湖的灵活性，将两者的优势发挥到了极致。
为什么你应该关注MDWs？因为它们是我们快速发展的数据生态系统的核心，使组织能够利用所需的信息进行创新和竞争。在本章中，我将阐明MDWs是什么，以及你可以通过它们实现什么，我将向你展示一些需要牢记的重要考虑因素。我们将穿越MDW的架构、功能和通往MDW的常见步骤，最后以一个富有洞见的案例研究结束。让我们深入现代数据仓库的世界，其中数据不仅仅是数字，更是成功的动力。
MDW架构
图10-1展示了MDW的混合特性，它将RDW与数据湖结合起来，创建了一个允许灵活数据操作和强大分析的环境。
正如第4章详细介绍的那样，RDW遵循自顶向下的原则。在进行任何数据加载之前（即在写入模式下），构建RDW需要进行重要的准备工作。这种方法有助于历史报告，使分析师能够深入进行描述性分析（解释发生了什么）和诊断性分析（探究为什么会发生）的研究。
相比之下，数据湖的定义是基于其自底向上的理念，正如第5章所述。开始利用数据（读取模式）需要的初始工作量很少，这使得能够迅速部署机器学习模型来探索预测性分析（预测将会发生什么）和指导性分析（提供解决方案以实现期望的结果）。
在MDW架构中，数据湖不仅仅是存储大量信息和训练机器学习模型的存储库；它是一个动态组件，负责数据转换和第5章中探讨的其他目的。例如，它可以作为流数据的接收中心，用户进行快速数据探索和报告的网关，并作为维护单一真相版本的集中源。 MDW架构的一个重要特征是，其中的一些数据必须复制到RDW中。没有这种复制，它将成为数据湖仓库架构------这是第12章的话题。
在2010年代中期，许多组织尝试将数据湖用于所有数据用例，并完全绕过使用RDW。在这种方法失败之后，MDW成为最流行的架构，受到数据量、种类和速度指数级增长的推动。许多行业的组织，包括医疗保健、金融、零售和技术，都认识到需要更敏捷和可扩展的数据存储和分析方法。他们的RDW已经不再能够应对大数据的挑战，但MDW提供了RDW和数据湖灵活集成的方式。一些主要的提供商崭露头角，包括Microsoft的Azure Synapse Analytics，Amazon的Redshift，Google的BigQuery和Snowflake------他们彻底改变了企业访问和利用数据的方式。
随着流数据、大数据和半结构化数据变得越来越受欢迎，大型企业开始使用第11章和第12章中讨论的数据布局和数据湖仓库架构。然而，对于数据量不大（比如，少于10 TB）的客户来说，MDW仍然很受欢迎，并且可能会保持这种方式，至少在数据湖能够像RDW一样高效运行之前。
实际上，仍然有一些公司构建云解决方案，完全不使用数据湖，主要用于公司数据量较小并且正在从没有数据湖的本地解决方案迁移的用例。我仍然认为这是一种可接受的方法，但要注意的是，公司必须绝对确定数据仓库的数据增长不会太大（这很难说得很确定）。此外，如果数据量很小，那么可能可以选择比大规模并行处理（MPP）解决方案更便宜的对称多处理（SMP）解决方案（请参阅第7章）。 现在让我们深入了解MDW的细节。图10-2展示了在MDW中数据湖和RDW之间数据流的典型流程。
当数据通过MDW架构传输时，它经历了五个阶段，这些阶段在图10-2中编号。让我们跟随数据走过每个阶段，带您游览MDW架构：
**步骤1：摄取 **
MDW可以处理几乎任何类型的数据，它可以来自许多来源，包括本地和云端。数据的大小、速度和类型可能各不相同；它可以是非结构化的、半结构化的或关系型的；它可以批量处理，也可以通过实时流传输；它可以是小文件，也可以是大文件。这种多样性在数据摄取过程中可能是一个挑战。
**步骤2：存储 **
一旦数据被摄取，它就会落入一个包含所有不同层的数据湖中，这些层在第5章中有详细解释，使得终端用户可以访问它，无论他们在哪里（只要他们可以访问云）。每个云提供商都提供无限的数据湖存储，而且成本相对非常便宜。数据湖内置了高可用性和强大的灾难恢复功能，以及许多安全和加密选项。
**步骤3：转换 **
数据湖的本质是它是一个存储中心。然而，要真正理解和处理数据，您需要一些计算能力，这就是计算能力发挥作用的地方。MDW的一个重要优势是它清晰地区分了数据的存储（在数据湖中）和处理（使用计算能力）。将这两者分开使您可以从各种计算工具中进行选择，这些工具可以来自云提供商或其他来源，旨在从数据湖中提取和理解数据，可以读取各种格式的数据，然后将其组织成更加标准化的格式，例如Parquet。这种分离提供了灵活性并增强了效率。
然后，计算工具会从经过标准化处理的层中获取文件，转换数据（丰富和清理数据），并将其存储在数据湖的清理层中。最后，计算工具会从增强层获取文件，并进行更多的转换以提高性能或易用性（例如合并来自多个文件的数据和聚合数据），然后将其写入数据湖中的表示层。
步骤4：数据建模
直接从数据湖中的数据进行报告可能会很慢、不安全，并且对终端用户来说会很混乱。相反，您可以将数据湖中的全部或部分数据复制到关系型数据仓库中。这意味着您将为RDW中的数据创建一个关系模型，其中模型通常处于第三范式（参见第8章）。出于性能和简化的原因，您可能还希望将其复制到RDW中的星型模式中。
步骤5：可视化
一旦数据以易于理解的格式出现在RDW中，业务用户就可以使用熟悉的工具进行分析，例如报告和仪表板。
对于摄取阶段，您需要确定提取数据的频率以及是否使用增量提取或完全提取（参见第4章）。请记住，从数据源到存放数据湖的云的管道的大小和带宽。如果需要传输大文件而带宽较小，则可能需要每天以较小的块多次上传数据，而不是每天一次上传一次大文件。您的云提供商甚至可能有购买更多互联网带宽的选项。
在这个旅程的各个步骤中，数据科学家可以使用机器学习从MDW中的数据中训练和构建模型。根据他们的需求，他们可以从数据湖中的原始、清理或表示层中获取数据，也可以从数据湖中的沙箱层中获取数据（这是一个专门用于进行数据实验、探索和初步分析而不影响其他层的空间），也可以从RDW中获取数据。 在我刚刚阐述的MDW架构中，数据通过的旅程存在一些例外，这取决于源数据的特征。例如，不是数据湖表示层中的所有数据都需要复制到RDW中，尤其是随着新工具使得从数据湖中查询和报告数据变得更加容易。这意味着在可视化阶段，业务用户不必为所有数据去RDW获取数据-他们可以访问数据湖中尚未复制到RDW的数据。
另一个例外是，并非所有源数据都必须复制到数据湖中。在某些情况下，特别是在云中构建的新项目中，将数据直接从源复制到RDW可能更快，而不是经过数据湖，尤其是对于结构化（关系型）源数据。例如，用作维度表的参考表不需要清理，是完全提取的，并且可以在需要重新运行ETL包时从源轻松检索。毕竟，从关系型数据库中提取数据，将其复制到数据湖中（丢失有价值的元数据，如数据类型、约束和外键），然后再导入到另一个关系型数据库（数据仓库）可能需要大量工作。
这在从没有使用数据湖的本地解决方案迁移的典型情况下尤为真实，并且有许多ETL包将数据从关系型数据库复制到RDW中。为了减少迁移工作量，您只需稍微修改现有的ETL包---只需更改目标源。随着时间的推移，您可以修改所有的ETL包以使用数据湖。但是，为了快速启动，您可能只需修改一些运行缓慢的ETL包以使用数据湖，并稍后再处理其余部分。 绕过数据湖的源数据会错过一些它的好处------特别是在需要重新运行ETL包时，备份数据。绕过数据湖还会对RDW施加不必要的压力，然后RDW将负责数据清洗。此外，使用数据湖的人会发现数据缺失，阻止数据湖成为唯一的真相来源。
MDW架构的优缺点
MDW（现代数据仓库）提供了许多优点和一些挑战。其优点包括：
- 整合多个数据源：MDWs能够处理来自各种来源的结构化和非结构化数据，包括关系型数据仓库（RDWs）和数据湖，为信息提供了全面的视图。
- 可扩展性：MDWs被设计为与业务一起增长，可以轻松扩展以处理增加的数据负载。
- 实时数据分析：MDWs促进了实时分析，使企业能够基于当前数据做出及时决策。
- 改善性能：通过利用先进技术和优化数据处理，MDWs可以提供更快的查询性能和洞察力检索。
- 灵活性：MDWs在数据建模方面提供了灵活性，允许传统结构化查询和大数据处理技术的应用。
- 增强安全性：领先的MDW提供商实施了强大的安全措施，保护敏感数据。
MDW架构的一些缺点包括：
- 复杂性：实施和管理MDW可能会很复杂，特别是在结合不同类型的数据存储和处理的混合架构中。
- 成本：初始设置、持续维护和扩展可能会很昂贵，尤其是对于中小型企业而言。此外，还需要额外的成本用于存储和创建多个数据副本的额外数据管道（用于RDW和数据湖）。
- 技能需求：充分利用MDW需要专业的知识和技能，可能导致招聘挑战或额外的培训成本。
- 潜在的数据孤岛：在缺乏适当的集成和治理的情况下，MDWs可能导致数据孤岛，即信息被孤立并且难以在整个组织中访问的地方。
- 合规性挑战：在处理多样化数据类型和来源的环境中满足法规合规性可能是管理MDW的一个具有挑战性的方面。
- 供应商依赖性：如果使用基于云的MDW服务，可能意味着对特定供应商的依赖，这可能会导致潜在的锁定并限制未来的灵活性。
随着数据在MDW内部复制并通过数据湖进入RDW，其格式会变得越来越易于使用。这有助于提供用户友好的自助式商业智能（BI），最终用户可以通过从列表中拖动字段到工作区而不连接任何表格来构建报表。IT部门必须做一些额外的前期工作，使数据真正易于使用，但这通常是值得的，因为它释放了该部门对所有报告和仪表板创建的参与，并且可能成为瓶颈。
将RDW和数据湖结合
在现代数据仓库（MDW）中，数据湖用于数据的暂存和准备工作，而关系型数据仓库（RDW）则用于数据的服务、安全性和合规性。让我们更仔细地看看在同时使用RDW和数据湖时功能的所在位置。
数据湖
在数据湖中，数据科学家和技术能力较强的用户会有独占性访问权限，这是由于复杂的文件夹-文件结构和元数据的分离所致。数据湖可能难以导航，访问可能需要更复杂的工具。数据湖的功能延伸到批处理，其中数据按批次转换，以及实时处理，作为流式数据的着陆点（参见第9章）。数据湖还用于精炼和清洗数据，提供一个平台，可以根据需要使用多种计算选项的计算资源。它还适应了ELT工作负载。
在这种框架中，数据湖作为存储较旧或备份数据的地方，而不是将其保留在RDW中。它还是备份来自数据仓库的数据的地方。用户可以轻松地在数据湖中创建数据副本，用于沙盒目的，让其他人可以在数据中"玩耍"。数据湖还为您提供了一个机会，可以查看和探索数据，如果您不确定要对其提出什么问题；您可以在将数据复制到数据仓库之前评估其价值。它便于快速报告和访问数据，尤其是因为它是基于读取模式的，因此数据可以迅速落地。
关系型数据仓库
业务人员通常会将目光投向RDW，作为非技术人员访问数据的地方，特别是如果他们习惯于关系型数据库。这些数据库提供低延迟，特别是如果您使用MPP技术（参见第7章），则查询速度更快。它们可以处理大量表连接和复杂查询，并且由于MPP技术提供的快速性能，它们非常适合运行交互式的自由查询。这使您可以连续微调查询，而无需长时间等待。RDW还可以支持许多同时运行查询和报告的并发用户。
在MDW环境中，RDW的附加安全功能包括行级和列级安全性选项。 RDW还为各种工具提供了充分的支持-由于它们比数据湖存在的时间更长，因此可用的工具更多。数据湖的性能不足以支持仪表板，但您可以对RDW运行仪表板，这归功于其到毫秒级的卓越性能。在数据之上强制执行元数据层需要更多的前期工作，但使自助式BI变得更加容易。一般来说，当您构建RDW时，您已经知道要对数据提出的问题，并且可以计划处理它们，使RDW成为一个强大而多才多艺的工具。
迈向现代数据仓库（MDW）的重要步骤
构建现代数据仓库（MDW）是一项至关重要但漫长而艰巨的任务，需要在技术、人力资源和时间方面进行相当大的投资。它代表了数据管理的演进，其中整合、可访问性、安全性和可扩展性至关重要。在这个过程开始时，大多数组织需要临时解决方案来满足其当前数据仓库的需求。这些解决方案作为迈向完全运作的MDW的阶梯，确保组织同时可以从其数据中获得价值，并保持对业务需求的敏捷和响应能力。它们不仅仅是临时修复措施，而是战略迁移中的重要组成部分。
三种常见的迈向MDW的阶梯架构是：
- EDW增强：增强传统企业数据仓库（EDW）以适应现代数据管理的需求。
- 临时数据湖加EDW：暂时性地使用数据湖加EDW的组合解决方案。
- 全能型：将所有功能整合到一个解决方案中。
每种方法都提供独特的优势和挑战。它们作为通向MDW的路径的适用性可能会根据组织的需求、现有基础设施、预算和战略目标而有所不同。让我们更详细地看看每一种。
EDW增强
这种架构通常出现在长期拥有大型本地EDW的公司希望从数据中获取价值，但由于存储空间不足、计算能力不足、数据加载维护窗口中的可用时间不足，或者对半结构化数据的一般支持不足，其EDW无法处理"大数据"的情况下。
工作原理
您在云中创建一个数据湖，并将大数据复制到其中。用户可以从数据湖查询和生成报告，但主要数据仍存储在EDW中，如图10-3所示。
Benefits
EDW增强架构通过利用云数据湖和现有EDW相结合，增强了数据容量和灵活性。这种策略提供了可扩展性和成本效益，为创新分析提供了机会，同时保持了当前结构。它提供了一种平衡的方法，与业务增长和连续性保持一致。
Challenges
这种架构确实存在一些潜在的困难：
- 如果您需要将EDW中的数据与数据湖中的数据合并，您必须将数据从EDW复制到数据湖。
- 您现有的查询工具可能无法针对数据湖进行操作。
- 您将需要一种新的计算形式来清理数据湖中的数据，这可能很昂贵，并且需要新的技能。
- 这种架构无法帮助您卸载EDW的任何工作负载。
Migration
这种架构可以作为逐步将本地EDW迁移到云端的方法的开端。在架构已经启动并与大数据一起运行后，您可以开始将本地EDW中的数据迁移到数据湖中。源系统的数据首先进入数据湖，然后，如果需要，再进入云端的新RDW，这是真正的MDW的一部分。
临时的数据湖加EDW
公司通常在拥有EDW并且需要整合大数据但转换需要太多时间时，会使用临时数据湖与EDW。这些公司希望通过卸载数据转换来缩短EDW的维护时间窗口。
工作原理
该架构使用数据湖，但仅作为临时的暂存和精炼区域。它不用于查询或报告；所有这些都是从EDW完成的，如图10-4所示。这种有限的范围意味着可以更快地整合数据湖。有时甚至可以将EDW数据复制到数据湖中，加工处理后再移回EDW。
好处
这种架构使数据处理卸载到数据湖，减轻了EDW的压力，提高了整体性能。在数据湖上使用其他类型的计算可以提供更快的速度和功能，允许灵活处理大数据。这种策略为整合大型数据集提供了一种经济高效的解决方案，而不会干扰现有的EDW运营，使其成为一种敏捷且可扩展的方法。
挑战
尽管你使用了数据湖，但这种架构并没有让你充分享受到数据湖的全部好处（见第5章）。
迁移
通过仅进行一些修改，这种架构就可以发展成为一个完整的MDW，因此它是一个很好的过渡阶段。
全包式架构
全包式架构通常被寻求数据处理流程简化的组织采用，比如初创企业或小型企业。它可能被用于快速原型设计或实现特定的短期目标。当主要用户是技术专家且偏好集成平台时，这也是一个不错的选择。
运作方式
所有的报告和查询都是通过数据湖来完成的，如图10-5所示。没有涉及到关系数据仓库。（全包式架构与第12章中讨论的数据湖仓架构密切相关。）
好处
这种方法可以快速实施并立即见效，对追求快速进展的技术团队特别有吸引力。通过在数据湖中 consoli 可以在数据湖中 consoli 实施报告和查询，简化了架构，潜在地减少了维护和集成的复杂性。这种方法可以更加敏捷和适应性强，可以容纳各种数据类型，并促进更加流畅的开发过程。
挑战
没有关系数据仓库会涉及到在性能、安全性、引用完整性或用户友好性方面的权衡。
迁移
对于一些公司和使用案例来说，比如数据湖中的数据只会被数据科学家使用时，仅使用数据湖的方法可能是可以接受的。但是，要将其作为迁移到 MDW 的垫脚石，您需要添加一个关系数据仓库。
案例研究：Wilson & Gunkerk 的战略转变至 MDW
Wilson & Gunkerk 是一家虚构的位于美国中西部的中型制药公司，一直依靠本地解决方案来处理其数据管理需求。由于数据量始终保持在 1TB 以下，公司从未感到有必要转向更先进的解决方案，如数据湖或 MDW。
挑战
随着业务环境变得更加竞争激烈，公司对市场趋势和客户行为的可行洞察需求变得更加迫切。现有的数据系统开始显示出其局限性，组织面临一个两难选择：是升级到更全面的数据湖解决方案还是 MDW。另一个关键考虑因素是对未来数据增长的不确定性，特别是随着新的研发项目逐步展开。
解决方案
在经过深入分析后，Wilson & Gunkerk 决定在云中实施 MDW 解决方案。导致这一决定的几个因素包括：
- 现有数据量远低于 1TB，并且预期增长在 10TB 内。
- 迁移到基于云的 MDW 提供了从现有本地解决方案平稳过渡的机会，无需适应像数据湖这样完全新的技术。
- MDW 将是经济高效的选择。Wilson & Gunkerk 选择了 SMP 解决方案，而不是更昂贵的 MPP 选项，因为其数据需求是适度且可管理的。
- 所选的 MDW 提供了强大的性能和足够的可扩展性，可以在可接受的范围内处理预期的数据增长。
结果
过渡到 MDW 在几个月内完成，对正在进行的业务流程的干扰最小化。Wilson & Gunkerk 实现了即时的好处：
- 增强的分析能力 新系统促进了更好的数据分析，实现了更明智的决策。公司从简单的历史分析转向了预测分析。在使用 MDW 之前，洞察力仅限于过去的趋势。新系统促进了各种数据源的整合和复杂数据挖掘算法的使用。这使公司能够创建预测模型，例如根据患者人口统计信息和遗传因素预测药物功效。过渡导致了更加细致的决策，为药物开发和个性化医疗解决方案提供了更精确的方法。
- 成本节约 与潜在的 MPP 解决方案或全面的数据湖相比，SMP 解决方案以较低的成本提供了出色的性能。
- 未来可扩展性 在保持未来过渡的同时，MDW 允许渐进式增长和适应性，而不会在公司目前不需要的技术上过度投资。
Wilson & Gunkerk 的案例展示了对数据管理解决方案的平衡处理。对于处理适度数据量并寻求可扩展和经济高效解决方案的公司而言，MDW 仍然可能是一个吸引人的选择。每个组织的需求和增长轨迹都是独特的，因此对现有和未来需求进行仔细分析对选择最合适的数据架构至关重要。
总结
本章首先详细描述了 MDW，然后描述了数据通过 MDW 的五个关键阶段的旅程：摄取、存储、转换、建模和可视化。这些阶段代表了数据的生命周期，它最初被捕获，安全存储，为可用性进行了改进，为洞察力进行了建模，最终被可视化以便易于解释和决策。
我详细介绍了 MDW 的优势，包括集成性、可扩展性、实时分析和安全性等方面，同时考虑了复杂性、成本和供应商依赖等挑战。然后，我们深入探讨了传统 RDW 与数据湖的结合，突出了这种混合提供的独特能力以及在处理各种数据类型和结构时提供的增强灵活性。
接着，我对公司通常部署的三种过渡性架构进行了详细探讨，这些架构作为它们的数据仓库需求的临时解决方案：企业数据仓库增强、临时数据湖加 EDW 和一体化。每种模型都作为组织朝着实施完整 MDW 的目标迈进时的临时措施。
最后，我以一个中等规模的制药公司 Wilson & Gunkerk 的案例研究结束，介绍了其战略性转向 MDW。
接下来的章节将深入探讨数据布局和数据湖架构，解开它们在不断发展的数据管理领域中的优势和潜在用例。