Интересный текст про сжатие данных и эволюцию DuckDB в этом направлении [1]․ Если вкратце, то текст о том как разработчики DuckDB организовали хранение данных улучшив за полтора года его примерно в 3 раза.
Для CSV файла в 17ГБ в версии 0.2.8 от июля 2021 г. данные занимали 15.3ГБ, а текущей версии они занимают порядка 4.8ГБ.
Для того чтобы обеспечить это сжатие разработчики использовали новый алгоритм Chimp [2] для сжатия чисел с плавающей запятой.
Это ниже чем сжатие алгоритмами Zstd или Snappy, но, важно помнить что сжатие в DuckDB обеспечивается практически без потери производительности.
Это важно поскольку DuckDB - это весьма перспективная SQL OLAP база данных, предназначенная для оптимизации аналитических расчётов.
Сам подход такого сжатия, ориентированного на быструю декомпрессию данных, весьма любопытен и наверняка переносим на другие продукты, многие из которых также используют похожий алгоритм Gorilla [3], на базе которого и построен алгоритм Chimp.
В обоих случаях числа сжимаются через специально подобранные операции основанные на XOR и повторяемости значений в битах чисел с плавающей запятой.
И, чтобы два раза не вставать, туда же в тему интересных исследований про данные, статья прошлого года в VLDB - DBOS: A DBMS-oriented Operating System [4] о том что вполне возможно построить операционную систему на основе высокопроизводительной базы данных. Подход очень оригинальный, это не просто data-shell, оболочка для работы с OS словно с базой данных и не data API для работы с функциями и настройками ОС через интерфейс API, а прямо таки полноценная ОС. А оно, тем временем, развивается [5] и может быть когда-то появится.
Ссылки:
[1] https://duckdb.org/2022/10/28/lightweight-compression.html
[2] https://www.vldb.org/pvldb/vol15/p3058-liakos.pdf
[3] https://www.vldb.org/pvldb/vol8/p1816-teller.pdf
[4] https://www.vldb.org/pvldb/vol15/p21-skiadopoulos.pdf
[5] https://dbos-project.github.io/
#dbms #duckdb #olap #dwh
Для CSV файла в 17ГБ в версии 0.2.8 от июля 2021 г. данные занимали 15.3ГБ, а текущей версии они занимают порядка 4.8ГБ.
Для того чтобы обеспечить это сжатие разработчики использовали новый алгоритм Chimp [2] для сжатия чисел с плавающей запятой.
Это ниже чем сжатие алгоритмами Zstd или Snappy, но, важно помнить что сжатие в DuckDB обеспечивается практически без потери производительности.
Это важно поскольку DuckDB - это весьма перспективная SQL OLAP база данных, предназначенная для оптимизации аналитических расчётов.
Сам подход такого сжатия, ориентированного на быструю декомпрессию данных, весьма любопытен и наверняка переносим на другие продукты, многие из которых также используют похожий алгоритм Gorilla [3], на базе которого и построен алгоритм Chimp.
В обоих случаях числа сжимаются через специально подобранные операции основанные на XOR и повторяемости значений в битах чисел с плавающей запятой.
И, чтобы два раза не вставать, туда же в тему интересных исследований про данные, статья прошлого года в VLDB - DBOS: A DBMS-oriented Operating System [4] о том что вполне возможно построить операционную систему на основе высокопроизводительной базы данных. Подход очень оригинальный, это не просто data-shell, оболочка для работы с OS словно с базой данных и не data API для работы с функциями и настройками ОС через интерфейс API, а прямо таки полноценная ОС. А оно, тем временем, развивается [5] и может быть когда-то появится.
Ссылки:
[1] https://duckdb.org/2022/10/28/lightweight-compression.html
[2] https://www.vldb.org/pvldb/vol15/p3058-liakos.pdf
[3] https://www.vldb.org/pvldb/vol8/p1816-teller.pdf
[4] https://www.vldb.org/pvldb/vol15/p21-skiadopoulos.pdf
[5] https://dbos-project.github.io/
#dbms #duckdb #olap #dwh
К вопросу о том почему я лично пишу про Polars, DuckDb, а теперь ещё и присматриваюсь к chDb, потому что в моей работе есть частые задачи с очисткой и обработкой данных. В принципе, чем бы я в жизни не занимался, читал лекции, делал презентации, программировал и тд., всегда есть задача чистки данных.
Есть много способов чистить данные с помощью кода, есть хороший инструмент OpenRefine [1] известный многим кто с открытыми данными работает. Но, честно скажу, в плане скорости, но не удобства, к примеру, DuckDB бьёт все рекорды. Главный недостаток - отсутствие удобного UI аналогичного OpenRefine или то что в OpenRefine нельзя, к примеру, заменить его движок на DuckDb.
В остальном это реально очень быстро. И работать с локально с многогигабайтными датасетами и в миллионы и десятки миллионов записей - вполне реально. Для сравнения, OpenRefine у меня едва-едва тянет базу в 100 тысяч записей в 680 MB.
Использовать это можно много где. К примеру, датасет от мусорных записей, найти и удалить персональные данные, обогатить дополнительными данными на основе текущий значений столбцов, исправить ошибки в данных и многое другое.
В общем-то на базе DuckDB и, скорее всего, chDb можно построить полноценную дата-студию по приведению данных в порядок перед загрузкой в хранилище. Опять же, если иметь полноценный веб интерфейс поверх.
Такие инструменты хорошо встраиваются как ядро более прикладных дата-продуктов.
Ссылки:
[1] https://openrefine.org
#data #datatools #thoughts #duckdb #openrefine
Есть много способов чистить данные с помощью кода, есть хороший инструмент OpenRefine [1] известный многим кто с открытыми данными работает. Но, честно скажу, в плане скорости, но не удобства, к примеру, DuckDB бьёт все рекорды. Главный недостаток - отсутствие удобного UI аналогичного OpenRefine или то что в OpenRefine нельзя, к примеру, заменить его движок на DuckDb.
В остальном это реально очень быстро. И работать с локально с многогигабайтными датасетами и в миллионы и десятки миллионов записей - вполне реально. Для сравнения, OpenRefine у меня едва-едва тянет базу в 100 тысяч записей в 680 MB.
Использовать это можно много где. К примеру, датасет от мусорных записей, найти и удалить персональные данные, обогатить дополнительными данными на основе текущий значений столбцов, исправить ошибки в данных и многое другое.
В общем-то на базе DuckDB и, скорее всего, chDb можно построить полноценную дата-студию по приведению данных в порядок перед загрузкой в хранилище. Опять же, если иметь полноценный веб интерфейс поверх.
Такие инструменты хорошо встраиваются как ядро более прикладных дата-продуктов.
Ссылки:
[1] https://openrefine.org
#data #datatools #thoughts #duckdb #openrefine
К вопросу о том почему я так часто писал в последнее время про форматы данных вроде Parquet которые из data science постепенно перебираются в другие дисциплины работы с данными. Вот наглядный пример, у меня на руках датасет который в несжатом виде занимает 195GB, а в сжатом .tar.gz около 22GB. Его владелец распространяет его именно в сжатой форме, но понятно что для работы с ним его приходится распаковывать, особенно учитывая что tar.gz не тот формат с которым удобно работать без полного его разжатия. Внутри датасета сплошные .jsonl файлы, удобный при любой работе с NOSQL, но не для хранения.
При этом, если пересжать все данные в архиве в формат parquet, то они сожмутся до 8-12GB, и с ними можно будет продолжить работу. Загрузить в СУБД из parquet в общем-то не проблема.
В целом получается настолько большой выигрыш что игнорировать такие инструменты просто нельзя.
И сюда же, кстати, про мои давние размышления про поиск замены OpenRefine. Самым интересным продуктом было бы если бы внутренний движок OpenRefine можно было бы заменить на DuckDB. Тогда можно было бы на стандартном десктопном железе работать по очистке датасетов условно почти любого размера.
#data #datatools #parquet #duckdb
При этом, если пересжать все данные в архиве в формат parquet, то они сожмутся до 8-12GB, и с ними можно будет продолжить работу. Загрузить в СУБД из parquet в общем-то не проблема.
В целом получается настолько большой выигрыш что игнорировать такие инструменты просто нельзя.
И сюда же, кстати, про мои давние размышления про поиск замены OpenRefine. Самым интересным продуктом было бы если бы внутренний движок OpenRefine можно было бы заменить на DuckDB. Тогда можно было бы на стандартном десктопном железе работать по очистке датасетов условно почти любого размера.
#data #datatools #parquet #duckdb