IT analysis • Системный и бизнес анализ

Друзья, привет! В статьях выше писал о том, что такое spark, зачем он нужен и как его применяют в работе аналитики, data engineer'ы и data scientist'ы. Сегодня делюсь подборкой материалов, по которым изучал Spark. Ставьте реакции, если хотите чтобы подобные подборки публиковались в канале чаще 😊 Книги: Для изучения batch обработки данных на spark: 1. Learning Spark: Lightning-Fast Data Analytics 2. High Performance Spark: Best practices for scaling and optimizing Apache Spark Для изучения потоковой обработки данных на spark: 1. Stream Processing with Apache Spark: Mastering Structured Streaming and Spark Streaming Курс по spark (scala): В курсе довольно понятно объясняют основные понятия spark-а и его преимущества + есть практические задания к темам: https://www.coursera.org/learn/scala-spark-big-data Лайфхак: курс можно проходить бесплатно слушателем (если не нужен сертификат) и без оформления заявки на денежную помощь, для этого на странице курса нужно нажать enroll for free, далее выбрать audit only.

Этот пост не про технические навыки и компетенции в IT, а про такой навык как целеполагание. Для достижения определённого результата важно ставить правильные цели. Карьера. Доход. Отношения. Социальные достижения. Не важно какая сфера. Всё начинается с правильной постановки цели. Но что такое правильная цель? Существует много разных фреймворков для постановки цели. Самый популярный - SMART. В соответствии со SMART цель должна быть: 1. Specific - конкретной 2. Measurable -измеримой 3. Attainable -достижимой 4. Relevant - значимой 5. Timebound-ограничена во времени. Приведу пример своей цели на 2024 год в соответствии с этим фреймворком. Моя цель: до конца 2024 года (timeboud) пробежать 10км (specific) из 37:40 (measurable). Достижима (attainable) ? Да! Т.к. личник в прошлом году был 39:30 Relevant (значима)? Да! Доказать, самому себе что всё в жизни достижимо. Первый старт на 10км будет уже в марте. Посмотрим на результаты!

Как Spark может ускорить скорость вычислений в 10 раз? Недавно столкнулся с задачей оптимизации загрузки данных в хранилище. Был уже готовый поток загрузки данных, который прогружал 1 день исторических данных за 5 часов. Требовалось перегрузить 5 месяцев исторических данных. По расчётам поток грузил бы данные 30 дней. Проблема такой долгой загрузки данных была в том, предварительно данные предобрабатывались отдельным Bash скриптом на одной ноде (с использованием мощностей всего лишь одной машины) без распараллеливания вычислений. Здесь как раз на помощь пришёл spark. Использовалась строка кода с регулярным выражением. После переноса всего лишь одной этой строки кода на spark скорость вычислений увеличилась в 10 раз. Поток стал отрабатывать за 30 минут. Как использование spark'a помогает получить такие результаты? Во-первых, Spark использует мощности не одной машины, а мощности всего кластера (то есть нескольких машин, работающих параллельно) Во-вторых, Spark позволяет кастомизировать загрузку данных под каждую задачу. Это достигается благодаря гибкой настройки параметров. В-третьих, все вычисления в spark происходят в оперативной памяти. Это позволяет выполнять вычисления за короткий промежуток времени. На прошлом посте набралось 15 🔥. Если наберём под этим постом 25 🔥, то поделюсь своей подборкой материалов для изучения spark. #hard_skills

Что такое распределенные вычисления? При работе с большими данными специалисты сталкиваются с проблемой, что вычисления с использованием одной машины становятся неэффективными. В таком случае компании стараются внедрить инструменты для работы с большими данными, такие как Hadoop, Spark и т.д. Основная идея таких инструментов - это использование мощностей нескольких машин (или нескольких "нод"). Вычисления на каждой ноде выполняются параллельно, что позволяет в несколько раз быстрее выполнить расчёты. Как я написал выше, один из инструментов для работы с большими данными - это spark. Использование spark'a позволяет кратно уменьшить время вычислений. Если хотите узнать о том за счёт чего достигается такая скорость вычислений в спарк - ставьте 🔥 на эту запись. И в следующем посте я расскажу вам об этом, а ещё поделюсь своей историей о том как мне удалось в 10 раз оптимизировать загрузку данных с использованием spark (изменив при этом всего 1 строку кода 😁) #hard_skills

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

Какие темы вошли в первую версию карты? 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. Инструменты для работы 🔨 - список всяких ПО, которые стоит освоить аналитику Фух, вроде бы всё. Если есть идеи по тому, что можно ещё закинуть в карту - пишите в комментарии, обсудим :) Также буду ждать критику/пожелания/замечания в комментариях к посту. В ближайшее время ещё выложу пару опросов (не пугайтесь 😄). Хочу понять, что вам будет интересно читать в канале.

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

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

Продолжаем тему предыдущего поста и остановимся на подходе ACID. Давайте подробно разберём каждое свойство из аббревиатуры. 1⃣ Atomicity (Атомарность) – транзакция является неделимой и должна быть выполнена полностью или не выполнена вообще. Если транзакция не может быть выполнена до конца, то СУБД должна откатить ее и вернуть данные к предыдущему состоянию. Это гарантирует, что если транзакция не может быть выполнена успешно, то все изменения, внесенные в базу данных до этого момента, будут отменены. 2⃣ Consistency (Согласованность) – транзакции должны поддерживать целостность данных. Это означает, что если данные в базе данных находятся в конкретном состоянии, то любая транзакция должна привести базу данных к другому согласованному состоянию. Транзакции не могут изменять данные в противоречии с правилами базы данных. 3⃣ Isolation (Изолированность) – каждая транзакция должна выполняться в изоляции от других транзакций, т.е. не должно быть видимости изменений, внесенных в базу данных другими транзакциями, пока текущая транзакция не завершена. Это гарантирует, что транзакции не будут конфликтовать между собой. 4⃣ Durability (Долговечность) – изменения, внесенные в базу данных транзакцией, должны быть сохранены и доступны после завершения транзакции, даже если происходит отказ системы или другой сбой. Это гарантирует, что данные в базе данных сохранятся даже в случае сбоя системы. Зачем соблюдать вышеперечисленные свойства ❓ ACID-свойства очень важны для проектирования ПО, особенно при работе с транзакционными базами данных. При соблюдении этих свойств, разработчики могут создавать приложения, которые гарантируют, что данные будут сохранены в надежном состоянии и не будут повреждены в случае сбоя или других непредвиденных обстоятельств. Но использование ACID-свойств может иметь некоторые ограничения на производительность системы, особенно при работе с большими объемами данных. Поэтому, для некоторых приложений может быть более подходящим использование более гибких моделей данных, таких как BASE, которые предоставляют более высокую производительность за счет некоторой потери надежности. О модели BASE мы поговорим в следующем посте  🔜 #базы_данных

Начинаем новую неделю с серии постов про подходы к проектированию баз данных 🔥 Что такое 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 теорему. Ставьте реакции к посту, если было полезно🔥 #базы_данных

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

#базы_данных Про оптимизацию sql запросов Зачастую на практике мне (думаю, что вам тоже) приходится сталкиваться с написанием сложных sql запросов, а потом долгое время ожидать выполнения запроса и пить кофе ☕️ Чтобы уменьшить время наслаждения вкусным ароматом кофе и сократить время работы запросов предлагаю ознакомиться со следующей статьей. В ней рассказывают про разные подходы к оптимизации sql запросов. В комментариях делитесь своим опытом о том, как часто вам приходится прибегать к вопросу оптимизации запросов и какой способ вы используете. Можем сыграть в игру "самый долгий sql запрос". Пишите в комментарии самое долгое время выполнения запроса 😄 Победителю - подарок 🎁

Друзья, привет! 👋 Предлагаю сегодня обсудить такую тему как шаблоны взаимодействия систем. Давайте рассмотрим основные шаблоны взаимодействия, их преимущества и недостатки. Что такое шаблоны взаимодействия ? 🤔 Шаблоны взаимодействия - это способы, с помощью которых организуется среда «общения» АС. И эти способы задают формат взаимодействия. В качестве аналогии из жизни можно использовать формат встречи - совещание, вечеринка и т.д. 🥳 Другими словами шаблоны отвечают на вопрос, «какую среду организовать для «общения» АС?» Типы шаблонов взаимодействия: 1. Прямая интеграция систем — шаблон взаимодействия двух систем, при котором две системы или компоненты взаимодействуют друг с другом способом, который технологически реализуем на обеих системах. Преимущества: производительность, тесная интеграция, отсутствие дополнительных точек отказа Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, отсутствие возможности переиспользования 2. Шлюз — шаблон взаимодействия двух систем, при котором две системы или компоненты взаимодействуют друг с другом с помощью интеграционного слоя, который берет на себя обеспечения интеграционной логики. Преимущества: производительность, готовая реализация интеграции, унифицированное решение Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, отсутствие возможности переиспользования 3. Сервисная шина предприятия (англ. enterprise service bus, ESB) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры. Другими словами, это промежуточное ПО, которое позволяет объединить большее число систем или приложений, а также организовать взаимодействия между ними на основе сервисов Преимущества: производительность, готовая реализация интеграции, унифицированное решение, возможность переиспользования Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, дополнительная точка отказа, команда сопровождения 4. Service mesh — шаблон для динамического связывания сервисов, в особенности микросервисов, из которых формируется одно приложение. Это выделенный слой инфраструктуры для обеспечения безопасного, быстрого и надёжного взаимодействия между сервисами. Преимущества: производительность, гибкость, масштабируемость Недостатки: дополнительная точка отказа, команда сопровождения с достаточными знаниями для создания и использования этого шаблона 5. Перегрузка данных — это специфический шаблон для передачи большого объема данных. Процесс перегрузки заключается в переносе данных из системы источника в систему потребителя или хранилище данных с помощью специализированных средств (например, ETL (от англ. Extract, Transform, Load) или промежуточное ПО) А с какими шаблонами взаимодействия приходилось сталкивать вам на практике ? Делитесь своим опытом в комментариях 👇 PS Относительно давно не было постов на канале, но буду исправлять эту ситуацию и стараться выкладывать полезный контент чаще 😊 PSS Ваши реакции мотивируют меня на новые посты 🔥

Индексы в БД на пальцах На последних нескольких интервью, к моему удивлению, кандидаты не смогли внятно ответить на вопрос, что такое индекс в бд. Поэтому хочу привести несколько базовых тезисов и в конце - довольно интересную статью с Хабра, где рассказано о разных типах индексов. 🔹 Что такое индекс? Это вспомогательная структура данных, которая создается средствами СУБД и хранит информацию о расположении (или адресе) строки в таблице с некоторым значением поля. Индексы строятся для каждого поля отдельно: можно построить по индексу на каждое поле таблицы, если в этом есть необходимость. 🔹 Зачем нужны индексы? Для ускорения поиска. Без индекса СУБД вынуждена перебирать все строки в таблице в поисках нужной; индекс позволяет быстро узнать местоположение этой строки и перейти сразу к ней. Аналог из жизни - статья в журнале или глава из книги: вместо того, чтобы перелистывать все страницы, вы ищете название в оглавлении и переходите к нужной странице. 🔹 Как работают индексы? Индексы можно упрощенно представить себе как отсортированные копии полей (столбцов таблицы). Поиск значения в отсортированной структуре происходит очень быстро - вы быстрее найдете старницу номер 742 в книге из 1000 страниц, чем бубновую девятку в перетасованной колоде карт, потому что карты нужно перебирать, а номера страниц отсортированы. Найдя значение поля в индексе, СУБД получит информацию об адресе всей строки таблицы (которая там была сохранена при создании индекса), то есть "перейдет по номеру страницы", если сравнивать с книгами. 🔹Минусы и особенности. Помимо очевидноно плюса в виде ускорения поиска, есть ряд особенностей, которые нужно иметь ввиду. 1. Индексы - это дополнительные структуры данных, которые нужно хранить, следовательно, они занимают дисковое пространство, особенно это важно учитывать при работе с большими таблицами (хотя именно там они наиболее эффективны). 2. Если мы меняем значения в таблице (включая добавление и удаление строк), то это будет происходить в двух местах: в самой таблице и в индексе, то есть у нас немного замедляется модификация таблиц. Для задач с большим количеством изменений это может быть ощутимо. 3. Неправильно выбранный тип индекса может замедлить поиск. Например, индексы в виде деревьев неэффективны для столбцов с низкой мощностью множества* 🔹Когда использовать индексы? Строить индексы нужно только по тем полям, по которым осуществляется поиск. Идеальный случай - данные в таблице меняются редко, а запрашиваются часто. Контрпример - таблица, которая представляет собой журнал аудита, куда данные пишутся постоянно всей системой, а читаются только в случае инцидентов и нет высоких требований к скорости поиска. В этом случае использование индекса только навредит: будет тратиться лишнее дисковое пространство и запись будет чуть медленнее. * Мощность множества или Cardinality - это характеристка, показывающая уникальность данных, входящих в множество. Если у нас есть миллион строк для поля Gender, которые содержат только значения Male и Female, то говорят, что у такого множества низкая мощность. А поле Email с уникальными данными будет иметь высокую мощность. Подробнее о типах индексов можно почитать в этой статье на хабре #СУБД #собеседование

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

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