《云数据湖》第三章：为您的数据湖考虑设计要素-灵析社区

第三章：为您的数据湖考虑设计要素

不要害怕完美，因为你永远无法达到它。 --萨尔瓦多·达利

在第1章和第2章中，我们从上帝视角了解了云数据湖是什么以及云上一些广泛使用的数据湖架构。前两章中的信息为您提供了足够的背景，以开始构建您的云数据湖设计；您至少需要能够拿起一支干擦笔并勾画一个表示云数据湖架构组件及其相互作用的块图。

在本章中，我们将深入探讨云数据湖架构的实施细节。正如您所记得的，云数据湖架构由各种IaaS、PaaS和SaaS产品组成，这些产品组装成一个端到端的解决方案。将这些个别服务视为乐高积木，而您的解决方案就是您用乐高积木搭建的结构。您可能最终会建造一个堡垒、一条龙或一艘宇宙飞船——选择仅取决于您的创造力（和业务需求）。然而，有一些基本概念您需要理解，这正是我们在本章中要讨论的内容。

我们将继续使用Klodars Corporation来举例说明一些决策选择。

建立云数据湖基础设施

大多数云数据湖架构可归为以下两类：

从头开始在云上构建云数据湖。您没有先前的数据湖或数据仓库实现，从零开始建设。
将数据湖从本地系统或其他云提供商迁移到云上。在这种情况下，您已经有了现有的实现，可以是数据仓库或数据湖，您将其迁移到云上。

在这两种情况下，您在迁移到云上的旅程中的第一步基本上是相同的。您将选择云提供商，选择服务，并设置基础设施。云提供了各种各样的选择供您选择，每种选择都有其优势和机会，因此在转向云之前，首先要记住的是，在进行这种转变时，没有什么万能药或规定的12步过程。然而，通过与许多客户以及亲自参与云迁移，我将客户旅程总结为一个决策框架，包括以下关键步骤，如图3-1所示：

确定您的目标。
计划架构和可交付成果。
实施云数据湖，可以从头开始构建，也可以将现有系统迁移到云上。
运营和发布。

确定你的目标

正如我们在第一章中所看到的，数据湖对于获取关键洞见以推动业务发展至关重要。然而，在众多可能性中，明确数据湖为您的组织提供的具体目标非常重要。这些目标将帮助您确定需要优先处理的数据和处理方式，以满足业务需求。

作为第一步，您需要确定数据湖的客户是谁，他们可以是组织内的部门（例如人力资源、财务、供应链）或组织外部的客户（例如消费您的仪表板的客户）。此外，还要查看您当前数据湖实施中的问题，如果有的话。例如，您当前可能面临数据中心和运营成本过高，耗尽了预算；或者您当前的硬件已经不再得到支持；或者您当前的架构无法支持数据科学和机器学习等高级场景，从而导致您的业务在竞争激烈的市场中失去优势。一旦与各种客户进行交流并了解他们最关注的问题，您可以确定数据能够帮助解决的一些头等问题的子集。您在数据湖实施中的目标将是解决这些问题，如图3-2所示。

通过与客户沟通并解决他们的关键问题，您的数据湖实施将能够为组织提供有价值的解决方案，并为业务提供所需的洞见和转型机会。

如图3-2所示，您的团队通过与各个消费者的交流，已经确定了10个问题。然而，当您将它们在高严重性与云数据湖在解决这些问题中的有用性之间进行绘制时，您会发现应该优先考虑Problem5、Problem6、Problem8和Problem9，因为它们在严重性和云数据湖的有用性方面都排名较高。

Klodars Corporation是如何定义数据湖目标的呢？

正如我们在第2章中所看到的，Klodars Corporation目前使用传统应用程序，利用操作数据库（如SQL Server）来管理其库存和销售情况，以及使用客户关系管理（CRM）软件（如Salesforce）来管理其客户资料和互动情况。当Klodars Corporation在迅速扩展至华盛顿州和周边州份，并且在线业务增长时，其软件开发负责人Alice向高管们推荐开发数据湖的想法，并且他们热衷于投资这种方法。现在该项目已经启动，Alice开始规划数据湖的实施。她首先采取的第一步是对整个组织的问题进行清点，并列出了在表格3-1中概述的问题列表。

根据这份清单，Alice将她的数据湖实施目标定义如下，并与相关利益相关者进行审查以最终确定目标：

（必备）通过在第75百分位数处查询性能提升50％来支持现有销售和营销仪表板的更好扩展和性能。
（必备）支持在数据湖上进行数据科学模型，通过在产品推荐方面向执行团队进行试点项目的参与来衡量。
（可选）支持更多的数据科学模型在数据湖上，通过销售合作伙伴的下一组场景和营销的影响者推荐来衡量。

规划架构和交付成果

确定数据湖的目标后，下一步是定义架构和交付成果。正如我们在第2章中所见，有多种常用的架构模式，每种模式都有其设计考虑因素，如“设计考虑”一节所述。结合数据湖的目标和组织成熟度等其他因素，确定适合数据湖的正确架构。以下是确定架构时的一些常见考虑因素：

解决方案的成本

确定设置初始成本以及维护解决方案的长期成本，并将其与收益进行权衡。数据湖比数据仓库要便宜得多，但数据仓库更容易启动和运行。

实施所需的时间

在软件开发领域，开发人员和运营时间与金钱一样重要，因此在计算中考虑人力和运营方面，并估计实施解决方案所需的时间和精力。如果您有即将到期的现有硬件，您需要选择一种能在现有硬件支持终止之前实施的模式/架构。

向后兼容性

当您需要将现有数据基础架构迁移到云端时，合理地假设您的云迁移将分阶段进行。您需要确保在将解决方案的某些部分移至云端时，可以保证业务连续性，而不会对现有应用程序和使用者造成太多的中断。如果您有支持仪表板的现有操作数据库，那么确保现有应用程序的兼容性是需要考虑的因素。

组织成熟度

这是大多数营销材料中经常被忽视的因素。当您与云服务提供商或独立软件供应商（ISV）交谈时，请确保讨论组织的当前技能集和数据文化，并了解他们的解决方案如何适应当前状态，同时计划提升组织技能并转变其文化。例如，如果您尚未雇佣数据科学家，那么针对数据科学进行优化的架构并不适合您。

一旦您确定了架构，您可以与客户进行合作，并根据您将支持的优先级列表来定义云数据湖架构的目标。然后，您可以创建一个项目计划，跟踪时间表、交付成果以及整体进展，以实现您的目标。

Klodars Corporation对他们的架构和可交付成果的计划

基于为云数据湖实施定义的目标，Alice和她的团队使用以下指导原则调查了不同的架构选择：

对销售和营销团队使用的现有仪表板最小/没有干扰。
仪表板需要根据数据的增长进行扩展，并解决客户面临的性能问题。
数据科学场景需要作为新平台的一部分进行处理。
包括向高管团队提供产品推荐，向销售团队提供分销商/零售商推荐，以及向营销团队提供影响者推荐。

考虑到仪表板对业务的重要性以及预计的未来增长，新架构需要在接下来的六个月内推出。他们评估了以下云端的架构模式（这与具体的提供者无关）：

云数据仓库

在这种架构模式中，没有涉及云数据湖，主要组件将是云数据仓库。如果您想对云数据仓库有更多了解，请参考“云数据仓库”。尽管这需要实施的时间最短，并且对销售和营销团队的业务分析师来说是一个无缝体验，但数据科学能力有限。因此，这可以作为一个试点，但在场景变得更加复杂（例如引入更多多样化的数据集）时可能会遇到障碍。

现代数据仓库

正如我们在“现代数据仓库架构”中所看到的，这涉及利用云数据湖存储进行数据收集和处理，并使用云数据仓库进行商业智能场景。这需要比云数据仓库更长的时间来实施。然而，数据湖上丰富的数据科学能力将帮助团队专注于试点项目，同时通过数据仓库支持数据分析师。此外，数据湖提供了更便宜的存储方式，用于保存本地数据库的多个历史数据快照。

数据湖仓库

正如我们在“数据湖仓库架构”中所看到的，这涉及利用云数据湖存储进行端到端实现，而无需云数据仓库组件。对于团队来说，这非常有吸引力，因为它支持数据科学和数据分析师场景；然而，他们很快意识到需要对工具支持和端到端自动化进行提升。

团队没有评估数据网格架构，因为他们希望专注于保持端到端实现的中央控制。他们将在项目的下一阶段评估数据网格架构。团队决定采用现代数据仓库架构，因为它提供了与当前架构更顺畅的过渡，同时也支持数据科学。团队还计划在项目的下一阶段，在他们在云上运行后，对数据湖仓库和数据网格架构进行调查研究。

正如图3-3所示，Klodars Corporation的现代数据仓库架构包括以下组件：

云数据湖存储，作为数据的中央存储库。
数据摄取系统，将来自现有来源（如操作数据存储）和新数据来源（如社交媒体）的数据上传到云数据湖中。
数据处理引擎，对云数据湖存储中的数据进行复杂的数据转换处理，生成高价值的数据。
数据科学和机器学习解决方案，由数据科学家用于临时的探索性分析。
云数据仓库，将这些高价值数据提供给商业智能用例和数据分析师。

项目的可交付成果包括以下阶段：

阶段1：

数据摄取：将数据加载到数据湖中。建立自动化流水线，将操作数据库和CRM系统的每日备份存储到数据湖中。保留过去90天的数据。

阶段2：

数据处理：包括两个可以并行运行的阶段：

处理商业智能数据：运行处理流水线，将数据每日刷新到云数据仓库中。通过与销售和营销团队的数据分析师的反馈进行验证。
高级场景：基于操作数据库和CRM系统的数据，开发产品推荐模型，利用数据科学家进行数据分析。

阶段3：

有限发布：在本地部署实施仍在运行时，将数据湖平台发布给销售、营销和高管团队的特定客户。这有助于早期发现问题并根据客户反馈进行迭代。

阶段4：

投入生产：将数据湖发布给Klodars Corporation的所有客户。此时，本地部署和云平台并行运行。

阶段5：

关闭本地仪表盘：一旦云上的数据湖实施成功，将关闭本地分析仪表盘。

实施云数据湖

在这个阶段，根据项目计划来实施架构。这个阶段涉及到选择云提供商和遵循基础设施的最佳实践。由于选择云提供商涉及到更多的因素，超出了技术层面，我们不会在这里详细讨论。在这个阶段的一些重要考虑因素如下：

设置和管理云身份：在云提供商上创建您的身份管理系统是开始使用云的关键步骤。如果您在本地有一个身份管理系统，云提供商允许您将本地的身份与云进行联合。
设置订阅：创建资源（基础设施即服务、平台即服务或软件即服务）需要一个订阅。订阅还有相关的访问控制；您可以将您的云托管身份分配给订阅的特定角色（所有者、贡献者等）。
创建环境：强烈建议为开发（供开发人员测试其代码使用）、预生产（开发人员和部分客户可访问）和生产创建独立的环境。我还建议您为不同的环境使用不同的订阅，以使它们相互隔离。如果您在不同的地区拥有业务，而这些地区有不同的要求，您可以为每个地区创建独立的环境，例如北美或欧洲。
选择服务：云提供商为云数据湖架构提供各种服务（基础设施即服务、平台即服务或软件即服务）。花些时间与云提供商交流，根据机会、业务需求和成本做出正确的选择。
投资于自动化和可观察性：除了实施数据湖本身，确保您具备必要的自动化功能来按需创建和管理资源。考虑到您在云上按使用量付费（而不是一直拥有硬件），自动化将确保您能够按需创建和删除资源，以帮助管理成本。同样，确保您在云上具备日志记录和监控功能，以便监视系统的健康状况。

要获取更多信息，您可以查阅以下顶级云提供商AWS、Microsoft Azure和Google Cloud的入门文档。

在你的数据湖上组织数据

一旦您建立并测试了端到端的基础架构，下一步就是进行数据摄取。在将数据摄取到数据湖之前，确保您有一个组织数据的策略非常重要。就像您设置厨房时，需要知道在哪个橱柜中存放瓷器、锅具和咖啡一样。您会确保锅具更容易拿到灶台附近，而咖啡、糖和奶精则放在一起存放。为了理解数据湖中的数据组织方式，让我们看一下数据在数据湖中的生命周期。

数据的一天

首先，数据以其原始的自然状态从各种来源被摄取到数据湖中。然后，对数据进行清洗和准备，例如应用模式、去重、删除空值以及在某些情况下修复空值为默认值。在数据准备阶段结束时，数据按照数据准备代码定义的表格结构进行组织。接下来，对数据进行聚合、连接和筛选，以提取高价值的数据，这个阶段被称为数据策划。除了按照这个生命周期进行处理的数据外，数据科学家等消费者也可以引入自己的数据集进行探索性分析。

这个生命周期是一个重要的点，因为它标志着不同的模式。在过去几十年中，用于分析的数据加载的最常见模式是ETL：提取、转换和加载。数据从源头提取出来，经过转换以符合特定结构，然后加载到存储（Hadoop文件系统或数据仓库）中。如果在转换过程中丢失了数据的信号，重新从源头检索该信号不是微不足道的，而且在某些情况下是不可能的。此外，随着云基础设施和硅技术的创新，存储成本越来越便宜。数据价值的增加与存储成本的降低相结合，催生了一种新的模式，称为ELT：提取、加载和转换。在这种模式中，数据从源头提取出来，加载到数据湖中，然后再进行数据处理和转换。

数据湖区域

按照数据的生命周期，数据将被组织到数据湖中的不同区域。现在让我们详细了解这些区域。图3-4提供了每个区域的可视化，本节中我们将逐个介绍它们。

数据湖中的数据根据处理阶段和数据中的价值密度可以划分为以下区域：

原始数据（铜）区域

该区域包含从源头获取的数据，处于其自然状态。该区域的数据具有最低的价值密度（即高信噪比），准备经过各种转换以生成有价值的洞察力。

增强数据（银）区域

该区域包含经过转换的原始数据版本，符合业务场景的结构要求。此时，价值密度为低到中等，但对数据遵循模式或结构有一定的保证。

精选数据（金）区域

该区域包含价值密度最高的数据。该区域的数据是通过对增强数据应用转换生成的。

工作区数据区域

该区域为数据湖的消费者提供自己的数据集。对于该数据区域没有特定的保证；可以将其视为在数据湖中预留的草稿区。

现在让我们详细了解这些部分：

原始数据（铜）区域

这是数据湖的一个部分，外部数据首先被存储在这里。在我们讨论的ELT模式中，这是从源头提取并加载到数据湖存储中的数据。数据可以来自各种来源，例如本地系统、社交媒体、外部开放数据集等等。数据可以按计划方式摄入（批量上传）或实时方式摄入（事件）。该区域的数据几乎没有保证、结构、语义和价值。通常情况下，这种摄入通常由一组特定的团队控制，而不是对所有人开放。该区域的数据将按摄入源和数据的时间戳进行组织。在典型的数据湖场景中，大多数数据都与时间相关（例如某一天的Twitter数据源，某一天的服务器日志等）。因此，该区域通常按源进行组织，源内按时间组织；时间结构表示数据的新鲜程度。

丰富的数据（银）区域

原始数据在被摄入到数据湖时并不完全符合特定的结构或格式。正如我们在《关于数据的多样性》中所见，被摄入到数据湖的数据可以是结构化、半结构化或非结构化的。然后，数据经过清洗和处理，以适应表格结构；这个过程被称为数据准备、丰富或烹饪。在这一步骤中通常会发生以下三件关键的事情：

模式定义

模式实质上是数据所遵循的结构定义，即为数据的不同部分赋予意义，使其成为具有列定义的表格结构。

数据清洗

一旦定义了模式，可能会有一些数据部分不符合模式。例如，如果模式指示你的CSV文件的第五个字段是邮政编码，那么这一步骤会确保值符合邮政编码格式（XXXXX或XXXXX-XXXX），如果不符合，则要么删除它，要么填充合法的值（例如从地址中查找邮政编码）。

优化

一旦数据符合表格结构，还需要准备数据以针对最常见的使用模式进行优化。最常见的模式是数据只写一次，读取多次。例如，如果你有一个销售数据库，对该数据的最常见查询往往是针对特定地区的销售信息或随时间变化的趋势。在这一步骤中，数据被转换成一种格式并重新组织，以便对最常见的查询友好。通常选择像Parquet这样的列式格式（在《数据格式》中介绍过）来进行查询优化。

这些数据更广泛地被不同的团队、数据科学家以及在某些情况下还有业务分析师用于更临时的分析。该区域的数据被组织成领域或各种消费者可以理解的单位，并在目录中发布（我们将在《数据治理简介》中详细讨论此内容）。

策划数据（金）区域

策划数据区域是数据湖中价值最高的数据和支撑关键业务仪表板的关键数据集。将该区域中的数据视为数据价值的摘要或总结，以及关键的洞察力。在该区域中，通过执行聚合、过滤、关联来自不同数据集的数据以及其他复杂计算等方式处理数据，从而为解决业务问题提供关键洞察力。该区域的数据使用策划区域的数据作为其来源，有时还会使用其他数据源。鉴于其对业务的广泛影响，该区域的数据在数据质量方面需要符合最高标准。

策划数据主要由业务分析师使用，并为关键业务决策者提供支持的仪表板提供动力。此外，这些数据会发布到目录中，并按业务单元和相关领域进行组织。

工作区或沙盒区（可选）

正如我们所讨论的，原始数据、丰富数据和策划数据区域中的数据大部分由一组精选的数据工程师或数据平台团队进行管理。然而，消费者可能希望带来一些数据，无论是用于探索性分析还是测试。这些数据可以组织到专门为用户配置的单元中（将其视为临时工作区）。此处的数据不受任何特定标准或质量的约束，基本上可以自由使用。

图3-5展示了Klodars公司的数据组织方式。

组织机制

虽然这不是一个强制要求，但按照使用模式来组织数据是一个良好的实践。如我们在“数据湖区域”中讨论的那样，数据在数据湖中经历了特定的生命周期，您可以将数据按照区域进行分组以实现组织。这种组织机制在数据湖中数据和使用量不断增长的情况下非常有用。组织机制有许多优点，包括以下几点：

控制对数据的访问：例如，原始区域中的数据访问通常被限制在数据平台团队，并由您来管理。当新员工加入营销部门时，他们将自动获得对营销业务单元区域中的数据的访问权限。
管理数据保留：例如，当您为用户提供工作区域区域以导入他们自己的数据时，由于数据本身不受数据平台团队的管理，该数据有可能无法受控地增长。数据平台团队可以为特定区域设置数据保留策略，以管理这种无法控制的增长。

主要云提供商的数据湖存储服务提供了不同的方式来组织数据区域。Amazon S3和GCS提供了可以利用的存储桶作为组织数据的单位。Microsoft Azure Data Lake Storage提供了一个本地文件系统，其中存储帐户、容器和文件夹作为数据组织的单位。

数据治理导论

无论您在数据之旅中的哪个阶段，无论是初步尝试还是已经具备成熟的数据湖实施，数据量及其对业务的价值只会增加。正如蜘蛛侠中Ben大叔所说：“伴随巨大的力量而来的是巨大的责任。”让我们来看看管理数据可能面临的一些挑战：

您收集的数据可能包含个人或业务关键信息，例如个人姓名和地址，或者商业机密，如果落入错误的手中，可能对个人或业务造成潜在伤害。像雅虎、斯达伍德万豪酒店、阿里巴巴等巨大企业多年来都不得不处理数据泄露问题。
数据平衡和完整性中的错误可能导致分析结果偏离，从而为用户构建非理想的体验。2016年，微软推出了一款会话式人工智能聊天机器人，由于所学习的数据集，该机器人很快学会了发布种族主义和性别歧视的消息。
随着数据湖中数据的增长和使用量的增加，这些数据集的管理和发现变得极为重要。如果没有这些功能，您的数据湖可能会变成一个数据沼泽。为了更好地理解这一点，想象一下那个杂乱无章的壁橱（或房间、车库或阁楼），在某个时候，您甚至不知道里面有什么，直到搬家时才去接触它。
涉及云数据湖运营时，有越来越多的数据隐私法规，例如《通用数据保护条例》（GDPR）、《加利福尼亚消费者隐私法》（CCPA）等，您需要注意遵守这些法规。

参与数据治理的角色

数据治理是一个统称，指的是确保组织使用的数据安全、可访问、可用和合规的技术、工具和流程。在组织的数据治理中，有四个主要角色。数据治理工具旨在满足其中一个或多个角色的需求。需要注意的是，这些角色不一定是人类用户，也可以是应用程序或服务。此外，同一团队或组织可以扮演一个或多个角色：

数据官员

这个团队主要负责管理数据的定义和要求，确保数据的可信度，并定期进行审计和评审以确保要求得到满足。这涉及到定义和管理数据共享要求、数据保留政策以及数据资产需要满足的合规法规等控制措施。他们设定了数据治理的标准。

数据工程师

这些角色负责实施数据湖架构。他们提供和设置各种服务，管理角色的身份，并建立正确的技术和流程，确保数据和相关洞见具有所需的可信度。换句话说，他们实施和管理基础设施和技术，确保实施符合数据官员定义的要求。他们利用各种工具集来了解数据经历的不同处理阶段，这个过程被称为跟踪数据的谱系，并确保数据的质量和一致性。他们还在审查和审计中提供相关证据和支持材料，起着关键的作用。

数据生产者

这些是数据湖用户的一个群体。顾名思义，数据生产者将数据引入您的数据资产中。这些数据可以是原始数据（从外部和内部来源摄取）、丰富数据（经过准备/处理的表格形式数据）、策划数据（具有高价值洞见的摘要/概要），或由数据科学家生成和使用的临时数据集。数据生产者非常关注确保数据的质量符合一定的标准，具体取决于数据的类型，并希望了解如何在访问管理方面将数据限制或开放给组织其他部分。他们需要遵守数据官员和数据工程师设定的工具和流程，并不试图规避限制措施。

数据消费者

这些是数据湖的另一个用户群体。与其他任何产品一样，只有当有客户使用时，产品才有价值。数据也不例外。无论他们使用仪表板、可查询的表格还是临时数据集，数据消费者是指使用数据或洞见的任何人。数据生产者控制着谁可以使用数据，而数据消费者实际上使用这些数据，要么按原样使用，要么进行进一步处理。例如，在数据策划过程中，一组用户或应用程序最终使用丰富的数据并生成策划的数据。

图3-6提供了与数据资产（在本例中是数据湖）交互的各种角色所关注的一些主要问题的非常简化的概述。为这些不同的角色提供了许多工具和自动化功能，以促进更好的数据治理并遵循最佳实践。话虽如此，您也可以通过手动操作进行数据治理。数据治理可以分为可以通过工具和自动化完成的任务以及通过手动执行的流程来实现。

数据分类

数据治理始终从数据官员开始，他们负责定义可以收集、存储和处理的数据的要求和控制措施。

数据类型指的是组织使用的数据或资产的类型。您的数据湖中的数据需要标记为其中一个或多个数据类型。数据类型本身也被称为信息类型（infotype），它具有与之相关联的单一含义，例如包含名字或邮政编码的数据。这些信息类型被组织成数据类别。例如，姓名和地址属于个人身份信息（PII）数据类别，信用卡号属于财务信息数据类别。

图3-7以一个例子说明了这种层次结构。

策略是适用于数据类别的规则和限制。例如，您的策略可能是消费者的PII数据必须在消费者同意并清楚了解您的组织如何使用这些信息后收集。

如果您的企业处理包含个人身份信息（PII）或财务信息等敏感数据，您将需要遵守由您的组织甚至有时由政府强制执行的政策和法规。您需要向监管机构（制定这些规定的人）证明您已经制定了相应的政策；这通常通过审计来完成。建议您制定这些政策，并以计划的方式记录您的处理过程，以避免在审查和审计期间出现紧急情况。

为确保您的数据符合政策，您的数据湖中的数据需要进行分类，即与类别和类型相关联，以便您可以应用相关的政策。像Amazon Macie这样的云服务利用机器学习来对数据湖中的数据进行自动分类，并处理结构化、非结构化和半结构化数据。

元数据管理、数据目录和数据共享

元数据是指描述存储在数据湖中的数据的格式和字段的技术数据，以及对数据集具有更多业务上下文的其他数据。在本书中，我们将重点关注技术元数据。例如，对于一个员工表，元数据包括描述信息。第一列是名字，它是一个字符串数组，接下来是另一个字符串数组表示姓氏。下一个字段是年龄，它是一个介于15到100之间的整数。

数据目录是存储这些元数据的系统，并可以为组织的其他部门发布。类比一下，在一家有很多书的图书馆中，如果没有目录，你很难找到你想要的书，而目录可以让你通过标题或作者搜索书籍。类似地，数据消费者可以利用数据目录查找他们有权访问的表，可以使用表名或特定关键字段进行搜索。例如，你可以搜索所有关于员工的表。这里需要记住的关键是一个数据目录可以存储来自各种数据源的数据，包括数据湖、数据仓库和任何其他存储系统。图3-8说明了这个概念。

一旦重要的数据集和高价值的洞见对组织可用，可能会有其他消费者，无论是组织内部的消费者，或者在某些情况下，甚至是组织外部的消费者。换句话说，数据就像一种产品，可以与更广泛的受众共享和实现货币化。数据共享是数据治理的一种新兴能力，其中数据湖或数据仓库中的数据集可以与组织内部或外部的受众共享，消费者向数据生产者支付数据访问费用。数据目录使得实现这些场景变得更加容易。

数据访问管理

当我们谈到通过目录和数据共享实现数据可发现性时，我们必须确保适当的角色组具有对适当的数据的访问权限，更重要的是，这些角色没有访问其他数据的权限。数据访问管理是数据治理的一个重要部分，其中有一系列功能让角色在不同层面管理数据，从对存储数据的访问到通过其他应用程序（如数据共享或仓库）对数据的访问。

我想以一种分层的方式解释数据访问管理的概念：

在最内层核心，有对数据本身的访问，这是一个数据湖存储级别的安全模型，帮助您锁定对存储本身的访问。
接下来的层次涉及对运行在数据湖存储之上的计算引擎的访问，可以通过ETL流程、数据仓库或仪表板进行访问。
下一层涉及到云系统级别的边界，它控制着云资源或数据在网络边界上的可见性和可访问性，例如区域访问限制，决定哪些数据需要保留在某个区域内，而哪些数据可以在不同区域之间传输。
最后，您可以使用全面的数据安全工具，例如Apache Ranger，在多个数据存储中应用高级规则和策略（例如被标记为PII的数据只能由人力资源部门访问）。

图3-9说明了这种方法。

数据质量和可观察性

鉴于数据对于运营业务的重要性，数据的质量已经变得与代码的质量一样重要，甚至更重要。无论是导致关键新闻如COVID-19数据被阻断的故障，还是像2017年奥斯卡颁奖典礼上尴尬地宣布《爱乐之城》获奖的错误公告，数据错误都会在下游产生连锁效应。

组织越来越多地依赖于衡量和监控数据质量作为最佳实践，这也是数据湖领域一个不断增长的投资领域。虽然这超出了本书的范围，但我建议您查阅其他关于数据质量和数据可观察性的资源，以深入了解相关概念，并了解可以用于数据质量和可观察性解决方案的可用工具集。在本节中，我将概述数据可观察性的基本概念和方法。

在《数据质量基础》一书中，Barr Moses、Lior Gavish和Molly Vorwerck（O'Reilly）给出了对数据可观察性的五个支柱的简明定义，即确保数据湖架构中数据质量的度量属性。这是思考数据可观察性的一个很好的起点。

特别是在云数据湖架构中，有一个不同的组件集将数据加载到数据湖存储中，并处理数据以生成高价值的洞察力，还有另一个组件集绘制仪表板。一个组件并不完全意识到其他组件的存在。因此，在数据湖中采用以数据为中心的方法建立这种共同理解，通过数据可观察性至关重要。

以下是从该书中改写的数据可观察性的五个支柱：

新鲜度新鲜度是数据的时效性指标。数据最后一次刷新是什么时候？举个例子，在前几章中我们讨论了一种常见模式，即将操作性数据存储中的数据每天上传到数据湖中。新鲜度属性表示此次更新的新鲜程度，因此如果昨晚的数据上传失败，那么您就清楚地知道报告是基于两天前的数据。
分布分布是数据的可接受范围或值的指标。这让您可以为数据定义可接受的范围。通常，当仪表板中的图表看起来异常时，您会想知道数据是不是在突出显示一个真正的问题，或者数据只是简单地错误或损坏了。确保对数据有可接受的范围有助于您知道当数据超出或低于可接受范围时，您遇到的是数据问题而不是趋势上的实际问题。例如，当最近的销售数据尚未到达时，您可能会看到销售额为0美元，而实际上几乎不可能没有销售。同样，如果您看到销售额突然增加了500%，与正常范围相比，您会知道您需要调查一下这是一个真正值得庆祝的原因，还是可能存在一些重复处理导致销售数据计算了两次。
容量容量是数据可接受大小的指标。类似于分布，这指示数据大小的可接受级别，而超出此范围的任何数据可能表明数据水平有问题。例如，当您的数据表通常有10,000行时，经过一天的处理后，您看到只有10行或5百万行，那么您就会得到进一步调查的线索。
架构如前所述，架构指的是数据的结构和语义定义的描述。如果上游组件更改了架构，那么一个或多个字段可能会消失，从而破坏下游场景。跟踪架构的变化有助于我们理解其对下游组件的影响，并将变化隔离到影响范围内。
血统简单来说，血统可以描述为数据的生产者和消费者之间的依赖关系图。对于给定的数据集，数据血统描述了数据是如何生成的以及哪些组件使用它。当出现错误时，数据血统提供了可以追溯到需要调查的其他组件的线索。

建议组织投资于自动化来衡量这些支柱，以确保数据具有可接受的质量，并且数据湖可以提供服务级别协议（SLAs），以确保数据符合标准的程度。

数据治理在Klodars公司的应用情况

Alice和她的团队了解数据治理对于他们的数据平台架构的重要性，并着手进行以下改变：

他们利用基于开源Apache Atlas的数据目录，对其丰富和策划区域中的数据进行整理和发布元数据。 - 他们对销售和客户表中的数据进行分类，包括PII（个人身份信息）、财务信息等，并确保数据目录中有关于这些数据分类的信息。
考虑到他们的业务场景不需要实际的PII信息，他们编写了一个PII清除程序，以确保PII数据被屏蔽（存储的是该值的唯一哈希值，而不是明文值）。结果是，数据分析师仍然可以查看关于唯一用户的信息，而无需查看其个人信息。
从安全和访问控制的角度来看，他们进行了以下操作：

他们实施了数据湖存储安全，以便只有平台团队可以访问原始数据，而业务分析师和数据科学家只能以只读方式访问丰富的数据和策划数据集。
数据科学家和业务分析师对为他们分配的工作空间具有读写权限，但除非他们明确选择共享，否则不能查看其他用户的工作空间。
他们确保产品团队和高管团队可以访问仪表板，而数据科学家可以访问所有的数据科学计算框架。数据摄取流水线和数据准备流水线严格受到数据工程团队的控制。
他们实施了一个数据治理解决方案，该解决方案包括数据目录以及跨数据湖和数据仓库数据的策略和访问管理。

图3-10展示了Klodars公司实施的数据治理情况。

数据治理总结

将所有这些概念综合起来，我将总结数据治理的方法，作为一系列步骤，可帮助您在数据湖的客户中建立对数据的信任：

了解数据治理政策，包括数据官员的专业知识以及数据生产者和数据消费者的需求。这些需求指导数据工程师实施数据治理。
理解并对数据湖中的数据进行分类，确保您知道哪些数据集适用于哪些政策。
构建数据目录，管理元数据，帮助理解和发现可用的数据集。这使得数据生产者和消费者可以更轻松地发布和查找可用的数据集。这还帮助数据工程师实施数据访问和治理政策，并使数据官员能够审核和审查数据集以确保合规性。您还可以利用数据共享功能来控制和管理数据的共享方式。
在不同层面上管理数据访问，包括数据层、计算引擎层和网络层，并设置定制的自动化数据策略，以确保控制和限制数据访问，以符合访问政策要求。
投资于适当的数据可观测性水平，确保您有可靠的监控工具，帮助识别和调试数据质量问题。

通过采取这些步骤，您可以建立与数据湖的客户对数据的信任，并确保数据的质量、安全和合规性。

管理数据湖成本

云数据湖架构的最大价值主张之一是降低成本。以下是实现较低成本的主要驱动因素：

无需维护数据中心和设备维护成本——由云服务提供商负责处理。
云上的按使用付费模式，您只需为实际消耗的资源付费，而不必维持一直运行的硬件。
解耦的计算和存储，使您能够独立扩展计算和存储，从而确保较大的存储需求不会导致相应的存储成本增加。

这样，您可以在数据湖上引入更多数据并启用更多场景，而不会造成成本激增。虽然数据湖上的单位成本较低，但也有一些因素会增加数据湖成本，您应该了解这些因素，以便在实施过程中平衡业务目标：

云服务提供较低的成本，因为您只需为实际消耗付费。然而，这意味着您需要有按需运行的云资源，并在不使用时关闭它们。如果您不管理云资源的按需预配和关闭，可能会导致它们一直运行，这种消费模型可能不适用于您的情况。
正如我们之前所见，云数据湖架构具有计算和存储的分离设计，它优化了成本，因为您可以根据需要独立扩展计算和存储。然而，这种设计还需要注意数据在服务之间传输时的事务成本，例如计算与存储服务之间的交互成本。
在云架构中，云资源在同一地区内按服务之间的交易没有网络成本。类似地，将数据从其他来源（例如您的本地系统）传入云中也没有成本。然而，当您在不同地区之间传输数据或将数据从云传出（从云到您的本地系统等）时，将会产生网络成本。
由于数据湖存储成本较低，您有机会引入各种类型的数据，即使您目前没有即时使用它的计划。然而，这可能导致数据无法受控地增长，使数据湖变成了数据沼泽，从而增加了成本。
云服务提供了丰富的数据管理、数据持久性和性能功能。当选择这些云服务功能时，如果选择不合理，可能会增加成本。

在本节中，我们将通过了解云交互的工作方式以及它们对成本的影响，从更广泛的角度来看这些因素。我们还将探讨如何通过仔细的设计考虑来优化成本。

解密云上数据湖的成本

云上数据湖的关键组件主要包括以下几个方面：

数据存储

数据湖存储或数据仓库，用于存储和组织数据。这里的计费模型主要包括两个关键要素：存储的数据量和事务的成本。

计算引擎

用于处理和转换数据的服务，即计算引擎。这可以是大数据框架如Spark引擎的IaaS，也可以是SaaS。这里的成本组成部分主要与计算资源的利用相关，比如每个计算单元的价格（由计算引擎定义），根据使用的CPU和内存量以及每个核心每小时的利用率。

软件成本

您需要支付订阅费用（通常是每月）来使用软件。

网络成本

数据在网络上的传输成本，特别是跨区域传输或从云端传出的数据（出口成本）。价格通常按传输的数据量（每千兆字节）计算。

图3-11以数据湖架构为背景，说明了这些成本的关系。

这些成本构成要素会以不同的方式呈现，影响到您的数据湖的总成本。例如，尽管您知道自己支付的是存储费用，但确切的费用取决于您如何设计存储系统。以下是一些影响可变存储成本的因素：

存储层级

不同层级的存储具有不同的成本。例如，热/标准层级比存档层级的静态数据成本更高，但对于事务来说成本较低。因此，如果数据需要频繁的事务处理，最好将其存储在标准层级中；对于冷存储（仅用于数据保留目的而没有事务处理，比如需要满足保留策略的数据），可以选择存档层级。

数据保护和持久性特性

数据保护特性（如版本控制和备份）以及冗余存储特性（如跨区域复制）为数据提供更高的持久性，但同时也会增加额外副本的费用。鉴于数据湖中的所有数据并非都是相同重要性，最好将这些特性用于高价值数据。

事务成本

需要特别注意两种具体的事务成本：与跨区域出口或从云端传输到本地系统相关的任何网络成本，以及在不同服务之间传输数据的事务成本。对于存储事务，事务成本是根据事务数量计算的，因此使用许多小文件（例如1 KB）传输相同数据量（例如1 GB）的成本将高于传输较大文件（几百兆字节）。

了解云上数据湖系统成本的这些关键因素对于根据您的需求优化成本是必要的。

数据湖成本策略

制定良好的数据湖成本策略始于对业务需求、架构、数据和最重要的客户的理解。图3-12显示了您需要了解的关于数据湖的关键因素。

数据湖环境和相关成本

在你的数据湖架构中，就像在你的编码环境中一样，存在着不同的环境：开发环境供数据开发人员使用，预生产环境用于端到端测试，生产环境用于支持你的客户。你需要了解这些环境的使用情况和你承诺的服务级别协议（SLA），以便为它们配置适当的配置水平。

例如，在开发环境中，由于运行的工作负载是为了验证功能，可能不需要非常强大的计算核心。你的压力测试环境可能需要很多计算核心，因为你正在推动系统的极限，但你的压力测试可能是每周运行一次，并不需要一直保持运行。你的生产环境需要满足客户的SLA，不能在可用性或性能方面妥协。

同样，了解你的作业的性质决定了哪些环境需要一直运行，哪些可以按需生成。例如，数据科学家使用的笔记本集群可以按需启动，而用于支持关键业务仪表板的集群需要一直运行。对于按需集群，使用自动化可以帮助按需启动和关闭资源。自动化对于按需生成合成数据以满足你的用例也非常有用，而不是存储数据。

基于数据的成本策略

你的数据湖中并非所有的数据都是等价的，了解数据的价值、可重现性和消费模式对于优化数据成本非常重要：

云数据湖存储解决方案提供预留选项，如果你能承诺一定大小的数据（例如，至少100 TB），你将获得更低的数据价格。如果有意义，可以考虑这个选项。
云数据湖存储系统提供不同层次的数据存储。需要频繁交易的数据称为热数据，而需要存储但不需要频繁交易的数据称为冷数据。对于冷数据，使用成本更低的归档层进行存储，但交易成本较高。归档层还有一个最小保留期，需要注意。对于需要频繁交易的数据，使用标准层进行存储。
云数据湖存储系统还提供高数据耐用性功能，例如版本控制：存储多个数据副本，以防止数据损坏，可以将数据复制到多个区域以应对灾难，可以将数据存储在硬化备份系统中以提供数据保护。这些功能非常适用于关键数据集，但对于非关键数据集来说并非必需，因为你可以容忍数据损坏或删除。
云数据存储系统具有数据保留策略，你可以实施这些策略，以便数据在一定期限后自动删除。通常的做法是从各个来源每天、每周或者其他你喜欢的时间间隔中拍摄数据快照，然后将其加载到数据湖中。这可能会导致成本飙升，并使你的数据湖变成一个数据沼泽。根据数据的生命周期设置保留策略可以确保你的数据湖保持整洁。

交易和对成本的影响

交易成本，无论是网络出口成本还是数据存储交易成本，在大多数情况下都会让数据湖的使用者感到意外，并且经常被忽视。问题在于，这些交易成本也是最难建模的。您需要关注两个因素来了解和优化交易成本：

交易数量
数据传输量

了解和优化交易成本的最佳方式是运行一个规模化的概念验证（PoC），以代表您的生产工作负载。同时，确保避免一些反模式，比如小文件，最好将它们设置为每个文件至少几百兆字节。除了节省成本外，这还可以提高数据湖解决方案的可伸缩性和性能。我们将在第四章中对此进行更详细的讨论。虽然这对于数据湖中的所有数据可能并非都可行，但您可以针对丰富和策划区域的数据来解决这个问题。例如，物联网数据往往只有几个字节或几千字节，并存储在原始数据湖区域中。然而，在数据准备过程中，有意识地将这些数据聚合到一个更大的文件中以优化交易。

总结

在本章中，我们深入探讨了云数据湖的实施细节。首先，我们介绍了如何开始规划云数据湖的实施。然后，我们讨论了数据湖的核心——数据：根据数据的自然生命周期，组织和管理数据的策略。接下来，我们概述了数据治理，以帮助管理数据湖中的数据的可发现性、访问和共享限制。最后，我们讨论了影响数据湖成本的因素，并制定了优化成本的策略。我在本章的目标是帮助您建立对设计数据湖架构的基本概念的理解。有了这种理解，您将能够通过选择适合您需求的正确云服务并使用正确的配置来设计数据湖架构。如果您不知道正确的配置是什么，请参考本章，并将您的要求传达给云服务提供商或ISV。在接下来的两章中，我将分别讨论构建可伸缩性和性能的数据湖的概念和原则。