Azure Event Hub Survey 周琦.

Presentation on theme: "Azure Event Hub Survey 周琦."— Presentation transcript:

1 Azure Event Hub Survey 周琦

2 Event Hub 定义： 例子： 特性： 可用性： Web站点、应用、设备间的大规模数据采集与传递
实时：Near real time 弹性：Elastic Scale Client提供多平台实现：Azure各服务间提供插件式集成 可用性： 99.9%

3 归属物联网行业（Lot Internet of Things）
Event Hub Receive telemetry from millions of devices Stream Analytics Real-time data stream processing Machine Learning Cloud based predictive analytics tool Notification Hubs Push notification engine for quickly sending message

4 Service Bus 三种模型 Queues, 一对一消费、实时，带临时存储
Topics, 一对多，带临时存储、消费者可以用Filter进行message筛选 Relays, 双向、非临时存储 Event Hubs, 针对事件与监控采集功能，低延时、高可用。EventHub与上述模型相比，针对Event垂直化的服务

5 Service Bus 与 Event Hub EventHub目标 与Queue、Topic区别：
用于向云提供大规模的事件与探测数据入口，并且具有较低的延迟和较高的可靠性 在应用程序检测、用户体验或工作流处理以及物联网 (IoT) 方案中，将此服务与其他下游服务结合使用可以带来极好的效果 与Queue、Topic区别： Queue通常需要大量复杂的功能，例如保序、定期删除、事务支持和强传送保证。 EventHub偏向于高吞吐量和事件处理方案，未实现Topic提供的某些消息传递功能

6 Service Bus 与 Event Hub（2）

7 Event Hub 数据模型 Partition：分区是事件中心内保留的有序Event。当较新Event到达时，它们将添加到此序列的末尾，可以将分区视为“提交日志”

8 Partition 按配置的保留时间保留数据，并应用到所有分区 Event根据特定的时间过期，无法显式删除
EventHub包含多个分区。每个分区是独立的，包含其自身的数据序列 Partition数目在创建事件中心时指定，它必须介于 8 和 32 之间 Partition数主要受消费应用程序中所需的下游并行度影响 Partition是一种数据组织机制，主要与下游并行度而不是EventHub吞吐量相关。因此，EventHub内分区数的选择与预期获得的并发读取者数目直接相关 创建EventHub后，分区计数不可更改。可以提交工单来增加 32 个分区这一限制 尽管分区是可识别的并且可以直接向其发送数据，但通常最好不要向特定分区发送数据，而可以使用“事件发布者”和“发布者策略”

9 Event Data 事件数据：包含事件的正文、用户定义的属性包和有关事件的各种元数据，例如，它在分区中的偏移量，以及它在流序列中的编号。分区中填充了事件数据的序列

10 Provider 发布者： 向EventHub发送事件或数据的任何实体都称为事件发布者。事件发布者可以使用 HTTPS 或 AMQP 1.0 发布事件。 事件发布者使用共享访问签名 (SAS) 令牌在事件中心上标识自身，并且可以包含唯一标识，或使用常见的 SAS 令牌，具体取决于方案的要求。 发布动作： 通过 AMQP 1.0 或 HTTP 发布事件 Service Bus 提供了一个 EventHubClient 类，使用该类可从 .NET 客户端向事件中心发送事件。对于其他运行时和平台，你可以使用任何 AMQP 1.0 客户端，例如 Apache Qpid 可以逐个或者批量发送事件 单个发布（事件数据实例）限制为 256KB，不管它是单个事件还是事件批。发布大于此限制的事件将导致出错。 发布者最好是不知道事件中心内的分区数，而只是通过其 SAS 令牌指定 PartitionKey（如下所述）或标识。

11 Partition Key 分区键是用于将传入事件数据映射到特定分区以便组织数据的值 该键将通过静态哈希函数进行处理，处理后将会创建分区分配
如果在发布事件时未指定分区键，则会使用循环分配。在使用分区键时，事件发布者只知道其分区密钥，而不知道事件要发布到的分区 分区键对于组织下游处理数据非常重要，但基本上与分区本身无关。每个设备或用户的唯一标识就可以充当一个适当的分区键，但是，也可以使用其他属性（例如地理位置），以便将相关的事件分组到单个分区中

12 Consumer 使用者组使多个消费应用程序都有各自独立的事件流，拥有各自状态、位置或偏移量
在流处理体系结构中，每个下游应用程序相当于一个使用者组。 EventHub有一个默认的使用者组，最多可为一个标准层事件中心创建 20 个使用者组。 以下是使用者组 URI 约定的示例： //<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1> //<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

13 Offset 与 CheckPoint Offset CheckPoint 偏移量是事件在分区中的位置
可以将偏移量视为客户端游标。偏移量是事件的字节编号。这样，事件使用者（读取者）便可以在事件流中指定要从其开始读取事件的点。可以时间戳或者偏移量值的形式指定偏移量。使用者负责在事件中心服务的外部存储其自身的偏移量值。 CheckPoint 检查点是读取者在分区事件序列中标记或提交其位置时执行的过程。检查点操作由使用者负责，并在使用者组中的每个分区上进行，相当于Kalfka中Ack 当读取者建立连接时，它会将此偏移量传递给事件中心，以指定要从其开始读取数据的位置 实现故障转移弹性和受控的事件流重放

14 消费过程 连接： 读取： 使用者必须连接到一个分区。
在使用者组中，每个分区上每次只能有一个读取者处于活动状态。在直接连接到分区时，常见的做法是使用租用机制来协调读取者与特定分区的连接。这样，便可以做到一个使用者组中每分区只有一个活动的读取者 读取：  AMQP 、 HTTP GET 推荐使用AMPQ，可以实现更高的吞吐量和更低的延迟

15 收费 BASIC STANDARD Ingress events $0.028 per million events
Throughput unit (1 MB/s ingress, 2MB/s egress) $0.015/hr (~$11/mo) $0.03/hr (~$22/mo) Publisher policies -- Consumer groups 1 - Default 20 Message replay Maximum throughput units Service Bus brokered connections 100 included 1,000 included Additional Service Bus brokered connections Message Retention 1 day included Additional storage (up to 7 days)

16 收费（说明） 事件大小：发送到事件中心的每个事件都统计为一条可计费消息。 单位处理能力吞吐量：
入口事件定义为小于等于 64KB 的数据单位。任何小于等于 64KB 的事件均被视为一个计费事件。 如果该事件大于 64KB，则根据事件大小按 64KB 的倍数来计算计费事件的数量 单位处理能力吞吐量： In：最多达每秒 1 MB，但每秒不超过 1000 个入口事件、管理操作或控制 API 调用。 Out：最多达每秒 2 MB。 事件存储空间最多达 84 GB（对于默认为 24 小时的保留期来说是很充足的）

17 计费换算 RDS：40TB、40 Billion Querys： CNZZ：8TB、8Billion Logs 写入收费：112 $/Day
年费用：138W CNZZ：8TB、8Billion Logs 写入收费：22.4 $/Day 预留写：100 $/Day 成本与计费： RDS一年费用为138W RMB，以RDS搭建5台Kalfka S9计算（10W成本），收费约为成本13倍

18 已开通地域

19 Reference Getting Started Sample： Event Hub Page：