Образованные и грамотные люди редко бывают лицемерными? Да неужели? У Вас статистические данные неверные. Хотя, впрочем, Ваша манера общаться, переходить на личности и писать «дешего» вместо «дешево» наводит на мысль, что слова «образование» и «грамотность» к Вам совершенно не относятся. На этом дискуссия завершается, не вижу смысла спорить с оппонентом такого уровня.
А Вы никогда не «приукрашивали» себя? Любой человек хоть раз в жизни выставлял себя в лучшем свете, используя для этого ложь разной степени тяжести. Хотя подобные манипуляции сознанием и не вызывают симпатий, речь все же не о попытках Дурова сформировать свой публичный образ, а о том, насколько этот образ расходится с реальностью. Скажу уж совсем по-простому: не стоит верить публичным заявлениям подобного рода. Их не стоит инвертировать, но и не стоит им верить. И — еще раз повторю для невнимательных — «в реальности Дуров может быть совсем другим».
Публичные люди имеют определенный образ, который далеко не всегда совпадает с реальностью. Я работал с пиарщиками много лет назад (разрабатывали сайт для них), поэтому в курсе некоторых вещей. Скажу наверное непопулярную вещь, но в реальности Дуров может быть совсем другим и придерживается совсем иных взглядов. Это как в политике — вчера был до мозга костей «левый», а завтра уже ярый «правый». Показной либерализм и заявления в духе «я продал долю потому что не хочу выдавать данные пользователей» — это настолько явная «показуха», что даже странно становится, как на нее «ведутся». Кстати, одна из причин возникновения паразитирующих правительств в любой стране — это готовность простых граждан легко верить в публичные образы политиков и социальных институтов. P.S. Я не утверждаю, что Дуров «плохой» — я утверждаю, что не факт, что он «хороший».
Ну не все так печально, есть же ротация кадров (из других компаний), различные коэффициенты «полезности» и «производительности» для каждого сотрудника. Плюс само понятие «компетентность» отражает лишь способность данного сотрудника справляться с определенным наобором задач. Но жизнь — штука изменчивая, сегодня нужен блог на PHP, завтра файлообменник на Go. Критерии компетентности в данных случаях будут очень разными.
Аж дважды «отказались по неизвестным причинам». Рискну предположить, что не все так радужно и некоторые вещи действительно могли ухудшать бизнес в долгосрочной перспективе. Пример из несколько иной области: обвесьте свои сайты блоками Adsense и Direct, и вы получите мощный прирост дохода на некоторое время — ровно до тех пор, пока сайт перестанет посещать постоянная аудитория.
Спасибо за комментарий. VPN у нас на сервере нет. Есть обычный LAMP + Postgres + MySQL + Python + Ruby + Nginx. Естественно, есть доступ по SSH, но выше вроде написали что SSH не затрагивает данная уязвимость. В общем, у нас обычный сервер для хостинга веб-сайтов. Нужно ли обновляться прямо сейчас?
Объясните неспециалисту — этот баг касается только https веб-серверов? Если у меня сайт, не использующий https протокол — нужно ли мне обновляться прямо сейчас? В данный момент у нас активна рекламная и PR кампания, и отключать сайт ну очень уж не хотелось бы (прямые потери денег). Уязвимы ли еще какие-то службы помимо веб-сервера с https?
Я бы все-таки четко разграничил алгоритм (MapReduce) и инструмент (Hadoop). На сравнительно небольших данных Хадуп оказывается далеко не самым быстрым MR-фреймворком — есть целая вереница всяческих Спарков, ДПарков, Диско и прочих, которые запросто могут оказаться быстрее (и съесть при этом меньше компьютерных ресурсов, что немаловажно). Хотя бы даже «классика» — bashreduce.
Я говорил много раз и не устану повторять, что Хадуп — отличный инструмент для действительно больших данных (скажем, от нескольких терабайт). На небольших данных иногда проще\быстрее\дешевле запустить какой-нибудь другой MR-фреймворк или вообще применить другой алгоритм.
Вопрос к знатокам — насколько быстрый этот архиватор, если брать с индексом? К примеру, если заархивировано 5 миллионов мелких файлов, как быстро можно извлечь 1-2 случайных? Гуглил бенчмарки, ничего не нашел.
Все как раз наоборот — люди пытаются на Феррари возить картошку, хотя явно дешевле ее загрузить в Жигули. Об этом я написал черным по белому — 32Гб это очень мало, даже single-node инсталляция того же Постгреса обработала бы данные за сравнимое время. Смысл городить Хадуп?
Вы, кстати, употребили слово «идеологически». Видимо Вам очень важна «идеология», раз Вы принципиально «за» одно решение и «против» других? Дело Ваше, мне же гораздо важнее удобство решения и его стоимость для бизнеса. Кстати, посмотрел Ваш профиль — видимо Вы фанат Хадупа, и Вам «из-за леса деревьев не видно».
Я не собираюсь ни с кем спорить и никому ничего доказывать, мой первый комментарий плюсанули 3 человека — следовательно, не я один так думаю. Простите, больше не вижу смысла продолжать дискуссию.
Вряд ли это будет хит, у нас всего лишь 2 терабайта данных суммарно и порядка миллиарда «строк» (в терминах SQL) на выходе — поэтому на фоне объемов Google или Facebook не будет ничего интересного. Могу только сообщить, что стоимость разовой обработки таких данных (а там целый конвейер и много архивирования\разархивирования) — порядка 70-100 руб., если посчитать в ценах Digital Ocean или Amazon. Используемые\использовавшиеся инструменты я примерно описал в первом комментарии, если что-то интересно под конкретную задачу — спрашивайте, с удовольствием поделюсь опытом.
1. Медленный по сравнению с однопоточными скриптами, Spark'ом или хотя бы минимально настроенным Postgres'ом. Это — если мы берем сравнительно небольшие данные (а 32Гб — это небольшой объем).
2. Не так важно, как это называется, как важно то, как это работает. А работает это — лично по моему мнению, да и не только по моему — довольно неудобно.
3. О том и речь — ситуации разные.
Вы наверное не полностью прочитали мой комментарий. Я писал, что Хадуп — это один из немногих инструментов, которые в принципе позволят обработать терабайты данных. Но для небольших объемов данных существует множество других инструментов, которые оказываются зачастую удобнее, проще, быстрее и в итоге дешевле.
Опять соглашусь с Вами и плюсану Ваш комментарий, если хватит кармы. Но есть одно «но» — Hadoop, а тем более Pig, абсолютно не предназначены для быстрой обработки данных. У автора поста на все ушло 15 минут — это довольно много. Тот же Spark, например, гораздо больше подходит для быстрой обработки. Стало даже классикой жанра сравнивать скорость Хадупа и Спарка и показывать, что Спарк может быть быстрее в сотни раз. Или какая-нибудь MemSQL, если данных не очень много. В общем, основная моя мысль — Hadoop это инструмент для обработки огромных объемов данных на сотнях машин, и больше. Задачи меньшего масштаба можно — зачастую — решить более привычными и удобными инструментами за меньшее время и деньги. Не то чтобы Хадуп вообще не подходит для мелких данных — конечно подходит — просто вопрос скорее оптимизации процессов, нежели чем решающего выбора инструмента.
… и муки отладки в довесок =) Нет, правда, мне есть с чем сравнить — стандартные питоновые traceback'и из Disco отличаются невероятной наглядностью и лаконичностью. Установка — дело не 30, а 10 минут. Вот прямо сейчас с ходу могу припомнить, что, к примеру, файловую систему на Disco форматировать не нужно. Это же очевидно — если человек только-только установил DDFS\HDFS, неужели нельзя отформатировать все автоматически? Вот эта избыточность в логах, необходимость лишних действий — это все, по ощущениям, очень близко к Java-way, где любят создавать классы на каждый чих. Только не подумайте, что я холивора ради это написал — нет конечно, на Java написаны многие отличные продукты, да и в целом язык очень хороший даже сегодня, несмотря на появления всяких модных штук типа Go. Просто Хадуп действительно монструозен, просто сравните с Disco ;)
Конечно, если нужно 100 нод, то здесь надо брать специализированные решения. Постгрес на 100 нод даже представлять страшно =) С другой стороны, пара-тройка серверов запросто способна обрабатывать те же 100 Гб значительно быстрее, чем за 15 минут. Про выборки и эксперименты… Наверное это дело субъективное, но в общем-то меня действительно сбивает с толку синтаксис Pig, да и отладка всего этого дела довольно мучительна. А Вы не смотрели в сторону других решений? Cassandra, к примеру, тоже использует подмножество SQL, и работать с ней (лично по моим ощущениям) оказалось очень приятно, просто и понятно. Или, к примеру Hive (у него синтаксис, насколько я помню, шире чем у Pig и даже Impala).
Не совсем понял, зачем здесь строить большие кластеры. Мы же не играем в игру «построй кластер», а решаем вполне конкретную задачу. 32Гб это очень, очень мало. Хватит одного мощного сервера. Да что там, такой объем данных даже в RAM поместиться может. О том и был мой комментарий — Хадуп для действительно больших данных и зоопарков из нод, в случае, если же big data не очень уж «big» — то эффективнее в большинстве случаев использовать что-то другое. Я просто по роду деятельности часто сталкиваюсь с тем, что люди лепят Хадуп где только ни попадя, разворачивая лишние ноды или просто используя single-node инсталляцию (неэффективную, Вы правы). Вот в этом и была основная мысль — летать в соседний магазин на вертолете конечно круто и трендово, но доехать на машине будет проще, быстрее и дешевле.
Я говорил много раз и не устану повторять, что Хадуп — отличный инструмент для действительно больших данных (скажем, от нескольких терабайт). На небольших данных иногда проще\быстрее\дешевле запустить какой-нибудь другой MR-фреймворк или вообще применить другой алгоритм.
Вы, кстати, употребили слово «идеологически». Видимо Вам очень важна «идеология», раз Вы принципиально «за» одно решение и «против» других? Дело Ваше, мне же гораздо важнее удобство решения и его стоимость для бизнеса. Кстати, посмотрел Ваш профиль — видимо Вы фанат Хадупа, и Вам «из-за леса деревьев не видно».
Я не собираюсь ни с кем спорить и никому ничего доказывать, мой первый комментарий плюсанули 3 человека — следовательно, не я один так думаю. Простите, больше не вижу смысла продолжать дискуссию.
2. Не так важно, как это называется, как важно то, как это работает. А работает это — лично по моему мнению, да и не только по моему — довольно неудобно.
3. О том и речь — ситуации разные.
Вы наверное не полностью прочитали мой комментарий. Я писал, что Хадуп — это один из немногих инструментов, которые в принципе позволят обработать терабайты данных. Но для небольших объемов данных существует множество других инструментов, которые оказываются зачастую удобнее, проще, быстрее и в итоге дешевле.