这是第一本最初的俄文书籍，其中以实际示例研究了在云中处理大数据（Big Data）的秘密。
重点是Microsoft Azure和AWS解决方案。 考虑了所有工作阶段-使用云存储，云数据分析工具获取准备在云中处理的数据。 特别关注SAAS服务，展示了与专用服务器或虚拟机上部署的解决方案相比，云技术的优势。
本书专为广大读者而设计，将成为开发Azure，Docker和其他必不可少的技术的绝妙资源，没有这些，现代企业是不可想象的。
我们邀请您阅读文章“直接下载流数据”
10.1。 通用架构
在上一章中，我们研究了许多客户端应用程序必须发送大量需要动态处理，放置在存储库中然后在其中再次处理的消息的情况。 同时，必须能够更改数据处理和存储流程的逻辑，而不必诉诸更改客户端代码。 最后，从安全性的角度来看，客户端应仅有权执行一件事-发送或接收消息，但绝不读取数据或删除数据库，并且他们不具有直接写入数据的权限。
在使用通过Internet连接连接的IoT设备的系统以及在线日志分析系统中，此类任务非常常见。 除了上面列出的针对我们专用服务的要求外，还有另外两个与“物联网”的细节相关的要求，以确保可靠的消息处理。 首先，客户端与服务接收者之间的交互协议必须非常简单，以便可以在计算能力有限且内存非常有限的设备上实现（例如，Arduino，Intel Edison，STM32 Discovery和其他“不合适的”平台，例如和以前的RaspberryPi一样）。 下一个要求是可靠的消息传递，而不考虑处理服务可能发生的故障。 这比对高可靠性的要求更强。 实际上，为了确保整个系统的整体可靠性，必须确保其所有组件的可靠性都足够高，并且添加新组件不会导致故障数量的显着增加。 除了云基础架构中的故障之外，用户创建的服务中可能还会发生错误。 即使这样，在恢复用户服务后也应立即处理该消息。 为此，消息流接收服务必须可靠地存储消息，直到消息被处理或生存期到期为止（这是防止连续消息流期间内存溢出所必需的）。 具有这些属性的服务称为事件中心。 对于IoT设备，有专门的集线器（IoT Hub），它具有许多其他属性，这些属性对于与物联网设备结合使用非常重要（例如，单点双向通信，内置消息路由，设备的“数字双打”以及许多其他）。 但是，这些服务仍是专门的，因此我们将不对其进行详细介绍。
在继续讨论消息集中的概念之前，让我们谈谈它所基于的思想。
假设我们有一个消息源（例如，来自客户端的请求）和应该处理它们的服务。 处理单个请求需要时间，并且需要计算资源（CPU，内存，IOPS）。 此外，在处理一个请求期间，其余请求无法处理。 为了使客户端应用程序在等待服务免费时不会冻结，有必要在附加服务的帮助下将它们分离，该服务将负责在队列中等待处理时消息的中间存储。 这种分离对于增加系统的整体可靠性也是必要的。 确实，客户端向系统发送了一条消息，但是处理服务可能会“掉落”，但是消息不应丢失，它必须存储在比处理服务更可靠的服务中。 这种服务的最简单版本称为队列（图10.1）。
队列服务的工作方式如下：客户端知道队列的URL并具有对其的访问密钥。 客户端使用队列的SDK或API，将一条消息放入其中，其中包含消息的时间戳，标识符和正文，并带有JSON，XML或二进制格式的有效负载。
服务的程序代码包括一个循环，该循环“侦听”队列，在每个步骤中检索下一条消息，如果队列中有消息，则将其提取并处理。 如果该服务成功处理了该消息，则将其从队列中删除。 如果在处理过程中发生错误，则不会删除该错误，并且可以在启动具有已更正代码的新版本服务时再次对其进行处理。 该队列旨在同步一个客户端（或一组相似的客户端）和一个处理服务（尽管后者可以位于服务器群集或服务器场中）。 云队列服务包括Azure存储队列，Azure服务总线队列和AWS SQS。 虚拟机上托管的服务包括RabbitMQ，ZeroMQ，MSMQ，IBM MQ等。
不同的队列服务保证不同类型的消息传递：
- 至少一次消息传递
- 严格一次性交货；
- 消息传递，同时保持秩序；
- 消息传递而不保持顺序。
队列提供消息从一个源到一个处理服务的可靠传递，即一对一交互。 但是，如果有必要向多个服务提供消息传递，该怎么办？ 在这种情况下，您需要使用一个名为“主题”（topic）的服务（图10.2）。
此体系结构的一个重要元素是“订阅”。 这是在发送消息的部分中注册的路径。 消息由客户端在主题中发布，并转移到其中一个订阅，然后由其中一项服务从中提取消息并对其进行处理。 主题提供了一对多的客户服务交互体系结构。 此类服务的示例包括Azure服务总线主题和AWS SNS。
现在假设有大量的异构客户端，它们需要向许多服务发送许多消息，也就是说，我们需要构建一个多对多交互系统。 当然，可以使用多个部分来构建这样的体系结构，但是这样的结构是不可扩展的，并且需要进行管理和监视。 但是，有单独的服务-消息集中器（图10.3）。
集线器接受来自许多客户端的消息。 所有客户端都可以将消息发送到一个公共服务端点，或通过特殊键分别连接到不同端点。 这些密钥使您可以灵活地管理客户端：断开某些客户端，连接新客户端等。集线器内部也有分区。 但是在这种情况下，可以将它们分布在所有客户端中以提高生产率（循环-“具有循环加法”），或者客户端可以在部分之一中发布消息。 另一方面，处理服务被合并为消费者组。 一项或多项服务可以连接到一组。 因此，消息集中器是最灵活的服务，可以配置为队列，部分或一组队列，或一组部分。 通常，消息集中器在客户端和服务之间提供多对多关系。 这些中心包括Apache Kafka，Azure事件中心和AWS Kinesis Stream。
在研究基于云的PaaS服务之前，我们将关注一种非常强大且知名的服务-Apache Kafka。 在云环境中，可以将其作为直接部署到虚拟机群集的分发或使用HDInsight服务进行访问。 因此，Apache Kafka是一项提供以下功能的服务：
- 发布和订阅消息流
- 消息的可靠存储；
- 应用第三方流消息处理服务。
实际上，Kafka在一个或多个服务器的群集中运行。 Kafka提供了一个用于与外部客户端进行交互的API（图10.4）。
按顺序考虑这些API。
- 供应商API允许客户端应用程序在一个或多个Kafka主题中发布消息流。
- 消费者API使客户端应用程序能够订阅一个或多个主题，并处理主题向客户端传递的消息流。
- 流处理器API允许应用程序作为流处理器与Kafka集群进行交互。 一个处理器的来源可能是一个或多个主题。 在这种情况下，已处理的消息也会放在一个或多个主题中。
- 连接器API帮助将外部数据源（例如RDB）作为消息源（例如，可以拦截数据库中的数据更改事件）并作为接收器进行连接。
在Kafka中，客户端和群集之间的交互是通过TCP进行的，现有的各种编程语言（包括.Net）SDK都促进了TCP与TCP的交互。 但是基本的SDK语言是Java和Scala。
在集群中，消息流的存储（在Kafka术语中也称为条目）在逻辑上发生在称为主题的对象中（图10.5）。 每个记录由一个键，一个值和一个时间戳组成。 本质上，主题是客户已发布的一系列记录（消息）。 Kafka主题支持从0到几个订阅者。 每个主题在物理上都表示为分区日志。 每个部分都是有序的记录序列，不断添加到Kafka输入中的新记录。
该部分中的每个条目对应于序列中的一个数字，也称为偏移量，它在序列中唯一地标识此消息。 与队列不同，Kafka不是在处理服务之后而是在消息的生存期之后删除消息。 这是非常重要的属性，它提供了从一个主题向不同的消费者阅读的能力。 此外，每个消费者都有一个偏见（图10.6）。 并且每次阅读行为只会导致每个客户的价值分别增加，并由客户精确确定。
在正常情况下，从主题成功读取一条消息后，此偏移量将增加一。 但是如果需要，客户端可以偏移此偏移量并重复读取操作。
使用节的概念具有以下目标。
首先，当一个主题不适合同一节点时，部分提供了缩放主题的能力。 同时，每个部分都有一个引导节点（不要与整个集群的头节点混淆）和零个或几个跟随者节点。 头节点负责读/写操作，而跟随者是其被动副本。 如果主节点发生故障，则后继节点之一将自动成为头节点。 每个群集节点是某些部分的负责人，而另一些部分则是关注者。 其次，由于并行读取操作的可能性，这种复制提高了读取性能。
生产者可以将消息明确地放置在他选择的任何主题中，也可以隐式地将其放置在循环模式中（即，使用统一填充）。 消费者被统一在所谓的消费者组中，并且主题中发布的每条消息都传递给每个消费者组中的一个客户。 在这种情况下，客户端可以物理托管在一个或多个服务器/虚拟机上。 更详细地，消息传递如下。 对于属于同一消费者组的所有客户，可以在客户之间分发消息，以优化负载。 如果客户属于不同的消费者组，则每个消息将发送到每个组。 图2显示了不同消费者群体将消息与各个部分分开的情况。 10.7。
现在，我将简要描述Kafka保证的消息传递和存储的主要参数。
- 制造商发送到特定主题的消息将严格按照其发送顺序进行添加。
- 客户端会看到保存邮件时收到的主题中的邮件顺序。 结果，严格按照接收消息的顺序将消息从生产者传递到消费者。
- 主题的N倍复制可确保主题在N-1个节点发生故障时的稳定性，而不会降低性能。
因此，可以在以下模式下使用Apache Kafka服务。
- 服务-消息代理（队列）或发布服务-消息订阅（主题）。 确实，Kafka基于一组主题，可以与一个订户一起转换为队列。 （应记住：与通常的基于队列原理的消息代理服务相反，在Kafka中，消息仅在其生存期到期后才被删除，而代理则实现了Peek-Delete原则，即在成功处理后进行检索和删除。 ）消费者群体的原则总结了这两个概念，并且具有通过循环分发在所有主题中发布消息的功能，使Kafka成为通用的多模式消息代理。
- 流消息分析服务。 这可以归功于Kafka中包含的用于流处理器的API，该API允许您构建基于事件驱动的复杂系统，该系统具有过滤或响应消息的服务以及聚集消息的服务。
所有这些属性使将Kafka用作平台的关键组件成为可能，该平台可处理流数据并具有构建复杂消息处理系统的强大功能。 但是同时，Kafka在部署和配置由多个节点组成的集群方面非常复杂，这需要大量的管理工作。 但是，另一方面，由于Kafka的基础思想非常适合构建系统，流式传输消息和接收消息，因此云提供商将提供PaaS服务，以实现这些思想并掩盖构建和管理Kafka集群的所有困难。 但是，由于这些服务在定制和扩展方面有许多限制，超出了为服务分配的限制，因此云提供商为虚拟机群集中的Kafka物理部署提供了特殊的IaaS / PaaS服务。 在这种情况下，用户几乎完全可以自由配置和扩展。 这些服务包括Azure HDInsight。 上面已经提到过。 创建它的原因是，一方面是为了向用户提供Hadoop生态系统中的服务，而无需外部包装程序，另一方面是为了减轻直接安装，管理和配置IaaS所带来的困难。 Docker托管有一点区别。 由于这是一个非常重要的主题，因此我们将考虑它，但首先要了解使用Kafka的基本概念实现的PaaS服务。
10.2。 Azure事件中心
考虑Azure事件中心消息中心服务。 它是基于PaaS模型构建的服务。 各种客户端组可以充当Azure事件中心的消息源（图10.8）。 首先，这是一个非常庞大的云服务组，可以将其输出或触发器配置为直接将消息发送到事件中心。 这些可以是流分析作业，事件网格以及可重定向事件的大量服务-登录事件中心（主要使用AppService构建：Api App，Web App，Mobile App和Function App）。
可以直接捕获传递到集线器的消息，并将其存储在Blob存储或Data Lake存储中。
下一组来源是没有Azure Event Hub SDK且不能直接与Azure服务集成的外部软件客户端或设备。 这些客户端主要包括物联网设备。 他们可以通过HTTPS或AMQP将消息发送到事件中心。 如何连接这些设备的考虑超出了本书的范围。
最后，软件客户端使用Azure Event Hub SDK生成消息并将其发送到Event Hub。 该组包括Azure PowerShell和Azure CLI。
作为来自事件中心的消息接收者（消费者-“消费者”），可以使用流分析作业或事件网格集成服务。 此外，可以使用Azure Event Hub SDK通过软件客户端接收消息。 使用者使用AMQP 1.0协议连接到事件中心。
考虑了解如何使用和配置Azure事件中心的基本概念。 向中心发送消息的任何源（在文档中也称为发布者）都必须使用HTTPS或AMQP 1.0协议。 协议的选择取决于客户端的类型，通信网络和消息速率的要求。 AMQP需要在两个双向TCP套接字之间建立永久连接。 它使用TLS传输层加密协议或SSL / TLS进行保护。 , , AMQP , HTTPS, . HTTPS.
, SAS (Shared Access Signature) tokens. SAS- SAS . SAS-, ( ).
256 . , .
, Event Hub. , , , -. EventHub (partitions). EventHub — , « — » (FIFO) (. 10.9).
— Event Hub. Event Hub 2 32 , Event Hub. , .
( ) , ( , — . ), (retention period), . . . , Azure Event Hub (offset). — , , , , . . Azure Event Hub SDK , , . -, .
, , , , . Azure Event Hub SDK , . , Storage Account. Azure, Event Hub, .
Event Hub (partition key), . — . , ( ) . , (round robin).
. , (consumer group) (. 10.11). . (view) ( ) , , . , . — 20, , .
. , . , (throughput unit). :
. , . . . 小心点！ , , , Event Hub.
(namespace) (. 10.12).
»这本书的更多信息可以
在出版商的网站上找到»
目录»
摘录小贩 20％优惠券
-BigData