Hive, Spark, Kafka (+ ZooKeeper) — да. Хотя сейчас с Kafka переходим на AWS Kinesis.
HBase, Pig, Flume — нет

У нас еще есть CoreOS + Docker + Mesos + Marathon + Cronos. Но это только показатель, что не нужно так часто давать волю команде разработчиков :)

Действительно, это невероятно тяжелая задача (особенно, если это делает DevOps утилита):

wget apache.volia.net/...op-2.6.0.tar.gz
tar -xzf hadoop-2.6.0.tar.gz
mv hadoop-2.6.0/ /opt

1) Из своих практических задач редко видел Machine Learning, поскольку ETL прост для многих разработчиков. Максимально, что я встречал — байесовская фильтрация и метод cингулярного разложение.

2) Класические. Меньше проблем со «специфическими», которые еще нужно разобрать, стоят ли они того.

3) Java, JRuby. Была попытка с RHadoop, но что то не сложилось (уже не помню в чем там был затык).

4) Нет, особенно, если есть готовые роли/кукбуки (Ansible/Chef/Puppet/Salt) свои или можно взять вендорные (которые можно модифицировать, если вдруг не совсем то). Также есть Amazon EMR, которые сам разворачивает Hadoop кластер по заданным мощностям, обрабатывает задачу и тушит ресурсы, тем самым экономя деньги: платите только за рабочее время EC2 + хранение на S3.

Можно. Триггерную (londiste, bucardo, etc.). Но с нагрузкой на эту базу это создает приблизительно 10% оверхед на операции записи (тут достаточно большая нагрузка на запись). Поэтому пока отложили эту идею. Пока как говорится «есть не просит». Вот на 9.5 — хотим переходить — нужно, что бы требуемые патчи (они уже прошли модерацию и осталось, что бы коммитеры их рассмотрели) наконец попали в мастер ветку и в резил.

P.S. 20-30 минут — это большой даунтайм (можно назвать — «лежим»). 5-10 — это норма.

Мне кажется что все же гораздо легче чем добавлять еще одну бд, обучать разработчиков ей пользоваться, встраивать ее в текущую архитектуру.

Для нас это не составляет труда, как бы громко это не звучало.

Почему основную? У меня на работе есть отдельный сервер с кучей дисков, мы его называем logdb, и туда пишем все чего душе угодно в структурированом виде, а потом по этим данным очень удобно разную аналитику считать и всякое дебажить, потому что все ходы записаны в доступном виде.

Замените «logdb» это на MongoDB — получите туже самую фразу (разве что писать можно в слабоструктурированном виде, как это часто бывает с логами: тут нужно еще вывести трейс, а тут debug режим, а тут и строчки про запуск хватит). Для логов это хорошая база. Ну и как я уже писал, если данные активно пишутся и стираются, то для PostgreSQL начинается слишком много работы с базой (крон скрипт для чистки, борьба с «table bloating») по сравнению с capped collection.

А нафига именно нужен этот «кеш»? Чем скл база именно не годится для этой всей роли?

У нас была задача не считать каждый раз репорты по архивным данным, раз они не меняются, а просто складировать (зачем вхолостую «ганять» CPU каждый раз?). В основную базу хранить это не нужно. Но и потерять эти данные не страшно — опять можно посчитать результат через SQL запрос.

Ну в постгрес наверное можно скрипт по крону запускать который будет старые записи складировать

Зачем нагружать основную базу? Тем более бороться с table bloating? Да и не нужно их складировать, их нужно вычищать.

Судя по github.com/...isan/meteor-sql это вопрос 20 строчек кода

Там ничего нет. Если бы указали этот: github.com/...rorm/meteor-sql то тогда было бы понятно — тут руками дописали REST интерфейс с веб сервером.

Это вообще какая то хрень полная. Что-что а скл для репортов любой сложности намного более пригоден чем убогий язык монго.

Агрегируются результаты по SQL, которые потом просто забираются из MongoDB при повторном запросе. MongoDB используется как хранилище результатов (думайте об этом, как о кеше без времени жизни).

1. Складирование логов. За счет capped колекций логи будут сами подчищаться и не забьют место на жестком диске.
2. Meteor. В чем смысл заменять MongoDB у этого инструмента (или подобных ему) на другую базу? Тут у монги есть хоть REST интерфейс, а к PostgreSQL придется написать (или включить через веб севрер модули), а так же очень тесная интеграция с фреймворком. Просто используем инструмент из коробки.
3. Преаграгационные и агрегационные репорты. Что бы не билдить дорогостоящие репорты каждый раз — делаем это один раз и ложем в могну. Пусть полежат. На основе репортов за день/неделю можно создавать отчеты за месяц/год.

Ну тут еще можно писать и писать, я только описал свои кейсы :)

Ну распишите уже поподробнее как OrientDB ведет себя в продакшн условиях. Какой у Вас кластер? Нагрузка? В чем минусы (плюсы мы уже поняли)? А маркетинг материал мы можем к любой базе на официальном сайте почитать :)

Я так же успешно могу написать про ArangoDB, но практической применение и разбор сорцов развеивает все эти маркетинг фразы в «bullshit».

PostgreSQL 9.4 vs MongoDB

Сравниваем теплое с мягким? Контекст задачи использования решает.