Spark Streaming App同时写入和读取Cassandra时卡住了

Question

我正在做一些基准测试，包括以下数据流：

Kafka - ＆gt; Spark Streaming - ＆gt; Cassandra - ＆gt; Prestodb

基础设施：我的火花串流应用程序在4个执行程序上运行（每个2核4g内存）。每个执行程序都在安装了Cassandra的datanode上运行。 4 PrestoDB工作人员也共同位于数据节点中。我的集群有5个节点，每个节点都配有英特尔酷睿i5,32GB DDR3内存，500GB SSD和1千兆网络。

Spark流媒体应用程序：我的Spark流式传输批处理间隔为10秒，我的kafka制作人每3秒生成5000个事件。我的流应用程序写入2个Cassandra表。

一切正常的上下文：一切运行良好，流媒体应用程序能够处理事件并将其存储在Cassandra中。批处理间隔足够，摄取率，调度和处理延迟在很长一段时间内几乎保持不变。

事情变得混乱和混乱的背景：在我的基准测试中，我每小时都会对Cassandra表运行6次查询。对于我运行这些查询的时间量，Spark流应用程序不再能够维持写入吞吐量并在写入Cassandra时挂起。

到目前为止我做了什么：我在其他网络帖子（包括stackoverflow）中搜索过这种现象，但我无法找到类似的现象。我见过的最好的事情是增加Cassandra可用的内存量。还可以看到与连接器的提取大小相关的其他方面，但我不知道这是否是一个问题，因为它只在同时进行读写时才会发生。

问题：Cassandra在阅读时不应该锁定写入，对吗？你们认为我需要解决的问题的根源（或来源）是什么？我应该考虑哪些配置？

我附加了一个打印a print，说明当我使用6个查询运行基准测试时，写入其中一个Cassandra表的阶段中的作业，如前所述。如果您需要更多信息来追踪问题，请随意询问。我很感激！

非常感谢您的支持，

希望我以正确的方式提出问题，

致以最诚挚的问候，

卡洛斯

Answer 1

由于原因/假设，这个问题看起来在Cassandra-Presto方面，而不是在Spark上

1. 由于火花执行者由RM（纱线/ mesos等）处理，您的查询不会直接影响。在关闭查询期间，如上所述，提取运行顺利。
2. 仅当您与其他组件直接共享资源时，才会发生Spark side resource饿死。一般来说，Cassandra，Presto工作者/线程不是使用RM分配的，因此它们从节点角度而不是RM角度共享资源。

我怀疑失速的原因可能是，

1. 在查询期间，Cassandra正在读取大量数据，因此JVM内存利用率会增加，而且很多GC都会发生。 GC暂停可能是暂停/停顿的原因。
2. Cassandra的连接数（读/写）完全被查询使用，因此Spark作业无法插入数据并在队列中等待获取连接。
3. 节点上的总体资源利用率增加，并且可能其中一个组件已达到其限制（CPU，内存，磁盘等）。在这种情况下，IMO CPU，磁盘值得检查。

通过监控堆填充工具和 GC日志，使用JMX打开连接为Cassandra验证这些原因，然后根据具体情况提升这些值可用资源来解决问题并尝试调整Presto查询，因此影响最小。

一旦确认Cassandra问题，就可以将Presto调整作为后续部分。

提供更多Presto调整

https://prestodb.io/docs/current/admin/tuning.html 或者如果使用teradata解决方案，那么， https://teradata.github.io/presto/docs/current/admin/tuning.html

Answer 2

我想知道这是否与cassandra有关。

配置的Spark scheduling策略是什么？默认情况下，它是FIFO。暗示，查询作业可能会消耗所有核心，直到完成为止。而且，会使流媒体工作挨饿。如果是FIFO，请更改为FAIR并重试。

Answer 3

只是为了完成这个问题并遵循堆栈溢出成员给我的建议，这些成员很友好地回复：

1）我将Cassandra的jvm.options中的Java垃圾收集器更改为G1，这不需要像默认CMS那样多的调整。 http://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsTuneJVM.html#opsTuneJVM__setting-g1-gc 我更改了它，因为在类似的情况下，GC暂停经常表示为问题。说实话，我不太熟悉GC监控，但Datastax Cassandra文档告诉我使用G1。我改变了它，我注意到我的工作负载和基础架构有一点性能和稳定性提升。

2）我意识到我对集群的性能持乐观态度，而且几乎不可能每10秒处理和写入Cassandra 20 000个事件，同时在Cassandra上运行繁重的prestoDB查询。 PrestoDB和Cassandra几乎消耗了我节点中的所有CPU。我每个节点只有4个核心。 Cassandra的CPU使用率几乎达到280％，Presto几乎达到了90％，因此Spark流媒体执行器在那里挨饿。此外，Cassandra没有更多的空间来容纳这个写入率，并且火花流工作开始挂起，在很长一段时间内累积了几批。因此，我将批处理间隔设置得更高。我知道你失去了一些数据的及时性，但如果基础设施无法处理，我就没有足够的资源来扩展：（

另一种可能性是通过使用linux cgroups，yarn cpu隔离和队列的应用程序来微调CPU限制，并查看它是否有帮助。对于我的集群，如前所述，我认为这个问题实际上是试图用一辆小型遥控车来移动一个山地车＃34; :)每个节点都负责火花流工作+ cassandra + presto，只有4个核心。

3）最后我还调整了火花Cassandra连接器，这适用于我的工作量，但我认为这将取决于您的数据和其他变量。我变了： *并发写入次数从5到2; * grouping.key来自＆＃34; partition＆＃34; to＆＃34; replica_set＆＃34;，因为我的分区键具有高基数（它们在RDD中几乎是唯一的），因此根据分区键对批处理进行分组是没有用的。但这当然取决于您的分区键。 * batch.size.rows到50.但这可能取决于您为每个流微批处理所拥有的数据量。 https://github.com/datastax/spark-cassandra-connector/blob/master/doc/reference.md

我希望这篇文章可以帮助其他人在流式传输大数据项目时遇到困难，因为有时候事情会非常困难:)如果我的某些决定也是错误或误导，请告诉我。感谢每一位帮助。

谢谢大家，

致以最诚挚的问候，

Carlos Costa