Симпатичные цифры и графики развития производительности 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
Спасибо Константину Рядову, телеграм канал Знай и умей ИТ, у него вышел подкаст с моим участием и разговором про дата инженерию и дата анализ. Я к подкасту много не готовился, поэтому у меня там лёгкое естественное косноязычие, но надеюсь слушателям будет полезно.
#podcasts #data #dataengineering
#podcasts #data #dataengineering
Telegram
Знай и умей ИТ
Канал об информационных технологиях: администрирование/программирование, софт/железо, события/анонсы. По всем вопросам сюда: @KayAr81
sq data wrangler [1] или просто sq - утилита для преобразований данных в SQL базах данных. По идеологии это аналог jq, утилиты для обработки JSON файлов. Фактически, автор, явно фанат jq перенес идею на SQL. Лично мне синтаксис jq всегда был из серии перловых регулярных выражений. Недостаточно просто и ясно, но это исключительно моё личное восприятие и есть немало фанатов jq применяющих его по поводу и без.
Поддерживает MySQL, Postgres, SQL Server, SQLite, CSV, JSON и XLSX.
Включают множество самых разных команд для работы с источниками данных и таблицами. Хорошо зайдет для тех кто работает с SQL, но не любит SQL синтакс.
#datatools #datawrangiling #dataengineering #opensource #sql #jq
Поддерживает MySQL, Postgres, SQL Server, SQLite, CSV, JSON и XLSX.
Включают множество самых разных команд для работы с источниками данных и таблицами. Хорошо зайдет для тех кто работает с SQL, но не любит SQL синтакс.
#datatools #datawrangiling #dataengineering #opensource #sql #jq
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
К вопросу об обработке данных с минимальным футпринтом (потреблением памяти оперативной и при хранении). Я добавил к библиотеке iterable пример по обработке дампов Википедии [1].
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Смотрю презентации выступлений участников DuckCon 5 [1]. Там довольно много насыщенных докладов интересных, как с точки зрения технических особенностей применения DuckDB, так и с продуктовой точки зрения, когда применение в нужном месте даёт качественное повышение эффективности продукта.
Из того что особенно привлекло внимание так это выступление Miguel Filipe из Dune Analytics про то как они применяют DuckDB для предоставления результатов аналитикам из мира крипты [2] и Edward Ruiz из Boston University о том как он разработал на базе duckdb движок dbverse для языка R [3] который даёт существенный прирост скорости в обработке геномных и других научных данных.
В целом просмотренное подтверждает мои мысли что DuckDB хороший внутренний движок и фундаментальная технология для многих потенциальных продуктов.
Ссылки:
[1] https://duckdb.org/2024/08/15/duckcon5.html
[2] https://blobs.duckdb.org/events/duckcon5/miguel-filipe-delighting-users-with-restful-apis-and-duckdb.pdf
[3] https://blobs.duckdb.org/events/duckcon5/ed-ruiz-composable-database-libraries-for-larger-than-memory-scientific-analytics.pdf
#datatools #duckdb #dataengineering
Из того что особенно привлекло внимание так это выступление Miguel Filipe из Dune Analytics про то как они применяют DuckDB для предоставления результатов аналитикам из мира крипты [2] и Edward Ruiz из Boston University о том как он разработал на базе duckdb движок dbverse для языка R [3] который даёт существенный прирост скорости в обработке геномных и других научных данных.
В целом просмотренное подтверждает мои мысли что DuckDB хороший внутренний движок и фундаментальная технология для многих потенциальных продуктов.
Ссылки:
[1] https://duckdb.org/2024/08/15/duckcon5.html
[2] https://blobs.duckdb.org/events/duckcon5/miguel-filipe-delighting-users-with-restful-apis-and-duckdb.pdf
[3] https://blobs.duckdb.org/events/duckcon5/ed-ruiz-composable-database-libraries-for-larger-than-memory-scientific-analytics.pdf
#datatools #duckdb #dataengineering
DuckDB
DuckCon #5 in Seattle
DuckDB is an in-process SQL database management system focused on analytical query processing. It is designed to be easy to install and easy to use. DuckDB has no external dependencies. DuckDB has bindings for C/C++, Python, R, Java, Node.js, Go and other…
Подборка полезных ссылок по данным, технологиям и не только:
- Sparrow [1] движок для извлечения данных из документов и изображений, использует LLM, открытый код под GPL
- Genealogy of Relational Database Management Systems [2] хорошо нарисованная история создания баз данных, полезно для преподавания этой дисциплины. Минус только в том что она 2018 года и последние разработки не охватывает, плюс в том что большая часть фундаментальных трендов охвачена c 70х годов.
- Hamilton [3] ещё один движок с открытым кодом для преобразования данных. Выглядит неплохо, распространяется под BSD лицензией.
- Meaningful metrics: How data sharpened the focus of product teams [4] о том как устроены метрики в Duolingo. Полезное про то как устроены метрики в массовых технологических продуктах, а заодно является ответом на вопросы о том почему Duolingo устроено именно так как оно устроено.
- Bigtable transforms the developer experience with SQL support [5] анонс поддержки SQL в Bigtable. Кажется "а что тут такого?", а как сильно помогает в пользовательском опыте работы с данными там.
Ссылки:
[1] https://github.com/katanaml/sparrow
[2] https://hpi.de/fileadmin/user_upload/fachgebiete/naumann/projekte/RDBMSGenealogy/RDBMS_Genealogy_V6.pdf
[3] https://github.com/dagworks-inc/hamilton
[4] https://blog.duolingo.com/growth-model-duolingo/
[5] https://cloud.google.com/blog/products/databases/announcing-sql-support-for-bigtable
#opensource #dataengineering #dataproducts #metrics #readings
- Sparrow [1] движок для извлечения данных из документов и изображений, использует LLM, открытый код под GPL
- Genealogy of Relational Database Management Systems [2] хорошо нарисованная история создания баз данных, полезно для преподавания этой дисциплины. Минус только в том что она 2018 года и последние разработки не охватывает, плюс в том что большая часть фундаментальных трендов охвачена c 70х годов.
- Hamilton [3] ещё один движок с открытым кодом для преобразования данных. Выглядит неплохо, распространяется под BSD лицензией.
- Meaningful metrics: How data sharpened the focus of product teams [4] о том как устроены метрики в Duolingo. Полезное про то как устроены метрики в массовых технологических продуктах, а заодно является ответом на вопросы о том почему Duolingo устроено именно так как оно устроено.
- Bigtable transforms the developer experience with SQL support [5] анонс поддержки SQL в Bigtable. Кажется "а что тут такого?", а как сильно помогает в пользовательском опыте работы с данными там.
Ссылки:
[1] https://github.com/katanaml/sparrow
[2] https://hpi.de/fileadmin/user_upload/fachgebiete/naumann/projekte/RDBMSGenealogy/RDBMS_Genealogy_V6.pdf
[3] https://github.com/dagworks-inc/hamilton
[4] https://blog.duolingo.com/growth-model-duolingo/
[5] https://cloud.google.com/blog/products/databases/announcing-sql-support-for-bigtable
#opensource #dataengineering #dataproducts #metrics #readings
GitHub
GitHub - katanaml/sparrow: Data processing with ML and LLM
Data processing with ML and LLM. Contribute to katanaml/sparrow development by creating an account on GitHub.
Ещё один любопытный ETL продукт VectorETL [1] с открытым кодом под MIT лицензией. Необычен тем что:
a) Включает AI в паплайны обработки данных
б) Изначально ориентирован на векторные (NoSQL) базы данных
Опубликован стартапом Context Data которые предоставляют облачную платформу для задач которые с помощью этого ETL решаются.
Документации немного, но сам продукт любопытный. И попробовать, и почерпнуть идеи.
Ссылки:
[1] https://github.com/ContextData/VectorETL
#opensource #dataengineering
a) Включает AI в паплайны обработки данных
б) Изначально ориентирован на векторные (NoSQL) базы данных
Опубликован стартапом Context Data которые предоставляют облачную платформу для задач которые с помощью этого ETL решаются.
Документации немного, но сам продукт любопытный. И попробовать, и почерпнуть идеи.
Ссылки:
[1] https://github.com/ContextData/VectorETL
#opensource #dataengineering
Подборка ссылок про данные, технологии и не только:
- The Open Data Editor is now ready for the pilot phase [1] обновлённый редактор для подготовки датасетов готов для тестирования, полезный инструмент для всех кто публикует данные с помощью CKAN
- To Be Born in a Bag [2] о исследованиях в разработки искусственной матки и возможностью создавать живых существ искусственным образом. Напоминает воплощение научной фантастики из серии книг Лоис Буджолд. А заодно и там же про создание мамонтов искусственным образом
- DuckDB foundation [3] один из успехов DuckDB в том что это фонд успешно взаимодействующий с несколькими компаниями контрибьюторами. Полезное чтение про успешную модель существования открытого кода.
- The Disappearance of an Internet Domain [4] Великобритания отказывается от суверенитета над островами Чагос и передаёт их Маврикию. Что такое острова Чагос? Это доменная зона .io. Автор рассуждает о его судьбе.
- The Prosopography of Anglo-Saxon England (PASE) [5] онлайн база данных всех британцев как-либо упомянутых в литературных источниках с 6 по 11 века нашей эры. Почти 20 тысяч персон
- Bots, so many Bots [6] боты составляют более 60% из 1 миллиона пользователей ProductHunt. А если говорить о других социальных площадках, то и там ботов всё больше. В какой-то момент должен будет возникнуть перелом когда такие площадки станут бесполезными.
- DatAasee - A Metadata-Lake for Libraries [7] научная статья и открытый код [8] каталога метаданных и озера данных для библиотек.
Ссылки:
[1] https://blog.okfn.org/2024/10/02/the-open-data-editor-is-now-ready-for-the-pilot-phase/
[2] https://press.asimov.com/articles/artificial-wombs
[3] https://davidsj.substack.com/p/foundation
[4] https://every.to/p/the-disappearance-of-an-internet-domain
[5] https://pase.ac.uk/pase/
[6] https://wakatime.com/blog/67-bots-so-many-bots
[7] https://www.semanticscholar.org/reader/7166be7af2fd4bc9cf73d19f076180d9ca83b029
[8] https://github.com/ulbmuenster/dataasee
#opendata #data #tech #dataengineering
- The Open Data Editor is now ready for the pilot phase [1] обновлённый редактор для подготовки датасетов готов для тестирования, полезный инструмент для всех кто публикует данные с помощью CKAN
- To Be Born in a Bag [2] о исследованиях в разработки искусственной матки и возможностью создавать живых существ искусственным образом. Напоминает воплощение научной фантастики из серии книг Лоис Буджолд. А заодно и там же про создание мамонтов искусственным образом
- DuckDB foundation [3] один из успехов DuckDB в том что это фонд успешно взаимодействующий с несколькими компаниями контрибьюторами. Полезное чтение про успешную модель существования открытого кода.
- The Disappearance of an Internet Domain [4] Великобритания отказывается от суверенитета над островами Чагос и передаёт их Маврикию. Что такое острова Чагос? Это доменная зона .io. Автор рассуждает о его судьбе.
- The Prosopography of Anglo-Saxon England (PASE) [5] онлайн база данных всех британцев как-либо упомянутых в литературных источниках с 6 по 11 века нашей эры. Почти 20 тысяч персон
- Bots, so many Bots [6] боты составляют более 60% из 1 миллиона пользователей ProductHunt. А если говорить о других социальных площадках, то и там ботов всё больше. В какой-то момент должен будет возникнуть перелом когда такие площадки станут бесполезными.
- DatAasee - A Metadata-Lake for Libraries [7] научная статья и открытый код [8] каталога метаданных и озера данных для библиотек.
Ссылки:
[1] https://blog.okfn.org/2024/10/02/the-open-data-editor-is-now-ready-for-the-pilot-phase/
[2] https://press.asimov.com/articles/artificial-wombs
[3] https://davidsj.substack.com/p/foundation
[4] https://every.to/p/the-disappearance-of-an-internet-domain
[5] https://pase.ac.uk/pase/
[6] https://wakatime.com/blog/67-bots-so-many-bots
[7] https://www.semanticscholar.org/reader/7166be7af2fd4bc9cf73d19f076180d9ca83b029
[8] https://github.com/ulbmuenster/dataasee
#opendata #data #tech #dataengineering
Open Knowledge Foundation blog
The Open Data Editor is now ready for the pilot phase
This week saw the release of version 1.1.0 of the Open Data Editor (ODE), the new Open Knowledge Foundation's app that makes it easier for people with little to no technical skills to work with data. The app is now ready to enter a crucial phase of user testing.