smikeshИгорь Бобак,

практически все коммерческие дистрибьюторы предоставляют
есть и клаудера, и хортонворкс и мапр

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

еще интересная связка это apache shark-spark-tachyon

hive сам по себе уже давно потерял актуальность, сейчас нужно смотреть либо на impala, shark or tez :)) причем для каждого нужно использовать свой формат хранения данных :)
Не в защиту Hive, который для меня убогое поделие индусских студентов из Мордокниги, но tez'у его противопоставлять нельзя. Это как противопоставлять двигатель автомобилю.

Игорь БобакЛюди не понимают, что big data

Люди не понимают, что big data - это такой модный слоган, который позволяет увеличить продажи, поэтому его лепят и куда надо и куда не надо.

Игорь Бобакэто тот же data warehouse, только distributed.
Big Data - это big data, data warehouse - это data warehouse, а distributed - это distributed.

Игорь БобакHadoop + Hive - это тот же движок SQL запросов (типа оракла или mssql), только недоделанный (цитирую слова одного опытного человека, с коротым разговаривал сегодня) и который тоже distributed.

Hadoop - это движек (среда) выполнения MapReduce, Hive - это транслятор SQL в MapReduce код.

Игорь БобакИ если они еще не делали простой data warehouse, то почему они думают, что distributed dw им будет сделать легко и от этого будет мгновенное счастье?
Вы бы порядок в голове по этому вопросу навели сначала, а потом рассуждали.

Игорь БобакНе совсем понимаю, к чему эти оскорбления.


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

Игорь БобакОт моего первого поста до последнего успел пересмотреть кучу видеоуроков и прочитать много материала. И если посмотреть на схему (см. ниже), то hadoop - это ничто иное, как хранилище данных, разложенное по частям на много узлов.

Или я может не тот термин использовал? Если это так, то можно и культурно меня поправить, а не давать грубые оценки о порядке в голове.

Ну, наверное и в термине тоже, фраза "хранилище данных, разложенное по частям на много узлов" звучит даже с точки зрения не буковеда очень коряво. Что вы понимаете под хранилищем? СУБД на которой оно реализовано? А под распределенным хранилищем?
К тому же, вы, похоже, слишком хорошего мнения о Hadoop, он гораздо примитивнее, чем кажется на первый взгляд. Это просто фреймворк, набор библиотек для исполнения MapReduce + пара-тройка сервисов поддержки и распределенная файловая система HDFS. По большому счету все. Файлопомойка с возможностью распределенной обработки данных. Можно ли реализовать на этом хранилище? Теоретически да, даже практически можно, если задаться целью. Правда, это примерно как пытаться реализовать хранилище на файловой системе, теоретически можно, но на парктике никто не делает.

Игорь БобакВладимир ШтепаВ Big data их структурируют на лету в процессе выполнения запроса.
Владимир,

а вот это структурирование не будет ли тормозить каждый раз при новом запросе?
И нет ли смысла каким-то образом все-таки поструктуризировать перед их заливкой в hadoop?
Даже после "структурирования" будет тормозить, хотя и не так сильно (тут все зависит от того, что и как парсим), но все же будет. Hadoop очень нерационально использует вычислительные ресурсы. Каждый mapper или reducer - это отдельный экземпляр JVM, который запускается каждый раз для каждого mapred job, вроде были какие-то работы в направлении использования потоков самой JVM, но насколько я помню оно так и не взлетело. Причем это каждый раз холодный старт. Перед Reduce step всегда должен быть Map step, даже если он не нужен, это ограничние самой вычислительной модели Map-Reduce, это то, что пробуют исправить в Tez. Обмен данными между map step и reduce step только через файловую систему. Сама HDFS живет поверх той FS, которая используется ОС на ваших серверах. Каждый блок HDFS - это просто файл на этой файловой системе. Напрямую с контроллерами оно не работает. Соответствие между блолками и файлами хранится на Name Node, в случае большого числа мелких файлов, которые меньше размера блока HDFS получите сильную нагрузку на Name Node. В общем там подводных камней очень много.
Так что мой вам совет, если ваши данные достаточно хорошо ложатся на реляционную модель и данных этих меньше полу-петабайта в сыром виде и у вас много пользователей, которые будут запускать Ad-Hoc запросы по ним, то скорее всего экономической выгоды от использования Hadoop для обработки этих данных вы не получите. Лучше взять реляционную MPP, самая примитивная и недорогая MPP реляционка подойдет для этой задачи лучше, чем связка Hadoop+Hive.

babonaнадо так понимать, что Big Data - это очередной маркетинговый ход, позволяющий вытянуть из заказчиков большую денюжку, доить их благодаря магическому слову Big. Это же Big !! Оооо, значит и денег должно стоить много. А потом окажется, что опять надо много кодить, программистов много нанимать, их кормить, чтобы получить какие-то там отчетики, посмотреть и выбросить их.
Надо понимать, что изначально продукт писался для очень ограниченного круга задач, где хорошая масштабируемость была важнее рациональности использования вычислительных мощностей. Теперь же, да, благодаря ушлым продажникам, для которых по-сути важно лишь, сколько и чего они могут продать, а не то, поможет это рельно клиенту или нет, это превратилось в marketing buzz и теперь эту сову пытаются натянуть на каждый глобус.

Alexander Ryndinbabonaвопрос:

продвинутым пользователям экномистам, финансистам (Power Users) - adHoc выборки данных как делать?Этих людей к Hadoop-подобным штукам пускать нереально
Ты наверное будешь смеяться, но так делали в Expedia, не знаю как там сейчас, но когда я там был, они реально так работали, финансисты и менеджеры реально сидели в Hue и гоняли там запросы. Вот вам и "продвинутость" ИТ в иностранных корпорациях:)