Открытые данные как дата продукт

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

Не секрет что большая часть модных СУБД и инструментов обработки данных из дата инженерии в качестве примеров почти всегда приводят открытые данные. Это, примеры Clickhouse с OpenCellID и датасетом такси Нью-Йорка или это пример DuckDB с данными из OpenBuildings или, снова, датасет такси из Нью Йорка, но для СУБД Timescale и так далее.

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

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

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

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

А самые популярные форматы данных это: CSV, JSON, XML, XLSX, XLS и ещё множество форматов в своих специфических областях: геоданные, научные форматы и тд.

Ещё один пример, это данные на Datahub.io, где команда Datopian (одни и разработчиков ПО CKAN для публикации открытых данных) публикуют то что можно назвать качественными датасетами, например, коды аэропортов. Там вроде как многое неплохо, есть схема данных, есть описание и даже код конвеера Github Actions с помощью которого данные создаются.

Datopian - это компания в Великобритании, отпочковавшаяся от Open Knowledge Foundation и поддерживающих open source каталог открытых данных CKAN.

Но для самих данных нет ни API, ни кода для их интеграции, ни SDK, ни экспорта в форматах отличных от CSV. Если, к примеру, я захочу подключиться к ним через ClickHouse или DuckDB или любую другую RDBS или ETL/ELT инструменты, то все они будут "угадывать" структуру данных поскольку схема данных отдельна не приведена, да и если бы была приведена то большая часть инструментов с ними не работает. В этом смысле хоть какие-то типы определяются в JSON файлах и ещё лучше в Parquet файлах и других файлах удобных для загрузки в инструменты для работы с датафреймами: Polars, Pandas и тд.

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

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

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

Это единственный из известных мне продуктов по публикации открытых данных имеющих партнёрство с BigTech, в данном случае Amazon. Но количественно их не так много. Сотни инсталляций в мире, подавляющее их число во Франции откуда они и происходят.

OpenDataSoft имеет соглашение с Amazon и позиционируется как продукт для Умных городов, с преимущественным развертыванием его на базе Amazon AWS.

История с форматами файлов - это лишь пример, важный, но не единственный. Дата продукты, в том числе открытые, сейчас могут не иметь каталогизации. Они могут распространятся в виде репозиториев на Github, в виде библиотек для Python, JS или R, во всех возможных форматах и тд.

И это уже не только про техническую реализацию, но и про понимание аудитории.

К примеру, на Github есть репозиторий Country List с 5.2 тысячами звезд, а есть Country codes с 888 звездами, разница в 7 раз. Потому что, при том что Country codes полезный репозиторий и я не хочу ругать его создателей, это всё та же команда Datahub.io, но создатель Country List сделал сразу датасет во всех возможных форматах: JSON, YAML, XML, HTML,CSV, SQL (MySQL, PostgreSQL, SQLite, PHP, XLIFF) и на всех языках.

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

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

#opendata #thoughts #datasets