Написал текст в рассылку на тему того зачем создаются корпоративные каталоги данных [1]. Это часть скорее теоретическая чем практическая, в неё мало практических примеров, зато много подробностей о том зачем и в какой ситуации компании, в принципе, задумываются о внедрении каталогов данных. В следующих текстах я уже подробнее разберу случаи когда точно не надо усложнять себе жизнь и заводить каталог данных который бы перестал быть актуальным и расскажу о выборе инструментов, там уже много особенностей технологических и разные инструменты решают разные задачи. А ещё точнее с разным качеством решают одни и те же задачи.

Ссылки:
[1] https://begtin.substack.com/p/corporate-data-discovery-1

#data #datacatalogs #dataengineering #dataanalytics #compliance

Полезное чтение про данные, технологии и не только:
- Google News Is Boosting Garbage AI-Generated Articles [1] статья о том что Google News бустят новости не с оригинальных сайтов, а с тех что рерайтят оригинал с помощью ИИ. Статья под пэйволом, но, в общем, всё сказано в заголовке. Непонятно только что с этим делать.
- Paper on Sleeping Agents [2] о том как помещать бэкдоры в языковые модели которые бы могли проходить проверки безопасности. Отдельное новое направление для команд занимающихся инфобезом.
- It's time to build [3] свежая заметка от Benn Stancil о том что для того чтобы создавать дата-стартапы (инструментальные стартапы) не надо новых идей, надо старые идеи/продукты сделать современными.
Не могу с этим не согласится и примеры он приводит релевантные.
- Python Packaging, One Year Later: A Look Back at 2023 in Python Packaging [4] о том как устроены пакеты в Python, технический и прикладной обзор за 2023 год. Может показаться сугубо технической темой, но она актуальна для всех кто создаёт или распространяет пакеты для Python. От себя добавлю что пакеты для Python уже давно стали одним из отражений качества любого продукта или сервиса. Уже не просто API предоставляется, а сразу пакет для Python для доступа к API.
- SQLMesh [5] - open-source движок для преобразования данных близкий и сравнимый с dbt по идеологии и авторы которого продвигают концепцию Virtual Data Environment (VDE) [6]. Концепт как минимум интересный. Кстати, эти же ребята авторы python библиотеки SQLGlot [7], парсера и оптимизатора SQL запросов
- Omni [8] свежий стартап по BI, упомянутый недавно Benn Stancil, делают то же что и все просто проще и симпатичнее. У меня в списке продуктов на потестить визуализацию разным образом. Главное удобство - это комбинация SQL запросов и визуализации данных.
- DataHem odyssey - the evolution of a data platform, part 2 [9] подробный рассказ о эволюции аналитической платформы в Mathem со множеством подробностей про использование dbt и не только.

Ссылки:
[1] https://www.404media.co/google-news-is-boosting-garbage-ai-generated-articles/
[2] https://arxiv.org/pdf/2401.05566.pdf
[3] https://benn.substack.com/p/its-time-to-build
[4] https://chriswarrick.com/blog/2024/01/15/python-packaging-one-year-later/
[5] https://sqlmesh.com
[6] https://tobikodata.com/virtual-data-environments.html
[7] https://github.com/tobymao/sqlglot
[8] https://omni.co
[9] https://robertsahlin.substack.com/p/datahem-odyssey-the-evolution-of-95f

#readings #data #datatools #opensource #dataengineering #ai

Я давно не писал про некоторые базовые принципы работы с данными, хотя регулярно о них задумываюсь в практическом контексте применения концепций и принципов инженерии данных к открытым и общедоступным данным. Например, про data lineage, которое на русский язык коллеги переводят как генеалогию данных. Я буду использовать термин data lineage, как более употребимое.

Так вот интересное тут то что в корпоративном мире с густой аналитикой (когда аналитические команды есть и они сильные, и запрос на аналитику есть), так вот в корпоративном мире data lineage - это понятное явление, если не привычное, то активно обсуждаемое и применяемое. Потому что decision maker'ы часто задают вопросы о том как та или иная цифра вышла и надо иметь ответ о том, а как же это оно есть. А вот в мире общедоступных данных, статистики и, отчасти, науки, с data lineage всё, скажем там, плоховато или очень специфично.

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

В других случаях это сложнее, иногда реально сложно. Ещё сложнее со статистикой, при том что там источники данных указываются практически всегда, но это указание может быть не на первоисточник, а на глобальный источник. Простой пример, какой-нибудь агрегатор данных статистики вроде портала данных ООН (data.un.org) может собирать данные из портала данных Международного валютного фонда (IMF) data.imf.org, а тот из первоисточника, страницы раскрытия данных на сайте резервного банка или статслужбы страны. А кто-то коммерческий может, опять же, собирать данные с портала ООН и выдавать в своём сервисе.
Будем ли он при этом рисовать полноценный data lineage от портала данных ООН до сайта статслужбы ? Вообще-то нет, источником будет указан портал ООН.

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

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

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

Первые продвинуты технологически и сразу ориентированы на разработчиков (API, структурированное хранилище, преобразование данных в удобные форматы JSON, Parquet и др.), но, часто, забывая про базовые принципы открытости.

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

Как выглядят идеальные порталы/сайты индикаторов или порталы публикации геоданных? Лично я считаю что главное в них это максимальная ориентация на использование дата-инженерами и дата-аналитиками владеющими современными инструментами. Даже, если не суперсовременными, но хотя бы актуальными.

Это реализация data lineage, это проектирование по принципу API First, это современные форматы предоставления данных для data science, это _всегда_ наличие bulk download, это концепция в основе что data as a product, а не данные как производный продукт от чего то ещё.

#opendata #data #dataengineering #thoughts

Свежие и полезные инструменты с открытым кодом для загрузки и обработки данных:
- PyAirbyte [1] библиотека для Python от команды Airbyte для того чтобы перенести логику этого движка по сбору данных в Python. Поддерживает все коннекторы Airbyte ранее написанные на Python
- dlt [2] Data Load Tool, явно созвучное dbt, библиотека для Python для реализации принципа Extract-Load-Transform. Выглядит довольно целостно, стоит изучить внимательнее
- ingestr [3] утилита командной строки по переносу баз данных из одного источника в другой. Поддерживает основные SQL СУБД
- sling [4] инструмент для выгрузки/загрузки данных с большинства основных СУБД включая облачные, файловых систем и различных дата файлов. Реализован на Go, важное ограничение GPL 2 лицензия (для сравнения у dlt лицензия Apache 2, а у ingestr MIT).

И конечно остаются такие инструменты как Meltano, Dagster, CloudQuery и многие другие

Ссылки:
[1] https://airbyte.com/blog/announcing-pyairbyte
[2] https://dlthub.com
[3] https://github.com/bruin-data/ingestr
[4] https://github.com/slingdata-io/sling-cli

#opensource #dataengineering

Фразы которыми можно пугать дата инженеров на собеседованиях и не только:
- данные у нас в CSV и Excel на FTP сервере
- наши Excel файлы обновляются в реальном времени на сетевом диске
- требуется работать с большим числом серверов и таблиц из SAP/1С/Oracle Application (нужное тяжелое легаси подставить)
- данные в личных папках пользователей в Sharepoint, надо их синхронизировать
- мы хотим сделать наше озеро данных на Hadoop'е
- большая часть данных у нас в PDF, мы не знаем тексты там или сканы
- требуется 10-летний опыт с dbt cloud

А чем Вы пугаете, чем пугают Вас ?

#humor #dataengineering

Свежий доклад State of Data Engineering 2024 от команды LakeFS.

Подмечают три ключевых тренда:
1. Генеративный ИИ влияет на инструментарий в Modern Data Stack
2. Конкуренция дата продуктов растёт и, соответственно, моё дополнение, цена выхода на рынок с новым продуктом.
3. Открытые форматы создают закрытые заборы. В центре конфликт между Databricks и Snowflake.

Последнее утверждение спорное, скорее речь о том что есть такой конфликт на рынке, а уж каким образом и что используется при нем - не это в его основе.

Что характерно в таких обзорах State of ... так то что от 75 до 95 процентов инструментов, по разным категориям, это облачные продукты. К российским реалиям, к примеру, они не применимы. Как и ко многим особо закрытым не-российским стекам данных.

И, кстати, чтобы не забыть, составители таких State of продолжают путать открытые данные и каталоги открытых данных и корпоративные каталоги. А это очень разные продукты под очень разные задачи.

А если бы я выпускал свой State of data ... то делал бы два отдельных. Один для облака, а другой для корп оффлайна. А может быть даже и три. Ещё один для корп оффлайна открытого кода.

#datatools #opensource #stateof #dataengineering #moderndatastack #readings

Хорошая статья [1] о том как добиться высокой производительности Python при обработке очень больших файлов с данными на примере данных конкурса One Billion Row Challenge [2].

Ключевое что можно из статьи вынести:
- да, по умолчанию Python медленный, но есть много способов его очень сильно ускорить
- Polars и DuckDB дают сильнейшее ускорение, буквально 30кратное и делают обработку данных особенно быстрой
- Pandas - это медленно, пора отказываться от него где возможно
- замена CPython на PyPy заметно ускоряет процесс
- всё это без использования GPU, на ноутбуке

А я не могу не вспомнить что уже есть One Trillion Rows Challenge [3] где Dask претендуют на лучшую скорость обработки данных [4]

Больше соревнований хороших и разных!

Ссылки:
[1] https://towardsdatascience.com/python-one-billion-row-challenge-from-10-minutes-to-4-seconds-0718662b303e
[2] https://1brc.dev
[3] https://t.me/begtin/5529
[4] https://docs.coiled.io/blog/1trc.html

#data #dataengineering #contests #python

Разное, дата инженерное:
1. При работе с JSON lines (NDJSON) по прежнему MongoDB поглощает любой скормленный файл, DuckDB лучше умеет считывать схемы и Clickhouse включая Clickhouse-local оказался самым "капризным". Для ситуаций данных с большим числом NoSQL данных и множеством схем clickhouse применим ограниченно и надо делать специальный инструментарий/надстройку чтобы иvмпортировать уже по предраспознанным схемам, что сильно замедлит импорт на больших файлах. По прежнему очень не хватает высокопроизводительного инструмента для работы с NoSQL.
2. DuckDB примечателен в плане й удобства разработчика, доступных примеров и документации, расширяемости и тд. DuckDB - это очень крутой инструмент. Причём можно смотреть на него как на вещь в себе и подспорье для аналитика, а можно как один из компонентов создаваемого дата-продукта.
3. Ценность Parquet'а начинаешь понимать когда взаимодействуешь с командами публикующими плохо документированные CSV файлы с кучей ошибок из-за того что они в CSV файлы упихивают иерархические структуры из первоисточника. Такие файлы или очень неудобно или совсем нормально не импортируются стандартными средствами. Parquet должен быть форматом для данных по умолчанию, остальное производится из него быстро.
4. Clickhouse или DuckDB были бы хорошими инструментами для замены движка внутри OpenRefine. Но, похоже, этого не дождаться. Разве что, сделать всё же, инструмент для headless data refine, я такой когда-то смастерил для MongoDB, но скорость там оставляет желать лучшего. Скорее это был прототип для оценки возможности реализации.
5. Классические ETL/ELT инструменты для геоданных не то чтобы совсем непригодны, но не заточены ни разу. Создавать / адаптировать существующие ETL движки под них? Или использовать что-то целенаправленно созданное в этой области? Пока не очень впечатляет всё что я видел.

#notes #dataengineering #data #datatools

Собрал свои публичные презентации по нескольким темам и понял что получится большой пост если перечислять все. Вот тут самые основные:

Открытые данные
- Раскрытие данных о госфинансах как часть государственной политики - про проекты открытости госфинансов и их значимости
- Открытые данные как основа госполитики - о том как устроены открытые данные в мире
- Как искать данные с помощью каталогов данных. Проект Datacatalogs.ru - об одном из первых каталогов-каталогов данных
- Sharing Data for Disaster Response and Recovery Programs - об открытых данных в вопросах чрезвычайных ситуаций и восстановления
- Открытость информационных систем нормотворчества - об открытости/закрытости систем нормотворчества в России

Data engineering
- Dateno. Global Data Discovery search engine - презентация проекта поиска по данным Dateno
- Datacrafter. Каталог и озеро данных на базе MongoDB - презентация для выступления на конференции SmartData, о внутренностях продукта Datacrafter и куча технических подробностей

Open Data Armenia
- Open Finances. International and Armenia overview - обзор проектов по открытости госфинансов в мире и в Армении
- Open Data, Open Code, Open Licenses - о разных компонентах открытости

Открытый код
- Открытый код в других странах - Как и в каком объёме и кто именно публикует открытый код, почему это важно и почему это становится всё более популярным

Приватность
- Слежка через государственные мобильные приложения - о том как государственные органы следят за гражданами с помощью мобильных приложений и сливают информацию о их передвижении и действиях коммерческим компаниям
- Термины и объекты регулирования: ADM-системы - о том что такое системы для автоматического принятия решения и как они описываются в разных странах
- О необходимости контроля и аудита ADM- систем - о том как регулировать ИИ используемый для автоматического принятия решений

Веб архивация
- Организация веб-архивов - о том как устроены современные интернет архивы и Национальный цифровой архив (ruarxive.org)
- Дата инженерия и цифровая гуманитаристика - о том какие большие цифровые гуманитарные проекты есть в мире и про Национальный цифровой архив

Понятный язык
- Простой и понятный русский язык - о простоте русского языка и её измерении
- Простота нормативно-правового языка - о подходах к оценке нормативно-правовых текстов

P.S. Всего у меня 200+ неразобранных презентаций за последние 15 лет, в онлайне не больше 30. Что-то устаревает, что-то нельзя публиковать, что-то бессмысленно без самого выступления, но, по мере разбора завалов, буду выкладывать дальше.

#opendata #opensource #plainlanguage #webarchives #digitalpreservation #dataengineering #armenia

Прямо интересное явление последних лет - это восхождение декларативного программирования когда дело касается данных и инфраструктуры в первую очередь. Вместо написания кода, пишутся YAML или TOML файлы и на их основе бегают конвейеры данных, разворачивается инфраструктура, создаются базы данных или API сервера.

Вижу всё больше и больше таких продуктов, особенно в областях devOps, dataOps и в продуктах типа ELT/ETL и других в области современного стека данных. Я и сам в инструментах что создавал или создаю делаю такое же.

Очень скоро работа с данными не потребует знаний даже SQL потому что всё будет в этом самом декларативном программировании. Из известных мне популярных ETL/ELT движков разве что Dagster не на декларативных языках, а по модели data-as-a-code, все написано на Python.

Внутри Dateno тоже используется декларативный сбор данных с помощью движка datacrafter [1] который я изначально делал для совсем других задач по извлечению данных из API и по преобразованию файлов. А также вместе с datacrafter там работает движок apibackuper [2] в котором тоже декларативный язык но в виде конфига для Python. Его, по хорошему, надо переписать для работы с конфигом в YAML и ещё многое поправить.

Достоинство декларативных языков в том что легко генерировать эти конфиги. В Dateno краулер создаёт тысячи конфигов под каждый сайт и запускает сбор данных вызовом datacrafter'а, и уже потом собирает результаты и складывает в базу данных.

Большая часть источников данных там - это API, для каждого из которых свой шаблон и свои правила выгрузки. Иногда довольно непростые, но стандартизованные. И из имеющихся ETL движков только dlt такое может. По сути миграция кода - это преобразование одних YAML файлов в другие, при соблюдении ряда условий конечно, что схожие операции можно воспроизвести в другом движке.

Пока главный недостаток почти всех инструментов такого рода в отсутствии хорошей поддержки NoSQL в целом и MongoDB в частности. Из-за чего и приходится пользоваться собственным стеком инструментов.

Ссылки:
[1] https://github.com/apicrafter/datacrafter/
[2] https://github.com/ruarxive/apibackuper

#opensource #dataengineering #thoughts

Ещё немного про всякое сугубо техническое, сейчас в 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

Спасибо Константину Рядову, телеграм канал Знай и умей ИТ, у него вышел подкаст с моим участием и разговором про дата инженерию и дата анализ. Я к подкасту много не готовился, поэтому у меня там лёгкое естественное косноязычие, но надеюсь слушателям будет полезно.

#podcasts #data #dataengineering

К вопросу о 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

Смотрю презентации выступлений участников 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

Подборка полезных ссылок по данным, технологиям и не только:
- 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

Ещё один любопытный ETL продукт VectorETL [1] с открытым кодом под MIT лицензией. Необычен тем что:
a) Включает AI в паплайны обработки данных
б) Изначально ориентирован на векторные (NoSQL) базы данных

Опубликован стартапом Context Data которые предоставляют облачную платформу для задач которые с помощью этого ETL решаются.

Документации немного, но сам продукт любопытный. И попробовать, и почерпнуть идеи.

Ссылки:
[1] https://github.com/ContextData/VectorETL

#opensource #dataengineering