Свежий любопытный BI(?) проект MotherDuck Data App Generator [1] который позволяет на основе датасета в DuckDB генерировать дата приложение. Приложение с открытым кодом, но зависит от инфраструктуры MotherDuck.

Хотя они и называют его Data App Generator, тут надо быть честными, это такой недо-BI, по крайней мере в текущей форме и примерах по генерации дашбордов.

Мне, честно говоря, показалось странным что они сделали такое, потому что визуализация данных не самая сильная сторона их команды, Mother Duck известны продуктом для облачной аналитики, но не BI. Но в итоге они, похоже, выбирают путь прокачки собственного продукта, а не интеграции с другими, предлагая свой продукт как бэкэнд.

В любом случае идея по генерации приложений на данных имеет право на существование и даже может быть весьма востребована.

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

Ссылки:
[1] https://motherduck.com/blog/data-app-generator/

#opensource #duckdb #data #dataapps #startups

Неплохая подборка примеров проектов в том что называют Rewrite Bigdata in Rust (RBiR) [1], а то есть по переписыванию функциональности и отдельных продуктов с открытым кодом на Rust, вместо Python или Java.

Подборка хорошая и примеры там все как один вполне применимые к инфраструктуре практически любого дата-продукта.

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

Ссылки:
[1] https://xuanwo.io/2024/07-rewrite-bigdata-in-rust/

#opensource #rust #bigdata #datatools #data

Симпатичный продукт для тетрадок работы с данными Briefer [1], обещают поддержку Python и SQL, генерацию Data apps, ИИ помощника и построение дашбордов.

Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.

Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/

#opensource #datatools #data

А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.

Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.

К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)


#sql #datatools #data

Полезное чтение про данные, технологии и не только:
- The Modern CLI Renaissance [1] о том как инструменты командной строки переживают ренессанс будучи переписанными, в основном, на Rust. Тоже наблюдаю эту картину и что тут скажешь, хорошо что это происходит.
- Nvidia and Oracle team up for Zettascale cluster: Available with up to 131,072 Blackwell GPUs [2] полным ходом гонка ИИ кластеров. Oracle и NVIDIA запускают в начале 2025 г. кластер на 2.4 зетафлопса, сравнивать сложно, это просто много
- Android apps are blocking sideloading and forcing Google Play versions instead [3] Google начали внедрять в андроид функцию установки приложения через Google Play если ты пытаешься поставить его из другого источника. То есть если ты из внешнего магазина загружаешь приложение которое есть в Google Play то тебя обязывают ставить то что в Google Play.
- Google will now link to The Internet Archive to add more context to Search results [4] Google теперь даёт ссылки в результатах поиска на Интернет Архив вместо их собственного кэша, на который они ранее ссылки удалили. Надеюсь они при этом дали денег Интернет Архиву, потому что как бы их не за ддосили.

Ссылки:
[1] https://gabevenberg.com/posts/cli-renaissance/
[2] https://www.tomshardware.com/tech-industry/artificial-intelligence/nvidia-and-oracle-team-up-for-zettascale-cluster-available-with-up-to-131072-blackwell-gpus
[3] https://arstechnica.com/gadgets/2024/09/android-now-allows-apps-to-block-sideloading-and-push-a-google-play-version/
[4] https://9to5google.com/2024/09/11/google-search-internet-archive-wayback-machine/

#software #data #google #android #readings

Полезные ссылки про данные, технологии и не только:
- Governing data products using fitness functions [1] полезная статья с определением того что такое Data Product и как ими управлять, в первую очередь с архитектурной точки зрения.
- UIS Data Browser [2] новый каталог данных (статистики) ЮНЕСКО, данных немного, но есть API и массовая выгрузка.
- Why is language documentation still so terrible? [3] гневная статья где автор ругает все языки программирования кроме Rust. Претензий много и я с ним согласен и не только в отношении языков. Хорошую документацию на SDK или open source продукты встретишь нечасто.
- How We Made PostgreSQL Upserts 300x Faster on Compressed Data [4] про оптимизацию загрузки данных в PostgreSQL с помощью TimescaleDB, лично я не видел этот движок в работе, но для каких-то задач он может быть именно тем что нужно
- ImHex [5] шестнадцатеричный редактор с открытым кодом для реверс инжиниринга. На мой взгляд мало что заменит IDA Pro, но для задач не требующих хардкора и когда нет денег вполне себе полезный инструмент.

Ссылки:
[1] https://martinfowler.com/articles/fitness-functions-data-products.html#ArchitecturalCharacteristicsOfADataProduct
[2] https://databrowser.uis.unesco.org/
[3] https://walnut356.github.io/posts/language-documentation/
[4] https://www.timescale.com/blog/how-we-made-postgresql-upserts-300x-faster-on-compressed-data/
[5] https://github.com/WerWolv/ImHex

#opensource #data #datacatalogs #documentation #dbs

В рубрике интересных наборов и каталогов данных, источники данных по блокчейну, Web 3
- Blockсhair datasets [1] дампы всех основных криптовалют: Bitcoin, Bitcoin Cash, Zcash, ERC-20, Ethereum, Dogecoin, Litecoin в виде коллекции сжатых TSV файлов
- Bitcoin Blockchain Historical Data [2] датасет на Kaggle адаптированный под data science прямо на платформе, только Bitcoin
- AWS Public Blockchain Data [3] дампы блокчейнов Bitcoin и Ethereum сразу в формате parquet
- Google Cloud Blockchain Analytics [4] данные и интерфейс работы с ними для 24 разных криптовалют на платформе Google Cloud

Ссылки:
[1] https://blockchair.com/dumps
[2] https://www.kaggle.com/datasets/bigquery/bitcoin-blockchain
[3] https://registry.opendata.aws/aws-public-blockchain/
[4] https://cloud.google.com/blockchain-analytics/docs/supported-datasets

#opendata #datasets #data #datacatalogs

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

Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?

Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.

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

А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.

В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.

Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?

Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.

В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.

В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.

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

#thoughts #data #datasets

Для тех кто любит применять правильные термины, оказывается ещё в июле 2024 г. вышел словарь CODATA Research Data Management Terminology [1] с подборкой англоязычных терминов по управлению исследовательскими данными.

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

Например, определение открытых данных звучит как:

Data that are accessible, machine-readable, usable, intelligible, and freely shared. Open data can be freely used, re-used, built on, and redistributed by anyone – subject only, at most, to the requirement to attribute and sharealike.[2]

Этот словарь доступен через портал Research Vocabularies Australia [3] агрегатор и поисковик по всем словарям используемым в исследовательских целях в Австралии.

Ссылки:
[1] https://vocabs.ardc.edu.au/viewById/685
[2] http://vocabs.ardc.edu.au/repository/api/lda/codata/codata-research-data-management-terminology/v001/resource?uri=https%3A%2F%2Fterms.codata.org%2Frdmt%2Fopen-data
[3] https://vocabs.ardc.edu.au

#opendata #semanticweb #data #datacatalogs #terms

В рубрике как это устроено у них есть большая тема про доступность данных которую никак не уложить в короткий текст да и длинных текстов понадобится немало. Про инфраструктуру открытых данных в медицине, тесно переплетённую с идеей открытого доступа в науке.

Сразу всё сложно, можно подступиться к к отдельным её частям.

...
Значительная часть открытых данных связанных с медицинскими исследованиями в мире публикуется благодаря политике Национального института здравоохранения США (NIH). И связано это с тем что у NIH есть последовательная политика:
1. Вначале предпочтительности, а далее обязательности открытого доступа для всех финансируемых им исследований.
2. Последовательная политика поощрения создания и создания собственных репозиториев данных и иных результатов научной деятельности.
3. Прямые инвестиции в инфраструктуру создания, обработки, визуализации и систематизации данных научных исследований.

Примеры реализации этих политик в виде каталога репозиториев данных поддерживаемых NIH [1] причём эти репозитории разделяются на Generalist и Domain Specific. Первые - это репозитории данных как датасетов, такие как Zenodo или OSF. Вторые - это специализированные репозитории данных где единицей измерения/учёта/записи являются, как правило, не датасеты, а объекты научной деятельности к которым привязаны данные. Это могут быть репозитории исследований (studies), репозитории геномов (genomes) и так далее. Как правило эти репозитории содержат существенное число метаданных связанных с медициной/биоинформатикой/генетикой и перевязаны между собой кросс ссылками.

По мере нарастания критической массы разных проектов, а там реально очень много проектов на данных у NIH есть Common Fund Data Ecosystem (CFDE) [2] по интеграции существующих дата порталов и иных дата проектов общими правилами и конвейерами обработки данных. А сама эта инициатива существует в рамках The Common Fund в рамках которого как раз финансируется общая инфраструктура, важная для всех направлений исследований [3].

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

Реальные объёмы данных, количественные и качественные там поражают и одновременно, это область весьма замкнутого применения. Она как бы полностью в себе, как и большая часть научных дисциплин. Во всяком случае так это выглядит со стороны человека не вовлеченного в них напрямую.
...

Ссылки:
[1] https://www.nlm.nih.gov/NIHbmic/domain_specific_repositories.html
[2] https://commonfund.nih.gov/dataecosystem
[3] https://commonfund.nih.gov/current-programs

#opendata #medicine #openaccess #health #data

В рубрике интересных поисковиков по данным Datacite Commons [1] это поисковик по научным данным, другим научным работам, научным организациям и репозиториям данных. Создан и развивается компанией DataCite, выдающей DOI для работ связанным с данными и собирающей единый индекс научных работ с метаданными объектов которые получили эти DOI.

Выглядит достаточно большим, 61 миллион работ включая 19 миллионов наборов данных [2].

Но, если присмотреться, то не всё так там с этим просто.
1) Значительная часть датасетов, около 2 миллионов, находятся на сервисе Data Planet [3] и публично недоступны, даже каталог посмотреть нельзя, только метаданные в DataCite.
2) Как минимум два источника - это GBIF и The Cambridge Structural Database это базы со структурированным описанием встречаемости видов и химических элементов. Это не датасеты, а как бы единые базы нарезанные на большое число записей. На эти записи по отдельности выдаются DOI, но называть их датасетами скорее неправильно.
3) Особенность метаданных в DataCite в отсутствии ссылок на файлы/ресурсы, поэтому те карточки датасетов что там есть не дают информации по реальному содержанию, только говорят о факте существования набора данных.

На фоне DataCite Commons у нас в Dateno реализовано гораздо больше, и с точки зрения объёмов проиндексированного, и с точки зрения удобства поиска.

Но не все источники данных из DataCite сейчас есть в Dateno и их ещё предстоит добавить. Ключевой вопрос в том рассматривать источники данных такие как GBIF как множество датасетов или не считать такое дробление обоснованным?

Ссылки:
[1] https://commons.datacite.org
[2] https://commons.datacite.org/statistics
[3] https://data.sagepub.com

#opendata #data #datasearch