tgoop.com/rzv_de/300
Last Update:
#вести_с_полей
Чтобы распарсить SQL, нужно всего лишь написать правильную регулярку. Правда?
🔸 Я на трёх проектах пробовал решить задачу "программно прочитать SQL код и построить по нему `Data Lineage`". В том числе используя разные python пакеты вроде Sqlparse и Sqlglot. Цель более-менее сводилась к "хочу знать зависимости для группировки объектов на стадии миграции". Если знаешь, что везти сначала, а что -- потом, это делает планирование проекта прозрачным, а сроки -- предсказуемыми. В общем, важное и крутое знание для менеджмента, которое можно получить анализом проекта.
🔸 Вначале с готовыми пакетами всё неплохо, OLTP запросы проходят все тесты. Но потом начинаются разные особенности OLAP запросов, и небо "затягивает тучами":
. CTE и подзапросы
. десятки JOIN'ов
. не ANSI-SQL особенности диалекта СУБД на проекте
. функции (UDF) и хранимые процедуры (SP), которые перешли в виде "наследства"
🔸 Сегодня на почту упала небольшая статейка как раз на эту тему: "3 уровня понимания SQL". В ней описывают термин "`SQL Comprehension`" -- распознавание SQL кода, которое можно реализовать на разной глубине:
1. Парсинг -- проверка валидности SQL Keywords, количества аргументов в функциях
2. Компиляция -- построение логического плана с учётом типов данных колонок
3. Выполнение -- физический план + результат запроса, учитывает особенности СУБД
Рекомендую пробежаться по примеру и тому, как и что можно сломать :)
p.s. спасибо dbt, что он есть, и UDF & SP можно встречать сильно реже
p.p.s. любая СУБД "понимает" SQL на 3м уровне, да
p.p.p.s. очень любопытно, что получится у dbt после поглощения SDF и использования его как движка. Неужели то самое светлое будущее наступит для analytics engineers?
BY rzv Data Engineering
❌Photos not found?❌Click here to update cache.
Share with your friend now:
tgoop.com/rzv_de/300