https://opennet.dev/openforum/vsluhforumID3/109767.html В Apache Hadoop (http://hadoop.apache.org/), свободной платформе для организации распределённой обработки больших объёмов данных, выявлена (http://seclists.org/oss-sec/2016/q4/537) критическая уязвимость (CVE-2016-5393), позволяющая злоумышленнику, аутентифицированному в HDFS NameNode, выполнить произвольный код c правами сервиса HDFS. Проблема устранена в выпусках Apache Hadoop 2.7.3 и 2.6.5, которые были опубликованы в августе и октябре (во время релизов, явно не было упомянуто об исправлении уязвимости). Уязвимость вызвана (https://issues.apache.org/jira/browse/HADOOP-13434) отсутствием экранирования (https://github.com/apache/hadoop/pull/119/commits/76aa6639475e97b36bd9e1c04b575bd8d4a08849) спецсимволов при запуске команд через shell.<br><br>URL: http://seclists.org/oss-sec/2016/q4/537<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=45580<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#11 Sun, 11 Dec 2016 21:39:01 GMT Смысл hadoop в том, чтобы размазанные по большему количеству серверов данные обрабатывать ярном или спарком на тех жа серверах на которых они находятся, а не выкачивать их перед обработкой. Это актуально когда данных сотни террабайт. <br> https://opennet.dev/openforum/vsluhforumID3/109767.html#10 Thu, 01 Dec 2016 18:20:52 GMT <br>hadoop как бы предназначен для потоковой обработки ОЧЕНЬ большого объема данных. Если для обработки ваших данных потребовалось всего четыре сервера (у hdfs по умолчанию replication factor равен трем вообще-то, для надежности), значит вы использовали микроскоп для забивания гвоздей (или комбайн для уборки дачного огорода, если угодно).<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#9 Wed, 30 Nov 2016 17:05:40 GMT Ну да, линкедин рекомендует не мелочиться и таки выдать эти 64ГБ ОЗУ %). Я сам долго офигевал, но давал не более 8ГБ.<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#8 Wed, 30 Nov 2016 15:09:57 GMT Та хрен редьки не слаще, что жабка, что эрланг. ZMQ вообще не вариант, потому что нужна персистентность и durability. Алсо, сама архитектура кафки на удивление нравится. В отличие от всяких MQ, кафка практически ничего не делает! Она просто тупо получает бинарный блоб, дописывает в конец файла и хранит некоторое время. Можешь попросить у кафки все сообщения, начиная с определённого номера. Старые сообщения кафка через заданное время удаляет. Остальное её не касается. Как ты будешь читать сообщения, успеешь или нет их обработать - ей пофиг. Ну ладно, вру: есть ещё тупое API - потребитель может поставить отметку, до какого места он уже обработал сообщения. Но кафке всё равно пофиг - она их всё равно удалит через заданное время, отметка чисто дле тебя. Ну ещё кафка умеет всё это делать распределённо, когда одна очередь размазана по нескольким машинам, с избыточностью и параллелизмом. Больше она не делает НИЧЕГО. И это круто, прямо юникс-вей. После сраного AMQP - как небо и земля. Офигение вызывает лишь одно. На https://opennet.dev/openforum/vsluhforumID3/109767.html#7 Wed, 30 Nov 2016 14:41:55 GMT Zookeeper нужен кафке, нам он нафиг не упёрся.<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#6 Wed, 30 Nov 2016 10:29:32 GMT Интересно... Продолжай.<br>Кашку можно заменить на RabbitMQ/ZMQ. Кластер кроликов я собирал, а вот про змк - не уверен, хоть это побыстрее будет. Можно конечно какафку и на Flume заменить, но MQ, как по мне - ближе всего по назначению.<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#5 Wed, 30 Nov 2016 07:36:17 GMT Индивидуально написанный код под обработку конкретной задачи грамотными программистами(не суперзвёздами) понимающими суть и бизнес-смыл решаемой задачи не ограниченными жёсткими временными рамками очень часто работает быстрее универсального решения, особенно для "нестандартных" задач.<br><br>А если по ваше решение разработать спецпроцессор, то можно ещё и энергозатраты снизить :)<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#4 Tue, 29 Nov 2016 21:15:05 GMT &gt; ходу только Kafka (плюс Zookeeper). Как только найдём, чем эту кафку <br>&gt; заменить, выкинем и её.<br><br>Расскажи поподробнее - Kafka выкинуть или-таки Zookeper? Если отскочить на кого-то вроде etcd, то может оба будут не нужны?<br> https://opennet.dev/openforum/vsluhforumID3/109767.html#3 Tue, 29 Nov 2016 20:45:39 GMT Что Hadoop, что Spark - кривое тормозное жручее глючное ненужно. Юзали у себя в конторе, чтобы обрабатывать много данных в реальном времени. На ~1000 евентов в секунду понадобилось аж четыре железных машины под спарк-слейвы. А те вещи, которые на обычном питоне делаются в одну строчку, в спарке иногда занимают экран кода и полдня дебага. В итоге выкинули нахрен спарк и переписали всё на обычном питоне с joblib. ВНЕЗАПНО теперь вся обработка данных спокойно умещается на одну машину. Нет спарка - нет проблемы. С апачьего кладбища у нас сейчас в ходу только Kafka (плюс Zookeeper). Как только найдём, чем эту кафку заменить, выкинем и её.<br>