Был запущен в марте 2025 года, сейчас включает 6362 наборов данных преимущественно в виде таблиц, текстов и геоданных.

Более половины данных происходят из области естественных наук, много лингвистических данных из Språkbanken Text.

Не все данные размещены на самом портале, многие ведут на оригинальные публикации в национальных и международных репозиториях данных.

Шведы не единственные кто создает национальные агрегаторы научных данных, в некоторых странах существуют агрегаторы любых результатов научной деятельности (Евросоюз, Германия), в других именно данных (Китай, Венгрия).

Про дата продукты

Еще немного размышлений вслух про дата продукты и открытые данные. Я поизучал спецификацию ODPS (Open Data Product Specification) в её последней редакции версии 4.1. Её, кстати, правильно читать не как спецификацию про открытые дата продукты, а как открытую спецификацию на дата продукты. Это, конечно, неплохой документ и чуть ли не единственный описывающий данные именно к продукт и спецификация сама по себе имеет ценность не только для технического описания, но и как шаблона для внутреннего описания дата продуктов. Условно хороший документ спецификации для API к доступу к данным на этапе проектирования (скорее продуктового чем технического).

Но, при этом, со своими ограничениями:

1. Малая экосистема. У дата продукта может быть более одного интерфейса, это могут быть данные доступные через REST API, в формате для массовой выгрузки (bulk download), в формате специализированного API (WFC и OGC совместимые). Хотя в спецификации это всё предусмотрено, но каждый из этих интерфейсов, но нехватает инструментов тестирования этих множественных интерфейсов на основе спецификации.

2. Интеграция с ИИ агентами. Наличие ссылок на документацию - это важно, и, ИМХО, важно не просто наличие human-readable документации, но и документации для ИИ агента (в виде markdown похоже) для автоматизированного доступа к дата продукту.

Как я понимаю в части работы с общедоступными данными у ODPS есть реализация внутри X-Road, но при этом общедоступно действующих примеров нет и нет примеров её использования наиболее продвинутыми создателями открытых дата продуктов в госсекторе, к примеру, государственные API во Франции не описываются через ODPS хотя их описание и документация наиболее близки именно к описанию дата продуктов.

В принципе лично меня это смущает более всего, я знаю довольно много дата продуктов которые могли бы быть описаны с помощью ODPS, но не описываются по какой-то причине. Я подозреваю по той что за спецификацией не стоит кто-то достаточно крупный кто внедрил бы это в свой достаточно популярный каталог дата продуктов. К примеру достаточно крупных агрегатор сервисов API (но им спецификация не вполне подходит) или дата маркетплейс (таких крупных не так много). Кто-то вроде бывшего Quandl’а мог бы использовать подобную спецификацию.

Разные мысли вслух

• инструменты мониторинга потребления токенов и запросов к LLM становятся всё более актуальными. Что-то вроде deepeval или phoenix и других. Характерно, что в мире такие решения существуют и интегрированы со всеми основными сервисами, а российские сервисы типа Яндекса и Сбера исключены из мировой экосистемы. Это отдельная тема для размышлений: изменится ли это как-либо или нет.

• единственные по-настоящему успешные бизнесы, связанные с открытыми данными, не являются бизнесами на самих открытых данных, а бизнесами на инфраструктуре вокруг них. Hugging Face сейчас крупнейший хостинг данных для обучения ИИ, но это не бизнес на открытых данных, хотя портал и наполнен ими. Другой пример — Esri. Я наблюдаю, как всё больше городских порталов данных и геоданных создаются на их платформе, но бизнес Esri не в них, а в том, что создатели порталов используют их сервисы, а портал по открытости данных/геоданных создают в довесок.

• У меня есть типовая задача по deep research с тестированием одной из идей развития Dateno. Она неплохо структурировано для аналитики результатом которой должна быть и оценка бизнес ниши и техническое проектирование. Я регулярно проверяю новые ИИ агенты на этой задаче. Что хорошо - оценку бизнес ниши parallel.ai выдал очень четкую, не идеальную, но логичную. А вот с техническим проектированием не очень. Я до этого сравнивал с десяток сервисов способных в deep research (Perplexity, ChatGPT, Kimi, MiroMind, Gemini, Antigravity, Cursor и др.) и пока только Kimi и MiroMind выдавали наиболее интересный результат в части продумывания архитектуры ПО.

Полезные ссылки про данные, технологии и не только

Полезные ссылки про данные, технологии и не только:

• anton ИИ агент для анализа данных и построения дашбордов. Позволяет быстро сделать дашборды не привлекая внимания санитаров выделенного аналитика. Выглядит как минимум любопытно, открытый код, AGPL. Но завязано на платформу MindsDB командой которой он и создан. У MindsDB минимальная подписка это $35 в месяц с привязкой карты, что для работы немного, а для тестирования, особенно когда тестируешь много сервисов, себя не оправдывает. Был бы аналогичный platform-agnostic инструмент - ценность его была бы выше для пользователей. Думаю что еще появится если еще не появился. P.S. Не понимаю тех кто называет продукты распространенными человеческими именами, не любят они людей.

• OpenScreen многоплатформенный инструмент для создания демок к софтверным продуктам. Открытый код, MIT, выглядит как наглядный и зрелый продукт. На практике надо проверять, если все как в его демо то можно использовать для создания пользовательской документации, презентаций инвесторам и тд.

• whylogs библиотека для ведения логов в задачах машинного обучения. Существует достаточно давно и, кроме всего прочего, умеет суммаризировать датасеты и выдавать их статистические профили. Не так много таких инструментов существует, как ни странно, а для данных очень большого объёма их практически нет, поскольку почти всегда они работают через датафреймы. Whylogs тоже основан на датафреймах поэтому и применимость его ограничена.

• Nicholas Carlini - Black-hat LLMs | [un]prompted 2026 том как применять LLM (в данном случае Anthropic) для поиска 0-day уязвимостей. Полезно для тех кто занимается безопасностью ПО в любой шляпе.

• parallel.ai онлайн ИИ агент с ориентацией на машинное использование (хотя формат вывода для людей тоже есть) и умеющий в поиск, deep research и тд. Как продукт выглядит интересно и в части вывода промежуточной информации в процессе работы над задачами и в части в том что он сделан в формате machine-first и API-first (машинная выдача и доступ через API/MCP выведены в приоритет). Я его на автоматических задачах еще не проверял, только сравнивал работу в режиме deep research с другими сервисами.

Great Data Products ещё один взгляд на открытые данные от основателей source.coop, платформы для публикации данных большого объёма, преимущественно геоданных. Автор делает экскурс в историю открытости данных, с акцентом на данные для исследователей публикуемые в США, с отсылками к первым большим изменениям в регулировании к 2003 году. Но при этом автор говорит о неопределенности слова “open” и предлагает ввести понятие “great” и акцент не на открытых датасетах, а на дата продуктах. Разница в том что дата продукты документированы, сопровождаются, имеют измеримую стоимость создания и поддержания и понятную стоимость для потребителей.

Это очень похоже на концепцию 3-й волны открытых данных (publish with the purpose) и акценте на понимании пользователей и ценности данных для пользователей.

Собственно он приводит в пример Scoop.coop, CommonCrawl, Open Supply Hub и другие специализированные НКО созданные вокруг дата продуктов и экосистемы вокруг дата продуктов.

Ко всему автор ведет и любопытный подкаст с одноименным названием.

И вдогонку к этому тексту пример проекта в виде дата продукта базы штормовых событий на основе данных NOAA с API и специализированным веб интерфейсом для их отображения.

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

Распространение STAC сервисов для геоданных

Для меня открытие этого года в том сколько спешно-успешно распространяются сервисы для доступа к геоданным на базе спецификации STAC (SpatioTemporal Asset Catalogs) . Я как раз обновляю реестр каталогов данных Dateno и у меня сервисов поддерживающих спецификацию STAC накопилось уже 168. Скорее будет больше. При этом изначально я их классифицировал как отдельное ПО, потому что большая часть сервисов были на базе референсных реализаций, а правильнее классифицировать как протокол, а ПО определять иначе. Например, после появления расширения STAC для Geoserver (ПО с открытым кодом для создания OGC совместимых API, используется по всему миру)

Особенность спецификации STAC в том что из нее сложно преобразовывать в другие спецификации и отсюда сложность в индексации в Dateno. То что обычно называют датасетом в STAC называется каталогом, в рамках этого каталога публикуются ресурсы охватывающие территорию заданную этим каталогом, но в разные промежутки времени (еженедельно, ежедневно, ежечасно и тд). В результате внутри одного набора данных могут быть тысячи и миллионы файлов. Рассматривать ресурсы как отдельные наборы данных будет некорректно, а как отображать карточки с таким числом файлов непонятно.

И, кстати, перечень каталогов STAC сервисов на StacIndex неполон, у нас в реестре Dateno полнее будет, а в живой природе их сильно больше потому что, как я упоминал, он теперь поддерживается расширением GeoServer’а, а этих инсталляций в мире очень много.

P.S. Кстати, у Роскосмоса тоже есть открытый STAC каталог, с декларируемыми примерно 200ТБ данными. Явление необычное при нынешнем тренде в РФ на закрытость.

Digital Public Infrastructure

Я ранее уже писал про Digital Public Infrastructure, то что государства создают цифровую инфраструктуру которую можно рассматривать как одну из форм общественной инфраструктуры и общественного блага, примерно как дороги, или общественные здания и тому подобное.

Оказывается существует The Digital Infrastructure Map проект по мэппингу национальных цифровых проектов по идентификации пользователей, цифровым платежам и инфраструктуре обмена данными и там же есть датасет с данными. Данных там количественно немного, а вот качественно немало.

Что можно оттуда узнать:

1. В большинстве стран создана или создается инфраструктура обмена данными

2. Самый популярный инструмент для этого вышедший из Эстонии X-Road и относительно недавно превращенный в Digital Public Good (не так уж недавно, на самом деле)

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

4. Ожидаемо российские технологии где-либо за пределами РФ отсутствуют.

#opendata #data #datasets #geodata #dataproducts

Архивы Вики проектов

Для тех кто интересуется где можно найти материалы многих, в том числе закрытых, Wiki проектов в мире. Команда Wikiteam (из ArchiveTeam регулярно архивирует вики сайты и результаты их архивации доступны в одноименной коллекции Wikiteam и Интернет Архиве.

Контент сохраняется в форматах XML и в виде архивов с изображениями.

Для тех кто хотел бы архивировать сайты на базе MediaWiki самостоятельно, существует открытый код инструмента wikiteam3.

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

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

Deutchland Stack

Знаете ли вы что... в Германии существует инициатива Deutchland-Stack как список обязательных и рекомендуемых открытых стандартов и технологий для использования в государственном секторе. Там есть множество стандартов по самым разным категориям: данные, low-code, интеграция, AI, транспортные протоколы и многое другое. Довольно хорошо описанные, оформленные и почти все с открытым кодом (кроме iOS для Apple)

Картинка и сайты основаны на базе Cloud Native Landscape у которого есть открытый код.

Удаление данных Администрацией Трампа

Хронология удаления администрацией Дональда Трампа данных из открытого доступа опубликовано в журнале Passport Общества историков Американских внешних отношений (SHAFR)

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

И, кстати, как я и предполагал США официально вышли из Open Government Partnership (OGP). Это не означает закрытие проектов по открытости внутри США, они всегда были отвязаны от международных обязательств, кроме малого числа случаев. Это означает, в первую очередь, прекращение финансирования OGP со стороны США и потенциальный кризис организации если страны ЕС и др. не компенсируют выпадающие средства.

Новые ограничения на доступ к VPN в России

Я тут думал как бы прокомментировать идущие и грядущие блокировки Интернета в РФ. По моему то что предсказания ИА Панорама начали сбываться это более чем иллюстративно к нынешней российской реальности.

Если коротко то политические решения однозначно начали доминировать над экономическими. Нарушается не только личное, но и любое профессиональное общение с теми кто живет и работает в странах с которыми Россия (пока что) торгует. Экономическое воздействие ограничительных мер если и анализируется, то очень секретно, а больше похоже что никак не анализируется. Социальное пространство сильно сжимается и это не одноразовое действие - это ежедневно ощущаемая людьми невозможность общаться с семьёй, друзьями, коллегами и тд.

Ограничения - это хреново, самоизоляция страны это ещё хуже. Я слышу как ощущения “осажденной крепости” у многих сменяется тем что осада то идет не снаружи, а изнутри.

У тех кто еще как-то умудрялся оставаться в России и работать на компании не в России, теперь всё жестче стоит выбор уезжать безвозвратно.

Печально это всё.

Отчет об открытых данных во Франции

FlowDataGouv проект с открытым кодом с результатами анализа 74 тысяч наборов и 384 тысяч ресурсов опубликованных во Франции на портале data.gouv.fr. Результаты доступны в репозитории и в виде PDF отчета.

Если коротко, то данных много, охватывают все регионы Франции, какие-то больше, какие-то меньше

Большая часть данных доступны, мертвых только 14 тысяч ссылок на ресурсы.

Тексты на французском языке, но всё довольно понятно и так.

Такие исследования стало сильно проще проводить используя ИИ ассистенты, в данном случае автор использовал Mistal + Claude и проделал исследование за январь-март 2026 года

Сегодня утром я выступал на конференции Digital Qazaqstan 2026 в Шымкенте, рассказывал про Dateno, Open Data Armenia, про открытые данные в целом, о том как страны могут развивать практики публикации данных. Презентация прошла успешно, судя по числу людей с кем я потом переговорил по итогам. Мероприятие целиком отличное и Шымкент город красивый.

А, помимо моего выступления, я немного послушал о чем говорили на сессии премьер министры стран и структурно это звучало примерно так:

• Казахстан: у нас лучшие цифровые услуги, мы делаем свой государственный LLM и SLM и наши услуги будут еще лучше

• Беларусь: У нас отличный ИТ парк и наши сельхозпроизводители роботизируются ( очень мало про цифровые услуги)

• Узбекистан: У нас есть ИТ парк, программа для стартапов и мы хотим улучшить кредитование ИТ компаний. И да, у нас отличные цифровые услуги

• Кыргызстан: У нас есть ИТ парк, разные программы развития бизнеса в ИТ и отличные цифровые услуги. А еще мы оцифровываем книжки для обучения ИИ

• Россия (Мишустин): покупайте наши импортозамещенные базовые станции и мы делаем свои LLM (показывал Алису, но не Гигачат, заметим) и покупайте наши технологии. Ничего не говорил про российские госуслуги и про Гостех

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

P.S. Изначально я планировал довольно редко писать в эту рассылку и только большими текстами, но с учетом блокировки Телеграм в России обновлять эту рассылку я буду теперь чаще. Не всё-всё переносить из телеграма, где-то объединять тексты, но тем не менее. Каналв телеграм по прежнему остается по адресу https://t.me/begtin

#opendata #data #kazakhstan

Для тех кто не следил ранее за его судьбой напомню что предыдущая версия портала была закрыта в 2023 году для “переноса на платформу Гостех“ и новая версия должна была быть открыта конце 2024 года, но всё растянулось до 15 июля 2025 г.

Немного цифр

До того как предыдущая версия data.gov.ru была закрыта, ещё в начале 2022 года я делал полную архивную копию собранных там данных и на 2 февраля 2022 года на портале было опубликовано более 24 тысяч наборов данных общим объёмом в 14ГБ в сжатом виде. Единый 14ГБ ZIP архив можно скачать с хранилища проекта Национального цифрового архива (ruarxive.org).

Новый портал оказался полной переделкой и на нём было размещено всего чуть менее 5826 наборов данных общим объёмом в 100МБ в виде сжатого ZIP архива (на страницах сайта декларируется меньшее их число, но через API доступно больше датасетов).

Большая часть этих данных - это CSV файлы небольшого объёма, не обновлявшиеся от 4 до 10 лет.

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

Для чего нужны национальные порталы открытых данных?

У примерно половины стран мира, всего 96 есть официальные государственные сайты выполняющие роль национальных порталов открытых данных. Это порталы таких стран как Франция (data.gouv.fr), Великобритания (data.gov.uk), США (data.gov), Албания (opendata.gov.al), Таиланд (data.go.th), Бразилия (dados.gov.br) и многие другие. Фактически, порталы открытых данных есть у всех развитых стран и значительной части развивающихся, а нет их, в основном, в наиболее неразвитых странах, не имеющих собственного цифрового бизнеса, развитого гражданского общества или живой науки.

Порталы открытых данных не совсем новое явление, их начали создавать на национальном уровне ещё примерно с 2010 года, а до этого были разрозненные инициативы.

Зачем же их создают? В мире порталы открытых данных ориентируются на одну или несколько целевых аудиторий специалистов имеющих потребность в данных.

Данные бывают разные, потребности, также, бывают разные:

✅ Аналитикам – полная и оперативная официальная статистика.

✅ Исследователям – отраслевые данные в своих дисциплинах для глубокого анализа и новых открытий.

✅ Геоинформатикам – доступ к цифровым картографическим материалам и геопространственным наборам данных.

✅ Общественникам и НКО – данные для гражданского контроля и мониторинга работы государственных институтов.

✅ Программистам – данные для создания и улучшения цифровых сервисов.

✅ Преподавателям и студентам – данные для обучения, практики и отработки аналитических и разработческих навыков.

к этим группам относительно недавно добавилась группа

✅ Исследователям ИИ - для обучения искусственного интеллекта, нейросетей и подключения к ИИ агентам.

Обычно национальные порталы открытых данных охватывают сразу несколько аудиторий, но бывает и специализация на какой-то конкретной.

Например, на портале открытых данных США (data.gov) преимущественно размещены исследовательские данные и геоданные.

На общеевропейском портале (data.europa.eu) и на большинстве порталов открытых данных стран Евросоза до 75% всех наборов данных - это геоданные в разнообразных форматах (Geojson, SHP, точки API для WFS, WMS и другие геосервисов).

Портал открытых данных Малайзии (data.gov.my) имеет сильный крен в сторону официальной статистики, да и создан он на базе статистического портала страны.

И так далее, примеров множество, все их объединяет акцент на доступность востребованных данных. Даже простые порталы данных, без визуализации, без API и других возможностей, полезны когда на них размещены и регулярно обновляются данные у которых есть пользователи.

На некоторых порталах, таких как портал открытых данных Франции (data.gouv.fr) есть специальный раздел с приложениями использующими наборы данных и API размещённые на портале.

Чтобы понять насколько новая версия data.gov.ru охватывает перечисленные аудитории надо подробнее взглянуть на опубликованные данные.

Глубже в данные

Рассмотрим портал data.gov.ru с точек зрения объёмов данных, их актуальности и полноты.

Объёмы данных

Общий объём всех данных на новой версии портала data.gov.ru составляет 100МБ в сжатом виде в ZIP архиве и около 1ГБ.

Из 5826 наборов данных которые удалось выгрузить с новой версии портала data.gov.ru следующим образом распределяются по их объёму:

• 4694 наборов данных имеют менее 100 строк (80.5%)

• 586 наборов данных имеют от 100 и менее 500 строк (10%)

• 350 наборов данных имеют от 500 и менее 10000 строк (6%

• и лишь 62 набора данных имеют от 10000 строк (1%)

• остальные 3% наборов данных выгрузить не удалось

Итого лишь 1% всех наборов данных можно отнести если не к большим, но хоть как-то заметным.

Много это или мало? В качестве сравнения я приведу объёмы данных статистических показателей на портале ЕМИСС (fedstat.ru) который до конца 2025 года Росстат выводит из эксплуатации. На сайте ЕМИСС сейчас доступно (удалось выгрузить совсем недавно) наборы данных 6905 показателей общим объёмом в 4.36ГБ в сжатом виде в форме CSV файлов и около 60ГБ в распакованном. Это, примерно, в 60 раз больше чем все данные на data.gov.ru.

А ведь ЕМИСС - это лишь одна из государственных информационных систем и далеко не самая большая. Гораздо большие объёмы данных публиковались Федеральным Казначейством, ФНС России и так далее.

Ещё для сравнения, в ноябре 2022 года я делал полный дамп данных с портала открытых данных Москвы (data.mos.ru), это 988 наборов данных, на тот момент, общим объёмом, в сжатом виде, 3ГБ. Это в 30 раз больше чем 5826 наборов данных на новой версии портала data.gov.ru

Как такое возможно? Этот вопрос необходимо задать ответственным лицам в Минэкономразвития РФ. Однако даже при том что данные на московском портале обновляются значительно реже и не все доступны, их объёмы многократно превышают опубликованное на федеральном портале.

Актуальность

У наборов данных на новой версии портала data.gov.ru есть атрибут firstPublication с датой первой публикации.

Из этого атрибута можно высчитать год публикации и получается вот такое распределение по годам.

Можно увидеть что лишь около 15% всех наборов данных опубликованы в 2025 году, около 84% опубликованы более 6 лет назад, в 2019 году и ранее.

От себя добавлю что даже если у набора данных указано что он обновлён в 2025 году - это ещё не значит что он актуален, по личному опыту работы с порталами открытыми данными российских госорганов скажу что актуальная отметка времени в метаданных не гарантирует актуальности самих данных и эти 892 набора данных за 2025 год ещё надо проверять вручную.

Итого на портале не менее 84% неактуальных данных. Много это или мало? Если бы портал существовал лет 10 - это не то чтобы нормально, но объяснимо, а вот для вновь открытого портала это даже не странно, это делает его довольно бесполезным для задач работы с актуальными данными.

С актуальностью данных столь плохо что даже в тех блоках которые создатели “подсвечивают“ на главной странице видно что данные устарели. Например, раздел Метеоданные содержит только один актуальный набор данных.

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

Полнота

Как понять насколько полон портал, действительно ли там все данные что есть в РФ? Хотя бы все доступные, открытые данные российских органов власти?

Начать стоит с того какие органы власти наиболее масштабно публиковали данные все эти годы, и по объёму, и по числу наборов данных.

Здесь можно начать с системы ЕМИСС (fedstat.ru) которую я ранее упоминал. В ЕМИСС размещено не менее 6905 наборов открытых данных и разместить их на портале открытых данных было бы логично и тем более логично что это именно те данные которые востребованы, как минимум, у исследователей и аналитиков.

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

К большим и востребованным источникам открытых данных можно отнести:

• информационные системы и веб-сайты Минфина России, ФНС России и Федерального Казначейства

• портал открытых данных Минкультуры РФ (opendata.mkrf.ru)

• региональные порталы открытых данных таких как портал открытых данных Москвы (data.mos.ru)

• и ещё ряд крупных государственных информационных систем.

Есть ли эти данные на новой версии data.gov.ru ? Увы, нет

О том что раздела “Финансы“ и финансовых данных на портале ранее писала Ольга Пархимович в своём телеграм канале

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

Фактически аудитория исследователей не охвачена ни коим образом.

—

Не последней причиной произошедшего является архитектура и проектирование портала которое вызывает серьёзные вопросы.

Архитектура и почему она важна

Почему на портале открытых данных так мало данных? Если не количественно, то по объёму? Почему туда не попадают данные из информационных систем? Почему так мало актуальных данных?

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

По моему опыту работы с источниками государственных данных в России почти все значимые данные создаются внутри государственных информационных систем. Данные внутри этих систем доступны в самых разных форматах, но преимущественно - это XML и JSON, реже CSV файлы созданные экспортом из SQL таблиц, а чаще это внутреннее или общедоступное API.

Таких государственных информационных систем в России сотни, на многих есть открытое API, данными многих из них аналитики и разработчики пользуются напрямую и существуют порталы открытых данных которые адаптированы под интеграцию с ними. Как минимум - это порталы открытых данных Москвы (data.mos.ru) и Минкультуры России (opendata.mkrf.ru), оба неидеальны, но построены как раз на механизмах интеграции с другими информационными системами. Данные на них размещаются автоматически и актуализируются регулярно. А сами данные могут быть как CSV файлами, так и данными довольно большого объёма в сложных структурах никак не укладываемых в плоские таблицы.

В то же время портал data.gov.ru просто не приспособлен для работы с подобными данными. Де-факто в нём применяется всего два механизма добавления и обновления данных: вручную и импортом данных созданных по “методрекомендациям“.

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

Импорт данных созданных по “методрекомендациям” был изначально тупиковой ветвью агрегации данных. Вместо использования международного стандарта DCAT или Schema.org в Минэке ещё на заре создания первой версии портала data.gov.ru придумали свой формат агрегации данных основанный на списках датасетов в CSV файлах реестров и обязали чуть ли не все госучреждения и муниципальные власти создавать такие реестры. Звучит хорошо? На самом деле нет. Это привело к бесконечному числу мелких CSV файлов которые на сайтах госорганахов и госучреждений публиковались пресс-службами. Почти все они неактуальные, бессмысленные и бесполезные почти для всех задач.

При этом, в реальной жизни, данные могут существовать в очень разных форматах: в виде файлов DBF, MS Access, ZIP архивов с текстами для машинного обучения, продвинутых форматах таких как Parquet, разного рода форматах используемых в научной среде, форматах для геоданных таких как SHP, GeoJSON и многие другие.

У меня лично есть большие сомнения что в текущей версии data.gov.ru могут быть какие-либо данные кроме плоских таблиц. Это получается даже хуже чем в предыдущей версии портала в котором могли быть хотя бы приложенные файлы в условно любом формате.

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

Однако, вернемся к вопросу об аудиториях портала открытых данных.

Как понять что нужно пользователям?

Важно помнить что для пользователей работающих с данными в своих областях и интересах портал открытых данных и сами открытые данные являются не более чем инструментом и снижением барьера для доступа к данным. Например, бизнес выгружает какой-либо реестр напрямую с сайта ведомства через парсинг страниц, а появляется возможность скачивать одним XML/JSON/CSV файлом. Это немного, но облегчает жизнь, но совсем немного, на самом то деле. Реальное же влияние появляется когда на портале публикуются те данные которые ранее в открытом доступе не публиковались и доступ к которым обременён множеством барьеров.

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

В Европейском союзе такими наборами данных определены:

• Геопространственные данные
  (кадастр, топографические карты, адресные реестры, административные границы и др.)

• Наблюдение за Землёй и окружающей средой
  (данные о качестве воздуха и воды, о состоянии почв, мониторинг биоразнообразия, климатические ряды)

• Метеорологические данные
  (почасовые прогнозы, архив метеоданных, данные о температурах, осадках, ветре)

• Статистические данные
  (официальная статистика, микро‑ и макроданные, демография, экономика, сельское хозяйство и пр.)

• Данные компаний и собственников бенефициаров
  (торговые реестры, реестры предприятий, реестры конечных бенефициаров)

• Мобильность и транспорт
  (расписания, данные о пробках, инфраструктура, точки пересадок, схемы дорожной сети)

Кроме того схожий подход применяется в США, Канаде, Австралии, Сингапуре, Новой Зеландии, Южной Корее и Японии.

Например, в Бельгии на национальном портале открытых данных страны data.gov.be доступно 709 наборов данных высокой ценности.

Почти все эти наборы данных - это геоданные из портала геоданных в рамках программы INSPIRE Европейского союза.

Называться они могут по разному: high priority datasets, high value datasets, high impact datasets и так далее. Однако цель их всегда одна, она в концентрации усилий государства на данных имеющих наибольший экономический и социальный эффект.

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

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

И, нельзя забывать про ещё одну область наиболее востребованных данных, это данные для искусственного интеллекта.

Данные для искусственного интеллекта

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

Самые яркие примеры концентрации данных для ИИ - это коммерческие порталы Hugging Face и Kaggle, известные каждому ИИ инженеру и специалисту по data science.

Государственные исследовательские центры, наравне с коммерческими компаниями публикуют там наборы данных под свободными лицензиями. В среде создателей и регуляторов порталов открытых данных активно обсуждается то где такие датасеты должны публиковаться. На порталах открытых данных ? На порталах открытого доступа (с данными для исследователей) ? Или на тех же платформах таких как Kaggle и Hugging Face ?

Я могу лишь сказать что в России немало организаций в сфере ИИ размещающих свои наборы данных на международных ресурсах или на своих веб сайтах. Почему их нет и, похоже, не планируется появление на data.gov.ru ? Этот вопрос лучше задать ответственным лицам в Минэкономразвития, потому что у меня лично это вызывает лишь удивление. Создавать портал данных в 2025 году когда индустрия ИИ является чуть ли не главным потребителем данных - это очень и очень странно, даже как-то неестественно.

А также многое другое

Есть много других направлений в сторону которых все эти годы двигались порталы открытых данных в мире.

Так для аудитории разработчиков активно появлялись как API самих порталов, так и реестры API реального времени к которым можно было бы подключится используя инфраструктуру национального портала как прокси. Так устроены национальные порталы открытых данных в Сингапуре, США, Франции, Великобритании и на порталах данных провинций Китая.

Для аудитории исследователей создаются отдельные подпорталы научных данных, как это сделано во Франции где на базе портала data.gouv.fr развернут подпортал для публикации данных исследователей с выдачей DOI каждому набора данных, расширенными метаданными и другими возможностями значимыми именно для исследователей.

На порталах на базе облачной платформы OpenDataSoft теперь по умолчанию данные можно скачать не только в форматах JSON/XML/CSV, но и в формате Parquet удобном для быстрой аналитики и используемом в data science. Это охватывает несколько сотен порталов открытых данных в мире.

И это лишь самые очевидные изменения в порталах открытых данных последних лет.

Итого

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

Поэтому как относится к новой версии портала data.gov.ru? Как к мемориалу. Минэкономразвития как бы говорит нам “Посмотрите, здесь похоронены открытые данные, мы для них сделали красивое надгробие“.

К счастью наличие национального портала открытых данных на реальную открытость/закрытость информации в России никак не влияет. Все кто работал с первоисточниками так и продолжат делать и дальше. А этот портал через 2-3 года опять превратится в помойку из мелких файлов и будет закрыт уже окончательно.

Но и такой инструмент как DuckDB не идеален и понимание его ограничений важный шаг в точном позиционировании его применения.

Я собрал небольшую подборку того что необходимо учитывать.

Только Юникод в CSV файлах

Да, всё верно, если вы собираетесь загружать CSV файлы в базу данных или делать к ним запросы через DuckDB - эти CSV файлы должны быть в кодироке UTF-8 или UTF-16, с недавних пор ещё может быть кодировка Latin1, но картины это не меняет. Если ваши CSV файлы, например, в кириллических кодировках Windows-1251 или KOI8, то до работы с ними их необходимо преобразовать и сделать это самостоятельно, потому что DuckDB определять кодировку и преобразовывать данные точно не будет. Почему так, неизвестно, это не самая сложная операция, но сейчас она точно не реализована. Поэтому, если вы работаете с большим числом CSV файлов кодировка которых вам неизвестна или может быть вариативно, предусматривайте идентификацию кодировки и их преобразование до обработки этих файлов с помощью DuckDB.

Не все JSON файлы будут считываться

По умолчанию DuckDB пытается преобразовать значения из JSON/JSON lines файлов в таблицу с идентификацией типов полей. Если у вас простой файл JSON в виде массива с перечислением объектов или если это простой JSON lines файл с построчными объектами, то проблем, скорее всего, не будет.

Но если у вас, например, JSON файл со структурой

{“total“ : 10000, “items“ : […]}

то не стоит рассчитывать что DuckDB поймёт что данные в атрибуте items. Он попытается реконструировать таблицу в виде одной записи с полями total и items и рассматривать items как массив значений. Сейчас нет опции передавать в функцию read_json путь к значениям для парсинга. Поэтому лучше знать какие именно JSON файлы вы подаёте на вход.

При автоопределении тип полей зависит от типа файла

Это может показаться странным, но это так. При автоопределении типов полей для JSON/JSON lines файлов DuckDB часто отмечает тип колонок как JSON даже если колонка содержит только строковые и нулевые значения.

Например, в этом файле поле Dataset и многие другие идентифицируются как JSON.

В то время как это же поле Dataset содержит только текстовые значения и NULL

Если бы мы также считывали не JSON lines, а CSV файл, то эти же поля были бы идентифицированы как VARCHAR. Эту разницу важно помнить если вы полагаетесь на механизм идентификации схем данных используемый в DuckDB.

Не надо доверять количественным оценкам в SUMMARIZE

SUMMARIZE - это очень удобная команда в DuckDB выдающая сводку по значениям базы данных. В нашем случае результат команды summarize по всей базе значений индикаторов Всемирного банка выдаёт следующие значения

А последующий distinct запрос по полю indicator выдаёт другое значение. Потому что approx_unique - это прогностическое, а не реальное значение. Оно может не совпадать с реальным даже на небольших объёмах данных поэтому относится к нему необходимо с осторожностью.

Команды DESCRIBE и SUMMARIZE не дают полной схемы данных

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

Например, команда DESCRIBE в отношении файла с перечнем датасетов с каталога открытых данных Hubofdata.ru выдаёт 5 полей с вложенностью идентифицированные как STRUCT, но они не развернуты, в DuckDB сейчас отсутствует такая опция.

И если хочется увидеть подробности по этим вложенным полям то это необходимо делать запросами с разветыванием их структуры, командой unnest, добавляя recursive:=true если необходимо развернуть структуру с подструктурами.

Это ограничение для задачи исследования данных с помощью DuckDB. Например, для автоматизации перевода описания датасетов лично мне приходилось писать код постепенной развертки атрибутов типа STRUCT через последовательные unnest команды, чтобы собрать все названия всех вложенных атрибутов.

Перечисленный список ограничений не исчерпывающий, но важный тем кто использует DuckDB в повседневной работе.

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

Экосистема WARC

WARC - это стандарт хранения и публикации веб-архивов изначально разработанный внутри веб-архива и в 2017 году ставший стандартом ISO 28500:2017.

Во многих смыслах WARC - это хороший формат позволяющий сохранять собираемые материалы веб-сайтов в форме позволяющей последующую переработку. Но важно помнить что его предшественних, формат ARC_IA появился ещё в 1996 году и WARC существует с 2009 года без серьёзных ревизий структуры, авторы стандарта лишь расширяли его сохраняя совместимость.

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

Например, WARC файлы умеют создавать специальные краулеры такие как:

• Apache Nutch - создан и используется Common Crawl

• Heritrix3 - создан в Интернет Архиве и им же применяется

• Brozzler - другой краулер от Интернет Архива, использует headless браузер для индексации, хорош для интерактивных сайтов

• Zeno - ещё один веб краулер от Интернет Архива, написан полностью на языке Go, с небольшим объёмом документации

• Browsertrix crawler - краулер с использованием headless версии Chrome, создан компанией Webrecorder и распространяется под AGPL лицензией

Другие инструменты включают такие утилиты для командной строки как wget и совместимый с ним wpull у которых есть режим сохранения содержимого в WARC архивы.

Экосистема довольно обширная, но можно обратить внимание что большая часть инструментов разрабатывалис довольно давно, а новые, кроме того что делают в Webrecorder, не то чтобы хорошо документированы

Одна из причин в том что эти инструменты все заточены под WARC экосистему и у WARC есть набор серьёзных недостатков которые, по мере их накопления, стали более чувствительными:

1. Необходимость существенных ресурсов для просмотра WARC файлов. Если, например, есть потребность изучить содержание заархивированного сайта, то надо, или разворачивать специальное серверное ПО, или копировать WARC файлы целиком к себе локально. Частично это решается сейчас созданием стандарта WACZ, но пока с ним работают только инструменты созданные компанией Webrecorder

2. Неэффективная структура. WARC файлы устроены как двоичные файлы с разметкой доступа к конкретным ресурсам через файлы CDX (подвид CSV). Для того чтобы собрать метаданные за пределами этого CDX файла, необходимо просканировать WARC файлы целиком что очень небыстрый процесс. Некоторые задачи, например, анализ архива для понимания контента по типам mime являются весьма трудозатратными. В этом смысле WARC файлы и метаданные в CDX далеки не только от форматов вроде JSON, но уж точно от современных вроде Parquet

3. Неэффективное сжатие. Стандарт WARC и инструменты его применяющие допускают сжатие содержимого, но только целиком и только сжатием GZip. В результате сжатие довольно неэффективно, и из-за алгоритма, и из-за того что содержимое сжимается вперемешку. Здесь бы интереснее было бы колоночное сжатие и разделение WARC файлов по видам контента (в одном HTML файлы, в другом изображения, в третьем документы и тд), но пока так не делают.

Не WARC, но LLM

Второе дыхание для веб-краулинга началось с расцветом сбора данных для обучения LLM, а далее вместе с использованием LLM для сбора онлайн контента. При этом, если для обучения LLM разработчики использовали продукты из WARC экосистемы, но как пользователи, а на сборщики поскольку поглощали контент из проектов Archive.org и Common Crawl, но новые продукты веб-краулеров WARC уже игнорировали.

Можно обратить внимание, например, на такие продукты как:

• firecrawl - в продукте фокус на превращении контента в структурированные данные, есть интеграция с LLM и множеством языков разработки, и ничего нет про использование/применение спецификаций или инструментов из экосистемы WARC. Открытый код там только у клиентских библиотек, а вся работа идёт через онлайн сервис

• crawl4ai - практически аналогичный по функционалу что и firecrawl, но с открытым кодом под лицензией Apache 2.0. Позволяет извлекать структурированный контент с помощью LLM. Довольно зрелый и активно используемый продукт.

• Elastic Open Web Crawler - часть продукта Elastic частично выделенная в отдельный код. Позволяет управлять индексацией сайтов в Elastic и, опять же, с игнорированием стандартов вроде WARC и прямым погружением контента сразу в поисковый индекс .

Кроме этих краулеров есть ещё множество других используемых в задачах скрейпинга, OSINT и иного сбора контента. Важно то что WARC и относящиеся к нему стандарты они игнорируют, при этом очень быстро развиваются, и с точки зрения качества кода, и с точки зрения удобства пользователя.

Почему это важно

Новые краулеры набирают бешеную популярность за очень короткий срок.

Если посмотреть на графики активности и востребованности краулеров, например, heritrix3 и crawl4ai или heritrix3 и firecrawl то можно увидеть как это происходит.

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

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

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

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

Сейчас я лично всё чаще читаю/слышу и вижу в демонстрациях продуктов и кода что Pandas уже де-факто легаси. Нужный, живой, полезный, но непрактичный продукт для задач обработкой данных относительно большого объёма. У Pandas появилось много альтернатив развивающихся быстрее и существенно обгоняющих в скорости работы. Я приведу в пример ключевые из них.

1. Polars

Написанный на Rust движок для работы с дата фреймами и поверх которого реализованы программные библиотеки для наиболее популярных языков включая Python. Ключевое - это использование колоночного формата Apache Arrow для работы с данными и дополнительные возможности такие как выполнять SQL запросы к дата фреймам. По их собственным бенчмаркам с Polars быстрее Pandas многократно и сравним только с DuckDB.

2. Dask

Dask - это движок изначально созданный для параллелизации выполнения задач и реализации модели "big pandas", то есть как pandas только для данных большего объёма. Собственно главным конкурентом у Dask всегда позиционировался не Pandas, а Pyspark. Dask как бы создавался для конкуренции в потоковой обработке данных на серверах/кластерах. Но оказалось что большинство пользователей используют Dask на ноутбуках и с датасетами до 100GB.

3. cuDF

cuDF (читается как “KOO-dee-eff”) это библиотека для дата-фреймов в Python с использованием GPU (графического процессора). Создана в Nvidia в рамках проекта Rapids и интегрирована с Pandas и Polars. Судя по их собственным тестам обгоняет не только их, но и DuckDB, Clickhouse. Правда бенчмарк у них довольно ограниченный, всего на данных в 5GB, но тем не менее сейчас многие смотрят в эту сторону.

4. DuckDB

Строго говоря DuckDB - это не программная библиотека для дата-фреймов, а движок СУБД. Но устроен DuckDB так что его можно с ними сравнивать поскольку DuckDB имеет библиотеку для Python в рамках которой как умеет строить запросы поверх дата фреймов Pandas, так и возвращать дата фреймы после SQL запросов. У DuckDB есть свой бенчмарк по которым он быстрее большинства движков вроде Polars, Pandas и др. Но ещё и важно отметить что DuckDB делают акцент на скорости на больших объёмах применительно к настольным компьютерам. Не все движки проходят их тест по JOIN'у 50GB данных.

—

Это те движки и инструменты которые можно назвать основными.

Что важно, это то что у них всех есть немного разное позиционирование и практически отсутствуют универсальное сравнение. Нет кого-то нейтрального кто бы разработал пул тестов и проверил бы каждый движок. Зато в сети легко находятся частные сравнения 2-3 движков, чаще всего сделанные разработчиками одного из них. При всех сравнениях важно лишь помнить что "чистый Pandas" это наиболее медленный инструмент.

Один из способов взгляда на эти движки для дата фреймов это сравнение их с аналитическими базами данных такими как Clickhouse и для этого есть бенчмарки Clickbench где также есть обзор Pandas, Polars, DuckDB и нет разве что Dask. И там нет многих именно инструментов, а не баз данных, а то есть этот бенчмарк очень полезен, но и он полной картины не даёт.

А также другие альтернативы, о которых в этот раз без подробностей, просто ссылками:

• Apache Datafusion - https://github.com/apache/datafusion

• chDB - https://clickhouse.com/blog/welcome-chdb-to-clickhouse

• Daft - https://github.com/Eventual-Inc/Daft

• datatable (Python) - https://github.com/h2oai/datatable

• data.table (R) - https://github.com/Rdatatable/data.table

• Dplyr - https://dplyr.tidyverse.org/

• Fugue - https://github.com/fugue-project/fugue

• Ibis - https://github.com/ibis-project/ibis

• Modin - https://github.com/modin-project/modin

• Ray - https://www.ray.io/

• Tibble - https://github.com/tidyverse/tibble

• Vaex - https://github.com/vaexio/vaex

Выбирая между разными инструментами в итоге я могу порекомендовать DuckDB и Polars как наиболее производительные и зрелые одновременно.

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

#dataengineering #dataframes #opensource #datatools

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

Территориальные подразделения

Особенность российской системы государственного управления и, как следствие, особенность статистического учёта в том что у большинства российских федеральных служб, агенств и некоторых министерств есть территориальные органы/подразделения. Они есть у антимонопольной службы, у ФССП, у Ространснадзора, МВД России и ещё многих органов власти.

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

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

Некоторые госорганы, такие как ФНС России, де-факто, коммуницируют через единый сайт nalog.ru, где можно уточнить свой регион, но, в целом, это выглядит как прямая коммуникация с федеральной службой.

Территориальные подразделения есть и у Росстата, у каждого из которых есть отдельный сайт, который является поддоменом сайта rosstat.gov.ru с кодом региона, например, сайт Рязаньстата с кодом 62.

В чём отличие Росстата и его территориальных подразделений от других органов власти? В основном результатами, в отличие от других ФОИВов и иных органов власти, результаты работы статслужб - это данные статистики, собранные и представленные для пользователей.

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

Публикуется в разных форматах, разной структуре данных, в виде таблиц Excel, файлов MS Word, PDF документов или всё это вместе внутри ZIP и RAR архивов, но, что важнее, всё это нигде и никак не сведено вместе.

Всё это формирует ту самую российскую особенность официальной статистики - институциональную фрагментированность данных.

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

Давайте я поясню, на практике.

Такие одинаковые и такие разные

Материалы которые публикуются на сайтах территориальных управлений Росстата частично унифицированы, в разделах официальной статистики в основном повторяются темы и данные более-менее схожи, хотя и не идентичны. Но когда речь заходит о статистических публикациях разница начинает проявляться весьма ярко.

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

• Социально-экономическое положение Рязанской области

• Рязанская область в цифрах. Статистический сборник

• Рязанская область. Статистический сборник

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

Есть и более экзотические случаи когда вместе публикаций, на сайте размещается “каталог публикаций“, как это происходит в Ивановостате, а сами публикации необходимо запрашивать у этого территориального органа.

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

Такие каталоги публикаций, которые можно заказать у территориальных органов, есть и, на сайте Мосстата, и на сайте Свердловскстата, и на сайте Амурстата и почти всех территориальных органов.

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

А, кроме того, практически все они поставляют за деньги статистику региональным органам власти. Например, Ульяновскстат поставляет ежегодно статистику Минцифре Ульяновской области, а Якутстат выполняет работы для Минэкономики Якутии.

Далее в разных регионах по разному, однако не то чтобы эти доходы терр органов очень велики, они могут не превосходить 5 миллионов рублей в год и чем далее тем более будут снижаться. Потому что кому сейчас нужна статистика в виде PDF и документах MSWord? Только тем кто ей не пользуется на практике.

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

А как оно в мире?

Если кратко, то мне не удалось найти в мире ни одного схожего примера.

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

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

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

Ни среди стран столь же территориально распределённых, таких как Канада, их статистическая служба весьма компактна. Ни в Бразилии, где статистика в ведении Института географии и статистики. Ни в статистической службы Индонезии, сравнимой с РФ как по числу граждан, так и по размеру территории.

—

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

#statistics #russia #data #openata

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

Я про российскую специфику знаю больше чем, к примеру, про китайскую и регулярно пишу, а какие-то факты могу и повторить.

Итак, особенности российской ситуации с открытыми и общедоступными данными:

1. Почти полное отсутствие открытых научных данных. В институциональных репозиториях научных результатов почти во всех ВУЗах есть только публикации в виде статей. Это резко контрастирует со всеми странами где есть живая наука. В то же время многочисленные научные наборы данных из РФ есть в иностранных репозиториях, как правило созданы эти данные в соавторстве с исследователями других стран.

2. Высокая степень закрытости всего что касается геоданных и это также отличает от всего мира, где повсеместно используются, либо ArcGIS, либо набор ПО открытого кода такие как GeoNode, Geonetwork, Geoserver. В России они тоже есть, но масштаб проникновения куда ниже чем мог бы быть и много продуктов представленных только в России и нигде более. Тут есть большое сходство с Китаем, кстати.

3. Всё что касается открытых государственных данных оказалось в кризисе ещё с момента первых инициатив в 2012-2015 годах. Обязательные требования к раскрытию никому не нужных административных данных привело к тому что 99% госорганов стали воспринимать публикацию данных как часть бессмысленной бюрократической нагрузки, а портал данных data.gov.ru выродился в бесконечную помойку. Но сейчас даже этой помойки нет, а оставшийся 1% госорганов - это ФНС РФ, Казначейство России, отчасти Минкультуры и несколько регионов. И всё. У большинства остальных госорганов публикация данных, либо имитационна, либо не производится уже лет 8. Данные просто не обновляют, удаляют и тд.

При этом, к примеру, в Dateno, формально, 244 тысячи наборов данных относятся к Russian Federation, но из них 195 тысяч - это датасеты ГИС-портала Спутникового Центра ДВО РАН. А там данные не российские данные, а клон метаданных датасетов NOAA (Метеорологическая служба США). По хорошему надо этот источник данных полностью исключить из-за его полной вторичности, тем более что он сейчас недоступен и при следующем обновлении индекса, с высокой вероятностью, мы его отключим.

Итого остаётся чуть менее 50 тысяч наборов данных из которых около 9 тысяч наборов данных - это созданные Инфокультурой порталы hubofdata.ru и ngodata.ru, ещё около 28 тысяч - это данные о России на международных статистических порталах и остальное - это геоданные из инсталляций ArcGIS и Geoserver органов власти. Совсем чуть-чуть научных данных из Репозитория открытых данных по русской литературе и фольклору Пушкинского дома в СПб.

Означает ли это что данных нет? Совсем не так. Это означает что большая часть российских данных не публикуются по принятым в мире стандартам и поэтому не индексируются в Dateno. Это означает что многие банки документов так и не были превращены в открытые данные. Для открытых государственных данных методрекомендации Минэкономразвития были бессмысленны с самого начала именно по этой причине, в мире для агрегации датасетов используют стандарт DCAT, а в РФ решили изобрести свой, плохо смоделированный, велосипед.

По этой теме я могу продолжать ещё долго, но в целом хочу зафиксировать что доступность данных - это не только их публикация, но и соблюдение стандартов за счёт чего повышается находимость данных. В поиске Google по датасетам на русском выпадают результаты со ссылками на hubofdata.ru и ngodata.ru не по той причине что они самые точные и релевантные, а просто потому что поддерживают стандарт schema.org.

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

К примеру данные с data.mos.ru портала открытых данных города Москвы отсутствуют в Google Dataset Search

и отсутствуют в поиске Dateno

не считая слепка сайта размещённого на hubofdata.ru. Почему так? Потому что data.mos.ru хоть и неплохой портал, но ни стандарта Schema.org, ни DCAT он не поддерживает. По мировым меркам он нестандартный.

И, наконец, я уже неоднократно говорил что вот это огораживание РФ от мира и мира от РФ приводит к тому что большая часть российских госсайтов недоступны за пределами российских подсетей. Они выпадают из под архивации Archive.org, выпадают из поиска в Google и тд. Многие из них выпадают из индекса Dateno по той же причине.

В этой ситуации, почти наверняка, нам получится привязать к РФ ещё 20-30 тысяч датасетов в текущем индексе улучшив геокодирование имеющихся данных. Это не так просто, но и не фантастически сложно, в первичных данных часто такие сведения есть, но закодированы по разному.

В будущем данных о России и из России будет в Dateno больше, но пока это происходит не от желания владельцев данных, а скорее вопреки их устремлениям.

#opendata #russia #datasets #datasearch #data #dateno

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

Так должно быть, вернее очень бы хотелось. При этом реальность наполнена как очень хорошими, так и откровенно плохими практиками предоставления данных.

Плохие открытые данные

Некоторые такие плохие практики раньше публиковались во французском проекте OpenDataFail, но сейчас от него остался только Twitter. Ещё был проект Bad data от Open Knowledge Foundation, с несколькими примерами плохой публикации данных. Я туда также, ещё много лет назад отправлял несколько примеров особенно плохих публикаций данных в РФ. Хотя это было давно, но до сих пор отчетливо помню когда обнаружил что на сайте российского МВД публиковались XML файлы разметки MS Word и они выдавались за открытые данные.

MS Word позволяет сохранять текстовые документы в XML формате, он называется Word 2003 XML document. Эти файлы не являются файлами с данными, это всего лишь язык разметки, также как HTML или другой формат публикации текста.

Почему этот случай такой заметный? Потому что оригинальные данные явно были в формате .doc или .docx. Вместо того чтобы сохранить их в Excel или CSV, сотрудники МВД сохранили их в формате Word 2003 XML document. Который, как бы XML, но какого-либо удобного способа получения из него данных нет.

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

Метаданные

Метаданные  — информация о другой информации, или данные, относящиеся к дополнительной информации о содержимом или объекте.

Можно сказать что метаданные - это данные о данных. Они описывают основные характеристика любого цифрового объекта таким как документы, научные статьи, репозитории кода и к которым, безусловно, относятся и наборы данных и открытые API. Важность метаданных очень хорошо понимают библиотекари и архивисты, в архивном деле давно распространён такой стандарт как MARC 21 для библиографии, а также такой общепринятый стандарт описания цифровых объектов как Dublin Core.

Если перевести понятие метаданных в практическое русло, то они отвечают на такие вопросы пользователей как:

• Что это такое?

• К каким предметным областям это относится?

• Когда оно было создано и изменено?

• Как это получить/скачать (ссылка) ?

• Кем оно создано и кто за это отвечает? Как с этим человеком/организацией связаться?

• Что с этим связано?

• В каком формате оно распространяется?

• Имею ли я право это использовать и если да то какие ограничения ?

Можно обратить внимание что базовые метаданные отвечающие на эти вопросы такие как: название, описание, дата создания, ссылка, условия использования/лицензия, автор, контакты автора и многое другое универсальны.

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

Отдельно можно выделить несколько стандартов метаданных которые, можно сказать, являются общепринятыми:

• DCAT2&3 стандарт публикации датасетов от W3C со множеством расширений в разных странах таких как DCAT-AP в Евросоюзе, DCAT-US в США. Наиболее проработанный стандарт описания наборов данных, поддерживается многими каталогами данных и расширениями для них.

• Schema.org Dataset используется для индексации датасетов в поисковиках, в первую очередь в Google. Адаптирован для использования в разметке веб страниц и расширяет спецификацию CreativeWork, также из Schema.org. Имеет смысл использовать его если Вы хотите чтобы Ваши данные было легко найти.

• Карточка набора данных в CKAN основна изначально на базе Dublin Core, и при этом расширяется. Даёт возможность заполнить минимально необходимое описание набора данных. Используется в ПО CKAN и DKAN, для потребителей данных доступна через CKAN или CKAN совместимое API.

Кроме этих стандартов существует ещё множество других, также, активно применяемых при публикации данных. Это и уже упоминавшийся ранее Dublin Core, и стандарт DataCite для научного цитирования, и CodeMeta, и MARC XML и многие другие. Большое число стандартов для описания и публикации метаданных существует для пространственных данных, можно сказать это отдельная область описания датасетов.

Те же метаданные экспортированные по спецификации DCAT

Можно сказать что метаданные - это базовый уровень качества данных. Многие порталы, так то общеевропейский портал data.europa.eu отображают сведения о качестве именно метаданных датасетов.

Поэтому, с одной стороны, может показаться что метаданные это сложно, но на самом деле это совсем не так и здесь мы приходим к первому практическому совету.

Большая часть ПО для каталогов открытых данных и онлайн платформ для их размещения требуют заполнения базовой информации о датасетах, поддерживают множество дополнительных атрибутов и экспорт во множество стандартов метаданных. К таким ПО можно отнести CKAN, DKAN, InvenioRDM, Harvard Dataverse, ArcGIS Hub, GeoNode, Geonetwork и OpenDataSoft, а к платформам Zenodo, Kaggle, Hugging Face и многие другие.

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

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

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

Ссылки и внутренние и внешние данные

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

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

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

Приведу пример из личного опыта. Анализируя и выгружая все доступные данные из нескольких порталов открытых данных в 2023 году, при подготовке проекта Dateno я столкнулся с тем что около 10% ссылок на портале data.gov.uk были нерабочими. Этот портал выступал агрегатором ссылок на муниципальные порталы данных страны и на многих из них обновлялось ПО сайта или менялся домен и ссылки более не вели на данные или не работали вовсе.

Форматы файлов

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

Но на практике есть много нюансов и вариаций.

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

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

Такой подход используется очень давно, и он был бы универсален если не некоторые особенности в работе с данными в последнее время:

• не все данные можно уложить в плоские таблицы и в этом случае CSV файлы использовать неудобно. Для таких случаев гораздо логичнее файлы JSON, JSON lines или XML;

• Большая часть стандартов публикации данных были разработаны под поддержку схем описания данных для XSD для XML или JSON Schema для JSON и описания текстом.

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

• CSV формат, даже со сжатием, менее эффективен чем современные форматы такие как Parquet где достигается колоночное зжатие данных.

Итак, в каком формате лучше всего публиковать данные? Вариантов много, многие весьма специфические/отраслевые

• XLS, XLSX, ODS - наиболее распространённые форматы файлов используемые в Microsoft Excel и Libre/OpenOffice. По факту являются скорее не дата файлами, а языками разметки таблиц и импорт из них в СУБД или использование эти данных машинным образом скорее затруднено. Имеет смысл использовать на практике только когда Вы публикуете какие-либо унаследованные данные или если Ваши пользователи точно планируют использовать их в редакторе типа Excel, но и в этом случае лучше дополнить их машиночитаемыми данными, например, в CSV.

• CSV - наиболее популярный формат для публикации данных. Очень распространён и очень часто содержит ошибки в форматировании. Хорошо подходит для публикации плоских таблиц, но плохо для любых иерархических данных.

• XML - расширенный язык разметки. Плюс в возможности валидации данных через XML схемы. Часто используется для публикации данных по определённым стандартам и из существующих информационных систем. Можно публиковать данные в любой сложной иерархии. Минусы в том что обработка подобных данных требует более сложно парсинга и в том что очень крупные XML файлы могут требовать больших ресурсов для их обработки поскольку стандартные DOM парсеры загружают их в память целиком.

• JSON - в полном названии, JavaScript Object Notation, фортмат данных получивший популярность с развитием веб приложений и использования JavaScript. Из плюсов хорошо поддерживает иерархию и множествотипов данных, из минусов, также как XML загружается полностью в память. Если JSON файл будет в несколько гигабайт, то и, как минимум, несколько гигабайт он займёт в оперативной памяти.

• NDJSON / JSON lines / JSON streaming - альтернатива формату файлов JSON решающая задачу потоковой обработки данных без полной загрузки в оперативную память. У JSON lines каждая строка - это JSON объект и данные обрабатываются построчно. JSON lines значительно набрал популярность для экспорта данных в сложной структуре и он позволяет сохранять те данные которые так просто не сохранишь в CSV. Важным недостатком JSON lines является увеличение объёма итогового файла. Например, CSV файл в 3.5 ГБ после преобразования в JSON lines занимает 8.7 ГБ (~2.5 раза больше).

• Apache Parquet - это специальный, колоночный формат файлов изначально использовавшийся в продуктах экосистемы Apache Hadoop с 2013 года и вышедший далеко за его пределы. Главные достоинства формата Parquet в удобстве для аналитической работы через ускорение запросов благодаря тому что данные хранятся по колонкам и сжатию данных превышающему сжатие CSV файлом с помощью Gzip, но без потери возможности работы с файлом. К примеру, CSV файл в 3.5 ГБ после преобразования в Parquet занимает 0.93 ГБ (~3,8 раз меньше).

Кроме того существует множество других форматов файлов за пределами наиболее популярных. Они не так популярны, приведу несколько примеров:

• RData - формат с расширениями .rdata и .rda используется для распространения данных для инструментов на языке R

• TSV - диалект CSV в котором в качестве разделителей используются символы табуляции. Чаще всего рассматривается просто как подвид CSV файла, но может иметь свое расширение .tsv

• NetCDF - популярный в метеорологии и ряде других наук формат для публикации и распространения научных данных измерений

• RDF, TTL, JSON-LD - семейство форматов используемых для публикации семантических/связанных данных

• MAT - проприетарный формат данных используемый в приложении MATLAB. Часто используется для распространения данных в статистике и социологии.

А также существует множество форматов данных и API для публикации пространственных данных, но это тема отдельного большого текста. И не меньшее число форматов и способов публикации отраслевых данных, большая часть которых может иметь расширение .xml, но содержать данные по конкретной спецификации.

Вернемся же к наиболее популярным форматам файлов и способом публикации данных.

Итоговый формат данных почти всегда складывается из следующих пунктов:

• В каком формате/форматах пользователи хотели бы использовать эти данные?

• В какой формат данных мы можем преобразовать те что у нас есть ?

• Какие технические ограничения у нас есть? (как правило речь про то сколько дискового пространства или ширина интернет канала у нас етсь)

В итоге, как же публиковать данные наиболее правильно?

1. Если данные являются плоскими то в CSV формате. Если размер CSV файла относительно велик, условно, начиная с 20 МБ, то сжать его Gzip или Bzip2 или Xzip или ZStandard.

2. Если данные не являются плоскими, то в формате JSON lines, опять же если файл достаточно велик, то сжать его как и CSV файл.

3. Если есть необходимость экономии дискового пространства и если среди пользователей есть дата аналитики и дата сайентисты, то дополнительно опубликовать данные в формате Parquet.

4. Если это специфичные отраслевые данные или геоданные, то воспользоваться одними или несколькими спецификациями. Например, GeoJSON для геоданных, или WARC для веб архивов, или PCAP для данных сетевого трафика и так далее.

5. Хотя и можно публиковать данные в Excel, это всё менее популярно, и в большинстве случаев сейчас данные публикуются как CSV с описанием разделителя. Большинство Excel пользователей умеют импортировать такие файлы.

6. Публиковать данные в форматах XML или JSON стоит только если они относительно невелики.

Про форматы данных можно рассказывать ещё много и я сознательно пока не затрагиваю тему пространственных данных.

Хорошие практики

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

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

Тем не менее хорошие практики - это хорошие практики. Для востребованных данных они добавляют качество их пользователям.

1. Статистику хорошо публиковать, в столь многих востребованных форматах сколь это возможно: CSV, Excel, XML, JSON-Stat, SDMX (специальный формат распространения) и Parquet. А также предоставлять API. У статитистики более всего разных категорий пользователей. От дата аналитиков и дата инженеров до нетехнических пользователей. Так делают, например:

   1. В Финляндии на портале данных статистики работающих на ПО PxWeb с экспортом в более чем 10 форматов.

   2. На портале данных ЮНЕСКО с экспортом в CSV, Excel и общедоступным API отдающим данные в формате SDMX.

   3. На национальном портале открытых данных Малайзии с публикацией данных в форматах CSV и Parquet, с открытым API и автоматически сгенерированным кодом доступа к данным

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

3. При выборе форматов сжатия файлов с данными правильный выбор зависит от того насколько Вы понимаете потребности аудитории/пользователей. Если Вы публикуете архивные унаследованные форматы файлов, то можно сжимать их как можно лучше используя Xzip или Bzip2. Если Вы хотите опубликовать сразу много файлов, то лучше запаковывать их в ZIP файлы. А если Вы хотите опубликовать файлы которые было бы удобно использовать аналитиками то лучше использовать компрессию Gzip или Zstandard.

   1. Почему ZIP, а не 7z, Rar или Tar.gz ? Две причины. Первая в том что ZIP файлы многие порталы данных умеют листать и отображать их содержимое при любом размере файла, например, такое поддерживает Zenodo. Вторая в том что для ZIP файлов во многих языках разработки есть возможность открытия файлов и потоковой обработке файлов прямо внутри ZIP контейнера. Для многих других форматов архивов, даже если есть программный код доступа, чаще всего нет возможности открывать файлы внутри для чтения и требуется распаковка архива до обработки файла.

   2. Некоторые современные аналитические продукты поддерживают только определённые режимы компрессии. Например, DuckDB поддерживает компрессии Gzip и Zstandard, но не поддерживает ZIP. Если Вы попробуете команду select * from 'data.csv.zip'; она не сработает, а если select * from 'data.csv.gz';. Файлы, конечно, должны существовать для такой проверки.

4. Некоторые дата продукты являются хорошими примерами даже при некоторой архаичности их реализации. Например, система ФИАС Налоговой службы РФ содержит раздел для разработчиков включающий API, актуальные данные ГАР, данные в унаследованной форме КЛАДР, публикацию обновлений и полных версий наборов данных. При этом некоторые практики неудобны или архаичны, а другие, наоборот, более чем разумны:

   1. Унаследованные архивы КЛАДР публикуются будучи сжатыми архиватором ARJ.

   2. Полные версии сжатых XML файлов ГАР - это 42 ГБ. Требуется написание специального SAX парсера для доступа к данным.

   3. Но все схемы данных хорошо задокументированы и описаны.

   4. Но есть специальный сервис получения обновлений данных.

5. Для научных данных особенно актуальна публикация данных с присвоением DOI и ссылками на опубликованные данные. В этом случае точно не надо публиковать данные на произвольном сайте, а лучше воспользоваться одной или онлайн платформ или развернуть систему управления данными и научными результатами и публиковать в ней.

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

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

В недавнем обновлении мы загрузили в него ещё 4 миллиона карточек датасетов и теперь общий объём индекса достиг 19 милллионов записей. Много это или мало? Поиск по данным от Google (GDS) на начало 2023 года содержал 50 миллионов записей. Поэтому это немало и вполне может быть ещё больше.

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

Поэтому ещё на старте проекта мы закладывали в него несколько принципиальных особенностей, отличающих его от других проектов по поиску данных:

Открытость

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

Другая часть открытости - это детальная статистика индекса доступная онлайн. В репозитории dateno-stats собрана статистика текущей версии индекса и предыдущей.

Сейчас статистика доступна в виде множества CSV и JSON файлов, далее мы развернём BI систему в дополнение к этим данным. Уже сейчас можно оценить охват по странам, языкам, программному обеспечению, лицензиям и многому другому.

Интегрируемость

У Dateno есть открытое API, достаточно лишь зарегистрироваться на сайте dateno.io и воспользоваться ключом для доступа к поиску и получению отдельных записей, как описано в документации на сайте API api.dateno.io.

А в качестве примера сделана утилита командной строки datenocmd с помощью которой можно искать данные так же как через веб интерфейс и которая доступна с открытым кодом.

Широта

Одна из особенностей Dateno, это многочисленные фасеты/фильтры используемые для уточнения поиска. Для поиска по датасетам сложно искать иначе кроме как по фильтрам поскольку для поиска не работают алгоритмы вроде PageRank поскольку на датасеты может и не быть ссылок.

Сейчас в Dateno 13 подобных активных фильтров, это:

• Тип каталога данных

• Тип владельца каталога

• Макрорегион

• Страна/Регион

• Территория в стране (субрегион)

• Тема по справочнику тем датасетов Евросоюза

• Тема по стандарту ISO 19115

• ПО каталога данных

• Язык (разговорный)

• Источник данных

• Формат файлов/стандарт API (если API)

• Тип лицензии

• Тип данных

Эти фильтры далеко не все что запланированы в Dateno, на подходе фасеты для поиска по сематическим типам данных, по временным промежуткам и многое другое.

Полнота

Сейчас в Dateno 19 миллионов наборов данных. Много это или мало? В поиске по датасетам от Google их 50 миллионов, крупных каталогах научных данных таких как ScienceBase их 18 миллионов, в индексах и поиске по научным данным вроде Datacite их около 30 миллионов. А на национальных порталах открытых данных обычно от 1 до 300 тысяч наборов данных, редко больше.

Индекс Dateno весьма велик, но далеко не полон. Более всего сейчас в нём данных с порталов открытых данных, порталов статистики и геоданных.

Тем не менее наша цель до конца года достигнуть планки в 30 миллионов наборов данных и это вполне реалистично.

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

Я буду регулярно писать в этом блоге на русском языке о том как Dateno устроен, а в блоге на Medium на английском языке.

#data #datasearch #dateno #datadiscovery

Если не пересказывать её целиком, то мысль статьи такова что данные имеют ценности сами по себе, когда для конечного пользователя важны именно данные, то и надо сосредотачиваться на создании дата продуктов (data products), а не приложений на них основанных. И эти приложения, а ещё точнее, интерфейсы над данными должны давать больше, а не меньше возможностей по их получению.

Мысль простая, очевидная для профессиональных дата аналитиков, не очевидная, к сожалению, для многих, даже весьма уважаемых владельцев и создателей данных, и часто забываемая разработчиками ПО, которые, зачастую, вместо создания дата продуктов, прилагают усилия по созданию визуализации и сложной программной логики вместо API и массовой выгрузки.

Всё это применимо и неотъемлимо от современной статистики, как официальной государственной и межгосударственной, так и той что создаётся бизнесом или НКО.

Официальная статистика как документы

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

До сих пор во многих наиболее бедных странах сложно найти официальную статистику кроме как в виде бумажных или электронных (PDF/сканы) книг и бюллетеней. С одной стороны эта форма кажется исчезающей и редкой, с другой стороны даже в развитых странах до сих пор существуют статистические бюллетени отдельных органов власти и представленные там данные только в этих документах и существуют.

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

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

Вот пара примеров такого подхода

Официальный сайт статистической службы Туркменистана www.stat.gov.tm

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

Раздел статистикан на официальном сайте Минтранса России mintrans.gov.ru

А вот другой пример, того как официальная статистика Минтранса России до сих пор публикуется в виде PDF документов статистического бюллетеня. Думаю что очевидно что работать с этими данными крайне сложно, построение временных рядов требует большой ручной работы.

Официальная статистика как таблицы

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

Начиная с самых очевидных форматов табличных файлов MS Excel (.xls, .xlsx) или OpenOffice (.ods) и продолжая другими форматами такими как CSV, TSV, форматами данных для программных продуктов Stata, Statistica и др.

Публикации статистических данных как таблиц кажется совершенно ественным развитием. Статистику создают таблицами, обновляют таблицами, используют таблицами. Так почему же её не публиковать таблицами?

Технических инструментов и программных продуктов для этой цели было создано немало. Можно особенно выделить продукты NESSTAR, PxWeb, .Stat. Они и многие другие позволяли использовать системы построения запросов к статистическим базам данных, просматривать отдельные индикаторы и экспортировать данных в разных табличных форматах.

К примеру, таблицами публикуется статистика Армении в статистическом банке и отчетами на сайте.

Выбор индикатора в statbank.armstat.am

Конечно, многое зависит от реализации и один и тот же владелец данных может отдавать данные более или менее удобным способом, где-то через построитель запросов, где-то в виде Excel файла, а где-то в виде HTML таблицы.

HTML таблица с индикаторами на сайте armstat.am

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

Такой доступ к данным уже кажется привычным, ну или как минимум “нормальным”.

Официальная статистика как дата продукты

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

К примеру, такой программный продукт как PxWeb эксплуатируется в странах Северной Европы и ещё ряда стран. Он позволяет выбирать индикаторы из базы и строить запрос с получением таблицы в итоге. Далее эту таблицу можно экспортировать в форматах CSV, JSON и других форматах.

Например, база статистики Финляндии

Визуализация индикатора в системе PxWeb на сайте statfin.stat.fi

Это пример можно сказать переходного подхода, от таблиц, к дата продукту. Здесь уже есть возможность скачать данные многочисленными способами и пример доступа через API. Но до полноценного перехода нехватает двух ключевых аспектов: массовая выгрузка и API как основа продукта (API-first).

В чём они заключаются?

Массовая выгрузка (bulk download) - это возможность получения всей базы целиком. Подобное применимо не только к статистике, но к статистике точно применимо. Основная идея в том что существует большое число потребителей которым просто нужна вся база со всеми данными. Не отдельный индикатор, не отдельный малый срез за период времени, а всё и целиком. Владельцам данных часто сложно преодолеть психологический барьер того что их усилия по созданию приложений по визуализации статистики никому не нужны и то что они не имеют контроля за распространением и доступом к данным. Но… Если такой механизм не делать, то всё равно найдутся те кто напишут парсеры и получат базу индикаторов целиком. А предоставление данных целиком - это реализация принципа открытости по умолчанию (open by default) который должен быть абсолютно естественнен для проектов ориентированных на создание общего блага. Официальную статистику однозначно можно к подобному отнести.

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

Портал данных Европейского банка с возможностью выгрузки всех данных индикаторов.

Страница выгрузки данных с портала data.ecb.europa.eu

Особенность данного портала в количестве показателей, в общей сложности их сотни тысяч и объём их весьма велик. Несмотря на это разработчики портала дают возможность получить данные “здесь и сейчас“ и многочисленными способами. В том числе непосредственно из карточки/профиля отдельных индикаторов где данные можно скачать в привычных Excel и CSV форматах или в виде картинки графика.

Карточка индикатора на сайте data.ecb.europe.eu и форматы выгрузки

Но, обратите внимание, что доступность данных первична. Страницы индикаторов и их визуальное отображение являются скорее ценным дополнением для тех специалистов кто не владеет техническими инструментами.

Похожим образом публикуется статистика ФАОСТАТ (Статистический отдел Продовольственной и сельскохозяйственной организации Объединенных Наций)

Страница сайта faostat.org

На сайте ФАОСТАТ можно двумя файлами скачать все их индикаторы, а их много. Общий объём не так велик, около 1.5 гигабайт в сжатом виде

Некоторые порталы реализуют эти функции не в полной мере. Например, на портале данных ООН data.un.org предоставляется SDMX API на основе двжка SDMX-RI Евростата. Можно сказать что портал частично переходит на модель дата продукта, но не до конца, потому что нет массовой выгрузки

Страница API портала data.un.org

Дальнейший поиск в Гугл по ключевым словам statistics bulk download выдаст ещё немало межгосударственных и национальных статистических порталов с удобной выгрузкой данных.

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

Как мог бы выглядеть современный портал с открытой статистикой?

По следам этих размышлений я сформулировал следующие пункты которым просто не может не соответствовать хороший современных статистический портал:

1. Унификация.

Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.

2. Массовая выгрузка.

На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.

3. Универсальный поиск.

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

4. Открытые данные по умолчанию.

Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft

5. Экспорт данных и доступ через API.

Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.

6. Технологичность.

Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

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

#statistics #opendata #datacatalogs #datasets

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

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

Зачем необходим поиск данных в компаниях?

Поиск данных - это то что нужно всем кто так или иначе с данными работает: журналистам, учёным, программистам, аналитикам, инженерам да и просто любому квалифицированному пользователю. Те кто их ищут могут использовать для этого самые разные способы, от специализированных закрытых поисковых систем, до того чтобы поспрашивать знакомых. Цели также могут отличаться: учёный ищет данные и ссылки для научной статьи, журналист подтверждение/материал для расследования, аналитик API для подключения к Excel и так далее.

Чем отличается поиск данных в компаниях? Чем отличаются бизнес-потребители данных от кого-либо ещё?

У бизнеса возникают задачи поиска данных в двух основных случаях:

1. Поиск внешних данных для приобретения и создания создания собственных продуктов на данных. Основные способы получения внешних данных - это их покупка или же поиск бесплатных/открытых данных.

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

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

Приобретение внешних данных

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

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

1. Идентифицировать владельца[-ев] данных, типа владельца и определить потенциальные источники.

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

   1. Исследовать сайты/порталы/веб-страницы с описанием данных

   2. Спросить в профильных сообществах по открытым данным

   3. Запросить консультантов/специализированные компании поставщики по добыче данные

3. Оценить стоимость приобретения данных, либо оценкой трудозатрат внутренней команды, либо ценовыми предложениями от потенциальных поставщиков.

4. Обеспечить получение данных и мониторинг, как технической так и юридической доступности данных.

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

Разбираем документы. Например, Ваша компания создаёт продукт по мониторинг качества жизни в регионах России. Вы понимаете что Вам нужны данные криминальной статистики по российским регионам. Где их взять? Вы знаете сами или узнаете у специалиста или в профильных сообществах что эти данные публикуются на сайта Crimestat.ru и на сайте МВД России. Но на сайте Crimestat.ru они не обновляются c начала 2023 года, а на сайте МВД России публикуются в виде PDF отчетов. Поскольку Вам нужны актуальные данные то сайт Crimestat.ru не подходит. Теперь Ваша задача оценить стоимость преобразования PDF с сайта МВД России внутренними силами или на рынке услуг парсинга/разработки парсеров сайтов и документов под заказ.

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

Множественный выбор. Например, Ваша компания консультирует корпорации по экономическому состоянию территорий/стран куда те планируют выходить со своими продуктами. Для этого Вы ищите и используете доступные открытые или коммерческие данные. Вы находите что существует много поставщиков таких данных, начиная с национальных стат. служб стран и продолжая системами данных ООН, Всемирного банка, ряда банков развития. А также присутствуют несколько коммерческих поставщиков приводящих эти данные в нормализованный и более удобный вид, и поставщиков альтернативных данных, не использующих официальную статистику. Вы сводите источников данных в таблицу и взвешиваете их качество, оперативность, гранулярность и стоимость для окончательного решения. В итоге Вы можете выбрать в качестве источника, как открытые данные, так и коммерческую услугу, и иметь альтенативы в случае проблем с выбранным источником данных.

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

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

Более подробно о том как взаимодействовать с поставщиками, контролировать качество и управлять рисками будет в отдельной главе в одном из следующих текстов.

Поиск и исследование внутренних данных

Поиск и исследование внутренних данных - это именно то что является основным коммерческим предложением продуктов в категориях каталоги данных (data catalogs)1 и связанных с ними более комплексных продуктов (data intelligence, data observation platforms, data platforms, data workspaces) и так далее.

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

Основные функции каталогов данных

Это включает решения множества задач применяемых в зависимости от специализации продукта. Задачи решаются через следующие функции подобных продуктов:

• инвентаризация существующих баз данных, таблиц, представлений, сохранённых процедур, конвейеров данных, источников получения данных, направлений передачи данных, обработчиков и иных артефактов и объектов сбора, хранения, обработки и передачи данных.

• классификация сохранённых объёктов на предмет наличия персональных данных, смысловых (семантических) типов данных, областей применения, проектов

• мониторинг изменений схем данных, добавления новых и удаления существующих объектов сбора, хранения, обработки и передачи данных

• мониторинг прослеживаемости данных (data lineage) с возможностью идентификации первоисточника данных

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

• а также профилирование, документирование данных и управление метаданными.

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

Отдельно можно выделить каталоги данных по критериям облачного и корпоративного внедрения. Поскольку очень многие компании сейчас используюь один или несколько облачных хранилищ таких как AWS, Azure, Snowflake, Google Cloud, а также многочисленные облачные сервисы из Modern Data Stack, то есть категория каталогов данных которые можно называть Cloud-only. Они являются, либо частью одной из SaaS платформ, например, Amazon Data Catalog, Google Data Catalog, Oracle Data Catalog; либо они умеют работать с разными облачными каталогами и сами находятся в облаке, например, Cloudera, Secoda и многие другие.

Типы потребностей при внедрении каталогов данных

Работу с внутренними данными можно разделить на три-четыре основных потребности:

• Compliance. Поиск, систематизация и анализ всех внутренних баз данных, ресурсов и процессов для соответствия регуляторным требованиям таким как GDPR. К этой категории продуктов каталогов данных можно отнести такие решения как Collibra, Inmuta, Securiti. Несоблюдение регуляторных требований может приводить к серьёзным штрафам и другим неприятным последствиям2.

• Analytical needs. Решение задач связанных с работой аналитиков, возможность для них быстро находить необходимые данные, оценивать их качество, прослеживать их первоисточник при необходимости. Это такие продукты как Data.world, Datalogz, Datahu. Бывает и так что каталоги данных для аналитиков являются частью BI продуктов3.

• Engineering needs. Решение проблем с прерыванием конвейеров данных, изменением схем, качеством данных, систематизацией источников, баз данных, получателей данных и других объектов. Например, такие продукты как Datakin, OpenLineage, Monte Carlo. В гайдах к коммерческим продуктам немало расказывается о применении каталогов данных дата инженерами4

• ML needs. Популярный подвид потребности для аналитиков и инженеров, но с акцентом на data science, а то есть когда основные выгодоприобретатели от хороших данных и стабильно работающих конвейеров по поставке данных являются ML специалисты. Особенность в том что контроль доступности и поставки данных формируется вокруг автоматизированных процессов и продуктов машинного обучения.

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

В чьих интересах внедряют каталоги данных и кто пользователи

Потребности использования каталогов данных и решение задач поиска данных напрямую происходят от основных их пользователей, их можно определить следующим образом:

• Data analytics - поиск нужных данных, контроль их качества, документирование/использование документации

• Business analytics - поиск данных, контроль качества данных, интеграция с системами визуализации, использование бизнес-глоссариев работы с данными.

• Data engineers, DataOps, DevOps - контроль качества данных, процессов их обработки, конвейеров данных,

• Data scientists and ML specialists - поиск данных для машинного обучения, отслеживание конвейеров обработки данных и машинного обучения

• Privacy and security officers - отслеживание персональных данных, данных составляющих корпоративную тайну, контроль доступа к данным, подготовка compliance отчетов.

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

Рассмотрим несколько примеров, я специально описываю их обезличенно, но все они взяты из реальной жизни.

Утечки и риски. Среднего размера компания поддерживает множество баз данных, обрабатывает данные с помощью ETL продуктов и имеет несколько команд разработчиков и аналитиков. В течение года у компании происходит несколько утечек данных, как минимум одного из специалистов ловят на злоупотреблениях в использовании данных клиентов и другие инциденты. Руководство компании хочет повысить безопасность работы с данными и выбирает продукт дата каталога из категории Compliance. После разворачивания продукта и анализа баз данных и процедур обработки, ответственный за приватность данных в компании (CPO) устанавливает или актуализирует, при наличии, правила работы с данными. Каталог внедряется, в первую очередь, для того чтобы упростить работу CPO и ответственного за безопасность данных (CTO) и его внедрение устанавливает определенные правила работы для аналитиков, программистов и инженеров.

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

—

Много лишней работы. Средняя ИТ компания специализируется на продуктах на данных, продаёт их в виде сервисов, в виде доступа к базам данных напрямую, в виде дампов данных. Многие данные являются производными из многих разных источников, много унаследованных продуктов и ресурсов и несколько команд разработчиков. Технический директор всё чаще сталкивается с многократным дублированием одних и тех же данных полученных из одних и тех же источников разными командами, а также с тем что процесс онбординга (приёма на работу нового сотрудника и включение в работу) занимает всё большее время из-за фрагментированного описания данных, их обработки и так далее. Технический директор принимает решение о внедрении каталога данных с акцентом на автоматизацию подготовки документации, поиска дублей, отслеживания конвееров обработки данных. Заодно он решает ещё одну задачу, мониторинга процессов обработки данных и выявления сбоев в этих процессах. Для закрытия этой потребности технический директор выбирает продукт каталога данных с функциями data observability, отслеживания процессов работы с данными.

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

—

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

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

—

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

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

Эти примеры не исчерпывают все модели внедрения каталогов данных и все потенциальные потребности в поиске данных, но демонстрируют некоторые реалистичные сценарии.

Как понять нужен ли вам каталог внутренних данных и их инвентаризация?

Прежде чем инвентаризировать данные нужно понять, а нужно ли это вообще. Возможно масштаб задач этого совершенно не требует.

Самый простой способ это понять в том чтобы задать себе несколько вопросов:

1. Есть много разных баз данных и обработчиков данных, написаны за разные годы, часто уже без тех кто их разрабатывал.

2. Многие базы данных дублируются, документация на них фрагментирована

3. Часто возникают ситуации когда невозможно быстро найти ответственного за создание какой-либо базы данных или конвейера их обработки.

4. Регулярно возникают вопросы без ответа о том откуда берутся данные и куда они уходят.

5. У компании были утечки данных или инциденты со злоупотреблением доступом к персональным данным

6. Общее число специалистов разработки, аналитики и инженеров данных превышает 50 человек.

Если хотя бы на 3 из этих вопроса Вы ответили да, то определённо Вам стоит задуматься о внедрении каталога управления данными, хотя бы в самом простом и бесплатном варианте.

Как говорить о том зачем нужен корпоративный каталог данных

Итого, один из важнейших вопросов, во внутренней коммуникации, в как аргументировать внедрение инструментов data discovery таких как дата каталоги:

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

2. Если были утечки данных, то это один из инструментов их предотвращения. Безусловно не единственный, но важный.

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

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

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

Итого

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

В следующих частях будут раскрыты следующие темы:

• Обзор технических продуктов по каталогизации данных, с акцентом на продукты с открытым кодом.

• Особенности, сложности и ограничения применения каталогов данных

• Подробнее о том как искать данные для коммерческих продуктов на данных

• Особенности инвентаризации данных в госсекторе.

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

Leave a comment