company_banner

Видео докладов Badoo с конференции Highload 2014

    Осенью мы выступали с докладами на одной из лучших технических конференций Highload 2014 и сейчас с удовольствием делимся с вами видео докладов. Вы можете задавать вопросы в комменариях и наши спикеры и остальные эксперты обязательно на них ответят.

    1. «Sharding — patterns & antipatterns».
    Доклад Алексея Рыбака (Badoo) и Константина kostja Осипова (Mail.ru).




    2. «Использование Hadoop в Badoo», доклад Валерия Старынина.




    3. «Приём платежей в Badoo — взгляд изнутри», доклад Анатолия GremniX Панова.




    4. "«Облако в Badoo год спустя — работа над ошибками», доклад Юрия youROCK Насретдинова.




    5. "«Docker & Puppet — как их скрестить и надо ли вам это», доклад Антона banuchka Турецкого.




    6. «Выбраться из спама — как повысить CTR рассылки», доклад Андрея Une4ga Саса.

    Краткое содержание первых 7 минут, которых нет на видео:
    «Данный доклад – о новом типе проблем с доставляемостью почты, с которым в последнее время часто сталкиваются даже те компании, которые делают емейл-рассылки весьма и весьма качественно. В докладе будет рассказано о том, с помощью какого универсального „рецепта“ данная проблема была предотвращена в Badoo.

    У вас хорошие традиционные показатели (% жалоб, % несуществующих адресов), вы делаете double opt-in, обрабатываете FBL и баунсы, имеете правильную конфигурацию DNS (PTR, SPF) и DKIM?

    Теперь это ничего не гарантирует, ваша рассылка всё равно может начать попадать в спам на крупнейших почтовиках, особенно зарубежных. Дело в том, что большие почтовики давно смотрят и на показатели взаимодействия ваших подписчиков с письмами, и клики на кнопку „Это спам“ — лишь одна из метрик.

    Какие же новые параметры отслеживаются почтовиками с целью принятия решения о том, куда положить ваше письмо? Ответ можно получить, заглянув в postmaster-интерфейсы Mail.ru и „Яндекса“. Теперь важны проценты открытий и кликов в письмах, которые наравне с известными ранее параметрами отслеживаются и, очевидно, принимаются во внимание.

    Как с этим жить, что делать — ответы на эти вопросы есть в докладе».


    Badoo
    Big Dating

    Comments 13

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

              Only users with full accounts can post comments. Log in, please.