Datadog的Husky数据摄取架构

Datadog为其第三代事件存储系统Husky设计了专门的数据摄取架构，提供了一次性语义（exactly-once semantics）。该架构基于事件驱动架构（EDA），能够在多租户平台中应对流量突发，同时保持合理的摄取延迟和可接受的操作成本。

Husky的诞生背景

Husky于2022年推出，旨在解决Datadog在运行两种不同架构时所面临的挑战。随着客户数量的增加和新产品对数据存储和查询的特定需求，Datadog需要一种更具扩展性的解决方案。

架构设计

Husky的架构将数据摄取、数据压缩和数据读取工作负载分离，使它们能够独立扩展。所有三个工作负载都依赖于基于FoundationDB的共享元数据存储和AWS S3的blob存储服务。数据摄取工作负载使用Apache Kafka将事件传送到存储平台，并内部路由到数据写入器。

数据摄取的挑战

Datadog的高级软件工程师Daniel Intskirveli指出，Husky面临的独特挑战是如何在高流量和低延迟的情况下确保数据一次性准确摄取，避免重复事件。重复事件可能导致监控警报的误报或漏报，并影响客户计费的使用报告。

解决方案

Datadog通过内部路由机制，将传入的事件流确定性地分割为每个租户的多个分片。每个分片的事件由下游写入器（writer）负责在内存中进行事件去重。由于租户数据在分片内的局部性，去重变得更加高效。同时，路由机制限制了每个分片中的租户数量，以降低存储成本。

写入器设计

写入器从分配的分片中消费事件，并将其持久化以供查询。团队选择了无状态设计，以支持自动扩展和负载均衡。为了支持事件去重，无状态写入器必须将处理过的事件ID保存到持久化存储中。事件ID被插入到FoundationDB的单独表中，并与事件元数据一起在单个事务中提交，确保原子性和一致性。此外，写入器使用LRU缓存将事件ID缓存在内存中。

冲突检测与解决

该设计还支持在分片因扩展、重新部署或基础设施问题而重新分配给另一个写入器时的冲突检测与解决。通过乐观并发控制，事件ID表的更新被版本化，任何乱序更新都会被拒绝。当写入器检测到冲突时，它会从FoundationDB表中刷新事件ID缓存，并重置Kafka主题中的偏移量。

总结

Husky的架构通过分离工作负载、优化路由机制和无状态写入器设计，有效解决了数据摄取中的去重和扩展性问题，确保了数据的一致性和可靠性。