Господа, а кто использует Hue для спарка?

Вообще для sql использовать hive приятней. А ноутбуки я не настраивал, есть смысл офф доку по интеграцию ноутбука и спарка почитать, там вполне возможно нужно настраивать

Хортон в последнем апдейте заявил, что Hue c HDP 3.0 не будет поддерживаться

https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.1/bk_release-notes/content/deprecated_items.html

Хортон в последнем апдейте заявил, что Hue c HDP 3.0 не будет поддерживаться

а что вместо него?

Consider Ambari Views as the alternative (c)

а вместо флюма?

видимо в какой то момент в амбари появится view для Oozie

NiFi

Точнее даже не просто NiFi, а отдельный кластер HDF

Привет всем! Есть вопрос по hdfs, насколько быстрее писать в кластер хадупа? И быстрее ли это чем писать в монго? Нужно понимание

В монго я пишу голые данные, без доп индексов, кроме id

Привет всем! Есть вопрос по hdfs, насколько быстрее писать в кластер хадупа? И быстрее ли это чем писать в монго? Нужно понимание

Насколько быстрее чем что?

HDFS достаточно нерасторопна

Неправильно сформулировал

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

быстрее всего в /dev/null писать, что дальше с данными предполагается делать то? странно выбирать средство только по одному критерию...

Обработка на кластере спарка, построение моделей машинного обучения

А так же чтение и вывод в веб приложение голых данных

может оказаться, что быстрее всего писать данные куда нибудь в kafka, а потом непосредственно выгребать их и обрабатывать из spark. но не зная откуда приходят данные, как часто, какими пачками, трудно что то определенное сказать... mongodb ведь не просто так изначально появилась?

Просто так, я делал прототип. И не думал, что данных будет столько. Чтобы понимать, база данных растет на 20гб каждый день.

И это еще где-то 1/15 мощности

а насчет вывода данных в веб-приложение - если подразумевается куча adhoc запросов, оперирующих небольшим количеством данных, с произвольной фильтрацией, то ходить за ними в hdfs не самая лучшая идея...

Как тогда сделать правильную архитектуру? Выбросить просто старые данные я тоже не могу, потому, что может потребоваться их показать на вебе

не зная откуда приходят данные, как часто, какими пачками - данные приходят с парсеров, которые парсят статистику с различных ресурсов, этот процесс постоянный. Какими пачками не знаю, но не очень большими, за день набегает суммарно 20 гб обработанной информации.

сложно сказать, не видя всей картины... тут уже скорее речь пойдет о каких то tradeoff'ах между мощностью доступного железа, потоком данных, архитектурой, возможностями системы. данные конечно при записи в hdfs можно пожать, если писать в orc/parquet, чем больше будет пачка данных тем лучше. все описанное немного напоминает идеальный случай для lambda архитектуры, но не уверен до конца. тем более что она не отвечает на вопрос про точный технологический стек

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

а даннные нативно в json формате? почему именно монга? возможно, стоить рассмотреть cassandra например? у нее с записью все лучше чем у монги, но хватает других моментов, которые могут не подойти

Монга была выбрана для прототипа, т.к. я ее лучше знаю.

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

она не решабельная; можешь попробовать тайгер (если не пробовал) но он создает иллюзию решения

С кассандрой работал меньше, да и то, на одном проекте она была в виде кеш хранилища.

какой продакшн размер средний банки будет?

Средняя банка это что? Поясните, если можно =)

Типа характеристики ноды ?

Сейчас у меня под прототип 200 тб хранилище, одна тачка

В случае расширения - их закупят.

размер БД да)

мне кажется монга тут не вариант)

200 тб по идее. Но никто не посчитал ничего, заставили быстро писать прототип

В разрезе чего тебе парсинг нужно делать. Если есть какая-то потоковость данных простым решением будет использовать спарк джобу которая агрегирует какой-то поток из MQ ( сам кладешь в кафку ) , делает первичную обработку, и сохранет в протобаф партицированный в нужном расширении.

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

Это если предполгается какой-то etl по этим данным сложный относительно

Ну и всё не сильно онлайново

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

Ну тут размер пачки не определен, поэтому ин мемори , как мне кажется не подходит

придёт не 20 гигов , а 100 и всё умрет

ну вдруг кластер есть )

ну или таки агрегировать сразу в redis

от задачи зависит

Ну сейчас данные явно не приходят пачкой, а потоково =)

раз потоково - вполне можно in-memory, и сбрасывать в другое хранилище по какому-то эмпирически подобранному правилу...

Ну сейчас данные явно не приходят пачкой, а потоково =)

а поток на чём строится?

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

надо заложить масштабирование... kafka или rabbitmq в помощь, как первый приемник, и далее уже куда-то еще

А что случится, если я переполню kaffkу?

Данные будут поступать быстрее, чем их будут разгребать

А что случится, если я переполню kaffkу?

не переполнишь

у нее всё конфигурируется, сколько сообщений хранить, сколько дней, какой максимальный объекм

она активно персистит данные на диск

Понятно, пойду тогда изучать. Спасибо

You are welcome !

Раз уж разговор про очереди зашел

Начну с каффки, а дальше подумаю, что еще можно сделать

какую очередь лучше под 1.6.3 использовать, если требования - это в первую очередь стабильность работы

под спарк 1.6.3

RabbitMQ емнип под 2.0+

Данные будут поступать быстрее, чем их будут разгребать

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

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

https://themodernwomendotorg.files.wordpress.com/2016/10/maxresdefault.jpg?w=1200

Я и не собирался :)) я сразу понял, что с локом на всю базу засчет одного пишущего треда я далеко не уеду

какую очередь лучше под 1.6.3 использовать, если требования - это в первую очередь стабильность работы

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

не

мы используем 1.6.3 и планируем использовать брокер

вопрос в том, что под 2.0 рабочих вариантов достаточно много, а вот под 1.6.3 я только кафку видел

остальное либо не тестировалось на 1.6х, либо еще что нибудь

вопрос в том, что под 2.0 рабочих вариантов достаточно много, а вот под 1.6.3 я только кафку видел

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

спасибо

спасибо

но это субъективно. Поэтому я бы провёл бы исследования.

да, само собой тестировать будем :) просто пытаюсь понять, с чего начинать

видимо с кафки

Некоторые проблемы были с кафка продьюсером в 1.3 версии спарка , валилось соединение если я продьюсер делал один на экзекьютор, поэтому продьюсер пер партишн пришлось сделать

Кстати, появился вопрос. Если использовать кафку с монгой, то код консумера придётся писать вручную и приляпывать в Кафке приложение, которое будет ее в монгу разгребать?

Кстати, появился вопрос. Если использовать кафку с монгой, то код консумера придётся писать вручную и приляпывать в Кафке приложение, которое будет ее в монгу разгребать?

есть akka-streams

но проще на чём-нибудь типа спарка сделать

Ну, т.е это отдельное приложение, которое ее будет перекладывать.

Akka-streams - это никак не связано с фреймворком для скалы?:)

)) связано

Я хотел написать kafka-streams, но akka-streams как вариант

Понятно. Короче с таким количеством систем походу все придётся упаковывать в докер

да; хорошая практика

я так и делаю

И нанимать админа

докеры сам мождешь

не сложно при должной практике

Как мониторить все образы на куче нод?

ранчер к примеру какой использовать

самое простое

http://rancher.com/

посложнее это дсос и кубернетес

кубернетес не предлагает инбилт средств для натягивания сетки между тачками