Я впервые про эту фишку узнал в 2013 году. Как сейчас помню, коллега так делала. Уверяла, что их на предыдущей работе DBA заставляли так писать, дескать запросы быстрее работают. Сути она не знала, на плане разницы не было. Чуть позже я услышал версию, что в ранних версиях MS баг был, Merge Join на неравенствах не работал, а 1=1 равенство добавляло и некоторые запросы действительно ускорялись. Баг починили, а привычка осталась. Про то, что так удобнее условия закомментить, я додумался значительно позднее😀

https://news.1rj.ru/str/rockyourdata/4325

Светлой памяти Майкла Гэмбона... Это ж надо было так совпасть.

https://vc.ru/u/2214539-mathshub/856411-garri-potter-i-inzhenery-dannyh

#немогумолчать

Это просто невероятные ощущения, когда тебе в рассылке приходит твоя же статья😁

Всех с пятницей!

Data-driven "Милан"

Билли Бин и манибол в "Милане" - однозначно новость года для меня из мира данных. Хочется понаблюдать, что из этого получится, жаль, что времени не хватает матчи смотреть. Европейский футбол пока достаточно прохладно относится к продвинутым данным, предпочитая надеяться на "чуечку", и автор в статье объясняет почему.

Поработать в спорте - моя детская мечта, с которой и началось увлечение данными. Вот только ФКСМ пока молчит... А, судя по летним трансферам и последним результатам, дата-офис им крайне необходим😁

https://www.sports.ru/tribuna/blogs/kleshchonok/3171782.html

Вот еще интересная статья о том, как data-driven подход (не только он, конечно) помог превратить неудачника четвертого дивизиона в крепкий клуб английской премьер-лиги.
С детства за Брайтон😁

https://www.sports.ru/tribuna/blogs/knedlikyapivo/3195611.html

Подъехал "убийца DBT"

Встречаем SQL Mesh

SQLMesh можно использовать через CLI/ноутбук или в веб-IDE с открытым исходным кодом.
SQLMesh создает эффективные среды разработки и промежуточного хранения с помощью «Виртуальных витрин данных» с использованием представлений,
что позволяет вам плавно откатывать или накатывать изменения!
С помощью простой замены указателя вы можете перенести свои «промежуточные» данные в рабочую среду.
Это означает, что вы получаете неограниченные среды copy-on-write при записи,
которые делают исследование данных и предварительный просмотр изменений дешевыми, простыми и безопасными.

Основной концепцией SQLMesh является идея виртуальных сред данных,
которые представляют собой набор представлений в схеме,
указывающих на материализованные таблицы, хранящиеся в отдельной схеме

Некоторые другие ключевые особенности:

- Автоматическое создание DAG путем семантического анализа и понимания сценариев SQL или Python.

- Модульные и интеграционные тесты CI-Runnable с возможностью преобразования в DuckDB.

- Обнаружение и согласование изменений на уровне столбца

- Нативная интеграция с Airflow

- Импортируйте существующий проект DBT и запустите его в среде выполнения SQLMesh(в превью)

Выглядит достаточно интересно

Подъехала новая архитектура ELTP.

Extract, Load, Transform, and Publish.

Этап publish похож на Reverse ETL, но как пишет автор статьи, вы не понимаете - это другое.

All Reverse ETL destinations are Publish-type destinations, but not all Publish destinations are Reverse ETL.

Сама статья в блоге Airbyte.

Похоже теперь каждая компания хочешь придумать модный buzz word, как DBT делают с modern data stack.
И потом продвигать новую концепцию на всех конференциях.

Решил воспоследовать примеру кумиров из ВИА Бони Нем и объявить прощальный тур. Последняя возможность послушать "Гарри Поттер и большие данные" в авторском исполнении. Такие вот "Поминки по дата-инжинирингу", только без Федорова и Волохонского...

https://news.1rj.ru/str/mathshubedu_ru/987

ТОП-20 лучших статей про данные 2023

Уважаемый ресурс Dataversity подвел итоги года и опубликовал ТОП-20 самых читаемых и востребованных статей, которые вызвали на их канале в течение года наибольший интерес. Пробежавшись по списку глазами, можно без труда понять к каким ключевым темам информационное сообщество обращалось снова и снова.

Смотреть список статей

Есть две вещи, которые чрезвычайно важны в изучении программирования:
- практика;
- способность искать информацию самостоятельно.

В случае с изучением SQL я рекомендую использовать ресурс https://sql-ex.ru

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

#sql

Одним из первых ликбезов по устройству компьютеров, который потребуется для рассказа про типы данных, - это представление данных в памяти. Очень сильно упрощая, компьютер умеет работать только с нулями и единицами. Каждая такая ячейка, в которой хранится 0 или 1 называется бит. Именно в количестве бит в секунду, например, измеряется скорость передачи данных (по сети интернет или же между жестким диском и оперативной памятью). И если математика в общем была готова к таком повороту (тут надо гуглить "основание системы счисления") и сравнительно легко мы смогли хранить и оперировать числами в памяти компьютера, то вот с остальными данными все сложней. Разберем как же хранятся те или иные вещи в памяти.

Числа
Набрав некоторое количество бит можно сохранить в них число в двоичной системе счисления. Например, десятичное число "64" потребует 7 ячеек и будет записано в виде: "1000000". Таким образом, от того, сколько бит выделено, зависит то, какое число максимум мы можем сохранить. В контексте типов данных мы можем сказать, что под каждое значение с тем или иным типом выделяется определенное количество ячеек. Например, тип данных Integer, который был использован в предыдущем посте для хранения идентификатора фрукта, под собой содержит 32 бита (ячейки) и в него может поместиться максимум десятичное число 2 147 483 647.

Слова (строки, буквы)
Символы, же хранятся в виде некоей таблицы, где каждой букве или символу сопоставляется число - номер в этой таблице символов. Таблиц символов великое множество и гуглятся они по словам "кодировка" или "таблица символов".

Например, слово "шум" в разных кодировках будет сохранено по разному:
- UTF-8: "209, 136", "209, 131", "208, 188"
- ISO-8859-5: "232", "227", "220"

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

В прошлом посте для хранения наименования фрукта fruit_name был выбран тип данных varchar(50). Это значит, предполагается хранить слова, состоящие не больше чем из 50 символов, где на каждый символ приходится 1 байт, то есть 50 байт максимум или не больше 400 бит (ячеек). При этом, если слово, которое мы храним, будет требовать меньше символов, то памяти оно займет меньше - ровно столько, сколько символов-байт потребовалось.

Даты
.... продолжение следует