Интересный текст про сжатие данных и эволюцию 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
Ещё один симпатичный бенчмарк сравнений обработки данных на Python с использованием чистого Python и разных библиотек.
Безоговорочный лидер Duckdb и близкий к нему по скорости Polars, но всё равно отстающий.
Вполне ожидаемо, от Duckdb многие в восторге именно из-за комбинаций скорости и функций.
Причём в текущем состоянии Duckdb ещё и может быть идеальным инструментом для ETL/ELT трансформации данных. Его можно рассматривать не как базу для хранения, а как инструмент быстрой обработки данных. А в нынешних облачных реалиях быстрый значит и дешёвый.
У меня вот есть штук пять внутренних и open source инструментов про которые я понимаю что если их на duckdb (или polars) смигрировать, то они станут удобнее и практичными многократно.
#opensource #datatools #data #duckdb #benchmarks
Безоговорочный лидер Duckdb и близкий к нему по скорости Polars, но всё равно отстающий.
Вполне ожидаемо, от Duckdb многие в восторге именно из-за комбинаций скорости и функций.
Причём в текущем состоянии Duckdb ещё и может быть идеальным инструментом для ETL/ELT трансформации данных. Его можно рассматривать не как базу для хранения, а как инструмент быстрой обработки данных. А в нынешних облачных реалиях быстрый значит и дешёвый.
У меня вот есть штук пять внутренних и open source инструментов про которые я понимаю что если их на duckdb (или polars) смигрировать, то они станут удобнее и практичными многократно.
#opensource #datatools #data #duckdb #benchmarks
Симпатичные цифры и графики развития производительности DuckDB со временем и версиями продукта [1]
Собственно они одни из главных причин почему я этот движок так расхваливаю, он хорошо годится для замены инструментов для типовых задач по обработке данных и даёт очень высокую скорость запросов и обработки данных даже при отсутствии индексов на колонках.
Очень высокая планка скорости обработки данных причём не только при локальной обработке, но и в серверной среде и с параллелизацией в облаке.
Особенно для задач дата инжиниринга на базе открытого кода.
Ссылки:
[1] https://duckdb.org/2024/06/26/benchmarks-over-time
#opensource #duckdb #dataengineering
Собственно они одни из главных причин почему я этот движок так расхваливаю, он хорошо годится для замены инструментов для типовых задач по обработке данных и даёт очень высокую скорость запросов и обработки данных даже при отсутствии индексов на колонках.
Очень высокая планка скорости обработки данных причём не только при локальной обработке, но и в серверной среде и с параллелизацией в облаке.
Особенно для задач дата инжиниринга на базе открытого кода.
Ссылки:
[1] https://duckdb.org/2024/06/26/benchmarks-over-time
#opensource #duckdb #dataengineering
Ещё немного про всякое сугубо техническое, сейчас в Dateno постепенно идёт переход от индексирования тысяч маленьких порталов с общедоступными данными и метаданными, к охвату крупных каталогов. Ключевое отличие таких крупных каталогов данных в том что необходимо писать скрейперы под каждый индивидуально, а это хоть и несложно, но означает увеличение кода скрейпинга многократно что постепенно будет усложнять сопровождение кода и так далее. Но это не проблема, это вполне измеримая техническая задача.
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются
Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.
А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.
В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!
Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.
Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.
Ссылки:
[1] https://clearspending.ru/opendata/
#duckdb #tech #dataengineering #etl
В качестве примера живых данных чтобы проверит Duckdb, попробовал его на одном из слепков индекса Dateno.
Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду
Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.
Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.
#data #datatools #duckdb #dateno
Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду
Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.
Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.
#data #datatools #duckdb #dateno