В первой части этой серии статей вы узнали о данных и о том, как можно использовать компьютеры чтобы добывать смысловое значение из крупных блоков таких данных. Вы даже видели что-то похожее на большие данные у Amazon.com середины девяностых, когда компания запустила технологию для наблюдения и записи в реальном времени всего, что многотысячная аудитория клиентов одновременно делала на их сайте. Довольно впечатляюще, но назвать это большими данными можно с натяжкой, пухлые данные — больше подойдёт. Организации вроде Агентства национальной безопасности США (NSA) и Центра правительственной связи Великобритании (GCHQ) уже собирали большие данные в то время в рамках шпионских операций, записывая цифровые сообщения, хотя у них и не было простого способа расшифровать их и найти в них смысл. Библиотеки правительственных записей были переполнены наборами бессвязных данных.

То, что сделал Amazon.com, было проще. Уровень удовлетворённости их клиентов мог быть легко определен, даже если он охватывал все десятки тысяч продуктов и миллионы потребителей. Действий, которые клиент может совершить в магазине, реальный он или виртуальный, не так уж много. Клиент может посмотреть что в доступе, запросить дополнительную информацию, сравнить продукты, положить что-то в корзину, купить или уйти. Всё это было в пределах возможностей реляционных баз данных, где отношения между всеми видами действий возможно задать заранее. И они должны быть заданы заранее, с чем у реляционных баз данных проблема — они не так легко расширяемы.

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

Гегель считал, что общество становится современным, когда новости заменяют религию.
The News: A User's Manual, Alain de Botton

Читать все новости стало разительно невозможно. И дело не только в том, что пишет их Стивен Бушеми в перерывах между боулингом с Лебовски, а скорее в том, что их стало слишком много. Тут нам на помощь приходят агрегаторы новостей и естественным образом встаёт вопрос: а кого и как они агрегируют?

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

Краткое определение того, что такое Meduza:

«Помните, как неумные люди все время называли «Ленту»? Говорили, что «Лента» — агрегатор. А давайте мы и в самом деле сделаем агрегатор» (интервью Forbes)

(это не просто КДПВ, а топ-35 медиа по числу новостей указанных в качестве источника на сайте Meduza, включая её саму)

Конкретизируем и формализуем вопросы:

• Q₁: Из каких ключевых источников состоит лента новостей?

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

• Q₂: Есть ли на них какая-то простая и интерпретируемая структура?

Проще говоря, можем ли мы кластеризовать источники в осмысленные группы?

• Q₃: Можно ли по этой структуре определить общие параметры агрегатора?

Продолжу обещанный рассказ о том, как можно применять полученную модель на практике, заодно попытаюсь более подробно раскрыть тему эксклюзивности TMVA.
Допустим, Вы работаете в проекте, требующем максимального быстродействия системы (геймдев, картографический сервис или же данные с коллайдера), тогда очевидно, что Ваш код написан на языке, который предельно близок к железу — C/C++. И однажды возникает необходимость добавить к сервису какую-то математику в зависимости от потребностей проекта. Обычно взгляд падает на змеиный язык, который имеет множество удобных математических библиотек для прототипирования идей, но при этом бесполезном в работе с действительно большим объёмом данных и поедающем словно удав все ресурсы машины.

Превью

В июне прошло одно из самых крупных мероприятий мира в сфере big data и data science — Spark Summit 2016 в Сан-Франциско. Конференция собрала две с половиной тысячи человек, включая представителей крупнейших компаний (IBM, Intel, Apple, Netflix, Amazon, Baidu, Yahoo, Cloudera и так далее). Многие из них используют Apache Spark, включая контрибьюторов в open source и вендоров собственных разработок в big data/data science на базе Apache Spark.

Мы в Wrike активно используем Spark для задач аналитики, поэтому не могли упустить возможности из первых рук узнать, что происходит нового на этом рынке. С удовольствием делимся своими наблюдениями.

2,8 млн репозиториев, 3 ТБ исходного кода и метаданных

Данная статья предназначена для статистиков, инженеров машинного обучения и специалистов, которые интересуются вопросами обнаружения зависимостей в наборах данных. Также материал, изложенный в статье, может быть интересен широкому кругу читателей, неравнодушных к data mining. В материале не будут затронуты вопросы feature engineering и, в частности, применения таких методов как анализ главных компонент.

Это третья статья в цикле про создание и использование скриптов для веб-скрейпинга при помощи Node.js:

1. Web scraping при помощи Node.js
2. Web scraping на Node.js и проблемные сайты
3. Web scraping на Node.js и защита от ботов
4. Web scraping обновляющихся данных при помощи Node.js

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

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

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

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

Как чуден и глубок русский курлык
— Генератор постов

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

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

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

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

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

  
  

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

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

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