После экспериментов с простым кодом, я постепенно добрался до тех инструментов которые используются внутри Dateno для сбора данных. Один из них это утилита apibackuper которая помогает вытащить данные публикуемые через API и сохранять их в виде датасета. Фактически это инструмент скрейпинга API через декларативное описание параметров скрейпинга (да, я люблю декларативные описания). У инструмента был ряд недостатков которые я исправлял и думаю что исправил, вот перечень изменений:
- переход от декларативного описания скрейперов с INI (.cfg) файлов на YAML, читать легче, синтаксис приятнее
- валидация YAML описаний через JSON схему
- поддержка ограченичений и таймаутов на число запросов в минуту (Rate Limiting)
- поддержка аутентификации к API
- экспорт данных не только в JSONL, но и в Parquet
- автоопределение формата экспорта данных по расширению файла
- массовое обработка исключений и понятные сообщения об ошибках везде где возможно
- тесты для покрытия большей части кода
- подробная документация
- и всякое по мелочи

Я этот инструмент изначально разрабатывал для для архивации данных публикуемых через API, но сейчас он используется в части кода Dateno для выгрузки метаданных из каталогов данных. Может его даже пора уже перенести из ruarxive в dateno на Github'е, ещё не решил.

На скриншоте то как это выглядит на примере реестра лекарственных средств ЕСКЛП

Для сбора данных достаточно выполнить две команды
- apibackuper run
- apibackuper export current.parquet

Первая выгрузит все данные постранично, вторая сохранит выгруженные данные в parquet файл.

#opensource #datatools #data #dataengineering

В рубрике полезных инструментов для сбора данных tdl (Telegram Downloader) инструмент командной строки,написан на Go, под лицензией AGPL-3.0, позволяет выгружать списки сообщений, сами сообщения и файлы и проводить другие манипуляции по выгрузке списков чатов, их участников и другой информации.

Выглядит как полезный инструмент для разных задач: мониторинга телеграм каналов, OSINT, создания наборов данных по тематикам и, конечно, цифровой архивации. Для последней задачи инструмент хорошо бы доработать и добавить команду "archive" для создания или обновления полного слепка данных, но можно и сделать надстройку над этой утилитой.

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

Мне лично нравится как сделан этот инструмент по архитектуре, логике команд, набору опций (выкачивать только сообщения, скачивать медиа) и так далее. Хотелось бы такой же, но универсальный для разных платформ и соцсетей или даже отдельные для других платформ сделанные по схожей логике. Для РФ скоро будет актуален инструмент для выгрузки чатов и каналов в MAX потому что у MAX'а нет открытой веб версии без авторизации как это есть у телеграм'а (пример - https://t.me/s/begtin) и все что создается внутри платформы не архивируется. Но это уже отдельная тема.

Пока же tdl полезный инструмент для телеграма и хорошая референсная реализация подобных инструментов для других задач.

#opendata #opensource #digitalpreservation #data #tools

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

Есть три основных категории пользователей и у каждой из них свой набор ожиданий :
1. Аналитики
- максимальная оперативность данных
- доступность данных в форматах привычных для работы (CSV, XLSX)
- возможность доступа к данным аналитическими и No code/Low code инструментами
- наличие данных по ключевым наиболее значимым темам (официальная и ведомственная статистика, например)

2. Исследователи
- доступность данных по научным дисциплинам, в открытом или регламентированном доступе (когда известно кого спросить, какие правила необходимо соблюсти и какие условия доступа к данным)
- наличие DOI у датасетов
- возможность работы с данными инструментами принятым в среде их научной дисциплины, разные для экономистов, биоинформатиков, физиков, геофизиков, астрономов и тд.
- наличие четкой прослеживаемости данных и методологии их получения

3. Разработчики и дата инженеры
- доступность данных через API
- доступность данных для массовой выгрузки (bulk download)
- доступность схем и структур данных
- наличие данных в современных форматах для выгрузки: сжатые CSV, Parquet и др.
- наличие предсказуемой инфраструктуры для интеграции с ETL/ELT системами получения данных
———
У этих 3-х групп есть ряд подгрупп которые имеют свою специфику:
- журналисты. Имеют те же требования что и аналитики, с меньшим погружением в технологии, с большим погружением в доступность данных.
- AI/ML инженеры. Помимо ожиданий разработчиков и дата инженеров у них еще присутствует потребность именно в данных большого объема для обучения, интегрируемость в стеки данных и интегрируемость в продуктами вроде Hugging Face
- статистики. Это не только сотрудники статслужб, но и профессиональные пользователи их данных. Они могут быть аналитиками и исследователями и тут важным становится наличие значимых метаданных и специальных стандартов и форматов SDMX, DDI и тд.
- геоаналитики и георазработчики. Подгруппы аналитиков и разработчиков с упором на геоданные, ключевое здесь это наличие возможности поиска данных по геопривязке, получению их в форме стандартизированных API ArcGIS/OGC и возможность выгрузки в наиболее востребованных форматах геоданных
—
Пользователь может быть в одной роли или хоть сразу в нескольких, важно то что любые публикуемые данные и создаваемые дата каталоги можно четко разметить по их потенциальным пользователям.

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

К примеру, когда я ругаюсь в адрес российского портала data.gov.ru, то могу объяснить это довольно просто. Можно посмотреть на него глазами любой из перечисленных ролей/групп пользователей и убедиться что для их задач он непригоден.

#opendata #users #thoughts #data

В рубрике интересных каталогов данных сеть порталов для публикации онтологий:
- https://biodivportal.gfbio.org/ - портал по онтологиям по биоразнообразию
- https://bioportal.bioontology.org/ - портал биомедицинским онтологиям
- https://technoportal.hevs.ch/ - репозиторий онтологий по технологиям и инженерии
- https://earthportal.eu/ - портал онтологий по наукам о Земле.
- ... и многие другие

Полный их список можно найти на сайте продукта с открытым кодом OntoPortal на котором они созданы. Их особенность в том что это порталы метаданных/справочников с описанием разного рода сложных понятий, весьма распространенные в биоинформатике в первую очередь и чуть меньше в других науках.

Их можно относить к каталогам данных, я их также вношу в реестр каталогов данных Dateno и их также можно индексировать в поисковой системе, хотя объём проиндексированного будет невелик, но полезен для некоторых категорий пользователей.

#opendata #datasets #data #datacatalogs #ontologies #linkeddata

Полезное чтение про данные, технологии и не только:
- Compute Is the New Oil статья в FA о том что чипы для ИИ стали основной для дипломатии США и стран Персидского залива и о том что вычислительные мощности - это новая нефть. Ну вы меня поняли, теперь если кто-то ляпнет что "данные - это новая нефть", то можно записывать его в древние ретрограды, потому что теперь чипы-чипы-чипы. По крайней мере на уровне глобальной дипломатии
- The Nation’s Data at Risk: 2025 Report доклад американской ассоциации статистиков о кризисе статистики в США, много критики, много рекомендаций в центре которого восполнение дефицита сотрудников, но еще много всего. Хочется тут конечно понять что если в США в статистике кризис, то что в России, апокалипсис? Армагеддон? Все познается в сравнении
- Personal Data Architectures in the BRICS Countries книга о персональных данных в странах БРИКС в Oxford Press, ещё не читал, но любопытно по некоторым странам. Есть правда подозрение что авторы могут недостаточно понимать внутреннюю кухню и смотрят на это глазами кабинетных исследователей

#readings #privacy #statistics #data

В рубрике полезного чтения про данные, технологии и не только:
- Saloni's guide to data visualization гайд по визуализации данных с акцентом на наглядность научных данных, хорошие примеры, понятные советы
- Useful patterns for building HTML tools обзор HTML инструментов, в том числе созданных с помощью LLM.Немного за пределами моих интересов, но взгляд на эти инструменты который я лично упускал.
- Economics of Orbital vs Terrestrial Data Centers про обоснованность и возможность создания дата центров на орбите Земли. Любопытно, хотя и не кажется практичным в ближайшие годы
- Cloudflare Radar 2025 Year обзор трендов 2025 года от Cloudflare, обзор большой, в том числе страновой и есть что посмотреть по разным странам. Тянет на отдельную заметку, а пока просто закладка на чтение

#readings #data #dataviz

Ещё в рубрике как это устроено у них FranceArchives официальный архивный портал Франции. Включает более 29 миллионов записей из которых более 5 миллионов - это оцифрованные документы, фотографии, карты и иные цифровые артефакты агрегированные из сотен музеев и архивов страны.

Предоставляют открытое API в виде интерфейса SPARQL, у каждой записи есть RDF, JSON-LD и N3 карточки с описанием со всеми метаданными в структурированой форме и есть возможность получить карточку записи в виде CSV файла.

#opendata #data #digitalpreservation

В продолжение истории про документы выложенные Минюстом США и в которых замазанный текст легко распознается я скажу вам что совершенно не удивлен и косяков госорганов и корпоратов в работе с документами и данными я знаю много, хотя и рассказывать про большую часть не могу и не хочу потому что не чувствую своей принадлежности к рынкам инфобеза и OSINT. Расскажу лишь некоторые примеры не называя имен

1. Скрытые, но доступные данные в недокументированном API
Госорган создает общедоступный портал с некоторой информацией и портал построен по уже классической трехзвенной структуре: База данных -> Слой API -> Веб интерфейс. При этом все ограничения в доступе к данным делаются только на уровне веб интерфейса, а через API вполне можно собирать записи имеющие статус "удаленные" или "черновики". Ситуация вообще не редкая и возникает от недостатка квалификации постановщика задачи, разработчиков и недостаточного тестирования

2. Скрытые данные в общедоступных материалах
Многие форматы публикации текстов, таблиц и изображений имеют свои особенности позволяющие как скрывать часть содержания так и "раскрывать" его. Пример с закрашиванием PDF файлов всем хорошо известен, а есть, к примеру, случаи когда публикуются Excel файлы со скрытыми вкладками, частенько когда публикуют статистику ее рассчитывают на более детальных первичных данных в другой вкладке, а потом эту вкладку скрывают, а не удаляют. Так чувствительные данные внутри Excel файлов становятся общедоступными. Есть и другие случаи когда одни файлы MS Office погружают в другие, а когда запускают процесс удаления метаданных он вырезает метаданные из основного контейнера, но не удаляет их из внедренных файлов. И так далее, это только то что совсем на поверхности

3. Доступное API стандартизированного ПО
Организация выбирает стандартизированное ПО для сайта, а у этого стандартизированного ПО (CMS) есть какое-то количество опять же стандартно общедоступных API о которых они могут и не подозревать. Я привожу часто в пример WordPress у которого есть открытые эндпоинты дающие возможность находить документы ссылок на которые может не быть на сайте, но сами файлы остаются. Например, если кто-то загружает документ в WordPress и потом делиться на него с кем-то по прямой ссылке, то даже если на страницах сайта этого документа нет, то в API он доступен. WordPress - это пример, кроме него есть немало других CMS и веб фреймворков имеющих такую особенность
—
Насмотревшись всего этого в больших количествах я совершенно не удивляюсь когда вижу как в очередной раз кто-то попадается на такой лаже как "затереть текст в PDF файле", думаю что еще не раз такое будет.

А я про такое пишу пореже потому что лично мне открытые данные и дата инженерия куда интереснее, кроме того рассказывая какой-либо кейс с такими утечками данных всегда велика вероятность что канал утечки исчезнет;)

#thoughts #osint #data #privacy

Полезное чтение про данные, технологии и не только:
- How to Stay Ahead of AI as an Early-Career Engineer в IEEE Spectrum о том как меняются требования к джуниорам в ИТ на фоне применения ИИ. Если вкратце то требования к кандидатам растут, хуже всего тем кто умеет не начальном уровне кодить и не вкладывался в собственное развитие многие годы. Ключевой вопрос в том как должно меняться образование?
- Congress: Protect NCAR and Climate Research союзе обеспокоенных ученых в США призывает остановить закрытие Национального центра атмосферных исследований (NCAR) США которое недавно было анонсировано администрацией Трампа
- The Hidden Price of Data статья в журнале IMF про то как измерять стоимость данных в экономике и экономическими методами, автор статьи написала книгу на эту тему, тоже полезную для понимания того как экономика данных устроена.
- Instagram CLI для тех кто любит текстовые терминалы и серьезное намерен бороться с "гниеним мозга" (brainrot) утилита для работы с инстаграмом с командной строки. Я бы пошел дальше и вместо отображения изображения сразу бы давал текстовое описание извлеченное из него с помощью LLM

#ai #instagram #data #careers #it

(Часть вторая)

3. Резкое падение стоимости создания наборов данных
Звучит парадоксально, но факт, с прогрессом ИИ агентов создать данные из существующих материалов в любой форме проще чем просить предоставить их в машиночитаемом виде. Реальные ограничения возникают только в отношении данных которые недоступны ни в каком виде, но если они всё таки есть, хоть сканами, хоть запутанными текстами, датасеты из них собираются. Это сразу же меняет несколько важных нарративов.

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

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

У меня есть живой пример подобного когда я давно откладывал задачу получения статистики из Статбанка Армении (statbank.armstat.am) из-за того что у них было поломано API и древняя версия ПО на котором он сделан. Развилка была в том чтобы:
a) Попросить у них данные (ждать пришлось бы долго и это не системное решение)
б) Заплатить фрилансеру написать парсер
в) Сделать парсер за пару часов с помощью ИИ агента

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

Условно зачем убеждать, к примеру, Пр-во Армении публиковать данные если мы и так их соберем и опубликуем на opendata.am ? Шутка, убеждать конечно же надо, но думаю что идея ясна.
—

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

#thoughts #openness #data #opendata #openaccess

Полезный ежегодный обзор баз данных в тексте Databases in 2025: A Year in Review от Andy Pavlov.
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения

В оригинальном обзоре много ссылок и других событий

#data #rdbms #readings

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

Но это лишь один уровень оптимизации, далее вопрос в выборочной обработке данных. Почему в какой-то момент так выстрелил довольно старый формат Parquet? Помимо хорошей компресии и возможности быстрого чтения данных он ещё и дает возможность выборочного чтения и фильтрации данных. К примеру, в отношении XML файлов это уже не работает, в отношении JSON, с большими ограничениями (для JSONl да, в остальных случаях нет) и так далее. А ещё есть огромное число форматов имеющих предметное и отраслевое применение где всё что можно - это, либо считывать их в память целиком, или перебирать содержание по каждой записи.

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

В качестве регулярных напоминаний, большое количество открытого кода который я лично создавал и поддерживаю:
- iterabledata библиотека для Python по работе с любыми файлами с записями с помощью прямого их перебора и возвращением каждой записи как словаря (dict). Фактически реализация интерфейсов csv.DictReader и csv.DictWriter для десятков форматов файлов таких как JSON, JSON lines, XML, Parquet, ORC и множества более специфических и отраслевых таких как PCAP, WARC и др.
- internacia-db референсная база данных с базовыми данными по странам и по страновым блокам. Распространяется в форматах JSONL, Parquet, DuckDB, YAML. Полезно для задач обогащения данных, поиска и фильтрации результатов в территориальной привязке, сравнении стран и территориальных блоков.
- undatum это инструмент командной строки для работы с файлами со сложной иерархией так как работают с CSV файлами. Он умеет считать статистику, преобразовывать файлы, анализировать их, разрезать на части и тд. Внутри используется библиотека iterabledata и большое число форматов файлов поддерживаются
- metacrafter библиотека для Python и инструмент командной строки для работы с семантическими типами данных, используется для выявления персональных идентификаторов и иных объектов (кодов организаций, кадастровых и почтовых кодов и так далее)

А также много другого открытого кода о котором я регулярно тут пишу.

#opensource #data #dataengineering #datatools

Фонд Викимедиа анонсировал партнерство с ещё несколькими ИИ бигтехами - это Amazon, Meta, Microsoft и Mistral AI, вдобавок к уже имевшимся партнерствам с Google, Ecosia, Nomic, Pleias, ProRata и Reef Media. Можно сказать что, вполне возможно, у Википедии появится таки устойчивое финансирование и проект будет жить. Это с одной стороны, с другой стороны не превратится ли в Викимедиа в коммерческий продукт под видом некоммерческого и не оттолкнет ли это многих редакторов от вклада в её тексты? Я слишком мало знаю о том что происходит там внутри, так что интересно. Что еще интересно так то что AI крупняк, не считая X.ai с его Грокипедией, не пытается воспроизвести продукты Фонда, а заключает соглашения с ним. Полагаю что причиной может быть и то что у Фонда Викимедиа есть техническая возможность ограничивать ИИ краулеры, а одни лишь дампы Википроектов содержат только текстовый контент и не в реальном времени.

#opendata #API #wikipedia #data #ai