Влияют ли процессы уплотнения в C* на задания Spark?

Я использую cassandra 2.1.5 (.469) со spark 1.2.1.

Я выполнил задание миграции с помощью spark для большой таблицы C * (2 034 065 959 строк) - перенес ее в другую таблицу схемы (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~ (и меньше, на 1 узле из 3) файлов SSTable, поэтому я думаю, что мне следует изменить параметр compaction_throughput_mb_per_sec на более высокое значение и перейти к стратегии сжатия DateTieredCompactionStrategy. поскольку мои данные представляют собой данные временных рядов.


cassandra apache-spark spark-cassandra-connector opscenter
person Reshef    schedule 18.01.2016    source источник
comment
Мне просто любопытно, какую стратегию сжатия вы используете для своих таблиц, которые показывают много ожидающих сжатий? Некоторые стратегии сжатия могут лучше подходить для массовой загрузки и ваших шаблонов запросов.   -  person Andy Tolbert    schedule 18.01.2016
comment
Также было бы неплохо узнать, сколько файлов SSTable (файлов *Data.db) у вас есть в таблицах с большим количеством действий по сжатию. Хотите знать, есть ли у вас много маленьких файлов, что может объяснить медленное время запросов, а также необходимость увеличения активности сжатия.   -  person Andy Tolbert    schedule 18.01.2016
comment
@ Энди Толберт - пожалуйста, смотрите мое редактирование. Мне интересно, влияет ли коэффициент репликации (я установил его на 2, когда у меня есть 3 узла) на уплотнение SSTable и/или на скорость чтения и записи в кластер?   -  person Reshef    schedule 18.01.2016

Ответы (1)


arrow_upward
1
arrow_downward

С точки зрения сжатия, потенциально использующего много системных ресурсов, это может повлиять на ваши задания Spark с точки зрения производительности. Вы можете контролировать, какую пропускную способность может выполнять сжатие за раз, с помощью compaction_throughput_mb_per_sec.

С другой стороны, снижение производительности уплотнения приведет к увеличению времени уплотнения.

Кроме того, тот факт, что происходит уплотнение, может означать, что ваши данные распределяются между sstables неоптимально. Таким образом, может быть, что уплотнение является признаком проблемы, но не фактической проблемой. На самом деле это может быть решением вашей проблемы (со временем, когда она будет прогрессировать).

Я рекомендую взглянуть на выходные данные cfhistograms. ваших таблиц, которые вы запрашиваете, чтобы увидеть, сколько SSTables попадает в одно чтение. Это может быть хорошим индикатором того, что что-то неоптимально — например, необходимость изменить вашу конфигурацию (например, скорость сброса памяти) или оптимизировать или изменить вашу стратегию сжатия.

Этот ответ дает хорошее объяснение того, как читать вывод cfhistograms.

person Andy Tolbert    schedule 18.01.2016