О компании Новости Продукты и сервисы Наши клиенты Контакты

О лаборатории Технологии Направления работ Публикации Бэкграунд

19.12.2017

Обновили структуру АБР

АБР – это наш собственный классификатор адресов России. Мы его ведём на основе данных из КЛАДР, ФИАС, а также на основе сведений, которые сообщают нам наши клиенты об адресах, которых нет ни в КЛАДР, ни в ФИАС. Этот классификатор лежит в основе всех наших сервисов, которые работают с почтовыми адресами. Например, он используется сервисом очистки и стандартизации адресов ahunter.ru, а также нашим гео-кодером и сервисом стандартизации номеров телефонов.

АБР нам нужен для того, чтобы учитывать и по возможности исправлять проблемы, возникающие в КЛАДР и ФИАС. Когда в этих справочниках происходят серьёзные изменения, мы отслеживаем их и отображаем на наш классификатор, контролируя этот процесс в полуавтоматическом режиме. Такой подход позволяет компенсировать структурные изменения в ФИАС, которые, как правило, возникают внезапно. С момента создания ФИАС состав классификационных уровней и структура классификационного кода в этом справочнике изменялся несколько раз. В ФИАС постепенно исчезли «Уровень дополнительных территорий» и «Уровень подчиненных дополнительным территориям объектов», «Уровень автономного округа» и «Уровень внутригородской территории». Вместе с тем появлялись новые уровни, такие как «Уровень городских и сельских поселений» и «Уровень планировочная структура».

Если бы все наши сервисы ориентировались на структуру классификатора ФИАС, то всякий раз, когда в нём происходили такого рода изменения, нам приходилось бы оперативно править и адаптировать к новой структуре все наши сервисы. Более того, эти изменения неизбежно приводили бы к изменениям API, а это в свою очередь создавало бы проблемы для наших пользователей. Для решения таких проблем мы ведём наш собственный классификатор, на который отображаются данные из ФИАС и КЛАДР. До недавнего времени структура нашего классификатора соответствовала уровням КЛАДР, так что объекты со всех уровней ФИАС отображались на пять уровней – регион, район, город, населённый пункт и улица.

Однако пару месяцев назад мы решили, что число накопленных отличий между ФИАС и АБР достигло критического значения, поэтому мы расширили состав уровней нашего классификатора и привели его к канонической структуре классификационного кода, зафиксированного на настоящий момент в ФИАС. В рамках этой структуры в дополнение к пяти указанным выше уровням добавлен уровень территорий, на который сейчас отображаются садоводческие товарищества, гаражные кооперативы, жилые и промышленные зоны и прочие территории.

В настоящий момент мы постепенно переводим на новую версию классификатора наши внутренние сервисы, после чего внесём соответствующие изменения в продуктах ahunterES и ahunter.ru. Изменения появятся в API, а также в тонком клиенте, отвечающем за пакетную стандартизацию почтовых адресов. Для сохранения совместимости с существующими интеграциями, новая версия API будет активироваться вручную пользователями в личном кабинете.

20.06.2017

Переделали геокодер

В рамках нашего сервиса ahunter.ru и серверного продукта ahunterES существует модуль геокодирования. Данный модуль осуществляет преобразование почтового адреса, записанного в свободной текстовой форме, в GPS-координаты. Координаты адресов полезно иметь под рукой, например, если требуется отображать их на карте, рассчитывать расстояние между ними или отыскивать кратчайшие маршруты.

В основе нашего геокодера лежат открытые картографические данные OpenStreetMap. Данные являются открытыми, поэтому любой энтузиаст может редактировать и пополнять карту Земли в пределах своих возможностей и знаний в области картографии. В силу открытости OpenStreetMap и отсутствия жёстких стандартов при оформлении объектов карты возникают серьёзные проблемы, связанные с извлечением и структурированием картографических данных для последующего их использования совместно с такими справочниками как ФИАС и КЛАДР. Для корректной работы нашего геокодера нам необходимо извлекать из OpenStreetMap максимально возможное количество адресообразующих объектов и привязать их к аналогичным объектам ФИАС и КЛАДР.

Поскольку единого стандарта ведения данных в OpenStreetMap не существует одни и те же адресные объекты могут быть зарегистрированы на этой карте разными способами. Как следствие, на карте появляются дубли одних и тех же объектов, описанные разными пользователями-картографами с применением разных способов. Кроме этого, названия адресных объектов могут отличаться от принятых официальных названий. Подчинённость объектов зачастую не соответствует принятым принципам административно-территориального деления России. Объекты, принадлежащие одному уровню ФИАС, могут быть размещены на разных уровнях карты.

Для решения всех этих проблем нами разработана система распознавания, извлечения и связывания объектов карты с объектами ФИАС. Поскольку всех способов нанесения объектов на карту мы не знаем, мы решили реализовать нашу систему с использованием принципов машинного обучения. Мы подготовили порядка 50 тыс. обучающих примеров, которые, на наш взгляд, наиболее полно отражают способы описания адресов на карте. На этой выборке мы обучили наш специализированный распознаватель, который в паре с нашим стандартным адресным детектором, выполняет отбор адресных объектов с карты и привязывает их к объектам ФИАС. Например, этот специализированный распознаватель понимает, что нанесённая на карте тропинка с названием Лесная не может считаться улицей Лесной, хотя она и находится в черте города наравне с остальными улицами. Вместе с тем пешеходная дорожка с названием аллея Мира вполне может быть отображена на соответствующую улицу в ФИАС. Удобство данного подхода заключается в том, что при появлении новых картографических данных, не укладывающихся в текущий набор правил распознавания, мы легко можем адаптировать геокодер к этим данным путём добавления их в обучающую выборку и последующего переобучения.

В результате построения базы геокодера с использованием нового подхода, нам удалось извлечь с карты дополнительно около 5000 новых населённых пунктов и отобразить их на соответствующие объекты ФИАС. Новая база геокодера уже внедрена в облачной версии Ахантера, в ближайшее время планируем включить её в решения ahunterES, поставляемые нашим клиентам.

27.01.2017

Запустили ahunter 3.0

Мы обновили версию ahunter.ru до 3.0. В рамках этой версии мы собрали все улучшения и доработки, над которыми велась работа в течение последних шести месяцев.

Среди наиболее заметных изменений можно выделить следующие.

• Упорядочили материалы и документацию, доступную на сайте, улучшили навигацию по сайту и полностью переработали дизайн.
• Добавили возможность отслеживать статистику использования сервиса в реальном времени. Также мы реализовали автоматическое отслеживание состояния серверов Ахантера и расчёт их доступности. Всю эту информацию можно увидеть непосредственно на сайте в разделе «Статистика».
• Переработали личный кабинет и панель администратора. Теперь работать в личном кабинете стало ещё удобней.
• Переработали алгоритмы распознавания почтовых адресов, так чтобы пользовательские фильтры применялись не только для отбрасывания не подходящих адресов. Теперь фильтры пользователя также выполняют функции подсказок в ходе самого распознавания. Это позволяет восстанавливать в адресах пропущенные названия городов и населённых пунктов за счёт подсказок из фильтров. В общем случае с помощью фильтра может быть восстановлен адрес, состоящий только из названия улицы и номера дома.
• Выполнили поиск дублей среди улиц в КЛАДР и ФИАС, объединили эти дубли и обновили адресное хранилище сервиса.
• Усилили борьбу с ботами. Теперь сервис может не пропускать пользователей, злоупотребляющих бесплатными возможностями сервиса с применением популярных сетей прокси-серверов.
• Переработали механизм пополнения баланса пользователя, так чтобы деньги пользователя не терялись в случае сбоев на стороне нашего сервиса.
• Закончили апробацию межсерверной репликации и запустили её между серверами сервиса в боевом режиме. Теперь репликация выполняется на постоянной основе в реальном времени.

30.11.2016

Внедрили репликацию данных на ahunter.ru

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

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

Изначально репликация выполнялась путём резервного копирования всех данных с боевого сервера и последующего развертывания резервной копии на остальных серверах. Этот приём был очень неудобен, поскольку с ростом числа пользователей сервиса рос и объем реплицируемых данных. Как следствие переливка всех данных между серверами отнимала много времени и создавала большой служебный сетевой трафик.

Также перед нами возникла задача предоставить пользователям возможность одновременно работать на разных серверах Ахантера. Это позволило бы распределить нагрузку между серверами.

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

В настоящий момент в кластере Ахантера запущено два сервера, репликация между которыми происходит каждые 5 минут. Суммарно кластер обеспечивает 100% доступность сервиса и полностью справляется с пользовательской нагрузкой. При возрастании нагрузки на сервис мы планируем увеличить количество серверов в кластере без потери в производительности.