Пока я продолжаю думать над большим текстом про качество и управление данными в государстве, я сформулирую краткий тезис на котором буду настаивать.
В современном государстве любой продукт создаваемый органами власти или госучреждениями - это или продукт в виде данных или продукт основанный на данных (data product).
Например, продуктом на данных являются (должны быть!):
- информационные системы (самое очевидное!)
- реестры и информационные ресурсы
- нормативные документы включая их проекты
- все без исключения отчеты
- аналитические / государственные доклады и любая аналитика, например, "мониторинг" чего бы то ни было
- сервисы для граждан
и многое другое
Собственно data-driven government - это когда внутренние процессы выстроены так что сбор данных, потоки данных, их обработка и хранение выстроены под создание этих продуктов.
Причём за каждым есть своя логика:
1. Нормативные документы должны быть подкреплены обоснованиями. Они могут быть превращены в executive papers/executive laws (исполнимые документы) как это происходит сейчас с научными работами.
2. Аналитические документы/доклады и госдоклады все построены вокруг сбора данных, просто очень архаичным образом как правило.
3. Реестры и информационные ресурсы де-факто - это всегда про сбор и представление данных для, как правило, неограниченного числа потребителей.
и так далее и многое другое.
Катастрофу [отсутствия] цифровой трансформации в Росстате можно понять именно по наличию перехода к подобным явно заявленным дата продуктам, а не к текущим публикациям статистических сборников в формах непригодных для современной аналитической работы. Также как и у других ведомств публикующим сейчас госдоклады с годовой задержкой (Минприроды) или Росгидромет выдающий из систем своих учреждений только ежегодную/ежемесячную аналитику в виде PDF отчетов, вместо данных чуть ли не реального времени. И так далее, и тому подобное.
#opendata #data #dataproducts #dataasaproduct
В современном государстве любой продукт создаваемый органами власти или госучреждениями - это или продукт в виде данных или продукт основанный на данных (data product).
Например, продуктом на данных являются (должны быть!):
- информационные системы (самое очевидное!)
- реестры и информационные ресурсы
- нормативные документы включая их проекты
- все без исключения отчеты
- аналитические / государственные доклады и любая аналитика, например, "мониторинг" чего бы то ни было
- сервисы для граждан
и многое другое
Собственно data-driven government - это когда внутренние процессы выстроены так что сбор данных, потоки данных, их обработка и хранение выстроены под создание этих продуктов.
Причём за каждым есть своя логика:
1. Нормативные документы должны быть подкреплены обоснованиями. Они могут быть превращены в executive papers/executive laws (исполнимые документы) как это происходит сейчас с научными работами.
2. Аналитические документы/доклады и госдоклады все построены вокруг сбора данных, просто очень архаичным образом как правило.
3. Реестры и информационные ресурсы де-факто - это всегда про сбор и представление данных для, как правило, неограниченного числа потребителей.
и так далее и многое другое.
Катастрофу [отсутствия] цифровой трансформации в Росстате можно понять именно по наличию перехода к подобным явно заявленным дата продуктам, а не к текущим публикациям статистических сборников в формах непригодных для современной аналитической работы. Также как и у других ведомств публикующим сейчас госдоклады с годовой задержкой (Минприроды) или Росгидромет выдающий из систем своих учреждений только ежегодную/ежемесячную аналитику в виде PDF отчетов, вместо данных чуть ли не реального времени. И так далее, и тому подобное.
#opendata #data #dataproducts #dataasaproduct
В рубрике интересное регулярное чтение:
- Every product will be data product [1] - статья о том что любой корпоративный продукт превращается в data product. Мои предыдущие мысли о том что любой госпродукт - это data product очень похожи [2]. Превращение / восприятие любого цифрового продукта как продукта на данных - это очень логично.
- dbd: new ELT tool that you’ll love [3] - автор пишет про свежесозданный инструмент dbd для задач ETL (Extract Transform Load) с примерами загрузки данных. Не то чтобы ETL инструментов было мало, в том числе с открытым кодом, но может пригодится и этот [4]. Инструмент совсем свежий, написан на Python и, похоже, рабочий.
- (P)TL, a new data engineering architecture [5] - автор пытается описать новую архитектуру работы с данными как Pushing Transform Load, где Pushing заменяет Extract и сводится к тому что "давайте вместо извлечения данных будем получать их в структурированном виде из потоковых источников вроде Kafka". Проблема в том что такой подход работает только в случае управляемых источников данных, причём скорее внутренних или очень зрелых внешних способных отдавать поток данных.
- The Modern Metadata Platform: What, Why, and How? [6] - видение современной платформы метаданных от Metaphor, стартапа, как уже понятно, декларирующего создание именно такой платформы. Интересно, по сути, описанием стратегии на то что платформы управления метаданными - это давно уже не только индексация таблиц, а систематизация баз данных, дашбордов, озёр данных, ETL, A/ML и многое другое. Metaphor делает та же команда что создала Datahub в Lyft [7] так что эти рассуждения достойны внимания.
- AutoDoc — a project to document automatically your data warehouse [8] - о том как один из продуктов каталогизации данных автоматически документирует данные из популярных источников. Они отслеживают когда пользователь подключает данные из одного из популярных источников вроде Salesforce, Facebook Ads, Google Ads, HubSpot и ещё нескольких десятков (всего 61) и автоматически добавляют документацию и метаданные которые заранее собраны и привязаны к полям/таблицам из этих источников. Интересный подход, в DataCrafter'е мы используем другой, кучу правил идентификации типов данных на основе их содержания [9], технологически это сложнее.
- The MAD Landscape 2021 — A Data Quality Perspective [10] - обзор стартапов по автоматическому мониторингу инфраструктуры данных и качества данных, data observability и data quality. Обзор интересный про 3 основных способа контроля качества данных: на основе правил, машинного обучения и статистики.
А в качестве завершения, как сформулировано в последней заметке Data is eating the world по аналогии с известной фразой Марка Андерсена Software is eating the world.
Ссылки:
[1] https://medium.com/kyligence/every-product-will-be-a-data-product-19e648f0333
[2] https://yangx.top/begtin/3423
[3] https://zsvoboda.medium.com/declarative-database-management-89d79e80d0cb
[4] https://github.com/zsvoboda/dbd
[5] https://adoreme.tech/p-tl-a-new-data-engineering-arhitecture-1dee8b7a84c0
[6] https://metaphor.io/blog/the-modern-metadata-platform
[7] https://engineering.linkedin.com/blog/2019/data-hub
[8] https://medium.com/castor-app/docmaster-a-project-to-auto-document-your-data-warehouse-castor-blog-69005927c4c3
[9] https://data.apicrafter.ru/class
[10] https://medium.com/validio/the-mad-landscape-2021-a-data-quality-perspective-e633f71c3eff
#dataquality #data #reading #dataengineering #metadata #dataproducts
- Every product will be data product [1] - статья о том что любой корпоративный продукт превращается в data product. Мои предыдущие мысли о том что любой госпродукт - это data product очень похожи [2]. Превращение / восприятие любого цифрового продукта как продукта на данных - это очень логично.
- dbd: new ELT tool that you’ll love [3] - автор пишет про свежесозданный инструмент dbd для задач ETL (Extract Transform Load) с примерами загрузки данных. Не то чтобы ETL инструментов было мало, в том числе с открытым кодом, но может пригодится и этот [4]. Инструмент совсем свежий, написан на Python и, похоже, рабочий.
- (P)TL, a new data engineering architecture [5] - автор пытается описать новую архитектуру работы с данными как Pushing Transform Load, где Pushing заменяет Extract и сводится к тому что "давайте вместо извлечения данных будем получать их в структурированном виде из потоковых источников вроде Kafka". Проблема в том что такой подход работает только в случае управляемых источников данных, причём скорее внутренних или очень зрелых внешних способных отдавать поток данных.
- The Modern Metadata Platform: What, Why, and How? [6] - видение современной платформы метаданных от Metaphor, стартапа, как уже понятно, декларирующего создание именно такой платформы. Интересно, по сути, описанием стратегии на то что платформы управления метаданными - это давно уже не только индексация таблиц, а систематизация баз данных, дашбордов, озёр данных, ETL, A/ML и многое другое. Metaphor делает та же команда что создала Datahub в Lyft [7] так что эти рассуждения достойны внимания.
- AutoDoc — a project to document automatically your data warehouse [8] - о том как один из продуктов каталогизации данных автоматически документирует данные из популярных источников. Они отслеживают когда пользователь подключает данные из одного из популярных источников вроде Salesforce, Facebook Ads, Google Ads, HubSpot и ещё нескольких десятков (всего 61) и автоматически добавляют документацию и метаданные которые заранее собраны и привязаны к полям/таблицам из этих источников. Интересный подход, в DataCrafter'е мы используем другой, кучу правил идентификации типов данных на основе их содержания [9], технологически это сложнее.
- The MAD Landscape 2021 — A Data Quality Perspective [10] - обзор стартапов по автоматическому мониторингу инфраструктуры данных и качества данных, data observability и data quality. Обзор интересный про 3 основных способа контроля качества данных: на основе правил, машинного обучения и статистики.
А в качестве завершения, как сформулировано в последней заметке Data is eating the world по аналогии с известной фразой Марка Андерсена Software is eating the world.
Ссылки:
[1] https://medium.com/kyligence/every-product-will-be-a-data-product-19e648f0333
[2] https://yangx.top/begtin/3423
[3] https://zsvoboda.medium.com/declarative-database-management-89d79e80d0cb
[4] https://github.com/zsvoboda/dbd
[5] https://adoreme.tech/p-tl-a-new-data-engineering-arhitecture-1dee8b7a84c0
[6] https://metaphor.io/blog/the-modern-metadata-platform
[7] https://engineering.linkedin.com/blog/2019/data-hub
[8] https://medium.com/castor-app/docmaster-a-project-to-auto-document-your-data-warehouse-castor-blog-69005927c4c3
[9] https://data.apicrafter.ru/class
[10] https://medium.com/validio/the-mad-landscape-2021-a-data-quality-perspective-e633f71c3eff
#dataquality #data #reading #dataengineering #metadata #dataproducts
Medium
Every Product Will Be a Data Product
Why build a data product? Typical use cases of data product
У DataIKU [1], платформы для совместной работы над Data Science проектами, вышел небольшой обзор 3 Keys to a Modern Data Architecture Strategy Fit For Scaling AI [2].
Как и практически все продукты на текущем рынке работы с данными, ML/AI они пишут про своё место в Modern Data Stack определяя его в блоках трансформации данных (Transform) и Data Science.
Тут важно понимать что DataIKU - это дорогая платформа для крупных компаний ещё и с сильным акцентом на ИТ безопасность, потому они и пишут в своём обзоре что миграция в облако не так уж небезопасна. Год назад я пытался у продавцов DataIKU выяснить стоимость их продукта, но даже 5 писем и 3-х созвонов с ними не хватило и ответа я так и не получил, хотя и сам продукт интересный и его бесплатную версию интересно посмотреть хотя бы для понимания как такие продукты устроены и можно ли сделать более дешёвую, дружелюбную альтернативу.
Ссылки:
[1] https://www.dataiku.com
[2] https://content.dataiku.com/modern-data-architecture/modern-data-architecture
#datascience #moderndatastack #data #dataproducts
Как и практически все продукты на текущем рынке работы с данными, ML/AI они пишут про своё место в Modern Data Stack определяя его в блоках трансформации данных (Transform) и Data Science.
Тут важно понимать что DataIKU - это дорогая платформа для крупных компаний ещё и с сильным акцентом на ИТ безопасность, потому они и пишут в своём обзоре что миграция в облако не так уж небезопасна. Год назад я пытался у продавцов DataIKU выяснить стоимость их продукта, но даже 5 писем и 3-х созвонов с ними не хватило и ответа я так и не получил, хотя и сам продукт интересный и его бесплатную версию интересно посмотреть хотя бы для понимания как такие продукты устроены и можно ли сделать более дешёвую, дружелюбную альтернативу.
Ссылки:
[1] https://www.dataiku.com
[2] https://content.dataiku.com/modern-data-architecture/modern-data-architecture
#datascience #moderndatastack #data #dataproducts
Dataiku
Home
Build, deploy, and manage data, analytics, and AI projects, realizing your Everyday AI vision with The Universal AI Platform™
Закрывается QRI [1], а на qri.cloud более нельзя размещать свои датасеты. QRI - это один из стартапов, публичный каталог данных, за которым я давно слежу. Проект существовал с 2016 года и удивительно что его создатели так и не привлекли инвестиций [2]. QRI позволяли подготовить данные для публикации с помощью довольно удобного инструмента QRI Desktop [3] или утилиту командной строки [4].
Например, если сравнивать QRI с Dolthub, Splitgraph и с Data.world, другими общедоступными каталогами данных, то им удалось привлечь финансирование и они продолжают развиваться.
А автор QRI делает два пессимистичных вывода что:
а) Данные - это не код (этот тезис понятный, но дискуссионный).
б) Сложно конкурировать с Web2 компаниями на стеке Web3 (этот тезис я не до конца понимаю)
В QRI было опубликовано 3,447 датасетов общим объёмом 49.2 гигабайта. Что, скажем честно, немного. К примеру в Splitgraph агрегирует 26 тысяч датасетов [5], в основном с порталов открытых данных США и Великобритании.
В DataCrafter'е у нас 3,4 терабайта данных [6] и 5972 набора данных, что, на самом деле, искусственное ограничение текущей архитектуры. В отличие от других каталогов данных DataCrafter базируется на NoSQL движке MongoDB, я рассказывал об этом на Smart Data Conf в презентации [7] и это даёт одновременно большие плюсы потому что данные не только плоские, а в DataCrafter'е больше половины данных это сложные структуры данных, не табличные. А с другой стороны это же и создает недостатки поскольку:
а) Стоимость хранения данных выше
б) У MongoDB есть ограничения числа коллекций на один экземпляр СУБД.
В остальном DataCrafter похож на Splitgraph. Нет данных от пользователей, только агрегируемые извне, ре-структурируемые и отдаваемые через API.
Возвращаясь к QRI я, по прежнему, удивлён что авторы закрывают его, а не перезапускают. Каталоги данных и технологии работы с ними сейчас на взлёте. Вообще на рынке работы с данными я вижу два восходящих тренда:
1) Технологии и продукты интегрированные в Modern Data Stack. Не "одна платформа/один продукт для всего", а именно что создание +1 компонента из которого дата инженеры собирают стек данных компании.
2) Альтернативные источники данных - в этом случае это data as a product, когда компания собирает какие-либо уникальные данные необходимые рынку. Более всего alternative data развито сейчас в финансовой сфере, особенно в сфере. Самый известный продукт в этой области - Quandl, купленный Nasdaq и превращённый в Nasdaq Data Link [8]
Ссылки:
[1] https://qri.io/winding_down
[2] https://www.crunchbase.com/organization/qri
[3] https://github.com/qri-io/desktop
[4] https://github.com/qri-io/qri
[5] https://www.splitgraph.com/explore
[6] https://data.apicrafter.ru/about
[7] https://www.beautiful.ai/player/-MtnRreZQZbCZH_PbKLf
[8] https://data.nasdaq.com/
#data #datacatalogs #qri #dataproducts
Например, если сравнивать QRI с Dolthub, Splitgraph и с Data.world, другими общедоступными каталогами данных, то им удалось привлечь финансирование и они продолжают развиваться.
А автор QRI делает два пессимистичных вывода что:
а) Данные - это не код (этот тезис понятный, но дискуссионный).
б) Сложно конкурировать с Web2 компаниями на стеке Web3 (этот тезис я не до конца понимаю)
В QRI было опубликовано 3,447 датасетов общим объёмом 49.2 гигабайта. Что, скажем честно, немного. К примеру в Splitgraph агрегирует 26 тысяч датасетов [5], в основном с порталов открытых данных США и Великобритании.
В DataCrafter'е у нас 3,4 терабайта данных [6] и 5972 набора данных, что, на самом деле, искусственное ограничение текущей архитектуры. В отличие от других каталогов данных DataCrafter базируется на NoSQL движке MongoDB, я рассказывал об этом на Smart Data Conf в презентации [7] и это даёт одновременно большие плюсы потому что данные не только плоские, а в DataCrafter'е больше половины данных это сложные структуры данных, не табличные. А с другой стороны это же и создает недостатки поскольку:
а) Стоимость хранения данных выше
б) У MongoDB есть ограничения числа коллекций на один экземпляр СУБД.
В остальном DataCrafter похож на Splitgraph. Нет данных от пользователей, только агрегируемые извне, ре-структурируемые и отдаваемые через API.
Возвращаясь к QRI я, по прежнему, удивлён что авторы закрывают его, а не перезапускают. Каталоги данных и технологии работы с ними сейчас на взлёте. Вообще на рынке работы с данными я вижу два восходящих тренда:
1) Технологии и продукты интегрированные в Modern Data Stack. Не "одна платформа/один продукт для всего", а именно что создание +1 компонента из которого дата инженеры собирают стек данных компании.
2) Альтернативные источники данных - в этом случае это data as a product, когда компания собирает какие-либо уникальные данные необходимые рынку. Более всего alternative data развито сейчас в финансовой сфере, особенно в сфере. Самый известный продукт в этой области - Quandl, купленный Nasdaq и превращённый в Nasdaq Data Link [8]
Ссылки:
[1] https://qri.io/winding_down
[2] https://www.crunchbase.com/organization/qri
[3] https://github.com/qri-io/desktop
[4] https://github.com/qri-io/qri
[5] https://www.splitgraph.com/explore
[6] https://data.apicrafter.ru/about
[7] https://www.beautiful.ai/player/-MtnRreZQZbCZH_PbKLf
[8] https://data.nasdaq.com/
#data #datacatalogs #qri #dataproducts
Qri.io
Qri is an open source version control and sharing system for datasets