《云数据湖》第二章：云上的大数据架构-灵析社区

攻城狮无远

第二章 云上的大数据架构

大数据可能意味着更多的信息，但也意味着更多的虚假信息。 ---纳西姆·塔勒布

正如我们在第1章中学到的那样，关于云数据湖有两个关键要点，为本章奠定了基础：

  • 数据湖方法从存储和处理任何类型的数据开始，无论数据的来源、大小或结构如何，从而使组织能够从许多不同的数据源中提取高价值洞察力，这些数据具有可变的价值密度（即信噪比）。
  • 在云上构建您的数据湖涉及到一种解聚架构，您将不同的IaaS、PaaS和SaaS组件组合在一起。

重要的是要记住，在构建云数据湖解决方案时，您还有很多架构选项，每种架构都有其独特的优势。这篇关于Future.com的文章提供了现代数据架构的综合概述。在本章中，我们将深入探讨一些常见的架构模式，了解它们是什么以及它们各自的优势如何适用于一个名为Klodars Corporation的虚构组织。

为什么Klodars Corporation选择迁移到云端

Klodars Corporation是一家在太平洋西北地区销售雨具和其他用品的蓬勃发展的公司。其业务的快速增长推动了其迁移到云端的原因如下：

  1. 在本地系统上运行的数据库无法再与业务的快速增长相适应。
  2. 随着业务的增长，团队也在扩大。销售和市场团队发现他们的应用程序变得越来越慢，有时甚至会超时，这是因为同时使用系统的用户数量增加。
  3. 市场部门希望在社交媒体上更好地定位其营销活动，并正在探索利用影响力人物的想法，但不知道从何处开始或如何进行。
  4. 销售部门无法迅速扩大与分布在三个州的客户的合作，因此很难确定首先要与哪种零售客户和批发分销商合作。
  5. 投资者对业务增长表示赞赏，并询问首席执行官如何扩展Klodars Corporation的业务范围。首席执行官需要制定扩展战略。

软件开发团队的积极领导者Alice向Klodars Corporation的首席执行官和首席技术官提出了一个想法，即探索云计算，并了解其他企业如何利用数据湖方法解决他们所面临的挑战。她还收集了一些数据，展示了云数据湖方法可以带来的机遇，包括以下内容：

  • 云计算可以根据公司不断增长的需求进行弹性扩展，由于按消耗付费，因此不需要过度配置硬件以预算应对高峰季节，并且硬件在其他时间不需要闲置。
  • 基于云的数据湖和数据仓库可以进行扩展，以支持不断增长的并发用户数量。
  • 云数据湖提供了处理来自各种来源的数据的工具和服务，例如网站点击流、零售分析、社交媒体信息，甚至天气数据，因此公司可以更好地了解其营销活动。

Klodars Corporation可以雇佣数据分析师和数据科学家来处理市场趋势，以帮助提供有价值的信号，从而协助其扩展战略。
首席执行官对这种方法完全认同，并希望尝试云数据湖解决方案。在公司的发展过程中，保持现有业务的运行非常重要，同时开始尝试云计算方法。让我们看看不同的云架构如何为Klodars Corporation带来独特的优势，并帮助满足其快速增长和扩展带来的需求。

云数据湖架构的基本原理

在部署云数据湖架构之前，重要的是要了解构成云数据湖架构基础并作为构建模块的四个关键组件。这些组件包括：

  • 数据本身
  • 数据湖存储
  • 处理数据的大数据分析引擎
  • 云数据仓库

对于数据的多样性需要提一下

我们已经提到数据湖支持各种类型的数据，但是这种多样性实际上指的是什么呢？让我们以之前提到的数据为例，具体是库存和销售数据集。从逻辑上讲，这些数据是表格化的，也就是由行和列组成，可以在表格中表示。然而，实际上，这些表格数据的表示方式取决于生成数据的源头。大体上来说，在大数据处理中，有三个广泛的数据类别：

结构化数据

这是一组具有定义结构（行和列）并且遵循严格预定义模式的格式。一个经典的例子是关系数据库（如SQL）中的数据，它看起来像图2-1所示。数据存储在专门定制的二进制格式中，用于关系数据库，并经过优化以存储表格数据（以行和列组织的数据）。这些格式是专有的，为特定系统量身定制。数据的消费者，无论是用户还是应用程序，都了解这个结构和模式，并依赖它们编写他们的应用程序。不符合规则的数据将被丢弃，不会存储在数据库中。关系数据库引擎还将这些数据存储在经过优化的二进制格式中，以便高效存储和处理。

半结构化数据

这是一组格式，其中存在一定的结构，但它的定义比较宽松，如果需要的话，可以灵活地自定义结构。JSON和XML就是半结构化数据的示例。图2-2展示了销售商品ID的半结构化数据的表示形式。半结构化数据格式的强大之处在于其灵活性。一旦你开始设计一个模式，然后确定需要一些额外的数据，你可以添加带有额外字段的数据，而不会违反任何结构的限制。读取数据的现有引擎将继续正常工作，而新的引擎可以包含新字段。同样，当不同的源发送类似的数据（例如，销售点系统和网站遥测都可以发送销售信息），你可以利用灵活的模式支持这些多个来源。

非结构化数据

这指的是没有对数据存储方式施加任何限制的格式，可以是类似社交媒体帖子上的评论这样简单的自由形式备注，也可以是复杂的MPEG4视频或PDF文档。非结构化数据可能是最难处理的格式，因为它需要定制编写的解析器才能理解并从数据中提取正确的信息。与此同时，从一般用途的对象存储角度来看，非结构化数据可能是最容易存储的格式，因为它没有任何限制。例如，想象一下社交媒体帖子中的图片，卖家可以为商品添加标签，并在有人购买该商品后添加另一个标签表示已售出。处理引擎需要处理图像以了解已售出的商品，然后处理标签以了解价格和购买者是谁。虽然这并非不可能，但需要花费大量的工作来理解数据，并且质量较低，因为它依赖于人工标记。然而，这扩大了灵活性的视野，可以用于开展各种销售渠道。例如，你可以编写一个引擎来处理社交媒体中的图片，以了解在给定地区以何种价格由哪个房地产经纪人出售的房屋，如图2-3所示。

云数据湖存储

云数据湖存储的非常简单的定义是一种作为云服务提供的服务，可作为各种数据（结构化、非结构化和半结构化）的中央存储库，并能支持大规模的数据和事务。当我说“大规模”时，可以想象一个支持存储数百PB的数据和每秒数十万个事务的存储系统，并且可以在数据和事务继续增长时实现弹性扩展。在大多数公共云服务提供中，数据湖存储作为PaaS服务提供，也称为对象存储服务。数据湖存储服务提供丰富的数据管理功能，例如分层存储（不同层级的成本不同，可以将很少使用的数据移动到成本较低的层级）、具有不同程度复制的高可用性和灾难恢复以及丰富的安全模型，允许管理员控制各种消费者的访问权限。让我们来看一些最受欢迎的云数据湖存储服务提供：

Amazon S3（简单存储服务）

亚马逊提供的S3是一个大规模的对象存储服务，建议将其作为构建基于AWS的数据湖架构的存储解决方案。在S3中存储的实体（结构化和非结构化数据集）被称为对象，对象被组织到称为存储桶的容器中。S3还允许用户通过使用共同前缀（将其视为虚拟目录）将对象组合在一起进行组织。管理员可以通过在存储桶或前缀级别应用访问策略来控制对S3的访问权限。此外，数据操作员可以向对象添加标签，这些标签实际上是键值对，可以用作标签或标签，让您可以通过指定标签检索对象。亚马逊S3还提供了丰富的数据管理功能，以管理数据的成本，并增加安全性保证。要了解有关S3的更多信息，您可以访问文档页面。

Azure Data Lake Storage（ADLS）

ADLS是Microsoft Azure提供的一种存储解决方案，它在其通用对象存储服务（Azure Blob存储）上提供了一个带有层次化命名空间的本地文件系统。根据ADLS产品网站的介绍，ADLS是一个用于摄取、处理和可视化的单一存储平台，支持最常见的分析框架。您可以创建一个ADLS账户，其中将在“启用层次化命名空间”选项中选择是。ADLS提供了一个称为容器的组织单元，以及具有目录和文件来组织数据的本地文件系统。您可以访问文档页面以了解有关ADLS的更多信息。

Google Cloud Storage（GCS）

GCS是由GCP提供的对象存储服务，并被推荐作为数据湖存储解决方案。类似于S3，Google中的数据被称为对象，并以存储桶进行组织。您可以在文档页面上了解更多关于GCS的信息。

云数据存储服务具有从各种来源加载数据的能力，包括本地存储解决方案，并与实时数据摄取服务集成，该服务连接到诸如物联网传感器之类的数据源。它们还与支持传统应用程序的本地系统和服务集成。此外，有许多数据处理引擎可以处理存储在数据湖存储服务中的数据。这些数据处理引擎属于多个类别：

  • 公共云提供的PaaS解决方案（例如，AWS的EMR，Azure的HDInsight和Azure Synapse Analytics，以及GCP的Dataproc）
  • 其他软件公司开发的PaaS解决方案，例如Databricks、Dremio、Talend、Informatica和Cloudera
  • SaaS解决方案，例如Microsoft Power BI、Tableau和Looker

您还可以预配IaaS解决方案，如虚拟机（VMs），并运行自己的软件发行版，如Apache Spark，来查询数据湖。 需要注意的一个重要点是，在数据湖架构中，计算和存储是分离的，您可以在数据湖中运行一个或多个处理引擎，而无需移动数据。一些流行的数据仓库包括Amazon Redshift、Google BigQuery和Snowflake Data Cloud。这些数据仓库既提供计算能力又提供存储空间，虽然某些情况下数据仓库支持查询存储在独立数据湖存储中的数据，但最常见的用例是使用最优化的路径：查询以专有数据格式存储在数据仓库中的数据。最近，数据仓库开始支持开放数据格式，如Apache Iceberg，这是一个非常有前景的趋势，它在方向上支持数据湖仓库架构。在本章中，我们还将更详细地介绍数据湖仓库架构。

大数据分析引擎

到目前为止，我们了解到大数据分析是对结构化、半结构化和非结构化数据进行处理。现在让我们来探索一下这个处理过程的实际情况。当我们谈论在数据湖上进行大数据分析时，所进行的处理很可能是下面描述的其中一种，或者是它们的派生形式之一。

MapReduce

大数据和分析处理的起源可以追溯到一个改变我们工作方式的事物的出现：搜索引擎。搜索引擎主要通过从互联网上的所有来源抓取文本数据并构建一个巨大的关键字索引来工作。当用户搜索一个关键字时，搜索引擎会根据这个索引对数据进行排名，并向用户提供一个有序的结果集。虽然搜索引擎的设计本身需要一本书来详细解释，我们在这里不会详细讨论，但它们证明了需要处理大量数据并将其简化为可搜索的索引的需求，从而诞生了一个称为MapReduce的编程模型。

MapReduce本质上是一个编程模型及其相关实现，它接受一组键值对作为输入，并生成一组键值对作为输出。听起来很简单，不是吗？问题在于规模——在包含数百万条记录的数据集上进行这种转换。正如Jeffrey Dean和Sanjay Ghemawat在他们的论文《MapReduce: Simplified Data Processing on Large Clusters》中所描述的，MapReduce有两个阶段，顾名思义。在映射阶段，数据按照键进行组织，并使用逻辑将相似的值归为一组，生成中间的键值对。规约阶段处理这些相似的数据集，生成一组经过筛选的结果，同样是键值对。

举个例子，让我们以Twitter数据为例，目标是了解在一组大型Feed中每个用户被提及的次数（图2-4中显示了一个较小的样本）。这里有一组计算单元在工作：多个工作单元在分配给它们的数据集上运行，并且有一个主要的编排单元负责协调工作单元之间的操作。计算单元可以是虚拟机、进程或线程，具体取决于实现方式。将大量的Twitter数据Feed分解成较小的集合（在这个例子中是一个Feed）并分配给工作单元，在这里它们将提及映射为计数，并生成一组输出的键值对，如图2-4所示。然后将这些数据值发送给另一组工作单元进行规约，以生成每个用户的提及次数。主要优势在于，这种编程模型可以将大型数据集有效地分布在一组工作单元中，并具有可预测的分布机制。

Apache Hadoop

Apache是一个开源组织，他们有一个名为Apache Nutch的开源网络搜索项目，即使在今天仍在使用。2005年，作为Apache Nutch的一部分，Doug Cutting和Mike Cafarella创建了Apache Hadoop，这是一套用于分布式处理大型数据集的工具、库和组件，其核心处理逻辑使用了MapReduce。Apache Hadoop由四个主要组件组成：

Hadoop通用模块：支持其他模块的通用库集合

Hadoop分布式文件系统（HDFS） ：用于大型数据集的分布式存储系统

Hadoop MapReduce ：用于大规模处理大型数据集的编程模型和实现

Hadoop YARN ：用于作业调度和资源管理的框架，可以在机群中分发工作和数据

Hadoop奠定了一个坚实的基础，孕育了许多其他开源项目，例如Apache Hive、Apache Pig、Apache Storm和Apache Mahout，用于构建更多分布式大数据处理的框架和编程模型。这里提供了所有Hadoop项目和工具的详细索引，示例见图2-5中的Hadoop生态系统表格。


Hadoop使大数据处理生态系统商品化，而像Hortonworks和Cloudera这样的供应商销售他们的Hadoop分发版本，客户可以在本地或云上安装。公共云提供商还提供基于Hadoop的处理的打包版本作为PaaS解决方案，例如AWS的Elastic MapReduce（EMR）和Microsoft Azure的HDInsight。在所有这些不同的Hadoop提供中，你可能会想知道该选择哪个。虽然有很多原因，比如对供应商的熟悉程度、销售和市场关系等，但几个技术关键因素对客户的选择起到了重要作用：

  • 在混合环境下运行的客户，即既有本地部署又有云部署，或者在多云环境下运行的客户，会选择由独立软件供应商（ISV）提供的Hadoop解决方案，如Cloudera或Hortonworks，以便其实现在所有环境中都能工作。
  • 更喜欢将其大数据平台与其他原生云服务紧密集成的客户，选择公共云提供商（如AWS、Azure和GCP）提供的解决方案。
  • 愿意投资于强大技术团队并希望节省供应商成本的客户，会通过分叉开源存储库并构建自己的平台来创建自己的Hadoop版本。

这在其他开源解决方案（如Apache Spark）中也同样适用。 可以说，Hadoop通过提供一套综合的工具为大数据处理奠定了数据湖架构的基础，包括用于批处理的MapReduce、用于实时处理的Apache Storm以及用于在Hadoop架构上查询数据的Apache Hive。

Apache Spark

Apache Spark孵化于加州大学伯克利分校的AMPLab，专注于大数据分析。Apache Spark的目标是提供一种灵活的编程模型，具有MapReduce的容错性和规模，用于分布式数据处理，同时支持更广泛的应用程序，如依赖于数据的迭代处理和实时处理的机器学习，以提供即时见解。

与Hadoop类似，Spark使用底层存储层；然而，并没有规定必须使用HDFS存储；Spark支持云对象存储服务甚至本地存储。同样，Spark使用集群管理器，也支持各种选项，如从Hadoop诞生的YARN和同样孵化于加州大学伯克利分校的Apache Mesos。最近，随着Kubernetes和容器（简单定义为包含代码、应用程序运行时和运行代码所需的其他组件的即用软件包）在云原生开发中的日益流行，Spark在Kubernetes上也得到了广泛应用。Spark的关键区别在于Spark核心引擎，它构建在作为弹性分布式数据集（RDDs）的数据集的基本抽象上，而无需将中间数据集存储到持久性存储中，仍然保持容错性。这种模型极大地提高了基于Spark的应用程序的性能，并为批处理、交互式查询（Spark SQL）、数据科学（MLlib）、实时处理（Spark Streaming）和最近引入的图处理（GraphX）提供了统一的编程模型。Apache Spark的易用性和日益增长的认可度帮助在各个行业中将大数据处理商品化。你可以使用Spark作为独立分发版，也可以利用公共云提供商提供的Spark（如Amazon EMR、Azure Synapse Analytics或Google Cloud Dataproc），或者使用由Spark的发明者创建的Databricks等软件提供商提供的Spark。

图2-6演示了Spark的各种技术组件以及它们如何相互层叠，以提供在机器学习、实时和批处理流式处理中的一致的编程模型。

实时流处理管道

实时流处理指的是对数据进行摄取、处理和消费，重点是追求速度，接近实时的结果。想象一下，当你在旅行时，你从你喜爱的美食评论应用程序收到了关于附近餐厅的实时通知，你可以去探索。这里有一个实时处理管道在工作，它从你的移动设备中获取你的位置信息，并将其与你的个人资料和其他相关数据结合起来，实时提供个性化的推荐。另一个例子是你手机上的导航应用在你通常的路线上有交通拥堵时建议你选择另一条路。在这种情况下，有一个实时处理管道将实时交通数据与地图结合起来，为你的目的地提供最佳路线建议。

实时流处理管道涉及到从源头以非常高的速率到达的数据，换句话说，这些数据就像雨水或瀑布一样源源不断地流入系统中。这些数据可能是不断从诸如GPS之类的源头实时流入的，或者可能是由物联网传感器（如家庭自动化系统或工业设备）发出的事件。这些数据往往非常小，通常为几千字节（KB）。 实时流处理管道的处理部分涉及处理实时流数据，有时将其与非实时数据结合，重点是低延迟，通常在毫秒级。实时处理应用程序的典型场景是提供接近实时的洞察力，以便消费者能够迅速采取行动，例如当系统处理系统日志并在出现问题时实时发出警报的系统。

实时数据处理技术在处理高速率和吞吐量的数据进入系统时考虑以下几个方面：

传递保证

实时流处理技术提供传递保证，确定实时数据的处理方式。至少一次保证确保数据将至少被处理一次，可能会多次处理以应对故障。至多一次保证确保数据将最多被处理一次，避免重复处理。精确一次保证确保数据将被精确处理一次，这是非常理想的，但也非常难以实现。

容错性

实时流处理技术需要确保在集群或底层基础设施发生故障时具有弹性，并能够从故障出现的地方继续处理。

状态处理

实时流处理框架提供状态管理功能，记录已处理的消息数量或最后处理的消息是什么。

实时流数据可以以多种方式进行消费：如展示社交媒体趋势图的可视化、安全事件检测等警报系统，甚至基于浏览模式的实时推荐等智能应用行为。

图2-7展示了实时流数据管道的架构。构建实时数据管道的多种技术也可供选择。Apache Kafka是一个重要的技术，用于实时流数据的摄取和存储，具有高吞吐量和可扩展性。Amazon Kinesis和Azure Event Hub是基于Apache Kafka构建的云原生PaaS解决方案。Apache Storm和Apache Flink是流行的开源技术，提供实时数据处理能力。Apache Kafka还提供Kafka Streams用于实时流处理。

云数仓

云数据仓库是在公共云上以托管服务（PaaS）形式提供的企业数据仓库，具有针对数据摄取、分析处理和商业智能分析的优化集成。商业智能分析指支持可视化和交互式查询功能的工具。云数据仓库的提供旨在通过将基础架构从用户中抽象出来，弹性扩展以满足客户不断增长的需求，并承诺比传统的本地数据仓库具有更快的性能和更低的拥有成本。让我们来看一些最受欢迎的云数据仓库提供商：

Amazon Redshift

Amazon Redshift是公共云上首个受欢迎的云数据仓库提供商。您可以配置一个Redshift集群，并指定所需的计算节点数量。根据产品文档，该集群可以支持PB级的数据。您可以使用流行的查询语言PostgreSQL来查询Redshift集群中的数据。要了解更多关于Redshift的信息，您可以访问产品页面。Redshift还宣布了在不复制数据的情况下在不同的Redshift集群之间共享数据的能力，以促进数据和洞察力的共享。

Google BigQuery

与Redshift不同，您在Google BigQuery中无需配置数据仓库集群，它是一个完全无服务器、高度可扩展的数据仓库解决方案，完全将集群管理的细节与客户隔离开来。此外，BigQuery还具有BigQuery Omni等功能，允许您在其他云（如AWS和Azure）上使用BigQuery计算服务。

Azure Synapse

Analytics Azure Synapse Analytics是在Microsoft Azure上提供的统一分析平台。与Redshift类似，您可以配置一个数据仓库集群，并为您的场景指定所需的节点数量。您还可以在同一体验中配置Spark集群以进行分析场景。此外，您还可以在SQL或Spark中运行无服务器查询。使用无服务器查询，您可以简单地提交作业而无需配置集群，类似于BigQuery。Azure Synapse Analytics还在同一体验中与其他Azure服务集成，如Azure Machine Learning、Azure Cognitive Services和Power BI。

Snowflake Data Cloud

Snowflake数据仓库是一种托管的数据仓库解决方案，可在所有公共云（AWS、Amazon和GCP）上使用。Snowflake被设计为一个真正可扩展的解决方案，它作为一个单一服务提供，而实现则在分离的计算和存储架构上运行，使其在计算或存储维度上高度可扩展，而不会增加成本。这种分离还可以让您启动不同的虚拟仓库，这些仓库可以访问相同的数据，为不同的查询场景提供隔离。Snowflake还提供表级和对象级的数据共享给其他Snowflake账户。

在本节中，我对云数据湖架构的四个组成部分进行了高级概述：数据、数据湖存储、计算引擎和云数据仓库。我还概述了常用的服务和技术，并提供了深入了解的链接。在下一节中，我将介绍代表这些构建块可以组装成解决方案的不同云数据湖架构。在我们阅读本书的同时，数据湖和数据仓库的提供商正在快速创新，模糊了它们之间的界限。我们将在数据湖仓库架构模式中进一步讨论这一点。

云数据湖架构中的数据可以用于多种目的。然而，有两种常见的组织中的消费模式：

商业智能

数据被商业智能分析师用于创建仪表板或处理交互式查询，以回答明确定义的关键业务问题，并处理高度结构化的数据。

数据科学和机器学习

数据被数据科学家和机器学习工程师用于进行探索性分析和实验工作，以回答没有明确定义的规则集且需要多次迭代才能改进的复杂问题。在这里涉及的数据假设没有结构。

现代数仓架构

在现代数据仓库架构中，数据湖和数据仓库和平共处，各自担任不同的角色。数据湖作为低成本存储用于大量数据，并支持数据科学和机器学习等探索性场景。数据仓库存储高价值的数据，并为企业的仪表板提供支持。它也被商业智能用户用于查询高度结构化的数据，以获取有关业务的洞察力。

参考架构

首先，数据从各种来源（如本地数据库、社交媒体数据源等）被摄取到数据湖中。然后，利用像Hadoop和Spark这样的大数据分析框架对数据进行转换，通过聚合和筛选多个数据集来生成具有高价值的结构化数据。接下来，将这些数据加载到云数据仓库中，用于生成各种仪表盘，包括供商业智能分析师使用的交互式仪表盘，他们可以使用他们非常熟悉的SQL工具进行查询。此外，数据湖还为数据科学家提供了一整套探索性分析以及将机器学习模型反馈到应用程序中的场景。图2-8展示了现代数据仓库架构的简化表示。

在这里，你可能会自然而然地提出一些问题：为什么不直接使用云数据仓库？为什么需要在两者之间加入数据湖？如果我只有结构化数据，是否真的需要数据湖？我可以说，这些是很好的问题。以下是为什么在这种架构中需要数据湖的几个原因：

  1. 数据湖的成本远低于数据仓库，并可作为长期数据存储库。请记住，数据湖通常用于存储大量的数据（数十或数百PB），因此成本差异是实质性的。
  2. 数据湖支持各种现代化的数据科学和机器学习工具和框架，可以用于实现全新的场景。
  3. 数据湖可以为未来的扩展需求提供可扩展性设计。例如，您可以使用初始的数据湖架构每晚从本地系统加载数据，并为商业智能用户发布报表或仪表盘。同样的架构可以扩展支持实时数据摄取，而无需重新设计解决方案。
  4. 各种形式和结构的数据对组织来说越来越重要。即使您今天专注于结构化数据，如前面的示例所示，您可能会发现各种类型的数据（例如天气、社交媒体数据等）都具有价值。

如果你还没有注意到，这里有一个需要记住的使用模式的区别：当你将数据加载到数据仓库时，你使用的是提取、转换和加载（ETL）模式，即从源中提取数据，将其转换为数据仓库所需的格式，然后加载到数据仓库中。而在数据湖中，你遵循提取、加载和转换（ELT）模式，即从源中提取数据，按原样加载到数据湖中，然后进行转换处理。

现代数据仓库架构的示例应用案例

让我们重新考虑我们的模型公司Klodars Corporation。它将利用现代数据仓库架构，开始将数据从其运营数据库加载到数据湖中。它可以停止在本地系统上存储备份，并将每日备份存储在数据湖中，保留一年的备份（或更长时间，如果需要）。在此过程中，Klodars的服务器上的运营数据库将继续为现有应用程序提供服务，从而确保公司运营的连续性。此外，Klodars还计划加载与雨具和冬季装备相关的社交媒体数据，以分析模式。该架构还将使公司能够使用实时摄取技术（如Apache Kafka）将其他数据（如点击流）实时加载到数据湖存储中。

准备好数据集后，数据工程团队将使用Apache Spark等工具处理来自数据库转储和网站点击流的结构化数据，生成显示购物和销售趋势的高价值数据。团队还将处理社交媒体数据流，提取与雨具和冬季装备相关的数据，以及这些数据所指示的任何相关购买行为。该架构将使数据工程团队能够定期生成关于销售趋势、库存和供应、网站浏览趋势以及与雨具和冬季装备相关的社交媒体趋势的高价值数据（例如，每日生成）。然后，将这些数据加载到数据仓库中，并定期刷新（例如，每日）。

存储在数据仓库中的数据是非常高价值的结构化数据。业务分析师将使用这些高价值数据构建仪表盘，显示按季度或按月的销售趋势，以便销售团队可以了解其销售的趋势并为即将到来的时间段制定预测。业务分析师还可以根据地区、销售人员覆盖范围、合作伙伴和其他属性对数据进行分析，以便领导团队了解增长驱动因素，并根据数据制定关于公司扩张策略的决策。营销团队通过在数据仓库上运行交互式查询来使用社交媒体和网站浏览趋势，以了解下一轮有针对性的营销活动的发展方向。团队还可以通过将营销活动与销售结果相关联来了解其营销活动的影响。

影响并不止于此。Klodars现在已经组建了一个数据科学团队，他们可以基于现有数据集（如销售、社交媒体趋势和网站浏览趋势）寻找有趣的关联和影响，这些关联和影响无法通过手动分析进行处理。团队可以将其他数据集引入数据湖中，例如天气数据、关于滑雪等冬季活动的数据等，以向领导团队展示有趣的见解。这些数据可以反馈给数据工程团队，加载到数据仓库中，供领导、营销和销售团队使用。

图2-9展示了Klodars Corporation的现代数据仓库架构的表示。

借助现代数据仓库架构，Klodars Corporation通过依靠数据，能够根据客户的增长需求进行适当的重点领域扩展。其现代数据仓库战略使公司能够在保持现有业务运作的同时进行创新工作。将现有应用逐步迁移到现代化的云架构中，使团队有时间来深思熟虑地设计和实施这一转变。

现代数仓架构的好处

现代数据仓库具有重要优势，可以帮助业务分析师利用熟悉的商业智能工具集（基于SQL）进行数据消费，并实现原本在本地数据仓库实现中无法实现的更现代化的数据科学和机器学习场景。这主要通过数据湖来实现，数据湖作为一个非孤立的数据存储库，支持使用云原生服务进行高级数据科学和机器学习场景，同时保留了熟悉的数据仓库，如面向商业智能用户的基于SQL的接口。此外，数据管理员可以通过数据仓库将对数据的访问隔离给商业智能团队，使用熟悉的数据仓库访问控制方法。运行在本地的应用程序也可以逐步迁移到云端，完全消除维护两套基础设施的需求。此外，通过将运营数据备份到数据湖中，企业可以降低总体成本，并延长数据备份的时间。

然而，这种方法也存在一些挑战。数据工程师和管理员仍然需要维护两套基础设施：一个数据湖和一个数据仓库。在数据湖中存储各种类型的数据的灵活性也带来了挑战。管理数据湖并确保数据质量的保证是数据工程师和管理员现在必须解决的重大问题，这是他们之前没有遇到的问题。如果数据没有得到妥善管理，数据湖也有可能变成一个数据沼泽，就像在一堆干草中找针一样隐藏了洞察力。如果商业智能用户或业务决策者需要新的数据集，他们必须依赖数据工程师来处理这些数据并将其加载到数据仓库中，这引入了一个关键路径。此外，如果数据科学家在数据仓库中发现了一个有趣的数据片段，他们想要将其包括在探索性分析中，他们需要将其重新加载到数据湖中，以不同的数据格式和不同的数据存储方式，增加了共享的复杂性。

数据湖仓架构

数据湖仓（Data Lakehouse），是由Databricks广泛使用的一个行业热词。根据451 Research的研究分析师Malav Parekh的博客文章，Amazon在发布Redshift Spectrum时首次使用了“lake house”（湖宅）这个术语，将“lake”和“house”之间加了一个空格。该术语在行业中逐渐流行起来是在2020年1月Databricks的一篇博客文章中，称数据湖仓是一种新的开放式架构，结合了数据湖和数据仓库的最佳元素。

我清楚地记得2020年的Data and AI Summit的主题演讲，Ali Ghodsi宣布了数据湖仓作为一种新的范式，并介绍了Delta Lake。有多个关于Delta Lake的会议，参会者排起长队沿着会议大厅的走廊。数据湖仓架构的不断增长的受欢迎程度和生态系统支持了这种新范式的主张。

数据湖仓架构可以简单解释为一个单一平台，结合了两个功能：

  1. 数据湖用于分析处理、数据科学和机器学习场景。
  2. 数据仓库用于SQL交互查询和商业智能场景。

换句话说，它指的是在数据湖上运行SQL和商业智能场景。这个概念具有以下三个吸引人的特点：

  1. 数据湖比数据仓库便宜得多，使得数据湖仓更具成本效益。
  2. 无需将数据从数据湖复制或移动到数据仓库，无需进行数据移动。
  3. 通过消除分离的体验和平台，数据科学家和商业智能团队可以自由共享数据集。

数据湖仓架构的出现在行业中引起了广泛关注，并为组织提供了更加灵活和高效的数据分析和查询方案。

数据湖仓的参考架构

图2-10展示了数据湖仓架构的简化表示。请注意，现在您可以在单一平台上运行所有场景，包括商业智能和数据科学，并且无需使用云数据仓库。

那么，如果我们已经有了在数据湖上运行商业智能场景的选项，为什么一开始就没有这样做呢？简单的答案是因为数据湖本身并不真正适合支持商业智能查询，而且有各种技术使得数据湖仓成为现实。请记住，数据仓库依赖于高度结构化的数据以实现更快的查询处理和支持涉及连接和聚合的复杂查询，而数据湖则是高度可扩展的对象存储服务，用于存储和处理数据，对结构不做任何假设。

让我们更详细地看一下，数据仓库具有以下优势：

ACID兼容的事务

数据仓库确保事务符合ACID的标准，这一特性对于保证通常存储在仓库中的高价值数据的完整性至关重要。这种完整性非常重要，因为这些数据用于支持涉及公司收入和运营的关键操作的查询和仪表板。例如，销售预测仪表板为组织设定收入目标。ACID是指事务的四个关键属性：

  1. 原子性

确保当事务完成时，整个事务作为一个单元成功。例如，如果您在查询中请求客户的详细信息，并要求包括姓名、年龄、位置和收入潜力，您将获得所有的详细信息，而不仅仅是年龄和位置。

  1. 一致性

确保遵循所有适当的数据验证规则，并且只写入允许的数据。如果验证不成功，则数据库将在事务之前回滚到之前的状态。例如，如果您想要将新的客户记录添加到数据库中，您有正确的姓名和年龄，但位置无效，整个事务将失败。

  1. 隔离性

确保在处理并发事务时，一个事务不会影响另一个事务。例如，如果两个用户尝试向数据库中添加相同的客户，第一个用户成功，而第二个用户会因为客户已经存在而收到错误。

  1. 持久性

确保在成功的事务之后，数据是可用的。例如，当您成功地将客户添加到数据库中时，即使发生断电或硬件故障，您也可以确保客户数据是完整的。

针对SQL进行优化

大多数商业智能和数据分析工具及生态系统都针对SQL进行了优化，而数据仓库提供了一个针对SQL进行优化的查询引擎，支持这些场景。

数据湖提供以下优势：

存储和处理非结构化数据的能力

大多数涉及高级分析、数据科学和机器学习的新兴场景都依赖于处理非结构化数据。数据湖对数据的结构或模式不做任何假设。在从数据湖读取数据时，您可以在读取时定义数据的模式。

低成本

数据湖是高度优化的存储系统，为用户提供了低成本的拥有权，并且可以存储任意量的数据，无需担心不断增长的费用。

丰富的数据管理

数据湖提供了一系列功能来帮助管理数据，正如我们在前面的部分所看到的。这些功能包括分层存储、数据复制和数据共享能力。

尽管将数据湖和数据仓库统一为一个体系结构具有吸引力，但数据湖的优势是数据仓库的不足之处，反之亦然，这长期以来一直妨碍着数据湖架构的发展。

然而，随着组织中对数据湖的日益采用以及在数据湖上运行的各种场景的增加，人们开始积极关注并为实现数据湖架构的关键技术做出贡献。其中一些技术包括源于Databricks的Delta Lake、源于Netflix的Apache Iceberg和源于Uber的Apache Hudi。

尽管这些技术本身不同，并从不同的角度解决问题，但它们有一个共同点：它们定义了存储在数据湖中的数据。这种数据格式为在数据湖上提供数据仓库的保证（接近ACID的一致性、元数据处理、模式强制和演化）奠定了基础。

它们通过三个关键组件来实现这一点：

  • 开放的文件格式
  • 定义数据的元数据层
  • 理解这些文件格式和元数据层的计算引擎

有了这些组件，它们可以将存储在数据湖中的非结构化数据作为对象或文件，并将其以表格的新逻辑形式呈现出来。表格是指以逻辑行和列组织的数据，如图2-11所示。

数据格式

我们已经确定数据格式对于数据湖架构至关重要，但为什么会这样呢？正如我们之前所看到的，数据仓库中的数据具有关于完整性的强大保证；为了使数据湖中的数据具备类似的保证，将数据限制在一些关键规则下是非常重要的。可以类比为，在教室里，孩子需要遵守一定的规则，以创造一个有利于学习的环境，但同样的孩子可以在公园里自由探索。想象一下，如果你在公园里建立一个教室，你需要做些什么；开放的数据格式试图确保数据在非结构化环境中受到一定规则的限制，而这种环境在这里就是数据湖存储。

数据格式对于数据湖架构至关重要，原因如下：

  • 存储的数据需要遵守由元数据定义的模式（描述数据集的表格结构的数据）。这里的模式指的是数据的定义表示或描述。
  • 存储的数据针对查询进行了优化，特别是为了支持主要使用类似SQL查询的BI用例。这种优化对于支持与数据仓库相当的查询性能至关重要。
  • 实际上，解决这些需求还有一个非常好的好处，即这些数据往往具有高度可压缩性，从而实现更快的性能和更低的成本，这意味着你可以同时拥有这两方面的好处。

数据湖架构中使用了诸如Delta Lake、Apache Iceberg和Apache Hudi之类的专用格式。我们将在第6章中对它们进行更详细的讨论。它们都源自一种基本的数据格式，即Apache Parquet，这是Apache Hadoop生态系统中使用的列存储数据格式。

让我们进行一个小的绕道，了解一下列格式意味着什么。请记住，我们正在讨论的是表格数据，其中数据按行和列组织，如图2-12所示。当涉及到如何在数据湖中存储这些数据时，直觉上可能会认为你将一个记录（即一行）一起存储。而在列格式中，数据以列为导向的方式进行存储，具有相似列值的数据被存储在一起。正是这种对相似数据的捆绑使得列格式（如Apache Parquet）具有高度可压缩性。图2-12提供了相同数据在行导向和列导向结构中存储的表示形式。

我们将在第4章中更详细地讨论Apache Parquet。开放数据技术使用Apache Parquet作为其底层数据格式，以便利用Apache Parquet的优化来优化查询。

元数据

元数据简单地指的是关于数据的数据。例如，如果您有一个包含1000行的表，存储为每个数据集的100行块，那么每个块都与描述存储的数据相关的元数据相关联，比如这个块包含第101至200行，其中包含以A-B开头的姓氏列的值。此外，还在表级别存储了指向不同块的指针的元数据。

这些元数据对于最终用户来说并不是很重要，但对于操作数据的计算引擎非常重要。这些计算引擎读取元数据，然后获取相关的数据。像Apache Iceberg、Delta Lake和Apache Hudi这样的技术都有自己的元数据版本，用于确定数据在不同的Parquet文件中的存储和组织方式，哪些数据正在进行更新以及何时进行更新，以便提供数据完整性和一致性，并与计算引擎进行握手，以优化特定的场景。

虽然它们都是合适的选择，但每个选项都是根据特定目的进行设计的，因此在设计架构时您需要考虑这一点。Databricks的Delta Lake针对在数据湖上运行高性能的SQL查询进行了优化，利用元数据进行智能数据跳过，只读取为提供查询所需的数据。Uber开源的Apache Hudi主要设计用于支持增量更新，并具有列格式的快速查询性能。Netflix开源的Apache Iceberg主要用于刷新数据集（例如，支持对像S3这样的追加存储系统上的现有数据进行更新），并可由众多计算引擎（如Apache Spark、Trino（Presto SQL）、Apache Hive和Apache Flink）进行读取，程度各不相同。

计算引擎

与数据仓库不同，数据湖架构中的计算和存储优化并一起作为一个服务提供。在运行数据湖架构时，需要选择合适的计算引擎，以利用用于优化数据存储的数据格式和元数据提供的优化功能。换句话说，数据被优化为以表格形式写入存储，您需要一个计算引擎来理解和读取表格，以有效地查询数据。

例如，对于由Databricks开发的Delta Lake格式，其计算组件（即Spark引擎）针对操作Delta表格进行了优化，并通过缓存提供更快的性能以及通过Bloom过滤器索引实现有效的数据跳过。我们将在第6章中对这些计算引擎进行更详细的讨论。

数据湖架构的示例应用场景

Klodars Corporation将利用数据湖从其操作数据源加载数据到数据湖存储中，类似于我们在现代数据仓库架构中所看到的。让我们更详细地看看这种架构对业务的影响。

数据工程团队将使用诸如Apache Spark之类的工具处理来自数据库转储和网站点击流的结构化数据，以生成随时间变化的购物和销售趋势等高价值数据。团队还将处理社交媒体信息流，提取与雨衣和冬季装备相关的数据，以及这些信息流指示的任何相关购买信息。

现在让我们来看看如何处理这些提取出的数据。数据工程团队将按计划（例如每日）生成关于销售趋势、库存和供应、网站浏览趋势以及雨衣和冬季装备周围的社交媒体趋势等高价值数据。现在，业务分析师可以开始使用他们熟悉的基于SQL的工具以及像Presto这样的现代查询工具来查询这些数据，而无需移动数据。类似于现代数据仓库模式，数据科学家可以带上自己的数据集，例如天气数据，并探索已经存在于数据湖中的数据。

数据湖架构通过消除存储相同数据的两个位置，相比现代数据仓库，提供了一个重要优势。假设数据科学团队利用其新的数据集（例如天气数据）构建了一个将销售与天气相关联的新数据集。由于每个人都使用相同的数据存储和可能相同的数据格式，因此业务分析师可以立即开始进行更深入的分析。同样，如果业务分析生成了特定的筛选数据集，数据科学家可以开始使用该数据集进行分析。

花点时间思考一下这意味着什么以及其影响是什么。这完全扩展了不同类别的数据平台使用者之间的洞察力交叉，促进了洞察力的交流。共享平台意味着BI分析师和数据科学家生成的数据对于两者都可用，以进一步创新，从而将数据的价值提升数倍。Klodars Corporation的数据湖架构示例如图2-13所示。

数据湖架构的优势和挑战

数据湖仓提供了一个关键优势，即能够直接在数据湖上运行高性能的BI/SQL场景，与其他探索性数据科学和机器学习场景并行进行。正如我们在用例中看到的那样，这也促进了数据平台的各个用户部门之间的共享，产生了新的场景。此外，与数据仓库相比，数据湖具有非常高的成本效益。

然而，也存在挑战。正如我们在架构部分看到的那样，构建数据湖仓需要精心设计和架构，选择合适的数据格式和计算引擎以实现最优化的解决方案，从而提供更快的性能。如果没有正确的规划，许多问题可能会出现，我们将在第4章中详细讨论这些问题。数据仓库可以直接提供这种优化路径，但它们并不是真正开放的。尽管我没有预测未来的能力，但鉴于数据湖仓架构的快速发展速度，我相信在未来几年中，这个领域将会迅速创新，从而实现简化的端到端体验。

数仓和非结构化数据

如果数据湖可以开始支持数据仓库场景，那么数据仓库是否也可以开始支持数据湖场景呢？令人惊讶的答案是肯定的。正如我们在前面的部分中看到的那样，Azure Synapse Analytics为Spark、机器学习和SQL提供了统一的数据平台。Google BigQuery支持存储非结构化数据，并原生支持Parquet格式；它还支持查询存储在GCS中的数据。Snowflake最近也推出了对非结构化数据的支持。无论是数据湖支持数据仓库，还是数据仓库支持数据湖，我们当前的创新明确表明，统一的数据平台和无障碍的数据平台是未来的发展方向。

Data Mesh

在2019年，Thoughtworks的新兴技术总监Zhamak Dehghani撰写了一篇关于数据网格的文章，奠定了数据网格架构的基础。数据网格架构使得组织能够以分散化的方式运行数据基础设施和操作，从而在整个组织中实现数据和洞察力的民主化。让我们看看为什么这种分散化的数据网格对于组织来说如此重要或相关。

到目前为止，我们已经讨论了数据湖作为组织的数据和智能的中央存储库，以及技术选择。在架构中的体现方式是作为一个由中央团队管理的基础设施。现在让我们看看在组织中谁负责设计和操作数据湖。数据的提取和处理由一个中央团队管理，通常被称为数据平台团队、数据基础设施团队、数据工程团队或者其他类似的名称。在本节中，我们将称这个团队为数据平台团队。

数据平台团队通常拥有以下角色：

数据平台架构

设计满足组织需求的计算和存储组件的基础设施。

数据管理

在云上组织数据集；应用数据管理策略，确保数据符合组织在数据保留和数据驻留方面的合规需求。

数据治理

控制谁可以访问哪些数据，提供目录，使数据平台的使用者可以发现数据集，并管理审计。

数据摄取

通常负责从各种源头（如本地系统、物联网等）摄取数据，以及可能的数据准备，使其可以被使用。在某些情况下，数据平台团队倾向于将这种摄取工作委托给数据湖的使用者们。

换句话说，数据基础设施是由一个中央团队管理的整体单元，而组织的其他部门则专注于消费场景：商业智能、数据科学或其他需求。随着基于数据的场景数量的增加和组织的扩大，这个通常是一个精简团队的数据平台团队很容易被来自整个组织的请求淹没，并成为数据的关键路径，从而引入了瓶颈。

数据网格架构呼吁进行一种文化转变，将数据视为可以在组织间共享的产品，而不是需要收集和处理的资产/实体数据。

这种文化转变意味着什么呢？在这一点上，我想引用Zhamak Dehghani在她的书《数据网格》（O'Reilly）中提出的一组重要原则：

  • 在组织上，责任的转变从一个做所有事情的中央数据平台组织到一个分散的模型，其中每个业务领域都有专门的人员专注于数据需求。
  • 在架构上，从一个庞大的中央数据仓库或数据湖的单体实现转变为数据湖和数据仓库的分布式网格，通过共享洞察和数据仍然对数据进行单一逻辑表示。
  • 在技术上，从将数据视为独立实体和平台转变为将数据和业务代码作为一个整体进行集成的解决方案。
  • 在运营上，从中央运营模型对数据治理的自上而下指令转变为一种联邦模型，其中每个业务领域都拥有并尊重组织的政策。
  • 在原则上，从将数据视为需要收集的资产转变为作为产品为用户服务和提供愉悦体验的产品。

参考架构

数据网格依赖于分布式架构，由多个领域组成。每个领域都是数据及其相关存储和计算组件的独立单元。当一个组织包含多个产品单位，每个单位都有自己的数据需求时，每个产品团队拥有一个由产品团队独立运营和管理的领域。其角色和责任包括以下内容：

  • 中央数据平台团队制定并维护计算、存储和数据组件架构的一套蓝图/参考模式。
  • 产品团队实施这些蓝图，以使其领域能够运营。

这使得产品团队/领域可以使用其选择的基础设施或技术。例如，一个单位可以在AWS上使用数据湖架构，另一个单位可以在Microsoft Azure上实现现代数据仓库架构，同时仍然共享数据和洞察力。关键原则在于，领域中的数据在组织内共享，并在符合合规和治理要求的边界内，遵循无隔离逻辑数据湖的原则，仍然促进数据和洞察力的共享。数据网格架构的示意图如图2-15所示。


数据网格架构的示例用例

Klodars Corporation 在其软件产品和团队较小的时候运营良好。然而，随着业务的增长和在更多地区的推出，团队和组织规模显著扩大，中央数据平台无法再满足需求的扩展。此外，由于 Klodars Corporation 收购了使用不同技术堆栈的其他公司，将它们整合成一个统一的单位变得困难。Alice 和她的团队在中央数据平台上决定实施数据网格架构。

Klodars Corporation 的中央数据平台团队发布了架构，连同部署和配置脚本，以自动设置数据领域，并建立数据治理、合规和数据共享基础设施。Klodars Corporation 拥有销售、营销和客户成功团队，它们实施自己的数据领域，并与其他组织共享洞察力。销售团队发现现代数据仓库架构适合他们的需求，因为他们大量使用操作数据库；客户成功团队发现数据湖架构更适合他们的需求，因为多样化的数据来源可以使他们的商业智能和数据科学团队受益。数据网格模式使 Klodars Corporation 能够给予其数据领域选择的自由，同时促进数据的共享，保持统一数据平台的特点。此外，Klodars Corporation 收购的公司能够保留其现有的数据湖，只需进行微调。当 Klodars Corporation 想要扩展到冬季装备时，它可以与合作伙伴的滑雪公司共享洞察力，以促进更好的合作关系，进一步扩展数据网格架构。Klodars Corporation 正在迅速增长，并希望将业务扩展到欧洲，该地区具有独特的数据驻留和其他合规要求。它可以设置特定于欧盟（EU）的领域，同时遵守 EU 的特定要求，而无需进行大量的开发或重建工作。在未来，当 Klodars Corporation 收购其他公司时，它可以将所收购公司的数据平台作为领域引入到现有的数据网格中。Klodars Corporation 的数据网格架构示例如图2-16所示。


数据网格架构的挑战和优势

数据网格具有独特的价值主张，不仅提供基础设施和场景的规模扩展，还有助于改变组织围绕数据的文化，正如我们在前面的部分所看到的。数据网格架构提供以下优点，正如使用案例所示：

  • 实现自助架构，能够适应组织的增长和数据多样性
  • 为领域提供架构和平台的选择灵活性
  • 在整个组织中推广数据文化，而不仅仅是小团队的角色，避免瓶颈的产生

当然，这种方法也存在挑战。首先，这依赖于各个产品团队是否有熟练的软件开发人员可用，而这并不总是情况。其次，数据湖架构本身就带来了数据和生态系统多样性的复杂性；添加分布式层级增加了这种复杂性。尽管如此，提前投资于这个领域可以为组织的成功打下基础，并且基于数据网格的不断增长的流行度，我可以做出一个有根据的猜测，即在简化此架构的部署和管理方面将会有快速创新。

那对我而言什么才是合适的架构？

在本节中，我们讨论了三种主要的热门云数据湖架构：

  • 现代数据仓库架构，这在组织中普遍存在
  • 数据湖仓架构，使得可以直接在数据湖上运行 BI 场景
  • 数据网格架构，提供了一种分散式的管理和操作云数据湖的方法

那么，你如何确定选择哪种架构？你如何知道你是正确的？尽管我们都是在实践中不断学习，但有一套基本原则可以帮助你朝着正确的方向前进。

了解你的客户

就像每个项目一样，首先确定你必须按照优先顺序满足的目标以及你的客户群体。根据你的组织需求，你可以从以下一个或多个客户群体开始：

  • BI/数据分析师：为他们准备数据集以供在数据湖上进行分析。这可以通过运行定期作业从各种来源获取数据并进行数据处理生成数据集来实现。
  • 数据科学家/探索性分析：建立一个基础设施，使数据科学家可以将自己的数据集带到数据湖进行分析。你还可以选择管理来自已知来源的数据摄取，并在数据湖上为他们提供数据集。

我知道有些客户在继续运行数据仓库的同时开始他们的数据湖之旅；他们没有技术负债或现有的兼容性，并从头开始建立数据湖来支持组织的第一批场景。我也知道有些客户通过解决数据湖上的 BI 用户需求开始他们的数据湖之旅；在这种情况下，他们的目标是现代化数据基础架构以支持新的场景，同时保持对现有流程的支持，因此他们有一定的余地进行重构，但优先级是确保系统正常运行。我还见过一些客户将数据湖用作备份计划，同时继续运行他们的本地系统；在这种情况下，他们的云架构必须是本地系统的复制品，并且他们将在以后的阶段考虑现代化。你可以符合其中一种情况，或者有自己的场景。最重要的是，了解你的客户是第一步：与你的客户和业务决策者交流，了解数据在你的组织中的作用，并展示其潜力。

了解你的业务驱动因素

虽然新技术非常迷人，也是我继续从事我的工作的原因，但我们始终需要记住，技术只是达到目标的手段，每个决策都需要以你试图为组织解决的问题为基础。有许多业务驱动因素会引导组织采用云数据湖。让我们来看看其中的几个：

成本

迁移到云数据湖可以保证你的总拥有成本(TCO)降低，根据我的经验，这仍然是组织采用云数据湖方法的主要动因之一。确保在架构决策上与降低成本的目标保持一致。

新场景

尽管一些组织已经有现有的数据基础设施，但它们有动力转向云数据湖，以利用不断增长的现代技术生态系统，如机器学习或实时分析，以区分其业务和产品。如果这是你的动力，那么你倾向于通过这些新场景提供价值，并应相应地定义目标。你是要通过新的营销活动增加采用率，还是通过智能产品提供价值？再次，将你的技术选择与这些目标相衡量。

时间

尽管组织迁移到云的动机可能是成本、现代化场景和其他因素，但时间有时会决定技术和架构选择。我见过一些客户制定了迁移到云的路线图，同时他们的本地硬件或软件许可证的支持即将终止。然后你的技术/架构选择将受到时间限制的制约。

考虑你的增长和未来场景

尽管客户需求和业务驱动力定义了你技术和架构决策的优先级，你需要确保所选择的设计不会束缚你的发展空间。举个例子，如果你的数据湖基础设施是由市场部门的需求驱动的，他们需要运行个性化的营销活动并更好地了解你的客户细分，那么你将设计第一个版本的数据湖架构以满足这些需求。确保你专注于从客户系统和社交媒体数据源中获取数据，并生成可供业务分析师使用的数据集，以便他们选择他们想要为其定制活动的优先级较高的细分群体。然而，你的设计应该预见到当这个第一个场景取得成功后，会有更多的场景和更多的客户。我曾经与一些客户合作，他们总是假定数据工程团队将是唯一能访问数据湖中数据的团队，并没有实施正确的安全和访问控制，结果发现各种场景迅速增长，每个人都能访问所有数据，并造成了意外的数据删除。因此，即使你目前只有一个客户，也要考虑如何设计一个多用户系统，重点关注数据组织、安全和治理。我们将在第三章中详细讨论这些问题。

设计考虑因素

当我与客户讨论他们的数据湖解决方案时，他们经常问我推荐最便宜或最快的方法，我的回答总是“这取决于情况”，我带着微笑给出这个回答。鉴于云数据湖解决方案的灵活性和多样性，以及软件和平台的生态系统，选择合适的方案和方法几乎就像规划你的家庭预算一样。虽然我们可以做一些笼统的陈述，比如“Costco的价格很优惠！”，但不太被理解的含义是“它依赖于您确保不浪费您大量购买的物品。”云数据湖提供了灵活性和较低的成本，但它们依赖于数据平台团队来确保它们以最优化的方式运行。在表格2-1中，我试图对这些架构在几个可预见的维度上进行评估，以便您可以将其作为确定适合您的合适方案的起点。让我们以另一种方式来看这些数据。图表2-17显示了在不同架构之间成本和复杂性之间的权衡关系。

混合方式

根据组织需求、方案成熟度和数据平台战略的不同，您可能会采用混合方法来管理您的数据湖。例如，虽然大部分组织使用云数据仓库作为中央数据存储库，但有一个创新中心正在使用数据湖架构进行一组精选场景的工作，并逐步将其扩展到整个公司。或者，虽然大部分组织采用数据湖仓架构，但一些团队仍然依赖需要数年才能迁移的传统基础设施。 您的场景的细微差别可能是如此独特或特定于您的组织，以至于超出了本书的范围。然而，本章讨论的原则将帮助您提出正确的问题并做出明智的数据湖架构选择。 大数据生态系统和云数据湖架构是一个快速创新的领域。我敢肯定，当我完成这一章时，某些方面已经发生了变化。

总结

在本章中，我们更深入地了解了云数据湖的三种关键架构，并与传统云数据仓库架构进行了比较。首先，我们介绍了现代数据仓库架构，在该架构中，您收集和处理数据，并将相对价值密度较低的原始数据转化为高价值的结构化数据，然后将高价值数据加载到云数据仓库以支持BI场景。接下来，我们介绍了数据湖仓架构，该架构支持在数据湖上直接进行BI场景（以及数据工程和数据科学场景），无需云数据仓库。然后，我们探讨了数据网格架构，它提供了一种分散化的管理和操作数据湖的方法，为组织内不断增长的需求和数据快速增加的情况提供可持续的扩展方式。最后，我们综合考虑了组织的成熟度、技能组合和规模等因素，帮助您制定适合您组织的云数据湖架构。在第三章中，我们将更多关注云数据湖中的“数据”部分：数据组织、管理、安全和治理的考虑因素。

阅读量：2019

点赞量：0

收藏量:0