{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Slavlotski",
    "_rss_description": "Меня зовут Влад и я Data Engineer. В свободное от работы время люблю писать электронную музыку, играть в видеоигры",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/slavlotski.com\/",
    "feed_url": "https:\/\/slavlotski.com\/rss\/",
    "icon": "https:\/\/slavlotski.com\/pictures\/userpic\/userpic@2x.jpg?1696305806",
    "authors": [
        {
            "name": "Slavlotski",
            "url": "https:\/\/slavlotski.com\/",
            "avatar": "https:\/\/slavlotski.com\/pictures\/userpic\/userpic@2x.jpg?1696305806"
        }
    ],
    "items": [
        {
            "id": "29",
            "url": "https:\/\/slavlotski.com\/all\/slavlotski-podcast-episode-2-aleksey-dral-pro-data-engineering\/",
            "title": "Slavlotski Podcast Episode #2. Алексей Драль про Data Engineering",
            "content_html": "<p>Во втором выпуске моего подкаста вместе с <a href=\"https:\/\/www.linkedin.com\/in\/alexey-dral\/\">Алексеем Дралем <\/a>— основателем BigData Team, ex-Яндекс, ex-Amazon, ex-Сбер, ex-Рамблер, выпускником ШАД обсудили: кто такой дата-инженер, чем он полезен бизнесу, почему важен навык System Design, чем специалисты уровня Senior отличаются от Staff+, как AI-трансформация затронет роль дата-инженера и как быть junior-специалистам в такое непростое время. Приятного просмотра!<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/TthBs0LncA0?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2026-04-04T17:46:42+05:00",
            "date_modified": "2026-04-04T17:46:06+05:00",
            "tags": [
                "DataScience",
                "IT",
                "Podcasting",
                "Дата инженерия"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/remote\/youtube-TthBs0LncA0-cover.jpg",
            "_date_published_rfc2822": "Sat, 04 Apr 2026 17:46:42 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "29",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-TthBs0LncA0-cover.jpg"
                ]
            }
        },
        {
            "id": "28",
            "url": "https:\/\/slavlotski.com\/all\/slavlotski-podcast-episode-1-andrey-shadrikov-pro-computer-visio\/",
            "title": "Slavlotski Podcast Episode #1. Андрей Шадриков про Computer Vision",
            "content_html": "<p>На днях вместе с <a href=\"https:\/\/www.linkedin.com\/in\/andrei-shadrikov\/\">Андреем Шадриковым<\/a> записали подкаст, где поговорили о компьютерном зрении, о применении его в бизнесе, включая антифрод, удаленную верификацию, проблему с дипфейками. Обсудили как работает CV в беспилотных автомобилях, затронули роботехнику и какие вызовы перед ней стоят.<\/p>\n<p>Для меня — это первый опыт записи такого рода подкастов, особенно было интересно его монтировать, делать обложку, цветокоррекцию и т. п. технические штуки. Буду рад если вы поделитесь обратной связью, понравилось вам или нет. Приятного просмотра.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/1Tf4UBvLPfs?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2026-02-28T16:36:02+05:00",
            "date_modified": "2026-02-28T16:35:44+05:00",
            "tags": [
                "Computer Vision",
                "DataScience",
                "IT",
                "ML",
                "Podcasting",
                "Анализ Данных"
            ],
            "_date_published_rfc2822": "Sat, 28 Feb 2026 16:36:02 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "28",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": []
            }
        },
        {
            "id": "27",
            "url": "https:\/\/slavlotski.com\/all\/kolesa-conf-2025\/",
            "title": "Выступление на Kolesa Conf 2025 в Казахстане",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Vladislav-Zabolockiy-Data.png\" width=\"1280\" height=\"720\" alt=\"\" \/>\n<\/div>\n<p>11 октября в Алматы состоялась крупная IT конференция <a href=\"https:\/\/kolesa-conf.kz\">Kolesa conf 2025<\/a> c более чем 1600 участниками, 50+ экспертами. На ней я выступил с адаптированным под местную аудиторию докладом про миграцию SAS платформы на новую дата платформу. Если вы хотите быстро погрузиться в суть доклада и узнать инсайты, то этот доклад как раз для вас. Если же вы хотите более расширенную и детальную версию, то я рекомендую посмотреть доклад с <a href=\"https:\/\/slavlotski.com\/all\/datainternals-conf-2025\">DataInternals 2025<\/a><\/p>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"1280\" data-ratio=\"1.5005861664713\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/photo_2025-12-20-01.51.54.jpeg\" width=\"1280\" height=\"853\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1291.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1293.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_1325.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1295.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1039.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1205.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/DSC-1206.JPG\" width=\"1707\" height=\"2560\" alt=\"\" \/>\n<\/div>\n<div class=\"e2-text-caption\">Немного фоток с мероприятия<\/div>\n<\/div>\n<p>В целом я уже 3 раз подряд посещаю Kolesa Conf, ощущаю себя уже как в своей тарелке, так как много знакомых лиц, понятные активности и движ, нетворкинг и новые знакомства. Kolesa Group задали высокую планку по организации конференций, если вы думаете как-то посетить в качестве спикера или обычного участника, то это одна из лучших IT конференций в Казахстане.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/X1ghoCYIEK8?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Запись доклада<\/div>\n<\/div>\n",
            "date_published": "2025-12-26T13:03:10+05:00",
            "date_modified": "2025-12-26T13:03:07+05:00",
            "tags": [
                "IT",
                "Анализ Данных",
                "Дата инженерия",
                "Конференция"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/Vladislav-Zabolockiy-Data.png",
            "_date_published_rfc2822": "Fri, 26 Dec 2025 13:03:10 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "27",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/fotorama\/fotorama.css",
                    "system\/library\/fotorama\/fotorama.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/Vladislav-Zabolockiy-Data.png",
                    "https:\/\/slavlotski.com\/pictures\/photo_2025-12-20-01.51.54.jpeg",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1291.JPG",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1293.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_1325.JPG",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1295.JPG",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1039.JPG",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1205.JPG",
                    "https:\/\/slavlotski.com\/pictures\/DSC-1206.JPG",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-X1ghoCYIEK8-cover.jpg"
                ]
            }
        },
        {
            "id": "26",
            "url": "https:\/\/slavlotski.com\/all\/datainternals-conf-2025\/",
            "title": "Как я сходил на DataInternals Conf 2025",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/datainternals-2025.png.jpg\" width=\"2560\" height=\"2560\" alt=\"\" \/>\n<\/div>\n<p>Всем привет! В этом году я открыл для себя новое направление развития — <b>спикерство<\/b>. 23 сентября 2025 года в Москве состоялась первая конференция по инженерии данных <a href=\"https:\/\/datainternals.ru\">DataInternals<\/a> от оператора <a href=\"https:\/\/ontico.ru\">Онтико<\/a>.<\/p>\n<p>Конференция собрала 275 офлайн-участников и около 100 онлайн-зрителей. В программе было 30 докладов, 2 круглых стола и 1 мастер класс. Фото с мероприятия можно посмотреть <a href=\"https:\/\/vk.com\/album-228253760_304965389\">здесь<\/a>.<\/p>\n<p>На ней мне посчастливилось выступить с докладом <b>«Как подготовить платформу данных к миграции уже сейчас?»<\/b>, где поделился опытом проекта миграции платформы данных SAS на новую дата платформу на базе open-source стека DataLake + GreenPlum.<\/p>\n<p>В рамках проекта я участвовал в качестве SAS разработчика, где помогал платформенной команде:<br \/>\n— лидировать стрим по миграции пользователей на целевые системы;<br \/>\n— разрабатывать чатбота для ускорения коммуникации с пользователями;<br \/>\n— переносить бизнес процессы на новую дата платформу;<br \/>\n— искать и размечать владельцев данных;<br \/>\n— строить аналитику динамики миграции;<br \/>\n— поддерживать функционал, сервисы платформы в рабочем состоянии<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/mxVD8UysOA0?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Запись моего доклада. Подписывайтесь на мой YouTube канал 😉<\/div>\n<\/div>\n<p>После доклада я получил множество вопросов в дискуссионной зоне и тёплые отзывы от коллег из Райфа, присутствовавших на конференции. Средняя оценка NPS от слушателей доклада составила <b>4.47 из 5<\/b>, что достаточно крутой результат для первого выступления.<\/p>\n<p>Помимо собственного доклада, удалось пообщаться и послушать ребят из разных «жёлтых», «зелёных» и «красных» банков 😁 Сложилось ощущение, что все движутся примерно в одном направлении — кто-то быстрее, кто-то чуть медленнее.<br \/>\nКонфа не осталась без добрых дел, так как мне получилось помочь добраться до дома одному DevRel из «красного» банка.<\/p>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"2560\" data-ratio=\"1.4997070884593\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0815.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0813.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0814.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0817.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0818.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/IMG_0819.JPG\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<\/div>\n<div class=\"e2-text-caption\">Немного фотографий с конфы<\/div>\n<\/div>\n<p>В целом это был классный опыт. Подготовка заняла несколько месяцев — начал работать над докладом ещё в феврале, многократно переделывал презентацию, работал над текстом, собирал ОС со стороны коллег, проводил десятки прогонов как в онлайн, так и в офлайн-формате. Этот опыт показал мне, что публичные выступления — отличный способ структурировать знания, презентации достижений большой команды, взглянуть на свою работу со стороны.<\/p>\n",
            "date_published": "2025-10-30T00:01:57+05:00",
            "date_modified": "2025-10-29T00:21:17+05:00",
            "tags": [
                "IT",
                "Анализ Данных",
                "Дата инженерия",
                "Конференция"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/datainternals-2025.png.jpg",
            "_date_published_rfc2822": "Thu, 30 Oct 2025 00:01:57 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "26",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js",
                    "system\/library\/fotorama\/fotorama.css",
                    "system\/library\/fotorama\/fotorama.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/datainternals-2025.png.jpg",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0815.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0813.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0814.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0817.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0818.JPG",
                    "https:\/\/slavlotski.com\/pictures\/IMG_0819.JPG"
                ]
            }
        },
        {
            "id": "25",
            "url": "https:\/\/slavlotski.com\/all\/obzor-sony-wf-1000xm5\/",
            "title": "Обзор Sony WF-1000XM5",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/photo_2025-08-02-13.24.34.jpeg\" width=\"1200\" height=\"760\" alt=\"\" \/>\n<\/div>\n<p>Сколько я слышал историй о выпавших AirPods в московском метро, столько же я себя отговаривал от покупки наушников-затычек, но по некоторым обстоятельствам я был вынужден временно отказаться от полноразмерных наушников, поэтому сегодня я поделюсь своим мнением о модели WF-1000XM5 от Sony 🎧<br \/>\n<b>Начну с плюсов:<\/b><br \/>\n1) Качество звучания. Боже как же круто когда есть фирменная приложуха с возможностью настроить эквалайзер (Привет, Apple), я настолько преуспел, что они сейчас звучат также как полноразмерные, а то и лучше. Любой жанр раскрывается полными красками, стереополе представлено замечательно, насыщенные басы, высокая детализация.<br \/>\n2) Звукоизоляция. Даже без шумоподавления они круто глушат звук, а в самолете ты комфортно проводишь время даже не замечая гул двигателей и окружающих.<br \/>\n3) Посадка и амбушюры. Я переживал, что при длительном ношении мне будет дискомфортно, а ношу наушники чуть ли не 24 на 7, но я был удивлен, подобрав нужный размер амбушюр (их в комплекте 3-4 пар), как они хорошо сели, плюс большое преимущество, что по сравнению с полноразмерными, при длительном ношении может потеть голова, а тут разумеется такого нет.<br \/>\n4) Микрофон. Многие модели затычки грешат ужасным звуком микрофона, но судя по реакции окружающих Sony завезли нормальный, для членораздельной речи, микрофон.<br \/>\n5) Цена. Сейчас выкатывается новая  6 серия модели, поэтому 5 серия активно теряет в цене. Мне удалось их приобрести за 15к рублей.<br \/>\n<b>Минусы:<\/b><br \/>\n1) Зарядка. Да, держат они 6-7 часов беспрерывного использования, потом клади их в кейс и жди пока зарядятся, но благо это происходит быстро.<br \/>\n2) Помехи. Периодически происходит потеря сигнала или помехи по Bluetooth, ощущается это как искажение звуков в музыкальных треках то в одном наушнике, то в другом, а то и вовсе звук пропадает на 1-2 секунды.<br \/>\n3) Загрязнения. На амбушюрах часто остается ушная сера и без влажной салфетки от нее сложно избавиться.<br \/>\n4) Риск выпадения. Да, об этом всегда стоит помнить и поправлять наушники особенно если вы в движении.<\/p>\n<p><b>Итоги:<\/b><br \/>\nНесмотря на минусы я рекомендую их к приобретению<br \/>\nособенно ауодифилам, Sony сделали крутые флагманские наушники, они подарили новый опыт использования девайсов, теперь я и не хочу возвращаться к полноразмерным.<\/p>\n",
            "date_published": "2025-08-02T13:32:04+05:00",
            "date_modified": "2025-08-02T13:32:01+05:00",
            "tags": [
                "Музыка",
                "Наушники",
                "Обзор"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/photo_2025-08-02-13.24.34.jpeg",
            "_date_published_rfc2822": "Sat, 02 Aug 2025 13:32:04 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "25",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/photo_2025-08-02-13.24.34.jpeg"
                ]
            }
        },
        {
            "id": "24",
            "url": "https:\/\/slavlotski.com\/all\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur\/",
            "title": "Книга: Основы инженерии данных. Глава 3. Проектирование хорошей дата архитектуры",
            "content_html": "<h2><b>Enterprise архитектура<\/b><\/h2>\n<p>Enterprise архитектура включает подмножество архитектур, таких как бизнес-архитектура, техническая, архитектура приложения и архитектура данных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur.png\" width=\"1142\" height=\"268\" alt=\"\" \/>\n<\/div>\n<p><b>Enterprise архитектура<\/b> — это проектирование систем для поддержки изменений в организации, достигаемое за счет гибких и обратимых решений, принятых на основе тщательной оценки компромиссов.<\/p>\n<p>Гибкие и обратимые решения необходимы по двум причинам. Во-первых, мир постоянно меняется, и предсказать будущее невозможно. Обратимые решения позволяют корректировать курс по мере изменений в мире и получения новой информации. Во-вторых, существует естественная тенденция к утрате гибкости организации по мере ее роста. Принятие культуры обратимых решений помогает преодолеть эту тенденцию, снижая риски, связанные с принятием решений.<\/p>\n<p>Джеффу Безосу приписывают идею «дверей в один и два конца». Дверь в один конец — это решение, которое почти невозможно отменить. Например, Amazon мог бы продать AWS или закрыть его. После такого шага восстановить облачный сервис с той же рыночной позицией было бы практически невозможно. С другой стороны, дверь в два конца — это легко обратимое решение: можно войти, оценить ситуацию и либо продолжить движение вперед, либо вернуться обратно, если результат не устраивает.<\/p>\n<p>Управление изменениями тесно связано с обратимыми решениями и является центральной темой в рамках архитектуры компании. Даже при акценте на обратимые решения организации часто вынуждены реализовывать крупные инициативы. В идеале их следует разбивать на более мелкие изменения, каждое из которых само по себе является обратимым решением.<\/p>\n<p>Архитекторы выявляют проблемы в текущем состоянии (низкое качество данных, ограничения масштабируемости), определяют желаемые будущие состояния (гибкое улучшение качества данных, масштабируемые облачные решения, оптимизированные бизнес-процессы) и реализуют инициативы через выполнение небольших, конкретных шагов.<br \/>\nВажно подчеркнуть, что технические решения должны поддерживать бизнес-цели, а архитектура организации должна балансировать между гибкостью и необходимыми компромиссами для достижения оптимальных результатов.<\/p>\n<h2><b>Архитектура данных<\/b><\/h2>\n<p><b>Архитектура данных <\/b> — это проектирование систем для поддержки изменяющихся потребностей организации в данных, достигаемое за счет гибких и обратимых решений, принятых на основе тщательной оценки компромиссов.<\/p>\n<p>Операционная архитектура охватывает функциональные требования к тому, что должно происходить в отношении людей, процессов и технологий.<br \/>\nТехническая архитектура определяет, как данные загружаются, хранятся, преобразуются и предоставляются на протяжении жизненного цикла работы с данными.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-1.png\" width=\"1114\" height=\"274\" alt=\"\" \/>\n<\/div>\n<h2><b>«Хорошая» архитектура данных<\/b><\/h2>\n<p>Хорошая архитектура данных обслуживает бизнес-требования с помощью общего, широко переиспользуемого набора строительных блоков, сохраняя гибкость и находя правильные компромиссы. Плохая архитектура авторитарна и пытается втиснуть множество универсальных решений в хаотичную и неуправляемую систему.<\/p>\n<p>Гибкость — основа хорошей архитектуры данных, поскольку благодаря ей мы можем быстро адаптироваться в вечно меняющейся окружающей среде. Хорошая архитектура данных остается адаптивной и легко поддерживаемой. Она развивается в ответ на изменения в бизнесе, а также на появление новых технологий и практик, которые могут открыть ещё большую ценность для бизнеса в будущем.<\/p>\n<p>Плохая архитектура данных отличается сильной связностью, жёсткостью, чрезмерной централизацией или использованием неподходящих инструментов, что затрудняет разработку и управление изменениями.<\/p>\n<p><b>Принципы хорошей архитектуры данных<\/b><br \/>\nФреймворк AWS Well-Architected состоит из шести ключевых принципов:<br \/>\n— Операционное совершенство<br \/>\n— Безопасность<br \/>\n— Надёжность<br \/>\n— Эффективность производительности<br \/>\n— Оптимизация затрат<br \/>\n— Устойчивость<\/p>\n<p>Пять принципов облачно-нативной архитектуры Google Cloud:<br \/>\n— Проектируйте для автоматизации.<br \/>\n— Грамотно управляйте состоянием.<br \/>\n— Отдавайте предпочтение управляемым сервисам.<br \/>\n— Применяйте многоуровневую защиту.<br \/>\n— Постоянно улучшайте архитектуру<\/p>\n<p>Мы хотели бы дополнить и расширить эти принципы, добавив ключевые принципы архитектуры инженерии данных:<br \/>\n— Осознанный выбор общих компонентов<br \/>\n— Планирование на случай отказов<br \/>\n— Проектируйте с учётом масштабируемости<br \/>\n— Архитектура — это лидерство<br \/>\n— Постоянно улучшайте архитектуру<br \/>\n— Стройте слабо связанные системы<br \/>\n— Принимайте обратимые решения<br \/>\n— Приоритизируйте безопасность<br \/>\n— Используйте принципы FinOps<\/p>\n<p><b>Принцип 1: Осознанный выбор общих компонентов<\/b><br \/>\nКогда архитекторы принимают взвешенные решения и эффективно руководят, общие компоненты становятся основой для совместной работы команд и устранения изолированных процессов. Они способствуют гибкости внутри и между командами, объединяя общие знания и навыки. Общие компоненты могут включать любое широко применимое решение в организации, например:<br \/>\n— Объектное хранилище<br \/>\n— Системы контроля версий<br \/>\n— Инструменты наблюдаемости и мониторинга<br \/>\n— Системы оркестрации<br \/>\n— Движки обработки данных<br \/>\nОблачные платформы являются идеальной средой для внедрения таких компонентов.<\/p>\n<p><b>Принцип 2: Планирование на случай отказов<\/b><br \/>\nКлючевые термины:<br \/>\n1) <b>Доступность<\/b> — процент времени, в течение которого ИТ-сервис или компонент находится в рабочем состоянии.<br \/>\n2) <b>Надёжность<\/b> — вероятность того, что система будет соответствовать установленным стандартам и выполнять свои функции в течение заданного интервала времени.<br \/>\n3) <b>RTO<\/b> (Recovery time objective, «целевое время восстановления») — максимально допустимое время простоя сервиса или системы. Например, один день простоя может быть допустимым для внутренней отчётности, но даже пять минут простоя могут серьёзно повлиять на бизнес интернет-ритейлера.<br \/>\n4) <b>RPO<\/b> (Recovery Point Objective, «цель точки восстановления») — максимально допустимый объём потерянных данных после сбоя. Время восстановления файлов из резервного хранилища не должно превышать RPO. Например, если RPO составляет 90 минут, то данные, накопленные за последние полтора часа, будут потеряны. Соответственно, снимок (snapshot) должен выполняться не реже одного раза в 90 минут. Резервное копирование может включать не только файлы на дисках, но и настройки приложений, параметры операционной системы сервера, а также состояние процессов в оперативной памяти.<\/p>\n<p><b>Принцип 3: Проектирование с учётом масштабируемости<\/b><br \/>\nМасштабируемость в системах данных включает два ключевых аспекта:<\/p>\n<ol start=\"1\">\n<li>Система должна уметь масштабироваться вверх для обработки больших объёмов данных.<\/li>\n<li>Система должна масштабироваться вниз, автоматически снижая ресурсы после спада нагрузки для оптимизации затрат.<br \/>\nИдеальная система должна динамически адаптироваться к нагрузке в автоматическом режиме.<\/li>\n<\/ol>\n<p><b>Принцип 4: Архитектура — это лидерство<\/b><br \/>\nАрхитекторы данных несут ответственность за технологические решения, разработку архитектурных артефактов и распространение решений через лидерство и обучение.<br \/>\nИдеальный архитектор данных:<br \/>\n— Обладает техническими навыками инженера данных, но не занимается ежедневными инженерными задачами.<br \/>\n— Наставляет инженеров, консультируется с организацией при выборе технологий.<br \/>\n— Распространяет знания через обучение и управление процессами.<br \/>\n— Объединяет ресурсы компании для достижения общих целей в технологиях и бизнесе.<\/p>\n<p><b>Принцип 5: Постоянно улучшайте архитектуру<\/b><br \/>\nРабота архитектора включает три основные задачи:<br \/>\n— Глубокое понимание текущей архитектуры.<br \/>\n— Разработка целевой архитектуры.<br \/>\n— Создание плана перехода с приоритизацией изменений<\/p>\n<p><b>Принцип 6: Построение слабо связанных систем<\/b><br \/>\nСистемы должны быть спроектированы так, чтобы команды могли тестировать, развертывать и изменять их без зависимости от других команд. Это снижает необходимость в сложной коммуникации.<br \/>\nПризнаки слабо связанных систем:<\/p>\n<ol start=\"1\">\n<li>Разделение на множество небольших компонентов.<\/li>\n<li>Взаимодействие между сервисами через уровни абстракции (например, API или шину сообщений), скрывающие внутренние детали.<\/li>\n<li>Изменения в одном компоненте не требуют изменений в других.<\/li>\n<li>Отсутствие глобального цикла релизов — каждый компонент обновляется независимо.<\/li>\n<\/ol>\n<p><b>Принцип 7: Принятие обратимых решений<\/b><br \/>\nВ условиях быстрой эволюции технологий и модульной архитектуры всегда выбирайте лучшие решения на текущий момент, но будьте готовы адаптироваться по мере появления новых решений.<\/p>\n<p><b>Принцип 8: Приоритизация безопасности<\/b><br \/>\nКаждый инженер данных должен нести ответственность за безопасность создаваемых и поддерживаемых систем. Два ключевых подхода:<br \/>\n— Модель нулевого доверия (Zero Trust) — проверка и защита на всех уровнях доступа.<br \/>\n— Модель разделённой ответственности — распределение обязанностей между облачным провайдером и пользователями.<\/p>\n<p><b>Принцип 9: Применение FinOps<\/b><br \/>\n<b>FinOps<\/b> — это подход к финансовому управлению облачными затратами, объединяющий инженеров, финансы и бизнес для принятия решений на основе данных.<\/p>\n<p>Ранее инженеры данных ориентировались на производительность: максимизация скорости обработки на фиксированном количестве ресурсов.<br \/>\nС появлением FinOps важно учитывать и стоимость:<br \/>\n— Какой баланс между AWS Spot Instance при запуске распределённого кластера?<br \/>\n— Какая модель расчёта (pay-per-query vs. reserved capacity) будет выгоднее в долгосрочной перспективе<br \/>\n— Как достичь оптимального соотношения между стоимостью и производительностью при выполнении больших задач?<\/p>\n<h2><b>Основные архитектурные концепции<\/b><\/h2>\n<p><b>Домен и сервисы<\/b><br \/>\nДомен — это предметная область реального мира, для которой создаётся архитектура. Сервис — это набор функций, предназначенных для выполнения определённой задачи. Один домен может включать несколько сервисов. Например, в домене продаж могут быть три сервиса: заказы, выставление счетов и товары. Каждый из них выполняет определённые задачи, поддерживающие общий процесс продаж.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-2.png\" width=\"1118\" height=\"392\" alt=\"\" \/>\n<\/div>\n<p>При определении границ домена сосредоточьтесь на том, что он представляет в реальном мире.<\/p>\n<h2><b>Распределенные системы, масштабируемость, проектирование случаев отказа<\/b><\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-3.png\" width=\"1130\" height=\"398\" alt=\"\" \/>\n<\/div>\n<p>Мы как инженеры данных рассматриваем четыре тесно связанных характеристик систем обработки данных:<br \/>\n— <b>Масштабируемость<\/b> (Scalability) — возможность увеличивать ёмкость системы для повышения производительности и обработки возросшей нагрузки. Например, нам может потребоваться масштабировать систему, чтобы справляться с высоким количеством запросов или обрабатывать огромные объёмы данных.<br \/>\n— <b>Эластичность<\/b> (Elasticity) — способность масштабируемой системы динамически адаптироваться. Высокоэластичная система может автоматически увеличивать или уменьшать ресурсы в зависимости от текущей нагрузки. Масштабирование вверх критично при росте спроса, а масштабирование вниз помогает снизить затраты в облачной среде. Современные системы иногда могут масштабироваться до нуля, полностью отключаясь при отсутствии нагрузки.<br \/>\n— <b>Доступность<\/b> (Availability) — процент времени, в течение которого IT-сервис или компонент находится в работоспособном состоянии.<br \/>\n— <b>Надёжность<\/b> (Reliability) — вероятность того, что система выполнит свои функции в соответствии с заданными стандартами в течение определённого промежутка времени.<\/p>\n<p>Распределённые системы широко используются в различных технологиях обработки данных, которые вы будете использовать в своей архитектуре. Почти каждое облачное хранилище данных или объектное хранилище содержит под капотом механизмы распределения.<\/p>\n<h2><b>Жёсткая vs. Слабая Связанность: Уровни, Монолиты и Микросервисы<\/b><\/h2>\n<p>На одном конце можно выбрать <b>крайне централизованные зависимости<\/b> и процессы, где каждая часть домена и сервиса критически зависит от всех остальных доменов и сервисов. Такой подход называется <b>жёсткой (тесной) связанностью<\/b> (tightly coupled).<\/p>\n<p>На другом конце находятся <b>децентрализованные домены и сервисы<\/b>, которые не имеют строгих зависимостей друг от друга. Этот подход называется <b>слабой (разряженной) связанностью<\/b> (loosely coupled). В такой архитектуре независимые команды могут легко разрабатывать системы, но их данные могут оказаться несовместимыми или малополезными для коллег из других команд.<\/p>\n<p><b>Уровни Архитектуры<\/b><br \/>\nПри разработке архитектуры важно учитывать её уровни. Архитектура состоит из различных слоёв — данных, приложений, бизнес-логики, представления и необходимо понимать, как их разделять.<br \/>\nЖёсткая связанность между уровнями создаёт уязвимости, поэтому при проектировании следует стремиться к максимальной надёжности и гибкости за счёт правильной организации и разделения слоёв.<\/p>\n<p><b>Одноуровневая (Single-Tier) Архитектура<\/b><br \/>\nВ одноуровневой архитектуре база данных и приложение<b> тесно связаны<\/b> и находятся на <b>одном сервере.<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-4.png\" width=\"1114\" height=\"284\" alt=\"\" \/>\n<\/div>\n<p><b>Многоуровневая (Multitier, N-Tier) Архитектура<\/b><br \/>\nМногоуровневая архитектура (также известная как <b>n-уровневая<\/b>) состоит из <b>отдельных слоёв<\/b>: данных, приложения, бизнес-логики, представления  и т. д. Эти слои организованы <b>иерархически<\/b>, то есть нижние слои не зависят от верхних, но верхние зависят от нижних.<\/p>\n<p>Основная идея такой архитектуры — <b>разделение данных, приложения и пользовательского интерфейса.<\/b><\/p>\n<p>Один из самых распространённых видов многоуровневой архитектуры — <b>трёхуровневая (three-tier) <\/b>архитектура, которая используется в клиент-серверных системах. Она включает три уровня:<\/p>\n<ol start=\"1\">\n<li><b>Уровень данных (Data Tier) <\/b>— хранение и управление данными.<\/li>\n<li><b>Уровень логики (Application Tier) <\/b>— обработка данных и выполнение бизнес-логики.<\/li>\n<li><b>Уровень представления (Presentation Tier)<\/b> — интерфейс пользователя, взаимодействие с системой.<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-5.png\" width=\"1112\" height=\"444\" alt=\"\" \/>\n<\/div>\n<p><b>Монолиты и Микросервисы<\/b><br \/>\n<b>Монолиты (Monoliths)<\/b><br \/>\nСвязанность внутри монолитных систем можно рассматривать с двух точек зрения:<\/p>\n<ol start=\"1\">\n<li><b>Техническая связанность<\/b> (Technical Coupling) — относится к архитектурным уровням (tiers).<\/li>\n<li><b>Доменная связанность<\/b> (Domain Coupling) — описывает, как домены взаимосвязаны друг с другом.<\/li>\n<\/ol>\n<p>Монолитная архитектура может иметь <b>различные степени связанности<\/b> между технологиями и доменами. Например, приложение может быть организовано по <b>многоуровневому (multitier) принципу<\/b>, но при этом всё равно содержать <b>жёстко связанные домены<\/b>.<\/p>\n<p><b>Микросервисы (Microservices)<\/b><br \/>\nМикросервисная архитектура состоит из<b> раздельных, децентрализованных и слабо связанных сервисов.<\/b><br \/>\n— Каждый сервис выполняет<b> конкретную функцию<\/b> и <b>не зависит <\/b>от других сервисов в своём домене.<br \/>\n— Если один сервис <b>временно выходит из строя<\/b>, это не нарушает работу остальных сервисов.<br \/>\n— Такая архитектура обеспечивает <b>гибкость, масштабируемость<\/b> и <b>отказоустойчивость<\/b> по сравнению с монолитными системами.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-6.png\" width=\"1114\" height=\"564\" alt=\"\" \/>\n<\/div>\n<p><b>Соображения по архитектуре данных<\/b><br \/>\nВместо того чтобы <b>слепо<\/b> утверждать, что микросервисы лучше монолитов (и наоборот), лучше действовать исходя из практических соображений, стремиться к слабой связанности, учитывая ограничения технологий, используемых в вашей архитектуре данных.<br \/>\nИспользуйте <b>обратимые технологические решения<\/b>, которые позволяют создавать <b>модульные<\/b> и <b>слабо связанные<\/b> системы <b>где это возможно<\/b>.<br \/>\n<b>Два подхода к управлению данными<\/b><\/p>\n<ol start=\"1\">\n<li><b>Централизация (Centralization)<\/b>  <br \/>\n— Одна команда отвечает за сбор данных из всех доменов, их согласование и подготовку для потребления всей организацией.  <br \/>\n— Это традиционный подход, используемый в классических хранилищах данных (Data Warehouses).<\/li>\n<li><b>Data Mesh<\/b><br \/>\n— <b>Каждая команда<\/b>, занимающаяся разработкой ПО, <b>самостоятельно<\/b> подготавливает свои данные для использования в организации.<br \/>\n— Подход основан на <b>децентрализации<\/b> и позволяет <b>лучше масштабировать<\/b> архитектуру данных<\/li>\n<\/ol>\n<p><b>Single vs Multitenant Access<\/b><br \/>\nВ многоарендной (multitenant) архитектуре важно учитывать два ключевых аспекта: <b>производительность<\/b> и <b>безопасность<\/b>.<br \/>\n— <b>Производительность<\/b>: если несколько крупных арендаторов (tenants) используют облачную систему, сможет ли она обеспечивать стабильную работу для всех? Или возникнет проблема «шумного соседа», когда активное использование одним арендатором ухудшает производительность для других?<br \/>\n— <b>Безопасность<\/b>: данные различных арендаторов должны быть надёжно изолированы, чтобы исключить утечки или несанкционированный доступ.<\/p>\n<p><b>Событийно-ориентированная архитектура (Event-Driven Architecture)<\/b><br \/>\nБизнес-процессы редко бывают статичными: постоянно происходят события — например, регистрация нового клиента, оформление заказа или обновление статуса товара.<br \/>\nСобытие (event) в этом контексте — это фиксирование <b>изменения состояния<\/b> чего-либо.<br \/>\nСобытийно-ориентированный рабочий процесс (workflow) включает три ключевых этапа:<br \/>\n1.\t<b>Создание событий (Event Production)<\/b> — генерация событий системой.<br \/>\n2.\t<b>Маршрутизация событий (Event Routing) <\/b>— передача событий в нужные компоненты системы.<br \/>\n3.\t<b>Потребление событий (Event Consumption) <\/b>— обработка событий различными сервисами.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-7.png\" width=\"1110\" height=\"214\" alt=\"\" \/>\n<\/div>\n<p><b>Событийно-ориентированная архитектура<\/b> опирается на событийный workflow и использует его для связи между различными сервисами. Преимущество event-driven архитектуры заключается в том, что она распределяет состояние события между несколькими сервисами.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-8.png\" width=\"1118\" height=\"346\" alt=\"\" \/>\n<\/div>\n<p><b>Brownfield vs. Greenfield проекты<\/b><br \/>\nПрежде чем приступить к разработке архитектуры данных, важно определить, начинаете ли вы с нуля или работаете с уже существующей системой.<\/p>\n<p><b>Brownfield проекты<\/b><br \/>\n— Означают модернизацию или реорганизацию существующей архитектуры.<br \/>\n— Ограничены текущими и прошлогодними решениями, что создает дополнительные сложности.<br \/>\n— Требуют детального анализа наследованной системы и понимания, как старые и новые технологии взаимодействуют друг с другом.<br \/>\n— Часто связаны с рефакторингом, миграцией данных и постепенным улучшением архитектуры.<\/p>\n<p><b>Greenfield проекты<\/b><br \/>\n— Начинаются с чистого листа, без ограничений прошлых решений.<br \/>\n— Позволяют выбрать наиболее современные и подходящие технологии.<br \/>\n— Чаще всего проще в реализации, так как отсутствуют технические долги.<br \/>\n— Дают архитекторам и инженерам больше творческой свободы и возможностей для инноваций.<\/p>\n<p>Выбор между <b>brownfield<\/b> и <b>greenfield<\/b> подходом зависит от контекста: если модернизация невозможна или слишком затратна, может быть разумнее начать с нуля. Однако brownfield-проекты часто встречаются в крупных компаниях, где полное обновление инфраструктуры сразу невозможно.<\/p>\n<h2><b>Примеры типов архитектур данных<\/b><\/h2>\n<p>Поскольку архитектура данных — это достаточно абстрактная штука, проще всего ее понимать на конкретных примерах. В этом разделе мы рассмотрим популярные типы архитектур данных.<\/p>\n<p><b>Data Warehouse (Хранилище данных)<\/b><br \/>\n<b>Data Warehouse (DWH)<\/b> — это центральное хранилище данных, используемое для отчетности и аналитики. Данные в хранилище обычно тщательно структурированы и подготовлены для аналитических задач.<\/p>\n<p>Существует два типа архитектуры хранилищ данных:<\/p>\n<ol start=\"1\">\n<li><b>Организационная архитектура DWH<\/b> — ориентирована на структуру бизнеса, процессы и потребности различных команд.<\/li>\n<li><b>Техническая архитектура DWH <\/b>— включает технические аспекты реализации, такие как архитектура MPP (Massively Parallel Processing), схемы хранения данных (звезда, снежинка) и механизмы ETL\/ELT.<\/li>\n<\/ol>\n<p><b>Организационная архитектура DWH<\/b> обладает двумя ключевыми характеристиками:<\/p>\n<ol start=\"1\">\n<li>Разделение OLAP и OLTP<br \/>\n— OLAP (онлайн-аналитическая обработка) и OLTP (онлайн-операционная обработка) выполняют разные задачи.<br \/>\n— Важно отделять аналитическую нагрузку от транзакционных баз данных, чтобы избежать влияния аналитических запросов на производительность бизнес-приложений.<br \/>\n— DWH создается как отдельная физическая система, куда выгружаются данные, что повышает производительность аналитики и снижает нагрузку на продакшн-системы.<\/li>\n<li>Централизованная организация данных:<br \/>\n— Традиционно хранилище данных получает данные из различных систем через процессы ETL (Extract, Transform, Load).<br \/>\n— На этапе <b>Extract<\/b> данные извлекаются из источников (CRM, ERP, базы данных транзакций и др.).<br \/>\n— После этого они проходят обработку и загружаются в хранилище в структурированном виде, удобном для аналитических запросов.<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-9.png\" width=\"1056\" height=\"372\" alt=\"\" \/>\n<\/div>\n<p><b>ETL (Extract, Transform, Load) — традиционный подход, в котором данные:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Extract<\/b> — извлекаются из источников (базы данных, API, файлы).<\/li>\n<li><b>Transform<\/b> — проходят преобразование (очистка, нормализация, агрегация) в промежуточной системе.<\/li>\n<li><b>Load<\/b> — загружаются в хранилище данных в уже структурированном виде.<\/li>\n<\/ol>\n<p><b>ELT (Extract, Load, Transform)<\/b> — современный вариант, особенно популярный в облачных хранилищах:<\/p>\n<ol start=\"1\">\n<li><b>Extract<\/b> — данные извлекаются из источников.<\/li>\n<li><b>Load<\/b> — загружаются в хранилище в «сыром» виде без предварительной обработки.<\/li>\n<li><b>Transform<\/b> — обработка и преобразование выполняются внутри хранилища с помощью его вычислительных мощностей (например, BigQuery, Snowflake, Redshift).<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-10.png\" width=\"1114\" height=\"360\" alt=\"\" \/>\n<\/div>\n<p><b>Cloud Data Warehouse (CDW)<\/b><br \/>\nОблачные хранилища данных (CDW) — это современный вариант традиционных <b>on-premise <\/b>хранилищ, обладающий рядом преимуществ:<br \/>\n— <b>Горизонтальное масштабирование<\/b>— ресурсы добавляются динамически.<br \/>\n— <b>Гибкость и доступность<\/b> — нет необходимости в сложной инфраструктуре.<br \/>\n— <b>Оплата за использование<\/b> — снижает издержки на поддержку серверов.<\/p>\n<p>Популярные CDW-платформы:<br \/>\n— <b>Amazon Redshift <\/b>— первый облачный DWH, ориентирован на MPP (massively parallel processing).<br \/>\n— <b>Google BigQuery<\/b> — полностью управляемое хранилище с serverless-архитектурой.<br \/>\n— <b>Snowflake<\/b> — облачная DWH-платформа с разделением вычислительных и хранилищных ресурсов.<\/p>\n<p><b>Data Mart<\/b><br \/>\nData Mart — это тематическое подмножество данных из хранилища, предназначенное для конкретного отдела (маркетинг, финансы, продажи).<br \/>\nПричины использования Data Mart:<\/p>\n<ol start=\"1\">\n<li><b>Упрощенный доступ к данным<\/b> — аналитики и бизнес-пользователи работают только с нужной информацией.<\/li>\n<li><b>Дополнительная трансформация<\/b> — данные могут обрабатываться с учетом специфики подразделения.<\/li>\n<li><b>Производительность<\/b> — уменьшение объема данных снижает нагрузку на запросы.<\/li>\n<\/ol>\n<p>Data Marts могут строиться двумя основными способами:<br \/>\n— <b>Independently<\/b> — независимо от основного хранилища, получая данные напрямую из источников.<br \/>\n— <b>Dependent<\/b> — на основе центрального DWH, получая из него уже очищенные данные.<\/p>\n<p><b>Связь CDW и Data Marts<\/b><br \/>\nОблачные хранилища часто используются как основа для Data Marts, обеспечивая быстрый доступ к агрегированным данным с учетом специфики различных бизнес-единиц.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-11.png\" width=\"1116\" height=\"362\" alt=\"\" \/>\n<\/div>\n<h2><b>Data Lake и его эволюция<\/b><\/h2>\n<p>Data Lake — это централизованное хранилище, в котором могут находиться данные в <b>сыром виде<\/b> без строгой схемы. Оно поддерживает все виды данных:<br \/>\n— <b>Структурированные<\/b> (таблицы, реляционные базы).<br \/>\n— <b>Полуструктурированные<\/b> (JSON, XML, Parquet).<br \/>\n— <b>Неструктурированные<\/b> (изображения, видео, логи, аудиофайлы)<\/p>\n<p>Плюсы Data Lake:<br \/>\n— Гибкость: не требуется предварительное моделирование схемы.<br \/>\n— Масштабируемость: хранит огромные объемы данных в S3, HDFS<br \/>\n— Поддержка Machine Learning: данные можно использовать для анализа и моделей.<\/p>\n<p>Однако со временем Data Lake стал превращаться в <b>data swamp<\/b> (болото данных), потому что:<br \/>\n— Данные плохо каталогизировались и терялись.<br \/>\n— Отсутствовала явная схема, что затрудняло анализ.<br \/>\n— Не было ACID-транзакций, сложно было обновлять данные.<\/p>\n<p><b>Data Lakehouse<\/b> — гибридное решение. Чтобы исправить недостатки Data Lake, появился<b> Data Lakehouse<\/b>, предложенный <b>Databricks<\/b>.<\/p>\n<p><b> Особенности Data Lakehouse:<\/b><br \/>\n—  <b>ACID-транзакции<\/b> (поддержка изменяемых данных, чего не было в классическом Data Lake).<br \/>\n— <b>Схемы и индексация<\/b> — можно добавлять структурированность, как в DWH.<br \/>\n— <b>Отделение хранения и вычислений<\/b> — данные хранятся в object storage, а обрабатываются SQL-движками (Spark, Trino).<br \/>\n— <b>Универсальность<\/b> — подходит и для аналитики, и для Data Science.<\/p>\n<p><b>Modern Data Stack (MDS) — эволюция аналитической архитектуры<\/b><br \/>\n<b>Modern Data Stack (MDS)<\/b> — это современный подход к построению <b>гибкой, масштабируемой<\/b> и <b>облачной<\/b> <b>аналитической платформы<\/b>, который:<br \/>\n— Упрощает интеграцию данных.<br \/>\n— Использует облачные, plug-and-play сервисы вместо монолитных решений.<br \/>\n— Минимизирует затраты за счет pay-as-you-go.<br \/>\n— Автоматизирует процессы с минимальным кодом (low-code\/no-code).<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-12.png\" width=\"1114\" height=\"234\" alt=\"\" \/>\n<\/div>\n<p>Если раньше стеки данных опирались на дорогие монолитные наборы инструментов, то основная цель современного стека данных — использовать облачные, готовые к подключению, простые в использовании и доступные компоненты для создания модульной и экономически эффективной архитектуры данных. Эти компоненты включают конвейеры данных, хранение, преобразование, управление и контроль данных, мониторинг, визуализацию и исследование данных.<\/p>\n<p><b>Архитектура Lambda<\/b><br \/>\nВ архитектуре Lambda системы работают независимо друг от друга — пакетная обработка, потоковая обработка и слой обслуживания. Исходная система в идеале является неизменяемой и работает по принципу “только добавление”, отправляя данные в два направления для обработки: потоковую и пакетную.<br \/>\nПотоковая обработка предназначена для предоставления данных с минимальной задержкой, которая обычно реализуется на базе NoSQL-базы данных. В пакетном слое данные обрабатываются и трансформируются в таких системах, как хранилище данных, создавая предвычисленные и агрегированные представления данных.<br \/>\nСлой обслуживания объединяет результаты запросов из двух слоев, предоставляя целостный взгляд на данные.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-13.png\" width=\"1112\" height=\"310\" alt=\"\" \/>\n<\/div>\n<p><b>Архитектура Kappa<\/b><br \/>\nВ качестве ответа на недостатки архитектуры Lambda Джей Крепс предложил альтернативу — архитектуру Kappa. Ее основная идея заключается в следующем: почему бы не использовать платформу потоковой обработки в качестве основы для всех этапов работы с данными — их получения, хранения и обслуживания?<\/p>\n<p>Такой подход способствует созданию истинно событийной архитектуры. Потоковая и пакетная обработка могут применяться к одним и тем же данным без лишних сложностей: данные обрабатываются в реальном времени, а для пакетной обработки можно просто воспроизвести большие объемы событий из потока.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-14.png\" width=\"1108\" height=\"234\" alt=\"\" \/>\n<\/div>\n<p>Хотя оригинальная статья об архитектуре Kappa была опубликована в 2014 году, ее широкого распространения пока не наблюдается. Возможно, этому есть несколько причин.<br \/>\nВо-первых, потоковая обработка по-прежнему остается чем-то загадочным для многих компаний: о ней легко говорить, но реализовать на практике сложнее, чем кажется. Во-вторых, архитектура Kappa на деле оказывается сложной и дорогостоящей в использовании.<\/p>\n<p><b>Архитектура The Internet of Things (IoT)<\/b><br \/>\n<b>IoT<\/b> — это распределенная сеть устройств: компьютеров, датчиков, мобильных устройств, умных гаджетов и любого другого оборудования, подключенного к интернету.<br \/>\nВ отличие от данных, вводимых вручную человеком (например, с клавиатуры), данные в IoT генерируются устройствами, которые периодически или непрерывно собирают информацию из окружающей среды и передают ее в целевую систему.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-15.png\" width=\"1114\" height=\"464\" alt=\"\" \/>\n<\/div>\n<p>— <b>Устройства<\/b> — это физическое оборудование, подключенное к интернету, которое отслеживает окружающую среду, собирает данные и передает их в целевую систему.<br \/>\n— <b>Взаимодействие с устройствами<\/b> — IoT-шлюз выступает в роли узла для подключения устройств и безопасной передачи данных в нужные точки в интернете. Хотя можно подключить устройство напрямую, шлюз позволяет устройствам работать с минимальным энергопотреблением.<br \/>\n— <b>Получение данных (Ingestion)<\/b> — Процесс начинается с IoT-шлюза, как упомянуто ранее. Далее события и измерения поступают в архитектуру приема событий.<br \/>\n— <b>Хранение<\/b> — Требования к хранилищу зависят в значительной степени от допустимой задержки в системе IoT.<br \/>\n— <b>Обслуживание (Serving)<\/b> Способы обработки и представления данных сильно различаются. В пакетных приложениях данные могут анализироваться в облачном хранилище и предоставляться в виде отчетов.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-16.png\" width=\"1116\" height=\"268\" alt=\"\" \/>\n<\/div>\n<h2><b>Data Mesh<\/b><\/h2>\n<p><b>Data Mesh<\/b> — это современный подход, предложенный в ответ на разрастающиеся монолитные платформы обработки данных, такие как централизованные озера данных и хранилища, а также на проблему разделения операционных и аналитических данных. Этот подход стремится переосмыслить традиционную централизованную архитектуру, применяя принципы предметно-ориентированного проектирования (Domain-Driven Design), широко используемые в разработке программного обеспечения, к архитектуре данных.<\/p>\n<p>Чтобы избавиться от монолитной централизованной платформы, необходимо изменить подход к данным, их локальности и владению. Вместо того чтобы собирать данные из различных доменов в централизованное озеро данных или платформу, каждый домен должен самостоятельно управлять своими данными и предоставлять их в удобном для использования виде.<\/p>\n<p>Джамак Дегхани выделила четыре ключевых принципа Data Mesh:<br \/>\n— <b>Доменно-ориентированное децентрализованное владение данными и архитектура<\/b><br \/>\n— <b>Данные как продукт<\/b><br \/>\n— <b>Самообслуживаемая инфраструктура данных как платформа<\/b><br \/>\n— <b>Федеративное вычислительное управление<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-17.png\" width=\"1116\" height=\"1044\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2025-04-05T18:12:23+05:00",
            "date_modified": "2025-08-02T13:29:09+05:00",
            "tags": [
                "BigData",
                "Clouds",
                "IT",
                "Инженерияданных",
                "Книги"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur.png",
            "_date_published_rfc2822": "Sat, 05 Apr 2025 18:12:23 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "24",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-1.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-2.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-3.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-4.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-5.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-6.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-7.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-8.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-9.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-10.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-11.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-12.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-13.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-14.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-15.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-16.png",
                    "https:\/\/slavlotski.com\/pictures\/kniga-osnovy-data-inzhenerii-postroenie-horoshey-data-arhitektur-17.png"
                ]
            }
        },
        {
            "id": "21",
            "url": "https:\/\/slavlotski.com\/all\/kniga-osnovy-inzhenerii-dannyh-glava-2-zhiznenny-cikl-data-inzhe\/",
            "title": "Книга: Основы Инженерии данных. Глава 2. Жизненный цикл работы с данными.",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Data-engineering-lifecycle.png\" width=\"1010\" height=\"547\" alt=\"\" \/>\n<\/div>\n<h2><b>Что такое жизненный цикл работы с данными?<\/b><\/h2>\n<p>Жизненный цикл работы с данными содержит этапы, где мы трансформируем сырые данные из источников в финальный, готовый к использованию продукт, которым могут воспользоваться такие специалисты как: дата аналитики, data scientistы, ML инженеры. В данной главе сфокусируемся на каждом этапе, раскроем их главные концепции.<\/p>\n<p>Жизненный цикл работы с данными состоит из:<br \/>\n— генерации данных<br \/>\n— загрузки и сбора данных<br \/>\n— трансформации данных<br \/>\n— предоставлении данных конечным потребителям<\/p>\n<p>Процесс <b>хранения<\/b> данных протекает через весь жизненный цикл работы с данными от самого начала до конца. На диаграмме «1-1» демонстрируется, что этап хранения является ключевым для всех вышестоящих этапов.<\/p>\n<p>Жизненный цикл работы с данными гибок, и его этапы (хранение, сбор, преобразование) не всегда следуют строгому порядку, а могут пересекаться или происходить в разных последовательностях в зависимости от ситуации.<\/p>\n<p>Фундаментом для всего жизненного цикла работы с данными являются следующие аспекты (нижняя часть диаграммы 1-1): безопасность, управление данными, DataOps, архитектура данных, оркестрация, software engineering.<\/p>\n<p>Дата инженер в процессе жизненного цикла работы с данными должен преследовать следующие цели:<br \/>\n— обеспечить максимальную окупаемость вложенных инвестиций (ROI) при разработке и минимизировать затраты как финансовые, так и связанные с упущенными возможностями<br \/>\n— снизить риски, связанные с безопасностью и качеством данных<br \/>\n— максимизировать ценность и полезность данных необходимых бизнесу<\/p>\n<h3><b>Генерация данных. Системы источники.<\/b><\/h3>\n<p>Системы источники — это то место где данные изначально появляются. Дата инженер потребляет данные из источников, но при этом не является владельцем и не управляет системой источником. Ему важно понимать как данная система работает и генерирует данные, включая такие параметры как: частоту генерации новых данных, скорость, разнообразие генерируемых данных, может ли потенциально привести к проблемам с производительностью системы в результате аналитических запросов.<\/p>\n<p>Также дата инженеру важно поддерживать связь с владельцами источника данных, чтобы быть в курсе о любых изменениях, которые могут прервать конвейер загрузки данных. Изменения могут быть такого характера: изменение типа данных, например, смена типа колонки в таблице БД, миграция на новую БД.<\/p>\n<p>Традиционным источником хранения генерируемых данных является транзакционная база данных, в которой может хранится информация о клиентах, платежах, заказах компании и т. д.. Данный подход стал популярен в 1980-ых и до сих пор активно используется во многих популярных архитектур приложений, например, как микросервисная архитектура.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/application-database.png\" width=\"824\" height=\"226\" alt=\"\" \/>\n<\/div>\n<p>Другим и более современным источником данных является IoT (Internet of things) devices. Каждый девайс, например, смартфон генерирует данные (поведение пользователя в приложении — это новые сгенерированные данные). Данные представляются в виде сообщений, которые направляются в брокеры сообщений (транспорт данных между системами), которые аккумулируют их и передают в другие системы потребители.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/iotswarm-diagram.png\" width=\"825\" height=\"382\" alt=\"\" \/>\n<\/div>\n<h3><b>Хранение данных<\/b><\/h3>\n<p>Решение где хранить данные очень важное, поскольку оно влияет на все этапы жизненного цикла работы с данными и взаимодействует с процессами их загрузки, преобразования и предоставления.<\/p>\n<p><b>Частота доступа к данным<\/b><br \/>\nРазные типы данных имеют разные паттерны доступа в зависимости от того, как часто они извлекаются и запрашиваются.  Данные классифицируются по «температуре» в зависимости от частоты доступа:<br \/>\n— Горячие данные. Часто запрашиваемые данные (несколько раз в день или даже в секунду), которые должны храниться для быстрого извлечения.<br \/>\n— Теплые данные. Запрашиваются реже, например, еженедельно или ежемесячно.<br \/>\n— Холодные данные. Редко запрашиваемые данные, подходящие для архивного хранения, часто сохраняемые для соблюдения требований законодательства, compliance или для восстановления после аварий.<\/p>\n<p>Подход к хранению холодных данных эволюционировал, и современные облачные среды предлагают специализированные уровни хранения, которые являются экономически эффективными для долгосрочного хранения, но могут нести более высокие затраты при их извлечении.<\/p>\n<p><b>Выбор системы хранения<\/b><br \/>\nКакой тип хранения данных вам следует использовать? Это зависит от ваших требований по их использованию, объема данных, частоты их поступления, формата и размера обрабатываемых данных — по сути, от ключевых факторов, перечисленных выше. Нет универсальной рекомендации по хранению, подходящей для всех. У каждой технологии хранения есть свои плюсы и минусы.<\/p>\n<h3><b>Загрузка, сбор данных<\/b><\/h3>\n<p>После того как удалось разобраться с источником данных и хранением данных, следующий шаг — это забор данных из системы. Источники данных и процессы их забора часто являются узкими горлышками в жизненном цикле работы с данными. Источники данных обычно находятся вне вашего контроля и могут стать недоступными или начать предоставлять некачественные данные. Сервисы, что загружают данные, также могут неожиданно выходить из строя, что вызывает проблемы с конвейером данных. Ненадежные источники и системы загрузки данных создают цепную реакцию проблем по всему жизненному циклу работы с данными.<\/p>\n<p><b>Пакетная обработка против потоковой обработки<\/b><br \/>\nДанные постоянно генерируются и обновляются на источнике в реальном времени. Пакетная обработка больших объемов данных, например, ежедневная загрузка, часто применяется в устаревших системах. Загрузка данных через пакетную обработку задается в заранее установленные временные интервалы или в тот момент когда накапливаемые данные достигнут установленных порогов по объему. Из-за ограничений старых систем пакетная загрузка долгое время была стандартным способом обработки данных. Тем не менее, пакетная обработка по-прежнему остается очень популярным методом загрузки данных для аналитики и машинного обучения. В свою очередь, потоковая загрузка позволяет передавать данные конечным потребителям в режиме реального времени или близком к реальному с минимальной задержкой (например, менее одной секунды). Современные платформы потоковой обработки данных и разделение процесса хранения и вычисления во многих современных системах способствуют доступности и росту популярности обработки данных в реальном времени. Выбор между пакетной и потоковой обработкой зависит от конкретных задач и ожиданиями по времени готовности данных для обработки в системах потребителях.<\/p>\n<p>Подход с потоковой обработкой данных может показаться хорошей идеей, но это не всегда так. Пакетная обработка является отличным подходом для многих распространенных случаев, таких как обучение моделей и еженедельная отчетность. Используйте потоковую обработку в реальном времени только после того, как выявите бизнес-сценарий, который оправдывает затраты и риски по сравнению с использованием пакетной обработки.<\/p>\n<p><b>Модель Push и Pull данных<\/b><br \/>\nВ моделе <b>push<\/b> источник отправляет данные непосредственно в целевую систему, будь то база данных, объектное хранилище или файловая система. В модели <b>pull<\/b> данные извлекаются из источника.<\/p>\n<p>Рассмотрим, к примеру, процесс извлечения, преобразования и загрузки данных (ETL), который часто используется в пакетных потоках загрузки данных. Часть процесса ETL, отвечающая за извлечение (E), подчеркивает, что мы имеем дело с моделью Pull данных. ETL система выполняет запрос к текущей таблице-источнику по определенному расписанию.<\/p>\n<p>В другом примере рассмотрим непрерывный процесс изменения данных (CDC), который достигается несколькими способами. Один из распространенных методов, когда обращаемся к каждой измененной строке в БД. Эта строка отправляется в очередь, откуда система по загрузке данных ее забирает. Другой распространенный метод CDC использует транзакционные логи, которые фиксируют каждый commit в БД. База данных записывает каждый commit в логи, а система по загрузке данных читает эти логи, не взаимодействуя с БД напрямую. Это создает минимальную или даже нулевую дополнительную нагрузку на БД. Некоторые версии пакетного CDC используют модель <b>pull<\/b> данных. Например, в случае CDC на основе временных меток система по загрузке данных делает запрос к БД и извлекает строки, которые изменились с момента последнего обновления.<\/p>\n<h3><b>Трансформация данных<\/b><\/h3>\n<p>На этом этапе жизненного цикла работы с данными происходит их преобразование, то есть данные изменяются из своего исходного вида во что-то полезное для дальнейшего использования. Без правильного преобразования данные останутся бесполезными и не будут пригодны для отчетов, анализа или машинного обучения. Как правило, именно на этапе преобразования данные начинают приносить пользу для конечных пользователей.<\/p>\n<p>При преобразовании данных следует учитывать следующие вещи:<br \/>\n— Каковы затраты и выгода преобразования данных? Какую бизнес ценность она несет?<br \/>\n— Является ли трансформация простой, понятной и изолированной от остальных операций с данными?<br \/>\n— Какую бизнес логику имплементирует преобразование данных?<\/p>\n<p>Преобразование данных может выполняться как в пакетном режиме, так и в потоковой обработке. Хотя пакетные преобразования остаются преобладающими, растущая популярность потоковой обработки и увеличение объема потоковых данных ведут к тому, что потоковые преобразования могут со временем вытеснить пакетные в некоторых областях.<\/p>\n<p>Преобразование данных часто интегрируется с другими фазами жизненного цикла работы с данными. Оно может выполняться уже на стороне системы источника или «налету» во время загрузки данных. Пример: система может обогатить запись дополнительными системными полями в процессе загрузки.<\/p>\n<p>Бизнес-логика — это основная движущая сила преобразования данных. Пример: продажа товара может быть выражена как бизнес-логика, которая переводится в конкретные и многократно переиспользуемые элементы. Моделирование данных важно для понимания и отражения бизнес-процессов, и важно обеспечивать стандартный подход к реализации бизнес-логики в процессе преобразования.<\/p>\n<p>Формирование признаков для машинного обучения — это еще один про­цесс преобразования данных. Он предназначен для извлечения и улучшения при­знаков данных, полезных для обучения моделей машинного обучения. Форми­рование признаков может быть сложным занятием, сочетающим в себе знания в данной области (чтобы определить, какие признаки могут быть важны для про­гнозирования). После определения способа формирования признаков data scientist’ами, процессы разработки признаков могут быть автоматизиро­ваны инженерами данных на этапе преобразования данных.<\/p>\n<h3><b>Предоставление данных конечным потребителям<\/b><\/h3>\n<p>Предоставление данных — это самая интересная часть жизненного цикла работы с данными. Именно здесь и происходит волшебство. Именно здесь инже­неры машинного обучения могут применить самые передовые подходы. Рассмотрим некоторые из популярных видов использования данных: аналитику, машинное обу­чение и обратный ETL.<\/p>\n<p><b>Аналитика<\/b><br \/>\nСуществует два типа аналитики:<\/p>\n<ol start=\"1\">\n<li>Операционная<\/li>\n<li>Бизнес аналитика<\/li>\n<\/ol>\n<p><b>Бизнес аналитика (BI)<\/b><br \/>\nДанный тип аналитики описывает состояние бизнеса компании в прошлом или в настоящем. Бизнес аналитика требует обработки сырых данных используя бизнес логику. Как мы ранее говорили процесс обработки данных по бизнес правилам происходит на этапе трансформации данных, но помимо этого все большую популярность набирает подход применение бизнес правил при чтении данных. Данные в таком случае хранятся практически в сыром виде с минимальной постобработкой по бизнес логике. BI системы, которые читают данные из хранилищ данных, хранят репозиторий знаний о бизнес логике. При запросе данных из хранилища применяется бизнес логика для составления отчетов, дашбордов.<\/p>\n<p>При росте компании и зрелости данных организация переходит от случайных ad-hoc запросов к сервисам самостоятельной аналитики, то есть без вмешательства IT специалистов, где любой бизнес пользователь может подключиться к данным, покрутить данные так как ему захочется и тут же получить ценную информацию. Однако зачастую организация сервисов самостоятельной аналитики проста лишь в теории, зачастую — это сложная задача по нескольким причинам: плохое качество данных, организационная изоляция, отсутствие навыков по работе с данными.<\/p>\n<p><b>Операционная аналитика<\/b><br \/>\nОперационная аналитика сфокусирована на деталях состоянии бизнеса в текущее время.<br \/>\nВ операционной аналитике данные потребляются в реальном времени напрямую из системы источника данных или из системы потоковой обработки данных. Ценность информации, полученной от операционной аналитики, отличается от традиционной бизнес аналитики тем что операционная аналитика сфокусирована на текущем состоянии бизнеса и нет задачи в поиске трендов в исторических данных.<\/p>\n<p><b>Машинное обучение<\/b><br \/>\nМашинное обучение (ML) — одна из самых значимых технологических революций наших дней. Компании, достигшие зрелости в работе с данными, могут начинать применять ML для решений задач бизнеса, формируя практики вокруг него. Однако важно не спешить и сначала построить надежный фундамент данных.<\/p>\n<p>Дата инженеры часто пересекаются в обязанностях с ML-инженерами и аналитиками. Они поддерживают кластеры Spark для аналитики и ML, системы оркестрации и каталоги данных. Определение зон ответственности между инженерией данных и ML — ключевое организационное решение.<\/p>\n<p>Хранилища признаков (feature stores) помогают уменьшить нагрузку на ML-инженеров, сохраняя историю и версии признаков и обеспечивая совместное их использование между командами. Инженеры данных играют важную роль в поддержке хранилищ признаков.<\/p>\n<p>Инженеры данных должны понимать основы ML, связанные с ними требования к обработке данных и задачи аналитических команд. Это помогает наладить коммуникацию, сотрудничество и создавать инструменты, которые объединяют усилия команд. Перед внедрением ML важно оценить качество данных, их доступность и соответствие реальности.<\/p>\n<p><b>Обратный ETL<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/reverse-etl.png\" width=\"839\" height=\"427\" alt=\"\" \/>\n<\/div>\n<p><b>Обратный ETL<\/b> — это процесс, при котором обработанные данные из хранилища данных возвращаются в исходные системы, такие как CRM или SaaS-платформы. Хотя раньше эта практика считалась нежелательной, сегодня она признаётся полезной и часто необходимой для бизнеса.<br \/>\nПримеры использования обратного ETL:<br \/>\n— Реклама и маркетинг: Аналитики рассчитывают ставки в Excel на основе данных из хранилища, а затем вручную загружают эти данные в Google Ads.<br \/>\n— CRM и платформы управления клиентами: Компании передают метрики и аналитические данные обратно в CRM  для улучшения взаимодействия с клиентами.<br \/>\n— Модели и аналитика: Данные аналитики или результаты моделей машинного обучения возвращаются в системы источники для дальнейшего использования.<\/p>\n<h2><b>Основные практики, протекающие через весь жизненный цикл работы с данными<\/b><\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/main-undercurrents.png\" width=\"847\" height=\"265\" alt=\"\" \/>\n<\/div>\n<h3><b>Безопасность<\/b><\/h3>\n<p>Проблемы безопасности в компаниях часто возникают из-за человеческого фактора, когда сотрудники пренебрегают базовыми мерами предосторожности. Это может включать в себя фишинговые атаки, слабые пароли, неправильную настройку систем безопасности или недостаточное внимание к соблюдению стандартов безопасности.<\/p>\n<p>Безопасность должна быть главным приоритетом для дата инженеров, поскольку они несут ответственность за защиту данных на уровне систем и инфраструктуры. Игнорирование аспектов безопасности может привести к значительным рискам для организации, таким как утечка конфиденциальной информации или серьезные сбои в системе. Помимо технической части работы с данными, инженеры должны уделять внимание вопросам безопасности, принимая во внимание как защиту самих данных, так и контроль доступа к ним.<\/p>\n<p><b>Принцип минимальных привилегий<\/b><br \/>\nПринцип минимальных привилегий предполагает предоставление пользователям и системам только того доступа, который необходим для выполнения их текущих задач. Например, если сотрудник выполняет только поиск, просмотр файлов, ему не нужно предоставлять права суперпользователя (root). Права администратора следует давать только тем пользователям, которым они действительно необходимы. Важно, чтобы доступ к данным был предоставлен только на тот период, который необходим для выполнения их задачи, чтобы минимизировать риски их утечки.<\/p>\n<p><b>Контроль доступа и защита данных<\/b><br \/>\nЗащита данных включает в себя не только предоставление доступа к данным только тем людям и системам, которые действительно нуждаются в них, но и обеспечение того, чтобы данные были защищены на всех этапах их использования. Данные должны быть защищены как в процессе их передачи, так и когда данные никем не используются . Это можно обеспечить с помощью таких технологий, как шифрование, токенизация, маскирование данных и использование строгих систем управления доступом.<\/p>\n<h3><b>Управление данными<\/b><\/h3>\n<p>Управление данными — это обеспечение качества, целостности, безопасности и удобства использования данных, собранных организацией, благодаря этому извлекается максимальная ценность из данных для бизнеса. Управление данными помогает компаниям избегать проблем с недоверием к ним и упрощает процесс принятия решений. Для эффективного управления данными необходимы люди, процессы и технологии.<br \/>\nЕсли управление данными организовано плохо, это может привести к таким ситуациям:<br \/>\n— Аналитик получает запрос на отчет, но не знает, какие данные использовать.<br \/>\n— Он тратит часы на поиск нужных таблиц, делая предположения.<br \/>\n— Итоговый отчет получается неполным и сомнительным.<br \/>\n— Это вызывает недоверие к данным в целом и осложняет бизнес-планирование<\/p>\n<p>Управление данных подразделяется на следующие категории:<br \/>\n— <b>Обнаружение данных (Discoverability)<\/b>: Возможность находить нужные данные<br \/>\n— <b>Безопасность (Security)<\/b>: Защита данных от несанкционированного доступа.<br \/>\n— <b>Ответственность (Accountability)<\/b>: Определение, кто отвечает за данные.<\/p>\n<p><b>Обнаружение данных<\/b><br \/>\nВ data-driven компании информация должна быть доступной и легко обнаруживаемой. Конечные пользователи должны иметь быстрый и надежный доступ к данным, необходимым для выполнения их работы. Они должны понимать, откуда берутся данные, как они связаны с другими данными и что эти данные означают.<br \/>\nКлючевые области, связанные с обнаружением данных, включают<b> управление метаданными<\/b> и <b>управление мастер-данными<\/b><\/p>\n<p><b>Метаданные<\/b> — это данные о данных, которые являются основой для всего жизненного цикла работы с данными. Используя метаданные дата инженеры проектируют потоки данных, управляют данными через весь жизненный цикл работы с данными, и убеждаются что данные использованы правильно.<br \/>\nОсновные категории метаданных:<br \/>\n— <b>Бизнес метаданные<\/b>.  Позволяет понять как данные используются в бизнес контексте, включая бизнес правила, определения<br \/>\n— <b>Технические метаданные<\/b>. Описывают создание и использование данных в процессе инженерии данных. Включают модель данных, происхождение и схему данных.<br \/>\n— <b>Операционные метаданные<\/b>. Относится к операционным системам, включают статистику работы заданий, логи, отслеживание ошибок, мониторинг успешного или неуспешного выполнения заданий<br \/>\n— <b>Справочная информация<\/b>. Редко меняющиеся данные, которые используются для классификации других данных, например, единицы измерения, налоговые ставки, коды валют, стран и т. д. Благодаря справочным данным все источники данных в организации буду классифицировать одинаковым образом, что повышает согласованность и их качество<\/p>\n<p><b>Мастер данные<\/b> — это данные о ключевых бизнес сущностях организации, таких как сотрудники, клиенты, продукты и т. д. <b>Управление мастер-данными (MDM)<\/b> — это практики создания последовательных определений сущностей, известных как «золотые записи», поддерживающиеся технологическими инструментами, приводящие данные из разных источников, форматов к единому стандарту или структуре по всей организации. Это необходимо для обеспечения согласованности, точности и совместимости данных. Данный процесс может прямо входить в сферу ответственности дата инженеров, но часто является задачей отдельной специализированной команды. В качестве примера команда MDM может определить стандартный формат адресов клиентов, а затем работать с инженерами для создания API, который будет возвращать согласованные адреса, систем, использующие данные об адресах для сопоставления записей клиентов между подразделениями компании.<\/p>\n<p><b>Ответственность за данные<\/b><br \/>\nОтветственность за данные — это назначение контактного лица для управления конкретной порции данных. Контактные лица обеспечивают согласованность, качество, доступ, корректное и понятное описание, защиту от несанкционированного доступа, соответствие регуляторным требования данных, координацию по управлению данными с другими заинтересованными лицами. Объектами, за которыми закреплены ответственные, могут быть как отдельные таблицы, потоки данных, так и конкретные поля в таблицах. Не всегда дата инженеры являются ответственными за данными, ими могут быть и software engineers, и product owners, и другие роли.<\/p>\n<p><b>Качество данных<\/b><br \/>\nКачество данных — это целостный, непрерывный процесс, требующий сочетания человеческих и технологических усилий, постоянного мониторинга, проверки, обратной связи с пользователями и четких определений данных, чтобы гарантировать, что данные точны, полны, согласованы и надежны<br \/>\nКачество данных определяется тремя ключевыми аспектами:<br \/>\n— Точность: Данные должны быть правильными, без дубликатов и с точными числовыми значениями<br \/>\n— Полнота: Записи должны быть полными, и все необходимые поля должны содержать допустимые значения<br \/>\n— Согласованность: Данные должны быть согласованы в разных системах<\/p>\n<p><b>Моделирование и проектирование данных<\/b> — процесс преобразования данных в пригодную для использования форме с целью извлечения бизнес-ценности. <b>Модель данных<\/b> — модель, которая показывает как данные соотносятся с реальным миром, чтобы наилучшим образом соответствовать процессам, определениям и бизнес логике вашей организации.<\/p>\n<p><b>Происхождение данных (Data Lineage)<\/b><br \/>\nПо мере того как данные проходят через жизненный цикл работы с данными, они изменяются через преобразования и комбинации с другими данными. Бывает сложно понять, как был получен определенный набор данных. Инструменты происхождения данных помогают инженерам понять предыдущие шаги трансформации, а также их источники. Важно отслеживать происхождение и изменения данных, их зависимости с течением времени, потому что это помогает отслеживать ошибки, решать инциденты, находить ответственных за данные и отлаживать данные при разработке систем, которые их обрабатывают.<\/p>\n<h3><b>DataOps<\/b><\/h3>\n<p><b>DataOps<\/b> — это совокупность практик, культурных норм и архитектурных паттернов.<br \/>\nDataOps имеет три основные технические составляющие: автоматизация, мониторинг и наблюдаемость, а также реагирование на инциденты.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/dataops-pillars.png\" width=\"975\" height=\"147\" alt=\"\" \/>\n<\/div>\n<p><b>Автоматизация<\/b> в DataOps имеет схожий воркфлоу что и у DevOps, состоящий из управления изменениями (управление окружением, кодом и версиями данных), непрерывной интеграции и развертывания (CI\/CD) и конфигурации приложения через код. Как и в DevOps, практики DataOps следят за надежностью технологий и систем (потоки данных, оркестрация и т. д.), но еще и проверкой качества данных, перекосом данных и целостностью метаданных.<br \/>\n<b>Мониторинг и наблюдаемость<\/b> критически важны для своевременного выявления любых проблем на протяжении всего жизненного цикла работы с данными. Мониторинг, логирование, нотификация — все это играет важную роль. Рекомендуется внедрять SPC (Statistical Process Control), чтобы понимать, являются ли отслеживаемые события отклонениями от нормы.<br \/>\n<b>Реагирование на инциденты<\/b> — это симбиоз использования возможностей автоматизации и мониторинга для быстрого выявления причин инцидента и устранения его последствий. Можно выделить следующие аспекты:<br \/>\n— Реагирование на инциденты — это не только про технологии и инструменты, но и открытая, лишенная обвинений коммуникация как среди дата инженеров, так и на уровне всей организации<br \/>\n— дата инженеры должны быть подготовленными к возникновению аварий и оперативно действовать для быстрого восстановления работы системы<br \/>\n— дата инженеры должны проактивно находить проблемы до того, как о них сообщит бизнес<\/p>\n<h3><b>Архитектура данных<\/b><\/h3>\n<p>Архитектура данных отражает текущее и будущее состояние дата систем, удовлетворяющих долгосрочные потребности и стратегию организации в области данных. Поскольку требования организации к данным, вероятно, будут быстро изменяться, а новые инструменты и практики появляются почти ежедневно, дата инженерам стоит разбираться в проектировании хороших архитектур данных.<\/p>\n<p>Дата инженер должен понимать потребности бизнеса и собирать требования для новых случаев использования данных. Дата инженер должен уметь переводить эти требования в проектирование новых загрузок и предоставление данных конечным потребителям, учитывая баланс между стоимостью и операционными затратами. Это означает, что знание компромиссов между паттернами проектирования, технологиями и инструментами является крайне важным аспектом в работе дата инженера.<br \/>\nДата инженер и архитектор данных — это две разные роли, но важно чтобы дата инженер мог реализовывать и понимать проекты архитектора данных и мог предоставлять обратную связь по архитектуре.<\/p>\n<h3><b>Оркестрация<\/b><\/h3>\n<p><b>Оркестрация<\/b> — это процесс координации множества заданий, чтобы они выполнялись быстро и эффективно по запланированному расписанию. Система оркестрации должна работать в режиме высокой доступности, это позволяет ей постоянно отслеживать и мониторить процессы без вмешательства человека и запускать новые задания всякий раз, когда она развертывается. Система оркестрации следит за задачами и при их успешном завершении запускает новые, анализируя их зависимости. Также она мониторит внешние системы, чтобы отслеживать поступление новых данных и выполнение необходимых условий для запуска новых заданий. Когда условия запуска заданий завершаются с ошибкой  система оповещает об этом заинтересованных лиц по почте или другим каналам связи.<\/p>\n<h3><b>Software Engineering<\/b><\/h3>\n<p>Software Engineering всегда был ключевым навыком для дата инженеров. В ранние годы инженерии данных (2000—2010) инженеры работали с низкоуровневыми фреймворками и писали задачи MapReduce на C, C++ и Java. В разгар эпохи больших данных (середина 2010-х годов) инженеры начали использовать фреймворки, которые абстрагировались от низкоуровневых деталей. Использование абстракций продолжается и сегодня, поскольку облачные хранилища данных поддерживают мощные преобразования данных, используя SQL, Spark. Несмотря на это, software engineering по-прежнему остается критически важным аспектом для дата инженеров.<\/p>\n<p><b>Разработка open-source фреймворков<\/b><br \/>\nМногие дата инженеры активно вносят вклад в разработку open-source фреймворков для решения конкретных задач в жизненном цикле обработки данных, а затем продолжают дорабатывать их код, улучшая инструменты под свои задачи и внося вклад в сообщество. Хорошими примерами таких фреймворков являются фреймворки экосистемы Hadoop и оркестратор Apache Airflow. Прежде чем дата инженеры начнут разрабатывать новые внутренние инструменты, им стоит изучить существующие решения. Есть большая вероятность, что уже существует open-source проекты, решающий их проблему, и лучше присоединиться к его развитию, чем изобретать велосипед заново.<\/p>\n<p>На практике, независимо от того, какие высокоуровневые инструменты используют дата инженеры, они неизбежно сталкиваются с необычными случаями в течение жизненного цикла обработки данных, которые требуют выхода за рамки возможностей выбранных инструментов. При работе с фреймворками, такими как Fivetran, Airbyte или Matillion, дата инженеры могут столкнуться с источниками данных, для которых нет готовых коннекторов, и тогда им придется разрабатывать их самостоятельно. Для этого важно владеть навыками программирования, чтобы разбираться в API, извлекать и преобразовывать данные, обрабатывать исключения и решать другие задачи, выходящие за рамки стандартного функционала инструментов.<\/p>\n",
            "date_published": "2025-02-02T19:01:03+05:00",
            "date_modified": "2025-02-03T15:50:10+05:00",
            "tags": [
                "BigData",
                "Clouds",
                "IT",
                "Инженерияданных",
                "Книги"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/Data-engineering-lifecycle.png",
            "_date_published_rfc2822": "Sun, 02 Feb 2025 19:01:03 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "21",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/Data-engineering-lifecycle.png",
                    "https:\/\/slavlotski.com\/pictures\/application-database.png",
                    "https:\/\/slavlotski.com\/pictures\/iotswarm-diagram.png",
                    "https:\/\/slavlotski.com\/pictures\/reverse-etl.png",
                    "https:\/\/slavlotski.com\/pictures\/main-undercurrents.png",
                    "https:\/\/slavlotski.com\/pictures\/dataops-pillars.png"
                ]
            }
        },
        {
            "id": "22",
            "url": "https:\/\/slavlotski.com\/all\/crystal-nova-na-joof-aura\/",
            "title": "Crystal Nova на JOOF Aura",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/JA121.jpg\" width=\"2560\" height=\"2560\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><b>Slavlotski — Crystal Nova (incl. Enlusion Remix)<\/b><br \/>\n<b>Дата релиза:<\/b> 11 ноября 2024<br \/>\n<b>Лейбл:<\/b> JOOF Aura<br \/>\n<b>Жанр:<\/b> прогрессив хаус, техно-транс<br \/>\n<b>BPM:<\/b> 121, 128<br \/>\n<b>Стриминговые платформы:<\/b><br \/>\n<a href=\"https:\/\/open.spotify.com\/album\/2UYOzMt1qy17sZ2JSnSt7x?si=qye_H9mxSXij5_GNiwF5qw\">Spotify<\/a><br \/>\n<a href=\"https:\/\/music.apple.com\/kz\/album\/crystal-nova-single\/1777303143\">Apple Music<\/a><br \/>\n<a href=\"https:\/\/soundcloud.com\/joof-recordings\/sets\/ja121?si=ae015c13345e461680b6f358a1bb42b1&utm_source=clipboard&utm_medium=text&utm_campaign=social_sharing\">SoundCloud<\/a><br \/>\n<a href=\"https:\/\/www.beatport.com\/release\/crystal-nova\/4802823?utm_source=toneden&utm_medium=bp_affiliate&utm_campaign=ToneDen\">Beatport<\/a><\/div>\n<\/div>\n<p>11 ноября на британском лейбле <a href=\"https:\/\/www.discogs.com\/label\/1008712-JOOF-Aura?srsltid=AfmBOorp1i7-0A8m8Ad3X5VEyAUe_oXRz1PCwM6_FbjlTfhbYMF-Sf1-&page=1\">JOOF Aura<\/a> вышел мой новый сингл <b>Crystal Nova<\/b>. Этот трек в жанре progressive house, созданный после двухлетнего перерыва, ярко подтверждает, что моя страсть к написанию музыки не угасла. В основе трека лежат мощные бас-линии, окутанные зловещей атмосферой с помощью эффектов и глубоких падсов, дополненные гипнотической плак мелодией.<\/p>\n<iframe width=\"540\" height=\"315\" src=\"https:\/\/www.youtube.com\/embed\/t-NksfJ9x4o?si=1FN6ur1larO1L0tE\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe>\n<p>Мой друг <a href=\"https:\/\/t.me\/forescapedigital\/\">Кирилл Enlusion<\/a> также представил свою техно-транс версию трека. Он признаётся, что ремиксы на мои треки всегда представляют для него сложность, но после долгой и усердной работы он закончил его, за что я ему искренне благодарен. Версия Кирилла — это техно движок с пробивной бочкой и мощной ритм-секцией, создающие отличный грув, а атмосферные эффекты и пады с разнообразными мелодиями обеспечивают постоянное движение и динамику в треке.<\/p>\n<iframe width=\"540\" height=\"315\" src=\"https:\/\/www.youtube.com\/embed\/g7WgDyLedVk?si=72yu35AqEvuY2Efs\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe>\n<p>В качестве бонуса Кирилл еще записал видео, где он прошелся по своему проекту ремикса в Ableton Live.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/iiACr_xPjTM?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2024-11-12T17:39:00+05:00",
            "date_modified": "2024-11-12T18:31:04+05:00",
            "tags": [
                "Музыка",
                "Музыкальный продакшен",
                "Прогрессив",
                "Релиз"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/JA121.jpg",
            "_date_published_rfc2822": "Tue, 12 Nov 2024 17:39:00 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "22",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/JA121.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-iiACr_xPjTM-cover.jpg"
                ]
            }
        },
        {
            "id": "19",
            "url": "https:\/\/slavlotski.com\/all\/fundamentals-of-data-engineering-chast-1\/",
            "title": "Книга: Основы Инженерии данных. Глава 1. Описание дата-инженерии.",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Fundamentals-of-Data-Engineering.jpg\" width=\"762\" height=\"1000\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><b>Авторы<\/b>: <a href=\"https:\/\/www.linkedin.com\/in\/josephreis\/\">Joe Reis<\/a>, <a href=\"https:\/\/www.linkedin.com\/in\/housleymatthew\/\">Matt Housley<\/a><br \/>\n<b>Дата публикации<\/b>: Июнь 2022 год<br \/>\n<b>Издатель<\/b>: O’Reilly Media, Inc.<br \/>\n<b>Ссылки на покупку<\/b>: <a href=\"https:\/\/www.amazon.com\/_\/dp\/1098108302?smid=ATVPDKIKX0DER&_encoding=UTF8&tag=oreilly20-20\">amazon<\/a>, <a href=\"https:\/\/ozon.ru\/product\/fundamentals-of-data-engineering-plan-and-build-robust-data-systems-1615976347\/\">ozon<\/a><\/div>\n<\/div>\n<p class=\"loud\"><b>Дисклеймер:<\/b> Целью данной статьи не является полностью пересказать содержание книги, а лишь выделить важные аспекты в более сжатом и понятном формате. Я рекомендую к ознакомлению с полной версией книги. Учитывая, что книга издана только на английском языке, я мог допустить неточности и ошибки в переводе и исказить смысл содержания заложенный авторами.<\/p>\n<p><b>Кем написана?<\/b><br \/>\nЭту книгу написали бывшие data scientist’ы. Они столкнулись с трудностями в Data Science проектах из-за отсутствия фундаментальных знаний в инженерии данных.<\/p>\n<p><b>Что не покрывает?<\/b><br \/>\nЭта книга не посвящена конкретным технологиям, инструментам или платформам в инженерии данных. Много хороших книг охватывают эти аспекты, но они быстро устаревают. В этой книге рассматриваются фундаментальные концепции дата-инженерии.<\/p>\n<p><b>О чем?<\/b><br \/>\nЭта книга заполняет пробелы в материалах по инженерии данных. В то время как многие ресурсы описывают конкретные технологии, трудно понять, как их эффективно использовать для решения задач бизнеса. Книга охватывает все этапы работы с данными и показывает, как использовать технологии для нужд аналитиков, data scientist’ов и инженеров машинного обучения.<\/p>\n<p>Главная идея книги — жизненный цикл работы с данными: создание, хранение, сбор, преобразование и предоставление данных. Несмотря на технологии, эти этапы остаются неизменными уже много лет.<\/p>\n<p><b>Для кого?<\/b><br \/>\nОсновная аудитория книги — специалисты уровня middle и senior, разработчики, аналитики, data scientist’ы, стремящиеся стать инженерами данных, а также дата-инженеры, желающие всестороннего развития. Книга также подойдет менеджерам, лидам data-команд и руководителям DWH, планирующим миграцию с on-premise на облако.<\/p>\n<p><b>Что вы узнаете?<\/b><br \/>\n— Как инженерия данных влияет на вашу текущую роль в компании<br \/>\n— Как среди тысяч технологий выбирать наиболее подходящие для решения ваших задач, для построения дата-архитектур<br \/>\n— Как использовать жизненный цикл работы с данными для создания надежной архитектуры<br \/>\n— Узнаете лучшие практики для каждого этапа жизненного цикла работы с данными<br \/>\n— Внедрите принципы инженерии данных в вашу текущую роль<br \/>\n— Объедините различные облачные технологии, чтобы удовлетворить потребности конечных пользователей<br \/>\n— Внедрите управление данными и безопасность на всех этапах жизненного цикла работы с данными<\/p>\n<h2><b>Что такое инженерия данных?<\/b><\/h2>\n<p>Инженерия данных — одна из самых востребованных областей в сфере данных,  технологиях, и не без причины. Она закладывает основу для data science и аналитики в production среде. В данной главе узнаем о том что такое инженерия данных, как она родилась и эволюционировала и с кем они работают в компаниях.<\/p>\n<p><b>Инженерия данных<\/b> — это разработка, внедрение и поддержка систем и процессов, которые обрабатывают сырые данные и превращают их в высококачественную, согласованную информацию для решения задач аналитики и машинного обучения. Инженерия данных идет бок о бок с безопасностью, управлением данными, DataOps, архитектурой данных, оркестрацией и software engineering. Инженер данных управляет жизненным циклом работы с данными, начиная с получения данных из исходных систем и заканчивая предоставлением данных для аналитики или машинного обучения.<\/p>\n<h2><b>Эволюция инженера данных<\/b><\/h2>\n<p><b>1980 — 2000 года, от хранилища данных к вебу<\/b><\/p>\n<p>Понятие хранилища данных возникло в 1980-х годах благодаря Биллу Инмону. После создания реляционных баз данных и SQL разработчиками IBM, компания Oracle популяризировала реляционные БД. Ральф Кимбал и Билл Инмон разработали методы описания бизнес-моделей в хранилищах данных, которые активно используются до сих пор.<\/p>\n<p>Хранилища данных стали основой масштабируемой аналитики с использованием MPP баз данных, что привело к появлению ролей BI инженера, ETL и DWH разработчика — предков современных инженеров данных.<\/p>\n<p>В середине 1990-х годов интернет стал популярным благодаря компаниям с web-first подходом, таких как AOL, Yahoo и Amazon. Популяризация интернета привела к генерации больших объемов данных в веб-приложениях, в то время как вендоры предлагали на рынке монолитные системы с дорогими лицензиями, которые не были способны обрабатывать такие объемы данных.<\/p>\n<p><b>2000-ые, рождение современной инженерии данных<\/b><\/p>\n<p>В начале 2000-х годов компании Yahoo, Google и Amazon, выросшие в крупные технологические компании, столкнулись с проблемами традиционных систем, не справлявшихся с большими объемами данных. Требовались системы нового поколения, которые были бы экономичными, масштабируемыми, надежными и доступными.<\/p>\n<p>Параллельно большому буму данных значительно подешевели цены на серверы, RAM, жесткие диски и флеш-накопители, что способствовало развитию распределенных вычислений и хранения данных, привело к созданию децентрализованных систем и началу эры больших данных.<\/p>\n<p>В эти же годы появились такие системы как Hadoop, Amazon DynamoDB, сервис AWS, который стал первым публичным облачным сервисом c бизнес моделью плати за использование вычислительных систем, хранение данных в облаке. Вместо приобретения физических компонент, серверов, разработчикам предлагалось арендовать вычислительные системы и хранение данных у AWS. Данная модель стала настолько прибыльной, что вскоре появились и другие облачные сервисы как Google Cloud, Microsoft Azure, DigitalOcean. Публичные облака вероятно стали самой значимой инновацией 21-ого века, которая устроила революцию в разработке и развертывании приложений.<\/p>\n<p>Публичные облака и первые инструменты обработки больших данных стали фундаментом современного ландшафта инженерии данных.<\/p>\n<p><b>2000 — 2010ые: инженерия больших данных<\/b><\/p>\n<p>Инструменты из экосистемы Hadoop быстро развивались и распространялись по всему миру. Помимо пакетной обработки данных появилась событийная обработка данных — потоковая обработка. Традиционные GUI-ориентированные инструменты уступили место инструментам с code-based подходом.<\/p>\n<p>Инженерам данных, помимо того что нужно было иметь навыки в разработке ПО, приходилось поддерживать большие кластеры серверов для обеспечения эффективной работы инструментов из экосистемы Hadoop (YARN, Hadoop Distributed File System (HDFS), MapReduce). Поддержка таких кластеров требовала больших команд и значительных затрат, что не всегда приносило ценность для бизнеса.<\/p>\n<p>Поэтому необходимо было найти возможности создать новые абстракции, упростить администрирование и поддержку big-data инфраструктуры, сделать инструменты обработки данных более доступными.<\/p>\n<p>В результате, с появлением облачных сервисов, обработка больших данных стала обычным делом для многих компаний, и фокус инженеров сместился с разработки технологий на доставку данных потребителям.<\/p>\n<p><b>2020-ые: инженерия для жизненного цикла работы с данными<\/b><\/p>\n<p>Исторически дата-инженеры использовали такие монолитные фреймворки как: Hadoop, Spark, Informaticа, но сейчас наблюдается тренд к децентрализованным, модульным и абстрагированным инструментам.<\/p>\n<p>Инженерия данных становится дисциплиной по интеграции различных технологий для достижения бизнес-целей. В то время как от инженера данных требовались навыки низкоуровневого программирования, они все больше и больше находят себя в роли, сфокусированных на вещах, находящихся выше в иерархии ценностей, таких как: безопасность, управление данными, DataOps, архитектура данных, оркестрация и в целом управление жизненным циклом данных.<\/p>\n<h2><b>Инженерия данных и Data Science<\/b><\/h2>\n<p>Инженерия данных — это отдельная от data science и аналитики область. Они дополняют друг друга, но они разные. Дата-инженеры обеспечивают входные данные для data scientist’ов, они же конвертируют эти входные данные во что-то полезное.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/data-engineering-sits-upstream-data-science.png\" width=\"611\" height=\"126\" alt=\"\" \/>\n<\/div>\n<p>Многие data scientist’ы тратят 70-80% своего рабочего времени на сбор, очистку и обработку данных, а не на аналитику и машинное обучение. Monica Rogati в своей <a href=\"https:\/\/hackernoon.com\/the-ai-hierarchy-of-needs-18f111fcc007\">статье<\/a> 2017 года критикует компании, за то, что прежде всего им нужно построить солидный фундамент данных (первые 3 нижних слоя в иерархии потребностей) перед тем как начать заниматься AI и ML.<\/p>\n<p>В идеальном мире data scientist’ы должны проводить около 90% своего рабочего времени, сфокусировавшись на верхних 3 слоях в иерархии потребностей. В то время как дата-инженеры сфокусированы на нижних 3 частях. Мы считаем, что роль дата инженеров так же важна, как и роль data scientist’ов, для успешных проектов Data Science.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Data-Science-Hierarchy-of-Needs.png\" width=\"871\" height=\"568\" alt=\"\" \/>\n<\/div>\n<h2><b>Зрелость данных в компании<\/b><\/h2>\n<p>Уровень сложности инженерии данных во многом зависит от степени зрелости данных в компании. <b>Зрелость данных<\/b> — это процесс совершенствования в использовании и интеграции данных в рамках всей организации. Существует три этапа зрелости данных:<\/p>\n<ol start=\"1\">\n<li>Начало работы с данными<\/li>\n<li>Масштабирование данных<\/li>\n<li>Лидерство на основе данных<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/data-maturity-stages.png\" width=\"821\" height=\"214\" alt=\"\" \/>\n<\/div>\n<p><b>Этап 1: Начало работы с данными<\/b><br \/>\nВ этот момент у компании могут быть нечетко поставленные цели или они вовсе не определены, архитектура данных и инфраструктура находятся на стадии планирования. Команда маленькая, и дата-инженер часто совмещает несколько ролей. Цель дата-инженера — быстро двигаться, адаптироваться и приносить ценность.<\/p>\n<p>На этом этапе уже существует желание получать инсайты из данных, но сотрудники не знают как эффективно использовать данные. Большинство запросов от бизнеса — это разовые запросы (ad-hoc запросы).<\/p>\n<p>На этом этапе дата-инженеру стоит сфокусироваться на следующих вещах:<br \/>\n— Заручитесь поддержкой от заинтересованных лиц, включая руководителей уровня C, по вопросам дизайна и построения архитектуры данных<br \/>\n— Определитесь с правильной архитектурой данных. Зная бизнес-цели должно быть понятно какие бенефиты компания стремится получить используя данные<br \/>\n— Постройте солидный фундамент данных для будущих аналитиков данных, data scientist’ов, чтобы генерировать отчеты и строить ML модели, которые принесут выгоду организации<\/p>\n<p>Данный этап может содержать множество подводных камней. Вот некоторые советы чтобы их избежать:<br \/>\n— Показывайте важность данных в организации через достижение быстрых побед, например, показав как используя данные можно принести больше прибыли, но помните, быстрые решения могут порождать технический долг<br \/>\n— Стройте взаимодействие с другими департаментами и избегайте изоляции<br \/>\n— Используйте готовые решения там где это возможно<br \/>\n— Создавайте кастомные решения только когда это приносит конкурентное преимущество<\/p>\n<p><b>Этап 2: Масштабирование c данными<\/b><br \/>\nНа данном этапе компания уже не делает разовые (ad-hoc) запросы по данным, внедрила формализованные практики работы с данными. Теперь одним из вызовов заключается в создании масштабируемых архитектур данных и планировании будущего, где компания уже будет принимать решения, стратегии основываясь на данных, так называемый data-driven подход. Роли инженерии данных теперь не совмещает сразу несколько ролей, специалисты сосредоточены на конкретных частях жизненного цикла работы с данными.<br \/>\nНа этом этапе зрелости данных целью дата инженера является:<br \/>\n— Создать формализованные практики работы с данными<br \/>\n— Создать надежную, масштабируемую архитектуру данных<br \/>\n— Внедрить принципы DevOps, DataOps в компанию<br \/>\n— Построить инфраструктуру, платформы, которые позволят разрабатывать, разворачивать, управлять ML моделями<br \/>\n— Быть сфокусированными над существующими решениями, являющимися стандартом индустрии для решения обычных задач, вместо того чтобы разрабатывать все с нуля<\/p>\n<p>Потенциальные проблемы с которыми можно столкнуться на данном этапе:<br \/>\n— С ростом объема данных в компании появляется соблазн внедрять технологии, которые популярны в компаниях из Кремниевой долины. Не стоит искушаться соблазну, любая технология должна быть выбрана с целью принести ценность вашим клиентам<br \/>\n— Узкое место по масштабированию это не кластер серверов, хранилища или технологии — это команда дата инженеров. Используйте решения, которые просто разворачивать и управлять<br \/>\n— Коммуницируйте с другими команда на тему практического применения данных. Учите организацию как потреблять и извлекать ценность из данных<\/p>\n<p><b>Этап 3: Лидерство на основе данных<\/b><br \/>\nНа этом этапе компания уже считается data-driven (все решения принимаются основываясь на данных). Автоматизированные потоки данных и системы разработанные дата инженерами позволяют сотрудникам проводить аналитику и ML самостоятельно. Подключение новых источников данных происходит бесшовно. Дата-инженеры внедрили меры мониторинга и практики для того чтобы данные были всегда доступны для потребителей и систем.<\/p>\n<p>На этом этапе зрелости данных дата-инженеры должны придерживаться следующего:<br \/>\n— Создавать автоматизации для бесшовной презентации и использования новых данных<br \/>\n— Сфокусироваться на построении кастомных инструментов и систем для извлечения ценности из данных как конкурентное преимущество<br \/>\n— Сконцентрируйтесь на аспектах данных, которые используются в больших корпорациях, например, управление данными, качество данных, data governance, DataOps<br \/>\n— Разверните инструменты, позволяющих проследить зависимости данных сквозь всю организацию, такие как каталог данных, data lineage, система по управлению метаданных<br \/>\n— Создайте сообщества, окружающую среду, где люди могут сотрудничать и говорить открыто независимо от занимаемой должности<\/p>\n<p>Проблемы с которыми можно столкнуться на данном этапе:<br \/>\n— Как только организация дошла до данного этапа она постоянно должна держать фокус на поддержке текущего уровня, продолжать улучшаться, чтобы нивелировать риск скатиться на этап ниже<br \/>\n— На этом этапе все больше соблазнов попробовать модные технологии, которые не принесут ценности бизнесу. Разрабатывайте кастомные технологии только если это будет вашим конкурентным преимуществом<\/p>\n<h2><b>Континуум ролей инженерии данных, от точки А до B<\/b><\/h2>\n<p>Зрелость данных служит полезным ориентиром для понимания вызовов, с которыми компания сталкивается в процессе своего роста. В зависимости от уровня зрелости компании ей могут понадобиться разные дата-инженеры для решения задач:<\/p>\n<p>— <b>Тип А<\/b>:<br \/>\nДата инженер типа А сосредоточен на абстракциях, использует готовые решения и управляет сервисами для упрощения архитектуры данных и избегает излишней сложности.<br \/>\n— <b>Тип B<\/b>:<br \/>\nДата-инженеры типа B сосредоточены на разработке собственных инструментов обработки данных и масштабируемых систем, опираясь на ключевые компетенции и конкурентные преимущества компании. Они часто встречаются в более зрелых организациях.<\/p>\n<p>Инженеры типов А и B могут работать вместе или быть одним и тем же человеком. Обычно компании начинают с найма инженеров типа А, а затем переходят к навыкам типа B по мере необходимости.<\/p>\n<h2><b>Дата-инженеры и другие технические роли<\/b><\/h2>\n<p>Дата-инженеры — это хаб между производителями данных, например, как software engineer, архитекторами данных, DevOps и потребителями данных, например, как аналитики данных, data scientists, ML инженеры.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Data-Engineers-and-other-techical-roles.jpg\" width=\"722\" height=\"323\" alt=\"\" \/>\n<\/div>\n<p><b>Производители данных:<\/b><br \/>\n<b>Архитекторы данных<\/b><br \/>\nАрхитекторы данных работают с высоким уровнем абстракции, имея большой инженерный опыт за плечами, они проектируют план для управления данными всей организации, связывая процессы компании и в целом архитектуру данных и систем. Они также являются неким мостом между техническими специалистами и заинтересованными лицами из бизнеса.<\/p>\n<p>Архитекторы данных ответственны за внедрение политик управления данными для разных департаментов, команд и бизнес юнитов всей организации. Они определяют глобальные стратегии по управлению данных и их контроля. Руководят основными инициативами, такими как миграция на облачные решения или проектирования облачной архитектуры.<\/p>\n<p>С появлением облачных сервисов архитекторы данных стали более гибкими по сравнению с традиционными on-premise системами. Решения для on-premise систем, которые требовали длительного планирования, контрактов на закупку, установки оборудования , сейчас принимаются в процессе реализации как один из этапов более широкой стратегии. Тем не менее, архитекторы данных остаются влиятельными визионерами в компаниях, тесно взаимодействуя с дата инженерами, чтобы определить большую общую картину архитектурных практик и стратегий по работе с данными.<\/p>\n<p>В зависимости от зрелости компании и ее размеров дата-инженеры могут забирать на себя обязанности архитектора данных. Поэтому дата инженер должен иметь отличное понимание лучших архитектурных практик и подходов.<\/p>\n<p><b>Software Engineers<\/b><br \/>\nSoftware engineers разрабатывают приложения и системы, которые позволяют бизнесу компании функционировать. В большинстве своем они ответственны за генерацию данных, которые являются для дата-инженеров одним из главных источников. Системы, которые разрабатывают software engineers обычно генерируют данные в виде событий приложения и логов, которые являются сами по себе очень полезным активом. Software engineers и дата-инженеры взаимодействуют начиная от старта нового проекта до проектирования данных приложения с целью потребления, обработки их для аналитики и ML сервисов.<\/p>\n<p>Дата-инженерам стоит тесно взаимодействовать с software engineers, чтобы понимать какого типа данные генерируют их приложения, какого объема, частоты, формата и все остальное что может повлиять на жизненный цикл данных, как например, безопасность и соответствие регуляторным требованиям.<\/p>\n<p><b>DevOps Engineers и SRE<\/b><br \/>\nDevOps и SRE часто создают данные через операционный мониторинг. Мы классифицируем их как производители данных для дата-инженеров, но они могут быть и потребителями данных от дата-инженеров, потребляя данные через дашборды или взаимодействуя с дата инженерами напрямую в координации работы системы данных.<\/p>\n<p><b>Потребители данных:<\/b><br \/>\n<b>Data Scientists<\/b><br \/>\nКак уже упоминалось, многие Data Scientists тратят 70-80% рабочего времени на сбор, очистку и подготовку данных, что свидетельствует о недостаточной развитости практик дата-инженерии в командах. Популярные фреймворки Data Science  могут стать узкими горлышками если их не масштабировать должным образом. Data Scientists, работающие на одной рабочей машине, вынуждены работать с небольшим по объему данными, тем самым значительно усложняя подготовку данных и потенциально идя на компромисс с качеством разрабатываемой модели. Кроме того, их написанный код и локальная среда окружения часто сложно развернуть в продакшен. Если дата-инженеры выполняют свою работу, то DSерам не нужно было бы тратить свое время на сбор, очистку и подготовку данных после первоначального анализа данных. Дата-инженеры должны максимально автоматизировать этот процесс.<\/p>\n<p>Потребность в данных, готовых к продакшен среде, — это значительный фактор почему профессия дата инженера существует. Работа дата инженеров обеспечить автоматизацию предоставления данных и их масштабирование, что делает проект Data Science более эффективным.<\/p>\n<p><b>Data Analysts<\/b><br \/>\nData Analysts сфокусированы на понимании эффективности бизнеса и его трендов, анализируя данные в прошлом и настоящем. Для аналитики они используют SQL в корпоративных хранилищах данных или озерах данных, Excel, инструменты визуализации такие как PowerBI, Tableau, Looker. Data Analysts обладают глубокой экспертизой в данных бизнес домена, понимая их происхождение, основные характеристики и метрики. Их основная работа заключается в предоставлении инсайтов бизнес домена для управляющих менеджеров с целью принятия стратегических решений.<\/p>\n<p>Дата-инженеры взаимодействуют с data analysts, чтобы обеспечить им доступ к новым источникам данных необходимых бизнесу. Экспертиза data analysts играет ключевую роль в улучшении качества данных. Работая с дата инженерами, они подсвечивают какие проблемы и неточности нужно исправить в данных.<\/p>\n<p><b>Machine Learning engineers<\/b><br \/>\nML инженеры тесно работают с дата инженерами и data scientistами, часто делят между собой задачи и обязанности. Основной фокус ML инженеров в разработке продвинутых методов машинного обучения, тренировке моделей, поддержка инфраструктуры для обеспечения работы ML процессов в масштабируемых продакшен средах. Помимо ML-фреймворков они часто работают с фреймворками глубокого обучения, такими как PyTorch и TensorFlow.<\/p>\n<p>ML инженеры обладают знаниями об оборудовании, сервисах и системах необходимых для работы ML фреймворков для обучения ML моделей и развертывания в продакшен среде. Они часто работают в облачных средах, где могут настроить и отмасштабировать инфраструктуру по мере необходимости. Сфера ML инженерии развивается быстрыми темпами с уклоном в MLOps, который заключается во внедрении лучших практик от software engineers и DevOps.<\/p>\n",
            "date_published": "2024-09-28T19:41:56+05:00",
            "date_modified": "2025-04-22T00:15:32+05:00",
            "tags": [
                "BigData",
                "Clouds",
                "IT",
                "Инженерияданных",
                "Книги"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/Fundamentals-of-Data-Engineering.jpg",
            "_date_published_rfc2822": "Sat, 28 Sep 2024 19:41:56 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "19",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/Fundamentals-of-Data-Engineering.jpg",
                    "https:\/\/slavlotski.com\/pictures\/data-engineering-sits-upstream-data-science.png",
                    "https:\/\/slavlotski.com\/pictures\/Data-Science-Hierarchy-of-Needs.png",
                    "https:\/\/slavlotski.com\/pictures\/data-maturity-stages.png",
                    "https:\/\/slavlotski.com\/pictures\/Data-Engineers-and-other-techical-roles.jpg"
                ]
            }
        },
        {
            "id": "20",
            "url": "https:\/\/slavlotski.com\/all\/dumay-bystro-govori-umno\/",
            "title": "Думай быстро, говори умно",
            "content_html": "<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/fJ_Dx9aSMrg?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p>Спонтанное общение составляет большую часть нашей повседневной коммуникации. По сравнению с публичными выступлениями, презентациями стартапа перед инвесторами или рабочими встречами, такие ситуации случаются значительно реже, чем спонтанные беседы, предоставление обратной связи или ответы на вопросы.<\/p>\n<p>Почему мы так волнуемся, когда нужно выступить перед аудиторией, даже на обычной встрече с коллегами, когда приходит наша очередь говорить? Почему это вызывает у нас дискомфорт? На эти и другие вопросы ответил Мэтт Абрахамс в 879 выпуске подкаста Luke’s English Podcast.<\/p>\n<p><b>Мэтт Абрахамс<\/b> — профессор престижной Стэнфордской высшей школы бизнеса, ведущий подкаста <a href=\"https:\/\/www.youtube.com\/watch?v=9FaqplylT0c&list=PL6caGRBUYZCmgDGM2RK6mxKB9jG_ccmm3\">“Think Fast, Talk Smart”<\/a> и автор книги <a href=\"https:\/\/mattabrahams.com\/books\/\">“Think Faster, Talk Smarter”<\/a>. Он является экспертом в области коммуникации и использует научно обоснованные методы для управления тревожностью, а также помогает делать ваш контент кратким, актуальным, запоминающимся и убедительным. Абрахамс консультирует частных клиентов с целью научить их презентовать себя публике, успешно проводить сессии вопросов и ответов, эффективно проходить собеседования, предоставлять качественную обратную связь и вести спонтанные разговоры.<\/p>\n<p>Основные сложности, с которыми сталкиваются люди при общении на неродном языке, заключаются в следующем:<br \/>\n1) Волнение. Многие испытывают нервозность, стремясь говорить правильно, пытаясь избежать ошибок в грамматике, синтаксисе и произношении. Независимо от того, на каком языке вы говорите, находясь перед группой людей у вас наверняка возникнет страх, страх потерять свою репутацию или статус, и это вызывает тревогу, но на самом деле волнение — это естественная человеческая реакция данная природой.<br \/>\n2) Некоторые люди начинают думать, что если у них что-то не выходит, то они просто не рождены для этого. Однако это совершенно неправда.<\/p>\n<p>У некоторых людей при волнении учащается сердцебиение и появляется комок в горле — это абсолютно нормально. Так тело реагирует на предполагаемую угрозу, активируя инстинкт «бей или беги». Дрожь в теле — это признак выброса адреналина, который помогает подготовить организм к действиям, направленным на перемещение от угрозы к безопасности. Некоторые люди начинают краснеть или потеть, что связано с повышением температуры тела, это та же реакция, которая происходят с нами во время физической активности в спортзале.<\/p>\n<p>Хорошая новость в том, что с волнением можно справиться. Один из самых полезных советов для людей, говорящих на иностранном языке, который Мэтт Абрахамс когда-либо слышал, заключается в том, что их цель не должна быть в том, чтобы звучать как носитель языка, а в том, чтобы эффективно транслировать свои идеи. Когда человек перестает стремиться быть как носитель языка, ему становится гораздо проще донести свои мысли.<\/p>\n<p><b>Глубокие вдохи и выдохи<\/b><br \/>\nОдин из самых эффективных способов справиться с волнением — это глубокие вдохи и выдохи.<\/p>\n<p><b>Холодный предмет<\/b><br \/>\nЧтобы снизить температуру тела и избавиться от покраснения, достаточно держать в руках холодный предмет. Вы, вероятно, замечали, как холодным утром держите горячую чашку чая, чтобы согреться, обратное нужно делать когда вам слишком жарко.<\/p>\n<p><b>Влияние позы тела<\/b><br \/>\nПри волнении часто хочется принять закрытую позу, словно защититься, но лучше встать прямо, расправить плечи и занять открытую, уверенную позу. Когда тело занимает больше пространства — выпрямлена спина, расправлены плечи, руки и ноги не скрещены — это помогает почувствовать себя более уверенно.<\/p>\n<p><b>Ресурсы мозга ограничены<\/b><br \/>\nМногие люди, говорящие на иностранном языке, пытаются выучить презентацию наизусть перед выступлением, но это не работает. Человеческий мозг можно сравнить с компьютером с его ограниченными ресурсами, такими как процессор и оперативная память. Когда на вашем ноутбуке открыто много окон, каждое из них начинает работать медленнее. Чтобы справиться с волнением, нужно перестать сосредотачиваться на том, как вы говорите или насколько точно следуете тексту. Закрыв все “окна” рабочего стола, вы высвободите ресурсы для передачи ваших мыслей. Снизив давление, вы сможете больше сосредоточиться на взаимодействии с людьми.<\/p>\n<p><b>Настрой на использование возможностей<\/b><br \/>\nМногие люди когда кто-то задает им вопрос или просят дать обратную связь, подходят к таким ситуациям с ощущением угрозы, как будто бы это проверка, чувствуют, что их тестируют. Как правило мы в такие моменты замыкаемся в себе. Однако если рассматривать такие ситуации как на возможности установления связей, обучения, сотрудничества — это изменит все. Один из способов добиться этого — это образ мышления через развитие. <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Дуэк,_Кэрол\">Кэрол Дуэк<\/a> — автор данного образа мышления, говорит, что если нам нужно чему-то научиться, то мы можем подойти к этому с мыслью: “Я способен это освоить, это возможно.” или же мы можем сказать себе: “Это не для меня, я не такой человек, я такой, какой есть, и не могу измениться.”<\/p>\n<p><b>Мантра «пока нет»<\/b><br \/>\nЧасть исследований Кэрол демонстрируют, что если у человека что-то не получается в общении или его начинаниях и он начинает думать «он проклят или у него никогда это не получится», вместо этого достаточно говорить себе «Пока нет. Я еще недостаточно освоил этот навык» — эта мантра оказывает мощное воздействие. Мантра «пока нет» позволяет мыслить в позитивном русле, что помогает достигать успехов в коммуникации и не только.<\/p>\n<p><b>Многие из нас боятся совершать ошибки<\/b><br \/>\nМы учимся на ошибках, для Абрахамса mistake — это не ошибка, а «miss take» — упущенная попытка. При съемках кино кинорежиссер делает множество дублей сцен и среди них выбирает лучшие, так вот дубли — это попытки снять кино лучше, тоже самое и с ошибками, ошибки — это часть пути в обучении, попытки сделать лучше, принимая во внимание накопленный опыт. Как-то известный виолончелист <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Ма,_Йо_Йо\">Йо Йо Ма<\/a> сказал:<\/p>\n<blockquote>\n<p>«Музыка остается для меня неживой до тех пор пока я не допущу свою первую ошибку».<\/p>\n<\/blockquote>\n<p>Из данной цитаты можно сделать следующие выводы:<br \/>\n1) Йо Йо Ма делает ошибки, тем самым показывает, что он живой человек<br \/>\n2) А также ищет и признает ошибки<\/p>\n<p><b>Быть хорошим слушателем<\/b><br \/>\nЧасто в беседах мы концентрируемся на себе, много говорим, но мало уделяем внимание собеседнику. Важно улавливать суть того что говорит собеседник. Для того чтобы быть хорошим слушателем нужно попробовать перефразировать то что человек имел в виду. Это позволяет проверить правильно ли мы поняли услышанное и демонстрирует, то что его слушают и ему становится приятно от этого.<\/p>\n<p><b>Структура «О чем говорим? Почему это важно? И что мы можем сделать с этой информацией дальше?»<\/b><br \/>\nМногие из нас, когда мы говорим, просто перечисляют информацию без какой либо структуры и это очень сложно для восприятия. Чтобы мозгу стало легче воспринимать нужно упаковать ваши мысли в структуру. Структура — это логическая связь ваших мыслей.  Каждый из вас кто видел рекламу на ТВ мог заметить следующую структуру: проблема, решение, выгода. Также существуют много других структур эффективного выстраивания ваших мыслей, одна из них состоит в том, что нужно задать себе 3 вопроса:  О чем говорим? Почему это важно? И что мы можем сделать с этой информацией дальше? Исследования показали, что при транслировании информации таким образом позволит окружающим запомнить содержимое гораздо лучше.<\/p>\n<p><b>Слова паразиты<\/b><br \/>\nМэтт на протяжении 50 минут своего выступления — <a href=\"https:\/\/www.youtube.com\/watch?v=HAnw168huqA&t=0s\">мастеркласс о техниках коммуникации, самопрезентации<\/a> в Стэнфордской школе не использовал ни разу ни одного слова паразита. Почему мы используем слова паразиты в нашей речи? Родители, когда учат своих детей говорить, используют слова паразиты, чтобы привлечь внимание ребенка. Для взрослых слова паразиты используются для старта новой мысли. Например, если вы закончили мысль и хотите продолжить, то используйте слова паразиты — это позволит держать контроль над беседой, чтобы вас никто не мог перебить и внезапно начать говорить.<\/p>\n<p><b>Что нам стоит ждать в будущем?<\/b><br \/>\nТехнологии уже и сейчас сильно влияют на то как мы коммуницируем. Стоит ждать больших изменений благодаря генеративным моделям ИИ как ChatGPT. Студенты уже сейчас используют ChatGPT для генерации вопросов для Q&A сессии после получения презентации лекции. Люди, изучающие иностранные языки, могут использовать его для проверки или помощи с  грамматикой языка или предложить идеи как они могут использовать изучаемую грамматику в своей речи.<\/p>\n",
            "date_published": "2024-09-22T23:52:37+05:00",
            "date_modified": "2024-09-23T11:53:59+05:00",
            "tags": [
                "Английский",
                "Коммуникация",
                "Саморазвитие"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/remote\/youtube-fJ_Dx9aSMrg-cover.jpg",
            "_date_published_rfc2822": "Sun, 22 Sep 2024 23:52:37 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "20",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-fJ_Dx9aSMrg-cover.jpg"
                ]
            }
        },
        {
            "id": "18",
            "url": "https:\/\/slavlotski.com\/all\/sien-festival-05-07-2024\/",
            "title": "Sien Festival 05.07.2024",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/sien-festival.png\" width=\"225\" height=\"225\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.instagram.com\/sien.festival\/\">instagram.com<\/a><\/div>\n<\/div>\n<p>05.07.2024 я по приглашению от <a href=\"https:\/\/soundcloud.com\/djbokeh\">bokeh<\/a> посетил фестиваль электронной музыки Sien, который организовывал коллектив <a href=\"https:\/\/www.instagram.com\/zvuk_collective\/\">Zvuk<\/a>.<br \/>\nФестиваль <b>Sien<\/b> позиционирует себя как мультикультурный, изобретательный, открытый для всех и любопытный ко всему фестиваль, выражающий себя через музыку, технологии, танцы, эксперименты и перформансы. Сам фестиваль проводится в 4 дня, но мы посетили лишь второй день, где планировался рейв с привозом зарубежных диджеев и местных артистов.<\/p>\n<p>К слову о диджеях из представленного line-up я не знал никого, но как мы помним по <a href=\"https:\/\/slavlotski.com\/all\/bardak-x-shu-lama-08-04-2023\/\">рейву от SHU[LAMA]<\/a> меня это нисколько не остановило.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/time-line.jpg\" width=\"570\" height=\"713\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Тайм-лайн выступления артистов. Источник: <a href=\"https:\/\/www.instagram.com\/sien.festival\/\">instagram.com<\/a><\/div>\n<\/div>\n<h2>Место проведения и организация<\/h2>\n<p>В качестве места проведения организаторы выбрали зону отдыха <a href=\"https:\/\/www.instagram.com\/balyqty.bulaq\/\">Balyqty Bulaq<\/a>, где в обычное время можно попариться в баньке, прокатиться на лошадях, половить форель, попробовать кумыс и расположиться в юртах. Зона отдыха находится в 15 минутах на такси от центра Алматы и представляет из себя открытое пространство рядом с горами.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/sien-festival-05-07-2024.png\" width=\"816\" height=\"612\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/2gis.kz\/almaty\/gallery\/firm\/70000001061416967\/photoId\/30258560076015455\">2GIS<\/a><\/div>\n<\/div>\n<p>Приехали мы к 21:00 и уже тогда шел небольшой дождь, но мы ребята опытные, подготовились и оделись в теплую одежду. По приезде я сразу обратил внимание, что на зоне отдыха много мест, где можно посидеть, перекусить или выпить чего-нибудь бодрящего, а также важное два туалета. Ознакомившись с обстановкой  на улице и вооружившись водой мы пошли искать сцены их было 3:<\/p>\n<ol start=\"1\">\n<li>Техно сцена<\/li>\n<li>Хаус сцена<\/li>\n<li>Экспериментальная музыка и селекторы<\/li>\n<\/ol>\n<p>К слову техно сцену мы нашли быстро, так как оттуда доносились звуки прямой 1\/4 бочки, туда мы и направились первым делом.<\/p>\n<h2>Выступления артистов<\/h2>\n<p>Техно сцена разместилась под шатром с некоторой инсталляцией в виде свисающих змей, дымовой машиной и неоновой подсветкой. Все в традиционной камерной атмосфере. По звуку было все хорошо, высокие не свистят, низкие не гудят. Первой по тайм-лайну выступала <b>Mariya El<\/b><\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/utvZ5aWksn4?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mariya El — 1<\/div>\n<\/div>\n<p><b>Mariya El<\/b> местами выдавала классные треки, но она открывающий диджей и уже несется такое техно как будто бы уже пик тайм вечеринки и конечно много смешения разных жанров привело к разной энергии на танцполе.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/6SFthFBEhW8?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mariya El — 2<\/div>\n<\/div>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/djbokeh\">bokeh<\/a> в Алмате не знают что такое warm up, у них всегда техно с 140+ BPM на открытии :D<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/8TjFtU_WIdI?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mariya El — 3<\/div>\n<\/div>\n<p>А пока <b> Mariya El<\/b> рубит техно в 21:00 по-местному времени мы решили пойти посмотреть две другие сцены.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/gcMIBYeOiBA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Akkujava<\/div>\n<\/div>\n<p>Хаус сцена полностью была open-air, что потом с ней сыграло злую шутку. Там играл прикольный хаус, который больше подходил под открытие мероприятия.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/zTxVgVVXUzo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">DekmantelSoundSystem<\/div>\n<\/div>\n<p>Ближе к 00:00 начал идти сильный дождь и все мигом разбежались с хаус сцены на техно сцену или укрываться под навесами, но благо ливень быстро закончился и мы продолжили зависать на хаус сцене пока не начали играть хэдлайнеры.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/oNls4H0J_zE?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Bismildin<\/div>\n<\/div>\n<p>Что относительно экспериментальной сцены, то она расположилась в самой настоящей традиционной казахской юрте, где можно было посидеть, перевести дух с техно сцены.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/8IPupryc9TA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Johannes Astrup — 1<\/div>\n<\/div>\n<p>И вот в полночь начинается жара, выходит первый хэдлайнер <b>Johannes Astrup<\/b>. Его уникальный стиль характеризуется быстрым техно с богатыми слоями ритма и перкуссии, а также включает в себя элементы грува и даже сальсы.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/0kM-fqm_oHo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Johannes Astrup — 2<\/div>\n<\/div>\n<p>Нетипичный прикид, улыбка на лице и танцы от Йоханнеса заряжают весь танцпол<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/3f3GgJtpUyg?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Johannes Astrup — 3<\/div>\n<\/div>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/wwb7iZNcuao?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Johannes Astrup — 4<\/div>\n<\/div>\n<p>Следующим за Johannes выступает француз <b>Mac Declos<\/b>. Уже в 19 лет он получил возможность выступить по-крупному на фестивалях Nördik Impakt и Astropolis. На счету музыканта выступления в Berghain, Fuse, HÖR, PAL, Rex Club и на множестве других именитых площадок Европы. И можно сразу сказать он отменный диджей, умеет круто сводить треки и использовать эффекты по полной. Мой персональный фаворит.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/8yLZAP0NyVo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mac Declos — 1<\/div>\n<\/div>\n<p>Послушайте как он виртуозно использует вокальный семпл и подмешивает его с другим треком в лайв режиме, джог при выходе из ямы. Просто класс!<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/O-sfQ4a_t4A?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mac Declos — 2<\/div>\n<\/div>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/QmOXGKnkgVw?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mac Declos — 3<\/div>\n<\/div>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/Dkcv5Jyuvp0?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mac Declos — 4<\/div>\n<\/div>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/BXJW240_a2E?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Mac Declos — 5<\/div>\n<\/div>\n<p>Следом за французом выступает <b>Neri J <\/b>— основательница Vortex parties и резидентка Den Anden Side. Тяжёлые удары с высокой интенсивностью и безостановочной подачей — вот отличительные черты одной из самых ярких звёзд копенгагенского андеграунда, которая выпускается и тесно сотрудничает с потрясающим лейблом <b>BunkerBauer<\/b>.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/GvtpQE8CdlA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Neri J  — 1<\/div>\n<\/div>\n<p>С <b>Neri J<\/b> пошел крутой техно-транс и я решил устроить съемку с ракурса позади диджея :D<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/efsyTCDnWck?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Neri J  — 2<\/div>\n<\/div>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/NgZMCkJoGpI?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Neri J  — 3<\/div>\n<\/div>\n<p>Один из закрывающих треков я впервые услышал lead партию за все мероприятие и как же он хорошо зашел после нескольких часов одного грува, перкусий и драмсов, потрясающие эмоции!<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/A7zjaZiJ9u0?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<div class=\"e2-text-caption\">Neri J  — 4<\/div>\n<\/div>\n<p>Это был последний диджей кого мы полноценно послушали.<\/p>\n<h2>Итого<\/h2>\n<p>Я получил одно удовольствие вновь оказаться в атмосфере танцующих людей в камерном помещении с крутой музыкой и хорошей организацией мероприятия. Еще раз проверил на прочность свои кастомные беруши, и они вновь показали себя с лучшей стороны. Спасибо <a href=\"https:\/\/soundcloud.com\/djbokeh\">bokeh<\/a> за приглашение, надо будет обязательно повторить!<\/p>\n",
            "date_published": "2024-07-06T21:32:09+05:00",
            "date_modified": "2024-07-07T21:09:22+05:00",
            "tags": [
                "Музыка",
                "рейв",
                "техно",
                "Транс"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/sien-festival.png",
            "_date_published_rfc2822": "Sat, 06 Jul 2024 21:32:09 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "18",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/sien-festival.png",
                    "https:\/\/slavlotski.com\/pictures\/time-line.jpg",
                    "https:\/\/slavlotski.com\/pictures\/sien-festival-05-07-2024.png",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-utvZ5aWksn4-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-6SFthFBEhW8-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-8TjFtU_WIdI-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-gcMIBYeOiBA-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-zTxVgVVXUzo-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-oNls4H0J_zE-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-8IPupryc9TA-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-0kM-fqm_oHo-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-3f3GgJtpUyg-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-wwb7iZNcuao-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-8yLZAP0NyVo-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-O-sfQ4a_t4A-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-QmOXGKnkgVw-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-Dkcv5Jyuvp0-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-BXJW240_a2E-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-GvtpQE8CdlA-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-efsyTCDnWck-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-NgZMCkJoGpI-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-A7zjaZiJ9u0-cover.jpg"
                ]
            }
        },
        {
            "id": "16",
            "url": "https:\/\/slavlotski.com\/all\/apache-airflow\/",
            "title": "Apache Airflow",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-airflow-1.png\" width=\"1812\" height=\"700\" alt=\"\" \/>\n<\/div>\n<h2>Предпоссылки создания Apache Airflow<\/h2>\n<p>В 2014 году компания Airbnb стремительно развивалась, что привело к увеличению объема данных и усложнению рабочих процессов обработки данных. Управление этими сложными конвейерами данных с помощью традиционных инструментов, таких как Cron и пользовательские скрипты, стало нецелесообразным из-за недостаточной масштабируемости, гибкости и возможностей мониторинга. Airbnb требовалось решение, которое могло бы масштабироваться в соответствии с растущими потребностями в данных.Им требовалось отслеживать состояния рабочих процессов и возможность эффективно отлаживать сбои. Инициатива со стороны <a href=\"https:\/\/www.linkedin.com\/in\/maximebeauchemin\/\">Maxime Beauchemin<\/a> привела к созданию масштабируемого, гибкого и удобного инструмента управления рабочими процессами под названием Airflow. Сделав Airflow open-sourceным и наладив взаимодействие с сообществом, Airbnb не только решила свои внутренние проблемы, но и предоставила мощный инструмент широкому сообществу разработчиков. Сегодня Apache Airflow широко используется в различных отраслях индустрии для организации сложных рабочих процессов и конвейеров данных.<\/p>\n<p><b>Apache Airflow<\/b> — фреймворк для построения конвейров обработки данных. Airflow сам по себе не является инструментом обработки данных. Он управляет различными компонентами, которые отвечают за обработку ваших данных в конвейерах. Ключевая особенность Airflow заключается в том, что он позволяет легко создавать конвейеры обработки данных, запускаемых по расписанию с помощью языка Python.<\/p>\n<h2>Какие задачи решает Airflow?<\/h2>\n<ol start=\"1\">\n<li><b>Оркестрация рабочих процессов:<\/b> Airflow позволяет управлять зависимостями между задачами, обеспечивая их выполнение в нужном порядке<\/li>\n<li><b>Планирование задач:<\/b> С помощью Airflow можно запланировать выполнение задач по заданному расписанию<\/li>\n<li><b>Мониторинг и управление задачами: <\/b>Airflow предоставляет интерфейс для отслеживания выполнения задач, просмотра логов и управления задачами в реальном времени<\/li>\n<li><b>Интеграция с различными системами:<\/b> Airflow может взаимодействовать с различными источниками данных и системами, такими как базы данных, облачные сервисы, API и другие.<\/li>\n<li><b>Автоматизация процессов:<\/b> Airflow помогает автоматизировать повторяющиеся процессы, что снижает ручной труд и минимизирует ошибки.<\/li>\n<li><b>Логирование и отслеживание изменений:<\/b> Airflow сохраняет логи выполнения задач, что помогает в отладке и анализе процессов.<\/li>\n<\/ol>\n<h2>Кому подойдет Airflow<\/h2>\n<p>— Для планирования задач, где возможностей Cron стало недостаточно<br \/>\n— У команды уже есть достаточная экспертиза в программировании на Python<br \/>\n— На проекте используется пакетная обработка данных (Batch), а не потоковая (Stream). AirFlow предназначен для Batch-заданий, для потоковой обработки данных лучше использовать Apache NiFi<br \/>\n— Планируется или уже осуществлен переход в облако и необходим надежный оркестратор, поддерживающий все принципы Cloud-Native<\/p>\n<h2>Конвейеры обработки данных в виде графов<\/h2>\n<p>Конвейер обработки данных легко представить в виде графа. В математике граф представляет собой конечный набор узлов с вершинами, соединяющими узлы. В контексте разработки каждый узел в графе представляет собой задачу, а зависимостями между задачами — направленные ребра между узлами. Ребро, направленное от задачи A к задаче B, указывает, что задача A должна быть завершена до того, как может начаться задача B. Такие графы обычно называются ориентированными, или направленными, потому что ребра имеют направление.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/directed-acyclic-graph.png\" width=\"223\" height=\"183\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Пример ациклического направленного графа. Источник: <a href=\"https:\/\/airflow.apache.org\/docs\/apache-airflow\/stable\/index.html\">airflow.apache.org<\/a><\/div>\n<\/div>\n<p>Данный тип графа обычно называется ориентированным ациклическим графом, поскольку он содержит ориентированные ребра и у него нет никаких петель или циклов (ациклический).<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/directed-cyclic-graph.png\" width=\"397\" height=\"227\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Пример циклического направленного графа<\/div>\n<\/div>\n<h2>Анатомия DAG в Airflow<\/h2>\n<p><b>DAG (Directed Acyclic Graph)<\/b> — направленный ациклический граф необходимый для смыслового объединения изолированных задач, которые необходимо выполнить в строго определенной последовательности согласно указанному расписанию. Задачами же в терминологии Airflow называют <b>Task<\/b>. Под задачами понимается, например, загрузка из различных источников, их агрегирование, очистка от дубликатов, сохранение полученных результатов и прочие ETL-процессы. На уровне кода задачи представляют собой Python-функции или Bash-скрипты в терминологии Airflow их называют <b>Operator<\/b>.<\/p>\n<p><b>Task<\/b> — это внутренние компоненты для управления состоянием <b>operator<\/b> и отображения изменений состояния (например, запущено\/завершено) для пользователя. Task управляет выполнением оператора.<\/p>\n<p><b>Operator<\/b> — отвечает за выполнение одной единицы работы. Операторы — это некие готовые шаблоны, которые можно переиспользовать, реализующие логику выполнения (запуск скрипта, команды, обращение к СУБД) с набором параметров на входе. В AirFlow богатый выбор встроенных операторов. Кроме этого, доступно множество специальных операторов — путем установки пакетов поставщиков, поддерживаемых сообществом. Также возможно добавление пользовательских операторов — за счет расширения базового класса BaseOperator.<\/p>\n<p><b>Sensor<\/b> — это особая группа операторов, которые позволяют в случае наступления определенного события запустить выполнение следующих по зависимости задач. В качестве триггера могут выступать получение некоторого файла, готовность данных на источнике и так далее.<\/p>\n<p>Так как Airflow оперирует языком Python, то у класса <b>DAG<\/b> могут быть свои экземпляры. В Airflow экземплярами DAGа называют <b>DAG Run<\/b>, связанные с этим DAGом экземляры задач — <b>task Instance<\/b>, а время запуска этих DAGов — <b>execution_date<\/b> (в более поздних версиях Airflow <b>logical_date<\/b>).<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/main-definitions-airflow.png\" width=\"1024\" height=\"564\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Визуализация DAGа. Источник: <a href=\"https:\/\/cloud.vk.com\/blog\/airflow-what-it-is-how-it-works\">cloud.vk.com<\/a><\/div>\n<\/div>\n<h2>Архитектура Airflow и принципы его работы<\/h2>\n<p><b>Web Server <\/b>— компонент, который позволяет визуализировать зависимости в Airflow, анализируемые планировщиком, и предоставляет пользователям основной интерфейс для отслеживания выполнения графов и их результатов. Помимо этого представления, Airflow также предоставляет подробное древовидное представление, в котором показаны все текущие и предыдущие запуски соответствующего DAG. Также здесь приводится беглый обзор того, как работал DAG, и оно позволяет покопаться в задачах, завершившихся сбоем, чтобы увидеть, что пошло не так.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/web-server-apache-airflow.jpg\" width=\"2560\" height=\"1540\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Web UI Airflow. Источник: <a href=\"https:\/\/airflow.apache.org\/docs\/apache-airflow\/2.0.2\/ui.html\">airflow.apache.org<\/a><\/div>\n<\/div>\n<p><b>Metadata DB (база метаданных)<\/b> — собственный репозиторий метаданных на базе библиотеки SqlAlchemy для хранения глобальных переменных, настроек соединений с источниками данных, статусов выполнения Task Instance, DAG Run и так далее. Хранит состояния <b>scheduler<\/b>, <b>executor<\/b> и <b>веб-сервера<\/b>. Требует установки совместимой с SqlAlchemy базы данных, например, MySQL или PostgreSQL.<\/p>\n<p><b>Scheduler (планировщик)<\/b> — служба, отвечающая за планирование в Airflow и отправку задания на исполнение. Отслеживая все созданные Task и DAG, планировщик инициализирует Task Instance — по мере выполнения необходимых для их запуска условий. По умолчанию раз в минуту планировщик анализирует результаты парсинга директории dags и проверяет, нет ли задач, готовых к запуску.Если все в порядке,то начинает планировать задачи DAG для выполнения, передавая их <b>воркерам<\/b> Airflow. Для выполнения активных задач планировщик использует указанный в настройках <b>Executor<\/b>. Для определенных версий БД (PostgreSQL 9.6+ и MySQL 8+) поддерживается одновременная работа нескольких планировщиков — для максимальной отказоустойчивости.<\/p>\n<p><b>Executor (исполнитель)<\/b>— часть scheduler, механизм, с помощью которого запускаются экземпляры задач. Работает в связке с планировщиком в рамках одного процесса.<\/p>\n<p><b>Worker (рабочий) <\/b>— отдельный процесс, в котором выполняются запланированные задачи. Размещение Worker — локально или на отдельной машине — определяется выбранным типом Executor. Допускается неограниченное число DAG за счет модульной архитектуры и очереди сообщений. Worker могут масштабироваться при использовании Celery или Kubernetes.<\/p>\n<p><b>DAG Directory<\/b> — каталог исполняемых DAGов для остальных компонентов Airflow<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/airflow-architecture.gif\" width=\"1200\" height=\"1500\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Архитектура Apache Airflow. Источник: <a href=\"https:\/\/www.linkedin.com\/posts\/activity-7220392622278795266-4d0t?utm_source=share&utm_medium=member_desktop\">linkedin.com<\/a><\/div>\n<\/div>\n<h2>Концепция планирования в Airflow<\/h2>\n<p><b>Выполнение работы с фиксированными интервалами<\/b><br \/>\nДля многих рабочих процессов, включающих временные процессы, важно знать, в течение какого временного интервала выполняется данная задача. По этой причине Airflow предоставляет задачам дополнительные параметры, которые можно использовать, чтобы определить, в каком интервале выполняется задача. Самый важный из этих параметров — <b>execution_date<\/b>, который обозначает дату и время, в течение которых выполняется <b>DAG<\/b>.  <b>execution_date<\/b> (начиная с версии Airflow версии 2.2 <b>logical_date<\/b>) — это не дата, а временная метка, отражающая время начала интервала, для которого выполняется DAG. Время окончания интервала указывается другим параметром, <b>next_execution_date<\/b> (<b>data_interval_end<\/b> в поздних версиях Airflow 2). Вместе эти даты определяют всю продолжительность интервала задачи.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/execution_date-explain.jpg\" width=\"590\" height=\"195\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Объяснение интервалов в DAG. Источник: <a href=\"https:\/\/www.labirint.ru\/books\/834612\/\">Книга. Apache Airflow и конвейеры обработки данных<\/a><\/div>\n<\/div>\n<p>Предположим, что у нас есть DAG, который следует ежедневному интервалу, а затем учитывает соответствующий интервал, в котором должны обрабатываться данные за 2019-01-03. В Airflow этот интервал будет запускаться вскоре после 2019-01-04:00:00, потому что в данный момент мы знаем, что больше не будем получать новые данные за 2019-01-03. Значение переменной <b>execution_date<\/b> при выполнении задач будет 2019-01-03. Это связано с тем, что Airflow определяет дату выполнения DAG как начало соответствующего интервала. Дата выполнения отмечает интервал, а не момент фактического выполнения DAG.<\/p>\n<p><b>Запуск через равные промежутки времени<\/b><br \/>\nAirflow можно запускать через равные промежутки времени, задав для него запланированный интервал с помощью аргумента <b>schedule_interval<\/b> при инициализации DAG.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">dag = DAG(\r\ndag_id=&quot;dag_1&quot;, schedule_interval=&quot;@daily&quot; &lt;-- Планируем запуск каждый день в полночь\r\n, start_date=dt.datetime(2019, 1, 1) &lt;-- Дата и время начала планирования запусков DAG\r\n... )<\/code><\/pre><p>Airflow также нужно знать, когда мы хотим начать выполнение DAG, указав дату запуска. Исходя из этой даты, Airflow запланирует первое выполнение нашего DAG. Airflow запускает задачи в конце интервала. Если разработанный DAG вывели на продуктив 1 января 2019 года в 14:00 с start_date — 01-01-2019 и интервалом @daily, то это означает, что первый DAG Run случится в полночь 02-01-2019:00:00.<\/p>\n<p><b>Интервалы на основе Cron<\/b><br \/>\nДля поддержки более сложных вариантов Airflow позволяет определять интервалы, используя тот же синтаксис, что и у <b>cron<\/b> — планировщика заданий на основе времени, используемого Unix-подобными операционными системами, такими как macOS и Linux. Достаточно указать crontab выражение в аргументе <b>schedule_interval<\/b> при инициализации DAGа.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">from airflow.models.dag import DAG\r\nimport datetime\r\n\r\ndag = DAG(&quot;regular_interval_cron_example&quot;, schedule=&quot;0 0 * * *&quot;, ...) &lt;-- задача будет регулярно запускаться в полночь<\/code><\/pre><p><b>Частотные интервалы<\/b><br \/>\nЕсли мы хотим запускать наш DAG раз в три дня, то в качестве интервала можно передать экземпляр timedelta (из модуля datetime в стандартной библиотеке Python) в <b>schedule_interval<\/b>.<br \/>\n— timedelta(minutes=10) каждые 10 минут<br \/>\n— timedelta(hours=2) каждые 2 часа<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">dag = DAG(\r\ndag_id=&quot;dag_3&quot;, schedule_interval=dt.timedelta(days=3),\r\n......)<\/code><\/pre><h2>Правила триггеров<\/h2>\n<p><b>Правила триггеров <\/b>— это, по сути, условия, которые Airflow применяет к задачам, чтобы определить, готовы ли они к выполнению, ориентируясь на их зависимости. Правило триггеров по умолчанию — это <b>all_success<\/b>, которое гласит, что все зависимости задачи должны быть успешно завершены, прежде чем саму задачу можно будет выполнить.<\/p>\n<p>А что произойдет, если одна из наших задач обнаружит ошибку во время исполнения? Это означает, что нижестоящую задачу уже нельзя выполнить, поскольку для ее успешного выполнения необходима успешное выполнение предшествующей задачи и она примет статус <b>upstream_failed<\/b>. Более подробно со статусами задач можно ознакомиться в <a href=\"https:\/\/airflow.apache.org\/docs\/apache-airflow\/stable\/core-concepts\/tasks.html\">официальной документации Airflow<\/a>.<\/p>\n<p>Airflow поддерживает и другие правила триггеров, которые допускают различные типы поведения при ответе на успешные, неудачные или пропущенные задачи. Правило <b>none_failed<\/b> означает, что оно допускает как успешные, так и пропущенные задачи, по-прежнему ожидая завершения всех вышестоящих задач, перед тем как продолжить. Например, правило <b>all_done<\/b> можно использовать для определения задач, которые завершили свое выполнение независимо от их конечного состояния. Более подробно об остальных правилах можно познакомиться в <a href=\"https:\/\/airflow.apache.org\/docs\/apache-airflow\/stable\/core-concepts\/dags.html#trigger-rules\">официальной документации Airflow<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/trigger-rules.png\" width=\"1098\" height=\"172\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Web UI статусов задач. Источник: <a href=\"https:\/\/airflow.apache.org\/docs\/apache-airflow\/stable\/core-concepts\/dags.html#trigger-rules\">airflow.apache.org<\/a><\/div>\n<\/div>\n<h2>Запуск задачи после определенного действия<\/h2>\n<p>Действия, связанные с запуском, часто являются результатом внешних событий. Представьте себе файл, который публикуется на общий диск, готовность данных за конкретную дату во внешней БД и т. д. Для решения подобных задач используют <b>сенсоры<\/b>, представляющие собой особый тип (подкласс) операторов. Сенсоры непрерывно опрашивают определенные условия, чтобы определить их истинность, и если условие истинно, то сенсор завершает свою работу со статусом успешно. В противном случае сенсор будет ждать и повторять попытку до тех пор, пока условие не будет истинно, или время ожидания истечет.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">from airflow.sensors.filesystem import FileSensor\r\n\r\nwait_for_supermarket_1 = FileSensor(\r\ntask_id=&quot;wait_for_data&quot;, \r\nfilepath=&quot;data.csv&quot;,\r\n)<\/code><\/pre><p>Здесь <b>FileSensor<\/b> выполняет проверку на предмет наличия файла data.csv и возвращает true, если файл существует. В противном случае возвращается false, и сенсор будет ждать в течение заданного периода (по умолчанию 60 секунд) и повторит попытку.<\/p>\n<p>Вывод сенсоров можно посмотреть в логах задач:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">{file_sensor.py:60} INFO – Poking for file data.csv \r\n{file_sensor.py:60} INFO – Poking for file data.csv \r\n{file_sensor.py:60} INFO – Poking for file data.csv \r\n{file_sensor.py:60} INFO – Poking for file data.csv \r\n{file_sensor.py:60} INFO – Poking for file data.csv<\/code><\/pre><p>Здесь видно, что примерно раз в минуту сенсор осуществляет <b>покинг<\/b> на предмет наличия определенного файла. <b>Покинг<\/b> — так в Airflow называется запуск сенсора и проверка условия.<\/p>\n<p>Зачастую сенсоры добавляются в самое начало DAGа, так как мы хотим запустить последующие манипуляции с данными только в случае их готовности на источнике. Таким образом, сенсоры в начале DAG будут непрерывно выполнять опрос на предмет наличия данных и переходить к следующей задаче после выполнения условия.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/sensors-in-dag.png\" width=\"800\" height=\"281\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Web UI работы сенсоров. Источник: <a href=\"https:\/\/livebook.manning.com\/book\/data-pipelines-with-apache-airflow\/chapter-6\/v-6\/22\">livebook.manning.com<\/a><\/div>\n<\/div>\n<p>А что произойдет, если однажды один из источников не предоставит свои данные за ожидаемое время?  По умолчанию сенсоры будут падать, как и зависимые от них задачи со статусом <b>upstream_failed<\/b>. Сенсоры принимают аргумент <b>timeout<\/b>, который содержит максимальное количество секунд, в течение которого сенсор может работать. Если в начале очередного покинга количество секунд превысит число, заданное для <b>timeout<\/b>, то это приведет к падению сенсора.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/failed-sensors-apache-airflow.png\" width=\"800\" height=\"301\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Web UI упавших сенсоров по timeout. Источник: <a href=\"https:\/\/livebook.manning.com\/book\/data-pipelines-with-apache-airflow\/chapter-6\/v-6\/22\">livebook.manning.com<\/a><\/div>\n<\/div>\n<p>Количество задач (на разных уровнях), которые Airflow может обработать ограничено. Важно понимать, что в Airflow есть ограничения на максимальное параллельное количество выполняемых задач на разных уровнях; количество задач на каждый DAG, количество задач на глобальном уровне Airflow, количество запусков DAG на каждый DAG и т. д. У класса DAG есть аргумент <b>concurrency<\/b>, определяющий, сколько параллельных задач разрешено в рамках этого DAG. Таким образом каждый сенсор — это одна задача и в случае если у вас их много и значение <b>concurrency<\/b> меньше кол-ва сенсоров, то некоторые сенсоры будут простаивать и не запускать проверку своего условия, эти сенсоры будут ожидать пока освободится слот в DAGе, то есть пока не завершит свое выполнение один из ранее запустившихся сенсоров.<\/p>\n<p>Класс сенсора принимает аргумент <b>mode<\/b>, для которого можно задать значение <b>poke<\/b> или <b>reschedule<\/b> (начиная с Airflow версии 1.10.2). По умолчанию задано значение <b>poke<\/b>, что приводит к блокировке. Это означает, что задача сенсора занимает слот, пока выполняется. Время от времени она выполняет покинг, осуществляя проверку условия, а затем ничего не делает, но по-прежнему занимает слот. Режим сенсора <b>reschedule<\/b> освобождает слот после покинга, слот остается занят только когда выполняется проверка.<\/p>\n<h2>Запуск задач с помощью REST API и интерфейса командной строки<\/h2>\n<p>Запуск DAGов можно осуществлять через REST API и командную строку. Это может быть полезно, если вы хотите запускать рабочие процессы за пределами Airflow. Данные, поступающие в случайное время в бакет AWS S3, можно обрабатывать, задав лямбда-функцию для вызова REST API, запуская DAG, вместо того чтобы постоянно запускать опрос с сенсорами.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">airflow dags trigger dag1<\/code><\/pre><p>Этот код запускает dag1 с датой выполнения, установленной на текущую дату и время. Идентификатор запуска имеет префикс <b>manu­al__<\/b>, указывая на то, что он был запущен вручную или за пределами Airflow.<\/p>\n<p>Для обеспечения аналогичного результата можно использовать REST API (например, если у вас нет доступа к командной строки, но к вашему экземпляру Airflow можно подключиться по протоколу HTTP).<\/p>\n<h2>Преимущества и недостатки Airflow<\/h2>\n<p><b>Преимущества:<\/b><br \/>\n— Airflow — это фреймворк с открытым исходным кодом<br \/>\n— Конвейеры на основе кода обладают большими возможностями расширения. Преимущество того факта, что Airflow написан на языке Python, состоит в том, что задачи могут выполнять любую операцию, которую можно реализовать на Python. Со временем это привело к разработке множества расширений Airflow, позволяющих выполнять задачи в широком спектре систем, включая внешние базы данных, технологии больших данных и различные облачные сервисы, давая возможность создавать сложные конвейеры обработки данных, объединяющие процессы обработки данных в различных системах<br \/>\n— Конвейеры на основе кода более управляемы: поскольку все находится в коде, он может легко интегрироваться в ваш CI \/ CD управления версиями и общие рабочие процессы разработчика.<br \/>\n— Множество интеграций с разными системами<br \/>\n— Гибкий планировщик<br \/>\n— Возможность масштабирования<br \/>\n— Такие функции, как <b>обратное заполнение (backfill)<\/b>, дают возможность с легкостью (повторно) обрабатывать архивные данные, позволяя повторно вычислять любые производные наборы данных после внесения изменений в код;<br \/>\n— Многофункциональный веб-интерфейс Airflow обеспечивает удобный просмотр результатов работы конвейера и отладки любых сбоев, которые могут произойти<br \/>\n— Поддерживаются все принципы Cloud-Native<\/p>\n<p><b>Недостатки:<\/b><br \/>\n— Обработка потоковых конвейеров, поскольку Airflow в первую очередь предназначен для выполнения повторяющихся задач по пакетной обработке данных, а не потоковых рабочих нагрузок<br \/>\n— Реализация высокодинамичных конвейеров, в которых задачи добавляются или удаляются между каждым запуском конвейера. Хотя Airflow может реализовать такое динамическое поведение, веб-интерфейс будет показывать только те задачи, которые все еще определены в самой последней версии DAG. Таким образом, Airflow отдает предпочтение конвейерам, структура которых не меняется каждый раз при запуске<br \/>\n— Поддержка Airflow может быстро стать сложной в крупных проектах<br \/>\n— Высокий порог входа в фреймворк<\/p>\n",
            "date_published": "2024-06-30T20:23:16+05:00",
            "date_modified": "2024-09-03T22:38:29+05:00",
            "tags": [
                "Airflow",
                "BigData",
                "IT"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/apache-airflow-1.png",
            "_date_published_rfc2822": "Sun, 30 Jun 2024 20:23:16 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "16",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/apache-airflow-1.png",
                    "https:\/\/slavlotski.com\/pictures\/directed-acyclic-graph.png",
                    "https:\/\/slavlotski.com\/pictures\/directed-cyclic-graph.png",
                    "https:\/\/slavlotski.com\/pictures\/main-definitions-airflow.png",
                    "https:\/\/slavlotski.com\/pictures\/web-server-apache-airflow.jpg",
                    "https:\/\/slavlotski.com\/pictures\/airflow-architecture.gif",
                    "https:\/\/slavlotski.com\/pictures\/execution_date-explain.jpg",
                    "https:\/\/slavlotski.com\/pictures\/trigger-rules.png",
                    "https:\/\/slavlotski.com\/pictures\/sensors-in-dag.png",
                    "https:\/\/slavlotski.com\/pictures\/failed-sensors-apache-airflow.png"
                ]
            }
        },
        {
            "id": "15",
            "url": "https:\/\/slavlotski.com\/all\/apache-kafka\/",
            "title": "Apache Kafka",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka.png\" width=\"736\" height=\"335\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/nz.pinterest.com\/pin\/kafka-logo--268456827773589368\/?amp_client_id=CLIENT_ID%28_%29&amp_url=https%3A%2F%2Fwww.pinterest.nz%2Famp%2Fpin%2F268456827773589368%2F&mweb_unauth_id=%7B%7Bdefault.session%7D%7D&open_share=t\">pinterest.com<\/a><\/div>\n<\/div>\n<p><b>Message broker<\/b> — это тип построения архитектуры, при котором элементы системы «общаются» друг с другом с помощью посредника. Данная архитектура нужна чтобы доставлять сообщения из пункта А в пункт Б, причем мы предполагаем, что эти сообщения бесконечны. Таким образом потоковая передача данных отличается от пакетной  (пакетная рано или поздно завершится, имеет границы и ее можно разделить на эти границы). Message broker’ы активно используются в микросервисной архитектуре, где используется событийно-ориентированный подход. Преимуществами микросервиса над монолитным приложением являются низкая связь сервисов друг с другом, устойчивость приложений к сбоям за счет изоляции поставщиков (producer) и потребителей (consumer).<\/p>\n<p>Типы Message broker’ов:<br \/>\n— <b>point-to-point<\/b>, брокеры которые работают на принципе доставки сообщения в строгой последовательности в виде очереди, где одна система пишет сообщение по принципу first in\/ first out, другая очередь эти сообщения вычитывает. Примеры таких брокеров: ZeroMQ, nanomsg, Java Message service (JMS)<br \/>\n— <b>publish \/ subscribe<\/b> Есть некий producer, который публикует свои сообщения, есть так называемые потребители (consumer), которые эти сообщения получают именно по подписке. Строгая последовательность доставки сообщений не гарантируется. Системы с таким типом являются более масштабируемыми. Примеры таких брокеров: Celery, ActiveMQ, Apache Kafka, IBM MQ<\/p>\n<p>В терминалогии потоковых данных событие генерируется 1 раз инициатором, а затем обрабатываются различными потребителями. Инициаторов может быть много, кто передает эти данные, также и потребителей может быть много.<\/p>\n<p>Назначение Message broker:<br \/>\n— интеграция систем, написанные на разных языках программирования и протоколах<br \/>\n— гарантия надежного хранения<br \/>\n— гарантированная доставка<br \/>\n— масштабирование (как источников, так и потребителей)<br \/>\n— преобразование сообщений<\/p>\n<p><b>Apache Kafka<\/b> — это распределенная и легко масштабируемая система обмена сообщениями, написанная на Java и Scala, с высокой пропускной способностью, которая может в режиме реального времени обрабатывать большие объемы данных.  Kafka появилась из-за необходимости компании LinkedIn эффективно перемещать огромные количества сообщений — до нескольких терабайт в час.<\/p>\n<p>Верхнеуровнево Kafka состоит из:<br \/>\n— Broker<br \/>\n— ZooKeeper или KRaft<br \/>\n— Consumer<br \/>\n— Producer<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-1.png\" width=\"1560\" height=\"870\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<p><b>Broker<\/b> — это серверное программное обеспечение с доступом к своему локальному диску, в которое producer’ы записывают данные, а consumer’ы читают данные, Broker эти данные аккумулирует и правильно сохраняет. Apache Kafka кластер состоит из множества Broker’ов, которые объединены в одну сеть.<\/p>\n<p><b>ZooKeeper<\/b> — это распределенное файловой хранилище необходимое для достижения согласованного состояния и синхронизации Broker’ов. Благодаря ZooKeeper мы можем управлять кластером Kafka, добавлять новых пользователей, создавать топики, задавать им настройки, обнаруживать сбои и восстанавливать работу кластера, хранить конфигурацию и секреты, авторизационные данные и ограничения или Access Control Lists при работе консумеров и продюсеров с брокерами.<\/p>\n<p><b>Consumer<\/b> — это приложение, которое имеет модуль Kafka, с помощью которого оно может прочитать сообщение. Приложение-консумер подписывается на события и получает данные в ответ.<\/p>\n<p><b>Producer<\/b> — это приложение, которое имеет модуль Kafka, с помощью которого оно может записать событие (сообщение) в кластер Kafka. Кластер сохраняет эти события и возвращает подтверждение о записи или acknowledgement.<\/p>\n<h2>Брокеры<\/h2>\n<p>Чтобы Broker’ы знали куда нужно отправить сообщение producer’а и какие consumer’ы могут читать эти сообщения существует такое понятие как <b>Topic<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-15.png\" width=\"1044\" height=\"433\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.lydtechconsulting.com\/blog-kafka-message-keys.html\">lydtechconsulting.com<\/a><\/div>\n<\/div>\n<p><b>Topic<\/b> — это базовая, основная сущность Apache Kafka, <b>логическое<\/b> разделение коллекции связанных сообщений на группы, последовательность событий. Топик удобно представить в виде лога, в который постоянно добавляются новые данные в конец, тем самым не разрушается цепочка старых событий.  Отличие топика Kafka от остальных топиков очередей тем что данные в топике Kafka нельзя удалить используя Consumer или Producer.<\/p>\n<p>Topic состоит из <b>партиций<\/b>, которых может быть одна или несколько. Партиции — это главный механизм масштабирования и отказоустойчивости.  1 партиция — это 1 копия данных. Партиция может находится как на одном брокере, так и на нескольких. Сколько нужно партиций зависит от того насколько много consumer’ов читает топик и насколько часто они читают из этого топика. Если довольно часто, то в идеале для каждого consumer’а иметь свою отдельную партицию.<\/p>\n<p>Сами партиции физически представлены на дисках в виде <b>сегментов<\/b>.  Сегмент — это отдельный файл, хранящийся на диске брокера. Файлы можно создавать, ротировать с одного брокера на другой, удалять согласно настройке устаревания. Число сегментов может варьироваться в зависимости от интенсивности записи и настроек размера сегмента. При превышении размера сегмента создается новый.<\/p>\n<h2>Хранение данных<\/h2>\n<p>Семантически и физически сообщения внутри сегмента не могут быть удалены, они иммутабельны. Всё, что мы можем — указать, как долго Kafka-брокер будет хранить события через настройку политики устаревания данных <b>retention policy<\/b> и указать <b>cleanup policy<\/b>, когда наступает некое событие для очистки данных.<\/p>\n<p><b>Retention policy<\/b> правила, которые позволяют избавляться от устаревших данных на основании времени. При достижении порога данные помечаются на удаление. Существуют следующие опции настройки:<br \/>\n— по милисекундам <b>log.retention.ms<\/b><br \/>\n— по минутам <b>log.retention.minutes<\/b><br \/>\n— по часам <b>log.retention.hours<\/b><br \/>\nПомимо этого существует size based подход, где оценивается размер сегмента, который может хранить топик:<br \/>\n— <b>log.segment.bytes<\/b><\/p>\n<p><b>Cleanup policy<\/b> состоит из:<br \/>\n— Delete (по умолчанию). Помечает на удаление segment при устаревании \/ превышении размера<br \/>\n— Compact. Оставляет только последние сообщения для каждого ключа (message key)<br \/>\n— Delete и Compact. Производится compaction и удаление согласно retention policy<\/p>\n<h2>Репликация данных<\/h2>\n<p>Для обеспечения отказоустойчивости и сохранности данных существует механизм репликации между брокерами, который имплементируется на уровне партиций:<br \/>\n— У каждой партиции есть настраиваемое число реплик<br \/>\n— Одна из этих реплик называется <b>партицией-лидером<\/b>, которая принимает все запросы на запись\/чтение данных. Все остальные являются <b>партициями-фолловерами<\/b><br \/>\n— Записанные данные в партицию лидера автоматически реплицируются фолловерами внутри кластера Kafka. Фолловеры подключаются к лидеру, читают данные и асихронно сохраняют к себе на диск<br \/>\n— Роли лидеров и фолловеров не статичны. В случае выхода из строя брокера с лидирующими партициями, роль лидера достанется одной из реплик фолловеров, а консумеры и продюсеры получат обновление о необходимости переподключиться к брокерам с новыми лидерами партиций<br \/>\n— Начиная с версии Kafka 2.4 консумеры могут читать с партиций фолловеров. Это полезно для сокращения задержек при обращении к ближайшему брокеру в одной зоне доступности. Однако, из-за асинхронной работы репликации, взамен вы получаете от фолловеров менее актуальные данные, чем они есть в лидерской партиции<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-7.png\" width=\"1560\" height=\"1015\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<h2>Что из себя представляет сообщение Kafka<\/h2>\n<p>Каждое событие — это пара ключ-значение. Ключ партицирования может быть любой: числовой, строковый, объект или вовсе пустой. Значение тоже может быть любым — числом, строкой или объектом в своей предметной области, который вы можете как-то сериализовать (JSON, Protobuf, …) и хранить. В сообщении продюсер может указать время, либо за него это сделает брокер в момент приёма сообщения. Заголовки выглядят как в HTTP-протоколе — это строковые пары ключ-значение. В них не следует хранить сами данные, но они могут использоваться для передачи метаданных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-6.png\" width=\"1560\" height=\"828\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<h2>Запись данных producer’ом<\/h2>\n<p>Чтобы producer смог отправить данные в Kafka кластер ему необходимо знать IP адреса всех брокеров и название топика. Перед тем как producer пойдет записывать данные он опросит брокер из своего пула и уточнит какая его партиция является лидером в топике и какое местоположение этой партиции в файловой системе. Запись осуществляется только в партицию-лидер.<\/p>\n<p>Продюсер определяет стратегию партицирования, она может быть как по <b>ключу сообщения<\/b>, <b>по очереди<\/b> (round-robin), так и <b>кастомная<\/b>, реализованная на стороне продюсера. По ключу сообщения одного и того же идентификатора сохраняются в одну партицию. Примером такого ключа может быть номер карты, ID клиента и т. д. Например, ключ со значением Prod_id_1 всегда будет сохраняться в партицию 0, а со значением Prod_id_2 будет сохраняться в партицию 1, то есть данные не будут распределены по всем имеющимся партициям.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-4.png\" width=\"500\" height=\"300\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.javatpoint.com\/apache-kafka-producer\">javapoint<\/a><\/div>\n<\/div>\n<p>При round-robin сообщения попадают в партиции по очереди, такая стратегия хорошо работает когда нужно равномерно распределить сообщения между всеми существующими партициями и очередность не играет роли.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-3.png\" width=\"500\" height=\"300\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.javatpoint.com\/apache-kafka-producer\">javapoint<\/a><\/div>\n<\/div>\n<p><b>Семантики доставки сообщений<\/b><br \/>\nВ очередях есть выбор между скоростью доставки и расходами на надежность доставки.<br \/>\n—  <b>at-most once<\/b> — при доставке сообщений устраивают потери сообщений, но не их дубликаты. Это самая слабая гарантия, которую реализуют брокерами очередей<br \/>\n— <b>at-least once<\/b> — не хотим терять сообщения, но нас устраивают дубликаты<br \/>\n— <b>exactly-once<\/b> — хотим доставить одно и только одно сообщение ничего не теряя и ничего не дублируя. Высокая надёжность данной семантики означает большие задержки<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-8.png\" width=\"1560\" height=\"584\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<p><b>Надежность доставки<\/b><br \/>\nНадежность доставки продюсером данных в брокер осуществляется с помощью возвращения подтверждения записи данных продюсеру в партиции регулируется параметром <b>acks<\/b>.<br \/>\n— При значении <b>acks=0<\/b> продюсер не получает подтверждение от брокера, что запись произошла успешно. Данная политика влечет за собой риски потери данных<br \/>\n— При значении <b>acks=1<\/b> продюсер будет ожидать получения ответа об успешной записи данных от лидера партиции<br \/>\n— При значении <b>acks=all<\/b> продюсер ожидает подтверждения и от лидера партиции, и от фолловеров партиции. Данный вариант является самым надежным и самым трудозатратным, так как требует больше накладных расходов: мало того, чтобы нужно сохранить на диск, так ещё и дождаться, пока фолловеры отреплицируют сообщения и сохранят их к себе на диск. При включенной опции <b>enable.idempotence<\/b> сообщениям проставляется PID (идентификатор продюсера) и увеличивающийся sequence number. Таким образом обеспечивается транзакционность и в случае сбоя в сети при попытке доставить сообщение повторно сообщения с одинаковым PID будут отброшены со стороны брокера.<\/p>\n<h2>Чтение данных consumer’ом<\/h2>\n<p>Консумеры читают данные синхронно или асинхронно из лидерской партиции — это позволяет достичь консистентности при работе с данными. Информация в партиции читается слева-направо. Консумеров, читающих сообщения из топика, может быть несколько, причем читать они могут с разных позиций партиции, тем самым не мешая друг другу. Также нет какой-то привязки к чтению по времени, в зависимости от задачи консумеры могут читать спустя дни, недели, месяцы или несколько раз через какое-то время. Сама Kafka (в данном случае брокер) не следит за тем какое сообщение будет читать consumer и когда ему приходить за этими сообщениями. Consumerы сами должны ходить в Kafka и читать оттуда сообщения, сами должны говорить Kafka какие сообщения им выдать<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-5.png\" width=\"1560\" height=\"592\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<p><b>Offset<\/b> — это позиция сообщения в очереди Kafka. Начальная позиция в сообщении называется <b>log-start offset<\/b>. Позиция сообщения, записанного последним — <b>log-end offset<\/b>. Позиция консумера сейчас — <b>current offset<\/b>.  Расстояние между конечным оффсетом и текущим оффсетом консумера называют лагом — это первое, за чем стоит следить в своих приложениях. Допустимый лаг для каждого приложения свой, это тесно связано с бизнес-логикой и требованиями к работе системы.<\/p>\n<p>Consumer при чтении умеет запоминать на каком offset он остановился. Сохранение события фиксации позиции сообщения происходит в специальный Kafka топик <b>_consumer_offset<\/b>. Под событием фиксации понимается так называемые <b>commits<\/b>, их может быть два:<br \/>\n— <b>auto commit<\/b> (по умолчанию). Он вычитывает кол-во offset (батч оффсетов) и потом фиксирует, какое кол-во offsetов он прочитал.<br \/>\n— <b>user commit<\/b>. Можно организовать свою логику фиксирования коммитов, например, прочитал 1 offset, зафиксировал коммит. Минус такого подхода — снижение производительности<\/p>\n<p>Как обеспечивается то, что консумеры читают разные данные, разные партиции, а не одни и теже:<br \/>\n— Для этого есть такое понятие как <b>консумер группы (consumer groups)<\/b> — это множество консумеров объединившихся в один кластер.<br \/>\n— Каждый консумер в группе будет читать разные сообщения. Каждый консумер пойдет в свою партицию и будет читать именно ее. Читать будет с того места где он остановился прошлый раз<br \/>\n— Kafka сохраняет на своей стороне текущий оффсет по каждой партиции топиков, которые входят в состав консумер-группы. Консумер в группе, после обработки прочитанных сообщений отправляет запрос на сохранение оффсета — или коммитит свой оффсет<br \/>\n— Распределение партиций между консумерами в пределах одной группы выполняется автоматически на стороне брокеров. Kafka старается честно распределять партиции между консумер-группами, насколько это возможно.<br \/>\n— Консумер группы создаются для решения разных кейсов. То есть данные могут быть одни и те же, но пользователи и задачи решаемые этими пользователями будут разные. Например, один консумер использует логи авторизаций пользователей для нужд администраторов, а другая консумер группа в виде маркетологов нужно смотреть кол-во авторизовавшихся пользователей на странице.<br \/>\n— Каждая такая группа имеет свой идентификатор, что позволяет регистрироваться на брокерах Kafka. Пространство имён консумер-групп глобально, а значит их имена в кластере Kafka уникальны.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-kafka-9.png\" width=\"1560\" height=\"577\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<p><b>Ребалансировка консумер-групп<\/b><br \/>\nПри добавлении новых потребителей топика происходит ребалансировка консумер-группы. Процесс ребалансировки заставляет все консумеры прекратить чтение и дождаться полной синхронизации участников, чтобы обрести новые партиции для чтения. Как только группа стала стабильной, а её участники получили партиции, консумеры в ней начинают чтение. Поскольку группа новая и раньше не существовала, то консумер выбирает позицию чтения оффсета: с самого начала earliest или же с конца latest. Топик мог существовать несколько месяцев, а консумер появился совсем недавно. В таком случае важно решить: читать ли все сообщения или же достаточно читать с конца самые последние, пропустив историю. Выбор между двумя опциями зависит от бизнес-логики протекающих внутри топика событий.<\/p>\n<p>Для того чтобы понимать какие из участников группы активны и работают, а какие уже нет, каждый консумер группы в равные промежутки времени отправляет <b>Heartbeat-сообщение<\/b>. Временное значение настраивается программой-консумером перед запуском. Также консумер объявляет <b>время жизни сессии<\/b> — если за это время он не смог отправить ни одно из Heartbeat-сообщений брокеру, то покидает группу. Брокер, в свою очередь, не получив ни одно из Heartbeat-сообщений консумеров, запускает процесс ребалансировки консумеров в группе.<\/p>\n<p>Процесс ребалансировки проходит достаточно болезненно для больших консумер-групп с множеством топиков. Поэтому разработчикам программ-консумеров обычно рекомендуют использовать по одной консумер-группе на топик. Также полезно держать число потребителей не слишком большим, чтобы не запускать ребалансировку много раз, но и не слишком маленьким, чтобы сохранять производительность и надёжность при чтении. Значения интервала Heartbeat и время жизни сессии следует устанавливать так, чтобы Heartbeat-интервал был в три-четыре раза меньше session timeout. Сами значения нужно выбирать не слишком большими, чтобы не увеличивать время до обнаружения «выпавшего» консумера из группы, но и не слишком маленьким, чтобы в случае малейших сетевых проблем, группа не уходила в ребалансировку.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/a52b72b1495d94797ab6f8642a09219f.gif\" width=\"800\" height=\"477\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/habr.com\/ru\/companies\/sbermarket\/articles\/738634\/\">habr.com<\/a><\/div>\n<\/div>\n<p>Ещё один гипотетический сценарий: партиций в топике 4, а консумеров в группе 5. В этом случае группа будет стабилизирована, однако участники, которым не достанется ни одна из партиций, будут бездействовать. Такое происходит потому, что с одной партицией в группе может работать только один консумер, а два и более консумеров не могут читать из одной партиции в группе. Отсюда возникает следующая базовая рекомендация: устанавливайте достаточное число партиций на старте, чтобы вы могли горизонтально масштабировать ваше приложение.<\/p>\n<h2>Бонус:<\/h2>\n<p>Неплохой ролик о том какие проблемы решает Kafka, какие его преимущества в сравнении с другими брокерами сообщений и многое другое. В ролике отличная анимация и демонстрация работы основных компонентов Kafka<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/hbseyn-CfXY?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2024-05-13T21:56:42+05:00",
            "date_modified": "2024-08-19T11:24:26+05:00",
            "tags": [
                "BigData",
                "IT",
                "Kafka"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/apache-kafka.png",
            "_date_published_rfc2822": "Mon, 13 May 2024 21:56:42 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "15",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-1.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-15.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-7.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-6.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-4.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-3.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-8.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-5.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-kafka-9.png",
                    "https:\/\/slavlotski.com\/pictures\/a52b72b1495d94797ab6f8642a09219f.gif",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-hbseyn-CfXY-cover.jpg"
                ]
            }
        },
        {
            "id": "14",
            "url": "https:\/\/slavlotski.com\/all\/apache-spark\/",
            "title": "Apache Spark",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark.png\" width=\"920\" height=\"406\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.azul.com\/glossary\/apache-spark\/\">azul.com<\/a><\/div>\n<\/div>\n<p><b>Apache Spark<\/b> — это универсальный, высокопроизводительный, отказоустойчивый движок, написанный на Scala, для распределенной обработки данных.<\/p>\n<p><b>Универсальный<\/b><br \/>\nSpark способен работать с различными видами обработок данных:<br \/>\n— batch обработка<br \/>\n— ad-hoc запросы<br \/>\n— циклические алгоритмы (нужно запускать часть команд раз за разом итеративно)<br \/>\n— streaming обработка<\/p>\n<p><b>Высокопроизводительный<\/b><br \/>\nSpark способен выполнять вычисления в <b>оперативной памяти<\/b>, но и с дисковой памятью он работает эффективно. Чтобы применить вычислительные преимущества Spark ему нужно выполняться на кластере серверов, а это значит, что необходима поддержка <b>горизонтального масштабирования<\/b> — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам, параллельно выполняющие одно и то же задание.<\/p>\n<p><b>Отказоустойчивый<\/b><br \/>\nSpark в случае нехватки оперативной памяти для вычислений выполнит так называемый <b>spill<\/b> данных с оперативной памяти на диск тем самым работа Spark приложения не приостановится, но сильно замедлится.<\/p>\n<p><b>spill<\/b> —  это термин для обозначения процесса перемещения данных из оперативной памяти на диск, а затем обратно в оперативную память.<\/p>\n<h2>С какой целью создали Apache Spark?<\/h2>\n<p>Spark был создан для устранения ограничений MapReduce у Hadoop за счет:<br \/>\n— обработки данных в оперативной памяти<br \/>\n— уменьшения кол-ва шагов в задании<br \/>\n— повторного использования данных в нескольких параллельных операциях<\/p>\n<p>Spark требуется только <b>один шаг чтения данных с диска в память<\/b>, а затем выполняются операции трансформации данных и записываются результаты во внешние системы хранения. Использование оперативной памяти и сокращение числа операций с данными приводит к гораздо более быстрому выполнению заданий нежели как у Hadoop.<\/p>\n<p>Spark также умеет <b>повторно использовать наборы данных,<\/b> помещенные в кэш памяти, чтобы значительно ускорить алгоритмы машинного обучения, которые многократно вызывают функцию в одном и том же наборе данных.<\/p>\n<p><b>Кэширование данных<\/b> — это высокоскоростной уровень хранения, на котором требуемый набор данных необходим временно. Доступ к данным на этом уровне осуществляется значительно быстрее, чем к основному месту их хранения. С помощью кэширования становится возможным эффективное повторное использование ранее полученных или вычисленных данных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-1.png\" width=\"624\" height=\"352\" alt=\"\" \/>\n<div class=\"e2-text-caption\">В чем основное отличие Spark и Hadoop. Источник: <a href=\"https:\/\/dimensionless.in\/what-is-the-difference-between-hadoop-and-spark\/\">dimensionless.in<\/a><\/div>\n<\/div>\n<p>Работа Spark с данными в оперативной памяти влечет за собой риски по их потере, так как они будут стерты в случае если пропадет электричество или что-то пойдет не так с самими нодами.<\/p>\n<h2>Когда нужно использовать Apache Spark?<\/h2>\n<p>— <b>Параллельная обработка<\/b> больших распределено хранящихся наборов данных<br \/>\n— Выполнение <b>интерактивных<\/b> ad-hoc запросов для изучения и визуализации наборов данных<br \/>\n— Построение сквозных конвейеров (ETL) обработки данных из различных источников<br \/>\n— Обработка потоков данных в режиме реального времени<br \/>\n— Создание и обучение моделей машинного обучения<br \/>\n— Анализ графов и соц сетей<\/p>\n<h2>Основные компоненты Apache Spark<\/h2>\n<p><b>Spark Core<\/b> — основная библиотека, главный движок спарка, который занимается: поддержкой API, управлением памятью, распределением нагрузки, параллельностью запросов, взаимодействием с внешними системами хранения.<\/p>\n<p><b>Spark SQL and DataFrames<\/b> — библиотека унифицирует работу со структурированными данными, поддержка языка SQL.<\/p>\n<p><b>Spark Streaming<\/b> — библиотека потоковой обработки данных, не совсем реал тайм, а скорее микробатчинг.<\/p>\n<p><b>RDD (Resilient Distributed Dataset)<\/b> — самая низкоуровневая единица в иерархии модели Spark, представляет собой распределенный неизменяемый набор данных, который делится на множество частей, обрабатывающихся различными узлами в кластере. Когда использовать RDD:<br \/>\n— когда какая-то внешняя библиотека использует RDD<br \/>\n— детальная оптимизация кода, когда с помощью DataFrame уже не получается<br \/>\n— когда нужно давать Spark’у точные инструкции как нужно выполнять запросы с данными<\/p>\n<p><b>Spark MLlib<\/b> — это библиотека фреймворка Apache Spark, позволяющая реализовывать механизм машинного обучения (Machine Learning, ML) и решать задачи, связанные с построением и обучением ML-моделей.<\/p>\n<p><b>Spark GraphX<\/b> — это компонент Apache Spark, специализирующийся на анализе графов. Графовые структуры широко используются в различных областях, таких как социальные сети, транспортные системы, биоинформатика и многое другое<\/p>\n<p><b>Catalyst Optimizer<\/b> — оптимизатор плана запроса. Catalyst — это дерево, состоящее из узловых объектов.  Каталист выполняет следующие шаги для оптимизации:<br \/>\n— Анализ — определить тип каждого передаваемого столбца и действительно ли существуют столбцы, которые вы используете<br \/>\n— Логическая оптимизация (логический план составляет дерево, которое описывает, что нужно сделать). Добавляется <b>predicate-pushdown<\/b> (добавление фильтра where в условие для внешних источников). <b>Predicate-pushdown<\/b> поддерживается у JDBC источников, форматов Parquet, Avro, ORC. Помимо  <b>Predicate-pushdown<\/b> существует <b>Projection Pushdown<\/b> направлено на то, чтобы как можно раньше удалить ненужные столбцы из вычислечний или не извлекать их вообще<br \/>\n— Физическая оптимизация (физический план точно описывает, как нужно делать)Например, логический план просто указывает на то, что необходимо выполнить операцию <i>join<\/i>, а физический план фиксирует тип соединения (например, <i>ShuffleHashJoin<\/i>) для этой конкретной операции. Физическим планом часто называют Spark планом, который указывает как логический план будет выполняться на кластере используя разные стратегии физического выполнения и сравнивая их друг с другом посредством модели оценки (cost model). Примером модели оценки может быть сравнение как будут выполняться разные виды Join в зависимости от размера таблицы, насколько большие партиции. Результатом физического плана является RDD трансформации, которые выполняются на каждом узле. Иногда Spark называют компилятором, который принимает запрос через DataFrame, DataSet, SQL API, а потом Spark под капотом компилирует этот запрос в трансформации над RDD<br \/>\n— Генерация кода — создание байт-кода Java для запуска на каждой машине<\/p>\n<p><b>Pyspark<\/b> — это API, позволяющее работать с Apache Spark с помощью Python.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-core.png\" width=\"2108\" height=\"1211\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Компоненты Spark и языки программирование, которые могут работать со Spark. Источник: <a href=\"https:\/\/moazim1993.github.io\/BigData_Spark_Tutorial\/\"> moazim1993.github.io<\/a><\/div>\n<\/div>\n<h2>Архитектура Spark<\/h2>\n<p><b>Spark Application<\/b> — приложение, которое состоит из Spark Driver и Spark Executors.<\/p>\n<p><b>Spark Driver<\/b> — компонент, который состоит из одного экземпляра в кластере и отвечает за:<br \/>\n— инициирование исполнения программы<br \/>\n— планирует, распределяет и запускает работу Spark Executors<br \/>\n— формирует план запроса, так называемый DAG (Directed Acyclic Graph)<\/p>\n<p><b>Spark Executor<\/b> —  компонент, который выполняет все распределенные вычисления. Executorов может быть от 0 до n, отвечает за:<br \/>\n— выполнение кода программы, отправленный Spark Driver’ом<br \/>\n— выполняет все распределенные вычисления<br \/>\n— передает информацию о процессе вычислений<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-4.png\" width=\"720\" height=\"425\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Архитектура Spark. Источник: <a href=\"https:\/\/medium.com\/@iharshsingh73\/spark-architecture-be66ea955a5a\">medium.com<\/a><\/div>\n<\/div>\n<p><b>Контейнер<\/b> — это некий формат пакетирования, упаковки вашего приложения, он позволяет весь ваш код вместе с зависимостями упаковать в некий стандартный формат, чтобы ваше приложение могло запускаться на разных платформах, вычислительных средах.<\/p>\n<p><b>Spark Session<\/b> —  точка входа для функциональных возможностей Spark:<br \/>\n— позволяет конфигурировать ресурсы, выделяемые для вычислений<br \/>\n— предоставляет доступ ко всем операциям Spark, в том числе и к данным<br \/>\nSpark Session позволяет выделять ресурсы для Spark приложения <b>статически<\/b> и <b>динамически<\/b>. При статическом выделяются и резервируются указанное кол-во ресурсов. При динамическом аллоцировании ресурсов они запросятся в нужном размере необходимом для Spark приложения. Помимо этого в Spark есть параметр, который указывает какое кол-во времени ресурсы Spark при динамическом аллоцировании могут простаивать и при достижении этого времени они высвобождаются для решения последующих заданий других приложений.<\/p>\n<h2>Архитектура Spark приложения во время исполнения<\/h2>\n<p><b>Spark Application<\/b>  — представляет собой распределенное приложение для получения максимальной производительности для которого необходим кластер, состоящий из нескольких машин под управлением Resource Manager (RM). Наиболее популярными решениями запуска Spark приложения в кластере являются YARN Resource Manager и Kubernetes cluster. Основное отличие запуска Spark в YARN и Kubernetes в том, что развернутые контейнеры YARNом при необходимости могут самостоятельно запрашивать дополнительные ресурсы для вычислений у Resource Manager, в то время как контейнеры в Kubernetes cluster так не умеют.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-rm.png\" width=\"698\" height=\"446\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Самые популярные Resource Manager для Spark. Источник: <a href=\"https:\/\/medium.com\/southworks\/movie-data-statistics-with-apache-spark-58c2ef8fe452\">medium.com<\/a><\/div>\n<\/div>\n<p><b>Spark submit<\/b> — один из подходов запуска Spark приложения в виде консольной утилиты, которая позволяет запускать приложение в кластере. Утилита читает код, подтягивает конфигурацию и отправляет задачу на деплой в кластер, cluster менеджер выделяет ресурсы и разворачивает приложение.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-cluster-deploy.png\" width=\"708\" height=\"345\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Spark Submit на кластере YARN. Источник: <a href=\"https:\/\/medium.com\/@mojtaba81\/introduction-to-spark-submit-d22cde2dfa86\">medium.com<\/a><\/div>\n<\/div>\n<p><b>Режимы Deploy Spark приложения<\/b><\/p>\n<ol start=\"1\">\n<li>cluster deploy_mode:<br \/>\n— Driver будет запущен на одной из машин YARN кластера<br \/>\n— Cluster Deploy mode снижает нагрузку на сеть (network latency), где Driver находится в одном контуре с Executor’ами. Вероятность разрыва связи между Driver’ом и Execut’oром в случае с cluster deploy mode’ом намного меньше, так как Driver и Executor находятся в одной сети.<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">spark-submit —master yarn —deploy_mode cluster<\/code><\/pre><p>Обычно deploy_mode cluster используется в PRODUCTION среде, где для запуска Spark Driver выделяется отдельная машина. В случае запуска приложения  в cluster deploy_mode режиме с помощью YARN, запускаемый им <b>Application Master = Spark Driver<\/b>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/1692292839305.gif\" width=\"800\" height=\"520\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Визуализация разворачивания Spark приложения через Spark Submit. Источник: <a href=\"https:\/\/www.linkedin.com\/posts\/vutr27_hadoop-apachespark-dataengineering-activity-7098264784348860416-uONw\/\">linkedin.com<\/a><\/div>\n<\/div>\n<ol start=\"2\">\n<li>client deploy_mode:<br \/>\n— Client mode режим используется по умолчанию<br \/>\n— Driver запускается на той же машине откуда и производится spark-submit<br \/>\n— client mode обычно используется для прототипирования, отладки, когда мы хотим увидеть промежуточный результат наших расчетов. Например, работая в JupyterHub’е, сессия запускается всегда с client deploy_mode<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">spark-submit —master yarn —deploy_mode client<\/code><\/pre><h2>Spark DataFrame и виды операций с ним<\/h2>\n<p><b>Spark Dataframe<\/b> — наиболее распространенная неизменяемая структура данных в Spark, представляет собой набор типизированных записей, разбитых на блоки. Иными словами — таблица, состоящая из строк и столбцов. Блоки могут обрабатываться на разных вычислительных узлах кластера.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-3.png\" width=\"1724\" height=\"1094\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Spark Dataframe — это как партицированная таблица. Источник: <a href=\"https:\/\/www.nvidia.com\/en-sg\/ai-data-science\/spark-ebook\/introduction-spark-processing\/\">nvidia.com<\/a><\/div>\n<\/div>\n<p><b>DataFrame<\/b> поддерживает привычные для работы с данными операторы, такие как:<br \/>\n— select<br \/>\n— filter (фильтрация)<br \/>\n— sort<br \/>\n— withColumn (новые столбцы)<br \/>\n— join (соединение таблиц) и прочие<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/image-2.png\" width=\"779\" height=\"258\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Какие форматы и источники поддерживает Spark Dataframe. Источник: <a href=\"https:\/\/www.databricks.com\/blog\/2015\/02\/17\/introducing-dataframes-in-spark-for-large-scale-data-science.html\">databricks.com<\/a><\/div>\n<\/div>\n<p>Spark отчасти напоминает концепт библиотеки Pandas в Python.<br \/>\nСуществуют два вида основных операций с Spark Dataframe:<br \/>\n— <b>transformation<\/b> — изменение существующего <b>Dataframe<\/b> (возвращает другой dataframe, например, с помощью filter, join)<br \/>\n— <b>action<\/b> — метод, который поручает Spark вычислить, записать, вернуть результат цепочек преобразований и трансформаций. Такими методами являются, например: <b>count(), show(), write(), save()<\/b><\/p>\n<p><b>Ленивые вычисления<\/b> — это стратегия вычисления в Spark, при которой запуск расчетов откладывается до того момента, когда понадобится результат. Необходимо это для <b>сокращения объема вычислений<\/b> за счет оптимизации и исключения вычислений, результат которых не используется. Реализовано это следующим образом, команды преобразования данных запускаются только после вызова <b>action<\/b> методов в виде одного оптимизированного плана запроса. Оптимизатор строит наиболее эффективный алгоритм, который уже и запускается.<\/p>\n<p>Операции <b>transformation<\/b> — ленивые операции, они никаких вычислений не запускают. Операции трансформации делятся на:<br \/>\n— <b>Narrow dependency<\/b> выполняются параллельно над партициями данных (select, filter, drop и не вызывают операции перемешивания (<b>shuffle<\/b>) данных)<br \/>\n— <b>Wide dependency<\/b> выполняются на сгруппированных данных, собранных из нескольких партиций (.groupBy(), .join(), orderBy(), distinct(), repartition() вызывают операцию shuffle)<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-5.png\" width=\"1334\" height=\"1040\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Иллюстрация narrow и wide трансформаций. Источник: <a href=\"http:\/\/horicky.blogspot.com\/2013\/12\/spark-low-latency-massively-parallel.html\">horicky.blogspot.com<\/a><\/div>\n<\/div>\n<p><b>Data shuffle<\/b> — это процесс перераспределения данных executor’ами для выполнения дальнейшей обработки над сгруппированными данными. Операцию shuffle инициируют широкие (wide) трансформации и прямое использование команды <b>repartition<\/b>. Результат каждого shuffle записывается на диск.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-6.png\" width=\"912\" height=\"343\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Принцип работы shuffle данных. Источник: <a href=\"https:\/\/towardsdatascience.com\/apache-spark-optimization-techniques-fa7f20a9a2cf\">towardsdatascience.com<\/a><\/div>\n<\/div>\n<p>Операции <b>перетасовки<\/b> данных являются <b>дорогостоящими<\/b> и часто являются причиной <b>снижения<\/b> скорости выполнения распределенного приложения из-за:<\/p>\n<ol start=\"1\">\n<li><b>Disk IO<\/b> операции чтения\/записи с диска<\/li>\n<li><b>Network IO<\/b> — передачи данных по сети между исполнителями или даже между рабочими узлами в кластере<\/li>\n<li><b>Serialization \/ Deserialization<\/b> — <b>конвертация<\/b> <b>Java объектов<\/b>, представляющие собой обрабатываемые Spark’ом данные в поток <b>байтов<\/b> (bytes-stream) для передачи их по <b>сети<\/b> (deserialization соответственно обратный процесс — конвертация bytes-stream в Java объекты).<\/li>\n<\/ol>\n<p>Операцию shuffle избежать не получится, но можно минимизировать затраты, например, за счет использования <b>фильтрации данных<\/b> до широких трансформаций, тем самым <b>уменьшая<\/b> общее кол-во данных к shuffle<\/p>\n<h2>Spark  Job, Stage, Task<\/h2>\n<p>При выполнении action-операций таких как <b>collect()<\/b>, <b>count()<\/b> и т. п. инициируется запуск такого компонента как Spark Job.<\/p>\n<p><b>Spark Job<\/b> — задача исполнения графа вычислений (DAG), которая разбивается на <b>Spark Stage<\/b>, а Spark Stage декомпозируется на <b>Spark Task<\/b>. Каждая action-операция создает отдельный pipeline вычислений, то есть новый Spark Job. Spark Jobы могут работать последовательно и параллельно, в данном случае как выполнять Jobы решает оптимизатор Spark.<\/p>\n<p><b>Spark Stage<\/b> — этапы вычислений, на которые разбивается Job, которые зависят друг от друга и используют общий результат перемешивания\/перетасовки (shuffle) данных в рамках этапа расчета. Операция перетасовки (shuffle) данных создает новый stage. Stage’ы могут выполняться как параллельно, так и последовательно и делятся на два типа:<br \/>\n— те операции что не вызывают <b>shuffle<\/b> у Spark могут быть обработаны параллельно. Например, чтение файла.<br \/>\n— последовательно stage’ы выполняются если у них есть функциональная зависимость, stage’ы построен так, что один stage должен получить результат другого stage’а. Например, джоин двух таблиц, чтение данных может произойти параллельно, а вот сам джоин уже будет идти последовательно<\/p>\n<p><b>Spark Task<\/b> —  наименьшая исполнительная единица в Spark, которая выполняет серию инструкций, например, чтение данных или фильтрацию. Task’и выполняются внутри Executor’ов. Таски — юниты исполнения, которые распределяются между экзекьюторами, каждая таска дается на выполнение одному экзекьютору и выполняется над одной партиции данных. Таким образом один экзекьютор с 16 ядрами (cores) может обрабатывать 16 партиций параллельно.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-8.png\" width=\"405\" height=\"303\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Схематичное описание работы Spark Job, Stage, Task. Источник: <a href=\"https:\/\/sprinkle-twinkles.medium.com\/spark-job-vs-stage-vs-task-in-simple-terms-with-cheat-sheet-fa9fae40c3ed\">medium.com<\/a><\/div>\n<\/div>\n<h2>Партиционирование в Spark<\/h2>\n<p>Apache Spark предназначен для обработки больших данных (Big Data), и партиции являются одним из способов это сделать. К плюсам партиций можно отнести:<br \/>\n— быстрый доступ к данным;<br \/>\n— возможность производить операции на меньших датасетах;<\/p>\n<p>Действительно, хранить в оперативной памяти огромный датасет может быть не эффективно, однако его заранее можно разбить на меньшие части, и уже работать с ними. К тому же фильтрационные запросы подразумевают партицирование<\/p>\n<p>К минусам партиций можно отнести:<br \/>\n— наличие большого числа партиций (операции ввода-вывода медленные);<br \/>\n— не решают проблему неравномерности данных (партиции могут быть разного размера)<\/p>\n<p>Существует два вида операции с партиционированием, одни выполняются в оперативной памяти, а другие на диске.<\/p>\n<p><b>Операции партиционирования в памяти<\/b><\/p>\n<p><b>repartition()<\/b> — принудительный shuffle данных, на вход подается два аргумента, кол-во партиций и список колонок по которым делается репартиционирование. Это команда делает следующее, одинаковые ключи отправляет на одинаковые executor’ы. С помощью этого метода можно увеличить количество партиций тем самым увеличив уровень параллелизма в кластере Apache Spark. Repartition может хорошо помочь в случае неравномерного распределения или перекоса данных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-9.png\" width=\"622\" height=\"464\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Принцип работы метода repartition. Источник: <a href=\"https:\/\/medium.com\/@badwaik.ojas\/repartition-vs-coalesce-in-apache-spark-e51b42a832c\">medium.com<\/a><\/div>\n<\/div>\n<p><b>coalesce()<\/b> — операция оптимизации, которая только уменьшает число партиций наиболее эффективным образом и при этом минимизирует количество перетасовок shuffle. Не может увеличить количество партиций, т. е. повысить уровень параллелизма в кластере Apache Spark. Данная операция может полезна для разделения данных на маленькое кол-во партиций без full shuffle, но есть риск, что данные могут разделиться неравномерным образом.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-spark-10.png\" width=\"658\" height=\"471\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Принцип работы метода coalesce. Источник: <a href=\"https:\/\/medium.com\/@badwaik.ojas\/repartition-vs-coalesce-in-apache-spark-e51b42a832c\">medium.com<\/a><\/div>\n<\/div>\n<p><b>Операция партиционирования на диске<\/b><br \/>\nПартиция на диске выполняется с помощью вызова метода <b>partitionBy<\/b>.  При создании партиций на диске они будут сгенерированы на основе уникальных значений столбца(ов), по которому(ым) происходит разбиение. Иными словами, <b>partitionBy<\/b> работает как <b>groupBy<\/b>, только вместо групп на диске создаются файлы с партициями.<\/p>\n<p><b>Разница между операциями в памяти и операциями на диске<\/b><br \/>\n<b>partitionBy<\/b> изменит структуру папок, то есть по сути это аналог партиций Hive, где под каждое значение партиционированной колонки создастся своя папка в HDFS. В то время как  <b>repartition()<\/b> или <b>coalesce()<\/b> оперируют кол-вом файлов, которые будут записаны в папку HDFS.<\/p>\n<h2>Best Practices<\/h2>\n<ol start=\"1\">\n<li>Использовать динамическую аллокацию ресурсов вместо статической. Приложение будет запрашивать ресурсы по мере необходимости и возвращать неиспользуемые ресурсы кластеру. На кластере могут работать тысячи пользователей, при динамической аллокации распоряжение ресурсами происходит более грамотно и можно не переживать за оставленную без присмотра spark-сессию.<br \/>\nПро выделение ресурсов:<br \/>\n— Для Spark Driver’а достаточно 1 ядра (core), 1 гигабайт оперативной памяти<br \/>\n— Если много данных, то нужно выделять много памяти на один Spark Executor, 1-2 ядра и увеличивать кол-во Executor<br \/>\n— Если мало данных, но много операций, трансформаций с данными, то нужно в приоритет ставить кол-во ядер, но меньше выделять памяти<br \/>\n— Параллелизм в Spark определяется по формуле: кол-во экзекьюторов умноженное на кол-во ядер одного экзекьютора, то есть, если у нас spark.executors.cores = 2 и spark.executors.instances = 10, то параллельно 1 экзекьютор может обработать 20 партиций<br \/>\n— Все Executor’ы используют общую оперативную память, то есть она делится между кол-вом ядер этого экзекьютора. Если spark.executors.memory = 8 и spark.executors.cores = 2, то на каждое ядро экзекьютора будет по 4 ГБ памяти<br \/>\n— Существуют операции, которые возвращают данные в Spark Driver <b>collect(), reduce(), count()<\/b>. Важно понимать, что зачастую на Spark Driver выделяют ограниченное кол-во ресурсов, поэтому данные большого размеры стягивать нельзя. Перечисленные операции используются для получения результата на <b>небольшом<\/b> по размеру DataFrame. Помимо перечисленных методов данные стягиваются на Spark Driver при <b>broadcast join<\/b>. При <b>broadcast join<\/b> датафрейм стягивается на Spark Driver, а дальше его копии рассылаются на каждый Executor. Если датафрейм очень большой, то это будет неэффективно<\/li>\n<li>Следить за кол-вом дорогостоящих операций.<br \/>\nДорогостоящие операции это:<br \/>\n— чтение исходных данных с диска. Чтобы существенно увеличить производительность в этом пункте необходимо использовать фильтры по полям партицирования таблиц, тем самым мы сократим кол-во перемещений данных по сети между Executor’ами, пользоваться преимуществами столбчатого хранения (ORC\/Parquet), а именно считывать только нужные для расчетов поля<br \/>\n— мониторить за вытеснением данных из памяти экзекьютора на локальный диск (spill). Вытеснение данных происходит на локальный диск Executor. После вытеснения данных нужно их снова считывать с диска. Помогает выделить больше памяти, большее кол-во Executor<\/li>\n<li>Обнаружение вытеснения данных с памяти на диск<br \/>\n— Событие вытеснения на диск можно увидеть в логах Executor<br \/>\n— нужно выделять достаточное кол-во памяти на процесс (executor.core) + следить за объемом данных и перекосами. Бывает что данные между экзекьюторами распределяются не равномерно, один экзекьютор читает большую партицию, а остальные маленькие партиции и после завершения работ с маленькими партициями остальные ждут окончания расчета у экзекьютора с большой партицией.<br \/>\nминусы <b>shuffle<\/b>:  <br \/>\n— сериализация\/дисериализация данных  <br \/>\n— пересылка данных по сети  <br \/>\n— возможны вытеснения на диск<\/li>\n<li>Анализировать план запросов с помощью explain.<br \/>\nОператор возвращает подробную информацию о том, какой план исполнения будет выбран оптимизатором для выполнения скрипта. Запросы нужно читать снизу вверх, смотреть что применились фильтры по партицированию.<\/li>\n<li>Грамотно использовать кэширование данных<br \/>\nКэширование в Spark — механизм сохранения промежуточных вычислений в памяти экзекьюторов. Экзекьюторы сохраняют обрабатываемые партиции данных в специально выделенную область памяти. Кэширование нужно использовать если один тот же датафрейм используется в алгоритме несколько раз, необходимо это чтобы дважды или более раз не считывать данные с диска. Кэширование происходит с помощью метода <b>cache()<\/b>.  Лучшими практиками является создавать новую переменную под кэшированный датафрейм и хранить в нем только необходимые столбцы, например:<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">cache_df = df.cache()<\/code><\/pre><p>Для удаления объекта из кэша используется метод <b>unpersist()<\/b>.<\/p>\n<ol start=\"6\">\n<li>По возможности избегать использоваться UDF<br \/>\nUDF — это реализованные пользователем функции, которые не содержатся во встроенных модулях Spark. В PySpark использование UDF ведет за собой существенную деградацию производительности приложений.<br \/>\n— сериализация\/дисериализация данных между JVM и Python интерпретатором<br \/>\n— черный ящик для оптимизатора запросов. Оптимизатор запроса не знает ничего про UDF и не сможет оптимизировать план запроса<br \/>\n— Если нужны UDF, то нужно обратить внимание на Pandas UDF<\/li>\n<li>Broadcast join должен производится только на небольших датафреймах<br \/>\nОсновное требование — один из датафреймов должен полностью перемещаться в память и драйвера, и экзекьютора. BroadcastHash join производится по хэшам ключей. Для построения HashMap, которая будет разослана на все экзекьюторы, Spark сначала вытянет все данные на драйвер. Для определения размера датафрейма Spark опирается на статистику по таблице, хранящуюся в том же Hive, а она может быть некорректной, что приводит к переполнению ресурсов Spark Driver<\/li>\n<li>При записи в HDFS не нужно создавать много маленьких файлов<br \/>\nПри проведении трансформаций spark по умолчанию создает 200 партиций. При записи на диск каждая партиция будет записана в отдельный файлик. Особенности архитектуры HDFS, каждый блок занимает оперативную память на NameNode, а она лимитированная. Лучшими практиками в данной ситуации будет:<br \/>\n— кол-во файлов не превышает параллелизм при чтении<br \/>\n— размер файла меньше размера блока на Data Node и все файлы примерно одинакового размера<\/li>\n<\/ol>\n",
            "date_published": "2024-03-11T23:12:08+05:00",
            "date_modified": "2025-03-04T23:53:07+05:00",
            "tags": [
                "BigData",
                "IT",
                "Spark"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/apache-spark.png",
            "_date_published_rfc2822": "Mon, 11 Mar 2024 23:12:08 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "14",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/apache-spark.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-1.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-core.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-4.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-rm.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-cluster-deploy.png",
                    "https:\/\/slavlotski.com\/pictures\/1692292839305.gif",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-3.png",
                    "https:\/\/slavlotski.com\/pictures\/image-2.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-5.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-6.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-8.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-9.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-spark-10.png"
                ]
            }
        },
        {
            "id": "13",
            "url": "https:\/\/slavlotski.com\/all\/apache-hadoop\/",
            "title": "Apache Hadoop",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop.png\" width=\"1280\" height=\"332\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/commons.wikimedia.org\/wiki\/File:Hadoop_logo.svg\">wikimedia.org<\/a><\/div>\n<\/div>\n<p><b>Hadoop<\/b> — проект фонда Apache Software Foundation, созданный в 2005 году и предназначенный для эффективного хранения и обработки больших наборов данных объемом от сотен гигабайт до петабайтов.<br \/>\nПод словом Hadoop может подразумеваться:<br \/>\n— Несколько сервисов, составляющих ядро Hadoop (YARN, HDFS, MapReduce)<br \/>\n— Вся экосистема сервисов Hadoop<br \/>\n— Кластер под управлением Hadoop<\/p>\n<h2>Предпосылки создания Hadoop<\/h2>\n<p>Из-за значительного роста обрабатываемых данных (терабайты, петабайты) действующие на тот момент системы уже эффективно не справлялись с обработкой такого потока данных. Помимо этого необходимо было где-то разместить (хранить) такое кол-во данных без потери информации, с сохранением ее постоянной доступности. Так появилась потребность в <b>распределенном хранилище данных<\/b>. Чтобы обеспечить высокую пропускную способность большого кол-ва данных необходимо было <b>распараллелить вычисления<\/b> эффективным и отказоустойчивым способом на кластере машин. Кроме того появление новых источников нетабличных данных как, например, логи, содержимое веб-страниц, тоже являлось предпоссылкой создания нового решения обработки и хранения данных, так как сложно решить данные задачи посредством обычных реляционных БД. Одним из основных достоинств Hadoop является то, что он проектировался так, чтобы стабильно работал на кластерах серверов не премиального класса.<\/p>\n<p>В то время при разработке приложений для распределенной обработки данных возникали следующие проблемы:<br \/>\n1) В кластере серверов сложно определить какой сервер является лидером, то есть сервер, который управляет всеми остальными<br \/>\n2) Проблема координации кластера<br \/>\n3) Отсутствие достаточной отказоустойчивости. При реализации сценария выхода из строя одной ноды не было четкого плана действий, механизмов у кластера для автоматического восстановления работы системы или продолжения функционирования системы без отказавших нод<br \/>\n4) Проблема консистентности данных. Сложность разработки приложения с распределенной обработкой<br \/>\n5) Отсутствие инструмента по управлению приоритетов обработки данных, по управлению вычислительными ресурсами кластера (CPU, RAM, HDD) в том числе если ресурсы запрашивают сразу несколько приложений<\/p>\n<p>Поэтому чтобы решить все вышеперечисленные проблемы был создан Hadoop.<\/p>\n<h2>Ядро Hadoop 2.0<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-1.png\" width=\"346\" height=\"246\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.dotnettricks.com\/learn\/hadoop\/apache-hadoop-ecosystem-and-components\">www.dotnettricks.com<\/a><\/div>\n<\/div>\n<p><b>MapReduce<\/b> — это фреймворк для обработки наборов данных с помощью параллельного распределенного алгоритма<br \/>\n<b>HDFS<\/b> —  файловая система, предназначенная для хранения файлов больших размеров,  поблочно распределенных между узлами вычислительного кластера<br \/>\n<b>YARN<\/b> — модуль, отвечающий за управление ресурсами кластеров и планирование заданий<br \/>\n<b>Others data processing<\/b> —  остальные фреймворки по процессингу данных, например, Apache Spark, Apache Kafka, которые позволяют обрабатывать данные с помощью новых оптимизаций, что приводит к значительному приросту производительности по сравнению с MapReduce. Помимо этого другие фреймворки могут работать с разными видами нагрузок данных, например, streaming, циклические алгоритмы, в то время как MapReduce предназначен для batch обработки.<\/p>\n<h2>Apache ZooKeeper<\/h2>\n<p><b>Apache ZooKeeper<\/b> —  инструмент, который следит за синхронизацией, координацией, состоянием всего кластера распределенных приложений. ZooKeeper позволяет Big Data разработчику сосредоточиться над логикой своего приложения, вся координация сервисов ложится на плечи ZooKeeper. Apache ZooKeeper представляет из себя консистентную файловую систему небольшого размера.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-4.png\" width=\"550\" height=\"432\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/dataview.in\/apache-zookeeper-and-importance\/\">dataview.in<\/a><\/div>\n<\/div>\n<h2>Архитектура HDFS<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-3.png\" width=\"624\" height=\"322\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.linkedin.com\/pulse\/hdfs-architecture-basic-concepts-babak-rezaei-bastani\">linkedin.com<\/a><\/div>\n<\/div>\n<p><b>HDFS (Hadoop Distributed File System)<\/b> — это распределенная append-only файловая система для хранения файлов больших размеров, поблочно распределенной по узлам вычислительного кластера. Любая файловая система состоит из иерархии каталогов с вложенными в них подкаталогами и файлами.<\/p>\n<p><b>NameNode<\/b> — это отдельный сервер, единственный в кластере для управления пространством имен файловой системы, хранящий дерево файлов, а также мета-данные файлов и каталогов. Данный сервер отвечает за открытие и закрытие файлов, создание и удаление каталогов, управление доступом со стороны внешних клиентов и соотвествие между файлами и блоками, которые реплицируются на остальные узлы данных. Сервер <b>NameNode<\/b> раскрывает расположение блоков данных на машинах кластера.<\/p>\n<p><b>Secondary NameNode<\/b> — отдельный сервер, единственный в кластере, который копирует образ HDFS (<b>fsimage<\/b>) и лог транзакционных операций (чтения, записи, удаления и т. д.) с файловыми блоками, применяет изменения, накопленные в логе к образу HDFS, а также записывает его на узел <b>NameNode<\/b>. <b>Secondary NameNode<\/b> необходим для быстрого ручного восстановления <b>NameNode<\/b> в случае его выхода из строя.<\/p>\n<p><b>fsimage<\/b> — образ файловой системы HDFS, в котором хранятся логи операций, которые происходили на <b>NameNode<\/b>. Так как вычитывать все операции логов над блоками за глубокую историю HDFS неэффективно, значит нужно объединять (merge) предыдущую версию логов операций с файловой системой с новоприбывшей пачкой логов. Данный процесс и происходит в <b>fsimage<\/b>, где он периодически обновляется новыми логами. В случае выхода из строя <b>NameNode<\/b> и его успешного восстановления, то чтобы ему вернуться к актуальному состоянию файловой системы HDFS происходит чтение <b>fsimage<\/b> с последнего объединения логов в <b>Secondary NameNode<\/b>.<\/p>\n<p><b>DataNodes<\/b> — множество серверов в кластере, отвечающие за файловые операции, хранение и работу с блоками данных. Основная необходимость <b>DataNode<\/b> — это чтение и запись данных, выполнение команд от <b>NameNode<\/b> по созданию, удалению и репликации блоков, а также периодическую отправку сообщений о состоянии обработки запросов на чтение и запись, поступающих от клиентов файловой системы HDFS. Приложению работающему с Apache Hadoop не достаточно иметь доступ только к NameNode, она должна иметь доступ к каждой DataNode.<\/p>\n<p>В HDFS есть 3 места, где могут храниться его настройки:<br \/>\n— глобальные настройки для всего HDFS кластера, это те настройки, которые применяются по умолчанию, если мы не указали что-то отличное. Одной из таких настроек — это размер блока файла.<br \/>\n— настройки для конкретной папки HDFS<br \/>\n— настройка для конкретного файла<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-5.png\" width=\"800\" height=\"437\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/phoenixnap.com\/kb\/apache-hadoop-architecture-explained\">phoenixnap.com<\/a><\/div>\n<\/div>\n<p><b>Блоки и файлы<\/b><br \/>\n<b>Файл<\/b> — это только запись в мета-данных на NameNode, содержимое же файла хранится в нескольких <b>блоках<\/b> одинакового размера на DataNode’ах. Основное назначение блоков в том чтобы сделать процесс чтения и записи предсказуемым. Сложно управлять одним большим файлом, переместить с одного сервера на другой, так как он может быть большим по объему. Когда нам нужно прочитать этот файл, то мы смотрим в справочник метаданных на NameNode и узнаем на каких DataNode’ах находятся блоки этого файла. Важно понимать, что DataNode’ы не знают что за блоки данных они хранят, к какому файлу они относятся и в случае выхода из строя NameNode’ы собрать блоки в единый файл не получится.<\/p>\n<p>Размер блока для каждого файла можно настраивать в момент записи. Если у нас настроено, что 1 блок хранит 64 МБ данных, то файл размером 65 МБ будет распределен на 2 блока, где 1 блок имеет 64 МБ данных, а второй 1 МБ данных. Блоки как уже понятно нарезаются по размеру и все блоки кроме последнего имеют один и тот же размер. Размер блока после записи файла поменять нельзя, так как блоки уже распределены на разные сервера.<\/p>\n<p>В HDFS существует проблема записи мелких файлов. NameNode хранит файлы в оперативной памяти, где как раз и лежит информация о связи файла с блоками и чем больше файлов, тем быстрее закончится место, поэтому важно следить за записью файлов и не плодить их с помощью мелких для экономии места в оперативной памяти NameNode. Примерный размер для хранения каждого такого файла равен 150 байт. Поэтому небольшие файлы в HDFS хранить неэффективно: много мелких файлов будут занимать много места на NameNode, больше, чем требуется для хранения их содержимого. Для сети в случае падения DataNode’ы проще дореплецировать 1 раз размер блока в 1 ГБ, чем 1000 мелких файлов в 1 МБ.<\/p>\n<p>У каждого блока данных есть отдельный файл, который хранит 3 контрольные суммы (3 суммы нужны чтобы избежать коллизий). Этот файл с хэш суммами нужен чтобы проверить, что файл блока не битый. В HDFS есть процесс, который ходит по DataNode’ам и пересчитывает контрольные суммы файлов, это  необходимо чтобы проверить, что блок не сломался или блок не изменен руками администратора.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-10.png\" width=\"630\" height=\"331\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/stackoverflow.com\/questions\/34437853\/how-does-hdfs-manage-block-size\">stackoverflow.com<\/a><\/div>\n<\/div>\n<p><b>Репликация<\/b> — процесс создания копии данных с целью обеспечения сохранности данных, в случае потери одной реплики у нас всегда оставалась запасная, резервная. Создавая файл в HDFS можно указать размер файла (64 МБ по умолчанию) и кол-во реплик, по умолчанию 3. Для достижения максимальной надежности 2 и 3 реплика помещаются на разные стойки узлов данных. HDFS следит за тем, что если какие-то файлы у него недореплицированы, то он сам автоматически начинает их реплицировать до нужного количества.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-6.png\" width=\"874\" height=\"536\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/hadoop.apache.org\/docs\/r1.2.1\/hdfs_design.html\">hadoop.apache.org<\/a><\/div>\n<\/div>\n<p><b>Чтение данных в HDFS<\/b><br \/>\nКлиент HDFS запрашивает информацию у NameNode через специальный интерфейс Distributed File System о файле, проверяет существует ли он, какие права доступа. В случае прохождения всех этапов проверки NameNode выдает клиенту информацию о файле, где находятся его блоки на DataNode. Получив эту информацию клиент с помощью интерфейса FSDataInputStream идет на каждую DataNode’у и выкачивает нужную информацию.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-9.png\" width=\"898\" height=\"517\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.javatpoint.com\/hdfs\">javatpoint.com<\/a><\/div>\n<\/div>\n<p><b>Запись данных в HDFS<\/b><br \/>\nКлиент HDFS иницирует запрос на запись файла к NameNode. NameNode со своей стороны проверяет существует ли такой файл и есть ли у клиента права на запись в этот файл. Если проверки прошли успешно, то NameNode в своих мета-данных создает запись для файла. Далее клиент делит файл на несколько пакетов согласно установленному размеру блока и управляет ими в форме очереди данных. HDFS последовательно отправляет пакеты на запись в DataNode’у, создавая новые блоки. Запись происходит в 1 DataNode, дальше идет репликация записанного блока на две другие DataNode’ы, как только репликация завершается клиенту возвращается подтверждение (ack packet) того что запись файла завершена успешно. Важно отметить, что клиенты пишут напрямую в DataNode’ы, минуя Namenode’у. Благодаря этому обеспечивается высокая надежность и пропускная способность.<\/p>\n<p>Есть возможность либо удалить, либо записать файл заново, либо записать что-то в конец файла причем при записи в конец файла создается отдельный новый блок, в существующие блоки, даже если их размер не достигается предельного размера согласно настройкам HDFS, дозаписать что-то не получится. Аналогично и про запись в середину файла, такой возможности не предоставляется.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-8.png\" width=\"901\" height=\"514\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.javatpoint.com\/hdfs\">javatpoint.com<\/a><\/div>\n<\/div>\n<p><b>Высокая доступность<\/b><br \/>\n<b>NameNode (standby)<\/b> — это сервер, который необходим в случае если активная NameNode в кластере выведена из строя. В <b>Journal Node<\/b> пишутся все изменения, а NameNode (standby) читает эти изменения и становится управляющим NameNode кластера в случае потери активной NameNode.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-11.png\" width=\"719\" height=\"382\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/doc.hcs.huawei.com\/productdesc\/mrs\/mrs_08_00071.html\">doc.hcs.huawei.com<\/a><\/div>\n<\/div>\n<h2>YARN<\/h2>\n<p><b>YARN<\/b> (Yet Another Resource Negotiator) — модуль, отвечающий за управление ресурсами кластера и планирование заданий. YARN работает с Java контейнерами, похожая сущность что у Kubernetes и Mesos, но YARN больше заточен для экосистемы Hadoop. Основная идея YARN состоит в том, чтобы предоставить абстракцию управления ресурсами и запуск\/мониторинг задач двум отдельным компонентам: глобальному менеджеру ресурсов <b>Resource Manager<\/b> и локальному серверному менеджеру <b>Node Manager<\/b>.<\/p>\n<p><b>Resource Manager<\/b> — планировщик ресурсов, абстрагирующий вычислительные ресурсы кластера и управляющий их предоставлением. Для выполнения заданий он оперирует контейнерами.<\/p>\n<p>Resource Manager выполняет следующие задачи:<br \/>\n— принимает задание от Client<br \/>\n— смотрит на доступные ресурсы и выбирает сервер, на котором есть доступные ресурсы<br \/>\n— запускает на сервере <b>Application Master<\/b> для того, чтобы следить как выполняется задание, успешно ли оно выполняется<br \/>\n— передает задание <b>Application Master<\/b><br \/>\n— выделяет по запросу <b>Application Master<\/b> контейнеры с ресурсами<\/p>\n<p><b>Application Master<\/b> — главный контейнер в YARN, который отвечает за координацию всех остальных контейнеров. Если выходит из строя Application Master, то все остальные контейнеры тоже отключаются. На Application Master запускается JAR файл приложения, переданный от клиента, дальше Application Master запрашивает у Resource Manager запуск контейнеров, Resource Manager опрашивает на каких Node Manager есть свободные ресурсы, определившись у каких серверов есть необходимые ресурсы Application Master  отправляет запросы этим Node Manager для запуска контейнеров. Само приложение внутри контейнера может иметь свой планировщик ресурсов, который может запрашивать дополнительные ресурсы у Resource Manager.<\/p>\n<p><b>Node Manager<\/b> — процесс, работающий на каждом вычислительном узле и отвечающий за запуск контейнеров приложений, мониторинг использования ресурсов контейнера (процессор, память, диск, сеть) и передачу этих данных Resource Manager.<\/p>\n<p><b>Разделение ресурсов<\/b><br \/>\nYARN может приоритезировать какому приложению в первую очередь выделить ресурсы. Настроить приоритезацию можно следующим образом:<br \/>\n— Отдельная очередь для долгих тяжелых задач<br \/>\n— Отдельная очередь для мелких ad-hoc запросов<br \/>\n— Отдельная очередь для обучения ML моделей<br \/>\n— Отдельная очередь на каждый отдел и т. д.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-12.png\" width=\"1280\" height=\"720\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.edureka.co\/blog\/hadoop-yarn-tutorial\/\">edureka.co<\/a><\/div>\n<\/div>\n<h2>MapReduce<\/h2>\n<p>MapReduce — это фреймворк для обработки наборов данных с помощью параллельного распределенонго алгоритма.<\/p>\n<p>Вычислительная модель MapReduce состоит из 3 этапов:<br \/>\n— <b>map<\/b> — каждый узел кластера, хранящий данные, применяет к каждой записи некоторую функцию и выдает результат в формате ключ-значение<br \/>\n— <b>shuffle<\/b> — перераспределение данных по сети по вычислительным узлам на основе ключей из этапа <b>map<\/b><br \/>\n— <b>reduce<\/b> — применение агрегирующей функции к сгруппированным данным благодаря этапу <b>shuffle<\/b> и расчет финального результата<\/p>\n<p>Достоинства такого фреймворка:<br \/>\n— Можно обрабатывать огромные объемы данных<br \/>\n— Отказоустойчивость при обработке<br \/>\n— Data Locality — данные хранятся на тех же узлах, где происходят вычисления<\/p>\n<p>Недостатки:<br \/>\n— Частые операции чтения и записи на диск<br \/>\n— Ограниченная область применения<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-13.png\" width=\"1344\" height=\"624\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.todaysoftmag.com\/article\/1358\/hadoop-mapreduce-deep-diving-and-tuning\">todaysoftmag.com<\/a><\/div>\n<\/div>\n<h2>Hive<\/h2>\n<p><b>Hive<\/b> — пользовательский интерфейс, где написанный клиентом SQL запрос преобразуется в MapReduce job и запускается на Hadoop. Благодаря Hive можно выполнять запросы к слабоструктурированным данным, для запросов используется специальный язык HiveQL. У Hive нет своего хранилища, но он имеет отдельную БД Hive Metastore для хранения метаданных о таблицах (структур таблиц).<\/p>\n<p>Как выглядит архитектура Hive, клиенты отправляют SQL запрос на выполнение, запрос принимает HiveServer2, который отвечает за взаимодействие с клиентами. После запрос парсится с помощью компилятора для проверок наличия такой таблицы в Hadoop, следующим этапом запрос передается оптимизатору, после оптимизации запроса результат оптимизатора передается на исполнение в виде MapReduce job. Помимо MapReduce Hive может выполняться поверх Apache Spark. К сожалению, Hive — это все же не полноценная замена классической СУБД, также он не про скорость выполнения запроса, а про всеядность обработки больших объемов данных с понятным для пользователей интерфейсом, так как запуск job в YARN с процессом его приоритизаций, выделения ресурсов не быстрое действие.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/apache-hadoop-2.png\" width=\"1024\" height=\"955\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/www.interviewbit.com\/blog\/hive-architecture\/\"> interviewbit.com<\/a><\/div>\n<\/div>\n<p><b>Apache Hive Beeline<\/b> — это клиент Hive для запуска HiveQL запросов с помощью командной строки.<\/p>\n<p><b>Таблица<\/b> в структуре Hive<br \/>\nТаблица в Hive представляет из себя аналог таблицы в классической реляционной БД. Основное отличие — что данные Hive’овских таблиц хранятся просто в виде обычных файлов на HDFS. Это могут быть обычные текстовые csv-файлы, бинарные sequence-файлы, более сложные колоночные parquet-файлы и другие форматы. Но в любом случае данные, над которыми настроена Hive-таблица, очень легко прочитать и не из Hive<\/p>\n<p>Таблицы в hive бывают двух видов:<br \/>\n— классическая таблица, куда данные добавляются при помощи HiveQL<br \/>\n— внешняя таблица, данные в которую загружаются внешними системами, без участия Hive. Для работы с  внешними таблицами при создании таблицы нужно указать ключевое слово <b>EXTERNAL<\/b>, а также указать путь до папки, по которому хранятся файлы<\/p>\n<p><b>Партиции в Hive<\/b><br \/>\nТак как Hive представляет из себя движок для трансляции SQL-запросов в mapreduce-задачи, то обычно даже простейшие запросы к таблице приводят к полному сканированию данных в этой таблицы. Для того чтобы избежать полного сканирования данных по некоторым из колонок таблицы можно произвести партиционирование этой таблицы. Это означает, что данные относящиеся к разным значениям будут физически храниться в разных папках на HDFS. Партиции в Hive это не тоже самое что партиции в Oracle или другой реляционной СУБД, так как отдельные секционированные части хранятся в разных файлах на HDFS. Партиционирование в Hive является нативным функционалом и не требует создания подтаблиц как в случае с реляционными СУБД. Все партиции создаются автоматически и распределяются в каталогах HDFS.<\/p>\n<p><b>MSCK REPAIR TABLE<\/b><br \/>\nУ Hive нет контроля над хранилищем HDFS и если случилось так, что в папку таблицы были записаны данные отличным от Hive инструментом, например, Apache Spark, то Hive не увидит эти изменения. Чтобы избавиться от несогласованности данных в этой таблице необходимо выполнить команду <b>MSCK REPAIR TABLE<\/b>. Благодаря этой команде Hive проанализирует таблицу и новые партиции станут доступны в Hive.<\/p>\n<h2>Форматы хранения данных в Hadoop<\/h2>\n<p>Основными форматами хранения в Hadoop являются:<br \/>\n— Parquet<br \/>\n— ORC<br \/>\n— Avro<\/p>\n<p><b>Parquet<\/b> и <b>ORC<\/b> — это колоночный формат хранения данных, а <b>Avro<\/b> является построчным форматом. Одним из плюсов перечисленных форматов в том, что в них записана схема, то есть указаны какие поля есть в таблице, какого они типа. Помимо этого плюсом колоночного формата хранения является то, что каждый столбец таблицы — это отдельный файл в HDFS, что позволяет гораздо быстрее считывать данные по сравнению с построчным хранением данных. В случае если нам нужна высокая скорость записи широких по столбцам таблиц, то необходимо присмотреться на строковый формат хранения <b>Avro<\/b>.<\/p>\n<p>При выборе между Parquet и ORC нужно понимать в чем их принципиальные отличия:<br \/>\n— Формат Parquet лучше хранит вложенные данные, например, колонки формата json<br \/>\n— У Parquet в метаданных колонок хранятся разные статистики по типу max, min, count, это может значительно сократить время подсчета агрегатов<br \/>\n— ORC поддерживает ACID-свойства<br \/>\n— ORC эффективнее сжимает данные чем Parquet<\/p>\n",
            "date_published": "2024-02-24T13:40:40+05:00",
            "date_modified": "2024-04-09T12:43:28+05:00",
            "tags": [
                "BigData",
                "Hadoop",
                "IT"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/apache-hadoop-7.png",
            "_date_published_rfc2822": "Sat, 24 Feb 2024 13:40:40 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "13",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-7.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-1.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-4.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-3.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-5.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-10.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-6.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-9.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-8.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-11.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-12.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-13.png",
                    "https:\/\/slavlotski.com\/pictures\/apache-hadoop-2.png"
                ]
            }
        },
        {
            "id": "12",
            "url": "https:\/\/slavlotski.com\/all\/relyacionnye-i-neryalyacionnye-bd\/",
            "title": "Реляционные и нереляционные БД",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd.png\" width=\"671\" height=\"322\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/bigdataschool.ru\/wiki\/nosql\">bigdataschool<\/a><\/div>\n<\/div>\n<h2><b>Реляционные БД<\/b><\/h2>\n<p>SQL подход — это семейство реляционных баз данных, основанное на отношениях (связях) таблиц друг с другом. Каждая таблица представлена в виде столбцов и строк. Столбец имеет свой предопределенный тип данных, в каждой ячейке значение. Строка хранит набор связанных значений, относящихся к объекту. Для определения уникальности строки существуют уникальный идентификатор (primary key). Строки из нескольких таблиц могут быть связаны посредством внешних ключей (foreign key).<\/p>\n<p><b>Отличительные черты реляционной модели<\/b>:<br \/>\n— подходит для решения большинства существующих задач<br \/>\n— запись и чтение структурированных данных<br \/>\n— данные связаны в виде логических отношений таблиц<br \/>\n— в таблицах есть строки и столбцы, где каждый атрибут имеет свой тип данных, а в ячейке свое значение<br \/>\n— есть уникальный ключ (primary key) для определения уникальности записи<br \/>\n— есть внешний ключ (foreign key) для отношения (связи) строк одной таблицы с строками другой таблицы<br \/>\n— необходима фиксированная схема (schema), где описана структура таблицы (наименование полей, тип полей и т. п.) наложенные на таблицу ограничения (constraints, checks, excludes)<br \/>\n— благодаря поддержки <a href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">ACID свойств<\/a> обеспечивается целостное хранение и согласованность данных, высокая отказоустойчивость и надежность<br \/>\n— поддержка языка SQL для манипуляций с данными<\/p>\n<p><b>Недостатки реляционных БД<\/b>:<br \/>\n— сложно горизонтально масштабироваться<br \/>\n— невозможно хранить данные с заранее неизвестной структурой<br \/>\n— менее эффективны в обработке больших объемов данных (террабайты, петабайты), чем нереляционные БД<\/p>\n<p>Популярными представителями реляционных СУБД являются: Oracle, MySQL, MSSQL, Postgres<\/p>\n<h2><b>Нереляционные БД (NotOnlySQL)<\/b><\/h2>\n<p>NoSQL подход — это семейство нереляционных баз данных, реализующее отличный от традиционной табличной модели представления данных, где управление данными осуществляется не только с помощью языка структурированных запросов SQL.<\/p>\n<p><b>Отличительные черты нереляционной модели<\/b>:<br \/>\n— используются для решения узкоспециализированных задач<br \/>\n— запись и чтение неструктурированных данных<br \/>\n— гибкость, отсутствует фиксированное описание схемы из-за хранения данных без строгой структуры в виде документов, ключ-значений, графов и т. д.<br \/>\n— взамен ACID принципов используются <a href=\"https:\/\/ru.wikipedia.org\/wiki\/NoSQL\">BASE принципы<\/a>, которые основаны на <a href=\"https:\/\/habr.com\/ru\/articles\/130577\/\">CAP теореме<\/a><br \/>\n— возможность горизонтального масштабирования путем добавления нового сервера в кластер<br \/>\n— поддержка <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Сегментирование_(базы_данных)#:~:text=sharding)%20—%20подход%2C%20предполагающий%20разделение,правило%2C%20на%20отдельном%20вычислительном%20узле.\">шардирования<\/a><br \/>\n— высокая доступность и отказоустойчивость благодаря репликации данных<br \/>\n— обработка больших объемов неструктированных данных с низкой временной задержкой<br \/>\n— поддержка собственных SQL-подобных языков запросов, RESTful-интерфейсов, API и сложных типов данных<\/p>\n<p><b>Недостатки нереляционных БД<\/b>:<br \/>\n— отсутствие сильной целостности данных приводит к случаям чтения неактуальной информации, реплика не всегда может успеть обновиться актуальными данными<br \/>\n— сильная привязка к специфике внутреннего языка запросов конкретной СУБД, когда в реляционной БД есть SQL, который универсален для всех реляционных баз. Это приводит к сложности перехода от одной нереляционной БД к другой<\/p>\n<p><b>Виды NoSQL БД<\/b>:<br \/>\n<b>Ключ-значение (key-value)<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-1.png\" width=\"2240\" height=\"1260\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/cloud.yandex.ru\/ru\/blog\/posts\/2022\/10\/nosql\">cloud.yandex.ru<\/a><\/div>\n<\/div>\n<p>В БД данного типа записи хранятся в парах ключ-значение, где ключ — уникальный идентификатор. Key-value БД используются для систем, где очень важна скорость и данные представлены не в сложном виде. Такие БД хорошо подходят например, для хранения кэша данных, пользовательских сессий, корзин в интернет магазине.<\/p>\n<p>Популярными представителями являются: Redis (Remote Dictionary Server), DynamoDB,  Memcached<\/p>\n<p><b>Колоночные (column family store)<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-2.png\" width=\"630\" height=\"258\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Стандартная строковая СУБД. Источник: <a href=\"https:\/\/clickhouse.com\/docs\/ru\/faq\/general\/columnar-database#:~:text=Что%20такое%20столбцовая%20(колоночная)%20база,(независимо)%20от%20других%20столбцов.\">clickhouse.com<\/a><\/div>\n<\/div>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-3.png\" width=\"630\" height=\"258\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Столбцовая СУБД. Источник: <a href=\"https:\/\/clickhouse.com\/docs\/ru\/faq\/general\/columnar-database#:~:text=Что%20такое%20столбцовая%20(колоночная)%20база,(независимо)%20от%20других%20столбцов.\">clickhouse.com<\/a><\/div>\n<\/div>\n<p>В колоночных БД данные каждой колонки хранятся отдельно независимо друг от друга (для каждого столбца создается свой файл). Такой принцип позволяет считывать с диска только данные тех столбцов что указаны в запросе — это ускоряет процесс чтения данных из больших таблиц, предназначенных для аналитических целей. Также преимуществом такого хранения является возможность сильно сжимать данные, что значительно экономит место на диске. Недостатком является выполнение операций над строками, у такого типа БД они более затратные.<\/p>\n<p>Популярными представителями являются: Cassandra, Apache Hbase, ClickHouse<\/p>\n<p><b>Документоориентированные (document-oriented store)<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-5.png\" width=\"890\" height=\"559\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Схема документоориентированного БД. Источник <a href=\"https:\/\/practicum.yandex.ru\/blog\/subd-mongodb-ustanovka-i-ispolzovanie\/\">practicum.yandex.ru<\/a><\/div>\n<\/div>\n<p>Данные в этом типе БД хранятся в виде документов в формате JSON, YAML, XML. Документы складываются в коллекции, а коллекции группируются логически тем самым создается иерархия. Преимуществом такой БД является гибкость, значения и структура документов может меняться в процессе разработки. Такие БД часто применяются для каталогов товаров в маркетплейсах, в соцсетях, платформ с блогами и видео, геоаналитики.<\/p>\n<p>Популярными представителями являются: MongoDB, Amazon DynamoDB, CouchDB<\/p>\n<h2><b>Бонус<\/b><\/h2>\n<p>Классное и креативное объяснение NoSQL простым языком:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/IBzTDkYNB7I?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2023-12-22T17:49:25+05:00",
            "date_modified": "2025-10-28T23:22:24+05:00",
            "tags": [
                "IT",
                "БД"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd.png",
            "_date_published_rfc2822": "Fri, 22 Dec 2023 17:49:25 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "12",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd.png",
                    "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-1.png",
                    "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-2.png",
                    "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-3.png",
                    "https:\/\/slavlotski.com\/pictures\/relyacionnye-i-neryalyacionnye-bd-5.png",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-IBzTDkYNB7I-cover.jpg"
                ]
            }
        },
        {
            "id": "11",
            "url": "https:\/\/slavlotski.com\/all\/traditional-db-and-mpp-db\/",
            "title": "Традиционная БД против MPP БД",
            "content_html": "<h2>Предисловие<\/h2>\n<p>В данной статье разберу чем традиционные БД отличаются от MPP, в каких задачах достаточно иметь традиционную, а в каких MPP значительно лучше.<\/p>\n<h2>Симметричная многопроцессорная архитектура SMP<\/h2>\n<p>Традиционные СУБД как Oracle, Postgres, MySQL, MSSQL используются в симметричной многопроцессорной архитектуре (SMP).<br \/>\n<b>SMP архитектура<\/b> — это share-everything архитектура, где несколько процессоров сервера одинаковой производительности совместно используют оперативную память, что позволяет быстро обмениваться данными между процессами, жесткие диски для хранения данных. Каждый процессор может решать разные задачи причем делает это независимо друг от друга.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/traditional-db-and-mpp-db-2.png\" width=\"562\" height=\"431\" alt=\"\" \/>\n<div class=\"e2-text-caption\">SMP архитектура<\/div>\n<\/div>\n<p><b>Преимущества SMP архитектуры относительно СУБД<\/b>:<br \/>\n— Хорошо масштабируется по вертикали, добавляются дополнительные ресурсы сервера (CPU, RAM, HDD), тем самым повышая скорость отработки запросов<br \/>\n— Один сервер легче администрировать и обслуживать (управлять правами доступа, делать резервное копирование, накатывать обновления для СУБД и т. д.)<br \/>\n— Высокая производительность на небольших объемах данных, так как данные хранятся в одном месте не нужно передавать их по сети<br \/>\n— Равномерное распределение нагрузки на процессоры сервера<br \/>\n— Отлично подходит для обработки постоянного потока (real time) небольших транзакций характерных для OLTP систем<br \/>\n— Благодаря грамотному использованию индексов достигается высокая скорость чтения данных<br \/>\n— Отказоустойчивость, выход из строя одного процессора не заблокирует работу всего сервера<\/p>\n<p><b>Недостатки<\/b>:<br \/>\n— Совместное использование, конкуренция за ресурсы сервера пользователями СУБД<br \/>\n— В вертикальном масштабировании можно упереться в потолок, где добавление новых компонент (CPU, RAM) не будет давать прирост серверу в производительности<br \/>\n— Отсутствие горизонтального масштабирования<br \/>\n— Медленная обработка аналитических-OLAP запросов<\/p>\n<p>Традиционные СУБД с SMP архитектурой хорошо показывают себя в<br \/>\nOLTP-системах, где важно обрабатывать постоянный поток (real-time) небольших по размеру транзакций с бОльшей долей операций вставки. Поэтому традиционные СУБД используются в микросервисах, веб-сайтах, CRM\/ERP системах, в банках при обработке платежных транзакций.<\/p>\n<h2>Массивно-параллельная архитектура MPP<\/h2>\n<p><b>Массивно-параллельная архитектура<\/b> — это зачастую shared-nothing архитектура, где каждому серверу выделены свои процессоры, своя оперативная память, а иногда и жесткие диски. Для общения и передачи данных между серверами все сервера подключены в одну сеть. Помимо этого в MPP СУБД встроена автоматическая разбивка данных по серверам под названием <b>sharding<\/b>. Если говорить грубо, то MPP — это несколько серверов, которые параллельно трудятся для решения одной задачи. К распространенным MPP СУБД можно отнести следующие продукты: ClickHouse, Greenplum, Vertica, Teradata.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/mpp-architecture.png\" width=\"886\" height=\"589\" alt=\"\" \/>\n<div class=\"e2-text-caption\">MPP архитектура<\/div>\n<\/div>\n<p><b>Преимущества MPP архитектуры относительно СУБД<\/b>:<br \/>\n— Легкая и доступная горизонтальная масштабируемость за счет добавления новых серверов в кластер<br \/>\n— Быстрая обработка аналитических-OLAP запросов за счет шардирования и партицирования<br \/>\n— Шардирование — разделение объектов базы данных на разные сегменты. Благодаря шардированию осуществляются распределенные вычисления. Шардирование в комплексе с shared-nothing концепцией дают хороший буст в производительности. Шардирование происходит благодаря дистрибуции данных по ключу, при правильном выборе ключа дистрибуции данные распределяются по сегментам равномерно, что играет ключевую роль<br \/>\n— Партицирование — разделение больших таблиц на секции, влечет за собой повышение производительности запросов путем снижения объема сканируемых данных, читаем только нужные секции. Также облегчает обслуживание таблиц, например, проще и эффективнее удалять, перемещать секции чем всю таблицу целиком<br \/>\n— Идеально подходит для корпоративных хранилищ данных<br \/>\n— Повышенная отказоустойчивость, отсутствует единая точка отказа. При выводе из строя одного из серверов кластера, работа СУБД не прерывается<br \/>\n— Возможность работать с несколькими источниками, например, разными OLTP системами, другими хранилищами или озерами данных<\/p>\n<p><b>Недостатки:<\/b><br \/>\n— Высокие требования к сети, объединяющая сервера в один кластер. Сеть должна стабильно работать и иметь высокоскоростное соединение для передачи данных<br \/>\n— Низкая производительность для OLTP нагрузок с постоянным потоком транзакций<br \/>\n— Возможность возникновения перекоса данных на серверах кластера из-за неверно подобранного ключа дистрибуции, то есть в одном сегменте потребуется обработать значительно больше данных чем в других — это приведет к низкой производительности и нехватки памяти<\/p>\n<p>В MPP СУБД фокус идет на аналитику больших данных (терабайты, петабайты), а значит предназначена решать задачи OLAP нагрузки, например, для построения корпоративного хранилища данных с обеспечением пользователей регулярными отчетами (МСФО, РСБУ), предиктивной аналитикой, подготовки данных с целью визуализации через BI инструменты.<\/p>\n",
            "date_published": "2023-11-27T12:32:50+05:00",
            "date_modified": "2023-11-30T14:11:04+05:00",
            "tags": [
                "IT",
                "БД",
                "СУБД"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/traditional-db-and-mpp-db-2.png",
            "_date_published_rfc2822": "Mon, 27 Nov 2023 12:32:50 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "11",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/traditional-db-and-mpp-db-2.png",
                    "https:\/\/slavlotski.com\/pictures\/mpp-architecture.png"
                ]
            }
        },
        {
            "id": "10",
            "url": "https:\/\/slavlotski.com\/all\/istoriya-sozdaniya-treka-inferno\/",
            "title": "История создания трека Inferno",
            "content_html": "<p>06.11.2023 года в составе <a href=\"https:\/\/www.beatport.com\/release\/reminiscence-ep\/4328623\">EP<\/a> на британском лейбле JOOF Recordings вышел наш совместный трек с <a href=\"https:\/\/soundcloud.com\/enlusion\">Enlusion<\/a> <b>Inferno<\/b>. Сегодня расскажу вам историю его создания.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/image-1.png\" width=\"1400\" height=\"1400\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Обложка трека с <a href=\"https:\/\/www.beatport.com\/release\/reminiscence-ep\/4328623\">Beatport<\/a><\/div>\n<\/div>\n<h2><b>The Beauty of the Past<\/b><\/h2>\n<p>Изначально трек не планировалось издавать как совместную работу. В сентябре 2022 года я закончил свой новый трек под кодовым названием <b>The Beauty of the Past<\/b>, где был такой трансовый вайб с несколькими дорожками прогрессив бэйс лайна, с похожей лид партией из моих прошлых успешных работ, например,  <a href=\"https:\/\/on.soundcloud.com\/d7Q44\">The Shockwave<\/a>, аранжировку трека можно легко узнать с моего <a href=\"https:\/\/on.soundcloud.com\/6qQrn\">Terminate<\/a>, да и что тут скрывать, хотелось написать трек в стиле крутого <a href=\"https:\/\/soundcloud.com\/slamduckofficial\">Slam Duck<\/a>, вот наглядные примеры:<\/p>\n<iframe width=\"100%\" height=\"166\" scrolling=\"no\" frameborder=\"no\" allow=\"autoplay\" src=\"https:\/\/w.soundcloud.com\/player\/?url=https%3A\/\/api.soundcloud.com\/tracks\/1224540979&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true\"><\/iframe>\n<div style=\"font-size: 10px; color: #cccccc;line-break: anywhere;word-break: normal;overflow: hidden;white-space: nowrap;text-overflow: ellipsis; font-family: Interstate,Lucida Grande,Lucida Sans Unicode,Lucida Sans,Garuda,Verdana,Tahoma,sans-serif;font-weight: 100;\"><p><a href=\"https:\/\/soundcloud.com\/joof-recordings\" title=\"JOOF Recordings\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\" <a href=\"https:\/\/soundcloud.com\/joof-recordings\/slam-duck-who-are-you-original\" title=\"Slam Duck  - Who Are You (Original Mix)\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\">Slam Duck  — Who Are You (Original Mix)<\/a><\/p>\n<\/div><iframe width=\"100%\" height=\"166\" scrolling=\"no\" frameborder=\"no\" allow=\"autoplay\" src=\"https:\/\/w.soundcloud.com\/player\/?url=https%3A\/\/api.soundcloud.com\/tracks\/620894751&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true\"><\/iframe>\n<div style=\"font-size: 10px; color: #cccccc;line-break: anywhere;word-break: normal;overflow: hidden;white-space: nowrap;text-overflow: ellipsis; font-family: Interstate,Lucida Grande,Lucida Sans Unicode,Lucida Sans,Garuda,Verdana,Tahoma,sans-serif;font-weight: 100;\"><p><a href=\"https:\/\/soundcloud.com\/joof-recordings\" title=\"JOOF Recordings\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\"> <a href=\"https:\/\/soundcloud.com\/joof-recordings\/slam-duck-intergalactic\" title=\"Slam Duck  - Intergalactic (Original Mix)\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\">Slam Duck  — Intergalactic (Original Mix)<\/a><\/p>\n<\/div><p>Моя версия в целом мне очень нравилась особенно своей атмосферой, прогрессией и сочетанием драмсов с басс линией. И вот я решил скинуть данный трек <a href=\"https:\/\/soundcloud.com\/enlusion\">Enlusion<\/a> и <a href=\"https:\/\/soundcloud.com\/daniellesden\">Daniel Lesden<\/a>, чтобы узнать их мнение о треке, может уже пора релизить думал я, но рано было радоваться 😄<\/p>\n<p>Вот так звучала первая версия <s>Inferno<\/s> The Beauty of the Past:<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"522\" href=\"https:\/\/slavlotski.com\/audio\/Slavlotski---The-Beauty-of-the-Past.mp3\">Slavlotski - The Beauty of the Past<\/a><\/div>\n<\/div>\n<p>И вот первые впечатления от коллег:<\/p>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/daniellesden\">Daniel Lesden<\/a>: Мне какого-то лида не хватает, основной темы. Сейчас это по сути филер<\/p>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/enlusion\"> Enlusion<\/a>: Трек звучит приглушённо, все ключевые партии играют фоном вместо того, чтобы быть на переднем плане. Думаю, что он оживёт, если ты пересведёшь его. Мне по идеям нравится трек<\/p>\n<p>Многочисленные правки с моей стороны не приводили в восторг никого.<\/p>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/enlusion\">Enlusion<\/a>: Стало лучше. До ямы хорошо нагнетается напряжение, но после ямы ожидаешь усиления. Этого не происходит, трек просто начинается ещё раз и потом заканчивается, теперь нужно усилить напор после ямы, дать более мощный заряд<\/p>\n<p>В конечном итоге произошло это:<\/p>\n<p class=\"loud\"> <a href=\"https:\/\/www.instagram.com\/enlusion\/\">Enlusion<\/a>: Короче я готов закончить этот трек<\/p>\n<h2><b>Трансформация The Beauty of the Past в Inferno<\/b><\/h2>\n<p>У Кирилла (так зовут Enlusion) всегда в треках получались мастерские прогрессив бэйс лайны, поэтому первым же делом он решил заменить этот элемент, послушайте такую версию:<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"558\" href=\"https:\/\/slavlotski.com\/audio\/Enlusion-&-Slavlotski--Inferno-(version-1.0).mp3\">Enlusion & Slavlotski — Inferno (v.1.0)<\/a><\/div>\n<\/div>\n<p>Сразу заметно, что трек сильно подрос в качестве, он стал более полным и звучать громче, Кирилл отлично постарался со сведением трека, но все же мне не нравилась добавленная им лид партия.<\/p>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/daniellesden\">Daniel Lesden<\/a>: Мне кажется тут бас-линия нужна более качающая. Мб тек-хаусовая? Кажется что трек пытается быть драйвовым пик-таймовым, а такой отрывистый короткий бас больше к прогу подходит<\/p>\n<p>Кирилл решил поэксперементировать и вписать тек-хаусовый движок:<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"556\" href=\"https:\/\/slavlotski.com\/audio\/Enlusion-&-Slavlotski--Inferno-(Tech-House-Mix).mp3\">Enlusion & Slavlotski — Inferno (Tech-House Mix v.1.0)<\/a><\/div>\n<\/div>\n<p>Была и такая версия, Кирилл любит потрудиться 😁<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"499\" href=\"https:\/\/slavlotski.com\/audio\/Enlusion-&-Slavlotski--Inferno-(Tech-House-Mix-v.2.0).mp3\">Enlusion & Slavlotski — Inferno (Tech-House Mix v.2.0)<\/a><\/div>\n<\/div>\n<p>В это время я решил попробовать сделать свою техно версию трека, основываясь на изначальный The Beauty of the Past, Кириллу очень понравилась отсюда бочка, но в итоге пришли к мнению, что не стоит допиливать.<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"240\" href=\"https:\/\/slavlotski.com\/audio\/Inferno-(Slavlotski-mix).mp3\">Enlusion & Slavlotski — Inferno (Slavlotski Mix v.1.0)<\/a><\/div>\n<\/div>\n<p>Кирилл не останавливается и продолжает потеть над треком, здесь он отказывается от тек-хаусового движка и решает добавить наикрутейший риз и мид-перк басс, зацените:<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"495\" href=\"https:\/\/slavlotski.com\/audio\/Enlusion-&-Slavlotski--Inferno-V3-(Original-Mix).mp3\">Enlusion & Slavlotski — Inferno (v.3.0)<\/a><\/div>\n<\/div>\n<p class=\"loud\"><a href=\"https:\/\/soundcloud.com\/daniellesden\">Daniel Lesden<\/a>:  Открытых хэтов очень не хватает в оффбит. Кажется в первую половину ещё какой-то музыкальный элемент нужен. Может стаб или что-то такое простое, буквально пару нот. Эсид(?) лид в кульминации лишний. Он там ещё и прячется как-то странно как енот-воришка, будто боится выйти из тени. Ни туда, ни сюда<\/p>\n<p>Кирилл добавляет оффбит хэтов, дополнительный плак и прячет под фильтр основную мелодию в кульминации, получилось офигительно! Эта версия и осталась финальной.<\/p>\n<div class=\"e2-text-audio\">\n<div class=\"e2-text-super-wrapper e2-jouele-wrapper\"><a class=\"jouele\" data-space-control=\"true\" data-length=\"507\" href=\"https:\/\/slavlotski.com\/audio\/Enlusion-&-Slavlotski--Inferno-(Original-Mix).mp3\">Enlusion & Slavlotski — Inferno (Original Mix)<\/a><\/div>\n<\/div>\n<h2><b>Итого<\/b><\/h2>\n<p>Создание треков — это длительный, кропотливый труд, который, к сожалению, мало кто замечает, так как все оценивают финальный результат и даже не догадываются что было за кулисами. Часто бывает так, что твой трек не удостаивается должного внимания среди куча другого музыкального контента и это очень обидно, ведь ты и твой напарник могут вкладывать десятки часов, чтобы добиться офигенного результата. Давайте в данном случае поддержим в первую очередь <a href=\"https:\/\/soundcloud.com\/enlusion\">Кирилла<\/a> он проделал титаническую работу и превратил трек в настоящий бэнгер 🔥 Под поддержкой я подразумеваю, чтобы вы послушали трек на любых из стриминговых платформ, поделились треком\/моей статьей в соц сетях, чтобы трек услышали как можно больше людей, написали комментарий здесь, в личке о своих впечатлениях.  Поддерживайте музыкантов прослушиваниями, вниманием, ведь это драйверы продолжать творить!<\/p>\n<h2><b>SoundCloud<\/b><\/h2>\n<iframe width=\"100%\" height=\"166\" scrolling=\"no\" frameborder=\"no\" allow=\"autoplay\" src=\"https:\/\/w.soundcloud.com\/player\/?url=https%3A\/\/api.soundcloud.com\/tracks\/1657876038&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true\"><\/iframe>\n<div style=\"font-size: 10px; color: #cccccc;line-break: anywhere;word-break: normal;overflow: hidden;white-space: nowrap;text-overflow: ellipsis; font-family: Interstate,Lucida Grande,Lucida Sans Unicode,Lucida Sans,Garuda,Verdana,Tahoma,sans-serif;font-weight: 100;\"><p><a href=\"https:\/\/soundcloud.com\/joof-recordings\" title=\"JOOF Recordings\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\">JOOF Recordings<\/a> · <a href=\"https:\/\/soundcloud.com\/joof-recordings\/enlusion-slavlotski-inferno\" title=\"Enlusion & Slavlotski - Inferno ( Original Mix)\" target=\"_blank\" style=\"color: #cccccc; text-decoration: none;\">Enlusion & Slavlotski — Inferno ( Original Mix)<\/a><\/p>\n<\/div><h2><b>YouTube<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/fHumf_sGSnE?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p>В скором времени <a href=\"https:\/\/fanlink.to\/JOOF483\">здесь<\/a> появятся ссылки на остальные стриминговые платформы. Как говорится stay tuned!<\/p>\n",
            "date_published": "2023-11-07T21:11:06+05:00",
            "date_modified": "2023-11-07T21:07:34+05:00",
            "tags": [
                "Музыка",
                "Музыкальный продакшен",
                "Прогрессив",
                "Релиз",
                "Транс"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/image-1.png",
            "_date_published_rfc2822": "Tue, 07 Nov 2023 21:11:06 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "10",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/jouele\/jouele.css",
                    "system\/library\/jouele\/jouele.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/image-1.png",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-fHumf_sGSnE-cover.jpg"
                ]
            }
        },
        {
            "id": "9",
            "url": "https:\/\/slavlotski.com\/all\/kolesa-conf23\/",
            "title": "kolesa conf’23",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/Kolesa-conf2023.png\" width=\"1280\" height=\"853\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник оригинала фото: <a href=\"https:\/\/t.me\/kolesa_group\/531\">Kolesa Group<\/a><\/div>\n<\/div>\n<p>07.10.2023 в Алмате состоялась ежегодная конференция Kolesa Conf’23. Kolesa Conf’23 — это масштабная конференция, объединяющая IT-сообщество Казахстана.<\/p>\n<h2><b>О Kolesa Group<\/b><\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kolesa-conf23.png\" width=\"1200\" height=\"630\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/kolesa.group\">Kolesa Group<\/a><\/div>\n<\/div>\n<p>Kolesa Group — казахстанская IT-компания, которая специализируется на создании сервисов по размещению частных и бизнес объявлений в сфере авто, недвижимости, товаров и услуг в Казахстане и Узбекистане.<\/p>\n<p>Главными продуктами компании являются мобильное приложение <a href=\"https:\/\/kolesa.kz\">kolesa.kz<\/a> — торговая площадка для автомобилистов, сайт <a href=\"https:\/\/krisha.kz\">krisha.kz<\/a> — размещение объявлений о недвижимости, <a href=\"https:\/\/obyavleniya.kaspi.kz\">market.kz<\/a> — сайт бесплатных объявлений общей тематики. Продуктами компании ежемесячно пользуются 15 миллионов пользователей.<\/p>\n<p>Компания была основана в 1996 году. Вначале своего пути компания занималась выпуском газетного издания «Колёса», где можно было разместить объявление о продаже своего авто с фотографиями и  техническими характеристиками.<\/p>\n<h2><b>Место проведения<\/b><\/h2>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"800\" data-ratio=\"1.498127340824\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/kolesa-conf23-1.png\" width=\"800\" height=\"534\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/kolesa-conf23-2.png\" width=\"1569\" height=\"1046\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/telegram-cloud-photo-size-2-5274177951128210823-y.jpg\" width=\"1280\" height=\"853\" alt=\"\" \/>\n<\/div>\n<div class=\"e2-text-caption\">Кинотеатр «Арман» на проспекте Достык. Источники: <a href=\"https:\/\/sovietarch.strelka.com\/en\/city\/almaty\">sovietarch.strelka<\/a>, <a href=\"https:\/\/kino.kz\/cinema\/14\">kino.kz<\/a>, <a href=\"https:\/\/t.me\/kolesa_group\/531\">Kolesa Group<\/a><\/div>\n<\/div>\n<p>Кинотеатр «Арман» открылся для посетителей в 1968 году, здание было спроектировано в лучших традициях эпохи совесткого модернизма с барельефом на боковых фасадах, отражающий путь Казахстана. Внутри вас встречает закусочная и пространство для проведения развлекательных мероприятий. Сейчас кинотеатр насчитывает 4 кинозала два на первом этаже и два на втором.<\/p>\n<h2><b>Направления конференции<\/b><\/h2>\n<p>Количество направлений полностью совпадает с количеством залов кинотеатра «Арман».<br \/>\n— <b>WEB<\/b> про Backend, Frontend, Security и QA<br \/>\n— <b>MANAGEMENT<\/b>  про запуск продукта, управление командой, изменение и управление процессами<br \/>\n— <b>MOBILE<\/b> про iOS, Android разработку, QA, Security<br \/>\n— <b>DATA<\/b> про ML, Product Analytics, Data Engineering<\/p>\n<p>Больше всего докладов удалось послушать именно на направлении <b>DATA<\/b>. В качестве бонуса порекомендую по докладу с направления <b>MANAGEMENT<\/b> и <b>MOBILE<\/b>.<\/p>\n<h2><b>Многоступенчатое тестирование и зоопарк моделей в ClearML<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/unibiCxOW2Y?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p><b>Спикер:<\/b> Андрей Шадриков, R&D Team Lead, Verigram<br \/>\n<b>О докладе:<\/b> Зачем делать много разных тестов ML-моделей и изменять их со временем? Этот подход помогает проверять модели на скрытые байесы, но добавляет проблемы в отслеживании зоопарка моделей.  Как в Verigram решают проблему с отслеживанием зоопарка моделей, используя ClearML, как в связке с отчётами и GitLab снижается трение между командой разработки и бизнеса.<br \/>\n<b>Основные тезисы доклада:<\/b><br \/>\n— В данных может быть много bias по разным причинам<br \/>\n— В ClearML можно разбивать тесты через параметры, можно искать по тегам, навешивать теги на модели, сохранять uncommited changes вместе с экспериментом<br \/>\n— ClearML проще расскатывается, чем MLFlow<br \/>\n— Если у вас уже готовая, настроенная инфраструктура, то переходить на ClearML не стоит<br \/>\n— ClearML — большой комбайн, может потреблять значительное кол-во ваших ресурсов<\/p>\n<h2><b>Эволюция подходов к персонализации в Авто.ру<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/G0tBWwdpUtU?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p><b>Спикер:<\/b> Вадим Кохтев, Руководитель ML-направления, Яндекс Вертикаль<br \/>\n<b>О докладе:<\/b> Путь Авто.ру в персональных рекомендациях, почему полезно строить платформенные решения и откуда у пользователя появилась особая роль<br \/>\n<b>Основные тезисы доклада:<\/b><br \/>\n— Изначально на Авто.ру был атрибутивный поиск без рекомендаций и персонализации<br \/>\n— Решили внедрить бесконечную ленту как в VK, Instagram вместо главной страницы для повышения retention<br \/>\n— В рекомендациях начали показывать объявления из истории просмотренных, рекомендацию похожих<br \/>\n— Замешивание контента с помощью постов пользователей, статей про авто<br \/>\n— Персонализация с помощью определения намерений, что пользователь хочет делать на сервисе. В результате чего у посетителя появляется набор предсказаний и роль<\/p>\n<h2><b>Повышение качества данных с использованием Zero Bug Policy<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/nAPrLVq5MbE?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p><b>Спикер:<\/b> Олег Харатов, Technical unit lead, Авито<br \/>\n<b>О докладе:<\/b> Как системный подход по работе с проблемными данными помог в борьбе с ошибками в хранилище данных, какие метрики использовали для оценки этого подхода и как договаривались с владельцами данных<br \/>\n<b>Основные тезисы доклада:<\/b><br \/>\n— В Avito Anchor modeling (6НФ), поэтому в детальном слое на проде крутятся несколько 10 тысяч таблиц<br \/>\n— Кол-во витрин растет очень быстро, а число ошибок растет еще быстрее<br \/>\n— Важно разделять витрины на несколько уровней важности: критичные, важные, стандартные, неважные<br \/>\n— Zero Bug Policy — это про то, что не стремишься решить все баги на проде, а лишь самые важные. Подход отвечает на вопросы какие, когда и кто<br \/>\n— Создали матрицу приоритетов в разрезе типа бага, важности витрин с SLA на исправление<br \/>\n— К большему числу багов необходимо подходить системно, трекать как быстро решаются проблемы с данными и оценивать метриками<\/p>\n<h2><b>Как правильно развивать продукт через исследования, поиск проблем и точек роста. Discovery в Kolesa Group<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/b0YkT6VLAPA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p><b>Спикер:<\/b> Дмитрий Казаков, Директор по аналитике, Kolesa Group<br \/>\n<b>О докладе:<\/b> Как в Kolesa перешли к discovery-процессам, через какие сложности прошли и какие проблемы Discovery помогает решать. Доклад будет полезен командам, которые хотят поставить на поток поиск и внедрение фичей в продуктовых командах и которые сталкивались с неэффективностью в этих процессах.<br \/>\n<b>Основные тезисы доклада:<\/b><br \/>\n— Discovery — поиск и работа с проблемами и точками роста<br \/>\n— Discovery нужно внедрять когда нехватка идей в продукте, есть искажения в принятии решений, есть фокус на project management, а не product management<br \/>\n— Double Diamond — основа Discovery в Kolesa. Спрашивайте у дизайнеров как строить продукт, они лучше понимают пользователей<br \/>\n— Команда Discovery состоит из Product Owner, аналитиков, дизайнеров, core команды сервиса, техлиды<br \/>\n— Систематизируйте хранение информации вокруг Discovery<br \/>\n— Инструменты Discovery должны быть такими, чтобы человеку со стороны было легко разобрать смысл написанного<br \/>\n— Выросло на 40% кол-во исследований и проверок идей в команде после внедрения Discovery<br \/>\n— Рост вовлеченности команды в продукт<br \/>\n— Начали работать от проблемы, а не от решений<\/p>\n<h2><b>Философия архитектуры<\/b><\/h2>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/8migJjRFD68?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p><b>Спикер:<\/b> Алексей Емелин, Руководитель группы разработки на Android, Yandex<br \/>\n<b>О докладе:<\/b> Основные трудозатраты программиста — это обдумывание кода, своего и чужого. А можно ли снизить эти трудозатраты? Как устроен процесс мышления? Есть ли методологии, помогающие лучше понять код? Поможет ли знание Канта и Гегеля глубже осознать логику MV* архитектуры и предположить, что будет после MVI? На эти и многие другие философские вопросы об архитектуре ПО Алексей постарался ответить в своем выступлении<br \/>\n<b>Основные тезисы доклада:<\/b><br \/>\n— Цель архитектуры — уменьшить человеческие трудозатраты<br \/>\n— Понимание того как мы мыслим может приблизить к цели архитектуры<br \/>\n— Философия — наука о мышлении, дает методологию постижения истины<br \/>\n— Принцип историзма — при рассмотрении чего либо в окружающем мире нужно учитывать нормы того времени, то есть что было принято тогда, какие технологии были в то время, на какой стадии развития они находились<br \/>\n— «Все течет, все меняется», то есть все есть процесс. В процессе нет границ<br \/>\n— Противоречие или парадокс — двигатель прогресса по философии<br \/>\n— Рассматривая явления в движении в развитии, появляется возможность выявлять тенденции к изменениям и причина изменений строится в какой-то проблеме<\/p>\n<h2><b>Остальные активности и плюшки<\/b><\/h2>\n<p>При входе на конференцию нам раздавали welcome паки, где подарили следующие ништяки:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/telegram-cloud-photo-size-2-5353041930163965879-y.jpg\" width=\"1280\" height=\"960\" alt=\"\" \/>\n<\/div>\n<p>На втором этаже расположилась развлекательная часть конференции, было 7-8 стендов от самих Kolesa и их партнеров, где можно было побатлиться в игре по определению ЯП, пройти виртуальный квест, постоять на баланс-борде, поугадывать мемы на карте мемасов, выиграть призы, правильно ответив на IT-вопрос разной категории сложности и многое другое.<\/p>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"1707\" data-ratio=\"0.666796875\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/IvanStepanov_131.jpg\" width=\"1707\" height=\"2560\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/1A0A3597.jpg\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/1A0A3592.jpg\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/1A0A3772.jpg\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<img src=\"https:\/\/slavlotski.com\/pictures\/1A0A3577.jpg\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<\/div>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/drive.google.com\/drive\/folders\/19_RuLUUQ93rBgIP_MpBakDj6g1AA6wV3\">Kolesa Group<\/a><\/div>\n<\/div>\n<p>В конце основной части было выделено время на пообщаться за кружечкой прохладного, пофотографироваться и подготовиться отправиться на after-party в местном баре.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/1A0A5069.jpg\" width=\"2560\" height=\"1707\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Источник: <a href=\"https:\/\/drive.google.com\/drive\/folders\/19_RuLUUQ93rBgIP_MpBakDj6g1AA6wV3\">Kolesa Group<\/a><\/div>\n<\/div>\n<h2><b>Полезные ссылки<\/b><\/h2>\n<p>Фото галерея конференции: <a href=\"https:\/\/drive.google.com\/drive\/folders\/19_RuLUUQ93rBgIP_MpBakDj6g1AA6wV3\">Kolesa Group<\/a><br \/>\nЗаписи выступлений с направления <a href=\"https:\/\/youtube.com\/playlist?list=PL3q8gXVayhpcjeFlWE_5HIrkNbOzeJoME&si=ckhHHkC5pdsW5BQ3\">DATA<\/a><br \/>\nЗаписи выступлений с направления <a href=\"https:\/\/youtube.com\/playlist?list=PL3q8gXVayhpdSxWACHszStCY5JxCeKysD&si=GofCYZA2lTdpTmrM\">MANAGEMENT<\/a><br \/>\nЗаписи выступлений с направления <a href=\"https:\/\/youtube.com\/playlist?list=PL3q8gXVayhpcsm3PPLhHOAn4KSGM9oSX0&si=ObSuYWaXuP8Pj8Wz\">MOBILE<\/a><br \/>\nЗаписи выступлений с направления <a href=\"https:\/\/youtube.com\/playlist?list=PL3q8gXVayhpfwM_1VVp13jhQXUZt-IP1v&si=eII2pzyw9WZo7Os9\"> WEB<\/a><\/p>\n<p>В качестве бонуса видеообзор конференции от команды Kolesa:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/xDdngNVCNc4?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2023-11-06T18:20:37+05:00",
            "date_modified": "2023-11-06T18:25:51+05:00",
            "tags": [
                "IT",
                "Анализ Данных",
                "Конференция",
                "Менеджмент",
                "Философия"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/Kolesa-conf2023.png",
            "_date_published_rfc2822": "Mon, 06 Nov 2023 18:20:37 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "9",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/fotorama\/fotorama.css",
                    "system\/library\/fotorama\/fotorama.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/Kolesa-conf2023.png",
                    "https:\/\/slavlotski.com\/pictures\/kolesa-conf23.png",
                    "https:\/\/slavlotski.com\/pictures\/kolesa-conf23-1.png",
                    "https:\/\/slavlotski.com\/pictures\/kolesa-conf23-2.png",
                    "https:\/\/slavlotski.com\/pictures\/telegram-cloud-photo-size-2-5274177951128210823-y.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-unibiCxOW2Y-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-G0tBWwdpUtU-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-nAPrLVq5MbE-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-b0YkT6VLAPA-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-8migJjRFD68-cover.jpg",
                    "https:\/\/slavlotski.com\/pictures\/telegram-cloud-photo-size-2-5353041930163965879-y.jpg",
                    "https:\/\/slavlotski.com\/pictures\/IvanStepanov_131.jpg",
                    "https:\/\/slavlotski.com\/pictures\/1A0A3597.jpg",
                    "https:\/\/slavlotski.com\/pictures\/1A0A3592.jpg",
                    "https:\/\/slavlotski.com\/pictures\/1A0A3772.jpg",
                    "https:\/\/slavlotski.com\/pictures\/1A0A3577.jpg",
                    "https:\/\/slavlotski.com\/pictures\/1A0A5069.jpg",
                    "https:\/\/slavlotski.com\/pictures\/remote\/youtube-xDdngNVCNc4-cover.jpg"
                ]
            }
        },
        {
            "id": "8",
            "url": "https:\/\/slavlotski.com\/all\/python-for-data-analysis-course\/",
            "title": "Python for Data Analysis Course",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/python-for-data-analysis-course.png\" width=\"1200\" height=\"600\" alt=\"\" \/>\n<\/div>\n<p>На днях презентовал внутри своей компании тренажер\/курс по Python для анализа данных. Если вы когда-нибудь хотели начать программировать на Python или вам надоел Excel, и вы хотите попробовать что-то поинтереснее для аналитики или визуализации, то рекомендую начать с данного <a href=\"https:\/\/github.com\/slavlotski\/Python-for-Data-Analysis-Course\">тренажера<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/slavlotski.com\/pictures\/qr-code-python-analysis-course-2.png\" width=\"250\" height=\"250\" alt=\"\" \/>\n<div class=\"e2-text-caption\">QR-Code на Github репо с тренажером<\/div>\n<\/div>\n<h3>Для кого данный тренажер?<\/h3>\n<p>Тренажер отлично подойдет для:<br \/>\n— бизнес-экспертов, работающих с табличными данными<br \/>\n— дата-аналитиков<br \/>\n— людей, кто никогда не программировал на Python<\/p>\n<h3>Формат обучения<\/h3>\n<p>— Онлайн<br \/>\n— В своем темпе без каких-либо дедлайнов<br \/>\n— В среднем тренажер займет от 2 до 4 недель<\/p>\n<h3>Что нужно для тренажера?<\/h3>\n<p>— Доступ в Интернет<br \/>\n— Браузер Google Chrome (рекомендация)<br \/>\n— Аккаунт Google<\/p>\n<h3>Содержание тренажера<\/h3>\n<p>Тренажер состоит из 3-ех больших блоков, написанных на <a href=\"https:\/\/jupyter.org\">Jupyter Notebook<\/a>:<\/p>\n<ol start=\"1\">\n<li>Введение в Python<\/li>\n<li>Основы Numpy и Pandas<\/li>\n<li>Визуализация данных<\/li>\n<\/ol>\n<h3>После прохождения тренажера вы будете уметь:<\/h3>\n<p>— Писать и читать простые программы на Python<br \/>\n— Загружать excel, csv в Jupyter,  манипулировать данными с помощью библиотек pandas, numpy<br \/>\n— Визуализировать данные с помощью библиотек matplotlib и seaborn<br \/>\n— Сможете использовать Jupyter Notebook в своей повседневной работе<\/p>\n<h3>Обратная связь и помощь<\/h3>\n<p>В случае если вы хотите поделиться обратной связью, указать на ошибки, опечатки или у вас возник вопрос по теме тренажера, то можете связаться со мной <a href=\"https:\/\/t.me\/Slavlotski\">здесь<\/a>.<\/p>\n",
            "date_published": "2023-10-24T17:45:02+05:00",
            "date_modified": "2025-05-09T14:32:01+05:00",
            "tags": [
                "IT",
                "Анализ Данных",
                "Программирование"
            ],
            "image": "https:\/\/slavlotski.com\/pictures\/python-for-data-analysis-course.png",
            "_date_published_rfc2822": "Tue, 24 Oct 2023 17:45:02 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "8",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/slavlotski.com\/pictures\/python-for-data-analysis-course.png",
                    "https:\/\/slavlotski.com\/pictures\/qr-code-python-analysis-course-2.png"
                ]
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}