Продолжая рассуждения о том как устроена работа с данными - об отличиях в работе с данными в корпоративном секторе и данными публикуемыми госорганами, о том в чем заключаются ключевые отличия. Текст не претендует на полноту, скорее заготовка к большому тексту по той же теме. Основное что важно понимать в интеграции государственных и корпоративных данных - это инертность обратной связи. При работе с корпоративными данными со многими источниками данных можно договориться, особенно если этот источник не супер-мега дата-корпорация, а частный поставщик данных за деньги. А вот случае государства даже если есть обратная связь то какие-либо изменения происходят очень долго, чаще всего проще найти альтернативные способы работы с данными чем их дождаться. Иначе говоря почти любой бизнес бизнес более клиентоориентирован чем госорганы. Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления: - слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, XML файлами в несколько гигабайт каждый в которых содержатся все данные в этом наборе данных - документированные API - редки, содержат описание, как правило не в привычном формате вроде OpenAPI, а в виде PDF/DOC документа с описанием всего текстом по ГОСТу или близко к ГОСТу - недокументированные API - наиболее распространены, есть почти на любом современном государственном ресурсе. К ним можно подключаться, выгружать данные, но нет никакой гарантии что всё это не слетит при следующем обновлении их системы. Документация отсутствует в принципе. - API в режиме запрос-ответ - когда доступа к данным в чистом виде нет, но можно запросить сведения по конкретному запросу и получить данные только по нему - неструктурированные данные - всё то что массово публикуется на сайтах в виде HTML/PDF/DOC и реже Excel файлов. Требует навыков извлечения и распознавания этих данных разными способами. Это не так сложно, но задаёт определенный "порог входа" при доступе к данным. Более всего неструктурированных данных, далее много данных в виде батчей опубликовано на порталах открытых данных, очень много недокументированных API, значительно меньше документированных. Всё это отличается от корпоративного сектора и довольно сильно. В корпоративном секторе, там где есть онлайн сервисы и цифровые онлайн продукты акцент идёт на API и доступность данных через API. Какие-то сервисы дают API за деньги (почти все API распознавания образов например), какие-то бесплатно для удержания в своей экосистеме (Github, Яндекс.Метрика и др.). Поэтому практически все сервисы интеграции корпоративных данных в облаке построены вокруг сбора данных из API и прямого подключения к базам данных. Базы данных, как правило собственные, API, как правило, чужие и к ним пишутся многочисленные коннекторы вроде стандарта Singer [1] и тех что собраны в каталоге коннекторов Meltano [2]. Но в целом, и у других инструментов тот же подход, в приоритете подключение к сервисам предоставляющим API. Отсюда возникает ситуация когда инструменты вроде Meltano, Airbyte, Singer, Fivetran и др. очень хорошо заточены под выгрузку на регулярной основе, вплоть до реального времени, из API, и почти не умеют и не адаптированы про то о чём я писал выше - работу с батчами, неструктурированными данными и недокументированным API. Когда я начинал только писать движок в Datacrafter'е про сбор данных - он был как раз про ситуации когда API недокументировано, описания данных нет, файлы лежат батчами или надо из HTML страниц создавать наборы данных. Ссылки: [1] https://www.singer.io [2] https://hub.meltano.com #data #datatools #opendata #apicrafter #datacrafter