Вопреки известным глобальным проблемам пусковая программа 2020 года является одной из лучших за последние 20 лет: 114 попыток орбитального запуска от восьми стран. Впереди двое: США (44 запуска при 4-х авариях) и Китай (39 запусков при 4-х авариях). На третьем месте Россия с 17 запусками без аварий. Из «редких» отметились Иран и Израиль.
Статистика запусков за 2020 год по странам.Легенда к статистике
2020. Прогнозы и реальность.
В оценках пусковых программ года преобладает негатив. Это связано с большими планами и ожиданиями на этот год. Можно оценить прогнозы (2019 год) и реальные результаты. Три первые (США, Китай и Россия) «выполнили план» только на 50%. У остальных еще хуже, особенно Индия и Европа.
Сравнение прогнозов (задний план) с реальными запусками 2020 года. Прогнозы неофициальные (личная оценка).
2020. Аварии года.
Год был рекордным на аварии. Это связано, в первую очередь, с испытаниями новых ракета-носителей (5 аварий). Но подвели и проверенные — CZ-3B, Electron, Vega. Россия второй год без аварий (в прогнозах традиционно 1-2 аварии).
Аварийные орбитальные запуски 2020 года.
2020. Пятерка «летающих» ракет.
Самые «летающие» ракеты остались традиционными за последние годы — американская Falcon 9, русская «Союз-2» и китайские CZ-2 и CZ-3. Уверенно вошел в пятерку Electron.
Пятерка «летающих» ракет в этом году.
2020. Лучшая ракета-носитель года.
Безусловный лидер года — американская Falcon 9 от компании SpaceX. Лидер по числу запусков, по количеству выведенных спутников, по общему весу полезных нагрузок на орбиту, по пилотируемой программе, по общественному интересу и пиару.
Пусковая компания Falcon 9. 2020 год.
2020. Что запомнилось.
— Пилотируемые полеты Crew Dragon от компании SpaceX. После десятилетия работы, многочисленных задержек и героических усилий, американцы восстановили свою компетенцию в запусках пилотируемых миссий. Сейчас и надолго — будут запускать на своих кораблях со своей земли своих астронавтов. Программа МКС наконец сможет преодолеть ограничения по численности экипажа из за малой вместимости корабля «Союз» и расширить научную и технологическую программу исследований.
— «Марсианские миссии». Целых три (а должно быть четыре) автоматических межпланетных станций отправились к Марсу. Две от новых «космических игроков» — китайская и арабская. Особенно китайская — самая комплексная и сложная по составу и задачам из всех — орбитальный аппарат, спускаемый аппарат и марсоход.
— «Лунные миссии». Полеты неофитов лунных исследований — Китая, Индии и Израиля. Две неудачи и безусловный успех китайцев — в стремительной и сложной миссии по возвращению лунного грунта на Землю.
— Новые ракеты и проекты. Запущенные Китаем — восстановление полетов тяжелой ракеты, запуски новых ракета-носителей, новый пилотируемый корабль, новый крылатый корабль. Россия продолжила испытания тяжелой ракеты «Ангара». Первые запуски новых ракет в США и Китае.
— Низкоорбитальный интернет. Реальное развертывание в космосе массовых спутниковых группировок низкоорбитального интернета. Две системы — Starlink и Oneweb.— Научный космос. Помимо запуска АМС к Марсу и Луне. Успешная миссия по забору грунта на астероиде Бену (США), возвращение грунта с астроида Рюгу (Япония), запуск и работа радиотелескопа Спектр-РГ, запуск солнечного зонда … Плюс с десяток научных спутников на низкую околоземную орбиту нескольких стран.
— Конкуренция планов и пиара. Огромное количество объявленных планов в новых проектах. Программа «Артемида», строительство китайской орбитальной станции, расширение русского сегмента МКС и планы на новую станцию от России, «ядерный буксир» от России. Большое количество частных низкоорбитальных группировок и новых ракет.
Очередные мультфильмы и грандиозные планы освоения Марса от Илона Маска в этом году не впечатлили — не было вдохновляющей презентации на фоне группы сверкающих Starship. Остались очередные дежурные обещания «будущих полетов через несколько месяцев». Но строительство и испытание прототипов Starship (в том числе и в полете) идет в быстром темпе и является одной из главных тем в СМИ (при освещении космической деятельности).
Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.
За год руководства было решено немало важных вопросов и их решений, о которых я сегодня буду рассказывать. Статья в большей степени предназначена для руководителей и тимлидов разработки, в команде которой требуются перемены. У читателя может сложиться мнение, что у меня и команды не было скучных рутинных задач, это не так. Эта часть работы будет пропущена.
Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps. Стэк разработки: Python, PHP, JavaScript. Мои глобальные задачи были стандартны, но это не делало их простым. Я упорядочил их по порядку решения задач:
Повысить качество и отказоустойчивость инфраструктуры
Повысить квалификацию разработчиков
Повысить качество ПО
Повышение качества и отказоустойчивости инфраструктуры
Проблема №1: Команда работала “по старинке”.Каждый разработчик сам управлял локальным окружением разработки. Это приводило ко всем знакомой ситуации при возникновении ошибок на production’е: у меня локально работало. Окружение должно быть единым для всех ваших окружений. С приходом контейнеризации (в частности, Docker’а) в массы, эта задача стала легко решаемой.
Решение:Контейнизируйте ваши приложения. Выберите единую ОС для вашего базового образа (на тот момент у нас был Ubuntu 18.04 LTS). Устанавливайте 3-rd party пакеты с точной версией, вплоть до хотфиксной. Пусть поддержкой занимаются системные админстраторы и DevOps’ы, разработчикам делать там нечего.
Проблема №2:Много self-hosted сервисов, мало системных администраторов
Все проекты и их компоненты были на выделенных серверах, которые поддерживались двумя (а долгое время одним) системным администратором. Большая часть работы была рутинным админством: тут «подкрутить», там «отшлифовать».
Решение: Освободите руки системного администратора от рутинных задач насколько это возможно. Автоматизируйте свои процессы с помощью Terraform и Ansible. На уровне малого бизнеса/стартапа зачастую дешевле делегировать часть работы, чем нанять еще одного системного администратора. Возьмите managed СУБД и K8s, за одно решив таким образом такие проблемы как отказоустойчивость, масштабируемость и админством этой инфраструктуры.
Проблема №3: Вшитые в код ключи/пароли/сертификаты (секреты) от production сервисов
Решение: Внедрите систему хранения секретами, такой как Vault. Настройте политику доступа к этим данным. Перенесите все секреты из кода в хранилище и запрашивайте их при инициализации приложения.
Повышение квалификации разработчиков
На момент моего прихода в команде были в основном junior разработчики.
Проблема №1: Низкая квалификация разработчиков
Если ваш код низкого качества и тем временем ваша компания состоялась на рынке, стоит стабилизировать кодовую базу. Начать нужно с людей.
Решение: Оставьте только талантливых людей (даже если они junior’ы), которые быстро учатся и самое главное, хотят учиться. На остальных не тратьте время. Новичков вполне могут позволить другие крупные и состоявшиеся компании. Наберите вместо 5 новичков 2 хороших специалиста, которые будут качественно выполнять свою работу. Старайтесь находить тех, у кого вы бы сами могли чему-нибудь научиться в узкой области.
Проблема №2: Каждый разработчик пишет код в своем стиле
Разработчикам сложно (читайте долго) переходить из одной области проекта в другой, потому что его писал другой разработчик. Во всех оркестрах играют профессиональные музыканты, отлично знающие свое дело. Тем не менее у оркестра есть свой дирижер, который задает свой ритм и стиль работы.
Решение: Дирижируйте свою команду. Прививайте разработчиков к единому стилю написания кода. Используйте линтеры типа we-make-python-styleguide (сборник плагинов к flake8) для поддержания единого стиля.
Проблема №3: Отсутствие технологического развития
Разработчики не развиваются в технологическом плане, решая задачи так, как они привыкли их решать.
Решение: Много читайте и постоянно следите за новинками вашей области. Внедряйте и обучайте этому вашу команду. Вместе с ростом квалификации вашей команды растет и ваша.
Повысить качество ПО
Из предыдущего раздела можно сделать вывод, что код, написанный подавляющим большинством junior’ов был низкого качества. Смешанные предметные области, ООП не по назначению, спаггети-код. Отсутствие автотестов или их нечитабельность.
Проблема №1: Плохо спроектированный код
Cотни и тысячи строк кода смешанных предметных областей, в который сложно вникнуть, поддерживать и улучшать.
Проблема №2: Классы, классы и еще раз классы по всюду
Проектировать большой набор абстракций с одной реализацией не есть хорошо. Не нужно использовать классы только ради группировки вашей бизнес-логики
Решение: Для группировки сойдут модули и пакеты. Функцию не обязательно оборачивать в класс. Прочитайте о YAGNI, KISS, а также о функциональном программировании.
Проблема №3: Слишком сложные для понимания автотесты
Сразу взять и понять как работает та область, которой вам поручили заняться сложно.
Решение: Описывайте логику в виде BDD сценария. Вникать в предметную область гораздо проще прочитав его сценарии, чем программный код.
Заключение
Перемены, описанные выше происходили в течение 1 года. По всем 3 пунктам удалось добиться хороших результатов. Инфраструктура и приложения стали реже падать, удалось снизить кол-во инцидентов в 10 раз. Системный администратор и DevOps стали крепче спать по ночам. Кодовая база всех проектов стала похожей, что позволило новым разработчикам быстро переключатся из одного проекта в другой. Укрепился командный дух. И не мало важно, руководство осталось довольным.
Напоследок немного новостей о «смотрелке» для логов chipmunk. Ничего особенного, никаких кардинальных изменений или же заметных фитч, а скорее работа над ошибками, да и просто хочется сказать пару слов о прошедшем, настоящем и будущем.
Это вообще о чем?
Это о программе chipmunk, позволяющей открывать файлы любых размеров и быстро по ним искать. Можно сохранять свои фильтры, можно стоить графики, мерить время и много чего другого, что не будет лишним при анализе логов. Здесь больше.
Итак, вышел релиз 2.10.2, содержащий исправления ряда ошибок. Полный список исправлений есть на github, здесь же ограничусь наиболее весомым: починили возможность определения собственного формата даты-времени при совмещении нескольких файлов (речь о функции «Merge»).
В целом часть времени стараемся тратить на наведение порядка и вылов всевозможных багов, однако основные ресурсы направлены на «переезд» движка на rust рельсы (речь о всех IO операциях, поиске, вычислениях и всем прочим, что должно летать, а не ездить), а также на проработку сетевых функций.
В любом случае, этого всего не могло случится без Вас. Именно благодаря Вашему вниманию к этому инструменту; Вашим сообщениям об ошибках, что мне в личку, что на github; Вашим предложениям по новым функциям и доработкам существующих; благодаря этому всему мы и движемся; движемся, покуда есть Ваш отклик.
Конечно, не всегда получается реализовать всё то что задумано и как оно задумано было. Не всегда получается и оперативно отреагировать на Ваши пожелания, но мы стараемся и будем стараться и впредь. В то время как найти стоящие инструменты на бесплатной основнее становится сложнее, а тот же youtube смотреть уже просто невозможно с их вставками рекламы на каждые 3-5 минут, мы верим, что слова «community» и «open source» что-то да и значат. Такой путь мы выбрали и сворачивать не собираемся.
P.S. Вся наша скромная команда будет рада Вашим поздравлениям в виде новогодних звёзд на github. Для Вас лишь, клик — для нас обратная связь и энергия! По-моему это здорово, когда одним кликом, можно поддержать разработчиков и их усилия.
В этом году Apple потрясла рынок десктопных процессоров чипом Apple M1 и устройствами на нём. Похожее событие произошло в мире облачных вычислений в прошлом году. AWS выпустили новый тип сервера на собственных ARM процессорах Graviton2. По заявлениям Amazon, соотношение производительности к цене у новых процессоров на 40% выше, чем у аналогов на x86. Ещё одно недавнее обновление — сервера Amazon RDS (облачный сервис, предоставляющий сервера баз данных) на Graviton2. Я запустил несколько бенчмарков и нагрузочный тест реального бэкенд приложения, чтобы проверить настолько ли хороши сервера на ARM процессорах и узнать какие проблемы совместимости могут возникнуть.
Производительность
Я сравнивал сервера типов t4g.small (ARM) и t3.small (x86) на AWS. На момент написания статьи цена за 1 час на x86 сервер составляет $0.0208, а на ARM сервер — $0.0168. Сервер на ARM на 20% дешевле.
Сперва я провёл нагрузочный тест при помощи wrk, запустив на серверах свежую установку recap.dev
Это шаблон docker-compose с 4 процессами. Веб-сервер, принимающий запросы и сохраняющий их в RabbitMQ и отдельный фоновый процесс, сохраняющий запросы группами по 1000 в PostgreSQL.
Я запускал wrk на сервере t3.2xlarge, находящемся в том же регионе, используя следующую команду:
wrk -t24 -c1000 -d300s -s ./post.lua <hostname>
Она непрерывно посылает запросы в течение 5 минут, используя 24 потока и 1000 HTTP соединений.
В тесте pts/compress-7zip-1.7.1 t4g.small (ARM) выдал 6833 MIPS, а сервер t3.small (x86) — 5029 MIPS. ARM сервер был производительнее на 35%.
Сервер на ARM процессоре также завершил бенчмарк pts/c-ray быстрее более чем в 2 раза. 958 секунд ушло у сервера на x86 процессоре против 458 секунд у сервера с ARM процессором.
Я также запустил несколько тестов pts/ramspeed, измеряющих пропускную способность ОЗУ при выполнении различных операций.
Тип бенчмарка
t4g.small (ARM)
t3.small (x86)
Add/Integer
50000 МБ/c
13008 МБ/c
Copy/Integer
58650 МБ/c
11772 МБ/c
Scale/Integer
31753 МБ/c
11989 МБ/c
Triad/Integer
36869 МБ/c
12818 МБ/c
Average/Integer
44280 МБ/c
12314 МБ/c
Add/Floating Point
49775 МБ/c
12750 МБ/c
Copy/Floating Point
58749 МБ/c
11694 МБ/c
Scale/Floating Point
58721 МБ/c
11765 МБ/c
Triad/Floating Point
49667 МБ/c
12809 МБ/c
Average/Floating Point
54716 МБ/c
12260 МБ/c
Вкратце, ОЗУ на сервере t4g.small с процессором Graviton2 была быстрее от 3 до 5 раз.
Если смотреть только на производительность, переход на ARM сервера это одни преимущества. Больше производительности за меньшие деньги.
Совместимость
Безусловно, один из самых больших вопросов при переходе с одной архитектуры процессоров на другую это совместимость программного обеспечения.
Некоторая часть ПО уже перекомпилирована для ARM процессоров. Например, Docker был доступен в форматах .rpm и .deb, как и большая часть образов (да, образы Docker требуют пересборки для разных архитектур). Однако, docker-compose не был скомпилирован для ARM процессоров, что вылилось в несколько часов сборки различных зависимостей из исходного кода. Скорее всего, ситуация улучшится в будущем, когда сервера на ARM станут более распространены. Сейчас, однако, в некоторых случаях, переход на ARM может принести больше затрат, чем преимуществ.
Зато сервера Amazon RDS на Graviton2 не требуют никакой настройки и позволяют получить все преимущества серверов на ARM процессорах без проблем с совместимостью.
Ввиду преимуществ ARM процессоров мы также собрали Docker образы recap.dev для архитектур arm/v7 и arm64.
Эта история произошла довольно давно, но некоторые подробности стали ясны только сейчас, отчего и настало время её рассказать.
Не будем останавливаться на описании типов параллельных реальностей, это уже давно и успешно делают многие литераторы, любители альтернативной истории, футурологи и просто поклонники подобных вещей. Перейдём сразу к делу.
А дело происходило в НИИЧАВО в тот момент, когда у Кристобаль Хозеевича Хунты не получилось навести порядок с Тройкой. Соответственно товарищ А.Привалов, выражаясь современным языком «завис» под началом товарища Выбегалло. Ноябрь выдался малоснежный, но близился новый год и т. Выбегалло пришёл к т. Привалову с поручением от Тройки: «Ввиду наступающего праздника Нового года необходимо разработать план обеспечения настроением всех жителей страны:
1) в недельный срок произвести оценку потребности нужных событий на 1000 жителей;
2) передать описание потребности из п.1 в лабораторию Хорошего настроения для реализации плана, уже доведённого до них Тройкой.
Передав поручение Тройки с резолюцией «Обеспечить январь настроением» Выбегалло, строго посмотрел на т. Привалова и сказал, что зайдёт через два дня.
Работа началась
Александр с максимально серьёзным видом кивнул. Сказал: «Немедленно займусь» и проводил уходящего т. Выбегалло взглядом. Особого беспокойства Александр не испытывал, т.к. недавно у заезжего путешественника во времени выменял на неразменный рубль notebook c Anaconda. Так что сейчас он точно знал, что Рython не только змея такая, но и полезная в хозяйстве вещь.
Немного поразмышляв о подходах, он создал данные с 1000 событий для января месяца. Малым, но приятным бонусом, было то, что 1 января выпадало на понедельник и функции обработки дат даже не понадобились. В данных он заложил два типа событий: «искренняя улыбка» и «беззаботный смех».
При подготовке к встрече Александр считал данные:
# Читаем данные о количестве событий каждого вида # Pivot самое простое средство для визуализации данных этой задачи: подсчитать сумму по типам событий Cnt_arr = pd.DataFrame() Cnt_arr = F_Lst_FULL_df.pivot_table('DT_evnt', index='Date_event',dropna = False,fill_value=0, columns='Type',aggfunc='count') # Рисуем sns.set() # используем seaborn styles по умолчанию Cnt_arr.plot() plt.xlabel('Даты событий') plt.ylabel('Количество событий')
Анализ
Когда т. Выбегалло пришёл, к обещанному времени т. Привалов показал ему графическое описание данных. Александр уточнил, что улыбки — это тип=1, а смех, это тип=2 и спросил какие вопросы нужно обсудить.
«Вот ведь т. Привалов» — сказал Выбегалло, «машина вроде умная у Вас, а чего же она сразу не обозначает, что самая важная тенденция в событиях – плавный переход от праздников к рабочему ритму?».
Александр улыбнулся и тут же в течение 5 минут быстро набрал на клавиатуре:
# Рисуем график для отображения тенденций по обоим сортам событий sns.set_style("white") gridobj = sns.lmplot(x='Date_event', y='DT_evnt', hue='Type', data=Cnt_arr, height=7, aspect=1.6, robust=True, palette='tab10', scatter_kws=dict(s=60, linewidths=.7, edgecolors='black')) # Внимание на общий масштаб и выбор добавки к минимальному и максимальному значению! # Ключевое: Наши данные в целочисленном диапазоне 0-100! # определяем размерность по X (min, max) Xmin=Cnt_arr['Date_event'].min()-1 Xmax=Cnt_arr['Date_event'].max()+1 # определяем размерность по Y (min, max) Ymin=Cnt_arr['DT_evnt'].min()-1 Ymax=Cnt_arr['DT_evnt'].max()+1 # Рисуем gridobj.set(xlim=(Xmin, Xmax), ylim=(Ymin, Ymax)) plt.title("График с линией тенденции для двух типов событий", fontsize=20) plt.show()
«Ну вот нужную тенденцию вижу. Так бы сразу!» — смягчившись, сказал Выбегалло и расплылся в довольной улыбке. Потом посерьёзнел и спросил: «А что это за пила такая была на первом рисунке? Отчего это она так дергается, мил человек?».
Александр был готов к этому вопросу (мысленно, только мысленно, он улыбнулся), а вслух сказал: «Это потому, что в данных есть две особенности: 1) количество событий определялось случайным образом, вроде как естественные всплески настроения; 2) субботы и воскресенья обеспечены пониженным количеством событий, т.к. это не рабочие дни.»
Александр замолчал, ожидая пока Выбегалло посмотрит на него, и закончил: «А для проверки отсутствия явных зависимостей я повёл кластерный анализ. Причём сами данные для удобства обогатил следующими временными признаками»:
# Добавленные признаки # Сначала день месяца (отбрасываем остаток) F_Lst_FULL_df['Date_event'] = F_Lst_FULL_df['DT_evnt']-F_Lst_FULL_df['DT_evnt']%1 # Исправляем особенность в данных 0 дату меняем на 1-ое F_Lst_FULL_df['Date_event'] = F_Lst_FULL_df['Date_event'].replace(0.0, 1.0) # Добавляем долю дня в течение суток от 0 до 1 F_Lst_FULL_df['PartOfDay'] = F_Lst_FULL_df['DT_evnt']%1 # Добавляем номера недели F_Lst_FULL_df['NWeek'] = F_Lst_FULL_df['Date_event']//7%7+1 # Добавляем номер дня в неделе 1-пн F_Lst_FULL_df['D_Week'] = 1 + (F_Lst_FULL_df['Date_event']+6)%7
На слове «кластерный» Выбегалло аж крякнул от неожиданности. Для иллюстрации «недельной» аналитики Александр запустил заранее готовый код и показал «Хитрый кругляшок», как его сразу де окрестил уже изрядно поражённый Выбегалло:
# Рисуем в двух координатах день недели и время события в доле суток количество этих событий # КЛЮЧЕВОЕ ПРАВИЛО: # равенство размерности массивов(серий) для трёх наборов данных - угла, радиуса, диаметра окружности # Самый простой способ создания таких данных - pivot vis_date = F_Lst_FULL_df.pivot_table('DT_evnt', index=['D_Week','PartOfDay'], dropna = False,fill_value=0, aggfunc='count').reset_index() Angle_dim = vis_date['D_Week'] # День недели Radius_dim = vis_date['PartOfDay'] # Часть суток (0-1) в 24 часах
# Построение # Угол отображения данных в зависимости от дня недели theta = 2 * np.pi * Angle_dim/7 # Приводим день недели к двум Pi (3.14159265...) # Площадь круга для отображения зависит от количества событий для этого дня недели area = vis_date['DT_evnt'] # colors = theta # Цвета зависят от дня недели (1-пн,2-вт,3-ср...7-вс) fig = plt.figure() # На всякий случай, если так ещё не рисовали: # Примечание: параметр, 111 - это первая строка, первый столбец и первая (единственная здесь) ячейка на сетке Figure. ax = fig.add_subplot(111, projection='polar') # Сделаем свои метки для круговой диаграммы, то что будем писать по кругу (вместо градусов) # К стати, углы увеличиваются против часовой стрелки! xtks = pd.DataFrame() xtks['val']=(2 * np.pi * Angle_dim/7).unique() # Сами значения угла xtks['mrk']=['Пн','Вт','Ср','Чт','Пт','Сб','Вс'] # Метки для его обозначения plt.xticks(xtks['val'].tolist(),xtks['mrk'].tolist()) c = ax.scatter(theta, Radius_dim, c=colors, s=area, cmap='hsv', alpha=0.75)
«С субботами и воскресеньями – хвалю, надо экономить волшебные средства» — выпалил Выбегалло, он был явно доволен. «Вот только насчёт кластерных анализов надо обмозговать. Надёжна ли вещь?» — осторожно подбирая слова и задумчиво гладя на Привалова, сказал Выбегалло. «Никаких сомнений» — сказал Александр и перешёл к показу.
Сначала нормализуем данные
Александр показал небольшой кусочек кода, который использовал для нормализации:
# Нормализация (все признаки в диапазон 0-1) d = preprocessing.normalize(F_Lst_FULL_df,axis=0) scaled_df = pd.DataFrame(d,columns = ['DT_evnt', 'Type', 'Date_event', 'PartOfDay','NWeek','D_Week']) del d
Готовим модель кластеризации (k-Menas)
Александр перешёл к коду модели и уточнил: «N_Clstr меняем для проверки нескольких гипотез.
N_Clstr=2 события делятся на кластеры по признаку тип события (улыбка/смех);
N_Clstr=7 события делятся на кластеры по признаку день недели для события;
N_Clstr=31 события делятся на кластеры по признаку день в месяце;
N_Clstr=14 делятся на кластеры по двум признакам день недели и тип события.»
# Описываем модель N_Clstr=14 model = KMeans(n_clusters=N_Clstr) # Проводим моделирование model.fit(scaled_df) # Предсказание на всем наборе данных all_predictions = model.predict(scaled_df)
Для данных посчитанных с помощью модели понижаем размерность (что бы нарисовать кластеры в двумерном пространстве)
Александр «напомнил», что кластеры определены в пространстве размерностью равной количеству признаков. Посмотреть на такое разбиение весьма проблематично. «Поэтому используем TSNE инструмент для снижения размерности нашей картинки кластеров до 2D.
# Определяем модель и скорость обучения model = TSNE() # Обучаем модель transformed = model.fit_transform(scaled_df) # Представляем результат в двумерных координатах x_axis = transformed[:, 0] y_axis = transformed[:, 1]
Рисуем для каждой гипотезы набор картинок, в качестве цвета задаём признаки, содержащие сравнительно малое количество вариантов значений
plt.title('K-Means кластеризация на кол-во кластеров: '+str(N_Clstr)+'. Цвет по типам событий') plt.scatter(x_axis, y_axis, c=scaled_df['Type']) plt.show() # Далее так же для: # Цвет по дням недели D_Week # Цвет по доле начала события в течение суток PartOfDay # Цвет по дате события Date_event # Цвет по номеру недели для события NWeek
Анализируем кластеры
Александр, окинул взглядом поле из картинок и выдержал паузу, после чего начал: «Вот, товарищ Выбегалло, как сами видите наглядная демонстрация, что чёткое распределение на ярко выраженные кластеры мы не наблюдаем только отчасти, для типов события есть разбиение на два (нижняя строчка картинок), в какой-то мере это же мы видели на первом графике (данные события одного типа не совпадают с данными события другого типа (есть только пара точек пересечений).
По остальным картинкам мы наблюдаем:
1) не односвязный характер цветовых массивов,
2) наложение разных цветов друг на друга.
Следовательно, как такового «понимания» управления настроением не ожидается. Всё веселье пройдёт по плану и строго по плану перейдёт в рабочий ритм февраля, абсолютно естественным образом!».
Выбегалло был очень доволен, широко улыбнувшись, он спросил: «Отчёт уже напечатали?». «Конечно, все эти данные вот». Александр достал папку из верхнего ящика.
«Вы молодец! Обязательно отмечу Вас при подведении итогов года!» — сказал Выбегалло и решительно отправился в секретариат Тройки.
