Ivan Begtin
8.06K subscribers
1.5K photos
3 videos
99 files
4.25K links
I write about Open Data, Data Engineering, Government, Privacy and Data Preservation and other gov and tech stuff
Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech

Contact @NMBabina for ads proposals
Download Telegram
One Trillion Row Challenge - совершенно замечательный по задумке конкурс по работе с датасетом в триллион строк [1] для тех кто работает большими, очень большими и очень-очень большими (шутка) данными на обычном железе или во временно арендуемом облаке, а не на мейнфреймах. Конкурс в том чтобы подсчитать минимальную, среднюю и максимальную температуру по погодным станциям отсортированным по алфавиту. Данные хранятся в 100 тысячах Parquet файлах, по 10 миллионов строк в каждом, а заявки отправляются через открытие issue в репозитории конкурса [2].

Сам конкурс - это продолжение другого конкурса, One Billion Row Challenge [3], где данных было только 1 миллиард, и принимались решения только в виде Java кода.

Решения можно отправлять в дискуссиях на Github в репозитории [4].

Конкурс интересный тем что по многим продуктам не-неожиданно, но подтверждённо очень высокая производительность. Например, в Clickhouse SQL задача с 1 миллиардом строк решается за менее чем 7.5 секунд [5] и у них же 3 минуты на конкурс в 1 триллион строк [6] и пишут что за $0.56, это совсем мало если что.

А в оригинальном посте Dask в облаке Coiled отрабатывает за 8.5 минут или $3.26 в стоимости Amazon Cloud, что тоже очень мало.

Хороший бенчмарк, в ситуации интенсивной конкуренции между высокопроизводительными продуктами по обработке данных, он весьма полезен.

Ссылки:
[1] https://docs.coiled.io/blog/1trc.html
[2] https://github.com/coiled/1trc
[3] https://www.morling.dev/blog/one-billion-row-challenge/
[4] https://github.com/gunnarmorling/1brc/discussions
[5] https://github.com/gunnarmorling/1brc/discussions/80
[6] https://clickhouse.com/blog/clickhouse-1-trillion-row-challenge

#data #datasets #opensource #datatools
Я регулярно пишу про такое явление как датацентричное мышление "что угодно как таблица" и в более узком звучании "что-угодно как SQL". Причём последнее попадается всё чаще и всё чаще всё то ранее было доступно каким-то другим образом через API или в иной специфической форме доступно как таблицы.

Из последнего, sqlelf, это программная библиотека и утилита превращающая метаданные из исполняемых Linux файлов в базу Sqlite и позволяют проделывать все дальнейшие операции по чтению этих метаданных из SQL таблиц. Удобно для всех кто занимается форенсикой под Unix-like системы.

Из похожего, несколько лет назад я делал утилиту metawarc, индексирует содержание веб-архивов в формате WARC и создаёт локальную Sqlite базу с результатами. Что позволяет сильно ускорить задачи по подсчёту статистики, экспорту файлов из архива (архивы бывают большие и это важна задача) и многое другое. Единственное что я не сделал - это там нет SQL интерфейса, хотя добавить такую команду и примеры это дело пары часов.

Похожий код у меня есть для HTML страниц, он превращает дерево HTML в плоскую таблицу с дополнительным обсчётом ряда параметров. Я его всё подумывал опубликовать и возможно что база в памяти это решение. Возможно, потому сколько я не пытался не удаётся сильно уменьшить размеры таблицы тэгов. Она выходит больше оригинального файла от 7 до 21 раза, это без использования СУБД внутри, только размер pandas Dataframe.

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

Чем дольше я об этом думаю, тем более чувствую что такой подход может иметь существенный потенциал для технологических продуктов. Например, если бы сервисы счётчиков посещаемости и иной пользовательской аналитики предоставляли бы не REST API, а сразу доступ к SQL таблицам с твоими данными то это резко упростило бы их интеграцию и использование. Такие внешние сервисы, кстати, есть, но суть в том что SQL интерфейсы доступа не являются сейчас стандартизированными продуктами.

Аналогично для многих других сервисов и продуктов которые сейчас интегрируются через ETL и ELT костыли.

А сама идея "что-угодно как SQL" может развиваться ещё применительно много к чему. К файловой системе, к реестру Windows, к работе с Excel/ODS файлами, к работе с онлайн таблицами (типа Google Sheets), к вебсайтам и ещё много к чему.

#thoughts #data #datatools #sql #everythingisdata
В рубрике как это устроено у них каталог научных данных SPARC [1] посвящённый исследованиям тела и мозга. Является результатом совместного проекта нескольких исследовательских центров в США.

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

Отличается тем что данные, в основном, большого объёма и файлы до 5GB можно скачать бесплатно, а файлы большего размера только через Amazon AWS или через сервис Osparc [2] по запросу.

На портале есть уникальная фича, визуализация датасетов [3] с помощью утилиты SDS Viewer, вот, пример [4]

Ссылки:
[1] https://sparc.science
[2] https://osparc.io/
[3] https://metacell.github.io/sds-viewer/
[4] https://metacell.github.io/sds-viewer/?doi=10.26275%2Fodx3-c5cv

#opendata #datacatalogs #datatools #data #brain #body #datasets
Ещё один, нестандартный, каталог данных - это общедоступные инсталляции Superset [1]. Для тех кто не сталкивался ранее, Superset - это BI платформа с открытым кодом и с функциональностью каталога датасетов который там представлен в упрощённом виде, адаптированном под то что на основе данных строятся разного рода графики включаемые в дашборды.

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

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

Можно ли индексировать такие источники данных в поисковый индекс или это, всё же, ближе к инфобезу и утечкам данных?;)

Ссылки:
[1] https://superset.apache.org

#opendata #datasets #data #datatools #superset #bi #datacatalogs
Регулярная подборка ссылок про данные, технологии и не только:
- Vector DB Comparison [1] большой обзор в виде таблицы со сравнением векторных баз данных. Список подробный, со ссылками на документацию и представленностью практических всех продуктов с открытым кодом.
- Pretzel Notebook [2] тетрадки для работы с данными с DuckDB внутри и языком PRQL
- Common Corpus [3] авторы утверждают что это крупнейший датасет public domain текстов на разных языках
- DuckDB snippets [4] подборка сниппетов для DuckDB по использованию в командной строке. Замена многих инструментов в том числе самописных
- Binjr [5] браузер для временных рядов, с инсталляцией локально под Windows, Linux или Mac. В демках про мониторинг серверов, но может и для чего-то ещё сгодится?

Ссылки:
[1] https://superlinked.com/vector-db-comparison/
[2] https://github.com/pretzelai/pretzelai
[3] https://huggingface.co/collections/PleIAs/common-corpus-65d46e3ea3980fdcd66a5613
[4] https://duckdbsnippets.com/page/1/most-popular
[5] https://binjr.eu/

#opensource #datatools #data
Отличная тема в блоге DuckDB про 42.parquet или о том как запихнуть в Parquet файл 4 петабайта данных [1]. Для тех кто не вспомнил контекст, несколько лет назад по интернету ходил файл zip bomb, с названием 42.zip и размером в 42 килобайта. Внутри него, 5 вложенными слоями было по 16 пустых файлов в 4.3 ГБ. В общей сложности 4.3 петабайта. А это штука способная сильно испортить жизнь тем кто использует наивные антивирусы и другие сервисы распаковки архивов. Про него есть статья в Википедии по ссылками [2] для тех кто хочет изучить тему. Я специально про это не писал до 1 апреля во избежание обострения юмора у весёлых ребят;)

Как ни странно, Virustotal показывает [3] что запароленный zip bomb определяет только Fortinet, остальные сервисы и продукты его игнорируют. Может быть они незапароленные zip bomb ловят? Но пока не хочется проверять такое;)

А теперь то же самое для Parquet, 42.parquet от DuckDB. Может быть довольно жестокой шуткой над каким-то дата сайентистом, а может быть просто примером для тренировки навыков.

Я пока не знаю случаев когда сайты/информационные системы взламывали бы parquet файлами. Но может быть всё впереди? Например, начнут антивирусы и другие инфобезные продукты отслеживать утечки персональных данных из компаний и начнут сканировать parquet файлы, а тут им подсунут 42.parquet.

Похоже на реальный сценарий ;)

Ссылки:
[1] https://duckdb.org/2024/03/26/42-parquet-a-zip-bomb-for-the-big-data-age.html?
[2] https://en.wikipedia.org/wiki/Zip_bomb
[3] https://www.virustotal.com/gui/file/bbd05de19aa2af1455c0494639215898a15286d9b05073b6c4817fe24b2c36fa

#data #datatools #dataspecs #parquet #readings
Redis, хорошо известный продукт для большинства разработчиков использующих NoSQL, меняет лицензию на SSPL и перестаёт быть проектом со свободным исходным кодом [1]. SSPL запрещает использование продукта облачными провайдерами, без раскрытия полного кода всего кода облака (интерфейса, бэкэнда, дизайна и тд).

Тем временем Linux Foundation создали Valkey [2], открытый код Redis'а. А другие команды переходят на KeyDB и другие альтернативы.

Ссылки:
[1] https://arstechnica.com/information-technology/2024/04/redis-license-change-and-forking-are-a-mess-that-everybody-can-feel-bad-about/
[2] https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

#opensource #data #datatools
К вопросу о том почему я так часто писал в последнее время про форматы данных вроде Parquet которые из data science постепенно перебираются в другие дисциплины работы с данными. Вот наглядный пример, у меня на руках датасет который в несжатом виде занимает 195GB, а в сжатом .tar.gz около 22GB. Его владелец распространяет его именно в сжатой форме, но понятно что для работы с ним его приходится распаковывать, особенно учитывая что tar.gz не тот формат с которым удобно работать без полного его разжатия. Внутри датасета сплошные .jsonl файлы, удобный при любой работе с NOSQL, но не для хранения.

При этом, если пересжать все данные в архиве в формат parquet, то они сожмутся до 8-12GB, и с ними можно будет продолжить работу. Загрузить в СУБД из parquet в общем-то не проблема.

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

И сюда же, кстати, про мои давние размышления про поиск замены OpenRefine. Самым интересным продуктом было бы если бы внутренний движок OpenRefine можно было бы заменить на DuckDB. Тогда можно было бы на стандартном десктопном железе работать по очистке датасетов условно почти любого размера.

#data #datatools #parquet #duckdb
Подборка ссылок и моих наблюдений про то как публикуют данные в мире:

1. Китайский национальный центр по биоинформатике собирает базы общим размером более 51 петабайта [1] большая часть которых доступна для скачивания онлайн через их FTP сервер, посмотреть можно через веб интерфейс их FTP сервера [2]

2. THREDDS Data Server [3] софт с открытым кодом для публикации научных данных. Изначально создан для работы с метеорологическими данными и, в основном, так и применяется. Несколько десятков инсталляций по всему миру, хотя сам продукт очень консервативный и заточенный под конкретную область. Можно посмотреть пример такого каталога [4]

3. Github - это крупнейший каталог данных, но плохо структурированный. Опубликовать данные там просто, найти данные там сложно потому что будучи репозиторием кода датасеты там не структурированы в отдельную категорию. Можно искать их через правильные поисковые запросы, например, находя спецификации Frictionless Data которые в файлах datapackage.json [5]

4. Datamed [6] поисковик по биомедицинским датасетам, пишут что их там миллионы, по факту 1.2 миллиона из 49 репозиториев. Из них 80% датасетов из всего 4-х репозиториев имеющих более продвинутые формы поиска. Идея хорошая, реализация, на мой взгляд, не очень, недостаточно нового качества создаётся. Ну и индексируют они похоже отдельными парсерами под каждый источник и у них всё та же запутанность о том что считать датасетами.

5. Уже несколько раз сталкиваюсь с тем что, казалось бы, у типового ПО для публикации данных нет API. Нечасто но такое бывает и выясняется что это не нет API, а подход возврата разного содержания от передачи заголовка Accept: application/json в HTTP запросе. То есть, де-факто, API есть, но GET запрос не вернет JSON или другой машиночитаемый ответ. Любопытно насколько это распространено в публикации чего-то ещё, есть подозрение что это не такое редкое явление и не только про каталоги данных.

Ссылки:
[1] https://www.cncb.ac.cn/
[2] https://download.cncb.ac.cn/
[3] https://github.com/Unidata/tds
[4] https://thredds.rda.ucar.edu/thredds/catalog/catalog.html
[5] https://github.com/search?q=path%3A**%2Fdatapackage.json&type=code&ref=advsearch
[6] https://datamed.org/

#opendata #data #datasets #datatools #datacatalogs #datasearch
Подборка полезных ссылок про данные, технологии и не только:
- drawdb [1] визуальное проектирование баз данных и SQL генератор на базе draw.io. Открытый код на JS, лицензия MIT. Выглядит очень даже неплохо
- quickwit [2] альтернатива Datadog и подобным сервисам, но с открытым кодом. Реализует поисковую систему для наблюдаемости процессов. Лицензия AGPL или коммерческая, для бизнеса. Выглядит как минимум интересно, очередной пример YAML программирования, огромного числа файлов для настройки.
- paradedb [3] альтернатива Elasticsearch на базе Postgres, обещают что внутри файлы parquet и многократно выше скорость аналитических запросов. Обещают облачный сервис, пока доступен open source продукт. Лицензия AGPL для всех и коммерческая для бизнеса.
- traefik [4] реверсный прокси для HTTP для развертывания микросервисов и API, похож на альтернативу Kong и Tyk. Открытый код под MIT лицензией

Ссылки:
[1] https://github.com/drawdb-io/drawdb
[2] https://github.com/quickwit-oss/quickwit
[3] https://github.com/paradedb/paradedb
[4] https://github.com/traefik/traefik

#opensource #data #datatools #api #dataviz