Русский
Русский
English
Статистика
Реклама

Блог компании step logic

Новые возможности анализа табличных данных с алгоритмами машинного обучения в Elastic

11.03.2021 12:11:09 | Автор: admin


Elastic stack, также известный как ELK Stack (аббревиатура из программных компонентов: Elasticsearch, Kibana и Logstash), это платформа построения озера данных с возможностью аналитики по ним в реальном масштабе времени. В настоящее время широко применяется для обеспечения информационной безопасности, мониторинга бесперебойности и производительности работы ИТ-среды и оборудования, анализа рабочих процессов, бизнес-аналитики.


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


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


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


  1. Обнаружение аномалий на потоке данных (Anomaly detection)
  2. Аналитика табличных данных (Data frame analytics)

Примечание: Попрактиковаться в использовании перечисленных выше наборов инструментов анализа данных можно будет 24 марта. Совместно с коллегами Elastic мы продемонстрируем, как применять Anomaly detection и Data frame analytics для выявления инцидентов информационной безопасности. Ссылка на регистрацию.

Об инструментах обнаружения аномалий Elastic ранее уже писали на Хабре. С того времени (Elastic версии 7.1) они продолжали активно развиваться, было улучшено качество алгоритмов и удобство их применения для прикладных задач. Но в этой статье мы решили осветить совершенно новый набор функций анализа табличных данных, появившийся в версиях с 7.2 до 7.11.


Data frame analytics это набор функций Elasticsearch и визуализаций Kibana, позволяющих проводить анализ данных без их привязки к временным меткам. В отличии от Anomaly detection, где предполагается временная последовательность анализируемых данных.


Работа с Data frame analytics осуществляется через графический интерфейс с пошаговым мастером настройки. При этом, за счёт автоматической оптимизации параметров обучения (hyperparameters) пользователю не требуются глубокие знания стоящих за ними математических алгоритмов.


Возможности Data frame analytics Elastic версии 7.11 включают в себя:


  1. Выявление отклонений в значениях параметров (outlier detection) с использованием алгоритмов машинного обучения без учителя (unsupervised)
  2. Построение моделей машинного обучения с учителем (supervised) для решения задач:


    a) Регрессии (regression), как определение зависимости одного значения от одного или нескольких других значений


    b) Классификации (classification), как определение принадлежности произвольного объекта к одному из заданных классов



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


Выявление отклонений с использованием алгоритмов машинного обучения без учителя (Outlier detection)


Функция Outlier detection, как и ранее существовавшая в Elastic anomaly detection, предназначена для выявления аномальных значений (выбросов) каких-либо параметров и не предполагает обучение с учителем модель строится каждый раз при запуске. Но в отличие от anomaly detection, значения признаков (фич, особенностей, характерных черт анализируемых объектов) в ней анализируются без учета временной последовательности.


Исходными данными для функции выступает массив записей (JSON документов), в котором данные представлены в виде полей и их значений (поддерживаются числовые и логические типы значений). Каждая запись характеризует поведение какого-либо объекта. Поля в записи включают в себя поле, идентифицирующее объект, и поля со значениями, указывающими на аномальное поведение объекта, их называют признаками (feature).


Результатом функции является оценка отклонения для каждого признака и документа в диапазоне от 0 до 1, где 1 указывает на максимальную вероятность того, что соответствующий признак/документ является выбросом по сравнению с другими документами в анализируемых данных.


В качестве алгоритмов поиска выбросов по умолчанию в Elastic используется ансамбль следующих методов:


  • Метод ближайшего соседа (distance of Kth nearest neighbor)
  • Метод K ближайших соседей (distance of K-nearest neighbors)
  • Локальный уровень выброса (local outlier factor)
  • Локальный уровень выброса на основе расстояния (local distance-based outlier factor)

Подробнее про алгоритмы можно почитать здесь и здесь.


Для оценки и интерпретации результатов выявления отклонений Elastic рассчитывает степень влияния признаков на искомое значение.


В качестве иллюстрации приведём несколько примеров применения Outlier detection:


  • анализ метрик производительности для выявления отклонений в нагрузке на сервера со стороны сразу нескольких приложений (здесь);
  • анализ отпечатков бинарных гистограмм исполняемых файлов для обнаружения обфусцированных и вредоносных файлов (здесь);
  • анализ публичных объявлений airnbnb.com (insideairbnb.com) для поиска необычных предложений (здесь).

Ниже рассмотрим функцию анализа выбросов на примере из документации Elastic.



Цель анализа в этом примере выявить необычное поведение пользователей интернет-магазина. Из магазина в систему поступают события оформления заказа продукции, каждое из которых содержит полное имя заказчика (customer_full_name.keyword), количество покупок в заказе (products.quantity), стоимость заказа (products.taxful_price), id заказа (order_id).


Документы в исходном индексе выглядят так
{  "_index": "kibana_sample_data_ecommerce",  "_type": "_doc",  "_id": "_mXypHcB6S7rlhJIFCvB",  "_version": 1,  "_score": null,  "_source": {    "category": [      "Women's Clothing",      "Women's Accessories"    ],    "currency": "EUR",    "customer_first_name": "Sonya",    "customer_full_name": "Sonya Smith",    "customer_gender": "FEMALE",    "customer_id": 28,    "customer_last_name": "Smith",    "customer_phone": "",    "day_of_week": "Saturday",    "day_of_week_i": 5,    "email": "sonya@smith-family.zzz",    "manufacturer": [      "Oceanavigations",      "Pyramidustries"    ],    "order_date": "2021-03-06T23:31:12+00:00",    "order_id": 592097,    "products": [      {        "base_price": 28.99,        "discount_percentage": 0,        "quantity": 1,        "manufacturer": "Oceanavigations",        "tax_amount": 0,        "product_id": 19238,        "category": "Women's Clothing",        "sku": "ZO0265502655",        "taxless_price": 28.99,        "unit_discount_amount": 0,        "min_price": 13.05,        "_id": "sold_product_592097_19238",        "discount_amount": 0,        "created_on": "2016-12-31T23:31:12+00:00",        "product_name": "Vest - red/white",        "price": 28.99,        "taxful_price": 28.99,        "base_unit_price": 28.99      },      {        "base_price": 13.99,        "discount_percentage": 0,        "quantity": 1,        "manufacturer": "Pyramidustries",        "tax_amount": 0,        "product_id": 13328,        "category": "Women's Accessories",        "sku": "ZO0201102011",        "taxless_price": 13.99,        "unit_discount_amount": 0,        "min_price": 6.86,        "_id": "sold_product_592097_13328",        "discount_amount": 0,        "created_on": "2016-12-31T23:31:12+00:00",        "product_name": "Across body bag - aqua ",        "price": 13.99,        "taxful_price": 13.99,        "base_unit_price": 13.99      }    ],    "sku": [      "ZO0265502655",      "ZO0201102011"    ],    "taxful_total_price": 42.98,    "taxless_total_price": 42.98,    "total_quantity": 2,    "total_unique_products": 2,    "type": "order",    "user": "sonya",    "geoip": {      "country_iso_code": "CO",      "location": {        "lon": -74.1,        "lat": 4.6      },      "region_name": "Bogota D.C.",      "continent_name": "South America",      "city_name": "Bogotu00e1"    },    "event": {      "dataset": "sample_ecommerce"    }  },  "fields": {    "order_date": [      "2021-03-06T23:31:12.000Z"    ],    "products.created_on": [      "2016-12-31T23:31:12.000Z",      "2016-12-31T23:31:12.000Z"    ]  },  "sort": [    1615073472000  ]}

Начнём с подготовки данных для анализа. Так как мы сравниваем между собой заказчиков, то исходные события необходимо группировать по полю customer_full_name.keyword. Признаками поведения заказчиков будут выступать суммарные значения количества заказов, количества покупок, стоимость заказов.


Чтобы сгруппировать события, используем функцию трансформации transforms, которая позволяет на лету формировать и сохранять в Elasticsearch результаты агрегации ранее собранных данных.


Примечание: Для расчёта нужных признаков используем функции Elastic по агрегации: числовые значения считаем через products.quantity.sum и products.taxful_price.sum, а количество заказов order_id.value_count.



Результат агрегации, представленный в табличном виде, выглядит следующим образом:



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



Чтобы просматривать индекс встроенными средствами Kibana, а не только через API, можно включить опцию "Create index template". Тогда соответствующий шаблон отображения индекса будет доступен в Kibana Discovery и при создании дашбордов в Kibana.


Опция "Continuous mode" включит выполнение трансформации в непрерывном режиме. Это обеспечит автоматическое обновление данных в индексе ecommerce_customers_outlier_detection с заданной периодичностью.


Примечание: Функцию транформации можно заменить правилом обработки данных, самостоятельно написанным для корреляционного движка watcher, также являющимся частью Elasticsearch.


Документы в результирующем индексе ecommerce_customers_outlier_detection выглядят следующим образом
{  "_index": "ecommerce_customers_outlier_detection",  "_type": "_doc",  "_id": "QWoH6FA5JvsfN4JjO_LF32QAAAAAAAAA",  "_version": 1,  "_score": 0,  "_source": {    "customer_full_name": {      "keyword": "Abd Adams"    },    "order_id": {      "value_count": 2    },    "products": {      "taxful_price": {        "sum": 98.9765625      },      "quantity": {        "sum": 4      }    }  }}

Теперь самое интересное запускаем задачу машинного обучения (job в терминах Elastic ML). Мастер создания задачи позволяет отфильтровать данные для анализа с использованием встроенных в Elasticsearch языков запросов KQL (Kibana query language) или Lucene.



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



С помощью Advanced configuration параметров создания модели мы можем включить/выключить расчёт степени влияния признаков на модель (Compute feature influence), задать минимальное значение выброса для расчёта этого влияния (Feature influence threshold), а также объём выделенной под модель оперативной памяти (Model memory limit) и количество используемых заданием потоков процессора (Maximum number of threads), тем самым снижая или увеличивая нагрузку на кластер Elasticsearch.



Блок Hyperparameters используется для управления параметрами обучения. Здесь можно выбрать:


  • математический алгоритм (Method) обнаружения отклонений (lof, ldof, distance_kth_nn, distance_knn) или использования ансамбля алгоритмов (ensemble), когда значения отклонений определяются путём комбинации и оценки их результатов;
  • количество используемых в расчётах соседей (N neighbors);
  • переключатель использования предварительной стандартизации значений (Standardization enabled).

Подробнее о параметрах и их значениях можно почитать в референсах на соответствующий эндпоинт API.


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



После запуска, задание проходит через этапы:


  • создание результирующего индекса и добавление в него исходных данных (reindexing);
  • загрузка данных из индекса (loading data);
  • анализ данных и расчёт оценок выбросов (analyzing);
  • запись значений оценок выбросов в результирующий индекс (writing results).


Результаты работы задания можно подробно рассмотреть через интерфейс Kibana Data frame analytics.



На таблице с результатами анализа видим значение совокупной оценки выброса для каждого заказчика (ml.outlier_score) и оценку влияния признаков по насыщенности цвета соответствующей ячейки. Соответствующее числовое значение оценки сохраняется в служебном индексе с результатами анализа в поле ml.feature_influence.


В итоговом индексе результат работы алгоритма выглядит следующим образом
 {  "_index": "ecommerce_customers_outlier_detection_results",  "_type": "_doc",  "_id": "RQzr5SwrcdFVVAr9s9NEOwAAAAAAAAAA",  "_version": 2,  "_score": 1,  "_source": {    "customer_full_name": {      "keyword": "Elyssa Tran"    },    "order_id": {      "value_count": 4    },    "products": {      "taxful_price": {        "sum": 223.9921875      },      "quantity": {        "sum": 5      }    },    "ml__incremental_id": 926,    "ml": {      "outlier_score": 0.9770675301551819,      "feature_influence": [        {          "feature_name": "order_id.value_count",          "influence": 0.9383776783943176        },        {          "feature_name": "products.quantity.sum",          "influence": 0.05973121151328087        },        {          "feature_name": "products.taxful_price.sum",          "influence": 0.0018910884391516447        }      ]    }  },  "sort": [    1,    0.9770675301551819  ]}

Графически выбросы отображаются на диаграммах рассеяния. Здесь можно подсвечивать значения выбросов по выбранному порогу оценки.



И включить отображение размера точек в соответствии со значением отклонения.



Примечание: Данные диаграммы разработаны с использованием языка Vega, доступного любому пользователю в конструкторе визуализаций Kibana.


Регрессия и классификация с учителем


Рассмотрим следующий набор функций Data frame analytics контролируемое обучение (обучение с учителем). Они предоставляют пользователю возможность обучить в Elastic свою собственную модель и использовать её для автоматического предсказания значений. Модель можно загружать и выгружать из системы, а также оценивать её качество. Кроме того, через Eland поддерживается импорт в Elastic моделей, обученных с помощью библиотек scikit-learn, XGBoost или LightGBM. Вместе с возможностями платформы по сбору и обработке данных эти функции помогают реализовать в ней подход CRISP-DM (Cross-Industry Standard Process for Data Mining).


В Elastic две функции обучения с учителем регрессия и классификация. Если говорить проще, то цель функций определение неизвестного значения объекта по значениям влияющих на него признаков. В случае регрессии речь идёт о предсказании числового значения, как характеристики объекта, а в случае классификации об определении класса (группы), к которой относится объект.


Исходными данными (обучающим датасетом) для функции служит массив из уникальных записей (JSON документов). В каждой записи присутствует искомое поле (числовое для регрессии или категориальное для классификации) и поля признаков, влияющих на искомое поле. Значения искомого поля здесь используются для обучения модели и проверки её результатов. Результатом работы функции выступает обученная модель и новый массив данных, включающий исходный датасет, предсказанные значения и данными о степени влияния каждого признака. Датасет при этом можно использовать для оценки качества модели, а саму модель для анализа потока данных, поступающих в Elastic или ранее сохранённых в системе.


Схема реализации функций в Elastic


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


Обе функции используют собственные алгоритмы Elastic, построенные на базе градиентного бустинга деревьев решений XGBoost. Также возможно определение важности признаков по методу SHapley Additive exPlanations (SHAP).


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


Далее разберем примеры использования регрессии и классификации и возможности платформы по интерпретации результатов их работы.


Регрессия


С помощью регрессионного анализа попробуем предсказать продолжительность задержки рейса, на примере из документации Elastic. Для анализа используем метеоданные, данные с табло вылета/прилёта и стоимость билетов.


Документы в исходном индексе выглядят так
{  "_index": "kibana_sample_data_flights",  "_type": "_doc",  "_id": "lmX0pHcB6S7rlhJI2kVr",  "_version": 1,  "_score": null,  "_source": {    "FlightNum": "6GZQTCH",    "DestCountry": "IT",    "OriginWeather": "Thunder & Lightning",    "OriginCityName": "Tokyo",    "AvgTicketPrice": 849.1194483923543,    "DistanceMiles": 6127.633563869634,    "FlightDelay": false,    "DestWeather": "Rain",    "Dest": "Pisa International Airport",    "FlightDelayType": "No Delay",    "OriginCountry": "JP",    "dayOfWeek": 2,    "DistanceKilometers": 9861.470310212213,    "timestamp": "2021-02-17T15:41:38",    "DestLocation": {      "lat": "43.683899",      "lon": "10.3927"    },    "DestAirportID": "PI05",    "Carrier": "ES-Air",    "Cancelled": false,    "FlightTimeMin": 493.07351551061066,    "Origin": "Narita International Airport",    "OriginLocation": {      "lat": "35.76470184",      "lon": "140.3860016"    },    "DestRegion": "IT-52",    "OriginAirportID": "NRT",    "OriginRegion": "SE-BD",    "DestCityName": "Pisa",    "FlightTimeHour": 8.217891925176845,    "FlightDelayMin": 0  },  "fields": {    "hour_of_day": [      15    ],    "timestamp": [      "2021-02-17T15:41:38.000Z"    ]  },  "sort": [    1613576498000  ]}

В данном случае функцию transforms применять не нужно, так как каждый документ датасета содержит данные только об одном полёте, и цель анализа предсказать задержку в отношении каждого полёта. Но подготовить данные можно исключим ошибочные записи с расстоянием перелёта 0 километров. В качестве предсказываемого (проверочного) поля указываем FlightDelayMin.



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



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



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


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



Advanced configuration:


  • количество признаков, для которых в результирующий индекс будет записано значение влияния соответствующего признака на результат предсказания (Feature importance values);
  • имя поля, в которое будет записан результат предсказания (Prediction field name);
  • лимит на объём используемой заданием оперативной памяти (Model memory limit);
  • максимальное количество используемых заданием потоков процессора (Maximum numbers of threads).

Hyperparameters:


  • коэффициент регуляризации Лямбда (Lambda);
  • максимальное количество деревьев для бустинга (Max trees);
  • коэффициент регуляризации Гамма (Gamma);
  • размер градиентного шага Эта (Eta);
  • доля выборки (Feature bag fraction);
  • псевдослучайное число, используемое при выборе из датасета документов для обучения модели (Randomize seed).

Примечание: Описание применения в Elastic этих и дополнительных гиперпараметров приведено в документации к API.


Теперь посмотрим на результаты работы алгоритма. Они записываются в итоговый индекс Elasticsearch и представлены в отчёте в табличном виде.



Здесь можно увидеть новые, по сравнению с датасетом, поля:


  1. Отметка об использовании данных для обучения (ml.is_training)
  2. Результаты предсказания задержки рейса (ml.FlightDelayMin_prediction)

Если при создании задания было указано количество признаков, для которых будет рассчитано значение их влияния на результат (Feature importance values), в таблице отобразятся соответствующие значения для каждого признака (ml.feature_importance), а в результатах бар-чарт средних значений по всему датасету.



При клике на поле ml.feature_importance увидим наглядный график принятия решения алгоритмом SHAP.



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


Результаты доступны для просмотра и другими средствами визуализации Kibana

Например, в Kibana Lens. Ниже построен бар-чарт фактических и предсказанных задержек рейсов с разбивкой по погоде в пункте назначения.



Кроме индекса с предсказанными моделью значениями, основным результатом выполнения задания также является обученная модель. Выгрузить модель из Elastic в JSON файл позволяет эндпоинт trained_models, как указано здесь.


В этом же отчете можно увидеть метрики качества модели:


  • среднеквадратическая ошибка (Mean Squared Error, MSE);
  • коэффициент детерминации (R-squared, R2 );
  • псевдо-функция потерь Хьюбера (Pseudo-Huber loss);
  • среднеквадратичная логарифмическая ошибка (Mean squared logarithmic error, MSLE).


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


После того как модель сформирована, она может применяться для предсказания значений по новым данным. Для этого в Elasticsearch есть две возможности:


  • анализ поступающих в Elasticsearch данных (Inference processor);
  • анализ ранее сохранённых в Elasticsearch данных (Inference aggregation).

Пример c Inference processor
POST /_ingest/pipeline/_simulate{  "pipeline" : {    "description" : "Flight delay prophecy",    "processors" : [       {          "inference": {           "model_id":"flights_delay_prophecy-1613827670191",           "inference_config": {             "regression": {               "results_field": "FlightDelayMin_prediction"             }           }         }       }    ]  },  "docs": [    {      "_index": "index",      "_id": "id",      "_source": {          "FlightNum" : "9HY9SWR",          "Origin" : "Frankfurt am Main Airport",          "OriginLocation" : {            "lon" : "8.570556",            "lat" : "50.033333"          },          "DestLocation" : {            "lon" : "151.177002",            "lat" : "-33.94609833"          },          "DistanceMiles" : 10247.856675613455,          "FlightTimeMin" : 1030.7704158599038,          "OriginWeather" : "Sunny",          "dayOfWeek" : 0,          "AvgTicketPrice" : 841.2656419677076,          "Carrier" : "Kibana Airlines",          "FlightDelayMin" : 0,          "OriginRegion" : "DE-HE",          "FlightDelayType" : "No Delay",          "DestAirportID" : "SYD",          "timestamp" : "2021-02-08T00:00:00",          "Dest" : "Sydney Kingsford Smith International Airport",          "FlightTimeHour" : 17.179506930998397,          "DistanceKilometers" : 16492.32665375846,          "OriginCityName" : "Frankfurt am Main",          "DestWeather" : "Rain",          "OriginCountry" : "DE",          "DestCountry" : "AU",          "DestRegion" : "SE-BD",          "OriginAirportID" : "FRA",          "DestCityName" : "Sydney"        }    }  ]}

Пример c Inference aggregation
GET kibana_sample_data_flights/_search{  "size":0,  "query": {    "term": {      "FlightNum": {        "value": "00HGV4F"      }    }  },   "aggs": {    "res": {       "composite": {         "size": 1,        "sources": [          {            "FlightNum": {              "terms": {                "field": "FlightNum"                              }            }          }        ]      },      "aggs" : {        "AvgTicketPrice": {          "max": {            "field": "AvgTicketPrice"          }        },       "Dest": {           "scripted_metric": {             "init_script": "state.Dest = ''",             "map_script": "state.Dest = params._source.Dest",             "combine_script": "return state.Dest",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DestAirportID": {           "scripted_metric": {             "init_script": "state.DestAirportID = ''",             "map_script": "state.DestAirportID = params._source.DestAirportID",             "combine_script": "return state.DestAirportID",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DestRegion": {           "scripted_metric": {             "init_script": "state.DestRegion = ''",             "map_script": "state.DestRegion = params._source.DestRegion",             "combine_script": "return state.DestRegion",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DistanceKilometers": {          "max": {            "field": "DistanceKilometers"          }        },        "DistanceMiles": {          "max": {            "field": "DistanceMiles"          }        },        "FlightDelayType": {           "scripted_metric": {             "init_script": "state.FlightDelayType = ''",             "map_script": "state.FlightDelayType = params._source.FlightDelayType",             "combine_script": "return state.FlightDelayType",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "FlightTimeMin": {          "max": {            "field": "FlightTimeMin"          }        },        "Origin": {           "scripted_metric": {             "init_script": "state.Origin = ''",             "map_script": "state.Origin = params._source.Origin",             "combine_script": "return state.Origin",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "OriginAirportID": {           "scripted_metric": {             "init_script": "state.OriginAirportID = ''",             "map_script": "state.OriginAirportID = params._source.OriginAirportID",             "combine_script": "return state.OriginAirportID",             "reduce_script": "for (d in states) if (d != null) return d"           }         },        "OriginRegion": {           "scripted_metric": {             "init_script": "state.OriginRegion = ''",             "map_script": "state.OriginRegion = params._source.OriginRegion",             "combine_script": "return state.OriginRegion",             "reduce_script": "for (d in states) if (d != null) return d"           }         },        "FlightDelayMin_prediction" : {          "inference": {            "model_id": "flights_delay_prophecy-1613827670191",             "buckets_path": {               "AvgTicketPrice": "AvgTicketPrice",               "Dest": "Dest.value",               "DestAirportID": "DestAirportID.value",               "DestRegion": "DestRegion.value",               "DistanceKilometers": "DistanceKilometers",               "DistanceMiles": "DistanceMiles",               "FlightDelayType": "FlightDelayType.value",               "FlightTimeMin": "FlightTimeMin",               "Origin": "Origin.value",               "OriginAirportID": "OriginAirportID.value",               "OriginRegion": "OriginRegion.value"             }          }        }      }     }  }}

Классификация


Продолжим тему полетов и проанализируем данные об авиарейсах, предсказывая не длительность задержки, как в регрессии, а факт отмены рейса. Используем датасет из предыдущего примера, трансформация в агрегированный индекс здесь тоже не требуется.


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



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



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


После завершения задачи можно оценить результаты предсказания отмены рейса.



В таблице результатов данные датасета дополнены полями:


  • отметка об использовании данных для обучения (ml.is_training);
  • предсказанный статус отмены рейса (ml.Cancelled_prediction);
  • вероятность предсказания (ml.prediction_probability);
  • влияние признаков на результат (ml.feature_importance);
  • оценка предсказания для всех искомых классов (ml.prediction_score).

Пример сохраненных результатов расчётов ml.prediction_score
"top_classes": [        {          "class_probability": 0.9617513617353418,          "class_score": 0.24080996012552122,          "class_name": false        },        {          "class_probability": 0.03824863826465814,          "class_score": 0.03824863826465814,          "class_name": true        }      ]

В понимании параметров оценки поможет документация Elastic.


Как и в регрессии, в результатах доступен график усреднённых значений важности признаков.



Для проверки результатов в классификации доступны следующие метрики:


  • матрица ошибок (Confusion matrix);
  • площадь кривой ошибок (area under receiver operating characteristic curve, AUC ROC).

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



Кривая ошибок и значение площади AUC ROC в версии 7.11 не отображается, но значения можно получить через API. В 7.12 такая возможность уже будет добавлена.


Пример запроса AUC ROC
POST _ml/data_frame/_evaluate{   "index": "cancelled_flights_prediction_2",   "evaluation": {      "classification": {          "actual_field": "Cancelled",          "predicted_field": "ml.Cancelled_prediction",          "metrics": {           "auc_roc": {             "class_name": "true"           }          }      }   }}

и ответа
{  "classification" : {    "auc_roc" : {      "value" : 0.8240223547611558    }  }}   

Сохранённая модель доступна для использования в Inference processor и Inference aggregation, как в предыдущем примере.


Заключение


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


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


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

Подробнее..

5 причин не уходить из техподдержки во внедрение

15.04.2021 18:16:38 | Автор: admin

Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.

В сервисном департаменте STEP LOGIC на двух линиях технической поддержки работает более 50 специалистов. Сейчас они обслуживают порядка 150 сервисных контрактов это более 10 тыс. инцидентов в год. Первая линия поддержки проводит классификацию обращений заказчиков и если проблему можно решить по скрипту, то закрывает заявку своими силами. Если сделать это в течение первого часа не удается или требуются дополнительные компетенции, то инцидент передается на вторую линию поддержки, инженеры которой обладают более глубокими техническими знаниями и навыками.

Как сервисные партнеры нескольких крупных вендоров, мы имеем право оказывать услуги по технической поддержке оборудования от их имени. Например, при обслуживании оборудования Cisco наши специалисты решают до 80-90% проблем самостоятельно, за помощью к вендору мы обращаемся только при гарантийной замене или обнаружении программных ошибок. Для того, чтобы вендор авторизовал партнера на предоставление совместных услуг, в штате обязательно должны быть сертифицированные инженеры, имеющие CCIE или, как минимум, CCNP. Еще два обязательных условия прохождение ежегодных аудитов на соответствие уровня услуг, требования к которым схожи с лучшими практиками ITIL, и принцип оказания технической поддержки, основанный на практиках Cisco CX Specialization.

Конечно, оптимальное решение для компаний, у которых есть локальная задача поддержки оборудования конкретного вендора, это покупка его стандартных пакетов обслуживания. У того же Cisco, например, есть варианты на разный вкус и кошелек: контракты Cisco SMARTnet или расширенная версия Solution Support, Next Calendar Day, если нужна замена оборудования в выходной или праздничный день, профессиональные услуги вендора Advanced Services (AS) и Business Critical Services (BCS), если заказчику необходим дизайн сети. Но бизнесу, в котором требования постоянно меняются, зачастую удобнее работать с компанией, которая будет жить в конкретной инфраструктуре, понимать, как она построена, в чем ее плюсы и минусы, узкие места и иметь опыт работы с технологиями разных производителей. Востребованы наши услуги и в системах высокой критичности, где нужен высокий SLA с фиксированным временем решения и круглосуточный сервис. Совместное оказание услуг часто удобно и самому производителю, так как он может не держать большой штат поддержки и сосредоточиться на основном бизнесе, не переживая при этом об уровне сервиса.

В локдаун значительно увеличилось число запросов на организацию и сопровождение VPN-каналов, Next Generation Firewall, SIEM-систем, расследование инцидентов безопасности, поэтому остро встал вопрос расширения команды инженеров по информационной безопасности на вторую линию поддержки.

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

График работы предлагаем стандартный 8 часов 5 дней в неделю. Иногда по отделу назначаются дежурства. Если ночью появилась критичная проблема, то дежурному придется подключиться и разобраться с ней. Но есть и небольшой плюс ехать никуда не нужно, специалисту выдается доступ в систему, с помощью которого он может работать удалено. Собственно, поэтому мы и не зацикливались на Москве или области, а сразу расширили зону поиска на всю Россию.

Почему возникли проблемы

  • Небольшое число подходящих специалистов. Забив перечисленные выше параметры на hh.ru, мы видим чуть более 70 человек, находящихся сейчас в поиске работы. Если бы мы искали сотрудника в московский офис, то ситуация была бы еще хуже. Для сравнения, при поиске бухгалтера сайт выдает более 1000 подходящих резюме.

  • Специалисты, имеющие релевантный опыт работы, не хотят идти в техническую поддержку. 30% соискателей отказались еще на этапе приглашения. Наиболее частая причина желание работать на стороне производителя или заниматься проектной деятельностью. В определенный момент мы даже решили несколько снизить планку по знаниям, но потом пришли к неутешительному выводу, что приходящие на собеседование кандидаты не могут объяснить, чем файрвол отличается от маршрутизатора.

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

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

  1. Быстрый горизонтальный рост компетенций

    Минимальные начальные требования для кандидатов знание сетевых технологий, основ информационной безопасности, шифрования, принципов работы межсетевого экрана и системы предотвращения вторжений. Кроме стандартных файрволов и VPN, инженеры техподдержки работают с такими классами решений как Next Generation Firewall, SIEM, Web Application Firewall, DLP, IPS/IDS, Identity/AccessManagement, IRP/SOAR, Threat Intelligence. Это помогает развиваться не по одному направлению предметной деятельности, а более широко. Наши специалисты детально изучают оборудование ведущих ИБ-вендоров, тестируют в лаборатории его новые версии.

    Идеальный кандидат должен уметь работать в режиме многозадачности, быстро адаптироваться к изменениям и все схватывать буквально на лету. Такой темп работы позволяет быстро продвигаться по карьерной лестнице: в среднем, путь от младшего инженера техподдержки до ведущего эксперта в STEP LOGIC составляет 5 лет.

  2. Возможность стать экспертом, так как нужно "копать" глубоко

    Работа инженера внедрения заканчивается после ввода проекта в эксплуатацию. Как сотрудники техподдержки, мы можем с уверенностью заявить, что все самое интересное на этом только начинается. Техническая поддержка это не только консультации клиентов по вопросам функционирования оборудования, удаленная диагностика и настройка, решение проблем, локализация и мониторинг аварий, но и совместная работа с вендором по устранению багов, разработка планов по развитию и миграции инфраструктуры. Недавно мы приняли участие в проекте по миграции, который стал для нас своеобразным челленджем. Немного предыстории: крупный российский банк для защиты периметра продолжительное время использовал межсетевые экраны Cisco ASA. За последний год объем трафика увеличился в несколько раз, и оборудование перестало с ним справляться. Заказчик закупил межсетевые экраны нового поколения Cisco Firepower и перед ним встала задача провести максимально бесшовную замену, так как инфраструктура критическая и должна работать 24х7. Необходимо было перенести с одной ОС на другую большое количество настроек: сотни интерфейсов, тысячи правил межсетевого экранирования, сотню VPN и сделать это в короткое окно работ. Была проведена комплексная работа, включающая в себя изменение настроек маршрутизации, трансляции NAT, редистрибуции и фильтрации тысяч маршрутов, учитывающая переходные процессы с целью минимизации возможных потерь трафика.

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

  3. Развить командные навыки работы и soft skills

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

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

  4. Научиться работать с технической документацией

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

  5. Усовершенствовать технический английский

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

По законам жанра дальше должен быть абзац про систему грейдов и возможностях профессионального роста. И они, действительно, есть: при желании инженер может вырасти в:

  • эксперта по классу решений или технологии

  • менеджера/сервис-менеджера/product owner по продукту или услуге

  • руководителя нового направления/услуги

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

Таким образом, если работа с оборудованием и устранение неполадок приносит радость, среди soft skills присутствует пресловутая коммуникабельность и клиентоориентированность, имеется стойкое желание развить свои технические знания и стать экспертом в конкретной области ИТ, то у вас есть веский повод обратить внимание на вакансию инженера технической поддержки.

Подробнее..

100 плагинов для Revit или как мы оптимизировали проектирование систем электроснабжения

01.04.2021 12:23:08 | Автор: admin

Привет, Хабр! Меня зовут Алексей Новиков, уже 5 лет я занимаюсь информационным моделированием систем электроснабжения в компании STEP LOGIC.

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

Изначально для проектирования зданий использовались бумага и кульман. Переход от плоских чертежей к трехмерным стал возможен с появлением и развитием AutoCAD и подобных программ. А с ростом популярности Building Information Modeling (BIM) на рынке появился целый ряд технологий для создания информационных моделей зданий.

Для работы я использую Autodesk Revit, который занимает большую нишу. Проектирование в Revit сильно отличается от того же AutoCAD, в котором можно за несколько дней научиться рисовать линии и ставить размер. С Revit это не работает. Здесь нужен другой подход, моделирование осуществляется элементами экземплярами семейств, которые изначально надо создать.

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

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

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

Чего не хватает:

  1. Расчетная часть программы минимальна и соответствует западным нормативам и стандартам. Более того, результаты расчетов зачастую неверны. Тестовые расчеты показали, что значения средней освещенности могут различаться на 20-30%. Для примера результаты расчетов для одного и того же помещения в Revit составили 653 лк, а в специализированном софте Dialux Evo - 496 лк.

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

  3. Отсутствует возможность создания уникальной топологии схем инженерных систем. Например, нельзя создать и рассчитать схемы с АВР или кольцевые схемы. Но ведь именно с такими решениями приходится сталкиваться при проектировании сложных комплексных объектов.

С чего мы начинали работы по созданию плагинов для Revit

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

Коммерческие плагины, например, достаточно популярный пакет MagiCAD для Revit или RChain. На начальных этапах работ мы рассматривали возможность применения коммерческих плагинов, но отказались от этой идеи, потому что:

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

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

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

  • Недостаточная интеграция с информационной моделью.

Плагины от вендоров (Schneider-Electric, Siemens, ДКС), функционал которых заточен под применение конкретного оборудования. Некоторые из них довольно удобны в применении, но, к сожалению, все они идут в привязке к вендору. То есть, грубо говоря, возможности перейти в проекте на оборудование другого производителя без внешних доработок там нет.

Рис.1. Плагин Bim Electrical Design от Schneider Electric обладает отличным модулем по расчету токов нагрузки. Но здесь мы можем производить расчеты только для оборудования SE.Рис.1. Плагин Bim Electrical Design от Schneider Electric обладает отличным модулем по расчету токов нагрузки. Но здесь мы можем производить расчеты только для оборудования SE.

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

Проектирование первых плагинов

Подробный процесс создания плагинов опишу на примере разработки функционала связи Revit с Dialux Evo.

Как я уже говорил выше, встроенный функционал Revit позволяет рассчитывать освещенность пространств, но проведённое тестирование показала крайне низкую точность этих расчетов. А вот Dialux Evo считается одним из самых передовых софтов в этой сфере. Для повышения точности в наших проектах мы решили провести взаимную интеграцию между Revit и Dialux Evo. В идеале хотелось получить полноценную двустороннюю связь между этими программными продуктами с минимальным набором промежуточных действий.

В первую очередь мы поставили перед собой задачу автоматизировать передачу информации о модели из Revit в Dialux Evo. В Dialux Evo можно импортировать трехмерные модели в форматах .ifc и .stf. Несмотря на то, что в Revit есть собственный функционал по созданию файла .ifc, мы остановились на генерировании файла .stf. Это было обусловлено следующими причинами:

  1. .stf в отличии от ifc передает данные не только о геометрии (пространствах), но и о светильниках. Таким образом мы можем передать в Dialux Evo координаты, углы поворота и типы светильников.

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

Из минусов стоит отметить, что нам необходимо предварительно создать (или скопировать из внешнего файла АР) пространства, так как именно они в итоге будут передаваться в Dialux Evo.

В результате было разработано два плагина по созданию файла .stf на основе выбранного уровня.

Рис.2. В зависимости от этапа работ проектировщику предлагается сгенерировать файл .stf на основе только пространств или пространства плюс светильники.Рис.2. В зависимости от этапа работ проектировщику предлагается сгенерировать файл .stf на основе только пространств или пространства плюс светильники.

Через генерирование файла .stf и импорт этого файла в Dialux Evo мы осуществили передачу информации о пространствах (геометрии) и светильниках (координаты, угол поворота, тип).

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

Следующей задачей стала передача информации из Dialux Evo в Revit. Экспортировать из Dialux Evo можно файл формата .dwg. Он содержит блоки светильников и таблицы с данными об их типах и расчетных значениях освещенностей пространств. В блоках светильников находится информация о координатах и углах светильников, а принадлежность блока к слою указывает на тип светильника. Таким образом, сгенерированный в Dialux Evo файл .dwg, содержит всю необходимую нам информацию.

В результате получаем плагин, который на основе .dwg файла создает светильники в модели Revit. Расставляет их на свои места с нужными углами и прописывает в пространства результаты расчетов из Dialux Evo.

То есть двусторонняя интеграция Revit и Dialux Evo выглядит следующим образом: Revit - файл.stf Dialux Evo - файл.dwg Revit.

Рис.3. Так модель выглядит в RevitРис.3. Так модель выглядит в RevitРис.4. Эта же модель в Dialux EvoРис.4. Эта же модель в Dialux Evo

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

  1. Анализ кабельных конструкций и раскладку кабелей

  2. Электротехнические расчеты и расчеты токов короткого замыкания

  3. Конфигурирование электрических щитов и построение однолинейных схем

  4. Построение структурной схемы системы электроснабжения всего объекта

  5. Интеграция между Revit и Dialux Evo

  6. Аналитика по заполнению кабельных лотков. Происходит построение разрезов лотка и расчет горючей массы кабелей в лотке.

  7. Создание таблиц и интеграция с Excel. В частности, происходит выгрузка полной спецификации ЭМ. И приведение спецификации к гостированному виду.

  8. Создание планов оборудования, распределительной и групповой сети, кабельных трасс и планов освещения

  9. Мониторинг параметров оборудования смежных разделов

  10. Расчет и построение зоны молниезащиты

  11. Расчет сопротивления заземляющего устройства

  12. Создание кабельных проходок

Как выглядит система проектирования электроснабжения

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

Рис.5. Интерфейс системы проектирования электроснабженияРис.5. Интерфейс системы проектирования электроснабжения

По сути в этом интерфейсе расписан весь процесс, который проходят инженеры при проектировании объекта, разбитый на наиболее характерные этапы работ.

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

Рис.6. Так выглядит вкладка Проведение электротехнических расчетовРис.6. Так выглядит вкладка Проведение электротехнических расчетов

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

Переход от бумажных чертежей к проектированию в 2D, далее 3D и BIM требует смены инструментария. При наличии системы, пройдя соответствующее обучение на тестовых моделях в системе, проектировщик в короткий срок сможет понять всю процедуру проектирования и создания информационной модели.

Из-за меняющихся нормативных документов и требований заказчиков систему проектирования необходимо постоянно развивать. Описание этого процесса можно проиллюстрировать с помощью цикла Деминга-Шухарта (PDCA plan, do, check, act). С определенной периодичностью мы планируем и проводим изменения, а затем проверяем и актуализируем их.

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

Если заглянуть на 5-10 лет вперед, то я вижу некоторое переформатирование роли проектировщика. Человек со стопкой ГОСТов и калькулятором превратится в своего рода архитектора решений, задача которого заполнение модели оборудованием, задание параметров и организация связи между этими элементами. А выбор кабелей, подбор коммутационных аппаратов, создание чертежей и многое другое будет выполняться автоматически.

В заключении минутный ролик, в котором мы собрали основной функционал нашей системы и показали, как он его можно использовать при проектировании.

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

Подробнее..

Тестируем СХД OceanStor Dorado V6 Hyper и Smart

02.02.2021 16:10:30 | Автор: admin


Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали в полях в инфраструктуре заказчика.


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


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


Подробно остановлюсь на функциях:


  • HyperSnap мгновенный виртуальный снимок одна из разновидностей моментальных снимков, фиксация данных в определенный момент времени.
  • HyperCDP функция создания мгновенных снимков с высокой частотой (через малый промежуток времени).
  • HyperClone создает полные копии исходных данных с использованием расписания. Механизм применяется для резервного копирования, защиты, анализа и тестирования данных. В отличие от классического моментального снимка, на создание клона требуется определенное время, клон не грузит основной LUN.
  • SmartQOS позволяет настроить приоритеты ввода-вывода: повысить или понизить приоритет выделенному LUN'у и тем самым управлять скоростью обмена данными.

А о результатах тестирования производительности и отказоустойчивости я напишу во второй части.


О технических параметрах Dorado V6


СХД OceanStor Dorado V6 впервые представлена в сентябре 2019 года. В линейке продуктов пять моделей, условно распределенных на три класса low-end (Dorado 3000), mid-end (Dorado 5000/6000) и hi-end (Dorado 8000/18000). Модели в линейке объединяет схожая архитектура, интерфейс управления и набор функций. Основные различия в максимальной емкости и производительности.


Из отличительных особенностей OceanStor Dorado V6 базируется на процессорах и контроллерах производства компании Huawei. Из-за санкций США Huawei вынуждены были отказаться от процессоров Intel для своих СХД, перейдя на ARM-чипы собственного производства. У флагманских моделей Dorado 8000 V6 и 18000 V6 количество ядер на контроллер переваливает за сотню, а точнее 128 и 192 ядра соответственно. Если быть точным сам чип Kunpeng 920 на архитектуре ARMv8.2 может иметь от 24 до 64 ядер. Такое высокое суммарное количество ядер получается путем установки нескольких подобных процессоров в 1 контроллер.


Ниже речь пойдет о Huawei OceanStor Dorado 3000 V6 (24 ядра на контроллер), которая может применяться как для вспомогательных систем и сервисов, так и в качестве основной СХД для небольших компаний.


Почему выбрана именно Dorado 3000 V6?


Как это часто бывает младшие модели оборудования выглядят не так ярко на фоне представителей hi-end из этой же линейки и незаслуженно получают меньше внимания. Поэтому после 21 миллиона IOPS, которые были достигнуты Huawei на своей OceanStor Dorado 18000 V6, хотелось посмотреть, на что годится самая бюджетная All-flash СХД от Huawei.


Заказчик, совместно с которым проводилось тестирование, планировал купить аналогичную модель СХД, но с увеличенным суммарным сырым объемом и дополнительной полкой расширения (Disk Enclosure). У компании были опасения в части производительности системы, которые мы и постарались преодолеть в процессе тестирования.


Коротко о стенде для тестирования


В тесте мы использовали следующую конфигурацию Huawei OceanStor Dorado 3000 V6:


  • пара контроллеров Active-Active с единым кэшем 192 Гб;
  • 48 процессорных ядер, по 24 ядра на каждый контроллер;
  • восемь SSD-дисков 7,68 Тб;
  • две карты расширения Smart-IO 4х16Gb FC;
  • две карты расширения Smart-IO 4х10Gb Ethernet.

Примечание. Dorado V6 3000, в отличие от более мощных моделей в этой же линейке, поддерживает установку только накопителей SAS 3.0. NVMe формата Palm доступны начиная с модели 5000 V6.



Рисунок 1. Фронтальная панель установленной в стойку Huawei OceanStor Dorado V6 3000.


Для чистоты эксперимента, чтобы абстрагироваться от нюансов существующей инфраструктуры, уже используемой заказчиком для рабочих целей (и не нагружать лишний раз production SAN), было принято решение подключить СХД к серверу виртуализации (VMware ESXi 6.5) напрямую двумя FC-интерфейсами. Сервер виртуализации обеспечивал работу двух виртуальных машин, в которых мы запускали утилиту генерации и измерения нагрузки VDBench (Oracle), также был установлен драйвер multipath (Huawei Ultrapath).


На СХД мы создали дисковое пространство Storage Pool (далее SP), включающее в себя все восемь SSD дисков, с параметром отказоустойчивости RAID-6 и двумя резервными дисками Hot Spare. Диски LUN, созданные на данном SP, были подключены к виртуальным машинам как RDM-диски.


HyperSnap


HyperSnap представляет собой ни что иное, как Snapshot, созданный на LUN'е. Используется для резервного копирования, тестирования и других задач.


Важно отметить, что такой Snapshot работает по принципу ROW (redirect-on-write), вместо ранее считавшимся классическим COW (copy-on-write). Согласно этому алгоритму, новые данные не заменяют на старые, а записываются на свободное место. Такой Snapshot по сути является таблицей со ссылками. При создании снимка HyperSnap СХД записывает все сведения об изменениях в специально выделенную часть виртуального диска LUN Metadata. Снимок HyperSnap не является полной копией данных и поэтому не занимает много места.


Собственно, алгоритм ROW уже своего рода классика для Flash-массивов.



Рисунок 2. Отличия алгоритмов COW и ROW.


Примечание. Известные системы резервного копирования, например, от Veeam и Commvault, поддерживают интеграцию с инструментами Huawei и могут использовать Snapshot для резервного копирования, расширяя таким образом окно бэкапа (оптимальное время, подходящее для создания копий, когда нагрузка на систему минимальна).


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


На рисунке 3 показан снимок, созданный с именем LUNGroup006_last, прародителем которого является диск LUN LUNGroup006_000. LUNGroup006_000 при этом уже был смонтирован на одной из тестовых виртуальных машин.



Рисунок 3. Мгновенный снимок HyperSnap с именем LUNGroup006.


Подключаем его на тот же хост и следим через интерфейс фирменного драйвера MultiPath от Huawei UltraPath. Эта функция является не только важным элементом отказоустойчивости, но и просто удобным рабочим инструментом, способным прямо с хоста однозначно определить доступные тома.



Рисунок 4. Консоль управления фирменного драйвера MultiPath от Huawei UltraPath.


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


Кроме того, LUN'ы можно добавлять в так называемые Consistency Groups, что позволяет делать снимки указанных данных в один и тот же момент данных. Это крайне важно, если вы придерживаетесь рекомендаций вендоров и раскладываете файлы и логи тех же баз данных по разным LUN'ам.


HyperCDP


Если HyperSnap механизм достаточно традиционный, то HyperCDP развитие Snapshot с возможностью создания снимков один за другим с большой частотой. Проще говоря, это набор мгновенных снимков, который можно создавать по расписанию с задержкой минимум 3 секунды.


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


Помимо функции защиты, HyperCDP имеет еще одно важное преимущество. При использовании данной функции практически не страдает производительность. Это мы и проверим в процессе тестирования.


Для теста заведем на нашей СХД 16 LUN по 512 Гб, подключим их к одной ВМ и дадим нагрузку с помощью бенчмарка VDBench.


Примечание. VDBench сам по себе довольно прост, Oracle распространяет его бесплатно, из сопутствующего ПО требуется лишь установленный JRE.


В вызываемом файле конфигурации необходимо задать параметры, которые будут использоваться при тестировании. Допустим, VDBench будет писать блоком 8 килобайт с 70% полностью рандомного чтения и параметрами дедупликации и компрессии 2 к 1.


На СХД мы также настроим HyperCDP-план, который позволит в процессе делать снимки каждого из 16 LUN'ов с интервалом в 10 секунд. Ограничим эту задачу 500 объектами (для каждого LUN'а). Максимальное же количество в рамках одного плана может быть 60000.



Рисунок 5. Веб-интерфейс с примером созданного HyperCDP-плана.


Остается запустить VDBench с указанными ранее параметрами и наблюдать за текущей производительностью.


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



Рисунок 6. Результаты теста HyperCDP.


Подождем еще немного, пока количество HyperCDP-объектов всех LUN'ов не перевалит за сотню, и проверим еще раз.



Рисунок 7. Результаты теста HyperCDP с количеством объектов более 100.


Подводя промежуточные итоги, стоит отметить, что эмулируемый в рамках теста сервис не испытал каких-либо воздействий в плане деградации производительности, и за полтора часа мы получили 500 снимков 16-ти LUN'ов, что в сумме составляет 8000 объектов.


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


HyperClone


Из названия HyperClone становится очевидно, что эта функция делает точную копию указанного LUN'а.


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


При создании клона также можно выбрать скорость синхронизации:



В отличие от снимков HyperCDP клон не грузит основной LUN. В веб-интерфейсе соответствующего раздела доступна синхронизация в обе стороны: Synchronize и Reversе Sync. Если данные на первичном LUN'е были изменены и должны быть перенесены на вторичный, используется инкрементальная синхронизация, т.к. СХД отслеживает изменения созданных пар.


Примечание. Ранее рассмотренные варианты создания снимков HyperSnap и HyperCDP занимают намного меньше дополнительного пространства на хранилище, т.к. не являются полной копией данных



Рисунок 8. Настройка HyperClone.


Для разрыва связи достаточно удалить созданную пару в разделе веб-интерфейса Data Protection, в закладке Clone Pairs.



Рисунок 9. Удаление клон-пары.


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


SmartQOS


В принципе, сервис SmartQoS штука не новая. Системы, которые обеспечивают нужную полосу пропускания для критичных сервисов за счет приоритизации, существовали и ранее. Использовать разные LUN'ы под различные сервисы совершенно нормальная практика. В этом случае иногда возникает необходимость выставить максимальные показатели производительности по IOPS или Bandwidth на те или иные объекты.



Рисунок 10. Настройка политики SmartQoS.


Такой подход бывает необходим в определенных ситуациях, например, утренний Boot Storm у VDI. Инженеры Huawei учли этот факт есть возможность включать нужный режим QoS по расписанию.


Функция прячется под кнопкой Advanced.



Рисунок 11. Настройка расписания (раздел Advanced).


Выполнить проверку просто необходимо создать политику SmartQOS для одного из LUN'ов с параметрами ниже.



Рисунок 12. Созданная политика SmartQoS001.


Далее снова обратимся к помощи бенчмарка VDBench (в тестировании он встретится еще не раз). СХД с точностью как в аптеке отмеряет нашей эмуляции сервиса предоставляемые IOPS'ы. Для наглядности ниже привожу показания со стороны тестового ПО и со стороны Dorado.



Рисунок 13. Результат выполнения политики SmartQOS.


Выглядит SmartQOS весьма неплохо. По результатам его тестирования могу порекомендовать Dorado к использованию в любой инфраструктуре как для оптимизации работы уже существующих сервисов, так и для изначального планирования, особенно если в СХД размещены крупные базы данных или VDI, требующие особого подхода.


Для последних также важно наличие такой настройки как Burst, когда политика позволяет превысить максимальные значения на определенный срок, задаваемый администратором. Это поможет проще пережить уже упоминаемый ранее Boot Storm. Если у Dorado будет возможность не жертвовать другими сервисами, она спокойно перейдет в режим Burst в политике и обеспечит требуемые параметры производительности.


Подведение итогов для первой части


При подведении итогов принято говорить о преимуществах и недостатках. В данном случае хочется и похвалить, и поругать Huawei за новый веб-интерфейс. В целом, он простой и логичный. Разобраться с ним можно, даже не имея опыта общения с продуктами компании Huawei. С другой стороны, современные интерфейсы должны быть интуитивно понятны во всем. Здесь же выезжающие справа фреймы можно закрыть исключительно нажатием кнопок снизу ОК или Cancel, хотя интуитивно хочется просто тапнуть по неактивному полю страницы.


Что касается результатов тестов они говорят сами за себя. Dorado V6 в реальной жизни выглядит достаточно неплохо, даже в начальной своей конфигурации. По цене младшая Dorado V6 соперничает со многими гибридными СХД, которые показывают куда более скромные результаты в тестах производительности. Ее можно рассматривать к покупке практически под любые сервисы. Разве что для резервного копирования All-flash массивы все еще слишком дороги.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru