Для тех кто работал/работает с данными в России и не могут найти данные портала федерального портала data.gov.ru поскольку он недоступен напомню что у нас есть полная архивная копия данных собранное на 2 февраля 2022 года [1]. 13ГБ архив и 29ГБ после распаковки. Не бог весть какие ценные там данные, но могут быть полезны тем кому они могут быть полезны.
Ссылки:
[1] https://hubofdata.ru/dataset/datagovru-20220202
#opendata #data #datagovru #russia
Ссылки:
[1] https://hubofdata.ru/dataset/datagovru-20220202
#opendata #data #datagovru #russia
hubofdata.ru
Архив данных портала открытых данных РФ data.gov.ru на 2 февраля 2022 г - Хаб открытых данных
Слепок всех данных с портала data.gov.ru на 2 февраля 2022 г.
Включает все файлы данных опубликованных на портале
Объём данных после распаковки 29 ГБ.
Включает все файлы данных опубликованных на портале
Объём данных после распаковки 29 ГБ.
Итальянское антикоррупционное агентство опубликовало свежие наборы данных о закупках органов власти в Италии [1] в форматах JSON и CSV. А также открыли дашборд с графиками и структурой расходов [2]. Данные в формате Open Contracting Data Standard [3] который постепенно всё больше и больше распространяется по миру, как минимум в Европе и Латинской Америке.
Кстати у Open Contracting есть гайд [4] по тому как работать с данными о госконтрактах с примерами.
Краткий обзор реестров конечных бенефициаров в странах Евросоюза Ultimate Beneficial Owners Registers in the EU 2022 [5], авторы из Польши и поэтому делают акцент на том что у них есть специальный реестр и приводят несколько графиков того как это в Европе устроено. Конечно, хотелось бы ту же информацию более структурированно, но и это полезно. Для тех кто не знает, реестры бенефициарных владельцев - это не реестры юридических лиц, это сведения именно о их конечных владельцах, через все структуры и "прокладки". В России требования раскрытия бенефициаров применяются только в части банковской системы, но не в виде реестра, а неструктурированно в виде схем в PDF предоставляемых банками.
Ссылки:
[1] https://dati.anticorruzione.it/opendata/organization/anticorruzione
[2] https://dati.anticorruzione.it/superset/dashboard/appalti/
[3] https://standard.open-contracting.org/latest/en/
[4] https://docs.google.com/document/d/1YXPDn_psBVPdeV6dE21TepLW7nEUUZEWDYZixIL51MQ/edit
[5] https://medium.com/transparent-data-eng/ultimate-beneficial-owners-registers-in-the-eu-2022-acc14a3057bc
#opendata #transparency #contracts #procurement #legalentities
Кстати у Open Contracting есть гайд [4] по тому как работать с данными о госконтрактах с примерами.
Краткий обзор реестров конечных бенефициаров в странах Евросоюза Ultimate Beneficial Owners Registers in the EU 2022 [5], авторы из Польши и поэтому делают акцент на том что у них есть специальный реестр и приводят несколько графиков того как это в Европе устроено. Конечно, хотелось бы ту же информацию более структурированно, но и это полезно. Для тех кто не знает, реестры бенефициарных владельцев - это не реестры юридических лиц, это сведения именно о их конечных владельцах, через все структуры и "прокладки". В России требования раскрытия бенефициаров применяются только в части банковской системы, но не в виде реестра, а неструктурированно в виде схем в PDF предоставляемых банками.
Ссылки:
[1] https://dati.anticorruzione.it/opendata/organization/anticorruzione
[2] https://dati.anticorruzione.it/superset/dashboard/appalti/
[3] https://standard.open-contracting.org/latest/en/
[4] https://docs.google.com/document/d/1YXPDn_psBVPdeV6dE21TepLW7nEUUZEWDYZixIL51MQ/edit
[5] https://medium.com/transparent-data-eng/ultimate-beneficial-owners-registers-in-the-eu-2022-acc14a3057bc
#opendata #transparency #contracts #procurement #legalentities
Google Docs
Open Contracting use cases guide #final
Вышла свежая версия Open Metadata 0.9.0 [1], каталога метаданных собирающего сведения о данных и процессах работы с ними.
Из интересного нового:
- много новых коннекторов к базам данных, теперь их 47 [2] поддерживают почти все популярные SQL базы данных
- поддерживают глоссарий терминов (смысловую привязку) к полям с данными
- дискуcсии к данным и отдельным полям
- контроль качества в виде стандартных метрик
В целом продукт быстро нагоняет другие каталоги данных такие как Amundsen или DataHub. Главным недостатком его остаётся отсутствие поддержки NoSQL баз данных таких как MongoDB и ElasticSearch
Ссылки:
[1] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882?gi=a94cfb8bcb3c
[2] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#8f53
[3] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#a91f
#data #metadata #opensource #datacatalogs
Из интересного нового:
- много новых коннекторов к базам данных, теперь их 47 [2] поддерживают почти все популярные SQL базы данных
- поддерживают глоссарий терминов (смысловую привязку) к полям с данными
- дискуcсии к данным и отдельным полям
- контроль качества в виде стандартных метрик
В целом продукт быстро нагоняет другие каталоги данных такие как Amundsen или DataHub. Главным недостатком его остаётся отсутствие поддержки NoSQL баз данных таких как MongoDB и ElasticSearch
Ссылки:
[1] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882?gi=a94cfb8bcb3c
[2] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#8f53
[3] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#a91f
#data #metadata #opensource #datacatalogs
Medium
OpenMetadata 0.9.0 Release
OpenMetadata 0.9.0 Release — Data Collaboration via Activity Feeds and Conversation Threads, Data Quality and Tests, Glossary Support …
Вышел AI Index Report 2022 [1] с оценкой развития ИИ по странам. Отчет большой, более 230 страниц, а также к нему много сопутствующих материалов. Россия там тоже упоминается, как именно рассказывать не буду, вся эта тема не про сравнение стран, а про развитие и эффективность регулирования.
Честно скажу, сравнивать развитие ИИ в России с любой другой страной я бы не стал, поскольку режим изоляции/самоизоляции науки в России сейчас будет крайне высок. Мониторить надо отток специалистов, если ещё не все уехали
Ссылки:
[1] https://aiindex.stanford.edu/report/
#ai #reports
Честно скажу, сравнивать развитие ИИ в России с любой другой страной я бы не стал, поскольку режим изоляции/самоизоляции науки в России сейчас будет крайне высок. Мониторить надо отток специалистов, если ещё не все уехали
Ссылки:
[1] https://aiindex.stanford.edu/report/
#ai #reports
В рубрике интересных инструментов по работе с данными ploomber ("сантехник") [1] движок на Python по работе с трубами данных. Главное достоинство - работа внутри notebooks (тетрадок) и примеры такой работы [2]. В январе 2022 года авторы присоединились к Y Combinator [3], так что почти наверняка продукт будет развиваться в сторону связки: бесплатный open source + платный cloud.
У проекта четкий акцент на интеграцию с инструментами для data science, так что может и через какое-то время он нарастит популярность.
Ссылки:
[1] https://github.com/ploomber/ploomber
[2] https://ploomber.io/
[3] https://ploomber.io/blog/yc/
#datascience #opensource #data #datatools
У проекта четкий акцент на интеграцию с инструментами для data science, так что может и через какое-то время он нарастит популярность.
Ссылки:
[1] https://github.com/ploomber/ploomber
[2] https://ploomber.io/
[3] https://ploomber.io/blog/yc/
#datascience #opensource #data #datatools
GitHub
GitHub - ploomber/ploomber: The fastest ⚡️ way to build data pipelines. Develop iteratively, deploy anywhere. ☁️
The fastest ⚡️ way to build data pipelines. Develop iteratively, deploy anywhere. ☁️ - ploomber/ploomber
Forwarded from Национальный цифровой архив
Для тех кто думает о сохранении материалов с Coub.com, в репозиторий coub-archival-campaign [1] на Github выложены данные собранные через API Coub.com, это по 5000 роликов по всем категориям и доступные ролики тематически собранные в группы Hot и Featured. Все данные собраны с помощью утилиты APIBackuper [2] выгружающей запросы к API в формате JSON lines. Из этих файлов можно простым способом выгрузить списки роликов на выгрузку.
Сейчас проведена архивация роликов из разделов Hot. Далее запланирована выгрузка роликов по другим категориям и выгрузка списков лучших Coub'ов по годам.
Большой помощью будет если кто-то поможет:
a) Выгрузить списки лучших роликов из разделов Best https://coub.com/best/2021, https://coub.com/best/2020 и тд. в форматах JSONL по аналогии с данными выше
b) Поможет выгрузить Coub'ы по категориям или темам. Для архивации через несколько дней мы организуем сервер куда можно будет ролики залить и также их можно загружать в Интернет Архив archive.org, в раздел Community Video. Это возможно после создания аккаунта на сайте Интернет архива.
Ссылки:
[1] https://github.com/ruarxive/coub-archival-campaign
[2] https://github.com/ruarxive/apibackuper
#opendata #coub #archives #api
Сейчас проведена архивация роликов из разделов Hot. Далее запланирована выгрузка роликов по другим категориям и выгрузка списков лучших Coub'ов по годам.
Большой помощью будет если кто-то поможет:
a) Выгрузить списки лучших роликов из разделов Best https://coub.com/best/2021, https://coub.com/best/2020 и тд. в форматах JSONL по аналогии с данными выше
b) Поможет выгрузить Coub'ы по категориям или темам. Для архивации через несколько дней мы организуем сервер куда можно будет ролики залить и также их можно загружать в Интернет Архив archive.org, в раздел Community Video. Это возможно после создания аккаунта на сайте Интернет архива.
Ссылки:
[1] https://github.com/ruarxive/coub-archival-campaign
[2] https://github.com/ruarxive/apibackuper
#opendata #coub #archives #api
Coub
Best coubs of 2021
Watch the year's top videos! Selected by our community and Coub editorial team
Полезное чтение про открытые данные
Открытый код эстонского портала открытых данных [1] [2]. Портал совместим со стандартом DCAT, разделен на компоненты код каждого из которых открыт. Всего 880 наборов данных. Всегда остаётся вопрос - зачем делать свой каталог/портал открытых данных когда есть несколько коммерческих и открытых продуктов? Но, видимо есть причина.
В ЕС анонсировали появление портала раскрытия информации о финансировании европейских проектов Kohesio.eu [4] на базе открытого кода Wikibase. Акцент там на том что это проект на открытых данных, но скорее это всё же проект по визуализации данных, датасеты там скачать нельзя, хотя недокументированное API наверняка есть. Скорее данные будут выкладывать на портале данных ЕС.
Интересные наборы данных
- набор данных твитов по теме COVID-19 [4], более 12 GB архив в сжатом виде
- набор данных для распознавания деревьев по их коре [5] для десяти видов деревьев встречающихся в умеренном климате. Небольшого объёма, десятки килобайт
- Europeana Sounds набор данных музыки и иных аудиозаписей из проекта агрегации культуры в Европе - Europeana [6] всего 21MB CSV файл с жанрами аудиозаписей
Ссылки:
[1] https://git.mkm.ee/avaandmete-portaal
[2] https://avaandmed.eesti.ee
[3] https://tech-news.wikimedia.de/en/2022/03/17/kohesio-eu-european-commission-goes-open-source/
[4] https://zenodo.org/record/6350198
[5] https://data.mendeley.com/datasets/pwfxgzz5fj/2
[6] https://zenodo.org/record/5536016
#opendata #datasets #opensource #dataportals
Открытый код эстонского портала открытых данных [1] [2]. Портал совместим со стандартом DCAT, разделен на компоненты код каждого из которых открыт. Всего 880 наборов данных. Всегда остаётся вопрос - зачем делать свой каталог/портал открытых данных когда есть несколько коммерческих и открытых продуктов? Но, видимо есть причина.
В ЕС анонсировали появление портала раскрытия информации о финансировании европейских проектов Kohesio.eu [4] на базе открытого кода Wikibase. Акцент там на том что это проект на открытых данных, но скорее это всё же проект по визуализации данных, датасеты там скачать нельзя, хотя недокументированное API наверняка есть. Скорее данные будут выкладывать на портале данных ЕС.
Интересные наборы данных
- набор данных твитов по теме COVID-19 [4], более 12 GB архив в сжатом виде
- набор данных для распознавания деревьев по их коре [5] для десяти видов деревьев встречающихся в умеренном климате. Небольшого объёма, десятки килобайт
- Europeana Sounds набор данных музыки и иных аудиозаписей из проекта агрегации культуры в Европе - Europeana [6] всего 21MB CSV файл с жанрами аудиозаписей
Ссылки:
[1] https://git.mkm.ee/avaandmete-portaal
[2] https://avaandmed.eesti.ee
[3] https://tech-news.wikimedia.de/en/2022/03/17/kohesio-eu-european-commission-goes-open-source/
[4] https://zenodo.org/record/6350198
[5] https://data.mendeley.com/datasets/pwfxgzz5fj/2
[6] https://zenodo.org/record/5536016
#opendata #datasets #opensource #dataportals
Я довольно давно не писал про коммерческие продукты которые мы делаем. Какие-то из них на слуху, какие-то не очень, но рассказать есть о чём. В этот раз немного про архитектуру работы с данными и технические особенности продуктов на данных.
—
Вот сейчас мы закончили переезд нашего каталога данных Datacrafter (data.apicrafter.ru) на новый сервер. Он снова доступен и должен работать значительно быстрее. А также продолжаем миграцию основных наших продуктов API к базам данных APICrafter (apicrafter.ru), по итогам они тоже будут быстрее чем ранее.
Это продукты про предоставление доступа к API с данными, а в последние несколько месяцев прошлого года я лично был погружен в перестройку его из продукта по продаже доступа к данным, в технологический продукт помогающий публиковать свои данные. Так сложилось что изначально DataCrafter создавался как моно-продукт с унаследованным кодом включавшем сбор, регистрацию и визуализацию данных с сильной заточкой под обработку больших бэтчей, опубликованных датасетов открытых данных. Внутри него много функций и упрощённых операций которые позволяют, например, огромный XML файлы быстро превратить в базу MongoDB, создать схему данных, автодокументировать всё что только возможно и опубликовать базу данных как API.
В итоге получилась хорошая, но не гибкая штука, с унаследованным кодом от которого ряд ограничений:
- описание источников данных идёт в коде на Python вместо конфигурационных файлов YAML как это делается в Meltano, dbt, soda, ploomber и других инструментах
- работа с метаданными "размазана" по компонентам, вместо концентрации только в реестре.
- обработка больших файлов сейчас не осуществляется параллельно, хотя это точно нужно для обработки слепков данных от нескольких гигабайт.
- компоненты не до конца разделены в отдельные продукты, пока полноценно отделен только apicrafter/metacrafter с помощью которого идёт классификация полей данных. А должно быть четкое деление на сборщик, регистратор данных, регистратор схем, фронт каталога, фронт управления (админка) и тд. но это же усложняет работу с данными, довольно сильно.
- архитектура не предусматривает модели плагинов для расширения отдельных блоков, например, сейчас в качестве адресата данных используется MongoDB, хотя некоторые данные могли бы загружаться и в другие NoSQL базы и в SQL базы поддерживающие JSON объекты
- для некоторых задач анализа структуры данных можно и нужно использовать нейросети, но пока это задача в не первая в списке
В итоге технически - это система работы с NoSQL данными, в современном стеке данных таких сейчас нет, все "танцуют" вокруг SQL во всех вариациях.
И почти всё это может быть переведено в открытый код + облачный сервис. А DataCrafter сейчас это эксперимент работающий на прототипе этой платформы.
Под такую платформу я и искал и ищу инвестиции на то чтобы её завершить и довести до продуктового состояния, а пока продолжаем наполнять наш каталог большими объёмами интересных данных;)
#opendata #datatools #datacatalogs #datarchitecture
—
Вот сейчас мы закончили переезд нашего каталога данных Datacrafter (data.apicrafter.ru) на новый сервер. Он снова доступен и должен работать значительно быстрее. А также продолжаем миграцию основных наших продуктов API к базам данных APICrafter (apicrafter.ru), по итогам они тоже будут быстрее чем ранее.
Это продукты про предоставление доступа к API с данными, а в последние несколько месяцев прошлого года я лично был погружен в перестройку его из продукта по продаже доступа к данным, в технологический продукт помогающий публиковать свои данные. Так сложилось что изначально DataCrafter создавался как моно-продукт с унаследованным кодом включавшем сбор, регистрацию и визуализацию данных с сильной заточкой под обработку больших бэтчей, опубликованных датасетов открытых данных. Внутри него много функций и упрощённых операций которые позволяют, например, огромный XML файлы быстро превратить в базу MongoDB, создать схему данных, автодокументировать всё что только возможно и опубликовать базу данных как API.
В итоге получилась хорошая, но не гибкая штука, с унаследованным кодом от которого ряд ограничений:
- описание источников данных идёт в коде на Python вместо конфигурационных файлов YAML как это делается в Meltano, dbt, soda, ploomber и других инструментах
- работа с метаданными "размазана" по компонентам, вместо концентрации только в реестре.
- обработка больших файлов сейчас не осуществляется параллельно, хотя это точно нужно для обработки слепков данных от нескольких гигабайт.
- компоненты не до конца разделены в отдельные продукты, пока полноценно отделен только apicrafter/metacrafter с помощью которого идёт классификация полей данных. А должно быть четкое деление на сборщик, регистратор данных, регистратор схем, фронт каталога, фронт управления (админка) и тд. но это же усложняет работу с данными, довольно сильно.
- архитектура не предусматривает модели плагинов для расширения отдельных блоков, например, сейчас в качестве адресата данных используется MongoDB, хотя некоторые данные могли бы загружаться и в другие NoSQL базы и в SQL базы поддерживающие JSON объекты
- для некоторых задач анализа структуры данных можно и нужно использовать нейросети, но пока это задача в не первая в списке
В итоге технически - это система работы с NoSQL данными, в современном стеке данных таких сейчас нет, все "танцуют" вокруг SQL во всех вариациях.
И почти всё это может быть переведено в открытый код + облачный сервис. А DataCrafter сейчас это эксперимент работающий на прототипе этой платформы.
Под такую платформу я и искал и ищу инвестиции на то чтобы её завершить и довести до продуктового состояния, а пока продолжаем наполнять наш каталог большими объёмами интересных данных;)
#opendata #datatools #datacatalogs #datarchitecture
apicrafter.ru
API Crafter
Весьма познавательное интервью [1] с George Fraser, сооснователем Fivetran, стартапа и продукта по сбору данных из многочисленных публичных источников/API и тд. В интервью он говорит про SQL, открытый код и революцию которую в это всё принесло появление dbt как продукта позволяющего создавать программные библиотеки для работы с SQL кодом.
Я уже несколько раз ранее писал что dbt стремительно набирает популярность, а создатели этого продукта уже привлекли огромные венчурные инвестиции.
При том что их облачный продукт для России уже малоактуален, а вот open source версия более чем востребована. В каком-то смысле это уникальный ренессанс работы с данными с помощью SQL, никем не ожидавшийся ещё несколько лет назад.
Ссылки:
[1] https://future.a16z.com/sql-needs-software-libraries/
#data #sql #dbt #articles #reading
Я уже несколько раз ранее писал что dbt стремительно набирает популярность, а создатели этого продукта уже привлекли огромные венчурные инвестиции.
При том что их облачный продукт для России уже малоактуален, а вот open source версия более чем востребована. В каком-то смысле это уникальный ренессанс работы с данными с помощью SQL, никем не ожидавшийся ещё несколько лет назад.
Ссылки:
[1] https://future.a16z.com/sql-needs-software-libraries/
#data #sql #dbt #articles #reading
Future
Why SQL Needs Software Libraries
Fivetran CEO George Fraser discusses the lack of software libraries for SQL, and how their emergence could change the nature of data analysis.
Опять же слегка отвлекаясь от обезличенного новостного потока, сформулирую несколько мыслей тезисами о происходящем которые постараюсь развить в полноценные тексты в будущем:
1. Один из больших рисков сейчас в том что кроме блокировки многих русскоязычных/российских онлайн ресурсов, Роскомнадзор может применять процедуры вроде разделегирования доменов или давления на редакции СМИ/организаций и тогда сайты с редакциями в России или в зоне .ru могут достаточно быстро исчезнуть.
2. Я так понимаю что никто до сих пор не измерял насколько большой урон по российской/русской культуре сейчас наносится и как много цифрового культурного наследия исчезает. Государственных архивов всего этого нет и не планируется, частные архивы охватят далеко не всё.
3. Интересна и важна судьба русского языка в мире. Если всё будет продолжаться как продолжается, то его начнут убирать из официальных языков структур ООН и других межгосударственных образований. Не сразу, но постепенно. Впрочем не та тема где хочется заниматься "анализом на диване".
4. Что в итоге будет с ИТ рынком в России ? Резкий рост предложений на рынке и падение доходов у ИТшников которые работали ранее за USD/EUR на зарубежные компании и не могут уехать? Или наоборот ещё более острый дефицит в виду массовости отъезда?
5. В моей профессиональной работе санкции - это большие ограничения. В первую очередь в том что исчезает возможность использовать продукты и сервисы к которым нужен доступ и исчезают экосистемы для сбора данных и интеграции. Российский рынок - это забыть про амбиции, международный рынок невозможен изнутри страны.
6. В не-мирное время открытость разрушается. Почти все открытые данные можно отнести к критически значимым. Но меньше открытости, меньше доверия, хуже принятие решений, хуже аналитика, разрушение внутреннего рынка для сервисных ИТ и информационных компаний. Я пока не могу представить, ни масштаб, ни последствий, ни формы как это будет происходить.
1. Один из больших рисков сейчас в том что кроме блокировки многих русскоязычных/российских онлайн ресурсов, Роскомнадзор может применять процедуры вроде разделегирования доменов или давления на редакции СМИ/организаций и тогда сайты с редакциями в России или в зоне .ru могут достаточно быстро исчезнуть.
2. Я так понимаю что никто до сих пор не измерял насколько большой урон по российской/русской культуре сейчас наносится и как много цифрового культурного наследия исчезает. Государственных архивов всего этого нет и не планируется, частные архивы охватят далеко не всё.
3. Интересна и важна судьба русского языка в мире. Если всё будет продолжаться как продолжается, то его начнут убирать из официальных языков структур ООН и других межгосударственных образований. Не сразу, но постепенно. Впрочем не та тема где хочется заниматься "анализом на диване".
4. Что в итоге будет с ИТ рынком в России ? Резкий рост предложений на рынке и падение доходов у ИТшников которые работали ранее за USD/EUR на зарубежные компании и не могут уехать? Или наоборот ещё более острый дефицит в виду массовости отъезда?
5. В моей профессиональной работе санкции - это большие ограничения. В первую очередь в том что исчезает возможность использовать продукты и сервисы к которым нужен доступ и исчезают экосистемы для сбора данных и интеграции. Российский рынок - это забыть про амбиции, международный рынок невозможен изнутри страны.
6. В не-мирное время открытость разрушается. Почти все открытые данные можно отнести к критически значимым. Но меньше открытости, меньше доверия, хуже принятие решений, хуже аналитика, разрушение внутреннего рынка для сервисных ИТ и информационных компаний. Я пока не могу представить, ни масштаб, ни последствий, ни формы как это будет происходить.
Продолжая рассуждения о том как устроена работа с данными - об отличиях в работе с данными в корпоративном секторе и данными публикуемыми госорганами, о том в чем заключаются ключевые отличия. Текст не претендует на полноту, скорее заготовка к большому тексту по той же теме.
Основное что важно понимать в интеграции государственных и корпоративных данных - это инертность обратной связи. При работе с корпоративными данными со многими источниками данных можно договориться, особенно если этот источник не супер-мега дата-корпорация, а частный поставщик данных за деньги. А вот случае государства даже если есть обратная связь то какие-либо изменения происходят очень долго, чаще всего проще найти альтернативные способы работы с данными чем их дождаться. Иначе говоря почти любой бизнес бизнес более клиентоориентирован чем госорганы.
Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления:
- слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, XML файлами в несколько гигабайт каждый в которых содержатся все данные в этом наборе данных
- документированные API - редки, содержат описание, как правило не в привычном формате вроде OpenAPI, а в виде PDF/DOC документа с описанием всего текстом по ГОСТу или близко к ГОСТу
- недокументированные API - наиболее распространены, есть почти на любом современном государственном ресурсе. К ним можно подключаться, выгружать данные, но нет никакой гарантии что всё это не слетит при следующем обновлении их системы. Документация отсутствует в принципе.
- API в режиме запрос-ответ - когда доступа к данным в чистом виде нет, но можно запросить сведения по конкретному запросу и получить данные только по нему
- неструктурированные данные - всё то что массово публикуется на сайтах в виде HTML/PDF/DOC и реже Excel файлов. Требует навыков извлечения и распознавания этих данных разными способами. Это не так сложно, но задаёт определенный "порог входа" при доступе к данным.
Более всего неструктурированных данных, далее много данных в виде батчей опубликовано на порталах открытых данных, очень много недокументированных API, значительно меньше документированных.
Всё это отличается от корпоративного сектора и довольно сильно. В корпоративном секторе, там где есть онлайн сервисы и цифровые онлайн продукты акцент идёт на API и доступность данных через API. Какие-то сервисы дают API за деньги (почти все API распознавания образов например), какие-то бесплатно для удержания в своей экосистеме (Github, Яндекс.Метрика и др.).
Поэтому практически все сервисы интеграции корпоративных данных в облаке построены вокруг сбора данных из API и прямого подключения к базам данных. Базы данных, как правило собственные, API, как правило, чужие и к ним пишутся многочисленные коннекторы вроде стандарта Singer [1] и тех что собраны в каталоге коннекторов Meltano [2]. Но в целом, и у других инструментов тот же подход, в приоритете подключение к сервисам предоставляющим API.
Отсюда возникает ситуация когда инструменты вроде Meltano, Airbyte, Singer, Fivetran и др. очень хорошо заточены под выгрузку на регулярной основе, вплоть до реального времени, из API, и почти не умеют и не адаптированы про то о чём я писал выше - работу с батчами, неструктурированными данными и недокументированным API.
Когда я начинал только писать движок в Datacrafter'е про сбор данных - он был как раз про ситуации когда API недокументировано, описания данных нет, файлы лежат батчами или надо из HTML страниц создавать наборы данных.
Ссылки:
[1] https://www.singer.io
[2] https://hub.meltano.com
#data #datatools #opendata #apicrafter #datacrafter
Основное что важно понимать в интеграции государственных и корпоративных данных - это инертность обратной связи. При работе с корпоративными данными со многими источниками данных можно договориться, особенно если этот источник не супер-мега дата-корпорация, а частный поставщик данных за деньги. А вот случае государства даже если есть обратная связь то какие-либо изменения происходят очень долго, чаще всего проще найти альтернативные способы работы с данными чем их дождаться. Иначе говоря почти любой бизнес бизнес более клиентоориентирован чем госорганы.
Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления:
- слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, XML файлами в несколько гигабайт каждый в которых содержатся все данные в этом наборе данных
- документированные API - редки, содержат описание, как правило не в привычном формате вроде OpenAPI, а в виде PDF/DOC документа с описанием всего текстом по ГОСТу или близко к ГОСТу
- недокументированные API - наиболее распространены, есть почти на любом современном государственном ресурсе. К ним можно подключаться, выгружать данные, но нет никакой гарантии что всё это не слетит при следующем обновлении их системы. Документация отсутствует в принципе.
- API в режиме запрос-ответ - когда доступа к данным в чистом виде нет, но можно запросить сведения по конкретному запросу и получить данные только по нему
- неструктурированные данные - всё то что массово публикуется на сайтах в виде HTML/PDF/DOC и реже Excel файлов. Требует навыков извлечения и распознавания этих данных разными способами. Это не так сложно, но задаёт определенный "порог входа" при доступе к данным.
Более всего неструктурированных данных, далее много данных в виде батчей опубликовано на порталах открытых данных, очень много недокументированных API, значительно меньше документированных.
Всё это отличается от корпоративного сектора и довольно сильно. В корпоративном секторе, там где есть онлайн сервисы и цифровые онлайн продукты акцент идёт на API и доступность данных через API. Какие-то сервисы дают API за деньги (почти все API распознавания образов например), какие-то бесплатно для удержания в своей экосистеме (Github, Яндекс.Метрика и др.).
Поэтому практически все сервисы интеграции корпоративных данных в облаке построены вокруг сбора данных из API и прямого подключения к базам данных. Базы данных, как правило собственные, API, как правило, чужие и к ним пишутся многочисленные коннекторы вроде стандарта Singer [1] и тех что собраны в каталоге коннекторов Meltano [2]. Но в целом, и у других инструментов тот же подход, в приоритете подключение к сервисам предоставляющим API.
Отсюда возникает ситуация когда инструменты вроде Meltano, Airbyte, Singer, Fivetran и др. очень хорошо заточены под выгрузку на регулярной основе, вплоть до реального времени, из API, и почти не умеют и не адаптированы про то о чём я писал выше - работу с батчами, неструктурированными данными и недокументированным API.
Когда я начинал только писать движок в Datacrafter'е про сбор данных - он был как раз про ситуации когда API недокументировано, описания данных нет, файлы лежат батчами или надо из HTML страниц создавать наборы данных.
Ссылки:
[1] https://www.singer.io
[2] https://hub.meltano.com
#data #datatools #opendata #apicrafter #datacrafter
Singer
Singer | Open Source ETL
Simple, Composable, Open Source ETL
На сайте ЦБ РФ из открытого доступа исчезли сведения о лицах, под контролем либо значительным влиянием которых находится кредитная организация. Например, это можно увидеть на странице Сбербанка [1] и в её копии в Интернет архиве на 11 января 2022 г. [2].
Причём были удалены не только разделы и ссылки на файлы, но и сами файлы. Частично они теперь остались в Интернет архиве, желающие легко их найдут
У меня, также, есть слепок данных сайта ЦБ РФ на 21.12.2021, там есть все эти документы. Мы как раз готовили эти данные для загрузки в Datacrafter, так что со временем они там появятся как наборы данных и API.
А сайт ЦБ надо, похоже, проверять, не исчезли ли что-то ещё.
Ссылки:
[1] https://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
[2] https://web.archive.org/web/20220111085025/https://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
#opendata #transparency #cbrf
Причём были удалены не только разделы и ссылки на файлы, но и сами файлы. Частично они теперь остались в Интернет архиве, желающие легко их найдут
У меня, также, есть слепок данных сайта ЦБ РФ на 21.12.2021, там есть все эти документы. Мы как раз готовили эти данные для загрузки в Datacrafter, так что со временем они там появятся как наборы данных и API.
А сайт ЦБ надо, похоже, проверять, не исчезли ли что-то ещё.
Ссылки:
[1] https://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
[2] https://web.archive.org/web/20220111085025/https://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
#opendata #transparency #cbrf
А также продолжение хроники постепенного исчезновения и закрытия данных. С официального сайта Алросы (www.alrosa.ru) исчезли сведения о наблюдательном совете. Они есть в Интернет архиве на начало года, но с сайта они удалены.
Интересно как долго останутся публичными сайты раскрытия информации о публичных компаниях (ПАО) ? Ведь там есть дублирование всех этих сведений.
#transparency #opendata #wtf
Интересно как долго останутся публичными сайты раскрытия информации о публичных компаниях (ПАО) ? Ведь там есть дублирование всех этих сведений.
#transparency #opendata #wtf
В блоге Spotify краткий пост о том как в компании команды переходят на систему управления потоками данных на базе Flyte [1], заменяя на него использовавшиеся ранее системы Luigi [2] и Flo [3]. В отличие от них Flyte [4] создавался с акцентом на задачи ML/Data science и с некоторыми особенностями которые отличают его от других движков.
1. Flyte построен на принципах что конфигурация это код. Вместо файлов YAML задачи описываются в коде на Python
2. Изначально разработан под расширение через код на Python
3. Автоматически отслеживает происхождение данных (data lineage)
И ещё много всего, продукт весьма интересный и, что немаловажно, простой в использовании.
А для тех кто ещё не определился на каком движке строить управление потоками данных, неплохая подборка в Awesome workflow engines [5]
Ссылки:
[1] https://engineering.atspotify.com/2022/03/why-we-switched-our-data-orchestration-service/
[2] https://github.com/spotify/luigi
[3] https://github.com/spotify/flo
[4] https://flyte.org/
[5] https://meirwah.github.io/awesome-workflow-engines/
#data #datatools #opensource #datapipelines
1. Flyte построен на принципах что конфигурация это код. Вместо файлов YAML задачи описываются в коде на Python
2. Изначально разработан под расширение через код на Python
3. Автоматически отслеживает происхождение данных (data lineage)
И ещё много всего, продукт весьма интересный и, что немаловажно, простой в использовании.
А для тех кто ещё не определился на каком движке строить управление потоками данных, неплохая подборка в Awesome workflow engines [5]
Ссылки:
[1] https://engineering.atspotify.com/2022/03/why-we-switched-our-data-orchestration-service/
[2] https://github.com/spotify/luigi
[3] https://github.com/spotify/flo
[4] https://flyte.org/
[5] https://meirwah.github.io/awesome-workflow-engines/
#data #datatools #opensource #datapipelines
Spotify Engineering
Why We Switched Our Data Orchestration Service
Why We Switched Our Data Orchestration Service - Spotify Engineering
Forwarded from Национальный цифровой архив
Как устроена веб-архивация в мире?
Веб-архивация - это один из видов цифровой архивации или архивации цифрового контента заключающаяся в том что архив ведет себя как поисковая система и с помощью специальной программы или набора программ называемых краулерами обходит страницы веб-сайта и сохраняет их содержимое, полностью, включая все связанные ресурсы, код Javascript, CSS и тд. или же частично сохраняя только содержимое. Веб архивы можно разделить на два подхода: ненаправленные и сфокусированные.
Ненаправленные веб архивы
Ненаправленные веб архивы ведут себя как поисковые системы эмулируя их максимально близко. Они имеют набор стартовых ссылок, а далее обходят сайты исходя из критерия числа ссылок на веб страницы. Самые известные ненаправленные архиваторы - это Common Crawl [1] и Wayback Machine [2]. Их достоинство - максимальная широта охвата, они обходят почти все известные и используемые сайты в интернете. Их недостаток - неполная глубина, они не собирают видео, аудио, сжатые файлы и далеко не все изображения.
Подобные архивы, также, практически всегда предоставляют API для получения данных и метаданных, с возможностью реконструкции исчезнувших сайтов.
Сфокусированные архивы
Кроме них существует множество инициатив по так называемой сфокусированной веб-архивации.
Самые известные:
- UKWA (UK Web Archive) [3] веб архив Великобритании совместная инициатива 6 национальных библиотек страны. Архивируют только сайты в зоне .uk и некоторые другие относящиеся напрямую к Великобритании.
- UK Government Web Archive [4] веб архив всех государственных сайтов Великобритании. Поддерживается Национальной службой архивов страны, обходит все сайты в зоне .gov.uk и ещё ряд сайтов по нескольку раз в сутки.
- Webarchiv Österreich [5] веб архив Австрии, охватывает все сайты домена .at и ещё ряда сайтов относящихся к Австрии. Поддерживается национальной библиотекой Австрии.
- Australian Web Archive [6] веб архив Австралии в рамках проекта Trove, Национальной библиотеки Австралии. Архивируют сайты по 18 категориям, не используют сплошную архивацию домена .au, но отбирают сайты по их культурной ценности
Проекты по веб архивации есть в большинстве развитых стран, как правило их создают службы национальных архивов или национальные библиотеки.
Подробнее о них можно узнать в статье в Википедии [7] где перечислены десятки подобных проектов по всему миру.
Кроме этих проектов существует ряд общественных и научных/исследовательских инициатив по архивации сайтов/данных по определенным темам; изменения климата, политические исследования, сохранение культурного наследия и т.д.
Все они возможны только при наличии технических возможностей которые для веб-архивов сопоставимы с крупными технологическими проектами. Архивы требуют больших объёмов хранения данных, хороших пропускных возможностей каналов архивации и инструментов предоставления результатов архивации гражданам.
В последние годы веб-архивация меняется, многие знания и данные уходят из веб'а в социальные сети, мобильные приложения и иные способы доступа недоступные классическим веб-краулерам. Веб-архивы оказываются неполны и недостаточны для охвата современных событий, а владельцы соцсетей всячески препятствуют сбору информации из их продуктов.
Ссылки:
[1] https://commoncrawl.org
[2] https://web.archive.org
[3] https://www.webarchive.org.uk/
[4] https://www.nationalarchives.gov.uk/webarchive/
[5] https://webarchiv.onb.ac.at/
[6] https://webarchive.nla.gov.au/collection
[7] https://en.wikipedia.org/wiki/List_of_Web_archiving_initiatives
#webarchival #digitalpreservation
Веб-архивация - это один из видов цифровой архивации или архивации цифрового контента заключающаяся в том что архив ведет себя как поисковая система и с помощью специальной программы или набора программ называемых краулерами обходит страницы веб-сайта и сохраняет их содержимое, полностью, включая все связанные ресурсы, код Javascript, CSS и тд. или же частично сохраняя только содержимое. Веб архивы можно разделить на два подхода: ненаправленные и сфокусированные.
Ненаправленные веб архивы
Ненаправленные веб архивы ведут себя как поисковые системы эмулируя их максимально близко. Они имеют набор стартовых ссылок, а далее обходят сайты исходя из критерия числа ссылок на веб страницы. Самые известные ненаправленные архиваторы - это Common Crawl [1] и Wayback Machine [2]. Их достоинство - максимальная широта охвата, они обходят почти все известные и используемые сайты в интернете. Их недостаток - неполная глубина, они не собирают видео, аудио, сжатые файлы и далеко не все изображения.
Подобные архивы, также, практически всегда предоставляют API для получения данных и метаданных, с возможностью реконструкции исчезнувших сайтов.
Сфокусированные архивы
Кроме них существует множество инициатив по так называемой сфокусированной веб-архивации.
Самые известные:
- UKWA (UK Web Archive) [3] веб архив Великобритании совместная инициатива 6 национальных библиотек страны. Архивируют только сайты в зоне .uk и некоторые другие относящиеся напрямую к Великобритании.
- UK Government Web Archive [4] веб архив всех государственных сайтов Великобритании. Поддерживается Национальной службой архивов страны, обходит все сайты в зоне .gov.uk и ещё ряд сайтов по нескольку раз в сутки.
- Webarchiv Österreich [5] веб архив Австрии, охватывает все сайты домена .at и ещё ряда сайтов относящихся к Австрии. Поддерживается национальной библиотекой Австрии.
- Australian Web Archive [6] веб архив Австралии в рамках проекта Trove, Национальной библиотеки Австралии. Архивируют сайты по 18 категориям, не используют сплошную архивацию домена .au, но отбирают сайты по их культурной ценности
Проекты по веб архивации есть в большинстве развитых стран, как правило их создают службы национальных архивов или национальные библиотеки.
Подробнее о них можно узнать в статье в Википедии [7] где перечислены десятки подобных проектов по всему миру.
Кроме этих проектов существует ряд общественных и научных/исследовательских инициатив по архивации сайтов/данных по определенным темам; изменения климата, политические исследования, сохранение культурного наследия и т.д.
Все они возможны только при наличии технических возможностей которые для веб-архивов сопоставимы с крупными технологическими проектами. Архивы требуют больших объёмов хранения данных, хороших пропускных возможностей каналов архивации и инструментов предоставления результатов архивации гражданам.
В последние годы веб-архивация меняется, многие знания и данные уходят из веб'а в социальные сети, мобильные приложения и иные способы доступа недоступные классическим веб-краулерам. Веб-архивы оказываются неполны и недостаточны для охвата современных событий, а владельцы соцсетей всячески препятствуют сбору информации из их продуктов.
Ссылки:
[1] https://commoncrawl.org
[2] https://web.archive.org
[3] https://www.webarchive.org.uk/
[4] https://www.nationalarchives.gov.uk/webarchive/
[5] https://webarchiv.onb.ac.at/
[6] https://webarchive.nla.gov.au/collection
[7] https://en.wikipedia.org/wiki/List_of_Web_archiving_initiatives
#webarchival #digitalpreservation
UK Government Web Archive
We capture, preserve, and make accessible UK central government information published on the web from 1996 to present.
Полезное чтение про modern data stack
- сравнение продуктов построения озер данных: Apache Hudi, Apache Iceberg и Delta [1]. Всё крутится вокруг экосистемы Apache Spark, со своими достоинствами и недостатками
- обработка данных в реальном времени в Grab [2]. В основе MySQL + Kafka + Kafka Connect + Debezium.
- построение современного стека работы с данными в Whatsnot [3]. У них не очень сложный стек, большая часть наблюдений за ним скорее через инфраструктурные инструменты вроде Datadog.
- Benn Stancil пишет о том что для стартапов выручка не должна быть ключевым KPI [4], лично я несогласен, но чтение полезное.
- описание свежей системы управления потоками данных DopplerTask [5] с открытым кодом. Написано на Javascript, из СУБД привязка явная к MySQL и есть low-code инструмент построения потоков задач. Больше напоминает n8, если честно
Ссылки:
[1] https://towardsdatascience.com/the-key-feature-behind-lakehouse-data-architecture-c70f93c6866f
[2] https://engineering.grab.com/real-time-data-ingestion
[3] https://medium.com/whatnot-engineering/building-a-modern-data-stack-at-whatnot-afc1d03c3f9
[4] https://benn.substack.com/p/startups-shouldnt-care-about-revenue?s=r
[5] https://medium.com/@feraswilson/dopplertask-a-revolutionary-open-source-automation-tool-b69e8167aba1
#datatools #opensource #reading #data #moderndatastack
- сравнение продуктов построения озер данных: Apache Hudi, Apache Iceberg и Delta [1]. Всё крутится вокруг экосистемы Apache Spark, со своими достоинствами и недостатками
- обработка данных в реальном времени в Grab [2]. В основе MySQL + Kafka + Kafka Connect + Debezium.
- построение современного стека работы с данными в Whatsnot [3]. У них не очень сложный стек, большая часть наблюдений за ним скорее через инфраструктурные инструменты вроде Datadog.
- Benn Stancil пишет о том что для стартапов выручка не должна быть ключевым KPI [4], лично я несогласен, но чтение полезное.
- описание свежей системы управления потоками данных DopplerTask [5] с открытым кодом. Написано на Javascript, из СУБД привязка явная к MySQL и есть low-code инструмент построения потоков задач. Больше напоминает n8, если честно
Ссылки:
[1] https://towardsdatascience.com/the-key-feature-behind-lakehouse-data-architecture-c70f93c6866f
[2] https://engineering.grab.com/real-time-data-ingestion
[3] https://medium.com/whatnot-engineering/building-a-modern-data-stack-at-whatnot-afc1d03c3f9
[4] https://benn.substack.com/p/startups-shouldnt-care-about-revenue?s=r
[5] https://medium.com/@feraswilson/dopplertask-a-revolutionary-open-source-automation-tool-b69e8167aba1
#datatools #opensource #reading #data #moderndatastack
Medium
The Key Feature Behind Lakehouse Data Architecture
Understanding the modern table formats and their current state
Свежая новость, с 13 апреля Яндекс.Облако подняли цены, в среднем на +60%
Почему они вынуждены это делать, в отдельном их посте [1], в основном из-за повышения стоимости железа.
Это о том что реальная инфляция - это то как растут расходы на то что ты используешь/потребляешь.
И это ещё без учёта того что скоро в стране может быть дефицит серверов и тогда стоимость облачных сервисов и серверов будет ещё выше.
Я бы сказал, конечно, что не надо ли государству отказаться от всех этих законов Яровой, проектов вроде Безопасный город (под них и нужны куча железа), но что-то мне подсказывает что не откажутся. Но это тема для отдельного рассуждения.
Ссылки:
[1] https://cloud.yandex.ru/blog/posts/2022/03/pricing-update-march-2022
#price #clouds #inflation #economics
Почему они вынуждены это делать, в отдельном их посте [1], в основном из-за повышения стоимости железа.
Это о том что реальная инфляция - это то как растут расходы на то что ты используешь/потребляешь.
И это ещё без учёта того что скоро в стране может быть дефицит серверов и тогда стоимость облачных сервисов и серверов будет ещё выше.
Я бы сказал, конечно, что не надо ли государству отказаться от всех этих законов Яровой, проектов вроде Безопасный город (под них и нужны куча железа), но что-то мне подсказывает что не откажутся. Но это тема для отдельного рассуждения.
Ссылки:
[1] https://cloud.yandex.ru/blog/posts/2022/03/pricing-update-march-2022
#price #clouds #inflation #economics
Тут все начали активно мигрировать в Telegram/VK, но не все понимают их отличия от *других соцсетей*.
В Telegram'е принципиально другая модель потребления контента. Тут нет "стены" со списком постов и надо подписываться на каналы, нормальный пользователь может читать до 20 каналов, но и это уже много. А больше совсем тяжело. Поэтому все очень избирательны в том что они читают, часто читают каналы агрегаторы не потому что те хорошие, а потому что так удобнее. Лично я начал вести свой канал 6 лет назад и всё это время прикладывал много сил к его продвижению, несмотря на то что пишу я на ну очень специфические для обывателя темы https://t.iss.one/begtin . Это совсем не так просто как может показаться и это ежедневная работа.
VK был и по большей части остаётся гигантским порнокинотеатром и молодежной соцсетью. Со своей спецификой, аудиторией, сервисами и тд. Не, там конечно много других сервисов и многие начнут мне возражать что там не только это. Да-да, конечно, там много всего, но без порно и пиратского видео популярность была бы кратно ниже. В любом случае невозможно вот так просто взять и перенести сообщества из FB в VK.
#thoughts #socialnetworks
В Telegram'е принципиально другая модель потребления контента. Тут нет "стены" со списком постов и надо подписываться на каналы, нормальный пользователь может читать до 20 каналов, но и это уже много. А больше совсем тяжело. Поэтому все очень избирательны в том что они читают, часто читают каналы агрегаторы не потому что те хорошие, а потому что так удобнее. Лично я начал вести свой канал 6 лет назад и всё это время прикладывал много сил к его продвижению, несмотря на то что пишу я на ну очень специфические для обывателя темы https://t.iss.one/begtin . Это совсем не так просто как может показаться и это ежедневная работа.
VK был и по большей части остаётся гигантским порнокинотеатром и молодежной соцсетью. Со своей спецификой, аудиторией, сервисами и тд. Не, там конечно много других сервисов и многие начнут мне возражать что там не только это. Да-да, конечно, там много всего, но без порно и пиратского видео популярность была бы кратно ниже. В любом случае невозможно вот так просто взять и перенести сообщества из FB в VK.
#thoughts #socialnetworks