Differences

This shows you the differences between two versions of the page.

--- etc:users:kel:diplomas [2024/09/28 23:58] – odoronin
+++ etc:users:kel:diplomas [2024/10/01 15:23] (current) – odoronin
@@ Line 3: / Line 3: @@
 ==== Медицина ====
 === 3D Slicer ===
-> //Технологии:// C++ / Qt / CMake / ...
+> //Технологии:// Python / OpenCV / Qt / OpenFOAM / CMake / C++ ...
 > //Пригодность:// бакалавр / магистр
@@ Line 19: / Line 19: @@
   - Расчёт маршрута проведения инфундибулотомии
   - Учёт газодинамических эффектов и моделирование дыхательного процесса
+На текущий момент в рамках 2 дипломных работ апробированы некоторые методы выделения аномалий и моделирования дыхания. Требуется доисследование с доведением до практического применения + решение остальных исследовательско-практических задач
 ==== Параллельное программирование / High performance computing ====
@@ Line 25: / Line 27: @@
 > //Пригодность:// бакалавр / магистр
-Исследования и доработка примитивов синхронизации glibc/ядра ОС для переключения стратегий синхронизации исходя из анализа текущего профиля исполнения приложения
+Исследования и доработка примитивов синхронизации glibc/ядра ОС для переключения стратегий синхронизации исходя из анализа текущего профиля исполнения приложения и загруженности ОС (contention level). Конечная цель - PR с адаптивной реализацией базовых примитивов в тесном взаимодействии с планировщиком ОС
-//Описание дополняется...//
+  * [[https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/2301|Описание проблемы на примере Postgres]]
+  * [[https://inria.hal.science/hal-04266815v1/file/BPF_Hybrid_Locks_Internship_report.pdf|Базовая идея определения contention level]]
 === YDB ===
@@ Line 38: / Line 41: @@
   * [[https://github.com/ydb-platform/ydb/wiki/Student-Projects#implementation-apache-nifi-ydb-sink|Разработка NoSQL-адаптера к СУБД ydb на основе протокола etcd: необходимо реализовать протокол etcd на основе YDB (активно используется GRPC), сохранив производительность и иные заданные параметры системы]]
   * [[https://github.com/ydb-platform/ydb/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fcli|Интеграция R7 office и YDB]]
-  * [[https://github.com/ydb-platform/ydb/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fcli|Интеграция DBT и YDB федеративных запросов]]
   * [[https://github.com/ydb-platform/ydb/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fcli|Поддержка новых федеративных источников на Go (как PostgreSQL, MySQL, MS и т.д.)]]
-  * [[https://github.com/ydb-platform/ydb/wiki/Student-Projects#implementation-apache-nifi-ydb-sink|Реализация синка YDB в Apache Nifi]]
   * **Кеширование прочитанных данных из S3.** В YDB федеративных запросах поддерживается чтение из внешнего источника [[https://en.wikipedia.org/wiki/Amazon_S3|S3]]. Чтение данных из такого источника может быть медленным, а также данные в нем могут храниться в неструктурированном виде json,csv,xml,raw и даже в сжатом представлении. Предлагается в качестве НИР разработать кеширование на диске прочитанных данных в уже подготовленном и разжатом виде для усорения и минимизации накладных расходов при повторном чтении таких данных.
   * **Автоскейлинг потоковых запросов.** Внутри сервиса [[https://yandex.cloud/ru/services/query|Yandex Query]] поддерживаются потоковые запросы, обработка в которых является бесконечной. Источниками в таких запросах являются бесконечные очереди сообщений. Для обеспечения отказоустойчивости и гарантий доставки данных используются так называемые [[https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/checkpointing/|чекпоинты]]. Но при этом в процессе работы таких запросов может увеличиться объем поступаемых данных и в этом случае нужно иметь механизмы для оценки и масштабирования запросов (в том числе и состояний которые сохраняются при прохождении чекпонитов)
   * **Планировщик для запуска запросов в YQ.** Некоторые системы поддерживаются запуск запросов по расписписания (аля [[https://en.wikipedia.org/wiki/Cron|cron]]). Примером такой системы является [[https://docs.snowflake.com/en/user-guide/tasks-intro|snowflake]]. В работе предлагается провести исследование существующих систем которые предлагают похожие решение. На основе этого анализа предложить варианты решения для Yandex Query и разработать прототип для предложенного решения.
   * **Продвинутый планировщик который учитывает локальный плейсинг с учетом доступных ресурсов для потоковых запросов.** Текущая реализация алгоритма планирования либо умеет явно заселять запрос на один хост или же заселять с учетом доступной памяти. Такие стратегии не всегда эффективны с точки зрения использования ресурсов. Предлагается учитывать струтктуру графов чтобы минимизировать число перессылок и учитывать другие потребляемые ресурсы при планировании CPU/Mem/Net
 ==== Сети ====
 === NetAnim ===