Короче говоря, у меня есть клиент, который хочет, чтобы данные, содержащиеся в наборе текстовых файлов ASCII (также известных как «входные файлы»), были загружены в Accumulo.
Эти файлы выводятся с различных устройств подачи данных и будут постоянно генерироваться на узлах, отличных от Hadoop или Accumulo (также называемых «узлами подачи»). Ожидается, что общая скорость передачи данных по всем каналам будет очень высокой.
Для простоты предположим, что все данные окажутся в одной таблице прямого индекса и одной таблице инвертированного [обратного] индекса в Accumulo.
Я уже написал клиентский модуль Accumulo, используя pyaccumulo, который может устанавливать соединение с Accumulo через Thrift Proxy, читать и анализировать входные файлы из локальной файловой системы (не HDFS), создавать соответствующие мутации прямого и обратного индекса в коде и используйте BatchWriter для записи изменений в таблицы прямого и обратного индекса. Все идет нормально. Но это еще не все.
Из различных источников я узнал, что существует по крайней мере несколько стандартных подходов для высокоскоростной загрузки Accumulo, которые могут применяться в моем сценарии, и я прошу совета относительно того, какие варианты имеют наибольший смысл с точки зрения использования ресурсов, и простота внедрения и обслуживания. Вот несколько вариантов:
- Клиенты BatchWriter на узлах каналов: запустите мой клиент Accumulo на узлах каналов. Недостатком этого варианта является отправка по сети как прямых, так и обратных мутаций индекса. Кроме того, библиотеки Accumulo/Thrift должны быть доступны на узлах каналов для поддержки клиента Accumulo. Однако у этого варианта есть то преимущество, что он распараллеливает работу по анализу входных файлов и созданию мутаций и, по-видимому, сводит к минимуму дисковые операции ввода-вывода в кластере Hadoop по сравнению с приведенными ниже вариантами.
- Клиент BatchWriter на главном узле Accumulo: scp/sftp — входные файлы с узлов подачи на главный узел Accumulo в какой-либо каталог в локальной файловой системе. Затем запустите мой клиент Accumulo только на главном узле Accumulo. Преимущество этого варианта заключается в том, что он не отправляет по сети как прямые, так и обратные мутации индекса от узлов подачи к главному узлу Accumulo, и не требует наличия библиотек Accumulo/Thrift на узлах подачи. Однако у него есть тот недостаток, что он заставляет главный узел Accumulo выполнять всю работу по анализу входных файлов и созданию мутаций, и он использует локальный диск главного узла Accumulo в качестве путевой точки для входных файлов.
- MapReduce с AccumuloOutputFormat: scp/sftp — входные файлы от узлов подачи к главному узлу Accumulo. Затем периодически копируйте их в HDFS и запускайте задание MapReduce, которое считывает и анализирует входные файлы из HDFS, создает мутации и использует AccumuloOutputFormat для их записи. Этот вариант имеет преимущества варианта № 2, описанного выше, плюс он распараллеливает работу по анализу входных файлов и созданию мутаций. Однако у него есть недостаток, заключающийся в том, что он будет постоянно запускать и ломать задания MapReduce и вызывать все накладные расходы, связанные с этими процессами. У него также есть недостаток, заключающийся в том, что он использует две дисковые путевые точки (локальную и HDFS) с соответствующим дисковым вводом-выводом. Звучит несколько болезненно для реализации и поддержки непрерывного приема.
- MapReduce с AccumuloOutput*File*Format (rfiles): scp/sftp — входные файлы от узлов подачи к главному узлу Accumulo. Затем периодически копируйте их в HDFS и запускайте задание MapReduce, которое считывает и анализирует входные файлы из HDFS, создает мутации и использует AccumuloOutputFileFormat для записи rfiles. Затем используйте оболочку Accumulo, чтобы «проглотить» rfiles. Этот вариант имеет все преимущества варианта № 3 выше, но я не знаю, есть ли у него другие преимущества (да? В руководстве по Accumulo говорится о массовой загрузке: «В некоторых случаях может быть быстрее загрузить данные таким образом, чем через прием через клиентов, использующих BatchWriters." Какие случаи?). Он также имеет все недостатки пункта 3 выше, за исключением того, что он использует три дисковых путевых точки (локальные, HDFSx2) с соответствующим дисковым вводом-выводом. Звучит болезненно для реализации и поддержки для непрерывного приема.
Лично мне больше всего нравится вариант № 2, поскольку мастер-узел Accumulo может самостоятельно обрабатывать нагрузку по обработке (непараллельный анализ входного файла). Вариант № 2, в котором я мог бы запустить свой клиент Accumulo на каждом узле Accumulo и отправить выходные данные разных узлов потока на разные узлы Accumulo или циклически, по-прежнему имеет недостаток, заключающийся в отправке прямых и обратных мутаций индекса по облаку. сеть к мастеру Accumulo, но имеет то преимущество, что анализ входного файла выполняется более параллельно.
Что мне нужно знать, так это: пропустил ли я какие-либо жизнеспособные варианты? Я пропустил какие-либо преимущества/недостатки каждого варианта? Являются ли какие-либо из преимуществ/недостатков тривиальными или очень важными, независимо от контекста моей проблемы, особенно компромиссов между пропускной способностью сети, циклом ЦП и дисковым вводом-выводом? Стоит ли MapReduce с rfiles или без них по сравнению с BatchWriter? У кого-нибудь есть "военные истории"?
Спасибо!
