你认为人工智能时代需要分布式流处理吗

你认为人工智能时代需要分布式流处理吗

• 来源:网络
• 更新日期:2020-06-10

摘要： 在中国大数据和人工智能时代，许多数据密集型应用程序表现出传统批处理模型无法满足的要求。流媒体应用，如流分析，物联网数据处理，网络监控，或金融欺诈检测，必须支持高处

在中国大数据和人工智能时代，许多数据密集型应用程序表现出传统批处理模型无法满足的要求。流媒体应用，如流分析，物联网数据处理，网络监控，或金融欺诈检测，必须支持高处理率，但始终达到亚秒级处理延迟。作为响应，分布式流处理系统，如SparkStreaming或ApacheFlink，利用计算集群的资源进行流式应用。他们的目标是从许多处理节点的总吞吐量中受益。与任何分布式系统一样，这引发了分布式流处理系统如何利用每个节点上的可用硬件资源的问题。单个处理节点的性能至关重要，因为它决定了满足给定流应用程序的吞吐量和延迟要求所需的计算集群的大小。

当谈到单节点性能时，流处理系统必须考虑（a）节点提供什么类型的并行处理器（即多核CPU，GPU，FPGA）和（b）如何有效地并行处理流计算。随着高度并行的异构体系结构在数据中心中的普及，流处理系统甚至可以从单个节点开始利用先前看不见的并行处理级别。

在这篇博客文章中，我们比较了针对单一服务器SABRE设计的高效流处理引擎与受欢迎的分布式流处理系统ApacheSpark和ApacheFlink所实现的性能。我们还将结果与StreamBox进行了比较，StreamBox是最近提出的另一个强调数据乱序处理的单服务器设计。根据我们的结果，我们认为单个多核服务器可以为多个流应用程序提供比多节点群集更好的吞吐量。这为通过用可能复制的单个服务器部署替换基于集群的流处理系统打开了一个降低系统复杂性和运营成本的机会。

实验装置

对于我们的比较，我们使用YahooStreamingBenchmark作为工作量。其他人（ApacheFlink，ApacheApex，差异数据流）也报告了此基准的局限性，它无法捕获流式应用程序中滑动窗口计算的丰富语义。滑动窗口可以说是流处理中最具挑战性的方面之一，并且对如何高效并行化计算有着深远的影响。尽管有这些限制，但该基准最近已被用于工业（数据布雷克，数据工匠）和学术界（SparkStreaming，Drizzle）。这使我们的结果与先前的努力相媲美。

单节点比较

在模拟广告流应用程序，它有一个包含四个操作符的流式查询：过滤器，项目，连接（关系数据）和聚合（窗口计数）。在我们的实现中，输入元组是128个字节，并直接存储在JavaByteBuffer中。

我们使用2个IntelXeonE5-2660v32.60GHzCPU，共有20个物理CPU核心，25MB最后一级缓存（LLC）缓存和32GB内存，在6台服务器（1个主服务器和5个从服务器）上执行实验。机器连接10Gbps以太网。我们用SABRE（没有GPU支持），Spark2.4.0，Flink1.3.2和StreamBox的最后一个版本来评估查询。对于分布式实验，我们每个节点只使用8个内核，因为在这个数字之后我们没有看到任何显着的吞吐量变化。

我们设计实验的目的是将流处理系统的性能与外部影响隔离开来。为此，我们以下列方式进行实验：

对于SABER，我们最初在一台单独的机器上生成数据。由于只有一个CPU核心设法使10Gbps网络连接饱和（每秒830万个元组），我们改为在内存中生成数据。

吞吐量比较

在吞吐量方面的可扩展性，因为我们增加了可用CPU核心的数量。通过单个节点，Flink的性能比Spark和StreamBox都要好，将吞吐量提高了1.9倍以上。凭借8个CPU内核，Spark和StreamBox分别拥有每秒1200万和1100万元的吞吐量，而Flink则达到了2200万以上。

与其他系统相比，SABRE的吞吐量分别比Spark，Flink和StreamBox分别高出7倍，3倍和7倍。它使用8个CPU内核每秒处理近7，900万个元组。只有两个CPU核心，SABRE超过了其他系统的最佳单节点吞吐量。除了不利用存储器层次并最小化数据复制外，Flink和Spark的吞吐量都受到通信和串行化开销的不利影响。这是预期的，他们的分布式设计试图利用多个节点的聚合性能。

有了这样一个简单的查询，我们的实验主要测量系统可以执行数据移动的速度，因为花在有意义的计算上的时间很短。SABRE将工作线程和生成线程绑定到CPU内核，以最大限度地减少L2缓存之外的内存访问。另外，我们维护一个512KB的输入缓冲区，确保所有活动数据都保存在LLC中。我们使用原子操作来编写和读取这个缓冲区的部分内容，同步代价可以忽略不计。

集群吞吐量比较

有趣的是观察到，与最近的结果相比，即使在集群部署的情况下，Flink的性能也比Spark好。Flink吞吐量的增长是由于更快的10Gbps网络所致，我们认为这在以前的工作中并未使用（请参阅结构化流媒体文件）。使用StreamBox，我们观察到致命的内存泄漏，当我们将摄取率提高到超过我们在图中报告的数量时。

总之，只有8个CPU内核的SABRE比具有5个工作节点（40个内核，5500万元组/秒）和Flink（40个内核;6700万元组/秒）的Spark性能更好。仔细调整的单服务器系统可以胜过计算集群，将所需资源减少一半以上。

分销的成本是多少？

根据先前提出的优于单线程（COST）的配置指标，我们通过将单核实现与手写C++程序进行比较来分析系统的性能。C++实现在我们的测试台服务器上每秒处理近2300万个元组（即它比SABER快2倍）。这个结果与FrankMcSherry的实现（3500万tuples/sec）基本一致，后者运行在具有更高基本时钟速度的笔记本电脑上。

理解此性能差距背后的原因并将其用于设计具有硬件意识的流处理系统非常重要。我们已经开始设计利用超标量执行和SIMD并行性的高效流媒体运算符实现。我们还致力于基于编译的技术，尽可能将数据保存在CPU寄存器中，从而最大限度地提高数据和代码的局部性（Hyper）。正如我们从上面的结果看到的那样，在LLC中维护数据已经带来了主要的性能优势。我们还设想了一组硬件无关的基元，它们考虑到现代扩展架构上多个CPU插槽引起的非均匀内存访问（NUMA）。

得出结论

随着大容量DRAM，数据中心中的许多CPU内核和加速器的可用性，流处理系统的设计必须专注于硬件意识技术。在YahooStreamingBenchmark的修改版本中，SABRE每秒处理7千万个元组，并拥有8个CPU内核，性能优于Flink（3x），SparkStreaming（7x）和StreamBox（7x）。它比具有40个CPU内核的基于群集的部署具有更好的性能。我们的结果还表明，填充单个节点仍然存在性能差距，我们认为这构成了设计下一代流处理引擎的机会。最后，关于雅虎流媒体基准测试的先前评论，我们同意基准测试不会捕捉真实世界的流媒体应用程序的行为，而这些应用程序往往是计算密集型的。