Языку SQL уже много, очень много лет, но он продолжает быть чуть-ли не основным для аналитиков данных, инженеров и иных специалистов по работе с данными. Разве что дата сайентисты в некоторых задачах могут избежать счастья работать с SQL и используют Python/Java/R и др.

У SQL много достоинств и не меньше недостатков, главным из которых я бы назвал отсутствие удобных способов работы с не-плоскими данными, такими как JSON и тд. Время от времени появляются альтернативы, которые редко выходят за пределы конкретного продукта, но могут быть очень интересными.
Итак:
- SpyQL [1] гибрид SQL и Python, утилита командной строки позволяет выполнять SQL-похожие запросы с выражениями на Python внутри. Умеет работать с CSV, JSON и текстовыми файлами
- LINQ [2] объектный родной для .NET язык запросов придуманный Microsoft. Не используется за пределами экосистемы .NET
- SPARQL [3] язык запросов родом из Sematic Web. Сложен для непосвящённых, так и не получил массового распространения как и сами СУБД которые его поддерживает, но имеет немало, в первую очередь научных внедрений и использования.
- GraphQL [4] изначально язык API, но есть немало СУБД для которых он уже стал нативным. Малопопулярен в среде обработки данных, но популярен для веб-продуктов, стыковки бэкэнда и фронтэнда.
- Pony [5] специальный маппер выражений из своего синтаксиса в синтаксис SQL. Изначально написан для Python для работы с объектами для задач ORM.
- LookML [6] язык запросов сервиса по визуализации Looker, свой формат, свой синтаксис. Пока мало где используемый за пределами Looker'а
- Malloy [7] ещё один язык от Looker, относительно свежий
- Prql [8] язык запросов ориентированный на преобразование данных.

И многие другие. Защитники SQL возразят что современные SQL базы давно уже поддерживают JSON объекты и функции по работе с ними, а для гибкости пользовательские функции (UDF) можно реализовывать хоть на Python, хоть через .NET, хоть на других языках в зависимости от движка СУБД.

Появится ли у SQL стандарта достойная признанная замена? Пока непонятно, но можно экспериментировать.

Ссылки:
[1] https://github.com/dcmoura/spyql
[2] https://en.wikipedia.org/wiki/Language_Integrated_Query
[3] https://www.w3.org/TR/rdf-sparql-query/
[4] https://graphql.org/
[5] https://github.com/ponyorm/pony/
[6] https://docs.looker.com/data-modeling/learning-lookml/what-is-lookml
[7] https://github.com/looker-open-source/malloy
[8] https://github.com/max-sixty/prql

#sql #nosql #queries #datatools

В блоге 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

Такое чувство что производители облачных СУБД "почувствовали фишку" / осознали возможность демонстрации своих продуктов через наглядное представление больших датасетов. Я ранее писал про 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