Комментарии 20
Написано: "… мы выбрали ..." — а кто вы?
Думаю, это несложно определить из профиля пользователя.
Наверное, стоило упомянуть. Команда разработки соответствующего проекта компании CUSTIS.
Как я понял Cloudera имеет те же проблемы что и классический Hadoop?
В частности не realtime нагрузка.
Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Как я понял Cloudera решает только проблему merge данных за счет больших требований к памяти?
В частности не realtime нагрузка.
Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Как я понял Cloudera решает только проблему merge данных за счет больших требований к памяти?
Cloudera — это компания. Вас какой из её продуктов интересует?
Мы кстати с вами недавно в моей тебе говорили.
Я ищу MPP, но для realtime. У нас дашборды на Oracle BI, на одном дашборде около 10 графиков и таблиц. Необходимо чтобы страница грузилась за 3 секунды. Hadoop классический не подходит, т.к. batch обработка медленная и вродебы Hadoop не держит больше 10 параллельных запросов.
HBase я тоже сомневаюсь что подойдет.
Так же нужно, чтобы обрабатывал базу в 300 Тб.
Чтобы могли работать одновременно 100 пользователей, в будущем больше.
Я ищу MPP, но для realtime. У нас дашборды на Oracle BI, на одном дашборде около 10 графиков и таблиц. Необходимо чтобы страница грузилась за 3 секунды. Hadoop классический не подходит, т.к. batch обработка медленная и вродебы Hadoop не держит больше 10 параллельных запросов.
HBase я тоже сомневаюсь что подойдет.
Так же нужно, чтобы обрабатывал базу в 300 Тб.
Чтобы могли работать одновременно 100 пользователей, в будущем больше.
Зависит конечно от типов запросов, но очень похоже для кейс для Spark-а. Там real-time updating (streaming), анализируемые выборки (у них называются «коллекции») по максимуму держатся в памяти.
Но, конечно по скудной информации сложно давать взвешенные советы
Но, конечно по скудной информации сложно давать взвешенные советы
Мы кстати с вами недавно в моей тебе говорили.
Когда отвечал, искренне полагал, что мы ещё там :)
Так же нужно, чтобы обрабатывал базу в 300 Тб.
Но ведь не все 300Тб одновременно и за 3 секунды?
Пакетная (batch) обработка всего лишь означает, что вы обрабатываете сразу много объектов, а не вызываете обработчик для каждого по отдельности. Пакетная обработка по определению быстрее поэлементной. Другое дело, что иногда ради такого ускорения приходится увеличивать время старта, что на небольших запросах приводит к замедлению, а не ускорению. Классический MapReduce, например, стартует что-то около 15 секунд, поэтому запускать его над данными, которые обрабатываются всего 5 секунд просто глупо. Насколько я понимаю, вам нужен batch processing, но с меньшим временем старта. Самое близкое здесь Impala (если нужен SQL-like язык) и Spark (если нужен общий API к распределённым коллекциям).
>Но ведь не все 300Тб одновременно и за 3 секунды?
Нет конечно. Может быть и 10 гигабайт за 3 секунды, но скорее всего меньше. Скорей всего будут применяться агрегаты, индексы, партиции, желательно ручная сегментация. Вообщем я ищу MPP, но с функциями почти классической СУБД, разве что джоинов там будет мало. Архитектура базы будет звездочка или снежинка.
Поддержка SQL явный плюс.
Если честно, я что-то сомневаюсь, что MapReduce может обеспечить быстрый отклик.
Так же большой проблемой я считаю жестко заданый размер блока в 64 мегабайта, это слишком много, у Оракла максиму 32 килобайта. Т.е. что бы считать одну строчку нужно считать целых 64 мегабайта.
Идеальную систему я вообще вижу очень гибкой, и что бы можно быть и realtime нагрузки давать, и если нужно выполнять ресурсоемкие задачи с десятками терабайт.
Почитал про Spark. Он in-memory, а у меня 300 терабайт, я же не будут строить класстер с 300 теребайтамии оперативки?
А вот Impala может и подойдет. Как я понял там не MapReduce, но все поверх той же HDFS.
Нет конечно. Может быть и 10 гигабайт за 3 секунды, но скорее всего меньше. Скорей всего будут применяться агрегаты, индексы, партиции, желательно ручная сегментация. Вообщем я ищу MPP, но с функциями почти классической СУБД, разве что джоинов там будет мало. Архитектура базы будет звездочка или снежинка.
Поддержка SQL явный плюс.
Если честно, я что-то сомневаюсь, что MapReduce может обеспечить быстрый отклик.
Так же большой проблемой я считаю жестко заданый размер блока в 64 мегабайта, это слишком много, у Оракла максиму 32 килобайта. Т.е. что бы считать одну строчку нужно считать целых 64 мегабайта.
Идеальную систему я вообще вижу очень гибкой, и что бы можно быть и realtime нагрузки давать, и если нужно выполнять ресурсоемкие задачи с десятками терабайт.
Почитал про Spark. Он in-memory, а у меня 300 терабайт, я же не будут строить класстер с 300 теребайтамии оперативки?
А вот Impala может и подойдет. Как я понял там не MapReduce, но все поверх той же HDFS.
Нет конечно. Может быть и 10 гигабайт за 3 секунды, но скорее всего меньше. Скорей всего будут применяться агрегаты, индексы, партиции, желательно ручная сегментация.
Если мы говорим про кубы данных, то, во-первых, после агрегации их объём значительно уменьшится, а во-вторых, всегда можно разбить на нужное количество партиций (директорий на HDFS) и иметь прямой доступ к любому нужному срезу. А если взять ещё и колончатый формат хранения данных (например, Parquet для Impala или ORC для Hive 0.13), то при аналитичкских запросах ещё и файл будет читаться не полностью, а только нужными колонками.
Так же большой проблемой я считаю жестко заданый размер блока в 64 мегабайта, это слишком много, у Оракла максиму 32 килобайта.
Размер блока можно задавать, причём для каждого файла в отдельности. Только чем меньше размер блока, тем больше запросов нужно, чтобы вытянуть один файл. А каждый запрос — это неплохой такой overhead. Если вы рассчитываете, что вам придётся работать с блоками по 32 килобайта, то Hadoop — явно не тот вариант.
Почитал про Spark. Он in-memory, а у меня 300 терабайт, я же не будут строить класстер с 300 теребайтамии оперативки?
Spark — это вычислительный фреймворк, а не хранилище. Если у вас запрос на 10Гб, то они элементарно помещаются целиком в память и обрабатываются максимально эффективно. Кроме того, Spark оперирует над ленивыми коллекциями, так что к важдый конкретный момент времени на воркерах может вообще обрабатываться всего одна строчка данных.
А вот Impala может и подойдет. Как я понял там не MapReduce, но все поверх той же HDFS.
Да, там тоже свой механизм для распределённых вычислений.
Spark — это вычислительный фреймворк, а не хранилище. Если у вас запрос на 10Гб, то они элементарно помещаются целиком в память и обрабатываются максимально эффективно. Кроме того, Spark оперирует над ленивыми коллекциями, так что к важдый конкретный момент времени на воркерах может вообще обрабатываться всего одна строчка данных.
Понимаете, это все не то, мне не нужен in-memory. Мне нужен быстрый MPP, которые без оперативной памяти может за секунды ответить на запрос. Пока я вижу только Терадату, остальные все очень медленные. MapReduce Хадупа ужасно тормозной. Где Терадата ответить на запрос за мили секунды, Хадуп будет отвечать 15-20 секунд.
Проблема Хадупа как я вижу, это реализация MapReduce, он жутко проигрывает механизму Запрос-ПланЗапроса-выполение Терадате
Требование понятно. Мы пытались объяснить, что движки типа Spark и Impala не используют MapReduce, у них другие механизмы, гораздо более быстрые, чем традиционный MR. Хотя, возможно, они не подойдут для ваших задач.
Посмотрите еще HP Vertica — она гораздо старше, чем Hadoop, и популярна среди банков. И там есть MPP.
Но опять же, они позиционируют этот продукт для аналитику, а не OLTP (это к пожеланию «и что бы можно быть и realtime нагрузки давать,»).
Но опять же, они позиционируют этот продукт для аналитику, а не OLTP (это к пожеланию «и что бы можно быть и realtime нагрузки давать,»).
Посмотрите еще HP Vertica — она гораздо старше, чем Hadoop
Да нет, как раз по возрасту они ровесники — оба основаны в 2005 году. Другое дело, что Vertica — это изначально СУБД, а на Hadoop такие системы стали строить позже, а делать их production-ready — ещё позже.
Ок, посмотрю, только у меня не OLTP. OLTP это транзакции и 50% запись, 50% чтения. У меня 90 на 10 и не нужна транзакции, но и грязное чтение тоже не желательно!
-> В частности не realtime нагрузка.
Не совсем. В Hadoop От Cloudera входит, например, такой компонент как Flume Solr Sink. Он позволяет в момент получения Flume-ом события сразу его индексировать в Solr-е, и при достаточной пропорции размеров индексов и машин в кластере производительность может легко превышать сотни тысяч в секунду (если говорить про типичные события приложений, не документы).
Другой пример — Lily HBase Indexer. Он отправляет запись на индексацию в момент, когда она вставляется в HBase.
Ну и конечно же нельзя обойти вниманием Spark, который позволяет делать complex event prosessing в почти реальном времени (near-realtime). Однако Spark очень требователен к оперативной памяти. Ну, правда, это уже не к теме поиска в данных.
-> Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Если говорить про задачи YARN (например, MapReduce), то конечно получится. Для их одновременно-параллельного запуска достаточно (если грубо), чтобы 200*{amount_of_memory_required_for_any_task} < {total_amount_of_memory_in_cluster_devoted_for_yarn_tasks} и {amount_of_processor_cores_in_cluster} > 200
Просто цель описанной в статье задачи — произвести начальную выгрузку всех существующих логов приложений (а их десятки терабайт и миллиарды записей). И делать это через merge индексов — самый производительный способ. И конечно же большое количество файлов нет необходимости индексировать все параллельно — можно пачками.
Не совсем. В Hadoop От Cloudera входит, например, такой компонент как Flume Solr Sink. Он позволяет в момент получения Flume-ом события сразу его индексировать в Solr-е, и при достаточной пропорции размеров индексов и машин в кластере производительность может легко превышать сотни тысяч в секунду (если говорить про типичные события приложений, не документы).
Другой пример — Lily HBase Indexer. Он отправляет запись на индексацию в момент, когда она вставляется в HBase.
Ну и конечно же нельзя обойти вниманием Spark, который позволяет делать complex event prosessing в почти реальном времени (near-realtime). Однако Spark очень требователен к оперативной памяти. Ну, правда, это уже не к теме поиска в данных.
-> Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Если говорить про задачи YARN (например, MapReduce), то конечно получится. Для их одновременно-параллельного запуска достаточно (если грубо), чтобы 200*{amount_of_memory_required_for_any_task} < {total_amount_of_memory_in_cluster_devoted_for_yarn_tasks} и {amount_of_processor_cores_in_cluster} > 200
Просто цель описанной в статье задачи — произвести начальную выгрузку всех существующих логов приложений (а их десятки терабайт и миллиарды записей). И делать это через merge индексов — самый производительный способ. И конечно же большое количество файлов нет необходимости индексировать все параллельно — можно пачками.
А морда, чтобы логи смотреть какая? Свою написали или какая стандартная для Solr есть?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проиндексировать логи бизнес-приложений в Hadoop (SolrCloud)