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

Недавно на работе общался с коллегой по поводу значения NULL и его использования в SQL запросах c WHERE.
Мне показалась эта тема довольно интересной и я решил написать о ней.
Итак, с точки зрения модели реляционной базы данных значение NULL указывает на неизвестное значение (это не True т.е. 1 и не False т.е. 0). Значение NULL указывает на неизвестное значение, но это неизвестное значение не равно нулевому значению или полю, содержащему пустую строку, неразрывный пробел итп. Из-за такой структуры значений NULL невозможно использовать в запросах c операторами сравнения (=, <, > , != и <>). Фактически, в стандартах SQL использование ключевого слова WHERE, как показано ниже, приведет к возврату пустоты.
SELECT
column_name1,
column_name2,
column_name3,
column_nameN
FROM
table_name
WHERE
column_nameN = NULL

SELECT
column_name1,
column_name2,
column_name3,
column_nameN
FROM
table_name
WHERE
column_nameN != NULL

Это занимательный факт который вероятно у вас могут спросить на техническом собеседовании. Так же стоит отметить что для этой проверки существует нормальный SQL Clause вроде IS NULL / IS NOT NULL, что как раз таки и будет проверять неизвестность а не истинность или ложь утверждения. С NULL так же есть нюанс при использовании функции COUNT(), тк функция COUNT будет считать только не NULL значения. (Тоже вопрос на собеседование) С этим можно бороться так.


SUM(CASE WHEN Title is null THEN 1 ELSE 0 END) AS helper,
COUNT(col1) AS counter
FROM
schema.table

Это как говорится, - база.

Признаюсь, форматирования постов в телеге - это на подумать.

Поговорим об индексах в базах данных.
Тема важная и встречается практически в каждом собеседовании на DE и бэкендера.
Итак, самое сложное как по мне это всегда понять абстрагированно концепцию термина.
По сути индекс - это некая сущность (строго говоря структура данных) в базе данных что позволяет существенно ускорить доступа к колонкам в таблице.
То есть это не уложенные в ряд строки что вы выбираете в своих селектах. А более сложная структура данных например (B-дерево, GiST итп) что хранит адреса, ключевые значения и прочее на основе того что находится в индексированной таблице.
Чтобы понять индексы желательно так же иметь представление о нотации Big O, тк по мне это довольно сильно связанные между собой темы.
Ведь эти самые индексы фактически являются для таблиц тем, чем алгоритмы являются для кода. Способом ускорения и оптимизации выполнения.
Индексов существует огромное множество. Их можно по разному классифицировать и если сходу стараться понять эту тему то можно столкнуться с рядом сложностей.
Индексы могут быть кластерными и не кластерными.
Уникальными и не уникальными.
Составными и нет.
Кластерный и не кластерный индекс при этом могут быть составными.
Наверняка есть какие то специальные типы индексов в каких то особенных СУБД о которых я не знаю.
Есть даже такие экзотические индексы как географический индекс. И если у собеседующего вас человека плохое настроение, то он вероятно начнет задавать вопросы о том может ли быть условный географический индекс составным и кластерным. (Да может)
Чтобы уверенно отвечать на такие вопросы важно знать БАЗУ и хорошо понимать структуры данных используемые в индексах. Таким образом вы сможете дойти до ответа даже если изначально его не знаете.

Разберемся в структурах данных индексов и в Нотации Big O в следующих постах.

Интересная гифка что доступно объясняет смысл методологии (строго говоря транзакционной модели) ACID (можно еще перевести как кислота с Английского).
Ее часто сравнивают с методологией BASE (база при переводе с Английского, Hadoop и в частности HBase и Impala использует его)

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

1) Нужно стараться в максимально короткие сроки выйти на работу, стажером, trainee, intern, Джуниором или даже вообще без ставки за просто так. (Если сможете лучше - то молодцы, тут главный посыл не в должности).
Когда вы столкнетесь с реальными задачами, реальным коллективом, рабочими процессами и техстеком что используется в промышленной среде - то у вас изменится восприятие всего. Вам нужно будет закрывать задачи, что на вас отправят ваши руководители, и вы сразу все начнете улавливать на лету.

2) Не фокусироваться на том, что вы чего то не знаете, не съедать себя из за синдрома самозванца. Невозможно знать все в этом мире, как и невозможно заработать все деньги в мире. Просто объективно оценивайте свои знания и старайтесь безболезненно воспринимать критику. (Например так: ага меня спросили про ГитФлоу, а я не знаю команды Git, стоит уделить этому побольше времени)

3) Старайтесь сразу брать какие то термины и концепции, «на понимание». Например если фраза
“Python это интерпретируемый язык программирования с сильной динамической типизацией» вам совершенно непонятна, то разбиратайте (как говорят программисты декомпозируйте) это предложение вплоть до каждого непонятного слова и изучайте что оно значит.
В целом это не критичный пункт, но он сэкономит ваше время, и так вы сможете изучить больше в более короткий промежуток времени.
Не опускайте руки если вы чего то не понимаете. Даже самые крутые сеньоры-помидоры когда то, совершенно так же втыкали над этим.

4) Бейте в одну точку - если вы условно изучаете, язык Java, хотите создавать какие то мобильные приложения, веб серверы, моды для майнкрафта или еще что то, но вы чувствуете что чего то не понимаете и упираетесь в стену. То не спешите менять тех стек и область своего изучения. Поспите день - другой, найдете того кто мог бы вам помочь и объяснить непонятный момент и так вы достигнете гораздо большего.
Это важно, потому что :
4.1) Вы столкнетесь с такими же проблемами и преградами в другом языке (это называется learning curve по умному)


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

Сегодня у меня прошел Deep Dive по Apache Airflow.
Рассказал об основных преимуществах этого инструмента, его основных юз-кейсах и показал несколько интересных конвееров данных.

Видео
https://drive.google.com/file/d/1KT1fXfdMKl8SD3WqbqEC6JyD61k-ulnq/view?usp=sharing

Презентация
https://docs.google.com/presentation/d/1oMTjc_Gjq6IIgNFzRzy2eoAF-jrWIRTf/edit?usp=sharing&ouid=114931412290786365808&rtpof=true&sd=true

Задачка пока что откладывается.
Расскажу о типах данных в контексте БД.

Иногда у вас на собесе могут спросить, а зачем вообще нужны типы данных? Ну или может вы сами задумаетесь об этом в процессе решения задачи.
Не легче было бы хранить любую информацию в одном универсальном типе? На такую роль вполне могли бы претендовать символьные строки (на жаргоне стринги или String).
Существует множество причин, почему развитие технологий пошло совсем другим путем и у нас появились long, double, bigint, text и другие.

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

Для хранения чисел от - 32768 до +32767 необходимо уже два байта (так как эти пределы представляют собой число 2 в степени 16).
Если бы для представления чисел использовались символы ASCII (т.е. хранить число в виде строки), для хранения чисел, превышавших 9999, потребовалось бы 6 байт (5 байт для цифр и один - для знака).
А теперь представьте себе, что в одном столбце могут находиться миллионы числовых значений, и экономия 4 байтов на каждом из них может вылиться в мегабайты освобожденного пространства. Сегодня эти цифры вряд ли вас впечатлят, но в 1970-х годах даже один мегабайт представлялся невероятно большим пространством. Принцип эффективности еще не утратил своего значения, но сегодня масштабы понятия пространства выросли на несколько порядков.
И тем не менее вопрос эффективного использования дискового пространства и вычислительных ресурсов никуда не делся. Просто сейчас это мультимедия и Большие Данные. Вполне нормальным юз кейсом считается прихранивание видео в базе данных. (Раньше это могли бы себя позвонить лишь очень богатые компании и правительство)

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

Итак обещанная задача из собеседования на позицию Middle Data Engineer.

Чтобы ее решить необходимо понимать структуры данных, что не реализованы стандартно в ваших любимых языках программирования. Т.е. связанный список необходимо будет создать самому.

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

Итак сама задача:

Задача на Python3 (можно на Scala/Java). (В Мире Дата инженерии очень и очень активно используется язык Scala придерживающийся философии функционального программирования и созданный на основе языка Java (буквуально использует JVM))

На вход подаётся массив l со связанными списками. Каждый связанный список отсортирован в порядке увеличения.
Задача соединить все связанные списки в один отсортированный связанный список и вернуть его.

Пример:

Вход: l = [[2,3,7],[2,32,44],[21,66]]
Выход: [2,2,3,7,21,32,44,66]

Ограничения:

l.length не выше 104 (может быть 0)
l[i].length не выше 500 (может быть 0)
значение чисел в связанном списке не больше (<=) 104 и не меньше (>=) -104
значения чисел отсортированы в порядке увеличения

Хочу заранее заметить, что задача не решается в лоб и вас не просят отсортировать обычный массив. Загуглите что такое связанный список если не знаете.

По поводу связанных списков в прошлом посте.
Хотел бы на них более подробно остановиться и объяснить суть этой структуры данных, на примере новогодних игрушек.
Представьте, что у вас по комнате разбросана куча игрушек. Вы хотите отслеживать их в определенном порядке, но у вас нет коробки для игрушек, чтобы хранить их все вместе. Вместо этого вы решаете создать воображаемую линию игрушек, в которой каждая игрушка связана со следующей.

Связанный список это по сути линия из игрушек. Каждая игрушка называется «узлом» и состоит из двух частей: одна часть содержит саму игрушку (назовем ее данными), а другая часть указывает на следующую игрушку в строке (назовем ее следующей). указатель).

Итак, вы начинаете с того, что выбираете игрушку и кладете ее в начало линии. Эта игрушка - первый узел в связанном списке. Затем вы выбираете другую игрушку и соединяете ее с первой игрушкой, используя указатель «следующий». Продолжайте делать это до тех пор, пока не соедините все игрушки в линию.

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

Если вы хотите добавить новую игрушку, вы просто соедините ее с последней игрушкой в связанном списке, используя указатель следующий. Если вы хотите удалить игрушку, вы обновляете указатель «следующий» предыдущей игрушки, чтобы пропустить игрушку, которую хотите удалить.

Связанные списки как структура данных полезна в высоконагруженных системах, тк очень эффективно используют память, позволяют легко добавлять или удалять элементы, так же их используют во всяких garbage collector-ax, чтобы понимать когда от какого либо объекта можно избавляться. Так же в более экзотических случаях их используют для реализации еще более сложных структур данных вроде деревьев или графов.
Но есть и минусы:
Поиск конкретной 'игрушки' в связанном списке занимает больше времени, чем если бы все игрушки находились в условном "ящике" для игрушек, где вы можете быстро найти их (имелся в виду обычный словарь/dictionary или массив).

так связаный список можно реализовать на языке Scala

//  Обьявляем класс с узлом
class Node(value: Int) {
  var data: Int = value
  var next: Option[Node] = None
}

// Создаем класс самого связанного списка
class LinkedList {
  var head: Option[Node] = None

  // Метод добавления нового узла в список
  def addNode(value: Int): Unit = {
    val newNode = new Node(value)
    if (head.isEmpty) {
      head = Some(newNode)
    } else {
      var current = head
      while (current.get.next.isDefined) {
        current = current.get.next
      }
      current.get.next = Some(newNode)
    }
  }

  // метод для вывода в консоль нового элемента связанного списка
  def printList(): Unit = {
    var current = head
    while (current.isDefined) {
      print(current.get.data + " ")
      current = current.get.next
    }
    println()
  }
}

// как использовать
val myList = new LinkedList()
myList.addNode(1)
myList.addNode(2)
myList.addNode(3)
myList.printList()

С наступающими новогодними праздниками, дорогие подписчики, пусть Новый Год пройдет у вас лучше чем прошлый, и в новом году вы станете умнее и лучше (желаю себе того же ха-ха).

В новогоднем посте хотел бы затронуть такую фундаментальную тему как построение и моделирование Хранилищ Данных (Data WareHouse), это ключевой элемент в работе подавляющего большинства Дата-инженеров. Вся работа инженеров данных так или иначе связана с DWH.

Существует множество методологий и подходов к созданию DWH
- Corporate Information Factory (CIF) (Корпоративная Аналитическая Платформа)
- Entity-Relationship Modeling (Отношение сущностей)
- Dimensional Modeling (Многомерное моделирование)
- Data Vault Modeling (Гибридный подход полученный соединением схемы «звезды» и 3-ей нормальной формы)
- другие экзотические подходы

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

Но не переживайте)

Для вас я приложу несколько БАЗОВЫХ книг что помогут вам лучше понять эти концепции, и с легкостью проходить собесы и курсы в университете. Преподавателей и собеседующих будете валить ВЫ, а не они вас)

Правда эти книги на английском, но вы только выиграете от того что будете читать это на английском.

The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling - Ralph Kimball (очень большой Папа в мире данных) and Margy Ross.

Building the Data Warehouse - W. H. Inmon

Data Warehouse Design: Modern Principles and Methodologies - Matteo Golfarelli and Stefano Rizzi.

Первый пост в новом году.
Прошлый год оставил мне и команде в которой я работаю странный и непонятный баг.

Одно из интеграционных приложений некорректно вело себя только на промышленном стенде.

Если говорить коротко, то генерируемые sequence-ом ID почему то стали дублироваться. То есть представьте ситуацию что в вашей таблице users ID 1, 2, 3, 4 - присваивались несколько раз в результате чего происходили падения.

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

Было перепробовано множество версий, даже самых экзотических, вплоть до некорректной работы nextval() в PostgreSQL. (Идея конечно безумная, но иногда до этого доходит в поиске причины проблем)

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

nextval(table_2_generator)

вместо

nextval(table_1_generator)

- этого никто не заметил и чтобы предупредить эту ошибку на стороне разработчиков должна была присутствовать банальная внимательность.
Забавен тот факт что эту ошибку не увидело целых 3 разработчика, которые так или иначе не видели этот код. (Включая меня ха-ха)

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

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