настоящее время я использую этот стек:joinWithCassandraTable становится намного медленнее растущего размера таблицы
- Cassandra 2,2 (многоузловой)
- Спарк/Streaming 1.4.1
- искровым Cassandra-Connector 1.4.0 -M3
У меня есть DStream [Ids] с RDD, насчитывающим около 6000-7000 элементов. id
- это ключ раздела.
val ids: DStream[Ids] = ...
ids.joinWithCassandraTable(keyspace, tableName, joinColumns = SomeColumns("id"))
Как tableName
становится все больше, скажем, вокруг 30k «строк», запрос занимает гораздо больше времени, и у меня возникают проблемы пребывания под порогом продолжительности партии. Он работает аналогично использованию массивного IN
-clause, который я понял нецелесообразно.
Есть ли более эффективные способы сделать это?
Всегда помните о том, чтобы переделать локальные RDD с помощью repartitionByCassandraReplica
перед выполнением соединений с Cassandra, чтобы гарантировать, что каждый раздел работает только с локальным узлом Cassandra. В моем случае мне также пришлось наращивать разделы при подключении к локальному RDD/DStream, чтобы задачи распределялись равномерно между рабочими.
Действительно, теперь это намного быстрее. Я делаю 'repartitionByCassandraReplica (keyspace, tableName)' с 10 разделами по умолчанию. У меня только 2 исполнителя, и данные разделяются на Murmur3. Кажется, что только один работник читает данные, что приводит к тому, что другой не работает. Это проблема разделения? – kareblak
У вас есть только один узел? Обычно у вас должен быть один искровой рабочий, работающий на каждом узле, поэтому каждый рабочий будет загружать данные, которые являются локальными для этого узла. –
Нет, у меня есть один водитель и 2 исполнителя, на 3 машинах. Я бы подумал, что даже при дефолте 10 разделов он попытается распространить материал вокруг. – kareblak