Cassandra and Spark

Question

Привет, У меня вопрос высокого уровня относительно топологии кластеров и репликации данных относительно cassandra и искры, которые используются вместе в предприятии datastax.

Это было мое мнение, что если в кластере было 6 узлов, и были сделаны тяжелые вычисления (например, аналитика), вы могли бы иметь три искровых узла и 3 узла кассандры, если хотите. Или вам не нужны три узла для аналитики, но ваши задания не будут работать так быстро. Причина, по которой вам не нужна тяжелая аналитика на узлах cassandra, заключается в том, что локальная память уже используется для обработки тяжелой нагрузки чтения/записи cassandra.

Это очень понятно, но вот мои вопросы:

• Как работает копируемые данные тогда?
• Все ли узлы кассандры только в одной стойке, а все искровые узлы в другой стойке?
• Все ли данные реплицируются на искровые узлы?
• Как это работает, если это так?
• Каковы рекомендуемые шаги настройки для обеспечения правильной репликации данных в искровых узлах?

Answer 1

Как работают реплицированные данные?

Регулярная репликация Cassandra будет работать между узлами и DC. Что касается репликации, это то же самое, что наличие кластера c * с двумя центрами данных.

Все ли узлы кассандры в одной стойке и все искровые узлы в другой стойке?

С помощью стандартного DSE Snitch ваши узлы C * будут находиться в одном постоянном токе и узлах Spark в другом контроллере постоянного тока. Все они будут в стойке по умолчанию.Если вы хотите использовать несколько стоек, вам придется настроить это самостоятельно, используя расширенный снитч. GPFS или PFS - хороший выбор в зависимости от ваших механизмов оркестровки. Узнать больше in the DataStax Documentation

Все ли данные реплицируются на искровые узлы? Как это работает, если это так?

репликации контролируется на уровне ключевого пространства и зависит от вашей стратегии репликации:

SimpleStrategy будет просто задать вам количество копий вы хотите в кластере (это не центр обработки данных известно, поэтому не используйте это если у вас есть несколько DC-х)

create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3 } 

Это предполагает, что вы есть только один DC, и что вы будете иметь 3 копии каждого бита данных

стратегия NetworkTopology ДАВАЙТЕ вы выбираете количество реплик на каждый DC

create KEYSPACE tst WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : 2, 'DC2': 3 } 

Вы можете выбрать другое количество реплик для каждого постоянного тока.

Каковы рекомендуемые шаги настройки для правильной репликации данных в искровых узлах?

Процедура обновления RF: in the datastax documentation. Вот это дословно:

Обновление фактора репликации Повышения коэффициента репликации увеличивает общее количество копий данных, хранящихся в пространстве ключей в Кассандра кластере. Если вы используете функции безопасности, то значение особенно важно для увеличения коэффициента репликации в пространстве ключей system_auth по умолчанию (1), поскольку вы не сможете войти в кластер, если узел с одиночной репликой не работает. Рекомендуется установить коэффициент репликации для системного_auth ключей, равный количеству узлов в каждом центре обработки данных.

Процедура

Обновление пространство ключей в кластере и изменить свою стратегию репликации варианты. ALTER KEYSPACE system_auth WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc1': 3, 'dc2': 2}; Или при использовании SimpleStrategy:

ALTER пространство ключей "Экскалибур" с репликацией = { 'класс': 'SimpleStrategy', 'replication_factor': 3}; На каждом поврежденном узле выполните команду восстановления nodetool. Дождитесь завершения ремонта на узле , затем перейдите к следующему узлу.

Знайте, что увеличение ВЧ в вашем кластере приведет к многократной загрузке ввода-вывода и процессора, а также к сетевому трафику, в то время как ваши данные будут перемещаться вокруг вашего кластера.

Если у вас есть рабочая нагрузка, вы можете throttle удар с помощью nodetool getstreamthroughput/nodetool setstreamthroughput.

Вы также можете throttle the resulting compactions с nodetool getcompactionthroughputnodetool setcompactionthroughput

Как Cassandra и свечи работают вместе на узлах аналитики и не бороться за ресурсы? Если вы не собираетесь ограничить Cassandra вообще во всем кластере, то в чем смысл ограничения Spark, просто включите все узлы Spark.

Ключевым моментом является то, что вы не будете указывать ваш главный транзакционных операций чтения/записи в DC Analytics (использовать что-то вроде уровня согласованности ONE_LOCAL или QUORUM_LOCAL указать те запросы на C * DC). Не волнуйтесь, ваши данные по-прежнему поступают в DC аналитики в результате репликации, но вы не будете ждать возврата данных из узлов аналитики, чтобы отвечать на запросы клиентов. Второй DC - eventually consistent.

Вы правы в том, что кассандра и искра все еще работают на одних и тех же блоках в DC аналитики (это важно для местоположения данных) и имеют доступ к тем же ресурсам (и вы можете делать такие вещи, как управление максимальными искровыми ядрами так что у кассандры еще есть комната для дыхания). Но вы достигаете workload isolation, имея два центра обработки данных.

Драйвер DataStax по умолчанию будет рассматривать DC первой контактной точки, с которой они соединяются, как локальный DC, поэтому просто убедитесь, что ваш список контактных точек включает только машины в локальном (c * DC).

Вы также можете указать локальный центр обработки данных самостоятельно в зависимости от драйвера. Вот пример для ruby driver, проверьте документацию драйвера для других языков.

использование: метод кластеров центров обработки данных: первый найденный центр данных будет принят по умолчанию. Обратите внимание, что вы можете пропустить этот параметр, если указать только хосты из локального центра данных в: hosts.

Answer 2

Вы правы, вы хотите разделить свою кассандру и свою аналитическую рабочую нагрузку. Типичная установка может быть:

• 3 Узлы в одном центре обработки данных (имя: Cassandra)
• 3 Узлы во втором центре данных (имя: аналитика)

При создании keyspaces вы определяете их NetworkTopologyStrategy и фактор репликации определяется для каждого центра обработки данных, например, так:

CREATE KEYSPACE myKeyspace WITH replication = {'class': 'NetworkTopologyStrategy', 'cassandra': 2, 'analytics': 2}; 

с помощью этой установки, ваши данные будут скопированы дважды в EAC h датацентра. Это делается автоматически cassandra. Поэтому, когда вы вставляете данные в DC cassandra, вставленные данные будут автоматически реплицироваться в DC-аналитику и наоборот. Примечание. Вы можете определить, какие данные реплицируются, используя отдельные пространства ключей для данных, которые вы хотите проанализировать, и данные, которые у вас нет.

В вашей cassandra.yaml вы должны использовать GossipingPropertyFileSnitch. С помощью этого snitch вы можете определить DC и стойку вашего узла в файле cassandra-rackdc.properties. Затем эта информация распространяется по протоколу сплетен. Поэтому каждый узел изучает топологию вашего кластера.