О данных, веб-сайтах и том как с ними работают. Я рассказывал что веду архивацию госсайтов, в том числе самописными инструментами, которые архивируют данные из открытых API которые веб-краулеры не поддерживают. Такая утилита есть APIBackuper для сфокусированной архивации и ещё для 5 популярных CMS у которых такое общедоступное API есть по умолчанию. Некоторые владельцы сайтов это API по умолчанию сразу отключают, но у большинства оно доступно и через него можно скачивать весь тот же контент что есть на сайте, только быстрее, удобнее и автоматически.

Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах.

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

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

#tech #government #governmentit #privacy #leaks

Нужно ли создание в России api.gov.ru ?
anonymous poll

Конечно! Пусть Минцифра его создаст, наконец – 85
👍👍👍👍👍👍👍 73%

Нужно, но на госорганы надежды нет, скорее как частный проект – 17
👍 15%

Мне лень отвечать, я просто хочу посмотреть ответы других – 5
▫️ 4%

Не нужно, пусть госорганы сами задокументируют API к своим системами и на этих системах разместят документацию – 4
▫️ 3%

Никому не нужно, некому пользоваться – 3
▫️ 3%

Что? Где? Что такое API? Ничего не понимаю – 3
▫️ 3%

👥 117 people voted so far.

Кстати по итогам моего прошлого опроса/голосования о том о чём я пишу, большинство проголосовавших, как оказалось, заинтересовано в материалах про приватности. Постараюсь добавлять об этом больше публикаций. Хотя мои лично самые любимые темы - это технологии работы с данными и доступность/открытых данных. А вот, как ни странно, международные практики мало кому интересны. Может быть, правда, это искажение инструмента голосования где нельзя проголосовать за несколько вариантов.

#votes #polls

Про формат Parquet я многократно писал и давал ссылки, а вот сравнение от Databricks его же с CSV [1]. Если кратко то CSV проигрывает Parquet по всем статьям, сравнение проводилось в экосистеме Amazon AWS:
- экономия при хранении данных на 87%
- в 34 раза быстрее отрабатываются запросы
- на 99% меньше данных надо сканировать
- финансовая экономия до 99.7%

Недостаток Parquet'а для человекочитаемости компенсируется появлением инструментов для GUI и командной строки которые эту проблему снимают. Она, вообще не так значима как кажется.

Лично я считаю что статистику, многие другие данные с временными рядами и иные большие наборы данных которые сразу берут в работу аналитики, можно и нужно публиковать сразу в Parquet. Это даёт не только экономию в хранении, но и сильно облегчает работу аналитиков. Тем более что многие инструменты вроде Power BI и Tableau их его поддерживают.

Ссылки:
[1] https://databricks.com/glossary/what-is-parquet

#fileformats #data #parquet

У Бэна Стэнсила, основателя и руководителя аналитиками в стартапе Mode, замечательная заметка в его рассылке, с рефлексией о том как компании сейчас потребляют данные и как это возможно в будущем [1]. Основной посыл заметки в том что "фронтэнд разваливается" и приводит в пример десятки разных способов донесения данных через дашборды, тетрадки, сервисы визуализации, разные виды, формы и ориентации BI продукты и так далее. Идея в том что можно ли сделать открытый продукт к которому разные формы потребления данных можно было бы добавлять плагинами? По аналогии с Wordpress'ом и другими аналогичными экосистемными продуктами.

Идея интересная, созвучная многим, включая меня. Хотя я пока и не чувствую что разваливается именно фронтэнд и конечное потребление данных, скорее современный стек данных превращается в набор для сборки, а для кого-то и в паззл где своими силами ты делаешь только то что не можешь собрать из кубиков. Или делаешь то что хочешь продать/продавать. Отсюда и растущий запрос не просто на дата-инженеров, а на платформенных дата-инженеров, а может уже пора ввести понятие data-constructor ?

Когда я сейчас проектирую стартап и продукт по анализу и/или/или не обработки данных, я, как и многие, не мыслю категориями разработать его с нуля. Я смотрю на open source и облачные продукты и понимаю что: вот тут для ELT можно взять вот это, вот тут для BI вот это, вот тут для хранилища вот это, вот тут для сбора данных в реальном времени вот это, для пользовательского интерфейса вот это и так далее.

А рассылка Бэна весьма популярна в среде аналитиков и дата инженеров, всячески его рекомендую.

Ссылки:
[1] https://benn.substack.com/p/business-in-the-back-party-in-the-front

#data #thoughts #reading #dataengineering #bi

Я много раз писал про такое явление как executable papers [1] [2] [3] о том как меняется создание научных статей в сторону написания тетрадок с кодом интегрированных или сопровождающих научный текст.

К этому хочу дополнить ещё один похожий и важный проект Executable books (исполняемые книги). Создание интерактивных книг/справочников/руководств по общему стандарту и с сохранением структуры именно книги. Довольно большое сообщество в Github - Executable book [4] вот уже несколько лет как создаёт Jupyter Book [5], специальный движок позволяющий писать руководства используя тетрадки Jupyter Notebook и предоставляя возможность создавать контент пригодный к публикации и с экспортом в HTML, PDF и другие форматы.

У авторов собрана большая галерея примеров [6], больше всего примеров с описанием open source пакетов по работе с данными. Авторы же даже создали своё расширение для языка Markdown под названием MyST - Markedly Structured Text для более удобного написания технической документации [7].

Executable books и их продукты происходят из научной среды, с командой из 3-х университетов и большим сообществом и поддержкой Alfred P.Sloan Foundation.

На мой взгляд у них есть явно недооценённый коммерческий потенциал. Удобных онлайн сервисов по написанию технической документации и руководств не так много. Есть Readme.io, Gitbook и ещё несколько, со своими достоинствами и недостатками, но не почти не включают часть связанную с "исполнимостью текста".


Ссылки:
[1] https://t.me/begtin/2147
[2] https://t.me/begtin/2607
[3] https://t.me/begtin/3386
[4] https://github.com/executablebooks
[5] https://jupyterbook.org
[6] https://executablebooks.org/en/latest/gallery.html
[7] https://myst-parser.readthedocs.io

#executablebooks #executablepapers #opensource #data #datadocumentations #datatools

В блоге SeattleDataGuy (консультант по дата платформам Ben Rogojan) две публикации про The Baseline Data Stack [1] [2] о том что нет универсального стека ьтехнологий для данных и есть много разных вариантов сборки. Можно сделать полностью на открытом коде, можно на основе ведущих продуктов и можно сделать только на базе облачных продуктов.
Реальность, как правило, где-то посередине, достаточно вспомнить Gitlab у которых смешаны open source Airbyte и dbt, коммерческий Fivetran, хранилище в Snowflake и собственноручно написанный Meltano, уже выделенный в отдельную компанию/стартап/продукт.

Основная мысль в том что под разные задачи - разные решения и это, конечно, так оно и есть. И я также вижу тренд как вначале появляется/давно существует коммерческий продукт, потом кто-то делает open source продукт который воспроизводит ключевые/значимые возможности этого коммерческого продукта и далее _очень быстро_ получают венчурное финансирование на создание облачного продукта на базе этого open source. Раньше такое тоже было, но сейчас всё ускоряется.

Меня, кстати, поражает насколько медленно развиваются Яндекс.Облако и облачные сервисы VK. Фактически если ты работаешь с современным стеком технологий то зарубежные платформы почти безальтернативны. Почти, потому что всегда есть "танцы с бубном", но в целом это так. Вообще в области работы с данными "импортозамещения" очень мало, только замена на open source.


Ссылки:
[1] https://medium.com/coriers/the-baseline-data-stack-going-beyond-the-modern-data-stack-part-1-9791b7d49e85
[2] https://medium.com/coriers/the-baseline-data-stack-the-different-types-of-data-stacks-part-2-c6a826d8f2f1

#data #readings #thoughts

В рубрике полезных наборов данных Unicode Common Locale Data Repository [1] [2], 18 летний проект по систематизации и публикации базы языковых данных включая: переводы названий языков, переводы названий стран, шаблоны для форматирования валют, дат, правила сортировки и ещё много всего.

Большинство из нас с этими данными сталкивается неявно, поскольку CLDR используется в операционных системах и во многих других продуктов где необходимо учитывать местные языковые и иные культурные особенности. Для работы с CLDR есть инструменты для всех наиболее популярных языков программирования, например, для Javscript [3] или Python [4] и многих других.

Традиционно CLDR распространялся в XML формате, но есть и версия в формате JSON [5], одна её сборка в сжатом виде - это около 59МБ, а в распакованном виде около 525MB.

Этот набор данных является скорее большим справочником, в нём нет временных рядов или больших данных для анализа, однако он полезен всем кто занимается "склейкой" данных из разных источников и задачами локализации интерфейсов/инструментов/алгоритмов распознавания шаблонов написания текстов.

Ссылки:
[1] https://ru.wikipedia.org/wiki/Common_Locale_Data_Repository
[2] https://cldr.unicode.org
[3] https://github.com/cldr-tools/cldr-tools
[4] https://github.com/carlospalol/money
[5] https://github.com/unicode-org/cldr-json

#datasets #opendata #dictionaries #data #unicode

Тем временем в РБК статья посвящённая теме нормативной закрытости ведомств [1] со ссылкой на мою заметку про рост числа постановлений и распоряжений Правительства РФ [2].

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

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

В целом у нас накопилась большая аналитическая база по российским НПА. Оно не особо монетизируемо в чистом виде, хотя и есть в DataCrafter'е в разных формах, но много интересных цифр подсчитать можно.

Одно жаль, можно сколь угодно диагностировать болезнь, а вот её лечение в текущей ситуации куда как менее очевидно. Мы все в последнее время превращаемся в "диагностов", без возможности исправления ситуации.

Ссылки:
[1] https://www.rbc.ru/politics/07/02/2022/61fbe8909a794784a2243429
[2] https://t.me/begtin/3511

#russia #npa #laws #legal #statistics

Итого проголосовало 104 человека из которых большинство, 71% за то что нужен api.gov.ru и что хорошо бы Минцифре РФ его создать (наконец) и около 16% за то что только если в рамках частной инициативы.

По моему запрос вполне очевиден.

#opendata #openapi #government

В нашем движке по распознаванию типов данных внутри баз данных, таблиц и файлов теперь 195 правил охватывающих геоданные, данные об организациях, о людях, о медицинских препаратах, финансах, госфинансах, справочниках и классификаторах и так далее. Прежде чем запускать бета-тестирование API, я выложил сам движок как открытый код и он доступен на Github как metacrafter [1].

Главные достоинства по сравнению с аналогичными инструментами:
* легко расширяется новыми правилами, правила описываются в файлах в YAML формате
* быстро работает без дополнительных расширений. Вместо регулярных выражений используются конечные автоматы PyParsing
* обычно такие инструменты работают с колоночными данными, а тут наоборот поддержка любых построчных.
* поддерживает MongoDB, любую СУБД через SQL Alchemy, файлы в форматах CSV, JSON, JSON lines, BSON, Parquet
* прицел именно на распознавание идентфикаторов, а не просто идентификацию PII.

Почему открытый код? Потому что он не единственный такой продукт и именно эта его часть с написанием правил может быть полезна многим. А я лично искренне надеюсь что у него будут пользователи которые помогут с его тестированием и доработкой. Главную коммерческую стоимость здесь имеет не код, а знание как устроены данные и сейчас в открытой версии выложено 25 правил, охватывающие базовые виды данных, а также используется 312 правил-шаблонов определения дат и времени.

Движок можно использовать для применения написанных и написания собственных правил.

Обратите внимение что в среди правил есть правила идентификации персональной информации (PII). Сейчас нет команды поиска только и именно PII, но это несложно добавить.

Плюс в него же встроен веб-сервер для запуска движка распознавания в серверном варианте, с API.

Для того чтобы правила и выявляемые идентификаторы были систематизированы, в отдельном репозитории metacrafter-registry [2] доступны данные по всем идентифицируемым объектам. По списку идентификаторов [3] в нём можно понять, то какие правила существуют и какие данные идентифицируются. Этот реестр будет расширяться, дополняться и пополняться.

Наше коммерческое API использует этот же движок, включает все 195 правил идентификации объектов и скоро будет доступно для бета-тестирования.

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://github.com/apicrafter/metacrafter-registry/blob/main/data/entities.yaml

#metadata #data #opensource

Я, кстати, не писал про весьма любопытный стартап Hyperquery который в декабре вошёл в публичную бету [1] и теперь доступен [2]. Авторы продают инструмент сочетающий SQL запросы и тетрадки (notebooks) в стиле Notion. Фактически - это Notion для команд аналитиков и дата саентистов.

Идея SQL тетрадок не новая, есть Franchise [3] в облаке и как открытый код, есть Query.me [4], есть Count [5].

Достоинство Hyperquery именно в Notion подобном интерфейсе, в том что команды привыкшие к такому интерфейсу заценят его удобство.
Интересное сочетание, на мой взгляд имеет хорошую перспективу если к SQL запросам добавят расширяемую коллекцию способов визуализации.

Ссылки:
[1] https://medium.com/df-foundation/introducing-hyperquerys-public-beta-b871252e99e9
[2] https://www.hyperquery.ai
[3] https://franchise.cloud/
[4] https://query.me/
[5] https://count.co/

#startups #datatools #querytools #notebooks

Humanitarian Data Exchange (HDX) опубликовали доклад The State of Open Humanitarian Data 2022 [1] с подробностями и цифрами их проекта Data Grids по сбору структурированных данных по странам где происходят гуманитарные кризисы. В основном это африканские и азиатские страны, а из постсоветских стран там только Украина упомянута.

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

Для тех кто не знает, HDX [3] - это проект каталога данных Управления по координации гуманитарных вопросов ООН. Там собрано более 18 тысяч наборов данных по гуманитарным кризисам. В отличие от многих других порталов данных, в проекте сильный фокус на данные в привязке к странам и территориям, визуализации и систематизации данных.

Год назад их представитель выступал у нас на Дне открытых данных в Москве и интересно рассказывал что они делают.

Не могу не напомнить что у ООН много проектов на данных и очень много открытых данных в повестке, подборку порталов открытых данных их управлений я приводил ранее на канале [4]

Ссылки:
[1] https://data.humdata.org/dataset/2048a947-5714-4220-905b-e662cbcd14c8/resource/56bb190e-fd43-4573-898c-76aaedb7e10a/download/state-of-open-humanitarian-data-2022.pdf
[2] https://data.humdata.org/dashboards/overview-of-data-grids
[3] https://data.humdata.org
[4] https://t.me/begtin/3310

#opendata #un #hdx #unocha

Я рассказывал про то что у очень многих госорганов/госсайтов/информационных систем есть документированные, плоходокументированные и совсем недокументированное API. Все вместе это частично, объект интереса в задачах сбора и извлечения данных, частично вопрос информационной безопасности и, в значительной степени, вопрос технической квалификации.

Я приведу несколько примеров API на порталах органов власти и их информационных систем.

Росрыболовство
Официальный сайт органа власти (fish.gov.ru) создан на бесплатной CMS Wordpess. Сайт установлен без доп. настроек и с настройками по умолчанию, поэтому из сайта доступно техническое API Wordpress'а [1] через которое можно автоматически выгрузить все их новости, веб-страницы и тд. Похоже на неотключенную возможность у CMS.

Автоматизированная система транспортного комплекса (АСУ ТК)
Сайт АСУ ТК (asutk.ru) создан на базе CMS Sharepoint, по умолчанию API к спискам на сайте и к веб-страницам доступно по технической ссылке [2]. Не видно что API используется где-то на сайте, скорее не отключенная возможность CMS.

Портал уполномоченного органа в сфере электронной подписи
Сайт Минцифры России со сведениями о УЦ и УП (e-trust.gosuslugi.ru) предоставляет недокументированное API, например, для получения списка аккредитованных УЦ [3]. Похоже на API сделанное разработчиками для скорости отображения данных на веб-страницах которые подгружают данные через Ajax запросы.

Цифровой мастер-план города Байкальска
Не совсем государственный, скорее государством заказанный сайт (план.байкальск.рф) отображает данные с помощью Graphql API [4]. Похоже это основной принцип работы сайты через отображение данных через запросы к бэкэнду Graphql.

Я привёл 4 примера из нескольких сотен, именно недокументированных API. Как такие API появляются? Почему часто владельцы данных сами о них не знают?

Основные причины таковы:
1. Неотъемлимая часть CMS или веб-фреймворка. CMS вроде Sharepoint'а или Wordpress предоставляют API по умолчанию, позволяющее скачивать весь общедоступный контент автоматизировано. Аналогично делают некоторые компоненты для существующих CMS.
2. Разработчикам так удобнее. Разработчики привыкшие делать внутренние или закрытые веб-приложения часто переносят эти практики для приложений в открытом доступе и отображают данные через Ajax запросы.
3. Внутреннее API не для всех. Значительно реже, API делается для себя/каких-то команд которые работают с данными, но не документируется, не описывается и тд. Часто можно найти в документах техзаданий к госконтрактам.

Есть порталы где API декоративно и запросы автоматически блокируются после 5-10 обращений в минуту. Есть порталы где API - это основной способ предоставлять информацию. В одном только портале электронного бюджета более 100 API к данным.

Ссылки:
[1] https://fish.gov.ru/wp-json/
[2] https://asutk.ru/_api/Web/
[3] https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/list
[4] https://api-dmp-baykalsk.chg.one/v1/graphql

#opendata #openapi #api #government

Полный слепок всех данных из портала Data.gov.ru выложен на Хаб открытых данных [1]. Это архив в 13ГБ, после распаковки 29 ГБ.

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

Ссылки:
[1] https://hubofdata.ru/dataset/datagovru-20220202

#opendata #data #dataports #ruarxive

В рубрике интересных инструментов по работе с данными Mercury [1], утилита по преобразованию тетрадок с Python в веб приложения и возможностью запуска их с определёнными параметрами.

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

А может и другие применения есть.

Ссылки:
[1] https://github.com/mljar/mercury
[2] http://mercury-demo-1.herokuapp.com/

#datatools #notebooks #python #opensource

Вышла новая версия Metabase [1] опенсорсной и облачной системы визуализации дашбордами (BI системы). В этой версии добавили поддержку моделей и возможности моделирования структуры отображаемых данных для нетехнических пользователей и, в принципе, видно что продукт эволюционирует в сторону повышения его доступености для аналитиков без технического бэкграунда и большей поддержке облачных продуктов.

Собственно основные продукты по визуализации данных с открытым кодом готовые к быстрому корпоративному применению - это Metabase и Superset. Изменения в них весьма интересны.

Ссылки:
[1] https://www.metabase.com/blog/Metabase-0.42/index.html

# datatools #cloud #bi #metabase #opensource

Написал в рассылку о судьбе NoSQL в современном стеке данных [1]. Могу сказать что сейчас NoSQL и современные инструменты - это плохо сочетающиеся комбинации, как минимум в ряде задач. Это создает как проблемы, так и коммерческие возможности

Ссылки:
[1] https://begtin.substack.com/p/23

#datatools #mailing #nosql #mongodb

Минцифры анонсировали поддержку раскрытия исходного кода и открытую государственную лицензию для открытого кода публикуемого от лица Российской Федерации и выставили проект НПА на обсуждение [1]

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

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

Ссылки:
[1] http://regulation.gov.ru/p/124850

#opensource #sourcecode #digital

Если университет проводит хакатоны на данных и не может опубликовать ни одного набора данных в открытом доступе, то это, конечно, то грош цена таким хакатонам. (c)

Кстати, в Испании 12 университетов публикуют свои данные на национальном портале открытых данных data.gob.es [1], а Университет Сарагосы опубликовал уже 341 набор данных.

В основном это административные данные о жизни университетов, их обязательной финансовой отчетности, статистике и образовательному процессу. Потому что раскрытие данных о научной деятельности обычно идёт по другим каналам - порталам публикации научных данных вроде Zenodo и других проектов открытого доступа.

Ссылки:
[1] https://datos.gob.es/es/catalogo?administration_level=U

#opendata #data

Продолжая тему недокументированных государственных API приведу ещё один живой пример с некоторыми техническими подробностями.

Вот, в Санкт-Петербурге есть портал бюджетных инициатив граждан [1]. В целом неплохой, современно выглядящий и с примерно 29 тысячами опубликованных инициатив. Когда я в целях архивации региональных сайтов бюджетов пытался его заархивировать то столкнулся с тем что у него нет веб-страниц в нормальном понимании. Вместо этого даннные отдаются через API по вполне легко находимой ссылке /api/v2/budget/initiatives [2] в коде страницы, в HTML коде сайта видно что что API передаётся параметр offset для перехода к следующей порции данных и limit для ограничений числа получаемых данных. В результате все инициативы можно выкачать простым перебором. Запросы к API возвращают в JSON формате общее число объектов в поле total_count и список объектов в поле objects в каждом ответе.

Особенность в том что это типовая задача. Не только на этом сайте и не только в этом API данные публикуются именно таким образом. В принципе вариации мышления и логики разработчиков очень невелики, всего 5-6 базовых сценария. Поэтому когда-то давно, 2 года назад я сделал ручную утилиту apibackuper [3] которую считаю личным вкладом в дело цифровой архивации;)

Утилита создана чтобы автоматизировать именно выгрузку данны из API, так чтобы всё можно было описать простыми параметрами в конфигурационном файле и запустить выгрузку. Не открою большого секрета в том что по объёму около 75% данных в Датакрафере [4] скачано именно с помощью apibackuper, фактически над этой утилитой просто возведена надстройка по автогенерации из API в процессе обнаружения данных.

В отличие от HTML парсеров утилита умеет проходить по всем страницам API, выгружать индивидуальные объекты при необходимости и складывать файлы в локальное хранилище или в S3 совместимое, а также экспортировать данные в JSONL формат. Для простоты все промежуточные файлы хранятся в ZIP контейнере и экспортируются по запросу. Всё описыается в .cfg файле

Пример который я озвучивал выше, с инициативами на портале инициативного бюджетирования СПб один из самых простых. Я специально его выложил онлайн как открытый код [4] хотя именно кода там мало, собственно .cfg файл необходимый для выполнения команд и набор этих команд прост.
- apibackuper estimage - оценить длительность и число запросов по выгрузке данных
- apibackuper run - запустить выгрузку данных
- apibackuper export data.jsonl - экспортировать данные в формат jsonl в файл data.jsonl
- apibackuper getfiles - выгрузить все изображения по ссылкам images.image.url

Когда-то я делал эту утилиту для архивации материалов с сайта Мэрии Москвы, там почти весь контент через API, и портала электронного бюджета. Сейчас, как я говорил, эта маленькая программа помогает собирать и большого числа документированных и недокументированных государственных API для архивации и для каталога данных.

Ссылки:
[1] https://tvoybudget.spb.ru
[2] https://tvoybudget.spb.ru/api/v2/budget/initiatives
[3] https://github.com/ruarxive/apibackuper
[4] https://data.apicrafter.ru
[5] https://github.com/ruarxive/apibackuper-example-spbbudget
[6] https://github.com/ruarxive/apibackuper-example-spbbudget/blob/main/apibackuper.cfg

#opendata #datatools #opensource