Открытые данные как дата продукт
Почему продвижение открытых данных не означает понимания их аудитории
Вдогонку к рассуждениям об оценке качества открытых данных и об актуальности оценки датасетов по 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