Pull to refresh

Comments 13

можно офтоп, а зачем нужна такая здоровая шапка в докладе номер 5?

а теперь не офтоп, присутствовал на докладе номер 6, но не успел задать вопрос, а автор в курсе что есть статистика и анализ данных?

еще не офтоп, первый пленарный доклад просто крутота, на остальных кроме 1 и 6 не попал, но первый полностью компенсирует провал номера 6 -)
Зачем у него на голове грелка для чайника?
Чтобы голова не остыла @ Snatch
Я — номер 6. В чём мой провал-то? В том, что я успешно решил сложную задачу простыми методами?
Может конечно с точки зрения бизнеса это и круто, просто быстро решить задачу, но хайлоад не о бизнесе. Многие ожидали на вашем докладе услышать что нибудь инновационное о повышение ctr рассылки, а получили шаманство. Безусловно шаманство бывает оправданно, скажем в стартапе где просто нет другого выхода как применять шаманство, тк нету даже истории рассылок и откликов.

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

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

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

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

К тому же появились бы новая технология, которую сложнее было бы понять обычным разработчикам, а не единичным «прекрасным аналитикам». Для компании это дополнительные риски, а результат, напомню, был бы тот же (при условии, что я не поставил бы ещё более сложную задачу).

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

Мой доклад, наверное, не выглядит столь [бесполезно] крутым, зато может на самом деле пригодиться. Проблема, о которой я рассказал, и правда достаточно новая, и правда мало кто понимает, что на самом деле нужно в случае её реализации делать.

Я рассказал о сути проблемы, её истоках, базовых триггерах, которые к ней приводят. Дал наглядный и простой пример того, как можно её предотвратить. Т.е. комплексно осветил вопрос, весьма актуальный для многих компаний.

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


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

но отличие такого подхода (даже если не брать в рассмотрение то что результат скорее всего был бы лучше) в том, что он имеет под собой теоретический фундамент

причина по которой я, извиняюсь за выражение, наехал на ваш доклад в том, что если бы это был доклад стартапа, то это было бы круто, типа какие молодцы не потратили ресурсов на найм математика и без истории рассылок вот так выкрутились, но когда это такая компания как баду, где есть и аналитики и история, и в такой задаче это не юзали, ну как то печалит
по поводу вашего Хадуп кластера — первый раз вижу NameNode которая значительно уступает DataNode по параметрам. Довольно странное решение — чем обосновывали?
Отвечаю как человек непосредственно работающий с Hadoop в Badoo. Мы принципиально не хотели держать NN и JT на одной машине с DN и TT. Это вызвано принципиально разными требованиями и к железу и нагрузке между «мастерами» и «слейвами».

NN это основная точка отказа Hadoop кластера, потому стоило подумать о том, что она должна быть надежной и легкозамещаемой. Потому, машинка стоит из старых, проверенных, диски в рейдах и нагрузки никакой не испытывает,

В то же время ставить весьма приличный сервер под абсоютно нулевую нагрузку — пустая трата ресурсов.

Вот такое обоснование.
под абсоютно нулевую нагрузку

ну не скажите, обычно NN очень и очень загруженый сервер, в первую очередь по CPU и RAM, тот же хортонворкс рекомендует 16 CPU

но главное что бы вас все устраивало — это главный критерий :)
NN RAM поглощает пропорционально числу объектов файловой системы и числу блоков в них. В нашем случае на 400К объектов NN heap size стоит 1.5Гб. Простое деление показывает 4Кб на файл — мне кажется вполне приличное соотношение.

Загруженность по CPU возникает в тот момент, когда много разных читателей/писателей активно взаимодействует с файлами. Или при очень большом количестве файлов.

Я, к сожалению, не знаю чем руководствовались хортонворкс, когда давали такие рекомендации и какой профиль нагрузки они ожидали.

Но, да, при нашем профиле нагрузки сервер с NN сильно недоиспользован.
Ну, и вот непосредственно цифры с системы
Total dirs: 11236
Total files: 378846
Total blocks (validated): 633558 (avg. block size 49200604 B)
Average block replication: 3.0
Автоматический шардинг из коробки вроде еще и в ElasticSearch есть
Почему так сильно прыгает качество звука у докладов? До пятого приходится уши во всю напрягать.
Sign up to leave a comment.