Аккумуляторные высокоскоростные возможности приема

Question

Вкратце, у меня есть клиент, который хочет получить данные, содержащиеся в кучке текстовых файлов ASCII (входные файлы A.k.a), которые попадают в Accumulo.

Эти файлы выводятся из различных устройств передачи данных и будут генерироваться непрерывно на узлах (HA), не являющихся Hadoop/non-Accumulo (a.k.a "узлами подачи"). Ожидается, что общая скорость передачи данных по всем каналам будет очень высокой.

Для простоты предположим, что все данные будут представлены в одной таблице прямого индекса и одной инвертированной таблице обратного индекса в Accumulo.

Я уже написал клиентский модуль Accumulo с использованием pyaccumulo, который может установить соединение с Accumulo через прокси-сервер Thrift, прочитать и проанализировать входные файлы из локальной файловой системы (а не HDFS), создать соответствующие мутации прямого и обратного индекса в коде и использовать BatchWriter для записи мутаций в прямую и обратную таблицы индексов. Все идет нормально. Но есть еще кое-что.

Из разных источников я узнал, что существует несколько стандартных подходов к высокоскоростному глотанию Accumulo, которые могут применяться в моем сценарии, и я прошу совета относительно того, какие варианты имеют наибольший смысл в терминах использования ресурсов и простоты внедрения & обслуживание. Ниже приведены некоторые варианты:

1. Клиенты BatchWriter на узлах подачи: запустите мой клиент Accumulo на узлах подачи. Этот вариант имеет недостаток, отправляющий мутации в прямом и обратном направлениях по сети. Кроме того, библиотеки Accumulo/Thrift должны быть доступны в узлах подачи для поддержки клиента Accumulo. Однако этот параметр имеет то преимущество, что он распараллеливает работу по разбору входных файлов и созданию мутаций и, похоже, минимизирует дисковый ввод-вывод в кластере Hadoop по сравнению с приведенными ниже параметрами.
2. Клиент BatchWriter на главном узле Accumulo: scp/sftp входные файлы из узлов подачи на главный узел Accumulo в некоторый каталог локальной файловой системы. Затем запустите мой клиент Accumulo только на главном узле Accumulo. Преимущество этой опции заключается в том, что она не отправляет мутации прямой и обратной передачи по сети из узлов подачи в главный узел Accumulo и не требует наличия библиотек Accumulo/Thrift для узлов подачи. Однако недостатком является то, что он делает главный узел Accumulo всей работой по разбору входных файлов и созданию мутаций, и он использует локальный диск мастера Accumulo в качестве путевой точки для входных файлов.
3. MapReduce with AccumuloOutputFormat: scp/sftp входные файлы из узлов подачи в главный узел Accumulo. Затем периодически копируйте их в HDFS и запускайте задание MapReduce, которое считывает и анализирует входные файлы из HDFS, создает мутации и использует AccumuloOutputFormat для их записи. Эта опция имеет преимущества # 2 выше, плюс она распараллеливает работу по разбору входных файлов и созданию мутаций. Однако недостатком является то, что он будет постоянно разворачивать и разбивать задания MapReduce и вызывать все накладные расходы, связанные с этими процессами. Это также имеет тот недостаток, что он использует две путевые точки диска (локальная и HDFS) с соответствующими дисковыми вводами/выводами. Это звучит несколько болезненно для осуществления и поддержания непрерывного приема пищи.
4. 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? Кто-нибудь имеет «военные истории»?

Спасибо!

Answer 1

Даже в каждом прецеденте люди имеют личные предпочтения относительно того, как они хотели бы реализовать решение для конкретного варианта использования. Я бы на самом деле запускал агентов потока на узлах подачи и собирал данные в HDFS и периодически запускал MapReduce по новым данным, которые поступают в HDFS с использованием подхода RFile.