C* 中的压缩过程会影响 Spark 作业吗？

Question

我正在使用带有 spark 1.2.1 的 cassandra 2.1.5 (.469)。

我在 big C* table（2,034,065,959 行）上使用 spark 执行了迁移作业- 将其迁移到另一个模式 table（new_table），使用：

some_mapped_rdd.saveToCassandra("keyspace", "new_table", writeConf=WriteConf(parallelismLevel = 50))

我在 OpsCenter/Activities 中看到 C* 在 new_table 上执行一些压缩任务，并且持续了几天。

此外，我正在尝试 运行 另一项工作，同时压缩任务仍在进行中，使用：

    //join with cassandra
    val rdd = some_array.map(x => SomeClass(x._1,x._2)).joinWithCassandraTable(keyspace, some_table)

    //get only the jsons and create rdd temp table
    val jsons = rdd.map(_._2.getString("this"))
    val jsonSchemaRDD = sqlContext.jsonRDD(jsons)
    jsonSchemaRDD.registerTempTable("this_json")

并且比平时（通常我不执行大量迁移任务）需要更长的时间才能完成。

那么 C* 中的压缩过程对 Spark 作业有影响吗？

编辑：

我的 table 配置为 SizeTieredCompactionStrategy（默认）压缩策略，我有 2882~ 20M~（和更小的，在 3 个节点中的 1 个节点上）SSTable 文件，所以我想我应该更改 compaction_throughput_mb_per_sec 参数设置为更高的值并使用 DateTieredCompactionStrategy 压缩策略，因为我的数据是时间序列数据。

Answer 1

就可能使用大量系统资源的压缩而言，从性能的角度来看，它会影响您的 Spark 作业。您可以通过 compaction_throughput_mb_per_sec.

控制一次可以执行多少吞吐量压缩

另一方面，降低压缩吞吐量将使您的压缩需要更长的时间才能完成。

此外，正在进行压缩的事实可能意味着您的数据在 sstables 之间的分布方式不是最佳的。因此，压缩可能是问题的症状，而不是实际问题。事实上，它可能是您问题的解决方案（随着时间的推移，它会取得更大的进步）。

我建议您查看您正在查询的表的 cfhistograms 输出，以了解每次读取命中了多少 SSTable。这可能是一个很好的指标，表明某些事情不是最优的——例如需要更改您的配置（即 memtable 刷新率）或优化或更改您的压缩策略。

很好地解释了如何读取 cfhistograms 输出。