#база_знаний

Почему дату в СУБД и других хранилищах часто записывают в формате строки?

💡 Этот пост будет полезен новичкам, кто только начинает изучать SQL и задумывается, почему даты иногда хранятся не в привычном формате DATE или TIMESTAMP, а в виде строк.

Когда я только погружался в SQL на работе, для меня было болью, если дата была записана в формате строки. Ведь везде на курсах говорят, что дату нужно хранить в DATE формате, и не иначе.

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

Давайте разберемся, какие есть плюсы и минусы в таком подходе - хранить даты в строковом формате в хранилище.

➕Плюсы:

▪️Универсальность и читабельность. Формат YYYY-MM-DD (ISO 8601) стал стандартом для представления дат. Записав дату строкой, её легко понять как человеку, так и компьютеру. Это особенно важно, когда данные передаются между разными системами.

▪️Минимизация ошибок при парсинге. Системы могут по-разному интерпретировать даты, записанные в числовом формате. Например, 12/11/2023 в одной системе может означать 12 ноября, а в другой — 11 декабря. Формат строки, особенно ISO 8601, помогает избежать таких путаниц.

▪️Совместимость с разными системами. Не все базы данных или приложения умеют работать с типом DATE, особенно старые системы. Строки проще использовать при интеграции с такими системами.

➖ Минусы:

▪️Неправильная сортировка. Строки сортируются по алфавиту, и это не всегда совпадает с хронологическим порядком. Например, '12/31/2023' может оказаться перед '01/01/2024', хотя по времени это не так. Если придерживаться формата YYYY-MM-DD, таких проблем не будет, но в других случаях возможны сложности.

▪️Ограниченные возможности работы с датами. В строковом формате нельзя сразу использовать встроенные функции для дат, такие как вычисление разницы между датами или извлечение дня недели. Для этого потребуется сначала преобразовать строку в DATE или TIMESTAMP.

▪️Ошибки валидации и формата. Строки не защищены от неверных данных. Например, можно ввести '2023-13-01' или '2023-02-30', и система их примет, хотя это некорректные даты. Тип данных DATE сразу бы отклонил такие значения.

❗️Когда стоит использовать строковый формат для дат?

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

Для новичков важно понимать: строковый формат может быть полезен, но лучше использовать типы данных, созданные для работы с датами, если это возможно. Это повысит точность работы и упростит управление данными.

Если работаете с датами в строковом формате, используйте маску ‘YYYY-MM-DD’, тогда проблем с интерпретацией даты, сортировкой и выполнению join возникать не будет.

🖥 Навигация по другим материалам группы.

А как вы предпочитаете хранить даты в ваших проектах дома или на работе?

#мысли

💬 Мой наставник сказал мне пару дней назад, что лучше быть инженером данных с разносторонним кругозором, быть знакомым с множеством технологий, но главное - понимать, как решать поставленную задачу, находить плюсы и минусы подходов, уметь анализировать, какой из них лучше в каждой ситуации. А также не забывать коммуницировать с заказчиками и выяснять их реальную бизнес потребность.

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

Эту мысль сразу сложно понять. Но если ваш кругозор будет широк, а также вы будете в постоянном контакте с бизнесом, то вы не только сможете использовать лучшее решение, но и принесете бизнесу бОльшую пользу, показав разные варианты решения их задачи.

#материалы

⚙️ Когда вы освоили SQL и разобрались с реляционными базами данных, самое время переходить к автоматизации!

Можно попробовать создать простой ETL прямо на вашей машине — без сложного ПО и оркестраторов, используя только SQL и встроенный cron. Это отличное упражнение для погружения в задачи автоматизации данных, ведь такой ETL-процесс поможет вам структурировать и автоматизировать регулярные операции с данными.

В статье я рассказываю:

🔸Как настроить cron для автоматического запуска SQL-скриптов
🔸Как ETL помогает структурировать процесс обработки данных
🔸Почему этот подход полезен для начинающих специалистов

Подробнее — по ссылке на статью

Насколько вам больше нравится новый формат постов? Ответ принимается реакциями 🔥

Друзья, рад представить вам свой курс по SQL на Stepik! 🎓

Что вас ждет:
✅ Основы SQL — от простых SELECT до построения витрин данных;
📚 Пошаговые уроки с видеолекциями, конспектами, понятными примерами и практическими заданиями;
💡 Удобный формат обучения с тренажерами и моей обратной связью;
📢 Выделенная закрытая группа в телеграм.

😎 Присоединяйтесь! Начнем ваш путь в Инженерию данных вместе.
P.S. Отключайте VPN при оплате. 👀

Различные подходы загрузки данных в DWH.

🔖В прошлом посте мы рассмотрели, как автоматизировать загрузку данных с помощью cron.

Теперь разберем три основных подхода:
1️⃣Full Load
2️⃣Incremental Load
3️⃣Delta Load.

❓ Какой выбрать? Всё зависит от ваших задач и объемов данных.

В статье разберу их плюсы, минусы и области применения!

🧑‍💻 Не программируйте в вакууме: как дома освоить базы данных?

Если вы только начинаете свой путь в Data Engineering или хотите углубить навыки работы с базами данных, есть несколько простых и эффективных способов:

🔸Установить PostgreSQL локально
🔸Попробовать облачные базы данных
🔸Освоить Docker

❓ Так что выбрать?

В статье я рассказываю о каждом варианте, делюсь плюсами, минусами, полезными советами для старта и своим опытом.

▶️ Кейс про связь BI, SQL и Airflow

Работаю с BI-инструментами уже 2-3 месяца и постепенно начинаю видеть, как это дополняет работу дата-инженера. Недавно разбирал интересный кейс: автоматический расчет данных, ручное обогащение и построение актуального отчета в Qlik Sense на основе SQL и оркестрации в Airflow.

🔹 Что это дало?

1️⃣Понимание бизнес-смысла: важно не просто строить пайплайны, а понимать, как данные влияют на решения.
2️⃣Более глубокое понимание BI: визуализация помогает увидеть конечный результат работы и получить обратную связь от бизнеса.
3️⃣Полный цикл данных: от загрузки и обработки до наглядного отображения в отчетах.

🎯 Вывод: Дата-инженеру полезно освоить BI и немного глубже погрузиться в потребности бизнеса. Это помогает лучше понимать конечный продукт и ценность данных, над которыми мы работаем.

А как у вас с BI? Пробовали строить отчеты или работать с визуализацией? Делитесь опытом!

#путь_DE

🔥 Почему важно учиться на реальных кейсах?
Многие новички в Data Engineering считают, что достаточно выучить SQL-синтаксис, Spark-трансформации или теорию о хранилищах данных. Как-то давно мне запомнилась фраза: «В теории можно обойтись без практики. На практике - нельзя»

💡 Реальные кейсы — это ключ к глубокому пониманию. Почему?

1️⃣Связь с реальной жизнью:
Часто учебные примеры слишком упрощены: одна таблица, простые запросы. В реальной работе вы столкнётесь с ситуациями, когда у вас:
• Несколько таблиц с огромным количеством данных.
• Сложные связи, которые нужно оптимизировать.
• Неоднозначные и часто непонятные требования от бизнеса.

Решая кейсы, вы учитесь справляться с этим заранее.

2️⃣Ошибки = опыт:
На реальных задачах вы неизбежно совершите ошибки: что-то не сработает, запрос выполнится слишком долго или окажется неверным результат.

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

3️⃣Готовность к собеседованию:
HR и технические специалисты ценят кандидатов, которые не просто «знают», но и умеют применять. Если у вас есть опыт решения реальных кейсов, это ваш козырь на собеседовании.

💼 Пример:
На собеседовании вас могут спросить:
“Как бы вы организовали ETL для обработки данных о продажах?”

Если вы решали кейсы, вы уже знаете, как спроектировать процесс, выбрать инструменты и оптимизировать запросы. У вас уже есть опыт, и это сразу будет видно.

🚀 Мой совет:
Не бойтесь сложных задач. Берите кейсы, даже если они кажутся трудными. На моём курсе, помимо основ SQL, итоговый проект приближен к реальной задаче DE, чтобы вы были готовы к работе уже после обучения.

А как вы учитесь на практике? Пишите в комментариях 👇

Какие антипаттерны вы встречали в SQL и Spark? 🤔

Вот пример из SQL:

Подзапросы вместо JOIN там, где это не нужно

Почему это плохо:
- Подзапросы могут вызываться для каждой строки, что снижает производительность.
- Логика запроса становится сложной для понимания и отладки.

🚫 Антипаттерн:

SELECT first_name, last_name,
(SELECT COUNT(*) FROM payments WHERE payments.client_id = clients.client_id) AS payment_count
FROM clients;

✅ Более правильно использовать JOIN:

SELECT c.first_name, c.last_name, COUNT(p.payment_id) AS payment_count
FROM clients c
LEFT JOIN payments p ON c.client_id = p.client_id
GROUP BY c.client_id, c.first_name, c.last_name;

Какие антипаттерны в SQL и Spark вы встречали?
Поделитесь своим опытом! Интересно собрать список того, чего точно не стоит делать, чтобы избежать проблем с производительностью и читаемостью кода.