Проект "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 часа.
Сам сервис при этом работал на очень ограниченных ресурсах — фактически за все отвечала одна единственная запущенная копия.
На данный момент проект выведен из эксплуатации, поскольку по мере роста компании-заказчика, на каком-то этапе оказалось проще покупать оптом готовые данные у сторонних поставщиков, чем собирать их самостоятельно.
Поэтому в данный момент всю логику обработки и поиска адресов выполняет сторонний сервис, предоставляемый внешней компанией-поставщиком.