大数据在2010年代初开始以前所未有的规模出现，这是由于输出半结构化和非结构化数据的来源增加，例如传感器、视频和社交媒体。半结构化和非结构化数据蕴含着巨大的价值------想想多年来客户电子邮件中蕴含的见解！然而，那个时候的关系数据仓库只能处理结构化数据。它们还很难处理大量数据或需要频繁摄入的数据，因此它们不适合存储这些类型的数据。这迫使行业提出了一个解决方案：数据湖。数据湖可以轻松处理半结构化和非结构化数据，并管理频繁摄入的数据。

多年前，我与一家大型零售连锁店的分析师交谈过，他们想要摄入来自Twitter的数据，了解客户对他们商店的看法。他们知道客户会犹豫向店员提出投诉，但会很快将它们发布到Twitter上。我帮助他们将Twitter数据摄入到数据湖中，并评估客户评论的情绪，将其分类为积极的、中立的或消极的。当他们阅读消极的评论时，他们发现有异常多的投诉是关于试衣间的------它们太小、太拥挤，不够私密。作为一个实验，公司决定在一家店重新装修试衣间。在重新装修后的一个月，分析师发现该店的试衣间有大量的积极评论，销售额增长了7%。这促使公司决定在所有店铺重新装修试衣间，在全国范围内销售额增加了6%，利润增加了数百万。这一切都要归功于数据湖！

什么是数据湖？

数据湖是一个比喻，用来描述将大量原始数据以其自然格式存储的概念。就像湖泊容纳水而不改变水的性质一样，数据湖容纳数据而无需首先对其进行结构化或处理。此外，就像湖泊容纳各种野生动植物物种一样，数据湖容纳不同类型的数据（结构化、半结构化和非结构化）。与数据仓库形成鲜明对比，数据仓库中的数据更加结构化和经过加工，类似于仓库中的瓶装或包装货物。

一旦数据进入数据湖，就必须对其进行清洗、连接和可能的聚合，以使其变得有用。这就是某种类型的计算（即管理、操作和分析数据所需的处理能力）必须连接到数据湖，获取和转换数据，然后将其放回数据湖的地方。

为什么要使用数据湖？

在使用数据湖的许多原因中，尤其是与关系型数据仓库一起使用时，有以下几点要考虑。正如前面提到的，您可以通过一种称为"按需读取架构"的方法，快速将数据存储到数据湖中（参见第二章）。这使您能够更快地访问数据，从而使用户可以快速运行报告（以加快投资回报，ROI），并为数据科学家提供快速访问数据以训练机器学习模型。它还对调查数据非常有用。如果最终用户要求您将源数据复制到DW中，您可以将源数据快速复制到数据湖中，并对其进行调查，以确保其具有价值，然后再努力创建数据仓库中的模式并编写ETL。

我在第四章中提到过，通常情况下，使用DW时，在夜间会有一个维护窗口，您会在这个窗口将最终用户踢出系统，以便将源数据加载到DW的暂存表中。然后，您会清理数据并将其复制到DW的生产表中。问题在于，如果遇到问题并且维护时间比预期的时间长，那么当最终用户在早晨尝试访问数据时，他们就会被锁在外面。更好的选择是在数据湖中转换数据，而不是在DW中进行转换。这样做的好处包括：

成本节约，因为DW计算通常比您可以在数据湖中使用的其他类型的计算要昂贵得多。通过具有多种计算选项，每个计算可以访问包含数据的不同文件夹并并行运行（或在相同数据上并行运行），可以实现极端的转换性能（如果需要）。可以以比DW更多的方式对数据进行细化，因为可以灵活使用数据湖中的数据的许多不同类型的计算选项。例如，您可以使用带有预构建例程的代码库执行复杂的转换，这些转换在DW中使用SQL非常困难或不可能完成。不需要DW维护窗口，允许全天候使用DW进行查询。如果尝试运行报告时数据转换正在进行，您还可以避免用户争用相同的计算资源。由于数据转换是资源密集型的，因此可能会大大减慢彼此之间的速度。数据湖是以低成本存储无限量数据的廉价方式。与本地存储不同，云提供商拥有无限的存储空间，因此您永远不必担心数据湖的空间不足。此外，云存储相对便宜，大多数云提供商都提供多种存储级别，可以让客户节省更多资金。

数据湖让您"随时随地"收集任何数据，以防将来可能需要。这种数据储存在DW中很少见，因为DW中的存储通常比数据湖中的存储要昂贵得多，并且在DW中存储更多数据可能会影响性能。由于数据湖中的存储非常便宜，除非出于监管原因，否则很少删除数据。

因为它是所有数据主题的集中地，所以数据湖可以成为"真理的单一版本"。如果在将数据复制到其他地方之前，所有数据都会进入数据湖，那么如果对数据的准确性产生疑问，例如在查询、报告和仪表板等其他使用地点，那么数据湖就可以成为返回的地方。此外，数据湖还使任何最终用户都可以轻松访问任何地点的任何数据，并多次使用它进行任何分析需求和用例。当您将数据湖与DW一起使用时，数据湖将成为真理的单一版本，而不是DW。此外，数据湖是一个可以用于存储流数据的地方，例如来自物联网设备的数据，这在DW中几乎不可能实现。

数据湖还充当在线存档的地方。例如，您可以将最近三年的订单数据保留在DW中，将三年前的订单数据保留在数据湖中。大多数用于构建DW的技术都允许您使用SQL查询数据湖中的数据，因此用户仍然可以在报告中使用湖中的数据（以性能较慢为代价）。这样可以节省成本并避免在DW中存储空间不足。

数据湖还是一个可以从DW中备份数据的地方，以防需要由于意外删除、损坏、UPDATE查询中的错误WHERE子句等而恢复数据。

此外，您还可以将结构不同的数据集成到数据湖中：从CSV和JSON文件到Word文档和媒体文件的一切。可以从这些文件中提取数据以提供更多价值。

使用DW时，从源系统复制到DW的原始数据通常会在一两天后删除，以节省有限的关系型存储空间。如果多天前的ETL运行中发现了ETL错误，那么如果需要重新运行ETL但原始数据已被删除，您就必须返回到源系统，并可能影响其性能。通过在数据湖中进行转换（存储更便宜），您可以保留原始数据的长时间历史记录，而无需返回到源系统。

自底向上方法

由于数据湖采用了"按需读取模式"，因此在开始使用数据时几乎不需要进行大量的预先工作。如果您还不知道要对数据提出什么问题，这种方法非常有效------您可以快速探索数据以确定相关的问题。这导致了所谓的"自下而上"方法，如图5-2所示，在生成任何理论或假设之前，您先收集数据。这与关系型数据仓库的自上而下方法截然不同，如图5-1所示。

这使得数据科学家可以使用偏爱文件格式的软件对数据湖中的数据进行机器学习，以确定未来可能发生的事情（预测分析）以及如何使其发生（规范性分析）。

预测性分析利用数据、统计算法和机器学习技术基于历史数据预测未来结果。它包括各种统计技术，如数据挖掘、预测建模和机器学习，以分析当前和历史事实，从而对未来或其他未知事件进行预测。这使您能够采取主动措施，而不仅仅是被动应对。例如，预测性分析可用于医疗保健领域预测患者再次入院率，在零售领域预测未来销售额，在银行业预测贷款违约率等。

规范性分析比预测性分析更进一步。它利用优化和仿真算法提供建议。规范性分析不仅预测未来会发生什么，还建议采取哪些行动来影响这些结果。其目标是基于预测的未来场景提供建议，以优化决策。规范性分析可以提出关于如何利用未来机会或减轻未来风险的决策选项，并且可以说明每个决策选项的影响。例如，在物流领域，规范性分析可用于寻找最佳的交付路线，甚至在发生意外道路关闭时建议备用路线。

起初，数据湖主要用于预测和规范性分析，以避免试图使用传统数据仓库进行高级分析时遇到的困难。但现在，数据湖被用于更多用途，正如"为什么使用数据湖？"中所述。

如果在探索数据湖时发现有价值的数据，并且希望将其轻松地提供给最终用户，您可以随时将其复制到关系型数据仓库中进行建模。数据建模就像创建组织和理解数据的蓝图。它有助于定义哪些数据是重要的，它们之间的关系是什么，以及在关系型数据仓库中如何存储和使用数据。数据湖的数据建模工具有限，而数据仓库多年来一直拥有建模工具。

数据湖设计的最佳实践

设计数据湖应该是一个耗时的过程。我经常发现，许多公司在设计数据湖时没有花足够的时间来思考所有的用例，后来不得不重新设计和重建它们。因此，请确保您仔细考虑现在和将来使用的所有数据源，并了解数据的大小、类型和速度。然后吸收您可以找到的所有关于数据湖设计的信息，并选择适合您情况的适当设计。

数据湖通常不对其摄取的数据强制执行特定结构；事实上，这是其关键特征之一。这与传统数据库或数据仓库不同，后者要求数据在摄取之前进行结构化或建模。然而，为了使数据可用并防止数据湖成为"数据沼泽"（一种无组织和无法管理的数据集合），应用一些组织和治理实践是很重要的。本节介绍了一些最佳实践，帮助您开始工作。

第一个最佳实践是将数据湖逻辑上划分为多个层（也称为区域），对应于逐渐增加的数据质量水平，如图5-3所示。否则，您的所有文件都将位于一个文件夹中，严重影响性能、可管理性和安全性。

为了更好地理解数据湖的结构和功能，让我们深入探讨它的各个层次，每个层次代表着数据质量和可用性的提升步骤。这些层次按层次结构排列，从原始、未经处理的数据逐步进化到高度精炼且适用于业务的信息。以下是对每个层次的更详细介绍：

原始层原始事件被存储作为历史参考，通常永久保留（不可变）。将原始层视为一个储存数据的水库，其中数据保持其自然和原始状态（未应用任何转换）。它是未经过滤和未经净化的。此层也被称为铜层、暂存层或着陆区。
一致化层通常，原始层中的数据将以不同的类型存储，例如CSV、JSON和Parquet（一种通用的存储文件格式，针对高效的大数据处理进行了优化）。一致化层是将所有文件类型转换为一个格式，通常是Parquet。将湖泊视为拥有两个水库，一个是海水，一个是淡水，并利用淡化技术将海水转化为淡水。此层也称为基础层或标准化层。
净化层在这里，原始事件被转换（数据被清理、集成和合并）为可直接使用的数据集。将净化层视为过滤层。它去除杂质，也可能丰富数据。其目的是使存储的文件在编码、模式、格式、数据类型和内容（例如字符串和整数）方面保持统一。此层也称为银层、转换层、精炼层、集成层、加工层、或丰富层。
展示层将业务逻辑应用于清洗后的数据，以生成可供最终用户或应用程序使用的数据，通常以易于理解和使用的格式呈现。转换可能涉及汇总或摘要，也可能意味着将文件放置到报告工具中的特定布局（例如，星型模式，在第8章中讨论），通常在每个文件中包含有关数据的信息（元数据）。此层也称为应用层、工作区、可信层、黄金层、安全层、生产就绪层、治理层、策划层、服务层、分析层或消费层。
沙盒层这是一个可选的层，用于"玩耍"。通常由数据科学家使用。它通常是原始层的副本，其中数据不仅可以被读取，还可以被修改。您可以创建多个沙盒层。此层也称为探索层、开发层或数据科学工作区。

这只是设置数据湖层次的一种方式。我见过许多其他优秀的设计，其中包括额外的层次或组合一些层次，例如一致化层和净化层。

以图5-3中的层次为例，让我们考虑一个零售公司，该公司有不同的数据源，如销售点（POS）系统、在线销售、客户反馈和库存系统。四个层次将包含不同质量的数据，如下所示：

原始层
- 来自POS系统的原始日志，包括每笔交易的详细信息（例如时间戳、购买物品、数量、价格、总金额、收银员ID和店铺位置）
- 来自网站或应用的在线销售数据，例如用户ID、购买物品、数量、价格、总金额和时间戳
- 来自各个仓库和商店的库存数据，包括物品、数量和补货日期
- 通过调查、评论和评分收集的原始客户反馈
一致化层
- 如果数据尚未以Parquet格式存储，则将所有POS、在线销售、库存和客户反馈文件转换为Parquet格式。
净化层
- 去除或纠正了POS和在线销售数据中的任何错误（例如物品名称的不一致性、数量错误和缺失的时间戳）。数据也被转换为通用模式（例如，物品的通用命名约定和格式、通用时间格式或通用店铺ID系统）。
- 标准化了库存数据中的物品命名，并纠正了错误或不一致性。数据也被转换为与销售数据中使用的通用物品名称和店铺ID相一致的形式。
- 清理了客户反馈数据，去除了不相关或错误的响应，给出了标准化的格式等。数据也被转换为通用格式，与通用店铺ID系统相一致，也许还提取了用于分析的通用元素。
展示层
- 一个综合的销售报告，显示每家店铺、每个地区或每天/每月/每年的总销售额，也许还包括按物品或类别细分的销售额
- 一个库存报告，显示每个店铺或仓库的当前库存水平，以及补货计划
- 一个客户反馈报告，总结了反馈内容，也许为每家店铺或产品提供了情感分析分数

另一个最佳实践是创建一个文件夹结构，通常为每个层次创建一个不同的文件夹，可以根据不同的原因进行划分。以下是一些示例：

数据分离
- 根据来源、业务单元或数据类型组织数据，使数据科学家和分析师更容易找到和使用相关的数据。
访问控制
- 组织文件夹基于用户角色或部门，不同团队或组织内的个人可能具有不同级别的数据访问权限。通过构建基于用户角色或部门的文件夹结构，组织可以实施细粒度的访问控制策略。
性能优化
- 以特定方式组织数据可以提高性能。例如，如果根据特定特征对数据进行分组，则某些数据处理或查询操作可能会更快。
数据生命周期管理
- 数据通常具有从摄取到归档或删除的生命周期。不同的文件夹可以用于根据数据在生命周期中的阶段进行分隔。
元数据管理
- 文件夹可以用于管理和分隔原始数据的元数据。此分隔可以简化元数据管理并加快数据发现速度。
合规要求
- 在许多行业中，合规要求规定特定类型的数据以特定方式存储和管理。不同的文件夹结构可以帮助组织满足这些要求。
备份和灾难恢复
- 具有不同文件夹结构可以帮助创建战略性的备份和灾难恢复计划。根据其重要性，某些文件夹可能会更频繁地备份或保留更长时间。
数据版本管理
- 不同的文件夹可以用于管理相同数据集的不同版本。
数据分区
- 数据可以根据关键属性进行分区，以提高查询性能。
摄取和处理需求
- 基于数据来源，数据可能需要不同的处理管道。不同的文件夹可以帮助管理和优化这些过程。

为了满足上述一个或多个原因，您可以根据以下一种或多种方式划分文件夹：

时间分区（年/月/日/小时/分钟），例如将数据复制到数据湖的时间
主题领域
数据来源
对象，例如源表
安全边界，例如部门或业务领域
下游应用程序或目的
数据类型，例如详细或摘要
数据保留策略，例如临时和永久数据，适用期间或项目寿命周期
业务影响或重要性，例如高、中、低
拥有者/监护人/专家
数据访问的概率，例如最近或当前数据与历史数据
机密分类，例如公共信息、仅内部使用、供应商/合作伙伴保密、个人身份信息或敏感信息

图5-4显示了原始和清理区域的示例文件夹结构。

大多数情况下，所有这些层都在一个云订阅下。也有一些例外情况，比如如果您对计费有特定要求，如果您将达到某些订阅限制，或者如果您希望为开发、测试和生产设置单独的订阅。（有关更多例外情况，请参阅下一节。）大多数客户为每个层创建一个存储账户（因此，三个层意味着三个存储账户），所有这些账户都在单个资源组内（资源组是一个包含与解决方案相关的相关资源的容器）。

这样做可以隔离各个层，有助于使性能更加可预测，并允许在存储账户级别使用不同的功能和功能。在每个存储账户级别设置的典型功能可通过大多数云提供商（在本节中我专注于 Azure）提供，包括生命周期管理，它允许您通过自动化数据管理任务（例如在不同存储层之间迁移数据或在不再需要时删除数据）来降低成本。您还可以设置防火墙规则，仅允许对某些受信任的组或个人进行访问，或者防止超出账户的存储或吞吐量限制。大多数数据湖使用云存储访问层，原始和符合层使用存档层，清洁层使用冷层，展示和沙盒层使用热层。

每个层提供了存储成本和访问成本的不同平衡，热层对存储成本最昂贵，存档层对检索成本最高。我建议建立审计或完整性检查机制，以确保数据在层间移动时准确无误。例如，如果处理财务数据，您可以创建一个查询，对当天的订单进行求和（行计数和销售总额），并将这些值与源数据进行比较，以确保所有数据层中的这些值相等。如果它们不相等，则表示您创建的用于移动和转换数据的管道存在问题。您需要修复问题并重新运行管道。

多个数据湖

理想情况下，您只需创建一个大型数据湖，并将其用于所有数据。这种方法会简化查询或报告中查找和组合数据的过程。但是，有许多原因可能需要创建多个物理上分离的数据湖（如图5-5所示），而不是将一个数据湖分成不同的部分。接下来我讨论的大多数用例，除非数据湖是物理上分开的，否则不可能实现（或者至少不那么方便）。

优势

我已将创建物理上独立的数据湖的原因分成五个部分，之后我将讨论拥有多个数据湖的缺点。

组织结构和所有权

维护多个数据湖可能有许多优势，其中大多数与组织结构和所有权相关。例如，公司的组织结构可能鼓励或要求每个组织单元保留自己数据的所有权，这通常与数据网格（见第13章）相关联。另一个原因是不同的团队或部门可能需要自己独立的数据湖来应对特定的用例或项目。

此外，公司可能会受益于拥有与数据源对齐的数据湖以及与消费者对齐的数据湖。特定数据源的数据可以被收集到一个只进行最小转换的数据湖中。这对于了解源数据的用户非常有效，例如从制造过程中获取数据的制造部门；然而，制造部门之外的人可能会发现数据难以理解。

在这种情况下，您可能会将数据复制到一个消费者对齐的数据湖中，并对其进行转换以使其更易于理解。因此，与一个数据湖相比，为源对齐和消费者对齐的数据分别拥有单独的数据湖可以简化数据处理过程。

合规性、治理和安全性

决定拥有多个数据湖而不是只有一个，受到多种因素的显著影响，这些因素属于合规性、治理和安全性的广泛范畴。例如，多区域部署可能需要多个数据湖，当数据驻留地或主权要求在各个地区有所不同时。例如，来自中国的数据不能出口到国外，因此在该地区需要一个独特的数据湖。

另一个关键考虑因素是，多个数据湖允许您将敏感或机密数据与较不敏感的数据分开。可以特别应用更严格的安全控制于敏感数据湖，从而提升整体数据安全性。

如果某些人具有较高的访问特权，单独的数据湖可以限制这些特权的范围，将其限制在个人所工作的特定数据湖中。这有助于促进更安全的数据环境。

最后，多样化的治理和合规要求可能是拥有多个数据湖的推动力。诸如《通用数据保护条例》（GDPR）和《健康保险可移植性与责任法案》（HIPAA）等法规需要采用独特的数据管理标准和实践。有了多个数据湖，组织可以根据适用于每个数据集的特定治理和合规要求来管理其数据，这种做法在高度受监管的行业中尤为重要。

云订阅、服务限制和政策

出于与云订阅、服务限制和政策主要相关的原因，拥有多个数据湖也可能是有利的。例如，拥有多个数据湖可以帮助规避云提供商的订阅或服务限制、配额和约束，例如每个订阅的存储账户数量上限。在这种情况下，如果您只运营单个数据湖，您的需求可能超出这些限制。

此外，多个数据湖可以让您实施不同的云政策。云提供商通常提供数百种不同的政策选项，可以为每个数据湖单独定制。这种灵活性有助于确保符合公司政策。例如，某些存储账户具有基础设施加密的规定，这个规则在您的操作中的一个数据湖与另一个数据湖之间可能会有所不同。

最后，当您维护各自拥有独立云订阅的单独数据湖时，为了计费目的跟踪成本会更加简单。这种成本跟踪的细粒度程度比云服务提供的其他方法更有优势，例如为每个资源使用标签。

性能、可用性和灾难恢复

性能、可用性和灾难恢复也提供了许多考虑采用多个数据湖的原因。其中一个原因是改善延迟。如果一组全球终端用户正在访问单个数据湖，那些距离较远的用户可能会发现服务非常缓慢。通过将数据湖放置在与查询数据的终端用户或应用程序相同的地区，您可以显著减少访问数据所需的时间。

维护多个数据湖并在不同地区的副本中保存数据还极大地增强了灾难恢复能力。如果一个地区的数据湖变得不可访问，可以将终端用户重定向到保存相同数据的另一个地区。

拥有多个数据湖还为不同类型的数据实施不同的数据恢复和灾难恢复策略提供了灵活性。需要持续可用性的关键数据可以存储在数据湖中，其数据在不同地区的多个湖中复制，而可以忍受无法访问的时期的较不重要的数据可以存储在单个数据湖中，以节省大量成本。

最后，通过多个数据湖，您可以为不同类型的数据实施不同的服务级别。例如，您可以将一个数据湖用于存储和处理高优先级数据，这些数据需要低延迟访问和高可用性，并将另一个数据湖用于较低优先级的数据，其中更高的延迟和较低的可用性是可以容忍的。这种策略通过允许您为较低优先级的数据使用更便宜的存储和处理资源，优化了数据管理基础设施的成本和性能。

数据保留和环境管理

拥有多个数据湖可以使数据保留和环境管理更加高效。例如，通过将专用于开发、测试和生产环境的数据湖进行分隔，组织可以确保每个环境都有自己独立的数据存储和处理空间。这最大程度地减少了数据生命周期不同阶段之间的干扰或冲突的风险。

拥有多个数据湖的另一个优势是您可以实施不同的数据保留政策。法律或监管要求通常规定需要在特定期间保留数据。如果针对不同类型的数据有单独的数据湖，您可以轻松实施针对这些类别量身定制的各种保留政策。这种方法可以有效管理数据保留，确保符合各种法规的同时优化存储资源利用。

缺点

使用多个数据湖可能会增加数据管理基础设施的复杂性和成本，并需要更多的资源和专业知识来维护，因此，如果有选择的余地，权衡成本与收益是很重要的。然而，在某些情况下，你可能别无选择；例如，如果你需要围绕数据主权的需求进行设计，那么你就必须拥有多个数据湖。

在保持数据一致性的同时，在多个数据湖之间正确传输数据可能需要额外的集成和管理工具（例如Azure Data Factory、Informatica或Apache NiFi）。最后，拥有多个数据湖还增加了性能挑战，当查询或报告需要来自多个数据湖的数据时，需要合并这些数据。如果这些数据湖在物理上相距很远，甚至可能位于世界不同地区，将所有数据复制到一个位置可能会耗费时间。

总结

本章对数据湖进行了全面探讨，这是一种大规模的数据存储和管理解决方案，能够以原生格式存储原始数据。我讨论了数据湖的作用和设计原则，以及在特定情境下为什么可能考虑维护多个数据湖。与关系型数据仓库不同，数据湖允许快速存储数据，无需任何预先准备或转换。这确保了快速而轻松的数据摄入过程，在当今大数据时代特别有用。

我讨论了使用数据湖的好处，强调了其为数据存储提供的灵活性和速度。这一特点，以及它能够容纳各种数据类型（结构化、半结构化和非结构化），是一个关键优势，特别是在需要快速、可扩展和多样化数据收集的情况下。

本章还介绍了自下而上的方法，这是一种重要的方法论，在这种方法中，你会先收集数据，然后再提出任何理论或假设。与传统的自上而下策略相反，这种方法促进了更灵活、以数据为中心的决策过程。

本章的重要部分集中在数据湖的设计上，介绍了将数据湖逻辑地划分为多个层的概念。这种分层结构有助于以有组织的方式管理数据，为高效的数据检索和分析铺平了道路，同时还可以帮助实现安全性、访问控制和数据生命周期管理。

本章最后探讨了组织选择拥有多个数据湖的原因。潜在的好处包括增强安全性，提高法规合规性，并在不同业务单位或特定用例中实现更好的数据管理。

在第六章中，我们将继续探讨数据存储。

解读数据架构——数据湖