Ivan Begtin
7.98K subscribers
1.85K photos
3 videos
101 files
4.56K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts [email protected]
Download Telegram
В блоге Fivetran весьма интересные размышления [1] о популярности dbt, инструмента по преобразованию данных с помощью SQL, с акцентом на то что dbt решает одну из главных системных проблем SQL - невозможность использования библиотек и шаблонов. В dbt это решается через их менеджер пакетов куда входят многочисленные рецепты работы с данными.

Авторы также ссылаются на статью середины прошлого года Against SQL [3] где как раз проблемы SQL четко актикулировались.

Я, кстати, также совершенно не в восторге от языка SQL, слишком много разных реализаций значительно меняющих/расширяющих SQL стандарт и сам по себе текст стандарта SQL 2016 составляет 1732 страницы. В целом то критика в адрес SQL идёт давно, многие NoSQL продукты появлялись как раз как замена SQL и, по ощущениям, как раз с появлением dbt происходит какое-то экспоненциальное перерождение подходов к работу с этим языком.

Ссылки:
[1] https://www.fivetran.com/blog/can-sql-be-a-library-language
[2] https://hub.getdbt.com/
[3] https://www.scattered-thoughts.net/writing/against-sql
[4] https://blog.ansi.org/2018/10/sql-standard-iso-iec-9075-2016-ansi-x3-135/

#reading #sql #data
Для всех кто учится работать с данными и работать с SQL я рекомендую сразу начинать изучать dbt, например, по ссылкам из awesome-dbt [1] и начиная с бесплатного официального курса [2]. Пройдёт год-два максимум и dbt в России начнут повсеместно использовать, а для работы инженера-аналитика (analytics engineer) дистанционно на проект/компанию в любой стране - это будет одна из наиболее востребованных технологий.

Почему dbt? Потому что пока это наиболее развитый инструмент преобразования данных. Если в областях ETL/ELT, data orchestration, data visualization, BI и других есть масштабная конкуренция и авторы и создатели проектов регулярно пишут о том как заменить одно на другое или как отказаться от чего-либо, например, как отказаться от Airflow [3], то про dbt все пишут только о том как они заменили свои механизмы трансформации данных на dbt.

Продукт получился просто таки попаданием в яблочко, в России он мало применяется только по причине малой применимости тут других зарубежных облачных продуктов. Но важная особенность dbt что он, и облачный, и как изначальный open source продукт.

Ссылки:
[1] https://github.com/Hiflylabs/awesome-dbt
[2] https://courses.getdbt.com/collections
[3] https://blog.fal.ai/the-unbundling-of-airflow-2/

#datatools #studies #learning #sql #dbt
Весьма познавательное интервью [1] с George Fraser, сооснователем Fivetran, стартапа и продукта по сбору данных из многочисленных публичных источников/API и тд. В интервью он говорит про SQL, открытый код и революцию которую в это всё принесло появление dbt как продукта позволяющего создавать программные библиотеки для работы с SQL кодом.

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

Ссылки:
[1] https://future.a16z.com/sql-needs-software-libraries/

#data #sql #dbt #articles #reading
PRQL - ещё один кандидат на замену SQL [1] позиционируется как PRQL is a modern language for transforming data, читается как "приквел". Основная идея в том чтобы сделать язык более дружелюбным для тех кто на нём пишет и не потерять возможностей SQL, ну и ещё много чего, вроде расширяемости новыми функциями.

Референсная реализация есть на Rust [2] и гораздо менее популярная на Python [3]

Автор известен тем что создал когда-то библиотеку Xarray [4] для Python, весьма известную теми кто работает с большими массивами вычисляемых данных.

Про PRQL он написал книгу [5] и как-то в целом системно подходит к разработке, так что есть хорошие шансы что результат будет и долгосрочный.

Ссылки:
[1] https://prql-lang.org/
[2] https://github.com/prql/prql
[3] https://github.com/prql/PyPrql
[4] https://xarray.dev/
[5] https://prql-lang.org/book/

#opensource #sql #datatools
Из любопытных инструментов, в Hex, онлайн сервисе тетрадок для машинного обучения, появились no-code cells [1], это когда вместо написания Python или SQL можно выбрать интерактивно параметры, а сервис сам сгенерирует код.

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

Наступает время гибридных инструментов!

Ссылки:
[1] https://hex.tech/blog/introducing-no-code-cells

#datatools #sql #python
Недавно я писал про подход к переосмыслению работы с любыми унаследованными продуктами/протоколами как "всё SQL" [1]. Иногда такой подход осуществлять сложно, иногда очевидно, а вот подборка примеров когда это работает и работает успешно․

- textql [2] - утилита и библиотека на Go по работе с файлами CSV и TSV так словно это SQL таблицы. Поддерживает практически полностью синтаксис SELECT запросов.
- gitql [3] - инструмент на Go для работы с Git как с базой данных SQL. Поддерживает все хранимые в Git объекты, лог и работает в режиме только для чтения.
- q - Text as Data [4] - инструмент работы с CSV и TSV как с SQL, но написанный на Python. Также поддерживает сразу множество sqlite баз данных.
- dockersql [5] - база контейнеров для Docker как SQL, тоже на Go написано, не обновлялось уже 9 лет, но как proof-of-concept интересно. Работает поверх API Docker'а
- Yahoo! Query Language (YQL) [6] универсальный SQL-подобный язык запросов к API и CSV, RSS и другим файлам. На сайте Yahoo! его более нет, осталась только страница в Википедии и рассеянные по интернету примеры

Наверняка есть и больше примеров. В некоторых случаях это оказывается совершенно оправдано, textql, к примеру, удобный инструмент для тех кто работает с CSV файлами часто и сложным образом. Можно ли через призму этого сделать инструменты SQL для IMAP4 или SQL для FTP или SQL для файловой системы (уже есть, кстати) и иначе? Конечно возможно!

Ссылки։
[1] https://t.iss.one/begtin/4613
[2] https://github.com/dinedal/textql
[3] https://github.com/filhodanuvem/gitql
[4] https://github.com/harelba/q
[5] https://github.com/crosbymichael/dockersql
[6] https://en.wikipedia.org/wiki/Yahoo!_Query_Language

#opensource #datatools #queryengines #sql
Интересное чтение про данные, технологии и не только։
- iasql [1] инструмент с открытым кодом позволяющим из PostgreSQL работать с облачными аккаунтами как с базами данных. Забавная штука подпадающая под категорию продуктов "всё SQL", интересно они могут быть только с открытым кодом или кто-то найдёт им бизнес модель тоже?

- Introduction to Data-Centric AI [2] курс по дата-центричному ИИ, зайдёт для тех кто приходит к мысли что "наши данные для обучения ИИ дерьмо и с этим надо что-то делать", про то как разрабатывать алгоритмы от данных, а не от моделей.

- The State of Data Journalism 2023 [3] обзор состояния дата-журналистики в мире от Европейского центра журналистики. Не понимаю как они смогли сделать его таким скучным, но крупицы любопытного там тоже есть. Например, что большая часть дата-журналистов 35+, что женщины в дата-журналистике моложе мужчин, что большинство фрилансеры, что большинство самообучались, зарабатывают мало, большинство работают с открытыми данными и тд.

- SQLake [4] ещё один, на сей раз коммерческий, сервис в стиле "всё SQL", на сей раз с его помощью создаются трубы данных (data pipelines). Лично мне это кажется слегка извращённым, но любопытным как минимум. Кстати, это и часть ответа на вопрос монетизируется ли такой подход. Похоже на то что да.

- Catalog of ETL and EL-T tools [5] каталог ELT и ETL инструментов от стартапа Castor. Неплохой обзор для понимания этого рынка. Тоже стратегия, выносить внутреннюю аналитику рынка наружу как медийный бесплатный продукт, полезных ссылок там немало.

- JXC [6] структурный язык для разметки данных как развитие JSON. Выглядит интересно, хотя и не достиг даже версии 1.0. По моему опыту у JSON есть две системные проблемы։ отсутствие типа дата и время и отсутствие других типов данных. JXC частично это решает.

- tbls [7] утилита по документированию баз данных сразу в формате Github Markup. Написано на Go, с открытым кодом, выглядит любопытно, поддерживает и NoSQL тоже.


Ссылки:
[1] https://github.com/iasql/iasql
[2] https://dcai.csail.mit.edu/
[3] https://datajournalism.com/survey/2022/
[4] https://www.upsolver.com/
[5] https://notion.castordoc.com/catalog-of-etl-tools
[6] https://github.com/juddc/jxc
[7] https://github.com/k1LoW/tbls

#opensource #data #datatools #sql #ai #datajournalism
Я регулярно пишу про такое явление как датацентричное мышление "что угодно как таблица" и в более узком звучании "что-угодно как SQL". Причём последнее попадается всё чаще и всё чаще всё то ранее было доступно каким-то другим образом через API или в иной специфической форме доступно как таблицы.

Из последнего, sqlelf, это программная библиотека и утилита превращающая метаданные из исполняемых Linux файлов в базу Sqlite и позволяют проделывать все дальнейшие операции по чтению этих метаданных из SQL таблиц. Удобно для всех кто занимается форенсикой под Unix-like системы.

Из похожего, несколько лет назад я делал утилиту metawarc, индексирует содержание веб-архивов в формате WARC и создаёт локальную Sqlite базу с результатами. Что позволяет сильно ускорить задачи по подсчёту статистики, экспорту файлов из архива (архивы бывают большие и это важна задача) и многое другое. Единственное что я не сделал - это там нет SQL интерфейса, хотя добавить такую команду и примеры это дело пары часов.

Похожий код у меня есть для HTML страниц, он превращает дерево HTML в плоскую таблицу с дополнительным обсчётом ряда параметров. Я его всё подумывал опубликовать и возможно что база в памяти это решение. Возможно, потому сколько я не пытался не удаётся сильно уменьшить размеры таблицы тэгов. Она выходит больше оригинального файла от 7 до 21 раза, это без использования СУБД внутри, только размер pandas Dataframe.

Возвращаясь к "что угодно как SQL", я в феврале прошлого года приводил много примеров такого подхода, когда SQL синтаксис и интерфейс создаются для работы с текстовыми файлами, репозиториями Git, базой контейнеров для Docker и тд.

Чем дольше я об этом думаю, тем более чувствую что такой подход может иметь существенный потенциал для технологических продуктов. Например, если бы сервисы счётчиков посещаемости и иной пользовательской аналитики предоставляли бы не REST API, а сразу доступ к SQL таблицам с твоими данными то это резко упростило бы их интеграцию и использование. Такие внешние сервисы, кстати, есть, но суть в том что SQL интерфейсы доступа не являются сейчас стандартизированными продуктами.

Аналогично для многих других сервисов и продуктов которые сейчас интегрируются через ETL и ELT костыли.

А сама идея "что-угодно как SQL" может развиваться ещё применительно много к чему. К файловой системе, к реестру Windows, к работе с Excel/ODS файлами, к работе с онлайн таблицами (типа Google Sheets), к вебсайтам и ещё много к чему.

#thoughts #data #datatools #sql #everythingisdata
Подборка полезных инструментов для работы с данными и не только:
- GROBID [1] библиотека и набор утилит для разбора PDF научных статей. Извлекает таблицы, ссылки, заголовки, цитаты, даты и именованные сущности. Используется внутри проекта Semantic Scholar. Открытый код под Apache 2.
- sqleton [2] универсальная библиотека для Python для доступа к разным SQL СУБД. Альтернатива SQLAlchemy, но выглядит как более простая в использовании
- reladiff [3] библиотека для Python для сравнения больших таблиц, сравнительно легко её можно доработать для сравнения больших датасетов
- Daft [4] распределенная библиотека для датафреймов на Rust и Python. Внутри Apache Arrow и язык запросов в виде функций для Python

Ссылки:
[1] https://github.com/allenai/grobid
[2] https://github.com/erezsh/sqeleton
[3] https://github.com/erezsh/reladiff
[4] https://github.com/Eventual-Inc/Daft

#opensource #datatools #data #pdf #sql #dataframes
Полезное чтение про данные, технологии и не только:
- A Quick Introduction to JavaScript Stored Programs in MySQL [1] в блоге Oracle MySQL о том чтобы использовать программы на Javascript внутри СУБД. Признаться честно я к этой практике отношусь с глубоким осуждением, особенно в части аргументации что миллионы разработчиков используют Javascript так давайте запихнём его ещё куда-нибудь. Тем не менее тоже тренд и тоже понятный, хотя и запоздавший лет на 10-15.
- ColPali: Efficient Document Retrieval with Vision Language Models [2] про распознавание текстов и Vision LLMs. Вот это перспективная тема которая может подвинуть текущих лидеров OCR.
- A Crash Course on Relational Database Design [3] хорошая инфографика для совсем начинающих работающих с базами данных. Как и вся наглядная инфографика от ByteByteGo
- Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models [4] проект STORM родом из Stanford который позволяет писать длинные вики статьи с помощью LLM на произвольные неизвестные темы. Выглядит как инструмент который может, как сильно дополнить Википедию, так и создать реального её конкурента с нуля, так и ещё много для чего. Когда уже сделают LLM для быстрой генерации корпоративной документации на ИТ продукты или доков для open source?

Ссылки:
[1] https://blogs.oracle.com/mysql/post/a-quick-introduction-to-javascript-stored-programs-in-mysql
[2] https://huggingface.co/blog/manu/colpali
[3] https://blog.bytebytego.com/p/a-crash-course-on-relational-database
[4] https://storm-project.stanford.edu/research/storm/

#ai #readings #sql #databases #ocr #data
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
Такое чувство что производители облачных СУБД "почувствовали фишку" / осознали возможность демонстрации своих продуктов через наглядное представление больших датасетов. Я ранее писал про OSS Insight [1] от TiDB Cloud с данными извлечёнными из Github, а теперь и команда ClickHouse анонсировала [2] CryptoHouse [3] как бесплатный открытый сервис для блокчейн аналитики. Просто открываешь веб интерфейс и делаешь SQL запросы. А то что интерфейс не требует даже авторизации - это лишнее подтверждение способности выдерживать большие нагрузки.

Выглядит как довольно продвинутая штука, есть немало баз данных над которыми было бы интересно иметь такой интерфейс, но без заоблачных облачных ценников и с возможностью экспорта результатов. Скорее всего это можно сделать достаточно просто и дешево с помощью ch-ui [4] и подобных инструментов.

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

Ссылки:
[1] https://ossinsight.io/
[2] https://clickhouse.com/blog/announcing-cryptohouse-free-blockchain-analytics
[3] https://crypto.clickhouse.com/
[4] https://github.com/caioricciuti/ch-ui

#opendata #clickhouse #sql #blockchain
А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.

Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.

К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)


#sql #datatools #data
SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL [1] научная статья от исследователей Google про GoogleSQL. Особенность в том что это не альтернативный новый язык, а именно специальный диалект для удобного написания конвейеров и так называемого pipe syntax для SQL.

GoogleSQL уже реализован во многих их продуктах вроде BigQuery, F1 и ZetaSQL [2]

Ссылки:
[1] https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/
[2] https://github.com/google/zetasql

#google #sql #datatools #data
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.

И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].

Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.

Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.

Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.

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

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

Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.

Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.

Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.

Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet

#dateno #dataquality #sql #duckdb #metrics #datacatalogs