[译] 伯克利开源多数据流实时分布式分析系统 Confluo，吞吐超 Kafka 4-10 倍

微信公众号： 深广大数据Club

关注可了解更多大数据的相关资讯。问题或建议，请公众号留言;

如果你觉得深广大数据Club对你有帮助，欢迎转发微信朋友圈

2018年12月5日，伯克利大学发布了一篇名为《Confluo: Millisecond-level Queries on Large-scale Live Data》的博客。对大型实时数据的毫秒级查询？

官方网址：https://ucbrise.github.io/confluo

github地址：https://github.com/ucbrise/confluo/

定义

Confluo是一个用于多个数据流的实时分布式分析的系统。底层开发语言是C++。Confluo同时支持高吞吐量并发写入，毫秒时间尺度的在线查询，以及通过为多个数据流专用案例精心设计的数据结构组合的CPU高效即席查询，以及端到端优化系统设计。

概述

许多现代应用程序（例如，基于终端主机的网络监控，物联网和中心运营服务等）每个后备服务器每秒捕获数千万个数据点。此数据用于在线查询中，用于可视化和监视目的，以及用于根本原因分析和系统优化的脱机查询。启用这些应用程序需要实时监控和分析工具，这些 工具 可支持高吞吐量数据提取，低延迟在线查询和低开销的脱机查询。

虽然存在用于高吞吐量数据摄取的数据结构，并且为了支持富有表现力的在线和离线查询，但到目前为止这两者仍然是互斥的。支持上述查询需要更新多个数据结构 - 用于存储多个属性中的原始数据，聚合统计信息和物化视图 - 同时从多个流中提取数据。遗憾的是，用于支持这些数据结构的数据结构往往具有较高的更新开销，并且无法维持大多数应用程序所需的数据提取率。另一方面，可以维持高数据摄取率的数据结构往往只支持非常简单的查询。

为了应对这一挑战，构建了Confluo，这是一个致力于同时实现高吞吐量数据提取和富有表现力的离线和在线查询的系统。

使用场景

目前伯克利大学针对几种不同的应用场景评估了Confluo，包括

• 网络监控和诊断框架，Confluo能够在单个核心上以线速（10Gbps链路）执行数千个触发器和数十个过滤器。

• 时间序列数据库，与先进技术相比，Confluo的吞吐量提高了2-20倍，插入延迟降低了2-10倍，吞吐量提高了1.5倍-5倍，时间范围查询延迟降低了5-20倍时间序列数据库：CorfuDB，TimescaleDB和BTrDB。

• pub-sub系统，Confluo在发布 - 订阅吞吐量方面优于Apache Kafka 4-10倍。

Confluo API

Confluo对数据流进行操作。每个流包括记录，每个记录遵循强类型属性集合上的预定义模式。如上所述，Confluo目前仅支持固定大小的属性; 这包括原始数据类型，如二进制，整数或浮点值，或特定于域的类型，如IP地址，端口，传感器读数等。

例如：具有五个属性的简单框架

{
    timestamp: LONG,
    op_latency_ms: DOUBLE,
    cpu_util: DOUBLE,
    mem_avail: DOUBLE,
    log_msg: STRING(100)
}

Confluo中的模式是强类型属性的集合。它通过类似语义的JSON指定;

目前，Confluo仅支持具有固定模式的流，即流中的每个记录必须符合所提供的模式。

为了加速即席脱机查询，应用程序可以为架构中的各个属性添加索引。为了支持在线查询，Confluo还采用了匹配动作语言，其中包含三个主要元素：过滤器，聚合和触发器。

目前Confluo Client API支持的语言包含：c++，Python，Java

实现

Confluo对数据流的基本存储抽象是一种新的数据结构：Atomic MultiLog，一组无锁并发日志，用于存储原始数据，聚合统计信息和物化视图，并使用新技术将整个集合作为单个原子操作高效更新。Atomic MultiLog利用上面概述的应用程序工作负载假设来促进高吞吐量数据提取，以及丰富的在线和离线查询。

Atomic MultiLogs与数据库表的接口类似。为了存储来自不同流的数据，应用程序可以创建具有预定义模式的Atomic MultiLog，并编写符合模式的数据流。然后，应用程序在Atomic MultiLog上创建索引，过滤器，聚合和触发器，以启用各种监视和诊断功能，如上所述。

有关Confluo实现和使用的更多资源，请查看其操作模式，数据存储，查询执行和快速入门指南。有关Atomic MultiLog和Confluo架构的详细信息，请参阅我们即将发布的NSDI'19文章，该文件重点介绍Confluo在网络监控和诊断方面的应用。

性能

伯克利针对Confluo的三个不同场景进行了性能测试：网络监控和诊断框架、时序数据库、发布订阅消息系统

网络监控和诊断框架

Confluo是一个终端主机堆栈，可以与现有的网络管理工具集成，以支持监视和网络事件的诊断。Confluo通过使用来实现这一点原子多日志，一种利用结构的新数据结构在网络流量中支持高并发读写操作。Confluo可以在单个核心上以线性速率(10Gbps链路)执行1000个触发器和10个过滤器。

具体内容可以查看官方发布的NSDI Paper，地址如下：

https://people.eecs.berkeley.edu/~anuragk/papers/confluo.pdf

时序数据库

在时序数据库上，Confluo与BTrDB，CorfuDB以及TimescaleDB进行了性能对比。

Confluo的插入速度提高了2-20倍，插入延迟降低了2-10倍，时间滤波器的吞吐量提高了1.5倍-5倍，延迟降低了5-20倍数据库

pub-sub系统

使用Confluo存储消息的主要好处包括：

• 不受读写争用的影响，以及写-写争用的无锁解决方案。

• 与Kafka不同，Confluo提供了获取整个主题快照的有效方法。

• 支持对发布和订阅之外的消息流进行丰富的在线和离线查询。

由于Kafka使用锁来同步并发附加，因此发布者写入吞吐量会因写写争用而受到影响（图（左））。Confluo对这些冲突采用无锁解析，以实现高写入吞吐量。较大批量（16K消息）在一定程度上缓解了Kafka的锁定开销，而Confluo在超过4个发布者的16K消息批处理中接近网络饱和。由于读取在两个系统中都没有争用，因此读取吞吐量与多个订户呈线性关系（图（右））。

Confluo实现了更高的绝对读取吞吐量，可能是由于Kafka的系统开销而不是因为基本的设计差异。和以前一样，由于网络饱和，Confluo的读吞吐量在4个用户和16K消息批处理中饱和。

总结

Confluo从网络监控和诊断框架、时序数据库以及pub-sub系统给我们展示了它强大性能。不过Confluo目前还不够灵活，功能还不够强大。

Confluo目前仅支持具有严格模式的流。

官方也表示后续会进一步完善Confluo，以使Confluo更具表现力和效率。

• 支持使用草图对数据流进行近似查询

• 支持数据流上的丰富 SQL 接口

• 通过文件合并和内存池提高性能

原英文博客链接：

https://rise.cs.berkeley.edu/blog/confluo-millisecond-level-queries-on-large-scale-streaming-data/