adoop现代大数据处理全绝不原创的飞龙

如今，复杂的数据结构需要复杂的数据转换解决方案及其语义表示，以使用户更容易访问信息。Apache Hadoop，以及大量其他大数据工具，使您能够相对轻松地构建此类解决方案。这本书列出了一些独特的想法和技术，使您能够在成为专家大数据架构师的道路上克服不同的数据处理和分析挑战。

这本书首先快速阐述了企业数据架构的原则，并展示了它们与 Apache Hadoop 生态系统的关系。您将全面了解 Hadoop 的数据生命周期管理，然后在 Hadoop 中建模结构化和非结构化数据。这本书还将向您展示如何通过利用 Apache Spark 等工具来设计实时流管道，以及如何使用 Elasticsearch 等工具来构建高效的企业搜索解决方案。您将在 Hadoop 上构建企业级分析解决方案，并学习如何使用 Tableau 和 Python 等工具可视化您的数据。

本书还涵盖了在本地和云上部署大数据解决方案的技术，以及管理和管理 Hadoop 集群的专家技术。

到本书结束时，您将拥有构建专家大数据系统所需的所有知识，这些系统可以利用全套现代大数据框架和工具来满足任何数据或洞察力需求。您将拥有成为真正的大数据专家所需的技能和知识。

这本书是为那些希望在 Hadoop 行业快速发展职业生涯并成为专业大数据架构师的大数据专业人士而写的。希望在大数据和 Hadoop 领域建立职业生涯的项目经理和大型机专业人员也会发现这本书很有用。需要对 Hadoop 有所了解，才能充分利用这本书。

如果 Hadoop 的正确安装能像前面几章解释的那样完成，那就太好了。对 Hadoop 的详细甚至很少了解将是一个额外的优势。

您可以按照以下步骤下载代码文件:

下载文件后，请确保使用最新版本的解压缩文件夹:

本书通篇使用了许多文本约定。

CodeInText:表示文本中的码字、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和推特句柄。下面是一个例子:“将下载的WebStorm-10*.dmg磁盘镜像文件作为另一个磁盘挂载到系统中。”

代码块设置如下:

任何命令行输入或输出都编写如下:

粗体:表示一个新的术语、一个重要的单词或者你在屏幕上看到的单词。例如，菜单或对话框中的单词像这样出现在文本中。下面是一个示例:“从管理面板中选择系统信息。”

Warnings or important notes appear like this. Tips and tricks appear like this.

我们随时欢迎读者的反馈。

请留下评论。一旦你阅读并使用了这本书，为什么不在你购买它的网站上留下评论呢？然后，潜在的读者可以看到并使用您不带偏见的意见来做出购买决定，我们在 Packt 可以了解您对我们产品的看法，我们的作者可以看到您对他们的书的反馈。谢谢大家！

传统上，企业采用数据仓库来存储、处理和访问大量数据。这些仓库通常是大型关系数据库管理系统数据库，能够存储非常大规模的各种数据集。随着数据复杂性、数量和访问模式的增加，许多企业已经开始采用大数据作为模型来重新设计他们的数据组织，并围绕它定义必要的策略。

此图描述了企业中典型数据仓库的外观:

由于企业有许多不同的部门、组织和地理位置，每个部门都倾向于拥有自己的仓库，并对整个企业提出了各种挑战。例如:

由于多项技术进步，以比几十年前更低的成本构建超大规模系统变得非常容易，例如:

随着全球化，市场全球化，消费者也全球化。这增加了覆盖范围。这些进步也给企业带来了以下方面的挑战:

为了掌握市场的需求，企业开始收集越来越多关于自己的指标；因此，在当前情况下，数据处理的维度有所增加。

在本章中，我们将学习:

当前状态的数据可以定义为以下四个维度(四个 Vs)。

数据量是设计大数据系统所需的一个重要指标。这是决定企业为满足当前和未来存储需求而必须进行的投资的一个重要因素。

企业中不同类型的数据需要不同的存储、归档和处理能力。Petabyte 存储系统在当今行业非常普遍，这在几十年前几乎是不可能实现的。

这是决定数据移动性的另一个数据维度。组织内部存在着属于以下类别的各种数据:

这个维度对企业用来消费和处理数据的网络架构有一些影响。

这个维度谈论数据的形式和形状。我们可以进一步将其分为以下几类:

作为一个组织，采用非常少的技术来减少数据的多样性是非常重要的。拥有许多不同类型的数据对于企业来说，在管理和使用所有数据方面都是一个非常大的挑战。

这个维度讲的是数据的准确性。如果没有对企业内每个系统为保持数据安全、可用和可靠而提供的保证有一个坚实的理解，就很难理解从这些数据中生成的分析并进一步生成见解。

必要的审计应该到位，以确保流经系统的数据通过所有质量检查，并最终通过大数据系统。

让我们看看典型的大数据系统是什么样子的:

如您所见，许多不同类型的应用正在与大数据系统交互，以存储、处理和生成分析。

在我们试图理解元数据的重要性之前，让我们尝试理解什么是元数据。元数据简单来说就是数据关于数据的数据。这听起来很混乱，因为我们正在以递归的方式定义定义。

在典型的大数据系统中，我们有这三个垂直级别:

这带来了一些挑战，因为我们谈论的是存储在大数据系统中的数百万(甚至数十亿)数据文件/数据段。我们应该能够正确识别整个企业中这些数据文件的所有权和使用情况。

我们举一个电视广播公司拥有一个电视频道的例子；它制作电视节目，并通过有线电缆网络、卫星网络、互联网等向所有目标受众广播。如果我们仔细看，内容的来源只有一个。但它正在通过所有可能的媒介传播，最终到达用户的位置，以便在电视、手机、平板电脑等设备上观看。

由于观众在各种设备上访问该电视内容，因此在这些设备上运行的应用可以生成若干消息来指示各种用户动作和偏好，并将它们发送回应用服务器。这些数据非常庞大，存储在一个大数据系统中。

根据数据在大数据系统中的组织方式，外部应用或对等应用几乎不可能知道系统中存储的不同类型的数据。为了使这一过程更容易，我们需要描述和定义数据组织是如何在大数据系统中发生的。这将帮助我们更好地了解大数据系统中的数据组织和访问。

让我们进一步扩展这个例子，假设有另一个应用从大数据系统中读取数据，以了解在给定的电视剧中做广告的最佳时间。该应用应该更好地理解大数据系统中可用的所有其他数据。因此，如果没有定义良好的元数据系统，很难做到以下几点:

拥有非常大的数据量不足以做出对业务成功有积极影响的非常好的决策。确保只收集、保存和维护高质量的数据是非常重要的。随着需要收集新类型的数据，数据收集过程也经历了演变。在这个过程中，我们可能会破坏一些从上一代数据中读取的接口。如果没有定义明确的流程和人员，处理数据对所有规模的组织来说都是一个巨大的挑战。

要在管理数据方面出类拔萃，我们应该考虑以下品质:

这些类型的质量的实现被称为数据治理。在高层次上，我们将数据治理定义为管理良好的数据。这个定义也帮助我们澄清了数据管理和数据治理不是一回事。管理数据与使用数据来做出良好的业务决策并最终管理组织有关。数据治理关注的是我们在管理数据时，在整个组织中使用规范行为的程度。

这是一个重要的区别。那么底线是什么呢？大多数组织都管理数据，但很少有人能很好地管理这些管理技术。

让我们试着理解数据治理的基本原理:

问责制确保有权访问数据的团队和员工描述他们可以对数据做什么和不能做什么。

标准化提高了数据质量，并为多个数据维度带来了秩序。

安全不是一个新概念。它从早期的 UNIX 分时操作系统设计开始就被采用了。在最近的过去，由于广泛的数据泄露给组织带来了大量收入损失，个人和组织在安全方面的安全意识有所提高。

安全，作为一个普遍的概念，可以应用于许多不同的事情。谈到数据安全，我们需要了解以下基本问题:

让我们看一看一个简单的大数据系统，并尝试更详细地理解这些问题。系统的规模让安全成为每个人的噩梦。因此，我们应该制定适当的政策，让所有人保持一致:

在本例中，我们有以下组件:

你可以想象流经这个系统的数据的规模和数量。我们还可以看到，参与整个生态系统的服务器、应用和员工数量非常多。如果我们没有适当的政策，要确保这样一个复杂的系统不是一件非常容易的事情。

此外，如果攻击者使用社会工程来获得对系统的访问，我们应该确保数据访问仅限于最低可能的级别。当糟糕的安全实施到位时，攻击者可以访问几乎所有的商业秘密，这可能会给企业带来严重损失。

仅举一个例子，一家初创公司正在构建下一代计算设备，以将其所有数据托管在云上，并且没有适当的安全策略。当攻击者危及云中服务器的安全时，他们可以很容易地发现这家初创公司正在构建什么，并窃取情报。一旦情报被窃取，我们可以想象黑客如何利用这一点为自己谋利。

了解了安全性的重要性后，让我们定义需要保护的内容。

应用是基于产品的组织的第一线，因为消费者使用这些应用与应用提供的产品和服务进行交互。我们必须确保在编程这些应用接口时遵循适当的安全标准。

由于这些应用向后端系统生成数据，我们应该确保在防火墙方面只允许适当的访问机制。

如果没有适当的审计，应用很难分析数据访问模式。所有日志都应该收集在远离应用服务器的中央位置，并可以进一步纳入大数据系统。

一旦应用生成了几个度量标准，它们就可以临时存储在本地，由周期性进程进一步使用，或者被进一步推送到像 Kafka 这样的流系统。

在这种情况下，我们应该仔细思考并设计数据存储在哪里，以及哪些用户可以访问这些数据。如果我们进一步将这些数据写入像 Kafka 或 MQ 这样的系统，我们必须确保进一步的身份验证、授权和访问控制到位。

在这里，我们可以利用操作系统提供的安全措施，如进程用户标识、进程组标识、文件系统用户标识、组标识，以及高级系统(如 SELinux)来进一步限制对输入数据的访问。

为了实现所有这些访问策略，我们可以使用操作系统提供的机制，如文件访问控制和使用访问控制。由于我们谈论的是地理上分布的大数据系统，因此我们必须思考和设计集中式身份验证系统，以便在员工与这些大数据系统交互时为他们提供无缝体验。

许多关系数据库管理系统非常安全，可以为用户提供以下访问级别:

他们也有内置的审计机制来告诉哪些用户已经访问了什么类型的数据以及何时访问。这些数据对于保持系统的安全至关重要，应该进行适当的监控，以监控这些系统的健康和安全。

由于这些应用提供的洞察力对组织的成功至关重要，因此应该采取适当的安全措施来保护它们。

到目前为止，我们已经看到了企业系统的不同部分，并了解了可以遵循什么来提高整体企业数据设计的安全性。让我们谈谈在数据设计中随处可以应用的一些常见的东西。

正如我们在前面几节中看到的，当操作系统运行时，我们能够通过利用操作系统的安全特性来保护资源。当入侵者获得对设备(甚至退役的服务器)的物理访问权限时，他们可以将这些设备连接到他们控制的另一个操作系统，并访问我们服务器上的所有数据。

当我们停用服务器时，必须小心，因为有一些方法可以恢复写入这些设备的数据(即使在格式化之后)。因此，我们应该遵循行业标准的设备擦除技术来适当地清除企业拥有的所有数据。

为了防止这些，我们应该考虑加密数据。

如果您使用过任何需要身份验证的应用，您将使用用户名和密码的组合来访问服务。通常这些秘密存储在源代码本身中。这给非编译程序带来了挑战，因为攻击者可以轻松访问用户名和密码来访问我们的资源。

许多企业开始采用集中式密钥管理，使用这种管理，应用可以查询这些服务来访问受身份验证保护的资源。所有这些访问模式都经过 KMS 的适当审核

数据即服务(【DaaS】)是近年来因采用云的增加而流行的一个概念。说到数据。如何将数据添加到服务模型中，这可能有些令人困惑？

DaaS 为服务用户提供了极大的灵活性，让他们不必担心运行服务的底层基础设施的规模、性能和维护。基础设施会自动为我们处理它，但是考虑到我们正在处理云模型，我们拥有云的所有优势，例如现收现付、容量规划等等。这将减轻数据管理的负担。

如果我们试着仔细理解这一点，我们将单独去掉数据管理部分。但是数据治理也应该在这里得到很好的定义，否则我们将失去服务模型的所有好处。

到目前为止，我们谈论的是云中的服务概念。这是否意味着我们不能在企业或更小的组织中使用它？答案是否。因为这是一个通用的概念，它告诉我们以下事情。

当我们谈论一个服务模式时，我们应该记住以下几点，否则混乱会接踵而至:

这将保证只有定义明确的用户、IP 地址和服务才能访问作为服务公开的数据。

让我们以一个拥有以下数据的组织为例:

如您所见，所有这些都是独立的数据集。但是，作为一个整体，当我们希望组织成功时。有很多重叠，我们应该尝试在这里接受 DaaS 模型，以便所有这些权威的数据应用仍然可以管理数据。但是对于其他应用，它们是使用 REST API 作为简单服务公开的；因此，这增加了组织内部的协作并促进了创新。

让我们进一步举例说明这是如何实现的:

在前面的示例中，我们看到了企业中使用的各种应用，以及数据作为模型如何以各种方式帮助企业带来协作、创新和信任。

但是，说到大数据，DaaS 能做什么？

就像所有其他数据一样，大数据也可以适合 DaaS 模型，并提供与我们之前看到的相同的灵活性:

有了这几个优势，企业可以更加敏捷，构建能够利用这些数据作为服务的应用。

Hadoop 是一款有助于可扩展和分布式计算的软件。在 Hadoop 出现之前，业界使用了许多技术来满足他们的数据需求。让我们对这些存储机制进行分类:

让我们了解一下这些数据架构是什么。

这种存储企业数据的模型是由 IBM 在 60 年代早期发明的，并被用于他们的应用中。层次数据库的基本概念是数据以根树的形式组织。根节点是树的开始，然后所有的子节点只链接到它的一个父节点。这是一种非常独特的存储和检索东西的方式。

如果你有一些计算机科学的背景，树是存储数据的独特方式之一，因此它彼此之间有一些关系(像父子关系)。

此图说明了数据在典型的 HDBMS 中是如何组织的:

即使我们在这个巨大的数据存储中表达了多种类型的关系，我们也可以看到数据被复制，并且查询不同类型需求的数据成为一个挑战。

让我们来看一个简单的问题，比如:哪个供应商提供了员工-391 拥有的 iMac？

为了做到这一点，我们需要遍历树并从两个不同的子树中找到信息。

网络数据库管理系统也源于计算机科学:图论，其中有大量不同类型的节点和关系将它们连接在一起。该结构中没有特定的根节点。它是在 70 年代早期发明的:

我们可以看到，在这个结构中，有几个核心数据集，还有其他数据集与核心数据集链接。

我们可以这样理解它:

在这种结构中，根据我们提出的设计，数据被表示为一个元素网络。

该系统于 80 年代初在 IBM 再次开发，被认为是迄今为止最著名的数据库系统之一。采用这种风格的软件的几个显著例子是甲骨文和 MySQL。

让我们看看这个关系数据库管理系统表的一个典型例子:

我们正在定义以下类型的表和关系

包含组织中所有部门的表格:

这是一个特殊的表，仅包含使用其唯一标识符的部门和员工之间的关系:

到目前为止，我们已经探索了企业使用的几种类型的数据架构。在本节中，我们将了解数据架构是如何在 Hadoop 中构建的。

简单介绍一下，Hadoop 有多个组件:

这是所有数据以文件形式存储的层。这些文件由 Hadoop 系统在内部拆分为多个部分，并在服务器之间复制以实现高可用性。

因为我们讨论的是以文件形式存储的数据，所以了解这些文件是如何组织的以实现更好的治理是非常重要的。

下图显示了如何在一个 Hadoop 存储层中组织数据。数据的内容可以是任何形式，因为 Hadoop 不会强制它们处于特定的结构中。因此，我们可以在该数据层中安全地存储蓝光电影、 CSV ( 逗号分隔值)文件、AVRO 编码文件等。

You might be wondering why we are not using the word HDFS (Hadoop Distributed File System) here. It's because Hadoop is designed to run on top of any distributed file system.

该层负责跟踪给定文件或路径的数据存储位置(根据服务器、偏移量等)。因为这只是一个记账层，所以非常重要的一点是，这一层的内容要得到高可靠性和持久性的保护。该层中数据的任何损坏都将导致整个数据文件永远丢失。

在 Hadoop 术语中，这也被称为名称节点。

一旦我们解决了数据问题，接下来就是读写数据的程序了。当我们谈论单个服务器或笔记本电脑上的数据时，我们很清楚数据在哪里，因此我们可以编写程序，将数据读写到相应的位置。

以类似的方式，Hadoop 存储层使得应用非常容易给出文件路径，以便在计算过程中将数据读写到存储中。这对编程社区来说是一个非常大的胜利，因为他们不需要担心数据在分布式 Hadoop 集群中的物理存储位置的底层语义。

由于 Hadoop 在数据模型附近提升了计算，这提供了非常高的性能和吞吐量，运行的程序可以由 Hadoop 引擎在更接近整个集群中数据的位置进行调度和执行。数据的整个传输和软件执行的移动都由 Hadoop 负责。

因此，Hadoop 的最终用户将该系统视为具有强大计算能力和存储的简单系统。这种抽象赢得了每个人的需求，成为当今大数据计算的标准。

在本章中，我们看到了有多少组织采用数据仓库来存储、处理和访问他们拥有的大量数据。我们学习了数据架构原则、它们的治理和安全性。在下一章中，我们将了解一些数据预处理的概念。

在本章中，我们将了解以下主题:

如果你有处理某种数据的经验，你会记得大多数时候数据需要被预处理，这样我们就可以进一步把它作为更大分析的一部分。这个过程叫做数据角力。

让我们看看这个过程中的典型流程是什么样的:

让我们试着详细了解这些。

尽管不是数据争论的一部分，这个阶段处理从某处获取数据的过程。通常，所有数据都是在一个中心位置生成和存储的，或者在位于某些共享存储上的文件中可用。

了解这一步有助于我们构建接口或使用现有的库从获取的数据源位置提取数据。

一旦获得数据，我们就必须了解数据的结构。请记住，我们获得的数据可以是以下任何形式:

这就是我们需要某些工具来帮助我们理解数据结构的地方。

一旦我们知道我们在寻找什么，并且对数据的结构有了坚实的理解，我们就更容易想出简单的算法来从输入数据中提取所需的信息。

在这个阶段，我们感兴趣的是从输入数据中提取必要的细节。在前一阶段，我们已经确定了我们感兴趣的必要部分。在这里，我们可以采用以下技术来提取信息:

根据数据的复杂性，我们可能必须采用一种或多种上述技术来从目标数据中提取信息。

该阶段可以发生在信息提取步骤之前或之后。这取决于哪一个更容易(缩短文本或提取信息)。这是分析师可以做出的设计选择。

在这一阶段，我们将从信息或输入数据中删除不需要的数据，以便进一步提取数据，并可以轻松地用于我们的业务需求。

这也是一个非常重要的阶段，在这个阶段，我们执行企业定义的标准来定义最终的数据输出。例如，一个组织可以建议所有国家/地区代码都采用 ISO 3166-1 alpha-2 格式。为了遵守这一标准，我们可能必须转换输入数据，其中可能包含具有全名的国家。因此，必须进行映射和转换。

可以对输入数据执行许多其他转换，以使组织中的任何人都可以按照组织的标准以定义良好的形式使用最终数据。

这一步也为拥有一个企业级标准来改进协作提供了一些重要性。

一旦信息提取完成，任何必要的清理完成，我们需要决定如何保存这个过程的结果。通常，我们可以对该数据使用简单的 CSV ( 逗号分隔值)格式。如果是处理复杂的输出格式，可以选择 XML ( 可扩展标记语言)或者 JSON ( javascript 对象标注)格式。

这些格式是非常标准的，我们今天所拥有的几乎所有技术都非常容易理解这些格式。但是为了一开始简单起见，最好从 CSV 格式开始。

处理客户数据的企业必须确保这些客户的 PII ( 个人身份信息)不会在整个数据管道中自由移动。该标准不仅适用于客户数据，还适用于根据 GDPR 法案、SOX 法案等标准被视为机密的任何其他类型的数据。为了确保我们保护客户、员工、承包商和供应商的隐私，我们需要采取必要的预防措施，以确保当数据通过几个管道时，数据用户只能看到匿名数据。我们的匿名化程度取决于公司遵守的标准以及国家标准。

因此，数据屏蔽可以称为在不丢失意义或上下文的情况下，用其他数据隐藏/转换部分原始数据的过程。

在本节中，我们将了解实现这一目标的各种技术:

替换是用计算数据替换部分数据的过程。数学上可以定义为:

其中 x 为源， y 为该功能的输出。

为了选择正确的替代机制，我们需要了解如何使用这些数据、目标受众以及数据流环境。让我们看看各种可用的替代机制。

在这个方法中，我们有一个查找表；它由给定输入集的所有可能替换组成。该查找表可以这样可视化:

| 源文本(y) | 替代文本(y) || 史蒂夫·乔布斯 | AAPL-1 || 猫 | One hundred and twenty-three million four hundred and fifty-six thousand seven hundred and eighty-nine || 网球 | 板球 |

此表说明了如何构建查找表来用不同的文本替换源文本。当有预定义数量的替换可用时，这种方法可以很好地扩展。

这种基于查找表的替换的另一个例子是当我们遵循国家代码的命名标准时，例如，ISO-8661:

| 源文本(x) | 替代文本(y) || 埃及 | 邪恶的笑（Evil Grin 的缩写） || 印度 | 在…里 || 圣文森特和格林纳丁斯 | 越南 || 联合王国 | 千兆字节 || 美利坚合众国 | 美国 |

当存在大量可能性，并且我们希望使用一些算法来更改数据时，这些替代技术非常有用。这些方法可以分为两种。

这是通过使用某种形式的秘密将给定文本更改为其他形式的过程。这些是数学定义的函数:

如您所见，这些函数接受一个输入和一个秘密，并生成可以使用相同的秘密和输出解密的数据:

如果我们仔细观察，它是在这里发挥重要作用的秘密。在密码学中，有两种基于这个秘密的算法。这些的使用取决于情况和秘密运输的挑战。

在不深入研究密码学的情况下，让我们试着了解一下这些方法是什么:

两者之间的基本区别是，在第一种情况下，我们对加密和解密使用相同的秘密。但是在后者中，我们使用两种不同的密钥进行加密和解密。

让我们看几个对称密钥加密的例子:

| 算法 | 输入数据 | 输出数据 | 方法 || ROT13 | hello | uryyb | 加密 || | uryyb | hello | [通信]解密 || 是吗 | hello | yOYffF4rl8lxCQ4HS2fpMg== | 加密(秘密是hello) || | yOYffF4rl8lxCQ4HS2fpMg== | hello | 解密(秘密是hello) || RIJNDAEL-256 | hello | v8QbYPszQX/TFeYKbSfPL/rNJDywBIQKtxzOzWhBm16/VSNN4EtlgZi3/iPqJZpCiXXzDu0sKmKSl6IxbBKhYw== | 加密(秘密是hello) || | v8QbYPszQX/TFeYKbSfPL/rNJDywBIQKtxzOzWhBm16/VSNN4EtlgZi3/iPqJZpCiXXzDu0sKmKSl6IxbBKhYw== | hello | 加密(秘密是hello) |

如您所见，根据我们使用的加密算法，生成的数据在复杂性和长度上都有所不同。它还取决于用于加密的密钥。

加密带来了更多计算需求和存储空间的挑战。如果我们想在屏蔽过程中使用加密作为方法之一，我们需要相应地规划我们的系统。

这也是一种基于密码学的技术，原始数据被转换成不可逆的形式。让我们看看这个的数学形式:

这里，与加密的情况不同，我们不能使用输出来发现输入是什么。

让我们看几个例子来更好地理解这一点:

| 输入 | 输出 | 方法 || 10-point | 7d862a9dc7b743737e39dd0ea3522e9f | 讯息摘要 5 || 10th | 8d9407b7f819b7f25b9cfab0fe20d5b3 | 讯息摘要 5 || 10-point | c10154e1bdb6ea88e5c424ee63185d2c1541efe1bc3d4656a4c3c99122ba9256 | SHA256 || 10th | 5b6e8e1fcd052d6a73f3f0f99ced4bd54b5b22fd4f13892eaa3013ca65f4e2b5 | SHA256 |

我们可以看到，根据我们使用的加密算法，输出大小会有所不同。另一件需要注意的事情是，给定的散列函数产生相同的输出大小，而与输入大小无关。

在这种方法中，数据被认为过于敏感，甚至不能透露给原始所有者。因此，为了保护数据的机密性，文本的某些部分用一个预定义的字符屏蔽，比如 X(或任何东西)，这样只有对这些部分有完全了解的人才能提取必要的信息。

示例:信用卡信息被认为是高度机密，绝不应该透露给任何人。如果你有一些在亚马逊等网站上在线购买的经验，你会看到你的完整信用卡信息没有显示出来；仅显示最后四位数字。由于我是这种信用卡的真正所有者，我可以轻松识别它并继续交易。

同样，当分析师需要查看部分数据时，重要的是要屏蔽掉其中的重要部分，这样最终用户就不会了解全部情况，而是同时使用这些数据进行他们正在进行的任何分析。

让我们看几个例子来更好地理解这一点:

| 数据类型 | 输入 | 输出 | 网络 || 信用卡呢 | 4485 4769 3682 9843 | 4485 XXXX XXXX 9843 | 签证 || 信用卡呢 | 5402 1324 5087 3314 | 5402 XXXX XXXX 3314 | 万事达信用卡 || 信用卡呢 | 3772 951960 72673 | 3772 XXXXXX 72673 | 美国运通 |

在前面的示例中，这些数字遵循预定义的算法和大小。因此，在固定位置屏蔽数字的简单技术可以更好地工作。

让我们再举一个隐藏部分电子邮件地址的例子，这些地址的大小和复杂性各不相同。在这种情况下，我们必须遵循不同的技术来隐藏角色，以免泄露完整的信息:

这些技术可以简单到:

顾名思义，当应用于输入数据时，这会导致数据丢失。根据我们处理的数据的重要性，我们需要应用这种技术。这种技术的典型例子是为一列中的所有记录设置一个NULL值。因为这种空数据不能用来推断任何有意义的东西，所以这种技术有助于确保机密数据不会被发送到数据处理的其他阶段。

让我们举几个擦除的例子:

| 输入数据 | 输出数据 | 什么被抹掉了 || 空每月收入 1000 印度卢比 | 拉维每月收入为空 | 工资和姓名 || 空手机号码为 0123456789 | 拉维的手机号码为空 | 手机号码和姓名 |

从这些例子中，你可能会想:为什么我们要否定这些价值观？当我们对 PII 不感兴趣，但对我们的数据库/输入中有多少工资记录或手机号码记录感兴趣时，这种技术很有用。

这个概念也可以扩展到其他用例。

擦除的另一种变体是截断，即我们使所有输入数据的大小一致。当我们非常确定信息丢失在管道的进一步处理中被接受时，这是有用的。

这也可以是一种智能截断，我们知道我们正在处理的数据。让我们看看这个电子邮件地址的例子:

从前面的例子中，我们可以看到电子邮件中的所有域部分都被截断了，因为它们都属于同一个域。这项技术节省了存储空间。

这遵循一种统计方法，即我们尝试通过算法将输入数据改变+/-X %的因子。X 的价值纯粹取决于我们正在进行的分析，不应该对理解业务数字产生总体影响。

让我们看几个例子:

| 输入数据 | 输出数据 | 方法 | 解释 || One hundred | One hundred and ten | 固定方差 | 增加 10% || -100 | Ninety | 固定方差 | 减少 10% || 2000 年 1 月 1 日 | 2000 年 2 月 1 日 | 固定方差 | 添加 1 个月 || 2000 年 8 月 1 日 | 2000 年 7 月 1 日 | 固定方差 | 减少 1 个月 || One hundred | One hundred and one | 动态方差 | 增加或减少 1%至 5% || One hundred | One hundred and five | 动态的 | 增加或减少 1%至 5% |

这也被认为是实现数据匿名的标准技术之一。这个过程更适用于我们有多个属性(数据库术语中的列)的数据记录的情况。在这种技术中，记录中的数据在一列中被打乱，以确保记录级别的信息被改变。但从统计数据来看，该列中的数据值保持不变。

例:在对一个组织的薪资范围做分析的时候，我们其实可以对整个薪资列做一个洗牌，所有员工的薪资从来都不符合现实。但是我们可以利用这些数据对范围进行分析。

在这种情况下，也可以使用复杂的方法，我们可以根据资历、地理位置等其他领域进行洗牌。这种技术的最终目标是保留数据的意义，同时使发现这些属性的原始所有者成为不可能。

让我们用一些示例数据来看看这一点:

有五个样本员工记录及其工资信息。上表有原始的工资明细，下表有打乱的工资记录。仔细看数据就明白了。请记住，在洗牌时，可以应用随机算法来增加发现真相的复杂性。

当企业做出非常关键的决策时，数据已经成为非常重要的资产。由于生成和使用这些数据的基础设施的复杂性，对这些数据的访问模式进行一些控制是非常重要的。在 Hadoop 生态系统中，我们有 Apache Ranger，这是另一个帮助管理大数据安全性的开源项目。

Apache Ranger 是一个应用，它使数据架构师能够在大数据生态系统中实施安全策略。该项目的目标是为所有 Hadoop 应用提供一种统一的方式来遵守定义的安全准则。

以下是 Apache 游侠的一些特性:

在本节中，我们将使用 Apache Ambari 安装 Ranger。本节假设已经有一个正在运行的 Ambari 实例。

打开主节点上运行的 Ambari web 界面；然后点击添加服务，如截图所示:

这将打开一个模态窗口，添加服务向导，它将带我们完成 Apache Ambari 的完整安装的几个步骤。

模态窗口出现后，从列表中选择 Apache Ranger 服务，然后单击屏幕上的下一步。

这显示在下面的截图中:

一旦选择了服务，我们将看到用户界面中的下一步，我们需要选择安装和运行该服务的服务器。

我已经为 Ranger 选择了节点-3(参见绿色标签):

Screenshot showing how to choose servers on which this services is going to be installed and run

之后，选择页面底部的下一步。

在这一步中，我们可以选择安装该服务客户端的位置。使用复选框标记您的首选项。

它们看起来像这样:

做出选择后，单击下一步。

我们已经在主节点上安装了 MySQL 数据库服务器。在继续执行 Ambari 向导的下一步之前，我们必须创建一个新的数据库并分配一些权限:

我们还必须使用ambari-server setup命令注册 JDBC 驱动程序:

完成这一步后，我们可以回到安巴里向导。

在向导中，系统会提示我们输入数据库名称、用户名和密码。请根据我们在上一步中所做的选择填写它们:

如有错误，请返回上一步；查看是否有拼写错误，然后重新运行。

完成更改后，单击下一步。

因为我们正在向 Ranger 添加一个服务，所以 Ambari 显示了 Ranger 正常工作所需的配置更改列表。大部分都是默认的。

这些更改看起来像下面的截图。一旦更改看起来不错，单击确定继续:

在这一步中，我们将看到向导中到目前为止所做的更改列表，并看到打印更改摘要和部署游侠的选项。

只有当我们点击部署时，游侠软件才会被安装。在此之前，它都保存在浏览器缓存中。

屏幕如下所示:

一旦游侠的安装开始，它应该看起来像截图中的样子。应该不会有任何故障，因为我们已经正确设置了所有配置。如果有任何故障，请检查日志并通过单击“上一步”按钮查看配置:

部署完成后，我们需要重启所有受影响的 Hadoop 组件，如下图所示:

一旦所有组件都重新启动，安巴里仪表板看起来相当健康，我们已经完成了 Apache Ranger 的安装。

在下一步中，我们将看到如何使用 Apache Ranger 来处理我们的数据安全。

一旦 Apache Ranger 的部署完成，我们就可以使用 Apache Ranger 提供的网络界面来管理我们整个 Hadoop 基础架构的安全性。

访问管理器允许我们定义基于服务和标签的策略。此屏幕截图显示了服务的默认列表和配置的策略:

如您所见，已经为 HDFS 服务和 KAFKA 服务定义了策略，因为它们已经安装在 Ambari 设置中。

当我们想要定义一个新的服务时，我们可以点击+图标并定义服务细节。

| 界面元素名称 | 描述 || 服务名称 | 代理配置中定义的服务名称 || 用户名 | 服务用户的名称 || 密码 | 服务用户的密码 || URL 名称代码 | 名称节点的网址 |

单击应用下方的+图标可以定义新服务(例如，HDFS、Kafka等)

之后，服务定义屏幕如下所示:

Screenshot of the service definition screen after defining new services

我们需要为我们的服务定义填写所有必要的值，然后点击保存。稍后，我们需要向该服务添加策略来执行访问和审核。

在本节中，我们将为三个用户定义一个名为“项目”的 HDFS 路径新策略:hdfs-alice、hdfs-bob和hdfs-tom。其中只允许hdfs-alice所有权限，其余用户只有读取权限。

我们将看到一旦策略到位，Ranger 如何实施访问限制。

让我们看看创建策略的屏幕:

Screenshot showing how Ranger enforces access restrictions

一旦我们点击添加按钮，这个策略就被注册并添加到当前服务中。

现在，让我们回到 Unix 终端，看看 Ranger 是如何执行策略的。

该屏幕显示如何允许hdfs和hdfs-alice用户创建目录/projects和/projects/1，但如何拒绝hdfs-tom:

Apache Ranger 在 web 界面中也有一个审计部分，在这里我们可以看到这些访问模式。

该屏幕显示策略拒绝hdfs-tom并授予hdfs-alice访问权限:

Screenshot showing access denied to hdfs-tom and access granted to hdfs-alice by the policy

像这样，我们可以定义自己的策略，并自定义hdfs应该如何允许/拒绝对多个资源的访问。

游侠的强大和灵活来自于它的可配置性。不需要任何配置文件和应用的重启，访问控制就能发挥重要作用。

本章让您详细了解了大数据是如何管理的，考虑到它是非结构化或半结构化的，并且到达率快、容量大。

随着业务组织中生成和使用数据的基础架构的复杂性急剧增加，正确保护您的数据变得势在必行。本章进一步介绍了数据安全工具，如 Apache Ranger，以及帮助我们学习如何控制数据访问模式的模式。

在下一章中，我们将了解 Hadoop 安装、其体系结构和关键组件。

大数据不一定意味着大数据。如果数据集很小，分析它非常容易。我们可以将其加载到 Excel 电子表格中，并进行所需的计算。但是，随着数据量越来越大，我们必须找到其他方法来处理它。我们可能必须将其加载到一个 RDMBS 表中，并运行一个 SQL 查询来查找给定结构的趋势和模式。此外，如果数据集格式更改为类似电子邮件的格式，那么加载到关系数据库管理系统将成为一个巨大的挑战。更复杂的是，如果数据速度变得像实时一样，用传统的基于关系数据库管理系统的工具分析给定的数据集几乎是不可能的。在现代世界中，术语大数据可以用五个最著名的 V s 来表示，以下是每个 V 的简单解释。

在本章中，我们将涵盖以下主题:

让我们来看看一些重要的数据架构原则:

既然我们已经了解了大数据的基础知识及其原理，让我们开始一些实际行动吧。

安装 Hadoop 集群需要执行以下步骤。在撰写本书时，Hadoop 2 . 7 . 3 版本是一个稳定的版本。我们会安装它。

假设我们有四个服务器，我们必须使用所有四个服务器创建一个 Hadoop 集群。这四个服务器的 IPs 如下:192.168.11.1、192.168.11.2、192.168.11.3、192.168.11.4。在这四个服务器中，我们将首先使用一个服务器作为主服务器(名称节点)，其余所有服务器都将作为从服务器(数据节点)。

使用这些值查找并更改以下属性:

以下代码用于格式化名称节点:

我们用以下代码行启动所有服务:

HDFS 建筑基于主模式和从模式。名称节点是主节点，所有数据节点都是从属节点。以下是关于这两个节点需要注意的一些要点。

名称节点是 Hadoop 集群中所有数据节点的主节点。它只存储以树的形式存储的文件和目录的元数据。重要的一点是，除了元数据，NameNode 从不存储任何其他数据。名称节点跟踪以块的形式写入数据节点的所有数据。默认块大小为 256 兆字节(可配置)。没有名称节点，就无法读取数据节点文件系统上的数据。元数据使用两个文件本地存储在名称节点上——文件系统名称空间映像文件、FSImage 和编辑日志。FSImage 是从 NameNode 编辑日志开始的文件系统的快照—自 NameNode 启动以来文件系统的所有更改，当 NameNode 启动时，它读取 FSImage 文件并编辑日志文件。所有的事务(编辑)都被合并到 FSImage 文件中。将 FSImage 文件写入磁盘，并创建一个新的空编辑日志文件来记录所有编辑。由于名称节点不经常重新启动，编辑日志文件变得非常大，难以管理。重新启动名称节点时，需要很长时间才能重新启动，因为所有编辑都需要应用到 FSImage 文件。在名称节点崩溃的情况下，编辑日志文件中的所有元数据都不会写入 FSImage 文件，并且会丢失。

辅助名称节点的名称令人困惑。它不充当名称节点。它的主要功能是从名称节点获取文件系统更改，并定期将其合并到名称节点 FSImage。将编辑日志文件更改写入 FSImage 称为提交。定期提交有助于减少名称节点的启动时间。辅助名称节点也称为提交节点。

这是 HDFS 群集的只读模式。不允许客户端对文件系统或块进行任何修改。在启动过程中，NameNode 自动以安全模式启动，对 FSImage 应用编辑，自动禁用安全模式，并以正常模式重新启动。

数据节点是 Hadoop 集群的主力。它们的主要功能是以块的形式存储和检索数据。他们总是以心跳的形式向名称节点传达他们的状态。这就是名称节点跟踪任何数据节点的方式，无论它们是活的还是死的。数据节点保留已知数据块和复制因子的三个副本。数据节点与其他数据节点通信，以复制数据块来维护数据复制。

HDFS 体系结构支持将非常大的文件放置在集群中的机器上。每个文件都存储为一系列块。为了确保容错，每个数据块将被复制三次到三台不同的机器上。它被称为复制因子，可以在群集级别或单个文件级别进行更改。它是一个命名节点，负责做出与数据块复制相关的所有决策。名称节点从每个数据节点获取心跳和块报告。心跳确保数据节点是活动的。块报告包含数据节点上所有块的列表。

HDFS 数据块放置将通过将一个数据块副本放置在不同的机架上，使用机架感知来实现容错，如下图所示:

让我们详细了解一下图:

下表显示了 HDFS 网络界面中的服务:

另一个资源协商者 ( Yarn)分离资源管理、调度和处理组件。它有助于实现集群资源的 100%资源利用率。Yarn 基于 Hadoop 调度策略管理集群的中央处理器和内存。Yarn 支持任何类型的应用，并不仅限于 MapReduce。它支持用任何类型的语言编写的应用，前提是可以在 Hadoop 集群上安装二进制文件。

让我们在接下来的章节中详细了解 Yarn 的架构。

资源管理器负责跟踪集群中的资源并调度应用。资源管理器有两个主要组件:调度器和应用管理器。

节点管理器负责启动和管理节点上的容器。容器执行应用主服务器指定的任务。它充当资源管理器的从属。每个节点管理器跟踪其从属节点上的可用数据处理资源，并定期向资源管理器发送报告。Hadoop 集群中的处理资源消耗在称为容器的字节大小的块中。

您可以执行以下步骤来配置 Yarn:

Find corresponding XML files based on your Hadoop installation.

Hadoop 1.x 从单个 NameNode 的架构开始。所有用于向该单一名称节点发送数据块报告的数据节点。架构中有一个辅助名称节点，但它的唯一职责是合并对 FSImage 的所有编辑。通过这种架构，名称节点成为了单点故障 ( SPOF )。由于它拥有 Hadoop 集群所有数据节点的所有元数据，因此在 NameNode 崩溃的情况下，Hadoop 集群在下次重启 NameNode 修复之前不可用。如果名称节点无法恢复，则所有数据节点中的所有数据都将完全丢失。如果关闭名称节点进行计划维护，HDFS 将无法正常使用。因此，有必要通过频繁备份名称节点文件系统来保护现有的名称节点，以最大限度地减少数据丢失。

为了克服 HDFS 高可用性 ( HA )问题，让 NameNode 成为 SPOF，架构发生了变化。新的体系结构提供了在同一个群集中运行两个冗余名称节点的主动/被动配置和一个热备盘。这允许在机器崩溃的情况下快速故障切换到新的名称节点，或者出于计划维护的目的由管理员发起的正常故障切换。HDFS 高可用性提供了以下两种体系结构选项:

下图描述了 HDFS 高可用性集群使用 NFS 作为名称节点体系结构所需的共享存储:

关于使用共享存储体系结构的 HDFS 高可用性，需要记住以下几点:

下图描述了仲裁日志管理器 ( QJM )体系结构，用于在活动和备用名称节点之间共享编辑日志:

关于使用 QJM 架构的 HDFS 高可用性，需要记住以下几点:

非常重要的是要知道，上述两种体系结构仅支持手动故障转移。为了实现自动故障转移，我们必须引入两个额外的组件 ZooKeeper quorum，以及ZKFailoverController(ZKFC)流程和更多的配置更改。

众所周知，Hadoop 集群由主服务器和从服务器组成:主节点——管理基础设施，从节点——分布式数据存储和数据处理。边缘节点不是 Hadoop 集群的一部分。该机器用于与 Hadoop 集群交互。用户没有任何权限直接登录到任何主节点和数据节点，但是他们可以登录到边缘节点来运行 Hadoop 集群上的任何作业。EdgeNode 上没有存储任何应用数据。数据始终存储在 Hadoop 集群的数据节点上。根据在 Hadoop 集群上运行作业的用户数量，可以有多个 EdgeNode。如果有足够的硬件可用，最好将每个主节点和数据节点托管在单独的机器上。但是，在典型的 Hadoop 集群中，有三个主节点。

请注意，假设我们将 HBase 用作群集中的 NoSQL 数据存储。

Hadoop 集群组合如下所示:

以下是一些需要考虑的硬件规格:

就处理器而言，建议至少有 2 个运行在 2 千兆赫的四核处理器，以处理主节点的消息流量。

以下是 Hadoop 部署应遵循的一些最佳实践:

在 Hadoop 中，有许多可用的文件格式。用户可以根据用例选择任何格式。每种格式在存储和性能方面都有特殊的功能。让我们详细讨论每种文件格式。

文本和 CSV 文件在 Hadoop 数据处理算法中非常常见。文件中的每一行都被视为新记录。通常，每行以 n 字符结束。这些文件不支持列标题。因此，在处理时，总是需要额外的一行代码来删除列标题。CSV 文件通常使用 GZIP 编解码器压缩，因为它们不支持块级压缩；这增加了更多的加工成本。不用说，它们不支持模式演化。

JSON 格式在所有现代编程语言中都变得非常流行。这些文件是集合名称/值对。JSON 格式通常用于数据交换应用，它被视为对象、记录、结构或数组。这些文件是文本文件，支持模式演化。从 JSON 文件中添加或删除属性非常容易。与文本/CSV 文件一样，JSON 文件不支持块级压缩。

Avro 是 Hadoop 社区中广泛使用的文件类型。它之所以受欢迎，是因为它有助于模式进化。它包含二进制格式的序列化数据。Avro 文件是可拆分的，支持块压缩。它包含数据和元数据。它使用一个单独的 JSON 文件来定义模式格式。当 Avro 数据存储在一个文件中时，它的模式也随之存储，这样文件以后可以被任何程序处理。如果读取数据的程序期望不同的模式，这很容易解决，因为两种模式都存在。

拼花地板以扁平柱状格式存储嵌套数据结构。在存储和性能方面，拼花比任何行级文件格式都更高效。Parquet 以面向列的方式存储二进制数据。在拼花格式中，新的列被添加到结构的末尾。Cloudera 主要支持 Impala 实现的这种格式，但最近变得非常流行。这种格式对于 SQL 查询很好，因为只有选择性的列被读取以降低输入输出成本，所以 SQL 查询从具有许多列的宽表中读取特定的列。

ORC 文件是优化的记录列文件格式，是 RC 文件的扩展版本。这些非常适合压缩，并且最适合 Hive 读取、写入和处理数据以减少访问时间和存储空间时的 Hive SQL 性能。这些文件不支持真正的模式演化。它们主要由 Hortonworks 支持，不适合 Impala SQL 处理。

答案是:这取决于你的用例。通常，选择文件格式的标准基于查询读取和查询写入性能。此外，这取决于您使用的 Hadoop 发行版。ORC 文件格式对于使用 Hortonworks 发行版的 Hive 和 Tez 来说是最好的，对于 Cloudera Impala 实现来说，建议使用拼花文件。对于涉及模式演化的用例，Avro 文件是最适合的。如果要使用 Sqoop 从 RDBMS 导入数据，文本/CSV 文件格式是更好的选择。对于存储地图中间输出，序列文件是最终选择。

在本章中，主要目的是了解各种 Hadoop 设计替代方案。说到 Hadoop 集群及其在典型生产环境中部署的最佳实践，我们学到了很多。我们从对 Hadoop 的基本了解开始，然后开始 Hadoop 配置、安装和 HDFS 架构。我们还了解了实现 HDFS 高可用性的各种技术。我们还研究了 Yarn 架构。最后，我们研究了各种文件格式，以及如何根据您的用例选择一种格式。

在下一章中，我们将看到如何将数据摄取到新创建的 Hadoop 集群中。

在最后一章中，我们学习了如何创建和配置 Hadoop 集群、HDFS 体系结构、各种文件格式以及 Hadoop 集群的最佳实践。我们还学习了 Hadoop 高可用性技术。

因为我们现在知道如何创建和配置 Hadoop 集群，所以在本章中，我们将了解将数据摄入 Hadoop 集群的各种技术。我们知道 Hadoop 的优势，但是现在，我们需要 Hadoop 集群中的数据来利用它的真正力量。

数据摄取被认为是 Hadoop 数据生命周期的第一步。数据可以以批处理或(实时)记录流的形式被吸收到 Hadoop 中。Hadoop 是一个完整的生态系统，MapReduce 是 Hadoop 的批处理生态系统。

下图显示了各种数据摄取工具:

在接下来的几节中，我们将详细了解每种工具。

在本章中，我们将介绍以下在 Hadoop 集群之间传输数据的方法:

在我们深入研究不同的数据摄取技术之前，让我们讨论一下批处理和实时(流)处理之间的区别。下面解释这两种生态系统的区别。

以下各点描述了批处理系统:

以下几点描述了实时处理与批处理的区别:

Apache Sqoop 是一种工具，旨在高效地在 Hadoop 集群和结构化数据存储(如关系数据库)之间传输大量数据。在典型的用例中，例如数据湖，总是需要将数据从基于关系数据库管理系统的数据仓库存储导入到 Hadoop 集群中。在数据导入和数据聚合之后，需要将数据导出回 RDBMS。Sqoop 允许从结构化数据存储(如关系数据库管理系统、企业数据仓库和 NoSQL 系统)轻松导入和导出数据。在 Sqoop 的帮助下，数据可以从外部系统调配到 Hadoop 集群中，并填充 Hive 和 HBase 中的表。Sqoop 使用基于连接器的架构，该架构支持插件来提供与外部系统的连接。在内部，Sqoop 使用 MapReduce 算法来导入和导出数据。默认情况下，所有 Sqoop 作业运行四个地图作业。在接下来的几节中，我们将详细了解 Sqoop 的导入和导出功能。

下图显示了将数据从关系数据库管理系统表导入到 Hadoop 集群的 Sqoop 导入功能:

以下是将数据导入 HDFS 的示例命令:

导入分两步完成，如下所示。

导入的数据保存在 HDFS 文件夹中。用户可以指定替代文件夹。导入的数据根据导入的表保存在 HDFS 的一个目录中。与 Sqoop 操作的大多数方面一样，用户可以指定任何替代目录来填充文件。通过显式指定字段分隔符和记录终止符，可以轻松覆盖数据复制的格式。用户可以使用不同的格式，如 Avro、ORC、Parquet、序列文件、文本文件等，将文件存储到 HDFS，例如，将 MySQL 表导入 HDFS。下面是一个将 MySQL 表导入 HDFS 的示例:

在命令提示符下，运行以下sqoop命令导入 MySQL 销售数据库表customer:

验证 HDFS 的customer文件夹，如下所示:

让我们创建一个外部 Hive 表来验证记录，如下面的代码片段所示:

| 卡斯特姆 | 成本 Fname | cust lname | 客户地址 | 城市 | 状态 | zip || one | 詹姆斯 | 屁股 | 北蓝胶街 6649 号 | 新奥尔良 | 在那里 | Seventy thousand one hundred and sixteen || Two | 艺术 | Venere 8 | W Cerritos 鸟#54 | 布里奇波特 | 新泽西州 | Eight thousand and fourteen || three | 莉娜？莉娜 | 爸爸的外套 | 主街 639 号 | 安克雷奇 | 阿拉斯加 | Ninety-nine thousand five hundred and one || four | 唐娜蒂 | folder(文件夹) | 中心街 34 号 | 哈密尔顿 | 俄亥俄州 | Forty-five thousand and eleven || five | 新美乐股份公司 | 莫拉斯卡 | 3 Mcauley 博士 | 亚什兰 | 俄亥俄州 | Forty-four thousand eight hundred and five || six | 御津... | 托尔纳 | 7 Eads St | 芝加哥 | 伊利诺伊 | Sixty thousand six hundred and thirty-two || seven | 利奥塔 | -比利 | 杰克逊大道西 7 号 | 圣何塞 | 加拿大 | Ninety-five thousand one hundred and eleven || eight | 明智的 | 维什尔 | 波士顿大道 5 号 88 | 苏福尔斯 | 南达科他州 | Fifty-seven thousand one hundred and five || nine | 克里斯 | 结婚的人 | 228 Runamuck Pl 编号 2808 | 巴尔的摩 | 医学博士 | Twenty-one thousand two hundred and twenty-four || Ten | 米娜 | 哥们儿 | 杰罗德大街 2371 号 | 煤炭村 | 和 | Nineteen thousand four hundred and forty-three |

以下是将 MySQL 表导入到 Hive 的示例:

验证表格配置单元:

您将看到customer_H表是在默认数据库下创建的。如果要在不同的数据库下创建customer_H表，例如销售数据库，必须提前创建销售数据库。另外，您必须将-hive-table参数更改为--hive-table销售cutomer_H增量负载(仅插入)。典型的数据加载要求是只加载源表中发生的增量更改。假设一个新客户11被插入到源customer MySQL 表中:

为了只容纳新记录(即客户 11)，我们必须在原始的sqoop命令中添加一些额外的参数。新的sqoop命令如下:

运行此命令后，Sqoop 将只拾取新行(即cust_num，也就是11):

| 卡斯特姆 | 成本 Fname | cust lname | 客户地址 | 城市 | 状态 | zip || one | 詹姆斯 | 屁股 | 北蓝胶街 6649 号 | 新奥尔良 | 在那里 | Seventy thousand one hundred and sixteen || Two | 艺术 | Venere 8 | W Cerritos 鸟#54 | 布里奇波特 | 新泽西州 | Eight thousand and fourteen || three | 莉娜？莉娜 | 爸爸的外套 | 主街 639 号 | 安克雷奇 | 阿拉斯加 | Ninety-nine thousand five hundred and one || four | 唐娜蒂 | folder(文件夹) | 中心街 34 号 | 哈密尔顿 | 俄亥俄州 | Forty-five thousand and eleven || five | 新美乐股份公司 | 莫拉斯卡 | 3 Mcauley 博士 | 亚什兰 | 俄亥俄州 | Forty-four thousand eight hundred and five || six | 御津... | 托尔纳 | 7 Eads St | 芝加哥 | 伊利诺伊 | Sixty thousand six hundred and thirty-two || seven | 利奥塔 | -比利 | 杰克逊大道西 7 号 | 圣何塞 | 加拿大 | Ninety-five thousand one hundred and eleven || eight | 明智的 | 维什尔 | 波士顿大道 5 号 88 | 苏福尔斯 | 南达科他州 | Fifty-seven thousand one hundred and five || nine | 克里斯 | 结婚的人 | 228 Runamuck Pl 编号 2808 | 巴尔的摩 | 医学博士 | Twenty-one thousand two hundred and twenty-four || Ten | 米娜 | 哥们儿 | 杰罗德大街 2371 号 | 煤炭村 | 和 | Nineteen thousand four hundred and forty-three || Eleven | 亚伯 | 麦克劳德 | 东 75 街 25 号 69 号 | 洛杉矶 | 加拿大 | Ninety thousand and thirty-four |

对于增量负载，我们不能直接使用 Sqoop 导入来更新数据。

| 卡斯特姆 | 成本 Fname | cust lname | 客户地址 | 城市 | 状态 | zip || four | 唐娜蒂 | folder(文件夹) | 中心街 34 号 | 哈密尔顿 | 俄亥俄州 | Forty-five thousand and eleven || five | 新美乐股份公司 | 莫拉斯卡 | 3 Mcauley 博士 | 亚什兰 | 俄亥俄州 | Forty-four thousand eight hundred and five |

以下是将数据导入到 HBase 表的示例命令:

Sqoop 将数据导入 HBase 表列族。数据被转换并以 UTF 8 字节格式插入。

下图显示了从 Hadoop 集群中导出数据的 Sqoop 导出功能:

额外的业务功能可能需要在类似数据湖的用例中处理的数据。Sqoop 可用于将数据从 HDFS 或从 Hive 表中导出回 RDBMS。在将数据导出回 RDBMS 表的情况下，目标表必须存在于 MySQL 数据库中。HDFS 文件中的行或配置单元表中的记录作为sqoop命令的输入，被称为目标表中的行。这些记录被读取并解析成一组记录，并用用户指定的分隔符进行分隔。

以下是将数据从 HDFS 导出到 MySQL 表的命令。让我们在 MySQL 中创建一个表来存储从 HDFS 导出的数据:

--table参数指定将要填充的表格。Sqoop 分割数据，并使用单独的地图任务将分割结果推送到数据库中。每个地图任务都执行实际的数据传输。--export-dir <directory h>是导出数据的目录:

| 卡斯特姆 | 成本 Fname | cust lname | 客户地址 | 城市 | 状态 | zip || one | 詹姆斯 | 屁股 | 北蓝胶街 6649 号 | 新奥尔良 | 在那里 | Seventy thousand one hundred and sixteen || Two | 艺术 | Venere 8 | W Cerritos 鸟#54 | 布里奇波特 | 新泽西州 | Eight thousand and fourteen || three | 莉娜？莉娜 | 爸爸的外套 | 主街 639 号 | 安克雷奇 | 阿拉斯加 | Ninety-nine thousand five hundred and one || four | 唐娜蒂 | folder(文件夹) | 中心街 34 号 | 哈密尔顿 | 俄亥俄州 | Forty-five thousand and eleven || five | 新美乐股份公司 | 莫拉斯卡 | 3 Mcauley 博士 | 亚什兰 | 俄亥俄州 | Forty-four thousand eight hundred and five || six | 御津... | 托尔纳 | 7 Eads St | 芝加哥 | 伊利诺伊 | Sixty thousand six hundred and thirty-two || seven | 利奥塔 | -比利 | 杰克逊大道西 7 号 | 圣何塞 | 加拿大 | Ninety-five thousand one hundred and eleven || eight | 明智的 | 维什尔 | 波士顿大道 5 号 88 | 苏福尔斯 | 南达科他州 | Fifty-seven thousand one hundred and five || nine | 克里斯 | 结婚的人 | 228 Runamuck Pl 编号 2808 | 巴尔的摩 | 医学博士 | Twenty-one thousand two hundred and twenty-four || Ten | 米娜 | 哥们儿 | 杰罗德大街 2371 号 | 煤炭村 | 和 | Nineteen thousand four hundred and forty-three |

Flume 是一种可靠、可用且分布式的服务，可高效地收集、聚合和传输大量日志数据。它具有基于流式数据流的灵活简单的体系结构。Apache Flume 的当前版本是 1.7.0，于 2016 年 10 月发布。

下图描述了 ApacheFlume 的结构:

让我们仔细看看 ApacheFlume 架构的组件:

整个 Flume 代理在一个 JVM 进程中运行，该进程包括所有组件(源、通道和接收器)。Flume 源从外部源接收事件，如网络服务器、外部文件等。信源将事件推送到信道，信道存储事件，直到被信宿接收。通道将有效负载(消息流)存储在本地文件系统或内存中，具体取决于源的类型。例如，如果源是文件，则有效负载存储在本地。接收器从信道获取有效负载，并将其推送到外部数据存储。代理内的源和接收器异步运行。有时，Flume 可能会将有效载荷推送到另一个 Flume 代理。我们将在下一节讨论这个场景。

请注意，这不是一个好的架构，但我提到它是为了解释 FlumeFlume 和 Flume 源如何连接。

下图显示了涉及多个代理的复杂数据流:

| 来源 | 描述 || 我有消息来源 | 侦听 Avro 端口并从外部 Avro 客户端流接收事件 || 执行源 | 运行一个给定的 Unix 命令，并期望该过程能够持续地以标准输出方式产生数据 || 假脱机目录源 | 从磁盘上的文件中获取数据 || Taildir 源 | 在文件中检测到新行后，几乎实时跟踪文件 || 卡夫卡来源 | 阅读卡夫卡主题的信息 || 系统日志源 | 读取系统日志数据(支持系统日志-TCP 和系统日志-UDP) || HTTP 源 | 通过 HTTP POST和GET接受 Flume 事件 |

广泛使用的 Flume 可总结如下:

| Flume | 描述 || 阿夫罗锌 | 事件被转换为 Avro 事件，并发送到配置的主机名/端口对 || HDFS Flume | 将事件写入 HDFS || HiveFlume | 将文本或 JSON 数据写入 Hive 表 || 氢碱锌 | 将数据写入 HBase || 吗啡太阳沉 | 几乎实时地将其加载到 Apache Solr 服务器中 || Elasticsearch sink | 将数据写入弹性搜索集群 || 卡夫卡 Flume | 将数据写入卡夫卡的主题 |

广泛使用的 Flume 渠道(总结)如下:

| 通道 | 描述 || JDBC 海峡 | 事件存储在数据库支持的存储中 || 卡夫卡频道 | 事件存储在卡夫卡集群中 || 文件通道 | 事件存储在文件中 || 可溢出存储通道 | 事件存储在内存中；如果内存已满，则存储在磁盘上 |

广泛使用的 Flume 拦截器可总结如下:

| 拦截器 | 描述 || 时间戳拦截器 | 将事件的处理时间添加到事件标题中 || 主机拦截器 | 添加代理的主机名 || 搜索并替换拦截器 | 支持 Java 正则表达式 || Regex 过滤拦截器 | 根据正则表达式过滤事件 || Regex 提取拦截器 | 提取并追加匹配的正则表达式组作为事件的头 |

在日常业务场景中，我们总是发现需要获取日志文件并从中获取意义。例如，我们总是发现需要从不同的应用和服务器获取日志，并将它们合并在一起以发现趋势和模式。让我进一步扩展这个例子。让我们假设我们有五个 web 服务器部署在五个不同的服务器上。我们希望获得所有五个网络服务器日志，并将它们合并/聚合在一起，通过将一个副本存储在 HDFS，另一个副本将被发送到卡夫卡主题进行实时分析来进一步分析它们。问题是我们如何设计基于 Flume 的日志聚合架构。以下是我们的网络服务器日志聚合场景的 Flume 体系结构:

什么是 Apache NiFi？在任何组织中，我们都知道有各种各样的系统。一些系统生成数据，而其他系统使用这些数据。Apache NiFi 是为了自动化从一个系统到另一个系统的数据流而构建的。Apache NiFi 是一个数据流管理系统，附带一个 web UI，帮助实时构建数据流。它支持基于流的编程。图形编程包括一系列数据移动通过的节点和边。在 NiFi 中，这些节点被转换成处理器，边缘被转换成连接器。数据存储在一个名为流文件的信息包中。该流文件包括内容、属性和边缘。作为用户，您使用连接器将处理器连接在一起，以定义应该如何处理数据。

下表描述了 Apache NiFi 的主要组件:

| 组件名称 | 描述 || 流文件 | 在系统中运行的数据包 || 流文件处理器 | 执行数据路由、转换和数据移动的实际工作 || connection-连线 | 处理器之间的实际数据链接 || 流量控制器 | 促进处理器之间的流文件交换 || 流程组 | 数据输入和数据输出处理器的特定组 |

这些组件如下:

以下是 Apache NiFi 的主要特性:

让我们想象一个场景。我有一个运行日志文件。它是动态更新的。我想根据文件的内容捕获并监控其中的每一行。我想发给我的卡夫卡经纪人。我还想把我所有的错误记录送到 HDFS 存档和进一步分析。不同的线路类型会发给不同的卡夫卡经纪人。例如，错误、信息和成功类型将被发送到三个不同的卡夫卡主题，即错误、信息和成功。为此，我开发了以下 NiFi 工作流。下表给出了每个处理器的详细说明:

以下示例工作流显示了如何将日志文件数据推送到 HDFS，然后再移动到卡夫卡经纪人那里:

卡夫卡连接是 Apache 卡夫卡的一部分。它是一个使用连接器将数据从一个系统摄取到另一个系统的框架。连接器有两种类型:源连接器和接收器连接器。接收器连接器从源系统导入数据，并写入卡夫卡主题。接收器连接器从卡夫卡主题中读取数据，并将其导出到目标系统。Kafka Connect 提供开箱即用的各种信号源和接收器连接器。

Kafka Connect 主要于 2015 年 11 月在 Kafka 0.9.x 中推出，除了 Kafka 0.9.x 的各种功能外，Connect APIs 还是一个全新的功能。随后，2016 年 5 月，新版卡夫卡 0.10.0 发布。在那个版本中，卡夫卡流应用编程接口是一个新的和令人兴奋的功能。但是，在 2017 年 3 月，正是卡夫卡版本 0.10.2，卡夫卡连接获得了真正的动力。作为 Kafka 0.10.2 的一部分，发布了改进的简化连接 API 和单消息转换 API。

以下是卡夫卡连接的一些特征:

下图展示了卡夫卡连接架构:

卡夫卡集群由卡夫卡经纪人组成:三个经纪人，如图所示。来源可以是任何类型，例如，数据库、NoSQL、推特等等。在源和卡夫卡集群之间，有一个由工人组成的卡夫卡连接集群。卡夫卡连接的工作包括以下步骤:

一些卡夫卡连接的概念如下:

卡夫卡连接工人有两种模式:

独立模式是运行所有连接器和任务的单个进程(工作进程)。配置捆绑在一个流程中。它不容错也不可扩展，而且很难监控。由于它易于设置，所以主要用于开发和测试期间。

在分布式模式下，多个工作人员(进程)运行您的连接器和任务。使用 REST 应用编程接口提交配置。它是可扩展的和容错的。如果有任何工作人员死亡，它会自动重新平衡集群上的所有任务。由于它具有可伸缩性和容错性，因此主要用于生产环境。

以下是 Kafka Connect 集群分布式体系结构细节的表示:

在上图中，我们可以看到以下细节:

下图显示了重新平衡后的卡夫卡连接集群:

在本章中，我们学习了生产环境中使用的所有流行的数据摄取工具。Sqoop 主要用于将数据导入和导出 RDBMS 数据存储。Apache Flume 在实时系统中用于导入数据，主要来自文件源。它支持各种各样的源和汇。Apache NiFi 是一个相当新的工具，最近变得非常流行。它还支持基于图形用户界面的 ETL 开发。自 HDP 2.4 版本发布以来，Hortonworks 已经开始支持该工具。Apache Kafka Connect 是市场上另一个流行的工具。它也是融合数据平台的一部分。Kafka Connect 可以将整个数据库或从所有应用服务器收集的指标摄取到 Kafka 主题中，使数据可用于低延迟的流处理。

由于到目前为止我们已经知道如何构建 Hadoop 集群以及如何在其中摄取数据，我们将在下一章学习数据建模技术。

到目前为止，我们已经学习了如何创建 Hadoop 集群以及如何将数据加载到其中。在前一章中，我们学习了各种数据摄取工具和技术。正如我们现在所知，市场上有各种各样的开源工具，但是有一个单一的银弹工具可以承担我们所有的用例。每个数据摄取工具都有某些独特的功能；在典型的用例中，它们可以被证明是非常有效和有用的。例如，当用于从关系数据库管理系统导入和导出 Hadoop 数据时，Sqoop 更有用。

在本章中，我们将学习如何在 Hadoop 集群中存储和建模数据。像数据摄取工具一样，也有各种可用的数据存储。这些数据存储支持不同的数据模型——即列数据存储、键值对等；而且它们支持各种文件格式，比如 ORC、Parquet 和 AVRO 等等。有非常受欢迎的数据存储，这些天在生产中被广泛使用，例如，Hive、HBase、Cassandra 等等。我们将进一步了解以下两种数据存储和数据建模技术:

首先，我们将从基本概念开始，然后我们将学习如何应用现代数据建模技术来加快数据访问。简而言之，我们将在本章中讨论以下主题:

Hive 是 Hadoop 中的一个数据处理工具。正如我们在上一章中了解到的，数据摄取工具在 Hadoop 中加载数据并生成 HDFS 文件；我们需要根据我们的业务需求来查询这些数据。我们可以使用 MapReduce 编程访问数据。但是使用 MapReduce 进行数据访问非常慢。要访问几行 HDFS 文件，我们必须编写单独的映射器、减速器和驱动程序代码。所以，为了避免这种复杂性，Apache 引入了 Hive。Hive 支持一个类似于 SQL 的接口，该接口有助于使用 SQL 命令访问相同行的 HDFS 文件。Hive 最初由脸书开发，但后来被 Apache 公司接管。

我提到 Hive 提供了一个类似 SQL 的接口。考虑到这一点，出现的问题是:Hive 和 Hadoop 上的 RDBMS 一样吗？答案是没有。Hive 不是数据库。Hive 不存储任何数据。Hive 将表信息存储为元数据的一部分，称为模式，并指向 HDFS 的文件。Hive 使用名为 HiveQL ( HQL )的类似 SQL 的接口访问存储在 HDFS 文件中的数据。Hive 支持在 HDFS 访问和修改数据的 SQL 命令。Hive 不是 OLTP 的工具。它不提供任何行级插入、更新或删除。Hive 的当前版本(0.14 版本)确实支持使用完整的 ACID 属性进行插入、更新和删除，但是该功能效率不高。此外，此功能不支持所有文件格式。例如，更新仅支持 ORC 文件格式。基本上，Hive 是为批处理而设计的，不像 RDBMS 那样支持事务处理。因此，Hive 更适合数据仓库应用，用于提供数据汇总、查询和分析。在内部，Hive SQL 查询由其编译器转换为 MapReduce。用户无需担心编写任何复杂的映射器和缩减器代码。Hive 仅支持查询结构化数据。使用 Hive SQL 访问非结构化数据非常复杂。您可能需要为此编写自己的自定义函数。Hive 支持各种文件格式，如文本文件、序列文件、ORC 和 Parquet，它们提供了显著的数据压缩。

Hive 版本 0.14 支持以下数据类型:

| 数据类型组 | 数据类型 | 格式 || 线 | STRING | column_name STRING || VARCHAR | column_name VARCHAR(max_length) || CHAR | column_name CHAR(length) || 数字的 | TINYINT | column_name TINYINT || SMALLINT | column_name SMALLINT || INT | column_name INT || BIGINT | column_name BIGINT || FLOAT | column_name FLOAT || DOUBLE | column_name DOUBLE || DECIMAL | column_name DECIMAL[(precision[,scale])] || 日期/时间类型 | TIMESTAMP | column_name TIMESTAMP || DATE | column_name DATE || INTERVAL | column_name INTERVAL year to month || 杂项类型 | BOOLEAN | column_name BOOLEAN || BINARY | column_name BINARY || 复数型 | ARRAY | column_name ARRAY < type > || MAPS | column_name MAP < primitive_type, type > || STRUCT | column_name STRUCT < name : type [COMMENT 'comment_string'] > || UNION | column_name UNIONTYPE <int, double, array, string> |

Hive 数据库由由分区组成的表组成。可以通过简单的查询语言访问数据，Hive 支持覆盖或追加数据。在特定的数据库中，表中的数据是序列化的，每个表都有一个对应的 HDFS 目录。每个表都可以细分为多个分区，这些分区决定了数据在表目录的子目录中的分布方式。分区内的数据可以进一步分解成桶。

以下是 Hive 架构的表示:

上图显示 Hive 架构分为三个部分——即客户端、服务和元存储。配置单元 SQL 的执行如下:

Hive 以以下四种方式处理数据:

我们将在接下来的章节中详细介绍它们。

配置单元表非常类似于任何关系数据库管理系统表。表格分为行和列。每个列(字段)都用正确的名称和数据类型定义。我们已经在支持的数据类型部分看到了 Hive 中所有可用的数据类型。配置单元表分为两种类型:

我们将在下面的章节中了解这两种类型。

以下是定义 Hive 托管表的示例命令:

当执行前面的查询时，Hive 会创建该表，元数据也会相应地在 metastore 中更新。但是桌子是空的。因此，可以通过执行以下命令将数据加载到该表中:

/user/hive/warehouse/<managed_table_name文件夹将被删除，存储在元存储中的元数据将被删除。

以下是定义 Hive 外部表的示例命令:

当执行前面的查询时，Hive 会创建该表，元数据也会相应地在 metastore 中更新。但是，同样，桌子是空的。因此，可以通过执行以下命令将数据加载到该表中:

该命令不会将任何文件移动到任何文件夹，而是创建一个指向文件夹位置的指针，并在 metastore 的元数据中进行更新。文件保持在查询的相同位置(<hdfs_folder_name>)。现在，如果我们决定删除该表，我们可以通过发出以下命令来完成:

文件夹/user/hive/warehouse/<managed_table_name不会被删除，只会删除元存储中存储的元数据。文件保留在同一个位置— <hdfs_folder_name>。

对表进行分区意味着根据分区键的值将表分成不同的部分。分区键可以是任何列，例如日期、部门、国家等。由于数据以部分形式存储，查询响应时间变得更快。分区不是扫描整个表，而是在主表文件夹中创建子文件夹。Hive 将根据查询的WHERE子句只扫描表的特定部分。配置单元表分区类似于任何 RDBMS 表分区。目的也是一样的。随着我们不断向表中插入数据，表的数据大小会变大。假设我们创建了一个ORDERS表，如下所示:

我们将加载如下示例文件ORDERS_DATA表，如下所示:

如下所示加载ORDERS_DATA表:

假设我们想在ORDERS_DATA表中插入城市数据。每个城市的订单数据大小为 1 TB。所以ORDERS_DATA表的总数据量为 15 TB(表中有 15 个城市)。现在，如果我们编写以下查询来获取在Los Angeles预订的所有订单:

查询将运行得非常慢，因为它必须扫描整个表。显而易见的想法是，我们可以为每个城市创建 10 个不同的orders表，并将orders数据存储在ORDERS_DATA表的相应城市中。但除此之外，我们可以对ORDERS_PART表进行如下划分:

对数据进行分区可以极大地提高查询的性能，因为数据已经根据列值被分离到文件中，这可以减少映射器的数量，并极大地减少生成的 MapReduce 作业中数据的洗牌和排序量。

如果您想在 Hive 中使用静态分区，应该按如下方式设置属性:

在前面的例子中，我们已经看到，我们必须将每个月度订单文件分别插入到每个静态分区中。与动态分区相比，静态分区节省了加载数据的时间。我们必须单独向表中添加一个分区，并将文件移动到表的分区中。如果我们有很多分区，编写一个查询来加载每个分区中的数据可能会变得很麻烦。我们可以通过动态分区来克服这个问题。在动态分区中，我们可以用一条 SQL 语句将数据插入分区表，但仍然在每个分区中加载数据。与静态分区相比，动态分区加载数据的时间更长。当表中存储了大量数据时，动态分区是合适的。如果您想对多个列进行分区，但不知道它们有多少列，那么动态分区也是合适的。以下是您应该允许的配置单元动态分区属性:

下面是一个动态分区的例子。假设我们要将数据从ORDERS_PART表加载到名为ORDERS_NEW的新表中:

将数据从ORDERS_PART表载入ORDER_NEW表。这里，Hive 将动态加载ORDERS_NEW表的所有分区:

让我们看看ORDERS_NEW中创建了多少分区:

现在很清楚何时使用静态和动态分区。在将数据加载到配置单元表中之前，如果事先知道分区列值，则可以使用静态分区。在动态分区的情况下，分区列值只有在将数据加载到配置单元表中时才知道。

分时段是一种将大型数据集分解成更易于管理的组的技术。分时段是基于散列函数的。当一个表被分时段时，所有具有相同列值的表记录将进入同一个时段。物理上，每个存储桶就像一个分区一样，是表文件夹中的一个文件。在分区表中，Hive 可以将数据分组到多个文件夹中。但是，当分区数量有限，并且数据在所有分区中平均分布时，分区证明是有效的。如果有大量的分区，那么它们的使用效率就会降低。所以在这种情况下，我们可以使用 bucketing。我们可以在创建表的过程中显式地创建多个桶。

下图详细显示了 Hive bucketing 的工作原理:

如果我们决定在一个表中为一列创建三个桶，在我们的示例中为(Ord_city)，那么 Hive 将创建三个桶，编号为 0-2 ( n-1 )。在记录插入期间，Hive 将对每条记录的Ord_city列应用哈希函数来决定哈希键。然后 Hive 将对每个哈希值应用一个模运算符。我们也可以在非分区表中使用 bucketing。但是，当分块特性用于分区表时，我们将获得最佳性能。倒挂有两个主要好处:

让我们考虑一下我们的ORDERS_DATA表示例。在CITY列中进行分区。可能并非所有城市的订单分配都是平等的。有些城市的订单可能比其他城市多。在这种情况下，我们将有不平衡的分区。这将影响查询性能。对订单多的城市的查询将比订单少的城市慢。我们可以通过打破僵局来解决这个问题。表中的桶由表 DDL 中的CLUSTER子句定义。以下示例详细解释了 bucketing 功能。

首先，我们将创建一个ORDERS_BUCK_non_partition表:

加载新创建的非分区桶表:

以下命令显示 Hive 已经在表中创建了四个存储桶(文件夹)00000[0-3]_0:

首先，我们将创建一个桶形分区表。这里，表在Ord_city列上被划分为四个桶，但又被细分为Ord_zip列:

用具有动态分区的另一个分区表(ORDERS_PART)加载分桶分区表:

配置单元视图是一个逻辑表。它就像任何 RDBMS 视图一样。概念是一样的。创建视图时，Hive 不会在其中存储任何数据。创建视图时，Hive 会冻结元数据。Hive 不支持任何 RDBMS 的物化视图概念。视图的基本目的是隐藏查询的复杂性。有时，HQL 包含复杂的连接、子查询或筛选器。在视图的帮助下，整个查询可以在虚拟表中展平。

当在基础表上创建视图时，对该表的任何更改，甚至添加或删除该表，都会在视图中失效。此外，创建视图时，它只更改元数据。但是当查询访问该视图时，它会触发 MapReduce 作业。视图是没有关联存储的纯逻辑对象(Hive 中目前不支持物化视图)。当查询引用视图时，将对视图的定义进行评估，以便生成一组行供查询进一步处理。(这是概念性的描述。事实上，作为查询优化的一部分，Hive 可能会将视图的定义与查询相结合，例如，将过滤器从查询下推到视图中。)

创建视图时，视图的架构被冻结；对基础表的后续更改(例如，添加一列)不会反映在视图的架构中。如果基础表以不兼容的方式被删除或更改，后续查询无效视图的尝试将会失败。视图是只读的，不能作为LOAD / INSERT / ALTER更改元数据的目标。视图可能包含ORDER BY和LIMIT条款。如果引用查询也包含这些子句，查询级子句将在 view 子句之后(以及查询中的任何其他操作之后)进行计算。例如，如果一个视图指定了LIMIT 5，一个引用查询作为(select * from v LIMIT 10)执行，那么最多将返回五行。

让我们看几个观点的例子:

我将使用以下几个例子来演示视图的优势。假设我们有两个表，Table_X和Table_Y，模式如下:Table_XXCol_1弦、XCol_2弦、XCol_3弦、Table_YYCol_1弦、YCol_2弦、YCol_3弦和YCol_4弦。要创建与基表完全相同的视图，请使用以下代码:

要在基表的选定列上创建视图，请使用以下命令:

要创建一个视图来过滤基表列的值，我们可以使用:

要创建隐藏查询复杂性的视图:

主要区别在于将行的映射值存储在不同的块中。

在 HDFS，数据以块的形式存储。但是扫描哪个数据存储在哪个块中是很耗时的。紧凑索引存储索引列的值及其blockId。所以查询不会转到表中。相反，查询将直接转到紧凑索引，其中存储了列值和blockId。不需要扫描所有的块来寻找数据！因此，在执行查询时，它将首先检查索引，然后直接进入该块。

位图索引将索引列值和行列表的组合存储为位图。位图索引通常用于具有不同值的列。我们来回顾几个例子:基表、Table_XXCol_1整数、XCol_2字符串、XCol_3整数、XCol_4字符串。创建索引:

前面的索引是空的，因为它是用DEFERRED REBUILD子句创建的，不管表中是否包含任何数据。创建该索引后，需要使用REBUILD命令来构建索引结构。创建索引后，如果基础表中的数据发生变化，必须使用REBUILD命令更新索引。创建索引并将其存储在文本文件中:

创建位图索引:

JSON，是一种结构化数据的最小可读格式。它主要用于在服务器和 web 应用之间传输数据，作为 XML 的替代。JSON 建立在两种结构上:

创建外部配置单元表，simple_json_table:

现在验证记录:

创建外部配置单元表，json_nested_table:

核实记录:

在生产中，我们必须改变表结构来满足新的业务需求。必须更改表架构才能添加/删除/重命名表列。任何这些变化都会对下游的 ETL 作业产生负面影响。为了避免这些，我们必须对 ETL 作业和目标表进行相应的更改。

将记录插入customer表:

在 Hadoop 上，运行以下sqoop命令将customer表和 Avro 文件中的数据导入 HDFS:

验证目标 HDFS 文件夹:

创建一个 Hive 外部表来访问 Avro 文件:

验证 Hivecustomer表:

完美！我们没有错误。我们使用 Avro 序列化成功地将源customer表导入到目标 Hive 表中。现在，我们向源表中添加一列，并再次导入它，以验证我们可以在没有任何模式更改的情况下访问目标 Hive 表。连接到 MySQL 并再添加一列:

现在插入行:

在 Hadoop 上，运行以下sqoop命令导入customer表，以追加新的地址列和数据。我使用了append和where "cust_id > 4"参数只导入新行:

验证 HDFS 文件夹:

现在，让我们验证我们的目标 Hive 表仍然能够访问旧的和新的 Avro 文件:

太好了。没有错误。尽管如此，一切如常；现在，我们将向 Hive 表中添加一个新列，以查看新添加的 Avro 文件:

验证配置单元表中的新数据:

太棒了。看看客户号5和6。我们可以看到新添加的带有值的列(cust_state)。您可以使用相同的技术尝试删除列和替换列功能。现在，我们对如何使用 Apache Hive 访问数据有了一个相当好的想法。在下一节中，我们将了解如何使用 NoSQL 数据存储区 HBase 访问数据。

我们刚刚了解了 Hive，这是一个用户可以使用 SQL 命令访问数据的数据库。但是在某些数据库中，用户不能使用 SQL 命令。这些数据库被称为 NoSQL 数据存储。糖化血红蛋白酶是一个 NoSQL 数据库。那么，NoSQL 到底是什么意思呢？NoSQL 的意思不仅仅是 SQL。在像 HBase 这样的 NoSQL 数据存储中，RDBMS 的主要功能，如验证和一致性，都有所放松。此外，关系数据库管理系统或 SQL 数据库与 NoSQL 数据库之间的另一个重要区别是写模式与读模式。在写入时模式中，数据在写入表时被验证，而读取时模式支持在读取时验证数据。这样，由于在写入数据时放松了基本数据验证，NoSQL 数据存储支持存储巨大的数据速度。目前市场上大约有 150 家 NoSQL 数据存储。这些 NoSQL 数据存储中的每一个都有一些独特的功能。一些受欢迎的 NoSQL 数据存储是 HBase、Cassandra、MongoDB、Druid、Apache Kudu 和 Coculuo 等等。

HBase 是一个流行的 NoSQL 数据库，被许多大公司使用，如脸书、谷歌等。

下面解释了 HDFS 和糖化血红蛋白之间的主要区别。Hadoop 建立在 HDFS 之上，它支持存储大容量(千兆字节)的数据集。这些数据集使用批处理作业，通过使用 MapReduce 算法来访问。为了在如此庞大的数据集中找到一个数据元素，需要对整个数据集进行扫描。另一方面，HBase 建立在 HDFS 之上，为大型表提供快速的记录查找(和更新)。HBase 会在内部将您的数据放入 HDFS 上的索引存储文件中，以便进行高速查找。

HBase 是一个数据库管理系统；它支持事务处理和分析处理。Hive 是一个数据仓库系统，只能用于分析处理。HBase 支持低延迟和随机数据访问操作。Hive 只支持批处理，这导致了高延迟。HBase 不支持任何与表数据交互的 SQL 接口。您可能需要编写 Java 代码来读写 HBase 表中的数据。有时，处理涉及多个数据集连接的数据集时，Java 代码变得非常复杂。但是 Hive 支持用 SQL 进行非常简单的访问，这使得向其表中读写数据变得非常容易。在 HBase 中，数据建模涉及到灵活的数据模型和面向列的数据存储，必须支持数据反规格化。在向表中写入数据时，将决定 HBase 表的列。在 Hive 中，数据模型包括具有固定模式的表，如关系数据库管理系统数据模型。

以下是糖化血红蛋白酶的几个关键特性:

这些是糖化血红蛋白数据模型的关键组成部分:

我们都知道数据是如何存储在任何 RDBMS 表中的。看起来是这样的:

| ID | Column_1 | Column_2 | Column_3 | Column_4 || one | A | Eleven | P | xx || Two | B | Twelve | Q | YY || three | C | Thirteen | 稀有 | 锯齿形 || four | D | Fourteen | S | XX1 |

列标识用作表的唯一/主键，用于访问表中其他列的数据。但是在像 HBase 这样的面向列的数据存储中，同一个表被分为键和值，存储方式如下:

| 键 | 值 || 行 | 栏 | 列值 || one | Column_1 | A || one | Column_2 | 11 || one | Column_3 | P || one | Column_4 | XX || Two | Column_1 | B || Two | Column_2 | 12 || Two | Column_3 | Q || Two | Column_4 | YY || three | Column_1 | C || three | Column_2 | 13 || three | Column_3 | R || three | Column_4 | ZZ |

在 HBase 中，每个表都是一种排序的映射格式，其中每个键都按升序排序。在内部，每个键和值都被序列化，并以字节数组格式存储在磁盘上。每个列值都由其对应的键访问。因此，在上表中，我们定义了一个键，它是两列的组合，行+列。例如，为了访问第 1 行的Column_1数据元素，我们必须使用一个键，第 1 行+ column_1。这就是为什么行键设计在 HBase 中非常关键。在创建 HBase 表之前，我们必须为每一列确定一个列族。列族是列的集合，它们位于同一位置并存储在一起，通常是出于性能原因。每个列族都有一组存储属性，如缓存、压缩和数据编码。例如，在典型的CUSTOMER表中，我们可以定义两个列族，即cust_profile和cust_address。与客户地址相关的所有列都被分配到列族cust_address；所有其他列，即cust_id、cust_name和cust_age，都被分配给列族cust_profile。分配完列族后，我们的示例表如下所示:

| 键 | 值 || 行 | 栏 | 柱族 | 值 | 时间戳 || one | Column_1 | cf_1 | A | 1407755430 || one | Column_2 | cf_1 | 11 | 1407755430 || one | Column_3 | cf_1 | P | 1407755430 || one | Column_4 | cf_2 | XX | 1407755432 || Two | Column_1 | cf_1 | B | 1407755430 || Two | Column_2 | cf_1 | 12 | 1407755430 || Two | Column_3 | cf_1 | Q | 1407755430 || Two | Column_4 | cf_2 | YY | 1407755432 || three | Column_1 | cf_1 | C | 1407755430 || three | Column_2 | cf_1 | 13 | 1407755430 || three | Column_3 | cf_1 | R | 1407755430 || three | Column_4 | cf_2 | ZZ | 1407755432 |

如果我们想从一个糖化血红蛋白表中读取数据，我们必须给出一个合适的行标识，糖化血红蛋白将根据给定的行标识执行查找。HBase 使用以下排序的嵌套映射来返回行 ID 的列值:行 ID、列族、时间戳处的列和值。HBase 始终部署在 Hadoop 上。以下是典型安装:

它是 HBase 群集的主服务器，负责区域服务器的管理、监视和管理，例如将区域分配给区域服务器、区域拆分等。在分布式集群中，主机通常运行在 Hadoop 命名节点上。

ZooKeeper 是 HBase 集群的协调者。HBase 使用 ZooKeeper 作为分布式协调服务来维护集群中的服务器状态。ZooKeeper 维护哪些服务器是活动的和可用的，并提供服务器故障通知。区域服务器负责管理区域。区域服务器部署在数据节点上。它为读取和写入提供数据。区域服务器由以下附加组件组成:

Rowkey 设计是 HBase 表格设计中非常关键的一部分。在按键设计过程中，必须小心避免过热。如果密钥设计不当，所有数据将被摄入到几个节点中，从而导致集群不平衡。然后，所有读取都必须指向这几个节点，导致数据读取速度变慢。我们必须设计一个密钥，帮助将数据平等地加载到集群的所有节点。可以通过以下技术避免热灌注:

以下是设计 HBase 表时的指导原则:

我们将使用之前创建的相同的customer表:

启动 HBase，并在 HBase 中创建一个customer表:

使用 Sqoop 在 HBase 中加载 MySQL customer表数据:

验证 HBase 表:

您必须看到 HBase 表中的所有 11 行。

插入新客户并更新现有客户:

这里，我们使用InsUpd_on列作为我们的 ETL 日期:

现在，我们将使用 Hive 外部表访问 HBase customer表:

在本章中，我们看到了如何使用一个名为 Hive 的 Hadoop SQL 接口来存储和访问数据。我们研究了 Hive 中的各种分区和索引策略。工作示例帮助我们理解了使用 Hive 中的 Avro 进行 JSON 数据访问和模式演化。在本章的第二部分，我们研究了一个名为 HBase 的 NoSQL 数据存储及其与关系数据库管理系统的区别。HBase 表的行设计对于平衡读写以避免区域热点至关重要。我们必须牢记本章中讨论的 HBase 表设计最佳实践。该工作示例显示了将数据摄取到 HBase 表中的更简单的路径及其与 Hive 的集成。

在下一章中，我们将了解设计实时数据分析的工具和技术。

这本书的前三章都涉及批量数据。了解了 Hadoop 的安装、数据接收工具和技术以及数据存储之后，让我们来看看数据流。我们不仅要考虑如何处理实时数据流，还要考虑如何围绕数据流设计管道。

在本章中，我们将涵盖以下主题:

数据流是从一端到另一端、从发送者到接收者、从生产者到消费者的连续数据流。数据的速度和数量可能会有所不同；它可能是每秒 1 GB 的数据，也可能是每秒或每分钟 1 KB 的数据。

在批处理中，数据是分批收集的，每批数据都被发送进行处理。批处理间隔可以是从一天到一分钟的任何时间。在当今的数据分析和商业智能世界中，数据不会在超过一天的时间内被批量处理。否则，业务团队将无法洞察日常业务发生了什么。例如，企业数据仓库团队可能会收集过去 24 小时内发出的所有订单，并将收集到的所有订单发送给分析引擎进行报告。

在实时处理中，一旦在源端产生事件，数据(事件)就从生产者(发送者)传输(流传输)到消费者(接收者)。例如，在电子商务网站上，一旦客户在该网站上下了相同的订单，订单就会立即在分析引擎中得到处理。这样做的好处是，该公司的业务团队可以实时(在几毫秒或亚毫秒内)全面了解其业务。这将有助于他们调整促销以增加收入，所有这些都是实时的。

下图解释了流处理架构:

复杂事件处理 ( CEP )是将来自多个来源的数据进行组合以发现复杂关系或模式的事件处理。CEP 的目标是识别有意义的事件(如机会或威胁)，并尽快做出反应。从根本上说，CEP 是将业务规则应用于流式事件数据。例如，CEP 用于用例，如股票交易、欺诈检测、医疗索赔处理等。

下图解释了流处理架构:

任何实时应用都应该随时可用，没有任何中断。事件收集、处理和存储组件应配置有下划线的高可用性假设。任何组件的任何故障都会对业务运行造成重大干扰。例如，在信用卡欺诈检测应用中，需要拒绝所有欺诈交易。如果应用中途停止，并且无法拒绝欺诈交易，那么将导致重大损失。

在任何实时应用中，事件应该在几毫秒内从源流向目标。源收集事件，处理框架将事件移动到其目标数据存储中，在那里可以进一步分析事件以发现趋势和模式。所有这些都应该实时发生，否则可能会影响业务决策。例如，在信用卡欺诈检测应用中，预期应分析所有传入的交易，以发现可能的欺诈交易(如果有)。如果流处理花费的时间超过了所需的时间，这些事务可能会通过系统，给业务造成重大损失。

硬件故障可能会导致流处理应用中断。为了避免这种常见情况，我们总是需要一个处理框架，该框架提供内置的 API 来支持连续计算、容错事件状态管理、故障情况下的检查点功能、运行中聚合、窗口等。幸运的是，最近的所有 Apache 项目，如 Storm、Spark、Flink 和 Kafka，都支持所有这些开箱即用的特性。开发人员可以使用 Java、Python 和 Scala 来使用这些应用编程接口。

流处理平台应该支持水平可伸缩性。这意味着在传入数据负载较高的情况下，向集群添加更多物理服务器，以保持吞吐量服务级别协议。这样，可以通过增加更多的节点来提高处理性能，而不是在现有的服务器上增加更多的 CPU 和内存；这就叫做垂直伸缩。

流的优选格式是键值对。JSON 和 Avro 格式很好地代表了这种格式。保存键值类型数据的首选存储是 NoSQL 数据存储，如 HBase 和 Cassandra。目前市场上总共有 100 个 NoSQL 开源数据库。选择合适的数据库非常具有挑战性，因为所有这些数据库都为数据持久性提供了一些独特的功能。几个例子是模式不可知、高度可分发、商品硬件支持、数据复制等等。

下图解释了所有流处理组件:

在本章中，我们将详细讨论消息队列和流处理框架。在下一章中，我们将集中讨论数据索引技术。

在接下来的部分中，我们将介绍一些重要的实时流组件。

消息队列允许您发布和订阅事件/记录流。在我们的实时流体系结构中，有多种可供选择的消息队列。比如有 RabbitMQ、ActiveMQ、Kafka。其中，卡夫卡因其各种独特的特征而获得了巨大的知名度。因此，我们将详细讨论卡夫卡的建筑。关于 RabbitMQ 和 ActiveMQ 的讨论超出了本书的范围。

Kafka 是一个快速、可扩展、持久且容错的发布-订阅消息传递系统。Apache Kafka 是一个开源的流处理项目。它提供了统一的高吞吐量，是处理实时数据流的低延迟平台。它提供了一个分布式存储层，支持大规模可扩展的发布/订阅消息队列。Kafka Connect 通过连接外部系统支持数据导入和导出。Kafka Streams 为流处理提供了 Java APIs。Kafka 与 Apache Spark、Apache Cassandra、Apache HBase、Apache Spark 等结合使用，实现实时流处理。

以下是卡夫卡的特点:

下图展示了卡夫卡的建筑:

让我们详细看看每个组件:

卡夫卡连接是融合平台的一部分。它与卡夫卡融为一体。使用 Kafka Connect，构建从多个源到多个目标的数据管道非常容易。源连接器从另一个系统导入数据(例如，从关系数据库导入卡夫卡)，而接收器连接器导出数据(例如，卡夫卡主题的内容到 HDFS 文件)。

下图展示了卡夫卡连线的架构:

数据流可以解释如下:

用户可以通过两种方式运行 Kafka Connect:独立模式或分布式模式。

在独立模式下，一个进程运行所有连接器。它不是容错的。因为它只使用一个进程，所以它是不可扩展的。一般来说，它对用户的开发和测试很有用。

在分布式模式下，多个工人运行 Kafka Connect。在这种模式下，Kafka Connect 具有可伸缩性和容错性，因此用于生产部署。

让我们了解更多关于卡夫卡和卡夫卡连接(独立模式)。在本例中，我们将执行以下操作:

下图显示了一个使用卡夫卡连接的用例:

让我们执行以下步骤来安装卡夫卡:

执行以下步骤创建主题:

执行以下步骤生成消息以验证生产者和消费者:

让我们看一下如何使用文件“源”和“接收器”创建主题，这有以下帮助:

请执行以下步骤:

下图显示了如何将数据库表中的所有记录推送到文本文件:

让我们使用卡夫卡连接实现前面的例子:

--new-consumer选项已被弃用，将在未来的主要版本中删除。如果提供了--bootstrap-server选项，则默认使用新消费者:

您将在目标文件中看到所有客户记录(cust_id)。使用前面的示例，您可以自定义和实验任何其他接收器。

下表显示了汇流平台上可用的卡夫卡连接器(由汇流开发并完全支持):

| 连接器名称 | 源/汇 || JDBC | 源和汇 || HDFS | Flume || 弹性搜索 | Flume || 亚马逊 S3 | Flume |

您一定已经观察到 Kafka Connect 是一个基于配置的流处理框架。这意味着我们只需配置源和接收器连接器文件。我们不需要使用 Java 或 Scala 等低级语言编写任何代码。但是，现在，让我们转向一个更流行的实时流处理框架，称为 Apache Storm 。让我们了解一下 Apache Storm 的一些很酷的特性。

Apache Storm 是一个免费的开源分布式实时流处理框架。在写这本书的时候，Apache Storm 的稳定发布版本是 1.0.5。Storm 框架主要是用 Clojure 编程语言编写的。最初，它是由内森·马尔斯和巴克特的团队创建和开发的。该项目后来被推特收购。

在他关于 Storm 框架的一次演讲中，Nathan Marz 谈到了使用任何框架的流处理应用，比如 Storm。这些应用涉及队列和工作线程。一些数据源线程将消息写入队列，而其他线程获取这些消息并写入目标数据存储。这里的主要缺点是源线程和目标线程彼此的数据负载不匹配，这导致了数据堆积。它还会导致数据丢失和额外的线程维护。

为了避免前面的挑战，Nathan Marz 想出了一个很棒的架构，将源线程和工作线程抽象成 tumbles 和 Bolts。这些喷口和螺栓被提交给拓扑框架，该框架负责整个流处理。

ApacheStorm 是分布式的。如果流的工作负载增加，可以将多个节点添加到 Storm 集群中，以添加更多的工作人员和更多的处理能力。

是真正的实时流处理系统，支持低延迟。事件可以在毫秒、秒或分钟内从源到达目标，具体取决于用例。

Storm 框架支持多种编程语言，但 Java 是首选。暴风是容错。即使集群中的任何节点出现故障，它也能继续运行。暴风是可靠的。它支持至少一次或恰好一次的处理。

下图显示了典型的Storm 拓扑:

以下部分解释了 Storm 拓扑的所有组件:

以下是在单台计算机上安装 Storm Cluster 的步骤:

您应该会看到以下输出:

(对于额外的工作人员，添加更多端口，如 6704 等)

在本节中，我们将创建以下三条管道:

在本节中，我们将看到数据流是如何从 Kafka 到 Storm 再到 MySQL 表的。

整个管道的工作原理如下:

我们将开发以下 Java 类:

下图显示了管道的组件。在这条管道中，我们将了解消息将如何从卡夫卡到 Storm 再到 MySQL 实时流动:

在本节中，我们将看到数据流将如何从卡夫卡到斯托姆再到 HDFS，并通过一个 Hive 外部表来访问它们。

下图显示了管道的组件。在这条管道中，我们将了解信息将如何实时从卡夫卡到 Storm 再到 HDFS:

整个管道的工作原理如下:

我们将开发以下 Java 类:

在前面的示例管道中，可以开发用于数据流解析和转换的多个单独的类来处理卡夫卡生产者和消费者。

的配置单元表如下:

除了 Apache Storm，还有相当多的其他开源实时数据流框架。在这一节中，我将只简单地讨论开源的非商业框架。但是，在这一节的最后，我将提供一些商业供应商产品的网址，这些产品提供了一些非常有趣的功能。

Kafka Streams 是一个用于构建流应用的库。Kafka Streams 是一个用于构建应用和微服务的客户端库，输入和输出数据存储在 Kafka Clusters 中。卡夫卡流应用编程接口转换和丰富数据。

以下是卡夫卡流应用编程接口的重要特性:

让我们再次回顾前面的图像，找出卡夫卡流应用编程接口在整个卡夫卡建筑中的确切位置。

这里有几个有用的网址来详细了解卡夫卡流:

通常的做法是使用 Hadoop MapReduce 进行批处理，使用 Apache Storm 进行实时流处理。

使用这两种不同的编程模型会导致代码大小、需要修复的 bug 数量和开发工作量的增加；它还引入了一条学习曲线，并引发了其他问题。Spark Streaming 有助于解决这些问题，并提供了一个可扩展的、高效的、有弹性的和集成的(带有批处理)系统。

Spark Streaming 的优势在于其与批处理相结合的能力。可以使用普通的 Spark 编程创建一个 RDD，并将其与 Spark 流结合起来。此外，代码库是相似的，如果需要的话，允许容易的迁移——并且从 Spark 没有学习曲线。

Spark 流是核心 Spark 应用编程接口的扩展。它扩展了 Spark 来进行实时流处理。Spark 流具有以下特征:

Spark Streaming 将数据流应用作为一系列非常小的确定性批处理作业进行处理。

Spark Streaming 用 Scala、Java 和 Python 提供了一个应用编程接口。Spark Streaming 根据时间将实时数据流分为多个批次。时间范围可以从一秒到几分钟/小时。一般来说，批次分为几秒钟。Spark 将每个批处理视为一个 RDD，并基于 RDD 操作(映射、筛选、连接平面图、distinct、reduceByKey 等)处理每个批处理。最后，RDDs 的处理结果被分批返回。

下图描述了 Spark 流数据流:

这里有几个有用的网址来详细了解 Spark 流:

Apache Flink 的文档是这样描述 Flink 的:Flink 是一个开源的分布式流处理框架。

Flink 提供准确的结果，并支持无序或延迟到达的数据集。它是有状态和容错的，可以从故障中无缝恢复，同时保持一次应用状态。它可以大规模运行，在数千个节点上运行，具有非常好的吞吐量和延迟特性。

以下是 Apache Flink 的功能:

Flink 的核心是分布式流式数据流引擎。它支持一次处理一个流，而不是一次处理整批流。

Flink 支持以下库:

Flink 支持以下 API:

下图描述了 Flink 编程模型:

下图描述了 Flink 架构:

以下是 Flink 编程模型的组成部分:

这里有几个有用的网址来详细了解 Spark 流:

在接下来的部分中，我们将看一看各种流框架的比较。

Spark 流的主要焦点是流批处理操作，称为微批处理。这种编程模型适合许多用例，但并不是所有用例都需要亚秒延迟的实时流处理。例如，信用卡欺诈防范之类的用例需要毫秒级延迟。因此，微批处理编程模型不适合那里。(但是，最新版本的 Spark 2.4 支持毫秒级数据延迟)。

Apache Flink 支持毫秒级延迟，适合欺诈检测等用例。

Spark 使用微批处理来处理事件，而 Storm 则逐个处理事件。这意味着 Spark 有几秒钟的延迟，而 Storm 提供了一毫秒的延迟。Spark 流提供了一个高级抽象，称为离散流或数据流，它代表一个连续的 rdd 序列。(但是，最新版本的 Spark，2.4 支持毫秒级的数据延迟。)最新的 Spark 版本支持数据帧。

几乎相同的代码(应用编程接口)可以用于 Spark 流和 Spark 批处理作业。这有助于重用两种编程模型的大部分代码库。此外，Spark 支持机器学习和图形应用编程接口。所以，同样的代码库也可以用于那些用例。

在本章中，我们首先详细了解了实时流处理概念，包括数据流、批处理与实时处理、CEP、低延迟、连续可用性、水平可扩展性、存储等。后来，我们了解了 Apache Kafka，它是现代实时流数据管道的一个非常重要的组成部分。Kafka 的主要特点是可扩展性、耐用性、可靠性和高吞吐量。

我们还了解了卡夫卡连接；它的体系结构、数据流、源和连接器。我们研究了使用文件源、文件接收器、JDBC 源和文件接收器连接器设计数据管道的案例研究。

在后面的章节中，我们学习了各种开源实时流处理框架，比如 Apache Storm 框架。我们也看到了一些实际的例子。Apache Storm 是分布式的，支持低延迟和多种编程语言。Storm 是容错和可靠的。它支持至少一次或恰好一次的处理。

Spark Streaming 有助于解决这些问题，并提供了一个可扩展的、高效的、有弹性的和集成的(带有批处理)系统。Spark Streaming 的优势在于其与批处理相结合的能力。Spark 流是可扩展的，并提供高吞吐量。它支持二级延迟的微批处理，具有容错能力，并集成了批处理和交互式数据处理。

随着数据源的数量和复杂性不断增加，从数据中获取价值也变得越来越困难。自从 Hadoop 诞生以来，它已经构建了一个可大规模扩展的文件系统，HDFS。它采用了来自函数式编程的 MapReduce 概念来应对大规模数据处理挑战。随着技术不断发展以克服数据挖掘带来的挑战，企业也在寻找方法来迎接这些变化以保持领先地位。

在本章中，我们将重点介绍这些数据处理解决方案:

MapReduce 是从函数式编程中借用的一个概念。数据处理分为地图阶段和缩减阶段，在地图阶段进行数据准备，在缩减阶段计算实际结果。MapReduce 发挥重要作用的原因是，当数据被分割到多个分布式服务器时，我们可以实现巨大的并行性。如果没有这个优势，MapReduce 就无法真正发挥出色。

让我们举一个简单的例子来理解 MapReduce 在函数式编程中是如何工作的:

让我们用一个简单的程序来理解这些步骤。该程序使用以下文本(随机创建)作为输入:

输入由以下字段组成的数据:城市名称、产品名称、当日商品价格。

我们想写一个程序，显示给定城市所有产品的总成本。这可以通过多种方式实现。但是让我们尝试使用 MapReduce 来处理这个问题，看看它是如何工作的。

映射程序是这样的:

减少程序是:

我们使用 UNIX 终端创建了一个数据管道，如下所示:

我们可以看到，结果是意料之中的。这是一个非常简单的 MapReduce 案例。让我们试着看看发生了什么:

MapReduce 操作的输出是:

没有区别，因为映射和缩减操作都是一次性独立执行的。这里没有数据并行。整个过程可以在该图中可视化:

我们可以看到，贴图阶段后有一个输入数据的副本，还原阶段后的最终输出才是我们感兴趣的。

运行单线程进程是有用的，当我们不需要处理大量数据时，它是必需的。当输入大小是无界的，无法放入单个服务器时，我们需要开始考虑分布式/并行算法来解决手头的问题。

Apache MapReduce 是一个框架，它使我们更容易在非常大的分布式数据集上运行 MapReduce 操作。Hadoop 的优势之一是分布式文件系统，它支持机架感知和可扩展。Hadoop 作业调度器足够智能，可以确保计算发生在数据所在的节点上。这也是一个非常重要的方面，因为它减少了网络 IO 的数量。

让我们看看这个框架是如何在这个图表的帮助下使大规模并行计算变得更加容易的:

这个图看起来比上一个图复杂一点，但是大部分事情都是 Hadoop MapReduce 框架自己为我们完成的。我们仍然编写映射和减少输入数据的代码。

让我们从上图中详细看看当我们使用 Hadoop MapReduce 框架处理数据时会发生什么:

流式 MapReduce 是 Hadoop MapReduce 框架中可用的功能之一，我们可以使用任何外部程序来充当映射器和缩减器。只要这些程序可以由目标操作系统执行，它们就可以运行映射和缩减任务。

在编写这些程序时，需要记住以下几点:

在前一节中，我们已经编写了简单的 Perl 脚本来进行映射和简化。同样在当前场景中，我们将使用相同的程序来理解它们如何执行我们的任务。

在本练习中，我们使用随机输入数据，如下所示:

稍后，我们需要将映射器和缩减器脚本复制到所有 Hadoop 节点:

在这一步中，我们将输入复制到hadoop /tmp/ directory。

Please use a sensible directory in your production environments as per your enterprise standards. Here the /tmp directory is used for illustration purposes only.

在这一步中，我们使用 Hadoop 流式 MapReduce 框架来使用我们的脚本来执行计算:

输出存储在 HDFS，我们可以这样查看:

如果我们仔细观察，结果与我们的传统程序完全匹配。

在前一节中，我们已经看到了如何使用任意编程语言在 Hadoop 上运行 MapReduce 操作。但是在大多数实际场景中，如果我们利用 Hadoop MapReduce 基础架构提供的库是很好的，因为它们功能强大，能够满足我们的许多需求。

让我们尝试使用 MapReduce 库编写一个简单的 Java 程序，看看我们是否能生成与前面练习中相同的输出。在这个例子中，我们将使用来自官方文档的官方 MapReduce 实现。

一旦我们有了源代码，我们需要编译它来创建一个 Java Archive ( JAR )文件。它以下列方式完成:

As in the case of streaming MapReduce, we need not copy the source to all the Hadoop servers.

这个运行应该通过 fine，并将产生/tmp/output-12目录中的输出文件。我们可以使用以下命令查看输出内容:

这也与之前的运行完全一致。

正如我们所看到的，Hadoop Mapreduce 框架已经采取了所有必要的步骤来确保整个管道进度保持在其控制范围内，从而为我们提供了期望的结果。

即使我们使用了一个非常简单的数据集进行计算，Hadoop Mapreduce 也能确保无论我们处理的数据大小如何，我们之前编写的相同程序都会产生我们想要的结果。这使得它成为一个非常强大的批处理作业架构。

到目前为止，我们已经看到 Hadoop Mapreduce 是一个强大的框架，它提供了流式和批处理操作模式，以非常简单的指令处理大量数据。尽管 Mapreduce 最初是 Hadoop 中计算框架的选择，但它未能满足市场不断变化的需求，因此开发了新的架构来解决这些问题。在下一节中，我们将学习一个名为 Apache Spark 的框架。

Apache Spark 是一个通用的集群计算系统。它非常适合大规模数据处理。当完全在内存中运行时，它的性能比 Hadoop 高 100 倍，当完全从磁盘运行时，它的性能比 Hadoop 高 10 倍。它有一个复杂的有向无环图执行引擎，支持无环数据流模型。

Apache Spark 拥有用 Java、Scala、Python 和 R 编程语言编写程序的一流支持，以迎合更广泛的受众。它提供了 80 多种不同的运营商来构建并行应用，而不用担心底层基础设施。

Apache Spark 拥有迎合结构化查询语言的库，被称为 SparkSQL；这支持在使用 ANSI SQL 的程序中编写查询。它还支持计算流数据，这在当今的实时数据处理需求中非常需要，例如为交互式用户体验系统的仪表板供电。Apache Spark 也有机器学习库，比如 Mlib ，它迎合了运行科学程序的需求。然后它支持为遵循图形数据结构的数据编写程序，称为 GraphX 。这使得它成为一个真正强大的框架，支持最先进的计算方式。

Apache Spark 不仅运行在 Hadoop 平台上，还运行在各种系统上，如 Apache Mesos、Kubernetes、Standalone 或 Cloud。这使得今天的企业选择它想要利用这个系统的力量的方式成为一个完美的选择。

在接下来的部分中，我们将了解更多关于 Spark 及其生态系统的信息。我们在本练习中使用的是 Spark 2.2.0。

从上一章开始，我们有一个正在运行的现有 Ambari 安装。我们将利用相同的安装来增加 Spark 支持。让我们看看如何实现这一点。

一旦我们点击添加服务菜单项，我们会看到一个向导，我们必须从安巴里所有支持的服务列表中选择 Spark 2。屏幕如下所示:

服务选择完成后，单击下一步按钮。

当更改看起来不错时，单击“下一步”按钮。

在这一步中，我们可以选择作为我们在上一步中选择的主节点的客户端的节点列表。我们还可以选择可以安装客户端实用程序的服务器列表。根据您的选择进行选择:

更改完成后，单击“下一步”按钮。

由于 Hive 也作为 Spark 2 选择的一部分被安装，我们可以选择定制 Hive 数据源的细节。我在主节点上创建了数据库，用户名为hive，密码为hive，数据库也为hive。在生产中进行更改时，请选择一个强密码。

定制屏幕如下所示:

正确完成更改后，单击下一步。

在此屏幕中，我们看到了迄今为止所做选择的摘要。单击部署开始在选定的服务器上部署 Spark 2 软件。如果我们觉得我们错过了任何自定义，我们可以随时取消向导并在此步骤中重新开始:

在这一步中，我们将看到 Spark 软件安装的进度及其其他依赖关系。一旦部署了所有内容，我们会看到任何警告和错误的摘要。从下面的屏幕中我们可以看到，在安装过程中遇到了一些警告，这表明一旦向导完成，我们需要重新启动一些服务。别担心，看到这些错误是很正常的。我们将在接下来的步骤中纠正这些错误，以使 Spark 系统成功运行:

单击完成完成向导。

由于在安装过程中出现警告，我们必须重新启动所有受影响的组件。该屏幕显示重启过程:

这就完成了 Spark 2 在由 Ambari 管理的现有 Hadoop 集群上的安装。在接下来的部分中，我们将了解更多关于 Spark 中各种数据结构和库的信息。

尽管 Mapreduce 提供了一种处理大量数据的强大方法，但由于以下几个缺点，它受到了限制:

仅举几个例子。自从 Apache Spark 从头开始构建以来，它一直以非常通用的方式处理大数据计算问题，并为开发人员提供了数据结构，使其更容易表示任何类型的数据，并以更好的方式使用这些数据进行计算。

Apache Spark 的核心是被称为 RDD 的分布式数据集，也被称为弹性分布式数据集。这些是集群中存在的不可变数据集，具有高可用性和容错性。RDD 中的元素可以并行运行，为 Spark 簇提供大量能量。

由于数据已经存在于存储系统中，如 HDFS、关系数据库管理系统、S3 等，因此可以从这些外部数据源轻松创建关系数据库。该应用编程接口还为我们提供了从现有内存数据元素创建关系数据库的能力。

这些关系数据库没有任何预定义的结构。因此，它们可以采取任何形式，并且通过利用 Spark 库中的不同运算符，我们可以编写强大的程序，为我们提供必要的结果，而不必太担心数据的复杂性。

为了满足关系数据库管理系统的需求，数据帧开始发挥作用，其中数据帧可以与关系数据库系统中的表进行比较。我们知道，表有行和列，数据的结构是提前知道的。通过了解数据的结构，可以在数据处理过程中进行一些优化。

Spark 数据集与数据框有些相似。但是它们通过用本地语言对象(Java 和 Scala)支持半结构化数据对象来扩展数据框架的功能。数据帧是具有关系模式语义的不可变对象集合。因为我们处理的是半结构化数据和本地语言对象，所以有一个编码器/解码器系统负责在类型之间自动转换。

下面是一个快速对比图:

| 功能 | RDDs | 数据帧 | 数据集 || 数据类型 | 非结构化数据 | 结构数据 | 半结构化数据 || 模式要求 | 完全自由形式 | 严格的数据类型 | 松散耦合 || Spark 提供的优化 | 不需要，因为数据是非结构化的 | 利用优化，因为数据类型是已知的 | 推断的数据类型提供了某种程度的优化 || 高级表达式/过滤器 | 因为数据形式本质上是复杂的，所以很难 | 我们可以利用这些，因为我们知道我们正在处理的数据 | 也可以在这里借力 |

Apache Spark 有非常好的编程语言支持。它为 Java、Scala、Python 和 R 编程语言提供了一流的支持。尽管编程语言中可用的数据结构和运算符本质上是相似的，但我们必须使用特定于编程语言的结构来实现所需的逻辑。在本章中，我们将使用 Python 作为首选编程语言。然而，Spark 本身对这些编程语言是不可知的，无论使用哪种编程语言，都会产生相同的结果。

使用 Python 的 Apache Spark 可以有两种不同的使用方式。第一种方式是启动pyspark交互外壳，帮助我们运行 Python 指令。体验类似于 Python 外壳实用程序。另一种方法是编写可以使用 spark-submit 命令调用的独立程序。为了使用独立的 Spark 程序，我们必须了解 Spark 程序的基本结构:

spark 程序的典型结构由一个主要函数组成，该函数在 RDDs 上执行不同的运算符来生成所需的结果。Spark 库中支持 80 多种不同类型的操作员。在高层次上，我们可以将这些操作符分为两种类型:转换和动作。转换运算符将数据从一种形式转换为另一种形式。操作从数据中生成结果。出于性能原因，为了优化集群中的资源，Apache Spark 实际上在检查点执行程序。每个检查点只有在有操作符时才会到达。这是一件需要记住的重要事情，尤其是如果你是使用 Spark 编程的新手。即使是最高级的程序员有时也会困惑为什么他们没有看到期望的结果，因为他们没有对数据使用任何操作符。

回到前面的图表，我们有一个驱动程序，它有一个主例程，对存储在像 HDFS 这样的文件系统中的数据执行几个动作/转换，并给出我们想要的结果。我们知道 RDDs 是 Spark 编程语言中的基本并行数据存储。Spark 足够智能，可以像 HDFS 一样从种子存储中创建这些 rdd，一旦创建，它就可以将这些 rdd 缓存在内存中，并通过使这些 rdd 容错来使其高度可用。即使 RDD 的拷贝由于节点崩溃而离线，相同 RDDs 上的未来访问也将从最初生成它的计算中快速生成。

为了理解 spark 的编程 API，我们应该有一个样本数据集，在这个数据集上我们可以执行一些操作来获得信心。为了生成这个数据集，我们将从上一章的 employees 数据库中导入示例表。

以下是我们生成该数据集的说明:

这将把我们放在一个远程 shell 中，我们可以从 MySQL 数据库转储该表:

接下来，我们应该使用以下命令将文件复制到 Hadoop:

现在，数据准备工作已经完成，我们已成功将其复制到 HDFS。我们可以用 Spark 开始使用这些数据。

Apache Spark 发行版附带一个名为 pyspark 的交互式外壳。由于我们处理的是像 Python 这样的解释编程语言，所以我们可以在学习的同时编写交互式程序。

前面的步骤启动了交互式 Spark 外壳。

如我们所见，该计数与 Unix shell 上之前的加载操作相匹配。

现在，让我们尝试从文件中加载前五条记录，并尝试查看数据结构对象的模式:

正如我们所看到的，即使我们有一个 CSV(制表符分隔的文件)，Spark 已经将该文件读取为由换行符分隔的普通文本文件，并且该模式只包含一个值，该值是字符串数据类型。

在这种操作模式下，我们将每条记录视为一行，我们只能执行几种类型的操作，例如计算给定名称的所有出现次数:

这种操作模式有点类似于日志处理。但是 Spark 真正的力量来自于把数据当作一个有行有列的表，也就是 DataFrames 的力量:

现在，我们可以看到 Spark 已经自动将输入的 CSV 文本转换为数据帧。但所有字段都被视为字符串。

让我们尝试使用 spark 的模式推断功能来自动查找字段的数据类型:

现在我们可以看到，所有字段都有一个最接近 MySQL 表定义的正确数据类型。

我们可以对数据应用简单的操作来查看结果。让我们试着找出男性记录总数:

此外，尝试找到工资超过 10 万美元的男性记录:

就这么简单，对吧？在官方的 Spark 文档中，有更多的操作符可供探索。

在前一节中，我们已经看到了如何使用交互外壳pyspark来学习 Spark Python API。在本节中，我们将编写一个简单的 Python 程序，在 Spark 集群上运行。在现实场景中，这是我们在 Spark 集群上运行应用的方式。

为了在 Spark 集群上运行这个程序，我们必须使用 spark-submit 命令，它在调度和协调整个应用生命周期方面做了必要的工作:

正如预期的那样，这些是我们的输入文件中的记录总数(不包括标题行)。

spark 的强大功能之一是构建处理实时流数据并产生实时结果的应用。为了更好地理解这一点，我们将编写一个简单的应用，试图在输入流中找到重复的消息，并打印所有唯一的消息。

当我们处理不可靠的数据流，并且我们只想提交唯一的数据时，这种应用很有帮助。

这里给出了这个应用的源代码:

在这个应用中，我们连接到端口5000上的远程服务，该服务在其自己的页面上发送消息。程序每 5 秒钟总结一次操作结果，如StreamingContext参数所定义。

现在，让我们使用 UNIX netcat 命令(nc)和一个简单的循环来启动一个简单的 TCP 服务器:

之后，将我们的计划提交给 spark cluster:

程序启动后，我们会看到以下输出:

我们看到每个单词都有正好 5 作为计数，这是预期的，因为我们在 Unix 命令循环中打印了五次。

借助这个图表，我们可以理解这一点:

输入流产生连续的数据流，由Spark 程序实时消耗。之后，通过消除重复项来打印结果

如果我们按照时间顺序来看，从时间零点到时间五秒( T0 - T5 )的数据被处理，结果可以在 T5 时间获得。其他时间段也一样。

在这个简单的例子中，我们刚刚学习了如何使用 Spark Streaming 构建实时应用的基础知识。

使用 Spark 编写应用时，开发人员可以选择在结构化数据上使用 SQL 来获得所需的结果。一个例子让我们更容易理解如何做到这一点:

由于我们有兴趣找到收入最高的员工，结果如预期所示:

正如我们所看到的，Apache Spark 提供的简化的应用编程接口使得在 CSV 数据的基础上编写 SQL 查询变得更加容易(不需要关系数据库管理系统)，以获得我们想要的东西。

在本章中，您了解了大规模数据处理框架的基本概念，并了解到 spark 的强大功能之一是构建处理实时流数据并产生实时结果的应用。

在接下来的几章中，我们将讨论如何使用 Elasticsearch 堆栈构建实时数据搜索管道。

在学习了数据摄取和数据持久化方法之后，让我们学习一下搜索数据。在本章中，我们将了解以下重要事项:

在我们的日常生活中，我们总是不断地寻找一些东西。早上，我们搜索牙刷、报纸，搜索股票价格、公交时刻表、办公包等等。这份名单越列越多。当我们一天结束睡觉时，搜索活动就停止了。我们使用很多工具和技术来搜索这些东西，以最大限度地减少实际搜索时间。我们用谷歌搜索大多数东西，比如新闻、股票价格、公共汽车时刻表，以及我们需要的任何东西。为了搜索一本书的特定页面，我们使用该书的索引。所以，重点是搜索是我们生活中非常重要的活动。有两个重要的概念可以浮出水面，那就是搜索工具和搜索时间。只要想一个你想知道某个公司的某个特定股票价格的情况，加载这个页面需要几分钟的时间。你肯定会很恼火。因为这种情况下的搜索时间是你不能接受的。那么接下来的问题就是，如何减少这个搜索时间？我们将在本章中了解这一点。

就像我们都需要一个工具来搜索自己的东西一样，每个公司也需要一个搜索引擎来构建，这样内部和外部实体就可以找到他们想要的东西。

例如，员工必须搜索他/她的 PTO 余额、特定月份的工资单，等等。人力资源部可能会搜索财务组的员工。在电子商务公司中，产品目录是最容易搜索的对象。这是一个非常敏感的对象，因为它直接影响公司的收入。如果顾客想买一双鞋，他/她能做的第一件事就是搜索公司产品目录。如果搜索时间超过几秒钟，客户可能会对产品失去兴趣。也有可能是同一客户去另一个网站买一双鞋，导致收入损失。

看来，即使有世界上所有的技术和数据，没有两个关键的组成部分，我们也做不了什么:

谷歌、亚马逊和苹果等公司改变了世界对搜索的期望。我们都希望他们可以随时随地使用任何工具搜索任何内容，例如网站、手机和语音激活工具，如谷歌回声、Alexa 和 HomePad。我们期待这些工具能回答我们所有的问题，从今天天气怎么样？给我一个我附近加油站的名单。

随着这些预期的增长，索引越来越多数据的需求也在增长。

以下是一些流行的工具/产品/技术:

In this chapter, I will focus on Elasticsearch in detail. I will discuss Apache Solr on a conceptual level only.

Elasticsearch 是一个开源搜索引擎。它基于 Apache Lucene。它是分布式的，支持多租户功能。它使用无模式的 JSON 文档，并有一个内置的基于 HTTP 的网络接口。它还支持分析性 RESTful 查询工作负载。它是一个基于 Java 的数据库服务器。它的主要协议是 HTTP/JSON。

Elasticsearch 是目前最流行的数据索引工具。这是因为它具有以下特点:

在我们深入探讨之前，让我们了解弹性搜索的几个重要组成部分。

Elasticsearch 索引是 JSON 文档的集合。Elasticsearch 是一个可能包含多个索引的数据存储。每个索引可以分为一种或多种类型。类型是一组相似的文档。一个类型可能包含多个文档。就数据库类比而言，索引是一个数据库，它的每种类型都是一个表。每个 JSON 文档都是该表中的一行。

Indices created in Elasticsearch 6.0.0 or later may only contain a single mapping type.

在 Elasticsearch 7.0.0 中将完全删除映射类型。

弹性搜索中的文档是指 JSON 文档。它是存储在索引中的基本数据单元。一个索引包含多个文档。在关系数据库管理系统世界中，文档只不过是表格中的一行。例如，客户文档可能如下所示:

映射是索引的模式定义。就像数据库一样，我们必须定义一个表的数据结构。我们必须创建一个表、它的列和列数据类型。在弹性搜索中，我们已经定义了索引创建过程中的结构。我们可能需要定义哪些字段可以被索引、搜索和存储。

好消息是，Elasticsearch 支持动态映射。这意味着在索引创建时映射不是强制性的。无需映射即可创建索引。当文档发送到弹性搜索进行索引时，弹性搜索会自动定义每个字段的数据结构，并使每个字段成为可搜索字段。

Elasticsearch 是节点(服务器)的集合。每个节点可以将部分数据存储在索引中，并提供跨所有节点的联合索引和搜索功能。默认情况下，每个集群都有一个唯一的名称elasticsearch。集群分为多种类型的节点，即主节点和数据节点。但是，弹性搜索集群可以只使用一个节点来创建，该节点在同一个节点上同时安装了主节点和数据节点:

文档分为各种逻辑类型，例如订单文档、产品文档、客户文档等。不是创建三个单独的订单、产品和客户索引，而是可以将单个索引逻辑上分为订单、产品和客户类型。在关系数据库管理系统的类比中，一个类型只不过是数据库中的一个表。因此，类型是索引的逻辑分区。

Type is deprecated in Elasticsearch version 6.0.

让我们通过索引这三个示例文档来了解弹性搜索实际上是如何工作的。在学习这一点的同时，我们将触及弹性搜索的一些重要功能/概念。

以下是要索引的三个示例 JSON 文档:

首先是第一件事。让我们安装弹性搜索。

请执行以下步骤在您的服务器上安装弹性搜索。假设您正在服务器上使用 CentOS 7 安装弹性搜索。

最低硬件要求是什么？

哪个 JDK 需要安装？我们需要 JDK 8 号。如果您的服务器上没有安装 JDK 8，请执行以下步骤安装 JDK 8:

既然我们已经成功地在我们的服务器上安装了 JDK 8，让我们开始安装弹性搜索。

有关详细的安装步骤，请参考以下网址:

现在开始弹性搜索:

使用以下网址检查弹性搜索是否正在运行:

我们将得到以下回应:

现在，我们的弹性研究进展顺利。让我们创建一个索引来存储我们的文档。

我们将使用下面的curl命令来创建第一个名为my_index的索引:

我们会得到这样的回应:

在索引创建 URL 中，我们使用了设置、碎片和副本。让我们理解什么是碎片和复制品。

我们已经用三个碎片创建了索引。这意味着 Elasticsearch 会将索引分成三个分区。每个分区称为一个碎片。每个碎片都是一个完整的、独立的 Lucene 索引。基本思想是弹性搜索将每个碎片存储在一个单独的数据节点上，以提高可扩展性。我们必须提到在创建索引时我们想要多少碎片。然后，弹性搜索会自动处理它。在文档搜索过程中，Elasticsearch 将聚合所有可用碎片中的所有文档，以合并结果，从而满足用户的搜索请求。它对用户是完全透明的。因此，概念是索引可以分成多个碎片，每个碎片可以托管在每个数据节点上。碎片的放置将由 Elasticsearch 本身负责。如果我们没有在索引创建网址中指定碎片的数量，默认情况下，弹性搜索将为每个索引创建五个碎片。

我们已经用一个副本创建了索引。这意味着 Elasticsearch 将为每个分片创建一个副本(复本)，并将每个复本放置在不同的数据节点上，而不是复制它的分片上。因此，现在有两个碎片，主碎片(原始碎片)和副本碎片(主碎片的副本)。在大量搜索活动中，弹性搜索可以从主碎片或放置在不同数据节点上的副本碎片中提供查询结果。这就是 Elasticsearch 提高查询吞吐量的方式，因为每个搜索查询可能会到达不同的数据节点。

总之，主碎片和副本碎片都提供了水平可扩展性和吞吐量。它可以扩展您的搜索量/吞吐量，因为搜索可以在所有副本上并行执行。

Elasticsearch 是一个分布式数据存储。这意味着数据可以分为多个数据节点。例如，假设我们只有一个数据节点，并且我们在同一数据节点上继续接收和索引文档，那么在达到该节点的硬件容量后，我们可能无法接收文档。因此，为了容纳更多的文档，我们必须向现有的弹性搜索集群添加另一个数据节点。如果我们添加另一个数据节点，弹性搜索会将碎片重新平衡到新创建的数据节点。所以现在，用户搜索查询可以适应两个数据节点。如果我们创建了一个副本碎片，那么每个碎片将创建两个副本，并放置在这两个数据节点上。现在，如果其中一个数据节点发生故障，那么用户搜索查询将只使用一个数据节点来执行。

此图显示了如何从两个数据节点执行用户搜索查询:

下图显示，即使数据节点 A 关闭，用户查询仍然从数据节点 B 执行:

让我们验证新创建的索引:

我们将得到以下回应:

让我们了解一下回应:

以下curl命令可用于摄取my_index索引中的单个文档:

在前面的命令中，我们使用了一个名为customer的类型，它是一个索引的逻辑分区。在关系数据库管理系统的类比中，一个类型就像弹性搜索中的一个表。

另外，我们在客户类型后使用了数字1。这是一个顾客的身份证。如果我们忽略它，那么弹性搜索将为文档生成一个任意的标识。

我们有多个文档要插入my_index索引。在命令行中逐个插入文档是非常繁琐和耗时的。因此，我们可以将所有文档包含在一个文件中，并批量插入my_index。

让我们使用我们最喜欢的浏览器来验证所有记录。它将显示所有三条记录:

由于我们的my_index索引中有文档，我们可以搜索这些文档:

找出city = " Los Angeles?所在的文档，查询如下:

回应:

如果我们分析响应，我们可以看到源部分返回了我们正在寻找的文档。文件在索引my_index、"_type" : "customer"、"_id" : "3"中。Elasticsearch 成功搜索所有three _shards。

在hits部分下，有一个名为_score的字段。Elasticsearch 计算文档中每个字段的相关频率，并将其存储在索引中。它被称为文档的重量。该权重是基于四个重要因素计算的:术语频率、反向频率、文档频率和字段长度频率。这就引出了另一个问题，【Elasticsearch 如何对文档进行索引？

例如，我们在 Elasticsearch 中有以下四个要索引的文档:

| 期限 | 频率 | 文件编号 || a | Two | Two || 指数 | one | Two || 弹性搜索 | Two | 1,2 || 巴什 | Two | one || 我 | Two | 1,4 || 是 | Two | 2,3 || 钥匙 | one | three || 爱 | Two | 1,4 || 商店 | Two | 2,3 || 价值 | one | three |

当我们在 Elasticsearch 中摄取三个文档时，会创建一个倒排索引，如下所示。

现在，如果我们想要查询术语 Elasticsearch，那么只需要搜索两个文档:1 和 2。如果我们运行另一个查询来查找 love Elasticsearch ，那么在只发送第一个文档的结果之前，需要搜索三个文档(文档 1、2 和 4)。

此外，还有一个更重要的概念我们需要理解。

当我们将一个文档摄取到索引中时，Elasticsearch 会为每个索引文档添加一些元字段。以下是参照我们的示例my_index的元字段列表:

在关系数据库管理系统的类比中，映射意味着定义一个表模式。我们总是定义一个表结构，也就是列数据类型。在 Elasticsearch 中，我们还需要为每个字段定义数据类型。但随之而来的是另一个问题。为什么我们之前把三篇文献摄入my_index索引的时候没有定义？答案很简单。弹性搜索不在乎。据称弹性搜索是一个无模式的数据模型。

如果我们没有定义映射，Elasticsearch 会通过将所有字段定义为文本来为我们动态创建映射。Elasticsearch 足够智能，可以找出日期字段并将date数据类型分配给它们。

让我们找到现有的索引my_index的动态映射:

回应:

Elasticsearch 支持以下两种映射类型:

在静态映射中，我们总是知道我们的数据，并为每个字段定义适当的数据类型。静态映射必须在创建索引时定义。

在我们的示例中，我们已经对文档使用了动态映射。基本上，我们没有为任何字段定义任何数据类型。但是当我们使用_Bulk加载摄取文档时，弹性搜索透明地为每个字段定义了合适的text和date数据类型。Elasticsearch 智能地将我们的Birthdate作为日期字段，并为其分配了date数据类型。

以下电子表格总结了弹性搜索中可用的数据类型:

| 常用 | 综合体 | Geo | 专业化 || 线 | 排列 | 地理点 | ip || 关键字 | 对象(单个 Json) | 地理形状 | completion || 日期 | 嵌套(Json 数组) | | token_count || 长的 | | | join || 短的 | | | percolator || 字节 | | | murmur3 || 两倍 | | | || 浮动 | | | || 布尔代数学体系的 | | | || 二进制的 | | | || 整数范围 | | | || 浮动范围 | | | || 远程 | | | || 双范围 | | | || 日期范围 | | | |

大多数数据类型不需要解释。但是以下是对特定数据类型的一些解释:

**# 映射示例

让我们重新创建另一个索引second_index，它类似于我们的静态映射的first_index，在这里我们将分别定义每个字段的数据类型:

让我们理解前面的映射。我们禁用客户类型的_source字段。这意味着，我们摆脱了默认行为，默认情况下，弹性搜索存储和索引文档。现在，由于我们已经禁用了它，我们将分别处理每个字段，以决定该字段是应该索引存储还是两者都存储。

因此，在前面的示例中，我们只想存储三个字段:name、state和zip。此外，我们不想索引state和zip字段。这意味着state和zip字段不可搜索。

我们已经了解了倒排索引。我们知道 Elasticsearch 将文档存储到一个倒排索引中。这种转变被称为分析。这是成功响应索引搜索查询所必需的。

同样，很多时候，我们需要在将文档发送到 Elasticsearch 索引之前使用某种转换。我们可能需要将文档更改为小写，从文档中剥离 HTML 标记(如果有)，删除两个单词之间的空白，根据分隔符标记字段，等等。

Elasticsearch 提供以下内置分析器:

标准分析仪示例:

回应:

简单分析仪示例:

回应:

弹性搜索堆栈包括以下内容

让我们简单地研究一下。

Beats 是轻量级数据托运人。Beats 作为代理安装到服务器上。他们的主要功能是收集数据并将其发送到 Logstash 或 Elasticsearch。我们还可以配置 beats 向卡夫卡主题发送数据。

有多个节拍。每个节拍都是为了收集特定的数据集和指标。以下是各种类型的节拍:

文件节拍的安装:

它最常被用作流行的分析和搜索引擎 Elasticsearch 的数据管道。Logstash 是将数据加载到 Elasticsearch 的流行选择，因为它紧密集成，强大的日志处理功能，以及 200 多个预构建的开源插件，可以帮助您按照自己想要的方式对数据进行索引。

Logstash 的安装:

Kibana 是一个开源的数据可视化和探索工具，用于日志和时间序列分析、应用监控和运营智能用例。Kibana 与流行的分析和搜索引擎 Elasticsearch 紧密集成，这使得 Kibana 成为可视化存储在 Elasticsearch 中的数据的默认选择。Kibana 也因其强大且易于使用的功能而广受欢迎，例如直方图、折线图、饼图、热图以及内置的地理空间支持。

基巴纳的安装:

建议的技术堆栈:

为了解决这个问题，我们在 Appserver 上安装了 filebeat。Filebeat 将从访问日志中读取每一行，并实时写入 kafka 主题。信息将在卡夫卡缓冲。Logstash 将从卡夫卡主题中提取消息，并写入 Elasticsearch。

Kibana 将通过读取 Elasticsearch 索引中的消息来创建实时流式仪表板。下面是我们用例的架构:

创建日志-主题:

在卡夫卡部分，我们提到了以下事情:

在过滤器部分、我们将每条消息转换为 JSON 格式。之后，我们解析每条消息，并将其分成多个字段，如ip、timestamp和status。此外，我们将应用名称myapp字段添加到每个消息中。

在输出部分，我们将每条消息写入弹性搜索。索引名为log_index-YYYY-MM-dd。

在本章中，您了解了弹性搜索集群的基本概念和组件。

之后，我们讨论了 Elasticsearch 如何使用倒排索引对文档进行索引。我们还讨论了映射和分析技术。我们学习了如何在加入弹性搜索之前对事件进行反规格化。我们讨论了弹性搜索如何使用水平可伸缩性和吞吐量。在了解了诸如 Beats、Logstash 和 Kibana 等 Elasticstack 组件之后，我们处理了一个真实的用例，在这个用例中，我们演示了如何使用 Filebeat 将访问日志事件摄入 Kafka。我们开发了一个代码来从卡夫卡那里提取消息，并使用 Logstash 将其摄入弹性搜索。最后，我们使用 Kibana 学习了数据可视化。

在下一章中，我们将了解如何构建分析来设计推动业务决策的数据可视化解决方案。**

一旦我们拥有了 Hadoop 生态系统中的数据并对其进行了处理，下一个合乎逻辑的步骤就是构建驱动业务决策的分析。

在本章中，我们将学习以下主题:

数据可视化是通过图形方式理解原始数据中各种实体之间关系的过程。这是一项非常强大的技术，因为它使最终用户能够以非常简单的形式获得消息，而无需了解底层数据。

数据可视化在大数据洞察的可视化交流中发挥着非常重要的作用。这既是一门艺术，也是一门科学，在理解数据方面需要一些努力；同时，我们也需要对目标受众有所了解。

到目前为止，我们已经看到任何类型的数据都可以存储在 Hadoop 文件系统 ( HDFS )中。为了将复杂的数据结构转换成可视化的形式，我们需要了解用于表示数据的标准技术。

在数据可视化中，信息以图形的形式传达给最终用户，这些图形可以是 1D、2D、三维甚至更高维度。这完全取决于我们试图传达的意思。

让我们看一下用于向用户传达视觉信息的标准图形:

这是数据的 2D 图形表示，其中数据点显示为垂直/水平条。每个条代表一个数据点。当数据点不涉及时间维度时，这些点的显示顺序可能不会有任何不同。当我们处理用于表示条形图的时间序列数据时，我们通常遵循沿 X(水平)轴显示的时间顺序。

让我们看一下由四个数据点生成的示例图表。数据代表每个用户拥有的数量:

解读:图中既有行和列的文本数据，也有视觉效果。如果仔细观察，文本数据的大小更小，只有四条记录。但是视觉图形在不了解任何数据的情况下直接传达了信息。

图表传达的信息是:

其他解释也是可能的。它们留给读者。

这也是典型的 2D 图表，其中每个数据点都表示为画布上的一个点，并且属于同一数据集的所有这些点都用一条线连接起来。当从水平/垂直轴到直线的区域被完全覆盖时，该图表成为面积图。

同一图形中可以有多条线，表示同一实体的多个数据系列。

让我们根据与之前相同的数据来看一下这个面积图的示例:

这些是图表的属性:

这也是一个 2D 图表，绘制成一个圆圈中的多个扇区。当我们想要突出所有数据点的相对重要性时，此图表非常有用。

让我们看一下使用与之前相同的数据集绘制的示例图表，以便更好地理解它:

如你所见，很容易理解使用这张图表的每个人所拥有的金额的相对重要性。

得出的结论与前面的图表相似。但是图是一个简单的圆，这里没有多个维度给用户增加负担。

这也是一个 2D 图形，其中数据轴是等距扇区的边缘(像饼图的边缘)。当我们想要了解每个数据点的相对重要性的多维度时，此图非常有用。

为了更好地理解这个图表，让我们看一下这个样本数据和图表:

数据由八列组成:

我们想画一张图表，向我们展示以下内容:

我们已经在雷达图中绘制了所有这些信息，其中轴是扇区(天)，上限为 400 的最大值。每个用户的价值被一个接一个地画出来，这样我们就知道总价值，而不是相对价值(这类似于面积叠加)。

散点图可以是多维图形。当我们沿着轴渲染画布上对应于数值的每个数据点时，这是一个更容易理解的图形。该图有助于理解轴上每个点的相对重要性。

气泡图是散点图的变体，画布上的点将数值显示为大气泡(表示其重要性)。

让我们用这个例子来看看这两个图形:

左侧的图形是气泡图，右侧的图形是散点图。

让我们看看生成的数据和图表。

输入数据:

用气泡图:

使用散点图:

Hadoop 拥有丰富的数据源和应用生态系统，可以帮助我们构建丰富的可视化。在接下来的章节中，我们将了解两个这样的应用:

我们还将学习如何使用 Apache 超集处理关系数据库(如 MySQL)中的数据。

让我们快速了解一下德鲁伊集群的不同组件:

| 组件 | 描述 || 德鲁伊经纪人 | 这些节点知道数据在集群中的位置。这些节点由应用/客户端联系，以获取德鲁伊内部的数据。 || 德鲁伊协调员 | 这些节点管理历史节点上的数据(加载、删除和负载平衡数据)。 || 德鲁伊霸主 | 该组件负责接受任务并返回任务的状态。 || 德鲁伊路由器 | 当数据量在万亿字节或更高范围时，需要这些节点。这些节点将请求路由到代理。 || 德鲁伊历史 | 这些节点存储不可变的段，是德鲁伊集群的骨干。它们服务于加载段、删除段，并服务于对段请求的查询。 |

下表列出了其他几个必需的组件:

| 组件 | 描述 || 动物园管理员 | Apache Zookeeper 是一个高度可靠的分布式协调服务 || 元数据存储 | MySQL 和 PostgreSQL 是流行的关系数据库系统，用于跟踪所有部门、主管、任务和配置 |

Apache Druid 可以独立安装，也可以作为 Hadoop 集群的一部分安装。在本节中，我们将看到如何通过 Apache Ambari 安装 Druid。

首先，我们调用 Hadoop 集群中服务列表下方的操作下拉列表。

屏幕如下所示:

在这个设置中，我们将同时安装德鲁伊和超集。超集是可视化应用，我们将在下一步中了解它。

选择屏幕如下所示:

选择两种服务后，单击下一步。

在这一步中，我们将可以选择安装应用的服务器。为此，我选择了节点 3。您可以选择任何想要的节点。

屏幕看起来像这样:

更改完成后，单击下一步。

在这里，我们可以选择为安装的组件选择需要从属节点和客户端的节点。我留下了已经为我选择的选项:

在这一步中，我们需要为德鲁伊和超集应用使用的元数据存储选择数据库、用户名和密码。随意选择默认的。我给了 MySQL 作为他们两个的后端存储。

屏幕如下所示:

一旦更改看起来不错，点击屏幕底部的“下一步”按钮。

在此步骤中，应用将自动安装，状态将在计划结束时显示。

安装完成后，单击下一步。对当前屏幕的更改如下所示:

一旦一切顺利完成，我们会看到一个已经完成的总结。完成后，单击完成:

让我们看看如何加载样本数据。从网上下载德鲁伊档案:

提取档案:

将示例维基百科数据复制到 Hadoop:

提交导入请求:

这一步之后，德鲁伊会自动将数据导入到德鲁伊集群中，进度可以在霸王控制台看到。

一旦摄取完成，我们将看到作业状态为成功。

In case of FAILED imports, please make sure that the backend that is configured to store the Metadata for the Druid cluster is up and running. Even though Druid works well with the OpenJDK installation, I have faced a problem with a few classes not being available at runtime. In order to overcome this, I have had to use Oracle Java version 1.8 to run all Druid applications.

现在我们准备开始使用德鲁伊来完成可视化任务。

Apache 超集还允许我们读取关系数据库管理系统(如 MySQL)中的数据。我们还将在本节中创建一个示例数据库，稍后我们可以将它与超集一起使用来创建可视化。

雇员数据库是一个标准数据集，其中包含示例组织及其雇员、工资和部门数据。我们将看看如何为我们的任务设置它。

本节假设 MySQL 数据库已经配置并运行。

在任何可以访问 MySQL 数据库的服务器上，使用以下命令从 GitHub 下载示例数据集:

在这一步中，我们将把文件中的数据内容导入到 MySQL 数据库中:

这是一个重要的步骤，只是为了确保我们导入的所有数据都正确地存储在数据库中。验证发生时会显示完整性检查的摘要:

现在数据被正确加载到名为员工的 MySQL 数据库中。

一旦我们有了规范化的数据，我们将看到如何使用这个表中的数据来生成丰富的可视化。

超集是一个现代化的企业级商业智能应用。这个应用的重要特性是，我们可以直接从浏览器运行所有分析。没有必要为此安装任何特殊软件。

如果你还记得，我们已经在前面的章节中安装了超集和德鲁伊。现在我们需要学习如何使用超集来构建丰富的可视化。

输入admin作为安装过程中选择的用户名和密码。

仪表板是超集应用的重要部分。他们让我们以图形形式展示分析计算的结果。仪表板是从切片创建的，而切片又是从超集应用中配置的各种数据源构建的。

为了构建仪表板，我们首先需要配置数据源。因此，让我们点击顶部导航中的源菜单，然后点击刷新德鲁伊元数据:

完成这一步后，我们将进入数据源页面，一个新的数据源将自动出现在这里。还记得我们之前把这个数据集上传到德鲁伊吗？

现在我们可以点击数据源名称(绿色)，这将把我们带到数据源探索页面:

正如我们所看到的，这个页面被分成多个部分。

在我们开始构建可视化之前。让我们更仔细地看看我们摄入到 Druid 中的数据，以及我们可以从这些数据中呈现什么类型的图形:

因此，我们列出了数据的所有属性。让我们看一下示例一，以更好地理解我们正在谈论的内容:

一旦我们对数据维度有了一些了解，我们就需要看看我们可以从这些数据中回答什么类型的问题。这些问题是我们容易获得的见解。稍后，我们可以用最适合我们的图形形式来表示这些。

让我们看看从这些数据中我们可以回答的一些问题。

一维洞见:

沿尺寸计数:

多维洞察:

看起来很有趣，对吧？为什么我们不尝试使用 Apache 超集来创建一个具有这些见解的仪表板呢？

为此，我们需要在超集应用中遵循这个简单的工作流程:

如果我们回想一下，我们已经在前面的章节中完成了步骤 1 。所以，我们可以马上进入第二步和第三步。

让我们看看使用超集应用中的切片功能可以生成什么类型的图形。

在此切片中，我们将看到如何生成图形来查找对数据集中的编辑做出贡献的唯一用户。

首先，我们需要从顶部导航进入切片页面。之后，屏幕看起来是这样的:

在此页面中，单击加号图标(+)添加新切片:

之后，我们会看到系统中配置的数据源列表。我们必须点击数据源名称:

在我们点击 wikiticker 之后，我们会进入可视化页面，在那里我们定义想要呈现为图形的维度。

对于当前的用例，让我们从用户界面中选择以下选项:

听起来很简单，对吧？我们先不要急着看仪表盘。在接下来的部分中，让我们根据数据创建更多分析。

在这一节中，我们将学习如何为美国顶级地区构建一个单词云，这些地区为我们在 Druid 中的数据源中的维基百科编辑做出了贡献。我们可以继续编辑上一节中的相同切片，或者转到一个空白切片，如前一节所述。

让我们专注于生成单词云时需要选择的值:

单词云的意义在于我们可以根据单词的相对大小来看到最上面的单词。当我们想要看到相对意义的单词较少时，这种可视化是有帮助的。

让我们尝试从数据中生成另一个图形。

在本节中，我们将了解到一种不同类型的图表，这种图表我们在本章中还没有见过。但是首先，让我们提出用例。

我们希望在所有三个级别找到每个频道、城市名称和命名空间的唯一用户；也就是说，图形应该能够向我们展示:

为了显示这种层次数据，我们可以使用太阳爆发图。

让我们看看需要选择什么类型的值来呈现这种类型的图表:

如我们所见，图中有三个同心环:

当我们悬停在最内环上时，我们可以看到它是如何扩展到最外环的。同样的事情也发生在其他戒指上。

当我们想要对数据进行漏斗分析时，这种图形非常有用。让我们在下一节中看看另一种类型的分析。

在这个网络图中，我们希望通过唯一的用户数度量来了解名称空间和通道之间的连通性。由于这是一个网络图，我们将看到节点在不同的路径上重复。

让我们看看如何得出这个图表:

请随意拖动图形中的节点，以了解更多关于它们如何相互连接的信息。节点的大小表示唯一的用户数及其细分(类似于阳光爆发图)。

现在我们将学习桑基图，这是一种类似瀑布的方式来表示数据之间的分解和互连。在这种情况下，我们希望了解在唯一用户指标方面，通道名称和国家名称维度是如何关联的:

至此，我们可以生成的所有分析列表都已完成。现在在下一节中，我们将看到如何在仪表板中使用它(这是我们最初的目标)。

到目前为止，我们已经看到了如何在 Apache 超集应用中为维基百科编辑存储在 Apache Druid 数据库中的数据创建切片。现在是时候让我们看看如何创建一个仪表板，以便我们可以与业务团队或任何其他我们想要分享见解的团队共享它。

在这个过程中，第一步是单击顶部导航栏上的仪表板菜单。这将带我们进入添加新仪表板页面，我们需要填写以下详细信息。

| 元素 | 描述 | 值 || 标题 | 这是我们要创建的仪表板的名称 | 我的仪表板 1 || 鼻涕虫 | 仪表板的简称 | dash1 || 部分 | 我们要添加到仪表板的切片列表。 |

|| 其他字段 | 我们可以将其他字段留空，因为它们不是创建仪表板所必需的 | |

这是本页的图片:

一旦更改看起来不错，点击屏幕底部的保存按钮。

这将带我们进入下一步，我们可以看到仪表板已成功创建:

我们可以在仪表板列表中看到我的仪表板 1。要访问此仪表板，请单击它，我们将进入仪表板屏幕:

如我们所见，我们有一种非常强大的方式来表示所有原始数据。这肯定会对最终用户产生影响，确保信息得到传达。

到目前为止，我们已经学习了如何从存储在 Apache Druid 柱状数据库中的数据创建切片和仪表板。在下一节中，我们将看到如何连接到关系数据库管理系统，并根据这些数据生成切片和仪表板。

Apache 超集是使用 Python 编程语言构建的，并且支持许多关系数据库，因为它使用 SQLAlchemy 作为数据库驱动程序。这些驱动程序的安装超出了本节的范围。但是，安装这些应该非常容易。大多数时候，操作系统供应商会为我们打包它们。所以，我们不用担心手动安装这些。

以下是 Apache 超集支持的一些数据库:

| 数据库名称 | Python 包名 | 驾驶员 URI 前缀 | 详情 || 关系型数据库 | mysqlclient | mysql:// | 甲骨文数据库 || 一种数据库系统 | psycopg2 | postgresql+psycopg2:// | 世界上最先进的开源数据库 || 很快 | pyhive | presto:// | 开源分布式查询引擎 || 神谕 | cx_Oracle | oracle:// | 甲骨文公司创建的多模型数据库管理系统。 || Sqlite | | sqlite:// | 快速、可扩展的嵌入式数据库库 || 红移 | sqlalchemy-redshift | postgresql+psycopg2:// | 亚马逊红移是建立在 PostgreSQL 上的柱状数据库 || MSSQL | pymssql | mssql:// | 微软 SQL 服务器 || 黑斑羚 | impyla | impala:// | Apache Impala 是运行在 Hadoop 上的大规模并行处理 SQL 引擎 || SparkSQL | pyhive | jdbc+hive:// | Apache Spark 模块，用于在 Spark 程序中编写 SQL。 || 青梅 | psycopg2 | postgresql+psycopg2:// | Greenplum 是一个先进的、功能齐全的开源数据平台 || 雅典娜(智慧与技艺的女神) | PyAthenaJDBC | awsathena+jdbc:// | 亚马逊雅典娜是无服务器交互式查询服务 || 垂直的 | sqlalchemy-vertica-python | vertica+vertica_python:// | Vertica 是大数据分析软件 || 钟罩 | sqlalchemy-clickhouse | clickhouse:// | 开源分布式柱状数据存储 |

如果您还记得，在前面的部分中，我们已经导入了一个名为 Employees 的示例数据库，并将其加载到 MySQL 数据库中。我们将深入研究这个示例数据存储，以便了解我们可以从中生成哪些类型的分析。

employees表包含员工的详细信息(随机生成的数据)，具有以下属性

| 栏 | 数据类型 | 描述 || emp_no | INTEGER | 员工编号 || birth_date | DATE | 员工出生日期 || first_name | STRING | 员工的名字 || last_name | STRING | 员工的姓氏 || gender | STRING | 员工性别，男性为男，女性为女 || hire_date | STRING | 员工的最新加入日期 |

departments表由组织中每个部门的基本细节组成。这张表进一步说明了这一点:

| 表列 | 数据类型 | 描述 || dept_no | STRING | 部门编号 || dept_name | STRING | 部门名称 |

dept_manager表记录了员工担任给定部门经理的情况。更多详情见下表:

| 表列 | 数据类型 | 描述 || emp_no | INT | 担任该部门经理的员工 ID || dept_no | STRING | 部门标识 || from_date | DATE | 员工担任该部门经理的起始日期。 || to_date | DATE | 员工担任该部门经理的截止日期。 |

| 表列 | 数据类型 | 描述 || emp_no | INT | 员工编号 || dept_no | STRING | 部门标识 || from_date | DATE | 员工所属部门的起始日期 || to_date | DATE | 该部门员工的最后日期 |

标题表包含从给定日期到结束日期的所有员工角色。更多细节如下所示:

| 表列 | 数据类型 | 描述 || emp_no | INT | 员工 Id || title | STRING | 员工的指定 || from_date | DATE | 员工担任此角色的开始日期 || to_date | DATE | 员工履行此职责的最后日期 |

salaries表由给定员工的薪资历史记录组成。下表解释了更多详细信息:

| 表列 | 数据类型 | 描述 || emp_no | INT | 员工 Id || salary | INT | 员工工资 || from_date | DATE | 计算薪资的起始日 || to_date | DATE | 计算薪资的最后一天。 |

employee_norm表由员工、工资、部门、dept_emp和职称表的数据组成。让我们详细看看这张表:

| 表列 | 数据类型 | 描述 || emp_no | INT | 员工编号 || birth_date | DATE | 员工出生日期 || full_name | STRING | 员工全名 || gender | STRING | 员工的性别 || hire_date | DATE | 员工加入日期 || salary | INT | 该期间员工的工资 || from_date | DATE | 薪资期间开始 || to_date | DATE | 薪资期间结束 || dept_name | STRING | 员工在此薪资期间工作的部门 || title | STRING | 在此期间指定员工 |

了解了员工数据库中的各种表格后，我们现在对目前掌握的数据有了一些了解。现在，下一个任务是找出我们可以从这些数据中生成什么类型的分析。我们将在下一节中了解这一点。

一旦我们对存储在 MySQL 数据库中的数据类型有了一些基本的了解。我们现在将看到我们可以从这些数据中回答什么类型的问题。

一维洞见:

多维洞察

如果我们按照这些思路思考，我们应该能够回答关于数据的非常重要的问题，并且应该能够生成漂亮的图形。

让我们举几个例子来说明在接下来的部分中我们可以生成什么类型的可视化。

在我们开始为员工表生成切片之前，我们应该首先注册它。注册过程包括以下步骤。

通过单击顶部导航栏中“源”菜单中的“数据库”下拉列表打开数据库，如下所示:

之后，我们需要点击页面上的加号(+)图标:

这将把我们带到一个页面，在那里我们可以注册新的数据库。屏幕如下所示:

我们将填写如下所示的详细信息。

| 字段名 | 值 | 描述 | || 数据库ˌ资料库 | employees | 我们要注册的数据库的名称。(在 MySQL 数据库中输入与其相同的名称) | || SQL anywhere uri | mysql+pymysql://superset:superset@master:3306/employees | URI 可以编程访问这个数据库。这将包括协议/驱动程序、用户名、密码、主机名和数据库名 | || 其他字段 | | 将它们保留为默认值 | |

在此之后，点击保存按钮，这将使用 Apache 超集保存数据库详细信息。我们将进入表格列表页面，如下所示:

如我们所见，我们已经在 MySQL 后端注册了员工数据库。

在下一步中，我们需要从顶部菜单中选择表格:

因为我们没有注册任何表，所以我们将看到一个像这样的空页面:

为了注册一个新的表，我们必须点击用户界面中的加号(图标)，这将我们带到以下页面:

输入如下所示的字段值，完成后单击保存:

| 字段名 | 值 | 描述 || 表名 | employee_norm | 我们要注册的表的名称。 || 数据库ˌ资料库 | employees | 选择已经向超集注册的数据库。 |

现在我们可以看到该表已成功注册，如下图屏幕所示:

超集的一个重要特性是，它将根据数据类型自动选择我们可以对表的列执行的不同类型的操作。这决定了我们在用户界面的其余部分显示哪些类型的维度和指标。

为了选择这些选项，我们需要通过单击编辑图标来编辑表格，我们将看到此页面:

正如我们所看到的，Apache 超集已经自动识别了每个字段的数据类型，它还为我们提供了一个选项来为各种活动选择这些维度。下表列出了这些活动:

| 活动 | 描述 || 可分组 | 如果选中该复选框，则该字段可用作分组操作的一部分(在 SQL 中为GROUP BY)。 || 可滤过的 | 如果选中该复选框，则该字段可用作条件操作(WHERE子句)的一部分。 || 区分计数 | 如果选中该复选框，则该字段可用作字段计数(DISTINCT)操作的一部分。 || 总和 | 如果选择了复选框，则该字段可用作SUM()功能的一部分。 || 最小/最大 | 指示该字段可用作查找最小值和最大值的一部分。 || 是暂时的 | 指示该字段是时间维度。 |

如上所示进行更改，然后单击保存按钮。

现在，我们准备在接下来的步骤中开始创建切片和仪表板。

正如我们在前面几节中看到的，为了创建仪表板，我们首先需要创建切片。在本节中，我们将学习创建几个切片。

在这一部分中，我们将学习如何创建可视化，显示每个部门的薪资细分百分比:

就像上一节一样，看看在没有任何编程知识的情况下创建好看的图形有多容易。

在下一节中，我们将从同一员工数据库中了解另一种类型的图形。

这是一个重要的图表，在这里我们确定了在整个组织历史中，不同性别之间的工资差异。这里我们用平均工资作为分析的基础。

从图中我们可以看出，男女之间的工资差距很大，而且非常接近。同期平均工资也有类似的增长。

在下一节中，我们将学习生成另一种类型的图形，这将使我们对数据有不同的见解。

这是一个重要的统计数据，我们想知道组织中不同职位的工资变化有多大。

从这张图中我们可以发现，很少有角色在组织内的总薪酬中有非常大的差异。

到目前为止，我们已经创建了三个切片，我们将使用到目前为止创建的切片创建一个新的仪表板。

在这一步中，我们将通过转到仪表板页面并单击添加仪表板图标(如前几节所示)来创建新的仪表板。

我们将看到下面的屏幕，在这里我们选择到目前为止创建的三个切片，然后单击保存:

仪表板保存成功后，我们可以看到它是这样的:

正如我们所看到的，仪表板是以简单的方式表达大量数据的非常强大的方式。

在本章中，我们学习了数据可视化，以及它如何帮助用户在不了解底层数据的情况下接收所需的消息。然后，我们看到了以图形方式可视化数据的不同方法。

我们浏览了用于可视化数据的 Hadoop 应用，如 Apache Druid 和 Apache 超集，并学习了如何将它们与 MySQL 等关系数据库一起使用。我们还看到了一个示例数据库，以帮助我们更好地理解应用。

在下一章中，我们将学习如何在云上构建我们的 Hadoop 集群。

在计算的早期，CPU 能力和存储非常匮乏，因此购买相关设备的成本非常高。随着 80 年代初苹果和微软在个人计算发展方面的进步，越来越多的个人和组织获得了这些计算设备。随着行业发展芯片制造方式，数十亿(如果不是数万亿)个晶体管被放在单个芯片上，这些计算设备的尺寸已经大幅缩小，从占据整个房间到在数据中心包含单个机架单元。当计算速度和存储设备容量开始增加时，个人和企业开始意识到高效管理其计算资源正在成为一项挑战。

互联网的广泛使用也对个人如何获取资源做出了重大贡献。

在本章中，我们将涵盖以下主题:

云计算，简称 Cloud，是一种在互联网上租用和使用电子存储空间、计算能力、网络带宽、IP 地址、数据库、网络服务器等资源的简单方式。云推动了按使用付费模式，即客户只为这些资源的使用付费，就像电网为其客户的电力消耗付费一样。

云计算已经改变了个人和组织在互联网上访问和管理其服务器和应用的方式。在云计算出现之前，每个人都习惯在自己的场所或专用数据中心管理自己的服务器和应用。单个芯片上多核计算的原始计算能力(中央处理器和图形处理器)的增加以及存储空间(硬盘和固态硬盘)的增加给有效利用可用计算资源带来了挑战。

随着云计算应用的增加，企业已经开始构建各种技术，并将其提供给消费者。我们将浏览率先推出云产品的组织列表，以及它们提供的不同类型的技术。

以下是提供云服务的公司列表:

正在以下列形式向消费者提供各种类型的资源:

现在，让我们看看顶级提供商微软、亚马逊和谷歌提供了哪些技术:

| 技术 | 蔚蓝 | 亚马逊网络服务 | 谷歌云 | 描述 || 服务器 | Azure 计算 | 亚马逊 EC2 | 谷歌计算引擎 ( GCE ) | 这项技术旨在提供随需应变的服务器，这些服务器可以是虚拟化的，也可以是专用/裸机的。 || 储存；储备 | 天蓝色存储 | 亚马逊 EBS | 谷歌存储 | 这是按需存储，可以根据需要连接到计算节点。一些供应商提供了按需扩展这些存储设备大小的能力。 || 网络 | Azure 网络 | 是 | 谷歌网络服务 | 提供商根据应用的网络要求提供 100 Mbps 至 10 Gbps 的网络带宽。 || 数据库 | Azure 数据库 | 亚马逊无线电数据系统 | 谷歌云 SQL | 对于托管数据库，我们不需要担心数据库服务器的维护，因为供应商会自动处理对这些服务器的支持。请记住，在某些情况下，我们需要为自己规划高可用性。 || 内容交付 | 天蓝色 CDN | 亚马逊云前线 | 谷歌云 CDN | 如果我们想通过利用交付网络将静态资产推给用户，这将非常有帮助，因为它可以显著降低延迟。我们还可以将它用作私有存储来存储所有文件，如备份、会议记录等。 || 域名系统 ( 域名系统) | DNA 蓝色 | 亚马逊 S3 路线 | 谷歌云域名系统 | 域名系统对于在互联网上运行我们的应用至关重要。这项服务让我们的生活变得更加轻松，因为它让我们的服务器可以被基础设施的其他部分访问，而不必运行我们自己的 DNS 服务器。 || 业务邮件 | 微软 o365 | 亚马逊工作邮件 | 谷歌邮件 | 对于要求以安全和可扩展的方式访问电子邮件和日历的组织来说，这是必须的。 || 机器学习 | Azure AI +机器学习 | 亚马逊机器学习 | 谷歌 ML 引擎 | 机器学习技术已经成为这些天的流行语。供应商提供了几种与机器学习相关的技术，因为我们只需关注我们需要做什么，而不必担心运行这些算法所需的基础设施。 || 分布式拒绝服务 ( 分布式拒绝服务)保护 | 天蓝色分布式拒绝服务保护 | 自动气象站防护罩 | – | 对于那些无法承受服务宕机的组织来说，这是一件非常重要的事情，当大规模拒绝服务攻击发生时，会影响网站的常规访问者。 || 监视 | 天蓝色监视器 | 亚马逊云观测 | 谷歌监控 | 如果不监控我们的应用和基础架构，我们将无法看到我们的表现。这些服务有助于我们保持业务正常运行，并对触发我们在云上运行的应用和基础架构宕机的事件做出响应。 || 容器 | 蔚蓝集装箱服务 ( AKS ) | 亚马逊库本内特弹性集装箱服务 ( 亚马逊 EKS ) | 谷歌库比厄引擎 | 这是一种基础架构，允许您将应用作为容器运行，而不是拥有完整的计算环境来运行它们。 |

传统组织有自己的 IT/基础架构团队来管理其专用服务器和网络。在规划向云的迁移时，我们必须牢记以下事项，以提高基础架构的可操作性。

规划云基础架构涉及:

云提供商让您可以选择租赁完全拥有物理硬件的服务器，或者与我们这样的其他云用户共享物理硬件。为了对此做出决定，我们需要了解这些模型的优缺点。

这些类型的服务器的所有权属于单个用户或组织，不与任何其他用户共享。这种设置有以下几个优点:

对于简单的实验来说，拥有一台完整的服务器是昂贵的。在这种情况下，我们可以采用共享设置，在给定的物理硬件中租用一些资源。共享服务器的一些优势如下:

根据我们计划运行的应用类型，我们必须了解供应商就正常运行时间为这些应用提供的服务级别协议 ( SLA )，并且我们需要相应地计划我们的应用。

让我们看一下使用 DNS 实现应用高可用性的简单方法:

在此设计中，会发生以下情况:

在这个设计中，我们需要记住以下几点:

Cloud providers provide a private IP address. In order to minimize the risk of DB servers being accidentally exposed to the internet, we should block the public internet access to these servers.

让我们来看看另一种设计，它也能保护我们的网络服务器免受互联网攻击:

在本设计中，与之前的设计相比，我们做了以下更改:

如果我们仔细观察这个设计，我们会发现这些是优于前一个设计的优点:

Depending on the security policy of the organization, you might need to enable SSL on the web servers as well.

业务连续性规划 ( BCP )是组织处于成长阶段时需要考虑的一件非常重要的事情。网络、服务器或数据库或任何其他云基础架构组件的任何宕机都可能导致整个业务瘫痪。

在规划 BCP 时，有几件关键的事情要记住:

如果云提供商提供的服务出现计划外停机，我们所有的服务都会随之中断。为了最大限度地提高我们业务的可用性，我们需要在另一个地理区域建立备份设置。对于一些组织来说，这可能是昂贵的，因为整个设置将被复制，但是为了业务连续性，这是规划云基础架构时要考虑的一个重要特性。

地震、洪水、火灾等事件很难预测。因此，我们需要制定必要的计划来保持我们的业务运行，这取决于我们的服务器在云上的位置，以及供应商在构建数据中心时遵循的技术标准。

业务数据以多种形式存在，并以文件、数据库服务器和大数据系统的形式存储。对于 BCP，我们需要仔细分析我们可以计划在哪些其他远程位置保留我们的数据副本，并进行测试运行，看看我们的应用是否可以通过单击一个按钮从任何一个地理位置无缝运行。

此图试图解释我们如何通过在多个数据中心设置相同的应用来实现 BCP:

该系统可以是:

在 Hot-Hot 系统中，两个数据中心同时处于活动状态，为用户的流量提供服务。这里，我们采用了几种 CDN 和地理定位技术来将用户路由到给定的数据中心。

我们在这样做时面临的挑战是，如果一个区域完全空白，另一个区域应该有足够的空间来确保另一个区域的流量被吸收

使用该系统的优点是用户体验良好，因为在该设计中，用户被路由到最近的系统

在此系统/设计中，任何时候都只有一个区域处于活动状态，只有在 BCP(业务连续性规划)的情况下，我们才会回到另一个区域。

我们在使用该系统时面临的挑战如下:

使用该系统的优点是所有的写操作都发生在一个区域，这使得数据库设计变得简单。

当您考虑迁移到云时，安全性非常重要。以下是需要记住的事情:

当我们谈论云时，我们将永远无法物理访问服务器(除非我们获得云供应商的许可)。在这种情况下，我们必须了解云提供商遵循什么级别的策略和实践来确保我们的应用将在其上运行的服务器的物理安全。

例如，政府在考虑迁移到云时可能需要一整套不同的物理安全限制。同样，有几个标准，如 PCI 和 HIPAA，在这个模型上执行更强的规则。

如果我们的业务需要遵守这些标准，我们需要选择支持所有这些标准的云变体。

在云上，我们可以选择自己托管应用，也可以使用作为服务提供的应用软件即服务 ( SaaS )。如果我们在自己调配的服务器(专用或共享)上托管应用，我们需要在服务器级别实施正确的防火墙规则，以及正确的用户访问规则，以确保我们的软件只允许经过授权和正确身份验证的用户。

为了保护我们在云上的服务器，我们需要实施适当的防火墙规则、域名系统区域，甚至拥有自己的虚拟专用网络，以确保我们的所有资产不会受到损害并暴露在互联网上。

云是互联网的代名词，对我们的数据和基础设施构成持续威胁。除非我们实施适当的安全措施，否则任何人都可以从我们的系统中随意获取任何东西。

单点登录 ( 单点登录)已经受到在云上为各个部门使用多个应用的组织的欢迎。最近，组织已经停止构建自己的应用来运行业务，而是开始采用其他服务。当此类应用的数量增加时，这些应用的用户不断面临在所有这些网站中输入用户名和密码的挑战。

为了提供无缝的浏览体验，同时遵守企业安全标准，许多提供商实现了 OAuth 和 SAML，因为它们是行业公认的。

谈到安全性，重要的是要理解遵循 AAA 标准的应用将解决企业面临的许多挑战。

美国汽车协会标准涉及:

认证确保用户的身份被正确验证。

审核确保所有访问和使用资源的尝试都得到跟踪，这也可以用于任何调查，并提供适当的会计和计费(如果需要)。

通过遵循这些最佳实践，我们可以确保事情在大范围内顺利进行。

我们之前看到，云提供了一种灵活且简单的方法来租用资源，如服务器、存储、网络等。云让消费者可以很容易地使用现收现付模式，但是云的许多复杂性被提供商隐藏了起来。

为了更好地理解 Hadoop 是否非常适合在云上，让我们尝试进一步挖掘，看看云是如何在内部组织的。

云的核心是以下机制:

让我们看一下这样一个云上数据中心的简单设计:

在上图中，我们有以下设备:

正如我们所看到的，云提供商拥有大量这样的体系结构，以使它们具有可扩展性和灵活性。

您应该已经正确地猜到，当这种服务器的数量增加时，当我们请求新的服务器时，提供商可以将服务器分配到该区域的任何地方。

这使得计算和存储在一起有点困难，但也提供了弹性。

为了解决这一同地问题，一些云提供商提供了创建虚拟网络和使用专用服务器的选项，然后在这些服务器上分配他们的所有虚拟节点。这在某种程度上更接近数据中心设计，但足够灵活，可以在不需要时返还资源。

让我们回到 Hadoop，并提醒自己，为了从 Hadoop 系统中获得最佳效果，我们应该让 CPU 功率更接近存储。这意味着中央处理器和存储器之间的物理距离应该更小，因为总线速度与处理要求相匹配。

中央处理器和存储之间的输入/输出速度越慢(例如，iSCSI、存储区域网络、网络连接存储等)，我们从 Hadoop 系统获得的性能就越差，因为数据是通过网络获取的，保存在内存中，然后馈送给中央处理器进行进一步处理。

这是在云上设计 Hadoop 系统时需要记住的重要事情之一。

除了性能原因，还有其他需要考虑的因素:

现在，让我们尝试了解如何在云环境中处理这些问题。

在前几章中，我们看到可以通过以下方法安装 Hadoop:

当我们想要在云上部署 Hadoop 时，我们可以使用以下方式进行部署:

在本节中，我们将学习如何使用谷歌云数据块来设置单节点 Hadoop 集群。

这些步骤可以分为以下几个部分:

本节假设您已经有一个谷歌云帐户。

一旦在项目中启用了数据块，我们就可以点击创建来创建一个新的 Hadoop 集群。

之后，我们会看到另一个屏幕，需要在其中配置集群参数:

我把大部分东西都保留了默认值。稍后，我们可以点击创建按钮，为我们创建一个新的集群。

SSH 窗口如下所示:

如您所见，Hadoop 命令对我们来说是现成的，我们可以运行任何标准的 Hadoop 命令来与系统交互。

要删除集群，请单击删除按钮，它将显示一个确认窗口，如下图所示。此后，群集将被删除:

看起来很简单，对吧？是的。云提供商让用户使用云变得非常简单，并且只为使用付费。

云已经成为存储个人数据和业务数据的重要目的地。根据数据的重要性和保密要求，组织已经开始使用云来存储他们的重要数据集。

下图试图总结典型企业的各种访问模式，以及它们如何利用云来存储数据:

云提供商提供不同种类的存储。让我们看看这些类型是什么:

当我们希望与计算服务器一起使用这种存储，并希望通过主机操作系统管理存储时，这种类型的存储非常有用。

为了更好地理解这一点，这种类型的存储相当于我们购买笔记本电脑/MacBook 时附带的硬盘/固态硬盘。就笔记本电脑存储而言，如果我们决定增加容量，我们需要用另一个磁盘替换现有磁盘。

说到云，如果我们想增加更多容量，我们可以购买另一个更大容量的存储，并将其连接到我们的服务器。这是云变得流行的原因之一，因为它可以非常容易地添加或缩减我们需要的存储。

记住这一点很好，因为我们的应用有许多不同类型的访问模式，云供应商还提供具有不同存储/速度要求的数据块存储，以他们自己的容量/IOPS 等衡量。

让我们举一个容量升级要求的例子，看看我们如何在云上利用这种数据块存储。

为了理解这一点，让我们看一下这个图中的例子:

想象一下由管理员创建的名为 DB1 的服务器，原始容量为 100 GB 。后来，由于客户的意外需求，一个应用开始消耗所有的 100 GB 存储，因此管理员决定将容量增加到 1 TB (1，024 GB)。

在这种情况下，工作流是这样的:

文件是计算的基础。如果你熟悉 UNIX/Linux 环境，你已经知道，一切都是文件在 UNIX 世界里。但是不要与此混淆，因为每个操作系统都有自己处理硬件资源的方式。在这种情况下，我们不担心操作系统如何处理硬件资源，但我们谈论的是用户作为日常业务的一部分存储的重要文档。

这些文件可以是:

尽管它们在我们的计算机中看起来很简单，但它们可能具有重要的业务意义，当我们考虑将它们存储在云上时，应该小心处理。

大多数云提供商都提供了一种在云上存储这些简单文件的简单方法，并且在安全性方面也提供了灵活性。

获取此表单存储的典型工作流程如下:

一些云提供商根据客户在创建存储桶时选择的功能数量向其收费。

Please choose a hard-to-discover name for buckets that contain confidential data, and also make them private.

这是业务关键数据的一个非常重要的要求，因为我们不希望信息泄露到组织范围之外。云提供商为我们提供静态加密设施。一些供应商选择自动执行此操作，一些供应商还提供了灵活性，允许我们为自己拥有的数据选择加密密钥和加密/解密方法。根据组织策略，我们应该遵循最佳实践来处理云上的这种情况。

随着存储设备性能的提高，加密不会在解密/加密文件时增加大量开销。如下图所示:

继续之前的相同示例，当我们选择加密 1 TB 的底层数据块存储时，我们可以利用云提供的加密，在那里他们会自动为我们加密和解密数据。因此，我们不必在主机操作系统上使用特殊的软件来进行加密和解密。

请记住，加密可以是供应商提供的数据块存储和基于文件的存储中的一项功能。

这种存储对于在云中存储很少访问的重要备份非常有用。由于我们在这里处理的是一种特殊类型的数据，我们还应该意识到，云供应商可能会对来自该存储的数据访问收取很高的费用，因为它应该被写入一次并被遗忘(直到需要为止)。这种机制的优势在于，我们只需支付更少的费用就可以存储甚至千兆字节的数据。

在这一章中，我们了解了云计算的含义，并看到了云如何彻底改变了我们在互联网上访问和管理服务器和应用的方式。然后，我们浏览了不同提供商在云上提供的不同技术的列表。

我们还学习了如何规划我们的云基础架构，并研究了在云上构建我们自己的 Hadoop 集群所涉及的不同步骤。最后，我们看到了在云上存储和访问数据的不同方式。

在下一章中，我们将了解一些部署 Hadoop 集群的策略和最佳实践。

Hadoop 本身以强大的核心和文件系统开始，旨在应对大数据挑战。后来，在此基础上开发了许多应用，创建了一个相互配合的大型应用生态系统。随着应用数量开始增加，创建和管理 Hadoop 环境的挑战也随之增加。

在本章中，我们将了解以下内容:

Apache Ambari 遵循主/从架构，其中主节点指示从节点执行某些操作，并报告每个操作的状态。主节点负责跟踪基础设施的状态。为此，主节点使用数据库服务器，该服务器可以在设置期间进行配置。

为了更好地理解安巴里是如何工作的，让我们来看看安巴里的高层架构，如下图所示:

核心是，我们有以下应用:

安巴里服务器具有以下入口点，当向ambari-server程序传递不同参数时，这些入口点可用:

当从命令行用start、stop、reset、restart参数调用脚本时，守护程序管理模式被激活。

例如，如果我们想要启动 Ambari 后台服务器，我们可以运行以下命令:

一旦安装了 Ambari，我们就可以使用这种模式来升级 Ambari 服务器本身。当我们用upgrade标志调用ambari-server程序时，就会触发这一点。如果我们想升级整个安巴里堆栈，我们可以传递upgradestack标志:

一旦安巴里从互联网上下载(或通过 YUM 和 APT 安装)，我们需要做一个软件的初步设置。当我们将setup标志传递给程序时，可以触发该模式。这个模式会问我们几个需要回答的问题。除非我们完成这一步，否则 Ambari 不能用于任何类型的服务器管理:

T he 轻量级目录访问协议 ( LDAP )用于企业中的身份管理。为了使用基于 LDAP 的身份验证，我们需要使用以下标志:setup-ldap(用于使用ambari设置ldap属性)和sync-ldap(执行来自ldap服务器的数据同步):

可插拔身份验证模块 ( PAM )是任何 UNIX 或 Linux 操作系统中身份验证和授权的核心。如果我们想为安巴里利用基于 PAM 的访问，那么我们需要使用setup-pam选项来运行它。如果我们想从 LDAP 转向基于 PAM 的身份验证，我们需要使用migrate-ldap-pam运行它:

Kerberos 是另一种先进的身份验证和授权机制，在网络环境中非常有用。这简化了大型服务器上的真实性、授权和审核 ( AAA )。如果我们想对 Ambari 使用 Kerberos，我们可以使用setup-kerberos标志:

如果我们想拍摄当前安装的 Ambari 的快照(不包括数据库)，我们可以进入这个模式。这支持通过backup和restore标志调用的备份和恢复方法:

除了这些选项之外，安巴里服务器程序还提供了其他选项，您可以使用-h(帮助)标志来调用这些选项。

安巴里代理是一个程序，它运行在我们希望由安巴里管理的所有节点上。该程序定期向主节点发送心跳信号。使用该代理，ambari-server执行服务器上的许多任务。

这是 Ambari 应用的强大功能之一。该 web 应用由运行在主主机上的 Ambari 服务器程序公开；我们可以在端口8080上访问这个应用，它受到身份验证的保护。

Ambari 支持多个关系数据库管理系统来跟踪整个 Hadoop 基础设施的状态。在第一次安装 Ambari 服务器的过程中，我们可以选择我们想要使用的数据库。

在撰写本文时，安巴里支持以下数据库:

在本节中，我们将学习如何使用 Ambari 从头开始设置一个全新的 Hadoop 集群。为了做到这一点，我们需要四个服务器——一个服务器用于运行 Ambari 服务器，另外三个节点用于运行 Hadoop 组件。

下表显示了我们在本练习中使用的服务器配置:

| 服务器类型 | 名称 | CPU | ram | 磁盘 || Ambari 服务器节点 | 掌握 | one | 3.7 GB | 100 GB || Hadoop 节点 1 | 节点 1 | Two | 13 GB | 250 GB || Hadoop 节点 2 | 节点 2 | Two | 13 GB | 250 GB || Hadoop 节点 3 | 节点 3 | Two | 13 GB | 250 GB |

由于这是一个示例设置，我们对这种配置很满意。对于现实场景，请根据您的需求选择配置。

本部分和所有其他部分都假设您在所有服务器上都有一个工作正常的互联网连接，并且安全地用防火墙来防止任何入侵。

所有服务器都运行 CentOS 7 操作系统，因为它是一个使用 RPM/YUM 进行包管理的系统。当您在以下部分看到yum时，不要感到困惑。

在我们开始使用服务器之前，我们需要运行基本的实用程序来帮助我们解决服务器的各种问题。它们是作为下一个命令的一部分安装的。如果你不确定它们是什么，不要担心。除了mysql-connector-java和wget以外，所有其他公用设施都不是强制性的:

Please use a strong password for production setup, otherwise your system will be vulnerable to any attacks.

现在我们已经完成了基础工作，让我们运行安巴里服务器设置。请注意，我们需要回答以下几个突出显示的问题:

在创建 Hadoop 集群之前，我们还需要做几个步骤。

由于我们已经启动并运行了 Ambari 服务器，因此让我们生成一个 RSA 密钥对，用于 Ambari 服务器和 Ambari 代理节点之间的通信。

如果您已经在采购服务器和基础架构的过程中这样做了，则此步骤是可选的:

这将在/home/user/.ssh目录中生成两个文件:

This step of propagating all the public SSH keys can be done during the server provisioning itself, so a manual step is avoided every time we acquire new servers.

现在，我们将只使用安巴里网络界面完成所有工作。

在本节中，我们将使用 Ambari 网络界面构建一个 Hadoop 集群。本节假设以下情况:

这是主页面，用户界面上有多个选项。由于这是全新的安装，目前还没有可用的集群数据。

让我们看看主页的截图:

从这个地方，我们可以开展以下活动:

正如您可能已经猜到的，本节用于启动一个向导，该向导将帮助我们从浏览器创建一个 Hadoop 集群。

本节有助于管理可以使用和管理 Ambari web 应用的用户和组。

该界面有助于为不同类型的用户创建视图，以及他们可以通过 Ambari 网络界面执行哪些操作。

由于我们的目标是创建一个新的 Hadoop 集群，我们将单击启动安装向导按钮并开始创建 Hadoop 集群的过程。

Hadoop 集群创建分为多个步骤。我们将在下面的部分中完成所有这些步骤。首先，我们会看到一个屏幕，我们需要在其中命名我们的 Hadoop 集群。

我选择了packt作为 Hadoop 集群名称。当在屏幕中输入 Hadoop 名称时，单击下一步。屏幕如下所示:

一旦我们命名了 Hadoop 集群，我们会看到一个屏幕来选择我们想要运行的 Hadoop 版本。

在撰写本文时，Ambari 支持以下 Hadoop 版本:

您可以选择安装的任何版本。我选择了默认选项 2.6.3.0 版本，可以在这个截图中看到:

单击屏幕底部的下一步继续下一步。

下一个逻辑步骤是选择我们将在其上安装 Hadoop-2.6.3.0 版本的服务器列表。如果您还记得原始表，我们将节点服务器命名为(1–3)。我们将在用户界面中输入这些。

此外，我们需要提供一个已经在所有节点(1–3)服务器上创建的 UNIX 用户名，这些服务器也可以接受 RSA 密钥进行身份验证。

请记住，这些主机名应该在域名系统 ( 域名系统)服务器中有正确的条目，否则安装将无法从这一步继续。

我给出的名字可以在下面的截图中看到:

输入数据后，点击注册并确认。

在此步骤中，如果详细信息准确，Ambari 代理会自动安装在给定的节点上。成功确认如下所示:

如果我们想删除任何节点，这是我们可以在其中进行操作的屏幕。当我们准备好进入下一步时，请单击“下一步”。

现在，我们需要选择要安装在我们选择的三台服务器上的应用/服务列表。

在撰写本报告时，安巴里支持以下服务:

| 应用/服务 | 应用描述 || HDFS | Hadoop 分布式文件系统 || Yarn+地图还原 2 | 下一代地图简化框架 || Tez | Hadoop 查询处理框架建立在 YARN 之上 || 储备 | 用于特定查询的数据仓库系统 || 巴什 | 非关系分布式数据库 || PIG | 用于分析 HDFS 数据集的脚本平台 || Sqoop | 在 Hadoop 和 RDBMS 之间传输数据的工具 || 驭象者 | 使用网络用户界面协调 Hadoop 作业的工作流 || 动物园管理员 | 分布式系统协调提供服务 || 猎鹰 | 数据处理和管理平台 || 暴风雨 | 流处理框架 || 水道 | 分布式系统，用于收集、聚合流式数据并将其移动到 HDFS || 累积性 | 分布式密钥/值存储 || 下面两个例子 | Amari 组件使用的共享服务 || 安巴里度量 | 基于 Grafana 的公制收集和存储系统 || 阿特拉斯 | 元数据和治理平台 || 卡夫卡 | 分布式流媒体平台 || 诺克斯 | 所有 Hadoop 组件的单点身份验证提供程序 || 日志搜索 | Ambari 管理的服务日志聚合器和查看器 || 看守人 | Hadoop 数据安全应用 || 游骑兵 KMS | 密钥管理服务器 || SmartSense | Hortonworks 智能感知工具，用于诊断应用 || Spark | 大规模数据处理框架 || 齐柏林笔记本 | 用于数据分析的网络笔记本 || 德鲁伊特 | 面向列的数据存储 || 象夫 | 机器学习算法 || 滑块 | 监控 Yarn 上应用的框架 || 超集 | 基于浏览器的关系数据库管理系统和德鲁伊数据探索平台 |

作为当前步骤的一部分，我们只选择了 HDFS 及其附属地区。屏幕显示如下:

做出选择后，单击用户界面底部的“下一步”按钮。

在这一步中，我们将看到在我们选择安装的三个节点上自动选择服务。如果我们想定制服务在节点上的位置，我们可以这样做。位置如下所示:

当更改看起来不错时，单击下一步。

一些应用支持从属和客户端实用程序。在此屏幕中，我们需要选择要在其上安装这些应用的节点。如果您不确定，请单击“下一步”。屏幕如下所示:

尽管 Ambari 会自动选择应用之间的大多数属性和链接，但它为我们提供了一些灵活性来选择某些功能的值，例如:

和其他有助于应用平稳运行的属性。这些在当前屏幕中以红色突出显示。

为了自定义这些，我们需要转到突出显示属性的选项卡，并根据我们的需要选择值。屏幕如下所示:

所有服务属性配置正确后，我们在 UI 中看不到任何红色内容，可以点击页面底部的“下一步”按钮。

在这一步中，我们将看到到目前为止所做更改的摘要。我们可以选择打印更改，这样我们就不会忘记它们(别担心，所有这些都可以在以后的用户界面上找到)。现在，我们可以单击部署。此时将对节点进行实际更改。

如果我们取消此过程，将不会对服务器进行任何更改。向导的当前状态如下所示:

在上一步中单击“部署”后，安巴里服务器将生成一个部署计划，应用将使用运行在所有节点上的安巴里代理并行部署在所有节点上。

在这一步中，我们可以看到实时部署的进度。

安装完所有组件后，它们将自动启动，我们可以在此屏幕中看到成功完成:

一切完成后，单击下一步。在任何失败的情况下，我们会看到失败的地方，并且会给我们一个重试安装的选项。如果有任何失败，我们需要挖掘错误并修复潜在的问题。

如果你已经按照本节开始时给出的说明去做了，你应该可以让一切顺利进行。

在这一步中，我们将看到已安装内容的摘要。屏幕如下所示:

单击“完成”按钮，这标志着 Hadoop 集群设置的结束。接下来，我们将进入集群仪表板。

这是我们刚刚创建的 Hadoop 集群的主页，在这里我们可以看到已经安装的所有服务和健康传感器的列表。

我们可以在这个界面中管理 Hadoop 集群的所有方面。请随意探索该界面并使用它来了解更多信息:

这标志着使用 Ambari 创建 Hadoop 集群的结束。

到目前为止，我们已经看到了如何使用 Ambari 创建单个 Hadoop 集群。但是，有没有对多个 Hadoop 集群的需求？

答案取决于业务需求。单个 Hadoop 集群和多个 Hadoop 集群各有利弊。

在我们讨论这两者的优缺点之前，让我们看看在什么场景下我们可以使用其中的任何一个。

这是最直接的方法，至少每个企业都从一个集群开始。随着业务多样性的增加，组织倾向于为每个部门或业务单位选择一个集群。

以下是一些优点:

采用这种方法的一些缺点如下:

带着这些想法，让我们看看企业中拥有 Hadoop 集群的另一种可能性。

即使在一个组织中拥有单个 Hadoop 集群更容易维护，但有时拥有多个 Hadoop 集群以保持业务平稳运行并减少对单点故障系统的依赖也很重要。

这些多个 Hadoop 集群的使用有几个原因:

当我们想到冗余的 Hadoop 集群时，我们应该考虑我们可以保留多少冗余。我们已经知道， Hadoop 分布式文件系统 ( HDFS )内置了内部数据冗余。

考虑到 Hadoop 集群有许多围绕它构建的生态系统(服务，如 Yarn、卡夫卡等)，我们应该仔细考虑和计划是让整个生态系统冗余，还是通过将数据保留在不同的集群中来仅使数据冗余。

由于有工具可以将数据从一个 HDFS 复制到另一个 HDFS，因此更容易使 Hadoop 的 HDFS 部分冗余。

让我们通过这张图来看看实现这一点的可能方法:

我们定义了两种类型的冗余集群:

该集群运行与主集群完全相同的一组应用，数据定期从主 Hadoop 集群中复制。由于这是从主群集到第二个群集的单向拷贝，因此当我们对此完全冗余的群集进行任何更改时，我们可以 100%确定主群集不会受到影响。

需要理解的一件重要的事情是，我们正在这个集群中运行应用的所有其他实例。由于每个应用都在自己的预定义位置维护其状态，因此应用状态不会从主 Hadoop 集群复制到该集群，这意味着在主 Hadoop 集群中创建的作业在该集群中不可见。这同样适用于卡夫卡的主题，动物园管理员节点，以及更多。

这种类型的集群有助于运行不同的环境，如质量保证、转移等。

在这种类型的集群设置中，我们创建一个新的 Hadoop 集群，并从主集群复制数据，就像前面的例子一样；但是在这里，我们并不担心在这个集群中运行的其他应用。

这种类型的设置适用于:

随着数据的老化，冷备份对企业来说非常重要。尽管 Hadoop 旨在存储无限量的数据，但并不总是需要保持所有数据可供处理。

出于审计目的和历史原因，有时需要保存数据。在这种情况下，我们可以创建一个只有 HDFS(文件系统)组件的专用 Hadoop 集群，并定期将所有数据同步到该集群中。

该系统的设计类似于数据冗余 Hadoop 集群。

尽管 Hadoop 在体系结构中有多个组件，但由于内部设计，并非所有组件都高度可用。

Hadoop 的核心组件是分布式、容错的文件系统 HDFS。HDS 有多个组件，其中之一是名称节点，它是文件在 HDFS 的位置的注册表。在早期版本的 HDS 中，名称节点是单点故障，在最新版本中，添加了辅助名称节点，以帮助满足 Hadoop 集群的高可用性要求。

为了使 Hadoop 生态系统的每个组件都成为一个高可用性系统，我们需要添加多个冗余节点(它们都有自己的成本)，作为一个集群一起工作。

还有一点需要注意的是，Hadoop 的高可用性在单个地理区域内是可能的，因为应用的数据位置是 Hadoop 的关键因素之一。当我们有多个数据中心时，我们需要交替考虑，以实现数据中心的高可用性。

这是业务连续性规划 ( BCP )的一部分，如果规划不正确，自然灾害可能会终结 Hadoop 系统。

一个可能的解决方案是在其他地理区域构建一个完全冗余的 Hadoop 集群，并定期保持数据同步。在一个地区发生任何灾难/故障的情况下，我们的业务不会停止，因为我们可以顺利运营。

许多企业内部采用不同的方式将软件发布到生产环境中。作为其中的一部分，他们遵循几种连续集成方法，以便更好地控制 Hadoop 环境的稳定性。用主生产环境中 X%的数据构建多个较小的 Hadoop 集群并在此运行所有应用是很好的。

应用可以在这些专用环境(质量保证、试运行等)上构建它们的集成测试，并且一旦一切正常，就可以将其软件发布到生产环境中。

我遇到的一个实践是，组织倾向于直接将代码运送到生产中，并最终因为未经测试的工作流或错误而面临应用的中断。拥有专用的 Hadoop 应用环境来彻底测试软件并实现更高的正常运行时间和更快乐的客户是一个很好的做法。

我们在前面的章节中已经看到，拥有高度可用的数据对于企业取得成功并跟上竞争对手的步伐非常重要。

在本节中，我们将探讨实现高可用性数据设置的可能方法。

Hadoop 以 HDFS 为核心存储文件。HDFS 具有机架感知能力，并且足够智能，当应用在数据节点上运行时，可以减少网络数据传输。

我们将看到几个将数据从一个 Hadoop 集群复制到另一个 Hadoop 集群的例子。但在此之前，让我们看看数据是如何布局的:

为了将数据从生产 Hadoop 集群复制到备份 Hadoop 集群，我们可以使用distcp。让我们看看怎么做:

当我们运行distcp命令时，会创建一个 MapReduce 作业来自动找出文件列表，然后将它们复制到目的地。

完整的命令语法如下所示:

让我们仔细看看几个重要的选项:

| 标志/选项 | 描述 || append | 如果目标文件已经存在，则将数据增量写入目标文件(仅执行append，不执行数据块级检查来进行增量复制)。 || async | 以非阻塞方式执行复制。 || atomic | 执行所有文件复制或中止，即使一个失败。 || Tmp <path> | 用于原子提交的路径。 || delete | 如果文件不在源树中，则从目标中删除文件。 || Bandwidth <arg> | 限制复制过程中要使用的网络带宽。 || f <file-path> | 文件名由需要复制的所有路径的列表组成。 || i | 忽略文件复制过程中的任何错误。 || Log <file-path> | 保存执行日志的位置。 || M <number> | 用于复制的最大并发映射数。 || overwrite | 覆盖文件，即使它们存在于目标上。 || update | 仅复制丢失的文件和目录。 || skipcrccheck | 如果通过，传输过程中将跳过循环冗余校验。 |

在这一章中，我们了解了 Apache Ambari，并详细研究了它的体系结构。然后，我们了解了如何使用 Ambari 准备和创建我们自己的 Hadoop 集群。为了做到这一点，我们还研究了在准备集群之前按照要求配置 Ambari 服务器。我们还了解了单个和多个 Hadoop 集群，以及如何根据业务需求使用它们。