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

Но даже так я слегка пробежался по старому коду движка metacrafter'а [1], инструмента для идентификации семантических типов данных, или более простым языком, инструмент идентификации того что за колонка в наборе данных или в базе данных и что с ней можно делать. Инструмент я потихоньку начал приводить в целевое состояние - усиление поисковых возможностей у Dateno и автодокументирование датасетов.

Что нового:
- правила для metacrafter'а перенесены теперь в новый репозиторий metacrafter-rules [2], их стало больше, в основном за счёт правил для других языков отличных от английского и русского;
- обновился серверный и клиентский режимы работы. Теперь можно ускорить сканирование данных запустив metacrafter как сервер и обращаясь к нему через параметр remote при вызовах сканирования файлов или баз данных. Это важно для ускорения процесса поскольку правила инициализируются только один раз
- добавилась команда просмотра правил 'metacrafter rules list'
- и так далее

Главный недостаток сейчас - это скорость работы на больших датасетах. Чем больше колонок тем дольше анализ, до нескольких минут. Это не так критично для задач вроде сканирования корпоративных СУБД, но тяжко для задач Dateno когда миллионы датасетов.

На самом деле чтобы всё ускорить нужно просто много ресурсов: процессорных, хранения и памяти. А прикрутив LLM'ку можно сильно повысить качество автодокументирования данных.

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

Ссылки:
[1] https://github.com/apicrafter/metacrafter/
[2] https://github.com/apicrafter/metacrafter-rules/

#opensource #data #datatools #dateno #metacrafter

В качестве примера живых данных чтобы проверит Duckdb, попробовал его на одном из слепков индекса Dateno.

Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду

Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.

Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.

#data #datatools #duckdb #dateno

Полезная картинка для составления стека работы с данными с помощью open source продуктов [1]. Автор большую часть основных продуктов охватил и много что не охватил как и бывает в таких картинках. Полезное когда уже знаешь большую часть продуктов и интересно находить какие-то незнакомые.

Странно что ещё никто не сделал генератор таких картинок. Оно же поддаётся автоматизации, незадорого причём

Ссылки:
[1] https://www.linkedin.com/posts/ravitjain_data-ai-dataengineering-activity-7226190324291837952-COT0/

#data #datatools

Про разного рода технически сложные задачи и их решения.

Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.

Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.

Причём именно в такой комбинации. Почему так?

DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.

Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.

CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.

Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.

Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.

Ссылки:
[1] https://github.com/datacoon/undatum

#thoughts #data #datatools #fileformats #dateno

Наглядная визуализация с открытым кодом того что происходит внутри LLM моделей [1]. Исходный код доступен [2] как и научная статья от авторов Transformer Explainer: Interactive Learning of Text-Generative Models [3]

Ссылки:
[1] https://poloclub.github.io/transformer-explainer/
[2] https://github.com/poloclub/transformer-explainer
[3] https://arxiv.org/abs/2408.04619

#opensource #llm #ai #datatools

Полезные ссылки про данные, технологии и не только:
- FOR-species20K dataset [1] датасет результатов лазерного сканирования более 20 тысяч деревьев и идентификация их видов на основе этих данных
- DuckDB Tricks – Part 1 [2] полезные трюки по работе с данными с помощью DuckDB.
- ncWMS Guide [3] руководство по серверу WMS ncWMS, активно используется вместе с серверами Thredds в метеорологии. Начал их активно добавлять в реестр каталогов данных, скоро проиндексируются в Dateno
- Mapbender 4.0 [4] вышла 4-я версия Mapbender, популярного open source геопортала используемого в ЕС во многих странах.
- SuperMap [5] популярный в Китае геосервер, альтернатива ArcGIS. Используется во многих китайских госорганах, компаниях и активно распространяется в южной, восточной и юго-восточной азии. Имеет частичную совместимость с ArcGIS
- Mealie [6] сервер для ведения рецептов, открытый код и импорт из разных источников. Локализован на многие языки включая русский.
- Slackdump [7] архиватор публичных и личных сообщений из Slack'а. Не требует админских привилегий, открытый код.

Ссылки:
[1] https://zenodo.org/records/13255198
[2] https://duckdb.org/2024/08/19/duckdb-tricks-part-1
[3] https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/
[4] https://mapbender.org/aktuelles/details/mapbender-version-400-released/
[5] https://www.supermap.com/en-us/
[6] https://github.com/mealie-recipes/mealie
[7] https://github.com/rusq/slackdump

#opensource #data #datatools #geodata #geoportals #tools #datasets

Свежая научная статья Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet [1] изнутри Amazon AWS с анализом около 32 миллионов таблиц и около 500 миллионов запросов за 3-х месячный период, а также открытый датасет который лежит в основе этой статьи и её выводов.

Для дата инженерии там немало инсайтов:
1. До сих пор использование parquet это редкость, большая часть клиентов AWS используют сжатые GZip'ом CSV и JSON файлы.
2. Самый популярный тип данных varchar, более 52%. Это ещё раз подтверждает что на AWS явно основное применение не для математических расчётов, анализа геномных данных и тд.
3. Реально больших данных мало, больше 99.8% запросов работают менее чем с 10TB.

По поводу последнего в блоге MotherDuck, пост со ссылкой на эту статью [3] как раз про то что "больших данных не существует" и то что статья про данные AWS это подтверждает. Реальная потребность в обработке очень больших данных невелика.

Ссылки:
[1] https://assets.amazon.science/24/3b/04b31ef64c83acf98fe3fdca9107/why-tpc-is-not-enough-an-analysis-of-the-amazon-redshift-fleet.pdf
[2] https://github.com/amazon-science/redset?tab=readme-ov-file
[3] https://motherduck.com/blog/redshift-files-hunt-for-big-data/

#datasets #data #datatools #dataresearch