Собрали в одном месте самые важные ссылкии сделали Тренажер IT-инцидентов для DevOps/SRE
Многие знакомы с алгоритмами дерева отрезков и корневой декомпозицией. Однако, не многие задаются вопросом о том, почему они устроены именно так, как они устроенны, и нельзя ли немного изменив их получить выигрыш во времени работы или памяти. Одно из таких изменений я бы и хотел рассмотреть в этой статье.
Когда мы расставляем мебель в комнате, мы ориентируемся на габаритные размеры мебели и фурнитуры, а не на их занимаемую площадь, и мебель часто квадратной формы. С полигонами на карте дело обстоит немного иначе, они могут быть произвольной формы, но должны иметь определенную площадь, а задача такая же как и с мебелью - уместить всё в комнату (участок). Когда полигоны квадратные, то рассчитать нужное изменение длины ребра для получение желаемой площади, не так и сложно. С полигонами сложной формы всё не так просто, но и это тоже не проблема, ведь можно методом тыка подобрать нужную площадь. Проблема возникает когда количество полигонов возрастает. Пример: на изменение полигона сложной формы уходит 5 минут (грубо говоря), но нам нужно изменить 15 полигонов, считаем и получаем 75 минут. За 75 минут можно сделать гору полезных дел, а всего было отредактировано 15 полигонов. Если полигоны придется менять заново? вдруг нужно их будет разбить на другую площадь? Вот была бы такая программа, которая сама бы изменяла полигон и добавляла бы нужную площадь.
На мастер-классе вы будете первыми, кто воспользуется нашей oпенсорсной генеративной моделью. Обсудим, что такое языковая модель и как ее использовать для conversational AI. И на практике: Поборемся с основной проблемой языковых моделей, обученных на корпусе из Интернета — генерация токсичных ответов. Повысим качество ответов болталки с помощью классификаторов. Улучшим качество с помощью промт-тюнинга. Найдем топовый алгоритм декодирования (чтобы ответы были длинные и кайфовые). И в конце обернем нашу модель в сервис и телеграм бота. Так у каждого участника МК останется бот, с которым он сможет поболтать в любой момент. Мастер-класс рассчитан на ML инженеров, которые смогут разобраться с технологиями NLP.
Доклад про выбор компонентов решения MLOps и первые шаги внедрения. Рассчитан на архитекторов, тимлидов и датасаентистов, вовлеченных в построение инфраструктуры для работы моделей машинного обучения. Слушатели смогут понять, зачем нужен MLOps и зачем заниматься его внедрением, узнают, каков был наш путь по выбору компонентов решения и как мы их внедряем.
Летом 2021 Яндекс Погода представила новую модель машинного обучения для прогнозирования дождя — Meteum 2.0. Впервые в истории она опирается не только на данные специализированных приборов наблюдения за погодой, но и на сообщения пользователей об осадках. До Яндекса никто в мире так не делал. Я расскажу, какие данные Яндекс Погода использует для создания карты осадков, как с помощью python и машинного обучения улучшить качество классических методов прогноза. Подробно опишу этапы обучения модели и то, с какими трудностями пришлось при этом столкнуться.
Как подружить OpenAPI и JSON:API. Почему мы решили использовать JSON:API в нашем FastAPI приложении, и какие задачи решает данная спецификация. Для чего применять Compound Documents (included ресурсы). Почему мы не захотели использовать Django с DRF и расширение для JSON:API, а выбрали именно FastAPI. Доклад рассчитан на разработчиков, имеющих опыт с веб-приложениями на Python, а также тех, кто работает с REST API. Слушатели познакомятся со спецификацией JSON:API, узнают, как и зачем её применять, научатся применять готовые решения для быстрого создания ресурсов с поддержкой JSON:API.
В докладе рассматривается текущее состояние PyPI: от статистики по пакетам и отдельным характеристикам хранимых артефактов, до трактовки тенденций в python-сообществе на сегодня. Нельзя обойти стороной и (как никогда!) актуальный вопрос безопасности компонентной базы и цепочки поставки в целом, поговорим про: typosquatting, dependency confusion и malware в пакетах и средствах предотвращения угрозы. Доклад рассчитан на dev, devops, devsecops, (+pm?) Слушатели: -узнают, что происходит с пайтон пакетами сегодня, интересные статистики и картиночки -получат понимание инфраструктуры пакетного индекса и сообщества, его окружающего -подкуются в базовых принципах безопасной разработки (devsecops)
В докладе поговорим о том, как использование стандартных возможностей уже готовых инструментов делает проект проще, как избавиться от лишних зависимостей и не потерять, а иногда и приобрести в функционале. Рассмотрим, как маршрутизация на кролике дает то, что не всегда может дать сторонний инструмент. Заглянем в то, как правильно заданный вопрос "почему и зачем" уменьшает количество проблем на проде. И конечно обсудим, на какие грабли мы наступили сами и какие встретятся, если выкинуть внешние зависимости.
Данные — это актив, они имеют реальную ценность, необходимо уметь ими управлять и защищать их. Мы в Тинькофф строим свою систему типа Data Catalog. Эта система собирает в себе все метаданные о таблицах, отчетах и бог знает чём еще в рамках предприятия и предоставляет инструменты для простого управления метаданными и самостоятельного поиска по ним. Я расскажу о том, как мы наполняем наш Data Catalog метаданными из более чем 25 источников, используя Apache Airflow. Как мы придумали подход, а затем и создали небольшой фреймворк.
В современном мире уже никого не удивить машинным обучением. Наиболее важно обеспечивать высокое качество и надежность моделей и, как следствие, бурно развиваются MLOps инструменты, которые позволяют управлять всем жизненным циклом машинного обучения. Мы в Яндексе, конечно, тоже делаем такой инструмент для внутренних пользователей. Один из его элементов — инструмент для пообъектного сравнения, позволяющий понять на каких объектах разные модели ведут себя лучше, а на каких хуже. Проблема заключается в том, что общий объем данных для сравнения может быть довольно большим. Кроме того, необходимо предоставить пользователю удобные средства сортировки и фильтрации для анализа полученного сравнения. В своем докладе я расскажу, как мы такой инструмент строили, развивали, и к чему в итоге пришли. Доклад будет интересен Data инженерам, разработчикам ETL процессов, специалистам по качеству и анализу данных.
Графы знаний активно применяются для улучшения пользовательских рекомендаций (амазон, нетфликс), для анализа фондового рынка (goldman sachs), поиска (яндекс, гугл) и даже для поиска новых молекул. Также это может быть удобным корпоративным инструментом, который объединяет и связывает данные внутри компании из разных источников. Это помогает исследователям, аналитикам и дата саентистам.
В докладе расскажем о том, как мы разрабатывали инструмент для запуска разнородных тестов на разнородном железе. Доклад рассчитан на разработчиков, тестировщиков, билд-инженеров и менеджеров, которые: планируют построить систему CI/CD, включающую прогон тестов на железе и эмуляторах; хотят иметь единый подход к запуску тестов; хотят, чтобы в их проектах была трассируемость результатов выполнения тестов в требования; имеют большой зоопарк разнородного железа, на котором нужно прогонять тесты.
Поговорим про мониторинг ML-моделей в production: о том, зачем и как это делать, что такое data drift и как его измерить. Также расскажу о том, почему выбор "правильной" метрики для data drift — одно из главных решений в мониторинге, и поделюсь результатами исследования пяти популярных статтестов, которое мы недавно провели в Evidently. На примерах покажу, как ведут себя разные метрики в зависимости от объема данных и размера data drift. Слушатели смогут сформировать интуицию о том, как ведут себя различные статтесты для определения data drift, и подобрать подходящую метрику под свою задачу и "сценарий" использования.
Общая задача обнаружения аномалий во временных рядах часто разделяется на две отдельные задачи: обнаружение выбросов или бинарная классификация (для точечных аномалий) и обнаружение точек изменения состояния (changepoint detection, для коллективных аномалий). В докладе подробно рассмотрена задача changepoint detection, методы для обнаружения точек изменения состояния, библиотеки на python, с помощью которых можно решать эту задачу. Также в докладе продемонстрирована реализация на python одного из самых распространенных подходов к решению задачи (генерация невязки сигнала) без применения специализированных библиотек.
Мультипроцессинг в питоне вещь актуальная, особенно если вы занимаетесь ML сервисами. Но если вы попытаетесь использовать его в ваших сервисах — вы непременно наткнетесь на ряд подводных камней, которые почти нигде не обсуждается. В докладе я бы хотел рассказать про наш опыт использования мультипроцессинга, с какими проблемами можно столкнуться, затаскивая его в реальные продакшн сервисы. Из этого доклада можно будет узнать: В каких случаях нужно использовать shared memory и как корректно и эффективно с ней работать. Расскажу про атомарные счетчики ссылок как альтернативу стандартным методам контроля над шареной памятью в питоне. Скрытые баги в стандартных питоновских очередях. Мультипроцессорные очереди в питоне ведут себя контринтуитивно (например, говорить, что очередь пуста, когда в ней на самом деле лежит куча тасков), плюс они не совсем кроссплатформенные. Эти вещи мало где обсуждаются, а проблемы, связанные с ними, напрямую аффектят сервисы. При этом сходу не понятно, что произошло не так и как можно это исправить.
Во время работы над сложными проектами, например, такими как виртуальные ассистенты, возникают нетиповые задачи, для решения которых нет подходящего инструмента или фреймворка. Иногда такие задачи кажутся маленькими и незначительными, поэтому один разработчик-энтузиаст за два дня пишет на коленке маленький Python сервис и делится им с коллегами. Но как быть, если маленький наколенный проект с 2 RPS, предназначенный для использования несколькими людьми, выстреливает, и его накрывает волна фича реквестов и пользователей из десятков команд? В своём докладе я расскажу, как развивался наш внутренний инструмент UnionPortal, предназначенный для поддержки NLP задач, про его эволюцию, начиная с маленького наколенного проекта и заканчивая большим отказоустойчивым сервисом со всеми правилами хорошего тона enterprise сервиса. Мы затронем такие интересные вопросы как масштабирование, бесшовный вывод из и ввод в эксплуатацию, сокращение стоимости разработки и внедрение единого архитектурного стандарта.
Большинство разработчиков знают символ звёздочки как оператор умножения в Python: product = 4 * 2 # 8 Однако, звёздочка имеет особое значение для сложных структур данных, например списка или словаря.
Если вы полезли в аналитику, то, вероятно, обнаружили, что там много, ну ОЧЕНЬ МНОГО графиков. Иногда хватает одного, и тогда всё отлично. А если нужно два? А если пять? И рядом. Тут поможет matplotlib.
Одним из главных достоинств Python является выразительность кода. Не последнюю роль в этом играет возможность удобной работы с коллекциями и последовательностями различного вида: перебор элементов списка по одному, чтение файла по строкам, обработка всех ключей и значений в словаре. Эти и многие другие подобные задачи в Python помогает решить так называемый протокол итераторов (Iterator protocol). Именно этот протокол обеспечивает работу цикла for, устанавливает по каким объектам можно итерироваться, а по каким нет. Как мы увидим далее, сам язык и стандартная библиотека очень широко используют возможности протокола. В этой статье попробуем отыскать не самые известные, но от этого не менее интересные примеры итераторов и итерируемых объектов, которые предлагает Python.
Сегодня рассказываем как написать простой MQTT-клиент на Raspberry Pi при помощи MicroPython и реализовать функции подключения, отправки сообщений и подписки между клиентом и брокером MQTT-сообщений.