Знакомьтесь, Олег Анастасьев — ведущий разработчик Одноклассников, спикер на конференциях по Java и Cassandra, эксперт в области распределенных и отказоустойчивых систем. С Олегом мы поговорили о следующем:

• Что не так с термином «архитектор»
• Зачем Одноклассникам 11 000 серверов
• Как выглядят учения по ликвидации аварий
• Что такое «Правило большого З»
• Как в Одноклассниках используют Cassandra
• В чём для современной компании сложности с размещением кода в Open Source
• Как в Одноклассниках работают с Big Data

Как всегда, под катом — полная текстовая расшифровка беседы.

Привет, Хабр! Меня зовут Александр Крашенинников, я руковожу DataTeam в Badoo. Сегодня я поделюсь с вами простой и элегантной утилитой для распределённого выполнения команд в стиле xargs, а заодно расскажу историю её возникновения.

Наш отдел BI работает с объёмами данных, для обработки которых требуются ресурсы более чем одной машины. В наших процессах ETL (Extract Transform Load) в ход идут привычные миру Big Data распределённые системы Hadoop и Spark в связке с OLAP-базой Exasol. Использование этих инструментов позволяет нам горизонтально масштабироваться как по дисковому пространству, так и по CPU/ RAM.

Безусловно, в наших процессах ETL существуют не только тяжеловесные задачи на кластере, но и машинерия попроще. Широкий пласт задач решается одиночными PHP/ Python-скриптами без привлечения гигабайтов оперативной памяти и дюжины жёстких дисков. Но в один прекрасный день нам потребовалось адаптировать одну CPU-bound задачу для выполнения в 250 параллельных инстансов. Настала пора маленькому Python-скрипту покинуть пределы родного хоста и устремиться в большой кластер!

Привет, друзья! Я тут проанализировал 2ТБ кода и получил самые популярные слова в разных языках программирования. Результаты можно посмотреть в виде облаков тегов и простым списком:


Сайт находится здесь, а его исходники можно почитать на гитхабе.

Под катом описано в деталях о том как собирались данные, как строился сайт и как укладывались облака. И немножко наблюдений.

Приятного чтения!

На днях произошло, в какой-то степени, знаменательное событие и одна из крупнейших компаний России заявила о том что теперь публикует открытые данные на своем сайте. Этой компанией является Сбербанк и соответствующий раздел на их сайте. Открытие раздела удостоилось пресс-релиза на их сайте и о нем, как о важном событии, написали десятки финансовых и не финансовых СМИ.

Действительно ли Сбербанк совершил нечто невероятное? Рядовое ли это явление и является ли то что сделал Сбербанк сейчас открытыми данными? Вот о чем далее пойдет речь.

В качестве вступления

Прежде чем продолжить о Сбербанке, давайте вернемся к термину открытые данные.

Мы решили описать простой и проверенный путь для тех, кто хочет внедрить аналитическую СУБД ClickHouse своими силами или просто испробовать ClickHouse на собственных данных. Именно этот путь прошли мы сами в новостном агрегаторе СМИ2 и добились впечатляющих результатов.

В предисловии статьи — небольшой рассказ о наших попытках внедрить Druid и InfluxDB. Почему после успешного запуска ClickHouse мы смогли отказаться от использования InfiniDB и Cassandra.

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



Очень скоро мы поняли, что тут мог бы здорово помочь общий высокоуровневый язык запросов, который бы предоставлял единообразный доступ к уже имеющимся системам, а также избавлял от необходимости заново реализовывать типовые абстракции на низкоуровневых примитивах, принятых в этих системах. Так началась разработка Yandex Query Language (YQL) — универсального декларативного языка запросов к системам хранения и обработки данных. (Сразу скажу, что мы знаем, что это уже не первая штука в мире, которая называется YQL, но мы решили, что это делу не мешает, и оставили название.)

В преддверии нашей встречи, которая будет посвящена инфраструктуре Яндекса, мы решили рассказать о YQL читателям Хабрахабра.

В течение последних шести лет в Яндексе идет работа над системой под кодовым называнием YT (по-русски мы называем её «Ыть»). Это основная платформа для хранения и обработки больших объемов данных — мы уже о ней рассказывали на YaC 2013. С тех пор она продолжала развиваться. Сегодня я расскажу о том, с чего началась разработка YT, что нового в ней появилось и что ещё мы планируем сделать в ближайшее время.



Кстати, 15 октября в офисе Яндекса мы расскажем не только о YT, но и о других наших инфраструктурных технологиях: Media Storage, Yandex Query Language и ClickHouse. На встрече мы раскроем тайну — расскажем, сколько же в Яндексе MapReduce-систем.

Какую задачу мы решаем?

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

Идея для написания этой статьи возникла прошлым летом, когда я слушал доклад на конференции BigData по нейронным сетям. Лектор «посыпал» слушателей непривычными словечками «нейрон», «обучающая выборка», «тренировать модель»… «Ничего не понял — пора в менеджеры», — подумал я. Но недавно тема нейронных сетей все же коснулась моей работы и я решил на простом примере показать, как использовать этот инструмент на языке JavaScript.

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

Сегодня внутренняя разработка компании Яндекс — аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0.



ClickHouse позволяет выполнять аналитические запросы в интерактивном режиме по данным, обновляемым в реальном времени. Система способна масштабироваться до десятков триллионов записей и петабайт хранимых данных. Использование ClickHouse открывает возможности, которые раньше было даже трудно представить: вы можете сохранять весь поток данных без предварительной агрегации и быстро получать отчёты в любых разрезах. ClickHouse разработан в Яндексе для задач Яндекс.Метрики — второй по величине системы веб-аналитики в мире.

В этой статье мы расскажем, как и для чего ClickHouse появился в Яндексе и что он умеет; сравним его с другими системами и покажем, как его поднять у себя с минимальными усилиями.

Однажды, мне стало интересно: насколько статьи на Хабре связаны между собой? Поэтому сегодня мы займемся исследованием связности статей, и конечно не только посчитаем численные метрики, но и увидим картину целиком.

(это не просто картинка для привлечения внимания, а граф цитирования статей внутри Хабрахабра, где размер вершин определяется числом входящих рёбер, i.e., "количеством цитат внутри Хабра")

Началось всё с того, что в комментариях к статье про Хабра-граф и карму Tiberius и Loriowar озвучили идею, фактически витающую в воздухе: а почему бы не взглянуть на граф цитирования статьёй внутри самого Хабра?

Вы спрашивали? Мы отвечаем. Для того чтобы рассказ не был размахиванием рук, конкретизируем разбираемые вопросы:

• Q₁: Как выглядит граф цитирования Хабрахабра и какие в нём хабы (hubs and authorities)?

  
  

• Q₂: Насколько связным является сообщество (граф цитирования) и какие в нём кластеры?

  
  
• Q₃: Как изменится граф, если из него убрать самоцитирование?

Под катом трафик. Все картинки кликабельны.

В новом выпуске «Черной археологии датамайнинга» мы немного поиграемся в шпионов. Увидим, что может узнать обычный Data Specialist на основе открытых в сети данных.

Всё началось со статьи на хабре, о том, что некий анонимный хакер делился слитыми в сеть данными агентов ФБР. Я получил эти данные, и стал смотреть, что с ними можно сделать? В данных есть только фамилия, имя, и служебные мейлы и телефон – немного информации.



Получив эти данные, я увидел, что они заканчиваются буквой J. То есть, датасет не полон. Интресено, каков его полный размер? Чтобы узнать его, надо построить статистику частоты встречаемости фамилий.

Для этого я начал искать наборы американских фамилий, и тут меня ждало открытие – в Америке можно найти открытые данные по, скажем, избирателям штата – как я понял, совершенно легально. Например, я за полчаса без проблем получаю данные всех избирателей штата Юта.

Есть прекрасный сайт www.reformagkh.ru. На нём можно найти, управляющую компанию, закреплённую за домом, сколько денег, на что тратится и всё такое. Но кроме этого можно узнать разные интересные вещи о нашей стране в целом, например, для каждого дома на сайте указана дата его постройки, поэтому можно посмотреть, как строилась Москва с 1900 года:



Ещё более эпичная картинка получается, если посмотреть на Россию целиком:

Выборы в Государственную думу только осенью, но мы уже начинаем готовиться. Если повторится история 2011 года, будет очень интересно. Наверное, многие помнят, как сразу после тех выборов появилась куча статистических исследований, намекающих на фальсификации и как все узнали, как выглядит распределение Гаусса. Я хотел бы рассказать, где искать данные про выборы и как с ними работать. Кроме хорошо известных графиков я покажу некоторые другие прикольные картинки, которых раньше в паблике не видел. Так, например, выглядит распределение голосов за Единую Россию по стране, хорошо видны регионы с максимальной поддержкой партии власти — Северный Кавказ и Татарстан:


Есть такой замечательный сайт izbirkom.ru. Его здесь даже недавно упоминали в контексте, что, типа, на него потратили слишком много денег. Но лично мне не жалко, сайт прекрасный:

Вступление

Cегодня мы вместе с анализом графов, data mining, subgroup discovery и всеми веселыми штуками взглянем на Хабр. Весь код и данные прилагаются — каждый может взглянуть на них самостоятельно, легко повторить рассчеты из статьи и найти что-то интересное самостоятельно.




(это не просто картинка для привлечения внимания, а — граф связей ~45000 пользователей Хабра по тому, кто на кого подписан; размер вершины пропорционален числу подписчиков; все картинки кликабельны; подробности далее)



Обсуждаемые проблемы возникли, конечно же, далеко не вчера, но некоторые их аспекты кажутся мне достаточно новыми и поэтому достойными дискуссии, основанной на непредвзятых и репрезентативных данных. Например в комментариях этой статьи, увидел интересное утверждение:

Тут проблема в том, что на всем хабре за сегодня не насчитать больше 50-80 человек, которые вообще могут голосовать. У 90% пользователей карма просто ниже 5. Как итог оценивают комментарии и статьи только избранные. Это как жюри выходит такое.

И решил, что стоить его сформулировать в виде гипотезы и проверить:

Q1: Правда ли, что Хабр превратился в жюри-based сообщество, где два с половиной человека голосуют за статьи?

Вот в этой статье к нам вернулись "железные" Хабы и стало интересно, а как вообще представлены разные сообщества внутри Хабра? Формулируем в виде гипотезы:

Q2: Как сегментировано сообщество, или проще говоря сколько у нас здесь групп по интересам и соотвествуют ли они имеющимся хабам?

Последнее, но не менее интересное наблюдение, что активность на Хабре упала (по данным Хабра-пульса и моим субъективным наблюдениям), что даже решили ввести аккаунты "read & comment". Поэтому решил оценить активность сообщества и продумать, как информация о структуре сообщества может нам помочь:

Q3: Насколько активно сообщество и как нам может помочь структура внутренних групп?

За подробностями добро пожаловать под кат.

Структура статьи

• Методология сбора данных
• Распределения кармы, постов, комментариев...
• Сообщества Хабра
• Связность Хабов
• Активность и выводы
  

Яндекс.Метрика сегодня это не только система веб-аналитики, но и AppMetrica — система аналитики для приложений. На входе в Метрику мы имеем поток данных — событий, происходящих на сайтах или в приложениях. Наша задача — обработать эти данные и представить их в подходящем для анализа виде.



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

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

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

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



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

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

Сейчас в мире есть несколько основных моделей, по которым предсказывают погоду. Например, модель с открытым исходным кодом WRF, модель GFS, которые изначально являлись американской разработкой. Сейчас ее развитием занимается агентство NOAA.

Если вы знаете, почему простая строка `strings` в Redis займёт в оперативной памяти 56 байт — вам, думаю, статья не будет интересна. Всем остальным я попробую рассказать, что такое строки в Redis и почему использующему эту базу данных разработчику важно понимать, как они устроены и работают. Это знание особенно важно, если вы пытаетесь рассчитать фактическое потребление памяти вашим приложением или планируете строить высоко нагруженные системы статистики или учёта данных. Или, как часто бывает, пытаетесь срочно понять, почему вдруг ваш экземпляр redis стал потреблять неожиданно много памяти.

Недавно, на хакатоне от Petamelon нам в руки попал датасет с ~6 000 000 резюме с НН. Там, естественно, не было никаких персональных данных и контактов, но было много других интересных вещей: ожидаемая зарплата, возраст, пол, примерный адрес, образование и индустрии, в которых человек ищет работу. Было решено попробовать использовать эти данные в нашем проекте про выбор школ. Идея заключалась в том, чтобы определить в каких индустриях работают выпускники школ и сколько примерно зарабатывают. Но я, конечно, не удержался и построил кучу других бесполезных, но прикольных таблиц и графиков.

Распределение резюме по возрасту имеет интересную форму и как будто разделено на две части: до окончания института и после:


В Москве с возрастом ожидаемая зарплата выходит на плато в ~50 000 рублей:

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

И сегодня мы хотим сказать, что наконец можем выполнить все эти пожелания. В январе на Курсере пройдёт курс, организованный совместно Яндексом (Школой анализа данных) и ВШЭ. Записаться на него можно уже сейчас: www.coursera.org/learn/introduction-machine-learning.


Сооснователь Coursera Дафна Коллер в офисе Яндекса

Курс продлится семь недель. Это означает, что по сравнению с ШАДовским двухсеместровым курсом он будет заметно упрощен. Однако в эти семь недель мы попытались вместить только то, что точно пригодится на практике, и какие-то базовые вещи, которые нельзя не знать. В итоге получился идеальный русскоязычный курс для первого знакомства с машинным обучением.

Кроме того, мы верим, что после прохождения курса у человека должна остаться не только теория в голове, но и скилл «в пальцах». Поэтому все практические задания построены вокруг использования библиотеки scikit-learn (Python). Получается, что после прохождения нашего курса человек сможет сам решать задачи анализа данных, и ему будет проще развиваться дальше.

Под катом можно прочитать подробнее обо всех авторах курса и узнать его примерное содержание.

Примечания tsafin:

Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.

Введение

Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.