Проект "IServer"

Еще один интересный проект, созданный нами в таком далеком 2019м году.

Если вы читали нашу предыдущую статью «Как мы делали скоринг», то думаю заметили некоторую похожесть в подходах.

Действительно, тут мы повторно использовали вариацию движка для выполнения Python-скриптов в Java-окружении (Jython) плюс IDE в веб-интерфейсе.

Но на этом вся похожесть заканчивалась и начинались отличия.

Официально проект назывался «Integration Server», поскольку с его помощью и разным набором скриптов решали сразу несколько сложных задач.

Ниже пойдет рассказ про самую первую из них.

Постановка

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

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

Со стороны клиентской системы (в которой работали пользователи), все это выглядело как-то так:

Проблемы

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

На Курской дуге.

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

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

Это не отечественный ГАР ФИАС с отдельным API для работы с выгрузками.

Забудьте про ссылки вроде /год/месяц/день, забудьте про наличие у архива метаданных с описанием содержимого и тем более про версионность самих данных.

Отдельной песней оказались и сами архивы (отличная же идея использовать Rar/7z форматы) и их содержимое в национальных кодировках.

Кстати о кодировках.

Только плотно разбираясь с адресами в UK я осознал насколько же американский английский отличается от британского.

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

Полнота данных

Стоит рассказать о еще одной важной проблеме, с которой вам обязательно придется столкнуться при работе над подобной задачей:

Проще говоря для европейских стран не существует полной официальной выгрузки, где одновременно есть и физический адрес и контактные данные и данные о регистрации компании.

Взгляните:

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

Это официальные государственные данные, получаемые из ASIC.

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

Существующие решения

Разумеется по мере чтения вы уже не раз задавались вопросом:

А мы и использовали, мы же не #бнутые.

По началу.

И быстро поняли, что хорошие и правильные готовые решения вроде Apache Flink или Apache NiFi — созданы для работы с хорошими и правильными данными.

Которые готовят специально для вас коренные британцы в десятом поколении, в смокингах, без перегара и с идеальным бритьем.

К сожалению, как только дело доходит до реальных данных, забиваемых самыми дешевыми полуграмотными сотрудниками или вообще интернами — сказки про «готовое решение» немедленно заканчиваются.

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

Или дробовик.

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

А затем NiFi устарел и его пришлось обновлять. Как думаете что случилось со всей нашей сложной логикой обработки?

Разумеется она на#бнулась.

Вы же не думали, что кто-то в 21м веке будет заморачиваться обратной совместимостью?

Итого

На момент завершения проекта, наш «IServer» собирал и обрабатывал данные о юрлицах из пяти европейских стран, а полный цикл обработки (от загрузки до построения поискового индекса) занимал 2.5 часа.

Сам сервис при этом работал на очень ограниченных ресурсах — фактически за все отвечала одна единственная запущенная копия.

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

Поэтому в данный момент всю логику обработки и поиска адресов выполняет сторонний сервис, предоставляемый внешней компанией-поставщиком.