最佳做法：对事件中心数据进行分区，并通过 Azure 事件中心到外部存储 (Azure Blob) 实现大规模、低延迟和高吞吐量

Question

作为安全产品的一部分，我有大规模的云服务(Azure 辅助角色)，该服务从事件中心读取事件，将其批处理到 ~2000 并存储在 Blob 存储中。 每个事件都有一个 MachineId(发送它的计算机)。 事件以随机顺序来自事件中心，我以随机顺序将它们存储在 Blob 存储中。 吞吐量高达 125K 事件/秒，每个事件为 ~2K，因此我们有高达 250MB/秒的流量。 我们有~1M机器...

稍后，另一个云服务会下载 Blob 并对事件运行一些检测逻辑。他按 MachineId 对事件进行分组，并尝试从机器时间轴中取消某些内容

问题是，今天来自同一台计算机的事件被填充到不同的 Blob 中。如果我能以某种方式按事件的 MachineId 对事件进行分组，并确保将计算机的某个时间窗口填充到同一 blob，这将增加我可以在云中进行的检测。

我们确实将事件写入另一个 Map Reduce 系统，在那里我们进行了许多复杂的检测，但这些检测当然具有高延迟。如果我能在云中更好地对事件进行分组，我可以实时捕获更多事件

我有什么技术可以帮助我吗？

提前致谢

Answer 1

tl;dr：在原始事件中心和 blob 存储之间引入另一个事件中心(按计算机 ID 重新分区数据)是最好的方法。

通常，有一个 INJESTING 事件中心 - 它只是监视系统的一个入口点。使用EventHubClient.send(eventData_without_partitionKey)方法发送到此INJESTING EVENTHUB。这将允许您以非常低的延迟和高可用性发送 - 因为它将发送到当前负载较少且可用的分区。

--------------                     -----------                 ----------
|              |    =========      |           |    ====       |          |
|  INJESTING   |    RE-PARTITION > |  INTERIM  |    BLOB      |   BLOB   |
|  EVENTHUB    |    =========      |  EVENTHUB |    PUMP /     |          |
|              |                   |           |    ====        ----------
--------------                     -----------

最重要的是，出于以下因素，避免直接在引入事件中心上对数据进行分区：

1. 高可用性引入管道 - 不将事件关联到分区 - 将使引入管道保持高可用性。在幕后，我们将在Container上主持您的每EventHubs Partition。当您在EventData上提供PartitionKey时，该PartitionKey将被哈希到特定分区。现在，Send操作延迟将与单个Partition的可用性相关联 - Windows操作系统升级或我们的服务升级等事件可能会影响它们。相反，如果您坚持使用EventHubClient.send(without_PartitionKey)- 我们会尽快将EventData路由到可用分区 - 因此，您的摄取管道保证Highly available。
2. 灵活的数据设计 - 在分布式系统中，您通常很快需要根据不同的键对数据进行重新分区。请务必 - 测量系统中此:)的概率。

使用临时事件中心作为对数据进行分区的一种方式。 即，在RE-PARTITION模块中 - 您只需通过将一个属换到EventData.PARTITION_KEY来重播原始流以INTERIM EVENTHUB- 该属性最初为空。

// pseudo-code RE-PARTITION EVENTS
foreach(eventData receivedFromIngestingEventHubs)
{
var newEventData = clone(eventData);
eventHubClient.send(newEventData, eventData.Properties.get("machineId"))
}

这确保了 - 是 - 所有具有特定MachineID的EventData都可以在1 and 1 - EventHubs Partition上找到。不需要创建 1M 事件中心分区。每个分区可以容纳无限数量的PartitionKey。您可以使用EventProcessorHost来托管每个分区逻辑或Azure Stream analytics Job。

此外，这是您过滤和生成最佳流的机会 - 下游处理管道可以使用该流。

在BLOB 泵模块(下游处理管道)中 - 当您使用来自特定临时事件中心的Partition的事件时 - 现在保证在此分区上拥有来自特定计算机 ID 的所有Events。 根据 PartitionId(机器 Id) 聚合所需大小 -2k- 不会连续拥有所有事件 - 您需要为此构建内存中聚合逻辑(使用EventProcessorHost或AzureStreamAnalytics Job)。