Краулинг по анкетам соискателей

Предисловие

Жизнь богата и многогранна. И вот мне потребовалось изучить состояние “рынка данных соискателей” для проектирования гипотетической системы сбора анкетных данных. Имею возможность показать результаты этой работы, авось, кому-то пригодится.
Исторически механизмы сканирования сайтов известны под именами краулеров или пауков (web crawlers / spiders) и в сети есть много описаний их реализации и даже готовых решений. Хотя классический паук пробирается по всем попавшимся ссылкам, что не совсем соответствует имеющейся задаче, поэтому можно взять эту идею и подкорректировать.
Источники данных я разделил на 2 группы — данные соискателя и личные данные. К первым я отношу рекрутинговые порталы: superjob, hh, rabota.ru и т.д., ко вторым — социальные сети — vk, facebook. Соц. сети для поиска работы, вроде linkedin, можно отнести к обеим группам. Я пока сконцентрировался только на первой группе источников, так как они содержат минимальные необходимые сведения о соискателе, а также заключают в себе сам факт того, что человек находится в режиме поиска.

Базы данных соискателей

Анкеты соискателей на изученных порталах находятся полностью или частично в закрытом доступе. Доступ к критичным данным (например, контакты) санкционируется через платные аккаунты. Такой подход может объясняться законами о персональной информации, которые ограничивают выдачу некоторых данных в открытый доступ, и конечно коммерческими интересами владельцев баз.

К федеральным законам, раскрывающим ответственность за нарушения в сфере защиты персональных данных, можно отнести:

  • Федеральный закон от 27.07.2006 № 152-ФЗ “О персональных данных” (в ред. от 23.12.2010).
  • Федеральный закон от 27 июля 2006 № 149-ФЗ “Об информации, информационных технологиях и о защите информации”.
  • Кодекс Российской Федерации об административных правонарушениях от 30.12.2001 № 195-ФЗ (ред. от 07.02.2011) (с изменениями и дополнениями, вступившими в силу с 07.04.2011).
  • Уголовный кодекс Российской Федерации от 13.06.1996 № 63-ФЗ (ред. от 07.03.2011).
  • Трудовой кодекс РФ от 30.12.2001 № 197-ФЗ (ред. от 29.12.2010).
  • Гражданский кодекс РФ (взято тут).

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

Например, как тут:

Портал Superjob.ru и компания Datex Software объявляют об успешной интеграции сервиса Superjob.ru и системы автоматизации рекрутинга E-Staff.

SuperJob

API: https://api.superjob.ru/

Условия использования: https://api.superjob.ru/rules/

Пример доступа к информации

HH.ru

API: https://dev.hh.ru

Условия использования: https://dev.hh.ru/admin/developer_agreement

Причём, база hh взаимодействует с rabota.mail.ru и career.ru.

Доступ к нормализованным данным:

rabota.ru

API: нет в открытом доступе, информация из дисклеймера: Чтобы сделать подбор кадров эффективным, можно воспользоваться разными услугами: от доступа к базе до безлимитных тарифов, позволяющих вести набор работников unlimited.

Принципы работы

Работа с внешними поставщиками заключает в себе некоторые трудности — различия форматов данных, перебои связи, обновления протоколов взаимодействия и т.д., поэтому взаимодействие должно быть управляемым — должен быть реализован механизм для лёгкого подключения новых источников данных, сопровождения их работы, управления договорами (оплатами / уровнем и качеством информации, допустимыми нагрузками), обновления протоколов/шаблонов парсинга. Условно систему назову “сборщиком анкет”.

Схема сборщика анкет

ЛК

Личный кабинет будет предоставлять оператору сборщика возможность выполнять настройки (какие есть аккаунты, какие ресурсы мониторить, по каким условиям искать анкеты, какие ограничения по нагрузкам должны выполняться — например, не более 500 вызовов в сутки и т.д.), видеть состояние обработки анкет, доступность источников анкет, выполнение SLA (service level agreement) и т.д.

Планировщик

Модуль, который инициирует забор анкет из источников. Также реализует роль адаптера интерфейсов. Также выполняет функцию балансировщика нагрузки на интерфейсы сбора анкет. Планировщик не выполняет никаких ресурсоёмких операций, поэтому требования минимальные — как по железу, так и по программному обеспечению. Для гибкой оркестровки процессов подойдёт среда управления Apache Mesos (есть даже пример реализации такого движка). Для простого старта могут подойти обычные библиотеки планирования, вроде Crone, Quartz.

Интерфейсы

Интерфейсы (по сути, краулеры) могут разрабатываться совершенно на любом удобном языке (можно отталкиваться от затрат на разработку и выбрать более дешёвый или быстрый вариант — это python или Java). Каждый интерфейс работает со своим источником анкет, соответственно, могут учитываться все нюансы работы — наличие API или необходимость парсинга HTML. Интерфейсы подключаются к планировщику и далее централизованно используются. Для выполнения условий по ограничению количества запросов к источникам с одного IP могут использоваться прокси-серверы, которые будут подменять IP исходящих запросов. После получения анкет интерфейс приводит данные к некоторому принятому виду, сохраняет их в общий архив анкет и добавляет команду о поступлении новых данных в очередь на обработку.

Raw forms

Большой архив куда будет собираться максимум информации, полученной из внешних источников с учётом версионности (обновления резюме/анкет сохраняются с новой версией). При этом, информация не будет принимать активное участие в логике, а использоваться по требованию, то есть база должна поддерживать нагрузку на чтение и запись (возможно, пакетно), обновление данных не требуется. Также стоит учитывать слабую структурированность данных (форматы анкет могут меняться). Для такой задачи на начальном этапе идеальна noSQL, вроде MongoDB. Эти базы легко горизонтально масштабируемы. Также я бы рассмотрел необходимость использования распределённого файлового хранилища, вроде Hadoop, хотя его предназначение — это сопровождение ежесекундной активности множества пользователей (активность в больших соц. сетях, видео-стримы, онлайн игры и т.д.), его использование будет актуальным при сборе множества данных из соц. сетей для анализа социальных паттернов, психологических портретов и т.д.

Очередь

Так как интерфейсов будет множество и они будут забирать новые анкеты по расписанию, можно ожидать пики нагрузки по их обработке. Чтобы правильно распределить нагрузку, требуется реализация очереди. Для очередей также есть множество реализаций, я привожу популярные для Java: более простая однопользовательская очередь, вроде RabbitMQ (поддерживает + 20 тысяч обращений в секунду) и т.д. На случай большого объёма данных стоит использовать “потоковую” очередь Kafka. Выбор опять-таки зависит от планируемой нагрузки.

Обработчик

Обработчик — это скрипт, который будет просто преобразовывать данные анкет в форму, нужную для работы всей системы, и сохранять их в основную базу соискателей. Здесь не требуется каких-то особых фреймворков — можно использовать разработку на основном языке (Java / Go / python и т.д.) — цель — переработать данные нужную форму и записать в базу. Масштабируемость под нагрузку реализуется развёртыванием новых экземпляров скриптов, которые будут разгребать очередь задач. Для больших объёмов данных при использовании Kafka стоит использовать также потоковый процессор, например Apache Storm. Для реализации машинного обучения в реальном времени по архиву Raw Forms также может удачно быть применён Apache Spark (это имеет смысл опять же при подключении к парсингу соц. сетей).

Humans

Центральным звеном всей системы будет база соискателей. Это та информация, которая представляет непосредственную ценность для клиентов. База должна равномерно поддерживать нагрузки и по чтению и по записи. В идеологии больших данных реляционным базам не очень доверяют, но в данном случае следует использовать именно реляционную базу, например, PostgreSQL, MariaDB и т.д. Выбор объясняется тем, что в данной архитектуре не планируется постоянная пакетная переработка данных, позволяющая игнорировать возможные проблемы консистентности в клиентской базе, таким образом, поддержка транзакционности, которая есть только в реляционных СУБД, будет очень кстати. С горизонтальным масштабированием проблем не должно возникнуть. В базе будет нормализованная информация о человеке, идентификатором будет бизнес-ключ человека, достаточный для определения его уникальности, а также важные данные из его резюме и другие характеристики (психологический портрет, история активности, стаж и т.д.). Нагрузка на базу, даже измеряя десятками миллионов записей, незначительна.

Интересные референсы

E-Staff

Существующее решение по сбору и обработке анкет: http://www.e-staff.ru. Работает через платную интеграцию с поставщиками данных. Разрабатывается компанией WebSoft.

Datacol

Приложение для парсинга сайтов: http://web-data-extractor.net/parser-rezyume-hh-ru/.

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

Итог

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