Перевод статьи: Experimenters Rules of Thumb

Владельцы веб-порталов, от самых маленьких, до таких крупных, как Amazon, Facebook, Google, LinkedIn, Microsoft и Yahoo, пытаются улучшить свой сайты, оптимизируя различные метрики, начиная с количества повторных использований до проведенного у них времени и выручки. Нас привлекали к проведению тысячи экспериментов на Amazon, Booking.com, LinkedIn и Microsoft, и хотим поделиться семью эмпирическими правилами, которые мы вывели из этих экспериментов и их результатов. Мы верим, что эти правила широко применимы как при оптимизации веба, так и в ходе анализа за пределами контрольных экспериментов. Хотя бывают исключения.

Чтобы сделать эти правила более весомыми, мы приведём реальные примеры из нашей работы, причем большинство из них будут опубликованы впервые. Некоторые правила озвучивались и ранее (например, «Скорость имеет значение»), но мы дополнили их допущениями, которые можно использовать при проектировании экспериментов, и делимся дополнительными примерами, которые улучшили наше понимание того, где скорость особенно важна, а в каких областях веб-страниц она не критична.

Эта статья преследует две цели.

Первая: научить экспериментаторов правилам хорошего тона, которые помогут оптимизировать сайты.

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

Sherlock by ThatsWhatSheSayd

Чтобы стать великим сыщиком, Шерлоку Холмсу было достаточно замечать то, чего не видели остальные, в вещах, которые находились у всех на виду. Мне кажется, что этим качеством должен обладать и каждый специалист по машинному обучению. Но тема Feature Engineering’а зачастую изучается в курсах по машинному обучению и анализу данных вскользь. В этом материале я хочу поделиться своим опытом обработки признаков с начинающими датасаентистами. Надеюсь, это поможет им быстрее достичь успеха в решении первых задач. Оговорюсь сразу, что в рамках этой части будут рассмотрены концептуальные методы обработки. Практическую часть по этому материалу совсем скоро опубликует моя коллега Osina_Anya.

Один из популярных источников данных для машинного обучения — логи. Практически в любой строчке лога есть время, а если это web-сервис, то там будут IP и UserAgent. Рассмотрим, какие признаки можно извлечь из этих данных.

Как всем известно, количество данных в мире растёт, собирать и обрабатывать поток информации становится всё сложнее. Для этого служит популярное решение Hadoop c идеей упрощения методов разработки и отладки многопоточных приложений, использующее парадигму MapReduce. Эта парадигма не всегда удачно справляется со своими задачами, и через некоторое время появляется «надстройка» над Hadoop: Apache Tez с парадигмой DAG. Под появление Tez подстраивается и HDFS-SQL-обработчик Hive. Но не всегда новое лучше старого. В большинстве случаев HiveOnTez значительно быстрее HiveOnMapReduce, но некоторые подводные камни могут сильно повлиять на производительность вашего решения. Здесь я хочу рассказать, с какими нюансами столкнулся. Надеюсь, это поможет вам ускорить ETL или другой Hadoop UseCase.

Первая часть моих приключений с Tibero тут

Для тестирования совместимости Tibero c Oracle я решил проверить, будут ли работать на нем любимые мною PL/SQL библиотеки, а именно:
https://github.com/mortenbra/alexandria-plsql-utils/
Тестирование началось с JSON_UTIL_PKG. Очень полезная функция позволяющая быстро генерировать JSON-ответ.

Недавно в моей жизни закончился период поиска новой работы. На одном из собеседований этого периода я узнал, что в мире появилась новая СУБД, разработчики которой обещают вот-вот затмить собой Oracle всемогущий. Заманчивое обещание тут же породило у меня желание попробовать это чудо заморской техники. Речь шла о корейской СУБД Tibero.