| 1.1, А (??), 17:11, 29/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно, какие права у Hadoop в типичной системе, где он используется?
| | |
| |
| 2.2, Аноним (-), 18:13, 29/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Юзерские. Каких-то расширенных прав для нормальной работы он не требует.
| | |
|
| 1.3, Фокс Йовович (ok), 23:45, 29/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Что Hadoop, что Spark - кривое тормозное жручее глючное ненужно. Юзали у себя в конторе, чтобы обрабатывать много данных в реальном времени. На ~1000 евентов в секунду понадобилось аж четыре железных машины под спарк-слейвы. А те вещи, которые на обычном питоне делаются в одну строчку, в спарке иногда занимают экран кода и полдня дебага. В итоге выкинули нахрен спарк и переписали всё на обычном питоне с joblib. ВНЕЗАПНО теперь вся обработка данных спокойно умещается на одну машину. Нет спарка - нет проблемы. С апачьего кладбища у нас сейчас в ходу только Kafka (плюс Zookeeper). Как только найдём, чем эту кафку заменить, выкинем и её.
| | |
| |
| 2.4, ACCA (ok), 00:15, 30/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > ходу только Kafka (плюс Zookeeper). Как только найдём, чем эту кафку
> заменить, выкинем и её.
Расскажи поподробнее - Kafka выкинуть или-таки Zookeper? Если отскочить на кого-то вроде etcd, то может оба будут не нужны?
| | |
| 2.5, Аноним (-), 10:36, 30/11/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Индивидуально написанный код под обработку конкретной задачи грамотными программистами(не суперзвёздами) понимающими суть и бизнес-смыл решаемой задачи не ограниченными жёсткими временными рамками очень часто работает быстрее универсального решения, особенно для "нестандартных" задач.
А если по ваше решение разработать спецпроцессор, то можно ещё и энергозатраты снизить :)
| | |
| 2.6, Аноним (-), 13:29, 30/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Интересно... Продолжай.
Кашку можно заменить на RabbitMQ/ZMQ. Кластер кроликов я собирал, а вот про змк - не уверен, хоть это побыстрее будет. Можно конечно какафку и на Flume заменить, но MQ, как по мне - ближе всего по назначению.
| | |
| |
| 3.8, Фокс Йовович (ok), 18:09, 30/11/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Та хрен редьки не слаще, что жабка, что эрланг. ZMQ вообще не вариант, потому что нужна персистентность и durability. Алсо, сама архитектура кафки на удивление нравится. В отличие от всяких MQ, кафка практически ничего не делает! Она просто тупо получает бинарный блоб, дописывает в конец файла и хранит некоторое время. Можешь попросить у кафки все сообщения, начиная с определённого номера. Старые сообщения кафка через заданное время удаляет. Остальное её не касается. Как ты будешь читать сообщения, успеешь или нет их обработать - ей пофиг. Ну ладно, вру: есть ещё тупое API - потребитель может поставить отметку, до какого места он уже обработал сообщения. Но кафке всё равно пофиг - она их всё равно удалит через заданное время, отметка чисто дле тебя. Ну ещё кафка умеет всё это делать распределённо, когда одна очередь размазана по нескольким машинам, с избыточностью и параллелизмом. Больше она не делает НИЧЕГО. И это круто, прямо юникс-вей. После сраного AMQP - как небо и земля. Офигение вызывает лишь одно. На то, чтобы ничего не делать, у неё спокойно уходит два гига памяти. Жабка ж. Как только кто-нибудь перепишет на нормальном языке, так я первый в очередь.
| | |
| |
| 4.9, Аноним (-), 20:05, 30/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну да, линкедин рекомендует не мелочиться и таки выдать эти 64ГБ ОЗУ %). Я сам долго офигевал, но давал не более 8ГБ.
| | |
|
|
| 2.10, alex53 (ok), 21:20, 01/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
hadoop как бы предназначен для потоковой обработки ОЧЕНЬ большого объема данных. Если для обработки ваших данных потребовалось всего четыре сервера (у hdfs по умолчанию replication factor равен трем вообще-то, для надежности), значит вы использовали микроскоп для забивания гвоздей (или комбайн для уборки дачного огорода, если угодно).
| | |
| 2.11, SunXE (ok), 00:39, 12/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Смысл hadoop в том, чтобы размазанные по большему количеству серверов данные обрабатывать ярном или спарком на тех жа серверах на которых они находятся, а не выкачивать их перед обработкой. Это актуально когда данных сотни террабайт.
| | |
|
|
