Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
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. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.
#opendata #api #statistics #thoughts
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. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.
#opendata #api #statistics #thoughts
👍11👏2
Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.
Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.
Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных
Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.
Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.
В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.
В этом смысле, если смотреть на продукты статистических служб к примеру, как на дата продукты то сразу в глаза бросается разница где их создатели делают реальный дата продукт, а где приложение для конечного пользователя. Чаще если делают приложение, то результат оказывается гораздо более посредственным чем когда делают доступными данные разными способами.
И это, конечно, относится не только к данным статистики.
Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html
#itarchitecture #datasaproduct #data #api
Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.
Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных
Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.
Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.
В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.
В этом смысле, если смотреть на продукты статистических служб к примеру, как на дата продукты то сразу в глаза бросается разница где их создатели делают реальный дата продукт, а где приложение для конечного пользователя. Чаще если делают приложение, то результат оказывается гораздо более посредственным чем когда делают доступными данные разными способами.
И это, конечно, относится не только к данным статистики.
Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html
#itarchitecture #datasaproduct #data #api
❤🔥7👍7❤2