Azure Event Hub Survey 周琦

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

归属物联网行业（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

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

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

Service Bus 与 Event Hub（2）

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

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

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

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

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

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>

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

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

收费 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)

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

计费换算 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倍

已开通地域

Reference Getting Started Sample：https://code.msdn.microsoft.com/windowsazure/Service-Bus-Event-Hub-286fd097 Event Hub Page：http://azure.microsoft.com/en-us/services/event-hubs/?rnd=1