Question

我使用cassandra 2.1.5（.469）和spark 1.2.1。

我在大C *表（2,034,065,959行）上执行了一个带有spark的迁移作业 - 使用以下命令将其迁移到另一个模式表（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作业？

编辑：

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

Answer 1

就可能使用大量系统资源的压缩而言，它可以从性能角度影响您的Spark作业。您可以通过compaction_throughput_mb_per_sec来控制压缩程序一次可以执行的吞吐量。

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

此外，压缩发生的事实可能意味着您的数据在sstables之间的分布方式并不是最佳的。因此，压缩可能是问题的症状，但不是实际问题。事实上，它可以解决您的问题（随着时间的推移，它会取得更多进展）。

我建议您查看要查询的表的cfhistograms输出，以查看每次读取时有多少SSTable被点击。这可能是一个很好的指标，表明某些事情是不理想的 - 例如需要更改配置（即可记忆的冲洗率）或优化或更改压缩策略。

This answer为如何阅读cfhistograms输出提供了很好的解释。

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

1 个答案: