Подъехала новая архитектура 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 бит (ячеек). При этом, если слово, которое мы храним, будет требовать меньше символов, то памяти оно займет меньше - ровно столько, сколько символов-байт потребовалось.

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

... продолжение предыдущего поста про типы
Даты и время
Если совсем просто, а мы тут все за простоту, то дату в БД можно хранить с разной степенью точности, а так же с указанием временной зоны. В зависимости от необходимой точности существует некоторое количество типов, которые отличаются от одной СУБД к другой и лучше бы ознакомится с документацией для выбора оптимального типа для проекта.

В рамках работы с фруктовой лавкой был использован тип данных: Date, который занимает в случае с PostgreSQL 4 байта, а случае с MS SQL 3 байта. Сравните с 10-ю байтами, если хранить дату в виде строки "16.02.2024".

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

Числа (снова)
В прошлый раз я был не совсем честен и рассмотрел только целые числа. Исправляюсь и представляю вашему вниманию числа приблизительные и дробные.

Числа (дробные)
Тут все просто, суть - это такие же целые числа, но еще при объявлении этого типа указывается сколько мы готовы хранить знаков после запятой. Называются они Decimal или Numeric или еще как-нибудь (у мелкомягких, например, есть тип Money, а в Postgres он появился только с 12-ой версии 🤑 ) . В нашей фруктовой лавке был использован тип Numeric(15, 2) для хранения веса и сумм. Это значит что мы могли бы хранить число с количеством символов 15, из которых 2 - это числа после запятой. Места занимает столько, сколько укажете при объявлении. У разных СУБД тут по разному.

Числа (приблизительные)
Такие числа называются еще числами с плавающей запятой. Если интересна математика, которая стоит за, хранением этих чисел, то вам, наверное, в вики - объяснение нетривиально и требует некоторой подготовки. В нашем случае лишь хочу заметить, что такие числа имеют неопределенную точность, и потому зарплату на таких лучше не считать, а разность двух одинаковых чисел не обязательно будет равна нулю. Чаще всего называют их float или real и занимают они от 4 до 8 байт.

Уникальный идентификатор
Еще один "монстр" для понимания сути которого нужна математика, но кратко - это специальный тип, который хранит уникальную строку определенного формата. Используется для распределенных систем для идентификации справочников (часто можно видеть в Госуслугах или на ГИС ЖКХ), так как вероятность сгенерировать два одинаковых UUID настолько мала, что ею пренебрегают.

XML и JSON
Сами по себе эти форматы хранения (да, тут и формат и тип имеют одно наименование, так что масло масленное) достойны отдельного поста и так и будет. Если кратко, то такие типы данных эдакий правильный способ хранить JSON или XML, чтобы потом можно было к ним обращаться.

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

Немного поиграли в теорию и возвращаемся к более практическим задачкам. На досуге мы с супругой частенько играем в игру 5букф от Тиньков (ссылка, не реклама, https://5bukv.tinkoff.ru/). На самом деле, игра не нова и является клоном игры wordle, которую ребята из Тинькофф встроили в приложение и посыпали немного подарками. Видимо, это что-то про маркетинг и попытка заставить клиентов почаще гулять в приложение, но это не точно.

Так вот, как-то я обмолвился, что решение этой игры можно написать на SQL и вот момент настал. Попробуем написать решение на SQL + немного добавить анализа того, а есть ли воля случая в игре или за шесть попыток в можно раскрыть любое слово? А если не в русском, а в английском? Получается, интересная задачка про данные.

Приступим. Попробуем спланировать наш заход в этот "продукт" по шагам:
1) Создать структуру хранения для всех возможных слов из пяти букв. Говорим на русском и потому слова тоже будем использовать русские.
2) Найти где-то базу слов (причем по правилам игры там только существительные) и скопировать к себе. Дальше я буду использовать словарь отсюда.
3) Продумать алгоритм по которому мы будем подбирать слово за словом в игре. Возможно, найдется вариант, по которому за один проход мы будем доходить до некоей точки, в которой будет оставаться только одно доступное слово. Это уже похоже на анализ данных.
4) Проверить алгоритмы из третьего пункта и проверить на решаемость или опровергнуть возможность решения.
.....
N) Написать ИИ, который будет решать задачу с первой попытки.

Итак, понедельник - день тяжелый и мы подумаем про структуру. Первой мыслью может быть, что нам хватит просто таблички с перечнем слов. Но, вряд ли кто-то за нас уже собрал все слова из пяти букв и потому данные нужно будет немного подготовить. Следовательно, наша структура претерпевает изменения и нам нужны теперь две таблички:
1) Все слова русского языка
2) Все слова русского языка из пяти букв

-- Все существительные русского языка
CREATE TABLE nouns (word VARCHAR(255));

-- Все существительные русского языка из пяти букв
CREATE TABLE nouns5 (word CHAR(5));

В скрипте выше создается две таблицы, каждая из которых содержит по одной колонке. В первом случае колонка со всеми словами и потому там длина поля (сколько букв можно положить) используется максимальная, а во втором мы знаем что слова будут только из пяти букв и потому явно говорим СУБД, что там будут только строки на пять символов.

Важно! В скрипте выше впервые использованы комментарии. Комментарии - это часть кода, которая не исполняется, но которая помогает понять что же хотел сказать автор без учительницы русского языка и литературы и даже без гугла и искусственных интеллектов. Рекомендую использовать комментарии везде, где возможно неоднозначное трактование кода. В SQL комментарии к коду бывают однострочные и многострочные. Первые начинаются с "--", а вторые начинаются с "/*" и заканчиваются "*/". Например:

-- Это комментарий и он не будет выполнен
SELECT 1; -- Комментарий может быть даже тут, после куска кода, который выполняется
/* А это многострочный комментарий,
когда мысль настолько широкая, что ее не получается
уместить в одну строку */

... продолжение следует
#sql #sqlbasics #firstproject

Шпаргалка по Airflow от Marc Lamberti

Вот ещё шпаргалка

Собрал все части воедино, поменял название и тональность.
Получилось мутно, плотно, в меру горько, в меру крепко. NE DIPA.

https://telegra.ph/Poigraem-v-DataOps-davaj-vecherom-04-16

#dataops

«По «Маяку» Стахан Рахимов дуэтом с Иошпе песни пел…»

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

Тем более, что у меня наконец-то «дошел ход» до выпущенной в сентябре 2022 года товарищами из O'Reilly книги под названием «Data Quality Fundamentals», которая и послужит отправной точкой для данного повествования.
«Все, все как вчера…» - скажет внимательный читатель данного канала словами одной известной рок-поэтессы, ссылаясь на ее стихи практически сорокалетней давности. И будет безусловно прав…
Ибо фразу «работает - не трогай!» я избрал своим основным жизненным принципом еще тогда, когда никакого IT толком в моей жизни и не существовало.

Продолжение следует...