Только сейчас понял, что комментарии к посту выше были выключены. Исправил ситуацию :)
Написать комментарий к предыдущему посту можно тут 👇

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

#моделирование_процессов

Нашёл прикольную шпаргалку с основными элементами BPMN.

А также немного полезного контента про моделирование в нотации BPMN:

Первое - Канал про BPMN

И второе - Статья на habr с описанием основных сущностей нотации

#базы_данных

Интересная статья про индексы в БД. Понравилась подача материала. Как говорится: "простыми словами о сложном".
Статья в посте ниже 👇

Индексы в БД на пальцах

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

🔹 Что такое индекс? Это вспомогательная структура данных, которая создается средствами СУБД и хранит информацию о расположении (или адресе) строки в таблице с некоторым значением поля. Индексы строятся для каждого поля отдельно: можно построить по индексу на каждое поле таблицы, если в этом есть необходимость.

🔹 Зачем нужны индексы? Для ускорения поиска. Без индекса СУБД вынуждена перебирать все строки в таблице в поисках нужной; индекс позволяет быстро узнать местоположение этой строки и перейти сразу к ней. Аналог из жизни - статья в журнале или глава из книги: вместо того, чтобы перелистывать все страницы, вы ищете название в оглавлении и переходите к нужной странице.

🔹 Как работают индексы? Индексы можно упрощенно представить себе как отсортированные копии полей (столбцов таблицы). Поиск значения в отсортированной структуре происходит очень быстро - вы быстрее найдете старницу номер 742 в книге из 1000 страниц, чем бубновую девятку в перетасованной колоде карт, потому что карты нужно перебирать, а номера страниц отсортированы. Найдя значение поля в индексе, СУБД получит информацию об адресе всей строки таблицы (которая там была сохранена при создании индекса), то есть "перейдет по номеру страницы", если сравнивать с книгами.

🔹Минусы и особенности. Помимо очевидноно плюса в виде ускорения поиска, есть ряд особенностей, которые нужно иметь ввиду.
1. Индексы - это дополнительные структуры данных, которые нужно хранить, следовательно, они занимают дисковое пространство, особенно это важно учитывать при работе с большими таблицами (хотя именно там они наиболее эффективны).
2. Если мы меняем значения в таблице (включая добавление и удаление строк), то это будет происходить в двух местах: в самой таблице и в индексе, то есть у нас немного замедляется модификация таблиц. Для задач с большим количеством изменений это может быть ощутимо.
3. Неправильно выбранный тип индекса может замедлить поиск. Например, индексы в виде деревьев неэффективны для столбцов с низкой мощностью множества*

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

* Мощность множества или Cardinality - это характеристка, показывающая уникальность данных, входящих в множество. Если у нас есть миллион строк для поля Gender, которые содержат только значения Male и Female, то говорят, что у такого множества низкая мощность. А поле Email с уникальными данными будет иметь высокую мощность.

Подробнее о типах индексов можно почитать в этой статье на хабре

#СУБД #собеседование

Друзья, привет! 👋

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

Что такое шаблоны взаимодействия ? 🤔

Шаблоны взаимодействия - это способы, с помощью которых организуется среда «общения» АС. И эти способы задают формат взаимодействия. В качестве аналогии из жизни можно использовать формат встречи - совещание, вечеринка и т.д. 🥳
Другими словами шаблоны отвечают на вопрос, «какую среду организовать для «общения» АС?»

Типы шаблонов взаимодействия:

1. Прямая интеграция систем — шаблон взаимодействия двух систем, при котором две системы или компоненты взаимодействуют друг с другом способом, который технологически реализуем на обеих системах.
Преимущества: производительность, тесная интеграция, отсутствие дополнительных точек отказа
Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, отсутствие возможности переиспользования

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

3. Сервисная шина предприятия (англ. enterprise service bus, ESB) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры. Другими словами, это промежуточное ПО, которое позволяет объединить большее число систем или приложений, а также организовать взаимодействия между ними на основе сервисов
Преимущества: производительность, готовая реализация интеграции, унифицированное решение, возможность переиспользования
Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, дополнительная точка отказа, команда сопровождения

4. Service mesh — шаблон для динамического связывания сервисов, в особенности микросервисов, из которых формируется одно приложение. Это выделенный слой инфраструктуры для обеспечения безопасного, быстрого и надёжного взаимодействия между сервисами.
Преимущества: производительность, гибкость, масштабируемость
Недостатки: дополнительная точка отказа, команда сопровождения с достаточными знаниями для создания и использования этого шаблона

5. Перегрузка данных — это специфический шаблон для передачи большого объема данных. Процесс перегрузки заключается в переносе данных из системы источника в систему потребителя или хранилище данных с помощью специализированных средств (например, ETL (от англ. Extract, Transform, Load) или промежуточное ПО)

А с какими шаблонами взаимодействия приходилось сталкивать вам на практике ?
Делитесь своим опытом в комментариях 👇

PS Относительно давно не было постов на канале, но буду исправлять эту ситуацию и стараться выкладывать полезный контент чаще 😊
PSS Ваши реакции мотивируют меня на новые посты 🔥

Хорошая наглядная иллюстрация к предыдущему сообщения 🔥

#базы_данных

Про оптимизацию sql запросов

Зачастую на практике мне (думаю, что вам тоже) приходится сталкиваться с написанием сложных sql запросов, а потом долгое время ожидать выполнения запроса и пить кофе ☕️

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

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

Можем сыграть в игру "самый долгий sql запрос". Пишите в комментарии самое долгое время выполнения запроса 😄
Победителю - подарок 🎁

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

Начинаем новую неделю с серии постов про подходы к проектированию баз данных 🔥

Что такое ACID и BASE в теории баз данных ?

BASE (Basically Available, Soft state, Eventually consistent) и ACID (Atomicity, Consistency, Isolation, Durability) - это два разных подхода к проектированию и обеспечению целостности данных в распределенных системах.

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

BASE, с другой стороны, является более гибким подходом, который учитывает ограничения и неизбежность ошибок в распределенных системах. BASE поддерживает высокую доступность и отказоустойчивость путем снижения требований к согласованности данных. Это достигается за счет того, что база данных может находиться в промежуточном состоянии - состоянии, когда некоторые копии данных могут быть обновлены, а другие нет. Однако, с течением времени все копии данных сходятся к одному состоянию (Eventually consistent), что обеспечивает согласованность.

В чем различаются эти подходы ?

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

В следующих постах мы подробно рассмотрим основные принципы, лежащие в модели ACID и BASE, а также поговорим про CAP теорему.

Ставьте реакции к посту, если было полезно🔥

#базы_данных

Продолжаем тему предыдущего поста и остановимся на подходе ACID.

Давайте подробно разберём каждое свойство из аббревиатуры.

1⃣ Atomicity (Атомарность) – транзакция является неделимой и должна быть выполнена полностью или не выполнена вообще. Если транзакция не может быть выполнена до конца, то СУБД должна откатить ее и вернуть данные к предыдущему состоянию. Это гарантирует, что если транзакция не может быть выполнена успешно, то все изменения, внесенные в базу данных до этого момента, будут отменены.

2⃣ Consistency (Согласованность) – транзакции должны поддерживать целостность данных. Это означает, что если данные в базе данных находятся в конкретном состоянии, то любая транзакция должна привести базу данных к другому согласованному состоянию. Транзакции не могут изменять данные в противоречии с правилами базы данных.

3⃣ Isolation (Изолированность) – каждая транзакция должна выполняться в изоляции от других транзакций, т.е. не должно быть видимости изменений, внесенных в базу данных другими транзакциями, пока текущая транзакция не завершена. Это гарантирует, что транзакции не будут конфликтовать между собой.

4⃣ Durability (Долговечность) – изменения, внесенные в базу данных транзакцией, должны быть сохранены и доступны после завершения транзакции, даже если происходит отказ системы или другой сбой. Это гарантирует, что данные в базе данных сохранятся даже в случае сбоя системы.

Зачем соблюдать вышеперечисленные свойства ❓

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

О модели BASE мы поговорим в следующем посте  🔜

#базы_данных

One hour later one month later...
Итак, мы завершаем серию постов про подходы к проектированию ПО👨‍💻

И сегодня разберём подход под названием BASE.

BASE - сокращение от Basically Available, Soft state, Eventually consistent. Подход BASE ставит упор на доступность данных и их масштабируемость, позволяя достигнуть этих целей за счет компромисса в отношении согласованности данных. В этом подходе допускается, что данные могут находиться в “мягком” состоянии, то есть состоянии, которое может быть не совсем точным или актуальным в любой момент времени.

Подход BASE подходит для систем, которые нуждаются в высокой доступности и масштабируемости, но могут терпеть небольшие задержки и несогласованности данных. Он может использоваться в системах, таких как распределенные системы, сетевые приложения, системы Big Data и другие.

Что означают буквы в аббревеатуре BASE❓

1⃣ Basically Available - это свойство обозначает, что система должна быть доступна для обработки запросов и предоставления данных в любое время, даже в случае сбоев в работе или разделения на несколько частей

2⃣ Soft state - это свойство обозначает, что состояние системы может быть временно несогласованным, то есть данные могут находиться в процессе изменения и обновления.

3⃣ Eventually consistent - это свойство обозначает, что в системе может быть временная несогласованность данных, но в конечном итоге все данные будут согласованы

Есть хорошая статья, где подробно описаны различия между двумя подходами в пооектировании: https://phoenixnap.com/kb/acid-vs-base

Друзья, привет!

Сделал "каркас" давнообещанной карты навыков для системного аналитика 📝
План на будущее: подробно расписать каждую тему карты и поделиться картой с вами.

Подробное описание каждой темы в посте ниже 👇

Какие темы вошли в первую версию карты?
1. Базовые знания из Computer Science 💻 - этот раздел является обязательным для всех it специальностей (мое личное мнение)
2. Нотации моделирования бизнес процессов 🧩 - BPMN, UML и т.д. Практически во всех вакансиях от аналитика требуют владения этими навыками
3. Требования к программному обеспечению 📜 - аналитик должен понимать какие требования существуют, как правильно подходить к процессу сбора требований
4. Архитектура ПО 🏠 - системный аналитик - это мини архитектор в команде. Зачастую приходится решать различные архитектурные задачи (+если хотите развиваться в сторону архитектора, то знание архитектуры - must have)
5. Теория баз данных 📟 - надо понимать как устроены БД, какие виды БД существуют и т.д.
6. Интеграция - знание темы нужно для того, чтобы понимать какими способами системы могут обмениваться информацией между собой
7. Языки программирования 🐍 - как обязательный включил бы sql, Python - как приятное дополнение :) Сейчас выпала задачка, пишу компонент ПО на Python, поэтому знание какого-нибудь ЯП - будет плюсом.
8. Тестирование ПО 📌- да, системный аналитик ещё и немного тестировщик. Поэтому с основами тестирования стоит ознакомиться.
9. Методологии разработки 🔖 - в каждой компании/команде свои подходы к разработке. Аналитик работает с задачей от самого начала до сдачи её заказчику. Поэтому понимать по какой методологии работает ваша команда - обязательно.
10. Soft skills 🗣 - важный пункт, гибкие навыки помогают быстрее наладить контакты, продвигаться по карьерной лестнице
11. Основы UX/UI 🧬 - добавил раздел, потому что иногда аналитику приходится на "скорую" руку сделать какой-нибудь макет в Figma (но всё зависит от сферы. думаю, этот пункт больше относится к тем, кто занимается mobile)
12. Инструменты для работы 🔨 - список всяких ПО, которые стоит освоить аналитику

Фух, вроде бы всё. Если есть идеи по тому, что можно ещё закинуть в карту - пишите в комментарии, обсудим :)
Также буду ждать критику/пожелания/замечания в комментариях к посту.

В ближайшее время ещё выложу пару опросов (не пугайтесь 😄). Хочу понять, что вам будет интересно читать в канале.

Остались последние часы уходящего 2023 года, самое время подвести итоги года и поставить цели на новый 2024 год. (да, я не забыл про свой канал, на 2024 год у меня на него большие планы:) )
Итак, мои итоги 2023 года:
1. Стал более техническим специалистом.
Что я имею ввиду?
В середине 2023 перешёл в другую компанию на позицию инженера данных. До этого работал с данными исключительно как аналитик. Но сейчас разработка стала скорее дополнением к моим обязанностам, так как обязанности аналитика всё равно остались.
2. Изучил новые для себя инструменты работы с большими данными, новые языки программирования.
2. Написал несколько статей на хабр
Скорее всего большинство участников канала как раз оттуда:)
3. Стал вести этот канал
Хоть и с перерывами))
4. Пробежал 2 старта за год полумарафон и 10км. Обновил личник на полумарафоне и на 10км.
5. Улучшил английский. Сейчас уровень B2. В новом 2024 году хочу довести английский до С1.

Хочу всем пожелать в Новом году ставить амбициозные цели и достигать их.
С Наступающим 2024 годом!

Что такое распределенные вычисления?

При работе с большими данными специалисты сталкиваются с проблемой, что вычисления с использованием одной машины становятся неэффективными.

В таком случае компании стараются внедрить инструменты для работы с большими данными, такие как Hadoop, Spark и т.д.

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

Как я написал выше, один из инструментов для работы с большими данными - это spark. Использование spark'a позволяет кратно уменьшить время вычислений.

Если хотите узнать о том за счёт чего достигается такая скорость вычислений в спарк - ставьте 🔥 на эту запись.

И в следующем посте я расскажу вам об этом, а ещё поделюсь своей историей о том как мне удалось в 10 раз оптимизировать загрузку данных с использованием spark (изменив при этом всего 1 строку кода 😁)
#hard_skills

Как Spark может ускорить скорость вычислений в 10 раз?

Недавно столкнулся с задачей оптимизации загрузки данных в хранилище.

Был уже готовый поток загрузки данных, который прогружал 1 день исторических данных за 5 часов. Требовалось перегрузить 5 месяцев исторических данных. По расчётам поток грузил бы данные 30 дней.

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

Здесь как раз на помощь пришёл spark. Использовалась строка кода с регулярным выражением. После переноса всего лишь одной этой строки кода на spark скорость вычислений увеличилась в 10 раз. Поток стал отрабатывать за 30 минут.

Как использование spark'a помогает получить такие результаты?

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

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

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

На прошлом посте набралось 15 🔥. Если наберём под этим постом 25 🔥, то поделюсь своей подборкой материалов для изучения spark.
#hard_skills