Сейчас множество всяких наборов данных в разных областях выкладывают под лицензией OpenData: скачивай и используй (но не искажай). Но раз эти данные открытые, то все их создают как им угодно. Отсюда множество проблем при обработке, начиная с получения и заканчивая интерпретацией. Мы работаем с открытыми данными последние пять лет, и за весь опыт работы накопилось немало интересных случаев. Под катом — основные проблемы и примеры ребусов, путешествий во времени и прочей чертовщины, с которой мы ежедневно боремся. Где-то польза от открытости данных очевидна. Многие научные наборы открыты и приносят пользу обществу, например, вместе с инструментами для поиска и сравнения нуклеотидных и аминокислотных последовательностей BLAST на сайте Национального центра биотехнологической информации США распространяется также ежедневно обновляемая база GenBank, содержащая все аннотированные последовательности ДНК и РНК (сейчас там около 650 ГБ файлов). Или есть проект OpenStreetMap, который не нуждается в рекламе, и на сайте прямо написано, что они тоже Open Data. Среди всего многообразия открытых данных особое место занимают государственные. Исторически эта тема восходит к американскому закону о свободе информации (FOIF), который вступил в силу более полувека назад — в 1967 году. В 2009 году был запущен портал data.gov, на котором сейчас размещено 312 тысяч наборов данных. Большая часть этих наборов весьма специфична (например, данные о размерах классов в школах Нью-Йорка или фид с ДТП в Остине в реальном времени), но и данных очень много. Кроме того, часто ведомства выкладывают данные и самостоятельно. А что у нас? В 2002–2010 действовала программа «Электронная Россия» (в рамках неё открыли данные о гос. закупках), а в 2013 был принят закон об открытых данных (как в США), и в том же году запущен сайт data.gov.ru. На нём на текущий момент 24 тысячи наборов данных (читайте обзор в блоге «Информкультуры»). Если посмотреть на статистику скачивания данных на портале, то там с большим отрывом лидирует производственный календарь с 1995 по 2025 год (при этом данные после 2019 не обновлялись). Есть даже данные из будущего! Государственные открытые данные — область весьма специфическая. От работы с ними складывается впечатление, что данные выкладываются исключительно, чтобы соответствовать требованиям законодательства и показывать красивые графики о росте открытости. Например, один из подзаконных актов требует, чтобы все ведомства публиковали в виде открытых данных свои вакансии — и все публикуют.  Мы в Rusprofile занимаемся сбором различной информации о юридических лицах и индивидуальных предпринимателях, поэтому для нас актуальны только те наборы, которые относятся к этой области. Мы пытаемся собрать и показать максимум полезной информации — на данный момент получаем информацию из 42 различных источников. Все собранное группируется по компаниям/индивидуальным предпринимателям. Собственно, за доступ к красиво сформированной информации люди и готовы платить, она экономит им время. Но с этим возникают разного рода сложности... Первое, с чем сталкиваешься, — проблемы с получением данных. Это может быть просто медленный или зарезанный канал, по которому нужно скачать огромные файлы без сжатия, а может быть какое-нибудь интересное ограничение скачивания, например, шейпинг трафика до 100 кб/с после первой минуты.  Вторая группа проблем — сложность с интерпретацией данных. Закон никак не регламентирует полноту документации, поэтому на выходе бывает разное, и часто — ничего полезного (вплоть до того, что даже типы полей указаны неверно). Приходится разбираться самостоятельно.  Третий тип сложностей связан с очисткой данных от всякого мусора и ошибок. Бывают просто ничего не несущие пустышки (например, XML-ка, в которой нет ни одного элемента и атрибута, даже обязательных по схеме), а бывает «тестовая прокуратура», проводящая, по-видимому, тестовые проверки тестовых компаний.  И, наконец, четвёртая группа проблем связана с атрибуцией данных — их ведь нужно показывать на страницах того или иного юридического лица или индивидуального предпринимателя. И к какому лицу относятся данные — не всегда легко понять. За несколько лет работы с открытыми данными встретилось довольно много интересного. В статье я расскажу о нескольких забавных случаях, разъясню проблемы и способы их решения. Получение открытых данных, по идее, должно быть делом чрезвычайно простым. Обратился, допустим, по заранее известному адресу, который не меняется, прочитал актуальные метаданные по интересующим наборам, сверил даты актуальности, если есть более новое — скачал. Вот, Росстат, например, сразу предлагает выгрузить список (в CSV, правда, ну это уже детали) наборов открытых данных, а дальше по каждому набору скачать метаинформацию, тоже в CSV. Это не самый удобный формат, XML или JSON подошли бы лучше, но работать с этим можно. Надо только один раз понять, какие там разделители, какие там кавычки и как они экранируются, сделать оповещения, что формат, возможно, поменялся, но это так, мелочи.  Налоговая служба публикует много полезных наборов открытых данных, и там, кстати, часто довольно неплохая документация (особенно если это XSD к XML), и нечасто встречаются ошибки. Но вот список всех наборов с метаинформацией на страничке  скачать нельзя. И «паспорт набора» приходится разбирать из HTML-кода, к счастью, за это время вёрстка ни разу не поменялась (но на этот случай мы предусмотрели специальное оповещение). У Федеральной службы судебных приставов (ФССП) часть наборов есть аж в виде Linked data. Но это в виде связанных данных ФССП на данный момент опубликовало только три очень полезных набора: «Реестр отделов судебных приставов», «Телефонный справочник работников ФССП России» и «Справочник должностей ФССП России».  А вот реестры ведущихся и прекращённых по определённым причинам исполнительных производств почему-то доступны только в CSV. Каждый день приходится заново выгружать оба реестра целиком: первый занимает 2 ГБ, а второй — 3,5 ГБ. Они никак не сжимаются даже на уровне веб-сервера и раньше качались изнуряюще долго — бывало, по 10 часов и даже дольше. Потом стало немного лучше, но внезапные обрывы соединения никуда не делись. Отсюда родилось решение, которое было заточено специально под сервера ФССП, но потом пригодилось во многих других местах: менеджер закачки в духе ReGet. Он запрашивает файл по частям через разные прокси-сервера, пытается ещё раз скачать те части, которые по какой-то причине получить с первого раза не удалось, аккуратно собирает весь файл, проверяет его целостность и уже потом только помещает в хранилище. Правда, иногда может оказаться так, что размер файла почему-то поменялся в процессе скачивания. В этом случае процесс начинается заново. В целом, этот «менеджер закачки» оказался настолько удобным, что сейчас мы его используем для многих наборов открытых данных: он помогает вообще не думать о таких проблемах. Ещё один случай, который заставил немало попотеть: единый реестр проверок. Кроме всяких эксцессов, когда полгода сайт находился «в техническом обслуживании» и не обновлялся (и мы даже жаловались в прокуратуру на… ту же прокуратуру), были и другие неприятности. Единый реестр проверок какое-то время генерировал динамические адреса доступа к файлам данных, причём веб-страница отправляла AJAX-запрос, который как раз их и возвращал. К счастью, в этом случае обошлось без headless-браузера: схема не менялась, и надо было просто отправить нужный запрос и получить ответ. Потом это исправили и адреса стали нормальные. Единый реестр проверок доставлял и другие неприятности с получением данных: часто файлы были просто недоступны, и приходилось пытаться их скачивать несколько раз (вот здесь снова пригождается менеджер закачки). Также реестр проверок предоставляет отдельные наборы данных на каждый месяц и год (хотя по сути это один набор). Нам пришлось разработать специальный механизм, который автоматически находит и записывает новые месяцы и годы. Когда данные всеми правдами и неправдами скачаны, наступает следующий этап — понять, что же все они означают. Некоторые наборы документированы достаточно подробно, например, налоговая вместе со многими наборами в XML отдаёт достаточно хорошо описывающую их XSD-схему. Вот, например, документация к данным по реестру малого и среднего предпринимательства. Кроме пугающего русскоязычного XML с тегами в духе <СвПрогПарт>, к которым через какое-то время просто привыкаешь, там нет ничего страшного. Есть, конечно, данные по гос. закупкам — бумажная бюрократия, переведённая в XML, и оттого ещё более формализованная и запутанная. В целом там тоже неплохая документация по форматам (в виде XSD-схем), и чтобы окончательно разобраться, достаточно было несколько проконсультироваться со специалистом по соответствующим областям законодательства. После этого становится ясно, какие документы соответствуют какой части процесса и что со всем этим делать. А вот бухгалтерская отчётность, которую за период с 2012 по 2018 год предоставляет Росстат, документирована просто восхитительно. Описание полей в структуре выглядит буквально следующим образом: И так две с лишним сотни строк со «значениями показателя», кодами ОКПО, ОКФС, ИНН. Код единицы измерения, как оказалось позже — по справочнику ОКЕИ, и, разумеется, все «значения показателя» оказались исключительно числами, но это так, мелочи. Кстати, по теме справочников: у Росстата есть ОКОК — общероссийский классификатор общероссийских классификаторов. Но главная сложность с этими данными состояла в том, что совершенно неясно, что именно означают таинственные пятизначные числа, которые не совпадают ни с планом счетов, ни с номерами строк в бухгалтерской отчётности — те четырёхзначные.  Наконец, когда я увидел бумажные формы бухгалтерской отчётности, всё начало проясняться. Номера строк там действительно четырёхзначные, но есть ещё и номера столбцов — пятая цифра. Складываем все коды в Excel, рисуем таблицу и видим... Расположение цифр слева соответствует расположению пустых полей справа — гипотеза подтвердилась! Присутствующие и отсутствующие коды показателей в выгрузке точно соответствуют бумажной форме. Остальное было делом техники. На этом проблемы с бухгалтерской отчётностью не закончились, но они были уже куда проще.  В целом проблемы с интерпретацией данных решаются, если сопоставить различные источники друг с другом и, как правило, когда накапливается достаточное количество данных, всё становится понятно. Иногда в данных бывают косяки. Зачастую безобидные, когда, например, отгружается проверка по несуществующей организации, или у дисквалифицированного лица указан ИНН, который ничему не соответствует. В таких случаях эти данные просто можно игнорировать и никак не показывать, но ошибки бывают и более существенные. Одна из самых частых проблем — опечатки в датах. Например, исполнительное производство, открытое, судя по дате, ещё в Римской империи — в 0204 году), и помеченное закрытым в 2015 году. Есть производства из будущего, например, от 2189 года (8585/17/50004-ИП, от 22 мая). Довольно много таких курьёзов можно отфильтровать по датам, но, допустим, бывает и такое: сначала появляются сведения о контракте на гос. закупку у какой-нибудь фирмы, а только через несколько дней появляются сведения, что эта фирма вообще зарегистрирована в налоговой. Иногда косяки бывают более хитрые. Например, всё та же незабвенная ФССП в один из дней выгрузила файл, в котором были перепутаны два столбца — номер исполнительного производства и номер исполнительного документа. А поскольку историю состояния по этим делам мы можем считать только сравнивая имеющиеся и новые файлы, то так вышло, что несколько миллионов исполнительных производств были помечены как закрытые. А на следующий день они переоткрылись, поскольку снова появились в файлах. Их приходится исправлять в ручном режиме, просто вычищая из БД все неверные данные. Установить жёсткие правила, чтобы отфильтровывать ошибочные данные, не удаётся — кроме, пожалуй, случая с явно некорректными датами. Поэтому здесь мы действуем иначе: проверяем данные достаточно расслабленно, но при этом корректируем их по запросам пользователей. Так был разработан специальный механизм, который первоначально решал и проблему атрибуции. И здесь я ещё раз вспоминаю о Федеральной службе судебных приставов. Помните, были истории, когда приставы по ошибке предъявляли требования полному тёзке должника? Так вот, с юридическими лицами происходит то же самое. Не вполне понятно, почему именно, но база ФССП (как доступная на сайте, так и, по-видимому, внутренняя), содержит только наименование и адрес организации, и в ней нет никаких реквизитов. При этом адрес может быть не юридический, а фактический, правда, в прошлом году эти поля всё-таки разделили (что, впрочем, не означает, что они не путаются). Можно предположить, что такие ошибки связаны с особенностями юридических процедур, но факт остаётся фактом — должников приходится искать по адресу и наименованию. Один из наших пользователей по этому поводу написал: Адский сайт. По-моему, они собирали совещания, где повесткой дня было: как сделать так, чтобы люди ничего не смогли найти даже по ИНН. И у них это получилось… Атрибутировать производства оказалось весьма интересной задачей. ,399782,48 ,ЕЛЕЦ Г,ЧЕРОКМАНОВА УЛ,10, Здесь 48 означает код региона — Липецкую область. А ещё код региона может внезапно стоять в конце, вместо квартиры: ,ЕЛЕЦ Г,ПРОМЫШЛЕННАЯ УЛ,90,КОРП643,48 Пришлось вручную собрать разнообразные форматы адресов, подготовить на основе реальных адресов компаний тестовые данные и обучить небольшую нейронную сеть — сегментатор адресов. С разобранным адресом дальше уже дело техники: — найти нужную компанию, которая в определенный период была зарегистрирована по конкретному адресу, а эта информация у нас есть из ЕГРЮЛ. 100% точности, понятное дело, с такими исходными данными достичь не удастся, но большую часть должников мы успешно идентифицируем. Аналогичный механизм пришлось делать и для картотеки арбитражных дел. Там часто бывают указаны реквизиты компаний, но иногда они перепутаны и требуется проверять все возможные соответствия, чтобы убедиться: нужные компании привязаны к нужным сторонам дела. В целом автоматизировать всё это невозможно, и пользователи регулярно пишут в поддержку, что какое-то дело неверно атрибутировано. Для этих случаев был разработан так называемый механизм перепривязок. Мы, разумеется, не редактируем исходные данные, полученные из источников, но при этом храним таблицу переопределений — что-то вроде вклеенного в книгу списка опечаток. На одном из этапов обработки источника эти переопределения применяются, и в промежуточные представления, из которых отображается информация на сайте, уже попадают скорректированные данные. Работать с российскими государственными открытыми данными скучно не бывает. С одной стороны, часто приходится разбираться с какой-нибудь очередной новой предметной областью, где встречаются неожиданные глубины. Например, лицензирование различных сфер деятельности отличается довольно сильно, и нам нужно было свести их в единую структуру, чтобы показывать список лицензий у какой-нибудь компании. С другой стороны, есть и чисто технические вызовы: оптимизировать парсинг больших XML-файлов и сделать так, чтобы все интересующие пользователей данные отдавались быстро.  Всё это требует от разработчиков упорства и изобретательности в борьбе с артефактами цифровизации. Зато каждый раз, когда удаётся понять, что же на самом деле означают эти недокументированные цифры, или когда удаётся найти надёжный способ извлекать из данных нечто полезное, приходит чувство глубокого удовлетворения от очередной маленькой победы человека над бюрократией. CTO Rusprofile.ru