Чем с больше данных тем больше потребности в их эффективном сжатии. Из любопытных продуктов на эту тему:
- llama-zip - LLM-powered lossless compression tool, как уже понятно использует языковую модель LLAMA для сжатия текстов на английском языке. Работает только с текстами, сжимает как-то совсем неимоверно судя по примерам. Хочется дождаться его внешнего тестирования и сравнений с другими.
- ts_zip архиватор от Fabrice Bellard работающий с помощью встроенной языковой модели RWKV 169M v4 . Автор известен тем что создал NNCP, компрессор и прекомпрессор на основе нейросетей и побеждающий несколько лет в конкурсе Large Text Compression Benchmark

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

1. Если у данных есть предопределённые схемы то самый эффективный способ их отдавать - это Parquet.
2. Если хранение данных вообще ничем не ограничено, то сохранять в JSONL
3. Если данные нужны для аналитики и их хочется сохранять сжатыми, то форматы gz, br, xz, zst, lz4 и bz2 если их обрабатывать в Clickhouse и в формате gz если в DuckDB. Фактически надо использовать сжатие GZip'ом при всех его недостатках.
4. Для холодного хранения можно сжимать чем угодно дающим хорошее сжатие, например xz, bz2 или 7z


#thoughts #compression #data #datatools

Сугубо техническое и инструментальное. Я на днях обновил исходный код утилиты metacrafter [1] и библиотеки для Python iterabledata [2].

Metacrafter - это утилита и библиотека для Python по выявлению семантических типов данных и далее автодокументирования датасетов. Она изначально поддерживала MongoDB, базовые типы файлов вроде csv, xml, jsonl и тд, а также большую часть SQL баз данных (через SQLAlchemy). Не хватало только поддержки файлов которые могут быть разнообразно сжаты. Эту задачу получилось решить переключившись на библиотеку iterabledata которая поддерживает работу с файлами вроде .csv.bz2, .xml.xz, .jsonl.gz и так далее. Собственно к уже имеющимся алгоритмам сжатия и форматам я добавил ещё Zstandard и Brotli. Из популярных форматов не поддерживаются пока только Snappy и 7z . Но у Snappy неудобная реализация на Python, надо её переписывать, а библиотека для 7z не поддерживает режим открытия файла в контейнере, без обязательного раз сжатия .

Но в остальном оказалось очень удобно . Осталось часть других инструментов переписать с этой библиотекой для простоты обработки условно любых входящих дата файлов с условно любым типом сжатия/контейнеров.

А поддержку сжатых файлов в metacrafter пришлось добавлять не просто так, а потому что хранение бесконечного числа CSV'шек и других первичных файлов в Dateno сжирает очень много места, а обрабатывать их надо. И обрабатывать достаточно быстро и с достаточно небольшими ресурсами памяти, процессора и тд.

Один из способов такой экономии это обновление инструментария для поддержки сжатых файлов на всех этапах. Причём не только на этапе обработки данных, но и на этапе извлечения и загрузки. Импорт в СУБД тоже нужен не в чистых .csv или .json, файлах, а в том числе, сжатыми тоже.

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

#opensource #datatools #data #metacrafter #dateno

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

У этого есть много причин, я бы выделил такие главные из них как:
1. Вовлечение широкого числа мотивированных участников в создание общего знания.
2. Понимание у участников того, что всё ими созданное принадлежит человечеству, не закрыто копирайтом и не является собственностью конкретного юр. лица
3. Открытая Вики экосистема: свободные лицензии, открытый код, открытые данные, открытые API и тд.
4. Гибкость, адаптируемость под новые способы работы с данными, авторедактирование, исправление и многое другое.

Для всех кто создавал знания с помощью Mediawiki или Semantic Mediawiki это может показать очевидным. Но не для создателей БРЭ в текущей их онлайн реинкарнации.

К тому как БРЭ создавалось у меня много вопросов, начиная с фундаментальной непрозрачности проекта (поди найди их годовые отчёты, их нет ) и продолжая выбранным форматом создания, но ключевое следующее:
- все материалы в БРЭ закрыты копирайтом. При том что это 100% госфинансирование, при том что в самой энциклопедии используется бесконечное число материалов взятых из первоисточников в CC-BY-NC/CC-BY.
- БРЭ никогда не была открытой средой. Там не было не только свободных лицензий, но и API, экспорта датасетов, открытого кода и вообще ничего
- всё это время чуть ли не единственная мотивация авторов писать туда была оплата за статьи. Денег нет - моментально нет нового контента.

Поэтому даже если БРЭ, по какой-либо, неведомой причине, власти РФ решат спасать то всё что необходимо сделать:
1. Опубликовать все материалы БРЭ под свободной лицензией допускающей свободное использование в любом Вики проекте, конкретно под лицензией CC-BY и в виде открытых данных.
2. Перевести в открытый код весь исходный код используемый в БРЭ.

Если не решат спасать, то сделать надо то же самое.

#government #content #encyclopedy #wiki #data

В рубрике интересных каталогов данных портал DataOne [1] с данными о о земле, климате и связанными науками, агрегирующий данные из 63 научных репозиториев по этой теме и созданных на его же технологии, доступных как hosted repositories. Большая часть этих порталов созданы университетами и органами власти в США, всего в них более 956 тысяч наборов данных и уникальная возможность поиска датасетов по их геопривязке.

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

Поддерживается Университетом Калифорнии, не имеет открытого кода, но довольно большое сообщество и открытое API.

Ссылки:
[1] https://www.dataone.org

#opendata #datasets #data #earthsciences

Вышел стандарт DCAT-AP 3.0 по публикации каталогов открытых данных. Это официальный стандарт Евросоюза по публикации данных и он основан на стандарте DCAT 3.0 от W3C.

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

Его отдельные ревизии есть в ЕС, в США, в отдельных европейских странах и ещё в ряде стран мира.

В Армении, если появится государственный портал открытых данных, он тоже будет с поддержкой DCAT. Если не появится, то мы добавим поддержку в Open Data Armenia

В РФ стандарт DCAT ни в какой версии не применялся. В начале инициатив по открытости Минэк РФ придумал свои "методические рекомендации" с раскрытием метаданных в виде CSV файлов. Чтобы облегчить краулинг данных на портал data.gov.ru. Рекомендации эти применяют до сих пор, хотя они и морально и технически устарели, а data.gov.ru более не существует.

Пока же добавлю что DCAT поддерживается в Dateno при индексации каталогов и, в частности, метаданные из порталов на базе ArcGIS Hub собираются именно в формате DCAT.

#opendata #data #standards

Подборка ссылок на продукты публикации датасетов для API и аналитики:

С открытым кодом:
- SQLite Studio [1] быстро первращает базы SQLite в веб интерфейс. Можно смотреть структуру таблиц и делать запросы. А также есть демо [2]. По ощущениям очень простой и удобный для этой небольшой задачи.
- Datasette [3] хорошо известный в узких кругах продукт, очень быстро превращающий датасеты в веб интерфейс. Умеет в разные данные, разные API, разные интерфейсы и куча расширений. Когда хочется конструктор и разного
- CSVBase [4] простой до безобразия для превращения CSV файлов в API. Внутри всё Python, одновременно и сервис для публикации данных онлайн для тех кто очень хочет делать это за деньги
- APIReady [5] написанный мной 11 лет назад очень простой движок по превращению CSV файлов в API. Честно говоря с той поры я его даже не развивал, просто как демонстрация самой идеи.
- APICrafter [6] тоже написанная мной утилита по публикации API к базам MongoDB. Развитие APIReady и необходимость поскольку MongoDB по умолчанию не давало и не даёт приемлимое API в их Community Server. Только в облачном сервисе есть уже что-то удобное. Всё на Python, управляется развесистыми YAML конфигами которые строятся автоматически на основе просканированных баз данных [7]

Если Вы знаете другие open source инструменты для публикации датасетов, о них можно рассказать в чатике.

А я через какое-то время напишу про то какие есть бесплатные и коммерческие, не open source, онлайн инструменты делиться датасетами.

Ссылки:
[1] https://github.com/frectonz/sqlite-studio
[2] https://sqlite-studio.frectonz.io/
[3] https://datasette.io/
[4] https://github.com/calpaterson/csvbase
[5] https://github.com/ivbeg/apiready
[6] https://github.com/apicrafter/apicrafter
[7] https://github.com/apicrafter/apicrafter/blob/main/examples/rusregions/apicrafter.yml


#opensource #datatools #data #api

В рубрике как это устроено у них новый каталог открытых данных Словакии data.slovensko.sk заменил предыдущий портал data.gov.sk (более недоступен). Новый портал переписали на CSharp и его код доступен [1]. Из его особенностей - это ориентация на SPARQL, доступность возможности работы со SPARQL эндпоинтом, а также то что краулит из 12 каталогов открытых данных страны и подлерживает каталоги датасетов по стандартам DCAT-AP, SPARQL и CKAN API.

Выглядит любопытно, но эта картина была бы неполной если бы:
1. Разработчики не поломали бы все ссылки на data.gov.sk которые были в европейском data.europe.eu где новый портал даже не зарегистрирован, а старый уже недоступен и ссылки "протухли"
2. Нет общедоступной документации API нового каталога
3. Нет экспорта DCAT AP или CKAN API у нового каталога.

В целом очень неаккуратно. Про SPARQL я скажу так, у него и Semantic Web есть очень много сторонников в европейских проектах за госсчёт, но к современной дата инженерии он имеет смутное отношение. Вообще никакого, если честно. Экспорт данных в Parquet, удобное REST API и, может быть, даже GraphQL эндпоинт куда важнее.

Ссылки:
[1] https://github.com/slovak-egov/nkod-portal

#opendata #slovakia #eu #standards #data #datasets

Где то полтора года назад я писал про то как устроен поиск по данным у Гугла и про ограничения использования разметки из Schema.org. Для тех кто пропустил ту публикацию, расскажу: Schema.org - это стандарт структурированной разметки веб страниц помогающий поисковикам извлекать из веб страниц структурированные разметку о продуктах, статьях, людях , фильмах, книгах и других понятиях. Включая такое понятие как набор данных (Dataset). Саму разметку делают веб-мастера или они встроены в код веб сайта, а поисковая система находит веб страницы и умело их обрабатывает.

Изначально готовили этот стандарт Google, Microsoft и Yandex. Сейчас главный её потребитель это Гугл. Данные этой разметки индексируют, также, другие краулеры и её извлекают из индекса Common Crawl. Я как раз недавно об этом писал.

И всё бы ничего, если бы не один немаловажный факт который прост и неизбежен. Проблема в том что все врут!
Уж не знаю как разметка помогает при SEO оптимизации, но реально всё устроено так что большая часть датасетов не имеет такой структурированной разметки и в том что большая часть того что так размечено, в реальности датасетами не являются. Это какие-то другие концепты/понятия, к данным не относящиеся.

В таблице выборка сайтов в которых есть разметка Dataset. И вот разве они есть на сайтах вроде kakprosto.ru или cbonds.ru ? Совсем нет. Там статьи и другие материалы. И так не только по российским доменам, но и по многим другим.

Из 1.4 миллионов размеченных Datasets в Common Crawl, реально ситуация такова что около 33% мусор, около 33% коммерческие датасеты и оставшиеся 33% данные которые можно скачать. И ещё надо проверять качество их метаданных.

Конечно, реально датасетов больше чем в индексе Common Crawl и индексация веба даст больший охват. Но даже индексация данных по стандартам API CKAN или DCAT работает быстрее и качество метаданных лучше.

#opendata #dateno #data #datasetsx

За много лет у меня накопилось множество инструментов для командной строки которые я создавал для разных дата задач:
- undatum [1] утилита для обработки данных с акцентом на JSONl файлы
- datadiff [2] утилита для создания патчей для датасетов
- mongo2md [3] утилита по автогенрации markdown документации к коллекциям mongodb
- metacrafter [4] утилита и библиотека по идентификации семантических типов данных
- docx2csv [5] утилита по превращению таблиц в файлах DOCX в CSV
- lazyscraper [6] утилита по быстрому и автоматическому извлечению данных из HTML таблиц и другой разметки

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

Сейчас я задумался не пора ли многие из них перенести в один инструмент. Тот же undatum.

Тем более что много есть задач в которых такой инструмент требуется. И есть незакрытые задачи

Вот примерно такое я хочу сделать с undatum добавив туда разные функции и поддерживая работу с NoSQL как приоритет.

Но самое интересная это думать над тем как это реализовать. Я всё чаще склоняюсь к тому что Duckdb правильнее воспринимать как data transformation движок, а не как хранилище. Можно очень многое ускорить с его помощью. Но не всё и тут важны альтернативы. Силами языка или встроенным DB движком.

А ещё у меня есть экспериментальный код mongorefine и код утилиты datacrafter которые живут несколько иначе и связать всё вместе сложнее.

В общем вот такие мысли в последнее время, и открытый код который хочется развивать. А вот код из Dateno можно раскрывать только ограниченно, потому что там много специфичного know how.

Ссылки:
[1] https://github.com/datacoon/undatum
[2] https://github.com/datacoon/datadifflib
[3] https://github.com/datacoon/mongo2md
[4] https://github.com/apicrafter/metacrafter
[5] https://github.com/ivbeg/docx2csv
[6] https://github.com/ivbeg/lazyscraper

#opensource #datatools #data