В блоге статистического ведомства ООН о том как государства получают доступ к данным частных компаний [1] с акцентом на свежее регулирование Евросоюза The Data Act [2].

Краткие тезисы:
— некоторые данные есть только у крупных компаний и они не спешат делиться ими с госорганами
— попытки государств установить партнерства с компаниями в период пандемии сработали в 9 случаях из 41, из отчета Мирового Банка
— Евросоюз в The Data Act установил условия при которых компании обязаны предоставлять данные органам власти по запросу:
* реакция на чрезвычайную ситуацию, например, пандемию или природный катаклизм
* предупреждение чрезвычайной ситуации или восстановление
* ситуации предполагающие "исключительную необходимость" и отсутствие возможности или затруднение в приобретении данных.

Всё это к свежему российскому регулированию в котором российское гос-во также хочет получить доступ к данным коммерческих компаний.

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

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

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

—
Ссылки:
[1] https://unstats.un.org/unsd/undataforum/blog/the-eu-data-act-regulating-public-sector-access-to-privately-held-data/
[2] https://digital-strategy.ec.europa.eu/en/library/data-act-proposal-regulation-harmonised-rules-fair-access-and-use-data

#data #datasharing #legislation #laws #eu

Вышла версия 6.0 MongoDB, самой популярной документо-ориентированной NoSQL СУБД в мире. Если Вы никогда о ней не слышали и не читали, но работаете с JSON документами, то самое время узнать что это такое и как работает.

В новой версии анонсируют:
1. Улучшение работы с временными рядами
2. Улучшение работы с потоками изменений и возможности подписки на них
3. Улучшенная обработка сложных запросов
4. Больше операторов в языке запросов
5. Улучшенная синхронизация и новые операторы для этих задач
6. Улучшенная безопасность (запросы к зашифрованным данным)
7. Улучшения в поиске в виде фасетного поиска

Если посмотреть на всё это вместе, то кажется всё, в общем-то, очень даже неплохо. Продукт развивается, у него реально очень мало альтернатив, наиболее близкий по функциям продукт ArangoDB, но мигрировать на него требует переписать все запросы, поэтому основная конкуренция идет между MongoDB Cloud и MongoDB-совместимыми облачными базами данных.

Но я скажу честно, по личному опыту и практическому применению, MongoDB - это огромная находка и огромное разочарование.

Дело в том что для многих задач без высокой нагрузки, с иерархическими данными, созданием API с отдачей JSON и тд. у MongoDB очень много уникальных возможностей. Многое готово из коробки, язык запросов прост, привычен, удобства очень велики.

Но, как только дело доходит до высокой производительности то часто оказывается что использовать MongoDB как расширенное key-value хранилище - это норм, а много сложных запросов на больших данных оно не тянет. По многим причинам, рассказывать о них можно много и отдельно, но в целом high-load - это не про MongoDB.

Другая проблема MongoDB в неэффективном хранении данных, по сравнению с колоночными базами данных, к примеру. Это особенность архитектуры, у данных нет схем, нет возможности сжатия их по колонкам, что сжатие улучшает.

Но самая главная проблема в том что MongoDB нет в Modern data stack! Понятно что MDS - это концепция, а не четкий стек инструментов, но MongoDB попадает туда только как унаследованное хранилище данных.

Ключевые продукты популярные в MDS основаны на SQL и плоских структурах данных с чёткими спецификациями. Инструменты вроде dbt не поддерживают MongoDB, не поддерживают его и большая часть ETL инструментов и так далее.

Фактически MongoDB и другие документо-ориентированные NoSQL СУБД - это продукты в себе. Чтобы реализовать для них полноценный инструмент по контролю качества данных или их преобразованию придётся делать его узкозаточенным и, как следствие, плохо переносимым на другие продукты.

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

Ссылки:
[1] https://www.mongodb.com/blog/post/big-reasons-upgrade-mongodb-6-0

#mongodb #data #datatools #rdbms

В рубрике интересных наборов данных проекты по теме машинного обучения для кода, Machine Learning for Code [1] из Secure, Reliable and Intelligent Systems Lab, ETH Zurich.

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

Из интересного:
- Nice2Predict - модель структурных предсказаний, используется для предсказаний названий функций
- JSNice - деобфускатор Javascript, активно используется теми кто про него знает
- DeGuard - деобфускатор мобильных приложений для Андроид (.APK файлов), основан на Nice2Predict

А также стартап DeepCode (переименовался в Snyk Code) [2] предлагающий возможность ревизии кода с помощью ИИ и... автоматического исправления ошибок и уязвимостей.

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

Ссылки:
[1] https://www.sri.inf.ethz.ch/research/plml
[2] https://www.deepcode.ai

#ai #programming #datasets #coding

Как сохранить журналистику данных

Зачем медиа и новостным СМИ позаботиться об цифровом сохранении собственных материалов? Профессор Бахарех Херави (Bahareh Heravi) изучает возможности цифрового архивирования и сохранения динамического контента, созданного в дата-журналистских материалах. В основном это интерактив и визуализации данных. Самые частые проблемы:

1. Динамические визуализации данных являются «сложными цифровыми объектами», что значит — такой контент не может быть охвачен существующими инструментами и методами архивирования.
2. Сервисы визуализации данных могут внезапно закрываться, а доступ к контенту, созданному с помощью них, затем теряется.
3. Существуют зависимости, лежащие в основе визуализации, такие как конкретные языки программирования, библиотеки, базы данных, хостинговые платформы и разные сервисы (Flash Player), которые со временем устаревают и не поддерживаются создателями.

Все это затрудняет использование материалов дата-журналистики в исторической ретроспективе. Подробнее о том, какие решения предлагает Бахарех Херави для сохранения сложного динамического контента, узнайте в этой статье: https://datajournalism.com/read/longreads/how-to-save-data-journalism

Дополнительно научная статья «Preserving Data Journalism: A Systematic Literature Review»: https://www.tandfonline.com/doi/full/10.1080/17512786.2021.1903972

#datajournalism #digitalpreservation #digitalarchive