Стажування - інженерія даних в конвеєрі

Пропозиція теми диплому NPX Спостережність RQ1: Проблема дослідження: Під час запиту PA для отримання даних про використання HPC виникають прогалини. Цей процес запиту ще більше розширює прогалини між фактичним використанням HPC та зареєстрованим використанням HPC, можливо, через те, що PA не спостерігає чи не зберігає дані під час цієї дії. Питання дослідження: Як нам точно спостерігати за даними та вести відповідний звіт про використання HPC? Що таке спостережність? В широкому розумінні, спостережність - це ступінь, до якої можна зрозуміти внутрішній стан або умови складної системи, базуючись лише на її зовнішніх виходах. Чим більша спостережність системи, тим швидше і точніше можна визначити проблему продуктивності та її первинну причину без додаткового тестування або кодування. Для цієї проблеми дослідження спостережність буде використовуватися для моніторингу використання HPC. Метод дослідження (можливе рішення): Рішення полягає в посиленні спостережності кластерів HPC. • Введення нових метрик та автоматичних методів для виявлення наявності прогалини. • Вивчення телеметрії спостережності, щоб визначити частоту значної прогалини, яку потрібно розв'язати. • Аналіз взаємозв'язку між метриками та прогалинами, щоб активувати рішення для виправлення прогалини, перш ніж вона стане занадто великою. На основі цього, ми можемо створити інструмент, який може вирішити цю проблему з прогалиною. Основна мета - пасивно спостерігати за кластером HPC, щоб зібрати важливі метрики, які використовуються інструментом рішення. Це дозволяє інструменту працювати як черга: захоплені метрики розміщуються у черзі до інструмента, який може перевірити, чи є у PA зазор порівняно з тим, що спостерігав інструмент. Проблема з запропонованим рішенням: Постійне спрацьовування бази даних для спроби досягти нульової прогалини передбачає регулярне викликання оновлення. Отже, потрібно встановити прийнятну мінімальну прогалину для бізнес-випадку. Критичне завдання - уникнути прогалини на певних порогах, наприклад, наприкінці дня, тижня або місяця. RQ2: Проблема дослідження: Основне завдання обертається навколо розбіжності між фактичним використанням HPC та зареєстрованим використанням HPC. Рішення для цієї проблеми повинно бути узагальненим, щоб вирішити інші проблеми з прогалиною, що виникають із спостережності HPC. Питання дослідження: Чи може попереднє рішення бути узагальненим, коли його застосовують до іншої системи? Метод дослідження: • Заплануйте систему, для якої ми хочемо покращити спостережність • Виявіть, чи можемо ми виміряти параметри, які можна використовувати для встановлення системних показників • Перевірте, чи можуть ці нові метрики використовуватися для попереднього рішення. Цей тактичний хід повинен дозволити нам впровадити узагальнену логіку та налаштувати її, враховуючи структуру системи, тим самим із використанням універсального рішення на різній системі шляхом персоналізації метрик. RQ3: Проблема дослідження: Стійкість потоку даних та її інфраструктури. Питання дослідження: Як ми можемо передбачити вимірювані проблеми, які можуть перешкоджати роботу? (наприклад, аварії в потоці) Метод дослідження та запропоноване рішення: Визначте сценарії, в яких може зазнати невдачу потік: • Проведіть аналіз попередніх проблем з потоком та їх звітів • Виявіть деякі крайні випадки RQ4: Проблема дослідження: Потік даних та інфраструктура мають систему резервного копіювання, яка може відновити збійний потік даних. Питання дослідження: Як ми можемо перевірити ефективне функціонування системи резервного копіювання? Що таке інженерія хаосу? Інженерія хаосу включає набір принципів, спрямованих на покращення стійкості системи. Вона включає в себе формування гіпотез навколо поведінки системи в стабільному стані, змінюючи реальні події, проводячи тести в продукті, автоматизуючи експерименти для постійного виконання, та зменшуючи радіус розповсюдження експериментів. Метод дослідження (можливе рішення): Інженерія хаосу може бути використана для перевірки стану резервних копій за допомогою експериментів хаосу. Остаточна мета запропонованого підходу передбачається для підвищення стійкості системи резервного копіювання, що гарантує, що в разі збою в потоці відновлення цього потоку буде більш продуктивним, без необхідності перезапускати потік з початку. Посилання: https://www.ibm.com/topics/chaos-engineering https://www.gremlin.com/community/tutorials/chaos-engineering-tools-comparison/. Додаткову інформацію про NXP в Нідерландах можно знайти тут.