Коллеги, добрый день и с прошедшими праздниками!

Прошу помочь.
Встал вопрос по архитектуре и интеграции приложения. В основе решено использовать кластер на CDH основная задача которого - предоставление HDFS для спарка. И на этом я бы и остановился, но есть ряд вопросов, прошу Вас поделиться опытом.

1. Правильно ли я понимаю что поднимая в кэш спарка данные (например плоские файлы): sc.textFile(Filename).cache();
эти данные будут расшарены между нодами в их ОЗУ, и основной профит применения CDH будет в том что не потребуется этот Filename выкладывать локально на каждую ноду?

2. Так же интересно как поведет себя спарк в случае падения нескольких нод, в спарке требуется разбивать на партиции данные между нодами? , что бы существенно ускорить процесс обработки (что бы не хранить ВСЁ на каждой ноде), если так.. то интересно что будет если выпадут все ноды хранящие одну и ту же часть данных.

* 1 и 2 вопросы - можно ли обойтись без HDFS одним спарком и при этом не потерять в скорости обработки.
как я понимаю нет, т.к. спарк через ярн цепляется к узлам и всё волшебство проходит именно в хадупном кластере.
правда я слышал что есть фичи в спарк которые с одной ноды могут раскидать файл по остальным, и если так, то значит можно эти данные партиционировать между нодами и т.о. обрабатывать быстрее, при этом не используя HDFS? прошу прокомментировать по п.1 и п.2

3. Вопрос по индексированию и всему что с ним связано (ребалансы, реорги, ранстаты) Есть несколько неподтвержденных историй успеха использования ЭластикСрч + Спарк, причем функция ЭластикСрч индексация, а значит скорость обработки. Подскажите в чем основная причина прикручивать ЭластикСрч к спарку.
И как спарк работает с индексами? ПОднимая в кэш файл на десятки и сотни гигов, чем будет обеспечен быстрый поиск?
(ИЛИ ЭТО КАЖДЫЙ РАЗ ФУЛЛСКАН, но за счет кластеризации и того что слой вычисления и хранения максимально близки - работает недолго)


4. Тачйон (tachyon) - верно ли я понимаю что он уже в дистрибе спарка, отдельная установка не требуется?

5. Кафка - месседжинг для кластера, требуется если в ит-ландшафте уже используется MQ, если нет, подскажите для интеграции чего с чем его лучше использовать.

6. Общий вопрос: имея несколько десятков плоских файлов (от 2Гб до 40Гб), взаимосвязанных между собой, (но для 90% случаев поиска потребуются алгоритмы нечеткого поиска, что бы найти связи) какой стек технологий Вы стали бы использовать с учетом того что спарк уже не убрать)))

Спасибо!

по п.5 - ясно. Кафка для заливки данных в HDFS, т.е. из спарк_стрим в кафка и в HDFS, думаю что бы не рестартовать и не тянуть инкремент каждый раз. и всё же про Кафку хотелось бы услышать. Интересно.. Кафка нужна только потому что там интеграция с хадуп из коробки + ноды для Кафки можно до бесконечности наращивать, так?

SHARK:шарк остановлен, спарк использует sparkSQL без хранилища мета данных на 2014. (отмечу импалу реализованную на С++)

SciDB,

- Насчет индексов и поиска - Спарк не для этого сделан. Если надо быстро чего-то искать, лучше это делать не Спарком. Им надо перелопачивать большие объемы.


только про это хотел спросить.
как я понимаю имея 100500 нод и рзмазанные ровным слоем по ним сырые данные, процесс построения индексов займет совсем не много времени (не в пример большинству БД), при этом мы их сохраняем, т.к. результат вычисления этого RDD сохраняем в ОЗУ.
(да, понятно, что если что.. потребуется заново перестраивать каждый раз, но! поиск будет бодр и свеж)

Не???